検索

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

download PDF

提供したいサービスに基づいてレプリケーションストラテジーを決定できます。実装できる一般的なレプリケーションストラテジーは次のとおりです。

  • 高可用性が主な懸念である場合は、1 つのサイトに複数の Directory Server を持つデータセンターを作成します。単一サプライヤーレプリケーションは、read-failover を提供しますが、マルチサプライヤーレプリケーションは write-failover を提供します。

    詳細は、高可用性のためのレプリケーションの使用 を参照してください。

  • ローカル可用性が主要な懸念事項である場合は、レプリケーションを使用して、世界中の現地事務所の Directory Server にデータを地理的に分散します。すべての情報のメインコピーを会社の本社などの 1 つのロケーションに保持することも、各ローカルサイトがそれぞれに関連するディレクトリー部分を管理することもできます。

    詳細は、ローカル可用性のためのレプリケーションの使用 を参照してください。

  • Directory Server が管理する要求の負荷を分散し、ネットワークの輻輳を回避するには、負荷分散用のレプリケーション設定を使用します。

    詳細は、負荷分散のためのレプリケーションの使用 を参照してください。

  • 会社のさまざまなロケーションやセクションで複数のコンシューマーを使用する場合、または一部のサーバーが安全でない場合は、部分 レプリケーションを使用して機密情報やほとんど変更されない情報を除外し、機密情報を危険にさらすことなくデータの整合性を維持します。

    詳細は、部分レプリケーション を参照してください。

  • ネットワークが地理的に広い地域に広がっている場合、複数のサイトに複数の Directory Server があり、ローカルデータサプライヤーがマルチサプライヤーレプリケーションによって接続されている場合、ワイドエリアネットワークのレプリケーション設定を使用します。

    詳細は、ワイドエリアネットワーク全体でのレプリケーション を参照してください。

レプリケーションストラテジーを確認するには、ネットワーク、ユーザー、アプリケーション、ディレクトリーサービスの使用方法などの調査から始めます。

6.3.1. レプリケーション調査の実施

レプリケーションストラテジーを定義するために、ネットワークの品質と使用状況に関する情報を収集します。

  • さまざまな建物やリモートサイトを接続する LAN と WAN の品質、および使用可能な帯域幅の量。
  • ユーザーの物理的なロケーション、各サイトのユーザー数、およびディレクトリーサービスをどのように使用する予定かを理解するための使用パターン。

    通常、人事データベースや財務情報を管理するサイトでは、電話帳の目的でのみディレクトリーを使用するエンジニアリングスタッフを含むサイトよりも、ディレクトリーにかかる負荷が大きくなります。

  • ディレクトリーサービスにアクセスするアプリケーションの数と、読み取り検索、および 比較 操作と 書き込み 操作の相対的な割合。

    メッセージングサーバーがディレクトリーを使用する場合は、処理する電子メールメッセージごと実行する操作の数を調べます。ディレクトリーを使用するその他の製品としては、通常、認証アプリケーションやメタディレクトリーアプリケーションなどの製品があります。アプリケーションごとに、ディレクトリーで実行される操作の種類と頻度を決定します。

  • ディレクトリーに保存されたエントリーの数およびサイズ。

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

レプリケーションにはリソースが必要です。レプリケーションストラテジーを定義する際に、以下のリソース要件を検討してください。

ディスク使用量
サプライヤーサーバーでは、Directory Server は更新操作ごとに changelog を書き込みます。したがって、多くの更新操作を受信するサプライヤーサーバーではディスク使用量が高くなります。
サーバースレッド
各レプリカ合意は専用のスレッドを作成し、CPU 負荷はレプリケーションスループットに依存します。
ファイル記述子
サーバーは、changelog に 1 つのファイル記述子を使用し、レプリケーション契約ごとに 1 つのファイル記述子を使用します。

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

マルチサプライヤートポロジーでは、サプライヤーは、ディレクトリー編集の changelog、更新エントリーの状態情報、削除されたエントリーの tombstone エントリーなど、レプリケーションに必要な追加のログを保持します。これらのログファイルは非常に大きくなる可能性があるため、ディスク領域の不要な使用を避けるために、これらのファイルを定期的にクリーンアップする必要があります。

各サーバーでは、次の属性を使用して、レプリケートされた環境でのレプリケーションログのメンテナンスを設定できます。

  • nsslapd-changelogmaxage 属性は、changelog のエントリーの最大有効期間を設定します。エントリーが最大経過時間値よりも古くなると、Directory Server はそのエントリーを削除します。エントリーの最大有効期間を設定すると、changelog が無制限に大きくなることを阻止できます。
  • nsslapd-changelogmaxentries 属性は、changelog に含めることができるエントリーの最大数を設定します。nsslapd-changelogmaxentries の値は、ディレクトリー情報の完全なセットを格納するのに十分な大きさである必要があることに注意してください。そうしないと、マルチサプライヤーのレプリケーションが機能する際に問題が発生する可能性があります。
  • nsDS5ReplicaPurgeDelay は、changelog の tombstone (削除) エントリーと状態情報の最大有効期間を設定します。tombstone 情報または状態情報のエントリーがその期間を過ぎると、Directory Server はそのエントリーを削除します。nsDS5ReplicaPurgeDelay 値は、tombstone および状態情報エントリーにのみ適用されますが、nsslapd-changelogmaxage は、ディレクトリーの変更を含む、changelog のすべてのエントリーに適用されます。
  • nsDS5ReplicaTombstonePurgeInterval 属性は、changelog から tombstone と状態エントリーを消去するためにサーバーがパージ操作を実行する頻度を設定します。最大経過時間が、最も長いレプリケーション更新スケジュールよりも長いことを確認します。そうしないと、レプリカの更新時にマルチサプライヤーレプリケーションで問題が発生する可能性があります。

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

単一のサーバーに障害が発生した場合にディレクトリーが使用できなくなるのを防ぐには、レプリケーションを使用します。少なくとも、ローカルディレクトリーツリーを 1 つ以上のバックアップサーバーにレプリケートします。フォールトトレランス用にどのくらいの頻度でレプリケートするかは、要件によって異なります。ただし、この決定は、ディレクトリーで使用されるハードウェアとネットワークの品質に基づいて行ってください。信頼性の低いハードウェアには、より多くのバックアップサーバーが必要です。

重要

レプリケーションとバックアップの目的が異なるため、通常のデータバックアップポリシーの代わりにレプリケーションを使用しないでください。ディレクトリーデータのバックアップに関する詳細は、Red Hat Directory Server のバックアップと復元 を参照してください。

次のストラテジーを選択すると、ディレクトリーが使用できなくなるのを阻止できます。

LDAP クライアントアプリケーションは通常、1 つの LDAP サーバーのみを検索するように設定されます。異なる DNS ホスト名にある LDAP サーバーをローテーションするカスタムクライアントアプリケーションがない場合は、LDAP クライアントアプリケーションは、Directory Server の単一の DNS ホスト名のみを参照するように設定できます。したがって、バックアップ Directory Server へのフェイルオーバーを提供するには、DNS ラウンドロビンまたはネットワークソートのいずれかを使用することを推奨します。

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

ネットワークの品質やデータがミッションクリティカルであるかどうかに応じて、ローカル可用性のためにレプリケーションを使用することを推奨します。

以下の理由により、ローカル可用性のレプリケーションを使用します。

  • データのローカルメインコピーが必要です。

    大規模な多国籍企業では、特定の国の従業員にのみ関係するディレクトリー情報を維持する必要がある場合があります。さらに、社内ポリシーにより部門レベルまたは組織レベルでデータを管理するよう指示されている企業にとって、データのローカルメインコピーを保持することは重要です。

  • 信頼できないネットワーク接続、または断続的にしか利用できないネットワーク接続があります。

    国際ネットワークには信頼性の低い WAN があり、ネットワーク接続が断続的になります。

  • 定期的に非常に大きなネットワーク負荷が発生し、Directory Server のパフォーマンスに影響を及ぼします。

    老朽化したネットワークを持つ企業では、通常の営業時間中にネットワーク負荷が大きくなる可能性があります。

  • ネットワーク負荷とサプライヤーの作業負荷を軽減したいと考えています。

    ネットワークの信頼性が高く、利用可能であっても、ネットワークコストを削減することを推奨します。

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

ディレクトリーデータをレプリケートする主な理由の 1 つは、ネットワークのワークロードのバランスを取り、ディレクトリーのパフォーマンスを向上させることです。

ディレクトリーエントリーのサイズは通常 1 KB なので、ディレクトリー検索ごとにネットワーク負荷が約 1 KB 増加します。ディレクトリーユーザーが 1 日に 10 回のディレクトリー検索を実行する場合、ディレクトリーユーザー 1 人あたりのネットワーク負荷の増加は 1 日あたり約 10 KB になります。WAN の速度が遅い、負荷が高い、または信頼性が低い場合は、ディレクトリーツリーをローカルサーバーにレプリケートすることを推奨します。

ただし、ローカルで利用可能なデータが、レプリケーションによって増加するネットワーク負荷のコストに見合う価値があるかどうかを判断します。ディレクトリーツリー全体をリモートサイトにレプリケートすると、ユーザーの検索によって発生するトラフィックに比べて、ネットワークにかかる負荷が大きくなる可能性があります。これは、ディレクトリーが頻繁に変更されるものの、リモートサイトで 1 日に数回のディレクトリー検索を実行するユーザーが少数である場合に特に当てはまります。

次の表は、100,000 件のエントリーが毎日変更される 100 万件のエントリーを持つディレクトリーをレプリケートした場合の負荷の影響と、1 日に 10 回ずつ検索を実行する 100 人の従業員がいる小規模なリモートサイトがある場合の負荷の影響を比較したものです。

表6.1 レプリケーションとリモート検索がネットワークに与える影響
負荷タイプアクセス数/日平均エントリーサイズLoad

レプリケーション

100,000

1KB

100Mb/日

リモート検索

1,000

1KB

1Mb/日

ネットワークに過負荷をかけずにローカルサイトでデータを利用できるようにする妥協策は、スケジュールされたレプリケーションを使用することです。データの一貫性とレプリケーションスケジュールの詳細は、データの一貫性 を参照してください。

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

この例では、ニューヨーク (NY) とロサンゼルス (LA) にオフィスがあり、各オフィスが個別のサブツリーを管理している企業を説明します。

次の図は、企業がサブツリーを管理する方法を示しています。

図6.6 エンタープライズ NY および LA サブツリー

dg レプリケーションの設計 8

各オフィスには高速ネットワークがありますが、2 つの都市間の接続は不安定です。ネットワーク負荷を分散するには、次のストラテジーを使用します。

  • ローカルで管理されているデータのサプライヤーサーバーとして、各オフィスで 1 台ずつサーバーを選択します。

    ローカルに管理されているデータを、そのサプライヤーからリモートオフィスの対応するサプライヤーサーバーにレプリケートします。各ロケーションにデータのメインコピーがある場合、ユーザーは信頼性の低い接続を介して更新および検索操作を実行しません。その結果、パフォーマンスが最適化されます。

  • 各サプライヤーサーバーのディレクトリーツリー (リモートオフィスから提供されるデータを含む) を少なくとも 1 つのローカルの Directory Server にレプリケートして、ディレクトリーデータの可用性を確保します。
  • ローカルデータの検索専用のコンシューマーの数を増やして、各ロケーションでカスケードレプリケーションを設定し、さらなる負荷分散を実現します。

    NY オフィスでは、LA 固有の検索よりも NY 固有の検索が多く生成されます。この例では、NY オフィスに 3 つの NY データコンシューマーと 1 つの LA コンシューマーが存在します。LA オフィスには、3 つの LA データコンシューマーと 1 つの NY データコンシューマーがあります。

図6.7 企業向け負荷分散の例

dg レプリケーションの設計 9

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

この例では、次の特性を持つ企業を説明します。

  • ディレクトリーには 1,000,000 人のユーザーをサポートする 1,500,000 件のエントリーが含まれています。
  • 各ユーザーは 1 日に 10 回のディレクトリー検索を実行します。
  • メッセージングサーバーは 1 日あたり 25,000,000 件のメールメッセージを処理し、メールメッセージごとに 5 回のディレクトリー検索を実行します。
  • ユーザーは 4 つのタイムゾーンに分散しています。

これは合計で 1 日あたり 135,000,000 件のディレクトリー検索に相当します。

1,000,000 ユーザー x 10 回の検索 = 1 日あたり 10,000,000 回のユーザー検索

25,000,000 通のメール x 5 回の検索 = 1 日あたり 125,000,000 件のメール検索

1 日あたりの全検索数 10,000,000 + 125,000,000 = 135,000,000

1 日の営業時間が 8 時間で、ユーザーが 4 つのタイムゾーンに分散している場合、4 つのタイムゾーンでのピーク使用時間は 12 時間に達します。したがって、Directory Server は 1 日 12 時間で 135,000,000 件のディレクトリー検索をサポートする必要があります。これは、1 秒あたり 3,125 回の検索 (135,000,000/(60*60*12)) に相当します。

Directory Server を実行するハードウェアが 1 秒あたり 500 回の読み取りをサポートする場合、この負荷をサポートするには少なくとも 6 台または 7 台の Directory Server を使用する必要があります。ディレクトリーユーザーが 100 万人いる企業の場合は、ローカルでの可用性を確保するために Directory Server を追加します。

このようなシナリオでは、次のレプリケーションストラテジーを使用できます。

  • すべての書き込みトラフィックを処理するために、1 つの都市のマルチサプライヤー設定に 2 つの Directory Server を配置します。

    この設定では、すべてのディレクトリーデータを単一の制御ポイントで管理することを前提としています。

  • サプライヤーサーバーを使用して、1 つ以上のハブにレプリケートします。

    読み取り検索比較 の要求をコンシューマーに向けることで、サプライヤーは 書き込み 要求のみを処理できるようになります。ハブの詳細は、カスケードレプリケーション を参照してください。

  • ハブを使用して、企業全体のローカルサイトにレプリケートします。

    ローカルサイトにレプリケートすると、サーバーとネットワークの負荷が分散され、ディレクトリーデータの高可用性が確保されます。

  • 各サイトで、少なくとも 読み取り 操作用に、最低 1 回レプリケートして高可用性を確保します。

    DNS ソートを使用すると、ローカルユーザーがディレクトリー検索に使用できるローカル Directory Server を常に見つけられるようになります。

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

例に挙げる企業には以下の特性があります。

  • 企業全体が 1 つのビルに入っています。
  • ビルには、非常に高速 (毎秒 100 Mb) で、使用量の少ないネットワークがあります。
  • ネットワークは非常に安定しており、サーバーハードウェアと OS プラットフォームは信頼できます。
  • 単一のサーバーで負荷を簡単に処理できます。

このような状況では、メンテナンスやハードウェアのアップグレードのためにプライマリーサーバーをシャットダウンするときに可用性を確保するために、少なくとも 1 回はレプリケートする必要があります。また、Directory Server の 1 つが使用できなくなった場合に LDAP 接続のパフォーマンスを向上させるために、DNS ラウンドロビンをセットアップします。

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

小規模サイトのレプリケーションストラテジーの例 の例にある企業は、より大きな企業に成長し、現在では次の特性を備えています。

  • この会社は、Building A と Building B という 2 つの別々の建物に入っています。
  • 通常の営業時間中は、建物間の接続が遅く、非常に混雑します。
  • 各建物には非常に高速 (100 Mb/秒) で使用頻度の低いネットワークがあります。
  • 各建物内のネットワークは非常に安定しており、サーバーのハードウェアと OS プラットフォームは信頼性があります。
  • 1 台のサーバーで 1 つの建物内の負荷を簡単に処理できます。

このような条件では、レプリケーションストラテジーには次の手順が含まれます。

  • ディレクトリーデータのメインコピーを格納するために、2 つの建物のうちの 1 つにある単一のサーバーを選択します。

    ディレクトリーデータのメインコピーを管理する担当者が最も多くいる建物 (たとえば、Building A) にサーバーを配置します。

  • ディレクトリーデータの高可用性のために、Building A 内で最低 1 回レプリケートします。

    マルチサプライヤーレプリケーション 設定を使用して、書き込みフェイルオーバーを確実に実行します。

  • 2 つ目の Building B に 2 つのレプリカを作成します。
  • サプライヤーサーバーとコンシューマーサーバーの間で厳密な一貫性が必要ない場合は、レプリケーションがオフピーク時間帯にのみ実行されるようにスケジュールします。

6.3.7. 部分レプリケーション

部分レプリケーションを使用すると、Directory Server がサプライヤーからコンシューマーまたは別のサプライヤーにレプリケートしない属性のセットを選択できます。したがって、データベースに含まれるすべての情報をレプリケートしなくても、データベースをレプリケートできます。

部分レプリケーションは、レプリカ合意ごとに有効になり、設定されます。Directory Server は、属性の除外をすべてのエントリーに均等に適用します。除外された属性は、コンシューマーに対して常に値を持ちません。したがって、検索フィルターでこれらの属性が明示的に指定されている場合でも、コンシューマーサーバーに対して検索を実行するクライアントには除外された属性は表示されません。

次の状況では部分レプリケーションを使用します。

  • コンシューマーサーバーは低速ネットワークを使用して接続されています。ほとんど変更されない属性や jpegPhoto などの大きな属性を除外すると、ネットワークトラフィックが減少します。
  • コンシューマーサーバーは、パブリックインターネットなどの信頼できないネットワーク上に配置されます。電話番号などの機密属性を除外すると、サーバーのアクセス制御手段が無効化されたり、マシンが攻撃者によって悪用されたりした場合でも、機密属性にアクセスできないようにする追加の保護レベルが提供されます。

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

ワイドエリアネットワーク (WAN) は通常、ローカルエリアネットワークよりも遅延や帯域幅遅延積が大きく、速度が遅くなります。Directory Server は、サプライヤーとコンシューマーがワイドエリアネットワークを使用して接続されている場合に効率的なレプリケーションをサポートします。

以前は、Directory Server が使用していたレプリケーションプロトコルは、サプライヤーが更新操作を 1 つだけ送信し、コンシューマーからの応答を待機していたため、遅延の影響を受けやすかったです。これにより、スループットが低下し、レイテンシーが長くなりました。

現在、サプライヤーは応答を待たずに多くの更新とエントリーをコンシューマーに送信しており、レプリケーションのスループットはローカルエリアネットワークのスループットと類似します。

WAN を使用する場合は、次のパフォーマンスとセキュリティーの問題を考慮してください。

  • インターネットなどのパブリックネットワーク経由で実行されるレプリケーションを保護するには、Transport Layer Security (TLS) プロトコルを使用します。
  • ネットワークには T1 以上のインターネット接続を使用してください。
  • WAN 経由のレプリケーション合意を作成するときは、サーバー間の継続的な同期を避けてください。レプリケーショントラフィックは帯域幅を大量に消費し、ネットワークとインターネット接続全体の速度を低下させる可能性があります。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.