Windows Server故障转移群集为Hyper-V基础架构提供了一个至关重要的技术，不仅可提供可用性，而且可提供可移植性。虚拟化和私有云环境的一个重要概念在于破除负载与底层物理资源之间的捆绑关系，而故障转移群集通过使用实时迁移技术在不同物理宿主机之间不停机移动和放置虚拟机，真正实现了这一点。这里将提供一些有关放置的最佳实践，帮企业对群集上使用的不同Hyper-V场景进行优化。

　　默认故障转移策略

　　如果有节点遇到故障，虚拟机将被分散到其他群集节点上。在老版本 Windows Server 中， 任何资源都可分散到承载虚拟机数量最少的群集节点中。在Windows Server 2012中，这种逻辑进行了改进，可根据宿主机的内存数量这一最常见的约束性资源，决定虚拟机的分散方式。每个虚拟机都可放置到空闲内存资源最多的节点中，并且会针对每个虚拟机的资源需求进行评估，例如检查虚拟机是否支持NUMA。

　　如果承载多个虚拟机的群集节点崩溃，群集服务将寻找优先级最高的虚拟机，然后检查其他 所有节点，确定拥有空闲内存最多的节点。随后会在这个节点上启动该虚拟机。这个过程可 针对所有虚拟机重复进行，从优先级最高的虚拟机开始按照优先级高低执行，直到所有虚拟 机都重新放置。

　　虚拟机优先级

　　在Windows Server 2012中，群集中运行的每个虚拟机都可分配优先级：高、中，或低。这样即可确保在群集运行中，高优先级的虚拟机可得到最妥善的放置。同时通过使用这种方式可确保组织最重要的服务或最关键的基础架构角色可比其他不那么重要的负载更快速的上 线。

　　如果承载多个虚拟机的群集节点崩溃，那么首先将启动高优先级虚拟机，随后是中等优先级 虚拟机，最后才是低优先级的。相同的逻辑还将应用于其他群集的运营，例如并发实时迁移 或节点维护模式，这种情况下优先级高的虚拟机总是可首先移动。

　　首选的所有者

　　从老版本Windows Server开始，就可针对每个虚拟机配置故障转移节点顺序首选项。如果 环境要求某些重要的虚拟机必须留在某些节点上，这一特性就显得非常有用。例如，通常虚 拟机都需要尽量留在主要数据中心(首选所有者)内运行，只有在主要站点不可用时，虚拟 机才在备份数据中心内运行，实现灾难恢复。

　　如果承载了多个虚拟机的群集节点崩溃，高优先级虚拟机会尝试移动到首选所有者列表中的 第一个节点。如果该节点不可用，那么虚拟机会继续尝试移动到首选所有者列表中的下一个 节点。如果所有首选所有者都不可用，那么就会移动到可能的所有者列表中的第一个节点。

　　可能的所有者

　　在老版本Windows中，每个虚拟机还有可能的所有者设置。该设置使得虚拟机可在不存在可用首选所有者的情况下也能移动到其他群集节点并启动。某些环境要求就算没有可用的首 选所有者，也要在其他宿主机上运行虚拟机，此时这个功能就变得非常有用。在多站点群集 中，位于备份站点的宿主机可分配为可能的所有者，但不能作为首选所有者。在这样的场景 中，只有主站点没有可用的节点(首选所有者)的情况下，虚拟机才会故障转移到辅助站点。

　　如果承载了多个虚拟机的群集节点崩溃，高优先级虚拟机会尝试移动到首选所有者列表中的 第一个节点。如果所有首选所有者都不可用，那么就会移动到可能的所有者列表中的第一个 节点。如果可能的所有者列表中的第一个节点不可用，则会移动到列表中的下一个节点。如 果首选所有者和可能的所有者列表中都没有可用节点，虚拟机将会移动到任何其他节点，但 保持离线状态。取决于故障回复策略，只要相应节点变得可用，虚拟机还可重新回到首选所 有者或可能的所有者，然后尝试启动。

　　故障恢复

　　在Windows Server 2012中，每个虚拟机还有一个选项非常重要，可将虚拟机重新移动到首选所有者或可能的所有者，并从最首选的所有者尝试启动。如果希望确保将某些虚拟机保留到相同宿主机上，并且在从崩溃中恢复后重新将这些虚拟机移动到这些宿主机中，该功能就非常有用。

　　如果群集节点从崩溃中恢复，并重新加入群集关系，那么任何没有在首选所有者上运行的虚 拟机都将可获得通知，该节点已经可用于进行放置。该过程首先从可能的所有者上运行的优 先级最高的虚拟机(或者位于其他节点上的离线虚拟机)开始，每个虚拟机都将判断该节点 是否是最佳宿主机，随后在自己的首选所有者上执行实时迁移(或启动操作)。

　　保持模式

　　在高度虚拟化的环境中还会遇到一个问题：“引导风暴”，如果同时启动大量虚拟机就容易遇 到这种问题。虚拟机的启动要比标准的正常运行状态需要更多宿主机资源，因此启动大量虚 拟机有时候可能会使得宿主机过载，影响宿主机的性能，甚至导致宿主机崩溃(如果某些宿 主机没有设置资源保留就可能出现在这种情况)。作为一项安全措施，在故障转移或节点重启动过程中，并发启动的虚拟机数量会受到限制(高优先级的首先启动)，其他虚拟机会在队列中等待启动。就算这些虚拟机是在同时启动，依然会分阶段错峰进行，以确保不会对宿主机造成太大压力。此外还可通过配置一些选项避免遇到“引导风暴”。

　　如果节点在这个时间段内没有加入群集，虚拟机会被放置到最首选的所有者上，这样既可确保虚拟机依然可上线，同时使得新宿主机有机会首先启动自己的虚拟机。

　　自动启动

　　有些时候，如果群集故障转移或崩溃，我们可能会希望某些不重要的虚拟机先不要启动，这 样其他虚拟机就有更多机会进行故障转移，并尽可能快速地上线。老版本Windows Server就具备自动启动属性，如果该属性被禁用，虚拟机在放置到节点上之后将不能自动启动。在高度虚拟化的环境中，这一特性会显得非常有用，因为必须确保宿主机和关键的基础架构虚拟机能够正常运行，不用担心这些群集中承载的并不需要持续可用的虚拟机所造成的资源 约束或“引导风暴”。这些虚拟机可稍后由管理员或自动化脚本启动。

　　Windows Server 2012之前就已存在最终放置策略，但主要考虑的是其他虚拟机，而非宿主机。群集属性AntiAffinityClassName(AACN)使得您可对虚拟机添加自定义的标签，这样不同虚拟机就可共享或使用不同的AACN。共享同一个AACN的虚拟机可自动将其分散到不同的宿主机。这样有助于在同一套基础架构角色中跨越群集中的不同节点对租户或虚 拟机进行隔离。例如，让所有虚拟化的DNS服务器或来宾群集节点位于同一台宿主机上， 一旦该节点崩溃就会造成单点故障，因此将这些虚拟机分散在不同的宿主机上，有助于为服务提供持续可用性。

　　结论

　　通过使用这些策略，就可对Windows Server 2012故障转移群集中的虚拟机放置进行优化。 永远要记得为虚拟机配置优先级，这样高优先级虚拟机就可优先放置，此外还要考虑如果任何节点变为不可用，虚拟机将用怎样的方式进行放置。