在本文中，按相似的方式學習如何解決 IBM AIX中的實際問題。您會了解相關的工具和知識，從而提升解決可能會遇到的一些棘手問題的技能。本文給出我曾經遇到的兩個有意思的場景，提供探測異常情況的步驟。然后停一下，讓您推測什么出了問題，最后給出答案。
示例問題
首先描述我作為系統(tǒng)管理員遇到的兩個問題。
問題 1：服務器更大，而計算能力卻降低了
當時，我需要把一個 AIX 5.3 LPAR 從基于 POWER4 的老式 IBM pSeries p670 服務器遷移到基于 POWER6 的全新的 pSeries p570 服務器上。老的服務器資源不足(使用 Workload Manager 管理服務器上主要應用程序的資源)，因此新硬件上新的動態(tài)處理器資源應該會提供我需要的計算能力。我對這個 LPAR 執(zhí)行了 mksysb，然后使用 Network Installation Manager 在新硬件上恢復它并通過 SAN 磁盤映射它。
我啟動了這個 LPAR，直到啟動應用程序之前看起來一切順利。突然之間，用戶開始打電話來了。他們根本無法訪問自己的產品了。當我登錄時，發(fā)現(xiàn)服務器完全是空閑的。服務器上根本沒有消耗資源很多的進程。用戶為什么會遇到問題?
問題 2：出故障的硬盤無法解除鏡像
我的一臺服務器具有鏡像的 root 磁盤。有一天，錯誤報告指出在其中一個磁盤上壞塊無法重新定位。我知道這是硬件故障的先兆，所以開始解除鏡像。但是，服務器說無法完全解除鏡像，因為其中一個邏輯卷只有一個好拷貝，它就在出故障的磁盤上。我應該怎么解決這個問題并更換硬件?
故障排除過程
記住這兩個示例問題，現(xiàn)在看看解決它們的過程。
步驟 1：別亂動
一旦發(fā)現(xiàn)有麻煩了，最明智的舉動就是別亂動。就像印地安納·瓊斯在 “奪寶奇兵” 中一樣，如果發(fā)現(xiàn)踩上地板就會有飛鏢射向您，那么就停在原地，不要繼續(xù)前進了。更多的變動只會讓問題復雜化，可能把情況弄得更糟。當一個問題影響系統(tǒng)正常運行時，不得不解決多個問題是沒有意義的。
對于 第一個示例問題，我讓用戶馬上退出系統(tǒng)，然后我終止應用程序。我知道在性能很差時用戶的查詢和輸入會中斷，這可能會破壞他們的數據，在我檢查系統(tǒng)之前不希望他們的環(huán)境有進一步的變動。盡管用戶不愿意聽到他們現(xiàn)在不能使用新的服務器，但是知道我正在查找問題的原因，他們會很高興。另外，這讓我有時間按自己的方式執(zhí)行其他故障排除步驟。
步驟 2：先從基本命令開始，然后增加復雜性
在我學功夫時，聽到了一位二級黑帶在公共汽車站制伏小偷的故事。同學們都想知道她用哪一招放倒了進攻者。是金虎式嗎?還是八卦掌中的圈掌?我們甚至想像她非常厲害，用醉八仙把對方放倒了。結果都不是：她使用的是白帶在班上最初學習的技術之一 — 肘擊前胸，再拳擊鼻子。
AIX 提供了用于檢查服務器的各個方面的命令，包括硬件和軟件。即使是最基本的命令也會為分析問題提供很好的基礎。當信息不夠或仍然有些東西表現(xiàn)不正常時，可以開始嘗試更復雜、更強大的工具。但是，應該從最簡單的命令和想法開始，然后再使用更強大的工具。
例如，AIX errpt 是在各種風格的 UNIX® 中都能夠找到的基本工具之一。它提供關于硬件和軟件問題的各種信息。如果使用 –a 標志或 –j 選項和標識碼，會產生更詳細的輸出，輸出描述問題的類型、受影響的組件以及系統(tǒng)如何根據錯誤的類型做出反應。如果它提供的信息不夠，可以用 diag 命令進一步檢查系統(tǒng)，這個命令會在硬件和操作系統(tǒng)的各個部分上運行測試。
對于 第二個示例問題，我先通過查看 errpt 輸出尋找硬件問題，然后使用 unmirrorvg 命令 — 嘗試解除鏡像的簡單但強大的工具 — 而不是對磁盤上的每個邏輯卷運行 rmlvcopy。當我發(fā)現(xiàn)有一個邏輯卷無法刪除時，就使用 lspv、lsvg 和 migratepv 等其他基本命令收集信息。我嘗試用 extendvg 和 mirrorvg 在另一個磁盤上創(chuàng)建卷組的另一個拷貝。這仍然留下了一些舊的分區(qū)，所以我更進一步，用 syncvg 和 synclvdom 協(xié)調 Object Data Manager 與服務器。最后，我用 migratelp 嘗試把各個邏輯分區(qū)轉移出這個磁盤。不幸的是，這些工具都不奏效，但是它們提供了大量信息。
步驟 3：再現(xiàn)問題
按照科學的方法，任何假想和試驗的關鍵一點是，能夠重建過程并產生相同的結果。如果做不到，結論至少是不確定的。在最糟糕的情況下，這會顛覆科學家的理論并損害他們的名譽，就像在上世紀 90 年代宣稱實現(xiàn)了室溫冷聚變的物理學家一樣。
或者，按我的說法：如果一開始不成功，那么在其他地方試試是否可以造成同樣的問題。
在管理 AIX 服務器時，如果某些東西出了問題，而您有再現(xiàn)問題所需的資源，那么在另一個相似類型的 LPAR 上執(zhí)行相同的操作，看看是否會產生相同的結果。如果在另一個服務器上修改相同的屬性會造成相同的結果，就可以推論這個操作就是問題的根源。但是，如果產生了完全相反的結果，那么要研究服務器之間的細微差別，嘗試推測造成問題的原因。
對于第一個示例問題涉及的 LPAR，我發(fā)現(xiàn)當把 SAN 磁盤交換回老的 p670 服務器并啟動它時，問題沒有出現(xiàn)。用戶能夠訪問他們的應用程序，CPU 承受正常的負載，CPU 利用率為 80% 多(10% 內核 + 70% 用戶)。因此，我能夠斷定是 p570 服務器上特有的某些東西導致了問題，而不是遷移過程中引入的某些東西。
步驟 4：研究問題
在信息時代，只需敲幾下鍵盤，點幾次鼠標，就能夠獲得大量信息。更好的是，系統(tǒng)管理員往往是大型社區(qū)的成員，社區(qū)記錄了很多人多年的經驗。
首先應該查閱生產商和銷售商自己的資料。IBM 這樣的公司在網上公開他們的所有手冊、Redbook、技術文件甚至 man 頁面以供研究。只需在主站點的搜索欄中輸入簡單的關鍵字，就可以找到大量可能有幫助的建議和信息。
我推薦的其他信息源包括其他系統(tǒng)管理員經常訪問的各個新聞組、論壇和站點。成天與服務器打交道的人往往會經常訪問技術站點，并對在工作過程中看到的東西發(fā)表評論。對于公開的求助，大多數系統(tǒng)管理員樂于提供指點，或通過電子郵件往來提供幫助。另外，常常可以找到與操作系統(tǒng)和軟件的其他版本相關的舊信息，可以通過它們找到更多信息。
對于這些信息源，主要的使用技巧是使用適當的關鍵字集。如果我使用 Google 這樣一般性的網站研究 AIX 問題，那么會確保搜索字符串以 AIX 開頭，以便排除與其他風格的 UNIX 相關的信息。然后，可能會包含命令的輸出或 errpt 產生的標簽等內容。我還會確保在特定的短語前后加上雙引號 ("")，以便把搜索限制在這些特定的問題，避免無關的信息，對于常用的單詞(比如 Logical Volume Manager)尤其應該這么做。
對于磁盤壞塊重定位失敗的問題，在 Google 上使用短語 AIX "bad block relocation" failure 進行搜索產生了幾百個結果，但是看起來沒有與我的情況相符的。
步驟 5：取消所有更改
有時候，解決問題最明智的做法是取消已經做的所有更改，回到原來的狀態(tài)。這個步驟并非總是可行的。有時候，過分熱心的 C 級執(zhí)行官強迫您回退他們的服務器。或者，由于時間緊迫，有必要這么做。無論如何，回退是可供選擇的最好的戰(zhàn)術之一。
我把這個步驟放在故障排除步驟列表的中間位置，這是因為有時候必須早點兒這么做，有時候要晚一些。但是根據我的經驗，我覺得最好先完成前四個步驟，然后再考慮取消所有更改。如果在故障排除過程開始時馬上取消更改，問題很可能沒有解決，下一次嘗試相同的工作時還會遇到相同的麻煩。如果在過程中過晚回退，會影響正常運行時間，或者讓問題復雜化，到了不可能回退的程度。
對于第一個示例，由于時間的原因，我實際上不得不回退了服務器遷移操作。如果這個生產服務器停運更長時間，用戶和公司就會損失金錢。重新安排這項工作花了一周時間，這讓我能夠多做一些研究，但是當我再次嘗試遷移時，問題又出現(xiàn)了。對于第二個示例，無法對硬件問題執(zhí)行回退。無法告訴服務器，“回到發(fā)生壞塊重定位錯誤之前的狀態(tài)!” 我不得不繼續(xù)努力克服磁盤的故障。
步驟 6：每次只更改一處規(guī)則
如果上面的所有步驟都不奏效，您決定開始更改主要組件或者對服務器做更激進的操作，那么要記住一條最重要的規(guī)則：每次只更改一處。
多處更改會導致兩種情況之一。首先，如果這些更改解決了問題，那么您不知道哪個更改是有效的操作。如果您不關心究竟是什么解決了問題，這可能沒什么大不了的，但是出色的系統(tǒng)管理員都希望掌握更多知識，因為他們知道問題往往會在同一地方多次出現(xiàn)。第二，如果問題沒有解決，這可能會引入更多復雜性。繼續(xù)這樣做，您會不知道要取消哪個更改。如果走得足夠遠，系統(tǒng)會亂成一鍋粥而您被弄得一頭霧水。(xkcd 上有一個關于這種情況的笑話。)
如果做一處更改之后問題沒有解決，通常希望取消它并嘗試其他措施。在第一個示例中就是這種情況：當我對比兩個服務器的 Hardware Management Console 概要文件時，看到它們不一樣。我注意到老的 POWER4 硬件使用專用的 CPU，而新的 POWER6 硬件使用不封頂的共享 CPU 池。我想知道這一差異如何影響 CPU 性能，所以修改了 POWER6 硬件上的概要文件以使用專用的 CPU。奇怪的是，根據用戶的反饋，服務器 “正常” 了，我在處理器上看到了負載。因此，我知道問題肯定與 CPU 資源有關，但是需要查明為什么會這樣。
步驟 7：求助于 IBM Support
如果已經嘗試了所有合理的步驟，需要新的想法，通常應該聯(lián)系 IBM Support。他們有高級的故障排除工具，有精通操作系統(tǒng)和相關產品(比如 VIO 和 PowerHA)的每個方面的專家，可以調出相關的案例以證實并協(xié)助解決相似的問題。但是，如果您以前沒有撥打過 800-IBM-SERV，有幾點需要了解。
首先，您應該有 IBM 合同號。有多個支持級別，從最高級的由專人負責的 24x7x365 支持直到適用于非關鍵服務器的上午 8 點到下午 5 點支持。可以直接從 IBM 購買這些支持服務包，也可以與增值銷售商簽訂合同。
還需要提供一些信息，讓 IBM Support 可以調出您的賬戶 — 通常是服務器所在地的電話號碼、序列號、合同號或物理位置。這一信息很大程度上取決于您建立的是硬件案例還是軟件案例。
還必須讓支持人員了解問題的嚴重程度或優(yōu)先級。優(yōu)先級分為從 1 到 4 幾個級別。1 級通常涉及系統(tǒng)停止運行或生產影響，對于這個級別會馬上把電話轉給技術人員。4 級意味著處理時間可以長一些，通常用于一般的管理問題。
您描述問題并建立支持案例之后，會給您一個跟蹤號 — 通常稱為 PMR。這個號碼向與您協(xié)作的其他支持人員標識這個案例。硬件和軟件 PMR 是惟一的，如果您的問題跨越邊界，就需要得到新的號碼。
對于兩個示例問題，我都不得不聯(lián)系 IBM。對于第一個問題，IBM 調動從 VIO 支持到內核團隊的多方面人員參與解決問題。對于第二個問題，只有硬件技術人員參與，我提供了來自 snap 命令的信息以供分析。
步驟 8：走極端
有時候，沒有其他方法能夠解決問題，只能嘗試大多數人認為是發(fā)瘋的某些非正統(tǒng)措施。當您已經絕望，甚至工作或生命岌岌可危時，通常會這么做。在這種情況下，IBM 支持人員常常會說，“如果您這么做，就會處于不受支持的狀態(tài)，必須重新開始，然后我們才能夠支持它。” 但是，如果您的解決方案是有效的，可能能夠化險為夷。
對于我的第二個示例，在我聯(lián)系 IBM Support 之后，他們說惟一的方法是生成 mksysb 映像以恢復服務器。由于我們沒有更多東西可失去了，與我的管理員團隊討論之后，我們打算對 root 磁盤做三重鏡像，然后從服務器上撥出磁盤。撥出磁盤可能導致服務器無法引導。但是，潛在的風險是撥出磁盤可能干擾更大的服務器，讓它上面的所有 LPAR 崩潰。我們真敢這么做嗎?
您來回答
既然我已經提供了問題的背景，該您來回答了。總結一下：
把一個啟用了 Workload Manager 的服務器遷移到更快的硬件上，但是工作不正常，除非是把 LPAR 概要文件設置為使用專用的 CPU 而不是動態(tài) CPU。這是為什么?
如何從無法撤銷配置的磁盤恢復服務器，或者取出無法移出這個磁盤的物理分區(qū)中的數據?
如果您有主意了，就繼續(xù)。
實際發(fā)生的情況
造成第一個問題的是 Workload Manager。使用它的應用程序被限制為只能使用 CPU 的 50%。因此，當系統(tǒng)管理程序輪詢循環(huán)探測到那個 LPAR 時，它問 “您需要多少 CPU?” 服務器回復，“我目前只使用分配的 CPU 的一半兒。” 因此，系統(tǒng)管理程序會動態(tài)地把 CPU 標稱值減少一半兒。這個循環(huán)重復幾次之后，CPU 計算能力多次減半，基本上接近零了。為了解決這個問題，把 Workload Manager 池調整為最多使用 CPU 的 100%，這樣動態(tài)的 CPU 標稱值會適當地限制其本身。
對于第二個示例，最終只能執(zhí)行備份和恢復。對于塊重定位失敗，沒有企業(yè)樂意采用臨時解決方法。根據 IBM Support 所說，這個問題很少見，只能執(zhí)行 mksysb 把數據備份到好的磁盤上并恢復系統(tǒng)，沒有其他選擇。恢復操作系統(tǒng)之后，就可以以安全的方式熱交換壞磁盤并更換它，而不會危及硬件上的其他 LPAR。
結束語
希望您對系統(tǒng)管理員如何排除 AIX 服務器的故障、可以使用的戰(zhàn)略、應該避免的做法以及在哪里尋找解決問題的建議有了一些認識。這些步驟并不完全適合所有情況，還有其他選擇，但是這些步驟可以指出正確的方向。
原文鏈接：http://os.51cto.com/art/201105/264283.htm
