マルチマスター・レプリカ生成を実装する場合、アービトレーション、リンク作成、およびパフォーマンスなど、設計における側面を考慮する必要があります。
衝突を回避するには、カタログ・サービス・ドメインのサブセットの衝突アービターとして、アービトレーション・カタログ・サービス・ドメイン と呼ばれる特定のカタログ・サービス・ドメインを選択します。例えば、ハブ・アンド・スポーク・トポロジーはハブを衝突ハンドラーとして使用する場合があります。 スポーク衝突ハンドラーは、スポーク・カタログ・サービス・ドメインで検出されたすべての衝突を無視します。ハブ・カタログ・サービス・ドメインは、改訂を作成し、予期しない衝突の改訂を回避します。衝突を処理するように割り当てられたカタログ・サービス・ドメインは、衝突の処理に責任を持つすべてのドメインにリンクしていなければなりません。 ツリー・トポロジーでは、内部の親ドメインが自分の直接の子の衝突を処理します。 対照的に、リング・トポロジーを使用する場合、リング内の 1 つのカタログ・サービス・ドメインをアービターとして指定することはできません。
トポロジー | アプリケーション・アービトレーション? | 注 |
---|---|---|
2 つのカタログ・サービス・ドメインのライン | はい | 1 つのカタログ・サービス・ドメインをアービターとして選択します。 |
3 つのカタログ・サービス・ドメインのライン | はい | 真ん中のカタログ・サービス・ドメインがアービターでなければなりません。 真ん中のカタログ・サービス・ドメインが、単純なハブ・アンド・スポーク・トポロジーのハブだと考えてください。 |
3 つより多いカタログ・サービス・ドメインのライン | いいえ | アプリケーション・アービトレーションはサポートされません。 |
N 個のスポークを持つハブ | はい | すべてのスポークへのリンクを持つハブがアービトレーション・カタログ・サービス・ドメインでなければなりません。 |
N 個のカタログ・サービス・ドメインのリング | いいえ | アプリケーション・アービトレーションはサポートされません。 |
非循環有向ツリー (n 進ツリー) | はい | すべてのルート・ノードは、自分の直接の子孫のみを評価する必要があります。 |
変更待ち時間は、変更が特定のカタログ・サービス・ドメインに到着する前に経由しなければならない中間カタログ・サービス・ドメインの数によって決まります。
トポロジーが、すべてのカタログ・サービス・ドメインを他のすべてのカタログ・サービス・ドメインにリンクすることによって中間カタログ・サービス・ドメインを除去すれば、トポロジーの変更待ち時間は最善になります。 ただし、カタログ・サービス・ドメインはそのリンク数に比例してレプリカ生成作業を実行しなければなりません。 大規模トポロジーの場合、非常に多くのリンクが定義され、管理が負担になる場合があります。
フォールト・トレランスは、変更のレプリカ生成のために、2 つのカタログ・サービス・ドメイン間に存在するパス数によって決定します。
特定のカタログ・サービス・ドメインのペア間に 1 つしかリンクがないと、リンク障害が発生した場合に変更を伝搬できません。同様に、中間ドメインのいずれかでリンク障害が発生すると、カタログ・サービス・ドメイン間で変更が伝搬されません。あるカタログ・サービス・ドメインから別のカタログ・サービス・ドメインへの単一リンクが中間ドメインを経由するトポロジーを考えることができます。その場合、中間カタログ・サービス・ドメインのいずれかがダウンすると、変更が伝搬されません。
4 つのカタログ・サービス・ドメイン A、B、C、および D を持つライン・トポロジーを考えてみます。
例えば、リング・トポロジー内の特定のカタログ・サービスがダウンしている場合、2 つの隣接ドメインはまだ互いに変更を直接プルすることができます。
すべての変更はハブを経由して伝搬されます。したがって、ライン・トポロジーやリング・トポロジーとは対照的に、ハブ・アンド・スポーク設計は、ハブに障害が起きた場合に機能停止となる可能性が高いといえます。
単一カタログ・サービス・ドメインは、ある量のサービス損失に対しては回復力があります。ただし、広域ネットワーク障害や物理データ・センター間のリンク障害などのより大規模な障害が発生した場合は、いずれかのカタログ・サービス・ドメインが中断される可能性があります。
カタログ・サービス・ドメイン上に定義されるリンク数は、パフォーマンスに影響します。リンクが多いと使われるリソースも多くなり、結果的にレプリカ生成パフォーマンスが落ちる場合もあります。 他のドメインを介してドメイン A の変更を取得する機能は、そのトランザクションを各場所に複製するドメイン A の負荷を効果的に軽減します。ドメイン上の変更配布の負荷は、トポロジー内のドメインの数ではなく、ドメインが使用するリンクの数によって制限されます。このロード・プロパティーは、スケーラビリティーを提供するため、トポロジー内のドメインは変更の配布に伴う負荷を分配できます。
A <=> B <=> C <=> D <=> E
カタログ・サービス・ドメイン A および E は、それぞれ単一カタログ・サービス・ドメインへのリンクのみを持っているので、配布の負荷は最も低くなります。 ドメイン B、C、および D は、それぞれ 2 つのドメインへのリンクを持っています。 つまり、ドメイン B、C、および D 上の配布の負荷は、ドメイン A および E 上の負荷の 2 倍になります。ワークロードは、トポロジー内のドメイン総数ではなく、各ドメインのリンク数によって決まります。つまり、記述される負荷の分散は、ラインに 1000 ドメインを含んだとしても一定のままです。
マルチマスター・レプリカ生成トポロジーを使用する際は、以下の制限を考慮してください。
TCP ソケットが、スライディング・ウィンドウのメカニズムを使用して大量データのフローを制御することを思い出してください。このメカニズムは、通常、往復のインターバルのソケットを 64 KB に制限します。往復のインターバルが 100 ミリ秒の場合、追加チューニングをすることなく帯域幅は 640 KB/秒に制限されます。 リンクで使用可能な帯域幅を完全に使用する場合は、オペレーティング・システムに固有のチューニングが必要になることがあります。 ほとんどのオペレーティング・システムにはチューニング・パラメーターがあり、高度な待ち時間リンクのスループットを向上させる RFC 1323 オプションも含まれます。
マルチマスター・レプリカ生成を使用すると、バージョン管理を扱うマップ・エントリーごとに一定の処理量が追加されます。各コンテナーはトポロジー内の各カタログ・サービス・ドメインの一定量のデータも追跡します。 2 つのカタログ・サービス・ドメインを持つトポロジーは、50 カタログ・サービス・ドメインを持つトポロジーとほぼ同じメモリーを使用します。 WebSphere eXtreme Scale は、その実装環境のリプレイ・ログや類似のキューを使用しません。すなわち、レプリカ生成リンクがかなりの期間使用できず、後で再開する場合、リカバリー構造は準備されていません。