哪一种高可用性（HA）策略最适合你的虚拟机（VM）环境？

对于虚拟机（VM）容错，每一种高可用性（HA）策略都提供了行之有效方法。但是，要觉得使用哪种方法并不总是很明显。“选择一个虚拟机的高可用性策略”介绍了在给生产环境中的虚拟机（VM）选择和实施一种高可用方案时的参考要点。

这些准则可以帮助你，但是，你至少应该创建主机故障转移群集。

每个主机上运行着多个生产的虚拟机。如果该主机出现故障，同时又没有实施高可用性（HA）方案，那么此主机上的每个虚拟机（VM）都将发生故障。根据应用的不同重要程度来决定高可用性（HA）的方案。当你在一台单独的物理机上运行着一个应用负载。在这种情况下，就没有理由为什么不能在运行一个基于主机级别集群的时候，同时再实施一个基于客户系统的高可用性（HA）解决方案，例如故障转移群集或者网络负载平衡（NLB）群集。

使用可以满足企业现有服务需要的方案，这可以确定你需要为每台虚拟机（VM）配置哪种高可用性（HA）方案。同时，你还必须考虑运行在虚拟机（VM）中的应用程序的服务政策。

配置单点或者多点集群

物理服务器支持单点和多点集群技术。单点集群技术是基于各种形式的共同存储。拿VMware举例，主机集群采用两项关键技术：高可用性（HA）和虚拟机文件系统（VMFS），它是一个共享式的文件系统，可让多个主机服务器连接到同一存储容器。VMFS通常需要某种形式的SAN，网络附加存储（NAS）或iSCSI存储容器。 VMware还可以支持网络文件系统（NFS），这可以使小企业对主机服务器实施高可用性（HA）方案。VMware的HA组件可以管理潜在的主机服务器故障。VMware主机集群可以支持最多32个节点。

思杰Xen服务也可以依靠共享存储来为主机服务器提供高可用性（HA），存储通常为NFS、NAS、SAN或者iSCSI容器的形式。每台思杰主机服务器环境，管理员可以通过创建主机资源池的方式来配置高可用性。虽然其他虚拟化技术依靠管理数据库来控制多台主机配置信息，但是每一台思杰Xen的服务器主机存储着它自己资源池配置数据信息的副本。这消除了资源池配置的一个潜在的单点故障。思杰资源池也可以包含多达32个主机节点。

微软的Hyper-V依赖于Windows Server 2008的故障转移群集技术来创建主机集群。单个Hyper-V主机集群需要共享存储，存储只支持SAN或iSCSI容器，其他存储形式不被支持。 Hyper-V的单点集群可以支持最多16个主机节点。

Hyper-V的也可以支持多点集群，它跨越多个点来支持可能影响整个集群的故障。正因为如此，在Hyper-V的多点集群中不再需要共享存储，而是依靠速度更快的直连方式存储（DAS）。

然而，为了提供高虚拟机（VM）的高可用性， DAS存储库必须使用第三方同步工具来实时同步。

无论你使用哪种虚拟化技术，最好的方式是让创建的主机集群尽可能为服务的连续性提供两个不同程度的保护：

主机集群为虚拟机（VM）提供持续的运作。如果一个主机发生故障，或者表明它已经不可用，那么此台主机上所有运行的虚拟机（VM）将自动转移到群集的另一个节点上。

在主机例行维护时间，主机集群为虚拟机（VM）提供持续的运作。举个例子，如果你需要在群集中的一个节点上安装系统更新，那么你可以在操作过程中将虚拟机迁移至其他节点，等操作完毕后再将虚拟机迁移回来。

如果群集中的其他节点也需要维护，最好的方式是让创建的主机集群尽可能为服务的连续性提供两个不同程度的保护。

在这两种情况下，在虚拟机迁移过程中服务将被中断。当检测到群集中的一个节点出现故障，群集服务会促使虚拟机从故障节点转移到另一个节点。在这种情况下，它会使用一个迁移过程，将虚拟机从一个节点移动到另一个。依据你使用的虚拟化技术的不同，这可能会引起服务的中断。以热迁移为例，VMware和Citrix的产品，支持迁移正在运行着的虚拟机（VM）。Hyper-V的第一个版本不能执行热迁移。然而，今年下半年的晚些时候发布的Hyper-VR2版，将支持此功能。

当一个节点出现故障，群集服务会通过在另外一个节点重启此虚拟机（VM）来达到迁移的目的。在这种情况下，虚拟机（VM）的停机时间在增加，因为故障节点上的所有虚拟机都会被关闭。当你需要对一个节点执行维护时，使用迁移工具将虚拟机（VM）从一个主机节点迁移到另一个节点。请记住，你必须在群集中的每台主机服务器上留有备用资源，以便支持迁移操作。理想情况下，每台主机服务器将拥有足够的备用资源，以支持群集中至少一个其他节点故障。

配置客户机故障转移群集

当虚拟机（VM）作为一个应用加入到主机集群中后，虚拟机的高可用性就已被配置。但是，虚拟机不像传统的应用程序。即便虚拟机将会始终在运行——或者尽可能在运行——在集群中的一台主机上，这个模型并不适用于你的生产网中的每一个应用负载。这是因为集群主机服务器不会对虚拟机中的应用起作用。

子机故障切换集群工作环境

所有的虚拟机都可以作为主机集群系统内的一个应用来对待，从而实现高可用。然而，虚拟机和传统的应用程序毕竟存在差别。虽然对于虚拟机来讲，我们也需要保持它始终处于运行状态（或者是在尽可能多的时间段内保持运行），但主机集群的这种操作方式并不是通用于生产环境中的所有工作负载的。原因在于对主机所做的集群不会直接作用于运行于在虚拟机中的应用程序。因此这些应用程序并不能感受到主机所具有的高可用性，而在这一点上，子机故障切换集群中就完全不同，这种模式中应用程序被直接作为集群中的一部分而安装。在主机集群模式中，并不能保证当主机故障后，虚拟机仍然可以保持运行。尽管事实上多数应用程序不能感知，故障发生后从一个主机节点到另一个主机节点的切换过程，但是这种主机高可用模式还是可以满足大多数应用程序的需求。

很多状态敏感型（state-sensitive）应用程序，如Microsoft Exchange，并不能很好地工作于主机集群模式下。在发生切换时，甚至可能会导致数据的丢失。

交易型应用程序，尤其是那些支持超高速交易模式的应用，也无法和主机集群模式良好地结合，因为从设计上讲，这些应用已经定义了在故障切换时的特殊处理方法。因此，当虚拟机需要做故障切换时，这些应用不能按照集群系统所规划的方式去正常工作。