譯者 | 核子可樂
審校 | 重樓
運行在老舊硬件或操作系統上的SQL Server故障轉移集群，往往很難以無宕機方式遷移至現代系統。我之前就面對過這類需求，將一個由HPE SAN支持的實時SQL集群遷移至Windows Server 2022新服務器，同時須保證依賴該集群的應用程序零中斷正常運行。以下是我們在完成這項工作中的一點心得體會。
SQL宕機對許多企業來說已經成為嚴重阻礙。報告管線會報錯、ERP系統會崩潰，即使是最簡單的用戶門戶也有可能癱瘓。無法承受這種連鎖反應，我們只能選擇無縫遷移方案。
業務運行的巨大壓力，要求我們最大限度降低高峰運營時段的停機風險。為此我們引入了額外的規劃、溝通和回滾驗證環節。
為何必須遷移
原因有以下幾點：
- 原始節點已經使用五年，且超出保修期。
- 我們的合規團隊將操作系統版本（Windows Server 2019）標記為即將停止支持。
- 我們希望借此調整配置決策，消除偶爾出現的故障轉移延遲。
這樣的基礎設施升級肯定不簡單，特別是在涉及關鍵SQL工作負載的情況下。
我們的設置（遷移前）
- 雙節點主-被動SQL Server 2019集群。
- 托管在Windows Server 2019系統上。
- 后端：具有多路徑I/O的HPE SAN。
- 通過DNS設置集群監聽器。
- .NET與報表工具會全天候訪問集群。
我們計劃引入兩個運行有Windows Server 2022的新節點，緩慢遷移所有內容，并在不中斷服務的情況下停用舊節點。
我們還與網絡和存儲團隊密切合作，在啟動操作之前先行驗證iSCSI配置與多路徑穩定性。
我們的遷移計劃
相較于直接遷移，我們決定：
- 將新服務器添加至現有集群。
- 以“添加節點”模式在新服務器中安裝SQL Server。
- 將集群角色遷移至新節點。
- 在完全驗證后移除舊節點。
這樣，我們就能在遷移底層基礎設施時，保證SQL實例、監聽器名稱與磁盤均保持不變。
我們的分步操作流程
1. 準備新服務器
我們將新服務器添加至域內，對其進行全面修復，并認真檢查了多路徑驅動程序是否支持SAN訪問。期間我們還差點忽略了一個重要細節：某個節點上的iSCSI啟動器服務未設置為自動。這個小小的配置問題一旦爆發，很可能會耗費幾小時的排查時間。
2. 加入集群
我們在故障轉移集群管理器添加了兩個新節點，PowerShell功能不受影響：
Add-ClusterNode -Name "UB-Prod-SQLA" -Cluster "SQLCluster"
Add-ClusterNode -Name "UB-Prod-SQLB" -Cluster "SQLCluster"每次加入后，必須驗證仲裁與見證設置。
3. 安裝SQL Server
在每個新節點上，我們使用SQL安裝UI“將節點添加至現有故障轉移集群”。我們對齊了現有實例名稱與安裝路徑，以避免后續出現問題。這里提醒大家，安裝程序在檢查集群角色時可能會短暫掛起，耐心等待即可。
4. 轉移SQL角色
我們使用PowerShell完成了簡潔切換：
Move-ClusterGroup-Name"SQL Server (MSSQLSERVER)"-Node"UB-PROD-SQLA"我們密切關注CPU/內存及應用程序日志。切換過程很快完成——應用層大約掛起了30秒，但沒有出現事務失敗。
5. 剔除舊節點
經過幾天的性能觀察與故障轉移，我們開始剔除舊節點：
Remove-ClusterNode-Name"SQLSERVER01"-Force在移除第二個節點之前，我們備份了集群配置并記錄了磁盤所有關系，以防發生意外。
而后使用PowerShell移除了第二個節點：
Remove-ClusterNode-Name"SQLSERVER02"-Force最終我們成功遷移到兩個新的SQL Server節點，未引發任何停機時間，高可用性亦未受到影響。
6. 清理工作
我們清理了過時的DNS條目，重新注冊了監控代理，并驗證了所有作業仍在SQL代理中正常運行。我們還激活了完整集群驗證報告，確保所有操作均順利通過。
讓我們措手不及的意外：
- 分區不匹配：一個LUN映射不正確——通過手動比較WWN解決了此問題。
- SQL代理：故障轉移后，由于腳本中包含硬編碼的節點名稱，因此一項作業靜默失敗。
- 防火墻規則滯后：盡管端口已經打開，但GPO需要一段時間才能應用；我們不得不手動啟動gpupdate /force。
- 監控誤判：我們的監控工具將正常的故障轉移誤判為需要手動重新配置的情況。
幾點小提示
- 在安裝SQL前驗證MPIO與SAN的訪問權限。
- 使用PowerShell執行可重復操作。
- 手動故障轉移前，務必進行測試。
- 如果已部署有虛擬化環境，請創建集群配置快照。
- 在啟動前，記錄每個節點擁有哪些磁盤。
- 專門測試SQL代理作業，留意其中硬編碼形式的路徑或節點名稱。
- 使用 cluster log /g 捕捉歷史故障轉移事件，以便日后進行故障排查。
- 將各個階段告知應用團隊——即使是短暫的故障轉移也可能觸發警報。
寫在最后
整個遷移過程并不簡單，令人緊張、細節繁瑣，但又無比重要。干凈利落地完成遷移，完全不引發用戶注意，正是區分優秀基礎設施團隊和卓越團隊的關鍵差異。
我們還發現，事后編寫一份內部快速行動手冊會很有幫助?，F在，組織內的其他團隊可以輕松重復整個過程，規避我們之前犯過的錯誤。
在生產環境中，整個遷移過程只有一次機會。所以務必整理好回滾計劃，知會值班人員，也絕不能樂觀認定預發布階段中奏效的方法可以直接在生產環境中成功。希望這篇文章能給大家一點啟發，幫助各位順利完成自己的遷移任務。
原文標題：Migrating SQL Failover Clusters Without Downtime: A Practical Guide，作者：Kishore Thota
