虚拟化提供了很多优势，但是服务器整合同样面临着新的挑战。集群内的故障转移功能有助于在主机发生故障时快速恢复虚拟机。但设计故障转移集群以确保所有的虚拟机都受到保护，需要考虑很多方面。

故障转移集群的一大通用原则以及虚拟化的基础优势之一就是通过确保运行在集群中的主机上的虚拟机持续运转来提升资源利用率。在该策略下，每台主机预留了一部分内存和计算资源，这样如果集群中的某台主机发生故障，其他主机还能够承载更多的虚拟机。在常规的操作下，这一策略通过分布部署计算资源实现了资源的最大化使用，避免了服务器处于空闲状态。同时在主机发生故障时将受影响的虚拟机数量降至了最低，因为每台主机都运行了较少的虚拟机。

当集群中的主机发生故障时，将在其他有可用资源的主机上重新启动虚拟机。当然，处于运行状态的主机必须要有足够多的计算资源来运行所有的虚拟机，尤其是资源消耗最多的虚拟机，通常也是最为重要的虚拟机。

计算资源规划

每台服务器预留的计算资源比例和集群中的主机数直接相关。通常小规模集群将会预留大约一台服务器的计算资源。规模更大的集群将会预留两到三台服务器的计算资源。例如，四节点集群的每台主机可能会预留25%的可用资源，在发生故障时将用于重启虚拟机。能够允许2台主机发生故障的12个节点的集群，每台主机将会预留17%的计算资源。

然而，这一策略在遇到消耗大量资源的虚拟机时会存在问题。既然该模型是在多个主机之间分配可用的计算资源，那么一台服务器可能没有足够的可用资源来启动一个需要消耗大量资源的虚拟机。在12个节点的集群中，如果虚拟机需要消耗的资源超过了17%，那么该虚拟机将无法在集群中的任意一台主机上重启。

在十年以前，虚拟化开始流行，每台虚拟机只需要使用几GB的内存和一颗CPU。当时物理服务器通常有4颗处理器以及十几GB的内存。启动虚拟机所需要的资源是很小的。在其他主机上发现可用的资源来启动虚拟机是件很容易的事儿。集群的规模通常很小而且负载很低，因此有大量的可用资源。很多组织仍旧有很多小虚拟机作为认证或者文件以及打印服务器，但是这些虚拟机对资源的需求在逐渐增大。

消耗资源多的虚拟机可能会带来大问题

既然虚拟化已经得到了广泛的部署与应用而且集群的规模在逐渐增大。既然我们认为hypervisor能够管理好资源，那么集群的负载通常会变得很大。目前很多公司正在虚拟化大型及重要的工作负载，比如数据库、ERP服务器以及Exchange服务器。运行这些大规模工作负载的虚拟机需要大量的CPU和内存。

如果集群包括六台物理主机，每台主机包含128GB的内存，那么每台主机将会预留六分之一的内存资源用于故障转移（大约是21GB/主机）。通常集群中需要32GB内存的单台虚拟机无法重新启动。在上述示例中保护需要32GB内存虚拟机的一种方式就是将每台主机的内存增加到192GB。

规避上述问题的另一种方式就是使用standby主机而非分布式容量模型。在常规操作下standby主机是空闲的，当其他主机发生故障它能够接管所有虚拟机。这违背了资源最大化使用原则因为standby主机处于空闲状态而且在大多数情况下都没有使用到。然而这确保了你甚至能够重启集群中占用资源最多的虚拟机。

规划故障转移集群容量的一个通用原则就是考虑资源需求最多的虚拟机。例如，这些虚拟机更适合具有高配置物理主机的小规模集群——这确保了资源需求最多的虚拟机不会超出任何主机上的可用计算资源。小规模虚拟机在任何集群下都很够很好地工作。如果你只有小型虚拟机，那么可以通过使用大规模集群并在每台主机上预留较少的资源来实现资源的最大化使用。通常情况下，设计的集群能够支持大型虚拟机以及小型虚拟机很可能会逐步被认可。