| System Management Services (SMS) 1.6 管理者マニュアル |    
|
| System Management Services (SMS) 1.6 管理者マニュアル |
|
第11章 |
|
イベント監視では、処置が必要な状況を検出するために、周期的にドメインとハードウェアの状態を確認します。実行するアクションはその状況に応じて決定され、状況の報告やそれを処理する自動手続きの初期化が伴います。この章では、監視により検出されるイベントと、検出されたイベントに応じて実行されるアクションに関する要件を説明します。
SMS は、イベントに応じて実行されるユーザー監視表示の記録や更新以外の重要なアクションをすべて記録します。重要なドメインソフトウェアイベントのログメッセージとその応答アクションは、/var/opt/SUNWSMS/adm/domain-id/messages に格納されている、影響を受けたドメインのメッセージログファイルに書き込まれます。ログに記録される内容は、後にハードウェアやソフトウェアを保守するための情報です。
SMS は、/var/opt/SUNWSMS/adm/platform/messages に格納されているプラットフォームログファイルに、重要なハードウェアイベントのログメッセージを書き込みます。SMS は、影響を受けたドメインの 1 つ以上に明らかに作用する可能性のある重要なハードウェアイベントについてのログメッセージを、/var/opt/SUNWSMS/adm/domain-id/messages に書き込みます。
ドメインソフトウェアシステムに障害を発生させるイベントに応じて実行されるアクションには、影響を受けたすべてのドメインの ASR (自動システム回復) 再起動があります。ただし、ドメインハードウェア (または起動可能なそのサブセット) が安全かつ正常な動作の要件を満たしていることを条件とします。
また、SMS は、ドメインコンソール、syslog、イベント、ポスト、およびダンプ情報の記録と、sms_core ファイルの管理も行います。
SMS ソフトウェアは、記録するすべてのサーバー情報のコピー (SC に常駐) を管理します。showlogs(1M) コマンドを使うと、ログ情報にアクセスできます。
プラットフォームメッセージログファイルには、そのプラットフォームの管理者が次のコマンドを使用する場合のみアクセスできます。
構成されたドメインに関連する SMS ログ情報には、そのドメインの管理者だけがアクセスできます。SMS は、各ドメインのログファイルを個別に維持します。ファイルにアクセスするには、次のコマンドを入力します。
|
domain-id - ドメインの ID。有効な domain-id は、A 〜 R で、大文字と小文字を区別しません。 |
SMS は、SC 上のドメインの syslog ファイルのコピーを /var/opt/SUNWSMS/adm/domain-id/syslog で維持します。この syslog 情報には、そのドメインの管理者だけがアクセスできます。
Solaris コンソールの出力ログは、ドメインのクラッシュ前に何が発生したのかを判断するための貴重な情報として管理されています。コンソール出力は、クラッシュしたドメインの SC 上の /var/opt/SUNWSMS/adm/domain-id/console で参照できます。console 情報には、そのドメインの管理者だけがアクセスできます。
reset コマンドで生成される XIR 状態ダンプは、showxirstate を使用して表示できます。詳細については、showxirstate のマニュアルページを参照してください。
ドメインポストログはサービス診断用に用意されており、showlogs や SMS CLI では表示されません。
/var/tmp/sms_core.daemon ファイルはバイナリで、表示できません。
SC 上の各種ログファイルを利用できるため、1 つまたは複数のドメインの起動を妨げる問題の分析および正常化をサポートすることができます。詳細については、showlogs のマニュアルページを参照してください。
|
注 - パニックになったドメインのパニックダンプは、SC 上ではなくドメイン上の /var/crash ログに収録されています。 |
表 11-1 に、SMS ログ情報の種類とその説明を示します。
SMS は、必要に応じてログファイルを管理し、許容範囲内で SC のディスク使用レベルを保持します。
メッセージログデーモン (mld) は、メッセージログのサイズ、ディレクトリごとのファイル数、および 10 分刻みの時間経過を監視します。mld デーモンは、最初の限度に到達すると開始します。表 11-2 に、MLD のデフォルト設定を一覧表示します。
ディレクトリ数が 20 個とすると、これらのデフォルトにより約 4G バイトのログが格納されることになります。
|
注意 - 表 11-2に示したパラメータは、ファイル /etc/opt/SUNWSMS/config/mld_tuningに格納されています。mldは、なんらかの変更が有効になるたびに停止して再起動する必要があります。このファイルの編集については、システムディスクの使用に経験を積んだ管理者のみが担当すべきです。このファイルでパラメータを不適切に変更してしまうと、ディスクがあふれ、SC をハングまたはクラッシュさせてしまう可能性があります。 |
もっとも古いメッセージファイルが message.9 であるか、またはコアファイルが sms_core.daemon.1 でないかぎり、もっとも古いメッセージファイルの x.X から始めて、そのファイルを x.X+1 に移し、x.X-1 から処理を始めます。
たとえば、messages は messages.0 になり、messages.0 は messages.1 になり、messages.9 まで順送りされます。messages が 2.5M バイトに達すると、messages.9 は削除され、すべてのファイルの接尾辞が 1 だけ増やされて、新しい空の messages ファイルが作成されます。
messages または sms_core.daemon の数が限度に達したら、もっとも古いメッセージファイルまたはコアファイルが削除されます。
メッセージファイルは、その生成後に x 日が経過すると削除されます。
詳細については、mld および showlogs のマニュアルページと、メッセージロギングデーモンを参照してください。
SMS は、ドメインソフトウェアの状態 (ソフトウェアのステータスを参照) を監視し、ドメイン再起動イベントを検出します。
ドメインソフトウェアは自分自身を再起動することはできないので、SMS ソフトウェアがすべてのドメイン再起動の初期シーケンスを制御します。その結果、SMS は常にドメイン再起動の初期化イベントを認識しています。
SMS ソフトウェアは、各再起動の初期化とドメインを起動するそれぞれの重要ステージを通じての推移をドメイン固有のログファイルに記録します。
SMS ソフトウェアは、ドメイン再起動の障害をすべて検出します。
SMS は、ドメイン再起動の障害を検出するとすぐに、再起動の障害イベントをドメイン固有のメッセージログに記録します。
SC に常駐するドメインごとのログファイルは、障害分析に利用することができます。再起動の障害をログに記録することに加え、SMS はログファイルの維持管理の説明のように、重要なドメイン常駐ログの複製およびドメインコンソール出力のトランスクリプトを管理できます。
それ以後のドメインハードウェア障害は、reboot 手続きにより処理されます。
それ以後のドメインソフトウェア障害は高速再起動手続きにより処理され、reboot または reset 要求は高速起動手続きにより処理されます。
SMS は、起動に失敗したドメインを起動するために、すべての ASR メソッドを適宜実行します。すべての回復試行動作は、ドメイン固有のメッセージログに記録されます。
ドメインがパニック状態になると、回復再起動を初期化できるように dsmd に通知します。パニックはドメインソフトウェア状態の変化として報告されます (ソフトウェアのステータスを参照)。
ドメイン上の Solaris ソフトウェアがパニックになると dsmd デーモンに通知されます。
dsmd はドメインパニックを検出するとすぐに、パニックイベントをドメイン固有のメッセージログに記録します。
SC に常駐するドメインごとのログファイルは、ドメインパニックの分析に利用することができます。パニックログに加え、SMS は ログファイルの維持管理の説明のように、重要なドメイン常駐ログの複製およびドメインコンソール出力のトランスクリプトを管理できます。
一般的に、ハードウェアエラーの兆候がない最初のパニックの後には、SMS はドメインを起動するために高速再起動を試みるよう要求します。詳細は、ドメインの再起動を参照してください。
dsmd デーモンはパニックイベントを次のように処理します。
それ以後のドメインハードウェア障害は、reboot 手続きにより処理されます。
それ以後のドメインソフトウェア障害は高速再起動手続きにより処理され、reboot または reset 要求は高速起動手続きにより処理されます。
この回復アクションは、ドメイン固有のメッセージログに記録されます。
Solaris パニックダンプロジックは、パニック時にハングする危険性を最小限に抑えるよう再設計されました。パニック状況では、通常機能が停止しているか、またはパニックにより無効にされているために、Solaris ソフトウェアの動作が異常になる場合があります。パニックになった Solaris ドメインの ASR 再起動動作は、そのドメインが再起動を要求できるようになるまでにハングしていても開始されます。
パニックになったドメインの通常のハートビート監視 (Solaris ソフトウェアハングイベントを参照) は、パニックになった Solaris ドメインが ASR 再起動要求まで進めない状況を検出するには妥当または十分でないことがあります。このため、dsmd は必要に応じて特別な措置を講じて、ドメインパニックハングイベントを検出します。
パニックハングイベントを検出するとすぐに、dsmd は各イベントの発生を、その情報とともにドメイン固有のメッセージログに記録します。
SMS は、ドメインパニックハング (存在する場合) を検出すると、ただちにドメインパニックを終了させて (ドメインの中止またはリセットを参照)、ドメインの ASR 再起動を開始します。dsmd は、これらの回復アクションをドメイン固有のメッセージログに記録します。
SC に常駐するログファイルは、パニックハングの分析に利用することができます。dsmd デーモンは、パニックハングイベントログに加え、ログファイルの維持管理の説明のように、SC 上の重要なドメイン常駐ログの複製およびドメインコンソール出力のトランスクリプトを維持します。
パニックイベントから回復した直後に 2 番目のドメインパニックが検出された場合には、dsmd はそのドメインパニックを反復ドメインパニックイベントとして分類します。
反復ドメインパニックイベント後に再起動を試みる場合、パニックに対して行われる標準のロギング動作に加え、次のアクションが実行されます。
dsmd デーモンは、Solaris ソフトウェアのハートビートで説明しているように、Solaris ソフトウェアの動作中に各ドメインの Solaris ハートビートを監視します (ソフトウェアのステータスを参照)。ハートビートインジケータが一定期間更新されない場合、Solaris ソフトウェアハングイベントが発生します。
dsmd デーモンは Solaris ソフトウェアハングを検出します。
Solaris ハングを検出するとすぐに、dsmd はイベントをイベント情報を含めてドメイン固有のメッセージログに記録します。
dsmd は、Solaris ハングを検出するとすぐに、Solaris ハングの分析用のコアイメージを取得できるように、ドメインソフトウェアにパニックを発生させるよう要求します (ドメインの中止またはリセットを参照)。SMS は、この回復アクションをドメイン固有のメッセージログに記録します。
dsmd デーモンは、ドメインソフトウェアがパニック要求に応じることができない場合を監視します。dsmd デーモンは、パニック要求に応じていないことを確認すると、ただちにドメインを終了させて (ドメインの中止またはリセットを参照)、ASR 再起動を開始します。dsmd デーモンは、これらの回復アクションをドメイン固有のメッセージログに記録します。
パニックの結果として取得されたコアイメージは、そのドメインのみで分析に使用できますが、SC 常駐ログファイルはドメインハング分析の支援に使用できます。dsmd デーモンは、Solaris ハングイベントログに加え、SC 上の重要なドメイン常駐ログの複製およびドメインコンソール出力のトランスクリプトを保守できます。
ハードウェア構成ステータスの変更は、ハードウェア構成イベントと見なされます。esmd は、Sun Fire ハイエンドシステムで次のハードウェア構成イベントを検出します。
ホットプラグ可能ユニット (HPU) の挿入はホットプラグイベントです。次のアクションが発生します。
ホットプラグ可能ユニット (HPU) の取り外しはホットアンプラグイベントです。次のアクションが発生します。
POST は、再起動や動的再構成などのドメイン関連イベントに応じて、適宜各種サーバーコンポーネントに対して実行できます。ハードウェア構成の説明のように、SMS は POST からの状態とテスト失敗コンポーネントを識別する状態を含みます。このため、コンポーネントの POST ステータスの変更はハードウェア構成イベントと見なされます。SMS は、POST 主導のハードウェア構成の変更を、プラットフォームメッセージログに記録します。
一般に環境イベントは、ハードウェア状態測定値が通常の動作範囲を超えたときに検出されます。許容動作範囲は、ハードウェアとサーバー構成により異なります。
esmd デーモンは、各センサーから返された測定値が許容動作範囲内に収まっているかどうかを確認します。esmd デーモンは、許容動作範囲外のセンサー測定値をすべて環境イベントとしてプラットフォームログファイルに記録します。
また、esmd デーモンは、環境イベントに対する応答として実行された重要なアクション (情報の記録またはユーザー表示の更新より重要なアクションなど) もプラットフォームログファイルに記録します。
esmd デーモンは、1 つ以上のドメインに影響する重要な環境イベント応答アクションを、その影響を受けるドメインのログファイルに記録します。
esmd デーモンは、環境イベントが発生したハードウェアおよび無効なコンポーネントに依存している他のハードウェアを動作から除外することで、それらのイベントを処理します。ただし、そのハードウェアの動作を継続させても、ハードウェアの損傷またはハードウェア機能エラーが発生しない場合には、引き続き稼働させることもできます。
環境イベントの処理オプションは、イベントの特性により異なります。すべてのイベントには、それを処理しなければならない時間枠があります。イベントの中にはドメインソフトウェアを終了するもの、終了しないものがあります。イベント応答アクションは、esmd がそのイベントの時間枠で応答するものです。
esmd が環境イベントに行う応答は、ファン速度の高速化など数多くあります。電源切断を必要とする環境イベントが検出されると、esmd は次のいずれかの修正処置を実行します。
ソフトウェアがまだ実行中であり、影響を受けたハードウェアの削除後に実行可能なドメイン構成が残っている場合は、dsmd はドメインの回復を試みます。
最後の 2 つのオプションのいずれかが指定の環境条件に割り振られた時間よりも長い時間を要する場合、esmd はドメインソフトウェアの状態とは無関係にコンポーネントの電源を即時切断します。
SMS は、環境イベントの原因として識別できるホットプラグ可能ユニットの障害インジケータを点灯させます。
環境イベント応答アクションにシステムコントローラのシャットダウンが含まれていないかぎり、ソフトウェア操作が環境イベントや次の応答アクションで終了されたすべてのドメインには、できるだけ早く ASR 再起動が行われます。
安全で正常な動作を保証するために Sun Fire ハイエンドシステムが課す制約に従って動作できる起動可能なハードウェアがある場合は、ASR 再起動がすぐに始まります。
次の節では、Sun Fire ハイエンドシステム上で発生可能な各種の環境イベントについてもう少し詳しく説明します。
esmd デーモンは、高温になりすぎている Sun Fire ハイエンドシステムのハードウェアの温度測定値を監視します。臨界温度しきい値を超過した場合には、影響を受けるハードウェアの電源を切断することで、できるだけすみやかに処理します。温度が高くても臨界温度に達していない場合は、正常な停止や MCPU ボードの DR などのゆるやかな回復アクションを試みて対処します。
完全な電源障害が発生した場合、是正手段はほぼないといえます。正常な停止を行わずにプラグを抜き取ったときは、プラットフォーム全体、ドメイン、さらに SC が停止します。電源が回復すると、最終回復アクションが講じられます (電源投入時自己診断 (POST)を参照)。
Sun Fire ハイエンドシステムの電圧を監視して、範囲外イベントを検出します。範囲外電圧の処理は、環境イベントの冒頭で概説した一般原則に従います。
電源制御の説明のように、ボードの電源投入前に妥当な電力かどうかをチェックすることに加え、電源装置の障害ではサーバーが電力不足のままになることがあります。システムには、障害に備えて電源装置を冗長的に装備します。esmd デーモンは、大容量の電源装置ハードウェアの障害に対する応答として、ロギング以外にはどのようなアクションも実行しません。電流不足イベントの処理は、環境イベントの冒頭で概説した一般原則に従います。
esmd デーモンは、ファンが連続動作しているかどうかを監視します。ファンに障害があれば、ファン障害イベントが発生します。ファン障害の処理は、環境イベントの冒頭で概説した一般原則に従います。
esmd は、クロックが連続動作しているかどうかを監視します。クロックに障害が発生すると、esmd は 10 分ごとにメッセージをログに記録します。ボード上のクロックセレクタがそのクロックを使用して自動的に起動することがないように、手動によるオーバーライドを有効にすることもできます。クロックが正常な状態に戻ったときに、esmd は手動によるオーバーライドを無効にして、メッセージをログに記録します。
フェーズロックが失われると、esmd デーモンはすべてのボードでの手動によるオーバーライドを有効にして、メッセージをログに記録します。フェーズロックが元に戻ると、esmd はすべてのボードでの手動によるオーバーライドを無効にして、メッセージをログに記録します。
ハードウェアエラーのステータスの説明のように、Sun Fire ハイエンドシステムにハードウェアエラーが発生すると、複数のメカニズムにより SC で認識されます。SC で直接認識できるエラーの中には、PCI 割り込みによって SC 上の UltraSPARC プロセッサに直接報告されるものと、Sun Fire ハイエンドシステムのハードウェアレジスタの監視を通じてのみ検出されるものがあります。
上記以外にも、ドメインで動作中のプロセッサにより検出されるハードウェアエラーがあります。ドメインで動作中のドメインソフトウェアは、それらエラーがドメインで発生していることを検出し、そのエラーを SC に報告します。SC がハードウェアエラーの発生を認識するメカニズムと同じように、ハードウェアエラー後にハードウェアが保持するエラー状態は、個々のエラーにより異なります。
ハードウェアエラーに応じて収集されたデータがログファイルへの記録に適していない場合は、SC 上の /var/opt/SUNWSMS/adm/domain-id/dump 内の一意の名前のファイルに保存できます。
SMS は、ハードウェアエラーの原因として識別できるホットプラグ可能なユニットの障害 LED を点灯させます。
ハードウェアエラーに対する応答として実行されるアクション (前述のような情報の収集および記録以外) には 2 つの要素があります。まず、障害を特定されたハードウェアを使用しないようにすると、特定種類のハードウェアエラーをそれ以上発生しないようにできます。次に、ハードウェアエラーの結果としてクラッシュしたすべてのドメイン、または最初の種類のアクションの結果として停止したすべてのドメインには、ASR 再起動アクションが実行されます。
|
注 - ハードウェアが停止されておらず、障害が発生していると識別されていない場合でも、ASR 再起動アクションは完全な POST 検証の対象になります。POST は、テストに不合格のハードウェアコンポーネントを、ハードウェア構成から削除します。 |
検出された各ハードウェアエラー、およびドメインソフトウェアから報告された各ハードウェアエラーに応答して、dsmd は適切な是正措置を講じます。自動診断とドメイン回復が行われる場合もあれば (第 6 章を参照)、ハードウェアエラーによって停止したドメインごとに、完全な POST 検証を伴う ASR 再起動が開始される場合もあります。
|
注 - ハードウェアエラー後のドメインの ASR 再起動に伴う問題は、ドメイン起動の障害の説明のように、ドメイン起動失敗イベントとして検出され、回復アクションが実行されます。 |
dsmd デーモンは、ハードウェアエラーに対する応答として実行されるすべての重要なアクション (情報の記録またはユーザー表示の更新より重要なアクションなど) をプラットフォームログファイルに記録します。ハードウェアエラーが 1 つまたは複数のドメインに影響を与えると、dsmd は影響を受けたドメインのメッセージログファイルに重要な応答アクションを記録します。
以下では、Sun Fire ハイエンドシステムで検出および処理されるハードウェアエラーの種類を簡単に説明します。
ドメイン停止は、影響を受けたドメインをただちに終了させる回復不能のハードウェアエラーです。ハードウェア状態ダンプは、影響を受けたドメインの ASR 再起動を dsmd が初期化する前に取得されます。これらのファイルは、/var/opt/SUNWSMS/adm/domain-id/dump に格納されます。
dsmd デーモンは、これらのイベントをドメインメッセージログファイルに記録します。また、イベントログファイルにも記録します。
RED_state またはウォッチドッグのリセットは、低レベルのドメインソフトウェア (OpenBoot PROM または kadb) にトラップされます。これらのリセットはエラーを報告し、ドメインの ASR 再起動の初期化を要求します。
XIR 信号 (reset -x) も低レベルのドメインソフトウェア (OpenBoot PROM または kadb) にトラップされます。これはソフトウェアの制御を保持します。ドメインは手動で再起動しなければなりません。
修正可能なデータ伝送エラー (CE ECC エラーなど) が原因で、Sun Fire ハイエンドシステムの ASIC の通常のトランザクション履歴レコード機能が停止することがあります。SMS は、伝送エラーをレコード停止として報告します。SMS はこれらの ASIC のトランザクション履歴バッファーをダンプし、レコード停止を処理するときにトランザクション履歴レコード機能をふたたび有効にします。dsmd デーモンは、ドメインログファイルにレコード停止を記録します。
ドメイン停止またはレコード停止以外の ASIC 検出ハードウェア障害には、コンソールバスエラーがあります。これは、ドメインに影響する場合としない場合があります。ハードウェア自体はどのドメインも終了させませんが、ドメインソフトウェアはハードウェア障害に耐えられないか、またはパニックまたはハングを起こすことがあります。dsmd デーモンは、ドメインログファイルにイベントを記録します。
SMS は、メインの SC ハードウェアと実行中のソフトウェア状態のほか、スペアの SC が存在すればそのハードウェアと実行中のソフトウェアを監視します。利用度の高い SC 構成では、SMS は自動 SC フェイルオーバー処理により、メインの SC 上のハードウェアまたはソフトウェアの障害や、メインの SC へのハードウェア制御パス (たとえば、コンソールバスや内部ネットワーク接続) で検出された障害を処理します。これは、メインの責任をスペアの SC に譲渡し、旧メインの SC を (不具合の可能性がある) スペアとして残します。
SMS は、メインとスペアの SC のハードウェアに障害があるかどうかを監視します。
SMS は、ハードウェア障害と関連情報をプラットフォームメッセージログに記録します。
SMS は、特定されたハードウェア障害によってシステムコントローラ上の障害 LED を点灯させます。
詳細は、第 12 章を参照してください。
| System Management Services (SMS) 1.6 管理者マニュアル | 819-6418-10 |
|
Copyright© 2006, Sun Microsystems, Inc. All rights reserved.