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地震虽然渐渐离我们远去,但对灾后重建我们并不陌生。
image
Symantec VCS典型的Cluster图
传统Cluster存在的问题
有了对传统Cluster的基本认识,咱们分析一下它存在的问题。我曾经在毕业后的一年内专注于Cluster软件底层的开发,曾经在之后的3年时间里经受过很多用户的质问。基本的体验是Cluster易建,灾难后成功切换难求。为什么会有这样的体验呢?我个人认为这和传统Cluster的设计有关。搭建过Cluster系统的都知道,建立一个Cluster系统不难。但是难就难在系统出现故障后,Cluster的切换往往失败。而当初建立的时候,进行的各种切换都没有问题,这着实成了传统Cluster永远难以摆脱的诟病,很多用户干脆将之归结为Cluster软件本事。但事实是怎样的呢?
传统的Cluster是基于主从结构的设计,平时应用运行的机器我们一般称之为生产服务器,平时应用运行在生产服务器上。但是为了保证应用可以在备用服务器上运行,就必须在备用服务器上安装同样的操作系统、应用、补丁等。为了确保应用的切换成功,两台对应的服务器就是确保始终一致,包括操作系统、补丁、应用和应用补丁等。并且,还要确保安装在上面的Cluster软件也能兼容操作系统补丁和应用补丁等的变化,否则故障切换就无从谈起。可是大多数人维护这一系统,往往不能确保生产服务器和备用服务器应用的更新一致,因为我们可能经常要给操作系统打补丁、对应用打补丁、甚至升级等,另外系统的其他变更也都可能影响Cluster的运行。要保证Cluster的正常运转,系统变更的流程如下(以操作系统打补丁为例):
操作系统打补丁 image检查应用对该补丁的兼容性 image 检查cluster软件对该补丁的兼容性 image兼容性检查可行后,在生产服务器安装补丁 image在实际环境测试补丁无误(包括应用对该补丁的适应性和Cluster软件的切换测试等) image在备用服务器上安装补丁 image在备用服务器上执行应用的检查等
我相信大家看完这样的步骤,会觉得十分繁琐,往往省略了某些步骤。而系统真的运行了一年半载后出现问题,往往就难以保证系统发生切换。
vHA确保100%切换成功
vHA的设计思路和传统的完全不同,抛开了在操作系统里安装Cluster软件和应用运行2+份的尴尬,应用只有一份。部署Cluster后,应用的维护模式没有发生任何变化,你仍然可以安装传统的方式来管理你的应用,大大降低了Cluster系统维护的复杂性。另外,因为系统里只有一份应用,确保了发生灾难后系统恢复的可靠性,不存在测试好用,实际环境不灵的尴尬。
说的简单点,传统的Cluster类似当今的搬家方式,是需要购买新房子,将老房子里的东西一件件搬到新家,结果往往是需要扔掉很多东西,因为新家和老家结构可能不同。vHA是基于平台的Cluster,搬家是搬房子,不动家里的任何东西,因此不需要更改家里的装修或者其他的东西,因此简单易行,可靠稳定。
image
vHA的典型架构
今天这一讲就到这里,如果大家希望了解vHA进一步的信息,请参考VMware的网站 http://www.vmware.com/products/high-availability/。下一讲再见。

你可能感兴趣的:(cluster,平台,业界,vPower,vHA)