AIXサーバーをトラブルシューティングするための8つのステップ

質問1：サーバーが大きくなり、計算能力が低下します。

現時点では、AIX5.3LPARを古いPOWER4ベースのIBM pSeries p670サーバーから新しいPOWER6ベースのpSeries p570に移行する必要がありました。サーバー上。古いサーバーのリソースが不足している（サーバー上のメインアプリケーションのリソースを管理するためにWorkloadManagerを使用する）ので、新しいハードウェア上の新しい動的プロセッサリソースが必要な計算能力を提供するはずです。このLPARでmksysbを実行し、次にNetworkInstallationManagerを使用して新しいハードウェアに復元し、SANディスクを介してマッピングしました。

このLPARを起動しましたが、アプリを起動するまでは問題ありません。突然、ユーザーが電話をかけ始めました。彼らは単に自分の製品にアクセスできない。ログインしたときに、サーバーが完全にアイドル状態であることがわかりました。サーバー上に大量のリソースを消費するプロセスはありません。ユーザーに問題があるのはなぜですか？

問題2：故障したハードディスクのミラー化を解除することはできません

私のサーバーの1つにミラー化されたルートディスクがあります。ある日、エラーレポートはディスクの1つの不良ブロックが再配置できなかったことを示した。これはハードウェア障害の前兆であることがわかっているので、ミラー解除を始めました。しかし、サーバーは、論理ボリュームの1つに正常なコピーが1つしかなく、それが障害の発生したディスク上にあるため、ミラーを完全にマウント解除できないと言っています。この問題を解決してハードウェアを交換するにはどうすればよいですか。

トラブルシューティングの手順
これら2つの質問例を覚えて、それらを解決するプロセスを見てください。

ステップ1：いじらないでください

困ったことに気づいたら、最も賢明な行動は混乱しないことです。 Indiana· Jonesが「失われた襲撃者」にいるのと同じように、床にダーツが当たったことがわかった場合は、その場所で停止して先に進まないでください。より多くの変更は問題を複雑にするだけで状況を悪化させるかもしれません。問題がシステムの通常の動作に影響を与えるとき、複数の問題を解決しなければならないことは意味がありません。

最初の質問例では、ユーザーにシステムをすぐに終了させて​​からアプリケーションを終了します。パフォーマンスが低下すると、ユーザーのクエリと入力が中断され、データが破壊される可能性があることを知っていますシステムをチェックする前に、ユーザーの環境をさらに変更したくない場合があります。ユーザーは、現在新しいサーバーを使用できないことを知りたくはありませんが、私は問題の原因を探していることを知っていて、彼らは幸せになるでしょう。さらに、これは私自身の方法で他のトラブルシューティングのステップを実行する時間を私に与えます。

ステップ2：基本的なコマンドから始めて、複雑さを追加します。

カンフーを勉強していたとき、泥棒を罰するためにバス停で2段目の黒い帯の話を聞きました。クラスメートは、攻撃者をどのトリックで倒したかを知りたがっています。それは黄金の虎ですか？それともあなたの手のひらの上の手のひらの円ですか？私達は彼女が非常に強力で、他の人を酔った天体で倒したと想像さえしました。結果はそうではありません：彼女はクラスで膣分泌物の最初のテクニックの1つを使用しました - 肘が胸に当たって、次に鼻をボクシング。

AIXには、ハードウェアとソフトウェアを含め、サーバーのあらゆる側面をチェックするためのコマンドが用意されています。最も基本的なコマンドでも、問題を分析するための優れた基盤となります。情報が足りない場合や何か問題が解決しない場合は、もっと複雑で強力なツールを試してみることができます。ただし、最も単純なコマンドとアイデアから始めて、それからより強力なツールを使用する必要があります。

2番目の問題の例では、まずエラーの出力を見てハードウェアの問題を調べ、次にディスク上の各論理ボリュームでrmlvcopyを実行するのではなく、unmirrorvgコマンド（ミラー解除を試みるシンプルで強力なツール）を使用します。論理ボリュームを削除できないことがわかったときは、lspv、lsvg、migratepvなどの他の基本コマンドを使用して情報を収集しました。 extendvgとmirrorvgを使用して、別のディスクにボリュームグループのコピーをもう1つ作成しようとしています。これでもまだいくつかの古いパーティションが残っているので、ObjectDataManagerをサーバーと連携させるためにsyncvgとsynclvdomを使用してさらに一歩進んだ。最後に、migratelpを使用して各論理区画をこのディスクから移動しようとしました。残念ながら、これらのツールは機能しませんが、多くの情報を提供します。

ステップ3：問題を再現する

科学的方法によると、仮説や実験の要点は、プロセスを再構築して同じ結果を生み出すことができることです。できない場合、結論は少なくとも不確実です。最悪の場合、これは科学者の理論を破壊し、1990年代に室温常温核融合を達成したと主張した物理学者のように彼らの評判を弱めるでしょう。

または、私が言ったように、最初に成功しなかった場合は、他の場所で試しても同じ問題が発生するかどうかを確認してください。

AIXサーバーを管理しているときに問題が発生し、問題を再現するために必要なリソースがある場合は、他の類似のタイプのLPARで同じことを実行して同じ問題が発生するかどうかを確認します。その結果別のサーバーで同じ属性を変更しても同じ結果が得られる場合は、この操作が問題の原因であると推測できます。ただし、反対の結果が得られた場合は、サーバー間のニュアンスを調べて、問題の原因を突き止めてください。

最初の問題例に関わるLPARについては、SANディスクを古いp670サーバーに戻して起動しても問題が起こらないことがわかりました。ユーザーは自分のアプリケーションにアクセスでき、CPUは通常の負荷を受けており、CPU使用率は80％（10％カーネル+ 70％ユーザー）です。したがって、移行プロセス中に発生したものではなく、p570サーバーに固有のものが問題を引き起こしていると結論できます。

ステップ4：質問の学習

情報化時代には、数回のキー入力とマウスのクリックだけで多くの情報を得ることができます。さらに良いことに、システム管理者は大規模なコミュニティのメンバーであることが多く、コミュニティは長年の経験を文書化しています。

まず、製造元と販売元の情報を確認してください。 IBMのような会社は研究のためにオンラインで彼らのすべてのマニュアル、Redbooks、技術的なファイルそしてmanページさえ発行します。メインサイトの検索バーに単純なキーワードを入力するだけで、役に立つ提案や情報がたくさん見つかります。

私がお勧めするその他の情報源には、ニュースグループ、フォーラム、他のシステム管理者が頻繁に訪れるサイトがあります。サーバーを常時取り扱う人々は、しばしば技術的なサイトを訪れ、仕事中に見ていることについてコメントします。一般の人々のために、ほとんどのシステム管理者はポインターを提供したり、電子メールを介して支援を提供しています。さらに、オペレーティングシステムやソフトウェアの他のバージョンに関する古い情報がしばしば見つかることがあり、それらを通してより多くの情報を見つけることができる。

これらの情報源の場合、主なトリックは適切なキーワードセットを使用することです。私がAIXの問題を研究するためにグーグルのような一般的なウェブサイトを使うならば、私は他のスタイルのUNIXに関連した情報を除外するために検索文字列がAIXで始まることを確かめるでしょう。それから、それはコマンドの出力かerrptによって生成されたラベルを含むかもしれません。また、検索をこれらの特定の問題に限定し、特に一般的に使用される単語（LogicalVolumeManagerのような）に関係のない情報を避けるために、特定のフレーズ（''）を二重引用符で囲みます。

ディスクの不良ブロックの再配置の失敗の問題については、GoogleでAIXの「badblockrelocation」のフレーズを使用して何百もの結果を生成していますが、私の状況とは一致しないようです。

手順5：すべての変更をキャンセルする

問題を解決するための最も賢明な方法は、行ったすべての変更をキャンセルして元の状態に戻すことです。このステップは必ずしも実行可能ではありません。熱心なCレベルの役員があなたに彼らのサーバーをロールバックすることを強いることがあります。あるいは、時間的な制約から、そうする必要があります。いずれにせよ、ロールバックはから選ぶべき最もよい戦術の1つです。

トラブルシューティングの手順の一覧の中にこの手順を追加しました。これは、早めに、時には後で行わなければならない場合があるためです。しかし、私の経験に基づいて、すべての変更を取り消すことを検討する前に最初の4つのステップを完了することが最善だと思います。トラブルシューティングプロセスが開始したらすぐに変更をキャンセルした場合、問題は解決しない可能性があり、次回同じジョブを試行したときにも同じ問題が発生します。あなたがその過程で遅すぎてフォールバックした場合、それは後退することが不可能である限りにおいて、稼働時間に影響を与えるか、または問題を複雑にするでしょう。

最初の例では、時間が経つため、実際にサーバーの移行操作をロールバックする必要がありました。運用サーバーが長期間にわたってサービスを停止していると、ユーザーや企業はお金を失うことになります。作業のスケジュールを変更するのに1週間かかったため、さらに調査を進めることができましたが、移行を再試行したときに問題が再発しました。 2番目の例では、ハードウェアの問題に対してフォールバックを実行できません。サーバーに通知できません。 - 不正なブロック再配置エラーが発生する前の状態に戻ります。 'ディスク障害を克服するために一生懸命努力し続ける必要があります。

手順6：一度に1つのルールしか変更しない

上記の手順がすべてうまくいかず、サーバー上で主要コンポーネントの変更またはより積極的な操作を行うことにした場合は、覚えておいてください。最も重要な規則の1つ：一度に1つの場所だけを変える。

複数の変更があると、次の2つの状況のいずれかになります。まず、これらの変更によって問題が解決した場合、どの変更が有効なアクションであるのかわかりません。問題を正確に解決する方法を気にしないのであれば、これは大したことではないかもしれませんが、良いシステム管理者は問題が同じ場所で複数回発生する傾向があることを知っているので詳細を知りたいと思います。第二に、問題が解決しない場合、これはより複雑になる可能性があります。これを続けると、どの変更をキャンセルするのかわかりません。あなたが十分に遠くに行けば、システムはお粥の混乱となり、あなたは混乱するでしょう。 （xkcdでこの状況についての冗談があります。）

変更しても問題が解決しない場合は、通常それをキャンセルして他の方法を試してください。最初の例では、これが当てはまります。2つのサーバーの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は問題を解決するためにVIOサポートからカーネルチームまで多くの人々を動員しました。 2番目の質問では、ハードウェア技術者だけが関与しています。そして、分析のためにsnapコマンドからの情報を提供します。

Step 8：Extreme

問題を解決する他の方法がない場合があります。ほとんどの人が気が狂っていると考える正統でない方法がいくつかあります。これは通常あなたが絶望的で仕事でさえ人生が危険にさらされているときに行われます。この場合、IBMサポート担当者は、「こうするとサポートされていない状態になり、サポートを受ける前にもう一度開始する必要があります」と頻繁に言います。 'ただし、あなたの解決策が有効であれば、それはあなたを救うことができるかもしれません。