VMWare thin provisioning 與thick 虛擬磁碟格式比較

Posted on Leave a commentPosted in 虛擬化

VMWare 在虛擬機磁碟設定時候 可以選擇 thin provisioning 與thick.但是不管效能或是資料安全性.
本文翻譯這篇 https://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf  後半段

先來看原文所說的thin provisioning 與thick 效能比較.

測試1:量測方法

每個 vSphere ESX 伺服器執行一個使用 Iometer 製造 I/O 負載的虛擬機。每個虛擬機的資料儲存硬碟都儲存在共享的LUN,而且,根據實驗的選擇將每個虛擬機的資料儲存硬碟配置為 thin-provisioned 或 thick-provisioned。

執行各個 Iometer 測試,每次2分鐘,然後重新啟動每個虛擬機。 Iometer 的完整重複執行包括通過1K-512K的所有區塊大小,並在適當的情況下使用依序和隨機讀/寫的工作量。 我們每個測試跑2分鐘,以便清楚地識別出 thick 和 thin 的兩個不同設定的階段歷程:

歸零,當VMFS區塊需要在它們寫入之前歸零

後歸零,當所有的VMFS區塊歸零之後,在寫入前沒有歸零需要使用空間

在測試的期間我們收集了以下的指標項目:

使用Iometer測量Guest I/O 存取量與延遲

Host 處理器的消耗量

使用EMC Navisphere analyzer 量測陣列端的存取量與延遲數

SCSI 保留衝突

VMDK資訊例如預備歸零的區塊與VMFS層在測試前後的區塊數

 

測試 1 結果

這個測試的結果回答了以下這些問題

1. thin provisioning 的表現與 thick 的對比?

2. thin provisioning 的規模與 thick 的相比?

3. 在 thin 磁碟上對於外部的碎片有什麼樣的效能衝擊?

4. 當一個 thin 磁碟分享同一個容量時 thick 磁碟的效能?

thin provisioning 的表現與 thick 的對比?

我們的測試顯示出thin與thick磁碟在比較時都有相同的存取量,圖四顯示了執行連續寫入的結果。

這張圖顯示出在後歸零階段的thin與thick磁碟這些工作量的總存取量大約在每秒180MB,以及當磁碟是在歸零階段時大約是每秒60MB。因為當空的區塊在第一次寫入時需要歸零,因此歸零階段的數字在兩種磁碟都如預期的大幅降低。

 

圖三:thin磁碟的總存取量與thick磁碟相似

對於更常見的工作負載(這些並非I/O密集型的工作負載)。請注意,歸零和後歸零階段的磁碟總存取量在這個測試中沒有顯示出明顯的差異

thin provisioning 的規模與 thick 的相比?

要回答這個問題,我們收集了 1 台機器上的連續寫入資料並且擴增到 16 台。

圖4:比較thin與thick磁碟在歸零與後歸零階段的存取量,並且將資料量從1台擴增到16台

結果顯示了thin與thick虛擬磁碟在歸零與後歸零階段也是相近的存取量。

還有值得注意的是當我們從少量擴增到大量 host 時我們沒有看見任何 SCSI 保留衝突對效能的影響。

在 thin 磁碟上對於碎片有什麼樣的效能衝擊?

要回答這個問題,首先需要看看兩種類型的碎片:內部與外部,對於VMFS-3檔案系統的影響。

內部碎片

內部碎片通常在檔案系統設置一個檔案的區塊時,但檔案沒有使用整個區塊。VMFS-3透過使用次級區塊配置器處理這個問題。小檔案使用次級區塊來替代檔案區塊。一個次級區塊是1MB檔案區塊大小的1/16,8MB大小檔案區塊的1/128。

外部碎片

外部碎片發生在隸屬於同一個檔案的區塊分散在不同的位置,這種分散式資料會因為增加搜尋時間跟旋轉延遲而影響效能,而這正是硬碟磁頭物理移動到正確軌道所需的時間。

舉例來說,一個虛擬機的檔案可能會在物理的磁碟儲存空間分為三個非連續性的區塊位置,如下圖所示,碎片就是兩個區塊間的距離,如下圖標註為gap的區域

圖5:當虛擬機器資料寫入VMFS的非連續區域而變成碎片

外部碎片對 vStorage thin-provisioned 磁碟沒有產生太大的影響是因為下列幾個原因:

VMFS預設的檔案大小是1MB。因為大多的I/O請求是64KB,1MB的VMFS區塊對多數的I/O請求而言是夠大的空間,不會超出邊界。所以就算區塊不是連續的(沒有彼此緊鄰),I/O請求也會執行在本地連續(相近的)區域。

當 thin-provisioned 磁碟完全成長,它的動作會跟預先分配並歸零的(eager zeroed thick)thick磁碟相同。在一個完全歸零與成長的磁碟上,兩個資料間的間隙通常就是區塊的大小一樣大。

磁碟陣列通常有很大的快取,大多數的磁碟寫入會在那邊被吸收。SAN裝置的這個特性使得碎片在磁碟寫入的效能上很難有顯著的影響。

特定的 thin 磁碟上碎片如何增長?

通常,虛擬機被註冊到分配的主機,並且主機的區塊被分配得更靠在一起,使被分配的虛擬磁碟在實體磁碟上的檔案區塊有空間位置。 配置的過程也取決於分派ESX主機上運行的工作量。

thin-provisioned 磁碟不會預先分配它的儲存空間。也因為如此,如果有幾個 thin-provisioned 虛擬磁碟正在使用著,那麼即使整體上從該 ESX 主機配置的區塊將緊密結合在一起,也不能保證單一 thin-provisioned 虛擬磁碟的分配磁碟會靠近在一起。

下圖顯示了碎片數量對 VMware vStorage thin-provisioned 磁碟的性能影響很小。

圖6:碎片對於 thin 磁碟上存取量的性能沒有明顯的影響

上圖所示的數據來自64K隨機寫入。這些碎片是通過將這個 thin 磁碟擴增到 12GB 的同時選擇適當的工作量而製造的。 利用 1KB 隨機寫入工作量來產生一個空的 12GB thin 磁碟,產生 1MB 區塊大小的 VMFS 容量裡有最多 12288 個碎片。 一個 1KB 的連續寫入製造了極少量的碎片,就不列入參考。

當 thin 磁碟跟 thick 磁碟在同一個容量空間時的性能?

下圖顯示了當thin磁碟在歸零階段時,thick磁碟的存取量性能只有被輕微影響

圖7:當thin磁碟同時與thick磁碟共存在同一個主機時的性能影響

測試 2:檔案拷貝的工作量

測試 2 要測量 thin-provisioned 磁碟加上相對輕量的檔案拷貝工作量。

測試 2 環境設定

下圖描述了為了此測試而設計的硬體配置

圖8:測試 2 的硬體配置

三台伺服器

型號: HP ProLiant DL380
處理器: Two Intel Xeon processors @ 2.8GHz with hyperthreading Memory: 4GB RAM
光纖卡: QLogic ISP-2432 based 4Gb adapter

儲存陣列

型號: EMC Clariion CX700
快取: 1GB exclusive read cache per SP, 2GB shared write cache
磁碟: 15 * ST371460 Seagate 10,000 RPM FC disks
前端連線: One 2Gbps FC connection to each storage processor in Active/Passive mode

虛擬機群

用戶端: Windows Server 2003 Enterprise Edition, 32-bit, 1 vCPU 512MB RAM (16 client VMs, 8 VMs per host)
伺服器端: Windows Server 2003 Enterprise Edition, 32-bit, 2 vCPU 1GB RAM

 

測試 2 量測方法

 

測試 2 測量在兩台ESX主機上的多台客戶端虛擬機上同時操作的複製檔案的性能表現,同時檔案是由另一個獨立的ESX主機上的SMB檔案伺服器虛擬機提供。網路使用專用1Gbit環境傳輸。每個客戶端VM將檔案從網路上複製到自己的虛擬磁碟,直到塞滿容量。在每次循環期間複製約290MB的檔案。所有客戶端虛擬機的虛擬磁碟設定在單個VMFS上。

透過這樣的配置,我們測量了各客戶端VM進行每個循環的檔案複製平均時間,同時將虛擬磁碟的後備磁碟類型更改為 thin(歸零)、thin(後歸零)、zeroed thick 和 eager zeroed thick。

 

測試2結果

 

下圖顯示了測試2的結果

圖9:在多台虛擬機器間複製一個檔案工作量的測試結果

結果更增強了我們之前所說的:

 

透過圖表比較 Thin(zeroing)與 Zeroed thick,thin-provisioned 磁碟與預設的磁碟格式(zeroed thick)在區塊配置與歸零階段相比並沒有效能的差距。

 

透過圖表比較 Thin(post-zeroed)與 Eager zeroed thick,thin-provisioned 磁碟由於碎片的影響而沒有效能的差距,而且跟完全配置的 zeroed thick 磁碟(eager zeroed thick)相比也是一樣。

 

效能建議

 

這一節提供陣列端的 thin provisioning、效能測試與監控的建議

 

陣列端的 Thin Provisioning 與 VMware vStorage Thin Provisioning

 

有些儲存陣列製造商在 LUN 的後端使用 thin provisioning。這種類型的 thin provisioning 可以做到第一次訪問時根據需求去 provisioning 以及需求區塊初始化。陣列也可以包含其他節省空間的措施像是刪除重複的 zeroed 區塊。

 

VMware vStorage thin provisioning 透過工作量最佳化它的空間,允許更多的虛擬機器來符合資料的儲存。陣列端的 thin provisioning 可以進一步最佳化物理的空間。您可以在您的 vSphere 環境中一起使用 VMware vStorage thin provisioning 與陣列端的 thin provisioning。不過,我們建議小心監控並管理 thin-on-thin 系統。

 

性能測試建議

如果您使用 thin provisioning 磁碟做性能測試,請確保您有足夠的時間把 thin 磁碟暖機,這樣才能完全的成長,或能確保您性能測試裡追蹤的 nb 與 tbz 值,也才能讓您知道 thin 磁碟正在經歷何種階段。

 

其他建議

 

我們建議使用警報來幫助監控 thin 磁碟的超額使用。特別是以下這些警報觸發會特別有用:Datastore Disk Usage % 與 Datastore Disk Overallocation % 。使用 VMware vCenter 伺服器,您可以提供報告以及設定臨界值來主動管理增量及容量。

 

Thin provisioning 可能會造成物理磁碟空間的超量使用。您可以使用 Storage VMotion 來管理超量使用,也能透過它來管理 VMDK 的動態融合或者 VMFS 的容量增長,以及動態增加您的資料儲存空間。

 

注意:Swap 檔、redo log、與快照的連結複製不會使用 thin provisioning.

 

結論:

 

在本文中,我們確定了 thin-provisioned 磁碟與 thick-provisioned 磁碟在歸零與後歸零階段的磁碟成長狀態有著非常相近的運算量。另外,將伺服器從1台擴展到16台能夠看到機器的增加能改善總存取量。當所有的磁碟都被配置與歸零完畢,存取量也如預期的維持在一個穩定的狀態。下一步,我們展示了外部碎片對效能的影響是微乎其微。最後,我們看到一個 thick 虛擬磁碟與一個 thin 磁碟共存的虛擬機器上性能也幾乎不受影響。另外對 thin provisioning 與 thick provisioning 複製檔案工作量的比較顯示兩者也是相當的。歸零與後歸零階段的磁碟成長量的I/O低到可以被忽略。

 

我們收集的數據顯示 VMware vStorage thin provisioning(thin虛擬磁碟的用量)與 VMware vStorage 預設方式的 provisioning (zeroed thick 虛擬磁碟的用量)有著同等的效能。此外 VMware vStorage thin provisioning 提高了儲存空間利用率,可以節省物理儲存硬體。

 

但是就資料安全性來講 由於thin provisioning 中間已經沒有GAP .因此.Raw Recovery 算法已經無效. 若Bitmap沒有保留 是不可能再將thin provisioning  磁碟格式資料內恢復的.
我們將會在下一篇文章分享與討論VMFS  的bitmap. 

 

附錄

 

這一節包含了重新創建這個測試的資訊,包括有:

如何使用 thin-provisioned 磁碟

to-be-zeroed 區塊(tbz)與 number of blocks(nb)的描述資訊,與如何找到這些訊息。

 

使用 Thin-Provisioned 磁碟

使用 thin 磁碟製造虛擬機器可以讓這些磁碟存取比它們實際使用上更大的空間。這個儲存空間被分配並在虛擬作業系統得用更多空間時使用VMFS-3的驅動來根據需求擴展。

 

虛擬磁碟在創建的過程中設定為 thin 是很簡單的,在 Create a Disk 頁面,選擇 Allocate and commit space on demand (Thin Provisioning) 的選項

 

已經存在的 thick 磁碟在 Storage VMotion 的遷移過程中也可以轉換為 thin。在 Disk Format 頁面,選擇 Thin Provisioned Format。

 

在命令列使用 vmkfstools 輸入以下指令可以將空間利用不完全的 thick 磁碟空間轉換成 thin :

vmkfstools –i <thick_disk>.vmdk <thin_disk>.vmdk –d thin

 

To-Be-Zeroed Blocks 以及 Number of Blocks

Zeroed-thick 磁碟與 thin 磁碟都會經過歸零與後歸零階段。為了在我們的實驗中進行數據收集和解釋,我們定義了 to-be-zeroed blocks (tb) 與 number of blocks (nb) 在 zeroed thick 磁碟與 thin 磁碟的變量。因為 zeroed thick 是 thick 虛擬磁碟的預設配置方式,因次這次研究中就不包含 eager zeroed thick 的數據。

 

針對 thin 與 zeroed-thick 磁碟類型,我們做了以下的設定:

tbz 是要歸零的區塊

nb 是現用磁碟的區塊數而且 nb = 磁碟大小(MB)/VMFS區塊大小(MB)來定義磁碟的預先配置狀態。

 

Thick 虛擬磁碟

在進入歸零階段之前,以下狀況在 thick 磁碟上都是正確的:

nb=磁碟大小/VMFS區塊大小,因為它的區塊被預先配置了

tbz=nb ,在啟動時。

thick 磁碟在進入歸零階段時,tbz 會減少所有的區塊直到0為止(沒有區塊留下來歸零)

圖10:thick 磁碟預先配置了12GB,在歸零與寫入的過程中,nb=12288(每個VMFS區塊為1MB,在12GB磁碟中有12288MB)

 

Thin 虛擬磁碟

在進入歸零階段之前,以下狀況在 thin 磁碟上都是正確的:

啟動時 nb=0,因為磁碟並沒有被預先配置

啟動時 tbz=nb

歸零階段的 thin 磁碟:

nb 從 0 增加到磁碟大小/VMFS區塊大小

tbz 為 0 ,當區塊被增加以及需要歸零的時候  

圖11:Thin磁碟(1MB VMFS區塊大小)當增量、歸零及寫入直到12GB,這時候 nb=2

 

當 thin 磁碟完成歸零階段,它會因為以下條件進入後歸零階段:

nb=磁碟大小/VMFS區塊大小,當區塊被配置後

tbz=0,因為所有區塊被歸零

在這個階段,thin 磁碟跟 zeroed thick 磁碟有著相似的動作與效能。請見表2,數值與 Post-Zeroing 是相同的。

表2:thin 與 thick 磁碟都為 12GB, tbz 與 nb 在歸零與後歸零階段的數值 – VMFS 區塊大小在這個範例均為 1 MB。

 

獲取實際數值

在測試中,磁碟的 tbz 與 nb 值是用以下方法決定的:

vmkfstools –D <flat-disk.vmdk>

我們檢視了 /var/log/messages 中 nb 與 tbz 的資料:

vmkernel: FS3: 142: <START flat-disk.vmdk>
vmkernel: Lock [type 10c00001 offset 64833536 v 734, hb offset 3940352
vmkernel: Addr <4, 121, 193>, gen 592, links 1, type reg, flags 0x0, uid 0, gid 0, mode 600 vmkernel: len 12884901888, nb 12285 tbz 0, cow 0, zla 3, bs 1048576

log 最後一行顯示 nb 與 tbz 區塊。在上面的例子中,這個磁碟已經完全成長與歸零。

 

 

 

 

 

 

 

 

 

 

虛擬化救援案例 (3) 四天搶救服務器Raid與156個快照修復

Posted on 2 CommentsPosted in 虛擬化
前面的虛擬化救援案例 
虛擬化救援案例 (1) Vsphere 、Synology、iSCSI

虛擬化救援案例 (2) Vsphere 、NFS

在2017 三月清明連假前 4.1 PM:4:00
OSSLab 又接到客戶系統Server   4顆 300G SAS 硬碟 .Raid 5 . 虛擬化用vsphere 6 因為硬碟壞軌 ,硬碟 離線 0 , 3 (也不知離線時間前後順序) 
客戶表示好像快照到一半就掛了….. 

 
這邊最重要的就是 要替硬碟做鏡像先
SAS 壞軌硬碟要準備SAS等級資料救援設備.DD3000 .DD3000 設備可以做SAS硬碟斷電控制 SAS控制卡讀取.跟SAS Retry 
 
好的硬碟則使用我們全鏡像 Server .  15 bay  空bay 隨時待命,能讓所有客戶硬碟用最高速10GbE 網路傳到我們的服務器上。
才能在第一時間將客戶資料救援出來。
 
 

四個小時內 我們已經有全部硬碟的DD(鏡像)檔案 了 

 
客戶對於時效很急迫 因此我們在假期出動三個工程師 兵分二路同時進行  
法一.以原硬碟結構倒回陣列Server去 
 
將壞軌硬碟跟好的硬碟都 備份到新的硬碟上去   玩麻將四缺一遊戲
 
 
 
 
 
陣列卡選到 Foreign View Scan Foreign 想辦法匯入原陣列資料
注意這個方法 是用新鏡像的硬碟做的. 請不要去動原硬碟 並且我們有保留原硬碟DD鏡像
 
準備 USB Vsphere Boot 看看有沒有機會可mount 這Datastore ..
並沒有看到Datastore
 
到介面下這指令

Rescan Datastore (VMFS ) 還是沒有資料
 
第二路 
用”肉眼跟大腦”根據檔案系統 算出   硬碟陣列排序  (Strip size 應該為1024KByte) 
 
 
組合Raid 生成總RAID 鏡像 
 
 
 
 找到VMFS分區.
 
 
客戶最重要資料是DB VM 但裡面竟然空的
 
我們分析過了  missing 2 硬碟 狀況下才有這目錄下的vmdk .(沒錯 必須要用離線硬碟 才會有正確資料)
 
 
 
 
但這時發現客戶做了15x個快照 XXXXXXX
 
 
 
這時候遇到麻煩了 …客戶要最新的資料 
解析VMDK快照 ,技術長說 他會解析. 他說七年前他沒解析成功 就會被市刑大抓進去了..
市刑大,Windows 2003, 虛擬化VMDK修複 – 酷!學園 – Study-Area
 技術長好不容易把157個 VMDK 指引一個個看完跟修正. 用SFTP 倒回去vsphere  .

發現連登錄VM都不行.

 
 

手動下指令註冊虛擬機  vim-cmd solo/registervm /vmfs/volumes/datastore_name/VM_directory/VM_name.vmx

 
VM匯入看似成功 不過有報錯

 
 
 
 開機執行報錯
 
這時就要思考 這些快照檔連續性問題了…
 
2 .轉換與修復 快照檔 
這邊看看有沒有辦法將快照檔轉成Flat檔 並且做檔案檢查
http://www.vmware.com/pdf/VirtualDiskManager.pdf

vmware-vdiskmanager -R 快照索引檔vmdk  修復快照檔
vmware-vdiskmanager -r 快照索引檔vmdk -t 0 目標flat快照檔
使用vmware 工具 vmware vdiskmanger轉換快照檔為flat 第一個快照檔成功
 
 
轉換之後快照檔出現 Uncoveryable memory alloacation
之後換了不同版本 vmware vdiskmanger 與電腦都一樣錯誤訊息 . XXXXXXXXXXXXXXXXXXX
 
 
PANIC 當機!!!
 
來 換 vmkfstools  
vmkfstools -i XXXXX-000019.vmdk J880000019.vmdk -d thin 
 
DiskLib_Check() failed for source disk ‘XX-DB-000001.vmdk’: The specified feature is not supported by this version (24).
 
 
 
再次兵分二路計畫
A 組盡量修復 VM
B 組盡量能搞到最新版本快照內的mysql 撈給對方….
先Mount VMDK 吧.
 
VMware 官方Mount程式不吃 半損VMDK …>< 
 
 
寫一個小程式提取殘缺VMDK內資料..
 
 
 
Mysql 有報錯 但是還是先交給客戶了.. 
A 組盡量修復 VM
既然原廠工具不支持  自己寫了一個程式 修復快照 
超密技 述省略…..
VMX 也要修改  device 要轉向到修好的flat.vmdk
 
 
 
VM 可以開啟
 
完美Boot DB 都正常
 
 
 
 
我們在四個工作天左右 約99%恢復客戶在上面所有VM

結論

這個案件難度是非常高. 我們預估就算是VMWare 原廠Support 成功機率應該也低.

這案例能夠能夠成功救出來資料95%最大原因.
是因為客戶沒有先找其他廠商 .
其他廠商很有可能會先做了 rebuild 跟 fsck 都會造成很高的 資料恢復難度. 
而是選擇了OSSLab實驗室 .
直接有效在短時時間搶救恢復客戶所要數據.

虛擬化救援案例 (2) Vsphere 、NFS

Posted on Leave a commentPosted in 虛擬化
報告單6TB

這邊再來分享OSSLab 虛擬化儲存救援狀況 

客戶原始架構
Vsphere 5.x  ,Synology  NAS  .6TB *3  (發生的狀況如下 )
1. 硬碟一直離線又強制上線  不同顆  並且疑似有 Rebuild
2.一開始可以Mount 後來連Mount都沒辦法.
3.一樣也是找了Synology公司 FAE處理 再找SI.都無法解決問題

此案例不同於前案例 .客戶有可能做了大量Rebuild ,
並且由於客戶非常狀況外. 其實連原始設定都不知道. 

處理這種案例 最重要的第一步 必須必備超大型的儲存Storage .
為了安全起見  如果需要做  Rebuild ,fsck 動作 全扇區備份一份是一定要的.這會吃掉一份空間
為了組合 Raid img 又一份 空間
為了倒出資料 又一份空間

這案例 目前還用不到做Rebuild ,fsck 狀況 .因此資料量約 2倍就可.. 
大體上 準備30TB 空間是必備的 .

如果一間資料恢復公司 沒有這些空閒超大儲存空間 .
是無法在最快時間與安全的救援大型Stroage .

image

NFS 虛擬化架構,其實會很單純的VMDK檔案放在ext 4 檔案系統上. 要先組好Raid Block Device. 
因為有過Rebuild 要先修復ext 4檔案系統,再拉出裡面的虛擬化檔案.
Rebuild 也有可能破壞到虛擬化格式檔案.
所以還要做虛擬機檔案格式修復.
更慘必須使用 File carving技術來取得檔案. 但是完整性會降低很多.

必須再三強調 rebuild 跟 fsck 都會造成很高的 資料恢復難度. 若資料重要 請先每顆硬碟都做全扇區備份.
但是照一般SI與NAS FAE流程就是先嘗試會這樣處理 (他們是免費的服務 不太可能處理太完整 )

分析Raid 5 結構 
每顆硬碟前面分區為 NAS  OS位置. 先取得真正DATA 區 偏移位置,
由於多次Mount 原有 MDADM  Raid metadata 已經完全不正確…
剛好客戶客戶是用 thick provisioning我們藉由虛擬機內的 NTFS 的檔案系統的MFT 來分析出Raid 硬碟排列與Stripe size 大小. 判定出 64 Kbyte =128 Sectors Stripe size

排列方式如圖

 

客戶對 還是 hex 對?

把分析後的結果用Winhex組合後發現跟客戶說法完全不一樣!
客戶明明說是 3 顆Raid 5, 實際上發現應該是4顆raid 5 (missing 一顆)
在這種狀況下.
要針對整個Raid Storage 做 前 中 後 三個區段數據正確性分析.   
因為做過Rebuild 前有可能跟中後段資料不一樣.

觀念上是所需要那區資料原來是怎樣就怎樣 就是最正確的
但整個跑下去非常耗時間… 

但這邊有一個基本方法可以了解 我們先搜索一些DB常用英文單字  (select ,query,from )
搜索後 發現有一大段明文在位於 361 178 534 sector(約單硬碟180GB位置  ) 一大段的明碼區可以幫助我們再確定是否校驗正確

image

再看一次Raid 結構圖  Stripe size=128 Sectors  
在一大段明文中 是最簡易判定Raid 是否有錯誤. 有錯誤就會有亂碼 

我們跳躍大概12個 Stripe size =1536 sector  
Winhex 選Go To Offset

image

 

發現這邊也是明文 .上下捲動 到前面原先扇區 發現全部都是明文 沒有任何亂碼

image

可以看到明碼的英文,證明這段RAID 的排序跟方向Stripe size 正確 

這時候開始考驗硬體了. 組合所有 Raid 
轉成超大鏡像檔案

上次iSCSI虛擬化救援案例有提到 會有三種狀況.

  1. 整個iSCSI Lun都還可mount ,裡面的 分區跟檔案系統 ,裡面VMDK都正常
  2. iSCSI Lun 文件系統大體完整或可救、重要的VM 檔案都還在、檔名也正常,  VM還可正常Boot
  3. 前二種都無法成功,只能用Raw Recovery 技術撈出 VMDK裡的檔案 ,能拿回多少就多少

本次ext 4+NFS 案例 由於大量Rebuild狀況. ext 4 文件系統都已經毀了.
因此只能使用 File Carving (Raw recovery)手段來做整個分區與虛擬化檔案救援.

方法為
先將所有硬碟生成一個超大Raid dd鏡像檔案
再用自行編寫File carving程式將檔案恢復… (使用此技術會有一定風險檔案打不開)

碎片恢復成果:
虛擬機檔案無法恢復.
但碎片恢復:如Office 文件 , MOV,照片檔案部份都可以正常打開 (因為保護客戶所以打馬賽克)

 

試著打開 office文件 , mov 文件.都可正常打開

 

 

 

這次案例完整性不如上次良好 其實原因都在於客戶做太多破壞性的操作 

遇到企業儲存損壞
必須要在 上線時間, 備份檔完整度 ,處理方法. 成本做一個取捨 .
當資料真正重要時自己或是找委外廠商(如OSSLab)先低成本備份鏡像.
再給系統整合廠商或是NAS FAE 處理
在處理不行時候 再交給資料救援廠商.這也是一個作法

瞭解真正技術運作原理 就會知道怎樣在最合理成本下去規避風險 取得平衡

 

虛擬化救援案例 (1) Vsphere 、Synology、iSCSI

Posted on Leave a commentPosted in 虛擬化

虛擬化集中化帶來了管理上方便 資源的集中. 整體硬體設備成本降低 .但是隨之而來的問題
就是資料會非常非常重要  一旦這個雞蛋籃子破了 後果不堪設想
(這篇文章就是要來討論如果籃子破了怎樣撈蛋汁跟蛋黃)

一般而言 在虛擬化規劃內
或有主機HA 跟Storage replication .
當然若有再一個備份Agent .與異地備援更理想  

 

上圖是客戶虛擬化架構
 HyperVisor 是用 VMware ESXi 5.1  兩台 Synology DSXXX做Storage Server
這邊客戶用上了  Synology High Availability 來保持在NAS內的資料與iscsi Lun的同步

想要對Synology High Availability 實用狀況更瞭解可以參考這 

這邊推測DRBD軟體實現了 Synology High Availability 功能, 客戶這樣規劃與設計也沒無不妥當

狀況是客戶在進行年度保養維護的時候停電時候,可能是沒留意到 VM 是否還在存取的情況下,就先把 Storage 關機,
再去關閉 Hyperviosr esxi,當再次開機之後,VMFS Datastore 已經損毀,無任何VM檔案存在。

  1. SI 有針對二個node lun個別掛載Lun , 但二個Lun esx 系統 都無法辨識Volumne。
  2. IQN Name 有無變化 等也找過。
  3. VMware上有一堆KB (Knowledge Base)  VMFS Undelete 也無解
  4. 詢求過 Synology  FAE Support 無解。

送到本實驗室來

先檢查儲存Server硬體狀況:

再檢查Raid 結構看似正常 (客戶也沒做過 Rebuild動作)

硬碟健康狀況正常 

 

這台機器有 8 個槽,全部使用 WD 3TB 構成,每四顆作為一組成為兩個陣列,每個陣列是使用三顆硬碟做 RAID 5,以及一顆做備援。

 

 iSCSI  Lun image 檔案完整度”看似”正常

 

客戶用的是  iSCSI  Lun (Regular img File  ) 也就是說iSCSI Lun存在NAS 檔案層系統上的 Image File 

 

 


要得到最上層的資料 File level 的iSCSI Data 跟 ohter Data 必須要滿足下面條件

  1. 硬碟無物理與韌體上損壞. 扇區讀取正常
  2. Storage Pool (Raid 順序 、排列方法、 stripe size  ) 都是正確的
  3. NAS  檔案層 (ext4 or Btrfs) 要正常 .
  4. iSCSI img File 結構要正常 
  5. VMDK檔案結構也要正常

這狀況推測  iSCSI Lun 內VMFS 分區跟檔案系統損壞的問題..
更深入瞭解請參考OSSLab的演講 架構儲存虛擬化合一與企業級儲存救援

 

開始準備恢復方法

一般說 這iSCSI  image file放在  “[email protected]/”.

在不改變客戶原有Storage設定與環境下 (假設客戶的Storage 有部分資料還是好的 日後還要上線這很重要)
先把 iscsi target 掛載起來(此圖已經屏蔽 iSCSI iqn Name)

掛載後最重要的事情 先DD (鏡像全扇區) iscsi Lun 

恢復虛擬化架構資料 會考慮到三種成果

  1. 整個 Lun 都還可mount ,裡面的 分區跟FS (VMDK檔案也都正常 )
  2. 重要的VM 檔案都還在,  VM還可正常Boot
  3. 前二種都無法成功,只能用Raw Recovery 技術撈出 VMDK裡的檔案 ,能拿回多少就多少

由於現在客戶大部分在iSCSI  Lun 與VMFS 層都有做thin provisioning.對於現有的資料救援軟體成功率都是偏低的.

網路上也沒VMFS文件系統敘述 這該怎辦?

Use The Force Luke !(可以用正念波還原資料嗎?) 

 

只能讀各路神人不知道怎寫出來的工具原始碼 VMFS TooL 改寫跳過檢查完整性方式 ,用Cygwin 編譯 
(閱讀原始碼後 會發現 VMFS 基本上就是EXT4 +LVM的修改版)

提取VMDK  (跳過 vSphere On-disk Metadata Analyze)
讓自己程式盡量Mount. OK開始提取資料

VM驗收 (列舉其中一台)

 

怎麼做可以避免這樣的問題發生,或是真的發生了該怎樣解,或是減輕費用的支出,我們歸納出幾個要點:

1. 備份的策略要更完備

原本客戶的環境是有做HA,但是很明顯的在某種情況的故障之下,這個架構是無效的,那就要更小心做好備份規劃,在這個案例中能改善的像是:

  • 虛擬機器的多重快照備份
  • 再多一個獨立儲存設備做第二份備份
  • 異地或雲端空間的備份(可參考虛擬化與雲端備份整合

 

2.  資料恢復手段只能留做最後手段,但當災難發生時候 如果發現備份的資料不對 或是太舊  若想要保有原資料請盡量保持原儲存裝置狀況,不要自行做任何處理,
像是新增或修改LUN, FSCK  Rebuild  VMware 某些KB 方法等 動到檔案層結構都有風險,要做這些動作前,請先對最底層Storage做快照,無法快照就要對Storage Pool做DD (鏡像全部扇區),
不然處理過後,會大幅度拉高資料救援成本並可能造成救回的資料再也無法挽回。

3. 要找怎樣的資料救援公司,在這個案例中,至少要有以下幾個要點:

  • 要有完整的設備:
    硬碟救援設備 PC3000 MRT  完整硬碟材料庫  訂製光纖轉卡 10G 網路服務器 虛擬化實驗室  超大儲存空間 這樣處理每個層面儲存裝置的問題。
  • 了解陣列、檔案系統結構、虛擬化架構 :才能第一時間的處置跟該救援什麼樣的資料,也才能對未公開檔案格式(如VMFS)做逆向推測 ,
    最終要驗證救出來的資料是否可用…等。
  • 受過專業援技術訓練