原廠救不回的案例分享[ IBM 企業級儲存Storwize V7000 ] －分析當代封閉儲存架構

當架構是封閉專用系統，自行研發程式架構，要怎麼做底層資料救援恢復呢?
今天跟大家分享一個IBM Storwize V7000資料救援實際案例

一般RAID Storage只能對單Block Device做好冗餘、加速功能。
但企業級儲存還需要儲存共用池(Storage Pool)、快照(Snapshot)、精簡空間(Thin Provisioning)、分層加速… 等。
能實現以上功能的台廠Storage Server (含NAS)，都是以開源架構為主，基於mdadm, LVM, Btrfs, ext4, iSCSI LUN等作法。



▼以下是一個客戶求助於IBM原廠，希望救回數據，最終沒辦法處理的狀況下，經由IBM與其他間SI介紹到我們工程師這救援的實際案子。

「IBM Storwize V7000」：機器不穩、硬碟嚴重損壞、Metadata已經損壞

IBM Storwize V7000隸屬於從IBM DS8000下放的儲存架構。
可提供快照、精簡、分層功能，再分享成SAN與iSCSI/FC。
這台在長久時間運作之下，硬碟已有壞軌，並且經過一些操作上Metadata已經損壞。
整台儲存設備已經無法正常Mount


客戶先聯絡了IBM原廠考慮以下恢復方式：

▶對儲存進行強制上線操作，分析故障儲存中的故障硬碟離線順序
▶修復後離線的故障硬碟
▶將修復好的硬碟插回儲存設備，或是故意不修理，在Drive Missing狀態下進行強制上線操作。
這也是一般原廠技術能提供的恢復技術程度～


以這次案例來說，IBM是叫Tier 3 Recovery
流程如下：
1. 清除兩個控制器數據 Manager System — Remove System Data
2. 選 Recovery System — Prepare For Recovery 會出現下圖▽

3. 等待流程跑完

但此案例，由原廠處理的T5恢復，資料無法復原，並且Metadata可能已經動到
因此由於IBM原廠恢復層級僅到上述的程度，本案只剩底層數據恢復選項可以做了。

底層數據恢復 IBM 的MDisk架構分析

這邊要先完全搞懂Storage架構！
IBM Storwize的MDisk構成是由實體硬碟透過RAID 0/1/5/6/10模式所得來的，而這個MDisk並不像一般RAID直接轉成LUN，是要考慮單個或多組MDisk 組合。
MDisk要先歸類出是哪組Storage Pool，以及是採用Mirror, Stripe, JBOD哪種形式，最終再以當初設定 Pool 的方式分出不同的 Volume (LUN)。



以下是IBM Storwize的MDisk架構簡述：

▼IBM Storwize V7000系列的MDisk架構。

這個Storage Pool是由單MDisk所組成，而Storage Pool可以拿來建置映像模式的Volume，以便透過iSCSI等協定給Client端存取。
若Volume又是做FAT LUN，無做精簡，是最簡單的救援狀況！


▼接下來這裡可以看到此Storage Pool，由3顆MDisk所組成。

當使用者從這個Storage Pool建立一個Striped的Volume，那麼這個Volume真正存取到的MDisk磁碟排序，就會像右邊那樣的交錯方式。
這種要做資料救援，就得再多重解析不同儲存層的Pool架構～


▼而若在Storage pool建立一個Sequential的Volume，那麼這個Volume真正存取到的MDisk磁碟排序，就會像下面右邊那樣的循序的儲存式。
這種要做資料救援，會比上面的Striped Volume簡單一點 ～



為何有MDisk呢？
這是為了方便擴充容量、冷熱資料分層，以此可兼顧效能與備援擴充優勢。
例如你今天買了4顆10TB SAS硬碟，用RAID 5做成一個MDisk 1 (容量約30TB)，然後將MDisk 1規劃成Storage Pool，此時Storage Pool就有約30TB的可存取空間，未來若容量不夠用的時候，可以再另外新增硬碟，不需要將既有的RAID砍掉或是高風險單顆擴容。
可再擴充5顆16TB SAS硬碟，用RAID 6做成MDisk 2 (這樣容量約48TB)，然後把MDisk2注入Storage Pool，這樣Storage Pool總容量就等於30TB+48TB=78TB，這時候可以再割多個Volume給既有或是新裝好的ESXi伺服器使用，以便達到零停機的Scale-Up目標。


Storage Pool最終分割出的Volume (LUN)，還會有前端Bitmap，與真實資料區、延伸資料區(快照過後的資料)。




從以上資訊可以得知，IBM Storwize的儲存層，大致如下：

第一層：實體SAS FC SATA等硬碟 (真正裝在Storwize裡面的多顆硬碟)

▼PC3000 Portable SAS救援裝置修復資料

第二層: MDisk (由實體SAS or FC 硬碟以RAID 0/5/6/10建立而來)

▼這邊要做MDisk分析及重組，根據客戶給出的部分配置信息，將硬碟按照MDisk組分類。
分析每一組MDisk中的所有硬碟，得到相關RAID訊息、順序與Stripe大小。
嘗試找出對應硬碟，並組合成RAID (MDisk)，最終在dump成映像檔。

第三層: Pool 組態

Pool組態可依照當初客戶的設定資訊，來組合MDisk資料。
不過若是Stripe Pool，則必須要分析出Stripe Size大小。
如果是Sequential，用copy指令也可以做的
我們主要以Ptyhon腳本完成～～

第四層: Volume VDisk

如果為精簡(Thin Provisioning)，前端還會有Bitmap 延伸數據，必須先定位找出Bitmap與資料結構塊位置，找出算法。

第五層: LUN filesystem

以上組好的LUN，為VMFS。
客戶最需要的資料，是VMware vSphere下其中一個 Linux Server虛擬機裡面的Oracle DB檔案。
就必須使用到Windows Mount VMFS工具，以取出DB的VMDK檔案。

第六層: Data File

這次要取出的是Ext4檔案格式下的Orable DB檔案。
驗證Oracle DB是很麻煩的狀況
因為當下客戶的AP與DB Server 都沒有送過來～
我們工程師團隊這次是以驗證 dbf (Oracle DataBase Format)資料庫檔案，來進行恢復成功度的評估。
▼搭配Oracle的DBV (DBVerify)命令列工具，來做檔案內容一致性檢查

以這樣的方式做驗收，普遍都能得到客戶技術部認同的～～

透過以上層層分析、拆解與救援，最終將客戶資料救回！！！

－層層拆解分析，是資料救援的核心技術－
高難度數據恢復，必須如上所述，全方面從底層開始。

以上部分圖片引用自https://www.weithenn.org/2014/03/ibm-storwize.html
想看更多硬碟技術救援案例～
歡迎追蹤FB粉絲團：OSSlab Geek Lab
或是回文討論