90年代末入行IT的时候正是HA大发展的时候，那时候还是双机热备的天下，我也有幸参与了某HA系统的开发工作，这也就是我这里所提到的传统的HA系统。虽然今天各个主流的HA都成为集群系统，可以支持多个节点，但是双机热备仍是最主流的应用模式。随着云计算时代的来临，传统基于操作系统的HA系统正在走向末路，云计算正成为传统HA的终结者。
传统HA系统的DNA就存在缺陷。HA系统本来是要解决软硬件系统故障时应用的可用性问题，如果主节点出现故障，可以通过部署在备用机器上的应用来接管主节点的工作。这个基本逻辑没有问题，并且看上去也很合理。但是因为传统HA的构建模式和传统的容灾系统类似，只是容灾系统往往距离比较远，而HA系统就是本地放在一起的两台机器而已。因此，HA系统的心跳往往有更多选择，并且更可靠。但就因为传统HA的设计和容灾类似，所以，管理的复杂性就不言而喻。
· 传统的HA节点配置同步困难：即使采用常见的双机配置，我们也要确保两边操作系统版本、配置的一致性、补丁一致性、两边相关软件的版本、配置一致性等等，系统运维的复杂性骤升。两节点的传统HA系统配置同步都困难，更不用说多节点了。时至今日，多节点的HA(或称为集群)系统基本都陷入“理论可行、运维人员头疼、实际没有几个客户采用”的尴尬。无论是微软的MSCS、Symantec的VCS、IBM的HACMP等，都逃不出这个怪圈，因为这是传统HA系统的DNA缺陷，根本不是后天可以弥补的。
· HA系统需要演练，传统HA演练复杂导致几乎没有用户进行演练：因为操作系统、应用配置都会不断发生变更，这些变更可能会影响到HA系统的正常工作。为了验证HA系统的工作情况，需要每次进行操作系统、应用等变更时都需要进行HA系统的演练，只有这样才能确保发生故障时HA系统的正常工作。但是因为系统往往变更频繁，如果每次变更都需要演练HA的话，运维的压力会极为巨大，导致系统失去维护性。
· 传统HA成本昂贵，只能针对“特权”应用来部署：因为维护的原因，几乎所有的传统HA都是双机方式存在，导致传统HA系统都需要配置完全相同的主备节点硬件资源，并且需要购买主备节点操作系统和应用软件，导致系统软硬件成本都同时加倍，而运维的复杂性不仅仅是加倍，甚至是3-4倍。这让传统的HA听上去很美好，但是一般的应用都不能享受这个特权，只有十分关键的应用才能配备HA系统，传统HA的贵族习性也因此被大量广泛诟病。
云计算像一股旋风席卷了整个IT界，也在颠覆传统IT的贵族习气。传统认为低端的x86服务器也开始支撑高端大气上档次的应用，原来只有大型用户才能享用的数据中心级的可用性、可靠性，今天中小用户也可以通过公有云租用，大型数据中心神秘的面纱已被揭开。传统贵族气十足的HA何去何从呢?
自从虚拟化的x86服务器颠覆了传统小型机的霸主地位，一系列的革命性创新就无往不利，包括VMotion、DRS、DPM等。当然，传统的HA也不在话下，通过在Hypervisor层提供HA的功能，让传统HA的桎梏瞬间打开。因为传统的操作系统和应用全部运行在Hypervisor层之上，基于Hypervisor的HA可以完全独立于操作系统和应用，无论多节点的集群还是简单的双机HA都不需要在操作系统层和应用层做复杂的配置，也无须购买多套应用软件和操作系统，节约的不仅仅是购买操作系统和应用软件的费用，也包括减少大量硬件资源的购置成本。HA系统从此走下神坛，中小型用户都可以轻松拥有，并且便捷运维这个系统。传统HA昂贵的培训费用再也不需要了，只需要点两三个按钮就轻松完成原来需要半天才能完成复杂的HA配置工作，并且原来HA维护的复杂性也变成了系统的自我监控，因为原来需要的配置同步、演练等的流程全部可以取消。因为任何运行在HypervisorHA之上的应用都只有一个副本，根本不存在配置同步等的问题，也就无需演练这样复杂的操作。另外，基于虚拟环境还可以轻松实现克隆、快照等系统的保护，在HA系统的基础上进一步增强了系统的可用性。
当然，***代的HypervisorHA仍然是系统级的，不能检测应用的故障，曾经被很多用户诟病。为此，有些第三方的公司在Hypervisor上添加了自己的应用级HA模组，比如SymantecApplication HA的。不过可喜的是***版本的vSphere5.5，已经内嵌了应用支持代理，默认就可以支持各种常见的应用了，从而让HypervisorHA完全具备了传统HA的能力，而抛弃了传统HA的贵族习气。
随云而生的HypervisorHA正茁壮成长，焕发出勃勃生机，以秋风扫落叶之势，迅速占领关键应用的制高点。传统HA系统已经完成了自己华丽的使命，可以寿终正寝了，即使你很念旧情，也不能阻挡HypervisorHA的来袭。就让我们张开双臂，热情拥抱云计算时代的新宠HypervisorHA吧。
本文出自 “中国云梦” 博客，请务必保留此出处http://virtualman.blog.51cto.com/200540/1324649
