複数の集合を組み込んだデプロイメントのトポロジーを選択する際、いくつかの異なるオプションがあります。
レプリカ生成データ・グリッドのインフラストラクチャーは、集合 間を双方向のリンクで接続したカタログ・サービス・ドメインのグラフです。 リンクを使用して、2 つの 集合 はデータ変更内容をやりとりできます。例えば、最も単純なトポロジーは、カタログ・サービス・ドメイン間に単一のリンクを持つ 1 対の 集合 です。 集合 は、左から A、B、C というようにアルファベット順で指定されています。リンクは、遠距離にわたる広域ネットワーク (WAN) を経由する場合もあります。 リンクが遮断されたとしても、いずれかの 集合 (collective) でまだデータを変更できます。トポロジーは、リンクが 集合 と再接続したときに変更を調整します。 ネットワーク接続が中断されると、リンクは自動的に再接続しようとします。
リンクをセットアップすると、この製品はまず、すべての 集合 (collective) を同一にしようと試みます。次に、いずれかの 集合 (collective) で変更が発生すると、eXtreme Scale は同一の状態を維持するよう試みます。 目標は、各 集合 (collective) がリンクで接続されたすべての他の 集合 (collective) の正確なミラーになることです。 集合 間のレプリカ生成リンクは、1 つの 集合 (collective) で行われたすべての変更を確実に他の 集合 にコピーするのに役立ちます。
ライン・トポロジーはこのような単純なデプロイメントですが、かなりのリンク品質を実証します。 まず、変更を受け取るために、集合 (collective) は直接すべての他の 集合 (collective) に接続する必要がありません。 集合 (collective) B は 集合 (collective) A から変更をプルします。 集合 (collective) C は、集合 A と C を接続する 集合 (collective) B を介して 集合 (collective) A から変更を受信します。同様に、集合 (collective) D は 集合 (collective) C を介して別の 集合 から変更を受信します。この機能により、変更配布の負荷が変更のソースから離れた場所に広がります。
リング・トポロジーは、より回復力のあるトポロジーの例です。 集合 (collective) または単一リンクに障害が起こった場合でも、残った 集合 がまだ変更を取得できます。その 集合 は、障害から離れて、リングの周りを回ります。リング・トポロジーの大きさには関係なく、各 集合 (collective) は他の 集合 とのリンクを最大 2 つ持ちます。変更を伝搬するための待ち時間は長くなる場合があります。特定の 集合 (collective) での変更は、すべての 集合 にその変更が反映されるまで、複数のリンクを経由して伝搬する必要がある場合があります。ライン・トポロジーにも同じ特性があります。
リングの中心に置いたルート・集合 (collective) を使用した、より洗練されたリング・トポロジーをデプロイすることも可能です。ルート・集合 (collective) は、調整の中心点として機能します。他の 集合 は、ルート・集合 (collective) で生じた変更に対する調整のリモート・ポイントとして働きます。ルート・集合 (collective) は、集合 間の変更をアービトレーションすることができます。 ルート・集合 (collective) を囲む複数のリングがリング・トポロジーに含まれている場合、集合 (collective) は最も内側にあるリング間の変更のみをアービトレーションすることができます。ただし、アービトレーションの結果は他のリングの 集合 にも広がります。
ハブ・アンド・スポーク・トポロジーでは、ハブ・集合 (collective) を経由して変更が伝搬します。ハブは指定される唯一の中間 集合 (collective) であるため、ハブ・アンド・スポーク・トポロジーでは待ち時間が短縮されます。ハブ・集合 (collective) は、リンク経由ですべてのスポーク・集合 (collective) に接続されています。ハブは、集合 間で変更を配布します。ハブは、衝突に対して調整のポイントとして機能します。更新頻度の高い環境では、同期を保つために、スポークよりも多くのハードウェア上でハブを稼働する必要がある場合があります。 WebSphere® DataPower® XC10 アプライアンス は、直線的に拡大するように設計されています。つまり、問題なく、必要に応じてハブをさらに大きくすることができます。 ただし、ハブに障害が起こった場合は、変更はハブが再始動するまで配布されません。 スポーク・集合 上の変更は、ハブが再接続された後に配布されます。
また、完全に複製したクライアントを使用したストラテジー、すなわち、ハブとして稼働しているサーバーのペアを使用するトポロジーのバリエーションを使用することもできます。各クライアントは、クライアント JVM 内に、必要なものを完備した単一コンテナー・データ・グリッドとカタログを作成します。 クライアントは、そのデータ・グリッドを使用してハブ・カタログに接続します。この接続により、クライアントはハブへの接続を取得すると、すぐにハブと同期するようになります。
クライアントによって行われた変更は、クライアントに対してローカルで、非同期でハブに複製されます。 ハブはアービトレーション・集合 (collective) として機能し、すべての接続されたクライアントに変更を配布します。完全複製クライアントのトポロジーは、OpenJPA などのオブジェクト・リレーショナル・マッパーに信頼性の高い L2 キャッシュを提供します。 変更はハブを介してクライアント JVM 間に迅速に配布されます。 キャッシュ・サイズを使用可能なヒープ・スペース内に含むことができる場合、このトポロジーは L2 のこのスタイルにとって信頼できるアーキテクチャーです。
必要であれば、複数の区画を使用して、複数の JVM 上にハブ・集合 (collective) を拡張します。 すべてのデータはまだ単一のクライアント JVM に収まらなければならないため、複数の区画を使用してハブの容量を増加させ、変更の配布とアービトレーションを行います。ただし、複数の区画を使用しても、単一 集合 (collective) の容量は変更されません。
非循環有向ツリーを使用することもできます。非循環ツリーには循環やループはなく、有向セットアップにより、リンクの存在は親と子の間のみに制限されます。 この構成は、多くの集合を含むトポロジーで役立ちます。これらのトポロジーでは、すべての可能なスポークに接続される中央ハブを使用することは実用的ではありません。また、このタイプのトポロジーは、ルート・集合 (collective) を更新することなく子 集合 を追加する必要がある場合にも便利です。
ツリー・トポロジーでもまだ、ルート・集合 (collective) に調整の中心点を置くことができます。第 2 レベルはまだ、それらの下の 集合 (collective) で生じた変更に対する調整のリモート・ポイントとして機能します。ルート・集合 (collective) は、第 2 レベルにある 集合 間の変更のみをアービトレーションすることができます。それぞれが各レベルで N 個の子を持つ、n 進ツリーを使用することもできます。それぞれの 集合 (collective) は、n 個のリンクに接続します。
このトポロジー変化には、ハブとして稼働する 1 対のサーバーが含まれます。 各クライアントは、クライアント JVM 内に、必要なものを完備した単一コンテナー・データ・グリッドとカタログを作成します。 クライアントは、そのデータ・グリッドを使用してハブ・カタログに接続します。これにより、クライアントはハブへの接続を取得すると、すぐにハブと同期するようになります。
クライアントによって行われた変更は、クライアントに対してローカルで、非同期でハブに複製されます。 ハブはアービトレーション・集合 (collective) として機能し、すべての接続されたクライアントに変更を配布します。完全複製クライアントのトポロジーは、OpenJPA などのオブジェクト・リレーショナル・マッパーに適した L2 キャッシュを提供します。 変更はハブを介してクライアント JVM 間に迅速に配布されます。 キャッシュ・サイズをクライアントの使用可能なヒープ・スペース内に含むことができる限り、このトポロジーは L2 のこのスタイルに適したアーキテクチャーです。
必要であれば、複数の区画を使用して、複数の JVM 上にハブ・集合 (collective) を拡張します。 すべてのデータはまだ単一のクライアント JVM に収まらなければならないため、複数の区画を使用してハブの容量を増加させ、変更の配布とアービトレーションを行いますが、単一 集合 (collective) の容量は変更しません。