譯者 | 核子可樂

審校 | 重樓

運行在老舊硬件或操作系統(tǒng)上的SQL Server故障轉移集群，往往很難以無宕機方式遷移至現(xiàn)代系統(tǒng)。我之前就面對過這類需求，將一個由HPE SAN支持的實時SQL集群遷移至Windows Server 2022新服務器，同時須保證依賴該集群的應用程序零中斷正常運行。以下是我們在完成這項工作中的一點心得體會。

SQL宕機對許多企業(yè)來說已經(jīng)成為嚴重阻礙。報告管線會報錯、ERP系統(tǒng)會崩潰，即使是最簡單的用戶門戶也有可能癱瘓。無法承受這種連鎖反應，我們只能選擇無縫遷移方案。

業(yè)務運行的巨大壓力，要求我們最大限度降低高峰運營時段的停機風險。為此我們引入了額外的規(guī)劃、溝通和回滾驗證環(huán)節(jié)。

為何必須遷移

原因有以下幾點：

• 原始節(jié)點已經(jīng)使用五年，且超出保修期。
• 我們的合規(guī)團隊將操作系統(tǒng)版本（Windows Server 2019）標記為即將停止支持。
• 我們希望借此調整配置決策，消除偶爾出現(xiàn)的故障轉移延遲。

這樣的基礎設施升級肯定不簡單，特別是在涉及關鍵SQL工作負載的情況下。

我們的設置（遷移前）

• 雙節(jié)點主-被動SQL Server 2019集群。
• 托管在Windows Server 2019系統(tǒng)上。
• 后端：具有多路徑I/O的HPE SAN。
• 通過DNS設置集群監(jiān)聽器。
• .NET與報表工具會全天候訪問集群。

我們計劃引入兩個運行有Windows Server 2022的新節(jié)點，緩慢遷移所有內(nèi)容，并在不中斷服務的情況下停用舊節(jié)點。

我們還與網(wǎng)絡和存儲團隊密切合作，在啟動操作之前先行驗證iSCSI配置與多路徑穩(wěn)定性。

我們的遷移計劃

相較于直接遷移，我們決定：

• 將新服務器添加至現(xiàn)有集群。
• 以“添加節(jié)點”模式在新服務器中安裝SQL Server。
• 將集群角色遷移至新節(jié)點。
• 在完全驗證后移除舊節(jié)點。

這樣，我們就能在遷移底層基礎設施時，保證SQL實例、監(jiān)聽器名稱與磁盤均保持不變。

我們的分步操作流程

1. 準備新服務器

我們將新服務器添加至域內(nèi)，對其進行全面修復，并認真檢查了多路徑驅動程序是否支持SAN訪問。期間我們還差點忽略了一個重要細節(jié)：某個節(jié)點上的iSCSI啟動器服務未設置為自動。這個小小的配置問題一旦爆發(fā)，很可能會耗費幾小時的排查時間。

2. 加入集群

我們在故障轉移集群管理器添加了兩個新節(jié)點，PowerShell功能不受影響：

Add-ClusterNode -Name "UB-Prod-SQLA" -Cluster "SQLCluster"

Add-ClusterNode -Name "UB-Prod-SQLB" -Cluster "SQLCluster"

每次加入后，必須驗證仲裁與見證設置。

3. 安裝SQL Server

在每個新節(jié)點上，我們使用SQL安裝UI“將節(jié)點添加至現(xiàn)有故障轉移集群”。我們對齊了現(xiàn)有實例名稱與安裝路徑，以避免后續(xù)出現(xiàn)問題。這里提醒大家，安裝程序在檢查集群角色時可能會短暫掛起，耐心等待即可。

4. 轉移SQL角色

我們使用PowerShell完成了簡潔切換：

Move-ClusterGroup-Name"SQL Server (MSSQLSERVER)"-Node"UB-PROD-SQLA"

我們密切關注CPU/內(nèi)存及應用程序日志。切換過程很快完成——應用層大約掛起了30秒，但沒有出現(xiàn)事務失敗。

5. 剔除舊節(jié)點

經(jīng)過幾天的性能觀察與故障轉移，我們開始剔除舊節(jié)點：

Remove-ClusterNode-Name"SQLSERVER01"-Force

在移除第二個節(jié)點之前，我們備份了集群配置并記錄了磁盤所有關系，以防發(fā)生意外。

而后使用PowerShell移除了第二個節(jié)點：

Remove-ClusterNode-Name"SQLSERVER02"-Force

最終我們成功遷移到兩個新的SQL Server節(jié)點，未引發(fā)任何停機時間，高可用性亦未受到影響。

6. 清理工作

我們清理了過時的DNS條目，重新注冊了監(jiān)控代理，并驗證了所有作業(yè)仍在SQL代理中正常運行。我們還激活了完整集群驗證報告，確保所有操作均順利通過。

讓我們措手不及的意外：

• 分區(qū)不匹配：一個LUN映射不正確——通過手動比較WWN解決了此問題。
• SQL代理：故障轉移后，由于腳本中包含硬編碼的節(jié)點名稱，因此一項作業(yè)靜默失敗。
• 防火墻規(guī)則滯后：盡管端口已經(jīng)打開，但GPO需要一段時間才能應用；我們不得不手動啟動gpupdate /force。
• 監(jiān)控誤判：我們的監(jiān)控工具將正常的故障轉移誤判為需要手動重新配置的情況。

幾點小提示

• 在安裝SQL前驗證MPIO與SAN的訪問權限。
• 使用PowerShell執(zhí)行可重復操作。
• 手動故障轉移前，務必進行測試。
• 如果已部署有虛擬化環(huán)境，請創(chuàng)建集群配置快照。
• 在啟動前，記錄每個節(jié)點擁有哪些磁盤。
• 專門測試SQL代理作業(yè)，留意其中硬編碼形式的路徑或節(jié)點名稱。
• 使用 cluster log /g 捕捉歷史故障轉移事件，以便日后進行故障排查。
• 將各個階段告知應用團隊——即使是短暫的故障轉移也可能觸發(fā)警報。

寫在最后

整個遷移過程并不簡單，令人緊張、細節(jié)繁瑣，但又無比重要。干凈利落地完成遷移，完全不引發(fā)用戶注意，正是區(qū)分優(yōu)秀基礎設施團隊和卓越團隊的關鍵差異。

我們還發(fā)現(xiàn)，事后編寫一份內(nèi)部快速行動手冊會很有幫助?，F(xiàn)在，組織內(nèi)的其他團隊可以輕松重復整個過程，規(guī)避我們之前犯過的錯誤。

在生產(chǎn)環(huán)境中，整個遷移過程只有一次機會。所以務必整理好回滾計劃，知會值班人員，也絕不能樂觀認定預發(fā)布階段中奏效的方法可以直接在生產(chǎn)環(huán)境中成功。希望這篇文章能給大家一點啟發(fā)，幫助各位順利完成自己的遷移任務。

原文標題：Migrating SQL Failover Clusters Without Downtime: A Practical Guide，作者：Kishore Thota