レプリカ配置のゾーン

ゾーンを使用すると、複数のデータ・センターにわたってレプリカを配置できます。 ゾーンは、ゾーン・ルールによる構成に従って、ビルの別フロア、別のビル、あるいは異なる都市やその他の異なる地域にも配置することができます。 この機能により、オプションの配置ルールを使用して、何千という区画のデータ・グリッドを管理できます。

ゾーン・ルール

eXtreme Scale 区画には、1 つのプライマリー断片と 0 個以上のレプリカ断片があります。 この例の場合、これらの断片について以下の命名規則を考慮してください。 P はプライマリー断片で、S は同期レプリカで、A は非同期レプリカです。 ゾーン・ルールは以下の 3 つの部分からなります。

  • ルール名
  • ゾーンのリスト
  • 包含または排他フラグ
コンテナー・サーバーのゾーン名の定義について詳しくは、 コンテナー・サーバーのゾーンの定義を参照してください。 ゾーン・ルールは、断片を配置できるゾーンのセットを指定します。 包含フラグは、1 つの断片がリストからゾーンに配置されると、他のすべての断片もそのゾーンに配置されることを示します。 排他設定は、区画の各断片がゾーン・リストの異なるゾーンに配置されることを示します。 例えば、排他設定を使用する場合、3 つの断片 (プライマリーと 2 つの同期レプリカ) がある場合は、ゾーン・リストに 3 つのゾーンがなければならないということです。

各断片は、1 つのゾーン・ルールに関連付けることができます。 ゾーン・ルールは、2 つの断片間で共有できます。 ルールが共有される場合、包含または排他フラグは、1 つのルールを共有するすべてのタイプの断片に拡張されます。

注: XIO 障害検出では、ゾーン配置はこのトピックの規則に従います。 ただし、XIO が障害検出を提供する代わりに、コア・グループ障害検出は無視されます。 クライアントがコンテナーとの通信障害を報告してきたとき、またはコンテナーがいずれかのカタログへのチェックインに失敗した場合など、カタログ・サーバーは、引き続きコンテナーのハートビートをモニターします。

さまざまなシナリオおよびそのシナリオを実装するためのデプロイメント構成を示す一連の例は、以下のとおりです。

ゾーン間でのプライマリーとレプリカのストライピング

3 つのブレード・シャーシがあり、3 つすべてにプライマリーを分散し、1 つの同期レプリカをプライマリー以外のシャーシに配置するものとします。 各シャーシをシャーシ名 ALPHABETA、および 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 のレプリカは BETAGAMMA のいずれかに配置されることになります。 同様に、他の区画のプライマリーは他のゾーンに配置され、レプリカは、また別のゾーンに配置されます。

プライマリー・レプリカおよび同期レプリカとは異なるゾーン内の非同期レプリカ

この例では、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 つのプライマリー用のゾーンと、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 つのルールがあります。

広域ネットワーク (WAN) 上のゾーン

低速のネットワーク相互接続を使用する複数のビルまたはデータ・センターにまたがって、1 つのデータ・グリッドをデプロイしたい場合があります。 ネットワーク接続が低速になれば、それだけ処理能力が低下し、接続待ち時間が長くなります。 このモードでは、ネットワーク輻輳やその他の要因のために、ネットワーク分割の可能性も増します。 eXtreme Scale は、ゾーン間のハートビートを制限することにより、この厳しい環境にアプローチします。

コア・グループにグループ化された Java™ 仮想マシン は、相互にハートビートを行います。 カタログ・サービスが Java 仮想マシン をコア・グループに編成する場合、それらのグループは複数のゾーンにまたがることはありません。 そのグループ内のリーダーがメンバーシップ情報をカタログ・サービスにプッシュします。 カタログ・サービスは報告された障害を検証してから、アクションを実行します。 これを行うには、疑わしい Java 仮想マシンへの接続を試行します。 カタログ・サービスは、誤った障害検出を認識した場合、何のアクションも実行しません。コア・グループ区画が短時間で回復するためです。

またカタログ・サービスは、定期的にコア・グループ・リーダーに低速でハートビートを行い、コア・グループ分離の症状を処理します。