| System Management Services (SMS) 1.4.1 管理者マニュアル |    
|
| System Management Services (SMS) 1.4.1 管理者マニュアル |
|
第10章 |
|
SC フェイルオーバーは、Sun Fire ハイエンドシステムの管理操作に高可用性の機能を追加してシステムの稼働時間を最大にします。Sun Fire ハイエンドシステムには 2 つの SC があります。フェイルオーバーは、高可用性の 2 つの SC システム構成のソフトウェアをサポートします。
メイン SC は、Sun Fire ハイエンドシステム全体のすべての資源を提供します。メイン SC またはメイン SC から他のシステムデバイスへのハードウェア制御パス (制御バスインタフェースや Ethernet インタフェースなど) でハードウェアまたはソフトウェアの障害が発生すると、SC フェイルオーバーソフトウェアは自動的にスペア SC に対してフェイルオーバーを行います。スペア SC は、メイン SC として動作することを認識して、すべてのメイン SC の処理を継続します。高可用性の 2 つの SC システム構成では、SMS のデータ、構成、ログファイルはスペア SC に複製されます。アクティブドメインは、この切り換えの影響は受けません。
現在の高可用性 SC 構成では、1 つの SC はもう 1 つの SC に対する「ホットスペア」として機能します。
フェイルオーバーは、Sun Fire ハイエンドシステムの管理で単独ポイントの障害を除去します。fomd は、可能な限り多くの複数ポイントの障害を特定して処理します。フェイルオーバーのシナリオは、障害および回復に示してあります。
SC フェイルオーバーのどの時点でも、SC の一時的なサービスの停止を除いて、フェイルオーバープロセスが構成済みまたは実行中のドメインに悪影響を与えることはありません。
メイン SC で障害 (ソフトウェアまたはハードウェア) が検出されると、fomd は自動的にスペア SC に対して処理を継続します。
スペア SC は、メイン SC との通信が停止したことを検出すると、テイクオーバーを起動してメインの役割を引き継ぎます。
SC フェイルオーバーメカニズムの中心には、フェイルオーバー管理デーモン (fomd (1M)) があります。このデーモンは、メインとスペアの両方の SC にインストールされます。
SC の役割を担当するのがメインかスペアなのかを判定します。
周期的な健全性ステータスメッセージ要求の方法で、リモート SC のハードウェアとソフトウェアの一般的な健全性ステータスを要求します。このメッセージは、2 つの SC 間の SMS 管理ネットワーク (MAN) を通して送信されます。
回復可能および回復不能なハードウェアおよびソフトウェアの障害のチェックや処理を行います。
2 つの SC 間での制御分割条件の可能性を常に排除します。(制御分割とは、両方の SC がそれぞれをメイン SC であると見なす場合をいいます。)
メイン SC の障害から回復するための時間を 5 〜 8 分用意します。回復時間に含まれるのは、fomd が障害を検出し、障害について了解して、メイン SC の処理をスペア SC に引き継ぐまでの時間です。
SC フェイルオーバーの発生をプラットフォームのメッセージログに記録します。
SC フェイルオーバーの影響を受けるサービスは以下のとおりです。
接続を確立する場合に、メイン SC のホスト名を知る必要はありません。SMS の構成の中で (smsconfig (1M) のマニュアルページを参照)、論理的なホスト名が作成され、メイン SC で常にアクティブになります。ネットワークデータベースでの論理的ホスト名の作成についての詳細は、『Sun Fire 15K/12K システムサイト計画の手引き』および『System Management Services (SMS) 1.4.1 インストールマニュアル 』を参照してください。
SC フェイルオーバーで影響を受けた処理は、フェイルオーバーの完了後に回復することができます。影響を受けた処理を再起動すると、その処理が再開して完了するまで実行されます。
fomd が提供するすべての自動処理機能は、オペレータが SC フェイルオーバー後に介入しなくても再開します。完了の前に SC フェイルオーバーに割り込まれた回復処理は、再起動します。
メイン起動
メイン起動フェイルオーバーでは、メイン SC で実行中の fomd が、回復不能なローカルのハードウェア/ソフトウェア障害またはオペレータの要求に応じて、スペア SC に対して制御を渡します。
スペア起動 (テイクオーバー)
スペア起動のフェイルオーバー (テイクオーバー) では、スペアで実行中の fomd がメイン SC が正常に動作していないことを判定します。
間接トリガーのテイクオーバー
SC 間の I2 ネットワークが機能を停止しておらず、メインに障害がある場合は、メインは自分自身をスペアに切り換え、スペア SC はそれを検出してメインの役割を引き継ぎます。
最後の 2 つのシナリオでは、スペア側の fomd がメイン SC をリセットすることによって、メインの並存が回避されます。
ソフトウェアの制御またはユーザーの指示によりフェイルオーバーが発生すると、fomd はフェイルオーバーメカニズムを無効にします。そのため、2 つの SC 間での処理の継続が繰り返される可能性が回避されます。
fomd の目的の 1 つは、2 つの SC 間に存在するインターコネクトを通してメイン SC からスペア SC にデータを伝達することです。このデータの中には、構成、データ、ログのファイルが含まれます。
すべての SMS 固有ファイルを、起動時にメインからスペアの SC に伝達します。この中に含まれるのは、すべてのドメインのデータディレクトリ、/etc/opt/SUNWSMS/config ディレクトリ、/var/opt/SUNWSMS/adm のプラットフォームとドメインのファイル、.logger ファイルです。ユーザーが作成したアプリケーションファイルは、cmdsyncスクリプトで指定されていなければ伝達されません。
前回の伝達サイクルの完了後に変更されたファイルだけが伝達されます。
フェイルオーバーでは、スペア SC がメインの役割を引き継ぐ前に、すべての変更済みの SMS ファイルを伝達します。
データを転送するには、I2 ネットワークが稼働している必要があります。
|
注 - 一方の SC で smsconfig -m を使ってネットワーク構成に変更を加えた場合には、もう一方の SC にも必ず同じ変更を加えてください。ネットワーク構成が、他方の SC に自動的に反映されることはありません。 |
2 つの SC 間の両方のインターコネクトに問題がある場合でも、メインおよびスペアの SC の高可用性 srams (HASram) に対するアクセスが完全であれば、フェイルオーバーは行われます。両方のインターコネクトに障害があれば、SMS データの伝達は行われず、スペア SC で同様のデータが作成されます。フェイルオーバーでは、新しいメインの fomd はデータの現在の状態を維持し、その状態を記録して、データの現在の状態に関する情報を、他の SMS デーモン/クライアントに提供します。
2 つの SC 間のどちらかのインターコネクトが再び健全になると、各 SMS ファイルの時刻表示に応じてデータが転送されます。ファイルの時刻表示が現在のスペア SC のものより前なら、そのファイルは転送されます。ファイルの時刻表示がスペア SC のものより後なら、何も処理されません。
フェイルオーバーは、以下の 2 つの条件がどちらも満たされる場合は発生しません。
この場合は、四重障害であると見なされ、フェイルオーバーは 1 つ以上のリンクが回復するまで使用できません。
フェイルオーバーソフトウェアが動作するためには、システムに 2 つの SC が存在する必要があります。メインおよびスペアの役割の判定には、一部で SC 番号を使用します。このスロット番号は、一方の SC がもう一方の SC の役割を引き継ぐのを妨げることはありません。役割の引き継ぎを制御するだけです。
SMS が先に起動した方の SC がメインになります。両方の SC が実質的に同時起動した場合には、他方を先にスペアとして認識した SC (または他方で SMS が動作していないことを先に認識した SC) がメインになります。
起動時には、たとえば起動中の SC0 が SC1 に役割を問い合わせた結果、SC1 の役割が確定できないと、SC0 がメインになります。SC0 はこの過程で SC1 をリセットします。SC1 をリセットするのは、メイン SC の並存を避けるためです。フェイルオーバー機能が無効な場合でも、このリセット処理は実行されます。
メイン SC で実行中の fomd は、起動時にハードウェアとネットワークインタフェースの定期テストを開始します。最初は、健全性を示す 1 つ以上のステータス応答を遠隔 (スペア) SC から受け付けない限り、フェイルオーバーメカニズムは (内部で) 使用不可になります。
最初の起動時にメインの fomd がローカルの障害を検出すると、以下のすべての条件が満たされる場合にフェイルオーバーが行われます。
起動時は、スペア SC で fomd が稼働してソフトウェア、ハードウェア、ネットワークインタフェースの定期テストを開始します。
最初の起動時にスペア SC で実行中の fomd は、ローカルの障害を検出すると問題点があることをメインの fomd に通知します。
setfailover は、SC フェイルオーバーメカニズムの状態を変更します。デフォルトの状態はオンです。フェイルオーバーは以下のように設定することができます。
|
注 - SMS 1.4.1 にパッチを適用する必要がある場合には、パッチをインストールする前にフェイルオーバーを使用不可にする必要があります。『System Management Services (SMS) 1.4.1 インストールマニュアル』を参照してください。 |
詳細と用例については、setfailover のマニュアルページを参照してください。
showfailover は、SC フェイルオーバーメカニズムの状態を監視したり現在のステータスを表示することができます。-v オプションは、すべての監視対象コンポーネントの現在のステータスを表示します。
-r オプションは、SC の役割を表示します。役割には、メイン、スペア、未定義があります。たとえば、次のメッセージが表示されます。
フェイルオーバーメカニズムには 4 つの状態があります。ACTIVATING、ACTIVE、DISABLED、FAILED です。
showfailover は、フェイルオーバープロセスが監視する各ネットワークインタフェースリンクの状態も表示します。表示形式は次のとおりです。
showfailover は、障害条件を表す障害文字列を返します。それぞれの障害文字列には、対応するコードがあります。以下の表に、コードおよび対応する障害文字列の定義を示します。
詳細と用例については、showfailover のマニュアルページを参照してください。
コマンドの実行中に SC フェイルオーバーが発生したときは、新しいメイン SC で同じコマンドを再起動することができます。
影響を受けた任意のドメイン (複数可) またはすべてのドメインの ASR 再起動を自動的に再開するための dsmd (1M) に対するコマンド同期のサポート。
フェイルオーバーの後の最後の DR 操作を再試行するためのすべての SMS DR 関連デーモンと CLI に対するコマンド同期のサポート。
コマンド同期のサポートを必要とする SMS の 4 つの CLI は、addboard、deleteboard、moveboard、rcfgadm です。
cmdsync コマンドは、cmdsync 記述子によるスクリプトやコマンドの初期化、既存の cmdsync 記述子の実行ポイントの更新、またはスペア SC の回復処理リストからの cmdsync 記述子の取り消しを行います。コマンドまたはスクリプトは、cmdsync 封筒でも実行可能です。
スペアへの SC フェイルオーバーでは、スペア SC での cmdsync 記述子の初期化により、最後の実行ポイントからの対象スクリプトまたはコマンドの再起動または再開をスペア SC で行うことができます。これらのコマンドはメイン SC でのみ実行されるものであり、スペアで実行されても現在の cmdsync リストには影響しません。
使用可能なスペア SC がない場合には、cmdsync コマンドでコマンドまたはスクリプトが起動されても処理は実行されません。つまり、コマンドは通常どおりに実行されますが、プラットフォームログのログエントリでは cmdsync の実行が失敗したことが示されます。
initcmdsync (1M) は、cmdsync 記述子を作成します。対象のスクリプトやコマンドおよびそれらの関連パラメタは、cmdsync データの一部として保存されます。initcmdsync コマンドの終了コードは、処理を参照するためにそれ以降の cmdsync コマンドで使用可能な cmdsync 記述子を提供します。対象コマンドまたはスクリプトは実際には実行されません。詳細は、initcmdsync (1M) のマニュアルページを参照してください。
savecmdsync (1M) は、定義済みの cmdsync 記述子に新しい実行ポイントを保存します。これにより、識別子に対応する位置で対象コマンドまたはスクリプトを再起動することができます。対象コマンドまたはスクリプトは、この実行ポイントでの再起動の機能をサポートします。実行ポイントが指定されていない場合は、対象のコマンドまたはスクリプトの先頭で再起動が実行されます。詳細は、savecmdsync (1M) のマニュアルページを参照してください。
cancelcmdsync (1M) は、スペアの再起動リストから cmdsync 記述子を削除します。このコマンドを実行すると、cmdsync 記述子に対応する対象コマンドまたはスクリプトはフェイルオーバーの際にスペア SC で再起動されません。正常または異常の終了フローの後では、すべての対象コマンドまたはスクリプトに initcmdsync コマンド処理および cancelcmdsync 処理が含まれていることを確認してください。詳細は、cancelcmdsync (1M) のマニュアルページを参照してください。
runcmdsync (1M) は、cmdsync ラッパーの下で指定された対象コマンドまたはスクリプトを実行します。先頭以外の実行ポイントでは再起動することはできません。対象のコマンドまたはスクリプトは、cmdsync 記述子の作成の後でシステムコマンドを通して実行されます。システムコマンドの終了時に、cmdsync リストから cmdsync 記述子から削除され、システムコマンドの終了コードがユーザーに返されます。詳細は、runcmdsync (1M) のマニュアルページを参照してください。
showcmdsync (1M) は、現在の cmdsync 記述子リストを表示します。詳細は、showcmdsync (1M) のマニュアルページを参照してください。
SMS では、setdatasync(1M) コマンドを実行することにより、データの同期をカスタマイズできます。setdatasync を使用すると、ユーザー作成ファイルをデータ伝播リストに追加したり削除したりできます。
setdatasync では、自動フェイルオーバーのデータ同期プロセスの一環としてメインからスペアシステムコントローラ (SC) へコピーされるファイルを特定します。両方の SC において、指定するユーザーファイルとそのユーザーファイルの格納ディレクトリに対する読み取り、書き込み許可が必要です。また、プラットフォーム管理特権かドメイン管理特権も必要です。
データ同期プロセスでは、メイン SC 上のユーザー作成ファイルに変更がないか調べます。メイン SC 上のユーザー作成ファイルが最後のファイル伝播以降に変更されていた場合には、そのファイルはスペア SC に再伝播されます。デフォルトのデータ同期プロセスでは、指定されたファイルを 60 分ごとに調べますが、setdatasync を使用して、ユーザー作成ファイルの変更を確認する時間間隔を指定することもできます。
ファイルをデータ伝達リストに追加せずに、setdatasync コマンドを使用して、指定したファイルをスペア SC に伝達することもできます。
setdatasync backup を使用すると、自動的に行われる fomd ファイルの伝達を遅らせることができます。
setdatasync backup の実行に要する時間は、転送するファイル数に比例します。ファイル転送速度に影響を与えるその他の要素には、転送ファイルの平均サイズ、SC 上の使用可能メモリー量、SC 上の負荷 (CPU サイクルとディスクトラフィック)、I2 ネットワークが機能しているかどうかなどがあります。
以下の統計情報は、200KB の平均ファイルサイズを前提としています。
I2 ネットワークが機能している、わずかに負荷がかかったシステムでは、FOMD は毎分約 750 ファイルを転送できます。
I2 ネットワークが機能していない、わずかに負荷がかかったシステムでは、毎分約 250 ファイルの転送が可能です。
|
注 - このコマンドを使用する前に、再伝播の制約について理解しておく必要があります。詳細と用例については、setdatasync (1M) のマニュアルページを参照してください。 |
showdatasync を使用すれば、メイン SC からスペア SC に伝播される (コピーされる) ファイルの現在の状態を表示することができます。showdatasync は、setdatasync を使って登録したファイルの一覧とその状態を表示することもできます。SC のフェイルオーバーが生じたときに、スペア SC がメイン SC と同じ状態で動作するように、データ伝播によってスペア SC 上のデータとメイン SC 上のデータの同期がとられています。
詳細は、showdatasync (1M) のマニュアルページを参照してください。
高可用性構成では、fomd はローカルと遠隔の SC でフェイルオーバーメカニズムを管理します。fomd は、ローカルのハードウェアおよびソフトウェアの障害を検出して適切な処置を決定します。
fomd は、以下のカテゴリについて障害の検出を管理します。
|
回復不能なソフトウェア障害。このカテゴリは、SMS ソフトウェアコンポーネント (デーモン) がクラシュしてから 3 回の試行の後で再起動できない場合、ファイルシステムがフルの場合、ヒープを使い果たした場合などに該当する。 |
図 10-1 にフェイルオーバーの障害カテゴリを示します。
以下の表に、カテゴリがフェイルオーバーメカニズムにどのように影響するかを説明します。フェイルオーバーメカニズムは稼動しているものとします。
以下に、SC フェイルオーバーでの主な fomd イベントを順番に示します。
障害を検出します。
ハートビートの生成を停止します。
遠隔のフェイルオーバーソフトウェアにテイクオーバータイマーの起動を通知します。このタイマーの目的は、何らかの理由でメインがハングアップして 10 まで達しない場合に、遠隔 (スペア) SC がテイクオーバーを実行する代替手段を提供することにあります。
SMS ソフトウェアをスペアモードで起動します。
論理 IP インタフェースを削除します。
コンソールバスのケージングメカニズムを使用可能にします。
変更された SMS ファイルのスペアの SC/HASrams への伝達をトリガーします。
ファイル伝達の監視を停止します。
メイン専用の各デーモンを終了し、メインの役割を UNKNOWN に設定します。
スペアフェイルオーバーイベントを記録します。
メインの役割が引き継がれたことを、遠隔 (スペア) のフェイルオーバーソフトウェアに通知します。スペアに通知する前にテイクオーバータイマーがタイムアウトしたときは、遠隔 SC が自分自身でテイクオーバーを実行します。
以下に、フェイルオーバーでのスペアの fomd のイベントを順番を示します。
メインの fomd からメッセージを受け取ってメインの役割を引き継ぐか、テイクオーバータイマーがタイムアウトします。メッセージを受け取った場合は、テイクオーバータイマーは停止します。
前のメイン SC をリセットします。
メインの役割に構成するよう hwad、frad および mand に通知します。
メインの役割を引き継ぎます。
ハートビート割り込みの生成を開始します。
論理 IP インタフェースを設定します。
コンソールバスのケージングメカニズムを使用不可にします。
SMS ソフトウェアをメインモードで起動します。
割り込みを受信する darb をセットアップします。
スペアからメインへの逆方向の役割イベントを記録します。
これでスペア SC はメインとなり、fomd フェイルオーバーメカニズムをオフにします。
このシナリオでは、スペア SC はメイン SC の不具合に応じてメインの制御を引き継ぎます。このタイプのフェイルオーバーの最も重要な側面は、制御分割条件の防止です。もう 1 つの前提条件は、フェイルオーバーメカニズムが起動されていないことです。このケースに該当しない場合、テイクオーバーは発生しません。
メイン SC が健全ではないことを確認する。
スペアの fomd から見ると、この現象は 2 つの条件によって引き起こされます。メイン SC が確実に機能停止している場合および I2 ネットワークインタフェースが停止している場合です。
前者の場合にはフェイルオーバーが必要ですが (フェイルオーバーメカニズムが起動されている場合)、後者の場合は不要です。どちらのケースかを特定するために、スペアの fomd はメイン SC からハートビート割り込みの存在をポーリングして、メイン SC が稼働中であることを判定します。ハートビート割り込みを受け取る場合、フェイルオーバーメカニズムが起動されていなかったり使用不可である場合は、フェイルオーバーは発生しません。
割り込みが検出されず、フェイルオーバーメカニズムが起動されていない場合は、オペレータが CLI コマンドの setfailover でフェイルオーバーメカニズムを手作業で起動しない限り、スペアの fomd が処理を引き継ぐことはありません。それ以外は、スペア SC が健全なら、スペアの fomd は前述したようにメインの役割の引き継ぎに進みます。
遠隔 (メイン) SC のリセットによりテイクオーバーを起動する。
以下に、フェイルオーバーでのスペアの fomd のイベントを順番に示します。
自分自身をメインとして再構成します。この中には、I2C バスの制御の引き継ぎ、メイン SC の論理 IP アドレスの設定、必要な SMS ソフトウェアデーモンの起動が含まれます。
ハートビート割り込みの生成を開始します。
論理 IP インタフェースを設定します。
コンソールバスのケージングを使用不可にします。
SMS ソフトウェアをメインモードで起動します。
DARB 割り込みを設定します。
テイクオーバーイベントを記録します。
これで、スペアの fomd はメインとなり、フェイルオーバーメカニズムをオフにします。
以下に、I2 ネットワーク障害の後で発生するイベントを順番に示します。
メインの fomd は、I2 ネットワークが健全ではないことを検出します。
メインの fomd は、スペア SC へのファイルの伝達とデータのチェックポイント処理を停止します。
スペアの fomd は、I2 ネットワークが健全ではないことを検出します。
スペアの fomd から見ると、この現象は 2 つの条件によって引き起こされます。メイン SC が確実に機能停止している場合および I2 ネットワークインタフェースが停止している場合です。前者の場合の適切な処置はフェイルオーバーですが、後者では違います。どちらのケースかを特定するために、fomd はメイン SC からハートビート割り込みの存在をポーリングして、メイン SC が稼働中であることを判定します。ハートビート割り込みが存在する場合は、fomd はスペアをスペアのままに保持します。
スペアの fomd は、ローカルディスクのチェックポイントデータをクリアします。
以下に、メイン SC の障害の後で発生するイベントを順番に示します。
メインの fomd は障害を検出します。
直前に通知されたスペア SC の状態が健全であった場合は、メインの fomd はハートビートの生成を中止します。それ以外はフェイルオーバーの継続処理は行いません。
コンソールバスへのアクセスが使用可能なら、メインのフェイルオーバーソフトウェアは残りの重要ファイルの HASram への伝達を停止して、任意またはすべての重要な状態情報を HASram にフラッシュします。
メインの fomd は、SMS ソフトウェアをスペアモードに再構成します。
メインの fomd は、メイン SC の論理 IP アドレスを削除します。
メインの fomd は、ハートビート割り込みの生成を停止します。
以下に、I2 ネットワークの障害回復で発生するイベントを順番に示します。
メインの fomd は、I2 ネットワークが健全であることを検出します。
健全性ステータスの応答メッセージによってスペア SC の健全性が指示されると、fomd はフェイルオーバーを使用可能にして、フェイルオーバーメカニズムはオペレータによってオフにされていないと見なし、ログファイルの完全な再同期を実行してスペア SC に対してデータのチェックポイント処理を行います。
スペアの fomd は、I2 ネットワークが健全であることを検出します。
以下に、再起動および回復で発生するイベントを順番に示します。再起動および回復のシナリオは、以下の 2 つのケースで発生します。
SSCPOST は問題なく合格したものとします。SSCPOST が失敗して OE が起動できなければ、そのメインは稼働できない状態です。
すべての SSC Solaris ドライバは問題なく組み込まれているものとします。SBBC ドライバが組み込まれない場合は、メイン SC の障害 (スペアがメインの役割を引き継ぐ場合)を参照してください。それ以外のドライバが組み込まれない場合は、メイン SC のフェイルオーバー (メイン制御のフェイルオーバー)を参照してください。
メインの fomd が起動します。
遠隔 SC がすでにメインの役割を引き継いでいると fomd が判定した場合は、スペア SC がマスターリセットを受け取るか、またはスペア SC の UltraSPARC がリセットを受け取る場合の 5 を参照してください。それ以外は、この手順の 5 に進みます。
fomd は、メインの論理 IP アドレスを設定し、残りの SMS ソフトウェアを起動します。
SMS デーモンは、必要に応じて回復モードで起動します。
メインの fomd は、ハートビート割り込みの生成を開始します。
この時点で、メイン SC は完全に回復します。
SSCPOST は問題なく合格したものとします。SSCPOST が失敗して OE が起動できなければ、そのメインは稼働できない状態です。
すべての SSC Solaris ドライバは問題なく組み込まれているものとします。SBBC ドライバが組み込まれない場合、またはそれ以外のドライバが組み込まれない場合は、スペア SC は稼働不能と見なされます。
fomd が起動します。
fomd は、SC を適切なスペアであると判定してスペアの役割を引き継ぎます。
fomd は、遠隔 (最初にメインであると見なされる) SC からのハートビート割り込みの存在をチェックします。
設定可能な長さの時間が経過した後でハートビート割り込みが検出されない場合は、フェイルオーバーメカニズムの状態がチェックされます。使用可能でかつ起動されていれば、fomd はテイクオーバーを起動します。メイン SC がマスターリセットを受け取るか、またはメイン SC の UltraSPARC® がリセットを受け取る場合の 5 を参照してください。それ以外は、fomd はハートビート割り込みの存在およびフェイルオーバーメカニズムの状態の監視を継続します。
fomd は、ハードウェア/ソフトウェアおよびネットワークインタフェースの定期チェックを開始します。
fomd は、ローカルのメイン SC の IP アドレスを設定します。
この時点で、スペア SC は完全に回復します。
以下に、クライアントフェイルオーバーの回復で発生するイベントを示します。回復のシナリオは、以下の 2 つのケースで発生します。
何らかの処理を実行中のクライアントは、その処理が非反復処理でない限り、データをチェックポイント処理することで手作業により回復されます。
I2 ネットワークが停止していれば、すべてのチェックポイントデータは削除されます。クライアントは、回復を実行することはできません。
メイン SC の障害--スペア SC からの回復と同じです。
フェイルオーバー固有のすべてのネットワークトラフィック (健全性ステータス要求/応答メッセージやファイル伝達パケット) は、2 つの SC 間に存在するインターコネクトネットワークを通してのみ送信されます。
| System Management Services (SMS) 1.4.1 管理者マニュアル | 817-6104-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.