複数のデータセンターにわたるレプリケーションの使用

レプリケーションの 1 つの目標は、LDAP サービスの地理的な分散を可能にすることです。レプリケーションを使用すると、複数のサーバー上や、複数のデータセンターにわたって情報の同一のコピーを保持することができます。レプリケーションの概念については、このガイドの 第 10 章「拡張配備の設計」でその概要が、さらに『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 4 章「Directory Server Replication」でその詳細が説明されています。この章では、グローバル配備で使用されるレプリケーション機能に焦点を絞ります。

WAN を介したマルチマスターレプリケーションの使用

Directory Server では、WAN を介したマルチマスターレプリケーションをサポートしています。この機能により、マルチマスターレプリケーション設定を地理的に離れた場所にある複数のデータセンターに国際的に配備できます。

一般に、「初期レプリケーション要件の評価」で計算されるホストの数が 16 より小さいか、またはそれより大幅に大きくはない場合、トポロジを、完全に接続されたトポロジ内にマスターサーバーのみが含まれる、つまり、すべてのマスターがトポロジ内のほかのすべてのマスターにレプリケートする状態にしてください。WAN 構成を介したマルチマスターレプリケーションでは、WAN で分離されたすべてのDirectory Server インスタンスが、Directory Server 5.2 より前のバージョンを実行していないようにしてください。4 つを超えるマスターを含むマルチマスタートポロジの場合は、Directory Server 6.x が必要です。

レプリケーションプロトコルでは、完全な非同期サポートのほか、ウィンドウ、グループ化、および圧縮のメカニズムが提供されます。これらの機能によって、WAN を介したマルチマスターレプリケーションが実行可能になります。レプリケーションのデータ転送速度は、帯域幅の点から見て、使用可能な物理媒体で可能になる速度を常に下回ります。レプリカ間の更新の量が、物理的に、使用可能な帯域幅に収まりきらない場合は、チューニングを行っても、更新の重い負荷の下でのレプリカの発散を避けることはできません。レプリケーションの遅延や更新のパフォーマンスは、変更の頻度、エントリサイズ、サーバーハードウェア、平均待ち時間、平均帯域幅など (ただし、これらには限定されない) を含む多くの要因に依存します。

レプリケーションメカニズムの内部のパラメータは、WAN に対してデフォルトで最適化されます。ただし、上で述べた要因のためにレプリケーションの速度低下が発生している場合は、ウィンドウサイズやグループサイズのパラメータを実験的に調整することをお勧めします。また、ネットワークのピーク時間帯を避けるようにレプリケーションをスケジュールして、全体的なネットワーク使用率を向上させることができる可能性もあります。最後に、Directory Server は、帯域幅使用率を最適化するためのレプリケーションデータの圧縮をサポートしています。

WAN リンクを介してデータをレプリケートする場合は、データの完全性と機密性を保証する何らかの形式のセキュリティーを確保することをお勧めします。Directory Server で使用可能なセキュリティー手段の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 2 章「Directory Server Security」を参照してください。

グループとウィンドウのメカニズム

Directory Server は、レプリケーションの流れを最適化するためのグループとウィンドウのメカニズムを提供しています。グループのメカニズムを使用すると、変更を個別にではなく、グループで送信するように指定できます。グループサイズは、1 つの更新メッセージにまとめることのできるデータ変更の最大数を表します。ネットワーク接続がレプリケーションのボトルネックになっているように見える場合は、グループサイズを増やし、レプリケーションのパフォーマンスをもう一度チェックしてください。グループサイズの設定については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「グループサイズの設定」を参照してください。

ウィンドウのメカニズムは、サプライヤが処理継続のためのコンシューマからの受信通知を待つことなく、コンシューマに特定の数の更新要求を送信するように指定します。ウィンドウサイズは、コンシューマからの即座の受信通知がなくても送信できる更新メッセージの最大数を表します。メッセージごとに受信通知を待つのではなく、多数のメッセージをすばやく連続して送信する方がより効率的です。適切なウィンドウサイズを使用することにより、レプリカがレプリケーションの更新または受信通知の到着を待つために費やす時間を削除できます。コンシューマレプリカがサプライヤから遅延している場合は、ウィンドウサイズをデフォルトより大きい値 (たとえば 100) に増やし、それ以上の調整を行う前にレプリケーションのパフォーマンスをもう一度チェックしてください。レプリケーションの更新頻度が高く、そのため更新の間隔が短い場合は、LAN で接続されているレプリカでもウィンドウサイズを大きくすると利点が得られます。ウィンドウサイズの設定については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「ウィンドウサイズの設定」を参照してください。

グループとウィンドウのメカニズムはどちらも、変更のサイズに基づいています。そのため、変更のサイズが大幅に変動する場合、これらのメカニズムを使用してレプリケーションのパフォーマンスを最適化することは実用的でない場合があります。変更のサイズが比較的均一である場合は、グループとウィンドウのメカニズムを使用して、差分更新と完全更新を最適化することができます。

レプリケーションの圧縮

グループ化とウィンドウのメカニズムに加えて、Solaris および Linux プラットフォームではレプリケーションの圧縮も設定できます。レプリケーションの圧縮は、レプリケーションの流れを効率化します。それによって、WAN を介したレプリケーションでのボトルネックの発生率が大幅に削減されます。レプリケートされるデータを圧縮すると、CPU 性能は十分だが帯域幅が狭いネットワークや、一括変更をレプリケートする場合など、特定の場合でのレプリケーションのパフォーマンスを向上させることができます。また、大きなエントリを含むリモートレプリカを初期化する場合も、レプリケーションの圧縮によって利点が得られます。広いネットワーク帯域幅が存在する LAN (ローカルエリアネットワーク) ではこのパラメータを設定しないでください。圧縮と圧縮解除の計算によってレプリケーションの速度が低下するためです。

レプリケーションメカニズムは、Zlib 圧縮ライブラリを使用します。予測されるレプリケーション使用率に対して WAN 環境で最高の結果が得られる圧縮レベルを実験的にテストし、選択してください。

レプリケーションの圧縮を設定する方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「レプリケーションの圧縮の設定」を参照してください。

部分レプリケーションの使用

グローバルなトポロジ (データセンターが各国に存在する) には、セキュリティーまたは遵守の理由から、レプリケーションの制限が必要になる場合があります。たとえば、法律上の規制で、特定の従業員情報を米国外にはコピーできないと規定されている可能性があります。または、オーストラリア内のサイトにはオーストラリアの従業員の詳細情報のみが必要になる可能性があります。

部分レプリケーション機能を使用すると、エントリ内に存在する属性のサブセットのみをレプリケートできます。属性リストは、レプリケートできる属性とレプリケートできない属性を判定するために使用されます。部分レプリケーションは、読み取り専用のコンシューマに対してのみ適用できます。

部分レプリケーションの動作の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Fractional Replication」を参照してください。部分レプリケーションを設定する方法については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「部分レプリケーション」を参照してください。

優先順位付きレプリケーションの使用

優先順位付きレプリケーションは、特定の属性に関してレプリケートされるデータのより厳密な一貫性を確保する、強いビジネス要件が存在する場合に使用できます。6.0 より前のバージョンの Directory Server の場合、更新は、受信された順序でレプリケートされていました。優先順位付きレプリケーションでは、トポロジ内のほかのサーバーにレプリケートするときに、特定の属性に対する更新を優先させるように指定できます。

優先順位付きレプリケーションには、次の利点があります。

• セキュリティーの強化。優先順位付きレプリケーションは、アカウントのロックアウトのためにデフォルトで使用されます。たとえば、ある従業員が組織を離れたために、その従業員のアカウントをロックする場合を考えてみます。その従業員が、アカウントのロックアウトがまだレプリケートされていないリモートサーバーにログインできてしまうことがないように、アカウントのロックアウトの変更は、ほかの変更がレプリケートされる前にレプリケートされます。

• 一貫性の向上。Directory Server のレプリケーションは、一貫性に関して厳密ではありません。優先順位付きレプリケーションを使用すると、組織内で重要であると見なされる特定の属性のより強力な一貫性を保証できます。

国際的な企業のレプリケーション戦略のサンプル

このシナリオでは、ある企業の 2 つの主要なデータセンターがロンドンとニューヨークに 1 つずつあり、WAN で分離されています。ここでは、通常業務時間内はネットワークが非常に混み合っていることを前提にしています。

このシナリオでは、ホストの数が 8 と計算されています。2 つのデータセンターのそれぞれに、完全に接続された 4 方向のマルチマスタートポロジが配備されています。これらの 2 つのトポロジもまた、相互に完全に接続されています。簡単のために、次の図には 2 つのデータセンター間のすべてのレプリケーションアグリーメントは示されていません。

このシナリオでのレプリケーション戦略には、次の内容が含まれます。

• ディレクトリデータのマスターコピーを、両方のデータセンターのそれぞれのサーバーで保持する。

• 配備全体にわたって高可用性と書き込みフェイルオーバーを実現するために、データセンター間にマルチマスターレプリケーショントポロジを配備する。

• 帯域幅を最適化するために、WAN リンク全体にわたるレプリケーションをスケジュールして、ピークを外れた時間帯にのみ実行されるようにする。

• パフォーマンスを向上させるために、クライアントアプリケーションをローカルサーバーに振り分ける。米国内のクライアントは、ニューヨークのデータセンター内のマスターとの間で読み取り/書き込みを行う。英国内のクライアントは、ロンドンのデータセンター内のマスターとの間で読み取り/書き込みを行う。

図 11–1 2 つのデータセンターでの負荷分散のためのマルチマスターレプリケーションの使用