vPower系列3：vHA-业界第一款平台级Cluster方案

vPower今天开讲第三讲-vHA。说到HA，我相信大家并不陌生，今天业界的各种解决方案都有提到HA的功能，本意是High Availability。但是，今天咱们这里开讲的vHA，是和我们平时见识的Cluster对应的技术，就是虚拟平台本身的HA技术。

传统Cluster概述

为了区分平时的Cluster解决方案，咱们还是先回顾一下大家熟悉的集群Cluster技术。集群技术已经被广泛应用，包括Microsoft的MSCS、IBM的HACMP、HP的McService Guard、Symantec(VERITAS)的VCS、当年Digital的TruCluster、国内曾经流行过的Rose HA、Lifekeeper等，在此不一一列举。说道这些集群技术，基本原理都很类似，就是为了应用的高可用性，通过集群软件监控硬件、应用的进程等，一旦发现应用运行出问题，马上启动在备用服务器上进行重新构建该应用的运行环境，包括获取磁盘的访问权、建立对外服务的基础环境、启动应用的相关进程等。说白了一点，就是应用运行环境遭到破坏，马上在另外一个地方重构该应用的运行环境，就类似灾后重建。2008年512地震虽然渐渐离我们远去，但对灾后重建我们并不陌生。

Symantec VCS典型的Cluster图

传统Cluster存在的问题

有了对传统Cluster的基本认识，咱们分析一下它存在的问题。我曾经在毕业后的一年内专注于Cluster软件底层的开发，曾经在之后的3年时间里经受过很多用户的质问。基本的体验是Cluster易建，灾难后成功切换难求。为什么会有这样的体验呢？我个人认为这和传统Cluster的设计有关。搭建过Cluster系统的都知道，建立一个Cluster系统不难。但是难就难在系统出现故障后，Cluster的切换往往失败。而当初建立的时候，进行的各种切换都没有问题，这着实成了传统Cluster永远难以摆脱的诟病，很多用户干脆将之归结为Cluster软件本事。但事实是怎样的呢？

传统的Cluster是基于主从结构的设计，平时应用运行的机器我们一般称之为生产服务器，平时应用运行在生产服务器上。但是为了保证应用可以在备用服务器上运行，就必须在备用服务器上安装同样的操作系统、应用、补丁等。为了确保应用的切换成功，两台对应的服务器就是确保始终一致，包括操作系统、补丁、应用和应用补丁等。并且，还要确保安装在上面的Cluster软件也能兼容操作系统补丁和应用补丁等的变化，否则故障切换就无从谈起。可是大多数人维护这一系统，往往不能确保生产服务器和备用服务器应用的更新一致，因为我们可能经常要给操作系统打补丁、对应用打补丁、甚至升级等，另外系统的其他变更也都可能影响Cluster的运行。要保证Cluster的正常运转，系统变更的流程如下（以操作系统打补丁为例）：

操作系统打补丁 检查应用对该补丁的兼容性 检查cluster软件对该补丁的兼容性 兼容性检查可行后，在生产服务器安装补丁 在实际环境测试补丁无误（包括应用对该补丁的适应性和Cluster软件的切换测试等） 在备用服务器上安装补丁 在备用服务器上执行应用的检查等

我相信大家看完这样的步骤，会觉得十分繁琐，往往省略了某些步骤。而系统真的运行了一年半载后出现问题，往往就难以保证系统发生切换。

vHA确保100%切换成功

vHA的设计思路和传统的完全不同，抛开了在操作系统里安装Cluster软件和应用运行2+份的尴尬，应用只有一份。部署Cluster后，应用的维护模式没有发生任何变化，你仍然可以安装传统的方式来管理你的应用，大大降低了Cluster系统维护的复杂性。另外，因为系统里只有一份应用，确保了发生灾难后系统恢复的可靠性，不存在测试好用，实际环境不灵的尴尬。

说的简单点，传统的Cluster类似当今的搬家方式，是需要购买新房子，将老房子里的东西一件件搬到新家，结果往往是需要扔掉很多东西，因为新家和老家结构可能不同。vHA是基于平台的Cluster，搬家是搬房子，不动家里的任何东西，因此不需要更改家里的装修或者其他的东西，因此简单易行，可靠稳定。

vHA的典型架构

今天这一讲就到这里，如果大家希望了解vHA进一步的信息，请参考VMware的网站 http://www.vmware.com/products/high-availability/。下一讲再见。