摘要：当前的虚拟化工具可以很容易的配合传统的HA方法。在企业需要零宕机时间的要求中，虚拟服务器可以使用基于虚拟化的容错虚拟机工具（如Marathon技术公司的everRunVM），该工具运行在服务器集群中每一成员服务器的虚拟化管理程序（如CitrixXenServer）之上。

　　高可用集群工具
　　
　　当前的虚拟化工具可以很容易的配合传统的HA方法。在企业需要零宕机时间的要求中，虚拟服务器可以使用基于虚拟化的容错虚拟机工具（如Marathon技术公司的everRunVM），该工具运行在服务器集群中每一成员服务器的虚拟化管理程序（如CitrixXenServer）之上。HA软件配置用来处理选择的虚拟机，这些虚拟机在高可用集群中可以很快地被复制到其它服务器上并且可以实时同步。在由于崩溃或者服务器故障时虚拟机停止响应的情况下，虚拟机复制操作可以在另外一台服务器上继续进行。在原来的服务器恢复之后，应用程序控制重新指向原虚拟机。
　　
　　例如，假设一台负载SQL服务器的虚拟机和一台负载企业资源规划（ERP：EnterpriseResourcePlanning）应用程序的虚拟机同时运行在服务器A上；在服务器B上运行三台虚拟机，其中一台承载Exchange服务器，另外一台作为域名服务器，在第三台上运行客户关系管理应用程序。
　　
　　一般来说，这些服务器不能用来容错，因为每一台虚拟机都没有复制。但是IT管理员可以使用诸如everRunVM这样的工具在服务器A和服务器B之间复制SQL虚拟机。另外也可以在集群中新增第三台冗余服务器，只用来宿主从服务器A上复制的SQL备份，以及从服务器B上复制的Exchanges虚拟机备份等。
　　
　　但是实际上虚拟化技术并没有使HA比使用传统的方法更高效。在虚拟机宕机备份中，使用诸如everRunVM这样的工具可以保证宕机时间是可以忽略不计的。但是可供虚拟化技术使用的软件工具的灵活性和功能不仅仅是对第二级应用程序的有效数据保护，这些应用程序如果在传统的工作环境中可能只是使用常规的磁带存储方法。
　　
　　数据中心管理器并不需要复制每一台虚拟机，因为这是服务器虚拟化的主要优势之一。没有即时复制的虚拟机仍然可以通过持续快照，也可以使用一些工具（如VMware高可用性）从SAN移植到其它可用的服务器上而快速启动。
　　
　　回顾上一个例子，只有服务器A上面的SQL应用程序为冗余备份复制到服务器B上。服务器A上的ERP应用程序并没有复制。通常来讲，这就意味着需要定期备份或者快照保护ERP虚拟机。相关的长恢复点对象（RPO：RecoveryPointObjective，每两次备份之间的时间更长）在断电情况下将会给更多的数据带来风险。
　　
　　中心化SAN上的ERP和其它虚拟机就有可能从服务器上维持每一台虚拟机的持续快照，把RPO（以及潜在的数据损失）减小到几乎为零。如果服务器A出现故障，ERP虚拟机可以从SAN恢复到另外一台有足够可用计算能力支持虚拟机的服务器上。大概只会引起几分钟的ERP应用程序不可访问，这对于一个企业来讲是完全可以接受的。因此在提升其它应用程序的可恢复性时，虚拟化可以继续支持高可用性。
　　
　　高可用性下的虚拟服务器维护
　　
　　虚拟化技术也可以支持常规维护这样的任务。在传统的高可用性集群中，常规维护通常就是指使集群中的一台服务器脱机服务，而让其它服务器处于高风险状态，直到另外一台服务器启动并且重新同步。如果应用程序没有得到HA的保护，该服务器就会持续保持脱机状态一直到该服务器正常运行。
　　
　　在虚拟化的工作环境中，底层硬件维护时可以使用工具，如WindowsServer2008R2的部分组件MicrosoftHyper-V动态迁移，或者VMwareVMotion和分布的资源调度器（DRS：DistributedResourceSchedule），把虚拟机导向其它可用的服务器上以维持应用程序的可用性。在从传统部署向虚拟化服务器部署转换的这个过程中，数据中心管理器最大的挑战就是为每一个应用程序实施最恰当的保护级别。
　　
　　以公司内部使用的FTP服务器虚拟机为例：通常情况下使用everRunVM这样的工具复制虚拟机并不合适，因为这样做会因为非关键目标耗费大量的计算资源。考虑花几分钟时间在另外一台服务器上启动该虚拟机将会是更明智的选择。

    责任编辑：handsome