クォーラム・メカニズムが有効である場合、クォーラム内のすべてのカタログ・サーバーは、データ・グリッドで配置操作を行うために使用可能でなければなりません。
コンテナー・サーバーおよびコア・グループ
カタログ・サービスはコンテナー・サーバーを限られたサイズのコア・グループに配置します。 コア・グループは、そのメンバーの障害を検出しようと試みます。コア・グループのメンバーの中から 1 つだけがコア・グループ・リーダーに選ばれます。 コア・グループ・リーダーは、コア・グループが活動中であることをカタログ・サービスに定期的に知らせるとともに、メンバーシップの変更をカタログ・サービスに報告します。 メンバーシップの変更としては、JVM の障害や、コア・グループに参加する、新しく追加された JVM などが考えられます。
JVM ソケットが閉じられていると、その JVM はもはや使用できないと見なされます。 さらに、各コア・グループ・メンバーは構成によって決定されたペースでこれらのソケットをハートビートします。 JVM が構成された最大時間内にこれらのハートビートに応答しないと、その JVM はもはや使用できないと見なされ、障害検出がトリガーされます。
カタログ・サービスがあるコンテナー JVM を障害と判断した後で、そのコンテナー・サーバーが使用可能であると報告された場合は、このコンテナー JVM に対して WebSphere® eXtreme Scale コンテナー・サーバーをシャットダウンするよう指示が出されます。この状態の JVM は xscmd ユーティリティー・コマンド照会では不可視です。コンテナー JVM のログのメッセージは、コンテナー JVM が失敗したことを示します。これらの JVM は、手動で再始動する必要があります。
コア・グループ・リーダーがいずれかのメンバーと連絡できないと、コア・グループ・リーダーはこのメンバーへの連絡を再試行し続けます。
コア・グループの全メンバーが完全に障害を起こす可能性もあります。 コア・グループ全体で障害が起こった場合は、カタログ・サービスがその障害を検出しなければなりません。
カタログ・サービス・ドメインのハートビート
カタログ・サービス・ドメインは静的メンバーシップおよびクォーラム・メカニズムを持つ専用コア・グループに似ています。そして、通常のコア・グループと同じ方法で障害検出を行います。 ただし、その振る舞いはクォーラム・ロジックを含むように変更されています。 さらに、カタログ・サービスではそれほど活発でないハートビートの構成が使用されます。
障害検出
WebSphere eXtreme Scale は、異常ソケット閉鎖イベントを通じていつプロセスが終了したか検出します。プロセスが終了すると、そのことが直ちにカタログ・サービスに知らされます。
ハートビートの構成について詳しくは、フェイルオーバー検出のためのハートビート間隔設定のチューニングを参照してください。
通常、カタログ・サービスのメンバーは完全な接続性を備えています。 カタログ・サービス・ドメインは JVM の静的集合です。WebSphere eXtreme Scale は、カタログ・サービスのすべてのメンバーがオンラインであることを想定しています。すべてのメンバーがオンラインであるとき、そのカタログ・サービスはクォーラムを持っています。カタログ・サービスは、カタログ・サービスがクォーラムを持っている間だけコンテナー・イベントに応答します。
クォーラム損失の理由
WebSphere eXtreme Scale は、以下のシナリオによってクォーラムの損失を予想します。
カタログ・サービスがクォーラムを失うと、カタログ・サービスはクォーラムが再確立されるのを待ちます。カタログ・サービスは、クォーラムを持っていない間は、コンテナー・サーバーからのイベントを無視します。コンテナー・サーバーは、このときにカタログ・サーバーが拒否したすべての要求を再試行し続けます。ハートビートは、クォーラムが再確立されるまで中断状態となります。
JVM 障害によるクォーラム損失
障害を起こしたカタログ・サーバーはクォーラム損失の原因となります。JVM に障害が発生した場合、できるだけ迅速にクォーラムをオーバーライドする必要があります。障害を起こしたカタログ・サービスは、クォーラムがオーバーライドされるまで、データ・グリッドに再参加できません。
ネットワーク・ブラウン・アウトによるクォーラム損失
WebSphere eXtreme Scale はブラウン・アウトの可能性を予想できる設計になっています。ブラウン・アウトとは、データ・センター間の接続が一時的に失われた状態をいいます。ブラウン・アウトは通常一時的なもので、数秒または数分で解消されます。ブラウン・アウト中、WebSphere eXtreme Scale は通常動作の維持を試みますが、ブラウン・アウトは 1 つの障害イベントと見なされます。この障害は修正されることが想定されており、アクションを必要とせずに通常動作が再開されます。
長時間に及ぶブラウン・アウトは、ユーザーの介入がある場合にのみブラック・アウトに分類できます。 このイベントをブラック・アウトに分類するためには、ブラウン・アウトの一方の側でクォーラムをオーバーライドする必要があります。
カタログ・サービス JVM の循環
stopOgServer コマンドを使用してカタログ・サーバーが停止された場合は、クォーラムを持つサーバーが 1 つ減少します。残りのサーバーはまだクォーラムを持っています。 このカタログ・サーバーを再始動すると、クォーラムは元の数に戻ります。
クォーラム損失の影響
クォーラムが失われると同時にコンテナー JVM が障害を起こした場合は、ブラウン・アウトが回復するまでリカバリーは行われません。 ブラック・アウト・シナリオの場合は、お客様がクォーラム・オーバーライド・コマンドを実行するまでリカバリーは行われません。クォーラム損失とコンテナー障害で二重障害と見なされますが、これはまれにしか起こりません。 二重障害のために、アプリケーションは障害を起こした JVM に保管されたデータへの書き込みアクセスを失う可能性があります。 クォーラムが復元されると、通常のリカバリーが行われます。
同様に、クォーラム損失イベントの発生中にコンテナーを開始しようとしても、コンテナーは開始されません。
クォーラムの損失中に完全クライアント接続が許可されます。 クォーラム損失イベント中にコンテナー障害も接続問題も起こらなければ、クライアントはコンテナー・サーバーと完全に対話することができます。
ブラウン・アウトが発生すると、クライアントによっては、ブラウン・アウトが解消されるまで、データのプライマリーまたはレプリカ・コピーにアクセスできない場合があります。
カタログ・サービス JVM は各データ・センターに存在しなければならないため、新規のクライアントを開始することができます。したがって、ブラウン・アウト・イベント中でもクライアントが少なくとも 1 つのカタログ・サービスには到達できます。
クォーラムのリカバリー
何らかの理由によってクォーラムが失われた場合は、クォーラムが再確立される際、リカバリー・プロトコルが実行されます。 クォーラム損失イベントが発生すると、コア・グループに対する活性検査はすべて中断され、障害報告も無視されます。 クォーラムが元に戻ると、カタログ・サービスはすべてのコア・グループをチェックして、直ちにそれらのメンバーシップを判別します。 障害として報告されたコンテナー JVM でそれまでホストされていた断片は、いずれもリカバリーされます。 プライマリー断片が失われると、残っているレプリカがプライマリー断片にプロモートされます。 レプリカ断片が失われた場合は、残存物の上に追加のレプリカ断片が作成されます。
クォーラムのオーバーライド
クォーラムのオーバーライドは、データ・センター障害が発生した場合にのみ行ってください。 カタログ・サービス JVM の障害またはネットワーク・ブラウン・アウトのためにクォーラムが失われた場合は、カタログ・サービス JVM が再始動されるか、またはネットワークのブラウン・アウトが終わると、リカバリーが自動的に行われます。
データ・センターの障害に通じているのは管理者のみです。WebSphere eXtreme Scale はブラウン・アウトとブラック・アウトを同様に扱います。このような障害の WebSphere eXtreme Scale 環境を、xscmd -c overrideQuorum コマンドを使用して知らせる必要があります。 このコマンドは、カタログ・サービスに対して、現在のメンバーシップでクォーラムが達成されていると想定するように指示し、完全リカバリーが行われます。 クォーラム・オーバーライド・コマンドを発行したときは、障害のあるデータ・センター内の JVM が実際に障害を起こしていて、しかもリカバリーする見込みがないことを保証していることになります。
コンテナーは 1 つ以上の断片をホストします。 断片は、特定の区画のプライマリーであるかレプリカであるか、そのいずれかです。 カタログ・サービスが断片をコンテナーに割り当てると、カタログ・サービスから新しい指示が送られてくるまで、コンテナー・サーバーはこの割り当てを使用します。 例えば、ネットワークのブラウン・アウト時にプライマリー断片は、カタログ・サービスがプライマリー断片にさらに指示を与えるまでそのレプリカ断片と通信を試み続けます。
同期レプリカの振る舞い
接続が中断されている間でも、オンラインであるレプリカの数が少なくともマップ・セットの minsync プロパティー値である場合、プライマリー断片は新しいトランザクションを受け入れることができます。同期レプリカへのリンクが中断されているときにプライマリー断片で新しいトランザクションが処理された場合は、リンクが再確立された時点で、レプリカはプライマリーの現在の状態と再同期されます。
データ・センター間や WAN スタイルのリンクに対しては、同期レプリカ生成を構成しないでください。
非同期レプリカの振る舞い
接続が中断されている間、プライマリー断片は新しいトランザクションを受け入れることができます。 プライマリー断片は変更内容を限界までバッファーに入れます。 この限界に達する前にレプリカとの接続が再確立された場合は、バッファーに入れられた変更内容を使用してレプリカが更新されます。 限界に達すると、プライマリーはバッファーに入れられたリストを破棄します。そしてレプリカが再接続されると、レプリカはクリアされて再同期されます。
カタログ・サービス・ドメインがクォーラムを持っていてもいなくても、常時、クライアントはカタログ・サーバーに接続して、データ・グリッドをブートストラップすることができます。クライアントは、経路テーブルを取得した上でデータ・グリッドと対話するために、カタログ・サーバー・インスタンスへの接続を試みます。 ネットワークの接続性により、ネットワーク・セットアップが原因でクライアントが一部の区画と対話できなくなる場合があります。 クライアントはローカル・レプリカに接続してリモート・データを取得できますが、その場合はクライアントがそうするように構成されていなければなりません。クライアントは、該当するプライマリー区画が使用可能でない場合、データを更新できません。