6.2. 一般的なレプリケーションシナリオ


次の一般的なシナリオを使用して、ニーズに最適なレプリケーショントポロジーをビルドできます。

6.2.1. 単一サプライヤーレプリケーション

単一サプライヤーレプリケーションシナリオでは、サプライヤーサーバーがディレクトリーデータのメインコピー (読み取り/書き込みレプリカ) を維持し、このデータの更新を 1 つ以上のコンシューマーサーバーに送信します。すべてのディレクトリーの変更は、サプライヤーサーバー上の読み取り/書き込みレプリカで行われ、コンシューマーサーバーにはデータの読み取り専用レプリカが含まれます。

サプライヤーサーバーは、サプライヤーレプリカに加えられたすべての変更を記録する changelog を保持します。

次の図は、単一サプライヤーのレプリケーションシナリオを示しています。

図6.1 単一サプライヤーレプリケーション

1 つのサプライヤーサーバーが管理できるコンシューマーサーバーの合計数は、ネットワークの速度と毎日変更されるエントリーの合計数によって異なります。

6.2.2. マルチサプライヤーレプリケーション

マルチサプライヤーレプリケーション環境では、同じ情報のメインコピーが複数のサーバーに存在し、ディレクトリーデータを異なるロケーションで同時に更新できます。各サーバーで発生した変更は他のサーバーにレプリケートされるため、各サーバーはサプライヤーとコンシューマーの両方として機能します。

複数のサーバーで同じデータが変更されると、レプリケーションの競合が発生します。競合解決手順を使用して、Directory Server は最新の変更を有効な変更として使用します。

マルチサプライヤーが存在する環境では、各サプライヤーにはコンシューマーと他のサプライヤーを指すレプリカ合意が必要です。たとえば、2 つのサプライヤー (Supplier ASupplier B) および 2 つのコンシューマー (Consumer CConsumer 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 マルチサプライヤーとカスケードレプリケーションの組み合わせ

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る