マルチマスター・レプリカ生成での設計上の考慮事項

マルチマスター・レプリカ生成を実装する場合、アービトレーション、リンク作成、およびパフォーマンスなど、設計における側面を考慮する必要があります。

トポロジー設計におけるアービトレーションの考慮事項

同じレコードが 2 個所で同時に変更される可能性がある場合には、変更の競合が生じることがあります。 各カタログ・サービス・ドメインが、同程度のプロセッサー、メモリー、ネットワーク・リソースを持つようにセットアップしてください。変更の衝突処理 (アービトレーション) を実行しているカタログ・サービス・ドメインは、他のカタログ・サービス・ドメインよりも多くのリソースを使用することに気付くことがあります。 衝突は、自動的に検出されます。 衝突は、以下の 2 つのメカニズムの 1 つを使用して処理されます。
  • デフォルト衝突アービター: デフォルトのプロトコルは、字句的に最も小さい名前の付いたカタログ・サービス・ドメインからの変更を使用します。 例えば、カタログ・サービス・ドメイン A と B によってレコードの競合が生じる場合には、カタログ・サービス・ドメイン B の変更は無視されます。 カタログ・サービス・ドメイン A はそのバージョンを保持し、カタログ・サービス・ドメイン B のレコードはカタログ・サービス・ドメイン A からのレコードに一致するように変更されます。この動作は、ユーザーやセッションが正常にバインドされているアプリケーション、またはユーザーやセッションがデータ・グリッドの 1 つにアフィニティーを持つ対象となるアプリケーションにも同様に適用されます。
  • カスタム衝突アービター: アプリケーションはカスタム・アービターを提供することができます。カタログ・サービス・ドメインは衝突を検出すると、アービターを開始します。 便利なカスタム・アービターの開発について詳しくは、 マルチマスター・レプリカ生成のためのカスタム・アービターの作成を参照してください。
衝突が起こる可能性のあるトポロジーに対しては、ハブ・アンド・スポーク・トポロジーまたはツリー・トポロジーの実装を検討してください。これらの 2 つのトポロジーは、以下のシナリオで発生する可能性のある、恒常的な衝突の回避につながります。
  1. 複数のカタログ・サービス・ドメインで衝突が発生します。
  2. 各カタログ・サービス・ドメインが衝突をローカルで処理し、改訂を生成します。
  3. 改訂が衝突し、その結果、改訂の改訂をもたらします。

衝突を回避するには、カタログ・サービス・ドメインのサブセットの衝突アービターとして、アービトレーション・カタログ・サービス・ドメイン と呼ばれる特定のカタログ・サービス・ドメインを選択します。例えば、ハブ・アンド・スポーク・トポロジーはハブを衝突ハンドラーとして使用する場合があります。 スポーク衝突ハンドラーは、スポーク・カタログ・サービス・ドメインで検出されたすべての衝突を無視します。ハブ・カタログ・サービス・ドメインは、改訂を作成し、予期しない衝突の改訂を回避します。衝突を処理するように割り当てられたカタログ・サービス・ドメインは、衝突の処理に責任を持つすべてのドメインにリンクしていなければなりません。 ツリー・トポロジーでは、内部の親ドメインが自分の直接の子の衝突を処理します。 対照的に、リング・トポロジーを使用する場合、リング内の 1 つのカタログ・サービス・ドメインをアービターとして指定することはできません。

次の表に、さまざまなトポロジーと互換性のあるアービトレーション・アプローチをまとめました。
表 1. アービトレーション・アプローチ. この表は、アプリケーション・アービトレーションがさまざまなトポロジーと互換性があるかどうかについて記述します。
トポロジー アプリケーション・アービトレーション?
2 つのカタログ・サービス・ドメインのライン はい 1 つのカタログ・サービス・ドメインをアービターとして選択します。
3 つのカタログ・サービス・ドメインのライン はい 真ん中のカタログ・サービス・ドメインがアービターでなければなりません。 真ん中のカタログ・サービス・ドメインが、単純なハブ・アンド・スポーク・トポロジーのハブだと考えてください。
3 つより多いカタログ・サービス・ドメインのライン いいえ アプリケーション・アービトレーションはサポートされません。
N 個のスポークを持つハブ はい すべてのスポークへのリンクを持つハブがアービトレーション・カタログ・サービス・ドメインでなければなりません。
N 個のカタログ・サービス・ドメインのリング いいえ アプリケーション・アービトレーションはサポートされません。
非循環有向ツリー (n 進ツリー) はい すべてのルート・ノードは、自分の直接の子孫のみを評価する必要があります。

トポロジー設計におけるリンクの考慮事項

変更待ち時間、フォールト・トレランス、およびパフォーマンス特性におけるトレードオフを最適化している間、トポロジーにはリンクの最小数が含まれているのが理想的です。
  • 変更待ち時間

    変更待ち時間は、変更が特定のカタログ・サービス・ドメインに到着する前に経由しなければならない中間カタログ・サービス・ドメインの数によって決まります。

    トポロジーが、すべてのカタログ・サービス・ドメインを他のすべてのカタログ・サービス・ドメインにリンクすることによって中間カタログ・サービス・ドメインを除去すれば、トポロジーの変更待ち時間は最善になります。 ただし、カタログ・サービス・ドメインはそのリンク数に比例してレプリカ生成作業を実行しなければなりません。 大規模トポロジーの場合、非常に多くのリンクが定義され、管理が負担になる場合があります。

    変更が他のカタログ・サービス・ドメインにコピーされる速度は、以下の追加要因によって異なります。
    • ソース・カタログ・サービス・ドメイン上のプロセッサーとネットワーク帯域幅
    • ソース・カタログ・サービス・ドメインとターゲット・カタログ・サービス・ドメインの間の中間カタログ・サービス・ドメイン数とリンク数
    • ソース・カタログ・サービス・ドメイン、ターゲット・カタログ・サービス・ドメイン、および中間カタログ・サービス・ドメインで使用可能なプロセッサーとネットワーク・リソース
  • フォールト・トレランス

    フォールト・トレランスは、変更のレプリカ生成のために、2 つのカタログ・サービス・ドメイン間に存在するパス数によって決定します。

    特定のカタログ・サービス・ドメインのペア間に 1 つしかリンクがないと、リンク障害が発生した場合に変更を伝搬できません。同様に、中間ドメインのいずれかでリンク障害が発生すると、カタログ・サービス・ドメイン間で変更が伝搬されません。あるカタログ・サービス・ドメインから別のカタログ・サービス・ドメインへの単一リンクが中間ドメインを経由するトポロジーを考えることができます。その場合、中間カタログ・サービス・ドメインのいずれかがダウンすると、変更が伝搬されません。

    4 つのカタログ・サービス・ドメイン A、B、C、および D を持つライン・トポロジーを考えてみます。

    ライン・トポロジー

    以下のいくつかの状態のままであれば、ドメイン D は A からの変更はまったく見えません。
    • ドメイン A が稼働中で B がダウン
    • ドメイン A および B が稼働中で C がダウン
    • A と B の間のリンクがダウン
    • B と C の間のリンクがダウン
    • C と D の間のリンクがダウン
    対照的に、リング・トポロジーの場合、各カタログ・サービス・ドメインはどちらかの方向から変更を受け取ることができます。

    リング・トポロジー

    例えば、リング・トポロジー内の特定のカタログ・サービスがダウンしている場合、2 つの隣接ドメインはまだ互いに変更を直接プルすることができます。

    すべての変更はハブを経由して伝搬されます。したがって、ライン・トポロジーやリング・トポロジーとは対照的に、ハブ・アンド・スポーク設計は、ハブに障害が起きた場合に機能停止となる可能性が高いといえます。

    ハブ・アンド・スポーク・トポロジー

    単一カタログ・サービス・ドメインは、ある量のサービス損失に対しては回復力があります。ただし、広域ネットワーク障害や物理データ・センター間のリンク障害などのより大規模な障害が発生した場合は、いずれかのカタログ・サービス・ドメインが中断される可能性があります。

  • リンク作成およびパフォーマンス

    カタログ・サービス・ドメイン上に定義されるリンク数は、パフォーマンスに影響します。リンクが多いと使われるリソースも多くなり、結果的にレプリカ生成パフォーマンスが落ちる場合もあります。 他のドメインを介してドメイン A の変更を取得する機能は、そのトランザクションを各場所に複製するドメイン A の負荷を効果的に軽減します。ドメイン上の変更配布の負荷は、トポロジー内のドメインの数ではなく、ドメインが使用するリンクの数によって制限されます。このロード・プロパティーは、スケーラビリティーを提供するため、トポロジー内のドメインは変更の配布に伴う負荷を分配できます。

    カタログ・サービス・ドメインは、他のカタログ・サービス・ドメインを間接的に経由して変更を取得できます。5 つのカタログ・サービス・ドメインを持つライン・トポロジーを考えてみます。
    A <=> B <=> C <=> D <=> E
    • A は、B、C、D、および E から B を介して変更をプルします。
    • B は、A と C からは直接、D と E からは C を介して変更をプルします。
    • C は、B と D からは直接、A からは B を介して、E からは D を介して変更をプルします。
    • D は、C と E からは直接、A と B からは C を介して変更をプルします。
    • E は、D からは直接、A、B、および C からは D を介して変更をプルします。

    カタログ・サービス・ドメイン A および E は、それぞれ単一カタログ・サービス・ドメインへのリンクのみを持っているので、配布の負荷は最も低くなります。 ドメイン B、C、および D は、それぞれ 2 つのドメインへのリンクを持っています。 つまり、ドメイン B、C、および D 上の配布の負荷は、ドメイン A および E 上の負荷の 2 倍になります。ワークロードは、トポロジー内のドメイン総数ではなく、各ドメインのリンク数によって決まります。つまり、記述される負荷の分散は、ラインに 1000 ドメインを含んだとしても一定のままです。

マルチマスター・レプリカ生成のパフォーマンスに関する考慮事項

マルチマスター・レプリカ生成トポロジーを使用する際は、以下の制限を考慮してください。