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

　　示例問題

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

　　問題 1:服務(wù)器更大,而計算能力卻降低了

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

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

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

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

　　故障排除過程

　　記住這兩個示例問題,現(xiàn)在看看解決它們的過程。

　　步驟 1:別亂動

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

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

　　步驟 2:先從基本命令開始,然后增加復(fù)雜性

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

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

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

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

　　步驟 3:再現(xiàn)問題

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

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

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

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

　　步驟 4:研究問題

　　在信息時代,只需敲幾下鍵盤,點幾次鼠標(biāo),就能夠獲得大量信息。更好的是,系統(tǒng)管理員往往是大型社區(qū)的成員,社區(qū)記錄了很多人多年的經(jīng)驗。

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

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

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

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

　　步驟 5:取消所有更改

　　有時候,解決問題最明智的做法是取消已經(jīng)做的所有更改,回到原來的狀態(tài)。這個步驟并非總是可行的。有時候,過分熱心的 C 級執(zhí)行官強(qiáng)迫您回退他們的服務(wù)器�；蛘�,由于時間緊迫,有必要這么做。無論如何,回退是可供選擇的最好的戰(zhàn)術(shù)之一。

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

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

　　步驟 6:每次只更改一處規(guī)則

　　如果上面的所有步驟都不奏效,您決定開始更改主要組件或者對服務(wù)器做更激進(jìn)的操作,那么要記住一條最重要的規(guī)則:每次只更改一處。

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

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

　　步驟 7:求助于 IBM Support

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

　　首先,您應(yīng)該有 IBM 合同號。有多個支持級別,從最高級的由專人負(fù)責(zé)的 24x7x365 支持直到適用于非關(guān)鍵服務(wù)器的上午 8 點到下午 5 點支持�？梢灾苯訌� IBM 購買這些支持服務(wù)包,也可以與增值銷售商簽訂合同。

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

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

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

　　對于兩個示例問題,我都不得不聯(lián)系 IBM。對于第一個問題,IBM 調(diào)動從 VIO 支持到內(nèi)核團(tuán)隊的多方面人員參與解決問題。對于第二個問題,只有硬件技術(shù)人員參與,我提供了來自 snap 命令的信息以供分析。

　　步驟 8:走極端

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

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

　　您來回答

　　既然我已經(jīng)提供了問題的背景,該您來回答了�？偨Y(jié)一下:

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

　　如何從無法撤銷配置的磁盤恢復(fù)服務(wù)器,或者取出無法移出這個磁盤的物理分區(qū)中的數(shù)據(jù)?

　　如果您有主意了,就繼續(xù)。

　　實際發(fā)生的情況

　　造成第一個問題的是 Workload Manager。使用它的應(yīng)用程序被限制為只能使用 CPU 的 50%。因此,當(dāng)系統(tǒng)管理程序輪詢循環(huán)探測到那個 LPAR 時,它問 “您需要多少 CPU?” 服務(wù)器回復(fù),“我目前只使用分配的 CPU 的一半兒�！� 因此,系統(tǒng)管理程序會動態(tài)地把 CPU 標(biāo)稱值減少一半兒。這個循環(huán)重復(fù)幾次之后,CPU 計算能力多次減半,基本上接近零了。為了解決這個問題,把 Workload Manager 池調(diào)整為最多使用 CPU 的 100%,這樣動態(tài)的 CPU 標(biāo)稱值會適當(dāng)?shù)叵拗破浔旧怼?/P>

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

　　結(jié)束語

　　希望您對系統(tǒng)管理員如何排除 AIX 服務(wù)器的故障、可以使用的戰(zhàn)略、應(yīng)該避免的做法以及在哪里尋找解決問題的建議有了一些認(rèn)識。這些步驟并不完全適合所有情況,還有其他選擇,但是這些步驟可以指出正確的方向。本文由服務(wù)器托管 | VPS主機(jī) |