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

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

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

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

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

故障排除過程

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

步驟1:別亂動

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

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

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

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

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

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

步驟3:再現問題

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

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

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

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

#p# 步驟4:研究問題

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

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

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

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

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

步驟5:取消所有更改

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

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

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

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

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

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

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

步驟7:求助于IBMSupport

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

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

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

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

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

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

步驟8:走極端

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