嘿哈布爾！ 我提請您注意這篇文章的翻譯 作者：安德魯比克霍夫
許多人喜歡兩節點集群，因為它們在概念上看起來更簡單，而且比三節點集群便宜 33%。 儘管很有可能將兩個節點組成一個良好的集群，但在大多數情況下，由於未考慮到的場景，這樣的配置會產生許多不明顯的問題。
創建任何高可用性系統的第一步是尋找並嘗試消除單一故障點，通常縮寫為 單點光纖 （單點故障）。
值得記住的是，不可能消除任何系統中所有可能的停機風險。 這是因為，典型的風險防禦方法是引入一些冗餘，這會導致系統複雜性增加並出現新的故障點。 因此，我們最初做出妥協，將重點放在與單一故障點相關的事件上，而不是相關的事件鏈上，因此可能性越來越小。
考慮到權衡，我們不僅尋求 SPoF，還要平衡風險和後果，因此每次部署的關鍵和非關鍵結論可能會有所不同。
並非每個人都需要擁有獨立電力線的替代電力供應商。 儘管當監控檢測到故障的變壓器時，至少一位客戶的偏執得到了回報。 客戶打電話試圖向電力公司報警，直到故障變壓器發生爆炸。
一個自然的起點是系統中擁有多個節點。 然而，在系統發生故障後將服務移至倖存節點之前，通常需要確保正在移動的服務在其他地方不活動。
如果故障導致兩個節點為相同靜態網站提供服務，那麼雙節點叢集不會有任何負面影響。 但是，如果結果是雙方獨立管理共享作業佇列或提供對複製資料庫或共享檔案系統的不協調的寫入訪問，情況就會發生變化。
因此，為了防止由於單節點故障而導致資料損壞 - 我們依靠稱為 “解離” （擊劍）。
解離原理
分離原則的核心問題是：競爭節點是否會導致資料損壞？ 如果可能發生資料損壞，一個好的解決方案是將節點與傳入請求和持久性儲存隔離。 最常見的解除關聯方法是停用故障節點。
解離方法有兩類，我稱之為 直接 и 間接，但它們同樣可以稱為 積極的 и 被動的。 直接方法包括倖存對等方的操作，例如與IPMI（智慧平台管理介面）或iLO（一種在無法實體存取伺服器的情況下管理伺服器的機制）裝置進行交互，而間接方法則依賴發生故障的設備節點以某種方式認識到它處於不健康狀態（或至少阻止其他成員恢復）並發出信號 關於需要斷開故障節點的連接。
使用直接和間接方法時，仲裁會有所幫助。
直接解離
在直接解離的情況下，我們可以使用仲裁來防止網路故障時的解離競爭。
有了仲裁的概念，系統中有足夠的資訊（即使沒有連接到其對等體），節點可以自動知道它們是否應該發起分離和/或恢復。
如果沒有法定人數，網路鴻溝的雙方都會正確地認為另一方已經死亡，並會尋求與另一方解除聯繫。 在最壞的情況下，雙方都會設法關閉整個集群。 另一個場景是死亡競賽，節點產生的無限循環，看不到它們的對等體，重新啟動它們，並且只有當它們的對等體遵循相同的邏輯時才啟動恢復以重新啟動。
解除關聯的問題是，由於我們想要恢復的相同故障事件，最常用的設備變得不可用。 大多數IPMI和iLO卡安裝在它們控制的主機上，並且預設使用相同的網絡，這會導致目標主機認為其他主機處於離線狀態。
不幸的是，在購買設備時很少考慮IPMI和iLo設備的操作特性。
間接解離
仲裁對於管理間接解除關聯也很重要；如果操作正確，仲裁可以允許倖存者假設遺失的節點將在一段時間後過渡到安全狀態。
使用此配置，如果仲裁未遺失，則硬體看門狗計時器每 N 秒重置一次。 如果計時器（通常是 N 的幾倍）到期，則裝置會執行非正常斷電（而不是關機）。
這種方法非常有效，但如果沒有仲裁，集群內就沒有足夠的資訊來管理它。 區分網路中斷和對等節點故障並不容易。 這很重要的原因是，如果無法區分這兩種情況，您就被迫在兩種情況下選擇相同的行為。
選擇一種模式的問題在於，沒有任何行動方案可以最大限度地提高可用性並防止資料遺失。
- 如果您選擇假設對等節點處於活動狀態但實際上發生了故障，則叢集將不必要地停止正在運行的服務，以補償故障對等節點的服務損失。
- 如果您決定假設某個節點已關閉，但這只是網路故障，並且實際上遠端節點正常運行，那麼您最多只能在未來對結果資料集進行手動協調。
無論您使用什麼啟發式方法，建立一個導致雙方失敗或導致叢集關閉倖存節點的故障都是微不足道的。 不使用仲裁確實會剝奪集群中最強大的工具之一。
如果沒有其他選擇，最好的方法就是犧牲可用性（這裡作者參考了CAP定理）。 損壞資料的高可用性對任何人都沒有幫助，手動協調不同的資料集也不有趣。
法定人數
法定人數聽起來很棒，對吧？
唯一的缺點是，為了將其放入具有 N 個成員的叢集中，您需要在剩餘的 N/2+1 個節點之間建立連接。 在一個節點發生故障後，這在兩節點叢集中是不可能的。
這最終為我們帶來了兩個節點的基本問題：
仲裁在兩個節點叢集中沒有意義，沒有它就不可能可靠地確定最大化可用性並防止資料遺失的操作過程
即使在透過交叉電纜連接的兩個節點的系統中，也不可能明確區分網路中斷和另一個節點的故障。 禁用一端（當然，其機率與節點之間的距離成正比）將足以使鏈路的健康狀況等於夥伴節點的健康狀況的任何假設失效。
使雙節點叢集正常工作
有時客戶不能或不想購買第三個節點，我們被迫尋找替代方案。
選項 1 - 重複解離方法
節點的 iLO 或 IPMI 設備代表一個故障點，因為如果它發生故障，倖存者將無法使用它來使節點進入安全狀態。 在包含 3 個或更多節點的叢集中，我們可以透過計算仲裁並使用硬體看門狗（一種間接解除關聯機制，如前所述）來緩解這種情況。 在有兩個節點的情況下，我們必須使用網路配電單元（PDU）。
發生故障後，倖存者首先嘗試聯繫主分離設備（嵌入式 iLO 或 IPMI）。 如果成功，恢復將照常進行。 僅當 iLO/IPMI 設備發生故障時才會存取 PDU；如果存取成功，則可以繼續恢復。
請務必將 PDU 放置在與叢集流量不同的網路上，否則單一網路故障將阻止對兩個解除關聯設備的存取並阻止服務的復原。
這裡你可能會問——PDU是單點故障嗎？ 答案是，當然。
如果這種風險對您來說很重要，那麼您並不孤單：將兩個節點連接到兩個 PDU，並告訴叢集軟體在開啟和關閉節點電源時使用這兩個 PDU。 現在，如果一個 PDU 失效，叢集仍保持活動狀態，並且需要另一個 PDU 或 IPMI 設備發生第二次故障才能阻止復原。
選項 2 - 新增仲裁者
在某些情況下，雖然重複分離方法在技術上是可行的，但在政治上卻很困難。 許多公司喜歡將管理員和應用程式所有者分開，並且具有安全意識的網路管理員並不總是熱衷於與任何人共用 PDU 存取設定。
在這種情況下，建議的替代方案是創建一個可以補充法定人數計算的中立第三方。
如果發生故障，節點必須能夠看到其對等點或仲裁器的電波，以便恢復服務。 如果兩個節點都可以看到仲裁器但無法看到對方，則仲裁器還包括斷開連接功能。
此選項必須與間接解除關聯方法結合使用，例如硬體看門狗定時器，該定時器配置為在機器失去與其對等節點和仲裁節點的連接時終止機器。 因此，倖存者可以合理地假設其對等節點在硬體看門狗計時器到期後將處於安全狀態。
仲裁器和第三節點之間的實際區別在於，仲裁器運作所需的資源要少得多，並且可以為多個叢集提供服務。
選項 3 - 人為因素
最後的方法是讓倖存者繼續運行他們已經在運行的任何服務，但不要啟動新的服務，直到問題自行解決（網路復原、節點重新啟動）或有人負責手動確認另一方已死亡。
獎金選項
我是否提到您可以新增第三個節點？
兩個機架
為了方便討論，讓我們假設我已經讓您相信了第三個節點的優點，現在我們必須考慮節點的物理排列。 如果它們安裝（並供電）在同一個機架中，這也構成了 SPoF，並且無法透過新增第二個機架來解決。
如果這令人驚訝，請考慮如果具有兩個節點的機架發生故障會發生什麼，以及倖存的節點如何區分該故障和網路故障。
簡而言之，這是不可能的，我們再次處理雙節點情況下的所有問題。 或者倖存者：
- 忽略仲裁並在網路中斷期間錯誤地嘗試啟動復原（完成分離的能力是另一回事，取決於是否涉及 PDU 以及它們是否與任何機架共用電源），或者
- 尊重仲裁並在對等節點發生故障時提前斷開連接
無論如何，兩個機架並不比一個機架好，節點必須要么接收獨立的電源，要么分佈在三個（或更多，取決於您擁有的節點數量）機架上。
兩個數據中心
此時，不再規避風險的讀者可能需要考慮災難復原。 當小行星撞擊同一個資料中心，而我們的三個節點分佈在三個不同的機架上時，會發生什麼事？ 顯然是壞事，但根據您的需求，增加第二個資料中心可能還不夠。
如果操作正確，第二個資料中心將為您提供（並且合理地）您的服務及其資料的最新且一致的副本。 然而，在兩個節點、兩個機架的場景中，系統中沒有足夠的資訊來確保最大可用性並防止損壞（或資料集差異）。 即使有三個節點（或機架），將它們分佈在兩個資料中心也會導致系統在發生（現在更有可能）雙方無法通訊的事件時無法可靠地做出正確的決策。
這並不意味著雙數據中心解決方案永遠不合適。 公司通常希望人們在採取轉移到備份資料中心的非凡步驟之前意識到這一點。 請記住，如果您想自動執行中斷，您要么需要第三個資料中心才能使法定人數有意義（直接或透過仲裁器），要么您會找到一種可靠地關閉整個資料的方法中心。
來源： www.habr.com