虛擬化儲存層原理
從「為什麼需要儲存虛擬化」出發，逐層理解 IBM SVC 的設計邏輯與三層架構，並對照市場主流方案的不同路線。實際數字推導請見情境案例頁。
為什麼需要儲存虛擬化？#
要理解 SVC 存在的意義，必須先從主機的儲存需求談起，逐步推導出每個架構演進的動機。
最簡單的起點：主機直接接儲存（DAS）
Direct Attached Storage，磁碟直接連到主機。簡單、低延遲，但容量被一台主機獨占，其他主機無法共用，擴充也受限於主機本身的插槽數量。
解決共享問題：SAN 出現
Storage Area Network 透過 Fibre Channel 或 iSCSI 網路，讓多台主機共享同一台儲存設備的容量。容量可以統一管理，主機之間不再各自為政。但 SAN 本身只解決了「連接」的問題，沒有解決「管理」的問題。
新問題出現：異構多設備的管理困境
企業的儲存設備不可能只有一台，也不可能永遠是同一個廠牌。幾年下來，環境裡可能同時有 A 廠的高階陣列、B 廠的中階陣列、上一代的舊設備還沒汰換完。每台設備有自己的管理介面、自己的容量池，容量無法跨設備共用，資料搬移需要停機，擴充一台設備不等於整體容量就能用到。
儲存虛擬化的出現：SVC 解決的核心問題
在主機和實體儲存設備之間，插入一個虛擬化層。主機只和這個虛擬化層溝通，不需要知道底下有幾台設備、是哪個廠牌。虛擬化層負責把所有設備的容量統一管理，並對主機提供一致的邏輯卷介面。IBM SVC 就是這個虛擬化層的角色。
| 問題 | SVC 如何解決 |
|---|---|
| 異構設備各自為政，管理介面不統一 | 所有設備統一以 Mdisk 呈現，透過 SVC 單一介面管理 |
| 容量無法跨設備池化，利用率低 | 多台設備的 Mdisk 組成統一 Pool，主機從 Pool 取用容量 |
| 資料搬移到新設備需要停機 | SVC 在背景搬移資料，主機端的 VDisk 持續可用 |
| 底層設備功能不一致（有些不支援快照、壓縮） | 功能統一由 SVC 虛擬化層提供，不依賴底層設備支援 |
In-band vs Out-of-band 虛擬化#
儲存虛擬化依據「虛擬化層是否在 I/O 資料路徑上」分為兩種架構，這個選擇決定了虛擬化設備能做什麼、以及它的風險在哪裡。
IBM SVC 採用 In-band 架構。所有主機的 I/O 都流經 SVC，這讓 SVC 能夠：
- 提供 Cache 層加速讀寫（對底層老舊設備效果顯著）
- 在 I/O 路徑上即時執行 Thin Provisioning、Compression 等功能
- 攔截並重新導向 I/O，實現不停機的資料搬移
代價是 SVC 本身成為 I/O 路徑上的關鍵節點，因此必須以雙節點 HA 方式部署，避免單點故障。
SVC 三層架構：Mdisk / Pool / VDisk#
SVC 用三個邏輯層次，把實體儲存設備和主機之間的複雜關係整理清楚。每一層解決一個特定的問題。
各層次的角色與職責
| 層次 | 名稱 | 解決的問題 | 主機視角 |
|---|---|---|---|
| Layer 1 | Mdisk Managed Disk |
把不同廠牌、不同世代的實體設備，統一抽象成 SVC 可以管理的磁碟單元 | 主機看不到這一層 |
| Layer 2 | Pool MDisk Group |
把多個 Mdisk 的容量合併成一個池，讓容量可以跨設備共用，並統一套用 Thin Provisioning、壓縮等功能 | 主機看不到這一層 |
| Layer 3 | VDisk Virtual Disk / Volume |
從 Pool 配置邏輯容量，對主機呈現為標準 LUN，主機直接對 VDisk 進行讀寫 | 主機唯一看到的層次 |
I/O Group 與 Cache
SVC 節點兩兩一組構成 I/O Group，每個 I/O Group 擁有獨立的 Cache 記憶體。主機的讀寫 I/O 先進入 Cache，由 Cache 決定是否需要對底層 Mdisk 進行實際讀寫。這個設計讓 SVC 即使管理老舊的 HDD 陣列，也能透過 Cache 提供相對穩定的 I/O 回應時間。
SVC 核心功能概覽#
SVC 在虛擬化層上提供一系列資料服務功能，這些功能不依賴底層儲存設備的支援，由 SVC 統一提供。以下是各功能解決的問題與對應章節。
市場主流方案對照#
市場上解決儲存虛擬化與多設備管理問題的方案，大致可分為兩條路線，設計哲學有根本性的差異。
兩條路線
| 路線 | 做法 | 代表產品 | 核心取捨 |
|---|---|---|---|
| 獨立虛擬化層 | 在主機與儲存設備之間部署獨立的虛擬化設備，I/O 流經此層 | IBM SVC Dell VPLEX |
功能最強（Cache、異構管理、豐富資料服務），但虛擬化設備本身需要 HA 設計，多一個維運對象 |
| 陣列內建 | 資料服務由儲存陣列作業系統直接提供，不需要外部虛擬化層 | NetApp ONTAP（AFF） Everpure Purity OS HPE Alletra |
架構簡潔，管理介面統一，但只能管理自家設備，異構統一管理能力有限 |
各產品定位對照
| 產品 | 路線 | 主要強項 | 相對弱項 |
|---|---|---|---|
| IBM SVC 2145-SV1 / 未來 SV3 |
獨立虛擬化層（In-band） | 異構設備統一管理、豐富資料服務（FlashCopy / HyperSwap / Metro Mirror）、老設備 Cache 加速 | 需額外部署虛擬化設備、架構相對複雜 |
| Dell VPLEX | 獨立虛擬化層（In-band） | 跨站雙活（Metro / Geo）、跨廠牌 Volume 延伸，雙活設計是核心 | 資料服務廣度不如 SVC，更聚焦雙活場景 |
| NetApp ONTAP（AFF） | 陣列內建 | Block + NAS + S3 三合一、SnapMirror 複製生態成熟、雲端延伸（Cloud Volumes ONTAP） | 無法管理非 NetApp 設備 |
| Everpure（前 Pure Storage）FlashArray | 陣列內建 | Always-On 資料縮減、極簡管理介面（Pure1）、Evergreen 原地升級商業模式 | 無法管理非 Everpure 設備、NAS 功能相對有限 |
| HPE Alletra MP | 陣列內建（解耦架構） | 控制平面與資料平面解耦、GreenLake 按用量付費、InfoSight AI 預測維運 | 市場成熟度相對較新，生態廣度仍在建立 |
選型判斷原則
- 環境有異構設備、需要統一管理：獨立虛擬化層（SVC / VPLEX）是唯一真正能解決問題的路線
- 全新建置、設備單一廠牌：陣列內建路線架構更簡潔，管理成本較低
- 需要跨站雙活（RPO = 0）：IBM SVC HyperSwap 或 Dell VPLEX Metro，兩者定位相近但生態不同
- 需要 Block + NAS 統一：NetApp ONTAP 生態最成熟；Everpure 在 Block 端極強但 NAS 相對有限