第12章 |
|
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 (1M)) があります。このデーモンは、メインとスペアの両方の SC にインストールされます。
SC フェイルオーバーの影響を受けるサービスは以下のとおりです。
接続を確立する場合に、メイン SC のホスト名を知る必要はありません。SMS の構成の中で (smsconfig (1M) のマニュアルページを参照)、論理的なホスト名が作成され、メイン SC で常にアクティブになります。ネットワークデータベースでの論理的ホスト名の作成についての詳細は、『Sun Fire 15K/12K システムサイト計画の手引き』および『System Management Services (SMS) 1.5 インストールマニュアル 』を参照してください。
SC フェイルオーバーで影響を受けた処理は、フェイルオーバーの完了後に回復することができます。影響を受けた処理を再起動すると、その処理が再開して完了するまで実行されます。
fomd が提供するすべての自動処理機能は、オペレータが SC フェイルオーバー後に介入しなくても再開します。完了の前に SC フェイルオーバーに割り込まれた回復処理は、再起動します。
メイン起動フェイルオーバーでは、メイン SC で実行中の fomd が、回復不能なローカルのハードウェア/ソフトウェア障害またはオペレータの要求に応じて、スペア SC に対して制御を渡します。
スペア起動のフェイルオーバー (テイクオーバー) では、スペアで実行中の fomd がメイン SC が正常に動作していないことを判定します。
SC 間の I2 ネットワークパスが機能を停止し、メインに障害がある場合は、メインは自分自身をスペアの役割に切り換えます。これを検出したスペア SC は、メインの役割になります。
最後の 2 つのシナリオでは、スペア側の fomd がメイン SC をリセットすることによって、メインの並存が回避されます。
ソフトウェアの制御またはユーザーの指示によりフェイルオーバーが発生すると、fomd はフェイルオーバーメカニズムを無効にします。そのため、2 つの SC 間での処理の継続が繰り返される可能性が回避されます。
fomd の目的の 1 つは、2 つの SC 間に存在するインターコネクトを通してメイン SC からスペア SC にデータを伝達することです。このデータの中には、構成、データ、ログのファイルが含まれます。
データを転送するには、I2 ネットワークが稼働している必要があります。
注 - 一方の SC で smsconfig -m を使ってネットワーク構成に変更を加えた場合には、もう一方の SC にも必ず同じ変更を加えてください。ネットワーク構成が、他方の SC に自動的に反映されることはありません。 |
2 つの SC 間の両方のインターコネクトに問題がある場合でも、メインおよびスペアの SC の高可用性 SRAM (HASRAM) に対するアクセスが完全であれば、フェイルオーバーは行われます。両方のインターコネクトに障害があれば、SMS データの伝達は行われず、スペア SC で同様のデータが作成されます。フェイルオーバーでは、新しいメインの fomd はデータの現在の状態を維持し、その状態を記録して、データの現在の状態に関する情報をほかの SMS デーモンと SMS クライアントに提供します。
2 つの SC 間のどちらかのインターコネクトが再び健全になると、各 SMS ファイルの時刻表示に応じてデータが転送されます。ファイルの時刻表示が現在のスペア SC のものより前なら、そのファイルは転送されます。ファイルの時刻表示がスペア SC のものより後なら、何も処理されません。
フェイルオーバーは、以下の 2 つの条件がどちらも満たされる場合は発生しません。
この場合は、四重障害であると見なされ、フェイルオーバーは 1 つ以上のリンクが回復するまで使用できません。
注 - Solaris OS バージョンが異なるメイン SC とスペア SC 間のフェイルオーバーは、Sun 構成としてサポートされません。 |
フェイルオーバーソフトウェアが動作するためには、システムに 2 つの SC が存在する必要があります。メインおよびスペアの役割の判定には、一部で SC 番号を使用します。このスロット番号は、一方の SC がもう一方の SC の役割を引き継ぐのを妨げることはありません。役割の引き継ぎを制御するだけです。
SMS が先に起動した方の SC がメインになります。両方の SC が実質的に同時起動した場合には、他方を先にスペアとして認識した SC (または他方で SMS が動作していないことを先に認識した SC) がメインになります。
起動中の SC0 が SC1 に役割を問い合わせた結果、SC1 の役割が確定できないと、SC0 がメインになります。SC0 はこの過程で SC1 をリセットします。SC1 をリセットするのは、メイン SC の並存 (分割ブレインとして知られる状態) を避けるためです。フェイルオーバー機能が無効な場合でも、このリセット処理は実行されます。
メイン SC で実行中の fomd は、起動時にハードウェアとネットワークインタフェースの定期テストを開始します。最初は、健全性を示す 1 つ以上のステータス応答を遠隔 (スペア) SC から受け付けない限り、フェイルオーバーメカニズムは (内部で) 使用不可になります。
最初の起動時にメインの fomd がローカルの障害を検出すると、以下のすべての条件が満たされる場合にフェイルオーバーが行われます。
2. 遠隔 SC が健全ある (健全性ステータス応答で指示される)。
起動時は、スペア SC で fomd が稼働してソフトウェア、ハードウェア、ネットワークインタフェースの定期テストを開始します。
最初の起動時にスペア SC で実行中の fomd は、ローカルの障害を検出すると問題点があることをメインの fomd に通知します。
setfailover は、SC フェイルオーバーメカニズムの状態を変更します。デフォルトの状態は on です。フェイルオーバーは次の値に設定できます。
注 - SMS 1.5 にパッチを適用する必要がある場合には、パッチをインストールする前にフェイルオーバーを使用不可にする必要があります。『System Management Services (SMS) 1.5 インストールマニュアル』を参照してください。 |
詳細と用例については、setfailover のマニュアルページを参照してください。
showfailover は、SC フェイルオーバーメカニズムの状態を監視したり現在のステータスを表示することができます。-v オプションは、すべての監視対象コンポーネントの現在のステータスを表示します。
-r オプションは、SC の役割を表示します。役割には、メイン、スペア、未定義があります。たとえば、次のメッセージが表示されます。
フェイルオーバーメカニズムには 4 つの状態があります。ACTIVATING、ACTIVE、DISABLED、FAILED です。
showfailover は、フェイルオーバープロセスが監視する各ネットワークインタフェースリンクの状態も表示します。表示形式は次のとおりです。
showfailover は、障害条件を表す障害文字列を返します。それぞれの障害文字列には、対応するコードがあります。以下の表に、コードおよび対応する障害文字列の定義を示します。
詳細と用例については、showfailover のマニュアルページを参照してください。
コマンドの実行中に SC フェイルオーバーが発生したときは、新しいメイン SC で同じコマンドを再起動することができます。
コマンド同期のサポートを必要とする 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 ネットワークが機能しているかどうかなどがあります。
以下の統計情報は、200K バイトの平均ファイルサイズを前提としています。
注 - このコマンドを使用する前に、再伝播の制約について理解しておく必要があります。詳細と用例については、setdatasync (1M) のマニュアルページを参照してください。 |
showdatasync を使用すれば、メイン SC からスペア SC に伝播される (コピーされる) ファイルの現在の状態を表示することができます。showdatasync は、setdatasync を使って登録したファイルの一覧とその状態を表示することもできます。SC のフェイルオーバーが生じたときに、スペア SC がメイン SC と同じ状態で動作するように、データ伝播によってスペア SC 上のデータとメイン SC 上のデータの同期がとられています。
詳細は、showdatasync (1M) のマニュアルページを参照してください。
高可用性構成では、fomd はローカルと遠隔の SC でフェイルオーバーメカニズムを管理します。fomd は、ローカルのハードウェアおよびソフトウェアの障害を検出して適切な処置を決定します。
fomd は、以下のカテゴリについて障害の検出を管理します。
回復不能なソフトウェア障害。このカテゴリは、SMS ソフトウェアコンポーネント (デーモン) がクラシュしてから 3 回の試行のあとで再起動できない場合、ファイルシステムがフルの場合、ヒープを使い果たした場合などに該当します。 |
図 12-1 にフェイルオーバーの障害カテゴリを示します。
以下の表に、カテゴリがフェイルオーバーメカニズムにどのように影響するかを説明します。フェイルオーバーメカニズムは稼動しているものとします。
メイン SC への影響はないが、スペア SC はハードウェア障害の影響を受けるためにフェイルオーバーは使用不可となります。 |
||||
次に、SC フェイルオーバーでの主な fomd イベントをそれらの発生順に示します。
3. 遠隔のフェイルオーバーソフトウェアにテイクオーバータイマーの起動を通知します。このタイマーの目的は、何らかの理由でメインがハングアップしてカウント 10 まで達しない場合に、遠隔 (スペア) SC がテイクオーバーを実行する代替手段を提供することにあります。
6. コンソールバスのケージングメカニズムを使用可能にします。
7. 変更された SMS ファイルのスペアの SC/HASrams への伝達をトリガーします。
9. メイン専用の各デーモンを終了し、メイン SC の役割を UNKNOWN に設定します。
11. メインの役割が引き継がれたことを、遠隔 (スペア) のフェイルオーバーソフトウェアに通知します。スペアに通知する前にテイクオーバータイマーがタイムアウトしたときは、遠隔 SC が自分自身でテイクオーバーを実行します。
以下に、フェイルオーバーでのスペアの fomd のイベントを順番を示します。
1. メインの fomd からメッセージを受け取ってメインの役割を引き継ぐか、テイクオーバータイマーがタイムアウトします。メッセージを受け取った場合は、テイクオーバータイマーは停止します。
3. スペア fomb をメインの役割に構成するよう hwad、frad および mand に通知します。
7. コンソールバスのケージングメカニズムを使用不可にします。
10. スペアからメインへの逆方向の役割イベントを記録します。
11. これでスペア SC はメインとなり、fomd フェイルオーバーメカニズムをオフにします。
このシナリオでは、メイン SC との通信停止に反応してスペア SC がメインの制御を引き継ぎます。このタイプのフェイルオーバーの最も重要な側面は、制御分割条件の防止です。もう 1 つの前提条件は、フェイルオーバーメカニズムが起動されていないことです。フェイルオーバーメカニズムが無効になっている場合は、テイクオーバーは発生しません。
スペアの fomd から見ると、この現象は 2 つの条件によって引き起こされます。メイン SC が確実に機能停止している場合および I2 ネットワークインタフェースが停止している場合です。
前者の場合にはフェイルオーバーが必要ですが (フェイルオーバーメカニズムが起動されている場合)、後者の場合は不要です。どちらのケースかを特定するために、スペアの fomd はメイン SC からハートビート割り込みの存在をポーリングして、メイン SC が稼働中であることを判定します。ハートビート割り込みを受け取る場合、フェイルオーバーメカニズムが起動されていなかったり使用不可である場合は、フェイルオーバーは発生しません。
割り込みが検出されず、フェイルオーバーメカニズムが起動されていない場合は、オペレータが CLI コマンドの setfailover でフェイルオーバーメカニズムを手作業で起動しないかぎり、スペアの fomd が処理を引き継ぐことはありません。それ以外は、スペア SC が健全なら、スペアの fomd はメインの役割の引き継ぎに進みます。
以下に、フェイルオーバーでのスペアの fomd のイベントを順番に示します。
1. 自分自身をメインとして再構成します。この中には、I2C バスの制御の引き継ぎ、メイン SC の論理 IP アドレスの設定、必要な SMS ソフトウェアデーモンの起動が含まれます。
8. これで、スペアの fomd はメインとなり、フェイルオーバーメカニズムをオフにします。
以下に、I2 ネットワーク障害の後で発生するイベントを順番に示します。
1. メインの fomd は、I2 ネットワークが健全ではないことを検出します。
2. メインの fomd は、スペア SC へのファイルの伝達とデータのチェックポイント処理を停止します。
3. スペアの fomd は、I2 ネットワークが健全ではないことを検出します。
スペアの fomd から見ると、この現象は 2 つの条件によって引き起こされます。メイン SC が完全な誤動作を起こしている場合および I2 ネットワークインタフェースが停止している場合です。前者の場合の適切な処置はフェイルオーバーですが、後者では違います。どちらのケースかを特定するために、fomd はメイン SC からハートビート割り込みの存在をポーリングして、メイン SC が稼働中であることを判定します。ハートビート割り込みが存在する場合は、fomd はスペアをスペアのままに保持します。
4. スペアの fomd は、ローカルディスクのチェックポイントデータをクリアします。
以下に、メイン SC の障害の後で発生するイベントを順番に示します。
直前に通知されたスペア SC の状態が健全であった場合は、メインの fomd はハートビートの生成を中止します。それ以外はフェイルオーバーの継続処理は行いません。
コンソールバスへのアクセスが使用可能なら、メインのフェイルオーバーソフトウェアは残りの重要ファイルの HASRAM への伝達を停止して、任意またはすべての重要な状態情報を HASRAM にフラッシュします。
2. メインの fomd は、SMS ソフトウェアをスペアモードに再構成します。
3. メインの fomd は、メイン SC の論理 IP アドレスを削除します。
4. メインの fomd は、ハートビート割り込みの生成を停止します。
以下に、I2 ネットワークの障害回復で発生するイベントを順番に示します。
1. メインの fomd は、I2 ネットワークが健全であることを検出します。
健全性ステータスの応答メッセージによってスペア SC の健全性が指示されると、fomd はフェイルオーバーを使用可能にして、フェイルオーバーメカニズムはオペレータによってオフにされていないと見なし、ログファイルの完全な再同期を実行してスペア SC に対してデータのチェックポイント処理を行います。
2. スペアの fomd は、I2 ネットワークが健全であることを検出します。
スペアの fomd は、フェイルオーバーを使用不可にしてローカルディスクのチェックポイントデータをクリアします。
以下に、再起動および回復で発生するイベントを順番に示します。再起動および回復のシナリオは、以下の 2 つのケースで発生します。
1. SSCPOST は問題なく合格したものとします。SSCPOST が失敗して OS が起動できなければ、そのメインは稼働できない状態です。
2. すべての SSC Solaris ドライバは問題なく組み込まれているものとします。SBBC ドライバが組み込まれない場合は、メイン SC の障害 (スペアがメインの役割を引き継ぐ場合) を参照してください。ほかにも組み込まれないドライバがある場合は、メイン SC のフェイルオーバー (メイン制御のフェイルオーバー) を参照してください。
4. 遠隔 SC がすでにメインの役割を引き継いでいると fomd が判定した場合は、スペア SC がマスターリセットを受け取るか、またはスペア SC の UltraSPARC がリセットを受け取る場合 の 5 を参照してください。それ以外は、この手順の 5 に進みます。
5. fomd は、メインの論理 IP アドレスを設定し、残りの SMS ソフトウェアを起動します。
6. SMS デーモンは、必要に応じて回復モードで起動します。
7. メインの fomd は、ハートビート割り込みの生成を開始します。
1. SSCPOST は問題なく合格したものとします。SSCPOST が失敗して OS が起動できなければ、そのスペアは稼働できない状態です。
2. すべての SSC Solaris ドライバは問題なく組み込まれているものとします。SBBC ドライバが組み込まれない場合、またはそれ以外のドライバが組み込まれない場合は、スペア SC は稼働不能と見なされます。
4. fomd は、SC を適切なスペアであると判定してスペアの役割を引き継ぎます。
5. fomd は、遠隔 (最初にメインであると見なされる) SC からのハートビート割り込みの存在をチェックします。
設定可能な長さの時間が経過した後でハートビート割り込みが検出されない場合は、フェイルオーバーメカニズムの状態がチェックされます。使用可能でかつ起動されていれば、fomd はテイクオーバーを起動します。メイン SC がマスターリセットを受け取るか、またはメイン SC の UltraSPARC がリセットを受け取る場合 の 5 を参照してください。それ以外は、fomd はハートビート割り込みの存在およびフェイルオーバーメカニズムの状態の監視を継続します。
6. fomd は、ハードウェア/ソフトウェアおよびネットワークインタフェースの定期チェックを開始します。
7. fomd は、ローカルのメイン SC の IP アドレスを設定します。
以下に、クライアントフェイルオーバーの回復で発生するイベントを示します。回復のシナリオは、以下の 2 つのケースで発生します。
何らかの処理を実行中のクライアントは、再発データのチェックポイント処理を行うことで手動で回復されます。
I2 ネットワークが停止していれば、すべてのチェックポイントデータは削除されます。クライアントは、回復を実行することはできません。
回復を完了した時点で、次に示す再起動作業に進むことができます。
状況は、メイン SC の障害--スペア SC からの回復 と同じです。
フェイルオーバー固有のすべてのネットワークトラフィック (健全性ステータス要求/応答メッセージやファイル伝達パケット) は、2 つの SC 間に存在するインターコネクトネットワークを通してのみ送信されます。
Copyright© 2005, Sun Microsystems, Inc. All rights reserved.