6.2. 一般的なレプリケーションシナリオ
次の一般的なシナリオを使用して、ニーズに最適なレプリケーショントポロジーをビルドできます。
6.2.1. 単一サプライヤーレプリケーション リンクのコピーリンクがクリップボードにコピーされました!
単一サプライヤーレプリケーションシナリオでは、サプライヤーサーバーがディレクトリーデータのメインコピー (読み取り/書き込みレプリカ) を維持し、このデータの更新を 1 つ以上のコンシューマーサーバーに送信します。すべてのディレクトリーの変更は、サプライヤーサーバー上の読み取り/書き込みレプリカで行われ、コンシューマーサーバーにはデータの読み取り専用レプリカが含まれます。
サプライヤーサーバーは、サプライヤーレプリカに加えられたすべての変更を記録する changelog を保持します。
次の図は、単一サプライヤーのレプリケーションシナリオを示しています。
図6.1 単一サプライヤーレプリケーション
1 つのサプライヤーサーバーが管理できるコンシューマーサーバーの合計数は、ネットワークの速度と毎日変更されるエントリーの合計数によって異なります。
6.2.2. マルチサプライヤーレプリケーション リンクのコピーリンクがクリップボードにコピーされました!
マルチサプライヤーレプリケーション環境では、同じ情報のメインコピーが複数のサーバーに存在し、ディレクトリーデータを異なるロケーションで同時に更新できます。各サーバーで発生した変更は他のサーバーにレプリケートされるため、各サーバーはサプライヤーとコンシューマーの両方として機能します。
複数のサーバーで同じデータが変更されると、レプリケーションの競合が発生します。競合解決手順を使用して、Directory Server は最新の変更を有効な変更として使用します。
マルチサプライヤーが存在する環境では、各サプライヤーにはコンシューマーと他のサプライヤーを指すレプリカ合意が必要です。たとえば、2 つのサプライヤー (Supplier A と Supplier B) および 2 つのコンシューマー (Consumer C と Consumer D) を使用してレプリケーションを設定します。さらに、1 つのサプライヤーが 1 つのコンシューマーのみを更新することを決定します。Supplier A で、Supplier B および Consumer C を指すレプリカ合意を作成します。Supplier B で、Supplier A および Consumer D を指すレプリカ合意を作成します。次の図はレプリカ合意を示しています。
図6.2 2 つのサプライヤーを持つマルチサプライヤーレプリケーション
Red Hat Directory Server は、任意のレプリケーション環境で最大 20 台のサプライヤーサーバーと、数量無制限のハブサーバーおよびコンシューマーサーバーをサポートします。
多くのサプライヤーを使用する場合は、さまざまなレプリカ合意を作成する必要があります。さらに、各サプライヤーは異なるトポロジーで設定できるため、Directory Server 環境では 20 の異なるディレクトリーツリーがあるだけでなく、さまざまなスキーマもあります。他の多くの変数がトポロジーの選択に直接影響を与える可能性があります。
サプライヤーは、他のすべてのサプライヤーまたは一部のサプライヤーのサブセットに更新を送信できます。更新がすべてのサプライヤーに送信されると、変更がより速く伝播され、全体的なシナリオの障害許容度が向上します。ただし、サプライヤーの設定が複雑になり、ネットワークとサーバーの需要が高まります。サプライヤーのサブセットに更新を送信すると、設定がはるかに簡単になり、ネットワークとサーバーの負荷が軽減されますが、複数のサーバーに障害が発生した場合にデータが失われるリスクが高まります。
完全に接続されたメッシュトポロジー
次の図は、4 つのサプライヤーサーバーが他のすべてのサプライヤーサーバーにデータをレプリケートする、完全に接続されたメッシュトポロジーを示しています。1 つのレプリカ合意は 1 つのサプライヤーと 1 つのコンシューマー間の関係のみを記述するため、4 つのサプライヤーサーバー間に合計で 12 のレプリカ合意が存在します。
サプライヤーが 20 ある場合は、合計 380 件のレプリカ合意 (サプライヤーが 20 で、各 19 件の合意) を作成する必要があります。
2 台以上のサーバーが同時に障害を起こす可能性が低い場合、または特定のサプライヤー間の接続の方が適している場合は、部分的に接続されたトポロジーの使用を検討してください。
部分的に接続されたトポロジー
次の図は、各サプライヤーサーバーが 2 つのサプライヤーサーバーにデータをレプリケートするトポロジーを示しています。前のトポロジーの例と比較すると、4 つのサプライヤーサーバー間に存在するレプリカ合意は 8 つだけです。
6.2.3. カスケードレプリケーション リンクのコピーリンクがクリップボードにコピーされました!
カスケードレプリケーションシナリオでは、ハブサーバーがサプライヤーサーバーから更新を受信し、その更新をコンシューマーサーバーに送信します。ハブサーバーは、一般的なコンシューマーサーバーのように読み取り専用のレプリカを保持し、一般的なサプライヤーサーバーのように changelog も維持するため、ハイブリッドになります。
ハブサーバーはサプライヤーデータをコンシューマーに転送し、ディレクトリークライアントからの更新要求をサプライヤーに参照します。
次の図は、カスケードレプリケーションのシナリオを示しています。
図6.3 カスケードレプリケーションのシナリオ
次の図は、各サーバー上でレプリカがどのように設定されているか (読み取り/書き込みまたは読み取り専用)、およびどのサーバーが changelog を維持しているかを示しています。
図6.4 カスケードレプリケーションにおけるレプリケーショントラフィックと changelog
カスケードレプリケーションは、次の場合に役立ちます。
- 大量のトラフィック負荷を分散する場合。レプリケーショントポロジー内のサプライヤーはすべての更新トラフィックを管理するため、コンシューマーへのレプリケーショントラフィックもサポートすると、サプライヤーに大きな負荷がかかる可能性があります。多数のコンシューマーにレプリケーション更新を処理できるハブにレプリケーショントラフィックをリダイレクトできます。
- 地理的に分散した環境でローカルハブサプライヤーを使用することで接続コストを削減する場合。
- ディレクトリーサービスのパフォーマンスを向上する場合。すべての読み取り操作をコンシューマーに送信し、すべての更新操作をサプライヤーに送信すると、ハブサーバーからすべてのインデックス (システムインデックスを除く) を削除できます。これにより、サプライヤーとハブサーバー間のレプリケーション速度が大幅に向上します。
6.2.4. さまざまなシナリオ リンクのコピーリンクがクリップボードにコピーされました!
ネットワークやディレクトリー環境のニーズに合わせて、いずれのレプリケーションシナリオも組み合わせることができます。一般的な組み合わせの 1 つとして、マルチサプライヤー設定をカスケード設定と使用する組み合わせがあります。
次の図は、混合シナリオのトポロジーの例を示しています。
図6.5 マルチサプライヤーとカスケードレプリケーションの組み合わせ