#proxmox#ha#high-availability#migration#fencing

Proxmox VE 高可用性：讓 VM 自己找活路

10 min read

高可用性（HA）的核心概念其實很樸素：某台機器掛了，上面的服務自動在別台機器重新跑起來。 就像餐廳的備用瓦斯爐——主爐壞了，菜不能停，換一台繼續炒。聽起來理所當然，但要做到「自動」且「安全」，底層有不少機制要搞對。HA 是建立在 叢集 之上的功能，還沒組叢集的話請先回去看。

HA 的腦與手

PVE 的 HA 架構分成兩層：

┌─────────────────────────────────────┐
│         CRM（叢集資源管理器）          │
│      → 在 Master 節點上執行            │
│      → 決策中心：誰掛了、搬去哪         │
├────────┬────────┬───────────────────┤
│ LRM    │ LRM    │ LRM               │
│ Node 1 │ Node 2 │ Node 3            │
│ → 執行者│ → 執行者│ → 執行者           │
├────────┴────────┴───────────────────┤
│     Corosync + Quorum + Fencing     │
└─────────────────────────────────────┘
  • CRM（Cluster Resource Manager）：大腦，負責監控所有 HA 資源，判斷「誰掛了」「搬去哪」
  • LRM（Local Resource Manager）：手腳，每個節點上都有一個，負責實際的開機、關機、遷移動作

CRM 跟 LRM 的關係像是調度室跟現場工人——調度室下指令，工人動手做。

Fencing：先確認倒下的人不會亂動

這是 HA 最關鍵也最常被忽略的一環。

想像一個場景：Node 1 的網路斷了，CRM 覺得它掛了，於是在 Node 2 啟動同一台 VM。但其實 Node 1 還活著，上面那台 VM 也還在跑。兩邊同時寫同一份資料——恭喜，資料毀了。

Fencing 就是為了防止這種事。PVE 使用 watchdog-based fencing：

  1. 每個節點跑一個 watchdog-mux 守護程序，持續「餵狗」
  2. 節點失去 Quorum → 停止餵狗 → watchdog 超時
  3. watchdog 超時 → 強制重啟該節點
  4. 節點重啟後，上面的 VM 自然就停了，CRM 才能安全地在其他節點啟動它們
# 確認 watchdog 狀態
systemctl status watchdog-mux
 
# 檢查有沒有硬體 watchdog
ls /dev/watchdog*

PVE 預設用軟體 watchdog（softdog），能用但不是最可靠。如果你的伺服器有硬體 watchdog（多數 server 級主板都有），建議啟用它。硬體 watchdog 就算系統整個卡死也能強制重啟，軟體的做不到。

設定 HA 資源

把 VM 加入 HA 管理很簡單：

# 新增 HA 資源
ha-manager add vm:100 --state started --group my-ha-group
 
# 查看 HA 狀態
ha-manager status
 
# 移除 HA 資源
ha-manager remove vm:100

Web GUI 操作路徑：Datacenter → HA → Add → 選 VM → 設定 Group

HA Groups：決定 VM 能住哪

HA Group 定義了資源可以在哪些節點上執行，以及優先順序：

  • Priority：數字越大越優先，故障轉移時優先選高優先順序的節點
  • restricted：開啟後資源只能在 Group 內的節點跑，不會跑到外面
  • nofailback：故障轉移後不自動搬回原來的節點，避免不必要的遷移

就像員工排班——你可以指定某些人優先上早班，也可以限制某些人只能待在特定部門。

HA 資源狀態速查

狀態 意思
started 正常運行中
stopped 已停止（HA 會確保它維持停止）
migrate 正在遷移
relocate 故障後正在重新安置
error 出事了，需要人工介入
fence 節點正在被隔離中

Live Migration：VM 搬家不斷線

Live Migration 是把正在跑的 VM 從 A 節點搬到 B 節點，過程中服務（幾乎）不中斷：

  1. 開始複製 VM 記憶體到目標節點
  2. 持續同步變動的記憶體頁面
  3. 最終短暫暫停（通常不到 1 秒）→ 切換完成
  4. VM 在目標節點繼續跑

前提條件：

  • 共享存儲（Ceph/NFS/iSCSI），或者用 Replication 先把磁碟同步過去——存儲怎麼選可以看 存儲全攻略
  • 兩台節點的 CPU 相容（同廠牌同世代最保險）
# 手動觸發 Live Migration
qm migrate 100 node2 --online

Live Migration 最常用在計劃維護——要更新 Node 1 的韌體？先把上面的 VM 全部 live migrate 到其他節點，更新完再搬回來。使用者完全無感，就像魔術師在你眼前把東西換掉，你卻什麼都沒察覺。

Affinity Rules（PVE 9.0+）

PVE 9.0 開始支援 Affinity Rules，讓你控制 VM 之間的「距離」：

  • 共置（Co-locate）：指定一群 VM 必須在同一節點。例如 Web Server 跟它的 Redis Cache，放一起延遲最低
  • 分離（Separate）：指定一群 VM 必須分散在不同節點。例如兩台 Database 主備，放一起就失去了備援的意義

這就像安排座位——有些人要坐在一起方便討論，有些人必須分開坐避免作弊。

故障轉移完整流程

當一台節點真的掛了，整個流程是這樣的：

  1. Corosync 偵測到心跳消失
  2. 其他節點確認：「它真的掛了，不是網路抖一下」
  3. CRM 觸發 Fencing → 等 watchdog 強制重啟故障節點
  4. 確認 Fencing 完成（故障節點上的 VM 確實停了）
  5. CRM 指派 LRM 在目標節點啟動受影響的 HA 資源
  6. 持續監控直到資源恢復正常

整個流程大概幾十秒到幾分鐘，取決於 watchdog 超時設定和 VM 啟動速度。

HA 不是萬能的

幾個前提得滿足，不然 HA 只是擺設：

  • 最少 3 節點（或 2 節點 + QDevice）——Quorum 機制的硬需求
  • 共享存儲或 Replication——VM 磁碟搬不過去，HA 就沒用
  • Fencing 正常運作——沒有 Fencing 的 HA 比沒有 HA 更危險
  • 不適合所有 VM 都開 HA——資源吃緊的時候故障轉移也跑不動，挑關鍵服務就好
  • 就算有 HA，備份還是要做——HA 防的是節點故障，不防人為誤刪或資料損壞

維護節點之前，記得先把 HA 資源手動遷走。直接關機會觸發故障轉移流程——不是不行，但沒必要讓系統白跑一趟驚嚇反應。更多 Homelab 維運的眉角，可以參考 最佳實踐總整理。

延伸閱讀

常見問題

Q: PVE HA 最少需要幾個節點？

最少 3 個節點（或 2 節點加 QDevice）。HA 依賴 Quorum 機制運作，過半數節點存活才能做決策。2 節點不加 QDevice 的話，掛一台整個 HA 就停擺了。

Q: Live Migration 需要共享存儲嗎？

標準做法是需要的，Ceph、NFS 或 iSCSI 都可以。如果沒有共享存儲，可以用 ZFS Replication 先同步磁碟到目標節點，但遷移速度會受磁碟大小影響。

Q: Proxmox 高可用的 Fencing 是什麼？

Fencing 是確保故障節點上的 VM 真正停止後，才在其他節點重新啟動的安全機制。PVE 用 watchdog 實現——節點失去 Quorum 後停止餵狗，watchdog 超時就強制重啟該節點，避免兩邊同時跑同一台 VM 導致資料損壞。

Q: HA 故障轉移要多久？

從偵測到故障到 VM 在新節點啟動完成，通常需要幾十秒到幾分鐘。取決於 watchdog 超時設定（預設約 60 秒）和 VM 本身的開機速度。這段期間服務會中斷，不像 Live Migration 幾乎無感。

HA 設定好之後，你的 PVE 叢集就從「多台電腦各管各的」升級成了「互相掩護的團隊」。搭配前面的存儲、網路、備份知識，一套完整的虛擬化基礎建設就成形了。剩下的就是根據你的場景微調，然後享受穩定運作帶來的安心感。