高可用性を備えている WebSphere® eXtreme Scale は、信頼できるデータの冗長性を備え、障害も検出できます。
WebSphere eXtreme Scale は、 Java 仮想マシン のデータ・グリッドを自己編成して、ゆるやかに連合する 1 つのツリーにします。そのツリーのルートにはカタログ・サービスが置かれ、ツリーのリーフ部分にはコンテナーを保持するコア・グループが置かれます。詳しくは、キャッシング・アーキテクチャー: マップ、コンテナー、クライアント、およびカタログを参照してください。
プロセスに障害が起きるのには、いくつかの場合があります。何らかのリソース限界に達したり (例えば、最大ヒープ・サイズ)、プロセス制御ロジックがプロセスを強制終了したといった理由で、 プロセスに障害が起こることがあります。オペレーティング・システムに障害が起きると、システム上で実行中のすべてのプロセスが失われます。ネットワーク・インターフェース・カード (NIC) などの頻繁には障害が起きないハードウェアに障害が起きると、オペレーティング・システムがネットワークから切断されます。さらに多くのポイントで障害が起きると、プロセスが使用不可になります。このような状況において、 これらすべての障害は、プロセス障害または接続不良の 2 つの障害タイプのうちのいずれかに分類されます。
WebSphere eXtreme Scale は、 プロセス障害に迅速に対応します。プロセスに障害が起きると、オペレーティング・システムは、プロセスが使用していたリソースの残りすべてをクリーンアップする必要が生じます。このクリーンアップには、ポートの割り当ておよび接続が含まれています。プロセスに障害が起きると、信号はそのプロセスによって使用されていた接続を通して送信され、各接続がクローズされます。これらの信号を使用し、障害の起きたプロセスに接続されている他のプロセスによって 即時にプロセス障害が検出されます。
オペレーティング・システムが切断されると、接続不良が発生します。その結果として、オペレーティング・システムは信号を他のプロセスに送信することができなくなります。接続不良が発生する理由はいくつかありますが、 それらの理由は、ホスト障害と孤立化の 2 つのカテゴリーに分割されます。
ホスト障害
マシンの電源コンセントのプラグが抜かれると、即座に動作しなくなります。
孤立化
このシナリオは、 使用不可であると見なされたプロセスが実際には使用不可ではないため、 ソフトウェアが正しく対処することが最も難しい障害の状態です。基本的に、システムにはサーバーまたは他のプロセスが失敗したように見えるが、 実際は正常に実行しているという状況です。
コンテナー障害は、 通常コア・グループ・メカニズムを通してピア・コンテナーによって 発見されます。コンテナーまたはコンテナーのセットに障害が起きると、カタログ・サービスにより、そのコンテナーにホスティングされていた断片が移行されます。カタログ・サービスにより、非同期のレプリカに移行する前に最初に同期レプリカが検索されます。プライマリー断片が新規ホスト・コンテナーに移行された後で、カタログ・サービスにより、欠落しているレプリカの新規ホスト・コンテナーが検索されます。
コンテナー障害検出までの 待ち時間
障害は、ソフトとハードの障害に 分類されます。ソフト障害の原因は、一般にプロセスの 障害です。そのような障害はオペレーティング・システムによって検出されます。 オペレーティング・システムでは、ネットワーク・ソケットなどの使用されたリソースを迅速にリカバリーできます。 ソフト障害の場合、標準的な障害検出までの時間は、1 秒未満です。 ハード障害の場合、デフォルトのハートビート・チューニングを使用すると、 検出まで最長 200 秒かかることもあります。そのような障害は、物理的なマシンの破損、 ネットワーク・ケーブル切断、オペレーティング・システム障害などです。ハード障害を検出するために、ランタイムは構成可能なハートビートに依存します。
カタログ・サービス・グリッドは、1 つの eXtreme Scale グリッドなので、コンテナー障害プロセスと同じようにコア・グループ・メカニズムも使用します。主な相違点は、カタログ・サービス・ドメインでは、コンテナーに使用するカタログ・サービス・アルゴリズムの代わりに、プライマリー断片の定義にピア選択プロセスを使用する点です。
配置サービスおよびコア・グループ化サービスは、N 個の中の 1 つのサービスです。N 個の中の 1 つのサービスは、高可用性グループのメンバーの 1 つで実行されます。 ロケーション・サービスおよび管理は、高可用性グループのすべてのメンバーで実行されています。配置サービスおよびコア・グループ化サービスは、システムをレイアウトする必要があるため別のものです。ロケーション・サービスおよび管理は読み取り専用サービスであり、 スケーラビリティーを提供するためにあらゆる場所に存在します。
カタログ・サービスはレプリカ生成を使用して、独自の障害限界を設定します。カタログ・サービス・プロセスに障害が起きると、サービスが再開し、システムを必要なレベルの可用性に復元します。カタログ・サービスをホスティングしているすべてのプロセスで 障害が起こると、データ・グリッドから重要なデータが失われます。この障害が発生した場合は、すべてのコンテナー・サーバーを再始動する必要があります。 カタログ・サービスは多くのプロセスで実行されているため、この障害は起きる可能性のないイベントです。ただし、単一のボックスですべてのプロセスを実行している場合は、単一のブレード・シャーシ内、または単一のネットワーク・スイッチで、障害が起きる可能性があります。カタログ・サービスをホスティングしているボックスから共通の障害モードを除去して、障害が起きる可能性を減らします。
プロセスが失われるとプライマリーおよびレプリカの両方が失われるため、レプリカはプライマリーとして同じプロセスに配置するべきではありません。単一マシンの開発環境においては、2 つのコンテナーを所有でき、それらの間で複製できます。デプロイメント・ポリシーで開発モード属性を定義して、レプリカをプライマリーと同じマシンに配置するよう構成できます。しかし、実動環境では、 そのホストを失うことにより両方のコンテナー・サーバーを失うことになるため、 単一マシンの使用では不十分です。単一マシンでの開発モードと 複数のマシンを使用する実動モード間でモードを変更するには、 デプロイメント・ポリシー構成ファイルで開発モードを無効にします。
ロス・タイプ | ディスカバリー (検出) メカニズム | 復旧メソッド |
---|---|---|
プロセス・ロス | 入出力 | 再始動 |
サーバー・ロス | ハートビート | 再始動 |
ネットワーク障害 | ハートビート | ネットワークおよび接続の再確立 |
サーバー・サイド・ハング | ハートビート | サーバーの停止および再始動 |
サーバー・ビジー | ハートビート | サーバーが使用可能になるまで待機 |