RAID VD復原案例

Combined revision comparison

這個案例是前幾天我前一家任職的公司遭遇到的, 因為它們的MIS看不懂要怎麼解決問題, 所以就緊急找我去修RAID. 由於這是一個中小企業, 並沒有能力(錢)去找SI的solution, 所以自然而言大多問題都是MIS處理. 在這個案例的數據結構是這樣的, 是一個LSI RAID 5 VD(IMR), 使用的控制器為LSISAS2008. 三顆RE3 500GB加一顆RE3作為HSP組建Web Server. 以前曾經有提過, IMR的LSISAS2008因為Software RAID Stack的關係, 性能都受到很大的限制, firmware-based RAID為cacheless, 以致在parity RAID mode得到非常悽慘的寫入性能. 不過由於該案例是作為一個流量很小的Web Server, 所以寫入速度到不是那麼需要去苛求.
我來說明這個問題的描述, 情狀如下:
一個以LSISAS2008運作RAID一家小型企業, 有一個以LSISAS2008運作RAID 5 VD, 這個系統穩定運作. 有一天其中一顆PD突然掉盤, 然後會有一個HSP開始進行Auto-rebuild. 不幸的是, 在rebuild過程中, 他遭遇到區域性斷電問題(ex: 某區域性停電措施), UPS可以撐住, 但是不能撐太久, 所以他還是電源丟失了. 等到電源開始正常運作之後重啟動, MIS遇到了一個挫折性問題:
1. VD數據毀損.
2. rebuild無法進行操作.
在這個情況下, 比較麻煩的是在rebuild過程中發生電源異常, 首先先想想在normal status的情況下, 如果發生掉盤導致COD不正確, 因而讓VD無法正常運作. 如果將被drop掉的PD重新再插入, 這時RAID controller進行scan後, 會發現有一部分COD存在, 會判定為foreign status. 事實上全部PD都是正常的, 只是因為莫名其妙的drop情況讓VD無法運作. 一般在一顆PD的故障情況下, 如果有HSP存在, 便會開始進行Auto-rebuild機制:
1. VD掛掉, 存在HSP會便開始進行Auto-rebuild.
2. 如果將bad slot的PD重新再插盤, 並且轉為Unconfigured Good status.
3. 當rebuild操作完成之後, 應當要進行copyback處理.
Note: When a drive fails or is expected to fail, the data is rebuilt on a hot spare. The failed drive is replaced with a new disk. Then the data is copied from the hot spare to the new drive, and the hot spare reverts from a rebuild drive to its original hot spare status.
從上述的流程來看, 這個典型的情況應當是要進行這樣的操作. 但是PD皆屬正常的情況下, 進行rebuild並不是那麼划算, 在LSISAS2008進行4顆PD的rebuild, 需要花費將近9hrs的時間. 而且超過2個盤掉盤的情況下, 這個作法便會失效, 因為RAID 5只能在一個PD丟失的情況下, 才有辦法利用parity進行XOR反解出正確的條帶數據.
如果是超過兩個盤掉盤且PD是normal status, 有一種方法就是強制給他online, 這樣的操作居多都可以使VD重新在運作. 但是如果這方法沒有效果, 另外有一種方式為VD creation without initialization, 這個做法其實就是將存在於DG(Drive Group)下的PD, 把應用在VD的PD的COD摧毀, 可以在WebBIOS或著MSM使用Clear Configuration達成. 然後重新在建立VD, 並且注意下面的提醒:
1. 確保條帶大小與之前的VD一致.
2. 請勿更換盤位(slot number).
3. 不要進行任何initialization操作.
通常進行這樣的操作有可能讓原本的VD完全復原, 這個操作具有風險性的, 這個風險就在於如果VD沒有復原呢?, 這之後的處理就很麻煩, 在這個問題案例下, 這個操作風險性極高, 因此並不適合進行VD creation without initialization.
在現行的RAID Controller設計, 有一種稱為OAR(Online RAID Roaming)的操作, 這種屬於必備競爭條件的功能大多RAID產品皆有使用, 該功能不是甚麼很特殊的, 早期的產品就有了. 只是這邊將拿來嘗試復原VD. 
OAR是一種用於DG遷移所應用的, 通常一個DG遷移到另一個RAID Controller, OAR便會觸發. OAR的操作會掃描PD上的metadata, 如果RAID HBA存在NVRAM, 便會將相關的COD載入到NVRAM裡面, 例如slot number, 在OAR階段之後, VD便會復原. 這個操作的最大重點就是千萬不可以和ODR(Online Drive Roaming)同時使用, 否則VD必定100%無法使用, 也就是說如果要進行DG的遷移, drive slot number是不可以改變的. 在這個問題案例下, 由於我來看的時候, PD的判定已經是foreign status且bad, 所以強制online的操作無法使用. 如果操作VD creation without initilization, 風險實在太高, 這是處於HSP在rebuild的情況下發生VD異常, 採用這樣的操作失敗率極大. 因此後來轉用OAR嘗試復原:
1. 先shutdown機器.
2. 把VD下的PD全部拔盤(pull out)
3. 啟動機器, 讓RAID BIOS初始化的時候判定VD missing, 使NVRAM的COD異動.
4. 再次shutdown後, 將全部的PD插回去, 記住! 要插回原來的slot.
在上述的操作過後, 啟動機器後, OAR的操作會從存在metadata上的PD確認發現有COD的存在, 會詢問您是否載入(import), 確認按Y鍵後, 便會將相關的COD載入到NVRAM, 這時VD會有很大的機會完全復原, 至少在我這個比較特別的案例下, VD確認是完全復原! 並且由於HSP在進行rebuild的階段下, 先前write-journaling操作的相關紀錄(record)會將上次的rebuild進度再次繼續, 而非從0%開始起算, 這些紀錄是存在於NVRAM裡, LSI大多的RAID HBA產品內置32KB大小的NVRAM. 通常用於像是default factory configuration(persistent area), COD, firmware log(tty log, 存放最後3筆紀錄)存放或著write-journaling操作, 因此這是相當重要的設計. 根據以往的悲慘教訓, 使用OAR的復原機率會比VD creation without initialization操作高.
個人曾經還遇到另一種情況, BIOS在初始化階段, 進行OAR操作時, 就直接hang在initializing就不動了. 遇到這樣的情況, 可以先shutdown機器後拔掉全部PD, 重啟動判定VD missing不管, 直接進入WebBIOS, 使用default factory重置(reset)初始設定, 透過這樣的操作NVRAM的COD會被初始異動. 接下來關機將全部PD插回去再次啟動, default factory的重新初始化階段比較需要時間, 通常是5~6分鐘左右. 在這個過程, OAR一樣會操作, 由於NVRAM的COD被重初始化, PD上的metadata會再次被載入, 這樣initializing發生hang住的情況不會再出現. 使用default factory reset和直接OAR操作結果都是一樣的, default factory reset如果初始化階段, OAR操作時, COD檢查符合會自動import, 不用手動import, 這跟foreign status的情況不同的. 通常在一個OAR操作後, 如果是parity RAID mode, 會伴隨著BGI在一定的時間內被觸發. 而以default factory重置, OAR操作後, BGI不會發生. 當然如果你擔心parity數據的一致性, 你可以另外作CC來校驗. 這兩種都是可行的方式.
native configuration error是我曾經看過的一種錯誤, 基本上這種是非常嚴重的錯誤. 而且沒有任何自行復原的方式, 根據以往的悲慘教訓, 遇到的情況如下:
1. 刷新f/w, 新的f/w讓NVDATA有影響性的異動.
2. 亂換盤位(slot number), 遭遇到COD的異常.
針對第一種情況, 通常刷回原本的f/w應該就沒事了. 但是第二種情況則是比較麻煩, 大概都沒啥機會復原, 只能進行數據救援. 
有時候在BIOS初始化階段發生錯誤, 如果hang住的情況下, 可以嘗試關閉StopOnError功能, 然後試著擷取tty log(firmware-based log)查看相關錯誤原因, 可能在T26階段檢查相關的PD載入過程.