Windows Server 2025 / 故障转移群集规划方法

Windows Server 故障转移群集(Windows Server Failover Clustering,WSFC)在服务器之间协调受支持的角色,并可在故障后重新启动或转移角色。只有两台服务器还不够,应用、存储、网络、仲裁、验证和恢复目标必须组成相互匹配的设计。

明确需要承受的故障

节点是参与群集的服务器,群集角色则是由群集管理的一组服务或虚拟机资源。检测故障和转移角色可能中断连接,因此需要测试客户端何时重新连接、应用何时真正可用,而不是只看管理界面中资源已联机。

需求 相应设计
单节点故障 受支持的群集角色与故障转移
恢复已删除数据 具有恢复时间点的独立备份
整个站点故障 独立故障域与灾难恢复
分配 Web 请求 适合应用的负载均衡和状态管理

高可用不能替代备份或灾难恢复。同一物理主机上的两台虚拟机可能一起停机;即使主机分开,也可能依赖同一存储设备、电源或交换机。在普通 IIS 服务器上启用群集功能,不会自动使网站具备高可用性。首先要确认应用支持哪种架构。

先确定受保护角色、恢复时间目标(Recovery Time Objective,RTO)和恢复点目标(Recovery Point Objective,RPO)。RTO 表示可接受的恢复时长,RPO 表示相对于可恢复时间点能够容忍的数据丢失。应记录计时起止条件及验收证据,不能默认群集具有零中断或零数据丢失能力。

检查节点、网络与剩余容量

对照群集硬件与存储要求检查 Windows Server 版本、受支持设备、驱动程序和固件。新方案可采用配置相近的 Windows Server 2025 节点,并确认整个配置能够获得支持、通过验证。常规域部署有相同版本和域等条件;工作组群集的要求不同,不应混用两种部署流程。

  • 绘制管理、群集、存储以及适用时的虚拟机迁移流量,估计故障与恢复期间的带宽需求及流量竞争。
  • 识别网卡、交换机、电源和存储路径中的单点故障。即使节点名称不同,也要记录共用依赖。
  • 计算丢失一个节点后剩余的处理器、内存和存储容量,包括接管负载与重新同步开销。正常运行时总容量充足,不代表故障期间也足够。
  • 域部署中检查内部 DNS、时间同步、群集身份和名称注册权限,并按部署方法将群集节点与域控制器分开。

把地址、名称、虚拟局域网(VLAN)和防火墙要求汇总到共享网络规划中。多块网卡如果经过同一交换机或布线路径,并不构成独立链路。例如,某台主机失效时,要写明哪一节点接管负载、还剩多少资源;共享存储失效时,要说明剩余节点是否仍能访问数据。应先区分这些情形,再决定增加哪些容量。

选择角色支持的存储

共享磁盘、服务器消息块(Server Message Block,SMB)存储和 Storage Spaces Direct 各有角色、硬件、版本及支持条件,不能假定所有选项适用于所有工作负载。两节点上的同名本地文件夹不提供共享数据,DFS 命名空间也不会自动提供复制或群集存储。所选方案必须让接管角色的节点以受支持方式访问最新数据。

检查项目 设计问题
数据访问 另一个节点能否访问相同的最新数据?
故障隔离 节点故障与存储故障能否分别处理?
支持条件 操作系统、角色、硬件与协议的组合是否受支持?
容量 是否能承受接管负载及重新同步的开销?
恢复 是否已验证备份一致性和应用恢复顺序?

在把业务磁盘交给配置或存储验证之前,先使用独立测试环境。记录磁盘所有权、预留、访问路径和架构的许可条件。能看到某块磁盘,不表示它可以自由分配。没有保护服务和数据的操作计划,不应把生产数据直接投入存储测试。

规划仲裁与见证的故障域

仲裁用于决定群集是否可以继续运行,包括网络分区把组件隔开的情况,并帮助避免同一资源出现相互竞争的所有者。见证参与仲裁决定,但不是服务数据的备份,也不是额外执行工作负载的节点。能够访问见证,并不证明存储或应用也能正常访问。

根据仲裁见证部署指南比较磁盘见证、文件共享见证和云见证。除节点数量外,还要考虑位置、权限、网络分区及外部连接。各类型有独立前提,例如云见证依赖获准的 Azure 资源及节点到相关服务的 HTTPS 连接。动态仲裁不能保证应对任意故障组合或发生顺序。

见证如果处于同一故障域,可能随两个节点一起不可用。物理距离远也不够,共用路径中断或授权缺失仍会影响访问。建立节点丢失、节点间连接中断、存储路径丢失和整处站点失效的矩阵,逐项记录剩余参与者、见证位置、数据访问能力及预期行为。结合所选见证类型的指南核对后,才能判断方案是否满足连续性要求。

把验证作为部署决策的前提

  1. 记录节点、网络、存储、账号、名称和受保护角色,分配负责人,并把各项依赖与可能造成的故障关联起来。
  2. 统一核对功能、更新、驱动和支持条件,确认完整配置的兼容性,而不只是各零件单独受支持。
  3. 在创建群集前安排配置验证。对每个警告和失败给出解决办法,或说明原因、影响与后续措施;保存一份警告报告不等于已完成审查。
  4. 在获准的测试环境中,把计划内角色移动和意外故障分开测试。计划移动成功不能证明自动故障检测和恢复具有相同结果。
  5. 测量客户端重连、数据一致性、恢复时长和告警送达情况,对照 RTO、RPO 记录实际差异,不虚构测试数值。
  6. 分别验证备份恢复和整个故障域丢失的场景,记录恢复顺序、依赖、责任人,以及返回正常运行的判定条件。

遵循适合该架构的群集创建与验证指南。存储测试可能影响服务,不能在生产环境不加区分地运行所有测试。保留报告及每项发现的原因、影响和处理措施。域部署还要规划管理节点以及创建或预先准备计算机对象的必要权限,不能只为绕过权限错误就授予整个域的管理权。

这项规划练习不会把 DC1、FS1 或课程中的其他服务器改成群集。成果应是受支持的角色设计、资源需求、故障域图、可接受中断目标,以及有明确负责人的验证计划。如果无法解释存储失效时会发生什么,或者如何恢复已删除文件,应把它记为待决事项。增加一个节点不会自动解决这些问题。