レプリケーション機構については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 4 章「Directory Server Replication」で詳しく説明しています。次の節では、この章の後半で説明するサンプルトポロジを検討する前に理解しておく必要がある基本的な情報を示します。
レプリケーションに関与するデータベースを「レプリカ」と呼びます。
Directory Server では、3 種類のレプリカを区別しています。
マスターレプリカ (読み書き可能レプリカ): ディレクトリデータのマスターコピーを含む読み書き可能データベース。マスターレプリカは、ディレクトリクライアントからの更新要求を処理できます。複数のマスターを含むトポロジのことを「マルチマスター」トポロジと呼びます。
コンシューマレプリカ: マスターレプリカ内の情報のコピーを保持する読み取り専用データベース。コンシューマレプリカは、ディレクトリクライアントからの検索要求を処理できますが、更新要求はマスターレプリカを照会します。
ハブレプリカ: コンシューマレプリカと同様の読み取り専用データベース。1 つ以上のコンシューマレプリカを「供給」する Directory Server 上に格納されます。
次の図は、レプリケーショントポロジ内でのこれらの各レプリカのロールを示したものです。
この図は例示のみを目的としたものであり、必ずしも推奨されるトポロジではありません。マルチマスタートポロジで、Directory Server 6.1 がサポートするマスター数は無制限です。ほとんどの場合、マスターのみのトポロジが推奨されます。
ほかのサーバーにレプリケートする Directory Server のことを「サプライヤ」と呼びます。また、ほかのサーバーによって更新される Directory Server のことを「コンシューマ」と呼びます。サプライヤは、特別に設計された LDAP v3 拡張処理により、コンシューマ上のすべての更新を再現します。このためサプライヤは、パフォーマンスの面ではコンシューマに対する要件の多いクライアントアプリケーションに似ています。
次のような状況で、サーバーはサプライヤとコンシューマの両方になることができます。
2 つの異なる Directory Server 上にそれぞれマスターレプリカが配置されているマルチマスターレプリケーション環境では、一方のサーバーは、他方のサーバーのサプライヤとして、またコンシューマとしての役割を果たします。
サーバーにハブレプリカが含まれるとき、サーバーはサプライヤから更新を受け取り、変更内容をコンシューマにレプリケートします。
コンシューマのロールのみを果たすサーバーのことを「専用コンシューマ」と呼びます。
「マスターレプリカ」の役割をするサーバーは次のことを行う必要があります。
ディレクトリクライアントからの更新要求に応答する
履歴情報および変更履歴ログを維持する
コンシューマへのレプリケーションを開始する
マスターレプリカを含むサーバーは、マスターレプリカに対して行われたすべての変更を記録する処理と、これらの変更をコンシューマにレプリケートする処理を受け持ちます。
「ハブレプリカ」の役割をするサーバーは次のことを行う必要があります。
読み取り要求に応答する
マスターレプリカを保持するサーバーに更新要求を送信する
履歴情報および変更履歴ログを維持する
コンシューマへのレプリケーションを開始する
「コンシューマレプリカ」の役割をするサーバーは次のことを行う必要があります。
読み取り要求に応答する
履歴情報を維持する
マスターレプリカを保持するサーバーに更新要求を送信する
マルチマスターレプリケーション設定では、データは異なる場所で同時に更新することができます。各マスターは、そのレプリカの変更履歴ログを維持します。各マスター上で発生した変更は、ほかのサーバーにレプリケートされます。
マルチマスター設定には、次の利点があります。
1 つのマスターにアクセスできなくなった場合でも、自動的に書き込み処理のフェイルオーバーが発生します。
地理的に分散されている環境では、ローカルのマスターで更新処理を実行できます。
マルチマスターレプリケーションでは、疎整合レプリケーションモデルを使用します。これは、同じエントリが異なるサーバー上で同時に変更される可能性があることを意味します。2 つのサーバー間で更新が送信された場合、更新の競合を解決する必要があります。待ち時間などの WAN の各種特性により、レプリケーション競合の可能性が高まる可能性があります。競合の解決は通常、自動的に行われます。どの変更が優先されるかは、競合規則によって決定されます。競合を手動で解決しなければならない場合もあります。詳細は、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「よく発生するレプリケーションの競合の解決」を参照してください。
マルチマスタートポロジでサポートされるマスターの数は、理論上は無制限です。同様に、コンシューマとハブの数も理論上は無制限です。ただし、1 つのサプライヤから何個のコンシューマにレプリケーションを実行できるかは、サプライヤサーバーの能力に依存します。サプライヤサーバーの能力を評価するために、SLAMD 分散負荷生成エンジン (SLAMD) を使用できます。SLAMD の詳細および SLAMD ソフトウェアのダウンロードについては、http://www.slamd.com を参照してください。
レプリケーションの最小単位はサフィックスです。レプリケーション機構では、サフィックスとデータベースが 1 対 1 で対応している必要があります。カスタム分散ロジックを使用している 2 つ以上のデータベースにまたがって分散されているサフィックス (またはネームスペース) はレプリケートできません。レプリケーション単位は、コンシューマとサプライヤの両方に適用されます。つまり、1 つのサフィックスだけを保持するコンシューマに 2 つのサフィックスをレプリケートすることはできません。
サプライヤとして機能するすべてのサーバーは更新履歴ログを維持します。「更新履歴ログ」は、マスターレプリカに対して行われた変更を記述した記録です。サプライヤは、この変更をコンシューマ上で再現します。エントリの変更、名称変更、追加、または削除が行われると、LDAP 操作を記述する変更レコードが更新履歴ログに記録されます。
Directory Server では、レプリケーションアグリーメントを使用して、2 つのサーバー間でレプリケーションがどのように行われるかを定義します。「レプリケーションアグリーメント」は、1 つのサプライヤと 1 つのコンシューマの間のレプリケーションを定義します。
レプリケーションアグリーメントは次のものを識別します。
レプリケートするサフィックス
データがレプリケートされるコンシューマサーバー
レプリケーションを実行できる時間帯
サプライヤがコンシューマへのバインドに使用する必要があるバインド DN と資格
接続をセキュリティー保護する方法 (SSL やクライアント認証など)
この特定のアグリーメントのレプリケーションの状態に関する情報
レプリケーションフィルタについての情報
Directory Server 6.x よりも前のバージョンの Directory Server では、更新は時系列順にレプリケートされていました。本バージョンでは、更新のレプリケーションに優先順位を付けることができます。優先度はブール型の機能であり、オンまたはオフを選択できます。優先度のレベルはありません。レプリケーションを待機している更新のキュー内で、優先度がオンの更新は、優先度がオフの更新よりも先にレプリケートされます。レプリケーションを待機している更新のキュー内で、優先度がオンの更新は、優先度がオフの更新よりも先にレプリケートされます。
優先度規則は、次のパラメータに従って設定されます。
クライアントのアイデンティティー
更新のタイプ
更新されたエントリまたはサブツリー
更新によって変更される属性
詳細は、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「Prioritized Replication」を参照してください。