| System Management Services (SMS) 1.6 管理者マニュアル |    
|
| System Management Services (SMS) 1.6 管理者マニュアル |
|
第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 で同一バージョンの Solaris OS および SMS ソフトウェアが構成されている必要があります。 |
現在の高可用性 SC 構成では、一方の SC は他方の 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.6 インストールマニュアル 』を参照してください。
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 つ以上のリンクが復元されるまで無効になります。
この節では、起動、メイン SC の役割、およびスペア SC の役割について説明します。
|
注 - Solaris OS バージョンが異なるメイン SC とスペア SC 間のフェイルオーバーは、Sun 構成としてサポートされません。 |
フェイルオーバーソフトウェアが動作するためには、システムに 2 つの SC が存在する必要があります。メインおよびスペアの役割の判定には、一部で SC 番号を使用します。このスロット番号は、指定された SC がどちらかの役割を担う妨げにはなりません。役割の引き継ぎ方法を制御するだけです。
SMS が先に起動した方の SC がメインになります。両方の SC 上で SMS が実質的に同時に起動した場合には、他方の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 コマンドおよび showfailover コマンドについて説明します。
setfailover コマンドは、SC フェイルオーバーメカニズムの状態を変更します。デフォルトの状態は on です。次に、setfailover コマンドの使用例を示します。
クロックに障害のあるスペア SC へのフェイルオーバーを強制すると、影響を受けるドメインでドメイン停止 (dstop) が発生することがあります。setfailover コマンドは、スペア SC 上の障害のあるクロックを検出し、障害のある SC へのフェイルオーバーを誤って強制することがないよう、もう一度確認するためのプロンプトを表示します。ただし、-q (非出力) オプションおよび -y (すべてのプロンプトに yes) オプションを指定すると、障害のある SC を確認できません。
|
注意 - -qオプションを指定すると、確認プロンプトを含むすべてのプロンプトが抑制されます。-qオプションと -yオプションの両方を指定すると、スペア SC に障害があっても、スペア SC へのフェイルオーバーが強制されます。SC に障害がある場合は、この強制フェイルオーバーによって Dstop が発生する可能性があります。 |
次に、スペア SC 上の障害のあるクロックを検出する setfailover コマンドの例を示します。
表 12-1 では、SC フェイルオーバーの状態について説明します。
|
注 - SMS 1.6 にパッチを適用する必要がある場合には、パッチをインストールする前にフェイルオーバーを使用不可にする必要があります。『System Management Services (SMS) 1.6 インストールマニュアル』を参照してください。 |
詳細と用例については、setfailover のマニュアルページを参照してください。
showfailover コマンドでは、SC フェイルオーバーメカニズムの状態を監視し、現在のステータスを表示することができます。-v オプションは、すべての監視対象コンポーネントの現在のステータスを表示します。
-r オプションは、SC の役割を表示します。役割には、メイン、スペア、未定義があります。たとえば、次のメッセージが表示されます。
オプションを指定しない場合は、次のように状態情報だけが表示されます。
フェイルオーバーメカニズムには、ACTIVATING、ACTIVE、DISABLED、および FAILED の 4 つの状態があります。表 12-2 では、4 つの状態について説明します。
showfailover は、フェイルオーバープロセスが監視する各ネットワークインタフェースリンクの状態も表示します。表示形式は次のとおりです。
showfailover は、障害状態を表す障害文字列を返します。それぞれの障害文字列には、対応するコードがあります。以下の表に、コードおよび対応する障害文字列の定義を示します。
表 12-3 では、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 で再起動されません。すべての対象コマンドまたはスクリプトでは、正常または異常終了フローのあとに cancelcmdsync シーケンスだけでなく initcmdsync コマンドシーケンスも必ず含まれるように注意してください。詳細は、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 デーモンは、表 12-4 で説明する障害の検出を担当します。
|
回復不能なソフトウェア障害。このカテゴリは、SMS ソフトウェアコンポーネント (デーモン) がクラシュしてから 3 回の試行のあとで再起動できない場合、ファイルシステムがフルの場合、ヒープを使い果たした場合などに該当します。 |
図 12-1にフェイルオーバーの障害カテゴリを示します。
表 12-5 に、カテゴリがフェイルオーバーメカニズムにどのように影響するかを示します。フェイルオーバーメカニズムは稼動しているものとします。
|
メイン SC への影響はないが、スペア SC はハードウェア障害の影響を受けるためにフェイルオーバーは使用不可となります。 |
||||
SC フェイルオーバー時のメインの fomd イベントは、次の順序で発生します。
3. 遠隔のフェイルオーバーソフトウェアにテイクオーバータイマーの起動を通知します。このタイマーの目的は、何らかの理由でメインがハングアップしてカウント 10 まで達しない場合に、遠隔 (スペア) SC が処理を引き継ぐための代替手段を提供することです。
6. コンソールバスのケージングメカニズムを使用可能にします。
7. 変更されたすべての SMS ファイルのスペア SC または HASRAM への伝達を引き起こします。
9. メイン専用の各デーモンを終了し、メイン SC の役割を UNKNOWN に設定します。
11. メインの役割が引き継がれたことを、遠隔 (スペア) のフェイルオーバーソフトウェアに通知します。スペアに通知する前にテイクオーバータイマーが期限切れになると、遠隔 SC が自発的に処理を引き継ぎます。
フェイルオーバー時のスペアの fomd イベントは、次の順序で発生します。
1. メインの fomd からメッセージを受け取ってメインの役割を引き継ぐか、テイクオーバータイマーがタイムアウトします。メッセージを受け取った場合は、テイクオーバータイマーは停止します。
3. スペア fomb をメインの役割に構成するよう hwad、frad および mand に通知します。
7. コンソールバスのケージングメカニズムを使用不可にします。
10. スペアからメインへの逆方向の役割イベントを記録します。
11. これでスペア SC はメインとなり、fomd がフェイルオーバーメカニズムを非アクティブにします。
このシナリオでは、メイン SC との通信の喪失に反応してスペア SC がメインの制御を引き継ぎます。このタイプのフェイルオーバーのもっとも重要な側面は、制御分割条件の防止です。もう 1 つの前提条件は、フェイルオーバーメカニズムが非アクティブになっていないことです。非アクティブになっていると、テイクオーバーは実行されません。
スペアの fomd から見ると、この現象は 2 つの条件によって引き起こされる可能性があります。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 間に存在するインターコネクトネットワークを介してのみ送信されます。
| System Management Services (SMS) 1.6 管理者マニュアル | 819-6418-10 |
|
Copyright© 2006, Sun Microsystems, Inc. All rights reserved.