Windows Server 2012 R2 群集故障转移介绍

故障转移群集是一组相互独立的计算机，通过协同工作改善群集角色（以前也叫做群集的应用程序与服务）的可用性与扩展性。群集的服务器（叫做节点）通过物理线缆及软件连接在一起。如果一个或多个群集结点故障，其他节点可继续提供服务（这一过程叫做故障转移）。此外群集角色可通过主动监控以验证节点是否正常工作。如果没能正常工作，则会重启动或转移到其他节点。故障转移群集还提供了群集共享卷（CSV）功能，能为群集角色提供一致的分布式名称空间，供群集节点访问所有节点的共享存储。通过使用故障转移群集功能，用户感受到的服务中断可以降到最低。故障转移群集有多种典型实用场景：

1) 为应用程序，例如 Microsoft SQL Server 及 Hyper-V 虚拟机提供高可用或持续可用的文件共享存储。

2) 运行在物理服务器或 Hyper-V 服务器中所运行虚拟机内的高可用群集角色，例如群集DHCP服务器。

Windows Server 2012 R2故障转移群集特点：

1. 创建最多包含64个节点的群集，对管理员的环境进行扩展，而老版本只能包含16个节点。

2. 通过对基础架构进行扩展，每个群集最多可运行8,000个虚拟机，每个节点最多可运行1,024个虚拟机。

3. 具有控制虚拟机群集管理和其他群集角色的功能。

4. 相比Windows Server 2008 R2，增加了对于扩展文件服务器的支持。

5. 支持群集感知更新 (CAU)，群集感知更新 (CAU)是一个自动化的功能，允许更新自动应用于群集服务器中的主机操作系统，并且更新过程中的可用性损失极小或为零

6. 在运行 Windows Server 2012 R2的群集中，管理员可以配置对同时运行Windows Server 2012 R2的群集虚拟机上的服务进行监视。

从虚拟化的角度来看，故障转移群集提供了具备高可用性的虚拟机。如果物理宿主机故障，运行在该宿主机中的虚拟机也会中断。这会造成破坏性关闭，并导致虚拟机停机。然而由于物理节点是群集的一部分，因此剩余群集节点可通过协调将停机的虚拟机重新恢复，通过群集中的其他节点再次将其快速启动。这一过程是自动化的，无需 IT 管理员干预，因此可确保群集中运行的负载比独立物理服务器中运行的负载具备更高级别的可用性。

在 Windows Server 2008 R2 及老版本中，在群集中运行虚拟机要求虚拟机必须使用共享的存储。这个场景中的共享存储意味着 iSCSI 或光纤通道连接的 SAN。在 Windows Server 2012 及后续的 Windows Server 2012 R2 中，故障转移群集可支持将虚拟机放置在文件共享中，使用 SMB 3.0 协议通过网络访问。这样管理员在部署基础结构时可获得更大程度的灵活性，并能简化部署与管理体验。

对于依然希望利用 SAN 存储作为共享存储解决方案的客户，强烈建议将 SAN 的 LUN 直接呈现给群集的每个节点，并将这些 LUN 作为群集共享卷使用。

一、 群集共享卷：

Windows Server 2012 R2 故障转移群集的群集共享卷（CSV）功能使得群集的多个节点可以同时读写访问同一个 LUN（磁盘）中供应的 NTFS 卷。通过使用 CSV，群集角色可从一个节点快速故障转移至其他节点，同时无需更改驱动器的所有权，也无需断开并重新加载卷。CSV 还有助于简化故障转移群集中大量 LUN 的管理工作。对于群集中的每个节点，CSV 都呈现为一致的文件命名空间，例如 C:\ClusterStorage\Volume1。CSV 以 NTFS 为基础提供了针对一般用途的群集文件系统，并且并非只能用于指定的群集负载。（在 Windows Server 2008 R2 中，CSV 只支持 Hyper-V 负载）。CSV 的应用包括：

1) 群集的虚拟磁盘（VHD）文件，将其用于群集的 Hyper-V 虚拟机。

2) 用横向扩展文件共享存储应用程序数据，供横向扩展文件服务器角色使用。这类应用程序数的例子包括 Hyper-V 虚拟机文件及 Microsoft SQL Server 数据。

1. 优化的 CSV 放置策略：

在故障转移群集中，有一个节点被看做该 CSV 的所有者或“协调节点”。协调节点拥有关联了逻辑单元号（LUN）的物理磁盘资源。所有针对文件系统的 I/O 操作都需要通过协调节点进行。分布式的 CSV 所有权可改善磁盘性能，因为有助于对磁盘 I/O 进行负载平衡。

因为 CSV 所有权可以跨越所有群集节点进行平衡，节点所拥有的 CSV 数量将不再不对称，因此如果一个节点故障，CSV 所有权的过渡将变得更高效。对于使用存储空间的横向扩展文件服务器群集，该功能非常重要，因为可确保存储空间所有权的分散。

此外在 Windows Server 2012 R2 中，针对某些情况，例如 CSV 故障转移、节点重新加入群集、为群集添加新节点、重启动群集节点，或在关闭后重新启动故障转移群集，所有权可自动重新进行平衡。

2. 增强 CSV 的适应性：Windows Server 2012 R2 包含下列有关 CSV 适应性的改进：

1) 每个故障转移群集节点多个服务器服务实例。默认实例负责处理来自服务器消息块（SMB）客户端的传入通讯并访问文件共享，辅助 CSV 实例处理节点间的 CSV 通讯。这种节点间通讯包括元数据访问及 I/O 通讯重定向。

2) 服务器服务的 CSV 健康度监控。

CSV 使用 SMB 作为群集节点间 I/O 转发的传输方式，并用于实现元数据更新。如果服务器服务变得不够健康，就会影响 I/O 性能以及访问存储的能力。因为现在群集节点可以包含多个服务器服务实例，因此如果默认实例遇到问题，CSV 将获得更大程度的适应性。此外这一变化也改善了 CSV 节点间 SMB 通讯的扩展性。

如果服务器服务变得不够健康，可能会影响到 CSV 协调节点接受其他节点 I/O 请求的能力，以及执行元数据更新的操作。在 Windows Server 2012 R2 中，如果一个节点的服务器服务变得不够健康，CSV 所有权会自动转移到其他节点，以保障适应性。

在 Windows Server 2012 中，每个节点的服务器服务只有一个实例，同时服务器服务也不受监控。

二、 Active Directory 分离的群集

在 Windows Server 2012 R2 中，可在不依赖 Active Directory 域服务（AD DS）作为网络名的情况下部署故障转移群集。这种群集也叫 Active Directory 分离的群集。在使用这种方式部署群集时，群集网络名称（也叫做管理访问点）及客户端访问点所用的任何群集节点的网络名称都需要在域名系统（DNS）中注册。不过在 AD DS 中无需为这样的群集创建计算机对象，包括群集本身的计算机对象（也叫做群集名称对象，即 CNO），及在 AD DS 中为任何客户端访问点访问群集角色时创建的对象（也叫做虚拟计算机对象，即 VCO）。（群集节点依然需要加入 Active Directory 域。）

通过这种部署方式，即可在原本不具备创建计算机对象所需权限的 AD DS，或无需求助 Active Directory 管理员在 AD DS中更新计算机对象的情况下直接创建故障转移群集。此外也无需为这样的群集管理并维护群集计算机对象。例如，可以避免遇到 Active Directory 管理员无意中删除群集计算机对象造成的问题，这种问题会对群集负载的可用性产生极大影响。

用于创建 Active Directory 分离群集的选项并未包含在 Windows Server 2012 中。在 Windows Server 2012 中，只能在 DNS 及 AD DS 中都存在群集网络名的情况下部署故障转移群集。

Active Directory 分离的群集使用 Kerberos 对群集内通讯进行身份验证。然而如果需要针对群集网络名进行身份验证，此时群集将使用 NTLM 协议。

Windows Server 2012 与 Windows Server 2012 R2 群集还能不依赖 AD DS 启动，因此对于在群集中运行虚拟化域控制器的数据中心，可提供更高程度的灵活性。

三、 群集仲裁及动态见证

群集的仲裁是由投票元素的数量决定的，该机制确保了群集能够正常启动并持续运行。一般来说，群集中的每个节点都有一个仲裁投票，此外仲裁见证（在配置后）可以有额外的一张仲裁投票。在 Windows Server 2012 中，可以为每个群集配置一个仲裁见证。仲裁见证可以是指定的磁盘资源或文件共享资源。每个元素可通过投出自己的一“票”确定群集是否可运行。群集能否正常工作的仲裁结果是由活跃群集关系中大多数投票元素决定的。

为改善群集以及群集中所托管角色的可用性，群集仲裁配置的设置一定要慎重。

群集仲裁配置将直接影响整个群集的高可用性，原因在于：

1) 有助于确保在活跃成员关系产生变化后，故障转移群集依然能正常启动并持续运行。成员关系的变化可能是由于节点计划内或计划外关机，或节点与群集存储之间连接的中断导致的。

2) 当节点的子集无法与节点的其他子集（分裂式群集）通讯时，群集仲裁配置有助于确保群集中只有一个子集可以持续运行。缺乏足够仲裁投票的子集将停止作为群集继续运行。具备大多数仲裁投票的子集可继续承担群集角色。这样即可避免群集产生分区，并确保同一个应用程序不会同时由多个分区承载。

群集环境下，使用群集完整功能的运行还取决于下列因素：

1）群集结点间的网络连接。

2）承载群集资源的每个节点所放置的容量。

3）群集角色的优先级设置。

1. 见证配置：

作为一项常规规则，在配置仲裁时，群集中的投票元素必须是奇数。因此如果群集包含偶数个投票节点，就必须配置磁盘见证或文件共享见证。群集可承受额外一个节点的故障。此外添加见证投票使得群集能够在半数节点同时故障或断开的情况下继续正常工作。

如果所有节点都能访问磁盘，则通常建议使用磁盘见证；如果需要通过复制存储实现多站点灾难恢复，则建议使用文件共享见证。只有存储供应商支持从所有站点读写访问复制存储时，才可以对包含复制存储的环境配置磁盘见证。

2. 节点投票的分配“

在 Windows Server 2012 中，作为一种高级仲裁配置选项，管理员可以选择针对每个节点分配或取消仲裁投票。默认情况下，所有节点都可投票，无论投票如何分配，所有节点都能在群集中正常工作，获得群集数据库的更新，并可承载应用程序。

在某些灾难恢复配置下，管理员可能希望取消某些节点的投票。例如在多站点群集中，可以取消备份站点内节点的投票权，让这些节点不影响仲裁的计算结果。但只建议对跨站点手工故障转移的环境使用这种方式。

要查看节点配置的投票选项，可使用 Get-ClusterNode Windows PowerShell cmdlet 查看群集节点的通用属性 NodeWeight。如果值为“0”，意味着该节点无法参与仲裁投票；如果值为“1”则意味着该节点将参与仲裁投票，并且受到群集的管理。所有群集节点的投票分配情况可使用 Validate Cluster Quorum 验证测试加以验证。

3. 动态仲裁管理：

在 Windows Server 2012 中，作为一个高级仲裁配置选项，管理员可以选择启用群集的动态仲裁管理。在启用该选项后，群集可根据每个节点的状态动态管理节点的投票分配情况。离开活跃群集关系的节点投票会被自动取消，重新加入群集的节点可重新获得投票。默认情况下动态仲裁管理已被启用。注意 – 通过动态仲裁管理，群集仲裁的大多数将由任意时刻位于群集活跃成员关系内的节点决定。这一点与 Windows Server 2008 R2 的群集仲裁有很大不同，以前的仲裁大多数是固定的，取决于初始群集配置。通过动态仲裁管理，群集还可以通过最后一个残存的群集节点正常运行。通过动态调整仲裁大多数需求，群集可持续承受节点的关机，直到剩下最后一个节点。

群集为节点分配的动态投票可通过使用 Get-ClusterNode Windows PowerShell cmdlet 查看群集节点的通用属性 DynamicWeight 加以验证。如果值为“0”，意味着节点没有仲裁投票；值为“1”意味着节点有仲裁投票。

4. 动态见证：

在 Windows Server 2012 R2 中，如果群集被配置为使用动态仲裁（默认设置），见证投票也将根据当前群集关系中投票节点的数量进行动态调整。如果有奇数个投票，仲裁见证将不参与投票；如果有偶数个投票，仲裁见证将参与投票。

正如在上图中看到的，对于这个包含 64 的节点的群集，我们使用了“节点及磁盘大多数”仲裁配置，并且这也是默认的推荐设置，但这一共就有了 64 张投票 – 偶数个。我们需要奇数个投票，因此使用见证磁盘作为第 65 个投票。然而如果即将失去一个节点，最后又剩下 63 个运行中的节点：

在本例中，负载已经故障转移到其他节点，已关机节点的投票被取消。这样我们就剩下 63 个节点，每个节点都有一票，再加上见证磁盘也有一票。这样总共就有 64 张投票 – 又是偶数个。上文已经提过，我们需要确保投票数量为奇数，而在 Windows Server 2012 R2 中，我们可以自动将见证磁盘的票数调整为 0。群集仲裁也会自动调整，这一次将变为“节点大多数”。

仲裁见证投票也能根据见证资源的健康程度动态进行调整。如果见证资源脱机或故障，群集会将见证投票设置为“0”。

动态见证功能极大降低了由于见证资源故障导致群集停机的风险。群集可根据目前可用的节点投票数量决定是否使用见证投票。

这一改动也极大简化了群集见证的配置。管理员不再需要决定是否配置仲裁见证，因为 Windows Server 2012 R2 的推荐配置始终包含仲裁见证。群集可以自动决定何时使用见证。

四、 关闭时清空虚拟机

在 Windows Server 2012 中，如果关闭群集结点前没有清空节点，虚拟机会被切换至保存状态，随后转移到其他节点上恢复。这意味着虚拟机的可用性将产生中断。如果保存虚拟机状态所需时间太长，则可将虚拟机关闭，然后在其他节点上重启动。不过在 Windows Server 2012 R2 中，群集可自动在关闭前将运行中的虚拟机实时迁移到其他节点。

这一变化提供了一种更安全的机制，可确保服务器关闭（或任何需要关闭群集服务的情况）不会造成虚拟机的计划外停机。这样的设计可提高来宾操作系统内所运行应用程序的可用性。

微软官方建议管理员在关闭群集节点前先将其置于维护模式，或将所有虚拟机移动到其他节点。这是清空运行中群集角色最安全的方式。

要启用或禁用该功能，需要配置 DrainOnShutdown 群集通用属性。默认情况下该属性已启用（值为“1”）。

五、 虚拟机网络健康度检测

在 Windows Server 2012 中，如果发生虚拟机层面的网络中断，此时虽然该虚拟机对用户不可用，但实际上依然在计算机上正常运行。

在 Windows Server 2012 R2 中，虚拟机的设置界面新增了一个保护网络选项。如果受保护的虚拟网络断开，群集会将受影响的虚拟机实时迁移到外部虚拟网络可用的其他宿主机。为此群集节点间须有多个网络路径。

该设置位于网络适配器的高级功能下。默认情况下此设置已被启用。管理员可以针对每个虚拟机的每个网络修改该设置，因此如果有低优先级网络，例如用于测试或备份的网络，可以选择在这样的网络断开后不对虚拟机进行实时迁移。

如果没有可连接到群集其他节点的可用网络，群集会将此节点从群集成员关系中删除，转移虚拟机文件的所有权，然后在其他节点上重启动这些虚拟机。

这一变化提高了虚拟机遇到网络问题的可用性。如果进行实时迁移，由于实时迁移可维持虚拟机的会话状态，因此不会产生停机。

六、 增强的群集仪表板

在 Windows Server 2012 中，需要点击每个故障转移群集的名称才能查看状态信息。在 Windows Server 2012 R2 中，故障转移群集管理器新增的群集仪表板可供管理员快速查看所有被管理故障转移群集的健康度状态。管理员可以看到故障转移群集的名称，并通过图标了解群集的运行状态，群集角色的数量与状态，以及节点状态和事件状态。

如果要管理多个故障转移群集，该仪表板可让管理员更方便地快速查看故障转移群集的健康度。

七、 虚拟机监控

在运行 Windows Server 2012 与 Windows Server 2012 R2 的群集中，管理员可监控同样运行 Windows Server 2012 或 Windows Server 2012 R2 的群集虚拟机内的服务。管理员可以监控虚拟机内的任何 Windows 服务（例如 SQL 或 IIS），或虚拟机发生的任何 ETW 事件。当管理员监控的条件被触发后，群集服务会在宿主机的错误日志中加以记录，并执行恢复操作。这些操作可能是重启动服务，或在其他节点上重启动或移动群集虚拟机（取决于服务重启动设置集群及故障转移设置）。

只能在列表中看到使用自己的进程所运行的服务，例如 SQL、Exchange，但 IIS 与 Print Spooler 服务不受此规则限制。不过可以通过使用 Windows PowerShell Add-ClusterVMMonitoredItem cmdlet 设置监控任何 NT 服务 – 该命令无任何限制：

Add-ClusterVMMonitoredItem –VirtualMachine BJ-VM-03 -Service spooler

当被监控的服务遇到非预期故障，后续的恢复操作将由该服务的恢复操作决定。这些恢复操作可在来宾系统内部使用 Service Control Manager 查看并配置。在下图所示的例子中，在服务首次和第二次故障后，Service Control Manager 将重启动这些服务，如果再次故障，Service Control Manager 将不执行任何操作，并将恢复操作交由宿主机所运行的群集服务负责处理。

群集服务通过定期健康度检查监控群集虚拟机的状态。当群集服务确定某个虚拟机处于“关键”状态，例如虚拟机内部的应用程序或服务处于不健康状态，群集服务将执行下列恢复操作：

1) 宿主机记录 ID 1250 事件 – 随后可通过集中化的监控解决方案加以监控，例如 System Center Operations Manager。

2) 故障转移群集管理器内的虚拟机状态将显示该虚拟机处于“应用程序关键”状态。

3) 针对“应用程序关键”状态的虚拟机执行恢复操作。首先在同一个节点上重启动该虚拟机。请注意 – 虚拟机的重启动是强制不允许取消的。如果第二次故障，虚拟机将重启动并故障转移到群集的其他节点。请注意 – 故障转移，或在同节点上重启动，这个决定是可配置的，并可由虚拟机的故障转移属性决定。

八、 故障转移优先级，相关性及反相关性

1. 优先级

在 Windows Server 2012 及后续的 Windows Server 2012 R2 中，故障转移提供的新功能使得管理员能够定义群集中虚拟机的启动顺序，这样一旦遇到故障，有大量虚拟机需要尽快重启动，取决于选项设置，部分虚拟机可被优先进行重启动处理。

该功能可以帮助管理员确保如果故障转移导致资源占用率过高，最重要的虚拟机始终可以优先获得所需的全部资源，随后才开始处理重要性次高的虚拟机。

另外在节点故障后，如果高优先级虚拟机无法获得所需的足够内存和其他资源以完成启动操作，群集服务会暂时让低优先级的虚拟机脱机。随后释放出来的资源可分配给高优先级虚拟机。在必要时，可抢占启动最低优先级的虚拟机，随后继续启动高优先级虚拟机。抢占启动的虚拟机会按照优先级顺序重启动。

2. 相关性

在 Windows Server 2012 与 Windows Server 2012 R2 故障转移群集中，管理员可以配置首选和可能所有者。

对于特定虚拟机（从技术上说，可以是任何群集组），可对故障转移时所用节点的顺序进行配置。假设该虚拟机通常在节点 A 上运行，管理员希望在可行的情况下尽量将其转移到节点 C，那么就可通过首选所有者选项定义最先转移到的节点，随后转移到的节点，以及后续转移到的节点。这是一种优先级列表，群集将通过该列表确定虚拟机的放置位置。因此管理员可以明确控制虚拟机的位置。

另一方面，可能的所有者则是指，对于特定虚拟机（从技术上说，可以是任何群集资源），可以配置虚拟机在故障转移时可能放置到的节点。默认情况下这是指所有节点，但如果不希望将任何虚拟机故障转移到某个特定节点，则可将其从可能的所有者列表中删除，防止转移到该节点。

3. 反相关性

可能的所有者是一种尽量确保相关虚拟机相关虚拟机分散在不同节点上的做法，每个虚拟机都有相对独立的可能的所有者，不过还有另一种方式实现这一点。

AntiAffinityClassNames 是另一个群集组属性，Windows 故障转移群集使用该属性确定不应位于同一个节点的群集组。在使用群集的 Hyper-V 环境时，群机组与虚拟机之间存在 1:1 的关系，因此可以使用 AntiAffinityClassNames 属性为虚拟机配置反相关性。

一旦配置完毕，故障转移群集会尽可能试图确保属于同一个组的虚拟机分散到群集不同节点上。与故障转移优先级与首选的和可能的所有者功能配合使用后，即可更细化地控制重要虚拟化负载的放置。

九、 群集感知更新

在老版本 Windows Server 中，服务器更新工具（例如 WSUS）无法考虑一组服务器可能是高可用群集成员这种情况。由于高可用群集的目的是为群集中托管的服务提供高可用性，因此绝不能同时对群集的所有节点安装补丁。故障转移群集的补丁安装工作通常需要分批手工进行，或使用专门的脚本/工具，同时需要管理员加以密切关注，在每月一次短暂的维护窗口内为所有节点成功安装补丁。

群集感知更新（CAU）是 Windows Server 2012 R2 内建的一个重要功能，解决了这个问题。CAU 可供管理员对群集服务器进行更新，而更新过程几乎不会影响可用性，或者只产生最少量的影响。在进行更新的过程中，CAU 会用透明的方式将群集每个节点设置为节点维护模式，将“群集角色”临时故障转移到其他节点，为节点安装更新和其他必要内容，需要时执行重启动操作，让节点退出维护模式，将最初的群集角色重新转移到这个节点上，并对下一个节点执行更新。CAU 的工作与具体负载无关，非常适合 Hyper-V 及各种文件服务器负载。

尤其是从 Hyper-V 的角度来看，CAU 能与故障转移群集功能配合使用，将运行中的虚拟机迁移到不同物理节点，这样即可确保虚拟机中运行的重要应用程序和负载不会停机，同时宿主机设施也能安装必要的更新，随时保持最新状态。

管理员触发 CAU 扫描后，CAU 会配合节点本身令其针对更新源执行更新检查工作，例如更新源可能是 Microsoft Update、Windows Update，或 WSUS。

CAU 可帮助企业促进 IT 进程的一致性。针对不同类型的故障转移群集可创建更新运行配置文件，并能通过文件共享集中管理，以确保整个 IT 机构内所部署的 CAU 能用一致的方式应用更新，就算群集是由其他业务线或管理员负责管理的也不受影响。

更新的运行可安排计划，每天、每周，或每月进行，这样即可确保群集的更新与其他 IT 管理流程保持一致，而 CAU 提供了一种可扩展架构，能用可感知群集的方式对群集软件清单进行更新。这样开发商即可对并非通过 Windows Update 或 Microsoft Update 发布的软件更新，或并非来自微软的更新安装情况进行协调，例如非微软设备的驱动更新。

CAU 的自行更新模式促成了一种“一体式群集”装置（一套运行 Windows Server 2012 与 Windows Server 2012 R2，通常安装到一个机箱内的群集环境）自行更新操作。一般来说，这类装置都部署在分支办公室，缺乏管理群集的本地 IT 人员。自行更新模式能为这类环境提供巨大的价值。

CAU 有两种模式：下文第一张图所示的自行更新模式，以及第二张图所示的远程更新模式。

在自行更新模式中，需要在一个节点上运行 CAU 角色，并充当更新工作的协调者。更新协调者这个节点确保了整个群集都能顺利安装更新。CAU 角色也是可以感知群集的，因此 CAU 更新协调者角色可由多个节点承担 – 但同一时间只能有一个节点是更新协调者。

另一方面，远程更新模式使得运行 Windows Server 2012、Windows Server 2012 R2、Windows 8 或 Windows 8.1 的远程计算机可以充当 CAU 更新协调者。这种方法最适合使用 CAU 对 Windows Server 2012/R2 服务器核心操作系统安装更新，并且需要实时看到更新进度的情况。

要部署故障转移群集，并充分利用故障转移群集的其他功能，需满足下列条件：

1. 带 Hyper-V 的 Windows Server 2012 R2 或 Hyper-V Server 2012 R2。

2. 对于群集共享卷，需要共享存储，并通过 iSCSI 或光纤通道连接。

3. 对于虚拟机监控，需要创建相应的防火墙例外，并提供所需的域配置。

4. 对于群集感知更新，需要 WSUS 基础结构，或从一个群集节点连接到互联网以访问 Microsoft/Windows Update。

十、 来宾群集

在 Windows Server 2012 Hyper-V 中，微软为虚拟机本身的虚拟化工作提供了完整的支持，从群集到来宾操作系统全都包含在内。例如群集的 SQL AlwaysOn 配置，其本身就需要多个节点，所有节点都为虚拟机，并且还需要访问共享存储。该配置看起来类似下图所示：

在上述例子中有一个简单的三节点 Hyper-V 物理群集，在该群集基础上使用两个虚拟机创建了两节点来宾群集，这些节点都能直接访问共享存储。使用共享存储的来宾群集在微软平台中可充分利用多种不同存储选项所提供的优势。举例来说，如果使用 SMB 存储作为 Hyper-V 群集的主要存储方式，则该 SMB 存储还可通过网络供应给虚拟机使用。通过这种方式，虚拟机即可借助虚拟网络适配器访问 iSCSI 存储。然而这些场景都需要通过虚拟网络适配器将底层存储设施直接提供给虚拟机，而非使用共享存储上保存的 VHD 或 VHDX 文件。

Windows Server 2012 中首次引入了虚拟光纤通道。正如上文介绍的，通过该技术可将虚拟光线存储直接供应给虚拟机，并能通过访问共享存储直接构建来宾群集。

上文曾提过，来宾群集配置可得到微软的完整支持，并可配合其他功能，例如实时迁移与动态内存等功能使用，这意味着客户能够将群集负载虚拟化，并且不会影响密度和敏捷度等重要特性。此外来宾群集能通过故障转移优先级、相关性，及反相关性等上文介绍的功能获益，可确保来宾群集节点能以在相互之间，以及与底层物理宿主机之间最优化方式放置。

来宾群集的优势是可提供额外的一层适应性。如果物理宿主机故障，只会导致来宾群集的一个节点子集遇到故障，来宾群集所提供的应用程序级别的适应性依然能够快速恢复负载。

当物理节点故障了，之前在该节点运行的虚拟机也停止运行，但物理 Hyper-V 群集可确保虚拟机在其他节点所运行的来宾群集虚拟机中快速重启动。应用程序级别的适应性确保了从整体来看，应用程序或负载只会经历一个短时间的停机。

然而挑战之处在于，在这些配置中，底层存储（FC、iSCSI、SMB）需要直接供应给虚拟机。在私有或公共云环境中，通常需要为用户或租户管理员隐藏底层设施细节。

PS：文章在写作的同时参考有微软TechNet。

转载于:https://blog.51cto.com/ericxuting/1597930