2. Windows Server故障转移集群基础

Always On可用性组并不是独立于操作系统的高可用机制，它建立在Windows Server故障转移集群（WSFC）之上。理解WSFC的集群角色、仲裁配置、节点与存储要求，是后续部署可用性组的前提。本节围绕“集群如何形成、如何判断存活、如何为Always On准备环境”展开，帮助读者建立可落地的工程认知。

一、集群角色：从节点到资源组

WSFC由若干节点（Node）组成，每个节点是一台安装了故障转移集群功能的Windows Server。节点之间通过心跳网络互相探测，通过共享的集群数据库（位于仲裁见证或节点本地）维护集群状态。集群中的资源（Resource）是真正被管理的对象，例如IP地址、网络名称、磁盘、服务或角色。资源被组织成角色（Role，旧称资源组），角色是故障转移的最小单位：当一个角色中的关键资源失效时，集群会尝试将该角色整体迁移到其他节点。

在Always On场景中，可用性组会注册为一个集群角色，其下包含可用性组资源、监听器资源（网络名称与IP）以及可能的共享存储资源。理解这一点很关键：可用性组的故障转移，本质上是集群角色在节点间的迁移，而SQL Server实例负责副本间的数据同步。因此，集群角色配置是否正确，直接决定可用性组能否正常上线和切换。

二、仲裁配置：决定集群“存活”的投票规则

仲裁（Quorum）是WSFC判断集群是否健康的核心机制。每个节点和见证资源都拥有投票权，集群需要获得超过半数的投票才能保持运行。仲裁配置决定了在部分节点或网络故障时，集群是继续提供服务还是停止，以避免“脑裂”（Split-Brain）导致数据不一致。

常见的仲裁模式包括：

• 节点多数（Node Majority）：仅节点投票，适合奇数节点集群，如3节点、5节点。
• 节点与磁盘多数（Node and Disk Majority）：节点加共享磁盘见证投票，适合偶数节点且有共享存储的场景。
• 节点与文件共享多数（Node and File Share Majority）：节点加文件共享见证投票，适合偶数节点且无共享存储的场景，常用于跨机房或云环境。
• 无多数：仅磁盘（No Majority: Disk Only）：仅磁盘见证投票，已不推荐用于生产环境。

以2节点集群为例，若采用节点多数，总票数为2，多数为2，任一节点故障都会导致集群失去多数而停止。因此2节点集群通常需要配置文件共享见证或磁盘见证，使总票数为3，多数为2，从而允许单节点故障。对于Always On可用性组，推荐使用“节点与文件共享多数”或“节点与磁盘多数”，并确保见证资源位于独立于节点的第三站点或共享存储上。

三、节点与存储要求

节点层面，所有节点应满足：操作系统版本一致且受支持（如Windows Server 2016/2019/2022），加入同一Active Directory域，时间同步一致，网络配置满足心跳与客户端访问分离。建议为心跳配置独立网段或至少独立网卡，避免客户端大流量影响心跳探测。节点间应开放必要的防火墙端口，包括RPC、SMB、WMI以及SQL Server相关端口。

存储层面，WSFC本身可以使用共享存储（如SAN、iSCSI）或仅使用本地存储。对于Always On可用性组，数据副本通常存放在各节点的本地存储上，由SQL Server负责同步，因此不强制要求共享存储。但仲裁见证需要独立于节点的存储或文件共享。若使用共享磁盘见证，需确保磁盘在集群中正确挂载并可被所有节点识别；若使用文件共享见证，需保证共享路径高可用且权限正确。

下表给出一个2节点Always On准备环境的示例参数，仅作教学参考，实际部署需根据业务与硬件调整：

四、为Always On准备集群环境

准备集群环境的核心步骤包括：安装故障转移集群功能、验证集群配置、创建集群、配置仲裁、调整集群参数。下面给出关键操作与判断依据。

首先，在每个节点上安装故障转移集群功能：

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

安装完成后，使用集群验证工具检查节点是否满足集群要求。验证应覆盖网络、存储、系统配置等。只有验证通过，才建议创建集群。创建集群的命令示例如下：

New-Cluster -Name SQLCLUSTER -Node SQLNODE01,SQLNODE02 -StaticAddress 10.0.2.100

创建后，配置仲裁为“节点与文件共享多数”：

Set-ClusterQuorum -NodeAndFileShareMajority \\FSW01\Witness

随后，建议调整以下集群参数以适配Always On：将“同一时间允许的故障数”保持默认或根据节点数调整；设置“集群服务”启动类型为自动；确认“可用性组”资源类型已注册。对于Always On，还需要在SQL Server中启用“Always On可用性组”功能，并确保SQL Server服务账户具有集群相关权限。

判断集群是否健康，可通过以下命令观察：

Get-ClusterNode
Get-ClusterQuorum
Get-ClusterResource

若节点状态为Up、仲裁配置正确、资源在线，则集群基础环境就绪。此时可以继续创建可用性组，并将副本加入集群角色。

完成上述配置后，集群环境即具备承载Always On可用性组的基础条件。后续创建可用性组时，集群角色会自动生成，监听器资源也会作为角色的一部分参与故障转移。理解仲裁与角色的关系，有助于在故障排查时快速定位是集群层问题还是SQL层问题。