共享儲存選 NFS、iSCSI 還是 Ceph？2026 年這題的答案變了

最近看到一位社群開發者，為了讓 Proxmox VE 能真正「管理」Synology 的 SAN，自己寫了一個儲存外掛——因為 Synology 沒有完整公開 SAN Manager API，他得交叉參考官方 CSI 驅動、OpenStack Cinder 驅動，再拿實機行為當最終依據。

一個人願意做到這種程度，通常代表兩件事：這個痛點是真的，而且原生方案沒有解決它。

這篇就從這裡談起：虛擬化叢集的共享儲存，2026 年該怎麼選。

先講三條路線的本質差別

Proxmox VE 的共享儲存實務上只有三條路：NFS（檔案層）、iSCSI/FC 搭 LVM（區塊層）、Ceph（分散式）。

差別不在效能數字，而在你把複雜度放到哪裡。

• NFS 把複雜度留在 NAS 上。PVE 只負責掛載，虛擬磁碟就是 NAS 上的 qcow2 檔案，快照存在檔案內部。
• iSCSI + LVM 把複雜度攤在每一台 PVE 節點上。你拿到的是裸區塊裝置，要自己用 LVM 切、自己設多重路徑。
• Ceph 把複雜度變成一套要長期照顧的分散式系統，換來「沒有單一儲存伺服器可以壞」。

iSCSI 路線最容易被低估的兩件事

第一件：精簡配置會消失。

在 iSCSI 上用標準 LVM（也就是 Proxmox 支援的做法）就沒有精簡配置。想用 LVM-thin 拿回精簡配置與快照？LVM-thin 根本不是為多主機共享存取設計的，在叢集裡不能當共享儲存用。

這不是設定問題，是架構限制。很多人是等到儲存空間被吃光才發現「我以為我開了精簡配置」。

第二件：多重路徑是每台機器的事。

multipath 要在每一個 PVE 節點各自設定與維護。三節點還好，十節點就是十份設定要對齊，而且新加節點時很容易漏。

回到開頭那個外掛——它想解決的正是這一整層落差：PVE 原生可以使用 iSCSI，但不會去管理 SAN 那一端。建立、刪除、擴充虛擬磁碟時，SAN 上的 LUN 不會跟著動；出事時你要在 PVE、LVM、iSCSI、儲存設備四層之間交叉比對。

2026 年變了什麼：區塊儲存終於能快照

過去「要快照就別選 iSCSI」幾乎是鐵律。Proxmox VE 9 打破了它。

新做法叫「快照即磁碟區鏈」：在 thick provisioned 的 LVM 上疊 qcow2，快照用外部覆蓋層記錄差異。這讓 iSCSI 與 FC 接的 SAN 也能做虛擬機快照，而且與儲存廠牌無關——不需要儲存設備支援什麼特殊功能。

聽起來很美好，但代價要看清楚：

• 目前是技術預覽，不是穩定功能
• 必須 thick provisioning，基礎映像和快照都要配足空間，等於再次放棄精簡配置
• qcow2 相較 raw 有 30–90% 的效能衰減
• 使用 TPM 的虛擬機不支援快照

換句話說：這解決的是「能不能」，不是「該不該」。如果你的工作負載對 I/O 敏感，那個效能區間的上緣足以讓人重新考慮。

我們自己踩的坑：NFS 版本

這一段是我們自己生產環境的經驗。先把範圍講清楚：我們的叢集走 NFS，iSCSI SAN 與 Ceph 沒有生產部署——所以前面兩段是公開資料與規格，這一段才是實測。我們寧可先說清楚界線，也不想讓你照著一份沒人驗證過的建議做決策。

我們的坑出在掛載參數。

Proxmox 掛 QNAP 這類 NAS 時，如果走 NFS v4.1，會出現 lease 過期導致掛載變成 stale。這件事本身不致命，致命的是後果：vzdump 備份任務跟著失敗，而且沒有明顯告警。

備份任務在跑、看起來也有排程紀錄，但實際上寫不進去。我們是好幾天後才發現的。

從此我們的規範是一律指定 vers=3，而且這條規則是寫進文件的，不是靠記憶。

這件事真正的教訓其實不是 NFS 版本，而是：

儲存故障最危險的形態不是「壞掉」，是「安靜地不工作」。

所以我們現在對備份的要求不是「有沒有跑」，而是「備份新鮮度有沒有被監控、失敗會不會主動通知」。選哪條儲存路線，都要回答這個問題。

一份可以照著走的判斷順序

不要從「哪個比較好」開始，那沒有答案。照這個順序問：

1. 你已經有 SAN 投資了嗎？ 有 → iSCSI/FC 是合理起點，沉沒成本是真的成本。 沒有 → 直接跳過 iSCSI，它的維運複雜度不值得為了「聽起來比較專業」而承擔。

2. 你需要虛擬機快照嗎？ 需要，而且走 iSCSI → 你現在有 PVE 9 這條路，但要接受技術預覽狀態與效能代價，先在非關鍵系統實測你自己的工作負載，不要看別人的數字。 需要，但沒有 SAN 包袱 → NFS + qcow2 是阻力最小的路，快照直接存在映像檔裡。

3. 儲存能不能有單一故障點？ 不能 → Ceph 是唯一原生答案，但要誠實評估：你有沒有人能長期照顧它？沒有人養的 Ceph 比單台 NAS 更危險。 可以（有備份與復原時間目標即可） → NFS 或 iSCSI 都行。

4. 你的團隊出事時查得動幾層？ 這題最少人問，卻最決定成敗。iSCSI 出事要跨四層排查，Ceph 出事要懂 CRUSH map 與 PG 狀態。如果半夜只有一個人待命，選你查得動的那條。

5. 不管選哪條，先把「備份會不會安靜失敗」解決掉。 掛載參數、備份新鮮度監控、還原演練——這三件沒做，選什麼儲存都一樣。

最後

這題沒有通用答案，但有通用錯誤：照著別人的架構圖抄，卻沒有對方的維運能量。

我們選 NFS 不是因為它最好，是因為它的失敗模式我們扛得住、也監控得到。你的答案可能不一樣，但推導過程應該是一樣的。

如果你正在做這個決策，或是想確認現有的備份是不是真的有在寫，我們可以直接談實際的組態與量測方式。