业务系统对服务器的依赖程度越来越高，单机部署一旦遇到硬件故障或计划内维护，服务就会被迫中断。Windows Server 提供的故障转移集群（Failover Cluster）可以将多台服务器组合成一个逻辑单元，当其中某个节点出现故障时，工作负载会自动切换到健康节点上，从而大幅提升业务的可用性。本文以 Windows Server 2019 为例，完整走一遍创建故障转移集群的全过程，并针对每一步容易踩的坑给出说明。
一、创建集群前的环境准备
故障转移集群对底层环境有明确要求，任何一项不满足都会在后续的验证环节报错。首先是操作系统版本，所有节点必须使用相同版本的 Windows Server，且都为 Standard 或 Datacenter 版本，同时加入同一个 Active Directory 域。集群账号需要一个具有域管理员权限的账户来执行创建操作，节点本身的计算机账户也需要有创建计算机对象的权限。
其次是网络配置。每个节点至少需要两块网卡：一块用于业务流量，另一块专门作为心跳网络。心跳网络建议独立网段，不配置网关，不与业务网络共用，这样能避免网络抖动引起的误判。所有节点的 DNS 设置要指向域控制器，确保名称解析正常。
最后是存储。传统集群要求共享存储，可以是光纤通道 SAN、SAS 阵列，也可以用 iSCSI 目标模拟。测试环境下最常用的方式是在一台服务器上安装 iSCSI 目标服务器角色，划分出集群磁盘和仲裁盘。下面是在存储服务器上用 PowerShell 创建 iSCSI 虚拟磁盘的示例：
# 在存储服务器上执行，创建集群共享磁盘和仲裁磁盘
New-IscsiVirtualDisk -Path "D:\iSCSI\cluster-data.vhdx" -SizeBytes 100GB
New-IscsiVirtualDisk -Path "D:\iSCSI\quorum.vhdx" -SizeBytes 1GB
# 创建 iSCSI 目标并绑定两块磁盘
New-IscsiServerTarget -TargetName "cluster-target" -InitiatorIds @("DNSNAME:node01.contoso.com","DNSNAME:node02.contoso.com")
Add-IscsiVirtualDiskTargetMapping -TargetName "cluster-target" -Path "D:\iSCSI\cluster-data.vhdx"
Add-IscsiVirtualDiskTargetMapping -TargetName "cluster-target" -Path "D:\iSCSI\quorum.vhdx"
创建完成后，在两个节点上分别打开 iSCSI 发起程序，连接到存储服务器的 IQN，并在磁盘管理中联机、初始化、格式化共享磁盘。这里有一个细节要注意：磁盘只需要在其中一个节点上格式化，另一个节点刷新后即可看到卷，千万不要两边各自格式化一遍，否则会破坏数据。
二、安装故障转移集群功能并运行验证
环境就绪后，需要在每个节点上安装故障转移集群功能。这个功能不安装任何服务，只是把管理工具和集群组件放到系统中，安装后不需要重启。可以通过服务器管理器的添加角色和功能向导安装，也可以直接用 PowerShell 一条命令完成：
# 在所有节点上执行 Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
功能装好后，强烈建议先运行群集验证向导。微软官方的立场是：验证不通过的配置不在支持范围内，所以这一步不能省。打开故障转移集群管理器，选择验证配置，添加所有节点，测试内容选择全部运行。验证过程会检查网络延迟、存储读写、系统版本一致性等几十项内容，耗时可能十几分钟。
验证报告中常见的警告有几类。存储持久保留超时警告通常与磁盘性能有关，生产环境需要认真对待；网络缺少冗余的警告说明只配置了一块心跳网卡，建议补充第二块；缺少域控制器可达性检查失败则要排查域网络。只要报告结论是适合使用群集，即使存在警告也可以继续，但如果出现错误项，必须先解决再创建。
三、创建集群与基础配置
验证通过后就可以正式创建集群了。在故障转移集群管理器中选择创建群集，或者使用命令行方式，后者在批量部署时更方便：
# 创建名为 CL01 的集群，指定静态 IP New-Cluster -Name CL01 -Node node01,node02 -StaticAddress 192.168.10.100 # 将可用磁盘添加到集群存储 Get-Disk | Where-Object PartitionStyle -eq "MBR" | Add-ClusterDisk
集群创建时会自动把之前连接的共享磁盘纳入管理，并默认选取其中一块小容量磁盘作为仲裁见证。仲裁的作用很关键：集群通过投票机制决定谁是存活方，节点票加磁盘见证票必须超过总票数的一半，否则集群会停止服务以避免脑裂。双节点集群配一块仲裁盘正好是三票，任何一方挂掉都无法达到多数，数据一致性得以保障。
创建完成后建议做几项基础检查。打开网络视图，确认心跳网络被标记为群集使用且不允许客户端访问；查看集群核心资源，确认集群名称和 IP 地址处于联机状态。如果业务跨子网，需要为集群 IP 地址资源配置 OR 依赖关系，让不同子网的 IP 都能承载集群身份。
四、部署高可用角色与故障切换测试
集群本身只是一个框架，真正的业务由角色承载。常见的角色包括文件服务器、Hyper-V 虚拟机、SQL Server 等。以通用应用程序或文件服务器为例，在故障转移集群管理器中配置角色，选择高可用的工作负载类型，向导会引导绑定客户端访问点、存储和依赖资源。配置完成后，所有资源会组织成一个资源组，整个组作为一个单元在节点间移动。
偏好设置决定资源组的归属。首选所有者节点设定了正常运行时希望承载资源的节点，故障回退策略可以配置为阻止或允许在特定时间回退。生产环境通常把回退时间安排在业务低峰，避免白天自动回退造成二次中断。
最后一步是演练故障切换，这一步在生产上线前必须完成。可以先做计划内迁移，右键角色选择移动，观察资源按依赖顺序依次脱机、联机的完整流程；再做故障模拟，直接关闭当前承载节点的电源，检验集群能否在检测超时后自动接管。切换耗时取决于资源类型和检测阈值，可以在资源属性的策略选项卡中调整心跳间隔和阈值，例如将 Ping 间隔从 5 秒调整为更短以加快故障感知，但过于激进的设置在高负载环境下容易误判，需要结合实际权衡。
五、日常运维中的注意事项
集群建成后并非一劳永逸。补丁更新要逐节点进行：先暂停一个节点，排空其上的角色，安装更新并重启，验证正常后再恢复节点并轮换另一个。操作系统的事件日志中，系统分类下的 FailoverClustering 事件源是排查问题的主要入口，节点驱逐、资源失败、仲裁变更都会在这里留痕。
存储链路的健康同样值得关注。多路径软件 MPIO 应该在连接 iSCSI 或光纤存储前安装好，路径冗余可以避免单链路故障导致集群存储脱机。另外，所有节点的 BIOS、驱动和固件版本尽量保持一致，微软的集群验证对固件差异比较敏感，版本不一致有时会引发间歇性的存储超时。
监控方面，可以把集群事件转发到日志服务器，重点关注事件 ID 1069（资源失败）、1177（仲裁丢失）和 1135（节点失联）。提前配置好告警通道，问题发生时才能第一时间介入，真正发挥故障转移集群高可用的价值。
故障转移集群Windows Server高可用修改时间：2026-09-11 20:30:47