クォーラムがシステム動作に与える影響を理解する
ただし、さらに致命的な障害が発生した場合 (たとえば可能なネットワーク パスすべての故障など)、everRun システムはシステム全体の総合状態を判断しようとします。その後、システムはゲスト VM の整合性を保護するために必要なアクションを実行します。
次の例は、致命的な障害発生時のシステムのプロセスを示すものです。
例 1: クォーラム サーバなしのシステムではスプリット ブレーン状態が発生する
SplitSite の例では、everRun システムに node0 と node1 が含まれますが、クォーラム サーバは含まれません。動作は正常で、現在検知されている障害はありません。2 つのノードは正常な (障害のない) 動作のときと同様に、A-Link 接続を介してその状態と可用性をやり取りします。次の図は正常な接続を示すものです。
致命的な障害
フォークリフトを運転する作業員が不注意から壁に衝突し、すべてのネットワーク接続 (ビジネスリンクと A-Link の両方) を切断してしまいました。ただし電源は残っており、システムも実行を継続しています。次の図は障害のある状態を示すものです。
障害処理
2 つのノードは次のように障害を処理します。
- node0 — node0 の AX が、A-Link とその他のネットワーク パスの両方が失われたことを検知します。node0 AX がそのパートナーの存在を検知できなくなると、node0 AX がアクティブになりゲスト VM を実行します。ゲスト VM 内のアプリケーションは、ネットワーク損失のため、おそらく機能が制限された状態で実行を継続します。
- node1 — node1 の AX が、両方の A-Link が失われたことを検知しますが、ibiz0 は引き続き利用可能です。パートナーが ibiz0 内のメッセージに応答しないため、node1 AX がアクティブになります。ゲスト VM 内のアプリケーションは、おそらくシステムの問題を認識しない状態で、実行を継続します。
アプリケーション クライアントまたは外部オブザーバの観点からは、ゲスト VM の両方がアクティブであり、同じ返信アドレスでネットワーク メッセージを生成しています。両方のゲスト VM がデータを生成し、それぞれ異なる量の通信エラーを検知します。ゲスト VM の状態は、時間が経つにつれて相違が大きくなります。
復旧と修復
しばらくしてネットワーク接続が復元され、壁の修理が済みネットワーク ケーブルの配線もやり直しました。
AX ペアの各 AX は、それぞれのパートナーがオンラインに戻ったことを認識し、障害処理規則のある AX ペアが、アクティブな状態を続ける AX を選択します。この選択は予測が不可能であり、スプリット ブレーン状態の間にどちらのノードのパフォーマンスがより正確であったかを一切考慮に入れません。
(その時点での) スタンバイ ノードから生成されたデータはアクティブ ノードの再同期によって上書きされるため、(その時点での) スタンバイ ノードにあるデータは永久に失われます。
スプリット ブレーン状態の後、システムが再同期を完了するまで数分間かかります。この所要時間はスタンバイ ノードに送信が必要なディスク アクティビティの量によって決まります。異なるアクティブ ノードをもつゲスト VM がいくつか実行されている場合、両方向の同期トラフィックが生じることがあります。
例 2: クォーラム サーバのある
この SplitSite の例では、everRun システムに例 1 のシステムとまったく同じ接続をもつ node0 と node1 が含まれています。これに加えて、例 2 のシステムにはクォーラム サーバが含まれます。次の図はこれらの接続を示すものです。
致命的な障害
例の不注意な作業員が再びフォークリフトで壁に衝突し、ネットワーク接続をすべて切断してしまいました。ただし電源は残っており、システムも実行を継続しています。次の図は障害のある状態を示すものです。
障害処理
2 つのノードは次のように障害を処理します。
- node0 — node0 の AX が、A-Link とその他のネットワーク パスの両方が失われたことを検知します。node0 AX はそのパートナーの存在を検知できなくなったため、node0 AX はクォーラム サーバへの通信を試行します。この場合、クォーラム サーバも利用不可になります。したがって、node0 AX はシャットダウンを選択します。このシャットダウンは Windows の正常なシャットダウンではなく強制停止であるため、ゲスト VM 内のアプリケーションが停止されます。
- node1 — node1 の AX が、両方の A-Link が失われたことを検知しますが、ibiz0 は引き続き利用可能です。node1 AX がクォーラム サーバへの通信を試行し、サーバが応答するため、node1 AX はアクティブなままになります。ゲスト VM 内のアプリケーションはおそらくシステムの問題を認識していない状態で、実行されます。
アプリケーション クライアントまたは外部オブザーバの観点からは、node1 のゲスト VM はアクティブなままになり、node0 の VM がシャットダウンしている間もデータを生成します。スプリット ブレーン状態は存在しません。
復旧と修復
しばらくしてネットワーク接続が復元され、壁の修理が済みネットワーク ケーブルの配線もやり直しました。
node1 AX でそのパートナーがオンラインに戻ったことが認識されると、node0 AX がスタンバイになります。node0 は以前実行中ではなかったので、node1 から node0 へのデータ同期が開始されます。
スプリット ブレーン状態は発生していないので、データ損失はありません。
システムが再同期を行うには数分間かかります。この所要時間はスタンバイ ノードに送信が必要なディスク アクティビティの量によって決まります。
例 2 (応用編): 致命的な障害時にクォーラム サーバがアクセス不可の場合
クォーラム サーバのある
障害処理は例 2 の場合と似ていますが、node1 に重要な違いが 1 つあります。
この場合、ゲスト VM が node0 と node1 の両方でシャットダウンされ、スプリット ブレーンの発生は回避されます。トレードオフは、node0 とクォーラム サーバのどちらかへの接続が復元されるまでゲスト VM が利用不可になる点です。
その場合、運用しない方のノードを特定し、その電源を切ります。次に、運用する方のノードを強制ブートしてら、VM を強制ブートします。VM をシャットダウンしてから起動する方法については、「仮想マシンの運用を管理する」を参照してください。)
例 2 (応用編): 致命的な障害のない時にクォーラム サーバがアクセス不可の場合
場合によっては、致命的な物理的障害がなくてもクォーラム サーバがアクセス不可になる可能性があります。これはたとえば、OS パッチの適用などの定期的なメンテナンスのためにクォーラム コンピュータがリブートされる場合などです。こうした状況では、クォーラム サービスが応答していないことが AX で検知されるため、AX はクォーラム サーバへの接続が復元されるまで同期のトラフィックを中断します。ゲスト VM は、接続が失われた時点でアクティブだったノード上で実行を継続します。ただし、追加の障害が発生する可能性があるため、ゲスト VM はスタンバイ ノードに移行しません。クォーラム サービスが復元された後、クォーラム サーバへの接続が維持されていれば、AX は同期と通常の障害処理を再開します。
停電から復旧する
停電やシステム シャットダウンの後にシステムを再起動する場合、everRun システムはゲスト VM の起動を行う前に、まずそのパートナーがブートして応答するまで待機します。以前アクティブだった AX がクォーラム サーバにアクセスできる場合には、AX がパートナー ノードのブートを待たずにゲスト VM を直ちに起動します。以前スタンバイだった AX が最初にブートした場合、この AX はパートナー ノードを待機します。
システムがパートナー ノードまたはクォーラム サーバのいずれかから応答を受け取ると、正常な運用が再開されて VM が起動します。その際、その他のケースと同じ障害処理規則が適用されます。
システムがクォーラム サーバからの応答を受け取らない場合や、システムにクォーラム サーバがない場合、ユーザが手作業でゲスト VM を強制的にブートする必要があります。これは AX または障害処理機能によって下されたすべての判断を上書きします。node0 と node1 でそれぞれ異なるユーザが同じゲスト VM をブートすることは避けてください。そうすると、誤ってスプリット ブレーン状態を引き起こす結果となります。
製品サポートとダウンロード