【IT168 专稿】由VMware主办的虚拟化及云计算年度盛会vForum 2011在北京国际饭店会议中心拉开帷幕。本届大会主题为“Your Cloud，Own it”，中文译为 “你的云你掌控”，大会上主办方详细讲解了虚拟化和云计算最新的发展趋势，以及其将如何促进 IT 加速发展，从而帮助企业业务更有效地适应市场，竞争和客户的需求。
在vSphere 5.0之前的版本中有一个非常重要的功能组件vSphere HA，vCenter Server(VC)用来配置和管理集群，但是在发生宕机的切换操作却独立于VC，FDMs仍然默认通过主机管理网络进行通信。但在5.0中，vSphere HA被全部重写，以简化HA集群的设置与管理，为更大的规模和功能提供基础，并提高了HA的健壮性和故障应对的能力。那么vShare 5.0中的HA功能到底在哪些方面进行了加强呢?
vSphere HA 5.0中的master与slaves
新的vSphere HA代理被称之为Fault Domain Manage(FDM)，其旨在Host上提供所有的HA相关功能。说到FDM，就不得不提到另外两个新的概念，即master和slaves。与以往所有版本中不同的是，5.0中不再有pnmary和secondary的概念，取而代之的是master和slaves。Master FDM的职责是监控整个集群中的主机或虚机的可用性，负责主机或虚机失效后的VM重启，并向VC报告集群的状态和故障信息，同时还维护集群的持久状态信息。一般来说，一个集群仅有一台master，其他的FDM被指定为slaves。master通过选举产生，任何一台FDM都可以被选举为master。
与master相对的slaves的职责则是将关键的状态变化信息转发给master，并根据master的指示重启VM。在master失效的情况下，参与新的master的选举。不管是master还是slaves也好，每一台FDM的通用职责是监控本地主机和VM的状态，实现VM或应用的监控特性。
Master的选举主要分为四种情况，即vSphere HA被启动时、masters主机失效、master主机上HA被重新配置以及进行管理网络分区时会对master进行选举。如果存在多个master的情况下，除了保留一个master之外的所有主机都要进行推出master状态的操作。Master选举耗时极短，大约在15秒到20秒之间。选举master的依据主要为主机挂载的Datastore的数量，数量相等的时，则通过Host ID进行选举，以保证每个集群只有一个master。
FDM双重通讯保证业务连续性
与上一代产品不同的是，FDM代理之间的通讯是通过管理网络进行环状通讯，当管理网络不可用时，则通过Datastore进行通讯。使用环状通讯的好处在于，所有的通讯都是点对点通讯，并通过UDP进行选举。为保证数据传输安全，所有的master到slaves之间通讯都被通过SSL的方式进行加密。
在使用了管理网络进行后，还增加了存储心跳这个功能的最大目的在于更好地保护集群中主机的业务不受其他故障的局限，更好地保证业务连续性。在本堂技术课程了，VMware给我们介绍了由于通讯不畅所引发的三种典型故障，不用通过手动方式，vSphere自动就能进行恢复。
主机故障
当主机无法连接到master，也无法响应ICMP pings，同时master也无法侦测到该主机的存储心跳时，master就会声明这台主机为Dead。并且master就会尝试重新启动该主机上的所有虚机，或者在网络可达的其他主机上火master本身重新启动这些虚机。
主机被网络分区
当master无法通过管理网络和某一台主机进行通讯，但master却可以检测到其存储心跳时，则声明这台主机为网络分区。此时，每个分离的网络分区都会进行选举，并产生一个master，在网络隔离的情况下，VC只会和一个master通信，任意一个VM都只能被一个master管理。在其他分区中的虚机将会通过存储心跳进行监控，一旦失效就会在所在的分区中重启虚机。一旦管理网络恢复之后，就仅仅只保留一个master，其他master将进行退出操作。
网络隔离
当主机无法看到vSphere HA网络通信或者无法ping通隔离地址时，即可判断这台主机发生网络隔离。此时，主机就将进入隔离响应，并检查是否有master控制一个虚机，如果虚机被master控制或者datastore不可访问，则应用隔离响应，Master重启关闭的虚拟机;如果能够通过存储心跳访问，则主机报告为隔离，否则报告为Dead，如果为Dead，则按刚刚讲到的第一种应对方案进行响应。
以上为vSphere HA 5.0中的故障处理机制，在管理网络出现故障的情况下，通过存储心跳来更为准确地判断主机的实际情况，再采取响应的措施解决故障。通过增加的存储心跳来判断主机故障，避免了不必要的重启操作，从而降低了业务中断的风险，极大地保证了业务连续性。
虽然通过上述的故障处理机制能极大地提高业务连续的能力，但其并不能解决所有问题，只有VC得知VM进入被保护状态的前提下，才能对其保护，而在master没有将虚机的信息写入完成之前的过程中，虚机都无法得到保护，需要人工进行判断并应对。
vSphere FT下一代架构技术预览
FT全名为Fault Tolerance，其旨在提供不中断的可靠性保障，其主要内容包括零宕机、零数据丢失、不中断的TCP连接以及完全透明的受保护的应用软件等。并且这一切只需要通过超简单的客户界面，只用选择打开FT开关即可完成。
其实FT这个功能在2009年VMware发布vSphere 4.0的时候就已经出现，在2010年时升级为4.1版本，2011年时随着vSphere 5.0的发布而在此升级。在这些版本之中，FT只能工作在单处理器的虚拟机中，那么为多处理器虚拟机设计的FT是否可行呢?据VMware公司相关负责人透露，其已经找到了相关的方法，但要完美解决还存在一定的难度。
上图为目前的vSphere FT架构。新一代的FT架构已基本确定，如下图所示：
据VMware相关负责人介绍，新一代的FT架构必须基于万兆网络才能实现，才能保证数据的一致性，用SMP protocol替代之前的vlockstep，并且，最大的不同之处在于使用两个不同存储分区代替之前的共用一个存储。如上图所展示的那样，客户端默认访问左边的应用程序，而一旦左边发生宕机，可迅速将访问转移到右边的应用。
尽管新一代的FT已经可以实现在多处理器的VM设计上，但却不能让多处理器虚拟机的应用性能最大化。如上图所示，在使用2处理器环境下，SQL Server与Oracle的性能大约能够发挥出80%。但在4处理器的环境下，SQL Server的性能只能达到70%的样子，而此时Oracle的性能还只能在55%左右。还需要进一步的优化。
尽管在多处理器上的表现还不能完全的尽如人意，但实践证明，新一代的 vSphere FT架构能够实现对多处理器虚拟机的保护。未来的vSphere HA或FT将实现对多处理器的支持，并提供对应用级高可靠的更广泛的支持。
