三台 PVE 能在同一個管理畫面出現，不代表它們已經具備高可用。三台主機各有一顆磁碟，也不會自動變成共享儲存。PVE 叢集（PVE Cluster）、Corosync、法定票數（Quorum）與 Ceph 分別處理不同問題，必須先把底層通訊與決策關係理清，才能判斷節點故障後究竟還剩下哪些能力。
今天會依照 " 網路通訊 → 叢集成員 → 多數決 → 共用設定 → 分散式儲存 " 的順序，回答以下問題：
pmxcfs 如何串在一起？本文閱讀方式
- 完整理解技術與底層原理：依序閱讀全文。
- 掌握完成部署所需的基本概念：優先閱讀標有「⭐」的章節。
- 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
- 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。
前面的準備已經完成單機儲存、虛擬網路與 VM 範本，現在才真正進入多節點控制平面。今天先把 pve01～pve03 組成 PVE 叢集，確認三台主機看到的是同一份成員名單與叢集設定。等三個節點形成穩定法定票數後，再建立 Ceph 分散式儲存。
PVE 叢集提供共同管理、設定同步與叢集決策。Ceph 提供跨節點的共享儲存。兩者完成後，還要等下一篇把 VM 加入 HA Resources，才會形成 PVE 層的自動復原流程。
先來看一下 PVE 叢集各元件之間的關係：
圖（一）PVE 叢集通訊與設定同步關係
這邊先介紹一下名詞：
/etc/pve，再透過 Corosync 即時複寫到各節點。這些元件的關係是：Knet 負責把訊息送到其他節點，Corosync 根據收到的訊息更新成員名單，votequorum 再用目前可見的票數判斷是否取得法定票數。取得多數的一側才能安全修改 pmxcfs 中的共享狀態。
pmxcfs 也解釋了為什麼 PVE 叢集是多主節點（Multi-master）管理：管理者登入 pve01、pve02 或 pve03，看到的都是同一套 Datacenter、Storage、Firewall 與 VM 設定，不需要指定一台永久的主節點。第一台執行 pvecm create 的節點只是用來建立叢集，不會因此變成永遠不能故障的主節點。
三台節點在加入叢集以前就應使用最終主機名稱（Hostname）與 IP。如本文用的 pve01.lab.home、pve02.lab.home、pve03.lab.home。名稱解析可由 DNS 或 /etc/hosts 提供，但 Corosync 設定直接使用固定的 10.77.80.x 位址，避免日後名稱解析改變連帶影響 Link 0。
節點加入叢集時，既有 /etc/pve 設定會被叢集設定取代，並繼承叢集的儲存設定（Storage Configuration）。若待加入節點已存在 VM 或 CT，不只 VM 設定可能消失，也可能和既有 VMID 衝突。正確做法是先備份 VM 或 CT，加入完成後再用不衝突的 VMID 還原。
三台 PVE 應使用相同版本並完成必要更新。節點之間要能使用 Corosync 的 UDP 5405～5412，PVE 節點之間也需要 TCP 22。若啟用 PVE Firewall，Corosync 的允許規則會由 PVE 自動處理，不需要再為同一條 Link 重複手工建立規則。
叢集中的三台 PVE 不只要能互相連線，系統時間也必須一致。Corosync 需要靠節點之間的通訊判斷成員名單與法定票數。PVE 的憑證、工作紀錄與後續 Ceph 服務也都會使用系統時間。如果三台主機各自快慢數秒甚至數分鐘，除了可能造成憑證或服務異常，發生故障時也很難從三台紀錄還原真正的事件順序。
Chrony 是 PVE 預設使用的 NTP 時間同步程式，會向時間來源取得標準時間並持續修正本機時鐘。這裡只要先理解它的任務是讓各節點使用一致的時間基準。服務狀態、來源與偏差的實際檢查統一放到後面的 Lab。
時間同步和時區並不相同：Chrony 負責校正實際時間，Asia/Taipei 則只決定畫面與紀錄如何顯示時間。本系列統一時區，是為了讓三台節點的事件紀錄更容易對照。
Corosync 傳輸的資料量不大，但它必須依序、穩定而且及時收到其他節點的訊息。大量 Ceph 資料復原（Recovery）或 VM 線上遷移（Live Migration）即使沒有吃滿平均頻寬，也可能造成延遲抖動與短暫丟包，讓 Corosync 誤判節點離線。Proxmox 官方要求節點間維持 LAN 等級、低於 5ms 的延遲，並建議不要讓主要 Corosync Link 和儲存流量（Storage Traffic）共用高流量網路。
Corosync 先確認成員名單，votequorum 再依目前可見的票數判斷能不能修改叢集狀態。一般情況下，每個節點預設一票，法定票數必須取得嚴格過半：
| 節點／預期票數 | 取得法定票數所需票數 | 最多可失去幾票 |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
計算方式為 floor(Expected Votes ÷ 2) + 1，也就是永遠必須取得嚴格過半。
圖（二）五節點只有多數一側取得法定票數
五節點被切成三票與兩票時，預設門檻依然是三票，因此只有左側能繼續修改叢集狀態。
圖（三）錯誤降低門檻可能形成腦裂
如果人為把門檻改成兩票，兩側便可能同時認為自己取得法定票數。這不是 PVE 的正常預設行為，只是用來說明任意修改 Expected Votes 為什麼危險。
為什麼需要奇數節點？因為每增加一組故障容忍能力，只需要增加兩票。三票與四票都只能容許失去一票，因為四票的多數門檻會從二提高到三。第五票加入後，多數門檻還是三，才真正把可失去票數從一提高到二。因此在故障容忍能力相同時，四節點比三節點多出的那一票沒有提高法定票數的容錯，這就是小型叢集通常選三、五等奇數票數的原因。
兩節點環境在任一節點失聯後只剩一票，無法判斷是對方真的關機，還是網路把雙方分開。在只有兩台 PVE 的情況下，可在獨立第三台 Linux 主機部署 Corosync QDevice／QNetd，讓外部仲裁者只把第三票交給其中一側，補上安全裁決所需的第三票。
法定票數保護的是叢集決策權，不是 VM 是否持續執行。三節點失去一台後還是有兩票，可以繼續進行一致性決策。失去兩台後只剩一票，便不再具有多數。
失去法定票數時，所有 VM 並不會立刻關機，已經在某節點上運作的 VM 可能繼續執行，但叢集會限制部分管理與 HA 決策，避免兩個彼此隔離的網路分割區同時認為自己有權修改狀態。
只中斷 Corosync 網路和整台節點關機不是同一種故障。前者可能保留管理與服務網路，卻失去叢集通訊。後者則該節點上的 VM、儲存與網路會一起消失。
到這裡，PVE 的成員通訊、票數與共同設定已經建立完成，但硬碟內容並不會因此共用。假設 VM 目前在 pve01，而它的虛擬磁碟只放在 pve01 的 local-lvm：即使 pve02 看得到這台 VM 的設定，也讀不到實際磁碟資料。要讓 VM 能在其他節點啟動，必須先讓目標節點取得相同的虛擬磁碟，方法可能是 Ceph、NFS、SAN 等共享儲存（Shared Storage），或使用支援情境下的儲存複寫（Storage Replication）。
本系列選擇 Ceph，是為了直接在三台 PVE 上同時提供運算與分散式儲存，形成超融合基礎架構（Hyper-converged Infrastructure，HCI）：
傳統架構會把角色分開：運算節點只執行 VM，另外準備 NAS、SAN 或專用儲存叢集保存虛擬磁碟。HCI 則讓同一批伺服器同時提供運算與儲存能力。每台 PVE 一方面執行 VM，一方面把自己的磁碟加入 Ceph。這是一種把運算、儲存與叢集管理整合在相同節點的部署方式。
這樣不需要另外準備一台中央 NAS 或 SAN，而且新增節點時可以一起增加運算與儲存能力。代價是 VM 工作負載與 Ceph 的複寫、復原及重新平衡會共用 CPU、RAM、磁碟與網路。
RAID 與單一 ZFS 儲存池主要處理一台主機內的磁碟，Ceph 則把資料分散到多台主機。以下從最底層的區塊裝置開始，逐層介紹資料如何變成 PVE 可用的共享儲存。
區塊裝置（Block Device）可以是一整顆 HDD、SSD、NVMe Namespace，也可以是磁碟分割區或 LVM 邏輯卷（LVM Logical Volume）。建立儲存服務時，所選裝置上的既有內容會被清除。
PVE 最常見且最容易維護的做法，是為每個儲存服務準備一顆專用、沒有資料的完整磁碟。Ceph 的 ceph-volume lvm 會在裝置上建立與標記所需的 LVM 結構。
RADOS 是 Ceph 底層的分散式物件儲存層。PVE 寫入 Ceph 的資料會被拆成許多物件（Object），它是 Ceph 處理複寫、校驗與重新配置的基本資料單位。
物件儲存守護程序（Object Storage Daemon，OSD）是 Ceph 實際管理磁碟與保存物件的服務。
OSD 會彼此交換心跳（Heartbeat）以確認存活狀態，並執行副本複寫、復原、回填（Backfill）、資料校驗（Scrub）與深度資料校驗（Deep Scrub）。復原著重補回遺失或落後的物件。回填則常見於 OSD 加入、移除或放置規則改變後，把較大量資料重新配置到新的位置。
BlueStore 是 OSD 使用的儲存後端，會直接在區塊裝置上管理資料，不需要先建立 ext4 或 XFS。它使用 RocksDB 保存中繼資料，並使用預寫式日誌（Write-ahead Log，WAL）協助處理寫入。
小型環境可以讓資料、RocksDB 與 WAL 共用同一顆 OSD 裝置。大型或 HDD 環境可能把 DB／WAL 放在較快的 SSD 或 NVMe 上。主要 OSD Device 與額外 DB/WAL Device 是不同用途，不能在建立畫面中同時選同一顆 /dev/sdb。
儲存池（Pool）是 Ceph 的邏輯儲存區。不同儲存池可以共用同一批 OSD，卻分別設定用途、權限、資料副本與後續的放置規則。
size=3 代表每份資料預計保存三份。min_size=2 代表至少要有兩份可用副本，儲存池才允許一般寫入。這兩個值描述資料保護條件，還沒有決定三份副本要落在哪三顆磁碟。
物件不會直接綁死在固定 OSD，它透過雜湊分配到放置群組（Placement Group，PG）。PG 位於物件與 OSD 之間，Ceph 可以整組處理同儕狀態確認（Peering）、複寫與重新配置，不必為每個物件維護一筆中央位置紀錄。
PG 太少可能造成資料分布不均，太多則會增加同儕狀態確認、CPU 與記憶體負擔。PG 自動調整器（PG Autoscaler）會依 OSD 數量、儲存池使用比例與設定目標提出或套用較合適的 PG 數量。
可控複寫雜湊演算法（Controlled Replication Under Scalable Hashing，CRUSH）會根據 OSD、主機（Host）、機架（Rack）等階層及規則（Rule），計算 PG 應放到哪些 OSD。故障域（Failure Domain）則指定副本必須分散到哪一層。本系列以 host 為故障域，三份副本會分散到三台 PVE。
到這裡，最底層的資料關係才完整：
圖（四）Ceph 從儲存池到實體磁碟的資料關係
Ceph 由多種守護程序（Daemon）共同維持：
| 元件 | 責任 |
|---|---|
| 監視器（Monitor，MON） | 維護描述叢集目前狀態的叢集映射（Cluster Map），並由多數 MON 建立 Ceph 自己的法定票數 |
| 管理器（Manager，MGR） | 提供統計、管理介面、儀表板與其他功能模組，通常保留作用中／待命（Active／Standby） |
| 物件儲存守護程序（OSD） | 實際保存物件，並執行複寫、復原、資料校驗（Scrub）與重新平衡 |
MON 保存的是叢集狀態與映射。MGR 負責管理、統計與模組功能。真正承載資料的是 OSD。PVE 的 Corosync／votequorum 與 Ceph MON 法定票數是兩套彼此獨立的多數決，不能只看其中一套是否正常。
叢集映射是 Ceph 對目前 MON、OSD、儲存池與 CRUSH 規則等狀態的共同認知，由 MON 維護版本。用戶端（Client）取得最新映射後，可以自行計算資料位置，不必讓每次 I/O 都經過 MON。
每個 PG 會有一個主要 OSD（Primary OSD）協調寫入，再將資料送往同一組的副本 OSD（Replica OSD）：
PVE／QEMU 用戶端取得叢集映射
→ 依儲存池與物件識別碼算出 PG
→ CRUSH 算出 OSD 組合
→ 主要 OSD 協調副本 OSD 寫入
→ 達到確認條件後回覆用戶端
Ceph 文件中的公用網路（Public Network）同樣不是 WAN。它是 Ceph 用戶端、MON 與 OSD 對外提供服務時使用的網路。叢集網路（Cluster Network）則主要承載 OSD 之間的心跳、副本複寫、復原與回填流量。
Public Network 與 Cluster Network 可以共用網段，也可以分離。本系列將 Ceph 流量放在獨立於管理、VM 與 Corosync 的 10.77.70.0/24。受限於 Lab，兩種 Ceph 流量共用這個網段。
建立 ceph-vm 後，三台 PVE 已經有共享儲存，但在建立 VM 時會發現它只能放 VM 磁碟，不能上傳 ISO。原因是 RBD 與 CephFS 對外提供的儲存介面不同。
RBD 把 Ceph 物件組合成類似硬碟的區塊裝置。PVE 建立 VM 磁碟時，客體作業系統（Guest）看到的是一顆虛擬 SCSI／VirtIO 磁碟，底層資料則由 Ceph 分散到 OSD。
ISO 則是一個需要檔名與目錄位置的靜態檔案。PVE 必須能在類似 template/iso/ 的目錄中列出、上傳、刪除與選取 ISO，因此需要 NFS、CIFS、目錄（Directory）或 CephFS 這類檔案層級儲存（File-level Storage）。RBD 雖然是共享儲存，卻不是一般共享資料夾。
簡單來說，RBD 提供的是虛擬硬碟，不是可直接列出檔名的共享資料夾。若要保存 ISO 等靜態檔案，就需要使用 CephFS 提供檔案系統介面。
CephFS 是建立在相同 RADOS／OSD 之上、符合 POSIX 介面的檔案系統（POSIX File System）。對 PVE 來說，它會掛載成一般目錄，例如 /mnt/pve/cephfs/，裡面可以存放 debian.iso、opnsense.iso 這類靜態檔案。
三台 PVE 掛載的是同一個 CephFS，因此只要在 pve01 上傳一次 ISO，pve02、pve03 也能看到同一個檔案。CephFS 中只有一個邏輯檔案，但 Ceph 會依儲存池的副本規則保存多份底層資料。實際用量約為檔案大小乘以副本數。
CephFS 需要以下元件共同工作：
| 元件 | 在 CephFS 中的責任 |
|---|---|
| MON | 維護 Ceph 叢集映射與法定票數 |
| MGR | 提供管理、監控與模組功能 |
| OSD | 實際保存中繼資料與檔案資料的物件 |
| MDS | 管理目錄樹、檔名、權限與其他檔案中繼資料 |
| 中繼資料儲存池（Metadata Pool） | 保存 CephFS 的目錄與中繼資料 |
| 資料儲存池（Data Pool） | 保存檔案實際內容 |
MDS 的工作比較像分散式檔案系統的目錄管理者：當用戶端要開啟 /template/iso/debian.iso，MDS 協助解析路徑與權限，真正的檔案資料由 OSD 保存。
CephFS 至少需要一個作用中的 MDS 才能正常提供中繼資料操作。在兩個以上 MDS 的狀況，正常情況下一個為作用中、其他為待命。作用中的 MDS 故障時，待命 MDS 可以接手。
正文已經說明 Corosync、法定票數與 Ceph 的分工。接下來透過三節點 PVE 叢集、受控故障與兩種 Ceph 儲存驗證實際結果。
GitHub 詳細部署文件：Day 07｜建立 PVE Cluster 與 Ceph
本次實作使用 10.77.80.11～.13 作為 Corosync Link 0，使用 10.77.70.11～.13 作為 Ceph 網路，並將三顆 40GiB 空白磁碟建立為三個 OSD。核心驗證分成三部分：
本日先驗證法定票數如何隨節點狀態改變。下一篇加入 VM 故障接手後，再實際量測 RTO 與檢查 RPO。
建立叢集前先確認三台主機時間一致，且 10.77.80.11～.13 能直接互通。完成加入後，在任一正常節點執行：
pvecm status
pvecm nodes
corosync-cfgtool -s
journalctl -u corosync --since '-10 min' --no-pager
pvecm status 應顯示 Cluster information 中的名稱為 iron-lab，Expected votes 與 Total votes 都是 3，而且 Quorate: Yes。Membership information 應列出三個 10.77.80.x 位址。這些結果證明三台節點已形成同一個叢集，Corosync 也確實使用規劃的 Link 0，不能是暫時建置用的管理網路。
圖（五）iron-lab 已形成三節點成員關係，Expected votes 與 Total votes 都是 3，並取得法定票數。
故障前先從 L0 開啟三台巢狀 PVE 的 Console，並在正常節點執行 pvecm status 記錄基準。每次停止或恢復節點後，再記錄一次法定票數狀態。輸出中的 Date 可用來對照狀態改變時間。
先停止一台節點。Expected votes 仍為 3，Total votes 降為 2，叢集保有多數票，因此 Quorate 維持 Yes。
圖（六）三票叢集剩下兩票時依然取得法定票數。
再停止第二台節點。此時 Total votes 只剩 1，低於兩票門檻，Quorate 會變成 No，需要一致性決策的叢集操作也會受到限制。
圖（七）只剩一票時失去法定票數，叢集活動受到保護機制限制。
這項結果證明法定票數保護的是叢集決策一致性。失去法定票數不代表既有 VM 一定立即關機，也不代表離線節點上的 VM 已經由其他節點接手。依序重新啟動另外兩個節點後，再執行 pvecm status，確認 Total votes 回到 3、Quorate: Yes，才進入 Ceph 部署。
| 觀察階段 | Total votes | Quorate | 核心結果 |
|---|---|---|---|
| 三台都在線 | 3 | Yes | 叢集正常取得多數票 |
| 停止一台 | 2 | Yes | 可進行一致性決策 |
| 再停止一台 | 1 | No | 阻止單一節點自行修改叢集狀態 |
| 恢復全部節點 | 3 | Yes | 控制平面恢復正常 |
三台節點恢復 3/3 法定票數後，才安裝相同版本的 Ceph，並以 10.77.70.0/24 初始化 Ceph 叢集。每台節點各提供一個 MON 與一個 40GiB OSD，pve01、pve02 另外執行 MGR。詳細的套件庫（Repository）、安裝、初始化與建立欄位留在實作文件。
建立 ceph-vm RBD 儲存池後，在任一節點執行：
ceph -s
ceph osd tree
ceph pg stat
pvesm status
核心結果是三個 MON 取得法定票數、三個 OSD 都為 up／in、PG 為 active+clean，而且 PVE Storage 出現 ceph-vm。RBD 至此已能作為三台 PVE 共用的 VM 磁碟儲存空間。
圖（八）Ceph 顯示 HEALTH_OK，三個 OSD 均為 up，ceph-vm 也已加入 PVE Storage。
接著建立 cephfs，並在 pve01、pve02 部署 MDS。驗證時執行：
ceph fs status cephfs
ceph mds stat
pvesm status
ceph fs status 應顯示一個作用中的 MDS 與一個待命 MDS，pvesm status 則應同時列出 ceph-vm 與 cephfs。這證明同一套底層 OSD 能透過 RBD 提供區塊儲存，也能透過 CephFS 提供共享檔案。
圖（九）CephFS 已形成一個作用中的 MDS 與一個待命 MDS，ceph-vm 和 cephfs 也都顯示為 active。
最後再次檢查 PG 與 PVE Storage：
圖（十）所有 PG 均為 active+clean，PVE 也顯示 ceph-vm 與 cephfs 兩種共享儲存為 active。
本 Lab 另外替 CephFS 根目錄設定 5GiB 配額（Quota），目的是限制教學環境上傳 ISO 使用的邏輯容量。它不是 CephFS 成立的必要條件，也不是預先切出一顆 5GiB 磁碟。配額、PG 數量與自動調整器的實際操作及檢查留在實作文件。
目前的結果證明 Ceph 已正確部署並能提供兩種共享儲存。HEALTH_OK 只代表當下狀態正常，Ceph 的故障容錯要另外透過節點或 OSD 故障實驗驗證。
| 正文概念 | Lab 證據 | 可以證明的結果 |
|---|---|---|
| Corosync 與成員名單 | pvecm status、corosync-cfgtool 與 Link 0 紀錄 |
三台節點透過規劃的專用網路形成同一個叢集 |
| 投票與法定票數 | 三票、兩票、一票及恢復後的狀態 | 只有取得多數票的一側可以繼續進行一致性決策 |
| Ceph OSD、MON 與 PG | ceph -s、ceph osd tree 與 ceph pg stat |
Ceph 服務已形成法定票數，三個 OSD 可用且資料群組為乾淨狀態 |
| RBD 與 CephFS | pvesm status 與 ceph fs status |
三台 PVE 能使用同一套 Ceph 提供的區塊儲存與共享檔案 |
iron-lab，並確認 Corosync 使用規劃的 Link 0。ceph-vm RBD，並確認 Ceph 達到 HEALTH_OK。ceph-vm 與 cephfs 共享儲存。下一篇是 Day 08｜節點故障後 VM 如何接手：Proxmox VE 遷移、HA 隔離與恢復時間量測。我們會把測試 VM 加入 HA Resources，比較線上／離線遷移與節點故障後的 HA 接手流程，並量測不同情境下的中斷與恢復時間。
iThome鐵人賽
看影片追技術