简介面向Windows Server 2019环境下SQL Server 2019群集部署需求的图文指南系统讲解基于MSCS双机热备的完整落地过程。资源共1个PDF文件约4.94MB内含71页详细步骤覆盖域控制器搭建、节点服务器IP与心跳网卡配置、故障转移群集创建以及SQL Server故障转移群集安装与验证等环节。内容以实际环境为背景给出明确的IP规划、计算机名和DNS设置并配有截图与操作提示可有效降低初学者对群集概念和配置流程的理解门槛。目前已有5503人学习下载适合需要搭建高可用数据库环境或正在备考相关认证的运维、DBA及系统架构师参考。1. 双机热备(MSCS)下Sql Server 2019群集部署这到底解决什么问题业务系统的数据库一旦宕机最坏的情况不是数据丢失而是你在凌晨被电话叫醒然后花半小时手动把服务拉起来。双机热备要解决的就是这个不可用时间窗口Windows Server 2019自带的故障转移群集MSCS配合Sql Server 2019的故障转移群集实例能在节点宕机后几十秒内把SQL服务自动切到另一台服务器。注意这里不是跑两套独立SQL实例而是同一份共享存储、同一个实例标识由群集决定它在哪台机器上存活。这个方案适合对连续性要求高的中小业务系统下文按部署顺序讲清从域环境、共享存储到群集创建和SQL安装的每个步骤以及那些不亲自踩一遍很难发现的坑。2. 部署前的三张图纸域环境、共享存储与网络规划MSCS群集部署最折磨人的往往不是安装那一步而是前期条件没想清楚。双节点Windows Server 2019都装好了SQL安装包也准备好了结果集群验证连着报错回过头来才发现域没加、存储没共享、心跳网段和业务网段混在一起。所以先别急着点安装向导把下面三张图画清楚。2.1 群集对Active Directory的依赖域账号、服务账号与DNS动态更新故障转移群集从Windows Server 2008开始就要求所有节点必须加入Active Directory域域控版本可以是Windows Server 2016或2019。这背后是Kerberos身份验证群集网络名称Cluster Network Name在故障转移时会重新绑定到新节点DNS里的A记录必须能动态更新客户端才能通过同一个名字找到当前主机。没有域这个过程根本走不通。准备工作至少包含三步第一两台Windows Server 2019节点加域并重启确认系统属性里的域和完整计算机名正确显示第二准备两个域账号——一个有本地管理员权限的部署账号比如sqladmin以及SQL Server服务专用的低权限域账号比如svc_sql第三确认域的DNS区域允许安全动态更新。默认安装的AD DS自带这个配置但如果你在企业已有DNS上做委派要额外检查。一个容易被忽略的细节是SQL Server服务的域账号密码不能随便改也不能启用用户下次登录时须更改密码。群集服务本身有自己的机器账号而SQL Server 2019故障转移群集实例会将服务账号、sqlservr.exe进程、加密密钥打包成一个资源组账号失效或密码过期都会导致资源无法联机。把运维手册里写上修改svc_sql密码必须走群集账号更新流程这能帮你省掉几次半夜救火。2.2 共享存储的两种落地方式与磁盘规划iSCSI Target与真实盘柜共享存储是双机热备的核心约束两块磁盘必须能被两个节点同时看到但同一时刻只有一个节点能读写。生产环境建议使用双控制器盘柜或企业级SAN通过FC或iSCSI划两个LUN出来——一个做仲裁见证盘一个做SQL数据盘测试环境常见做法是用一台独立服务器搭Windows iSCSI Target把虚拟磁盘分别映射给两个节点。两块磁盘的规划建议如下磁盘用途建议容量文件系统说明仲裁磁盘1 GB – 5 GBNTFS存放群集投票和配置变更记录不能放业务数据SQL 数据盘按业务量评估NTFS推荐 64K 簇存放数据文件、日志文件也可以拆成两块盘仲裁盘是最容易翻车的地方。群集在节点失联后需要根据投票决定哪个部分存活仲裁盘的租约Lease超时机制会触发故障转移如果把数据库文件、日志文件甚至tempdb都塞进仲裁盘一旦磁盘IO被业务拖垮整个群集性能会受到直接影响。还有一点值得注意SQL Server数据库文件所在的盘符不要和仲裁盘混用安装SQL群集实例时向导会要求你为每个SQL资源组勾选一块盘勾错了后面SQL资源联机会报磁盘无效。2.3 网络规划业务网、心跳网、存储网的边界与防火墙例外群集节点之间至少要有三条逻辑网络通道业务网络客户端访问SQL的虚拟IP所在网段、心跳网络群集节点通信和租约续签、存储网络如果走iSCSI建议单独隔离。我常用的规划表是这样网络名称网段示例节点1 IP节点2 IP群集虚拟IP业务网192.168.100.0/24192.168.100.11192.168.100.12192.168.100.200心跳网10.10.10.0/2410.10.10.1110.10.10.12无存储网iSCSI192.168.200.0/24192.168.200.11192.168.200.12无心跳网卡有个硬性要求不配置网关和DNS并且节点的防火墙必须放行故障转移群集规则。Windows Server 2019安装故障转移群集功能时会自动创建对应的防火墙规则但前提是网络位置被识别为域配置文件如果节点加入域后网卡显示为公用网络PowerShell里把它强制设为域类别# 先看当前网卡的 NetworkCategory 是否为 DomainAuthenticated Get-NetConnectionProfile # 把心跳网卡假设名称为“以太网2”设为域网络 Set-NetConnectionProfile -InterfaceAlias 以太网2 -NetworkCategory DomainAuthenticated这里的参数说明-InterfaceAlias指定的是操作系统里的网卡名别和物理网口编号搞混DomainAuthenticated是域网络类别在PowerShell里的枚举值设置后故障转移群集的防火墙规则才会生效。如果一块网卡上同时配置了业务IP和心跳IP群集验证会报网络绑定失败因为群集不允许同一物理网卡承载两种角色。3. 搭建故障转移群集角色安装、验证与创建命令这一章把Windows Server 2019环境从两台普通服务器变成一台群集主机。核心命令就三条但每一条后面都有值得细说的参数和行为照着跑能少走弯路。3.1 在两个节点上安装故障转移群集功能不要在图形界面里添加角色和功能一路点到底先用PowerShell确认目标机器的状态再执行安装这样能避免遗漏管理工具。在两台节点上分别执行# 检查故障转移群集功能当前的安装状态 Get-WindowsFeature -Name Failover-Clustering | Select-Object Name, InstallState第一次执行时InstallState一般是Available接着安装# 安装故障转移群集功能并包含管理工具 Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools-IncludeManagementTools这个参数非常实用它会顺带安装故障转移群集管理器MMC和群集PowerShell模块避免在图形界面里再翻一遍。安装完成后Get-WindowsFeature的InstallState会变成Installed。注意这个功能只需要在SQL Server节点上安装域控上不需要装。3.2 用Test-Cluster做部署前验证关注网络、存储和系统配置三类报告创建群集前必须先运行验证向导这是微软官方推荐也是排查问题最快的路径。验证会检查网络通信、存储访问、系统配置、磁盘仲裁能力等十几个子项任何Fail级别的错误都会阻挡群集创建。命令# 对两个节点做完整验证并把报告输出到指定路径 Test-Cluster -Node SQL01, SQL02 -Include Storage, Network, System Configuration -ReportFilePath C:\ClusterTests-Include参数可以按需裁剪验证范围。第一次跑建议把三组都包含Storage一项会检查两个节点对同一磁盘的读写是否正常Network会检查网卡绑定、IP配置和节点间通联。报告生成后用浏览器打开C:\ClusterTests下的HTML文件逐条看重点关注两类问题IP地址冲突两个节点用了同网段的IP导致心跳无法隔离和磁盘无法被验证通常是iSCSI发起程序没在另一个节点登录。验证报告里出现Warning不一定会阻止创建但像DNS后缀不一致这类Warning建议在创建前解决掉否则群集网络名称注册可能出现诡异现象。3.3 创建群集与配置仲裁New-Cluster与Set-ClusterQuorum验证通过后创建群集本身只有一条命令。我习惯先加-NoStorage参数把存储排除在外等群集管理界面起来之后再把共享磁盘手工添加进去这样可以避免系统自动把第一块共享盘当作仲裁盘造成数据盘和见证盘混用# 创建名为SQLCLU的群集两个节点为SQL01、SQL02指定管理IP New-Cluster -Name SQLCLU -Node SQL01, SQL02 -NoStorage -StaticAddress 192.168.100.200执行后观察输出群集名称会尝试在DNS注册。如果网络名称联机失败八成是DNS动态更新被拒绝了转到DNS服务器上检查安全动态更新设置。接下来在故障转移群集管理器里把共享磁盘加入群集# 查看当前可供群集使用的磁盘 Get-ClusterAvailableDisk # 将仲裁盘设为节点与磁盘多数仲裁模式 Set-ClusterQuorum -NodeAndDiskMajority Cluster Disk 1要从Get-ClusterAvailableDisk的输出里确认哪一块是仲裁盘、哪一块是数据盘然后把仲裁盘设置为见证盘。Windows Server 2019默认启用动态仲裁它允许群集在没有多数节点在线时维持运行但在双节点的MSCS场景中磁盘见证仍然是最稳妥的选择——它保证只要一块仲裁盘可达整个群集就能维持合法状态。4. Sql Server 2019群集实例部署从第一个节点到第二个节点的完整操作群集就绪后SQL Server 2019的部署思路和单机安装完全不同在第一个节点执行新建SQL Server故障转移群集安装在第二个节点执行添加到SQL Server故障转移群集。流程看似没差多少但几个关键界面选错会让整个实例无法故障转移。4.1 安装前的账号权限与安装介质准备SQL Server 2019故障转移群集实例FCI要求所有节点上的SQL服务使用同一个域账号。建议新建一个svc_sql的域用户密码设为永不过期并赋予以下权限在群集节点本地的Administrators组中在SQL Server安装期间被授予作为服务登录权限。第二项权限安装向导通常会自动配置但如果你的域有安全基线策略锁定了这些用户权限需要在域策略里提前放开。安装介质方面从SQL Server 2019的官方评估中心下载的是Evaluation版180天到期生产环境建议用批量授权渠道的ISO可以是Standard或Enterprise。注意两个节点必须从同一位置的介质安装不要一个节点用中文版、另一个节点用英文版版本不匹配会导致添加节点时校验不通过。也可以先把介质解压到共享路径两个节点都从该路径运行setup.exe。4.2 在第一个节点执行新建SQL Server故障转移群集安装在SQL01上运行setup.exe进入SQL Server安装中心后选择新建SQL Server故障转移群集安装。安装向导会先执行一轮规则检查重点确认Windows群集服务正在运行、所有节点能访问共享磁盘。之后会依次经过这些关键页面功能选择数据库引擎服务是必选如果业务需要集成服务或全文检索也要确保后续添加节点时勾选相同的功能。实例配置实例名称可以留默认MSSQLSERVER也可以命名实例比如SQLFCI。这里输入的SQL Server网络名称是客户端连接时用的名字和Windows群集名称不同。比如Windows群集叫SQLCLUSQL网络名称可以叫SQLFCI01。群集磁盘选择向导会列出当前群集里可用的磁盘这里只勾选SQL数据盘不能勾仲裁盘。群集网络配置输入SQL虚拟IP地址。如果只有一个业务网段只需填一个IP如果有多子网每个子网都需要一个IP。服务器配置为SQL Server数据库引擎、SQL Server代理等服务的账号填入svc_sql域账号和密码。在服务器配置这一步账号的格式必须是域名\svc_sql不能写SQL01\svc_sql这样的本地账号。SQL Server服务启动时需要在群集资源组内移动本地账号无法在其他节点登录。安装向导还会要求为svc_sql设置排序规则和SQL Server管理员这两项保持默认或按企业规范设置即可。4.3 在第二个节点执行添加到SQL Server故障转移群集第一个节点安装完成后SQL Server服务会作为群集资源在SQLCLU群集中注册。此时Windows群集可能把节点SQL01识别为所有者但SQL01不可用时它还不能直接切到SQL02因为SQL02上还没有安装SQL二进制的副本。这就是为什么必须继续在SQL02上运行安装程序在SQL02上运行setup.exe在SQL Server安装中心选择将节点添加到SQL Server故障转移群集。向导只需要提供实例名称并确认svc_sql账号的密码它会自动检测到现有群集实例并复制二进制文件。添加完成之后打开故障转移群集管理器在角色里应该能看到类似SQL Server (SQLFCI01)或SQL Server (MSSQLSERVER)的资源组里面包含SQL Network Name、SQL IP Address、SQL Server、SQL Agent等资源。添加节点时常见的失败原因是两个节点的Windows更新版本不一致。SQL Server 2019要求所有节点具有相同的Service Pack和累积更新级别否则添加节点界面会直接报版本不匹配。如果企业补丁策略允许差异最好在集群验证时就把Update Level作为检查项。4.4 把MSDTC并入群集分布式事务业务的必选项如果业务没有用到分布式事务这一步可以跳过但只要涉及跨库事务或者链接服务器、队列等场景就必须在故障转移群集管理器里单独创建分布式事务协调器(MSDTC)角色否则分布式事务的记录文件没有地方写事务会随机报MSDTC不可用。操作路径在故障转移群集管理器中右键角色→配置角色→选择分布式事务协调器然后分配一个网络名称、一个虚拟IP并指定仲裁盘作为MSDTC的磁盘资源。MSDTC角色创建后SQL Server会优先使用群集化的MSDTC服务。这一步在图形界面操作即可不用写代码但值得记录在部署文档里方便日后验证。创建完成后做一次快速验证在任意节点上用Services.msc查看Distributed Transaction Coordinator服务的状态应该是已启动并且注册表项HKLM\SOFTWARE\Microsoft\MSDTC\Security里的NetworkDtcAccess值为1。如果服务没有使用群集角色故障转移后分布式事务状态会丢这是比SQL资源本身更隐蔽的故障点。5. 避坑Sql Server双机热备部署中的5个经典故障这一章是我在实际部署中被反复折磨过的几个场景把现象、原因和解决办法写在下面。每一条都不是偶然故障而是架构级的问题遇到时按顺序排查能节省大量时间。5.1 群集验证报网络错误心跳网卡与业务网卡配置在同一网段现象运行Test-Cluster时Network项报节点间通信失败或者验证报告提示两块网卡绑定到了同一个子网。原因群集要求每种网络角色至少有一条独立物理链路。如果心跳网卡配了192.168.100.x的地址和业务网卡同网段群集无法区分业务流量和心跳流量会认为通信路径存在环路。解决把心跳网段改到独立网段比如10.10.10.0/24心跳网卡不配网关和DNS。改完之后在两节点之间用Test-NetConnection 10.10.10.12 -Port 445验证SMB端口通联。防火墙如果启用了严格策略还要确认故障转移群集入站规则已启用。这块是双机热备里最典型的配置没问题但网络不通我每次都先查网卡再查防火墙顺序不能反。5.2 共享磁盘在可用存储里看不到磁盘被当成普通本地磁盘接管了现象故障转移群集管理器→存储→磁盘里是空的但在服务器管理器的磁盘管理里能看到共享盘而且带了一个盘符比如E:。原因在创建群集或安装iSCSI连接后某个节点提前把共享磁盘做了联机格式化分配盘符的操作Windows就把这个LUN当成本地磁盘接管群集数据库里根本看不到它的SCSI保留信息。解决在磁盘管理里把共享盘的所有分区和盘符删除右键磁盘选择脱机然后回到故障转移群集管理器的存储→磁盘里点击显示可用存储右键添加磁盘。添加成功后磁盘管理里的联机状态由群集接管不再手工干预。这块还有个血泪教训不要在两个节点上分别对同一块iSCSI盘执行联机并格式化没有共享文件系统保护时两边的写入会直接覆盖数据。5.3 DNS动态更新被拒绝故障转移后客户端连不上SQL现象手动切换或故障转移后客户端仍然用旧的SQL虚拟IP连接或者SQL网络名称SQLFCI01在局域网内解析不到。原因SQL Server故障转移群集实例的虚拟网络名称在切换时会重新注册DNS A记录如果DNS区域设置成不允许动态更新或群集节点的DNS后缀和区域不匹配例如节点名为SQL01.lab.local但DNS区域是corp.local注册就会失败。解决在DNS管理器中确认承载SQL网络名称的DNS区域允许安全动态更新如果企业安全策略不允许也可以手工创建一条A记录指向SQL虚拟IP并将SQL网络名称的注册行为改为不注册。但手工记录在故障转移场景下需要你自己改DNS自动化程度低。另外在群集资源里检查SQL Network Name的HostRecordTTL值一般设置为300秒5分钟避免故障转移后客户端还抱着旧TTL不放。5.4 SQL Server资源反复启动失败服务账号没有共享盘权限现象故障转移群集管理器里SQL Server (MSSQLSERVER)资源每次联机几秒后又回到失败状态事件日志里报服务未及时响应或超时。原因SQL Server服务账号svc_sql对SQL数据盘或仲裁盘没有NTFS权限或者服务账号没被加入节点本地管理员组。安装向导在磁盘上创建数据目录时需要写权限群集在把SQL资源切到另一节点时也需要读仲裁盘两边缺一都起不来。解决在ADUC中确认svc_sql属于Domain Users并加入两台节点的本地Administrators组然后在数据盘上右键属性→安全→添加svc_sql为完全控制。如果磁盘权限模板是企业统一下发的排查时优先看这条。也可以在群集管理器里点击SQL Server资源查看其依赖列表确认它同时依赖SQL网络名称和SQL IP地址。5.5 群集仲裁盘与数据盘混用磁盘满了导致群集集体脱机现象某天磁盘空间告警检查发现仲裁盘和数据盘被格式化成了同一个卷业务数据和群集配置混在一起最后仲裁盘空间满了群集进入仲裁丢失状态。原因我在2.2节就强调过仲裁盘和数据盘必须分离但实际落地时有人图省事把一块LUN格式化成多个分区或直接把仲裁卷放到数据盘下导致群集心跳记录在业务高IO时被拖垮。解决重新规划LUN分配仲裁盘独立使用1GB-5GB的LUN数据盘独立使用大容量LUN。如果已经部署了但想修复需要先停止SQL资源用Set-ClusterQuorum重新指定见证盘再把数据文件迁移到独立磁盘。整个过程建议维护窗口操作因为动仲裁盘相当于把群集推倒重配。6. 最后一项验证与日常维护让双机热备真正在需要时能切换群集部署完成SQL双机热备看起来在跑但千万别急着给业务开验收报告。我把最后这部分拆成一个验证动作和一个运维习惯。6.1 手工切换与回归验证的完整操作每年至少做两次故障转移演练手工切到备用节点再切回来验证业务连接是否自动恢复。命令如下# 查看当前SQL资源组在哪台节点上 Get-ClusterGroup -Name SQL Server (MSSQLSERVER) | Select-Object Name, OwnerNode, State # 把SQL资源组手工切换到SQL02 Move-ClusterGroup -Name SQL Server (MSSQLSERVER) -Node SQL02执行切换后等待群集把资源全部联机再用客户端连接字符串测试 先用Test-NetConnection SQLFCI01 -Port 1433确认端口在线再用SQL Server Management Studio登录执行一条简单的SELECT SERVERNAME确认返回的是群集实例名而不是节点名。如果业务有写入量建议在切换前后对比表里的计数验证数据一致性。回切用同样的Move-ClusterGroup命令切回SQL01即可。6.2 日常运维要盯的三个日志位置群集故障转移不是随机玄学背后都有日志线索。第一个是事件查看器Windows日志→系统筛选来源为FailoverClustering的事件群集状态变更都会记录在这里第二个是故障转移群集管理器里右键群集→查看诊断信息导出群集日志路径默认在C:\Windows\Cluster\Reports第三个是SQL Server自身的ERRORLOG默认目录在SQL数据盘的\MSSQL\Log下。切换后第一件事先看SQL错误日志里有没有IO超时和缓存初始化失败记录这决定了切换是否真的干净。我给自己定的规矩是每次部署完双机热备都必须挑一个周末的维护窗口把备节点主动宕机一次让群集自己完成切换。第一次做的时候我连SQL网络名称都不知道该按哪个顺序重启后来演练多了才摸清套路——故障转移的瞬间旧节点正在写的日志文件没有正常关闭SQL实例在新节点启动时要经历一个前滚/回滚的恢复周期切换时间长短取决于事务日志里未提交事务的规模这也是RTO的主要构成。希望这一整套流程能帮你在自己的Windows Server 2019环境中把Sql Server 2019群集稳稳跑起来。本文还有配套的精品资源点击获取
