運算與儲存解耦的企業級架構思維
企業在擴充虛擬化環境時，最常遇到的瓶頸除了單一伺服器的效能不足，架構本身需要調整和改善的空間不少。傳統做法是將運算與儲存綁定在同一台實體主機上，虛擬機磁碟直接存放於本機硬碟或本機陣列。這種模式在虛擬機數量少、負載單純的階段運作良好，然而一旦環境成長到數十台、數百台虛擬機，以及改架構數百台到數千台容器運作，或開始承載資料庫、AI 推論等高 I/O 負載，問題便會浮現。
當運算資源與儲存資源無法獨立擴充，某台主機的磁碟空間吃緊時，即使其他主機仍有大量閒置容量也無法支援。更關鍵的是，單機架構意味著單點故障，實體伺服器一旦損壞，其上所有虛擬機隨之停擺，資料能否救回還得看陣列的健康狀態。
這份 CyberQ 實作並驗證過的架構，做法是是將兩者徹底解耦，Proxmox VE (以下簡稱 PVE) 專職擔任 Hypervisor 運算節點，只負責 CPU 與記憶體的調度，而 QNAP 全快閃 NAS 或混合架構 NAS 則作為集中化的區塊儲存 (Block Storage) 後端，統一承擔虛擬機磁碟的存放、快照、RAID 陣列維護與資料保護工作。
這樣的分工帶來三項直接效益。第一，運算節點變成近乎無狀態的角色，新增或汰換 PVE 主機不牽動任何資料搬遷。第二，儲存後端由專用硬體與韌體最佳化處理，快照與重建等作業不會侵蝕 Hypervisor 的運算資源。第三，共享儲存是高可用性叢集的先決條件，虛擬機磁碟不落在任何單一運算節點上，才有可能實現熱移轉與自動故障轉移。
以下將依序實作這套架構，先建立高速且具備冗餘的儲存管道，再規劃虛擬化網路拓撲，接著啟用 PVE HA 叢集，最後補上資料防護與災害復原機制。
高速儲存管道建置 iSCSI LUN 與 Multipath 多路徑設定
為什麼選擇 Block-level iSCSI
QNAP NAS 對外提供儲存服務有兩大路線，一種是最常見的檔案級的 NFS 與 SMB，以及區塊級的 iSCSI。對於一般檔案共享，檔案級協定簡單直觀，但虛擬化場景的核心工作是對虛擬磁碟映像檔進行大量隨機讀寫，此時區塊級協定的優勢相當明顯。iSCSI 將 NAS 上的 LUN 以原始區塊裝置的形式呈現給 PVE，作業系統可直接對其下達 SCSI 指令，省去檔案系統層的中介轉換，在寫入延遲與 IOPS 表現上都更為出色。PVE 端取得 LUN 之後，慣例做法是在其上建立 LVM，由叢集內所有節點共享同一個 Volume Group，每台虛擬機的磁碟即為其中一個 Logical Volume。這種設定呢，天生支援多節點同時存取，是後續熱移轉的基礎。
在 QNAP 端的準備工作上，建議於全快閃儲存池中建立區塊型 LUN(Block-based LUN)而非檔案型 LUN，並依據虛擬機的用途評估是否啟用精簡配置(Thin Provisioning)。同時應為 iSCSI Target 設定 CHAP 驗證與存取控制清單，僅允許 PVE 節點的 IQN 連入，避免儲存資源暴露在不必要的風險之下，你的內網網段要設定好可存取的伺服器是那些 IP 。
Multipath 多路徑 I/O 部署實務
延續之前我們文章討論過的 100GbE 或 25GbE 網路基礎，接著我們需要讓儲存流量同時具備頻寬聚合與故障切換能力。做法是在 PVE 節點與 QNAP NAS 各配置兩張(或兩埠)高速網卡，分別劃入兩個獨立子網段，例如 10.10.1.0/24 與 10.10.2.0/24，兩條路徑之間不共用交換器或至少不共用線路，PVE 可透過 iscsiadm 對同一個 Target 的兩個 Portal IP 各建立一條 Session。
此時 Linux 會看到兩個指向相同 LUN 的區塊裝置，接著由 multipath-tools 將其聚合為單一的 mpath 裝置。在 /etc/multipath.conf 中將 path_grouping_policy 設為 multibus 可讓兩條路徑同時分擔 I/O，達到頻寬疊加的效果，若偏好主備模式則可採用 failover 策略。無論哪種策略，當其中一條實體路徑因線材、網卡或交換器故障而中斷時，I/O 會在秒級時間內轉移至存活路徑，虛擬機層面幾乎無感，用戶也不會反應到 IT 來。
儲存網路本身也有兩項不可省略的最佳化。其一是在 PVE 網卡、交換器連接埠與 QNAP 網卡三處同步啟用 MTU 9000 巨型封包，減少高速傳輸下的封包處理開銷，任何一段遺漏都會導致封包分割而抵銷效益。其二是在交換器上為儲存流量啟用流量控制(Flow Control)或 DCB 無損乙太網路機制，避免瞬間突發流量造成封包遺失後的 TCP 重傳，這對 IOPS 的穩定度影響不小。CyberQ 實測上，完成 MTU 與多路徑設定後，4K 隨機讀寫的延遲抖動會明顯收斂，大區塊循序傳輸則能逼近網卡的線速上限。
第二章:虛擬化網路拓撲,專用 VLAN 劃分與流量隔離
儲存管道就緒之後，下一步是為整個虛擬化環境規劃網路拓撲。核心原則其實不難，關鍵是不同性質的流量必須在實體或邏輯層面儘量完全隔離，關鍵服務不能因為突發流量而受到擠壓。實務上建議至少劃分四個獨立區段，以下表格整理各區段的用途與設計要點。
| 網路區段 | 承載流量 | 建議頻寬 | 設計要點 |
|---|---|---|---|
| 叢集心跳網路 | Corosync 叢集通訊 | 1GbE 即可,重點是低延遲 | 專用實體網卡或專用 VLAN,嚴禁與其他流量混用 |
| 儲存網路 | iSCSI 多路徑流量 | 25GbE 或 100GbE 雙路徑 | MTU 9000,無損乙太網路,不設定閘道 |
| 管理網路 | PVE Web UI 與 SSH | 1GbE 至 10GbE | 限制來源 IP,僅開放維運人員存取 |
| 業務網路 | 虛擬機對外服務 | 依服務需求 | 透過 VLAN aware bridge 依租戶或服務再細分 |
在 PVE 端的實作上，建議將 Linux Bridge 設為 VLAN aware 模式，虛擬機網卡直接標註 VLAN Tag，即可在單一 bridge 上承載多個業務區段，交換器端對應的連接埠則設定為 Trunk 模式。管理介面與儲存介面各自綁定獨立的實體網卡或 VLAN 介面，彼此之間不存在路由互通的必要，儲存網段尤其不應設定預設閘道，我們是讓它成為一個純粹的封閉高速通道。
四個區段之中，最容易被輕忽卻最不能出事的是 Corosync 心跳網路。Corosync 是 PVE 叢集的神經系統，節點之間透過它交換狀態與投票資訊，而它對頻寬的需求極低，對延遲的容忍度卻也極低。一旦心跳封包因為與儲存或備份流量共用線路而被排擠，延遲飆高或連續遺失，叢集就可能誤判某個節點已經失效，進而觸發不必要的故障轉移，這其實非常有事唷，在最壞情況下甚至造成虛擬機在兩個節點上同時啟動的災難。因此正確做法是為 Corosync 保留一條專屬路徑，並在 corosync.conf 中設定第二組 link 作為備援，即使備援線路只是一條普通的 1GbE 連線，也遠勝於與高流量網段混用。
高可用性叢集實戰得搭配 PVE HA、Quorum 投票與零停機熱移轉
Quorum 與腦裂防禦
PVE 的高可用性建立在 Corosync 叢集通訊與 Quorum 法定人數機制之上。叢集中每個節點各持一票，任何叢集層級的決策都必須獲得過半數票數才能自動執行，這正是防禦「腦裂(Split-Brain)」的關鍵邏輯。怎樣說呢 ? 設想一個情境，叢集因網路故障被切割成兩半，若沒有 Quorum 機制來仲裁和處理，兩邊都會認定對方已死並各自接管虛擬機，同一台虛擬機在兩個節點上同時寫入共享儲存，這樣一來，資料毀損幾乎是必然結局。
當有了過半數規則之後，只有擁有多數票的分區能繼續運作，少數票的分區則會自我凍結，停止一切 HA 動作，就不會打架了。這是一種民主的仲裁機制，著名的經典動畫新世紀福音戰士 (Neon Genesis Evangelion) 中，超級電腦 MAGI 的運作也是三個大腦投票，過半數才能夠同意，也就是三票要有兩票以上才行，類似的道理。
這也解釋了為什麼 PVE 叢集強烈建議部署奇數個節點。三節點叢集可容忍一台故障，五節點可容忍兩台，而偶數節點的叢集在對半分裂時雙方都無法過半，整個叢集反而全面停擺。若環境限制只能部署兩台 PVE 主機，畢竟最近記憶體和伺服器都變貴不少，預算有限可能有些單位在某些專案只能部署二台，那這時呢，CyberQ 建議的正確解法是加入 QDevice 仲裁機制，在第三台輕量設備上執行投票代理，湊足奇數票源。順帶一提，QNAP NAS 上的 Container Station 或 Virtualization Station 開一個小 VM 也可勝任這個角色，讓儲存設備兼任仲裁者，你就不需要額外添購硬體，省下的錢可以再來買記憶體。
而且還要注意「有 quorum」≠「HA 一定沒問題」。例如三台 PVE 雖然可以容忍一台故障，但 VM 是否能成功 HA migration / restart，還取決於共享儲存、Ceph、網路、CPU 相容性、VM state、HA 設定等。 如果你是在規劃自己的 PVE 叢集，CyberQ 建議把「PVE 節點數、Ceph OSD 節點數、QDevice、Corosync 網路」一起設計，而不是只看節點奇偶數。對於 3-node、4-node、5-node 的 PVE + Ceph 架構，最佳配置其實會有一些差異。
在自動故障轉移的場景中，還有一個必須理解的機制是 Fencing。當某個節點失聯，叢集在其他節點重啟虛擬機之前，必須先確保失聯節點真的不會再碰共享儲存。PVE 的做法是透過硬體或軟體 Watchdog 實作自我隔離，失去 Quorum 的節點會在固定時間內自動重新開機，叢集則在確認這段隔離時間經過之後才執行接管，以此杜絕雙重寫入的可能。有些公司就踩到這個雷，設定上要留意。
架構中多增加一組小型 QDevice 仲裁機制方案的簡單比較
| 方案 | 故障域獨立 | 部署複雜度 | Proxmox 官方支援 | 額外成本 |
|---|---|---|---|---|
| A. 獨立小型設備跑 qnetd（Pi 4 / Zero 2W / 二手 thin client） | 完全獨立 | 極低，apt install corosync-qnetd 即可 | 是 | 約 NT$1,000 起，功耗 2 至 5W |
| B. QNAP Virtualization Station 開 Debian VM | 與 NAS 同域 | 低，有完整 systemd | 是 | 約 1GB RAM |
| C. Container Station 跑 qnetd | 與 NAS 同域 | 高，需 systemctl shim、處理 22 埠衝突、憑證持久化 | 否 | 數十 MB RAM |
| D. 第三台 x86 mini PC 直接加入叢集 | 完全獨立 | 中 | 是 | 約 NT$4,000 起 |
| E. 不加 QDevice，關閉 HA，手動 failover | 不適用 | 零 | 是 | 零 |
熱移轉與自動故障轉移
有了共享的 iSCSI 儲存，熱移轉(Live Migration)便成為日常維運的基本動作。由於虛擬機磁碟本來就存放在 QNAP NAS 上，移轉過程只需要在節點之間傳輸記憶體分頁與裝置狀態，不須搬動任何磁碟資料。實際操作時，執行中的虛擬機可以在數秒至數十秒內從 A 節點轉移到 B 節點，服務連線不中斷，使用者端完全無感。這讓計畫性維護變得從容，韌體更新、記憶體擴充、核心升級都可以在上班時間進行，先把虛擬機移走，維護完再移回來即可。
至於非計畫性的硬體故障，則交給 HA 資源管理器處理。將重要虛擬機加入 HA 資源清單並指派至 HA 群組之後，一旦其所在節點發生斷電或當機，叢集會在 Fencing 程序完成後，自動於其他健康節點重新啟動這些虛擬機。整體服務中斷時間取決於隔離等待與開機時間，通常可壓縮在兩至三分鐘之內。相較於傳統單機架構動輒數小時的救援流程，這樣的復原速度對絕大多數企業應用已經足夠。CyberQ 建議，在正式上線前實際演練一次拔電測試，親眼確認虛擬機在另一個節點自動復活，同時記錄實際的中斷秒數，作為對內服務水準承諾的依據。
資料防護與災害復原透過 ZFS 快照、PBS 與 QNAP 聯防
高可用性解決的是硬體故障，但它無法對抗誤刪檔案、勒索軟體加密或應用程式邏輯錯誤，因為 HA 只會忠實地讓「壞掉的資料」繼續高可用。企業級架構的最後一道防線，必須由快照與備份共同構成。
第一層防護來自快照，而且是雙層快照。在 QNAP 端，針對承載虛擬機 LUN 的儲存池設定定時快照排程，並啟用快照保險箱(Snapshot Vault) 機制，即使 LUN 內的資料被勒索軟體加密，也能在數分鐘內將整個 LUN 回滾至加密前的時間點。在 PVE 端，若節點本機仍配置有 ZFS 儲存區(例如存放作業系統或部分本地虛擬機)，則可搭配 ZFS 原生快照與 zfs send 遠端複寫，為本地資料建立時間點保護。兩層快照各司其職，QNAP 快照守護共享儲存上的全體虛擬機，ZFS 快照則涵蓋節點本機資料。
第二層防護是 Proxmox Backup Server(PBS)。PBS 是 Proxmox 官方的專用備份系統，與 PVE 深度整合，其全域去重複化(Deduplication)技術會將備份資料切割為區塊並僅儲存唯一內容，數十台以相同範本部署的虛擬機，實際佔用的備份空間可能只有原始容量的一小部分。搭配增量備份與 Dirty Bitmap 追蹤，除了首次全量備份之外，後續每次備份只傳輸有變動的區塊，即使每日甚至每小時執行備份，對儲存網路的負擔也相當輕微。部署方式上，可以將 PBS 安裝為實體機或虛擬機，並將其 Datastore 指向 QNAP NAS 上獨立於虛擬機 LUN 的儲存空間，讓備份資料與正式資料分屬不同儲存池，再視需求透過 QNAP 的異地複寫功能，將備份推送至第二台 NAS 或雲端，完成 3-2-1 備份策略的最後一哩。
除了 PBS，也可以採用第三方廠商如思備提供的 QNAP 備份一體專用機程式，具備 PVE / VMware / Hyper-V 備份功能，也可以進行增量備份，還原也方便，介面上是比較簡單易用的方式，協助企業 IT 營運。
第三層防護，是災難復原，其價值必須透過演練來驗證。建議每季執行一次完整的還原演練，從 PBS 挑選任一備份時間點，將虛擬機還原至測試區段並確認服務可正常啟動，同時記錄兩項關鍵指標，復原時間目標(RTO)，也就是從決定還原到服務恢復所需的時間，以及復原點目標(RPO)，亦即最多可能遺失多少時間範圍內的資料。以每小時增量備份搭配 PBS 的架構而言，RPO 可以收斂到一小時以內，單台虛擬機的 RTO 則視磁碟大小通常落在數分鐘至數十分鐘之間。這兩個數字，才是對管理階層說明備份投資效益時最有力的語言。
所以如果你現在的目標是：「我有 3 台 PVE，希望三台都能看到 QNAP 上同一套 VM Storage，並且可以做 HA。」
簡單的方式就是 NFS
PVE1 ─┐
PVE2 ─┼── NFS ── QNAP
PVE3 ─┘優點是簡單、直觀、管理容易。
企業級更複雜但效果更好的考量就是本文提到的 iSCSI + Multipath
PVE1 ─┐
PVE2 ─┼── iSCSI Multipath ── QNAP
PVE3 ─┘優點是 block storage、Multipath、更穩固的企業儲存架構，但設定與維護複雜度明顯高於 NFS。
如果是「QNAP 全快閃 + PVE Cluster + 10GbE/更高速網路」的架構：
VM Storage
↓
iSCSI + Multipath
↓
QNAP All-Flash
ISO / Template
↓
NFS
Backup
↓
PBS也就是不要一定要二選一。讓 iSCSI 專門負責高 I/O 的 VM block storage，NFS 負責比較方便的檔案型共享資料，而 PBS 或第三方備份軟體平台方案則負責真正的備份。這樣的架構比全部都塞進 NFS 更適合企業的中大型規模用途，小規模則是 NFS 即可。
為地端 AI 算力與企業應用建構穩固基石
回顧整個架構，PVE 運算叢集與 QNAP 全快閃儲存的組合，實質上是以合理的成本在地端重現了企業級虛擬化平台的核心能力。iSCSI 多路徑提供了高速且冗餘的儲存管道，VLAN 隔離確保各類流量互不干擾，Quorum 與 HA 機制將硬體故障的衝擊壓縮到分鐘等級，而快照與 PBS 備份則守住資料安全的底線。
更重要的是，這套基礎設施是後續一切進階應用的底座。完成 100GbE 實體網路與本文的虛擬化架構之後，企業已具備高度靈活且可靠的運算儲存平台，無論是部署資安封包側錄與流量分析系統、建置 CI/CD 自動化開發流水線，或是調度多節點 GPU 資源承接地端 AI 訓練與推論工作負載，都能在這個穩固的基石上從容展開。
