已開啟高可用性，機器還是停了：HA 真正的承諾是什麼

高可用性已經開啟。某個節點倒下後，機器也確實在另一個節點上啟動了。但中間有好幾分鐘完全無法提供服務，而原本的預期是不會有任何中斷。

誤解就在這裡：高可用性承諾的不是不中斷運作，而是自動重新啟動。

兩件不同的事

線上遷移是計畫中的工作。由管理者發起，機器連同記憶體一起移到另一個節點，幾乎不會停頓。這是維護之夜的工具。

高可用性則是為非計畫中的故障而設。節點崩潰時，記憶體中的一切也隨之消失，沒有東西可以複製。唯一能做的，是在另一個節點上從頭啟動這台機器。也就是說，它的啟動方式就和伺服器在停電後重新開機一樣。

所以衡量 HA 的標準不該是有沒有中斷，而是中斷持續了多久。

決定中斷時間的三件事

察覺。叢集不會立刻判定節點真的已經死亡。把一次網路抖動誤判為死亡並移動機器，比沒察覺到死亡還糟。所以會有一段等待時間。

讓舊節點靜默。這個步驟最常被誤解，也是本文的核心：在機器於新節點上啟動之前，必須確定舊節點真的已經停止。如果無法確認，叢集會強制重新啟動那個節點。

這聽起來很粗暴，但另一種結果是災難：如果舊節點其實還在運作，只是網路斷了，同一台機器就會在兩個地方執行，從兩邊寫入同一顆磁碟。資料會損壞到無法挽回。正因如此，叢集寧可把無法確認狀態的節點關掉。

開機。機器在新節點上從頭開機。作業系統啟動、服務陸續上線，若有資料庫則會自行復原。這段時間就是機器平常的開機時間，叢集沒有辦法縮短它。

在多數環境中，加總起來是以分鐘計算。不是零，也不會是零。

HA 能夠運作的三個前提

多數決。HA 仰賴叢集能夠做出決定。沒有多數，什麼都不會移動。在兩個節點的叢集上開啟 HA，等於架設一張在最需要它的那一刻剛好失效的安全網。

磁碟能從另一個節點存取。機器要在新節點上啟動，就必須能存取自己的磁碟。只放在本機儲存空間上的機器哪裡也去不了。

容量。剩下的節點必須也能扛起倒下節點的負載。如果兩個節點都已經用到百分之八十，HA 救不了局面，反而會把第二個節點也一起拖垮。

不要每台機器都開啟 HA

每一台開啟 HA 的機器，都會變成叢集持續監看的對象，並在叢集認為適當時自行決定啟動或停止。這不一定是想要的結果。

判斷方法很簡單：如果這台機器在凌晨三點自己在另一個節點上啟動，早上得知這件事時，會感到安心還是擔心？如果安心，就開啟 HA。如果擔心，就不要開啟，這台機器的決定由管理者自己來做。

Atlas 的做法

Atlas 會另外標示交由高可用性管理的機器。這在維護時最有幫助：更新前列出某個節點上的機器時，哪些取決於管理者的決定、哪些取決於叢集的決定，可以分開看清楚。手動移動與交給管理機制是不同的兩件事，混淆兩者的代價很高。

一個小但有意義的行為：如果這套安裝從未設定過高可用性，Atlas 會發現相關的設定檔不存在，於是根本不去詢問，直接回傳空的答案。因此在不使用 HA 的環境中，產品不會讓管理者或系統為了尋找不存在的東西而忙碌。

還有一個限制值得明說：Atlas 不會做出也不會變更叢集的 HA 決定。一台機器是否交給 HA 管理，是管理者與 Proxmox 的事；Atlas 讓它看得見，但不代為決定。