7.3. レプリケーションストラテジーの定義

レプリケーションストラテジーは、提供する必要のあるサービスで決定されます。レプリケーションストラテジーを確認するには、ネットワーク、ユーザー、アプリケーション、ディレクトリーサービスの使用方法などの調査から始めます。
レプリケーションストラテジーを計画したら、ディレクトリーサービスをデプロイすることができます。管理者は、ディレクトリーサービスにかける負荷に応じてディレクトリーサービスを調整できるため、ディレクトリーサービスを段階的にデプロイすることが推奨されます。負荷分析がすでに動作しているディレクトリーに基づいている場合を除き、ディレクトリーに対する実際の需要が明確になったときにディレクトリーサービスを変更できるようにしてください。

7.3.1. レプリケーションサーベイの実施

サイト調査でネットワークの品質と使用状況に関する情報を収集して、レプリケーションストラテジーの定義に役立てます。
  • さまざまな建物やリモートサイトを接続する LAN と WAN の品質、および使用可能な帯域幅の量。
  • ユーザーの物理的な場所、各サイトのユーザー数、使用状況パターン。これがディレクトリーサービスの使用目的になります。
  • ディレクトリーサービスにアクセスするアプリケーションの数。読み取り、検索、および比較操作と書き込み操作の相対的な割合。
  • メッセージングサーバーがディレクトリーを使用する場合は、処理する電子メールメッセージごと実行する操作の数を調べます。ディレクトリーサービスに依存するその他の製品は、通常、認証アプリケーションやメタディレクトリーアプリケーションなどの製品です。それぞれについて、ディレクトリーサービスで実行される操作の種類および頻度を決定します。
  • ディレクトリーサービスに保存されているエントリーの数およびサイズ。
人事データベースまたは財務情報管理するサイトは、電話帳の目的でのみディレクトリーを使用する技術者が含まれるサイトよりも、ディレクトリーサービスの負荷を大きくする可能性があります。

7.3.2. 一部レプリケーションで選択された属性を複製する

フラクショナルレプリケーションにより、管理者はサプライヤーからコンシューマー (または別のサプライヤー) に送信されない属性セットを選択できます。したがって、管理者は、含まれるすべての情報を複製せずにデータベースを複製できます。
一部レプリケーションは、レプリケーション合意ごとに有効になり、設定されます。属性の除外は、すべてのエントリーに等しく適用されます。コンシューマーサーバーに関する限り、除外された属性には常に値がありません。そのため、コンシューマーサーバーに対する検索を実行するクライアントは、除外された属性を見ることはありません。同様に、フィルターにそれらの属性を指定して検索を行うと、一致するエントリーはありません。
一部レプリケーションは、以下のような状況で特に便利です。
  • コンシューマーサーバーが低速なネットワークを使用して接続されている場合、頻繁に変更されていない属性や jpegPhoto などの大きな属性により、ネットワークトラフィックが少なくなります。
  • コンシューマーサーバーがパブリックインターネットなどの信頼できないネットワーク上に配置されている場合、電話番号などの機密属性を除外すると、サーバーのアクセス制御手段が無効になったり、マシンが攻撃者によって悪用されても、これらの属性にアクセスしないことを保証する追加レベルの保護が提供されます。
一部レプリケーションの設定は、『Administration Guide』の第 8 章 Managing Replication のレプリケーション契約およびサプライヤーの設定のセクションで説明しています。

7.3.3. レプリケーションリソース要件

レプリケーションを使用すると、より多くのリソースが必要になります。レプリケーションストラテジーを定義する際に、以下のリソース要件を検討してください。
  • ディスク使用量 - サプライヤーサーバーでは、変更ログは各更新操作の後に書き込まれます。多数の更新操作を受信するサプライヤーサーバーでは、ディスク使用量が増える可能性があります。
    注記
    各サプライヤーサーバーは 1 つの changelog を使用します。サプライヤーに複数の複製されたデータベースが含まれる場合、changelog はより頻繁に使用され、ディスク使用量がさらに高くなります。
  • サーバースレッド - 各レプリケーションアグリーメントは 1 つのサーバースレッドを消費します。そのため、クライアントアプリケーションが使用できるスレッドの数が減少し、クライアントアプリケーションのサーバーパフォーマンスに影響を与える可能性があります。
  • ファイル記述子 - サーバーで利用可能なファイル記述子の数は、変更ログ (1 つのファイル記述子) および各レプリケーションアグリーメント (アグリーメントごとに 1 つのファイル記述子) によって削減されます。

7.3.4. マルチサプライヤーレプリケーションに必要なディスク領域の管理

マルチサプライヤーレプリカは、ディレクトリー編集の changelog、更新エントリーの状態情報、削除されたエントリーの tombstone エントリーなど、追加のログを保持します。この情報は、マルチサプライヤーレプリケーションを実行するために必要です。これらのログファイルは非常に大きくなる可能性があるため、ディスク領域を残すためにこれらのファイルを定期的にクリーンアップする必要があります。
マルチサプライヤーレプリカに対して changelog メンテナンスを設定できる属性は 4 つあります。2 つは cn=changelog5 の下にあり、変更ログのトリミングに直接関連します。
  • nsslapd-changelogmaxage changelog のエントリーの最大期間を設定します。エントリーがその制限より古い場合は、削除されます。これにより、変更ログが無期限に大きくなるのを防ぎます。
  • nsslapd-changelogmaxentries changelog で許可されるエントリーの最大数を設定します。nsslapd-changelogmaxage と同様に、changelog もトリミングされますが、設定に注意してください。これは、ディレクトリー情報の完全なセットを許可するのに十分な大きさである必要があります。そうしないと、マルチサプライヤーのレプリケーションが正しく機能しない可能性があります。
他の 2 つの属性は、cn=replica, cn=suffixDN, cn=mapping tree, cn=config のレプリケーションアグリーメントエントリーの下にあります。これらの 2 つの属性は、ディレクトリーの編集情報ではなく、changelog に保持されるメンテナンス情報である tombstone および状態情報に関連します。
  • nsDS5ReplicaPurgeDelay tombstone (削除済み)エントリーおよび状態情報が changelog に設定可能な最大期間を設定します。tombstone または状態情報エントリーがその時間よりも古くなると、削除されます。nsslapd-changelogmaxage の値は、tombstone および状態情報エントリーにのみ適用される点で nsDS5ReplicaPurgeDelay 属性とは異なります。nsslapd-changelogmaxage は、ディレクトリーの変更など、変更ログ内のすべてのエントリーに適用されます。
  • nsDS5ReplicaTombstonePurgeInterval サーバーがパージ操作を実行する頻度を設定します。この間隔で、Directory Server は内部操作を実行して、tombstone および状態のエントリーを削除します。最大経過時間が最長のレプリケーション更新スケジュールよりも長いことを確認してください。そうしないと、マルチサプライヤーレプリケーションがレプリカを適切に更新できない場合があります。
レプリケーションおよび変更を管理するパラメーターの説明は、『Configuration, Command, and File Reference』の第 2 章 Core Configuration Attributes にあります。

7.3.5. ワイドエリアネットワーク全体でのレプリケーション

ワイドエリアネットワークは通常、ローカルエリアネットワークよりも遅延や帯域幅遅延積が大きく、速度が遅くなります。Directory Server は、サプライヤーとコンシューマーがワイドエリアネットワークを使用して接続されている場合に効率的なレプリケーションをサポートします。
以前のバージョンの Directory Server では、サプライヤーとコンシューマー間のエントリーおよび更新の送信に使用されたレプリケーションプロトコルは、サプライヤーは 1 つの更新操作のみを送信し、コンシューマーからの応答を待つため、レイテンシーの影響を大きく受けていました。これにより、スループットが低下し、レイテンシーが長くなりました。
サプライヤーは、応答を待たずに、多くの更新とエントリーをコンシューマーに送信します。したがって、レイテンシーが高いネットワークでは、多くのレプリケーション操作がネットワーク上で転送されている可能性があり、レプリケーションスループットはローカルエリアネットワークで達成できるスループットと同様です。
注記
サプライヤーが 7.1 よりも前のバージョンの Red Hat Directory Server を実行する別のサプライヤーに接続されている場合は、互換性のために以前のレプリケーションメカニズムにフォールバックします。したがって、遅延の影響を受けないレプリケーションを実現するには、サプライヤーサーバーとコンシューマーサーバーの両方で少なくともバージョン 7.1 を実行する必要があります。
Directory Server とネットワーク接続の効率の両方について、パフォーマンスとセキュリティーの両方の問題を考慮する必要があります。
  • インターネットなどのパブリックネットワークを介してレプリケーションを実行する場合は、TLS を使用することが強く推奨されます。これにより、レプリケーショントラフィックの盗聴が防止されます。
  • ネットワークには T-1 以上のインターネット接続を使用してください。
  • ワイドエリアネットワークを介したレプリケーションアグリーメントを作成するときは、サーバー間を持続的に同期しないでください。レプリケーショントラフィックは帯域幅を大量に消費し、ネットワークとインターネット接続全体の速度を低下させる可能性があります。
  • コンシューマーを初期化するときは、コンシューマーをすぐに初期化しないでください。代わりに、ファイルシステムレプリカの初期化を利用します。これは、オンライン初期化やファイルからの初期化よりもはるかに高速です。ファイルシステムレプリカの初期化の使用方法については、『Red Hat Directory Server Administration Guide』を参照してください。

7.3.6. 高可用性でのレプリケーションの使用

レプリケーションを使用して、単一のサーバーが失われることでディレクトリーサービスが使用できなくならないようにします。少なくとも、ローカルディレクトリーツリーを 1 つ以上のバックアップサーバーにレプリケートします。
一部のディレクトリーアーキテクトは、データの信頼性を最大限にするには、情報を物理的な場所ごとに 3 回複製する必要があると主張しています。フォールトトレランスにレプリケーションを使用する範囲は、環境と個人の好みによって異なりますが、ディレクトリーサービスで使用されるハードウェアとネットワークの品質に基づいてこれを決定します。信頼性の低いハードウェアには、より多くのバックアップサーバーが必要です。
注記
通常のデータバックアップポリシーの代わりにレプリケーション を使用しないでください。ディレクトリーデータのバックアップに関する詳細は『Red Hat Directory Server Administration Guide』を参照してください。
すべてのディレクトリークライアントの書き込みフェイルオーバーを保証するには、マルチサプライヤーレプリケーションシナリオを使用します。read-failover で十分な場合は、単一サプライヤーレプリケーションを使用します。
LDAP クライアントアプリケーションは通常、1 つの LDAP サーバーのみを検索するように設定できます。異なる DNS ホスト名にある LDAP サーバーを介してローテーションするカスタムクライアントアプリケーションがなければ、LDAP クライアントアプリケーションは、Directory Server の単一の DNS ホスト名のみを検索するように設定できます。したがって、DNS のラウンドロビンまたはネットワークソートを使用して、バックアップ Directory Server へのフェイルオーバーを提供する必要があるでしょう。DNS のラウンドロビンまたはネットワークソートの設定および使用に関する詳細は、DNS のドキュメントを参照してください。

7.3.7. ローカル可用性でのレプリケーションの使用

ローカル可用性をレプリケートする必要性は、ネットワークの質とサイトのアクティビティーによって決まります。さらに、ディレクトリーサービスに含まれるデータの性質と、そのデータが一時的に利用できなくなった場合の企業への影響を慎重に検討してください。データがミッションクリティカルであるほど、ネットワーク接続の不良によるシステムの停止に対する耐性が低くなります。
以下の理由により、ローカル可用性のレプリケーションを使用します。
  • データのローカルメインコピーを保持する。
    これは、特定の国の社員のみに関連するディレクトリー情報を維持する必要がある大規模な多国籍企業にとって重要なストラテジーです。データのローカルメインコピーを保持することは、データを部門または組織レベルで管理する企業においても重要です。
  • 信頼できないネットワーク接続または断続的に利用可能なネットワーク接続への対策。
    国際ネットワークで頻繁に発生しますが、信頼性の低い WAN がある場合は、ネットワーク接続が断続的になる可能性があります。
  • ディレクトリーサービスのパフォーマンスを大幅に低下させる可能性のある、定期的で非常に重いネットワーク負荷を補正。
    ネットワークが古い企業でもパフォーマンスに影響が出る可能性があり、通常の営業時間中にこのような状態が発生する可能性があります。

7.3.8. ロードバランシングでのレプリケーションの使用

レプリケーションは、複数の方法で Directory Server の負荷のバランスを取ることができます。
  • 複数のサーバーにユーザーの検索アクティビティーを分散させます。
  • サーバーを読み取り専用にします (書き込みはサプライヤーサーバーでのみ行われます)。
  • メールサーバーのアクティビティーのサポートなど、特定のタスク専用の特別なサーバーを提供します。
ネットワークのワークロードの分散は、ディレクトリーデータのレプリケーションにより実行される重要な機能です。可能な限り、適度に高速で信頼性の高いネットワーク接続を使用してアクセスできるサーバーにデータを移動します。最も重要な考慮事項は、サーバーとディレクトリーユーザー間のネットワーク接続の速度と信頼性です。
通常、ディレクトリーエントリーのサイズは平均で約 1 キロバイト (KB) です。したがって、ディレクトリールックアップを行うたびにネットワークの負荷に約 1KB が追加されます。ディレクトリーユーザーが 1 日に 10 回のディレクトリールックアップを実行すると、ディレクトリーユーザーごとに 1 日あたり約 10KB のネットワーク負荷が追加されます。サイトの WAN の速度が遅い、負荷が高い、または信頼性が低い場合は、ディレクトリーツリーをローカルサーバーにレプリケートすることを検討してください。
また、ローカルで利用可能なデータの利点が、レプリケーションによって増加するネットワーク負荷のコストに見合うかどうかも検討してください。たとえば、ディレクトリーツリー全体がリモートサイトに複製されると、ユーザーのディレクトリールックアップによって発生するトラフィックよりも大きな負担がネットワークにかかる可能性があります。これは、ディレクトリーツリーが頻繁に変更されている場合に特に該当しますが、リモートサイトで 1 日に数回のディレクトリールックアップを実行するユーザーはごくわずかです。
表7.1「ネットワークにおけるレプリケーションおよびリモートルックアップの影響」 は 100 万エントリーのディレクトリーを複製するおおよそのコストを比較しています。これらのエントリーの 10% は毎日変更され、社員が 100 人の小さなリモートサイトで 1 日あたり 10 回の検索を実行するコストと比較します。いずれの場合も、ディレクトリーエントリーの平均サイズは 1KB であると想定されています。

表7.1 ネットワークにおけるレプリケーションおよびリモートルックアップの影響

負荷タイプ オブジェクト[a] アクセス/日[b] 平均エントリーサイズ 負荷
レプリケーション 100 万 100,000 1KB 100Mb/日
リモートルックアップ 100 1,000 1KB 1Mb/日
[a] レプリケーションの場合、オブジェクト はデータベースのエントリー数を参照します。リモートルックアップの場合、データベースにアクセスするユーザーの数を参照します。
[b] レプリケーションの場合、Accesses/Day は、レプリケートする必要があるデータベースの変更率を 10% としています。リモートルックアップの場合、各リモートユーザーの 1 日あたり 10 ルックアップに基づきます。
レプリケーションによって引き起こされる負荷と通常のディレクトリーの使用によって引き起こされる負荷の違いを考えると、ネットワークの負荷分散の目的でレプリケーションを使用することは適切でない場合があります。一方、ローカルで利用可能なディレクトリーデータの利点は、ネットワークの負荷に関する考慮事項をはるかに上回ります。
ローカルサイトでデータを利用できるようにすることと、ネットワークを過負荷にすることの適切な妥協点は、スケジュールされたレプリケーションを使用することです。データの一貫性とレプリケーションスケジュールの詳細は、「データの整合性」 を参照してください。

7.3.8.1. ネットワーク負荷分散の例

この例では、ニューヨークとロサンゼルスに事務所を持ち、各事務所には管理する特定のサブツリーがあります。

図7.9 リモートオフィスでのエンタープライズサブツリーの管理

リモートオフィスでのエンタープライズサブツリーの管理
各オフィスには高速ネットワークがありますが、2 つの都市間の接続は不安定です。ネットワークの負荷のバランスを取るには、以下を行います。
  1. ローカルで管理されているデータのサプライヤーサーバーとして、各オフィスで 1 台ずつサーバーを選択します。
  2. ローカルに管理されているデータを、そのサーバーからリモートオフィスの対応するサプライヤーサーバーに複製します。
  3. 各サプライヤーサーバーのディレクトリーツリー (リモートオフィスから提供されるデータを含む) を少なくとも 1 つのローカルの Directory Server に複製して、ディレクトリーデータの可用性を確保します。ローカルで管理される接尾辞にマルチサプライヤーレプリケーションを使用し、リモートサーバーからデータのメインコピーを受け取る接尾辞にはカスケードレプリケーションを使用します。

7.3.8.2. パフォーマンス向上のための負荷分散の例

企業には以下の特性があるとします。
  • 100 万人のユーザーをサポートする 150 万エントリーの Directory Server を使用しています。
  • 各ユーザーは、1 日あたり 10 個のディレクトリールックアップを実行します。
  • 1 日あたり 2,500 万通のメールを処理するメッセージングサーバーを使用します。
  • メッセージングサーバーは、処理するメールごとに 5 つのディレクトリールックアップを行います。
これは、ユーザーの 1 日あたり 1,000 万回のディレクトリールックアップと、メールの 1 日あたり 1.25 億回のディレクトリールックアップ (合計 1 日あたり 1.35 億 ディレクトリールックアップ) に相当します。
たとえば、1 日の営業時間が 8 時間で、ユーザーが 4 つのタイムゾーンに分散している場合、4 つのタイムゾーンでの営業日 (またはピーク時の使用時間) は 12 時間になります。したがって、サービスは 1 日 12 時間で 1.35 億回のディレクトリールックアップに対応する必要があります。これは、1 秒間に 3,125 回のルックアップ (135,000,000 / (60*60*12)) に相当します。

表7.2 Directory Server の読み込みの計算

アクセスタイプ タイプ数 1 日あたりのアクセス数 合計アクセス数
ユーザー検索 100 万 10 1,000 万
メールルックアップ 2,500 万 5 1.25 億
アクセスの合計 1.35 億
合計 1.35 億 (3,125/秒)
Directory Server を実行するハードウェアが 1 秒あたり 50 0 回の読み取りをサポートする場合、この負荷をサポートするには、少なくとも 6 つまたは 7 つの Directory Server を使用する必要があります。ディレクトリーユーザーが 100 万人いる企業の場合は、ローカルでの可用性を確保するために Directory Server を追加します。
レプリケーションにはいくつかの方法があります。
  • すべての書き込みトラフィックを処理するために、1 つの都市のマルチサプライヤー設定に 2 つの Directory Server を配置します。
    この設定は、すべてのディレクトリーデータに単一の制御ポイントがあることを前提としています。
  • これらのサプライヤーサーバーを使用して、1 つ以上のハブサプライヤーを複製します。
    ディレクトリーサービスによって処理される読み取り、検索、および比較の要求は、コンシューマーサーバーを対象にする必要があります。これにより、サプライヤーサーバーは書き込み要求を処理できるようになります。
  • ハブサプライヤーを使用して、企業全体のローカルサイトに複製します。
    ローカルサイトに複製することで、サーバーおよび WAN のワークロードのバランスを取ることや、ディレクトリーデータを高可用性を確保するのに役立ちます。
  • 各サイトで、少なくとも読み取り操作のために、最低 1 回複製して高可用性を確保します。
  • DNS ソートを使用して、ローカルユーザーがディレクトリールックアップに使用できるローカルディレクトリーサーバーを常に見つけられるようにします。

7.3.8.3. 小規模サイトのレプリケーションストラテジーの例

Example Corp. には以下の特徴があります。
  • 企業全体が 1 つのビルに入っています。
  • ビルには、非常に高速 (毎秒 100 Mb) で、使用量の少ないネットワークがあります。
  • ネットワークは非常に安定しており、サーバーハードウェアと OS プラットフォームは信頼できます。
  • 単一のサーバーでサイトの負荷を簡単に処理できます。
この場合、Example Corp. は、プライマリーサーバーがメンテナンスまたはハードウェアのアップグレードでシャットダウンした場合に、少なくとも 1 回複製することを決定します。また、Directory Server の 1 つが利用できなくなった場合に、LDAP 接続のパフォーマンスを向上するために DNS ラウンドロビンを設定します。

7.3.8.4. 大規模サイトのレプリケーションストラテジーの例

Example Corp. が成長するにつれ、いくつかの変更を加えて以前の特性 (「小規模サイトのレプリケーションストラテジーの例」) を保持します。
  • 会社は 2 つビルに分かれています。
  • ビル間の接続は遅く、これらの接続は通常の営業時間中は非常に混雑しています。
ネットワークの変更が必要になると、Example Corp. の管理者はレプリケーションストラテジーを調整します。
  • 2 つのビルのいずれかで、ディレクトリーデータのメインコピーを格納する単一のサーバーを選択します。
    このサーバーは、ディレクトリーデータのメインコピーを担当するユーザーが最も多いビルに配置する必要があります。このビルを Buidling A とします。
  • ディレクトリーデータの高可用性のために、Buidling A 内で最低 1 回複製を行います。
    マルチサプライヤーレプリケーション設定を使用して、書き込みフェイルオーバーを確実に実行します。
  • 別のビル (Building B) に 2 つのレプリカを作成します。
  • サプライヤーサーバーとコンシューマーサーバーの間で厳密な一貫性を保つ必要がない場合は、オフピーク時にのみ実行されるようにレプリケーションをスケジュールします。