為什麼兩節點叢集是最糟的選擇：多數決問題

第二台伺服器買了，叢集也建好了。感覺更安全了：現在有兩台機器，一台倒下，另一台可以繼續撐著。

事實並非如此。兩節點叢集比單一節點更脆弱，而發現這件事的那一天，通常都不是什麼好日子。

原因

叢集以多數決做出決定。三個節點中有兩個在線，就構成多數，叢集持續運作。兩個節點中倒下一個，剩下的一個節點不構成多數，叢集便會自我鎖定：機器繼續執行，但設定無法變更，也無法啟動新的機器，大部分管理工作都會停擺。

這不是缺陷，而是刻意的設計。另一種結果糟糕得多：兩個節點互相看不到對方時，雙方都會認定自己還活著、倒下的是對方，於是在兩個地方啟動同一台虛擬機器。同一顆磁碟從兩邊被寫入，資料損壞到無法挽回。

所以叢集是以把管理者鎖在門外的方式來提供保護。但在兩個節點的情況下，每兩次故障就有一次會觸發這種保護。

正確的數字是三

在三節點叢集中，倒下一個還剩兩個，多數依然成立，一切照常。這就是叢集文件中到處都會出現三這個數字的原因。

第三台機器不必很強大。它只負責投票，不必執行任何工作。一台小機器，甚至一台舊電腦，就足以勝任。

如果真的不想要第三台機器，可以改為架設一個只用來投票的小型見證節點。它不是完整的節點，也無法在上面執行機器，但能把多數決的算術補足到三。如果打算維持兩個節點，至少要架設這個。

如果維持兩個節點，必須知道這些

當一個節點因維護而下線時，剩下的單一節點同樣會變得無法管理。所以即使是計畫中的更新，也會造成鎖定。

可以手動指定讓單一節點也能做出決定，但這正好重新打開了前面所說的重複啟動風險。這只能暫時、刻意且短時間地使用，並不是永久的解決方案。

建立叢集不等於做了備份

這是最常被混淆的兩件事。叢集是為了可用性：讓機器倒下時工作得以繼續。備份是為了復原：讓資料損毀或被誤刪之後還能回到原本的狀態。

叢集無法救回不小心刪除的虛擬機器。刪除動作會立即擴散到所有節點，因為叢集存在的目的，就是讓所有節點看到同樣的東西。即使有了叢集，備份依然不可或缺。

Atlas 的做法

Atlas 不把叢集當成一個概念，而是當成一種狀態：有幾個節點、其中幾個在投票、此刻多數是否成立。

這在更新時最有幫助。在更新某個節點之前，Atlas 會檢查其上的機器有多少台能移到另一個節點，並建議一個順序。建議始終只是建議：遷移指令不會自行執行，按下按鈕的是管理者。

這裡有一個細節特別重要，而且直指本文主題。查詢叢集狀態的指令，在兩種不同的情況下會以完全相同的方式失敗：一種是真的是單機，另一種是叢集成員，但叢集層已經崩潰。如果不區分這兩者，產品就會在叢集崩潰的那一刻回報沒有叢集、多數正常。也就是說，在最危險的時刻說出最讓人安心的話。

Atlas 透過檢查設定檔是否存在來區分兩者：這個檔案在加入叢集時一併寫入，即使叢集層崩潰也會留在原處。這項判斷只存在於單一位置，因為它過去分別寫在三個不同的地方，而三處都有同樣的錯誤。