Windows Server 故障转移群集为 Hyper-V 基础架构提供了一个至关重要的技术，不仅可以提供可用性，而且可以提供可移植性。虚拟化和私有云环境的一个重要概念在于破除负载与底层物理资源之间的捆绑关系，而故障转移群集通过使用实时迁移技术在不同物理宿主机之间不停机移动和放置虚拟机，真正实现了这一点。这里将提供一些有关放置的最佳实践，帮您对群集上使用的不同 Hyper-V 场景进行优化。
默认故障转移策略
如果有节点遇到故障，虚拟机将被分散到其他群集节点上。在老版本 Windows Server 中，任何资源都可以分散到承载虚拟机数量最少的群集节点中。在 Windows Server 2012 中，这种逻辑进行了改进，可以根据宿主机的内存数量这一最常见的约束性资源，决定虚拟机的分散方式。每个虚拟机都可以放置到空闲内存资源最多的节点中，并且会针对每个虚拟机的资源需求进行评估，例如检查虚拟机是否支持 NUMA。
如果承载多个虚拟机的群集节点崩溃，群集服务将寻找优先级最高的虚拟机，然后检查其他所有节点，确定拥有空闲内存最多的节点。随后会在这个节点上启动该虚拟机。这个过程可以针对所有虚拟机重复进行，从优先级最高的虚拟机开始按照优先级高低执行，直到所有虚拟机都重新放置。
虚拟机优先级
在 Windows Server 2012 中，群集中运行的每个虚拟机都可以分配优先级：高、中，或低。这样即可确保在群集运行中，高优先级的虚拟机可以得到最妥善的放置。同时通过使用这种方式可以确保组织最重要的服务或最关键的基础架构角色可比其他不那么重要的负载更快速的上线。
如果承载多个虚拟机的群集节点崩溃，那么首先将启动高优先级虚拟机，随后是中等优先级虚拟机，最后才是低优先级的。相同的逻辑还将应用于其他群集的运营，例如并发实时迁移或节点维护模式，这种情况下优先级高的虚拟机总是可以首先移动。
首选的所有者
从老版本 Windows Server 开始，就可以针对每个虚拟机配置故障转移节点顺序首选项。如果环境要求某些重要的虚拟机必须留在某些节点上，这一特性就显得非常有用。例如，通常虚拟机都 需要尽量留在主要数据中心(首选所有者)内运行，只有在主要站点不可用时，虚拟机才在备份数据中心内运行，实现灾难恢复。
如果承载了多个虚拟机的群集节点崩溃，高优先级虚拟机会尝试移动到首选所有者列表中的第一个节点。如果该节点不可用，那么虚拟机会继续尝试移动到首选所有者列表中的下一个节点。如果所有首选所有者都不可用，那么就会移动到可能的所有者列表中的第一个节点。
可能的所有者
在老版本 Windows 中，每个虚拟机还有可能的所有者设置。该设置使得虚拟机可以在不存在可用首选所有者的情况下也能移动到其他群集节点并启动。某些环境要求就算没有可用的首 选所有者，也要在其他宿主机上运行虚拟机，此时这个功能就变得非常有用。在多站点群集中，位于备份站点的宿主机可以分配为可能的所有者，但不能作为首选所 有者。在这样的场景中，只有主站点没有可用的节点(首选所有者)的情况下，虚拟机才会故障转移到辅助站点。
如果承载了多个虚拟机的群集节点崩溃，高优先级虚拟机会尝试移动到首选所有者列表中的第一个节点。如果所有首选所有者都不可用，那么就会移动到可能 的所有者列表中的第一个节点。如果可能的所有者列表中的第一个节点不可用，则会移动到列表中的下一个节点。如果首选所有者和可能的所有者列表中都没有可用 节点，虚拟机将会移动到任何其他节点，但保持离线状态。取决于故障回复策略，只要相应节点变得可用，虚拟机还可以重新回到首选所有者或可能的所有者，然后 尝试启动。
故障恢复
在 Windows Server 2012 中，每个虚拟机还有一个选项非常重要，可以将虚拟机重新移动到首选所有者或可能的所有者，并从最首选的所有者尝试启动。如果希望确保将某些虚拟机保留到相同宿主机上，并且在从崩溃中恢复后重新将这些虚拟机移动到这些宿主机中，该功能就非常有用。
如果群集节点从崩溃中恢复，并重新加入群集关系，那么任何没有在首选所有者上运行的虚拟机都将可以获得通知，该节点已经可用于进行放置。该过程首先 从可能的所有者上运行的优先级最高的虚拟机(或者位于其他节点上的离线虚拟机)开始，每个虚拟机都将判断该节点是否是最佳宿主机，随后在自己的首选所有者 上执行实时迁移(或启动操作)。
保持模式
在高度虚拟化的环境中还会遇到一个问题：“引导风暴”，如果同时启动大量虚拟机就容易遇到这种问题。虚拟机的启动要比标准的正常运行状态需要更多宿 主机资源，因此启动大量虚拟机有时候可能会使得宿主机过载，影响宿主机的性能，甚至导致宿主机崩溃(如果某些宿主机没有设置资源保留就可能出现在这种情 况)。作为一项安全措施，在故障转移或节点重启动过程中，并发启动的虚拟机数量会受到限制(高优先级的首先启动)，其他虚拟机会在队列中等待启动。就算这 些虚拟机是在同时启动，依然会分阶段错峰进行，以确保不会对宿主机造成太大压力。此外还可以通过配置一些选项避免遇到“引导风暴”。
保持模式最早出现在 Windows Server 2008 R2 中，可以让虚拟机保留在最后一次刻意放置(可能是由系统管理员决定的，或者 System Center Virtual Machine Manager 的放置策略决定的)后所分配的宿主机上。如果整个群集崩溃，每个虚拟机都会等待之前自己所在节点上线，然后开始启动。当然这个过程也是高优先级虚拟机首先 开始。这样既可防止整个群集的所有虚拟机试图在上线的第一个节点上启动，有助于避免“引导风暴”。群集服务将等待一个默认设置的时间段，等待原始节点重新 加入群集。如果节点在这个时间段内没有加入群集，虚拟机会被放置到最首选的所有者上，这样既可确保虚拟机依然可以上线，同时使得新宿主机有机会首先启动自 己的虚拟机。
自动启动
有些时候，如果群集故障转移或崩溃，我们可能会希望某些不重要的虚拟机先不要启动，这样其他虚拟机就有更多机会进行故障转移，并尽可能快速地上线。老版本 Windows Server就具备自动启动属性，如果该属性被禁用，虚拟机在放置到节点上之后将不能自动启动。
在高度虚拟化的环境中，这一特性会显得非常有用，因为必须确保宿主机和关键的基础架构虚拟机能够正常运行，不用担心这些群集中承载的并不需要持续可用的虚拟机所造成的资源约束或“引导风暴”。这些虚拟机可以稍后由管理员或自动化脚本启动。
Anti-Affinity
Windows Server 2012 之前就已存在最终放置策略，但主要考虑的是其他虚拟机，而非宿主机。群集属性 AntiAffinityClassName(AACN)使得您可以对虚拟机添加自定义的标签，这样不同虚拟机就可以共享或使用不同的 AACN。共享同一个 AACN 的虚拟机可以自动将其分散到不同的宿主机。这样有助于在同一套基础架构角色中跨越群集中的不同节点对租户或虚拟机进行隔离。例如，让所有虚拟化的 DNS 服务器或来宾群集节点位于同一台宿主机上，一旦该节点崩溃就会造成单点故障，因此将这些虚拟机分散在不同的宿主机上，有助于为服务提供持续可用性。
假设有一个包含四个节点和四个虚拟机的群集，每个虚拟机的 AntiAffinityClass-Name 都设置为“蓝色”，那么默认情况下，每个节点都可以承载“蓝色”虚拟机。如果使用相同 AACN的“蓝色”虚拟机的数量超过群集中的节点总数，那么每个节点上就可能有超过一个“蓝色”虚拟机，但这些虚拟机依然会尽可能保持更广泛的平均分散。
结论
通过使用这些策略，就可以对 Windows Server 2012 故障转移群集中的虚拟机放置进行优化。永远要记得为虚拟机配置优先级，这样高优先级虚拟机就可以优先放置，此外还要考虑如果任何节点变为不可用，虚拟机将用怎样的方式进行放置。
