在本文中，按相似的方式學習如何解決 IBM AIX中的實際問題。您會了解相關的工具和知識，從而提升解決可能會遇到的一些棘手問題的技能。本文給出我曾經遇到的兩個有意思的場景，提供探測異常情況的步驟。然后停一下，讓您推測什么出了問題，最后給出答案。

示例問題

首先描述我作為系統管理員遇到的兩個問題。

問題 1：服務器更大，而計算能力卻降低了

當時，我需要把一個 AIX 5.3 LPAR 從基于 POWER4 的老式 IBM pSeries p670 服務器遷移到基于 POWER6 的全新的 pSeries p570 服務器上。老的服務器資源不足(使用 Workload Manager 管理服務器上主要應用程序的資源)，因此新硬件上新的動態處理器資源應該會提供我需要的計算能力。我對這個 LPAR 執行了 mksysb，然后使用 Network Installation Manager 在新硬件上恢復它并通過 SAN 磁盤映射它。

我啟動了這個 LPAR，直到啟動應用程序之前看起來一切順利。突然之間，用戶開始打電話來了。他們根本無法訪問自己的產品了。當我登錄時，發現服務器完全是空閑的。服務器上根本沒有消耗資源很多的進程。用戶為什么會遇到問題?

問題 2：出故障的硬盤無法解除鏡像

我的一臺服務器具有鏡像的 root 磁盤。有一天，錯誤報告指出在其中一個磁盤上壞塊無法重新定位。我知道這是硬件故障的先兆，所以開始解除鏡像。但是，服務器說無法完全解除鏡像，因為其中一個邏輯卷只有一個好拷貝，它就在出故障的磁盤上。我應該怎么解決這個問題并更換硬件?

故障排除過程

記住這兩個示例問題，現在看看解決它們的過程。

步驟 1：別亂動

一旦發現有麻煩了，最明智的舉動就是別亂動。就像印地安納·瓊斯在 “奪寶奇兵” 中一樣，如果發現踩上地板就會有飛鏢射向您，那么就停在原地，不要繼續前進了。更多的變動只會讓問題復雜化，可能把情況弄得更糟。當一個問題影響系統正常運行時，不得不解決多個問題是沒有意義的。

對于 第一個示例問題，我讓用戶馬上退出系統，然后我終止應用程序。我知道在性能很差時用戶的查詢和輸入會中斷，這可能會破壞他們的數據，在我檢查系統之前不希望他們的環境有進一步的變動。盡管用戶不愿意聽到他們現在不能使用新的服務器，但是知道我正在查找問題的原因，他們會很高興。另外，這讓我有時間按自己的方式執行其他故障排除步驟。

步驟 2：先從基本命令開始，然后增加復雜性

在我學功夫時，聽到了一位二級黑帶在公共汽車站制伏小偷的故事。同學們都想知道她用哪一招放倒了進攻者。是金虎式嗎?還是八卦掌中的圈掌?我們甚至想像她非常厲害，用醉八仙把對方放倒了。結果都不是：她使用的是白帶在班上最初學習的技術之一 — 肘擊前胸，再拳擊鼻子。

AIX 提供了用于檢查服務器的各個方面的命令，包括硬件和軟件。即使是最基本的命令也會為分析問題提供很好的基礎。當信息不夠或仍然有些東西表現不正常時，可以開始嘗試更復雜、更強大的工具。但是，應該從最簡單的命令和想法開始，然后再使用更強大的工具。

例如，AIX errpt 是在各種風格的 UNIX® 中都能夠找到的基本工具之一。它提供關于硬件和軟件問題的各種信息。如果使用 –a 標志或 –j 選項和標識碼，會產生更詳細的輸出，輸出描述問題的類型、受影響的組件以及系統如何根據錯誤的類型做出反應。如果它提供的信息不夠，可以用 diag 命令進一步檢查系統，這個命令會在硬件和操作系統的各個部分上運行測試。

對于 第二個示例問題，我先通過查看 errpt 輸出尋找硬件問題，然后使用 unmirrorvg 命令 — 嘗試解除鏡像的簡單但強大的工具 — 而不是對磁盤上的每個邏輯卷運行 rmlvcopy。當我發現有一個邏輯卷無法刪除時，就使用 lspv、lsvg 和 migratepv 等其他基本命令收集信息。我嘗試用 extendvg 和 mirrorvg 在另一個磁盤上創建卷組的另一個拷貝。這仍然留下了一些舊的分區，所以我更進一步，用 syncvg 和 synclvdom 協調 Object Data Manager 與服務器。最后，我用 migratelp 嘗試把各個邏輯分區轉移出這個磁盤。不幸的是，這些工具都不奏效，但是它們提供了大量信息。

步驟 3：再現問題

按照科學的方法，任何假想和試驗的關鍵一點是，能夠重建過程并產生相同的結果。如果做不到，結論至少是不確定的。在最糟糕的情況下，這會顛覆科學家的理論并損害他們的名譽，就像在上世紀 90 年代宣稱實現了室溫冷聚變的物理學家一樣。

或者，按我的說法：如果一開始不成功，那么在其他地方試試是否可以造成同樣的問題。

在管理 AIX 服務器時，如果某些東西出了問題，而您有再現問題所需的資源，那么在另一個相似類型的 LPAR 上執行相同的操作，看看是否會產生相同的結果。如果在另一個服務器上修改相同的屬性會造成相同的結果，就可以推論這個操作就是問題的根源。但是，如果產生了完全相反的結果，那么要研究服務器之間的細微差別，嘗試推測造成問題的原因。

對于第一個示例問題涉及的 LPAR，我發現當把 SAN 磁盤交換回老的 p670 服務器并啟動它時，問題沒有出現。用戶能夠訪問他們的應用程序，CPU 承受正常的負載，CPU 利用率為 80% 多(10% 內核 + 70% 用戶)。因此，我能夠斷定是 p570 服務器上特有的某些東西導致了問題，而不是遷移過程中引入的某些東西。

步驟 4：研究問題

在信息時代，只需敲幾下鍵盤，點幾次鼠標，就能夠獲得大量信息。更好的是，系統管理員往往是大型社區的成員，社區記錄了很多人多年的經驗。

首先應該查閱生產商和銷售商自己的資料。IBM 這樣的公司在網上公開他們的所有手冊、Redbook、技術文件甚至 man 頁面以供研究。只需在主站點的搜索欄中輸入簡單的關鍵字，就可以找到大量可能有幫助的建議和信息。

我推薦的其他信息源包括其他系統管理員經常訪問的各個新聞組、論壇和站點。成天與服務器打交道的人往往會經常訪問技術站點，并對在工作過程中看到的東西發表評論。對于公開的求助，大多數系統管理員樂于提供指點，或通過電子郵件往來提供幫助。另外，常常可以找到與操作系統和軟件的其他版本相關的舊信息，可以通過它們找到更多信息。

對于這些信息源，主要的使用技巧是使用適當的關鍵字集。如果我使用 Google 這樣一般性的網站研究 AIX 問題，那么會確保搜索字符串以 AIX 開頭，以便排除與其他風格的 UNIX 相關的信息。然后，可能會包含命令的輸出或 errpt 產生的標簽等內容。我還會確保在特定的短語前后加上雙引號 ("")，以便把搜索限制在這些特定的問題，避免無關的信息，對于常用的單詞(比如 Logical Volume Manager)尤其應該這么做。

對于磁盤壞塊重定位失敗的問題，在 Google 上使用短語 AIX "bad block relocation" failure 進行搜索產生了幾百個結果，但是看起來沒有與我的情況相符的。

步驟 5：取消所有更改

有時候，解決問題最明智的做法是取消已經做的所有更改，回到原來的狀態。這個步驟并非總是可行的。有時候，過分熱心的 C 級執行官強迫您回退他們的服務器。或者，由于時間緊迫，有必要這么做。無論如何，回退是可供選擇的最好的戰術之一。

我把這個步驟放在故障排除步驟列表的中間位置，這是因為有時候必須早點兒這么做，有時候要晚一些。但是根據我的經驗，我覺得最好先完成前四個步驟，然后再考慮取消所有更改。如果在故障排除過程開始時馬上取消更改，問題很可能沒有解決，下一次嘗試相同的工作時還會遇到相同的麻煩。如果在過程中過晚回退，會影響正常運行時間，或者讓問題復雜化，到了不可能回退的程度。

對于第一個示例，由于時間的原因，我實際上不得不回退了服務器遷移操作。如果這個生產服務器停運更長時間，用戶和公司就會損失金錢。重新安排這項工作花了一周時間，這讓我能夠多做一些研究，但是當我再次嘗試遷移時，問題又出現了。對于第二個示例，無法對硬件問題執行回退。無法告訴服務器，“回到發生壞塊重定位錯誤之前的狀態!” 我不得不繼續努力克服磁盤的故障。

步驟 6：每次只更改一處規則

如果上面的所有步驟都不奏效，您決定開始更改主要組件或者對服務器做更激進的操作，那么要記住一條最重要的規則：每次只更改一處。

多處更改會導致兩種情況之一。首先，如果這些更改解決了問題，那么您不知道哪個更改是有效的操作。如果您不關心究竟是什么解決了問題，這可能沒什么大不了的，但是出色的系統管理員都希望掌握更多知識，因為他們知道問題往往會在同一地方多次出現。第二，如果問題沒有解決，這可能會引入更多復雜性。繼續這樣做，您會不知道要取消哪個更改。如果走得足夠遠，系統會亂成一鍋粥而您被弄得一頭霧水。(xkcd 上有一個關于這種情況的笑話。)

如果做一處更改之后問題沒有解決，通常希望取消它并嘗試其他措施。在第一個示例中就是這種情況：當我對比兩個服務器的 Hardware Management Console 概要文件時，看到它們不一樣。我注意到老的 POWER4 硬件使用專用的 CPU，而新的 POWER6 硬件使用不封頂的共享 CPU 池。我想知道這一差異如何影響 CPU 性能，所以修改了 POWER6 硬件上的概要文件以使用專用的 CPU。奇怪的是，根據用戶的反饋，服務器 “正常” 了，我在處理器上看到了負載。因此，我知道問題肯定與 CPU 資源有關，但是需要查明為什么會這樣。

步驟 7：求助于 IBM Support

如果已經嘗試了所有合理的步驟，需要新的想法，通常應該聯系 IBM Support。他們有高級的故障排除工具，有精通操作系統和相關產品(比如 VIO 和 PowerHA)的每個方面的專家，可以調出相關的案例以證實并協助解決相似的問題。但是，如果您以前沒有撥打過 800-IBM-SERV，有幾點需要了解。

首先，您應該有 IBM 合同號。有多個支持級別，從最高級的由專人負責的 24x7x365 支持直到適用于非關鍵服務器的上午 8 點到下午 5 點支持。可以直接從 IBM 購買這些支持服務包，也可以與增值銷售商簽訂合同。

還需要提供一些信息，讓 IBM Support 可以調出您的賬戶 — 通常是服務器所在地的電話號碼、序列號、合同號或物理位置。這一信息很大程度上取決于您建立的是硬件案例還是軟件案例。

還必須讓支持人員了解問題的嚴重程度或優先級。優先級分為從 1 到 4 幾個級別。1 級通常涉及系統停止運行或生產影響，對于這個級別會馬上把電話轉給技術人員。4 級意味著處理時間可以長一些，通常用于一般的管理問題。

您描述問題并建立支持案例之后，會給您一個跟蹤號 — 通常稱為 PMR。這個號碼向與您協作的其他支持人員標識這個案例。硬件和軟件 PMR 是惟一的，如果您的問題跨越邊界，就需要得到新的號碼。

對于兩個示例問題，我都不得不聯系 IBM。對于第一個問題，IBM 調動從 VIO 支持到內核團隊的多方面人員參與解決問題。對于第二個問題，只有硬件技術人員參與，我提供了來自 snap 命令的信息以供分析。

步驟 8：走極端

有時候，沒有其他方法能夠解決問題，只能嘗試大多數人認為是發瘋的某些非正統措施。當您已經絕望，甚至工作或生命岌岌可危時，通常會這么做。在這種情況下，IBM 支持人員常常會說，“如果您這么做，就會處于不受支持的狀態，必須重新開始，然后我們才能夠支持它。” 但是，如果您的解決方案是有效的，可能能夠化險為夷。

對于我的第二個示例，在我聯系 IBM Support 之后，他們說惟一的方法是生成 mksysb 映像以恢復服務器。由于我們沒有更多東西可失去了，與我的管理員團隊討論之后，我們打算對 root 磁盤做三重鏡像，然后從服務器上撥出磁盤。撥出磁盤可能導致服務器無法引導。但是，潛在的風險是撥出磁盤可能干擾更大的服務器，讓它上面的所有 LPAR 崩潰。我們真敢這么做嗎?

您來回答

既然我已經提供了問題的背景，該您來回答了。總結一下：

把一個啟用了 Workload Manager 的服務器遷移到更快的硬件上，但是工作不正常，除非是把 LPAR 概要文件設置為使用專用的 CPU 而不是動態 CPU。這是為什么?

如何從無法撤銷配置的磁盤恢復服務器，或者取出無法移出這個磁盤的物理分區中的數據?

如果您有主意了，就繼續。

實際發生的情況

造成第一個問題的是 Workload Manager。使用它的應用程序被限制為只能使用 CPU 的 50%。因此，當系統管理程序輪詢循環探測到那個 LPAR 時，它問 “您需要多少 CPU?” 服務器回復，“我目前只使用分配的 CPU 的一半兒。” 因此，系統管理程序會動態地把 CPU 標稱值減少一半兒。這個循環重復幾次之后，CPU 計算能力多次減半，基本上接近零了。為了解決這個問題，把 Workload Manager 池調整為最多使用 CPU 的 100%，這樣動態的 CPU 標稱值會適當地限制其本身。

對于第二個示例，最終只能執行備份和恢復。對于塊重定位失敗，沒有企業樂意采用臨時解決方法。根據 IBM Support 所說，這個問題很少見，只能執行 mksysb 把數據備份到好的磁盤上并恢復系統，沒有其他選擇。恢復操作系統之后，就可以以安全的方式熱交換壞磁盤并更換它，而不會危及硬件上的其他 LPAR。

結束語

希望您對系統管理員如何排除 AIX 服務器的故障、可以使用的戰略、應該避免的做法以及在哪里尋找解決問題的建議有了一些認識。這些步驟并不完全適合所有情況，還有其他選擇，但是這些步驟可以指出正確的方向。

原文鏈接：http://os.51cto.com/art/201105/264283.htm