四大因素决定应用程序可用性

ZDNet至顶网服务器频道 10月10日 ： 在完全由物理部件组成的世界里，单个应用程序只能在单个的服务器上运行。如果服务器有任何闪失无法正常运作，那这应用程序也会跟着完蛋。 采用集群可以规避单个服务器存在的风险：将多个服务器集合成一个整体来运行应用程序，应用程序不再会因为单个服务器的故障而崩溃。

虚拟化手段能汇集数百、甚至数千台服务器组成集群，使单一服务器的故障丝毫不会成为问题。云计算充分运用了相同的概念，创建出可供应用程序使用的动态、弹性的资源池——个别组成部分的故障对应用程序可用性和性能的影响根本难以察觉到。

好极了！现在我们实现高可用目标了，然后，故事结束，真的这么简单？

很不幸，还早着呢！！

高可用性的实现远比初看上去复杂。高可用性并不局限于服务器领域，只是服务器的脆弱性更明显，在历史上就自然成为可用性问题的焦点。 网络可用性、存储可用性、数据镜像——甚至是应用程序代码中的缺陷——都足以使应用程序性能陷入谷底。

网络可用性问题

虚拟化的、网状网络结构集合多个物理网卡建立可按需动态分配的带宽资源池。如果某条物理网络链路连接中断，业务流量会很轻松地被立即路由到其它物理链路继续传输。

网络系统必须从架构上消除单一故障点。每台物理服务器系统都应使用多个网络接口卡，但这对于大多数IT组织而言，这并非主要的技术或者成本问题。

存储可用性问题

存储一直是应用程序可用性的最大障碍。 存储系统可以被虚拟化，但数据以物理的方式存入某些存储设施时，可用性问题依然存在：物理设施总会产生故障和引发问题。

技术上，类似RAID和其它冗余存储技术可以避免因为单个磁盘驱动器失效引起的问题，但这仍然保留着磁盘控制器或RAID控制器方面的单一故障点。对付存储故障的最简单途径是将数据实时镜像保存到另一个物理存储设施。 这种办法成本高昂，因为需要再买一套和主存储设施容量一样的镜像存储。

这种办法也有技术上的困难，包括如何确保数据能够实时镜像，如何识别存储器失效时正在进行的事务、如何定义数据恢复点。一旦确认被确认，应用程序就会被故障转移到镜像存储设施，应用程序数据存储点也被重新分配到新的虚拟LUN。

存储级别的业务连续性后台保障技术正在飞速发展，如果投资于恰当的技术，在数据中心内部实现高可用性是完全可行的。

外部问题

那么，如果故障在数据中心外部发生时会怎样？ 在许多情况下，数据中心会继续有效运转，但是数据中心数据进出的通道拥塞。例如，某条租用线路被挖掘机挖断，同时也就切断了数据中心的访问通道。 从不同的方向引入不同供应商的线路接入数据中心可以满足关键应用所需的可用性水平，但是成本也同步上升。在大多数情况下，这方面的代价是值得的。

再考虑一下更难对付的故障，例如数据中心内发生火灾，或者遇到大范围的自然灾害。在这种情况下，没有哪一种独立的高可用性手段可以保护你。 要在灾难中仍然维持高可用性，就必须建立数据中心的交叉镜像。数据中心镜像代价极其高昂，但如果应用程序中断会立即导致巨大经济损失，那这种投入也是必要 的。

如果只是在较近的距离实现数据中心镜像，其技术难度和单设备镜像几乎相同。随着距离的增加，数据传输延迟将成为最大的问题，特别是在高速事务处理环境下。 要让镜像系统故障转移切换对业务和客户的影响最低，就要尽量准确识别故障发生时系统事务处理的具体状态。

无论你在服务器、网络和存储的可用性上花多少心思，都无法弥补应用程序本身的代码错误。程序代码中的内存泄漏或者其他缺陷必须采用全面的代码测试和运行垃圾汇总手段来检测和排除，否则高可用性就永远只是幻想。

最后，不要让应用程序在数据中心例行维护期间关闭。应用程序的一个实例升级或修补期间，另一个实例应该继续保持运行。 更新后的实例效能会更好，运行中的实例会快速切换到新的版本——这种故障转移几乎是实时完成的。切换过程或许会导致几秒钟延迟，但不会有实质的影响。

哪种应用程序可用性方法是最好的？

大多数机构会混和使用用多种高可用性解决方案。一些企业会将他们主要应用系统的灾难损失控制在几个小时以内。 对于他们来说，仅仅使用标准的服务器和网络虚拟化方法不足以保障他们的应用程序可用性，必须在存储上配合使用RAID保护。

如果应用程序停机会对企业造成损失，就必须采用云计算平台和数据镜像来实现更高级别的防护。缺乏可用性保障的应用系统随时可能会沉重打击企业的财政和品牌形象，那就必须考虑对整套设施进行镜像。

IT部门和企业高管必须认同高可用性对于企业的重要程度，在企业应该投资哪些可用性保障措施方面达成一致。