在 Split-Brain 狀態下強制 quorum 的安全操作

Question

在 Split-Brain 狀態下強制 quorum 的安全操作

Li Jia Hao INC 20

在一個 4 節點 Failover Cluster 的環境中，假設因為 SAN 路徑 flapping，導致動態見證磁碟 (dynamic witness disk) 突然失效。當其中兩個節點掉線時，整個叢集進入了 Split-Brain 狀態，每邊都嘗試維持自己的 quorum，結果造成配置不一致。這種情況下，管理員需要快速處理，否則可能會有 cluster shared volume (CSV) 元數據損壞的風險。

在這種見證磁碟失效 + 節點掉線的情境下，如何在倖存的節點上執行 force quorum manual override，以便讓叢集重新取得控制權並恢復正常配置？

在執行 ForceQuorum 之前，是否需要先檢查或清理某些 Cluster Log / Event Trace，以避免強制操作後出現配置衝突？

如果之後要把 Witness Disk 遷移到 cloud witness 或 File Share Witness，在設計上需要注意哪些 quorum model 調整，才能避免再次出現 Split-Brain？

0 則留言

1 個回答

您的回答

Answer 1

歡迎來到 Microsoft Q&A！

感謝您提供如此詳細的情境說明。

首先，見證 (Witness) 故障加上網路分割 (Network Partition) 的情況下，理論上不應該讓兩個分區同時保持運作。Quorum 的設計目的就是在於停止無法取得多數票的分區，以避免發生 Split-Brain 狀況。Force Quorum 會繞過這項保護機制，因此只能作為受控且最後手段的災難復原作業來使用。

1. 使用 Force Quorum

在執行之前，請先確認：

無法透過正常方式恢復 Quorum。
選擇擁有最新叢集組態的節點。
確認所有不屬於所選權威分區 (Authoritative Partition) 的節點，其 Cluster Service 已停止。
驗證另一個分區無法存取或擁有 CSV (Cluster Shared Volume) 資源。

在權威節點上，以提升權限的 PowerShell 執行下列命令：

Start-ClusterNode -ForceQuorum

或者透過 Failover Cluster Manager 選擇 Force Cluster Start。

被選定的節點組態將成為權威組態 (Authoritative Configuration) ，並會同步複寫至後續重新加入叢集的其他節點。因此，如果選擇了過時的節點，部分較新的組態變更可能會遺失。

接著，以 Prevent Quorum 模式啟動其餘節點：

Start-ClusterNode -Name <NodeName> -PreventQuorum

PreventQuorum 可讓節點加入現有叢集，而不是建立另一個競爭中的叢集執行個體。建議所有在 Force Quorum 之後重新加入的節點都使用此選項啟動。

在確認儲存體擁有權及組態一致性之前，請勿將叢集工作負載或 CSV 上線。

2. 是否需要先清除記錄檔？

不需要。

在執行 Force Quorum 之前，不應清除 Cluster Log, Event Log 或 ETL Trace。這些資訊應保留下來供故障排除及事後分析使用。

可透過下列命令收集叢集記錄：

Get-ClusterLog -UseLocalTime

建議檢查：

與 Quorum 遺失相關的 Event ID 1177。
Witness 或磁碟資源失敗事件。
SAN 路徑異常及 Persistent Reservation 錯誤。
網路分割與 Heartbeat 相關事件。
CSV 擁有權變更或儲存體切換事件。

此外，也建議匯出相關的 System 與 Application Log，並檢查：

Witness 連線狀態
儲存體健康狀況
Quorum 與 Witness 組態設定

目前沒有任何受支援的做法要求先「清除記錄檔」以避免組態衝突。組態衝突的避免方式應包括：

正確選擇權威節點
隔離另一個分區
在節點重新加入時使用 PreventQuorum

3. Witness 遷移設計考量

對於四節點叢集，建議採用 Node Majority with Witness，並保留 Dynamic Quorum 與 Dynamic Witness 功能。對於三節點及四節點叢集，強烈建議配置 Witness。

建議如下：

若所有節點皆可穩定透過 HTTPS 存取 Azure Storage，則使用 Cloud Witness。
當無法可靠連線至 Azure 時，使用 File Share Witness。其位置應位於獨立的故障網域 (Fault Domain)，並與叢集節點及站台分離。
一個叢集只應設定 一個 Witness。
不應使用 DFS 或任何複寫式儲存體作為 File Share Witness。
避免使用 Disk Only / No Majority 模式，因為 Witness Disk 將成為單一失敗點 (Single Point of Failure) 。

完成 Witness 變更後，建議執行 Quorum 驗證測試，並確認新的仲裁設定符合預期。

簡單來說，Force Quorum 並不會自動修復 Split-Brain 問題。其安全使用的前提包括：