當 AIX 磁盤出現問題時

5Seven

簡介

如果您曾經做過一段時間的 IBM ® AIX® 系統(tǒng)管理員或 SAN 管理，那么您就會對磁盤錯誤、文件系統(tǒng)問題和 Logical Volume Manager (LVM) 故障非常熟悉。如果其中某種情況發(fā)生了，您將如何應對呢？但是更好的是，如何提前預防這類情況的發(fā)生呢？

本文關注的是這類情況，即當好磁盤開始轉壞。本文首先概述了磁盤錯誤及其分類。其后，介紹了硬件概念以及搭建設計良好的冗余環(huán)境的方式。進而討論了危機情況下的應對方案。

磁盤錯誤分類

我使用兩個主要的度量值來分類 AIX 系統(tǒng)上的磁盤錯誤：影響和持續(xù)時間。影響 所量度的是磁盤錯誤的影響力及其對服務器的沖擊。換言之，就是 “這會造成何程度的傷害？”。持續(xù)時間 所量度的是磁盤錯誤持續(xù)的時長和恢復時間，即 “這傷害將持續(xù)多久？”。

影響可分為四個主要級別：

• 可用性喪失：當存儲資源離線或斷開與其管理服務器的連接時就會發(fā)生可用性喪失。雖然磁盤上的數據沒有損失，但是無法訪問該磁盤。例如：文件系統(tǒng)遭卸裝或光纖通道適配器被斷開連接。
• 數據丟失：由于邏輯或物理問題，數據無法寫入磁盤或無法從磁盤讀取。例如：LVM 寫入錯誤。
• 跨多個磁盤的數據丟失：在這種情況下，不僅一個磁盤而是多個磁盤均遭遇了數據丟失。當邏輯卷跨磁盤條帶化且其中一個磁盤故障時，常常會發(fā)生這種情況。
• 跨多個服務器的數據丟失：隨著 SAN 技術的廣泛應用，一個磁盤硬件可能受損到這樣的程度：多個服務器均受到了數據丟失的影響。
  

同樣地，持續(xù)時間也可用分為四個主要級別：

• 暫時：這類磁盤錯誤不常見且只發(fā)生一次，不會帶來真正的威脅。它只在服務器的 errpt 內出現一次，然后即消失。例如：一次糟糕的塊重分配。
• 間歇：間歇錯誤的出現很不規(guī)律，可以由初期問題推斷，比如若硬盤記錄了一系列寫入錯誤時，往往表明此驅動器可能會出現故障。
• 經常：就像是由一個 cron 作業(yè)定期安排的那樣，以周、天、小時或分鐘為間隔發(fā)生問題，這會對服務器形成嚴重威脅并具有廣泛的有害影響。
• 永久：不太容易或者根本不可能從這類錯誤中恢復。缺乏可替換硬件，將不能從這種情況中恢復。
  

通過交叉參考表中的這兩個度量指標，您就能夠更好地了解磁盤錯誤的危急程度以及它們對服務器的影響。圖 1 提供了這樣的一個示例表。

圖 1. 磁盤錯誤的影響和持續(xù)時間指標的交叉參考

圖 1 顯示了一個四乘四的表。其中的列代表的是問題的持續(xù)時間，從左到右升序排列。行代表的是問題的影響，嚴重程度從下至上升序排列。表中的單元格按色譜進行了顏色編碼，從左下角表示問題不怎么嚴重（比如可用性的臨時喪失）的藍綠色開始，一直到右上角表明問題比較嚴重（比如跨多個服務器的數據永久丟失）的橙紅色。

就我的經驗而言，超過綠色區(qū)域均會產生嚴重的問題，并有可能會導致生產效率或業(yè)務上的損失。服務器進入黃色區(qū)域并帶來災難性后果的實例，我也只是見到過幾次。

預防性措施

磁盤是否 會出現故障從來都不是考慮問題，要考慮的問題是故障會在何時 發(fā)生。沒有任何磁盤能夠保證永遠正常工作。所有好的系統(tǒng)管理員的目標是避免成為硬件平均故障間隔時間的受害者，并找到一種方式來減輕磁盤故障的風險。

所有 AIX 或 SAN 管理員的三個主要目標是最大化可用性、性能和冗余。您希望存儲環(huán)境是可用的，即為了能確保按需訪問數據也能有足夠的磁盤空間來保存所有數據。磁盤也必須具有良好的性能以便應用程序不會被任何 I/O 等待所延誤。此外，磁盤還需要具有冗余以便資源的故障不會妨礙服務器繼續(xù)發(fā)揮作用。

通常，每一種最大化都會要在至少一個其他方面做出權衡。一個在可用性和性能上做到最大化的存儲環(huán)境通常就不會考慮實現大量的冗余，因為針對速度做過優(yōu)化的磁盤資源常常都會用盡最后一個可用比特。一個側重于可用性和冗余的存儲環(huán)境則很有可能讀寫速度較低，因為長期的穩(wěn)定性是其追求的目標。而一個側重于性能和冗余的解決方案則常常因為要獲得高速 I/O 以及雙倍的讀寫而占用更多的空間，這在可用的空間方面，的確降低了可用性。

AIX 提供了更多的實用方式可用來準備預防性措施。每個管理員都應該知道下列的幾個常用概念：

• 避免單點故障。永遠不要構建這樣一個環(huán)境，即其中單個資源的喪失會損害整個環(huán)境。這樣的一種架構通常只包含單個硬盤、單個光纖通道適配器或單個電源供所有設備共用。在這種情況下，資源必然會在最不恰當的時候癱瘓。
• RAID 技術是最大化資源的一個很好的方式。多年前，工程師們開發(fā)了一種通過 RAID 技術將便宜的存儲設備集中到一個較大的組群中的方式。AIX 已經融合了很多級別的 RAID 技術，且無任何其他的成本；這些技術可在軟件級別上使用，比如條帶化 (RAID 0) 和鏡像 (RAID 1)。根據所使用的磁盤子系統(tǒng)的類型，還有其他的幾個選項可用，比如具有分布式奇偶校驗的條帶化 (RAID 5)、條帶化鏡像 (RAID 0 + 1) 或已鏡像條帶化 (RAID 1 + 0/RAID 10)。
• 使用有效的 LVM 策略來隔離數據。管理員可能犯的最嚴重錯誤就是把服務器的所有資源如操作系統(tǒng)、第三方應用程序、頁面空間以及應用程序數據等均置于單個卷組中。這么做會產生各種各樣不好的后果，包括性能差、系統(tǒng)備份過多、可管理性受損以及故障發(fā)生幾率增加。應該對服務器的各個方面進行評估和隔離，并將其資源放入各自卷組和存儲類型。例如，可以將一個大型的數據庫服務器設計成：擁有一個已經部署成鏡像模式的 rootvg 磁盤，用于存儲應用程序的 SAN 存儲和分頁空間，一些用于歸檔日志和高-I/O 交互的固態(tài)磁盤。
  

接下來，我們將研究 AIX 服務器上所使用的各種存儲類型的策略。

內部硬盤驅動器

作為 AIX 中最常用的存儲格式，內部硬驅常被用于根卷組磁盤以及占用空間較小的服務器。在使用內部硬驅時，第一步均要為每個卷組配置至少兩個磁盤，并使用 mirrorvg 命令鏡像這些硬盤驅動器。如果服務器是一個大型的 IBM System p® 機，那么就需要跨多個抽屜 (drawer) 選擇磁盤來最大化冗余，以防某個硬件如背板發(fā)生故障。同時，為了優(yōu)化性能，最好使用 lspv –l 和 lspv –p 檢查磁盤上邏輯卷布局來保持磁盤外沿上較高的-I/O 區(qū)域與邏輯卷相鄰。

小型 SAN 存儲

對于需要更多內部磁盤空間來存儲大量數據的環(huán)境來說，較小的存儲子系統(tǒng)，如直接附加的 IBM FAStT 磁盤抽屜或較早的小型 SAN 技術，均是非常實惠的解決方案。對于這類情況，重要的是要密切管理環(huán)境的配置，因為過程中很有可能會出現一些單點故障。該存儲必須通過適當的 RAID 配置進行優(yōu)化，比如一個附帶熱備份磁盤的 RAID 5 設置。還要有兩個能夠訪問這個抽屜的適配器以保證服務器端的可用性和冗余。為了讓這些磁盤能夠清楚地呈現給服務器，還應該安裝并隨時更新適當的軟件驅動器，比如多路徑 I/O 或一個子系統(tǒng)設備驅動器路徑控制模塊。

大型 SAN 存儲

在大型的 SAN 存儲環(huán)境中，多個服務器通過交換機訪問多個存儲設備，比如 IBM System Storage® DS8300 設備，通常也會有專門的 SAN 管理員來管理磁盤資源。但是從 AIX 角度看，系統(tǒng)管理員也可以幫忙做這些事，比如選擇多個雙端口光纖通道卡來與不同的光纖進行通信和改進吞吐量。如果使用了虛擬基礎架構優(yōu)化 (VIO) 技術，那么 N_Port ID 虛擬化 (NPIV) 可充許具有較低 I/O 需求的多個服務器通過同一個適配器進行相互通信，從而減少分配給 LPAR 的插槽數量。SAN 引導技術為 LPAR 提供了極快速的構建和引導時間，特別是在用 Network Installation Manager (NIM) 完成時，尤其如此。

恢復步驟

磁盤故障的影響程度不一，從輕微的中斷到整個的服務器故障。那么，當遇到故障時該怎么做呢？

第一步是檢查磁盤資源的可訪問性，從最高可用級別開始一直往下，在需要時使用 errpt 作為指導。如果服務器仍在正常運行，那么使用 df 或 mount 命令進行查看時文件系統(tǒng)是否仍然存在？如果沒有，是否能用 lsvg 或 varyonvg 訪問卷組，或是它已丟失了配額（quorum）？磁盤本身是否仍處在 Available 狀態(tài)，或者使用 lsdev –Ccdisk 命令后，是否顯示它們處于的是 Defined 狀態(tài)？像執(zhí)行 lspath 或 pcmpath query adapter 這樣的 SAN 存儲命令后，這些光纖通道設備顯示的是離線還是丟失？當通過 Hardware Management Console 查看時，服務器僅是宕機并處于 Not Activated 狀態(tài)？大型的 System p 機器或 SAN 子系統(tǒng)宕機了？不要只是因為某一類資源可用而貿然做這樣的假設；所有類似資源都必須處于可用狀態(tài)，所以務必全面檢查。

第二步是檢查資源的完整性，從最低的可用性等級開始向上檢查。服務器是否成功引導？系統(tǒng)啟動時是否出現故障，如帶有數字 552、554、 或 556 的 LED 消息（毀壞的文件系統(tǒng)、JFS 或 Object Data Manager [ODM]）？如果系統(tǒng)仍在正常運行，那么執(zhí)行cfgmgr 命令后，磁盤資源是否會重新聯(lián)機并回到 Available 狀態(tài)？卷組是否可由 varyonvg 命令激活？文件系統(tǒng)是否完全載入？想要查看的數據是否能出現在文件系統(tǒng)內，還是丟失了？

第三步是按具體情況具體分析的方式解決資源問題。以下是我在多年的修復問題過程中常常使用的一些技巧：

• 文件系統(tǒng)。以我的經驗，這是最常見的一種磁盤錯誤。無需多費勁就可以讓超塊變臟、造成存儲碎片、搞亂存儲節(jié)點或引起errpt 反復出現 JFS 錯誤。即便是一個完整的文件系統(tǒng)也可能會把事情搞砸。修復文件系統(tǒng)問題最好的策略也是最簡單的：利用文件系統(tǒng)檢查命令 (fsck)。在這些情況下，我會卸載文件系統(tǒng)并針對它們運行 fsck –y ，直至不再出現錯誤，然后再重新載入它們。有時，我會格外徹底地卸載一個卷組內所有的文件系統(tǒng)，并使用外殼腳本中的循環(huán)腳本來完成此項任務以防出現潛在問題。
• 卷組。問題若超出了文件系統(tǒng)的范疇時，通常會轉向卷組級別。有時，問題是 ODM 級的，可以通過 syncvg 或 synclvodm 進行糾正。在緊要關頭，我曾用 varyoffvg 關閉卷組，用 exportvg 導出它們，然后用 importvg 重新導入它們以使其能被正確識別。但我總是會提前備份好 /etc/filesystems 文件并記錄下磁盤端口 VLAN ID (PVID) 以保存載入的順序。
• 物理卷。談到 PVID，我看到過磁盤丟失，然后再以不同的 PVID 重新回到服務器。一個有幫助的做法是定期在別處記錄下磁盤信息作為比照以防這類事情發(fā)生。如果真的發(fā)生了，我通常會用 rmdev –dl 從服務器刪除這些磁盤，再用 cfgmgr 重新檢測它們，然后再導出并重新導入卷組。
• SAN 連接。有時全局名稱 (WWN) 并不跨 SAN 網絡進行端對端的傳播，比如 VIO 服務器上的 NPIV。我有時會通過運行pcmpath set adapter offline 禁用光纖通道適配器并手動定義或檢查 WWN，然后再重新開啟適配器。我也做過最極端的事，就是探查電纜并檢查另一端是否有燈亮以確保沒有物理問題存在。
• 引導問題。如果想要判斷一個服務器為何在磁盤故障后不能引導，我通常會做的第一件事情是從服務器（根卷組除外），斷開所有磁盤的映射和連接。如果為了找到一兩個 rootvg 磁盤而探查數百個磁盤，那么將花去 Software Management System (SMS) 大量的時間。因此，我會在維護模式從一個 NIM 服務器引導系統(tǒng)來運行診斷并修復文件系統(tǒng)，用 bosboot 命令重新創(chuàng)建引導邏輯卷或訪問此根卷組來修復諸如 /etc/filesystems 的配置文件。而且，在服務器啟動后，有問題的文件系統(tǒng)通常都是那些本身處于關閉狀態(tài)而它們旁邊其他的文件系統(tǒng)則載入正常的文件系統(tǒng)。
• 恢復。最后，如果有東西損壞并確實需要修復，就要確保新更換的部件盡量接近于原始設備。這樣一來，就可以最大限制地減少處理像文件系統(tǒng)大小或軟件驅動器這類占用修復時間的操作。我一直建議要為做好系統(tǒng)備份（mksysb 映像和使用諸如 IBM Tivoli® Storage Manager 的產品）來應對數據丟失和無法恢復的最壞情況。
  

結束語

避免好的磁盤轉壞所帶來的影響和問題持續(xù)時間太長的最佳做法是不要在問題出現后才去解決問題，而是要設法最大限度地利用 AIX 環(huán)境的可用性、性能和冗余來提前防止這些錯誤的發(fā)生。但是如果錯誤確實發(fā)生了（因為故障在所難免），則應該驗證它們的可訪問性和完整性，并設計出增量計劃 (incremental plan) 來修復它們，使您的服務器重新正常運行。

關于作者

Christian Pruett 是一個 IBM 全球服務團隊的 p 系列主機工程師。他畢業(yè)于科羅拉多州立大學的歷史系，擁有學士學位。他擁有 IBM 認證管理員認證，職業(yè)經歷主要是圍繞 RS/6000 主機，p 系列主機硬件和系統(tǒng)的支持工作。他目前是 IBM IGS 的一名團隊負責人。

http://www.ibm.com/developerworks/cn/aix/library/au-gooddisksgobad/index.html