Proxmox Ceph 規劃：架構選擇、需求問題與驗證清單
在選擇共享儲存之前，團隊需要先說清工作負載、故障承受方式與維運責任。本文把 Ceph 的架構問題整理成可討論的規劃清單。
故障域是可能因同一事件一起失效的一組資源，例如共用電源的伺服器或同一機櫃內的設備。共用交換器或電源，都可能讓多台主機一起失效；先採購節點、再補寫容錯需求，會讓虛擬化架構的判斷失去依據。
重點摘要
- 先確認可接受的中斷與資料損失。
- 將服務需求整理成工作負載需求表。
- 以故障域草圖標出共用設備。
- 把維運責任納入架構選擇。
- 在部署前寫下可檢查的驗收條件。
團隊先辨認 Ceph 位於虛擬化平台的哪一層，以及它與哪些資源相依，再討論設備配置。
Proxmox VE 中的 Ceph 扮演什麼角色
一台同時承載 VM 與 Ceph 儲存服務的主機離線，會讓團隊同時失去運算與儲存資源。Ceph 為 Proxmox VE 提供分散式儲存，儲存規劃不能只看磁碟，還要考慮服務接手與資料重建所需的資源。
Proxmox VE 整合 KVM 虛擬機器、Linux 容器（LXC）、軟體定義儲存與網路，並提供網頁管理介面，功能範圍可參閱 Proxmox VE 產品功能。共享儲存不等於客體會自動恢復服務，儲存可用性與高可用性設定必須分開判斷。
VM 或容器使用 Proxmox VE 配置的儲存；選用 Ceph 後，資料存取還會經過 Ceph 服務、實體網路與磁碟。運算與儲存共用節點稱為超融合架構（HCI），兩類服務會競爭資源，也受同一次主機維護影響。
上述主機離線時，剩餘主機既要承接客體，又要承擔資料重建。重建會使用磁碟、網路與運算資源，不能只以正常運作時的閒置記憶體判斷餘裕。運算與儲存分離能分開安排部分維護，但仍依賴儲存網路與後端可用性。
團隊整理 proxmox 共享儲存需求時，須另列 VM 重新啟動與遷移條件；資料仍可讀取，不代表應用已恢復。先釐清資料用途：服務需要的是虛擬磁碟，還是共同存取的檔案空間？
RBD 與 CephFS：先釐清儲存用途
要存放 VM 的虛擬磁碟，先評估 RBD；要提供共同的檔案與目錄空間，才評估 CephFS。兩者同屬 Ceph，但提供給使用端的介面不同，不能只因底層相同就互換用途。
Ceph RBD 提供區塊裝置，CephFS 提供共享檔案系統。多個節點能存取 RBD，不代表一般檔案系統能安全地由多方同時寫入；存取權限與寫入協調是不同問題。
| 比較面向 | Ceph RBD | CephFS |
|---|---|---|
| 提供介面 | 區塊裝置 | 檔案與目錄 |
| 對應用途 | 客體虛擬磁碟 | 叢集共享檔案 |
| 檔案系統中繼資料管理 | 由使用該區塊裝置的檔案系統處理 | 由 MDS 處理 |
資料庫 VM 的系統碟與資料碟，可對應到 Ceph RBD；需要共同檔案與目錄的工作流程，則評估 CephFS。CephFS 的中繼資料伺服器（MDS）負責管理檔案系統中繼資料，不是替資料庫協調交易。
一般客體檔案系統與應用程式的一致性，仍須在客體與應用層處理。團隊也要分別確認儲存用途，以及 Proxmox VE 各儲存後端支援的內容類型，不能由「可以存檔案」直接推論所有客體內容都受支援。每項用途都應配上實際工作負載與可接受的故障影響。
從工作負載與故障情境整理需求
先請應用負責人回答：尖峰時段最不能接受的是延遲增加、服務中斷，還是資料回退？工作負載評估要把答案轉成可核定的服務條件，而不是只留下「需要高可用」的描述。
復原點目標（RPO）描述可接受的資料損失時間範圍；復原時間目標（RTO）描述可接受的服務復原時間。節點數本身不能證明容量、效能與故障後餘裕足夠，三節點示範也不是通用的規模配置標準。
- 工作負載有哪些讀寫比例、隨機與循序存取、尖峰併發及延遲要求？交付物：負載清冊，逐項記錄應用、資料用途與尖峰時段。
- 資料量如何成長，快照與備份各保留多久？交付物：容量成長假設，註明估算期間與保留政策，避免將備份空間漏算。
- 磁碟、主機、交換器或電源失效時，哪些服務必須繼續運作？交付物：故障情境矩陣，對應受影響設備、服務及可接受狀態。
- RPO、RTO 與維護窗口由誰核定？交付物：服務目標，記錄核定人及適用服務，不以維運團隊的推測代替業務決定。
- 誰負責監控、故障處理與夜間升級支援？交付物：值班責任表，列明接手人、通知方式與升級處理路徑。
資料庫可能重視交易延遲，批次備份可能重視作業窗口內的循序吞吐量，一般辦公 VM 則可能在登入時集中存取。團隊應分開記錄這些需求，不能用平均負載抹平尖峰差異。
故障情境還要納入「既有設備尚未修復，又必須進行維護」：剩餘資源是否仍符合服務目標？將已確認的需求作為 Ceph 與本機 ZFS 的選擇依據，而不是先替技術評分。
Ceph 與本機 ZFS 的決策問題
若工作負載不需要共享後端，團隊為何要承擔分散式儲存的維運範圍？Ceph 與 ZFS 的選擇應由資料位置、復原方式及團隊能力決定，不是預設哪一種普遍較快或較可靠。
本機 ZFS 的資料位於所屬節點。Proxmox VE 支援以 ZFS 進行非同步客體磁碟複寫，但非同步複寫不是共享儲存，目標端可能落後於來源端。評估資料損失時，須計入最後成功複寫之後的資料差距。
| 決策問題 | Ceph 評估方向 | 本機 ZFS 評估方向 |
|---|---|---|
| 需要共同存取同一儲存後端嗎 | 評估共享後端與存取需求 | 確認本機資料配置及跨節點資料移動方式 |
| 容許複寫時間差嗎 | 依資料保護與故障域設計判斷 | 若採非同步複寫，將資料差距納入 RPO |
| 擴充以什麼為單位 | 評估儲存叢集擴充及資料重新分布 | 評估各節點容量與客體放置 |
| 團隊能維護哪些相依系統 | 承接分散式儲存及儲存網路維運 | 承接各節點 ZFS 與複寫維運 |
若共享需求明確，且團隊能承接分散式儲存維運，就深入評估 Ceph。若資料局部性明確，且團隊能接受相應的復原方式，就評估本機 ZFS；不能只因已有複寫，就假設任何節點隨時持有相同資料。
管理與儲存設定的延伸閱讀可參閱 Proxmox VE 管理手冊，實際操作程序須對應目標部署版本。候選架構仍須通過容量、網路與故障恢復驗證，才能定案。
容量、網路與維運驗證清單
只有正常狀態能跑，不足以證明架構能在故障後支撐服務。proxmox ceph 規劃必須驗證正常、故障與維護期間的服務表現，並留下能與需求逐項對照的證據。
驗收門檻由服務需求核定，並在演練前寫下。容量成長、資料保護與資料重建空間都會減少可配置給業務的容量；網路備援也必須涵蓋實體路徑，不能只以 VLAN 數量判斷。
- ☐ 容量：分別記錄原始容量、資料保護後可用容量與業務可配置容量，保留容量成長及資料重建空間。留下證據：容量模型，註明保護方式與預留用途。
- ☐ 故障域：在隔離環境模擬磁碟或節點離線，核對剩餘資源與服務狀態。留下證據：事件時間線，記錄故障、偵測、服務恢復及資料重建的時間。
- ☐ 網路：盤點管理、叢集通訊、客體與儲存流量路徑，驗證實體路徑切換。留下證據：拓樸與連線紀錄，標明共用網卡、交換器及切換結果。
- ☐ 負載：以代表性工作負載比較正常與資料重建期間的延遲、吞吐量和應用錯誤。留下證據：對照紀錄，保留相同測試條件與負載設定。
- ☐ 維運：確認告警收件人、權限、維護步驟與失敗退出條件。留下證據：責任表和操作程序，明列停止操作及恢復原狀的條件。
- ☐ 復原：執行備份還原，由應用負責人核對資料與服務。留下證據：復原時間及完整性檢查紀錄，不以還原作業顯示成功代替應用驗收。
正常服務與資料重建可能競爭網路和磁碟資源，只測空載無法代表尖峰。VLAN 不能消除共用網卡或交換器的實體故障，只拔除一條邏輯連線也不足以證明備援有效。
操作流程的延伸閱讀可參閱 Install Ceph Server on Proxmox VE 示範，示範不能代替環境驗收。團隊應先為未通過項目補齊責任人與改善動作，再安排部署或進一步學習。
文件、示範與 Clustering and Shared Storage 學習下一步
把尚未通過的驗證項目整理成團隊的文件核對與學習清單。後續 proxmox ceph 維運培訓應對應實際缺口；文件用來核對目標部署版本、相容性與維護程序，示範則用來理解操作流程，不直接沿用不同版本的安裝步驟。
Proxmox VE Clustering and Shared Storage 涵蓋 HCI、Ceph RBD、CephFS、維護、ZFS 非同步客體磁碟複寫，以及 HA 與 Ceph 故障情境演練；先備要求為完成 Proxmox VE Deployment and Management。
團隊應以「用需求選架構、用證據驗收」安排學習優先順序，並將改善項目帶回操作程序。帶著需求表與故障情境，查看中文培訓資訊。