高可用性

高可用性を備えている WebSphere® eXtreme Scale は、信頼できるデータの冗長性を備え、障害も検出できます。

WebSphere eXtreme Scale は、 Java 仮想マシン のデータ・グリッドを自己編成して、ゆるやかに連合する 1 つのツリーにします。そのツリーのルートにはカタログ・サービスが置かれ、ツリーのリーフ部分にはコンテナーを保持するコア・グループが置かれます。詳しくは、キャッシング・アーキテクチャー: マップ、コンテナー、クライアント、およびカタログを参照してください。

各コア・グループはカタログ・サービスによって自動的に作成され、約 20 個のサーバーからなるグループに 入れられます。コア・グループ・メンバーは、グループ内の他メンバーのヘルス・モニタリングを 提供します。また、各コア・グループは、 カタログ・サービスにグループ情報を伝達するためのリーダーとして 1 つのメンバー を選びます。コア・グループのサイズを制限することにより、 良好なヘルス・モニタリングおよび高度にスケーラブルな環境を維持できます。
注: コア・グループ・サイズを変更できる WebSphere Application Server 環境 では、eXtreme Scale は、 コア・グループあたり 50 を超えるメンバー数はサポートしません。

ハートビート処理

  1. Java 仮想マシン間ではソケットがオープン状態のままなので、ソケットが予想外に閉じると、この予想外のクローズはピア Java 仮想マシンの障害として検出されます。 この検出機能は、Java 仮想マシンが極端に早く終了したなどの障害事例をキャッチします。 また、この検出機能により、通常 1 秒足らずで、こうしたタイプの障害から回復できます。
  2. その他のタイプの障害には、オペレーティング・システム・パニック、物理サーバー障害、ネットワーク障害などがあります。こうした障害は、ハートビート処理を使用して検出します。
プロセスのペア間では定期的にハートビートが送信されます。一定数のハートビートが欠落すると、障害とみなされます。 この方法は、N*M 秒で障害を検出します。N は欠落ハートビートの数で、M はハートビート間隔です。M と N を直接指定することはサポートされていません。スライダー・メカニズムを使用してテストされる一定範囲の M と N の組み合わせを指定できるようになっています。

障害

プロセスに障害が起きるのには、いくつかの場合があります。何らかのリソース限界に達したり (例えば、最大ヒープ・サイズ)、プロセス制御ロジックがプロセスを強制終了したといった理由で、 プロセスに障害が起こることがあります。オペレーティング・システムに障害が起きると、システム上で実行中のすべてのプロセスが失われます。ネットワーク・インターフェース・カード (NIC) などの頻繁には障害が起きないハードウェアに障害が起きると、オペレーティング・システムがネットワークから切断されます。さらに多くのポイントで障害が起きると、プロセスが使用不可になります。このような状況において、 これらすべての障害は、プロセス障害または接続不良の 2 つの障害タイプのうちのいずれかに分類されます。

プロセス障害

WebSphere eXtreme Scale は、 プロセス障害に迅速に対応します。プロセスに障害が起きると、オペレーティング・システムは、プロセスが使用していたリソースの残りすべてをクリーンアップする必要が生じます。このクリーンアップには、ポートの割り当ておよび接続が含まれています。プロセスに障害が起きると、信号はそのプロセスによって使用されていた接続を通して送信され、各接続がクローズされます。これらの信号を使用し、障害の起きたプロセスに接続されている他のプロセスによって 即時にプロセス障害が検出されます。

接続不良

オペレーティング・システムが切断されると、接続不良が発生します。その結果として、オペレーティング・システムは信号を他のプロセスに送信することができなくなります。接続不良が発生する理由はいくつかありますが、 それらの理由は、ホスト障害と孤立化の 2 つのカテゴリーに分割されます。

ホスト障害

マシンの電源コンセントのプラグが抜かれると、即座に動作しなくなります。

孤立化

このシナリオは、 使用不可であると見なされたプロセスが実際には使用不可ではないため、 ソフトウェアが正しく対処することが最も難しい障害の状態です。基本的に、システムにはサーバーまたは他のプロセスが失敗したように見えるが、 実際は正常に実行しているという状況です。

コンテナー障害

コンテナー障害は、 通常コア・グループ・メカニズムを通してピア・コンテナーによって 発見されます。コンテナーまたはコンテナーのセットに障害が起きると、カタログ・サービスにより、そのコンテナーにホスティングされていた断片が移行されます。カタログ・サービスにより、非同期のレプリカに移行する前に最初に同期レプリカが検索されます。プライマリー断片が新規ホスト・コンテナーに移行された後で、カタログ・サービスにより、欠落しているレプリカの新規ホスト・コンテナーが検索されます。

注: コンテナー孤立化 - コンテナーが使用不可であることが検出されると、カタログ・サービスによりコンテナーの断片がコンテナーから移行されます。 これらのコンテナーが使用可能になると、カタログ・サービスは、通常の開始フローの場合と同じように、これらのコンテナーを配置可能とみなします。

コンテナー障害検出までの 待ち時間

障害は、ソフトとハードの障害に 分類されます。ソフト障害の原因は、一般にプロセスの 障害です。そのような障害はオペレーティング・システムによって検出されます。 オペレーティング・システムでは、ネットワーク・ソケットなどの使用されたリソースを迅速にリカバリーできます。 ソフト障害の場合、標準的な障害検出までの時間は、1 秒未満です。 ハード障害の場合、デフォルトのハートビート・チューニングを使用すると、 検出まで最長 200 秒かかることもあります。そのような障害は、物理的なマシンの破損、 ネットワーク・ケーブル切断、オペレーティング・システム障害などです。ハード障害を検出するために、ランタイムは構成可能なハートビートに依存します。

カタログ・サービス障害

カタログ・サービス・グリッドは、1 つの eXtreme Scale グリッドなので、コンテナー障害プロセスと同じようにコア・グループ・メカニズムも使用します。主な相違点は、カタログ・サービス・ドメインでは、コンテナーに使用するカタログ・サービス・アルゴリズムの代わりに、プライマリー断片の定義にピア選択プロセスを使用する点です。

配置サービスおよびコア・グループ化サービスは、N 個の中の 1 つのサービスです。N 個の中の 1 つのサービスは、高可用性グループのメンバーの 1 つで実行されます。 ロケーション・サービスおよび管理は、高可用性グループのすべてのメンバーで実行されています。配置サービスおよびコア・グループ化サービスは、システムをレイアウトする必要があるため別のものです。ロケーション・サービスおよび管理は読み取り専用サービスであり、 スケーラビリティーを提供するためにあらゆる場所に存在します。

カタログ・サービスはレプリカ生成を使用して、独自の障害限界を設定します。カタログ・サービス・プロセスに障害が起きると、サービスが再開し、システムを必要なレベルの可用性に復元します。カタログ・サービスをホスティングしているすべてのプロセスで 障害が起こると、データ・グリッドから重要なデータが失われます。この障害が発生した場合は、すべてのコンテナー・サーバーを再始動する必要があります。 カタログ・サービスは多くのプロセスで実行されているため、この障害は起きる可能性のないイベントです。ただし、単一のボックスですべてのプロセスを実行している場合は、単一のブレード・シャーシ内、または単一のネットワーク・スイッチで、障害が起きる可能性があります。カタログ・サービスをホスティングしているボックスから共通の障害モードを除去して、障害が起きる可能性を減らします。

複数のコンテナー障害

プロセスが失われるとプライマリーおよびレプリカの両方が失われるため、レプリカはプライマリーとして同じプロセスに配置するべきではありません。単一マシンの開発環境においては、2 つのコンテナーを所有でき、それらの間で複製できます。デプロイメント・ポリシーで開発モード属性を定義して、レプリカをプライマリーと同じマシンに配置するよう構成できます。しかし、実動環境では、 そのホストを失うことにより両方のコンテナー・サーバーを失うことになるため、 単一マシンの使用では不十分です。単一マシンでの開発モードと 複数のマシンを使用する実動モード間でモードを変更するには、 デプロイメント・ポリシー構成ファイルで開発モードを無効にします。

表 1. 障害のディスカバリーおよび復旧の要約
ロス・タイプ ディスカバリー (検出) メカニズム 復旧メソッド
プロセス・ロス 入出力 再始動
サーバー・ロス ハートビート 再始動
ネットワーク障害 ハートビート ネットワークおよび接続の再確立
サーバー・サイド・ハング ハートビート サーバーの停止および再始動
サーバー・ビジー ハートビート サーバーが使用可能になるまで待機