第 6 章レプリケーションについての理解

ディレクトリの内容をレプリケートすると、ディレクトリの可用性が向上します。また、ロードバランスのような追加の指標が実装されている場合は、グローバルな検索パフォーマンスを向上させる上で役立ちます。レプリケーションでは書き込みの可用性を高めることはできますが、書き込みまたは更新のパフォーマンスは向上しません。

第 4 章と第 5 章では、ディレクトリツリーとディレクトリトポロジの設計について検討しました。この章では、データの物理的および地理的な場所に焦点を当て、特に、レプリケーションを使用していつでもどこでも必要なときにデータを使用できるようにする方法について考察します。

この章では、配備でのレプリケーションの使用について説明します。説明する内容は次のとおりです。

レプリケーションについて

レプリケーションとは、1 つの Directory Server から別の Directory Server にディレクトリのデータを自動的にコピーするメカニズムのことです。レプリケーションを行うと、それ自身のサフィックスに格納しているディレクトリツリーやサブツリーをサーバー間でコピーできます。ただし、設定や監視の情報サブツリーはコピーされません。

レプリケーションを行うと、可用性の高いディレクトリサービスを提供でき、データを地理的に分散することができます。具体的には、レプリケーションには次のような利点があります。

ディレクトリツリーを複数のサーバーにレプリケーションすると、ハードウェア、ソフトウェア、またはネットワークに障害が発生し、ディレクトリクライアントアプリケーションが特定の Directory Server にアクセスできない場合でも、ディレクトリを利用可能にできます。読み取りや書き込み操作を実行するために、クライアントを別のディレクトリに転送することができます。書き込みフェイルオーバーに対応するには、レプリケーション環境にデータのマスターコピーが複数必要であることに注意してください。

ディレクトリツリーを複数のサーバーにレプリケートすることで、各マシン上のアクセス負荷を軽減し、サーバーの応答時間を短縮できます。レプリケーションは、書き込みのスケーラビリティのためのソリューションではありません。配備内で書き込みのスケーラビリティを改善するには、データの分散を考慮する必要があります。

レプリケーション戦略を決定する前に、レプリケーションの動作を理解しておく必要があります。ここでは、次の点について概要を説明します。

レプリケーションの概念

レプリケーションの実装について考慮するときは、次のような基本的な質問に回答することから始めてください。

これらの事項は、Directory Server がレプリケーションをどのように実装するかを理解していないと効率的に決定できません。たとえば、レプリケートする情報を決める場合は、Directory Server が処理できる最小のレプリケーション単位を知っておく必要があります。次に、Directory Server に実装されるレプリケーションの概念について説明します。

レプリカ

レプリケーションに関与するデータベースを、レプリカと呼びます。レプリカには、3 つの種類があります。

マスターレプリカ (読み書き可能レプリカ) : ディレクトリデータのマスターコピーを格納する読み書き可能データベース。マスターレプリカは、ディレクトリクライアントからの更新要求を処理できる

コンシューマレプリカ : マスターレプリカに保持される情報のコピーを格納する読み取り専用データベース。コンシューマレプリカは、ディレクトリクライアントからの検索要求を処理できるが、更新要求はマスターレプリカを照会する

ハブレプリカ : コンシューマレプリカと同じく、読み取り専用データベース。ただし、1 つまたは複数のコンシューマレプリカを提供する Directory Server 上に格納される

Directory Server は、複数のレプリカを管理するように設定できます。各レプリカには、レプリケーションにおいて異なる役割を持たせることができます。

レプリケーションの単位

レプリケーションの最小単位はサフィックスです。レプリケーションメカニズムでは、サフィックスとデータベースが 1 対 1 で対応している必要があります。つまり、カスタム分散ロジックを使用している 2 つ以上のデータベースにまたがって分散されているサフィックス (またはネームスペース) はレプリケートできません。レプリケーション単位は、コンシューマとサプライヤの両方に適用されます。つまり、1 つのサフィックスだけを保持するコンシューマに 2 つのサフィックスをレプリケートすることはできません。また、その反対も同様です。

レプリカ ID

マスターレプリカは一意のレプリカ識別子 (ID) を必要とし、コンシューマレプリカはすべて同じレプリカ ID を持ちます。マスターのレプリカ ID は 1 ～ 65534 の間の任意の 16 ビット整数で、コンシューマレプリカのレプリカ ID はすべて 65535 です。レプリカ ID は、どのレプリカで変更が発生したかを識別し、これによってレプリケーションが正しく行われます。

サーバーが複数のレプリカ (またはサフィックス) をホスティングする場合、1 つのレプリケートされたサフィックスを持つ複数のマスターの間でレプリカ ID が一意であれば、それぞれのレプリカがすべて同じレプリカ ID を持つことができます。マスター上のサフィックスすべてに同じレプリカ ID を使用することで、サフィックスとは無関係に、1 つのマスターを 1 つのレプリカ ID のみに関連付けることができます。

サプライヤとコンシューマ

別のサーバーにレプリケートされる Directory Server をサプライヤと呼びます。別のサーバーによって更新される Directory Server をコンシューマと呼びます。サプライヤは、特別に設計された LDAP v3 拡張処理により、コンシューマ上のすべての更新を再現します。このためサプライヤは、パフォーマンスの面ではコンシューマに対する要件の多いクライアントアプリケーションに似ています。

サーバーは、場合によってはサプライヤとコンシューマの両方の機能を持ちます。これは、次の場合に当てはまります。

サーバーがハブレプリカを含む場合。つまり、サプライヤから更新を受け取り、変更内容をコンシューマにレプリケートする場合。詳細については、「カスケード型レプリケーション」を参照

マルチマスターレプリケーションで、一方のサーバーが他方のサーバーのサプライヤおよびコンシューマとして動作する 2 つの Directory Server がマスターレプリカを保持する場合。詳細については、「マルチマスターレプリケーション」を参照

サーバーがマスターレプリカとコンシューマレプリカの組み合わせを管理する場合

コンシューマとしてだけ機能するサーバー (コンシューマレプリカだけを保持するサーバー) を、専用コンシューマと呼びます。

Directory Server では、レプリケーションは常にサプライヤサーバーから開始されます。コンシューマサーバーから開始されることはありません。サプライヤがコンシューマにデータをプッシュすることから、これをサプライヤ主導レプリケーションと呼びます。Directory Server の初期のバージョンでは、サプライヤからのデータの送信に関して、コンシューマ側に設定するコンシューマ主導のレプリケーションも許されていました。Directory Server 5.0 以降では、コンシューマが更新の送信をサプライヤに要求する手順に切り替えられました。

マスターレプリカでは、サーバーは次のように機能する必要があります。

ハブレプリカでは、サーバーは次のように機能する必要があります。

コンシューマレプリカでは、サーバーは次のように機能する必要があります。

コンシューマは、エントリの追加、削除、変更の要求を受け取ると、その要求はマスターレプリカを保持するサーバーにクライアント経由で送信されます。つまり、レプリケーションの流れの中で、サーバーがサプライヤとして機能します。サプライヤは要求を実行し、変更をレプリケートします。

セキュリティまたはパフォーマンス上の理由から、リフェラルではなく、エラーを返すようにコンシューマレプリカまたはハブレプリカを設定することもできます。詳細は、「リフェラル」を参照してください。

レプリカのオンライン昇格とオンライン降格

Directory Server 5.2 では、レプリカのオンライン昇格とオンライン降格が可能です。レプリカの昇格と降格は、レプリケーショントポロジで、レプリカの役割を変更することを意味します。専用コンシューマをハブに変更したり、ハブをマスターに変更したりできます。マスターをハブに変更したり、ハブを専用コンシューマに変更したりすることもできます。コンシューマレプリカをマスターレプリカに昇格させるには、まず、ハブレプリカに昇格させ、それからマスターレプリカに昇格させます。オンライン降格にもこれと同じ段階的なアプローチが適用されます。詳細は、『Directory Server 管理ガイド』の第 8 章にある「レプリカの昇格と降格」を参照してください。

オンライン昇格および降格によって柔軟性が向上するだけでなく、フェイルオーバー機能も向上します。たとえば、ロードバランスとフェイルオーバーのために 2 つのハブが設定された双方向のマルチマスターのレプリケーション環境を例に考えてみます。いずれかのマスターがオフラインになった場合は、いずれかのハブを昇格させるだけで読み取り、書き込みの最適な可用性を維持できます。マスターレプリカがオンラインに復帰したときは、ハブレプリカに降格させるだけで元のトポロジを回復できます。



注	ハブがコンシューマに降格されると、レプリカは変更を伝達できなくなり、コンシューマとして更新履歴ログを持たなくなります。このため、ハブをコンシューマに降格する前に、そのハブが他のサーバーと同期していることを確認する必要があります。これを確認するには、レプリケーション監視ツール insync を使用します。このツールについては、「レプリケーションの監視」を参照してください。

リフェラル

コンシューマは、変更要求を受け取っても、マスターレプリカを保持するサーバーにその変更要求を転送しません。代わりに、クライアントからの変更要求を正しく実行できる可能性のあるマスターの URL リストを返します。このような URL がリフェラルです。

レプリケーションのメカニズムでは、レプリケーショントポロジに含まれるすべての既知のマスターのリフェラルを返すようにコンシューマを自動的に設定します。ただし、自分のリフェラルを追加し、サーバーが自動的に設定するリフェラルを上書きすることもできます。リフェラルを制御する機能は、セキュリティとパフォーマンスを次のように最適化する際に役立ちます。

リフェラルがセキュリティ保護されたポートだけを指すようにする

ロードバランスのために Directory Proxy Server を指すようにする

WAN によって分散されているサーバーの場合にのみローカルサーバーに転送するようにする

4 方向のマルチマスタートポロジのサブセットだけにリフェラルを限定する

更新履歴ログ

サプライヤとして機能するすべてのサーバー (マスターレプリカ、ハブレプリカ) は、更新履歴ログを維持します。更新履歴ログは、マスターレプリカに対して行われた変更を記述した記録です。サプライヤは、この変更をコンシューマ上で再現します。

エントリの変更、名称変更、追加、または削除が行われると、実行された LDAP 操作を記述する変更レコードが更新履歴ログに記録されます。

Directory Server の従来のバージョンでは、LDAP から更新履歴ログにアクセスできました。しかし現在では、更新履歴ログはサーバーが内部的に使用するだけで、専用データベースに格納され、LDAP 経由でアクセスできなくなりました。使用しているアプリケーションで更新履歴ログを読み取る必要がある場合は、旧バージョン形式の更新履歴ログのプラグインを使用して、下位互換性を保つことができます。旧バージョン形式の更新履歴ログのプラグインについては、『Directory Server 管理ガイド』の「旧バージョン形式の更新履歴ログプラグインの使用」を参照してください。



注	エントリが更新履歴ログから削除されると、それらのエントリはレプリケートできなくなります。このため、予定される変更の数とサイズを考慮して、更新履歴ログに十分なディスク容量を確保しておく必要があります。詳細は、『Directory Server Performance Tuning Guide』の第 5 章にある「Multi-Master Replication Change Logging」を参照してください。

レプリケーションの認証

サプライヤがコンシューマにバインドしてレプリケーション更新を送信するとき、コンシューマサーバーはサプライヤサーバーを認証します。この認証処理を実行するには、サプライヤがコンシューマにバインドする際に使用するエントリがコンシューマサーバーに格納されている必要があります。このエントリをレプリケーションマネージャエントリと呼びます。レプリケーション時に Directory Server コンソールが DN またはバインド DN を参照する場合、レプリケーションマネージャエントリの DN が参照されます。

レプリケーションマネージャあるいはその役割を果たすために作成したエントリは、次のような条件を満たしている必要があります。

レプリケーションマネージャエントリは、コンシューマサーバーに定義されたすべてのアクセス制御規則を迂回する、特別なユーザープロファイルとなります。この特別ユーザープロファイルはレプリケーションだけで有効です。

2 つのサーバー間でレプリケーションを設定する場合は、両方のサーバーでレプリケーションマネージャエントリを識別する必要があります。

コンシューマサーバーでは、コンシューマレプリカ、ハブレプリカ、またはマスターレプリカ (マルチマスターレプリケーションの場合) を設定するときに、レプリケーション更新の実行が承認されたエントリとしてこれを指定する必要があります。コンソールを使用する場合、デフォルトではレプリケーションマネージャのエントリが使用されます。

サプライヤサーバー、つまりすべてのマスターレプリカとハブレプリカでは、レプリケーションアグリーメントを設定するときに、このエントリのバインド DN を指定する必要があります。

レプリケーションマネージャのエントリは、デフォルトでは Directory Server コンソールを使ってレプリケーションを設定するときに作成されます。自分のレプリケーションマネージャのエントリを作成することもできます。

レプリケーションと一緒に SSL を使用している場合、認証を行うには次の 2 つの方法があります。

SSL サーバー認証を使用する場合は、認証するサーバーのレプリケーションマネージャエントリと、認証のためのパスワードが必要です。

SSL クライアント認証を使用する場合は、認証するサーバーに、証明書を保持するエントリが含まれている必要があります。このエントリは、レプリケーションマネージャエントリとマッピングさせる、またはマッピングさせないことができます。

レプリケーションアグリーメント

Directory Server は、2 つのサーバー間でレプリケーションがどのように行われるかを、レプリケーションアグリーメントを使用して定義します。レプリケーションアグリーメントは、1 つのサプライヤと 1 つのコンシューマの間のレプリケーションを定義します。レプリケーションアグリーメントははサプライヤ上に設定され、レプリケーションが正しく機能するようにする必要があります。既存のレプリケーションアグリーメントを有効にしたり、無効にしたりできます。これは、現在のところレプリケーションアグリーメントの必要はなくても、将来の必要性を考えて保持しておきたい場合に便利です。

レプリケーションアグリーメントは次のものを識別します。

レプリケートするサフィックス

データがレプリケートされるコンシューマサーバー

レプリケーションを実行できる時間帯

サプライヤがコンシューマへのバインドに使用する必要があるバインド DN と証明情報 (「レプリケーションの認証」を参照)

接続をセキュリティ保護する方法 (SSL、クライアント認証)

部分レプリケーションが設定されている場合は、除外するか含める属性セットへのポインタ (「部分レプリケーション」を参照)

1 つの要求にグループ化できる変更の数と、コンシューマからの受信通知が必要となるまでに送信できる要求の数を設定するグループサイズとウィンドウサイズ

この特定のアグリーメントのレプリケーションの状態に関する情報

Solaris および Linux システムでは、レプリケーション時に使用する圧縮のレベル

コンシューマの初期化

コンシューマの初期化は、すべてのデータをサプライヤからコンシューマに物理的にコピーする完全更新プロセスです。レプリケーションアグリーメントを作成したら、アグリーメントに定義されているコンシューマを初期化する必要があります。コンシューマが初期化済みの場合、サプライヤは、更新操作をコンシューマに再現、つまりレプリケートすることができます。通常の環境では、それ以後のコンシューマの初期化は必要ありません。ただし、サプライヤ上のデータをバックアップから復元した場合は、そのサプライヤに合わせてコンシューマを初期化し直さなければならない可能性があります。たとえば、復元されたサプライヤがトポロジ内でコンシューマの唯一のサプライヤの場合、コンシューマの再初期化が必要になることがあります。

コンシューマは、オンラインでもオフラインでも初期化できます。コンシューマの初期化プロセスについては、『Directory Server 管理ガイド』の第 8 章にある「レプリカの初期化」を参照してください。

マルチマスターレプリケーショントポロジでは、バックアップファイルまたは LDIF ファイルから再初期化された読み書き可能レプリカは、デフォルトではクライアントからの更新要求を拒否します。レプリカはデフォルトで永続的に読み取り専用モードになり、更新操作の要求についてはトポロジ内の他のサプライヤを参照します。この場合は、更新の受け入れをレプリカに設定する必要があります。『Directory Server 管理ガイド』の第 8 章にある「マルチマスター初期化後のマスター間の一致」を参照してください。

Directory Server には、拡張されたバイナリコピー機能が用意されています。この機能を利用することで、1 つのサーバーのバイナリバックアップファイルを使って、別のサーバー上の同じディレクトリの内容を復元することで、マスターレプリカまたはコンシューマレプリカのクローンを作成できます。特定の制限が適用されるため、この機能が実用的で時間の節約となるのは、大規模なデータベースファイルのレプリカを対象とする場合だけです。バイナリコピーの手順と機能の制限リストについては、『Directory Server 管理ガイド』の第 8 章にある「バイナリコピーによるレプリカの初期化」を参照してください。

差分更新

コンシューマが初期化済みの場合、サプライヤ上で変更が行われたときに、コンシューマにレプリケーション更新が送信されます。このような更新を、差分更新と呼びます。コンシューマは、更新が異なるレプリカ ID に由来する場合は、複数のサプライヤで同時に差分更新することができます。

データの整合性

整合性とは、レプリケートされたデータベースの内容が、任意の時点でどの程度一致しているかを示します。2 つのサーバー間でレプリケーションを設定する場合、設定の一部として更新のスケジュールが含まれます。サプライヤは、いつコンシューマを更新すべきかを判断し、レプリケーションを開始します。レプリケーションを開始できるのは、コンシューマの初期化が完了してからだけです。

Directory Server には、レプリカの同期を常に維持するオプションと、特定の時間または曜日に更新をスケジュールするオプションが用意されています。レプリカの同期を常に維持する利点は、トポロジ間でデータの整合性が保たれるという点です。ただしその場合は、頻繁な更新操作によってネットワークトラフィックが増大します。このソリューションは、次のようなときに最適です。

データの整合性が低くてもかまわない場合は、更新の頻度を選択して、ネットワークトラフィックへの影響を軽減することができます。このソリューションは、次のようなときに最適です。

ネットワーク接続の信頼性が低いか、あるいは断続的なネットワーク接続を使用している場合 (ダイヤルアップ接続を使用してレプリカの同期をとっている場合など)

ディレクトリのサービスを受けるクライアント要求が主に追加と変更の操作である場合

通信コストを削減する必要がある場合

マルチマスターレプリケーションの場合は、一般に、各マスターに格納されているデータ間に違いがある可能性があるため、各マスター上のレプリカは緩やかな整合性を保っている状態といえます。これは、レプリカの同期を維持するように選択している場合にも当てはまります。理由は次のとおりです。

一般的なレプリケーション設定

レプリケーショントポロジは、レプリケーションの更新情報をサーバー間でやり取りする方法と、更新情報を伝達するときのサーバー間の相互作用の方法を決定します。基本的なレプリケーション設定は 5 つあり、配備に合うように組み合わせることができます。

次に、上記の設定ついて説明し、配備に最も適した方法を決定するための指針を示します。

シングルマスターレプリケーション

レプリケーションの最も基本的な設定では、サプライヤが 1 つまたは複数のコンシューマにマスターレプリカを直接コピーします。この設定では、すべてのディレクトリ変更はマスターレプリカに対して行われ、コンシューマには読み取り専用のデータコピーが維持されます。

サプライヤは、レプリカに対するすべての更新を記録した更新履歴ログを管理します。サプライヤは、レプリケーションアグリーメントも定義します。

サプライヤがレプリケーションの更新を送信するためにコンシューマにバインドしたときに、コンシューマがサプライヤを認証できるように、コンシューマにはレプリケーションマネージャエントリに対応したエントリが格納されます。


注	どのようなレプリケーション設定を実装する場合でも、スキーマのレプリケーションを考慮する必要があります。詳細は、「スキーマのレプリケーション」を参照してください。

サプライヤは、レプリケーションアグリーメントに従って、すべての変更をコンシューマレプリカに伝達します。図 6-1 は、この基本例を示しています。

この例では、ou=people,dc=example,dc=com サフィックスが、クライアントから多数の検索要求と更新要求を受け取ります。負荷を分散するために、サーバー A 上にマスターのあるこのサフィックスは、サーバー B 上にあるコンシューマレプリカにレプリケートされます。

サーバー B は、クライアントからの検索要求を処理できますが、ディレクトリエントリの変更要求は処理できません。サーバー B は、クライアントにサーバー A に対するリフェラルを返すことによって、クライアントから受け取った変更要求を処理します。コンシューマにサプライヤのリフェラル情報が格納されますが、クライアントからの変更要求は、サプライヤに転送されません。代わりに、クライアントはコンシューマによって返されたリフェラルを実行します。

この例では、1 つのサーバーだけがコンシューマとして機能していますが、サプライヤは複数のコンシューマにレプリケートすることができます。1 つのサプライヤが管理できるコンシューマの総数は、ネットワークの速度と 1 日当たりのエントリの変更総数によって異なりますが、1 つのサプライヤサーバーで複数のコンシューマサーバーを管理できると想定して特に問題ありません。

マルチマスターレプリケーション

マルチマスターレプリケーション設定では、同じデータを持つマスターレプリカが複数のサーバー上に存在します。この節は、次の節で構成されています。

マルチマスターレプリケーションの基本概念

マルチマスター設定では、データは異なる場所で同時に更新することができます。各マスターはそのレプリカの更新履歴ログを格納し、各マスターで行われた更新は、他のサーバーにレプリケートされます。つまり、各マスターはサプライヤとコンシューマの役割を果たします。マルチマスター設定には、次の利点があります。

2 つのサーバー間で更新が送信された場合、更新の競合を解決する必要があります。ほとんどの場合、各変更に関連するタイムスタンプに基づいて競合は自動的に解決されます。もっとも新しい変更が優先されます。ただし、更新の競合を解決するためにユーザーの介入が必要となる場合もあります。詳細は、『Directory Server 管理ガイド』の第 8 章にある「よく発生するレプリケーションの競合の解決」を参照してください。

独立した 2 つのサーバーが同じデータのマスターコピーを保持することはできますが、1 つのレプリケーションアグリーメントにおいては、1 つのサプライヤと 1 つのコンシューマだけしか存在できません。このため、同じデータの管理責任を共有する 2 つのサプライヤ間にマルチマスター環境を構築するには、2 つのレプリケーションアグリーメント (各サプライヤで 1 つ) を作成する必要があります。図 6-2 は、この設定を示しています。

図 6-2 マルチマスターレプリケーションの設定 (2 つのマスター)

この図では、マスター A とマスター B は、それぞれが同じデータを持つマスターレプリカを保持し、レプリケーションの流れを制御する 2 つのレプリケーションアグリーメントが存在します。マスター A は、レプリケーションアグリーメント 1 の範囲ではマスターとして機能し、レプリケーションアグリーメント 2 の範囲ではコンシューマとして機能します。

Directory Server 5.2 は、マルチマスターレプリケーショントポロジで最大 4 つのマスターをサポートします。コンシューマレプリカとハブの数は、理論的には無制限です。ただし、1 つのサプライヤがレプリケートできるコンシューマの数は、サプライヤサーバーの性能によって異なります。

マルチマスターレプリケーションの機能

Directory Server 5.2 には、より効率的で柔軟なプロトコルが用意されています。このプロトコルにより、次のことが可能です。

レプリカ ID に基づいて更新をレプリケートします。レプリカ ID ベースの更新により、複数のサプライヤがコンシューマを同時に更新できるようになるため、パフォーマンスが向上します (それぞれの更新が異なるレプリカ ID に由来する必要がある)。

レプリケーションアグリーメントを有効化または無効化して、レプリケーション設定の柔軟性を向上させます。レプリケーションアグリーメントは設定できますが、無効化したままの場合、必要になったときすぐに有効化する必要があります。

広域ネットワークを介したマルチマスターレプリケーション

Directory Server 5.2 で提供された、広域ネットワーク (WAN) を介したマルチマスターレプリケーションのサポートにより、地理的に離れた国際的な配備や複数のデータセンター配備にまたがってマルチマスターレプリケーションを設定できます。Directory Server 5.2 より前のバージョンでは、マルチマスターを完全にサポートするためには、高速で待ち時間の少ない 100M バイト / 秒以上の転送スピードのネットワークに接続することが必要でした。そのため、WAN を介したマルチマスターレプリケーションの可能性は問題外でした。

Directory Server 5.2 以降では、レプリケーションプロトコルが、Solaris および Linux システム上での完全な非同期のサポート、ウィンドウとグループ化メカニズム、および圧縮のサポートを行います。これらの機能は、WAN を介したマルチマスターレプリケーションの配備を実現します。WAN を介したマルチマスターレプリケーションはプロトコルの改善によって実現しましたが、この改善は、ローカルエリアネットワーク (LAN) を介した配備にも同様に有効です。

プロトコルが異なるため、WAN を介したマルチマスターレプリケーションは、5.2 より前のバージョンの Directory Server との互換性はありません。このため、WAN を介したマルチマスターアプリケーションの設定では、WAN によって分散されるすべての Directory Server インスタンスは、5.2 インスタンスである必要があります。

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

レプリケーションの流れを最適化するために、Directory Server では変更を個別に送信する代わりにグループ化して送信することができます。また、サプライヤが処理継続のためのコンシューマからの受信通知を待たずにコンシューマに送信できる要求の数を指定することもできます。

グループとウィンドウのメカニズムはエントリのサイズに基づくため、エントリサイズが大きく異なる場合、これらのメカニズムを使ってレプリケーションのパフォーマンスを最適化することは実用的でない場合があります。エントリのサイズが比較的均一である場合は、グループとウィンドウのメカニズムを使用して、差分更新と完全更新を最適化することができます。WAN を介したマルチマスターレプリケーションのパフォーマンスは、使用する WAN の待ち時間と帯域幅によって異なることに注意してください。

ウィンドウとグループのサイズ調整については、『Directory Server 管理ガイド』の第 8 章にある「ネットワークパラメータの設定」を参照してください。

レプリケーションの圧縮

Directory Server は、グループとウィンドウのメカニズムのほかにも、Solaris および Linux システムの圧縮メカニズムを用意しています。Directory Server 5.2 より前のバージョンでは、帯域幅の制限が WAN を介したレプリケーションでボトルネックになることがよくありました。レプリケーションの圧縮は、レプリケーションの流れを効率的にして、このボトルネックを回避するのに役立ちます。コマンド行を使ったレプリケーションの圧縮方法については、『Directory Server Administration Reference』の第 4 章にある「ds5ReplicaTransportCompressionLevel」を参照してください。

完全にメッシュ化されたマルチマスタートポロジ

完全にメッシュ化されたトポロジとは、トポロジ内のマスターのそれぞれが、他のマスターのそれぞれに接続されていることを意味します。このようなトポロジは、高可用性と保証されたデータの整合性を提供します。図 6-3 は、完全にメッシュ化された 4 方向のマスタートポロジを示しています。

図 6-3 サフィックス「ou=people,dc=example,dc=com」の完全にメッシュ化された 4 方向のマルチマスターレプリケーション構成

この例では、4 つのマスターで ou=people,dc=example,dc=com サフィックスが維持され、変更要求に常に対応できるようにしています。各マスターは、自身の更新履歴ログを管理します。いずれかのマスターがクライアントからの変更要求を処理すると、そのマスターは操作を更新履歴ログに記録します。次に、その他のマスターにレプリケーション更新を送信し、そこからその他のコンシューマに伝達されます。このためマスターは、マスター間のレプリケーションアグリーメントだけでなく、コンシューマとのレプリケーションアグリーメントも保持する必要があります。また各マスターには、レプリケーション更新を送信するために他のマスターにバインドできるように、他のマスターの認証に使用するレプリケーションマネージャエントリも格納されます。

各コンシューマはレプリケーションマネージャエントリに対応する 1 つまたは複数エントリを保持しています。これにより、コンシューマはマスターがレプリケーション更新を送信する際にバインドするときに、マスターを認証できます。各コンシューマが 1 つのレプリケーションマネージャエントリだけを保持し、すべてのマスターが同じレプリケーションエントリを認証に使用するように設定することもできます。デフォルトでは、コンシューマはトポロジ内のすべてのマスターに対するリフェラルを保持します。クライアントから変更要求を受け取ると、コンシューマはマスターへのリフェラルをクライアントに返します。リフェラルについては、「リフェラル」を参照してください。

このトポロジは、読み書き対応フェイルオーバー機能の面ではもっとも安全ですが、この機能を使用するとパフォーマンスに影響する場合があります。完全にメッシュ化されたトポロジは、配備において高可用性がきわめて重大な場合に最適です。高可用性がそれほど重要でない場合、またはパフォーマンス上の理由からレプリケーショントラフィックを削減する場合は、読み書き可能フェイルオーバーの面でより「軽量」の配備が適しています。

レプリケーションの要素を理解しやすくするために、完全にメッシュ化された 4 方向のマルチマスターレプリケーションの設定について説明します。図 6-4 は、マスター A で設定する必要があるレプリケーションアグリーメント、更新履歴ログ、レプリケーションマネージャエントリを示しています。図 6-5 は、コンシューマ E で設定する必要がある同じ要素を示しています。

図 6-4 マスター A のレプリケーション設定 (完全にメッシュ化されたトポロジ)

図 6-4 に示されるように、マスター A は、マスターレプリカ、更新履歴ログ、マスター B、C、D 用のレプリケーションマネージャエントリ (4 つすべてのマスターでは、必ずしも同じレプリケーションマネージャエントリを使用しない場合) を必要とします。また、マスター A は、マスター B、C、D 用のレプリケーションアグリーメントとコンシューマ E、F 用のレプリケーションアグリーメントも必要とします。

図 6-5 コンシューマサーバー E のレプリケーション設定 (完全にメッシュ化されたトポロジ)

図 6-5 は、コンシューマ E のレプリケーション設定の詳細を示しています。コンシューマ E は、コンシューマレプリカ、およびレプリケーション更新の送信時にマスター A、B とのバインドで認証に使用されるレプリケーションマネージャエントリを必要とします。

カスケード型レプリケーション

カスケード型レプリケーション設定では、ハブとして機能するサーバーがサプライヤとして機能するサーバーから更新を受け取り、その更新をコンシューマ上で再現します。ハブはコンシューマとサプライヤの、両者の機能を合わせ持っています。つまり、通常のコンシューマと同様にデータの読み取り専用コピーを保持すると同時に、通常のサプライヤと同様に更新履歴ログも保持しています。

ハブは、元のマスターから受け取ったマスターデータのコピーを渡し、ディレクトリクライアントからの更新要求についてマスターを参照します。

図 6-6 は、カスケード型レプリケーション設定を示しています。

カスケード型レプリケーションは、次の場合に特に便利です。

非常に大きなトラフィック負荷のバランスをとる必要がある場合。レプリケーショントポロジのマスターはすべての更新トラフィックを処理するため、コンシューマへのレプリケーショントラフィックをサポートするには、大きな負荷がかかります。多数のコンシューマに対するレプリケーション更新を実行できるハブにレプリケーショントラフィックを任せることで、負荷を軽減できます。

地域分散型環境でローカルハブサプライヤを使用することで、接続費用を削減したい場合

ディレクトリサービスのパフォーマンスを向上させる場合。読み取り操作を行うすべてのクライアントアプリケーションをコンシューマへ、更新操作を行うすべてのクライアントアプリケーションをマスターへ導くことができる場合は、ハブのすべてのインデックス (システムインデックスを除く) を削除できます。これにより、マスターとハブの間のレプリケーション速度が向上します。

図 6-7 は、前の例で説明したサーバーがレプリケーションアグリーメント、更新履歴ログ、デフォルトリテラルの面からどのように設定されるかを示しています。

この例では、ハブ B はコンシューマ C、D にレプリケーション更新をリレーするために使用され、マスター A は多くのリソースを含んだままディレクトリの更新処理を続けます。マスターとハブは、どちらも更新履歴ログを維持します。ただし、クライアントからの変更要求を直接処理できるのは、マスターだけです。ハブにはマスター A のレプリケーションマネージャエントリが含まれるので、マスター A はハブにバインドし、レプリケーション更新を送信できます。コンシューマ C、D にはハブ B のレプリケーションマネージャエントリが含まれ、コンシューマへの更新の送信時の認証にはこれらのエントリが使用されます。

コンシューマとハブは、クライアントからの検索要求を処理できますが、変更要求の場合は、マスターへのリフェラルをクライアントに送信します。図 6-7 は、コンシューマ C、D がマスター A へのリフェラルを保持していることを示しています。これは、ハブとコンシューマの間のレプリケーションアグリーメントを作成するときに自動的に作成されるリフェラルです。ただし、パフォーマンスまたはセキュリティ上の理由から、これらのリフェラルを書き換えることもできます。詳細は、「リフェラル」を参照してください。

混合環境

上で説明したレプリケーション設定を、配備に合うように自由に組み合わせることができます。たとえば、マルチマスター設定とカスケード型設定を組み合わせて、図 6-8 に示すようなトポロジを構築できます。

図 6-8 マルチマスターレプリケーションとカスケード型レプリケーションの組み合わせ

図 6-8 では、2 つのマスターと 2 つのハブが 4 つのコンシューマにデータをレプリケートしています。前の例のように、マスターとハブの間でハブを共有することで、レプリケーション更新の負荷のバランスをとります。

この例に示される点線は、無効化されたレプリケーションアグリーメントを示しています。これらのレプリケーションアグリーメントを有効化しない場合、いずれかのハブがオフラインになった場合にこのトポロジにはシングルポイント障害が発生します。このテクノロジを配備する際は、パフォーマンスと高可用性の要件を比較考慮して、すべてのレプリケーションアグリーメントを有効化して完全な読み書き対応フェイルオーバーを提供するかどうかを決定する必要があります。

部分レプリケーション

レプリケーションの単位はサフィックスまたはサブサフィックスですが、部分レプリケーション機能はレプリケーションを大幅に細分化します。部分レプリケーションでは、サフィックスまたはサブサフィックスのすべてのエントリの属性のサブセットをレプリケートできます。

部分レプリケーションの利点

部分レプリケーションは、さまざまな状況で使用できます。

イントラネットサーバーとエクストラネットサーバーの間で同期が必要で、セキュリティ上の理由から一部のコンテンツをフィルタリングしなければならない場合に、部分レプリケーションがフィルタリング機能を提供します。

部分レプリケーションではレプリケートするものを選択できるため、レプリケーションの費用を削減することができます。すべての場所で特定の属性を利用できるようにすることだけが必要な配備では、すべての属性をレプリケートする代わりに、部分レプリケーション機能を使用して必要な属性だけをレプリケートできます。

たとえば、ほかの属性が頻繁に変更され、ネットワークトラフィックの負荷が非常に大きくなる場合は、ユーザーエントリのすべての属性をレプリケートするのではなく、電子メールアドレスと電話番号の属性だけをレプリケートすることもできます。部分レプリケーションを使用することで、必要な属性をフィルタリングし、トラフィックを最小限に抑えることができます。このフィルタリング機能は、WAN を介したレプリケーションでは特に有効です。

部分レプリケーションは、5.2 より前のバージョンの Directory Server との下位互換性はありません。部分レプリケーションを使用する場合は、Directory Server のすべてのインスタンスが 5.2 インスタンスである必要があります。

部分レプリケーションの設定

部分レプリケーションは、Directory Server コンソールから簡単に設定することができます。部分レプリケーションは、次のいずれかの方法で設定します。

ほとんどの場合、推奨される方法は排他的な設定アプローチです。ACI、CoS、ロールなど、一部の機能の複雑さ、および特定の属性に対するこれらの機能の依存性を考えると、対象から除外する属性のリストを管理するほうが、対象に含める属性のリストを管理するより安全であり、人的エラーの可能性が少なくなります。

部分レプリケーションを設定するときは、レプリケートされるサーバーが読み取り専用レプリカである必要があります。

一般には、スキーマ違反を回避するために、スキーマに定義されている各エントリのすべての必須属性をレプリケートします。部分レプリケーションを使用して一部の必須属性をフィルタリングする場合は、スキーマ検査を無効にする必要があります。スキーマ検査で部分レプリケーションが有効になっていると、サーバーを LDIF ファイルからオフラインで初期化できなくなる可能性があります。これは、必須属性をフィルタリングすると、サーバーが LDIF ファイルを読み込めなくなるためです。部分コンシューマレプリカでスキーマ検査を無効にした場合、その部分コンシューマレプリカが存在するサーバーインスタンス全体にスキーマが適用されなくなります。部分レプリケーションの設定ではサプライヤがスキーマをプッシュするため、部分コンシューマレプリカのスキーマは、マスターレプリカのスキーマのコピーとなります。このため、適用される部分レプリケーション設定には対応しません。

部分レプリケーション設定を変更する前に、それによって影響を受けるレプリケーションアグリーメントを無効にする必要があります。設定の変更が完了したら、レプリケーションアグリーメントを再度有効化し、新しい設定が適用されるようにコンシューマを再初期化します。

レプリケーション戦略の定義

使用するレプリケーション手法は、提供するサービスによって異なります。この節では、次の内容を詳しく示すレプリケーショントポロジの例を示します。

配備においてこれらの側面のそれぞれがどの程度重要かを考えるには、ネットワーク、ユーザー、クライアントアプリケーション、およびそれらでディレクトリサービスを使用する方法の調査を行うことから始めてください。この調査のガイドラインについては、「レプリケーション調査の実施」を参照してください。

レプリケーション手法を決定したら、Directory Server の配備を開始できます。ディレクトリを実際の環境に配備する段階に入ると、ディレクトリを全体的に配備した際の負荷をより正確に把握できるようになります。実際に運用されているディレクトリに基づいた負荷分析を行うことができない場合は、ディレクトリの使用状況をよく把握して、ディレクトリを修正するために準備してください。

次に、レプリケーション手法の決定に影響する要因について説明します。

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

レプリケーション調査を実施するときは、次の情報を収集することに専念してください。

たとえば、メッセージングサーバーがディレクトリを使用する場合は、処理するメールメッセージごとにディレクトリが実行する操作数を調べる必要があります。ディレクトリを使用するその他の認証アプリケーションには、META Directory アプリケーションなどがあります。アプリケーションごとに、ディレクトリで実行される操作のタイプと頻度を調べる必要があります。

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

レプリケーション機能は、システムリソースを必要とします。レプリケーション手法を決定するときは、次のリソース要件を検討してください。

サプライヤでは、各更新操作後に更新履歴ログが書き込まれます。サプライヤが複数のレプリケートされたサフィックスを保持する場合、更新履歴ログはより頻繁に更新されるため、ディスク使用量はさらに増えます。

ボトルネックを回避するため、コンシューマのマシンの規模は、少なくともサプライヤと同等である必要があります。

各レプリケーションアグリーメントは、2 つの追加スレッドを作成します。レプリケーションアグリーメントのスレッドは、操作スレッドとは分けられます。このため、いくつかのレプリケーションアグリーメントが存在する場合、クライアントアプリケーションで使用できるスレッドの数が少なくなり、クライアントアプリケーションに対するサーバーのパフォーマンスに影響が生じる可能性があります。

レプリケーションの下位互換性

レプリケーショントポロジで複数のバージョンの Directory Server を使用する場合は、レプリケーションを正しく機能させることができるように、表 6-1 の下位互換性に関する情報を考慮する必要があります。この表は、さまざまなバージョンの Directory Server 間で考えられるサプライヤとコンシューマの組み合わせを示しています。

表 6-1 さまざまなバージョンの Directory Server でのレプリケーションの下位互換性
	4.x コンシューマ	5.0/5.1 コンシューマ	5.0/5.1 マスター	5.2 コンシューマ	5.2 マスター	5.x ハブサプライヤ
4.x マスター	はい	はい	はい	はい	はい	いいえ
5.0/5.1 マスター	いいえ	はい	はい	はい	はい	はい
5.2 マスター	いいえ	はい	はい	はい	はい	はい

さまざまなバージョンの Directory Server でレプリケーションを使用する場合は、次の点に注意してください。

4.x マスターから 5.x マスターにレプリケートする設定で、5.x マスター上で旧バージョンのレプリケーションを有効にする場合、5.x マスターは、トポロジ内のその他の 5.x マスターからクライアント更新とレプリケーション更新を受信できなくなります。この場合、4.x マスターからのレプリケーション更新だけが受信可能です。ただし、旧バージョンのレプリケーションを無効にすると、5.x マスターのマスターレプリケーションとしての動作は完全に復元されます。

5.2 サーバーから 5.0/5.1 サーバーにレプリケートするときは、5.2 の新しい機能と機能強化は使用しないでください。これらの機能には、部分レプリケーション、複数パスワードポリシー、WAN を解したマルチマスターレプリケーション、オンライン昇格および降格があります。

5.2 スキーマ拡張によって 5.1 サーバーが混乱することがないように、nsslapd-schema-replicate-useronly 属性は on に設定する必要があります。

高可用性を実現するためのレプリケーションの使用

レプリケーションを使用して、単一のサーバーの障害によってディレクトリが使用できなくなることを防止することができます。最低限、ローカルのディレクトリツリーを少なくとも 1 つのバックアップサーバーにレプリケートしておきます。

ディレクトリの設計者の中には、データの信頼性を最大限保証するために物理的な場所ごとに 3 回はレプリケートしておく必要があると主張する人もいます。しかし、耐障害性を目的としたレプリケーションの使用頻度はユーザーの決定事項ですが、その決定はディレクトリで使用するハードウェアとネットワークの品質を考慮したものでなければなりません。信頼性の低いハードウェアでは、より多くのバックアップサーバーが必要になります。



注	通常のデータバックアップポリシー代わりにレプリケーションを使用することはできません。ディレクトリデータのバックアップについては、「バックアップ方法の選択」および『Directory Server 管理ガイド』の「データのバックアップ」を参照してください。

ディレクトリクライアントに書き込みフェイルオーバーを保証するには、マルチマスターレプリケーションのトポロジを使用する必要があります。読み取りフェイルオーバーが十分で、ディレクトリが地理的に分散されていない場合は、シングルマスターレプリケーションを使用できます。

LDAP クライアントアプリケーションは通常、1 つの LDAP サーバーだけを検索するように設定します。つまり、カスタムクライアントアプリケーションを異なる DNS ホスト名にある LDAP サーバーを循環するように作成していない限り、LDAP クライアントアプリケーションが Directory Server の単一の DNS ホスト名を検索するように設定するだけで済みます。したがって、バックアップ用の Directory Server にフェイルオーバーを提供するには、DNS ラウンドロビンまたはネットワークソートのどちらかを使用する必要があります。DNS ラウンドロビンとネットワークソートの設定方法と使用方法については、DNS のマニュアルを参照してください。

地理的に離れた 2 つの場所にまたがって書き込みフェイルオーバーを維持するには、WAN を介した 4 方向のマルチマスターレプリケーションを使用します。この場合、1 つの場所に 2 つのマスターサーバーを設定し、もう 1 つの場所にも 2 つのマスターサーバーを設定して、それらが WAN を介して完全にメッシュ化されるように設定します。これが、1 つのマスターがオフラインになった場合の安全対策になります。

ローカルでのデータの可用性を高めるためのレプリケーションの使用

次の場合、ローカルでもデータを利用するためにレプリケーションを使用することができます。

これは、特定の地理的な場所のユーザーだけにとって重要なディレクトリ情報を管理する必要がある、大規模な国際企業にとって重要です。また、データのローカルマスターコピーを保有することは、データを部門レベルまたは組織レベルで管理するようにしている企業にとっても便利です。

ロードバランスのためのレプリケーションの使用

レプリケーションを使用すると、次のような方法で Directory Server にかかる負荷のバランスをとることができます。

図 6-9 は、レプリケーションを使用してさまざまなアプリケーション間でディレクトリのアクティビティをどのように分割し、それによって各サプライヤサーバーにかかる負荷を削減できるかを示しています。

図 6-9 ロードバランスのためのマルチマスターレプリケーションの使用

ディレクトリデータをレプリケートすることで、ネットワークにかかる負荷も調整されます。可能であれば、高速で信頼性の高いネットワーク接続を介してアクセス可能なサーバーにデータを移動します。

通常、ディレクトリエントリの平均サイズは約 1K バイトです。したがって、ディレクトリの検索ごとにネットワークの負荷が約 1K バイト増加します。ディレクトリユーザーが 1 日当たり約 10 回検索を実行すると、ネットワークの負荷はユーザー 1 人につき 1 日当たり約 10,000 バイト増加します。低速な、負荷が大きい、あるいは信頼性が低い WAN を使用している場合は、ディレクトリツリーをローカルサーバーにレプリケートする必要がある場合もあります。

ローカルで使用できるデータの利点は、レプリケーションによって増加するネットワークトラフィックの費用と比較して考慮する必要があることに注意してください。たとえば、ディレクトリツリー全体をリモートサイトにレプリケーションする場合は、ユーザーのディレクトリの検索によるトラフィックに比べ、はるかに大きな負荷をネットワークに課すことになります。このことは、ディレクトリツリーが頻繁に変更されるのに対して、リモートサイトの少数のユーザーが、1 日当たり数回のディレクトリ検索しか実行しない場合は、特に当てはまります。

ディレクトリツリーに平均して 1,000,000 件を超えるエントリがあり、毎日 10 % 前後が変更される場合を考えてみます。ディレクトリエントリのサイズが平均して 1K バイトとすると、ネットワークの負荷が 1 日当たり 100M バイト増えることになります。しかし、リモートサイトの従業員がたった 100 人で、1 日当たり平均して 10 回のディレクトリ検索を実行している場合は、ディレクトリアクセスによるネットワークの負荷は 1 日当たり 1M バイトにすぎません。

レプリケーションによるネットワークの負荷と通常のディレクトリの使用による負荷の違いから、ネットワークのロードバランスを目的とするレプリケーションは実現可能ではないという結論に達する場合もあります。反対に、ネットワークにかかる負荷を考慮しても、ディレクトリデータをローカルで利用できる利点の方が勝っていると判断する場合もあります。

ネットワークに過度な負荷をかけずにデータをローカルサイトで使用できるようにするには、スケジュールされたレプリケーションを使用します。データの整合性とレプリケーションスケジュールについては、「データの整合性」を参照してください。

ネットワークのロードバランスの例

2 つの都市に事務所を持つ企業を考えてみます。図 6-10 に示すように、それぞれの事務所は別々のサブツリーを管理します。

図 6-10 ニューヨークとロサンゼルスでそれぞれにあるサブツリー

各事務所には高速の LAN がありますが、2 都市間の通信にはダイヤルアップ接続を使用しています。このような場合は、以下のようにネットワークの負荷のバランスをとります。

ローカルで管理するデータを、選択したサーバーからリモートオフィスのマスターにレプリケートします。それぞれの地域でマスターコピーを保持することで、ユーザーはダイヤルアップ接続経由で更新と検索を行う必要がなくなり、パフォーマンスが最適化されます。

ディレクトリデータのローカルでの可用性を保証するために、リモートオフィスからのデータも含め、各マスター上のディレクトリツリーを少なくとも 1 つのローカル Directory Server にレプリケートする

それぞれの地域でカスケード型レプリケーションを設定し、ローカルデータに対する検索に特化したコンシューマの数を増やすことで、ロードバランスをさらに進める

ニューヨーク事務所では、ロサンゼルスに関する検索よりもニューヨークに関する検索のほうが多く行われるため、この例では、ニューヨーク事務所に 3 つのニューヨークデータコンシューマと、1 つのロサンゼルスデータコンシューマが設定されています。同様に、ロサンゼルス事務所には 3 つのロサンゼルスデータコンシューマと 1 つのニューヨークデータコンシューマがあります。

図 6-11 は、このネットワークロードバランスの設定を示しています。

図 6-11 マルチマスターレプリケーションとカスケード型レプリケーションによるロードバランス

パフォーマンス向上のためのロードバランスの例

この例では、ディレクトリには 15,000,000 のエントリが格納されて 10,000,000 のユーザーがアクセスし、各ユーザーが 1 日当たり 10 件のディレクトリ検索を実行します。メッセージングサーバーは 1 日当たり 250,000,000 通のメールメッセージを処理し、メールメッセージごとに 5 件のディレクトリ検索を実行します。メール処理に 1 日当たり 1,250,000,000 件のディレクトリ検索が実行されます。ディレクトリとメッセージングシステムの合計トラフィックでは 1 日当たり 1,350,000,000 件のディレクトリ検索が実行されることになります。

1 日の就業時間は 8 時間、ディレクトリユーザーが 4 つの時間帯に分かれているとすると、4 つの時間帯にわたる就業時間 (または、ピーク時の利用率) は 12 時間となります。したがって、ディレクトリは、1 日 12 時間で 1,350,000,000 件の検索をサポートする必要があります。これは毎秒 31,250 (1,350,000,000/(60×60×12)) 件の検索をサポートするのと同じです。つまり、次のようになります。


10,000,000 人のユーザー	1 ユーザーにつき 10 件の検索 =	100,000,000 件の読み取り/日
250,000,000 通のメッセージ	1 メッセージにつき 5 件の検索=	1,250,000,000 件の読み取り/日
	合計読み取り/日 =	1,350,000,000

12 時間は 43,200 秒	合計読み取り/秒 =	31,250

ディレクトリで毎秒 5,000 件の読み取りをサポートできる CPU と RAM の組み合わせを考えてみます。簡単な割り算で、この負荷をサポートするには 6 ～ 7 つの Directory Server が必要であることがわかります。10,000,000 人のディレクトリユーザーを有する企業の場合は、ローカルでデータを利用するという目的も考慮するとさらに Directory Server を追加する必要があります。

Directory Server 5.2 では、適切なハードウェアと設定により、1 台のサーバーで、1 秒あたり 5,000 回を超える読み取り処理の継続が可能になります。

小規模サイト向けのレプリケーション手法の例

会社全体が 1 つの建物内にある場合を考えてみます。この建物には、毎秒 100M バイトの高速で使いやすいネットワークが装備されています。ネットワークは安定しており、サーバーのハードウェアと OS プラットフォームの信頼性も十分に高いものとします。また、1 つのサーバーの処理能力でサイトの負荷を容易に処理できるものとします。

このような場合、保守やハードウェアのアップグレードのためにプライマリサーバーが停止されたときでも、ディレクトリデータが利用できるようにしておくために、少なくとも 1 回はレプリケートしておきます。また、Directory Server の 1 つが使用できなくなったときに LDAP 接続のパフォーマンスを上げるために、DNS ラウンドロビンを設定します。代替方法として、Sun Java System Directory Proxy Server などの LDAP プロキシを使用することもできます。Directory Proxy Server については、http://www.sun.com/software/products/directory_proxy/home_dir_proxy.html を参照してください。

大規模サイト向けのレプリケーション手法の例

会社が 2 つの建物に分かれている場合を考えてみます。それぞれの建物には、毎秒 100M バイトの高速で使いやすいネットワークが装備されています。ネットワークは安定しており、サーバーのハードウェアと OS プラットフォームの信頼性も十分に高いものとします。また、1 つのサーバーの処理能力で、各建物内のサーバーにかかる負荷を容易に処理できるものとします。

建物間は低速接続 (ISDN) で、通常の営業時間中に大きな負荷がかかります。

この例での典型的なレプリケーション手法は、次のとおりです。

大規模な国際企業のレプリケーション戦略

企業の 2 つのデータセンターがフランスと米国にあり、WAN によって分割されていると仮定します。WAN 経由によるレプリケーションが必要なだけでなく、パートナー企業にすべてのデータを開示しないために、一部のデータをフィルタリングしなければなりません。通常業務時間内は、使用するネットワークはとても混み合っています。

この例での典型的なレプリケーション手法は、次のとおりです。

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

フランスサイト内と米国サイト内の書き込みフェイルオーバーのために、各データセンターの第 2 のマスターにデータをレプリケートする

フランスと米国の間に完全にメッシュ化された 4 方向のマルチマスターレプリケーショントポロジを配備し、配備全体で高可用性と書き込みフェイルオーバーを実現する

各データセンターで必要なだけのコンシューマを配備し、ディレクトリ検索の面でマスターへの負荷を軽減する

両地域のマスターとコンシューマの間に部分レプリケーションを設定し、パートナー企業にアクセスさせたくないデータをフィルタリングする

帯域幅を最適化できるように、混雑していない時間帯に実行されるようにレプリケーションをスケジュールする

レプリケーションとほかのディレクトリ機能との併用

レプリケーションは Directory Server のほかの機能と連携して、高度なレプリケーション機能を提供します。次に、最適なレプリケーションの設計に役立つ、機能の併用について説明します。

レプリケーションとアクセス制御

ディレクトリはエントリの属性として ACI を格納しています。つまり、ACI はほかのディレクトリ内容と一緒にレプリケートされます。Directory Server は ACI をローカルに評価するため、これは重要です。

レプリケーションと Directory Server のプラグイン

レプリケーションは、Directory Server に付属するほとんどのプラグインと一緒に使用できます。次に、いくつかの例外と制限について説明します。

レプリケーションと旧バージョン形式の更新履歴ログプラグイン

旧バージョン形式の更新履歴ログプラグインは、Directory Server の 4.x リリースとの下位互換性を備えています。このプラグインは、競合解決の結果は記録しません。つまり、変更は実際にエントリで適用されます。旧バージョン形式の更新履歴ログプラグインは、デフォルトでは無効になっているため、Directory Server コンソールまたはコマンド行を使用して有効化する必要があります。

旧バージョン形式の更新履歴ログプラグインは、マルチマスターレプリケーション環境で機能するようには設計されていません。このプラグインをマルチマスター環境の 2 つのサーバーに設定した場合、変更が同じ順序、および同じ変更番号でログに記録されるとは限りません。アプリケーションで変更の順序が重要な場合、そのアプリケーションは 2 つの異なる旧バージョン形式の更新履歴ログは使用できません。

マルチマスターレプリケーション環境のマスターの 1 つだけに旧バージョン形式の更新履歴ログプラグインを設定すると、順番による問題は多少は解決します。ただし、この設定はシングルポイント障害を引き起こすため、マスターで障害が発生します。

レプリケーションと参照整合性プラグイン

参照整合性プラグインがすべてのマスターレプリカで有効になっている場合は、プラグインとマルチマスターレプリケーションを一緒に使用できます。参照整合性プラグインは、デフォルトでは無効になっているため、Directory Server コンソールまたはコマンド行を使用して有効化する必要があります。

整合性チェックにはメモリと CPU が多大に消費されるので、変更要求を送信するサーバーで参照整合性プラグインを有効化する前に、パフォーマンスリソース、時間、整合性の必要性を分析してください。

レプリケーションと操作前、操作後プラグイン

操作前プラグインと操作後プラグインを作成するときは、これらのプラグインがレプリケーション操作を無視するように指定することができます。ほとんどの場合は、これがプラグインの目的の動作である可能性があります。レプリケーション操作を変更すると予期しない動作が起きる可能性があることに注意してください。

レプリケーションと連鎖サフィックス

連鎖を使用してエントリを分散する場合は、連鎖サフィックスを保持するサーバーが、実際のデータを含むリモートサーバーを指します。このリモートサーバーは、ファームサーバーとも呼ばれています。このような環境では、連鎖サフィックス自体をレプリケートすることはできません。ただし、実際のデータを格納しているサフィックスのレプリケートは可能です。連鎖サフィックスを含むサーバー上ではなく、リモートサーバー上のレプリケーションアグリーメントを設定する必要があります。

レプリケーションを連鎖サフィックスのバックアップとしては使用しないでください。連鎖サフィックスは手動でバックアップする必要があります。連鎖とエントリの分散については、「リフェラルと連鎖」を参照してください。

スキーマのレプリケーション

レプリケーション環境で Directory Server を使用する場合は、レプリケーションに含まれるすべてのサーバーについてスキーマの一貫性を維持する必要があります。サーバー間でスキーマの一貫性が維持されない場合は、レプリケーションでエラーが発生する可能性があります。

スキーマの一貫性を確保するために、マルチマスターレプリケーショントポロジの場合でも、1 つのマスターでスキーマの変更を行うことをお勧めします。スキーマの変更についての競合解決はありません。したがって、マルチマスタートポロジの 2 つのマスターサーバーでスキーマに変更を加えた場合、最後に変更されたマスターがそのスキーマをコンシューマに伝達します。つまり、後から加えた変更が、もう一方のマスターに加えた変更と異なる場合は、その内容が失われる危険があります。

コンシューマ上のスキーマは絶対に更新しないでください。コンシューマ上のスキーマを更新し、その結果としてサプライヤ上のスキーマのバージョンがコンシューマ上のスキーマのバージョンより古くなった場合は、コンシューマを検索したりサプライヤを更新しようとするとエラーが発生します。

スキーマのレプリケーションは自動的に行われます。サプライヤとコンシューマ間でレプリケーションが設定されている場合は、デフォルトでスキーマがレプリケートされます。

Directory Server でスキーマのレプリケーションに使用されるロジックは、次のように説明できます。

データをコンシューマにプッシュする前に、サプライヤは自身のスキーマが、コンシューマ上で保持されているバージョンのスキーマと同期しているかどうかを検査します。

サプライヤとコンシューマ両方のスキーマエントリが同じであれば、レプリケーションが実行されます。

サプライヤ上のスキーマがコンシューマに格納されているものよりも新しい場合、サプライヤはデータのレプリケーションを実行する前に自身のスキーマをコンシューマにレプリケートします。



注	スキーマに含まれる ACI は、レプリケートされます。

カスタムスキーマファイルへの変更は、スキーマが LDAP または Directory Server コンソールを使用して更新されている場合にのみレプリケートされます。カスタムスキーマファイルは、すべてのサーバー上で情報を同じスキーマファイルに保持するために、各サーバーにコピーする必要があります。詳細は、『Directory Server 管理ガイド』の第 9 章にある「スキーマ定義のレプリケーション」を参照してください。

ユーザー定義のスキーマのみをレプリケートすることで、転送されるデータの量が削減され、スキーマのレプリケーションを高速にすることができます。詳細は、『Directory Server 管理ガイド』の第 9 章にある「スキーマレプリケーションの制限」を参照してください。

レプリケーションと複数パスワードポリシー

複数パスワードポリシーを使用するときは、レプリケートされたエントリに適用するポリシーの定義を含む LDAP サブエントリをレプリケートする必要があります。これを行わなければ、デフォルトのパスワードポリシーが適用されます。このポリシーは、デフォルト以外のパスワードポリシーを使用するように設定されているエントリに対しては機能しません。

これらのエントリを 5.0/5.1 サーバーにレプリケートすると、レプリケーションは正しく機能しますが、パスワードポリシーは 5.0/5.1 サーバー上で実施されません。複数パスワードポリシー機能は、Directory Server 5.2 のみでサポートされています。

レプリケーションの監視

Directory Server 5.2 は、サーバー間でレプリケーションを監視するためのコマンド行ツールを備えています。レプリケーションアクティビティを監視する機能は、レプリケーションに関する問題を特定する上で役立ちます。すべての監視ツールは、セキュリティ保護された接続を介して使用できます。

レプリケーション監視ツールは LDAP クライアントを構成するため、サーバーへの認証と、cn=config に対する読み取りアクセス権を持つバインド DN が必要となります。

insync - マスターレプリカと 1 つまたは複数のコンシューマレプリカとの間の同期状態を示す

entrycmp - 複数のサーバー上の同一エントリを比較することができる

repldisc - レプリケーショントポロジを推測することができるトポロジの推測は、1 つのサーバーから始まり、トポロジ内のすべての既知のサーバーをグラフ化することで行われます。このレプリケーショントポロジ推測ツールは、配備したグローバルトポロジを思い出すことが難しい、大規模で複雑な配備で便利です。

レプリケーション監視ツールについては、『Directory Server Administration Reference』の第 1 章を参照してください。特定のレプリケーション属性で使用できる監視機能については、『Directory Server Administration Reference』の「Core Server Configuration Attributes」を参照してください。

前へ目次索引次へ
Sun Java™ System Directory Server 5 2004Q2 配備計画ガイド