PART 07 / CORE CURRICULUM
企業實戰場景
將前六個 Part 的知識整合到完整的企業儲存專案流程：從合規風險評估、汰換規劃、遷移技術選型，到 EOS 生命週期管理。通用概念適用各品牌，具體示範以 IBM 環境為例。
通用概念
IBM 示範
跨品牌對照
本篇範圍說明#
閱讀前請注意
本章涵蓋的概念與流程（EOS 風險評估、汰換規劃邏輯、遷移策略選型）適用於各品牌儲存環境，是企業 IT 採購與建置的通用實務。
具體示範以 IBM SVC + FlashSystem 環境為主，包含：IBM EOS 查詢方式、IBM 特定工具名稱、IBM 文件術語。
使用其他品牌設備的讀者：通用概念直接適用，IBM 專屬工具請參照本章各節提供的跨品牌對照表，找到對應品牌的做法。
| 標籤 | 意義 |
|---|---|
| 通用概念 | 適用所有品牌，核心邏輯不變 |
| IBM 示範 | IBM 環境的具體工具或做法 |
| 跨品牌對照 | 其他主流品牌的對應做法 |
7.1 企業儲存合規與風險管理#
通用概念
EOS 風險的四個面向
End of Support（EOS）不只是「沒有軟體更新」這麼簡單。超過原廠支援期限後，企業實際面臨的風險來自四個面向：
| 風險面向 | 具體影響 | 緊急程度 |
|---|---|---|
| 資安合規 | 無法取得資安修補程式，已知漏洞無法修復，構成稽核缺失，可能影響認證（ISO 27001、SOC 2 等） | 高 |
| 原廠支援終止 | 故障時無法開 Case 取得原廠技術支援，問題排查完全依賴自身能力或第三方維護廠商 | 高 |
| 維護成本上升 | 第三方維護合約通常比原廠貴 20～40%，且零件取得難度增加，MTTR（平均修復時間）延長 | 中 |
| 保險與法規風險 | 部分資安保險條款要求設備在原廠支援期內；部分行業法規（如金融、醫療）對設備生命週期有明確要求 | 中高（視行業而定） |
通用概念
何時應該啟動汰換評估
不要等到 EOS 當天才開始行動。以下任一條件成立，就應該啟動正式評估：
- 距離 EOS 日期 18～24 個月：給足時間完成採購、建置、遷移、驗收的完整流程
- 年維護費用超過新設備年折舊的 50%：繼續維護的 TCO 已不划算
- 容量使用率達到 70% 警戒線：搭配 Lead Time 評估，避免空間不足時設備才到貨
- 效能已無法滿足 SLA：應用層出現明顯延遲投訴，診斷確認是儲存層瓶頸
IBM 示範
IBM 環境的合規文件邏輯
在 IBM 環境中，提案文件（業簽、建置計畫書）通常以 EOS 合規風險作為汰換的主要論述依據，而非單純的效能升級。原因是：
- EOS 風險是客觀事實，不需要與客戶爭論「現有設備夠不夠用」
- 合規要求通常比效能需求更容易獲得預算核准
- All-Flash NVMe 的效能提升作為「導入後的附加效益」說明，而非主要賣點，避免驗收時的效能爭議
文件撰寫原則
涉及效能的描述，使用方向性語言（「採用目前市場主流 All-Flash NVMe 架構」）而非精確數字（「IOPS 提升 X 倍」）。精確數字在驗收時容易成為爭議點，方向性描述則給予合理的解讀空間。
7.2 汰換專案規劃實務#
通用概念
標準專案流程
通用概念
Phase 1：現況調查清單
現況調查是整個專案的基礎，資料不完整會導致後續容量規劃和遷移策略出現嚴重偏差。以下是標準調查清單：
設備層資料
- 設備型號與 MTM（Machine Type-Model）
- 序號（Serial Number）
- 原廠支援終止日期（EOS Date）
- 目前韌體 / 軟體版本
- FC Port 數量與速度
- Cache 容量
- 磁碟數量、類型、容量
容量與連接層資料
- 各 Pool / Volume Group 總容量
- 各 Pool 目前使用率
- 是否開啟 Thin Provisioning
- 是否開啟 Compression / Dedup
- 連接的主機清單與作業系統
- 各主機對應的 LUN / Volume 清單
- 過去 12 個月容量成長趨勢
IBM 示範
IBM 環境的調查工具
| 調查項目 | 工具 / 來源 | 指令或操作 |
|---|---|---|
| 設備型號 / MTM / 序號 | IBM Econfig / 設備銘牌 | Econfig → Installed → 查詢序號 |
| EOS 日期 | IBM Support 頁面 | ibm.com/support → Product lifecycle |
| SVC Pool 容量現況 | SVC CLI | lsmdiskgrp -delimited : |
| VDisk 清單與使用量 | SVC CLI | lsvdisk -delimited : |
| 連接主機清單 | SVC CLI | lshost / lshostcluster |
| Mdisk（底層設備）狀態 | SVC CLI | lsmdisk |
| 容量驗算 | IBM Storage Modeller | 輸入 BOM 確認 Usable |
跨品牌對照
其他品牌的調查工具
| 品牌 | Pool / 容量查詢 | 主機連接查詢 | EOS 查詢 |
|---|---|---|---|
| NetApp ONTAP | volume show / aggr show | lun igroup show | mysupport.netapp.com |
| Dell PowerStore | PowerStore Manager → Storage | PowerStore Manager → Hosts | dell.com/support → EOL |
| Everpure（Pure） | Pure1 → Arrays → Capacity | Pure1 → Hosts | support.purestorage.com |
| HPE Alletra | HPE GreenLake → Storage | HPE GreenLake → Hosts | h20195.www2.hpe.com |
| Hitachi VSP | Hitachi Ops Center | Hitachi Ops Center → Hosts | Hitachi Vantara Support Portal |
通用概念
Phase 2 & 3：容量規劃與設備選型
容量規劃的方法論已在 Part 6 第 6.4 節完整說明，這裡補充選型的決策邏輯：
- 同品牌汰換：遷移最簡單，管理工具不變，學習成本最低，但失去比價機會
- 跨品牌汰換：有比價空間，但需評估遷移複雜度、管理工具學習成本、現有 SAN Zone 調整
- 新舊並存過渡：透過 SVC 等虛擬化層，新舊設備同時在線，資料逐步搬移，風險最低但時間最長
7.3 資料遷移技術選型#
通用概念
遷移方式的三個維度
選擇遷移方式前，先確認三個維度的需求：
| 維度 | 問題 | 影響選擇 |
|---|---|---|
| 停機容忍度 | 遷移期間主機可以停機嗎？可以停多久？ | 決定是否需要不停機遷移方案 |
| 資料量 | 需要搬移的資料總量是多少？ | 影響遷移時間，決定是否需要分批執行 |
| 新舊設備關係 | 新舊設備是同品牌？同 SVC 管理下？還是完全異構？ | 決定可用的遷移工具 |
IBM 示範
IBM SVC 環境的遷移選項
| 方法 | 原理 | 停機需求 | 適用情境 |
|---|---|---|---|
| SVC Volume Migration | SVC 在背景將 VDisk 的資料從舊 Mdisk 搬到新 Mdisk，搬移期間主機持續讀寫 | 不需停機 | 新舊設備都在同一 SVC 管理下，是最優先選擇 |
| External Storage 切換 | 新設備加入 SVC 作為新的 Mdisk，Pool 擴充後用 Volume Migration 逐步搬資料，再退出舊 Mdisk | 不需停機 | 汰換 SVC 管理下的舊設備，新設備同樣由 SVC 管理 |
| FlashCopy + 重新掛載 | 建立 FlashCopy 快照，將快照掛給主機作為新 Volume，確認無誤後切換 | 短暫停機（切換瞬間） | 需要確保資料一致性，且有短暫停機視窗 |
| 主機層複製 | 在主機作業系統層用 dd、rsync 或備份軟體複製資料 | 視工具而定 | SVC 無法直接管理新設備時（跨品牌異構） |
跨品牌對照
其他品牌的不停機遷移選項
| 品牌 | 不停機遷移工具 | 說明 |
|---|---|---|
| NetApp ONTAP | Volume Move / SVM Migration | Volume 在不同 Aggregate 或控制器間搬移，主機無感知 |
| Dell PowerStore / PowerMax | Live Migration / SRDF/S | PowerStore 內建 Live Migration；跨陣列可用 SRDF |
| Everpure（Pure） | ActiveCluster / Purity Migration | Evergreen 架構下控制器升級本身就是不停機遷移 |
| 第三方工具 | IBM Spectrum Virtualize、Zerto、Cirrus Data | 跨品牌異構遷移的通用方案，與底層設備無關 |
通用概念
遷移期間的風險控制
- 遷移前：確認完整備份、確認主機 MPIO 路徑正常、確認新設備 FC Zone 設定完成
- 遷移中：監控遷移進度與 I/O 影響，建議在離峰時段（夜間、週末）執行大量資料搬移
- 遷移後：驗證資料完整性（Checksum 比對）、確認主機讀寫正常後，再退出舊設備
- 回滾計畫：遷移完成前，舊設備不能提前下線，必須保留回滾能力
7.4 EOS 生命週期管理#
通用概念
生命週期的四個階段
| 階段 | 說明 | 對應行動 |
|---|---|---|
| GA（General Availability） | 產品正式上市，開始銷售 | 可採購、可導入 |
| EOM（End of Marketing） | 停止銷售，但仍提供維護支援 | 不可採購新品，現有設備仍可繼續使用 |
| EOS（End of Support） | 原廠停止所有技術支援與安全更新 | 應在此日期前完成汰換，否則面臨合規風險 |
| EOL（End of Life） | 產品完全終止，零件停產 | 第三方維護也難以取得零件 |
IBM 示範
IBM EOS 查詢方式
IBM 產品的 EOS 資訊分散在幾個來源，建議依照以下優先順序查詢：
- IBM Support — Hardware Lifecycle：
ibm.com/support/pages/hardware-lifecycle，可依產品名稱或 MTM 查詢 - IBM Econfig（BOM 確認平台）：輸入客戶序號，可確認 MTM 並對應查詢 EOS 日期
- IBM Support — Product lifecycle（舊版）：部分舊型號需用此頁面查詢
⚠️ MTM 優先原則
IBM 產品名稱在不同世代可能相同（如「FlashSystem 7300」有不同 MTM），但 EOS 日期可能不同。查詢時必須以 MTM（Machine Type-Model）為準，不能只靠產品名稱。
跨品牌對照
各品牌 EOS 查詢入口
| 品牌 | EOS 查詢入口 | 查詢方式 |
|---|---|---|
| IBM | ibm.com/support/pages/hardware-lifecycle | 依 MTM 或產品名稱搜尋 |
| Dell Technologies | dell.com/support → Product Support → End of Life / Support | 輸入 Service Tag 或型號 |
| NetApp | mysupport.netapp.com → Product Library → Hardware Universe | 依產品系列查詢 |
| HPE | h20195.www2.hpe.com/v2/Getdocument.aspx（End of Support Search） | 輸入 Product Number |
| Hitachi Vantara | Hitachi Vantara Support Portal → Product Lifecycle | 需登入 Support Portal |
| Everpure（Pure Storage） | support.purestorage.com → Product Lifecycle | 依產品系列查詢 |
通用概念
EOS vs 維護成本的決策框架
不是所有超過 EOS 的設備都必須立刻汰換，實務上需要做成本效益評估：
| 評估項目 | 繼續維護 | 汰換 |
|---|---|---|
| 年維護費用 | 第三方維護合約（通常較貴） | 新設備年折舊 |
| 風險成本 | 資安事件、稽核缺失的潛在損失 | 遷移風險（一次性） |
| 效能 | 維持現狀 | 通常大幅提升（新一代 All-Flash） |
| 容量 | 無法擴充（EOM 後零件難取得） | 新設備可規劃未來成長空間 |
| 決策建議 | 僅在汰換成本遠高於維護成本，且合規風險可接受時考慮 | 大多數情況下，汰換的長期 TCO 優於繼續維護 |
通用概念
建置文件的撰寫原則
不論哪個品牌，提案與建置文件有幾個通用原則：
- 方向性優於精確性：「採用市場主流 NVMe All-Flash 架構」比「讀取速度 X GB/s」更安全，不會在驗收時被數字卡住
- 合規論述優先：EOS 風險、資安合規是最容易被決策層理解和核准的論述角度
- 容量用概估值：「約 XXX TB」保留解讀空間，精確到小數點反而引發不必要的爭議
- 效能提升作為附帶說明：新一代設備的效能提升是事實，但作為附帶效益說明，不列入驗收條件