Skip to main content

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

但當架構是封閉專用系統,自行研發程式架構,要怎樣做底層資料救援恢復?

以下是一個客戶求助於IBM原廠,希望救回數據,最終沒辦法處理的狀況下,
經由IBM與其他間SI 介紹一致建議送到OSSLab的實際案例。

機器不穩、硬碟嚴重損壞,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 的MDisk架構分析

由於IBM原廠恢復層級僅到上述的程度,因此本案只剩底層數據恢復選項可以做了。

這邊要先完全搞懂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? 這是為了方便擴充容量,跟冷熱資料分層,可兼顧效能與備援擴充優勢。

例如你今天買了10TB SAS硬碟4顆,用RAID 5做成一個MDisk 1 (容量約30TB),然後將MDisk 1規劃成Storage Pool,此時Storage Pool就有約30TB的可存取空間,未來若容量不夠用的時候,您可以再另外新增硬碟,不需要將既有的RAID砍掉或是高風險單顆擴容。

可再擴充16TB SAS硬碟5顆,用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裡面的多顆硬碟)

若硬碟有硬體或韌體損壞,必須修復 。OSSLab實驗室有 PC3000 Portable  SAS救援裝置,可以處理這類問題。


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

這邊要做MDisk分析及重組,根據客戶給出的部分配置信息,將硬碟按照MDisk組分類。
分析每一組MDisk中的所有硬碟,得到相關RAID訊息、順序與Stripe大小。
OSSLab擁有專業的數據恢復軟體,可對MDisk進行軟RAID重組。

▲ 嘗試找出對應硬碟,並組合成RAID (MDisk),最終在dump成映像檔

第三層: Pool 組態

Pool組態可依照當初客戶設定資訊,來組合MDisk資料。不過若是Stripe Pool則必須要分析出Stripe Size大小。
如果是Sequential用copy指令也可以做的。 🙂
我們主要以ptyhon腳本完成,參考python腳本範例放在這。(非本次救援用腳本)


第四層: 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 都沒有送過來。
OSSLab這邊是以驗證 dbf (Oracle DataBase Format)資料庫檔案,來進行恢復成功度的評估。
搭配Oracle的DBV (DBVerify)命令列工具,來做檔案內容一致性檢查,我們以這樣方式作驗收普遍得到客戶技術部認同。

▲ 使用DBV工具查驗dbf資料庫檔案內容完整性

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

層層拆解分析,才是資料救援真核心技術

高難度數據恢復,必須如上所述,全方面從底層開始。並必須具備:

1. 有SAS、SCSI、FC硬碟維修設備與經驗
2. 對Infra、原廠處理手法,架構有經驗
3. 能拆解底層檔案系統與算法
4. 核對也必須科學專業

這樣才是完整的數據恢復技術流程!

 

以上部分圖片引用自 https://www.weithenn.org/2014/03/ibm-storwize.html

 

Thx Chang

Author Thx Chang

More posts by Thx Chang

Leave a Reply