SQL Server高可用之Always On故障转移群集实例 (FCI) 配置

ZhangQi

SQL Server 的 Always On 实际上是一个品牌家族，它主要包含两种完全不同的高可用性技术：Always On 可用性组 (Availability Groups, AG) 和 Always On 故障转移群集实例 (Failover Cluster Instances, FCI)。

虽然它们都依赖 Windows 故障转移群集 (WSFC) 服务，但在架构和工作原理上有本质区别：

1. Always On 故障转移群集实例 (FCI)

FCI 是实例级别的高可用性方案。它通常基于“共享存储”架构。

- 核心原理：多个节点共同管理同一个实例。SQL Server 的数据文件（mdf/ldf）存放在外部共享存储（如 SAN、存储服务器）上。
- 切换方式：当主节点宕机，群集服务会在备用节点上重新启动 SQL Server 服务并接管共享磁盘。
- 优点：保护整个实例（包括所有的系统数据库、登录名、作业等）。
- 缺点：存储存在单点故障风险（除非存储本身有冗余）；备用节点处于闲置状态，无法分担读取压力。

2. Always On 可用性组 (AG)

AG 是数据库级别的高可用性方案。它是目前更为主流和灵活的选择。

- 核心原理：每个节点都有自己独立的数据副本（非共享存储）。通过数据库日志传输的方式，将主库的数据同步到从库。
- 切换方式：如果主库发生故障，群集会自动将其中一个从库切换为新的主库。
- 优点：
        • 读写分离：从库可以配置为“只读”，分担主库查询压力。
        • 无单点存储风险：每个节点都有本地副本。
        • 灵活性：可以只针对核心业务数据库做高可用，而不必针对整个实例。
- 缺点：无法自动同步实例级别的元数据（如作业、登录名），需要手动或通过脚本同步。

对比总结



简单理解：
FCI 像是“几个人轮流开同一辆车”，车坏了大家都走不了。
AG 像是“每个人都有自己的车”，并且通过对讲机实时同步位置，一辆车坏了，大家换另一辆继续走。

在现代的企业环境下，如果对读取性能有要求，通常会优先考虑 AG；如果应用非常依赖复杂的作业和系统登录名，且有成熟的存储方案，FCI依然是非常稳健的选择。

下面对Always On故障转移群集实例 (Failover Cluster Instances, FCI)的搭建进行演示

一.准备工作

搭建有域的，一主两从的环境（这里准备四台机器）

192.168.133.180：域控制器 (Domain Controller)        负责管理域环境（AD）、DNS 解析和集群服务账号，同时共享存储(iSCSI Target)也放在这里，服务器版本为 Windows Server 2022
192.168.133.181（私有IP:10.10.0.181）：SQL Server 主节点，作为 Primary Replica，服务器版本为 Windows Server 2019，数据库版本为 SQL Server 2019
192.168.133.182（私有IP:10.10.0.182）：SQL Server 从节点 1，作为 Secondary Replica，服务器版本为 Windows Server 2019，数据库版本为 SQL Server 2019
192.168.133.183（私有IP:10.10.0.183）：SQL Server 从节点 2，作为 Secondary Replica，服务器版本为 Windows Server 2019，数据库版本为 SQL Server 2019

集群名称及VIP地址：SQL_CLUSTER/192.168.133.184

SQL Server群集 IP:192.168.133.185

网关：192.168.133.2

需要先关闭每个节点的防火墙，禁用自动更新，并且三个节点都需要配置两个网卡（一个公共网卡一个私有网卡）

二.配置域控

同可用性组配置，详见：http://bbs.cqsztech.com/forum.php?mod=viewthread&tid=33325

三.设置集群节点

同可用性组配置，详见：http://bbs.cqsztech.com/forum.php?mod=viewthread&tid=33325

四.设置故障转移集群

同可用性组配置，详见：http://bbs.cqsztech.com/forum.php?mod=viewthread&tid=33325

五.在域控上配置共享存储 (iSCSI Target)

域控服务器上执行以下操作，将其模拟为一台 SAN 存储：

安装角色：打开“服务器管理器” -> “添加角色和功能” -> 安装 “文件和存储服务” 下的 “iSCSI 目标服务器”。













创建虚拟磁盘：

在服务器管理器左侧点击“文件和存储服务” -> “iSCSI”，选择任务 -> 新建 iSCSI 虚拟磁盘。





创建两个盘：一个 仲裁盘 (Quorum)（1G 即可），一个 数据盘 (Data)（根据需求分配，这里选择20G）。

先创建仲裁盘











在分配iSCSI 目标时，将 SQL01、SQL02、SQL03 的IP全部加入访问列表，确保三台节点都有权访问这两个虚拟磁盘。







点击创建





接着创建数据盘





加入创建好的目标







结果如下所示



六.节点识别共享磁盘

在 SQL01、SQL02、SQL03 上分别执行：

1. 连接存储：

搜索并打开“iSCSI 发起程序”。





在“目标”栏输入域控的 IP，点击“快速连接”。





2.联机与初始化（仅在 SQL01 执行一次）：

在 SQL01 的“磁盘管理”中，你会看到两个新磁盘。



将它们改为“联机”，初始化为 GPT 格式，并格式化为 NTFS（分配盘符，例如 F 盘和 G 盘）。



3.其他节点刷新：

在 SQL02 和 SQL03 的“磁盘管理”中，将这两个磁盘改为“联机”即可，不需要重复格式化。





4.加入群集磁盘：

在 SQL01 上打开“故障转移群集管理器” -> “存储” -> “磁盘”，点击“添加磁盘”，将这两块盘加入群集池。





添加成功



七.设置磁盘见证（指定仲裁盘）

群集现在有 3 个节点（奇数），理论上不强制需要仲裁盘，但为了架构的稳健性（防止出现 2 节点宕机），建议还是配上。

在“故障转移群集管理器”中，右键点击群集名称，选择更多操作 -> 配置群集仲裁设置。





选择 选择仲裁见证 -> 配置磁盘见证。





只勾选那块1GB 的小盘。





配置成功



此时该盘已经指派给“仲裁中的磁盘见证”。



八.安装 SQL Server FCI

这是与 AG 最大的区别点。

1. 在 SQL01 上安装（创建集群）：

使用域用户登录windows，运行安装程序，选择左侧的“安装”选项卡。

点击：“新的 SQL Server 故障转移群集安装”。













推荐选择必要的功能，如下所示，也可以全选，但会占用较大的存储空间：

- 数据库引擎服务：SQL Server复制（会自动勾选全文和语义提取搜索、Data Quality Services）
- 客户端工具连接   
- 客户端工具向后兼容性
- 客户端工具 SDK
- SQL 客户端连接 SDK



群集网络名称：输入 SQL 虚拟服务的名称（如 SQLCLUSTER）









填写之前在域控中创建好的“域用户”账号和密码。





可以看见，数据目录自动划在了共享存储盘上



点击开始安装



安装完成



2. 在 SQL02 和 SQL03 上安装（加入节点）：

使用域用户登录windows，运行安装程序，点击“安装”。

点击：“向 SQL Server 故障转移群集添加节点”。



向导会自动识别出 SQL01 创建的集群，只需按提示完成安装，这里以 SQL02 为例进行演示（一台一台的安装，不要同时安装）















填写正确的域用户密码





安装完成



九.验证与测试

1.查看资源控制权：

打开“故障转移群集管理器” -> “角色”。

应该能看到 SQL Server 角色。查看它目前处于哪个节点（比如 SQL01）。



2.手动切换测试：

右键点击 SQL Server 角色 -> “移动” -> “选择节点” -> 选 SQL02。

观察 SQL 服务是否在 SQL01 停止并在 SQL02 成功启动。





注意：此时配置管理器（Config Manager）显示“已停止”且打不开，这是 FCI 的正常现象，不是故障。 这是因为在 FCI 模式下，SQL Server 服务的控制权已经从“SQL 配置管理器”移交给了 “Windows 故障转移群集管理器”。在群集环境中，SQL 服务是由群集服务（Cluster Service）根据资源健康状况来自动启停的。如果你在本地强行点“启动”，会和群集的仲裁机制冲突，所以它通常会显示停止且操作受限。



3.连接验证：

使用 SSMS 客户端，连接地址填写群集网络名称（如 SQLCLUSTER），而不是物理机名。

无论服务漂移到哪个节点，都应该能正常连接。





连接成功