本文目錄
Ceph 並不是不能使用 HDD，但如果主要用途是承載 PVE 上的 VM、資料庫及企業應用系統，HDD 通常無法提供穩定的延遲與足夠的 IOPS。
省下來的可能只是硬碟採購費用，後續卻可能付出更多效能、維運及故障復原成本。就算採用 HDD 搭配 SSD 的混合配置，也一樣不建議拿來當主要的 VM 儲存。
VM 與資料庫以小區塊隨機 I/O 為主
VM 內同時包含作業系統、應用程式、資料庫、Log 及各種背景服務。因此，實際磁碟行為不是單純的大檔案連續讀寫，而是大量的：
- 4K、8K 等小區塊 I/O
- 隨機讀取與隨機寫入
- 多台 VM 同時存取
- 短時間突發 I/O
而「隨機 I/O」正是 HDD 最大的弱點。
HDD 必須依靠磁頭尋軌與碟片旋轉。即使規格標示的循序傳輸速度不差，遇到大量隨機讀寫時，IOPS 與延遲仍遠不如 SSD，量級差距可以參考下圖。
企業環境常見約 70% 讀取、30% 寫入
企業 VM 與資料庫規劃，常以約 70% 讀取、30% 寫入作為混合負載的估算基準。
雖然讀取比例較高，但這些讀取通常不是單一大檔案的連續讀取，而是多台 VM 共同產生的大量小區塊隨機讀取。
HDD 的磁頭必須不斷尋軌，I/O Queue 很容易快速累積，進而造成：
- VM 開機及登入變慢
- Windows Update 時整批 VM 卡頓
- 資料庫查詢反應時間不穩定
- 應用程式偶發停頓
- PVE 管理及磁碟操作延遲
- 同一組 OSD 上的 VM 互相影響
因此，評估 VM 儲存效能時，不能只看硬碟標示的 MB/s，更重要的是：
- 隨機 IOPS
- 平均延遲
- Queue Depth
- 高負載時的尾端延遲
Ceph 三副本會進一步放大寫入負載
假設 Ceph 採用三副本，一筆 VM 寫入必須分散寫入多個 OSD，完成必要副本寫入後才能回應客戶端。
因此，企業環境中的 30% 寫入並不是單純的 30% 磁碟負載，還會受到下列因素放大：
- 三副本寫入
- BlueStore metadata 操作
- RocksDB 與 WAL/DB 操作
- Ceph 網路傳輸
- 資料一致性處理
只要其中某顆 HDD 忙碌、老化或延遲突然升高，就可能影響相關 PG，進而拖慢多台 VM。
多台 VM 共用時 HDD IOPS 很快耗盡
單顆 HDD 的隨機 IOPS 能力有限。
當多台 VM 同時進行資料庫查詢、系統更新、Log 寫入、檔案掃描或備份作業時，所有工作負載都會競爭 OSD 的磁頭與 IOPS。
因此，HDD Ceph 常見的問題不是完全不能運作，而是：
測試階段與低負載時看起來正常，正式上線且 VM 數量增加後，延遲開始不穩定；遇到備份、更新、維護或故障時，效能則明顯下降。
這種問題也很難透過單純增加 CPU、記憶體或網路頻寬解決，因為真正的瓶頸仍然在 HDD 的隨機 I/O 能力。
HDD 故障後的重建時間較長
HDD 或節點故障後，Ceph 必須執行 recovery/backfill，把缺少的副本重新分散到其他 OSD。
此時磁碟必須同時處理：
- 正常 VM I/O
- 資料複製與重建
- PG recovery/backfill
- Scrub 與其他 Ceph 背景工作
如果提高重建速度，VM 效能就會明顯下降；如果限制重建速度，叢集又會長時間維持 degraded 狀態，增加重建期間再次發生硬碟或節點故障的風險。
Proxmox 官方也建議小型 Ceph 環境使用 SSD，以縮短復原時間並降低復原期間再次故障的風險。
日常維護也會造成 HDD 效能抖動
即使沒有發生硬碟故障，以下作業仍會產生大量背景 I/O：
- Scrub/deep-scrub
- VM 快照
- VM 備份
- Live Migration
- 新增或移除 OSD
- CRUSH 資料重新分布
- 節點重新開機後的 recovery
SSD 擁有較大的 IOPS 餘裕，可以同時處理前景與背景工作。
HDD 則很容易進入高 Queue Depth，造成整體 VM 延遲突然升高。最後看到的可能是 Ceph 狀態仍然正常，但 VM 與應用系統的反應已經明顯變慢。
HDD 容量便宜不代表整體建置成本較低
Ceph 採用三副本時，可用容量約為原始容量的三分之一，另外還必須保留足夠空間供資料重新分布與故障復原使用。
如果為了補足 HDD 的 IOPS 而增加更多硬碟，還會增加：
- 硬碟槽位及伺服器成本
- HBA、線路及背板成本
- 電力與散熱成本
- 硬碟故障率及更換次數
- Recovery 所需時間
- 維運及障礙排除成本
最終節省的可能只是硬碟本身的採購單價，卻增加了整套系統生命週期的總持有成本。
SSD DB/WAL 無法完全解決 HDD 的效能瓶頸
將 BlueStore DB/WAL 放在 NVMe 或 SSD，可以改善部分 metadata、RocksDB 與寫入操作。
但是，實際 VM 資料仍然存放在 HDD，因此下列工作仍會受到 HDD 限制：
- VM 隨機讀取
- VM 資料寫入
- Recovery/backfill
- Scrub
- 多台 VM 同時存取
這種混合配置只能改善 HDD Ceph 的部分操作，無法讓 HDD OSD 達到全 SSD Ceph 的 IOPS 與延遲表現。
此外，DB/WAL 與多顆 HDD OSD 共用同一顆 SSD，也會增加裝置配置及故障相依性的複雜度。
HDD Ceph 的適用場景
HDD Ceph 比較適合容量需求高，但不要求高 IOPS 與低延遲的工作負載，例如：
- 以大檔案循序存取為主、使用人數不多的 File Server
- Archive Server/歸檔伺服器
- 長期保存且不常讀取的冷資料
- 影音、ISO、映像檔等大型靜態檔案
- Log 歷史資料及合規留存資料
- 低頻率存取的次要資料
需要注意的是，File Server 如果包含大量小檔案、多人同時存取、頻繁搜尋索引或防毒掃描，一樣會產生大量隨機 I/O，也未必適合使用 HDD。
建議將 HDD 與 SSD 分成不同的 Device Class、CRUSH Rule 及 Pool：
| 儲存集區 | 建議用途 |
|---|---|
| SSD Pool | VM、資料庫、作業系統及高 IOPS 應用 |
| HDD Pool | File Server、大型靜態檔案、Archive 及冷資料 |
注意：不要將 HDD 與 SSD 混在同一個主要 VM Pool，否則整體效能仍可能受到 HDD OSD 影響。
規劃工具
規劃全 SSD 的 PVE Ceph 時，可以搭配我做的兩支線上工具，都放在 IT @ Jason Tools，純前端計算、免註冊。兩支工具的硬碟選項都只有 SSD，這也是刻意的。
PVE Ceph 容量計算機
輸入需求的可用容量，選擇 SSD 規格與副本策略，工具會自動建議節點數與每節點 SSD 數量，並列出原始容量、可用容量、容錯能力，以及每台節點的記憶體需求估算。
PVE Ceph 網路計算機
依照 OSD 硬碟類型與數量、VM 負載與副本策略，估算 Public Network 與 Cluster Network 需要的頻寬，並建議交換器規格。也會提醒 corosync 跟 Ceph 併用同一組網路的風險。
結論
Ceph 可以使用 HDD，但必須依照實際工作負載分類。
VM 與資料庫本身會產生大量小區塊隨機 I/O，而隨機 I/O 正是 HDD 最大的弱點。當三副本、多台 VM 共用、備份、Scrub 與故障重建同時存在時，HDD 很難維持企業環境所需要的穩定延遲與服務品質。
因此：
- 正式承載 VM、資料庫及企業應用系統的 PVE Ceph，建議採用具備 PLP 的企業級 SSD。
- 不建議採用消費級 SSD 承載正式 Ceph 工作負載。
- HDD 適合低 IOPS、大容量、循序存取或冷資料。
- HDD 應建立獨立 Pool，不要與主要 VM 工作負載混用。
我不是認為 Ceph 不能使用 HDD，而是不建議使用 HDD 承載對延遲敏感的 VM 與資料庫。HDD 可以用在適合的場景，但主要 VM 儲存集區應以企業級 SSD 為優先。
參考資料
- Proxmox VE 官方文件：Deploy Hyper-Converged Ceph Cluster
https://pve.proxmox.com/pve-docs/chapter-pveceph.html - Ceph 官方文件：BlueStore Configuration Reference
https://docs.ceph.com/en/latest/rados/configuration/bluestore-config-ref/ - IT @ Jason Tools：PVE Ceph 容量計算機
https://it.jason.tools/tools/pve-ceph-size-calc.html - IT @ Jason Tools：PVE Ceph 網路計算機
https://it.jason.tools/tools/pve-ceph-net-calc.html - Proxmox VE 儲存架構表
https://blog.jason.tools/2024/09/proxmox-ve-storage-choice.html
