无论是一台虚拟机崩溃或是主机出错，高可用性虚拟化（HA）应用工具保证可以自动重启出错的虚拟机。这些HA应用却为开发人员和服务器管理员带来了不切实际的希望。

　　服务器管理团队开始相信他们可以将HA工具应用于各式各样的企业套管程序，但是最近由数据中心之间虚拟机的机动性带来的挑战，正是错误地相信了HA的魔力所带来的直接后果。

　　让我们来关心一下关于HA产品的传说与现实情况：

　　VMware的高可用性：假定你可以准确地检测到一个虚拟机操作系统或应用服务出错（例如：数据库软件），但你仍然需要重启虚拟机。一些时间的流失就是系统可运行性上一个9的损失（系统的可运行性一般用百分数表示，常用的是5个9——99.999%，一个9的损失就会使可运行性降至99.99%）。

　　VMware的容错性：这个特征是指在两台主机上分别同时运行相同虚拟机的两个不同副本。对于短期问题而言这是一个完美的解决方案，例如：我不想让硬件问题中断我的长时间的批处理任务。可现实问题是如果虚拟机或是它自己的软件崩溃，这个虚拟机的两个副本会同时崩溃。

　　高可用性集群：类似Windows Server故障转移集群技术（Failover Clustering）的策略会在同一个或者另外一台服务器上重启失败的服务（例如：SQL服务），与此同时，这种重启会耗费若干秒钟到若干分钟的时间不等，有时如果数据库必须进行大规模恢复时甚至会耗费更长的时间。这也会降低系统的可运行性。

　　现在让我带来另外一种数据观点：我们最近经历了一次由一个站内STP协议错误导致的转发循环。在网管系统（NMS）及时发现问题和一个操作员现场支持的情况下，恢复时间花费了将近30分钟。不可否认，这其中一些时间花在了收集便于事后处理分析的证据上。

　　下一个事实：数据中心之间的桥接可能会导致长距离的转发循环，或者你可能看到由转发循环导致的流量泛洪溢出链接其他数据中心的WAN，截断同所有其他数据中心之间的流量（如果你有足够的勇气使用长距离的集群的话，也会截断集群心跳线的流量）和存储响应。你真的愿意将整个IT基础设施置于风险中来支持一个无论如何连3.5个9的可运行性都无法达到的应用吗？别忘了，大家都希望服务器管理员可以为服务器打补丁，而打补丁偶尔需要重启，不是么？

　　故事的寓意：“魔力”产品让你产生一种错误的安全感；就像MySQL数据库集群一样，好的应用架构和使用真正高可用性的产品才是唯一正确的应对高可用性挑战的解决方案。