无停机迁移SQL故障转移集群：实用指南
我们使用滚动节点替换策略将运行中的SQL故障转移集群迁移到新硬件——零停机、完整验证且无应用程序中断。
当您的SQL Server故障转移集群运行在老化硬件或旧操作系统上时，迁移到现代环境而不中断生产可能会令人望而生畏。我们的团队必须将实时SQL集群迁移到运行Windows Server 2022的新服务器，后端为HPE SAN，同时保持依赖它的应用程序愉快且不间断。以下是我们如何完成迁移以及沿途学到的经验。
SQL停机在许多企业中不仅是轻微中断，而是完全阻塞。报告管道失败。ERP系统锁定。甚至简单的面向用户门户也可能陷入黑洞。我们无法承受这种连锁反应，这就是为什么这次迁移必须无缝进行。
我们还面临业务压力，要求在高峰运营时间最小化任何停机风险。这增加了额外的规划、沟通和回滚验证层。我们的利益相关者——尤其是财务和合规——需要保证服务不会中断。
为什么我们必须迁移
我们有几个原因：
- 原始节点已使用五年，保修即将到期。
- 合规团队标记操作系统版本（Windows Server 2019）接近生命周期结束。
- 我们希望清理导致偶尔故障转移延迟的遗留配置决策。
如果您在基础设施领域工作过，您知道这样的升级很少是直截了当的——尤其是关键SQL工作负载依赖其上。
我们的设置（迁移前）
- 2节点主动-被动SQL Server 2019集群
- 托管在Windows Server 2019上
- 后端：带有多路径I/O的HPE SAN
- 通过DNS设置集群监听器
- 混合.NET和报告工具24/7访问集群
计划是滚动加入两个运行Windows Server 2022的新节点，缓慢移动一切，并在无服务中断的情况下停用旧节点。
我们还与网络和存储团队密切合作，在启动任何操作之前验证iSCSI配置和多路径稳定性。
我们的迁移游戏计划
我们不想要直接迁移。相反，我们：
- 将新服务器添加到现有集群。
- 在“添加节点”模式下安装SQL Server。
- 将集群角色移动到新节点。
- 在完整验证后驱逐旧节点。
这让我们在滚动基础设施的同时保持SQL实例、监听器名称和磁盘完整。
逐步操作：我们做了什么
1. 准备新服务器
我们将新服务器加入域，完全打补丁，并双重检查SAN访问的多路径驱动程序。我们几乎错过的一件事：一个节点上的iSCSI启动器服务未设置为自动。小配置问题可能 later 花费数小时。
2. 加入集群
从故障转移集群管理器，我们添加了两个新节点。PowerShell也可以：
|
|
确保在每次加入后验证仲裁和见证设置。
3. 安装SQL Server
在每个新节点上，我们使用SQL安装UI“将节点添加到现有故障转移集群”。我们匹配现有实例名称和安装路径以避免 later 问题。如果您从未做过这个，请耐心——设置可能在检查集群角色时短暂挂起。
4. 移动SQL角色
我们使用PowerShell进行干净切换：
|
|
我们密切监控CPU/内存和应用程序日志。切换很快——应用程序层可能有30秒的“挂起”，但没有失败事务。
5. 踢出旧节点
在观察性能和故障转移几天后，我们驱逐了每个遗留节点：
|
|
在移除第二个节点之前，我们备份了集群配置并记录了磁盘所有权——以防万一。
并通过以下方式移除了第二个旧节点：
|
|
这确认了迁移，两个新SQL服务器节点无任何停机，并在迁移期间提供高可用性。
6. 清理任务
我们清理了陈旧的DNS条目，重新注册了监控代理，并验证了所有作业仍从SQL代理运行。我们还触发了完整的集群验证报告以确保一切通过。
让我们措手不及的事情
- 分区不匹配：一个LUN未正确映射——通过手动比较WWN解决。
- SQL代理：故障转移后，一个作业由于脚本中的硬编码节点名而静默失败。
- 防火墙规则延迟：虽然端口已打开，但GPO需要时间应用；我们必须手动运行gpupdate /force。
- 监控混淆：我们的监控工具误报健康故障转移为故障转移失败——需要手动重新配置。
迁移的快速提示
- 在安装SQL之前验证MPIO和SAN访问。
- 使用PowerShell进行可重复操作。
- 在宣布完成之前始终测试手动故障转移。
- 如果您是虚拟化的，快照您的集群配置。
- 在开始之前记录哪个节点拥有哪个磁盘。
- 特别测试SQL代理作业——注意硬编码路径或节点名。
- 使用集群日志/g捕获历史故障转移事件以供 later 故障排除。
- 将每个阶段沟通给应用团队——即使是短暂的故障转移也可能引起警报噪音。
最后 thoughts
这种迁移不简单——它令人神经紧张、细节繁重，且当它工作时往往 invisible。但它很重要。干净地完成它，用户甚至没有注意到，是一个好基础设施团队与伟大团队的区别。
我们还发现事后编写快速内部 playbook 有帮助。现在，我们组织中的其他团队可以重复过程或避免我们早期的错误。
在生产中，您只有一次机会干净地做这些事情。打印出您的回滚计划。知道谁在待命。并且永远不要假设在暂存中有效的在生产中会表现相同——尤其是SAN延迟或集群作业行为。
如果您计划做同样的事情，从我们的过程中学习。随意调整脚本片段和步骤以适应您的环境。并且总是——首先在测试中干运行。