PART 06 / CORE CURRICULUM

效能規劃與容量管理

從 HDD 與 All-Flash 的規劃思維差異出發，掌握 Raw → Usable → Effective 三層換算邏輯，搭配 IBM Storage Modeller 操作實戰，建立完整的容量規劃與效能診斷能力。

容量規劃 IBM Storage Modeller 通用概念

本頁章節

6.1 效能指標基礎
6.2 容量三層換算
6.3 IBM Storage Modeller 操作實戰
6.4 容量規劃方法論
6.5 效能瓶頸診斷

6.1 效能指標基礎#

儲存效能由三個核心指標描述，三者之間有密切的相互影響關係，不能單獨看待。

⚡

IOPS

每秒 I/O 操作次數。資料庫、交易系統等隨機讀寫密集的工作負載最關注此指標。

🚀

吞吐量（Throughput）

每秒傳輸的資料量（MB/s 或 GB/s）。大型循序讀寫（備份、影像串流）最關注此指標。

⏱️

延遲（Latency）

單次 I/O 的回應時間（ms 或 µs）。即時交易、核心應用對延遲最敏感。

三者的相互關係

IOPS 和吞吐量不能同時最大化：小 I/O（4K、8K）有利於高 IOPS；大 I/O（64K、128K 以上）有利於高吞吐量，但同時 IOPS 數字會下降。延遲則受到 Queue Depth（佇列深度）影響——Queue Depth 越高，儲存系統越忙，單次 I/O 的等待時間越長。

Queue Depth 的直覺理解

把儲存系統想像成一個服務窗口，Queue Depth 就是排隊人數。窗口忙碌（高負載）時，即使窗口本身的服務速度夠快，每個人等待的時間（延遲）還是會增加。所以高 IOPS 不代表低延遲，這兩個目標在高負載下會互相拉扯。

HDD 時代：用顆數換 IOPS

傳統 HDD 的 IOPS 受限於機械動作：磁頭尋道（Seek Time）和碟片旋轉等待（Rotational Latency）。這兩個都是物理限制，無法靠軟體突破。

HDD 類型	轉速	典型 IOPS（4K 隨機）	典型延遲
SATA HDD	7,200 RPM	75 ~ 100 IOPS	8 ~ 12 ms
SAS HDD	10,000 RPM	130 ~ 150 IOPS	5 ~ 8 ms
SAS HDD（高速）	15,000 RPM	175 ~ 210 IOPS	3 ~ 5 ms

假設應用需要 10,000 IOPS，使用 15K SAS HDD（約 180 IOPS / 顆）：

所需磁碟數 = 目標 IOPS ÷ 單顆 IOPS
= 10,000 ÷ 180 ≈ 56 顆

56 顆 4 TB HDD 的總容量是 224 TB，但應用實際可能只需要 20 TB 的資料量。其餘 204 TB 完全是為了湊 IOPS 而買的「無效容量」。這是 HDD 時代容量規劃最大的浪費來源。

All-Flash 時代：規劃思維的根本轉變

NVMe SSD 沒有機械動作，IOPS 由電子訊號速度決定，一顆現代 NVMe SSD 可提供數十萬甚至百萬 IOPS。這讓「用顆數換 IOPS」的邏輯完全瓦解。

媒介類型	典型 IOPS（4K 隨機）	典型延遲	規劃主軸
15K SAS HDD	~200 IOPS / 顆	3 ~ 5 ms	用顆數換 IOPS
SATA SSD	~80,000 IOPS / 顆	0.1 ~ 0.5 ms	IOPS 不再是瓶頸
NVMe SSD（企業級）	500,000 ~ 1,500,000 IOPS / 顆	50 ~ 200 µs	容量與成本為主軸

All-Flash 的顆數取捨三角

當 IOPS 不再是瓶頸，All-Flash 的容量規劃轉變為以下三角取捨：

實際規劃時，採購方通常會在「給定容量需求」的前提下，尋找顆數與單顆容量的最佳組合，讓總成本最低、同時 Usable 比例和重建速度都在可接受範圍內。IBM Storage Modeller 是驗證這個取捨的標準工具。

6.2 容量三層換算#

從磁碟的標示容量到主機實際可用的空間，中間經過三層轉換，每一層都有損耗或放大。搞清楚這三層，是容量規劃最基礎的功夫。

Raw → Usable → Effective

TiB vs TB：最常見的混淆來源

磁碟廠商用十進位（1 TB = 1,000,000,000,000 Bytes），作業系統和 SVC 介面用二進位（1 TiB = 1,099,511,627,776 Bytes）。兩者差距約 9.1%，在大容量環境下數字落差很明顯。

TB → TiB 換算：TiB = TB × (1000⁴ ÷ 1024⁴) ≈ TB × 0.9095
TiB → TB 換算：TB = TiB × (1024⁴ ÷ 1000⁴) ≈ TiB × 1.0995

例：廠商標示 9.6 TB NVMe
→ 實際 = 9.6 × 0.9095 ≈ 8.73 TiB（作業系統 / SVC 顯示值）

⚠️ 規劃文件的單位一致性

同一份文件中混用 TB 和 TiB 是最常見的錯誤來源。建議原則：SVC 介面顯示什麼單位，文件就用什麼單位。IBM SVC 和 FlashSystem 介面一律顯示 TiB，所以規劃文件統一用 TiB，需要對外說明時再換算成整數 TB 概估值。

DRAID vs 傳統 RAID 的 Usable 差異

同樣 18 顆磁碟，DRAID-6 和傳統 RAID-6 的 Usable 有顯著差異：

RAID 類型	18 顆磁碟	保護方式	Usable 比例	優勢
傳統 RAID-6	18 顆（固定群組）	每群組固定 2 顆 Parity	~88.9%（16/18）	簡單直觀
DRAID-6（10+P+Q）	18 顆（分散 Stripe）	Parity 分散於所有磁碟	~83.3%（10/12 per stripe）	重建速度快、所有磁碟都參與重建

DRAID 的 Usable 比例略低於傳統 RAID-6，但重建時間大幅縮短（因為所有磁碟都參與重建，不只是固定幾顆）。在 All-Flash 環境中，重建速度的優先級高於 Usable 比例，因此 IBM FlashSystem 全系列預設使用 DRAID。

顆數對 Usable 比例的影響

磁碟顆數	DRAID-6 配置	Data Drives	Usable 比例	備註
12 顆	10+P+Q	10	83.3%	最小可用配置
18 顆	10+P+Q × 1.5 組	~15	~83.3%	FS7300 典型配置
24 顆	10+P+Q × 2 組	~20	~83.3%	FS7200 典型配置
顆數越多	—	—	比例趨於穩定	重建速度↑、單顆故障影響↓

實務建議

不要手算 DRAID Usable，直接用 IBM Storage Modeller 輸入 BOM 規格，系統會自動計算出精確的 Raw / Usable / Effective 數字，這才是提案和驗收的官方依據。

6.3 IBM Storage Modeller 操作實戰#

IBM Storage Modeller 是 IBM 官方的容量規劃工具，輸入 BOM 規格後自動計算 Raw / Usable / Effective 容量。是提案、驗收、容量規劃的標準依據，不能用手算取代。

介面四個頁籤

頁籤	功能	常用時機
System	設定機型、軟體版本、Standard / Custom 配置	建立新專案第一步
Adapters	設定前端 FC / iSCSI 介面卡數量	需要確認 FC Port 數量時
Capacity	設定磁碟顆數、DRAID 類型、Pool 參數（Thin / Compression / Dedup）	容量規劃核心頁面
Report	輸出完整規格報表，含 Raw / Usable / Effective	提案文件截圖依據

建立 FlashSystem 專案步驟

STEP 01

選擇機型

System 頁籤，從下拉選單選擇正確的 FlashSystem 型號（如 FlashSystem 7300 / 4657-924）

STEP 02

選擇軟體版本

選擇對應的 Software Version，影響功能可用性（如 DRP 需要特定版本以上）

STEP 03

切換 Capacity 頁籤

Add Pool 建立儲存池，選擇 Regular Pool 或 Data Reduction Pool

STEP 04

設定磁碟

Add Array，選擇磁碟型號（需與 BOM 一致）、顆數、DRAID 類型（如 DRAID-6 10+P+Q）

STEP 05

設定 Pool 參數

Thin Provisioning（%）、Compression（%）、Deduplication（%），不開就填 0

STEP 06

確認右上角數字

Raw / Usable / Effective 三個數字即時更新，這是提案文件的官方依據

Pool 參數的意義

參數	填 0 的意思	填非 0 的效果	建議
Thin Provisioning (%)	不開，Effective = Usable	Effective 大於 Usable（虛擬放大）	反推現況時使用；新建提案填 0，用物理 Usable 說明
Compression (%)	不開壓縮	Effective 進一步放大（依資料壓縮率）	資料庫環境壓縮率有限，建議保守估計
Deduplication (%)	不開重刪	Effective 進一步放大（依資料重複率）	需使用 Data Reduction Pool 才能開啟

用 Storage Modeller 驗證顆數取捨

以 FlashSystem 7600（5075-A30）為例，比較不同顆數配置的 Usable 差異：

磁碟顆數	單顆容量	Raw	Usable（DRAID-6）	單位成本比較
12 顆	6.4 TB NVMe FCM5	~65 TiB	~54 TiB	基準
25 顆	6.4 TB NVMe FCM5	~136 TiB	~113 TiB	控制器成本分攤較低
12 顆	12.8 TB NVMe FCM5	~131 TiB	~109 TiB	顆數少、大容量單顆，控制器負擔低

相近的 Usable 容量，可以用「少顆大容量」或「多顆小容量」達成。前者控制器負擔低、成本可能較低；後者重建速度較快、Usable 比例略高。Storage Modeller 是驗證這個取捨的最快工具。

6.4 容量規劃方法論#

容量規劃不是算一次就結束，而是一個「現況 → 預測 → 設計緩衝 → 定期複查」的循環。以下是標準流程。

Step 1：現況盤點

從 SVC 管理介面或 CLI 取得每個 Pool 的現況數字：

SVC CLI：lsmdiskgrp -delimited :
關鍵欄位：capacity（總容量）、used_capacity（已使用）、
free_capacity（可用）、overallocation_max（Thin 上限）

注意：如果 Pool 有開 Thin Provisioning，capacity 是虛擬容量，需回到 Storage Modeller 確認物理 Usable。

Step 2：成長率預測

預測方法	說明	適用情境
歷史趨勢法	取過去 12～24 個月的容量成長紀錄，計算月均成長率	業務穩定、無重大變化
業務預估法	依業務單位提供的未來業務量預估，換算儲存需求	業務有明確擴張計畫
保守估計法	取歷史趨勢的 1.5～2 倍作為規劃基礎	不確定性高、寧可保守

Step 3：安全緩衝設計

不能讓 Pool 使用率達到 100% 才開始行動，因為：

採購到交貨有 Lead Time（IBM FlashSystem 一般 4～12 週）
Thin Provisioning 環境下，Pool 爆滿會導致 VDisk 直接離線，影響比想像中大
需要保留空間給 FlashCopy / Snapshot 的暫存使用

建議警戒線（物理 Usable）：70%
建議採購啟動點：使用率達 70%，立即啟動採購流程
建議緊急上限：80%（超過此點應立即減少非必要資料）

剩餘可用年限估算：
剩餘容量 = 物理 Usable × (1 - 目前使用率)
可用年限 = 剩餘容量 ÷ (年均成長量)

Step 4：汰換時機判斷

容量不足不是汰換的唯一理由，以下四個條件任一成立，就應該啟動汰換評估：

條件	說明	緊急程度
已超過原廠支援期限（EOS）	無法取得原廠支援、安全更新，構成合規風險	高
容量使用率超過 80%	距離爆滿緩衝不足，且採購 Lead Time 可能來不及	高
年維護費用接近或超過新設備折舊	繼續維護的 TCO 不划算	中
效能已無法滿足應用需求	延遲過高、IOPS 不足，影響應用 SLA	視情況

6.5 效能瓶頸診斷#

效能問題的根源不外乎四類，這個分類框架是通用的，不管用哪個品牌的儲存設備都適用。確定根源類型後，再用各廠商對應的工具深入診斷。

四類效能瓶頸（通用框架）

類型	症狀	常見原因
① 前端路徑瓶頸主機 → 儲存的連線	主機 I/O 等待時間長，但儲存設備本身負載不高	FC HBA 頻寬不足、FC Switch 擁塞、Zoning 設定錯誤、MPIO 路徑不均衡
② Cache 效率低虛擬化層 / 控制器	Cache hit rate 低，大量 I/O 穿透到磁碟層	Cache 容量不足、工作負載隨機性太高（難以預測預取）、Cache 被少數大 I/O 佔滿
③ 後端磁碟瓶頸實體磁碟層	磁碟 IOPS / 吞吐量達到上限，延遲升高	磁碟數量不足（HDD 時代常見）、DRAID 重建中（臨時效能下降）、熱點 Volume 集中在同一 Array
④ 熱點問題資料分佈不均	特定 Volume 延遲高，其他 Volume 正常	少數 LUN 承擔大量 I/O、Easy Tier 尚未完成熱資料遷移、應用層 SQL 查詢效率問題（需從應用層排查）

各品牌對應診斷工具

診斷項目	IBM SVC / FlashSystem	NetApp ONTAP	Everpure Pure1	Dell PowerStore
整體 I/O 統計	`lsiogrp` `lsnodestats`	`statistics show`	Pure1 Dashboard → Arrays	PowerStore Manager → Performance
Cache hit rate	`lsnodestats` （cache_read_hits 欄位）	`statistics show -object cache`	內建顯示（Always-On）	Performance → Cache
熱點 Volume	`lsvdiskcopy` `lsiogrp -delimited`	`qos statistics volume show`	Array Analytics → Volumes	Performance → Volume
前端 FC 路徑	`lsportfc` `lsportstats`	`network interface show`	Pure1 → Connections	Hardware → FC Ports
磁碟層狀態	`lsdrive` `lsarray`	`storage disk show`	Pure1 → Hardware	Hardware → Drives

診斷建議順序

效能問題發生時，建議依照「前端路徑 → Cache → 後端磁碟 → 熱點」的順序排查，不要一開始就假設是磁碟不夠用。前端路徑問題（FC 設定錯誤、MPIO 不均衡）是最常被忽略但修復成本最低的問題類型。

IBM SVC 常用診斷指令速查

指令	用途	關鍵欄位
`lsmdiskgrp`	Pool 容量與使用率	capacity、used_capacity、free_capacity
`lsvdisk`	VDisk 清單與使用量	capacity、used_capacity、mdisk_grp_name
`lsmdisk`	Mdisk（底層設備）狀態	status、capacity、mdisk_grp_name
`lsiogrp`	I/O Group 統計	node_count、cache_size
`lsnodestats`	節點即時效能統計	stat_name=cache_read_hits / total_cache_delay_ms
`lsportfc`	FC Port 狀態	status、WWPN、speed、attachment
`lsdrive`	磁碟狀態	status、tech_type、capacity