具有多個節點的 Sql Server 集群
考慮不到 50% 的所有包含節點處於備用狀態的故障轉移群集配置是否有意義？
例如，與其設置 4 個雙節點集群，其中一個在每個集群上處於活動狀態，一個處於待機狀態 - 創建 1 個具有 4 個活動節點和兩個處於待機/被動狀態以進行故障轉移的集群不是更有意義嗎？這總共節省了 2 個節點。
當然，如果多個節點發生意外故障並且必須共享以前的備用節點之一，則存在風險，但如果您決定承擔風險來配置備用硬體資源？
尋找“多節點故障轉移群集”我找不到更多關於此的資訊。
首先，在我看來，擁有 4 個獨立的 2 節點集群，每個集群都有一個 FCI 部署，這似乎有點極端。你描述的第二個模型對我來說真的沒有意義。我建議不要使用任何一種部署方式，而是執行 2 個 4 個節點的集群（每個節點都需要見證人），並將每個節點中的一個節點視為專用的故障轉移節點（即，為每個集群安裝 3 個 SQL FCI）。
此外，您應該嘗試在 Windows 2012 R2 上進行部署，因為它具有動態仲裁和動態見證功能（2012 僅具有動態仲裁） - 這將有助於在節點發生故障時保持最長的正常執行時間。
如您所知，沒有足夠的專用故障轉移節點的最大問題是最終您會面臨 SQL 共存的考慮（例如，如果與其他 SQL FCI 共享，則在故障轉移時設置正確的最大記憶體）。此外，在真正的高可用性環境中，您可能不希望在故障轉移後進行故障恢復（否則會進一步增加停機時間），因此共享專用故障轉移節點可能需要一個實例的故障恢復（假設兩個已故障轉移）。
然而，話雖如此，所有系統部署都是一種折衷方案，配置過多的冗餘故障轉移節點沒有意義，重要的是要在 HA 要求和成本效益之間找到適當的平衡。
作為一般經驗法則，您應該考慮每 (2 SQL FCI) 3 節點集群大約有 1 個專用（故障轉移節點），每 (5 FCI) 7 節點集群有 2 個專用，每 (8 FCI) 11 節點集群有 3 個專用。這些數字是近 20 年 SQL 故障轉移集群的個人經驗的近似值，但顯然還有許多其他因素會影響您的設計策略。
ps 有一些技術集群的原因，為什麼不部署大量集群節點是有意義的，所以我可能無論如何都不會超過 5 節點集群（在這種情況下，我可能仍然對 1 個專用的故障轉移節點感到滿意）。