| System Management Services (SMS) 1.4.1 管理者マニュアル |    
|
| System Management Services (SMS) 1.4.1 管理者マニュアル |
|
第11章 |
|
イベント監視では、周期的にドメインとハードウェアの状況を確認し、アクションの対象にする状態を検出します。実行するアクションはその状態応じて決定され、アクション状態の報告やそれを処理する自動手続きの初期化が伴います。この章では、監視により検出されるイベントと、検出されたイベントに応じて実行されるアクションに関する要件を説明します。
SMS は、SC のメッセージファイルでのユーザー監視表示の記録または更新以外のアクションを必要とするイベントなど、すべての重要なイベントを記録します。ログに記録される内容は、後にハードウェアやソフトウェアを保守するための情報です。
SMS は、/var/opt/SUNWSMS/adm/platform/messages に格納されているプラットフォームログファイルに、重要なハードウェアイベントのログメッセージを書き込みます。
ドメインソフトウェアシステムに障害を発生させるイベントに応じて実行されるアクションには、影響を受けたすべてのドメインの ASR (自動システム回復) 再起動があります。ただし、ドメインハードウェア (または起動可能なそのサブセット) が安全かつ正常な動作の要件を満たしていることを条件とします。
SMS は、イベントに応じて実行されるユーザー監視表示の記録や更新以外の重要なアクションをすべて記録します。重要なドメインソフトウェアイベントのログメッセージとその応答アクションは、/var/opt/SUNWSMS/adm/domain_id/messages に格納されている影響を受けたドメインのメッセージログファイルに書き込まれます。
SMS は、影響を受けたドメインの 1 つ以上のドメインに大きく作用する重要なハードウェアイベントについてのログメッセージを、/var/opt/SUNWSMS/adm/domain_id/messages に書き込みます。
また、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 ログに収録されています。 |
SMS は、必要に応じてログファイルを管理し、許容範囲内で SC のディスク使用レベルを保持します。
メッセージログデーモン (mld) は、ログのサイズ、ディレクトリごとのファイル数、および 10 分刻みの時間経過を監視します。mld は、最初に到達する限度まで実行されます。
ディレクトリ数が 20 個の場合、デフォルトで約 4 G バイトのログが格納されます。
ログメッセージファイルがサイズの限度に達したら、mld は次の処理を行います。
最も古いメッセージファイルが message.9 であるか、またはコアファイルが sms_core.daemon.1 でない限り、最も古いメッセージファイルの x.X から始めて、そのファイルを x.X+1 に移し、x.X-1 から処理を始めます。
たとえば、messages は messages.0 になり、message.0 は messages.1 になり、messages.9 まで順送りされます。messages が 2.5 MB に達すると、messages.9 は削除され、すべてのファイルの接尾辞が 1 だけ増やされて、新しい空の messages ファイルが作成されます。
ログファイルがファイル数の限度に達したら、mld は次の処理を行います。
messages または sms_core.daemon の数が限度に達したら、最も古いメッセージファイルまたはコアファイルが削除されます。
ログファイルの生成後の経過時間が限度に達したら、mld は次の処理を行います。メッセージファイルは、その生成後に x 日が経過すると削除されます。
postdate.time.sec.log または dump_name.date.time.sec ファイルが、ファイルのサイズ、数、または経過時間の限度に達したら、mld はディレクトリで最も古いファイルを削除します。
詳細については、mld および showlogs のマニュアルページと、メッセージロギングデーモンを参照してください。
SMS は、ドメインソフトウェアの状態 (ソフトウェアのステータスを参照) を監視し、ドメイン再起動イベントを検出します。
ドメインソフトウェアは自分自身を再起動することはできないので、SMS ソフトウェアがすべてのドメイン再起動の初期シーケンスを制御します。その結果、SMS は常にドメイン再起動の初期化イベントを認識しています。
SMS ソフトウェアは、各再起動の初期化とドメインを起動するそれぞれの重要ステージを通じての推移をドメイン固有のログファイルに記録します。
SMS ソフトウェアは、ドメイン再起動の障害をすべて検出します。
SMS は、ドメイン再起動の障害を検出するとすぐに、再起動の障害イベントをドメイン固有のメッセージログに記録します。
SC に常駐するドメインごとのログファイルは、障害分析に利用することができます。再起動の障害をログに記録することに加え、SMS は ログファイルの管理の説明のように、SC 上の重要なドメイン常駐ログのコピーおよびドメインコンソール出力のトランスクリプトを管理します。
reboot 要求または reset 要求への応答は、常に高速起動手続きです。
ソフトウェア障害からドメインを回復しようとする最初の試みでは、速やかな再起動手続きが使用されます。
ハードウェア障害からドメインを回復しようとする最初の試みでは、reboot 手続きが使用されます。POST デフォルト診断レベルは、reboot 手続きで使用されます。
POST の実行時にドメインの回復が失敗した場合、dsmd は最初の回復試行動作の失敗後に、ドメイン回復が 6 回連続して失敗するまで、デフォルトの診断レベルで POST を再試行します。
IOSRAM レイアウト時、OpenBoot PROM のダウンロードおよびジャンプ時、OpenBoot PROM の実行時、または Solaris ソフトウェアの起動時に、ドメイン回復が失敗した場合には、dsmd はデフォルトの診断レベルで POST を再実行します。このタイプのそれ以後の障害では、回復動作ごとに dsmd は、以前のレベルより高いテスト診断レベルで POST を実行します。dsmd は最初の回復試行動作の失敗後に、デフォルトレベルでドメイン回復ドメインを 6 回まで再試行します (つまり、dsmd はドメイン回復試行動作を最高で 7 回行います)。
システムが回復して、Solaris ソフトウェアが起動されると、4 時間以内のドメイン障害は反復的なドメイン障害として扱われ、より高い診断レベルで POST を実行することで回復されます。
Solaris ソフトウェアを 4 時間実行したときにドメイン障害が出ない場合は、ドメインは正常に回復され健全な状態にあると見なされます。
それ以後のドメインハードウェア障害は、reboot 手続きにより処理されます。
それ以後のドメインソフトウェア障害は高速再起動手続きにより処理され、reboot または reset 要求は高速起動手続きにより処理されます。
SMS は、起動に失敗したドメインを起動するために、すべての ASR メソッドを適宜実行します。すべての回復試行動作は、ドメイン固有のメッセージログに記録されます。
ドメインがパニック状態になると、回復再起動を初期化できるように dsmd に通知します。パニックはドメインソフトウェア状態の変化として報告されます (ソフトウェアのステータスを参照)。
ドメイン上の Solaris ソフトウェアがパニックになると dsmd に通知されます。
dsmd はドメインパニックを検出するとすぐに、パニックイベントをドメイン固有のメッセージログに記録します。
SC に常駐するドメインごとのログファイルは、ドメインパニックの分析に利用することができます。パニックログに加え、SMS は ログファイルの管理の説明のように、SC 上の重要なドメイン常駐ログのコピーおよびドメインコンソール出力のトランスクリプトを管理します。
一般的に、ハードウェアエラーの兆候がない最初のパニックの後には、SMS はドメインを起動するために高速再起動を試みるよう要求します。詳細については、高速起動を参照してください。
POST の実行時にドメインの回復が失敗した場合、dsmd は最初の回復試行動作の失敗後に、ドメイン回復が 6 回連続して失敗するまで、デフォルトの診断レベルで POST を再試行します。
IOSRAM レイアウト時、OpenBoot PROM のダウンロードおよびジャンプ時、OpenBoot PROM の実行時、または Solaris ソフトウェアの起動時に、ドメイン回復が失敗した場合には、dsmd はデフォルトの診断レベルで POST を再実行します。このタイプのそれ以後の障害では、回復動作ごとに dsmd は、以前のレベルより高いテスト診断レベルで POST を実行します。dsmd は最初の回復試行動作の失敗後に、デフォルトレベルでドメイン回復ドメインを 6 回まで再試行します (つまり、dsmd はドメイン回復試行動作を最高で 7 回行います)。
システムが回復して、Solaris ソフトウェアが起動されると、4 時間以内のドメイン障害は反復的なドメイン障害として扱われ、より高い診断レベルで POST を実行することで回復されます。
Solaris ソフトウェアを 4 時間実行したときにドメイン障害が出ない場合は、ドメインは正常に回復され健全な状態にあると見なされます。
それ以後のドメインハードウェア障害は、reboot 手続きにより処理されます。
それ以後のドメインソフトウェア障害は高速再起動手続きにより処理され、reboot または reset 要求は高速起動手続きにより処理されます。
この回復アクションは、ドメイン固有のメッセージログに記録されます。
Solaris パニックダンプロジックは、パニック時にハングする危険性を最小限に抑えるよう再設計されました。パニック状況では、通常機能が停止しているか、またはパニックにより無効にされているために、Solaris ソフトウェアの動作が異常になる場合があります。パニックになった Solaris ドメインの ASR 再起動動作は、そのドメインが再起動を要求できるようになるまでにハングしていても開始されます。
パニックになったドメインの通常のハートビート監視 (Solaris ソフトウェアハングイベントを参照) は、パニックになった Solaris ドメインが ASR 再起動要求まで進めない状況を検出するには妥当または十分でないことがあります。このため、dsmd は必要に応じて特別な措置を講じて、ドメインパニックハングイベントを検出します。
パニックハングイベントを検出するとすぐに、dsmd は各イベントの発生を、その情報とともにドメイン固有のメッセージログに記録します。
ドメインパニックハング (があれば) を検出するとすぐに、SMS はドメインパニック (ドメインの中止 / リセットを参照) を終了し、ドメインの ASR 再起動を初期化します。dsmd は、これらの回復アクションをドメイン固有のメッセージログに記録します。
SC に常駐するログファイルは、パニックハングの分析に利用することができます。パニックハングイベントログに加え、dsmd は ログファイルの管理の説明のように、SC 上の重要なドメイン常駐ログのコピーおよびドメインコンソール出力のトランスクリプトを管理します。
パニックイベントから回復した直後に 2 番目のドメインパニックが検出された場合には、dsmd はそのドメインパニックを反復ドメインパニックイベントとして分類します。
反復ドメインパニックイベント後に再起動を試みる場合、パニックに対して行われる標準のログ記録動作に加え、次のアクションがとられます。
連続する反復ドメインパニックイベントでは、SMS は、管理者が指定した次の未試行の縮退設定に対して、より高い診断テストレベルで POST の実行を試行します (機能が低下した構成の設定の変更を参照)。
すべての縮退設定が試行された後、その後の反復ドメインパニックイベントは、最後に指定された縮退設定を使用して、フルテストレベルの起動を続行します。
反復ドメインパニックイベントが発生したのを確認したらすぐに、dsmd は、適宜 ASR を試みて安定したドメインソフトウェア環境を起動します。dsmd は、すべての回復試行動作をドメイン固有のメッセージログに記録します。
dsmd は、Solaris ソフトウェアの稼動中に各ドメインの Solaris ハートビート (Solaris ソフトウェアのハートビートで説明) を監視します (ソフトウェアのステータスを参照)。ハートビートインジケータが一定期間更新されない場合、Solaris ソフトウェアハングイベントが発生します。
dsmd は Solaris ソフトウェアハングを検出します。
Solaris ハングを検出するとすぐに、dsmd はハングイベントを情報を含めてドメイン固有のメッセージログに記録します。
Solaris ハングを検出するとすぐに、dsmd は Solaris ハングの分析のコアイメージを取得するため、ドメインソフトウェアにパニック要求を出します (ドメインの中止 / リセットを参照)。SMS は、この回復アクションをドメイン固有のメッセージログに記録します。
dsmd は、ドメインソフトウェアがパニック要求を満足できないかどうかを監視します。パニック要求に適合していないと判断したらすぐに、dsmd はドメイン (ドメインの中止 / リセットを参照) を終了させ、ASR 再起動を初期化します。dsmd は、これらの回復アクションをドメイン固有のメッセージログに記録します。
パニックの結果として取得されたコアイメージの用途はドメインからの分析のみですが、SC 常駐ログファイルはドメインハング分析に利用できます。Solaris ハングイベントログに加え、dsmd は SC 上の重要なドメイン常駐ログのコピーおよびドメインコンソール出力のトランスクリプトを管理します。
ハードウェア構成状況に加えられた変更は、ハードウェア構成イベントと見なされます。esmd は、Sun Fire ハイエンドシステム上で次のハードウェア構成イベントを検出します。
ホットプラグ可能ユニット (HPU) の挿入はホットプラグイベントです。次のアクションが発生します。
SMS は、HPU 挿入イベントを検出し、各イベントと追加情報をプラットフォームメッセージログファイルに記録します。
挿入された HPU がドメインの論理構成においてシステムボードである場合、SMS はドメインのメッセージログファイルにその装着を記録します。
ホットプラグ可能ユニット (HPU) の取り外しはホットアンプラグイベントです。次のアクションが発生します。
ホットアンプラグイベントが発生するとすぐに、SMS は HPU の取り外しをプラットフォームメッセージログファイルに記録するログエントリを作成します。
論理ドメイン構成からシステムボードを取り外したことを検出したホットアンプラグイベントは、そのことを当該ドメインのメッセージログファイルに記録します。
POST は、再起動や動的再構成などのドメイン関連イベントに応じて、適宜各種サーバーコンポーネントに対して実行できます。ハードウェア構成の説明のように、SMS は POST からの状態とテスト失敗コンポーネントを識別する状態を含みます。結果的に、コンポーネントの POST 状態の変更はハードウェア構成イベントと見なされます。SMS は、POST 初期化ハードウェア構成の変更を、プラットフォームメッセージログに記録します。
一般に環境イベントは、ハードウェア状態測定値が通常の動作範囲を超えたときに検出されます。許容動作範囲は、ハードウェアとサーバー構成により異なります。
esmd は、各センサーから返された測定値が許容動作限度内に収まっているかどうかを確認します。esmd は、許容動作範囲外のセンサー測定値をすべて環境イベントとしてプラットフォームログファイルに記録します。
また、esmd は、環境イベントに応じて講じられた重要なアクション (情報の記録やユーザー表示の更新を超えるようなアクションなど) もプラットフォームログファイルに記録します。
esmd は、1 つまたは複数のドメインに影響する重要な環境イベント応答アクションを、当該ドメインのログファイルに記録します。
esmd は、環境イベントを処理するために、そのイベントを経験したハードウェアと (および無効なコンポーネントに依存している他のハードウェア) 、から動作を取り去ります。ただし、そのハードウェアの継続動作がハードウェアを損傷させたり、ハードウェアの機能エラーを招くことがない場合には、ハードウェアの動作を継続することもできます。
環境イベントの処理オプションは、イベントの特性により異なります。すべてのイベントには、それを処理しなければならない時間枠があります。イベントの中にはドメインソフトウェアを終了するもの、終了しないものがあります。イベント応答アクションは、esmd がそのイベントの時間枠で応答するものです。
esmd が環境イベントに行う応答は、ファン速度の高速化など数多くあります。電源切断を必要とする環境イベントが検出されると、esmd は次のいずれかの是正措置を講じます。
esmd は、時間の制約を満たすオプションが他にない場合には即時の電源切断を使用します。
環境イベントが即時電源切断を必要とせず、かつコンポーネントが MaxCPU ボードであれば、esmd は動作中のドメインから危険にさらされているボードを DR して、電源切断を試行します。
環境イベントが即時電源切断を必要とせず、かつコンポーネントがセンタープレーンサポートボード (CSB) なら、esmd はバストラフィックを再設定してもう 1 つの CSB のみを使用し、そのコンポーネントの電源切断を試行します。
環境イベントが即時電源切断を必要とせず、かつコンポーネントのボードの種類が MaxCPU と CSB 以外の場合、esmd はできる限り dsmd に環境条件を通知し、dsmd は「正常型シャットダウン」をドメインに送ります。ドメインは、コミットされていないメモリーバッファーを物理記憶領域にフラッシュします。
ソフトウェアがまだ実行中であり、影響を受けたハードウェアの削除後に実行可能なドメイン構成が残っている場合は、dsmd はドメインの回復を試みます。
最後の 2 つのオプションのいずれかが指定の環境条件に割り振られた時間よりも長い時間を要する場合、esmd はドメインソフトウェアの状態とは無関係にコンポーネントの電源を即時切断します。
SMS は、環境イベントの原因として識別できるホットプラグ可能ユニットの故障インジケータの LED を点灯します。
環境イベント応答アクションに 1 つまたは複数のシステムコントローラのシャットダウンが含まれていない限り、ソフトウェア操作が環境イベントや次の応答アクションで終了されたすべてのドメインには、できるだけ早く 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 IIi プロセッサに直接報告されるものと、Sun Fire ハイエンドシステムのハードウェアレジスタの監視を通じてのみ検出されるものがあります。
上記以外にも、ドメインで動作中のプロセッサにより検出されるハードウェアエラーがあります。ドメインで動作中のドメインソフトウェアは、それらエラーがドメインで発生していることを検出し、そのエラーを SC に報告します。SC がハードウェアエラーの発生を認識するメカニズムと同じように、ハードウェアエラー後にハードウェアが保持するエラー状態は、個々のエラーにより異なります。
SC が認識できるすべてのハードウェアエラーを検出するのに必要なメカニズムを実装します。
ドメインソフトウェアを実装し、ドメイン検出ハードウェアエラーの報告を受け取ります。
ハードウェアエラーのデータを収集し、エラー状態を解消します。
ハードウェアエラーと関連情報を必要に応じてプラットフォームメッセージログに記録します。
影響を受けたすべてのドメインのドメインメッセージログファイルに、ハードウェアエラーを記録します。
ログファイルに記録するべきではないハードウェアエラーに応じて収集されたデータは、SC 上の /var/opt/SUNWSMS/adm/domain_id/dump に格納されている一意に名前を付けられた 1 つまたは複数のファイルに保存できます。
SMS は、ハードウェアエラーの原因として識別できるホットプラグ可能なユニットの故障インジケータの LED を点灯します。
ハードウェアエラーに応じて実行されるアクション (上記のような情報の収集および記録以外) には 2 つの要素があります。まず、障害を特定されたハードウェアを使用しないようにすると、特定種類のハードウェアエラーをそれ以上発生しないようにできます。
次に、ハードウェアエラーの結果としてクラッシュしたすべてのドメイン、または最初の種類のアクションの結果として停止したすべてのドメインには、ASR 再起動アクションが実行されます。
|
注 - 障害が特定されたハードウェアを使用しないようにするアクションがない場合でも、ASR 再起動アクションは完全な POST 検証の対象になります。POST は、テストに不合格のハードウェアコンポーネントを、ハードウェア構成から削除します。 |
検出された各ハードウェアエラー、およびドメインソフトウェアから報告された各ハードウェアエラーに応答して、dsmd は適切な是正措置を講じます。自動診断とドメイン回復が発生する場合もあれば (第 5 章を参照)、ハードウェアエラーより停止された各ドメインごとに完全な POST 検証による ASR 再起動が始まる場合もあります。
|
注 - ハードウェアエラー後のドメインの ASR 再起動に伴う問題は、ドメイン起動の障害の説明のように、ドメイン起動失敗イベントとして検出され、回復アクションが実行されます。 |
dsmd は、ハードウェアエラーに応じて行われる情報の記録やユーザー表示の更新を超えるようなアクションなど、すべての重要なアクションをプラットフォームログファイルに記録します。ハードウェアエラーが 1 つまたは複数のドメインに影響を与えると、dsmd は影響を受けたドメインのメッセージログファイルに重要な応答アクションを記録します。
以下では、Sun Fire ハイエンドシステムで検出および処理されるハードウェアエラーの種類を簡単に説明します。
ドメイン停止は、影響を受けた 1 つまたは複数のドメインをただちに終了させる回復不能のハードウェアエラーです。ハードウェア状態ダンプは、dsmd が影響を受けた 1 つまたは複数のドメインの ASR 再起動を初期化する前に取得されます。これらのファイルは、/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 を点灯します。
詳細については、SC フェイルオーバーを参照してください。
| System Management Services (SMS) 1.4.1 管理者マニュアル | 817-6104-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.
