ゾーン・サポートは、データ・センター間でのレプリカ配置のための高度な構成を可能にします。 この機能により、少数のオプションの配置ルールを使用して、何千という区画のグリッドを簡単に管理することができます。データ・センターは、ゾーン・ルールによる構成に従って、ビルの別フロア、別ビル、または異なる都市にさえ配置することも、またはその他の区分に配置することができます。
ゾーンに断片を配置することができます。この機能により、eXtreme Scale がグリッド上に断片をどのように配置するかをさらに制御できるようになります。eXtreme Scale サーバーをホストする Java 仮想マシンは、ゾーン ID によってタグ付けすることができます。現在、デプロイメント・ファイルには 1 つ以上のゾーン・ルールを含めることができます。これらのゾーン・ルールは、断片タイプに関連付けられます。次のセクションでは、ゾーンの使用法について概要を示します。詳しくは、ゾーンによる断片配置の制御を参照してください。
配置ゾーンは、高度なトポロジーを構成するために、eXtreme Scale がプライマリーとレプリカの割り当てをどのように達成するかを制御します。
Java 仮想マシンは、複数のコンテナーを持つことができますが、サーバーは 1 つだけしか持てません。コンテナーは、単一の ObjectGrid の複数の断片をホストできます。
この機能を利用すると、レプリカとプライマリーを異なるロケーションまたはゾーンに配置して、より優れた高可用性を実現することができます。通常、eXtreme Scale は、同じ IP アドレスでプライマリー断片とレプリカ断片を Java 仮想マシンに配置することはありません。この単純なルールにより、一般的には、2 つの eXtreme Scale サーバーが同じ物理コンピューターに配置されることがなくなります。ただし、より柔軟なメカニズムが必要になる場合もあります。例えば、2 つのブレード・シャーシを使用していて、プライマリーを両方のシャーシ間でストライプ し、それぞれのプライマリーのレプリカがそのプライマリーの他方のシャーシに配置されるようにしたい場合があります。
ストライプ・プライマリーは、プライマリーが各ゾーンに配置され、その各プライマリーのレプリカが対向ゾーンに配置されることを意味します。 例えば、プライマリー 0 は zoneA に入り、同期レプリカ 0 は zoneB に入ります。 プライマリー 1 は zoneB に入り、同期レプリカ 1 は zoneA に入ります。
この場合、シャーシ名がゾーン名となります。代替方法として、ビルのフロアの後にゾーンを命名し、ゾーンを使用して、同じデータのプライマリーとレプリカが別フロアに配置されるようにすることができます。ビルおよびデータ・センターでも可能です。データ・センター間でデータが適切に複製されるようにするためのメカニズムとしてゾーンを使用し、データ・センター全体に渡るテストが実行されています。eXtreme Scale の HTTP セッション・マネージャーを使用している場合も、ゾーンを使用することができます。このフィーチャーを使用すると、1 つの Web アプリケーションを 3 つのデータ・センターに渡ってデプロイできます。これにより、ユーザーの HTTP セッションがデータ・センター間で複製され、1 つのデータ・センター全体が障害を起こした場合にも、セッションを回復できるようになります。
WebSphere eXtreme Scale は、複数のデータ・センターに渡る大きなグリッドを管理する必要性を配慮されています。これにより、同一区画のバックアップとプライマリーを必要に応じて異なるデータ・センターに配置することが可能です。すべてのプライマリーをデータ・センター 1 に、すべてのレプリカをデータ・センター 2 に配置したり、両方のデータ・センター間でプライマリーとレプリカをラウンドロビンしたりすることができます。ルールは柔軟であり、さまざまなシナリオが考えられます。また eXtreme Scale は数千ものサーバーを管理することができます。これにより、データ・センター認識による完全な自動配置を同時に使用することによって、管理の観点から手ごろな大規模グリッドの作成が可能です。管理者は、簡単かつ効果的に実行するものを指定できます。
管理者の場合、配置ゾーンを使用して、プライマリー断片とレプリカ断片の配置場所を制御できます。これにより、高性能でかつ高可用性のトポロジーのセットアップが可能になります。 前述したように、eXtreme Scale プロセスのいずれの論理グループに対してもゾーンを定義できます。これらのゾーンは、データ・センター、データ・センターのフロア、ブレード・シャーシなど、物理ワークステーション・ロケーションに対応付けることができます。 ゾーン間でデータをストライプすることができます。これにより、可用性が増します。またホット・スタンバイが必要な場合に、プライマリーとレプリカを別々のゾーンに分割することができます。
eXtreme Scale が Java Standard Edition で使用されるか、あるいは、WebSphere Extended Deployment バージョン 6.1 をベースにしていないアプリケーション・サーバーで使用される場合、断片コンテナーである JVM は、以下の手法を使用して、ゾーンに関連付けられます。
startOgServer スクリプトを使用するアプリケーション
startOgServer スクリプトは、既存のサーバーに組み込まれない eXtreme Scale アプリケーションを開始するために使用されます。-zone パラメーターを使用すると、サーバー内のすべてのコンテナーに使用するゾーンを指定できます。
API を使用するコンテナーを開始する場合のゾーンの指定
コンテナーのゾーン名は、 組み込みサーバー APIの文書に記述されているとおりに指定できます。
eXtreme Scale を WebSphere Extended Deployment Java EE アプリケーションで使用している場合、WebSphere Extended Deploymentノード・グループを使用して、サーバーを特定のゾーンに配置できます。
eXtreme Scale では、JVM は、単一ゾーンのメンバーになることだけを許可されています。 ただし、WebSphere は、ノードが複数ノード・グループの一部になることを許可しています。 各ノードが 1 つのゾーンのノード・グループ内のみにあると確認できれば、eXtreme Scale のゾーンのこの機能を使用できます。
ノード・グループがゾーンであると宣言するために、次の構文を使用して、ノード・グループに名前を付けてください。ReplicationZone<UniqueSuffix> そのようなノード・グループの一部であるノード上で稼働しているサーバーは、ノード・グループ名で指定されるゾーンに組み込まれます。 以下に、トポロジーの例を説明します。
まず、4 つのノードを構成します。node1、node2、node3、および node4 で、各ノードには 2 台のサーバーがあります。 その後、ReplicationZoneA という名前のノード・グループと ReplicationZoneB という名前のノード・グループを作成します。 次に、node1 と node2 を ReplicationZoneA に追加し、node3 と node4 を ReplicationZoneB に追加します。
node1 と node2 のサーバーが始動すると、それらのサーバーは ReplicationZoneA の一部になり、同様に、node3 と node4 のサーバーは ReplicationZoneB の一部になります。
グリッド・メンバー JVM は、始動時にのみゾーン・メンバーシップをチェックします。 新規ノード・グループを追加するか、メンバーシップを変更した場合、それは新たに始動されるか、再始動される JVM のみに影響します。
eXtreme Scale 区画には、1 つのプライマリー断片とゼロ個以上のレプリカ断片があります。この例の場合、これらの断片について以下の命名規則を考慮してください。P はプライマリー断片で、S は同期レプリカで、A は非同期レプリカです。ゾーン・ルールは以下の 3 つの部分からなります。
各断片は、1 つのゾーン・ルールに関連付けることができます。ゾーン・ルールは、2 つの断片間で共有できます。ルールが共有される場合、包含または排他フラグは、1 つのルールを共有するすべてのタイプの断片に拡張されます。
さまざまなシナリオおよびそのシナリオを実装するためのデプロイメント構成を示す一連の例は、以下のとおりです。
ゾーン間でプライマリーとレプリカをストライピングする
3 つのブレード・シャーシがあり、3 つすべてにプライマリーを分散し、1 つの同期レプリカをプライマリー以外のシャーシに配置するものとします。各シャーシをシャーシ名 ALPHA、BETA、および GAMMA を持つゾーンとして定義します。デプロイメント XML の例は以下のとおりです。
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation=
"http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
<objectgridDeployment objectgridName="library">
<mapSet name="ms1" numberOfPartitions="37" minSyncReplicas="1"
maxSyncReplicas="1" maxAsyncReplicas="0">
<map ref="book" />
<zoneMetadata>
<shardMapping shard="P" zoneRuleRef="stripeZone"/>
<shardMapping shard="S" zoneRuleRef="stripeZone"/>
<zoneRule name ="stripeZone" exclusivePlacement="true" >
<zone name="ALPHA" />
<zone name="BETA" />
<zone name="GAMMA" />
</zoneRule>
</zoneMetadata>
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
このデプロイメント XML には、「book」という名前の 1 つのマップを持つ「library」という名前のグリッドが含まれます。さらに、1 つの同期レプリカを持つ 4 つの区画を使用します。zone metadata 文節は、1 つのゾーン・ルールの定義およびゾーン・ルールと断片の関連付けを示します。プライマリー断片と同期断片は、ともにゾーン・ルール「stripeZone」に関連付けられます。このゾーン・ルールでは 3 つのゾーンがすべて含まれ、排他配置が使用されるようになっています。このルールは、区画 0 のプライマリーが ALPHA に配置されると、区画 0 のレプリカは BETA か GAMMA のいずれかに配置されることになります。 他の区画のプライマリーは他のゾーンに配置され、レプリカが同様に配置されます。
非同期レプリカがプライマリーや同期レプリカと異なるゾーンにある
この例では、2 つのビルがあり、その間の接続は待ち時間が長いものとします。すべてのシナリオでデータ損失のない高可用性が保たれるようにします。ただし、ビル間の同期レプリカ生成によるパフォーマンス・インパクトのためトレードオフが生じます。このため、一方のビルに同期レプリカがあり、他方のビルに非同期レプリカがあるようなプライマリーが必要になります。 通常では、障害は、大規模な問題ではなく、JVM の破損やコンピューター障害です。このトポロジーを使用すると、データ損失なしに通常の障害を切り抜けることができます。ビルがなくなることは非常にまれなことであるため、その場合でもある程度のデータ損失は許容範囲内に収まります。それぞれのビルに 1 つずつ、合計 2 つのゾーンを作成できます。デプロイメント XML ファイルは以下のようになります。
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
<objectgridDeployment objectgridName="library">
<mapSet name="ms1" numberOfPartitions="13" minSyncReplicas="1"
maxSyncReplicas="1" maxAsyncReplicas="1">
<map ref="book" />
<zoneMetadata>
<shardMapping shard="P" zoneRuleRef="primarySync"/>
<shardMapping shard="S" zoneRuleRef="primarySync"/>
<shardMapping shard="A" zoneRuleRef="aysnc"/>
<zoneRule name ="primarySync" exclusivePlacement="false" >
<zone name="BldA" />
<zone name="BldB" />
</zoneRule>
<zoneRule name="aysnc" exclusivePlacement="true">
<zone name="BldA" />
<zone name="BldB" />
</zoneRule>
</zoneMetadata>
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
プライマリーと同期レプリカは、排他フラグ設定 false で primaySync ゾーン・ルールを共有します。このため、プライマリーか同期のいずれかがゾーンに配置されると、他方も同じゾーンに配置されます。非同期レプリカは、primarySync ゾーン・ルールと同じゾーンで第 2 のゾーン・ルールを使用しますが、true に設定された exclusivePlacement 属性を使用します。この属性は、断片を同じ区画の別の断片があるゾーンには配置できないことを示します。結果的に、非同期レプリカは、プライマリーまたは同期レプリカと同じゾーンに配置されません。
すべてのプライマリーを 1 つのゾーンに配置し、すべてのレプリカを別のゾーンに配置する
ここでは、すべてのプライマリーが特定のゾーンに配置され、すべてのレプリカが別のゾーンに配置されます。これにより、1 つのプライマリーと 1 つの非同期レプリカを持つことになります。すべてのレプリカはゾーン A に、プライマリーはゾーン B に配置されます。
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
<objectgridDeployment objectgridName="library">
<mapSet name="ms1" numberOfPartitions="13" minSyncReplicas="0"
maxSyncReplicas="0" maxAsyncReplicas="1">
<map ref="book" />
<zoneMetadata>
<shardMapping shard="P" zoneRuleRef="primaryRule"/>
<shardMapping shard="A" zoneRuleRef="replicaRule"/>
<zoneRule name ="primaryRule">
<zone name="A" />
</zoneRule>
<zoneRule name="replicaRule">
<zone name="B" />
</zoneRule>
</zoneMetadata>
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
ここには、プライマリー用に 1 つ (P)、レプリカ用に 1 つ (A) という 2 つのルールがあります。低速のネットワーク相互接続を使用する複数のビルまたはデータ・センターにまたがって、1 つの eXtreme Scale をデプロイしたい場合があります。ネットワーク接続が低速になれば、それだけ処理能力が低下し、接続待ち時間が長くなります。 このモードでは、ネットワーク輻輳やその他の要因のために、ネットワーク分割の可能性も増します。eXtreme Scale は、以下の方法でこの厳しい環境に対処します。
ゾーン間のハートビート処理の制限
コア・グループにグループ化された Java 仮想マシンは、互いにハートビートを実行します。カタログ・サービスが Java 仮想マシンをグループに編成した場合、こうしたグループはゾーンをまたぎません。そのグループ内のリーダーがメンバーシップ情報をカタログ・サービスにプッシュします。カタログ・サービスは報告された障害を検証してから、アクションを実行します。問題のある Java 仮想マシンとの接続を試みて、この処理を実行します。カタログ・サービスは、誤障害検出を認めた場合、何のアクションも実行しません。コア・グループ区画が短時間で回復するためです。
またカタログ・サービスは、定期的にコア・グループ・リーダーに低速でハートビートを行い、コア・グループ分離の症状を処理します。