引言
在企业IT基础设施运维中，数据库服务器的稳定性直接关系到核心业务的连续性。许多中小型企业虽然购买了IT外包服务，但在应对SQL Server这类关键组件的硬件故障或计划内维护时，往往缺乏自动故障转移机制，导致停机时间过长。本文将以IT外包服务实施案例为背景，详细讲解如何为企业SQL Server环境部署Always On可用性组，实现高可用与负载均衡。
一、 场景背景与需求分析
假设某零售企业拥有核心ERP数据库，采用Microsoft SQL Server 2019 Enterprise Edition。当前架构为单节点主库，存在以下痛点：
- 单点故障风险：物理服务器主板损坏会导致业务中断。
- 备份压力：全量备份期间影响业务性能。
- 维护困难：打补丁或升级需停机窗口。
解决方案目标：利用两台Windows Server 2019虚拟机构建Always On可用性组，实现数据库级别的自动故障转移，并允许读操作分流至辅助副本。
二、 前置环境准备
在开始部署前，需确保基础环境满足以下条件。这一步骤是外包服务标准化运维的关键，常被忽略却至关重要。
1. 网络与DNS配置
两台服务器（Node1: SRV-SQL-01, Node2: SRV-SQL-02）必须位于同一域环境中（例如 domain.local）。需配置内部DNS记录，确保通过主机名可以互相解析，并且为可用性组监听器配置一个静态IP地址（如 192.168.10.20）。
2. 防火墙规则设置
SQL Server默认使用TCP 1433端口通信，而Always On监听器需要额外的动态端口或固定端口用于健康检测。建议在防火墙中开放以下规则：
- SQL Server 数据库引擎 (TCP 1433)
- SQL Server 浏览器 (UDP 1434)
- 自定义端口 (如 TCP 5022，用于端点通信)
3. 存储权限检查
确保用于存放数据库文件的共享文件夹路径一致，或者各自拥有独立的本地存储路径。本例采用独立本地存储以提升性能。
三、 详细部署步骤
步骤1：配置Windows故障转移集群（WSFC）
Always On依赖Windows Server故障转移集群作为底层基础设施。需在两台服务器上依次执行：
- 打开 服务器管理器 > 管理 > 添加角色和功能。
- 勾选 故障转移集群工具 和 故障转移集群。
- 安装完成后，打开 故障转移集群管理器。
- 右键集群名称，选择 创建集群。
- 运行集群验证向导，将SRV-SQL-01和SRV-SQL-02加入集群。
- 注意：若验证测试中有关于存储空间或网络延迟的警告，需根据具体环境调整，确保集群状态显示为“联机”。
步骤2：创建数据库镜像端点
这是旧版本SQL Server常用的方式，但在2012及以上版本中，推荐使用Always On内置的端点。若需手动配置，请在两台服务器上执行T-SQL：
CREATE ENDPOINT [Hadr_endpoint]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (
ROLE = ALL,
AUTHENTICATION = WINDOWS NEGOTIATE,
ENCRYPTION = REQUIRED ALGORITHM AES
);同时，需确保SQL Server服务账户对端点拥有CONNECT权限。
步骤3：创建可用性组
在SSMS（SQL Server Management Studio）中操作：
- 展开 可用性组 文件夹，右键选择 新建可用性组。
- 常规页面：输入可用性组名称（如 AG_RetailDB），选择故障转移模式为“自动”，并启用 强制人工故障转移（可选）。
- 副本页面：添加SRV-SQL-01（主副本）和SRV-SQL-02（辅助副本）。设置同步模式为 同步提交 以保证数据零丢失，故障转移模式为 自动。
- 端点页面：确认端点URL和端口一致（通常为TCP://服务器名:5022）。
- 侦听器页面：勾选 创建侦听器，输入侦听器名称（如 Listener-AG-Retail）和静态IP地址（192.168.10.20）。
步骤4：添加数据库
完成上述配置后，向导会提示初始化副本。此时：
- 在主副本服务器上，右键需要加入高可用的数据库（如 RetailDB）。
- 选择 任务 > 加入可用性组。
- 选择之前创建的AG，系统将自动在辅助副本上创建数据库的空壳。
- 等待初始同步完成，状态变为 已同步。
四、 故障切换测试与验证
部署完成后，必须进行实际故障模拟以验证高可用性。这是IT外包服务交付验收的核心环节。
1. 模拟主节点故障
在辅助副本（SRV-SQL-02）上监控可用性组状态。随后，在SRV-SQL-01上断开网络连接或停止SQL Server服务。观察SSMS中的可用性组视图，主副本状态应变为“不可用”，辅助副本状态应变为“主”。此过程通常应在10-30秒内完成。
2. 应用程序连接测试
修改ERP系统的数据库连接字符串，将数据源指向可用性组监听器的IP地址（192.168.10.20）而非具体服务器IP。应用重启后，尝试执行查询。即使原主节点宕机，应用程序也应能无缝连接到新的主节点（原辅助节点），实现透明故障转移。
3. 手动故障转移演练
在主节点恢复在线后，可通过SSMS右键可用性组选择“故障转移”，将主角色手动切换回SRV-SQL-01。这验证了维护窗口内的平滑迁移能力。
五、 标准化运维建议
为确保长期稳定运行，IT外包团队应建立以下规范：
- 监控告警：配置SQL Server代理作业或第三方监控工具，当可用性组延迟超过阈值或副本断开时发送警报。
- 备份策略：仅在辅助副本上执行全量备份和日志备份，避免影响主节点性能。
- 日志保留：定期清理Windows事件日志和SQL错误日志，防止磁盘空间耗尽导致集群节点卸载。
- 文档更新：记录监听器IP、证书信息（若使用Kerberos约束委派）及应急联络人，纳入知识库。
结语
通过部署Always On可用性组，企业不仅解决了数据库单点故障问题，还提升了整体IT架构的健壮性。对于IT外包服务商而言，掌握此类高可用技术的标准化实施流程，是体现专业服务价值、增强客户粘性的关键能力。
