自 2023 年起，我以 Operator 的角色規劃與維運 Proxmox VE、Proxmox Backup Server（PBS）、GPU server 與 On-prem infrastructure，承載 internal services、AI runtime workload，並負責整體的 backup strategy。

這篇不是安裝教學，而是整理我在這類中小型地端環境裡比較在意的規劃原則，以及維運時實際踩過、也在 blog 記錄過的問題。文中不會提到任何主機名稱、IP、網段配置或資安細節；涉及設定建議的地方，都是一般性的做法，並以 Proxmox 官方文件為準。

背景與需求

地端環境的需求通常很實際：有一批 internal services 要長期穩定運作，有 AI workload 需要 GPU，還有資料必須能備份、能還原。預算與人力有限，所以選擇的平台要能讓少數人就維護得動。

Proxmox VE 適合這種情境：VM 與 LXC container 可以在同一個介面管理，cluster、storage、backup 都有內建的做法，搭配 PBS 就能有 incremental、deduplicated 的備份。對我來說，重點不是「功能最多」，而是「出事時能不能快速查、快速救」。

我在這個範圍內負責的工作包含：

  • 設計與維運 Proxmox VE cluster、virtualization、storage 與 VM lifecycle。
  • 建置 Proxmox Backup Server，規劃 backup、restore 與 disaster recovery 流程。
  • 管理 NVIDIA GPU server、driver / runtime、inference environment 與系統調校。
  • 評估 Dell、HP、Supermicro server hardware 與 GPU server 規格，整理成可採購、可維運的技術規格。
  • 規劃內外部機房、site-to-site backup 與 high availability 路徑，並用 LibreNMS 做 network / server monitoring。

規劃重點：叢集、儲存與網路

叢集

Cluster 的價值在於集中管理與 VM 搬移，但它也帶來 quorum 的問題。依照 Proxmox VE 官方文件，如果要用 High Availability，至少需要三個節點才能有可靠的 quorum；只有兩個節點時，可以用 QDevice 補第三票。

另外幾個我會先確認的事：

  • 節點版本一致：官方建議 cluster 內所有節點維持相同版本，升級要有計畫地一台一台做。
  • CPU 相容性：官方文件提到 online migration 只在相同 CPU vendor 之間保證可行；硬體不一致時，VM 的 CPU model 要選得保守一點，否則 live migration 可能失敗。
  • 節點生命週期：加入、汰換、移除節點都要有固定流程，不要臨場發揮。

儲存

儲存規劃的原則是「把會長大的東西和系統分開」。VM disk、ISO / template、備份資料各自有適合放的位置，備份資料尤其不要和 hypervisor 的系統碟擠在同一個空間，否則某一邊爆量就會連帶影響另一邊。

VM 的 disk 也要預期會成長。在 Proxmox 上擴充磁碟本身不難，但要記得 hypervisor 端 resize 之後，guest OS 裡的 partition、LVM 與 filesystem 也要跟著調整。這個流程我在 blog 整理過 Ubuntu 22.04 VM 的完整步驟。

網路

Cluster 通訊使用 Corosync，對延遲很敏感，但不太吃頻寬。官方建議給 cluster traffic 一張專用的實體網卡，並在另一個實體網路上準備第二條 link 作為備援，避免 VM 流量或備份流量把 Corosync 擠掉。

一般性的原則是把管理、cluster、VM 與備份流量分開規劃，並在一開始就決定好位址規劃，因為之後要改 cluster 的通訊位址，成本會比想像中高（後面「踩過的坑」會提到）。

GPU Server 與 AI Workload

AI runtime 對 GPU、driver、CUDA 版本與 kernel 都很敏感，所以 GPU server 的維運重點是「環境可以被重建」，而不是某台機器剛好能跑。

在 Proxmox 上使用 GPU，常見做法是 PCI(e) passthrough。官方文件提到幾個要先想清楚的取捨：

  • 硬體與 BIOS / UEFI 要支援並啟用 IOMMU。
  • GPU passthrough 給某台 VM 之後，host 和其他 VM 就不能再使用那張卡。
  • 有 passthrough PCI 裝置的 VM 目前不能 live migration，因此維護節點時要預先安排停機時間。

因為這些限制，GPU workload 適合用「整台規劃」的角度思考：哪些服務要獨佔 GPU、driver 與 runtime 怎麼版本化、主機維護時服務要怎麼停與怎麼回來。

Driver 問題是 GPU 維運最常遇到的。我在 blog 記錄過 nvidia-smi 出現 No devices were found 的處理方式，以及 Ubuntu 24.04 在 Secure Boot 環境下 NVIDIA 驅動無法載入 的解法。這類問題的共通點是：先確認 kernel、driver、Secure Boot 與編譯環境的關係，再決定怎麼修，而不是一直重裝。

Proxmox Backup Server 備份策略

備份策略我會分成四件事看：備份、保留、清理、驗證，最後再加上還原演練。

Prune 與 Garbage Collection 是兩件事

這是 PBS 最容易誤解的地方。依照 PBS 官方文件：

  • Prune 只會移除 snapshot 的 metadata（manifest、index 等），實際資料所在的 chunk 不會立刻消失。
  • Garbage Collection（GC） 才會真正刪除不再被任何 snapshot 參考的 chunk。GC 分成 mark 與 sweep 兩個階段，而且有一段寬限時間（預設約 24 小時 5 分鐘），所以剛 prune 完、馬上跑 GC，空間不一定會立刻釋放。

所以保留政策（keep-last、keep-daily、keep-weekly 等）和 GC 排程要一起設計。只設定 prune、沒有排 GC，空間會一直長；只看 GC 而保留政策太寬，空間一樣會不夠。

空間要預留，不要等到 100%

我在 blog 記錄過 PBS 硬碟空間滿到 100% 的處理過程。當時的困境是：GC 需要一點空間才能執行，但空間已經完全用完。最後是先清掉超過 90 天的舊 task log，釋放出一點空間，再手動執行 GC。

這次經驗讓我更重視幾件事：

  • 用 monitoring 盯 datastore 使用率，在還有餘裕時就處理，而不是等到寫不進去。
  • 讓 datastore 和 PBS 系統本身的空間盡量分開，避免備份資料把系統擠爆。
  • 定期檢查 prune 與 GC job 是否真的有在跑、有沒有失敗。

Verify 與還原演練

備份成功不等於可以還原。PBS 官方文件建議設定 verify job，並且至少每個月重新驗證一次所有備份，因為硬碟老化可能讓原本正常的備份慢慢損壞（bit rot）。比較好的做法是：頻繁的 verify job 檢查新的備份，再搭配每週或每月一次的完整 re-verify。

除了 verify，還需要真正的還原演練：定期挑幾台 VM 或 container 還原到測試環境，確認開得起來、服務能跑、資料是預期的版本。Proxmox VE 也提供 live-restore 與 single file restore，適合在演練時一起確認流程。

Off-site 與 disaster recovery

只有一份備份放在同一個機房，遇到整個站點出問題時就不夠。PBS 可以透過 remote 與 sync job 把備份同步到另一台 PBS，作為 site-to-site backup 的基礎。重點是要把「另一個站點的備份怎麼還原、還原到哪裡」也寫進 disaster recovery 流程，而不是只有資料在那裡。

維運踩過的坑

以下每一項都是我在 blog 上公開記錄過的問題，這裡只摘要重點與學到的事。

變更 Cluster 通訊 IP

我在 blog 記錄過 Proxmox VE Cluster IP 更新與配置同步 的過程。重點是要修改 cluster 共享的 /etc/pve/corosync.conf，而不是單一節點上的 /etc/corosync/corosync.conf；改之前先備份，改的時候要遞增 config_version，各節點的網卡設定與 /etc/hosts 也要同步更新，最後用 pvecm status 確認設定已經套用。這類操作會影響 quorum，屬於高風險變更，要排在維護時段做。

從叢集移除節點

節點汰換時，我在 blog 整理過 如何從 Proxmox VE 叢集中安全移除節點：先備份或遷移該節點上的 VM 與 container，關機並確認它不會自動開回來，再用 pvecm delnode 移除，最後清掉殘留的節點目錄與 SSH key 資訊。官方文件也特別強調，被移除的節點不能用原本的設定再接回同一個 cluster 網路，否則可能把 cluster 弄壞。

網卡 firmware 錯誤

我在 blog 記錄過一台 Proxmox VE 主機的 Intel X550 一直出現 ixgbe FWSM firmware error。封包 counters 看起來都正常，更新 kernel 也沒有解，最後是更新網卡 NVM 並做真正的 power cycle 才消失。學到的是：driver 從硬體讀到的 firmware 警告不要用過濾 log 的方式處理；刷 firmware 前要先做 inventory、確認版本對應，並準備好 BMC / IPMI 或實體 console。

VM 與 container 的修復

舊硬體與硬體監控

我在 blog 記錄過 在 HP ProLiant DL380 G6 安裝 PVE 或 PBS 時畫面出現條紋 的解法，也記錄過 在 Proxmox 安裝 HPE Agentless Management，讓 iLO 能讀到主機狀態。舊世代硬體可以延長使用，但要預期安裝與監控工具的支援會越來越少，汰換計畫要提早排。

升級前的檢查

我在 blog 整理過 Proxmox VE 9.2 幾個比較重要的新功能，例如 HA disarm / arm、CRS 動態負載平衡與 Custom CPU Models GUI。不論是哪一版，正式環境升級前我都會先確認：備份是否完整、kernel / driver 相容性、HA 與 migration 行為，以及網路設定有沒有受到影響，並優先在測試環境或非核心節點驗證。

學到的事

  • 備份要以「能還原」為目標：prune、GC、verify 與還原演練缺一不可，只看備份 job 成功是不夠的。
  • 空間與容量要提前監控：PBS 滿到 100% 時，連清理工具都很難執行，預留空間比事後救火便宜很多。
  • Cluster 的變更都是高風險操作：改 IP、移除節點、升級，都要先備份設定、照文件流程走，並排在維護時段。
  • 把踩過的坑寫下來：上面每一個問題，下次再遇到時都能直接查自己的紀錄，這也是我持續寫 blog 的原因。