从各个厂家的数据表上看高可用性软件以及其它产品看起来可能是相同的，但是在这些产品的背后却有很大的不同。

　　详细地探究和测试这些属性是非常重要的，因为这些属性可能会影响到高可用性架构的恢复性能、可扩展性、故障侦测和管理。

　　评估高可用性软件

　　在测试虚拟化管理程序厂商的高可用性软件和产品或者验证内部配置时，需要注意以下几个方面：

• 物理服务器故障发生之后的自动虚拟机恢复；
• 虚拟机客体操作系统发生故障之后的自动虚拟机恢复；
• 确定虚拟机布局的标准；
• 服务器发生故障之后的虚拟机平衡和重新布局；以及
• 集群底层存储架构相关的虚拟机部署和管理TCO；

　　通常情况下，任何高可用性软件断电之后都应该重新启动尚存集群节点上的虚拟机。常见的宕机备份方法测试都是通过直接拔掉物理集群节点上的电源线进行的。需要检查清楚高可用性架构中的宕机备份是由不太严重的硬件问题（如网络故障）引起的，还是由存储端口（存储端口故障可能把服务质量降低到可接受的标准以下）引起的。

　　另外还需要测试集群的“裂脑（裂脑是指系统中的节点间因人为/非人为故障而中断的结果。节点间不再能够获知彼此的状态而有可能执行主动激活的策略，争取获取双机资源）”免疫属性，可以通过拔掉其中一个物理服务器节点上集群侦听网络连接，并且确保在另外一条路径上（如网络或者光纤通道上）继续保持没有中断的集群侦听流量。

　　最后需要通过移除一个物理节点上的所有网络侦听来强制执行一个潜在的裂脑操作——假定没有通过光纤通道存储区域网络提供冗余备份。移除所有监听可能会孤立一个节点并且导致该节点不能够和其余集群节点通信。如果集群通过尝试在多个节点（原始节点以及其它正常运行的节点）上挂载和启动虚拟机响应的话，该集群节点就无法很好正常工作。这就意味着最终将会导致虚拟机数据遭到破坏。

　　为高可用性架构对比虚拟机管理程序

　　很多管理程序都包含侦测主要客体操作系统故障的能力，比如虚拟机内部的Windows停机错误或者Linux内核崩溃故障。在故障发生之后管理程序可以自动重新启动虚拟机。

　　可以使用其中一项功能构造一个使用键盘操作的内存清除文件解决Windows上的运行停机故障。针对Linux平台的另外一项功能是在SUSE Linux企业版服务器上设置Linux内核崩溃转储。

　　确定虚拟机宿主布局的准则可能包括以下几个方面：

• 可用的CPU、内存、网络I/O和存储I/O；
• 服务层面需求感知；
• 安全和复合型相关的布局限制；

　　对于服务层面需求意识，首先需要决定高可用性软件是否基于虚拟机的需求软件级别之上的虚拟机物理宿主选择。另外也应该检查故障之后虚拟机的布局方式，有一些虚拟机集群产品通过节点顺序布置虚拟机，而不会把虚拟机排除在可用物理节点之外。

　　例如，如果集群节点1出现故障，所有运行在节点1上面的虚拟机都将会试图在节点2上运行；在节点2上不能运行的虚拟机将会试图在节点3上运行；这个过程将会持续到所有虚拟机都可以正常运行。

　　虚拟化管理程序管理软件应该通过扩展在集群中所有剩余节点上重启虚拟机的方式，提供一些信息布局信息。当然，至少需要一个三节点的集群才可以测试宕机备份，以验证是否某特定的产品在多个剩余节点上的虚拟机重启部署工作。

　　共享存储方式对高可用性的影响

　　集群产品依赖于共享的存储技术，因此评估高可用性基础架构上共享存储管理的影响非常重要。

　　例如，要求每台虚拟机一个逻辑单元号（LUN：Logic Unit Number）的集群虚拟化管理程序产品可能就需要服务器管理员在部署一台新虚拟机时与存储管理员建立连接。这一步骤必不可少，因为在这个过程中需要提供一个LUN并且映射到集群合适的物理宿主机器上。

　　一些厂商，如Citrix系统，已经开始生产可以整合LUN供给到Hypervisor管理程序，但并不是支持所有的存储阵列。尽管这只是很小的一个技术点，但给每台虚拟机配置一个LUN的架构有可能会增加管理系统的开销。

　　共享的集群文件系统，如VMware的虚拟机文件系统（VMFS：Virtual Machine File System），允许虚拟机共享2TB以上的卷。这样做的好处是在虚拟化管理员部署新虚拟机时不需要提供新的LUN。

　　VMFS和存储阵列之间的整合程度差异很大，因此在购买存储设备之前需要认真评估其支持度。另外也会发现很多高级阵列属性都是不可用的。当然很多虚拟化管理程序都支持网络文件系统，另外一个方面会涉及到相对简单和熟悉的管理体系。

　　在为虚拟工作环境评估存储系统时，也有很多因素值得考虑。存储系统对高可用性架构非常关键，因此需要花一定的时间做全方位的考察。所选择的存储模型应该可以很方便、高效地管理，也应该能够和企业的虚拟化和存储架构很好地整合。

　　高可用性对于虚拟化的生产工作环境非常必要。把很多鸡蛋放在一个篮子里（孤注一掷）——或者直接说把很多虚拟机部署在一台物理主机上——意味着一个服务器故障就可以带来多个资源同时瞬间掉线。因此需要全面、彻底地评估管理程序集群特征。否则，如果在高可用软件发生一次故障之后就无法按照预期方式工作的话，会是一件非常令人沮丧的事情。