當一台 PVE 節點故障時，為什麼有些 VM 能在另一台節點重新啟動，有些 VM 卻只能跟著原節點一起離線？
今天要對主線一進行收尾。前面建立的 PVE 叢集（PVE Cluster）、法定票數（Quorum）與 Ceph 共享儲存（Ceph Shared Storage），已經準備好讓 PVE HA 接手 VM 所需的基礎條件。
要看懂 PVE HA 要先回答以下問題：
今天會依照「先確認 VM 能移動，再讓 HA Manager 接手」的順序，最後使用 VMID 903 比較計畫性遷移與非預期故障復原。
本文閱讀方式
- 完整理解技術與底層原理：依序閱讀全文。
- 掌握完成部署所需的基本概念：優先閱讀標有「⭐」的章節。
- 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
- 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。
高可用（High Availability）要改善的是服務在故障後恢復的能力，但不保證任何故障都不會造成中斷。
PVE HA 在節點故障時，主要動作是在其他可用節點重新啟動 VM。原節點記憶體裡尚未寫入磁碟的狀態、已建立的 TCP 連線，以及應用程式正在處理的請求，通常不會一起轉移。在一個服務斷線的週期中，可能會經歷：
圖（一）PVE HA 從節點故障到服務恢復的時間差。
因此，VM 已在另一台節點亮起綠燈，只表示 PVE 已完成 VM 層的故障復原，不代表它把原本執行中的狀態遷移過去，也不等同於使用者已能正常使用服務。真正的恢復時間還包含作業系統、資料庫、Web 服務、DNS、負載平衡器與用戶端重試時間。
PVE 官方文件說明，節點失聯後，其他節點通常會先等待約兩分鐘，再於剩餘叢集中重新啟動 HA VM。
PVE 叢集會透過 Proxmox 叢集檔案系統（Proxmox Cluster File System，pmxcfs）讓節點共享 VM 設定。目標節點必須取得 VM 執行所需要的全部資源。
VM 設定位於叢集檔案系統中，所以同一個叢集內的節點可以看見 VMID、CPU、記憶體、磁碟與網卡設定。pmxcfs 也提供分散式鎖（Distributed Lock），讓 HA Manager 協調資源時不會由多個節點任意修改同一份狀態。
pmxcfs 儲存的是設定。即使設定裡寫著 scsi0: local-lvm:vm-903-disk-0，其他節點如果沒有那個本機磁碟區，依然無法啟動 VM。
可移動的 VM 要逐一檢查：
昨天建立的 ceph-vm RBD 儲存，三台 L1 PVE 都能存取同一份 VM 磁碟，因此節點故障後不必先從故障節點複製磁碟。
共享儲存不是唯一可行方案。PVE 也能遷移部分本機儲存，或使用 ZFS 複寫（ZFS Replication）讓另一個節點保有較新的副本。使用 ZFS 複寫時，能恢復到哪個時間點會受到最近一次同步進度影響，不一定會和關閉當下狀態一致。
同時也要分清楚：Ceph 不能取代備份（Backup）。使用者誤刪檔案、勒索軟體加密資料或應用程式寫入錯誤時，錯誤還是會正常寫進 Ceph。
目標節點必須存在 VM 設定所引用的 Linux 網路橋接器（Linux Bridge），例如本系列的 vmbr1。如果 VM 網卡設定了 VLAN Tag，目標節點的網路橋接器、上層 Trunk 與對應網路也必須一致。
VM 雖然成功開機，若目標節點缺少 vmbr1、VLAN 50 沒有通過，或防火牆規則只在原節點存在，服務仍然無法連線。HA Manager 在這個階段只負責啟動 VM。
線上遷移需要讓正在執行中的 VM 在目標 CPU 上繼續運作。來源節點已經提供給客體作業系統（Guest OS）的 CPU 指令集與功能旗標，目標節點也必須能提供。
PVE 的 CPU Type 可以理解為提供給客體作業系統的 CPU 能力範圍：
host：接近直接暴露目前主機的 CPU 型號與功能，通常效能與功能最好，但跨不同硬體世代時相容性最低。部署時應該先盤點所有節點共同支援的 CPU 功能旗標，再選擇能覆蓋全部目標節點的共同基準。x86-64-v2-AES 是目前 PVE Web UI 建立 VM 時的預設 CPU 型號，相容性通常較容易控制，但還是要實際確認每台目標節點都支援。
PCI／USB 裝置直通（Passthrough）、直接掛載本機磁碟，以及只接在某一台主機的實體裝置，都可能讓遷移或 HA 故障復原失敗。除非目標節點具有等價裝置，並完成一致的資源對應（Resource Mapping），否則 HA Manager 無法憑空建立這些硬體。
因此，加入 HA 前至少要完成以下檢查：
遷移是管理者已知來源節點正常時，主動將 VM 移到另一台節點。常見用途是硬體維護、更新、調整負載或預先騰空節點。
遷移是 PVE 叢集本身提供的能力，不需要先把 VM 加入 HA。HA Manager 的作用，是依期望狀態（Requested State）、節點狀態與親和性規則協調受管理資源的移動或故障復原。兩者不能直接畫上等號。
離線遷移會在 VM 關機後移動設定與必要磁碟，然後在目標節點啟動。它不需要搬移正在執行的記憶體與 CPU 執行狀態，因此流程較單純。
如果 VM 磁碟位於共享儲存，目標節點本來就能看到相同磁碟映像，主要是切換 VM 的執行節點。若磁碟位於可遷移的本機儲存，PVE 還必須把磁碟資料傳送到目標節點，時間會隨磁碟大小與遷移網路（Migration Network）速度增加。
線上遷移的目的，是讓 VM 在大部分搬移期間保持執行。QEMU 大致會依以下方式處理：
圖（二）線上遷移的預先複製流程
這種方式稱為預先複製（Pre-copy）。VM 的記憶體越大、寫入越頻繁，或遷移網路越慢，需要重送的已修改記憶體頁面（Dirty Page）就越多，遷移時間與最後暫停時間都可能增加。
即使畫面顯示線上遷移成功，既有連線不保證完全無感。QEMU 會遷移客體的記憶體與虛擬裝置狀態，但既有連線是否不中斷，會受到網路拓樸、SNAT、交換器 MAC 位址學習、應用程式逾時與切換期間短暫暫停影響。因此不能只看 PVE 工作顯示 OK，還要從用戶端持續送出請求，確認實際中斷時間。
線上遷移會傳送 VM 記憶體。本機磁碟遷移還會傳送大量磁碟資料。若全部與 Corosync 共用同一條網路，大量遷移流量可能干擾叢集心跳。
所以規劃獨立或至少有足夠頻寬與 QoS 的遷移網路十分重要，重點為：
這三種操作都可能讓 VM 換到另一台節點，但觸發原因與行為不同。表格中的 HA 管理堆疊（HA Stack）是 CRM、各節點的 LRM、看門狗、叢集鎖與 HA 設定共同組成的管理機制，不是一台獨立主機或單一程式：
| 操作 | 觸發者與情境 | VM 狀態 | 主要動作 |
|---|---|---|---|
| 線上遷移 | 管理者在來源節點正常時主動執行 | 持續執行 | 搬移記憶體、CPU 與裝置狀態，最後短暫切換 |
| 離線遷移 | 管理者先關閉 VM 再移動 | 已關機 | 移動或重新指向磁碟，在目標節點重新啟動 |
| HA Migrate | 由 HA 管理堆疊協調已受管理的資源 | 通常使用線上遷移 | 保持 HA 狀態一致並把執行位置移到指定節點 |
| HA Relocate | 由 HA 管理堆疊將資源移往其他節點 | 會停止再啟動 | 不保留執行中的記憶體與 CPU 執行狀態 |
| HA 故障復原 | 節點非預期故障 | 原 VM 已不可用 | 確認原節點安全離線後，在其他節點重新啟動 |
HA 資源已由 HA Manager 管理後，不應繞過 HA 管理堆疊任意改變狀態。需要以指令移動 HA 資源時，應使用 ha-manager migrate 或 ha-manager relocate，讓期望狀態、實際位置與 HA Manager 紀錄保持一致。
VM 已經具備跨節點執行條件後，才適合交給 HA Manager。PVE HA 不由一台永久主控節點控制，主要由以下元件協作。前幾天出現過的名詞也在這裡一併複習：
正常情況可以概略表示為：
圖（三）PVE HA Manager 各元件的協作關係
作用中的 CRM 只是目前取得叢集鎖、負責協調 HA 的角色，不是 PVE 叢集的永久主控節點。作用中的 CRM 離線後，只要剩餘節點仍有法定票數，就能由其他節點取得鎖並接替。
假設 pve01 只是 Corosync 網路中斷，但 VM 還在執行並持續寫入 Ceph。如果 pve02 認為 pve01 已經故障，立刻啟動同一台 VM，兩份客體作業系統可能同時寫入同一個磁碟映像，形成資料毀損。
因此，HA 必須分別從有法定票數的多數側，以及失去法定票數的少數側處理：
圖（四）取得法定票數的多數側等待原節點完成隔離
圖（五）失去法定票數的少數側由看門狗完成自我隔離
第一張圖是多數側的視角：它具有法定票數，可以繼續維護叢集狀態，但要等待原節點完成隔離，才能把資源交給新的節點。第二張圖是少數側的視角：失去法定票數的節點不能繼續維護自己的 HA 執行權，最後由看門狗讓整台 PVE 重新啟動。隔離要處理的是讓狀態不明的節點退出可寫入共享儲存的範圍。
PVE 可使用硬體看門狗，也能在缺少硬體看門狗時使用 Linux softdog。硬體看門狗有較獨立的硬體監督能力。softdog 主要依賴 Linux 核心與軟體路徑，不應被視為與獨立硬體看門狗完全相同。
每個正在管理 HA 資源的 LRM 都必須持續持有自己的 LRM 代理程式鎖（LRM Agent Lock）。這個鎖不是寫入後永久存在的靜態標記，而是必須在具有法定票數的叢集狀態中持續維持的租約。當節點失去法定票數時，pmxcfs 轉成唯讀，LRM 無法繼續維持代理程式鎖，也就不能再安全地更新看門狗。若該節點承載 HA 資源，PVE 預設會在看門狗逾時約 60 秒後讓整台節點重新啟動。
這 60 秒內，多數側不會因為看不到原節點就立刻啟動同一台 VM，也不需要向少數側更新或搶走鎖。少數側無法續租代理程式鎖，本身就是租約逐步失效的原因。多數側會等待看門狗保證原節點退出，再由作用中的 CRM 重新指派資源，讓目標節點的 LRM 取得新的執行權並從共享儲存啟動 VM。等待的目的正是避免網路隔離時兩側同時寫入同一顆虛擬磁碟。
如果剩餘節點沒有法定票數，HA Manager 就不能作出新的全域決策。法定票數決定哪一側有資格更新叢集狀態，代理程式鎖與看門狗共同保證舊節點退出，共享儲存則讓新節點取得同一份 VM 磁碟。三者處理不同問題，不能互相取代。
PVE HA 與 Ceph 不會互相觸發。PVE HA 負責判斷 VM 應在哪一個節點執行。Ceph 則負責讓存活的節點讀寫同一份 RBD VM 磁碟。HA Manager 決定要恢復 VM 以前，Ceph 必須有能力提供 I/O，否則目標節點即使符合親和性規則，也可能因為磁碟不可用而啟動失敗。
以三台節點為例，把 MON 與 OSD 分散在三台 PVE，停止一個節點時會同時失去一張 PVE 叢集票、一個 Ceph MON、一個 Ceph OSD，以及該節點正在執行的 VM。
剩餘兩台 PVE 還有 2/3 票，可以維持 PVE 法定票數。剩餘兩個 MON 也有 2/3 多數，可以維持 Ceph MON 法定票數。ceph-vm 使用 size=3、min_size=2，失去一個 OSD 後還有兩份可用副本，因此通常能在降級（Degraded）狀態下繼續 I/O，讓 HA Manager 從另一個節點啟動 VM。
這段關係可以整理成：
圖（六）單一節點故障時 PVE HA 與 Ceph 的可用條件
若再停止第二台 PVE：PVE 只剩 1/3 票而失去法定票數，Ceph MON 也只剩 1/3 而失去多數，OSD 可用副本數還會低於 min_size=2。此時剩餘環境同時缺少決策權與可寫入的儲存。
HEALTH_WARN 時 Ceph 可能持續提供服務節點故障後，ceph -s 很可能從 HEALTH_OK 變成 HEALTH_WARN。這只表示 Ceph 偵測到需要注意的狀態，是否還能提供 I/O 必須繼續查看 PG 與 OSD：
active：PG 可以處理 I/O。clean：PG 已達到預期副本數，沒有待復原內容。degraded：可用副本少於 size，但依然可能符合 min_size 而繼續服務。undersized：PG 的作用集合（Acting Set）少於設定副本數，通常會和 degraded 一起出現。peering：OSD 正在交換 PG 歷史並確認哪份資料最新，這段期間不一定能立即處理 I/O。remapped／backfilling／recovering：資料正在重新映射、回填或補回副本，會額外使用磁碟與網路資源。inactive、stale 或長時間無法回到 active+clean：不是正常狀態，應使用 ceph health detail 追查。OSD 的 up/down 與 in/out 分別代表：up 表示 OSD 守護程序正在執行並可回應，in 表示 CRUSH 把它視為可配置資料的成員。故障初期可能先看到 down/in，等待逾時或管理動作後才成為 down/out，並觸發資料重新配置。
目標節點可能已經把 VM 啟動，但 Ceph 處於 degraded 或 recovering。這代表服務已經恢復，不過副本數尚未回到故障前的狀態，兩個時間點不能混在一起記錄。
本 Lab 只有三個 OSD，而且 size=3。其中一台 L1 PVE 關閉後，Ceph 沒有第四個 OSD 可以立刻補回第三份副本，所以通常要等原節點與 OSD 回來後，PG 才能逐步回到 active+clean。在此之前不應再關閉第二台節點。恢復與回填也會使用 Ceph 網路與磁碟 I/O，如果和遷移或 Corosync 共用壅塞路徑，還可能拖慢 VM 與叢集通訊。
把 VM 加入 HA 資源後，HA Manager 會嘗試讓實際狀態符合期望狀態，也就是管理者希望它維持的狀態。常見概念包括：
started：HA Manager 應讓資源保持啟動。故障時會依規則嘗試恢復。stopped：由 HA Manager 維持停止狀態，但保留在 HA 資源中。disabled：停止並停用 HA 資源，節點故障時也不再重新安排，完成後保留設定。ignored：HA Manager 暫時忽略這個資源，不再主動修正其狀態。使用時要非常小心，避免人工操作與 HA 狀態互相衝突。
圖（七）PVE 9 的 HA Resource Request State
依 PVE 官方文件，新增 HA 資源時的預設期望狀態是 started。本次使用的 PVE 9 Web UI 也能直接在 Request State 欄位選擇 started、stopped、disabled 或 ignored。如圖所示，VMID 903 目前設定為 started。把原本關閉的測試 VM 以 started 加入 HA 資源後，HA Manager 會嘗試將它啟動。新增後可使用 ha-manager config 確認設定，並以 ha-manager status 查看執行結果。
HA 的操作是非同步的。下達啟動、遷移或重新安置後，畫面可能先顯示等待、遷移、停止、啟動或錯誤等中間狀態，直到 LRM 完成動作並回報。
VM 在目標節點啟動失敗，可能是儲存不可用、網路橋接器不存在、CPU 不相容、裝置直通缺少，或客體作業系統設定本身有問題。HA Manager 不會無限重新啟動同一台 VM，以免失敗動作持續消耗叢集資源。
每個 HA 資源可以設定：
Max Restart：在同一節點嘗試重新啟動的次數。Max Relocate：本機重啟失敗後，嘗試換到其他節點的次數。目前預設值通常各為 1。超過次數後，資源可能進入 error 狀態，需要管理者先排除根本原因，再清除錯誤或重新要求啟動。
PVE 9 以後的新版 Web UI 以 Affinity Rules 表達資源與節點的放置關係：
圖（八）PVE 9 的 HA Node Affinity Rule
HA 節點親和性規則用來描述一個或多個 HA 資源對節點的偏好與限制。節點可以設定正向或負向優先權（Priority）：
規則還分成非嚴格與嚴格模式（Strict）：
嚴格模式適合處理授權、硬體、儲存或法規限制，但嚴格模式不等於更高可用：沒有合格節點時，VM 會保持停止。如果只是希望某台 VM 優先落在 pve01，通常先使用非嚴格模式即可。
HA 資源親和性規則描述多個 HA 資源之間的相對位置：
與 HA 節點親和性規則不同，HA 資源親和性規則預設就是嚴格模式。若條件無法滿足，故障接管時資源可能停在恢復階段，其他操作則可能進入錯誤狀態。因此建立前要先確認可用節點數量。例如三個 VM 要彼此分散，但叢集只有兩個可用節點，就不可能同時滿足條件。多條規則互相衝突時，PVE 也可能停用有衝突的規則。
管理者已知節點即將更新、重新啟動或維修時，可以使用計畫性遷移或節點維護（Node Maintenance）的方式先移走 HA 資源。
正文已經拆開遷移、隔離、HA 故障復原與 Ceph 恢復的責任。本次 Lab 先證明測試 VM 具備跨節點執行的條件，再比較管理者主動遷移與節點故障後自動復原的差異，最後確認 VM 恢復服務和 Ceph 恢復完整副本是兩個不同時間點。
GitHub 詳細部署文件：Day 08｜PVE HA、Affinity Rules、Migration 與 VM Recovery
本文畫面使用 VMID 903 作為可丟棄測試 VM。若使用其他 VMID，只要整套測試前後使用同一台 VM 即可。
先執行 pvecm status、pvesm status、ceph -s 與 ha-manager status，確認 PVE 與 Ceph 都有法定票數、三個 OSD 可用，而且 HA Manager 沒有既有錯誤。如果測試前 Ceph 已經處於降級狀態，就先排除問題，避免把原有異常誤認為本次故障造成的結果。
Ceph Dashboard 顯示三個 MON、MGR 與 OSD 的整體狀態：
圖（九）故障測試前的 Ceph Dashboard。
pvecm status 顯示三個 PVE 節點都在線，而且叢集已取得法定票數：
圖（十）三個 PVE 節點均在線並取得法定票數。
pvesm status 顯示 ceph-vm、local 與 local-lvm 均可正常存取：
圖（十一）PVE 各項儲存均為 active。
ceph -s 與 ha-manager status 則共同保存故障前的儲存與 HA 狀態：
圖（十二）Ceph 與 HA Manager 的測試前狀態。
接著執行 qm config 903，確認系統碟、Cloud-Init Drive，以及存在時的 EFI／TPM Disk 都位於 ceph-vm。同時確認三個節點具有相同名稱的 Bridge、所需 VLAN 與相容的 CPU Type。這些結果可以證明 VM 具備移動條件。
先把 VM 關機，從 PVE Web UI 執行一次 Offline Migration。再啟動 VM，執行一次 Live Migration。測試端在遷移前就持續 Ping VM，或定時建立 SSH 連線，並同時記錄 PVE 工作的開始與完成時間。
以下畫面中，VM 903 原本由 pve01 執行：
圖（十三）遷移前 VM 903 位於 pve01。
遷移完成後，VM 的執行位置移到 pve02，但還是使用 Ceph 上同一份 VM 磁碟：
圖（十四）遷移後 VM 903 位於 pve02。
Ping 只能證明 VM 網路有回應，不能代表應用服務可用。如果 VM 內有測試 Web 服務，應在遷移前開始持續送出 HTTP 請求，另外記錄 PVE 工作的開始與完成時間。這樣才能分開觀察管理工作花費的時間，以及使用者實際感受到的服務中斷時間。在最後服務都部署完成後，我們會再做這項測試。
離線遷移會先停止 VM，再於目標節點啟動。線上遷移則在 VM 執行期間搬移記憶體狀態，通常只有切換階段出現短暫中斷。兩者成功都證明來源與目標節點目前能配合完成手動遷移。
到 Datacenter → HA → Resources 加入 vm:903。加入後讓 Request State 維持 started，再以 ha-manager config 確認設定，並用 ha-manager status 查看目前由哪個節點執行。
圖（十五）將 VM 903 加入 HA Resources。
加入後回到 HA Status，確認 VM 903 顯示為 started，並記下目前負責它的節點：
圖（十六）VM 903 已交由 HA Manager 管理。
接著到 Affinity Rules 建立非嚴格模式的 HA Node Affinity Rule，將測試 VM 與三個節點加入同一條規則。非嚴格模式表示優先遵循列出的放置偏好。條件暫時無法滿足時，不會只因為偏好失效就停止故障復原。
圖（十七）為 VM 903 建立非嚴格模式的 Node Affinity Rule。
ha-manager status 顯示資源為 started，證明 HA Manager 已接管並維持目前狀態。
核心 Lab 在 HA Manager 接管 VM 後，就可以進行節點故障測試。若要額外比較中斷時間，才先執行 Migrate 與 Relocate：Migrate 會進行線上遷移。Relocate 則會停止 VM，再於目標節點重新啟動。每次操作完成後都必須等 HA Status 回到 started、Ping 恢復且 Ceph 維持健康，才能進入下一項測試。
進行故障測試前，先確認 VM 903 正常執行且 Ceph 為 HEALTH_OK ：
圖（十八）節點故障前 VM 與 Ceph 均正常。
非預期故障測試從 L0 直接停止目前承載 VMID 903 的巢狀 PVE，模擬整個節點失聯。不要先在客體作業系統內正常關機，也不要只停止 QEMU 行程，否則無法驗證整個 PVE 節點失聯後的 HA 決策。測試期間持續觀察：
HA Status 何時進入隔離／故障復原的中間狀態。active+clean。以下畫面使用 pve02 作為故障節點。pve02 離線後，HA Manager 在完成隔離與重新指派後，於 pve01 重新啟動 VM 903：
圖（十九）pve02 離線後 VM 903 在 pve01 恢復。
同一時間，Ceph 因為少了一個 MON 與 OSD 進入 HEALTH_WARN，PG 顯示為 undersized／degraded。這代表服務可能還能讀寫，但儲存副本尚未恢復完整：
圖（二十）單一節點離線後 Ceph 進入降級狀態。
VM 在另一個節點啟動後，還要進入客體作業系統或從測試端連線，確認服務是否正常。HA Status 顯示 started 和應用服務恢復不是同一項證據。作業系統啟動後，服務可能需要額外時間才能接受請求。
PVE、HA 與 Ceph 狀態可使用以下指令交叉確認：
pvecm status
pvesm status
ceph -s
qm config 903
ha-manager config
ha-manager status
故障測試期間再搭配以下紀錄觀察狀態轉換：
journalctl -u pve-ha-crm
journalctl -u pve-ha-lrm
ceph -s
pvecm status
停止其中一台巢狀 PVE 時，該節點上的 Ceph MON 與 OSD 也會一起離線。VM 恢復後先保持另外兩個節點運作，不要再停止第二台。重新啟動原節點後，等待 pvecm status 回到三票、ceph -s 回到 HEALTH_OK，並以 ceph pg stat 確認 PG 回到 active+clean。
核心 Lab 完成後，再以每 0.2 秒一次的 Ping 探測進行選做量測。固定路徑為 pve01 → pve02 線上遷移、pve02 → pve03 重新安置，最後停止 pve03，讓 VM 903 由 pve01 接手。完整命令收錄在 Day 08 HA 恢復時間量測。
Day02 已介紹 RPO 與 RTO。這裡先用每 0.2 秒一次的 Ping 探測，觀察 VM 從中斷到恢復網路回應所需的時間。等後續實際服務與資料庫部署完成，再以持續 HTTP 請求與帶有序號的資料寫入量測服務恢復和資料遺失情況。
量測方式如下：
HEALTH_OK 且全部 PG 為 active+clean，才記錄完整恢復時間。| 測試 | 實測結果 | 結果代表什麼 |
|---|---|---|
| HA Migrate | 0.228 秒 | 約等於一次探測間隔，只能證明中斷極短，不能宣稱絕對零停機 |
| HA Relocate | 33.041 秒 | 包含停止 VM、在目標節點啟動與 VM 網路恢復 |
| 節點故障後 HA 故障復原 | 223.006 秒 | 包含故障偵測、隔離、重新指派、VM 啟動與 VM 網路恢復 |
| 原節點恢復後 Ceph 恢復 | 53.756 秒 | 從啟動 pve03 到 HEALTH_OK 且全部 PG 為 active+clean |
圖（二十一）線上遷移的最長可觀察 Ping 中斷為 0.228 秒。
圖（二十二）重新安置的最長可觀察 Ping 中斷為 33.041 秒。
HA Manager 在故障後 192.854 秒顯示 VM 為 started，VM 網路則在 223.006 秒恢復。兩者相差約 30 秒，證明 HA 狀態恢復不等於客體作業系統或應用程式已經可用。
圖（二十三）從故障注入到 VM 首次恢復 Ping 共 223.006 秒。
計算指令稿（Script）較長，因此截圖只保留部分指令稿與完整結果。完整測試命令請參考文件庫中的 Day 08 HA 恢復時間量測。
pve03 重新啟動後，PG 在 43.790 秒時已全部回到 active+clean，但時鐘偏差告警尚未消失，因此以 53.756 秒作為 Ceph 完整恢復時間。
圖（二十四）以第一筆同時符合 HEALTH_OK 與 active+clean 的紀錄計算，pve03 啟動到 Ceph 完整恢復共 53.756 秒。
| 證明 | 主要證據 | 可以得到的結論 |
|---|---|---|
| 證明一：健康基準與 VM 可移動性 | pvecm status、pvesm status、ceph -s 與 qm config |
故障測試不是從既有異常開始，目標節點也能取得 VM 必要資源 |
| 證明二：主動遷移 | PVE 工作、遷移前後節點與連續 Ping | 健康來源節點可以配合移動 VM |
| 證明三：HA Manager 接管 | HA Resource、Affinity Rule 與 ha-manager status |
HA Manager 已接管 VM 的期望狀態與放置偏好 |
| 證明四：節點故障後復原 | 原節點失聯、VM 在其他節點啟動、Ceph 降級與最終恢復 | PVE HA 與 Ceph 依各自條件完成接手與恢復 |
| 證明五：實測時間 | 0.2 秒 Ping 探測、HA／Ceph 狀態紀錄 | 不同切換方式的中斷時間不同，HA 狀態與 VM 網路也不是同一個恢復點 |
HA Resources，設定 started 與非嚴格模式的 Node Affinity Rule。至此，主線一已經完成。圖中橘色虛線框標示目前建立完成的虛擬化平台。
圖（二十五）主線一完成三節點 PVE 叢集、Corosync 與 Ceph 共享儲存
這八天完成的基礎與功能包括：
下一篇開始進入主線二：受控的網路與管理入口。這條主線會逐步建立 OPNsense 網路邊界、防火牆與 NAT、遠端 VPN、入侵偵測與防禦，以及受控的 SSH 管理入口。
Day 09｜狀態式防火牆如何運作：封包路徑、連線狀態與信任邊界會在安裝 OPNsense 與建立規則以前，先從封包欄位、五元組（Five-tuple）與狀態表（State Table）理解防火牆如何判斷一筆流量，再分清楚介面方向、路由、NAT 與過濾的責任。最後依照安全區域（Security Zone）、信任邊界（Trust Boundary）、攻擊面（Attack Surface）與預設拒絕（Default Deny），整理後續可以直接轉成防火牆規則的流量需求矩陣。
iThome鐵人賽
看影片追技術