企业官网建设流程全解析

简介：这份图文教程面向需要在 Windows Server 2019 环境下搭建高可用数据库的运维工程师与系统管理员，围绕 MSCS 故障转移群集与 SQL Server 2019 群集部署展开，解决单节点故障导致业务中断的问题。资源共 1 个 PDF 文件，压缩包约 4.94MB，文档共 71 页，以截图配文字的方式逐步讲解，涵盖域控制器搭建、节点服务器配置、心跳网卡与 DNS 设置、故障转移群集安装、SQL Server 2019 群集安装及运行测试等完整流程，并附有虚拟机三节点模拟环境的 IP 与主机名配置示例。目前已有 5502 人学习下载，适合希望掌握双机热备与群集排错思路的中高级读者对照实操，也可作为企业内部高可用架构落地的参考手册。

1. Windows Server 2019 双机热备与 SQL Server 2019 群集部署：为什么值得做，以及它到底在解决什么

生产库里最怕的不是慢查询，而是单点。一台物理机或虚拟机上的 SQL Server 2019 实例，只要宿主、存储、网卡、系统盘任意一环出问题，业务就整体停摆。Windows Server 2019 自带的 MSCS（Microsoft Cluster Service，故障转移群集）配合 SQL Server 2019 的 Always On 故障转移群集实例（FCI），做的就是把「单实例」变成「多节点共享一份数据、对外只暴露一个虚拟 IP 和虚拟网络名」的双机热备方案。客户端连接串不用改，节点挂了自动在另一台拉起，RTO 通常在一分钟级别，RPO 取决于共享存储本身。这套方案适合中小规模、预算有限、又要求数据库高可用的场景，也是很多运维从「会装 SQL Server」跨到「会做数据库高可用」的第一道门槛。下面按选型、环境、部署、验证、避坑的顺序，把能复现的步骤和参数讲透。

2. 部署前的选型与前置条件：MSCS 和 SQL Server 2019 FCI 到底怎么配

2.1 先分清 FCI 和 Always On 可用性组，别选错

很多人一上来就说「我要做双机热备」，但没分清两种形态。FCI（Failover Cluster Instance）是实例级高可用，两个节点共享同一份存储，同一时刻只有一个节点持有实例，故障时整个实例漂移过去，对外是同一个虚拟网络名和虚拟 IP。Always On 可用性组（AG）是数据库级，每个节点各自有独立存储，靠日志传输同步，可以读写分离。标题里写的是「MSCS 下 SQL Server 2019 群集部署」，指的就是 FCI 这条路。

选 FCI 的理由很直接：应用连接串完全不用动，共享存储保证数据只有一份，不存在同步延迟导致的数据分歧。代价是共享存储本身成了新的单点，所以生产上共享存储一般也要做 RAID 或双控。如果预算只够两台机器、没有共享存储，那应该考虑 AG 而不是 FCI，这是选型阶段最容易翻车的地方。

2.2 硬件、系统与网络的前置清单

在动手之前，把下面这些条件逐条确认，缺一条后面都会卡住。

网络规划上，我一般会分三个网段：业务网（客户端访问虚拟 IP）、心跳网（节点间私有通信）、存储网（iSCSI 流量）。心跳网不要和业务网共用，否则大流量查询会把心跳包挤掉，导致节点误判对方下线，触发不必要的故障转移，这是最典型的「玄学漂移」来源。

2.3 域账户和 DNS 记录的准备

MSCS 需要一个域账户来运行群集服务，SQL Server 2019 FCI 还需要一个独立的域账户跑 SQL 服务。建议提前建好两个账户，比如domain\clustersvc和domain\sqlsvc，密码设置成永不过期，避免某天密码到期导致群集服务起不来。

DNS 方面，群集的虚拟网络名（CNO，Cluster Name Object）和 SQL 的虚拟网络名（VNN）都需要在 DNS 里有对应记录，通常由群集服务自动注册。如果 DNS 是手动管理的，要提前留好 A 记录的位置，否则创建群集时会报「无法更新 DNS 记录」。

3. 搭建 MSCS 故障转移群集：从加域到验证的完整步骤

3.1 安装故障转移群集功能并配置 iSCSI 共享存储

两台节点分别执行下面的 PowerShell，安装群集和 iSCSI 发起程序功能。

# 在两台节点上分别执行 Install-WindowsFeature -Name Failover-Clustering, Multipath-IO -IncludeManagementTools Install-WindowsFeature -Name FS-iSCSITarget-Server -IncludeManagementTools # 仅存储服务器需要 # 启动 iSCSI 发起程序服务 Set-Service -Name MSiSCSI -StartupType Automatic Start-Service -Name MSiSCSI

逻辑说明：Failover-Clustering是 MSCS 的核心功能，Multipath-IO用于多路径存储，避免单条 iSCSI 链路故障。FS-iSCSITarget-Server只在你要把某台机器当存储服务器时才装，如果用的是独立 SAN 或 NAS，这一步跳过。

参数说明：-IncludeManagementTools会一并装上图形化管理工具，方便后面用cluadmin.msc排查。装完必须重启，否则群集服务无法注册。

存储侧，在 iSCSI 目标端划一个 LUN，比如 500GB，然后在两台节点上用iscsicpl.exe连接。连接时勾选「启用多路径」和「将此连接添加到收藏目标列表」，保证重启后自动重连。连上之后在磁盘管理里会看到一块「脱机」的磁盘，先不要初始化，等群集创建时由群集接管。

3.2 用 PowerShell 创建群集并加入第二节点

第一台节点上执行创建，第二台节点执行加入。

# 在节点1上创建群集 New-Cluster -Name SQLCLUSTER -Node Node1,Node2 -StaticAddress 10.10.1.100 -NoStorage # 验证群集状态 Get-Cluster -Name SQLCLUSTER | Format-List Name, Status, Nodes # 把共享磁盘加入群集 Get-ClusterAvailableDisk -Cluster SQLCLUSTER | Add-ClusterDisk

逻辑说明：New-Cluster一次性把两个节点都加进去，-StaticAddress指定群集的虚拟 IP，这个 IP 必须和业务网同网段且未被占用。-NoStorage表示先不自动纳管存储，等群集建好后再手动加，避免存储没准备好导致创建失败。

参数说明：-Name是群集的虚拟网络名，后面 SQL Server 安装时会用到。Get-ClusterAvailableDisk会列出所有对两个节点都可见、但还没被群集纳管的磁盘，Add-ClusterDisk把它们加进来。加进来之后磁盘会变成「群集磁盘」，在磁盘管理里显示为「保留」。

创建完成后，用Test-Cluster做一次验证，重点看存储、网络、系统配置三项有没有警告。存储的「磁盘仲裁」警告通常可以忽略，但网络的「只有一块网卡」警告必须处理，否则后面心跳会出问题。

3.3 配置群集仲裁和心跳网络

双节点群集默认用「节点多数」仲裁，但更稳的做法是加一个文件共享见证或磁盘见证。

# 查看当前仲裁配置 Get-ClusterQuorum -Cluster SQLCLUSTER # 设置磁盘见证（如果有共享磁盘） Set-ClusterQuorum -Cluster SQLCLUSTER -DiskWitness "Cluster Disk 1" # 或者设置文件共享见证 Set-ClusterQuorum -Cluster SQLCLUSTER -FileShareWitness "\\fileserver\witness"

逻辑说明：仲裁决定群集在节点失联时如何判断哪边是「多数派」。双节点场景下，如果没有见证，两个节点互相看不到对方时会同时认为自己是唯一存活节点，导致「脑裂」。加见证后，能联系到见证的节点获胜，另一方自动下线。

参数说明：-DiskWitness指定一块共享磁盘作为见证，这块盘不能用来存数据。-FileShareWitness指定一个网络共享路径，适合没有额外共享磁盘的场景。文件共享见证的路径必须对两个节点的计算机账户都有读写权限。

心跳网络方面，在群集管理器里把心跳网卡的「允许群集通信」勾上，业务网卡也勾上，但把心跳网卡的优先级调高。如果心跳网卡是独立网段，可以在网卡属性里取消「Microsoft 网络客户端」和「文件和打印机共享」，只保留「Internet 协议版本 4」，减少无关流量。

4. 在 MSCS 上安装 SQL Server 2019 群集实例：参数与顺序都不能错

4.1 安装前的账户与权限确认

SQL Server 2019 FCI 安装必须用域账户，且这个账户要对两个节点都有本地管理员权限（安装时临时需要，装完可以降权）。提前在 AD 里建好domain\sqlsvc，密码永不过期。

另外确认两件事：一是共享磁盘已经加入群集并且处于「联机」状态，二是群集的虚拟网络名和虚拟 IP 已经能 ping 通。如果这两条不满足，安装程序会在「群集网络名称」这一步直接报错。

4.2 用命令行执行静默安装

图形界面安装容易在「群集磁盘选择」那一步选错，我一般用命令行，参数明确、可复现。

# 在节点1上执行，安装 SQL Server 2019 FCI Setup.exe /Q /ACTION=InstallFailoverCluster /FEATURES=SQLENGINE,IS \ /INSTANCENAME=MSSQLSERVER /SQLSVCACCOUNT="domain\sqlsvc" /SQLSVCPASSWORD="YourPassword" \ /SQLSYSADMINACCOUNTS="domain\sqladmin" /AGTSVCACCOUNT="domain\sqlsvc" /AGTSVCPASSWORD="YourPassword" \ /FAILOVERCLUSTERNETWORKNAME="SQLVNN" /FAILOVERCLUSTERIPADDRESSES="IPv4;10.10.1.101;Cluster Network 1;255.255.255.0" \ /FAILOVERCLUSTERDISKS="Cluster Disk 2" /INSTALLSQLDATADIR="S:\MSSQL" \ /UPDATEENABLED=False /IACCEPTSQLSERVERLICENSETERMS

逻辑说明：/ACTION=InstallFailoverCluster告诉安装程序这是群集实例安装，不是独立实例。/FAILOVERCLUSTERNETWORKNAME是 SQL 对外暴露的虚拟网络名，客户端连接串里写的就是这个名字。/FAILOVERCLUSTERIPADDRESSES指定虚拟 IP，格式是「协议;IP;网络名;子网掩码」。

参数说明：/FAILOVERCLUSTERDISKS指定 SQL 数据要放在哪块群集磁盘上，这里填的是磁盘在群集里的资源名，不是盘符。/INSTALLSQLDATADIR是数据目录，建议单独放一块盘，不要和系统盘混用。/UPDATEENABLED=False关掉自动更新，避免安装过程中被 Windows Update 打断。

节点1装完后，在节点2上执行AddNode：

Setup.exe /Q /ACTION=AddNode /INSTANCENAME=MSSQLSERVER \ /SQLSVCACCOUNT="domain\sqlsvc" /SQLSVCPASSWORD="YourPassword" \ /AGTSVCACCOUNT="domain\sqlsvc" /AGTSVCPASSWORD="YourPassword" \ /IACCEPTSQLSERVERLICENSETERMS

逻辑说明：AddNode只装二进制文件和群集资源，不碰数据，所以速度比节点1快很多。执行前确认节点2能访问共享磁盘，且群集服务正在运行。

4.3 安装后的服务账户与依赖检查

装完后打开群集管理器，在「角色」里应该能看到一个「SQL Server（MSSQLSERVER）」角色，包含网络名称、IP 地址、磁盘、SQL Server 服务、SQL Agent 服务等资源。逐个检查依赖关系，特别是「SQL Server 服务」依赖「网络名称」和「磁盘」，如果依赖顺序错了，故障转移时会卡住。

服务账户方面，确认 SQL Server 和 SQL Agent 都用的是domain\sqlsvc，不要用 LocalSystem。用 LocalSystem 的话，故障转移后新节点上的服务账户权限可能不一致，导致实例起不来。

5. 故障转移验证与常见问题排查：别等生产出事才第一次切换

5.1 手动故障转移的完整验证流程

装完不验证，等于没做。我一般按下面的顺序做一次完整切换测试。

# 查看当前 SQL 角色在哪个节点 Get-ClusterGroup -Name "SQL Server (MSSQLSERVER)" | Format-List Name, OwnerNode, State # 手动把角色移到节点2 Move-ClusterGroup -Name "SQL Server (MSSQLSERVER)" -Node Node2 # 等待角色联机 Start-Sleep -Seconds 30 Get-ClusterGroup -Name "SQL Server (MSSQLSERVER)" | Format-List Name, OwnerNode, State

逻辑说明：Move-ClusterGroup会按依赖顺序依次把资源从节点1下线、在节点2上线。整个过程通常 30 到 60 秒。切换完成后，用sqlcmd连虚拟网络名SQLVNN执行SELECT @@SERVERNAME，确认返回的是群集实例名而不是某个节点名。

参数说明：-Node指定目标节点，必须是群集里的有效节点。如果切换卡在「联机挂起」，去事件查看器看「FailoverClustering」日志，通常是磁盘没释放或网络名称注册失败。

5.2 常见问题排查清单

现象：创建群集时报「无法访问共享磁盘」。原因：iSCSI 会话没建立，或者磁盘在两台节点上状态不一致（一台联机一台脱机）。 解决：在两台节点上分别打开iscsicpl.exe确认会话状态是「已连接」，然后在磁盘管理里把磁盘状态统一成「脱机」，再重新执行Add-ClusterDisk。

现象：SQL Server 安装到「群集磁盘选择」这一步，列表是空的。原因：共享磁盘还没加入群集，或者加入后没联机。 解决：在群集管理器里确认磁盘资源状态是「联机」，如果显示「脱机」，右键联机。如果磁盘根本没出现在群集里，用Get-ClusterAvailableDisk | Add-ClusterDisk加进去。

现象：故障转移后客户端连不上，报「找不到网络名」。原因：DNS 里 SQL 虚拟网络名的记录没更新，或者客户端 DNS 缓存没刷新。 解决：在 DNS 服务器上确认SQLVNN的 A 记录指向当前持有节点的 IP，然后在客户端执行ipconfig /flushdns。如果用的是 hosts 文件，记得同步改。

现象：群集日志里频繁出现「节点心跳丢失」。原因：心跳网卡和业务网卡混用，或者心跳网段有防火墙拦截。 解决：给心跳单独划一个网段，在群集管理器里把心跳网卡的「允许群集通信」勾上，业务网卡取消勾选。防火墙放行「Failover Clustering」的入站规则。

现象：SQL Server 服务在故障转移后启动失败，事件日志报「无法打开数据库文件」。原因：共享磁盘的盘符在新节点上变了，或者 SQL 服务账户对新节点上的磁盘没有权限。 解决：在群集管理器里确认磁盘资源的盘符和安装时一致，如果不一致，用cluster res "Cluster Disk 2" /priv DiskLetter=X:改回来。服务账户权限方面，把domain\sqlsvc加到新节点的本地管理员组，并授予数据目录的完全控制权限。

6. 进阶技巧：把切换时间压到 30 秒以内，以及我踩过的那些坑

默认配置下，SQL Server FCI 的故障转移时间在 60 到 90 秒之间，主要耗在三个地方：群集检测节点下线的超时、SQL 服务停止的等待、新节点上数据库恢复的时间。想把切换压到 30 秒以内，可以从下面几个参数入手。

第一，调整群集的「同一子网延迟」和「跨子网延迟」。在群集管理器的「网络」里，把心跳网络的「同一子网延迟」从默认的 1000ms 调到 500ms，「跨子网延迟」调到 1000ms。这样节点失联的判定更快，但不要调太低，否则网络抖动会误触发切换。

第二，SQL Server 服务资源里有个「LooksAlive」和「IsAlive」轮询间隔，默认分别是 5000ms 和 60000ms。可以在注册表HKLM\Cluster\Resources\<SQL Resource GUID>\Parameters下把LooksAlivePollInterval调到 3000，IsAlivePollInterval调到 30000。改完重启群集服务生效。

第三，数据库恢复时间取决于日志大小和检查点频率。把recovery interval设成 30 秒左右，让检查点更频繁，故障转移时需要前滚的日志更少。代价是正常运行时磁盘写入压力略增，SSD 存储上基本无感。

-- 在 SQL 实例上执行，把恢复间隔设为 30 秒 EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'recovery interval', 30; RECONFIGURE;

逻辑说明：recovery interval控制检查点之间的最大时间，值越小，故障恢复时需要重放的日志越少，切换越快。参数说明：单位是秒，默认 0 表示由 SQL Server 自动管理，设成 30 是手动指定。改完用SELECT * FROM sys.configurations WHERE name = 'recovery interval'确认生效。

我踩过最深的坑是心跳网卡和 iSCSI 网卡共用一块物理网卡。当时为了省网卡，把 iSCSI 流量和心跳都走同一块千兆网卡，结果备份任务一跑，心跳包延迟飙升，群集误判节点下线，半夜自动切换了两次。后来加了独立网卡，问题再没出现过。另一个坑是 SQL 服务账户密码到期，群集服务起不来，但错误日志只报「登录失败」，查了半天才想到是密码策略。现在我的习惯是：所有群集相关的域账户，密码永不过期，并且单独建一个 OU 管理，避免被全局密码策略覆盖。

这套方案值不值得做，取决于你的业务能不能接受一分钟以内的停机。如果能接受，FCI 是性价比最高的选择；如果不能接受，那要考虑 Always On 可用性组加只读副本，或者上云托管实例。但无论走哪条路，先把 MSCS 这套基础打牢，后面扩展都不会白费。希望帮到你。

本文还有配套的精品资源，点击获取