ゾーンを使用して、断片の配置を制御できます。ゾーンは、ユーザー定義の物理サーバーの論理グループです。各種ブレード・サーバー、ブレード・サーバーのシャーシ、ビルのフロア、マルチ・データ・センター環境での異なる地理的ロケーションなど、さまざまなタイプのゾーンの例を以下で示します。また、それぞれ固有の IP アドレスを持っている複数のサーバー・インスタンスが同じ物理サーバー上で実行されている仮想化環境での使用状況も取り上げます。
ゾーンの典型的な例および使用状況は、2 カ所以上に地理的に分散したデータ・センターがある場合です。分散データ・センターにより、データ・センターでの障害からのリカバリーのためにデータ・グリッドが異なるロケーションに広がります。例えば、リモート・データ・センターにデータ・グリッドの非同期レプリカ断片の完全な集合を配置するようにすることをお勧めします。このストラテジーによって、ローカル・データ・センターで障害が発生しても、透過的にデータを失うことなくリカバリーできます。データ・センター自体は、高速で待ち時間の短いネットワークを使用しています。ただし、あるデータ・センターと別のデータ・センターとの間の通信では、待ち時間が長くなります。同期レプリカは各データ・センター内で使用され、待ち時間が短いことにより、レプリカ生成が応答時間に与える影響が最小に抑えられます。非同期レプリカ生成を使用すると、応答時間への影響が緩和されます。ローカル・データ・センターで障害が発生した場合に、地理的距離があると、可用性が提供されます。
以下の例では、Chicago ゾーンにプライマリー断片があるものについては、そのレプリカが London ゾーンにあります。London ゾーンにプライマリー断片があるものについては、そのレプリカが Chicago ゾーンにあります。
eXtreme Scale での以下の 3 つの構成設定により、断片配置を制御します。
以下のセクションでは、各種オプションについて説明します。大まかに複雑さの低いものから高いものまで提示します。
デプロイメント XML ファイルで、developmentMode="false" と設定します。
この単純なステップにより、1 番目の eXtreme Scale 断片配置ポリシーがアクティブになります。
この XML ファイルについて詳しくは、デプロイメント・ポリシー記述子 XML ファイルを参照してください。
ポリシー 1: 同じ区画の断片は、別個の物理サーバーに配置する。
1 つのレプリカ断片を使用したデータ・グリッドの単純な例を考えてみましょう。このポリシーでは、各区画のプライマリー断片とレプリカ断片は異なる物理サーバー上にあります。1 つの物理サーバーに障害が起こった場合でも、データは失われません。各区画のプライマリー断片またはレプリカ断片が障害の発生しなかった異なる物理サーバー上にあるか、その両方が障害の発生しなかった他のいくつかの物理サーバー上にあることになります。
このポリシーの高可用性および単純性のために、すべての実稼働環境で最も効率的な設定となります。 多くの場合、環境内の断片配置を効果的に制御するために必要な唯一のステップは、このポリシーを適用することです。
このポリシーを適用した場合、1 台の物理サーバーは 1 つの IP アドレスによって定義されます。断片は、コンテナー・サーバー内に配置されます。コンテナー・サーバーは、例えば、startOgServer スクリプトに指定する -listenerHost パラメーターなど、1 つの IP アドレスを持っています。複数のコンテナー・サーバーが同じ IP アドレスを持っている場合があります。
1 台の物理サーバーが複数の IP アドレスを持っているため、環境をさらに制御するには、次のステップを検討してください。
コンテナー・サーバーは、startOgServer スクリプトに -zone パラメーターを指定して、ゾーンに割り当てます。WebSphere Application Server 環境では、ゾーンは特定の名前形式 ReplicationZone<Zone> でノード・グループを通じて定義されます。 このようにして、ゾーンの名前とメンバーシップを選択します。詳しくは、コンテナー・サーバーのゾーンの定義を参照してください。
ポリシー 2: 同じ区画の断片は、別個のゾーンに配置する。
1 つのレプリカ断片を使用したデータ・グリッドの例を拡張して、今度はそれを 2 つのデータ・センターにわたってデプロイしたと考えてみましょう。各データ・センターは独立ゾーンとして定義します。1 番目のデータ・センター内のコンテナー・サーバーにゾーン名 DC1 を使用し、2 番目のデータ・センター内のコンテナー・サーバーに対してゾーン名 DC2 を使用します。このポリシーでは、各区画のプライマリー断片とレプリカ断片は、異なるデータ・センターにあります。1 つのデータ・センターに障害が起こった場合でも、データは失われません。それぞれの区画について、プライマリー断片かレプリカ断片のいずれかがもう一方のデータ・センターにあります。
このポリシーでは、ゾーンを定義することによって断片配置を制御できます。興味のある物理的境界、論理的境界、またはグループを選択します。次に、それぞれのグループごとに固有のゾーン名を選択し、各ゾーン内のコンテナー・サーバーを当該ゾーンの名前で始動します。このようにして、eXtreme Scale は、同じ区画の断片が別個のゾーンに配置されるように断片を配置します。
詳しくは、例: デプロイメント・ポリシー記述子 XML ファイルを使用したゾーン定義を参照してください。
断片配置ストラテジーのさまざまな使用状況を以下に示します。
ローリング・アップグレード
デプロイメントの再開を要する保守など、ローリング・アップグレードを物理サーバーに適用するシナリオを考えてみましょう。 この例では、データ・グリッドが 20 台の物理サーバーにわたって広がっており、1 つの同期レプリカを使用して定義されていると想定します。保守のために、10 台の物理サーバーを一度にシャットダウンするとします。10 台の物理サーバーのグループをシャットダウンとき、シャットダウンするサーバー上にプライマリー断片とレプリカ断片の両方がある区画はありません。 そうでないと、その区画のデータが失われます。
最も簡単な解決策は、3 番目のゾーンを定義することです。2 つのゾーンにそれぞれ 10 台ずつ物理サーバーを入れる代わりに、3 つのゾーンを使用し、2 つのゾーンには 7 台の物理サーバーを、1 つのゾーンには 6 台の物理サーバーを入れます。データがより多くのゾーンに広がると、可用性のためのフェイルオーバーが向上します。
別の手法として、ゾーンをもう 1 つ定義するのではなく、レプリカを追加するというのがあります。
eXtreme Scale のアップグレード
eXtreme Scale ソフトウェアをライブ・データを含むデータ・グリッドでローリング・アップグレードする場合は、次の問題を考慮してください。カタログ・サービス・ソフトウェアのバージョンは、コンテナー・サーバー・ソフトウェアのバージョンより大きいか等しくなければなりません。まずローリング・ストラテジーを使用してすべてのカタログ・サーバーをアップグレードします。デプロイメントのアップグレードについて詳しくは、トピックeXtreme Scale サーバーの更新を参照してください。
データ・モデルの変更
関連問題として、ダウン時間を生じさせることなく、どのようにデータ・グリッド内に保管されたオブジェクトのデータ・モデルまたはスキーマを変更するかということがあります。データ・モデルを変更するのに、データ・グリッドを停止し、コンテナー・サーバー・クラスパスの更新されたデータ・モデル・クラスを使用して再開し、データ・グリッドを再ロードすると、破壊的な影響を与える可能性があります。代わりに、新規データ・グリッドを新しいスキーマを使用して開始し、古いデータ・グリッドのデータを新規データ・グリッドにコピーし、最後に古いデータ・グリッドをシャットダウンします。
仮想化
クラウド・コンピューティングおよび仮想化は、人気のある新たなテクノロジーです。デフォルトでは、eXtreme Scale は、「ポリシー 1」に述べられているように、確実に同じ区画の 2 つの断片が同じ IP アドレス上に置かれないようにします。VMware などの仮想イメージ上にデプロイする場合は、それぞれ固有の IP アドレスを持つ複数のサーバー・インスタンスを同じ物理サーバー上で実行できます。レプリカを別個の物理サーバー上にのみ配置可能であるようにするには、ゾーンを使用すると、この問題を解決できます。物理サーバーをゾーンにグループ化し、プライマリー断片とレプリカ断片を別個のゾーンに保持するゾーン配置ルールを使用します。
広域ネットワークでのゾーン
低速のネットワーク接続を使用する複数のビルまたはデータ・センターにまたがって、1 つの eXtreme Scale データ・グリッドをデプロイしたい場合があります。ネットワーク接続が低速になれば、それだけ処理能力が低下し、接続待ち時間が長くなります。 このモードでは、ネットワーク輻輳やその他の要因のために、ネットワーク分割の可能性も増します。
これらのリスクに対処するために、eXtreme Scale カタログ・サービスは、コンテナー・サーバーの障害を検出するためにハートビートをやりとりするコア・グループにコンテナー・サーバーを編成します。これらのコア・グループは複数のゾーンに広がりません。各コア・グループ内のリーダーがメンバーシップ情報をカタログ・サービスにプッシュします。カタログ・サービスは、報告された障害があれば、問題のコンテナー・サーバーにハートビートを行うことによってそれを検証してから、メンバーシップ情報に応答します。 カタログ・サービスは、誤障害検出を認めた場合、何のアクションも実行しません。コア・グループ区画が短時間で回復するためです。またカタログ・サービスは、定期的にコア・グループ・リーダーに低速でハートビートを行い、コア・グループ分離の症状を処理します。