什么是 Windows Server 中的故障转移集群？

什么是 Windows Server 中的故障转移集群？

计划外停机可能带来严重的财务后果。关键应用哪怕中断一小时，也可能让企业损失数千到数百万美元的收入、生产力以及声誉损害。正因如此，高可用性（HA）如今已成为现代 IT 基础设施的基本要求。

如果您的服务器运行的是 Windows Server 系统，Microsoft 的 Windows Server 故障转移集群（WSFC）可以作为一个选项。它是一组协同工作的独立服务器（节点），用于提高应用程序和服务器（称为集群角色）的可用性和可扩展性。

如果一个或多个节点发生硬件或软件故障，其余节点会通过称为故障转移的过程自动接管工作负载，从而最大限度地减少服务中断。

Windows Server 故障转移集群如何工作？

WSFC 并不是简单的“备份服务器”配置。它是一个复杂的编排引擎，协调多个独立系统之间的资源。

节点与集群网络

WSFC 集群中的每台服务器都是一个节点，可以是物理机或虚拟机。节点通过默认均能够承载心跳信号（端口 3343 上 134 字节的小型 UDP 数据包）的网络进行通信。集群不会按传统意义上的“公用”或“专用”来区分网络角色；每个启用于集群用途的网络都会传输心跳和其他集群流量。

尽管如此，Microsoft 和经验丰富的管理员仍然推荐的最佳实践是：至少专用一个网络用于内部集群通信。该网络承载健康检查、集群共享卷（CSV）重定向和管理命令，将其与面向客户端的应用流量隔离。

为这些通信提供可靠、低延迟的连接，可显著降低误判故障的风险。但请不要将其视为“仅心跳”网络——它处理所有关键的节点间集群流量。

WSFC 节点可以采用两种主要模式部署：

• • 主动/被动：部分节点主动运行工作负载，其他节点处于待命状态。当主动节点发生故障时，被动节点接管。此配置强调简单性和可靠性，在可以接受专用待命硬件时通常更具成本效益。
  • 主动/主动：所有节点同时运行工作负载并分担处理负载。这可以最大化性能和资源利用率，但需要谨慎的容量规划，以便在另一节点发生故障时单个节点能够吸收额外负载。选择取决于组织的具体需求以及集群应用的关键程度。

仲裁：防止脑裂的大脑

任何分布式系统最大的危险是脑裂场景——集群节点失去通信，每个节点都认为自己是唯一的活动集群，从而导致数据损坏。WSFC 通过仲裁机制防止这种情况。

仲裁是集群保持在线所需的最少集群成员投票数。当发生网络分区时，只有拥有仲裁的分区继续提供工作负载；其他节点停止运行以保护数据完整性。

Windows Server 支持多种仲裁类型：

• 节点多数：适用于节点数为奇数的场景。每个节点获得一票。
• 节点和磁盘多数：共享磁盘（磁盘见证）也获得一票，适用于具有共享存储的偶数节点集群。
• 节点和文件共享多数：单独服务器上的文件共享充当见证。
• 云见证：使用 Azure blob 存储容器作为仲裁点。非常适合多站点集群、无共享存储的环境、Azure 托管的 VM 以及分支机构部署。

现代 Windows Server 版本（2012 R2 及更高版本）包含动态仲裁，默认启用。动态仲裁允许集群在节点加入或离开时自动调整分配给每个节点和见证的投票数。例如，如果某个节点正常关闭，集群会重新计算，并可能为剩余节点分配额外权重以维持仲裁。这大大提高了集群的韧性，无需人工干预。

如何在 Windows Server 中逐步创建和配置故障转移集群

在本节中，我们将演示如何在 Windows Server 2008/2012/2016/2019/2022/2025 中配置故障转移集群的详细步骤。

前提条件：✎…

操作系统一致性：所有服务器需要运行相同版本的 Windows Server。还强烈建议各节点保持相同的补丁级别，以避免故障转移期间出现意外行为。

所有节点应加入同一个 AD 域，并设置为与域控制器相同的时区。域控制器本身不应托管在任何集群节点上（虽然技术上可行，但会造成复杂的启动时依赖关系，最好避免）。

验证您的服务器满足故障转移集群硬件要求。对于存储空间直通（Storage Spaces Direct），还有额外的硬件要求。

您需要域管理员凭据（或委派权限）来创建集群。

建议在 AD DS 中为集群计算机对象创建一个专用 OU。这样可以更好地控制组策略设置，并防止集群对象被意外删除。

如果在创建期间添加集群存储，请确保所有服务器都能访问共享存储（iSCSI、光纤通道等）。

安装故障转移集群功能

选项 A：使用服务器管理器（GUI）安装

1. 在每个节点上打开服务器管理器。

2. 单击“管理” > “添加角色和功能” > “功能”。

3. 选择“远程服务器管理工具” > “功能管理工具” > “故障转移集群”并完成安装。在每个节点上重复此操作。

选项 B：使用 PowerShell 安装

在每个节点上以管理员身份运行 PowerShell 并执行：

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

-IncludeManagementTools 参数会同时安装该功能和故障转移集群管理器管理单元。

运行集群验证向导

该步骤将测试您的硬件、网络、存储和系统配置的兼容性。

1. 打开故障转移集群管理器（或使用 Windows Admin Center）。

2. 在中间窗格中，单击“验证配置”。

3. 添加您想要作为集群节点的所有服务器名称。

4. 选择“运行所有测试”（推荐）并仔细查看结果。

5. 在继续之前解决所有错误和任何相关警告。

创建集群

使用 Windows Admin Center：

1. 在 Windows Admin Center 中，导航到集群管理器。

2. 将服务器添加为节点，配置网络设置（名称、IP、子网掩码、VLAN ID），然后单击“下一步”。

3. 在“创建集群”页面上，输入唯一的集群名称和 IP 地址，然后单击“创建集群”。

4. 如果遇到 DNS 传播延迟（错误：“Failed to reach cluster through DNS”），请单击“重试连接检查”。

使用 PowerShell：

# Creates a new cluster named MyCluster using Server1 and Server2, setting a static IP
New-Cluster -Name MyCluster -Node Server1, Server2 -StaticAddress 192.168.1.100

如果您计划稍后添加存储，可以附加 -NoStorage 参数。

创建后，验证集群名称是否出现在故障转移集群管理器的导航树中。集群名称在 DNS 中复制并出现在服务器管理器的“所有服务器”视图中显示为“联机”可能需要一些时间。

配置集群仲裁

对于双节点集群，见证是必不可少的。对于更大的偶数节点集群，强烈建议配置见证。要配置云见证：

确保您拥有有效的 Azure 订阅、通用存储账户，并在所有集群节点上开放端口 443 以访问 Azure 存储服务 REST 接口。

1. 在故障转移集群管理器中，右键单击集群 > “更多操作” > “配置集群仲裁设置”。

2. 按照向导操作，选择“选择仲裁见证”。

3. 在“选择仲裁见证”窗口中，我们建议选择“配置云见证”。

4. 输入您的 Azure 存储账户名称和访问密钥。向导会自动创建一个名为 msft-cloud-witness 的容器，用于存储投票仲裁所用的 blob 文件。（注意：Windows Server 2025 还支持托管标识，无需管理访问密钥。）

配置集群感知更新（CAU）

CAU 使您能够为集群节点应用 Windows 更新，同时集群角色零停机。它会自动从一个节点排空角色、应用更新、重启并使节点重新上线——然后移动到下一个节点。

1. 在故障转移集群管理器中，在控制台树中选择您的集群。转到“操作”窗格或主页，单击“集群感知更新”。

2. 在集群感知更新窗口中，单击“配置集群自更新选项”。

3. 在“添加集群角色”页面上，勾选“添加 CAU 集群角色，并启用自更新模式”。如果您在 Active Directory 中为此角色预置了计算机对象，还请勾选“我为 CAU 集群角色预置了计算机对象”并提供对象名称。

4. 然后配置更新源和计划：

• 更新源：默认情况下，CAU 使用 Windows 更新代理（WUA）插件，可配置为从 Microsoft Update、Windows Update 或本地 Windows Server Update Services（WSUS）服务器拉取更新。
• 计划：设置所需的定期更新计划（例如，每周六凌晨 2:00）。CAU 将在计划时间自动开始更新过程。

5. 如有需要，单击“高级选项”：

• 每个节点的最大重试次数：默认值为 3。如果更新在某个特定节点上失败，CAU 最多重试此限制次数，然后将该节点标记为“失败”并继续。
• 最大失败节点数：一旦整个集群达到此限制，整个更新运行将停止。
• 更新前和更新后脚本：在每个节点上更新过程之前和之后运行的自定义 PowerShell 脚本。这些对于在重启节点前验证存储同步状态等任务很有用。

配置完成后，单击“下一步”，然后单击“应用”以完成向导。

设置故障回复策略

故障回复是指集群角色在该节点从故障中恢复后自动移回其首选所有者。在许多生产环境中，不建议自动故障回复。如果某个节点在凌晨 2 点发生故障并在上午 10 点恢复，立即自动故障回复可能会在用户最活跃的时候造成第二次短暂中断。

以下是如何将角色配置为手动或计划故障回复。

1. 在故障转移集群管理器中，在控制台树中展开您的集群。单击左窗格中的“角色”。

2. 右键单击集群角色（例如，虚拟机、SQL Server 实例或文件服务器角色），然后选择“属性”。

3. 在“常规”选项卡上的“首选所有者”下，按首选顺序选择一个或多个节点。

4. 单击“故障转移”选项卡。在“故障回复”下，选择以下之一：

• 阻止故障回复（默认值，建议用于大多数生产工作负载）
• 允许立即故障回复
• 允许在 [开始时间] 和 [结束时间] 之间故障回复——指定允许自动故障回复的时间窗口。

5. 单击“确定”应用。

您还可以使用 FailoverClusters 模块中的 PowerShell cmdlet 配置首选所有者和故障回复策略：

# View current preferred owners for a role
Get-ClusterOwnerNode -Cluster MyCluster -Group "SQL Server (MSSQLSERVER)"

# Set preferred owners (ordered by priority)
Set-ClusterOwnerNode -Cluster MyCluster -Group "SQL Server (MSSQLSERVER)" -Owners Node1, Node2

# Configure failback behavior
# Parameters: -FailbackType Immediate | Prevent | Policy; -FailbackWindowStart/End if Policy is used
Set-ClusterGroup -Cluster MyCluster -Name "SQL Server (MSSQLSERVER)" -FailbackType Prevent

# Or allow failback within a specific window
Set-ClusterGroup -Cluster MyCluster -Name "SQL Server (MSSQLSERVER)" `
    -FailbackType Policy `
    -FailbackWindowStart 1 `
-FailbackWindowEnd 4

关键参数：

• -FailbackType：接受 Immediate（首选节点恢复后立即故障回复）、Prevent（不自动故障回复——默认值）或 Policy（仅在 -FailbackWindowStart 和 -FailbackWindowEnd 指定的窗口内故障回复）。
• -FailbackWindowStart 和 -FailbackWindowEnd：指定允许自动故障回复的小时数（24 小时制）。这些仅在 -FailbackType 设置为 Policy 时适用。
• -PreferredOwner：指定角色应优先故障回复到的节点。

故障排查：破坏故障转移集群的 3 个常见错误

即使是设计良好的集群也可能因配置疏忽而失败。基于真实世界的故障模式，以下是最常见的原因。

错误 1：网络配置错误

问题：集群通信流量与同一 NIC 上的应用流量竞争，导致延迟飙升或数据包丢失。不正确的 DNS 设置或防火墙规则阻止了 UDP 端口 3343（集群服务通信端口）。

修复方法：为集群通信使用专用网络接口（或组合），将其与客户端访问流量分离。验证所有节点上所有集群名称的 DNS 解析。确保防火墙规则允许 UDP 端口 3343 用于集群通信。使用性能监视器监控数据包丢失。网络不稳定是导致不必要故障转移的主要原因，更糟糕的是，还会导致需要故障转移却无法成功的情况。

错误 2：仲裁配置错误

问题：双节点集群未正确配置见证。一次简单的网络中断就会使两个节点都无法形成仲裁，导致即使两台服务器完全健康也会出现完全服务中断。

修复方法：始终为偶数节点集群配置见证。验证见证资源（磁盘、文件共享或 Azure blob）可从所有节点访问。请记住，动态仲裁（默认启用）会自动调整投票，但它需要正确配置的基础仲裁才能运作。

错误 3：存储不一致

问题：各节点之间的驱动器号或装入点不匹配。在基于复制的集群中，上线前未能完全同步卷。存储复制流量带宽不足。

修复方法：验证所有节点本地磁盘上的驱动器号和装入点一致性。对于共享存储，在创建集群之前测试所有节点都能访问所有 LUN。对于存储空间直通（S2D），确保所有磁盘满足硬件要求并已正确初始化。

诊断工具

故障排查时，请利用以下工具：

• 事件查看器：查找事件 ID 1069（集群资源失败）、1146（集群节点被移除）和 1230（集群网络失败）。这些是在意外故障转移调查中首先要检查的地方。
• Get-ClusterLog PowerShell cmdlet：此命令从所有集群节点收集时间相关的诊断日志，并将其保存到执行该命令的节点上的单个工作目录中。它对于深入分析集群事件非常有价值。
• 验证配置向导：随时重新运行验证，以检查配置漂移或新出现的硬件问题。

WSFC 的替代方案：实现更好的高可用能力

尽管有其优势，Windows Server 故障转移集群并非通用解决方案。它需要深厚的专业知识才能正确配置，严重依赖共享存储，并且无法将高可用性扩展到非 Windows 系统。

此外，其原生故障转移机制以存储为中心而非以应用为中心。检测故障并完成切换可能需要很长时间。

这正是 i2Availability 的用武之地。由 英方软件 开发的 i2Availability 是一个第三方高可用性和灾难恢复平台，将字节级实时复制与应用感知健康监控相结合。它保护运行在 Windows、Linux 和异构虚拟化平台上的关键应用。

以下是 i2Availability 如何直接解决 WSFC 单独无法完全解决的痛点：

• 无需共享存储。与 WSFC 不同，i2Availability 使用字节级复制来同步每个节点上的独立存储卷。这消除了共享存储单点故障，并大幅降低基础设施成本。
• 跨平台、异构保护。您可以在单一控制台中保护跨不同操作系统、hypervisor 和硬件平台的应用程序。相比之下，WSFC 仅限于 Windows Server 节点。
• 亚秒级、应用感知故障转移。i2Availability 不仅监控服务器硬件，还监控应用本身——进程健康状况、网络可用性和操作系统响应能力。它比大多数原生集群心跳更快地检测故障，并可在不到一秒内触发自动故障转移。
• 更简单的管理。集中式 Web 控制台取代了 WSFC 所需的多个 MMC 管理单元、PowerShell 脚本和手动验证步骤。预置规则和自动化工作流使即使没有专业集群技术知识的团队也能轻松实现高可用性。
• 池化集群模型实现持续韧性。除了经典的主备对之外，i2Availability 还可以将多台待命服务器分组到资源池中。当主动节点发生故障时，系统会自动选择最合适的待命节点，确保即使在故障转移后也能保持冗余

您可以查看演示视频，了解如何使用 i2Availability 构建稳健的高可用性：

您可以单击下面的按钮申请 60 天免费试用：

结论

Windows Server 中的故障转移集群仍然是 Microsoft 环境的基础高可用性技术。在本指南中，我们逐步介绍了 Windows Server 中故障转移集群的配置过程。

此外，对于需要更灵活、应用感知和跨平台高可用性方法的组织，英方软件 的 i2Availability 是一个强大的替代方案。凭借内置的实时复制、亚秒级故障转移和集中管理体验，它解决了原生 WSFC 经常遇到的复杂性、存储依赖和平台限制问题