4. 部署前的环境准备

Always On 可用性组的部署失败，绝大多数并不是卡在“建组”那一步，而是卡在部署之前的环境准备上。可用性组依赖 Windows 故障转移集群（WSFC）、域身份验证、数据库镜像端点以及一系列版本与补丁约束，这些条件中任意一项不满足，后续的“新建可用性组向导”都会以看似无关的报错终止。因此，本节把环境准备拆成四条主线：操作系统与补丁、SQL Server 版本与实例配置、域账户与权限、防火墙与端点，并给出可执行的核对方式。

一、操作系统版本与补丁

Always On 可用性组要求所有副本节点必须处于同一个 WSFC 集群中，而 WSFC 对操作系统版本有硬性要求。工程上应遵循两条原则：版本一致、补丁一致。版本不一致（例如一个节点是 Windows Server 2019，另一个是 2022）虽然在某些情况下可以加入同一集群，但会带来集群功能级别、故障转移行为和后续升级路径的差异，属于应当避免的隐患。

补丁方面，重点不是“打没打补丁”，而是“所有节点是否打了同一批补丁”。集群节点的补丁级别不一致时，可能出现节点间通信正常但资源无法联机、或者故障转移后副本无法同步的现象。建议在部署前统一执行一次 Windows Update，并记录每台节点的 OS Version 与 Build Number。可用 PowerShell 快速采集：

# 在每台节点上执行，记录操作系统版本与内部版本号
Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion, OsBuildNumber

# 查看已安装的关键更新（示例：筛选最近安装的补丁）
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID, Description, InstalledOn

此外，WSFC 需要启用“故障转移群集”功能，并建议为集群配置独立的网络（心跳网络与业务网络分离）。如果使用云主机或虚拟化平台，还需确认虚拟化层支持集群所需的共享存储或存储副本方案。

二、SQL Server 版本与实例配置

SQL Server 版本决定了可用性组的能力边界。标准版从 SQL Server 2016 起支持“基本可用性组”，但限制为每个可用性组只能有一个数据库、两个副本（一个主副本和一个辅助副本），且不支持读取辅助副本、备份辅助副本等高级功能。企业版则支持多数据库、多副本、可读辅助副本、自动故障转移等完整能力。部署前必须明确业务对 RPO/RTO 和只读负载的要求，再决定版本。

实例配置层面，有几个容易被忽略但影响很大的点：

• 实例排序规则：同一可用性组内所有副本的实例排序规则必须一致，否则数据库无法加入可用性组。
• SQL Server 服务账户：建议使用域账户（或至少是同一域内的托管服务账户），避免使用本地系统账户导致跨节点权限不一致。
• 数据库恢复模式：参与可用性组的数据库必须为完整恢复模式，且必须先做一次完整备份，否则无法加入可用性组。
• 实例端口：默认 1433 可以保留，但若同一节点部署多个实例，需明确每个实例的 TCP 端口，后续端点配置会用到。

可用以下查询确认实例排序规则与版本：

SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion,
       SERVERPROPERTY('Edition') AS Edition,
       SERVERPROPERTY('Collation') AS InstanceCollation;

-- 确认待加入可用性组的数据库恢复模式
SELECT name, recovery_model_desc, state_desc
FROM sys.databases
WHERE name IN ('AGDB1','AGDB2');

三、域账户与权限

Always On 的很多操作需要跨节点身份验证，因此域账户规划是部署前必须完成的工作。通常需要准备三类账户：

• SQL Server 服务账户：每个节点上的 SQL Server 服务使用域账户运行，建议统一使用同一个域账户或同一组托管服务账户，便于权限统一。
• 集群服务账户：WSFC 的群集服务账户，用于集群资源管理。
• 部署与运维账户：执行可用性组创建、故障转移、备份等操作的 DBA 账户，需要具备相应权限。

权限方面，SQL Server 服务账户需要在每个节点上具备“作为服务登录”“锁定内存页”等本地策略权限；同时，在 SQL Server 实例内，服务账户需要被授予 CONNECT SQL、VIEW SERVER STATE 等权限。若使用可用性组侦听器，还需要在 DNS 中为侦听器名称预留记录，并确保域账户对该名称有创建权限。

四、防火墙与端点配置

可用性组依赖数据库镜像端点进行数据同步，端点默认使用 TCP 5022 端口。因此，必须在每台节点的防火墙中放行以下端口：

• TCP 5022：数据库镜像端点，用于副本间日志传输。
• TCP 1433（或实例实际端口）：SQL Server 数据库引擎，供客户端和侦听器访问。
• TCP 135 / 动态端口：WSFC 与远程管理所需，视集群配置而定。
• UDP 3343：集群心跳与节点通信。

端点配置本身也需要在 SQL Server 内完成。每个实例需要创建一个数据库镜像端点，并授予其他副本的服务账户 CONNECT 权限。示例脚本如下：

-- 在每个副本实例上执行，创建数据库镜像端点
CREATE ENDPOINT [Hadr_endpoint]
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (ROLE = ALL, AUTHENTICATION = WINDOWS NEGOTIATE);

-- 授予其他副本服务账户连接权限（示例域账户）
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DOMAIN\svc_sql_ag];

配置完成后，可用 telnet 节点名 5022 或 PowerShell 的 Test-NetConnection 验证端口连通性。若端口不通，优先检查防火墙规则、端点状态是否为 STARTED，以及服务账户是否具备端点连接权限。

五、部署前核对清单

把上述四条主线收敛成一份可执行的核对清单，部署前逐项确认，可以显著降低后续排障成本。下表给出的是示例字段，实际使用时可按现场规划替换节点名、账户名和端口。

环境准备的本质，是把“部署时可能失败的点”提前变成“部署前可验证的点”。操作系统与补丁保证集群能建起来，SQL Server 版本与实例配置保证可用性组能建起来，域账户与权限保证跨节点操作能通过，防火墙与端点保证数据能同步过去。四条主线全部通过后，再进入可用性组创建，成功率会高得多。