iPlanet Directory Server 5.1 管理者ガイド: 第 8 章レプリケーションの管理

前へ目次索引 DocHome 次へ

iPlanet Directory Server 5.1 管理者ガイド

第 8 章 レプリケーションの管理

レプリケーションは、使用しているディレクトリサービスを単一サーバの構成から拡張するための重要なメカニズムです。この章では、単一マスターレプリケーション、マルチマスターレプリケーション、およびカスケード型レプリケーションを設定するために、サプライヤサーバおよびコンシューマサーバ上で実行される処理について説明します。この章は、次の節で構成されています。

レプリケーションの概要

レプリケーションのモデル

複雑なレプリケーション構成手順のまとめ

レプリケーションのための作業の詳細

単一マスターレプリケーションの構成

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

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

更新履歴ログの削除

コンシューマの初期化

レプリカの同期の維持

SSL を介したレプリケーション

旧バージョンからのレプリケーション

レトロ履歴ログのプラグインの使用

レプリケーション状態の監視

よく発生するレプリケーションの競合の解決
ディレクトリでのレプリケーションの使い方に関する、全体的な情報については、『iPlanet Directory Server 導入ガイド』を参照してください。

レプリケーションの概要

レプリケーションとは、ある Directory Server から別のサーバへディレクトリデータを自動的にコピーするメカニズムです。すべての更新処理 (エントリの追加、変更、削除など) は、レプリケーションを使用して別の Directory Server に自動的にミラーされます。ここでは、次のレプリケーションの概念について説明します。

「レプリカ」

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

「更新履歴ログ」

「レプリケーションの単位」

「レプリケーションの識別情報」

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

「Directory Server の旧バージョンとの互換性」

レプリカ

レプリケーションに関与するデータベースのことを、レプリカと定義します。レプリカには、いくつかの種類があります。

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

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

ハブレプリカ : コンシューマレプリカと同じ読み取り専用データベース。コンシューマレプリカとの相違は、このデータベースに格納された情報が、レプリケートされた情報のコンシューマおよびサプライヤ (ハブ) として動作する Directory Server によって使用される点である
Directory Server は、複数のデータベースを管理するように構成できます。各データベースには、レプリケーションにおいて異なる役割を持たせることができます。たとえば、マスターレプリカに dc=engineering,dc=siroe,dc=com 接尾辞、およびコンシューマレプリカに dc=sales,dc=siroe,dc=com 接尾辞を格納する 1 つの Directory Server を持つことができます。

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

ほかのサーバにそれがレプリケートするマスターレプリカを管理するサーバをサプライヤ (supplier) サーバまたはマスターサーバと呼びます。別のサーバによって更新されるコンシューマレプリカを管理するサーバは、コンシューマサーバと呼ばれます。
ここでは便宜のため、サプライヤまたはコンシューマとしてのサーバの役割について説明します。サーバは、サプライヤとコンシューマの両方に指定できるため、常に正しいとは限りません。これは、次の場合に当てはまります。

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

Directory Server がハブサプライヤ (hub supplier) として機能する場合。つまり、マスターサーバから更新を受け取り、変更内容をコンシューマサーバにレプリケートする場合。詳細については、「カスケード型レプリケーション」を参照してください。

マルチマスターレプリケーションで、マスターレプリカが 2 つの異なる Directory Server に保持される場合。この場合、各 Directory Server が、もう一方の Directory Server のサプライヤおよびコンシューマとして機能する。詳細については、「マルチマスターレプリケーション」を参照してください。
iPlanet Directory Server 5.1 では、レプリケーションは常にサプライヤサーバから開始されます。コンシューマサーバから開始されることはありません。この処理は、サプライヤ主導レプリケーション (supplier-initiated replication) と呼ばれます。この処理により、1 つ以上のコンシューマサーバへデータをプッシュするようにサプライヤサーバを構成できます。
iPlanet Directory Server の旧バージョンでは、コンシューマ主導レプリケーション (consumer-initiated replication) を許可しており、コンシューマサーバがサプライヤサーバからデータをプルするように設定できました。iPlanet Directory Server 5.1 では、コンシューマがサプライヤに更新の送信を促すことができる手順に変更されました。この機能については、「レプリカの同期の維持」を参照してください。

更新履歴ログ

すべてのサプライヤサーバは、更新履歴ログ (change log) を保持しています。更新履歴ログとは、マスターレプリカに対して行われた変更を記述しておく記録のことです。サプライヤサーバは、コンシューマサーバに格納されているレプリカに対して、またはマルチマスターレプリケーションの場合はほかのサプライヤに対して、これらの変更をリプレイします。
エントリが変更されると、実行された LDAP 操作を記述する変更レコードが更新履歴ログに記録されます。
更新履歴ログは、通常の LDBM データベースと同じ方法で構成できます。
iPlanet Directory Server 5.0 では、更新履歴ログの形式が変更されました。旧バージョンの Directory Server では、LDAP から更新履歴ログにアクセスできました。しかし今回、更新履歴ログの形式が変更され、サーバによる内部処理専用になりました。使用しているアプリケーションで更新履歴ログを読み取る必要がある場合は、レトロログのプラグインを使用して、下位互換性を保つことができます。詳細については、「レトロ履歴ログのプラグインの使用」を参照してください。

レプリケーションの単位

iPlanet Directory Server 5.1 では、レプリケーションの最小単位はデータベースです。つまり、データベース全体をレプリケートすることはできますが、データベース内のサブツリーだけをレプリケートすることはできません。そのため、ディレクトリツリーを作成するときは、レプリケーション計画を考慮に入れる必要があります。ディレクトリツリーの設定方法については、『iPlanet Directory Server 導入ガイド』を参照してください。
レプリケーションメカニズムでは、接尾辞とデータベースが 1 対 1 で対応している必要があります。つまり、カスタム分散論理を使用している 2 つ以上のデータベースにまたがって分散されている接尾辞 (またはネームスペース) はレプリケーションできません。このトピックについては、「データベースの作成と管理」を参照してください。

レプリケーションの識別情報

2 つのサーバ間でレプリケーションが行われる場合、レプリケーション更新データを送信するためにバインドするときに、コンシューマサーバがサプライヤを認証します。この認証処理を実行するには、サプライヤがコンシューマにバインドする際に使用するエントリがコンシューマサーバに格納されていなければなりません。このエントリをレプリケーションマネージャエントリまたはサプライヤバインド DN と呼びます。
レプリケーションマネージャエントリあるいはそのロールを遂行するために作成したエントリは、次のような条件を満たしている必要があります。

コンシューマレプリカ (またはハブレプリカ) を管理するすべてのサーバに少なくとも 1 つのエントリが必要

セキュリティ上の理由から、このエントリをレプリケートされたデータの一部にしないこと

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

2 つのサーバ間でレプリケーションを構成する場合は、両方のサーバにレプリケーションマネージャ (サプライヤバインド DN) を識別する必要があります。

コンシューマサーバまたはハブサプライヤ上に、コンシューマレプリカまたはハブレプリカを構成する場合、レプリケーション更新を実行する権限をもつエントリに対応する 1 以上のサプライヤバインド DN を指定する必要がある

サプライヤサーバ上にレプリケーションアグリーメントを構成する場合、レプリケーションアグリーメントでレプリケーションマネージャの DN を指定しておく必要がある

注
Directory Server Console では、このレプリケーションマネージャのエントリをサプライヤバインド DN と呼びますが、実際にはサプライヤサーバにそのようなエントリが存在しないため、この呼び方は誤解を招くおそれがあります。これをサプライヤバインド DN と呼ぶのは、コンシューマにレプリケーション更新を提供するためのバインド時にサプライヤを認証できるように、コンシューマに置く必要があるエントリだからです。

レプリケーションマネージャエントリの作成については、「サプライヤバインド DN エントリの作成」を参照してください。

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

Directory Server では、レプリケーションアグリーメントを使用してレプリケーション構成を定義します。1 つのレプリケーションアグリーメント (replication agreement) には、1 つのサプライヤと 1 つのコンシューマだけの間のレプリケーションについて記述されています。契約はサプライヤサーバ上に設定され、次のものを特定します。

レプリケートされるデータベース

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

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

サプライヤサーバがバインドに使用する必要のある DN と資格 (レプリケーションマネージャエントリ、またはサプライヤバインド DN と呼ばれる)

接続のためのセキュリティ確保 (SSL、クライアント認証)

Directory Server の旧バージョンとの互換性

iPlanet Directory Server 5.0 および 5.1のレプリケーションメカニズムは、Directory Server の旧バージョンで使用されていたメカニズムとは異なります。互換性は次のプラグインによって保持されます。

旧バージョンのレプリケーションプラグイン

レトロログプラグイン
古いバージョンのレプリケーションプラグインを使用すると、Directory Server 5.1 は、コンシューマロールで Directory Server 4.x のように動作します。このプラグインを使用した旧バージョンのレプリケーションの実装方法については、「旧バージョンからのレプリケーション」を参照してください。
レトロログのプラグインを使用すると、Directory Server 5.1 サプライヤに 4.x スタイルの更新履歴ログを維持できます。このプラグインは、Directory Server 4.x の形式の更新履歴ログに依存している、iPlanet Meta Directory などのアプリケーションで必要になる場合があります。これは、アプリケーションが更新履歴ログからデータを読み取るためです。レトロログのプラグインについては、「レトロ履歴ログのプラグインの使用」を参照してください。

レプリケーションのモデル

ここでは、もっともよく使用される次のレプリケーションモデルについて説明します。

「単一マスターレプリケーション」

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

「カスケード型レプリケーション」
これらの基本的なモデルの組み合わせによって、最適なレプリケーション環境を構築することができます。

注
どのレプリケーションモデルを選択した場合でも、スキーマのレプリケーションを考慮するようにしてください。詳細は、『iPlanet Directory Server 導入ガイド』を参照してください。

単一マスターレプリケーション

もっとも単純なレプリケーションモデルでは、ディレクトリデータのマスターコピーは、サプライヤサーバと呼ばれる 1 つのサーバ上の単一のマスターレプリカに保持されます。このサーバによって、コンシューマサーバに格納されたコンシューマレプリカに更新が供給されます。
サプライヤサーバでは、マスターレプリカに対するすべての更新を記録した更新履歴ログを管理します。サプライヤサーバには、レプリケーションアグリーメントも格納されます。
コンシューマサーバには、サプライヤバインド DN に対応するエントリが格納されるので、レプリケーション更新を送信するためにバインドするときにサプライヤを認証できます。
図 8-1    単一マスターレプリケーション

図 8-1 に示した例では、ou=people,dc=siroe,dc=com 接尾辞が、クライアントから多数の検索および更新要求を受け取ります。したがって、負荷を分散するために、サーバ A 上にマスターのあるこの接尾辞は、サーバ B 上にあるコンシューマレプリカにレプリケートされます。
サーバ B は、クライアントからの検索要求を処理できますが、ディレクトリエントリの変更要求は処理できません。サーバ B は、クライアントにサーバ A に対するレフェラルを返すことによって、クライアントから受け取った変更要求を処理します。

注
レプリケーションでは、コンシューマサーバにサプライヤサーバのレフェラル情報が格納されますが、変更要求はクライアントからサプライヤに転送されません。クライアントは、コンシューマから返送されるレフェラルに従う必要があります。

単一マスターレプリケーション環境の構成方法については、「単一マスターレプリケーションの構成」を参照してください。

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

iPlanet Directory Server 5.1 では、同じ情報が 2 つのサーバ上で、それぞれマスターとして保持されるというより複雑なレプリケーションモデルもサポートします。この情報は、各サーバのマスターレプリカに保持されています。このため、各サーバがレプリカに対する更新履歴ログを、それぞれ維持しています。
このタイプの構成も、任意の数のコンシューマサーバをコピー先として設定できます。2 つのサプライヤから更新を受け取ります。コンシューマでは、両方のサプライヤを定義したレフェラルも保持しています。このようなモデルを、マルチマスター構成と呼びます。
図 8-2 は、マルチマスターレプリケーションのモデルを示したものです。マルチマスターレプリケーションの設定に必要なレプリケーションアグリーメント、更新履歴ログ、およびサプライヤバインド DN については、図 8-3 を参照してください。
図 8-2    マルチマスターレプリケーション

マルチマスター構成には、次の利点があります。

1 つのサプライヤにアクセスできなくなった場合でも、自動的に書き込み処理のフェイルオーバが実行される

地域分散型環境のローカルサプライヤで更新処理を実行できる

注
レプリケーションの中でも特にマルチマスターレプリケーションは、地域分散型環境で使用される WAN のような接続速度の遅い接続方式ではなく、より高速な接続方式で使用する方が効果的です。

図 8-3    マルチマスターレプリケーションの詳細

図 8-3 の例では、変更処理で ou=people,dc=siroe,dc=com 接尾辞を常に使用できるようにするために、この接尾辞を 2 つのサプライヤサーバにマスターとして保持します。各サプライヤサーバは、自身の更新履歴ログを管理します。マスターの 1 つがクライアントからの変更要求を処理した場合は、その処理が更新履歴ログに記録され、レプリケーション更新がほかのサプライヤサーバおよびコンシューマに送信されます。
このため、サプライヤサーバでは、コンシューマサーバとのレプリケーションアグリーメントだけでなく互いのレプリケーションアグリーメントを保持する必要があります。各サプライヤサーバには、ほかのマスターがレプリケーション更新を提供するためにバインドできるようにバインド DN も保存されます。
この例では、各コンシューマサーバに、サプライヤバインド DN に対応する 2 つのエントリが格納されるので、レプリケーション更新を送信するためにバインドするときにサプライヤを認証できます。それぞれのコンシューマに、サプライヤバインド DN のエントリを 1 つだけ格納することも可能です。この場合、両方のサプライヤは、同じサプライヤバインド DN を使用してバインドします。
マルチマスターレプリケーションでは、コンシューマがクライアントから変更要求を受け取った場合、両方のサプライヤに対するレフェラルがクライアントに返されます。

注
コンシューマサーバには、サプライヤサーバについてのレフェラル情報が格納されます。コンシューマサーバは、クライアントからの変更要求をサプライヤに転送しません。クライアントは、コンシューマによって返されたレフェラルに従う必要があります。

2 つのサプライヤサーバおよび 2 つのコンシューマサーバからなるマルチマスターレプリケーションの設定方法については、「マルチマスターレプリケーションの構成」を参照してください。

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

カスケード型レプリケーションモデルでは、しばしばハブサプライヤと呼ばれる 1 つのサーバが特定のレプリカに対してコンシューマとサプライヤの両方の役割を受け持ちます。このサーバは、データのマスターコピーを保持するサプライヤサーバから更新を受け取り、次にコンシューマにこの更新を供給します。カスケード型レプリケーションは、次の場合に便利です。

過大なトラフィック負荷の均衡を図る必要がある場合。たとえば、サプライヤサーバですべての更新トラフィックを処理しなければならないため、そのことで、コンシューマに対するすべてのレプリケーショントラフィックもサポートするために、サプライヤサーバに過度の負荷がかかってしまうとき。多数のコンシューマに対するレプリケーション更新を実行可能なハブサーバに、レプリケーショントラフィックを任せることにより負荷を軽減できる

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

ディレクトリサービスの性能を向上させたい場合。読み取り操作を実行するすべてのクライアントアプリケーションをコンシューマで実行させ、更新処理を実行するアプリケーションをサプライヤに実行させると、ハブサーバからすべてのインデックス (システムインデックスを除く) を削除できる。これにより、サプライヤとハブサーバ間のレプリケーションの速度が飛躍的に向上する
図 8-4 は、カスケード型レプリケーションの例を示したものです。この例では、もっとも単純なカスケード型レプリケーションモデルを示しています。複数のハブサプライヤおよび多数のコンシューマを含む、さらに複雑なモデルを作成することも可能です。
図 8-4    カスケード型レプリケーション

図 8-4 に示した例では、ハブサプライヤを使ってレプリケーション更新処理をサプライヤサーバとハブサプライヤに分散することにより、レプリケーション更新の負荷の均衡を図っています。
サプライヤサーバとハブサプライヤサーバは、いずれも更新履歴ログを管理します。ただし、クライアントからの変更要求を直接処理できるのは、サプライヤサーバだけです。
コンシューマサーバおよびハブサプライヤは、クライアントからの検索要求を処理できますが、変更要求の場合には、サプライヤサーバへのレフェラルをクライアントに返します。図 8-4 は、コンシューマサーバ C および D にサプライヤサーバ A へのレフェラルが設定されていることを示しています。これらは、コンシューマレプリカの構成中にサプライヤサーバを指定したときに作成された自動レフェラルです。

注
コンシューマサーバおよびハブサプライヤには、サプライヤサーバのレフェラル情報が格納されます。これらのサーバは、クライアントからの変更要求をサプライヤに転送しません。クライアントは、コンシューマによって返されたレフェラルに従う必要があります。

カスケード型レプリケーションの構成方法については、「カスケード型レプリケーションの構成」を参照してください。

注
マルチマスターレプリケーションとカスケード型レプリケーションを組み合わせて使用することもできます。たとえば、図 8-3 のマルチマスターモデルでは、サーバ C とサーバ D を、ハブサプライヤとして構成することにより、任意の数のコンシューマサーバにそれらのサーバからレプリケーションを実行できます。

複雑なレプリケーション構成手順のまとめ

レプリケーションを構成するサーバが多数存在し、レプリケーションが比較的複雑な構成をとる場合、設定作業の効率を高めるためには、次の手順で作業を進めてください。

すべてのコンシューマサーバ上で次の操作を行います。

レプリカデータベースの作成

少なくとも 1 つのレプリケーションマネージャまたはサプライヤバインド DN エントリの作成

コンシューマレプリカに対する設定の指定

すべてのハブサプライヤ上で次の操作を行います。

レプリカデータベースの作成

レプリケーションマネージャまたはサプライヤ DN エントリの作成

レプリケーションに対するサプライヤ設定の指定 (更新履歴ログの構成を含む)

ハブレプリカに対する設定の指定

すべてのサプライヤ上で次の操作を行います。

レプリカデータベースの作成

レプリケーションに対するサプライヤ設定の指定 (更新履歴ログの構成を含む)

サプライヤレプリカに対する設定の指定

次のすべてのサプライヤ上にレプリケーションアグリーメントを構成します。

マルチマスターセットのサプライヤ間

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

サプライヤとハブサプライヤの間

コンシューマサーバおよびハブサプライヤ上のレプリカの初期化は、この時点でも実行できます (任意)。マルチマスターレプリケーションの場合は、1 つのサプライヤレプリカを別のレプリカから初期化します。サプライヤレプリカ間の相互初期化を実行しないでください。

すべてのハブサプライヤ上で、ハブサプライヤと対応するコンシューマの間のレプリケーションアグリーメントを構成します。

コンシューマサーバ上のレプリカの初期化は、この時点でも実行できます (任意)。

注
以上の手順で重要なことは、レプリケーションアグリーメントを作成する前に、レプリカをすべて作成し、構成しておくことです。このことによって、レプリケーションアグリーメントの作成が完了すると、コンシューマレプリカをただちに初期化することができるようになります。コンシューマの初期化は、常にレプリケーションの設定の最後の段階で実行します。

レプリケーションのための作業の詳細

ここでは、レプリケーションを構成するために必要な処理について説明します。

サプライヤバインド DN エントリの作成

レプリケーションの設定において重要なことは、サプライヤがレプリケーションの更新を行うためにコンシューマサーバにバインドするときに使用するエントリの作成です。このエントリは、レプリケーションマネージャまたはサプライヤバインド DN エントリと呼ばれます。
サプライヤバインド DN エントリが満たす必要がある条件および特徴については、「レプリケーションの識別情報」を参照してください。
サプライヤバインド DN エントリを作成するには、次の手順を実行します。

レプリケーションアグリーメントでコンシューマとして動作する各サーバに、サプライヤがバインドするために使用する特別なエントリを作成します。

このエントリをレプリケートされたデータベースの一部にしないでください。ここでは例として、cn=Replication Manager,cn=config を使用します。エントリは、必ずレプリケーションアグリーメントで定めた認証方法に必要となる属性を含めて作成してください。

属性と値がペアになった userPassword を指定します。

パスワードの有効期限ポリシーを有効にしているか、将来有効にする場合は、パスワードの期限切れによってレプリケーションが失敗しないように、このポリシーを忘れずに無効にしてください。userPassword 属性でパスワードの有効期限ポリシーを無効にするには、passwordExpirationTime 属性に 20380119031407Z という値を追加します。こうするとパスワードの有効期限が切れなくなります。
コンシューマレプリカを構成する場合は、このエントリの DN を使用してサプライヤバインド DN を定義する必要があります。

注
サプライヤバインド DN は、アクセス制御の影響を受けない特権ユーザです。

サプライヤの構成

サプライヤレプリカまたはハブレプリカを保持するサーバでは、サプライヤ設定 (すなわち更新履歴ログパラメタ) を指定する必要があります。
サプライヤを構成するには、次の手順を実行します。

Directory Server Console で、「構成」タブをクリックします。

Directory Server Console の起動については、「iPlanet Directory Server Console の使用」を参照してください。

左側のナビゲーションツリーで、Replication ノードを選択します。

右側のナビゲーションウィンドウで、「サプライヤ設定」タブをクリックします。

「更新履歴ログを有効にする」チェックボックスを選択します。

これにより、ウィンドウの下の区画にある無効にされていたフィールドが有効になります。

「デフォルトの使用」ボタンをクリックするか、または「参照」をクリックしてファイルセレクタを表示し、更新履歴ログを指定します。

更新履歴ログのパラメタ (数および保存期間) を設定します。

別の値を指定する場合は、無期限のチェックボックスの選択を解除する必要があります。

「保存」をクリックして、Directory Server のサプライヤ設定を保存します。

サプライヤレプリカの構成

各サプライヤレプリカについて、適切なレプリケーション設定を指定する必要があります。
サプライヤレプリカを設定するには、次の手順を実行します。

Directory Server Console で、「構成」タブをクリックします。

Directory Server Console の起動については、「iPlanet Directory Server Console の使用」を参照してください。

左側のナビゲーションツリーで、Replication フォルダを展開し、レプリケーション対象のデータベースを選択します。

「レプリカの設定」タブが右側のナビゲーションウィンドウに表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「単一マスター」または「マルチマスター」ラジオボタンのいずれかを選択します。

「共通設定」セクションで、レプリカ ID (1 ～ 65534 の整数) を指定します。

各サプライヤレプリカのレプリカ ID は、一意である必要があります。このサーバおよびほかのサーバ上のほかのサプライヤレプリカで使用される ID とは異なる ID を指定するようにしてください。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

「保存」をクリックして、データベースに対するレプリケーション設定を保存します。

コンシューマレプリカの構成

各コンシューマレプリカについて、適切なレプリケーション設定を指定する必要があります。

Directory Server Console で、「構成」タブをクリックします。

Directory Server Console の起動については、「iPlanet Directory Server Console の使用」を参照してください。

左側のナビゲーションツリーで、Replication フォルダを展開し、レプリカデータベースを選択します。

「レプリカの設定」タブが右側のナビゲーションウィンドウに表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「専用コンシューマ」ラジオボタンを選択します。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

コンシューマに対してはレプリカ ID を指定する必要がないため、「レプリカ ID」フィールドは無効のままになります (このフィールドは、すべてのコンシューマレプリカで自動的に「65535」に設定されます)。

「設定の更新」セクションで、サプライヤがレプリカにバインドするために使用するサプライヤバインド DN (レプリケーションマネージャ DN) を指定します。

はじめてレプリカを構成する場合は、「現在のサプライヤ DN」のリストには何も表示されません。1 つのレプリカに対して複数のサプライヤバインド DN を指定できますが、1 つのレプリケーションアグリーメントには 1 つのサプライヤ DN しか指定できません。

新しいサプライヤバインド DN を指定するには、次の手順を実行します。

対応するフィールドに新しいサプライヤバインド DN を入力します。

ここで入力する DN は、コンシューマサーバで作成したエントリに対応していなければなりません (例 : cn=Replication Manager,cn=config)

「追加」をクリックします。

サプライヤバインド DN が「現在のサプライヤ DN」のリストに表示されます。

リストに含めたいすべてのサプライヤバインド DN で同じ操作を繰り返します。

更新の参照先として、サーバの LDAP URL を指定します。

はじめてレプリカを構成する場合は、「現在のレフェラルのレプリカデータのマスターを保持しているサーバの URL は表示されません (このレフェラルは、コンシューマサーバによって自動的に作成されます)。

自動レフェラルでは、クライアントが通常の接続を介してバインドするので、ldap://servername:port の形式であると想定しています。SSL を使用してクライアントをサプライヤにバインドする場合は、このフィールドを ldaps://servername:port の形式でレフェラルを指定するのに使用できます。ここで ldaps の s は、セキュリティで保護された接続を意味しています。

レフェラルの LDAP URL を指定すると、Directory Server では、最初にその URL で修正要求が照会されます。URL を指定しない場合は、現在のレプリカのサプライヤに修正要求が照会されます。

レフェラルの新しい URL を指定するには、次の手順を実行します。

対応するフィールドに新しい LDAP URL を入力します。または「構築」をクリックすると、LDAP URL の作成を支援するダイアログボックスが表示されます。

「追加」をクリックします。

「現在のレフェラルの URL」リストのすぐ上に、入力した LDAP URL が表示されます。

同じ操作を繰り返して、リストにレフェラルを追加します。

「保存」をクリックして、レプリケーションの設定を保存します。

ハブレプリカの構成

カスケード型レプリケーション環境で、ハブサプライヤを次のように構成します。

Directory Server Console で、「構成」タブをクリックします。

Directory Server Console の起動については、「iPlanet Directory Server Console の使用」を参照してください。

左側のナビゲーションツリーで、Replication フォルダを展開し、レプリケーション対象のデータベースを選択します。

「レプリカの設定」タブが右側のナビゲーションウィンドウに表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「ハブ」ラジオボタンを選択します。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

ハブサプライヤにレプリカ ID を指定する必要がないため、「レプリカ ID」フィールドは無効のままになります (このフィールドは、コンシューマレプリカと同じように自動的に「65535」に設定されます)。

「設定の更新」セクションで、サプライヤがハブレプリカへのバインドに使用するサプライヤバインド DN (レプリケーションマネージャ DN) を指定します。

はじめてレプリカを構成する場合は、「現在のサプライヤ DN」のリストには何も表示されません。1 つのレプリカに複数のサプライヤバインド DN を指定できますが、1 つのレプリケーションアグリーメントには 1 つのサプライヤ DN しか指定できません。

新しいサプライヤバインド DN を指定するには、次の手順を実行します。

対応するフィールドに新しいサプライヤバインド DN を入力します。

ここで入力する DN は、コンシューマサーバで作成したエントリに対応していなければなりません (例 : cn=Replication Manager,cn=config)

「追加」をクリックします。

サプライヤバインド DN が「現在のサプライヤ DN」リストのすぐ上に表示されます。

同じ操作を繰り返して、サプライヤバインド DN をリストに追加します。

更新の参照先として、サーバの LDAP URL を指定します。

はじめてレプリカを構成する場合は、「現在のレフェラルの URL」のリストには何も表示されません。デフォルトでは、このリストには、レプリカデータのマスターを保持しているサーバの URL は表示されません (このレフェラルは、ハブサーバによって自動的に作成されます)。

自動レフェラルでは、クライアントが通常の接続を介してバインドするので、ldap://servername:port の形式であることを想定しています。SSL を使用してクライアントをサプライヤにバインドする場合は、このフィールドに ldaps://servername:port の形式でレフェラルを指定する必要があります。ここで ldaps の s は、セキュリティで保護された接続を意味しています。

レフェラルの LDAP URL を指定すると、Directory Server では、最初にその URL で修正要求が照会されます。URL を指定しない場合は、現在のレプリカのサプライヤで修正要求が照会されます。

レフェラルの新しい URL を指定するには、次の手順を実行します。

対応するフィールドに新しい LDAP URL を入力します。または「構築」をクリックすると、LDAP URL の作成を支援するダイアログボックスが表示されます。

「追加」をクリックします。

「現在のレフェラルの URL」リストのすぐ上に、入力した LDAP URL が表示されます。

同じ操作を繰り返して、リストにレフェラルを追加します。

「保存」をクリックして、データベースに対するレプリケーション設定を保存します。

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

ここでは、レプリケーションアグリーメントの作成方法を説明します。レプリケーションアグリーメントは、サプライヤサーバ上で各コンシューマサーバやハブのサプライヤに供給されるサプライヤレプリカに対して作成しておく必要があります。
レプリケーションアグリーメントを作成する前に、次の手順を実行しておく必要があります。

「サプライヤの構成」の説明に従って、サプライヤをサーバに設定する

「サプライヤレプリカの構成」の説明に従って、サプライヤに対するレプリケーション設定を構成する

「ハブレプリカの構成」および「コンシューマレプリカの構成」の説明に従って、ハブサプライヤ (存在する場合) およびコンシューマに対するレプリケーションを設定する
レプリケーションアグリーメントを作成するには、次の手順を実行します。

Directory Server Console で、「構成」タブをクリックします。

ナビゲーションツリーで、レプリケートするデータベースをマウスの右ボタンでクリックし、「新規レプリケーションアグリーメント」を選択します。

または、データベースを選択して、「オブジェクト」メニューから「新規レプリケーションアグリーメント」を選択することもできます。この操作を行うと、レプリケーションアグリーメントウィザードが開始されます。

「次」をクリックしてステップを進め、レプリケーションウィザードの全ステップを完了します。

各フィールドへの入力方法については、オンラインヘルプを参照してください。

ウィザードが完了すると、レプリケーションアグリーメントを表すアイコンがデータベースアイコンの下に表示されます。このレプリケーションアグリーメントアイコンは、レプリケーションアグリーメントが設定されたことを示します。

注
SSL を経由したレプリケーションアグリーメントでは、コンシューマサーバのホスト名は完全指定によるドメイン名 (例えば、server.remote.siroe.com など) として指定する必要があります。エイリアス、IP アドレス、またはドメイン名のローカルの部分だけを指定しないでください。SSL を経由したレプリケーションが許可されなくなります。さらに、「man-in-the-middle」による攻撃からレプリケーションを保護できなくなります。
デフォルトでは、サプライヤはコンシューマサーバの証明書のあるパスを有効にします。サプライヤの信頼するCA (認証局) のルートストアは、SSL を経由したレプリケーションまたはクライアント認証に使用されている CA からの証明書のみである必要があります。SSL を経由したレプリケーションで、「man-in-the-middle」による攻撃から保護するため、コンシューマサーバの証明書に CN 属性にサブジェクト識別名があるか、拡張子が完全指定によるドメイン名と一致することが分っている場合、nsSslServerAuth 構成属性は cncheck 値を持つ必要があります。

単一マスターレプリケーションの構成

ここでは、単一マスターレプリケーションの構成方法の手順を説明します。図 8-1 に示すように、サプライヤレプリカを保持するサプライヤサーバ A とコンシューマレプリカを保持するコンシューマサーバ B の間に単一マスターレプリケーションを設定するには、次の手順を実行します。

コンシューマサーバ (サプライヤバインド DN とオプションで変更要求のレフェラル) およびコンシューマレプリカを構成します

この手順については、「コンシューマサーバおよびレプリカの構成」を参照してください。

サプライヤサーバ (更新履歴ログとレプリカ ID) およびサプライヤレプリカを構成します。

この手順については、「サプライヤサーバおよびレプリカの構成」を参照してください。

コンシューマサーバ上のレプリカを初期化します。

この手順については、「単一マスターレプリケーションにおけるレプリカの初期化」を参照してください。

コンシューマサーバおよびレプリカの構成

レプリカの対象となるデータベースがない場合は、これを作成します。

手順については、「接尾辞の作成」を参照してください。

コンシューマサーバ上に、サプライヤバインド DN に対応するエントリがない場合は、これを作成します。これは、サプライヤがバインドするために使用する特別なエントリです。

Directory Server Console で、「属性名」タブをクリックし、エントリを作成します。ここでは例として、cn=Replication Manager,cn=config を使用します。

属性と値がペアになった userPassword を指定します。

パスワードの有効期限ポリシーを有効にしているか、将来有効にする場合は、パスワードの期限切れによりレプリケーションが失敗しないように、このポリシーを忘れずに無効にしてください。userPassword 属性でパスワードの有効期限ポリシーを無効にするには、passwordExpirationTime 属性に 20380119031407Z という値を追加します。こうするとパスワードの有効期限が切れなくなります。

注
サプライヤバインド DN は、アクセス制御の影響を受けない特権ユーザです。このエントリをレプリケートされたデータベースの一部にしないでください。

コンシューマレプリカに必要なレプリケーション設定を指定します。

Directory Server Console で、「構成」タブをクリックします。

ナビゲーションツリーで、Replication フォルダを展開し、レプリカデータベースを選択します。

「レプリカの設定」タブがウィンドウの右側に表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「専用コンシューマ」ラジオボタンを選択します。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

コンシューマにレプリカ ID を指定する必要がないため、「レプリカ ID」フィールドは無効のままになります (このフィールドは、すべてのコンシューマレプリカで自動的に「65535」に設定されます)。

「設定の更新」セクションで、サプライヤがレプリカにバインドするために使用するバインド DN (レプリケーションマネージャ DN) を指定します。

はじめてレプリカを構成する場合は、「現在のサプライヤ DN」のリストには何も表示されません。1 つのレプリカに複数のサプライヤバインド DN を指定できますが、1 つのレプリケーションアグリーメントには 1 つのサプライヤ DN しか指定できません。

新しいサプライヤバインド DN を指定するには、次の手順を実行します。

対応するフィールドに新しいサプライヤバインド DN を入力します。ここで入力する DN は、手順 2 で作成したエントリに対応していなければなりません (例 : cn=Replication Manager,cn=config)

「追加」をクリックします。サプライヤバインド DN が「現在のサプライヤ DN」リストのすぐ上に表示されます。

同じ操作を繰り返して、サプライヤバインド DN をリストに追加します。

更新の参照先として、サーバの LDAP URL を指定します (任意)。

はじめてレプリカを構成する場合は、「現在のレフェラルの URL」のリストには何も表示されません。デフォルトでは、このリストには、レプリカデータのマスターを保持しているサーバの URL は表示されません (このレフェラルは、サーバによって自動的に作成されます)。

自動レフェラルでは、クライアントが通常の接続を介してバインドするので、ldap://servername:port の形式であることを想定しています。SSL を使用してクライアントをサプライヤにバインドする場合は、このフィールドに ldaps://servername:port の形式でレフェラルを指定する必要があります。ここで ldaps の s は、セキュリティで保護された接続を意味しています。

レフェラルに LDAP URL を指定すると、Directory Server では、最初にその URL で更新要求が照会されます。指定しない場合は、現在のレプリカのサプライヤで更新が照会されます。

レフェラルの新しい URL を指定するには、次の手順を実行します。

対応するフィールドに新しい LDAP URL を入力します。または「構築」をクリックすると、LDAP URL の作成を支援するダイアログボックスが表示されます。

「追加」をクリックします。「現在のレフェラルの URL」リストのすぐ上に、入力した LDAP URL が表示されます。

同じ操作を繰り返して、リストにレフェラルを追加します。

「保存」をクリックして、レプリケーションの設定を保存します。

サプライヤサーバおよびレプリカの構成

サーバに対するサプライヤ設定を指定します。

Directory Server Console で、「構成」タブをクリックします。

ナビゲーションツリーで、Replication ノードを選択します。

ウィンドウの右側にある「サプライヤ設定」タブの「更新履歴ログを有効にする」チェックボックスを選択します。

これにより、ウィンドウの下の区画の無効にされていたフィールドが有効になります。

「デフォルトの使用」ボタンをクリックするか、または「参照」ボタンをクリックしてファイルセレクタを表示し、更新履歴ログを指定します。

更新履歴ログのパラメタ (数および保存期間) を設定します。

別の値を指定する場合は、無期限のチェックボックスの選択を解除する必要があります。

「保存」をクリックして、サプライヤ設定を保存します。

サプライヤレプリカに必要なレプリケーション設定を指定します。

「構成」タブのナビゲーションツリーで、Replication ノードを展開し、レプリケーション対象のデータベースを選択します。

「レプリカの設定」タブがウィンドウの右側に表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「単一マスター」ラジオボタンを選択します。

「共通設定」セクションで、レプリカ ID (1 ～ 65534 の整数) を指定します。

各サプライヤレプリカのレプリカ ID は、一意である必要があります。このサーバおよびほかのサーバ上のほかのサプライヤレプリカで使用される ID とは異なる ID を指定するようにしてください。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

「保存」をクリックして、データベースに対するレプリケーション設定を保存します。

このサプライヤとコンシューマ間のレプリケーションアグリーメントを作成します。

「構成」タブのナビゲーションツリーで、レプリケートするデータベースをマウスの右ボタンでクリックし、「新規レプリケーションアグリーメント」を選択します。

または、データベースを選択して、「オブジェクト」メニューから「新規レプリケーションアグリーメント」を選択することもできます。この操作を行うと、レプリケーションアグリーメントウィザードが開始されます。

「次」をクリックしてステップを進め、レプリケーションウィザードの全ステップを完了します。

各フィールドへの入力方法については、オンラインヘルプを参照してください。

ウィザードが完了すると、レプリケーションアグリーメントが設定されます。

単一マスターレプリケーションにおけるレプリカの初期化

コンシューマレプリカは、レプリケーションアグリーメントウィザードから初期化することができ、その後ならいつでも可能です。レプリカの初期化については、「コンシューマの初期化」を参照してください。

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

ここでは、マルチマスターレプリケーションの構成方法について説明します。マルチマスター構成では、2 つのサプライヤが更新を受け取り、互いに同期をとりすべてのコンシューマを更新することができます。コンシューマは、両方のマスターに更新要求を照会できます。ここでは、マルチマスターレプリケーションの設定手順について説明します。
図 8-2 のように、それぞれがサプライヤレプリカを保持するサーバ A とサーバ B という 2 つのサプライヤ、およびそれぞれがコンシューマレプリカを保持するサーバ C とサーバ D という 2 つのコンシューマといった、マルチマスターレプリケーションを設定するには、次の処理を実行します。

コンシューマサーバ (サプライヤバインド DN およびオプションで変更要求のレフェラル) およびコンシューマレプリカを構成します

この手順については、「コンシューマサーバおよびレプリカの構成」を参照してください。

サプライヤサーバ (更新履歴ログとレプリカ ID) およびサプライヤレプリカを構成します。

この手順については、「サプライヤサーバおよびレプリカの構成」を参照してください。

コンシューマサーバ上のコンシューマレプリカを初期化します。

この手順については、「マルチマスターレプリケーションにおけるレプリカの初期化」を参照してください。

コンシューマサーバおよびレプリカの構成

各コンシューマサーバに対して、次の手順を実行します。

レプリカの対象となるデータベースがない場合は、これを作成します。

手順については、「接尾辞の作成」を参照してください。

サプライヤバインド DN に対応するエントリがない場合は、これを作成します。これは、サプライヤがバインドするために使用する特別なエントリです。

Directory Server Console で、「属性名」タブをクリックし、エントリを作成します。ここでは例として、cn=Replication Manager,cn=config を使用します。

属性と値がペアになった userPassword を指定します。

パスワードの有効期限ポリシーを有効にしているか、将来有効にする場合は、パスワードの期限切れによってレプリケーションが失敗しないように、このポリシーを忘れずに無効にしてください。userPassword 属性でパスワードの有効期限ポリシーを無効にするには、passwordExpirationTime 属性に 20380119031407Z という値を追加します。こうするとパスワードの有効期限が切れなくなります。

注
サプライヤバインド DN は、アクセス制御の影響を受けない特権ユーザです。このエントリをレプリケートされたデータベースの一部にしないでください。

コンシューマレプリカに必要なレプリケーション設定を指定します。

Directory Server Console で、「構成」タブをクリックします。

ナビゲーションツリーで、Replication フォルダを展開し、レプリカデータベースを選択します。

「レプリカの設定」タブがウィンドウの右側に表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「専用コンシューマ」ラジオボタンを選択します。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

コンシューマにレプリカ ID を指定する必要がないため、「レプリカ ID」フィールドは無効のままになります (このフィールドは、すべてのコンシューマレプリカで自動的に「65535」に設定されます)。

「設定の更新」セクションで、サプライヤがレプリカにバインドするために使用するバインド DN (レプリケーションマネージャ DN) を指定します。

はじめてレプリカを構成する場合は、「現在のサプライヤ DN」のリストには何も表示されません。1 つのレプリカに複数のサプライヤバインド DN を指定できますが、1 つのレプリケーションアグリーメントには 1 つのサプライヤ DN しか指定できません。

新しいサプライヤバインド DN を指定するには、次の手順を実行します。

対応するフィールドに新しいサプライヤバインド DN を入力します。ここで入力する DN は、手順 2 で作成したエントリに対応していなければなりません (例 : cn=Replication Manager,cn=config)

「追加」をクリックします。サプライヤバインド DN が「現在のサプライヤ DN」リストのすぐ上に表示されます。

同じ操作を繰り返して、サプライヤバインド DN をリストに追加します。

更新の参照先として、サーバの LDAP URL を指定します (任意)。

はじめてレプリカを構成する場合は、「現在のレフェラルの URL」のリストには何も表示されません。デフォルトでは、このリストには、レプリカデータのマスターを保持しているサーバの URL は表示されません (このレフェラルは、コンシューマサーバによって自動的に作成されます)。

自動レフェラルでは、クライアントが通常の接続を介してバインドするので、ldap://servername:port の形式であると想定しています。SSL を使用してクライアントをサプライヤにバインドする場合は、このフィールドに ldaps://servername:port の形式でレフェラルを指定する必要があります。ここで ldaps の s は、セキュリティで保護された接続を意味しています。

レフェラルに LDAP URL を指定すると、Directory Server では、最初にその URL で更新要求が照会されます。指定しない場合は、現在のレプリカのサプライヤで更新が照会されます。

レフェラルの新しい URL を指定するには、次の手順を実行します。

対応するフィールドに新しい LDAP URL を入力します。または「構築」をクリックすると、LDAP URL の作成を支援するダイアログボックスが表示されます。

「追加」をクリックします。「現在のレフェラルの URL」リストのすぐ上に、入力した LDAP URL が表示されます。

同じ操作を繰り返して、リストにレフェラルを追加します。

「保存」をクリックして、レプリケーションの設定を保存します。
レプリケーション構成におけるすべてのコンシューマサーバに対して上記の手順を繰り返します。

サプライヤサーバおよびレプリカの構成

各サプライヤサーバに対して、次の手順を実行します。

サーバ A およびサーバ B 上で、サーバに対するサプライヤ設定を指定します。

Directory Server Console で、「構成」タブをクリックします。

ナビゲーションツリーで、Replication ノードを選択します。

ウィンドウの右側にある「サプライヤ設定」タブをクリックします。

「更新履歴ログを有効にする」チェックボックスを選択します。

これにより、ウィンドウの下の区画の無効にされていたフィールドが有効になります。

「デフォルトの使用」ボタンをクリックするか、または「参照」ボタンをクリックしてファイルセレクタを表示し、更新履歴ログを指定します。

更新履歴ログのパラメタ (数および保存期間) を設定します。

別の値を指定する場合は、無期限のチェックボックスの選択を解除する必要があります。

「保存」をクリックして、サプライヤ設定を保存します。

サプライヤバインド DN に対応するエントリがない場合は、これを作成します。マルチマスターレプリケーションでは、レプリケーションがほかのサプライヤサーバに対してコンシューマとサプライヤの両方の役割を果たすため、サプライヤサーバ (と同様にコンシューマ) にこのサプライヤバインド DN を作成する必要があります。

Directory Server Console で、「属性名」タブをクリックし、エントリを作成します。ここでは例として、cn=Replication Manager,cn=config を使用します。

属性と値がペアになった userPassword を指定します。

パスワードの有効期限ポリシーを有効にしているか、将来有効にする場合は、パスワードの期限切れによってレプリケーションが失敗しないように、このポリシーを忘れずに無効にしてください。userPassword 属性でパスワードの有効期限ポリシーを無効にするには、passwordExpirationTime 属性に 20380119031407Z という値を追加します。こうするとパスワードの有効期限が切れなくなります。

注
サプライヤバインド DN は、アクセス制御の影響を受けない特権ユーザです。このエントリをレプリケートされたデータベースの一部にしないでください。

サーバ A およびサーバ B 上で、マルチマスターサプライヤレプリカに必要なレプリケーション設定を指定します。

「構成」タブのナビゲーションツリーで、Replication ノードを展開し、レプリケーション対象のデータベースを選択します。

「レプリカの設定」タブがウィンドウの右側に表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「複数マスター」ラジオボタンを選択します。

「共通設定」セクションで、レプリカ ID (1 ～ 65534 の整数) を指定します。

各サプライヤレプリカのレプリカ ID は、一意である必要があります。このサーバおよびほかのサーバ上の他のサプライヤレプリカで使用される ID とは異なる ID を指定するようにしてください。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

「設定の更新」セクションで、サプライヤがレプリカにバインドするために使用するバインド DN (レプリケーションマネージャ DN) を指定します。

はじめてレプリカを構成する場合は、「現在のサプライヤ DN」の一覧には何も表示されません。1 つのレプリカに複数のサプライヤバインド DN を指定できますが、1 つのレプリケーションアグリーメントには 1 つのサプライヤ DN しか指定できません。

新しいサプライヤバインド DN を指定するには、次の手順を実行します。

対応するフィールドに新しいサプライヤバインド DN を入力します。ここで入力する DN は、手順 2 で作成したエントリに対応していなければなりません (例 : cn=Replication Manager,cn=config)

「追加」をクリックします。サプライヤバインド DN が「現在のサプライヤ DN」リストのすぐ上に表示されます。

同じ操作を繰り返して、サプライヤバインド DN をリストに追加します。

注
サプライヤサーバでは、レフェラルの LDAP URL を指定する必要はありません。

「保存」をクリックして、データベースに対するレプリケーション設定を保存します。

サーバ A 上で、次のレプリケーションアグリーメントを設定します。

サプライヤサーバ B との契約。サーバ B がレプリカのコンシューマとして構成される

サーバ C およびサーバ D の各コンシューマのための契約

「構成」タブのナビゲーションツリーで、レプリケートするデータベースをマウスの右ボタンでクリックし、「新規レプリケーションアグリーメント」を選択します。

または、データベースを選択して、「オブジェクト」メニューから「新規レプリケーションアグリーメント」を選択することもできます。この操作を行うと、レプリケーションアグリーメントウィザードが開始されます。

「次」をクリックしてステップを進め、レプリケーションウィザードの全ステップを完了します。

各フィールドへの入力方法については、オンラインヘルプを参照してください。

サーバ B 上のコンシューマレプリカおよびサプライヤレプリカは、レプリケーションアグリーメントウィザードから初期化することができ、その後ならいつでも可能です。コンシューマレプリカの初期化の順序および手順については、「マルチマスターレプリケーションにおけるレプリカの初期化」および「コンシューマの初期化」を参照してください。

ウィザードが完了すると、レプリケーションアグリーメントが設定されます。

サーバ B 上で、次のレプリケーションアグリーメントを設定します。

サプライヤサーバ A との契約。サーバ A がレプリカのコンシューマとして宣言される。手順 4 でサーバ A からサーバ B を初期化している場合は、この処理中にサーバ B からサーバ A を初期化してはならない

サーバ C およびサーバ D の各コンシューマのための契約

注
上記の手順を完了すると、サーバ A およびサーバ B には相互レプリケーションアグリーメントが作成されます。つまり相互の更新処理が可能になります。

サプライヤレプリカを保持するサーバ、必要なレプリケーションアグリーメント、およびコンシューマレプリカを保持するサーバを構成したら、レプリケーションを初期化することが準備できます。この作業は、サプライヤサーバ上にレプリケーションアグリーメントを作成するとき、またはそれ以降に実行できます。

マルチマスターレプリケーションにおけるレプリカの初期化

マルチマスターレプリケーションの場合、次の順序でレプリカを初期化する必要があります。

1 つのマスターが、レプリケーション対象の完全なデータセットを保持していることを確認します。このマスターを使用して、マルチマスターレプリケーションセットのほかのマスター上のサプライヤレプリカを初期化します。

コンシューマサーバ上のコンシューマレプリカを、2 つのマスターのうちのどれか 1 つから初期化します。
レプリカの初期化については、「コンシューマの初期化」を参照してください。

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

ここでは、カスケード型レプリケーションの設定について説明します。カスケード型レプリケーションモデルでは、サプライヤサーバは中間サーバ (ハブサーバと呼ばれる) を更新します。次に中間サーバは 1 つまたは複数のコンシューマサーバを更新します。ここでは、カスケード型レプリケーションの設定手順について説明します。
図 8-4 に示す構成のように、サーバ A 上のサプライヤ、ハブサーバ B、およびコンシューマサーバ C 間にカスケード型レプリケーションを設定するには、次の手順を実行します。

コンシューマサーバ (サプライヤバインド DN とオプションで変更要求のレフェラル) およびコンシューマレプリカを構成します

この手順については、「コンシューマサーバおよびレプリカの構成」を参照してください。

ハブサプライヤ (更新履歴ログ、サプライヤバインド DN、およびオプションで変更要求のレフェラル) およびハブレプリカを構成します

この手順については、「ハブサプライヤおよびレプリカの構成」を参照してください。

サプライヤサーバ (更新履歴ログとレプリカ ID) およびサプライヤレプリカを構成します。

この手順については、「サプライヤサーバおよびレプリカの構成」を参照してください。

サプライヤサーバおよびハブサプライヤ上にレプリケーションアグリーメントを構成します。

この手順については、「レプリケーションアグリーメントの構成」を参照してください。

ハブサプライヤおよびコンシューマサーバ上のレプリカを初期化します。

この手順については、「カスケード型レプリケーションでのレプリカの初期化」を参照してください。

コンシューマサーバおよびレプリカの構成

コンシューマサーバ上に、レプリカの対象となるデータベースがない場合は、これを作成します。

手順については、「接尾辞の作成」を参照してください。

コンシューマサーバ上に、サプライヤバインド DN に対応するエントリがない場合は、これを作成します。これは、サプライヤがバインドするために使用する特別なエントリです。

Directory Server Console で、「属性名」タブをクリックし、エントリを作成します。ここでは例として、cn=Replication Manager,cn=config を使用します。

属性と値がペアになった userPassword を指定します。

パスワードの有効期限ポリシーを有効にしているか、将来有効にする場合は、パスワードの期限切れによってレプリケーションが失敗しないように、このポリシーを忘れずに無効にしてください。userPassword 属性でパスワードの有効期限ポリシーを無効にするには、passwordExpirationTime 属性に 20380119031407Z という値を追加します。こうするとパスワードの有効期限が切れなくなります。

注
サプライヤバインド DN は、アクセス制御の影響を受けない特権ユーザです。このエントリをレプリケートされたデータベースの一部にしないでください。

コンシューマサーバ上に、コンシューマレプリカに対するレプリケーション設定を指定します。

Directory Server Console で、「構成」タブをクリックします。

ナビゲーションツリーで、Replication フォルダを展開し、レプリカデータベースを選択します。

「レプリカの設定」タブがウィンドウの右側に表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「専用コンシューマ」ラジオボタンを選択します。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

コンシューマにレプリカ ID を指定する必要がないため、「レプリカ ID」フィールドは無効のままになります (このフィールドは、すべてのコンシューマレプリカで自動的に「65535」に設定されます)。

「設定の更新」セクションで、サプライヤがレプリカにバインドするために使用するバインド DN (レプリケーションマネージャ DN) を指定します。

はじめてレプリカを構成する場合は、「現在のサプライヤ DN」のリストには何も表示されません。1 つのレプリカに複数のサプライヤバインド DN を指定できますが、1 つのレプリケーションアグリーメントには 1 つのサプライヤ DN しか指定できません。

新しいサプライヤバインド DN を指定するには、次の手順を実行します。

対応するフィールドに新しいサプライヤバインド DN を入力します。ここで入力する DN は、手順 2 で作成したエントリに対応していなければなりません (例 : cn=Replication Manager,cn=config)

「追加」をクリックします。サプライヤバインド DN が「現在のサプライヤ DN」リストのすぐ上に表示されます。

同じ操作を繰り返して、サプライヤバインド DN をリストに追加します。

更新の参照先として、サーバの LDAP URL を指定します (省略可能)。

はじめてレプリカを構成する場合は、「現在のレフェラルの URL」のリストには何も表示されません。デフォルトでは、このリストには、レプリカデータのマスターを保持しているサーバの URL は表示されません (このレフェラルは、コンシューマサーバによって自動的に作成されます)。

自動レフェラルでは、クライアントが通常の接続を介してバインドするので、ldap://servername:port の形式であることを想定しています。SSL を使用してクライアントをサプライヤにバインドする場合は、このフィールドに ldaps://servername:port の形式でレフェラルを指定する必要があります。ここで ldaps の s は、セキュリティで保護された接続を意味しています。

レフェラルに LDAP URL を指定すると、Directory Server では、最初にその URL で更新要求が照会されます。指定しない場合は、現在のレプリカのサプライヤで更新が照会されます。

レフェラルの新しい URL を指定するには、次の手順を実行します。

対応するフィールドに新しい LDAP URL を入力します。または「構築」をクリックすると、LDAP URL の作成を支援するダイアログボックスが表示されます。

「追加」をクリックします。「現在のレフェラルの URL」リストのすぐ上に、入力した LDAP URL が表示されます。

同じ操作を繰り返して、リストにレフェラルを追加します。

「保存」をクリックして、レプリケーションの設定を保存します。

ハブサプライヤおよびレプリカの構成

マスターからレプリケーションの更新を受け取り、それらをコンシューマに伝達するハブサプライヤ上で、次の手順を実行します。

レプリカの対象となるデータベースがない場合は、これを作成します。

手順については、「接尾辞の作成」を参照してください。

サプライヤバインド DN に対応するエントリがない場合は、これを作成します。これは、サプライヤがバインドするために使用する特別なエントリです。

Directory Server Console で、「属性名」タブをクリックし、エントリを作成します。ここでは例として、cn=Replication Manager,cn=config を使用します。

属性と値がペアになった userPassword を指定します。

パスワードの有効期限ポリシーを有効にしているか、将来有効にする場合は、パスワードの期限切れによってレプリケーションが失敗しないように、このポリシーを忘れずに無効にしてください。userPassword 属性でパスワードの有効期限ポリシーを無効にするには、passwordExpirationTime 属性に 20380119031407Z という値を追加します。こうするとパスワードの有効期限が切れなくなります。

注
サプライヤバインド DN は、アクセス制御の影響を受けない特権ユーザです。このエントリをレプリケートされたデータベースの一部にしないでください。

ハブレプリカに対するレプリケーション設定を指定します。

Directory Server Console で、「構成」タブをクリックします。

ナビゲーションツリーで、Replication フォルダを展開し、レプリカデータベースを選択します。

「レプリカの設定」タブがウィンドウの右側に表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「ハブ」ラジオボタンを選択します。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

ハブサプライヤにレプリカ ID を指定する必要はないため、「レプリカ ID」フィールドは無効のままになります (このフィールドは、コンシューマレプリカと同じように自動的に「65535」に設定されます)。

「設定の更新」セクションで、サプライヤがレプリカにバインドするために使用するバインド DN (レプリケーションマネージャ DN) を指定します。

はじめてレプリカを構成する場合は、「現在のサプライヤ DN」のリストには何も表示されません。1 つのレプリカに複数のサプライヤバインド DN を指定できますが、1 つのレプリケーションアグリーメントには 1 つのサプライヤ DN しか指定できません。

新しいサプライヤバインド DN を指定するには、次の手順を実行します。

対応するフィールドに新しいサプライヤバインド DN を入力します。ここで入力する DN は、手順 2 で作成したエントリに対応していなければなりません (例 : cn=Replication Manager,cn=config)

「追加」をクリックします。サプライヤバインド DN が「現在のサプライヤ DN」リストのすぐ上に表示されます。

同じ操作を繰り返して、サプライヤバインド DN をリストに追加します。

更新の参照先として、サーバの LDAP URL を指定します (任意)。

はじめてレプリカを構成する場合は、「現在のレフェラルの URL」のリストには何も表示されません。デフォルトでは、このリストには、レプリカデータのマスターを保持しているサーバの URL は表示されません (このレフェラルは、ハブサーバによって自動的に作成されます)。

自動レフェラルでは、クライアントが通常の接続を介してバインドするので、ldap://servername:port の形式であることを想定しています。SSL を使用してクライアントをサプライヤにバインドする場合は、このフィールドに ldaps://servername:port の形式でレフェラルを指定する必要があります。ここで ldaps の s は、セキュリティで保護された接続を意味しています。

レフェラルの LDAP URL を指定すると、Directory Server は、最初にその URL で変更要求を照会します。URL を指定しない場合は、現在のレプリカのサプライヤで変更要求が照会されます。

レフェラルの新しい URL を指定するには、次の手順を実行します。

対応するフィールドに新しい LDAP URL を入力します。または「構築」をクリックすると、LDAP URL の作成を支援するダイアログボックスが表示されます。

「追加」をクリックします。「現在のレフェラルの URL」リストのすぐ上に、入力した LDAP URL が表示されます。

同じ操作を繰り返して、リストにレフェラルを追加します。

「保存」をクリックして、レプリカの設定を保存します。

サプライヤサーバおよびレプリカの構成

データベースの元のコピーを保持するサプライヤサーバ上で、次の手順を実行します。

サーバに対するサプライヤ設定を指定します。

Directory Server Console で、「構成」タブをクリックします。

ナビゲーションツリーで、Replication ノードを選択します。

ウィンドウの右側にある「サプライヤ設定」タブをクリックします。

「更新履歴ログを有効にする」チェックボックスを選択します。

これにより、ウィンドウの下の区画の無効にされていたフィールドが有効になります。

「デフォルトの使用」ボタンをクリックするか、または「参照」ボタンをクリックしてファイルセレクタを表示し、更新履歴ログを指定します。

更新履歴ログのパラメタ (数および保存期間) を設定します。

別の値を指定する場合は、無期限のチェックボックスの選択を解除する必要があります。

「保存」をクリックして、サプライヤ設定を保存します。

必要なレプリケーション設定を指定します。

「構成」タブのナビゲーションツリーで、Replication ノードを展開し、レプリケーション対象のデータベースを選択します。

「レプリカの設定」タブがウィンドウの右側に表示されます。

「レプリカを有効にする」チェックボックスを選択します。

「レプリカロール」セクションの「単一マスター」ラジオボタンを選択します。

「共通設定」セクションで、レプリカ ID (1 ～ 65534 の整数) を指定します。

各サプライヤレプリカのレプリカ ID は、一意である必要があります。このサーバおよびほかのサーバ上の他のサプライヤレプリカで使用される ID とは異なる ID を指定するようにしてください。

「共通設定」セクションの「パージ遅延」フィールドにパージ遅延を指定します。

このオプションは、レプリケートされたエントリに状態情報を格納する期間を示します。パージ前の遅延期間は、レプリケーションのシャットダウンまたはエラーと復元に必要な長さで、同時にエントリに過度に多くのデータを保持させない長さにする必要があります。デフォルト値は 1 週間です。

「保存」をクリックして、データベースに対するレプリケーション設定を保存します。

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

カスケード型のレプリケーション環境を構成する場合は、まず次の順序でレプリケーションアグリーメントを作成する必要があります。

最初にサプライヤサーバでサプライヤとハブサプライヤ間のレプリケーションを定義する

次にハブサプライヤでハブサプライヤとコンシューマ間のレプリケーションを定義する
この順序で操作を実行することにより、レプリケーションアグリーメントの作成時に、ハブサプライヤ上のレプリカおよびコンシューマ上のレプリカを初期化することもできます。

サプライヤサーバ上に、このサーバとハブサプライヤの間のレプリケーションアグリーメントを設定します。

「構成」タブのナビゲーションツリーで、レプリケートするデータベースをマウスの右ボタンでクリックし、「新規レプリケーションアグリーメント」を選択します。

または、データベースを選択して、「オブジェクト」メニューから「新規レプリケーションアグリーメント」を選択することもできます。この操作を行うと、レプリケーションアグリーメントウィザードが開始されます。

「次」をクリックしてステップを進め、レプリケーションウィザードの全ステップを完了します。

各フィールドへの入力方法については、オンラインヘルプを参照してください。

この時点以降、ハブサプライヤ上のレプリカを初期化できます。レプリカを後で初期化する場合の手順については、「コンシューマの初期化」を参照してください。

ハブサプライヤとコンシューマの間のレプリケーションアグリーメントを、ハブのサプライヤ上に設定します。

手順 1 と同じ手順を実行します。レプリケーションウィザードからコンシューマサーバ上のレプリカを初期化できます。コンシューマサーバを後で初期化する場合の手順については、「コンシューマの初期化」を参照してください。

注
SSL を経由したレプリケーションアグリーメントでは、コンシューマサーバのホスト名は完全指定によるドメイン名 (例えば、server.remote.siroe.com など) として指定する必要があります。エイリアス、IP アドレス、またはドメイン名のローカルの部分だけを指定しないでください。SSL を経由したレプリケーションが許可されなくなります。さらに、「man-in-the-middle」による攻撃からレプリケーションを保護できなくなります。
デフォルトでは、サプライヤはコンシューマサーバの証明書のあるパスを有効にします。サプライヤの信頼するCA (認証局) のルートストアは、SSL を経由したレプリケーションまたはクライアント認証に使用されている CA からの証明書のみである必要があります。SSL を経由したレプリケーションで、「man-in-the-middle」による攻撃から保護するため、コンシューマサーバの証明書に CN 属性にサブジェクト識別名があるか、拡張子が完全指定によるドメイン名と一致することが分っている場合、nsSslServerAuth 構成属性は cncheck 値を持つ必要があります。

カスケード型レプリケーションでのレプリカの初期化

レプリケーションアグリーメントの構成中にレプリカを初期化しない場合は、いつでも「コンシューマの初期化」で説明した手順に従って、この処理を実行できます。ただし、カスケード型レプリケーションの場合、常に次の順序でレプリカを初期化する必要があります。

サプライヤサーバから、ハブサプライヤ上のレプリカを初期化します。

ハブサプライヤから、コンシューマ上のレプリカを初期化します。

更新履歴ログの削除

更新履歴ログとは、指定されたレプリカに対するすべての変更内容を記録したもので、これを使用してサプライヤはコンシューマサーバ (またはマルチマスターレプリケーションの場合はマスター) 上のレプリカにその変更をリプレイします。サプライヤサーバがオフラインになった場合、更新履歴ログには、すべての変更内容を正確に記録することができず、レプリケーションには使用すべきではないので、更新履歴ログを削除可能なことは重要です。更新履歴ログを削除すると、コンシューマを初期化したり、レプリケーションを新しく始めたりすることができます。更新履歴ログを削除するには、それを削除するか、ほかの場所に移動します。
ここでは、次の手順を説明します。

「更新履歴ログの削除」

「更新履歴ログの移動」

更新履歴ログの削除

Directory Server Console を使用すると、更新履歴ログを削除することができます。サプライヤサーバから更新履歴ログを削除するには、次の手順を実行します。

Directory Server Consoleで、「構成」タブを選択します。

左側のナビゲーションツリーにある Replication フォルダを選択してから、右側の区画にある「サプライヤサーバ設定」タブを選択します。

「更新履歴ログを有効にする」チェックボックスの選択を解除します。

これにより、更新履歴ログが削除されます。

「保存」をクリックします。

Directory Server を再起動します。

コンシューマを初期化し直します。

詳細は、「コンシューマの初期化」を参照してください。

注
更新履歴ログを削除したあとで、コンシューマサーバを初期化し直す必要があります。

更新履歴ログの移動

サーバが稼働しており更新履歴ログへの記録を続けている時に更新履歴ログを削除するには、更新履歴ログを単に新しい場所に移動します。更新履歴ログを移動すると、指定したディレクトリに新しい更新履歴ログが作成され、古い更新履歴ログは削除されます。更新履歴ログの位置の変更は、ログの再初期化と同じことなので、コンシューマも初期化し直す必要があります。
たとえば、更新履歴ログをデフォルト位置の /var/ds5/slapd-serverID/changelogdb から /var/ds5/slapd-serverID/newchangelog に移動することができます。この操作は、Directory Server Console から実行する必要があります。ファイルシステムの rename または mv コマンドを使用しないでください。

コンシューマの初期化

一度レプリケーションアグリーメントを作成すると、コンシューマを初期化、つまりデータを物理的にサプライヤサーバからコンシューマサーバにコピーする必要があります。ここでは、コンシューマの初期化について詳細に解説したあと、コンシューマを初期化する 2 つの方法で操作を説明します。この節は、次の項目で構成されています。

「コンシューマの初期化のタイミング」

「Console を使用したオンラインでのコンシューマの初期化」

「コマンド行を使用した手動によるコンシューマの初期化」

コンシューマの初期化のタイミング

コンシューマの初期化には、サプライヤサーバのデータをコンシューマサーバにコピーする処理が含まれます。サブツリーがコンシューマ上に物理的に配置されると、サプライヤサーバはコンシューマサーバに対して更新処理を再実行できるようになります。
通常の運用では、コンシューマを初期化し直す必要はありません。ただし、何らかの理由によりサプライヤサーバのデータがバックアップから復元された場合、対応するコンシューマは、すべて初期化し直す必要があります。
Console を使用してオンラインでコンシューマを初期化するか、コマンド行を使用して手動で初期化できます。Console を使用したオンラインコンシューマの初期化は、少数のコンシューマを初期化するのに効果的な方法です。ただし、この方法は、レプリカを 1 つずつ初期化していくため、多数のレプリカを処理する場合には適していません。オンラインによるコンシューマの初期化は、サプライヤサーバでのレプリケーションアグリーメントの設定中、コンシューマの初期化に使用する方法です。
コマンド行を使用した手動によるコンシューマの初期化は、1 つの LDIF ファイルから多数のコンシューマを初期化する場合により効果的な方法です。

Console を使用したオンラインでのコンシューマの初期化

Console を使用したオンラインコンシューマの初期化は、コンシューマの初期化と再初期化にもっとも簡単な方法です。ただし、低速の接続を経由したレプリケーションの場合は、この方法ではかなり時間がかかるため、コマンド行を使用した手動によるコンシューマの初期化の方がより効果的なこともあります。詳細は、「コマンド行を使用した手動によるコンシューマの初期化」を参照してください。

注
コンシューマサーバがオンラインコンシューマの作成方法を使用して初期化されている場合、レプリカに対するすべての処理 (検索を含む) は、初期化のプロセスが完了するまでサプライヤサーバを参照します。

オンラインでのコンシューマ初期化の実行

コンシューマをオンラインで初期化または再初期化するには、次の手順を実行します。

Directory Server Console でサプライヤサーバを選択し、次に「構成」タブを選択します。

Replication フォルダを展開し、レプリケートされたデータベースを展開します。レプリケーションアグリーメントをマウスの右ボタンでクリックし、ドロップダウンメニューから「コンシューマの初期化」を選択します。

コンシューマ上のレプリカに格納されている情報がすべて削除されるという警告メッセージが表示されます。

確認ボックスで「はい」をクリックします。
ただちにオンラインコンシューマの初期化が開始されます。レプリケーションアグリーメントでオンラインコンシューマの初期化の状態を確認できます。オンラインコンシューマの初期化の処理中は、レプリカを初期化中であるというコンシューマ初期化の状態が示されます。
このウィンドウを更新するには、ナビゲーションツリーのレプリケーションアグリーメントアイコンをマウスの右ボタンでクリックし、「再読み込み」を選択します。オンラインコンシューマの初期化が終了すると、状態がこれを反映するものに変わります。
レプリケーションおよび初期化の状態の監視については、「レプリケーション状態の監視」を参照してください。

コマンド行を使用した手動によるコンシューマの初期化

コマンド行を使用して手動でコンシューマを初期化するのは、多数のエントリのレプリケーションがあるサイトで、コンシューマの初期化が最も早い方法です。ただし、手動によるコンシューマの作成は、オンラインコンシューマの作成と比べてプロセスが複雑です。性能上の問題からオンラインプロセスが適切でないと判断する場合は、手動プロセスを使用するように提案します。
この節は、次の項目で構成されています。

「手動によるコンシューマ初期化の概要」

「LDIF ファイルへのレプリカのエクスポート」

「コンシューマサーバへの LDIF ファイルのインポート」

手動によるコンシューマ初期化の概要

手動でサーバを初期化または再初期化するには、次の手順を実行します。

サプライヤサーバのレプリカを LDIF ファイルにエクスポートします。

「LDIF ファイルへのレプリカのエクスポート」を参照してください。

サプライヤレプリカの内容が含まれている LDIF ファイルをコンシューマサーバにインポートします。

手順については、「コンシューマサーバへの LDIF ファイルのインポート」を参照してください。

注
カスケード型のレプリケーション環境では、サプライヤサーバからエクスポートされた LDIF ファイルを使用して、ハブサーバとハブサーバのコンシューマの両方を初期化できます。

LDIF ファイルへのレプリカのエクスポート

レプリカを LDIF ファイルに変換するには、次の 3 つの手順のうち 1 つを実行します。

レプリケーションウィザードの「コンシューマの初期化」ダイアログボックスで「コンシューマの初期化ファイルの作成」を選択して、レプリケーションアグリーメントを作成します。

Directory Server Console で、任意のときに Replication フォルダのレプリケーションアグリーメントをマウスの右ボタンでクリックし、ポップアップメニューから「レプリカのエクスポート」を選択します。

コマンド行で、「コマンド行からの LDIF へのエクスポート」に記載されている export コマンドを使用します。

コンシューマサーバへの LDIF ファイルのインポート

サプライヤレプリカの内容が含まれている LDIF ファイルをコンシューマサーバにインポートするには、Directory Server Console のインポート機能を使用するか、directoryserver ldif2db または directoryserver ldif2db-task コマンドを使用します。これらのインポート方法については、「コマンド行からのインポート」を参照してください。
ldif2db-task を使用する場合、コンシューマサーバ上に構成されているサプライヤバインド DN を使用してバインドする必要があります。

注
ldif2db-task を使用する場合は、LDIF ファイルのインポート操作をする前にサーバをシャットダウンする必要がありません。

レプリカの同期の維持

定期保守のためにレプリケーションに関連する Directory Server の停止後、オンライン状態に復帰させたときには、レプリケーションを介してそれが更新されていることを確実する必要があります。特に、マルチマスター環境のマスターサーバでは、マルチマスターセットのもう 1 つのサーバからディレクトリ情報を更新する必要があります。マルチマスター以外の環境でも、ハブのサプライヤやコンシューマが保守のためにオフラインになった場合、オンラインに復帰したときは、サプライヤサーバ側により更新をする必要があります。
ここでは、レプリケーションの再試行アルゴリズムおよび次の実行まで待たずに強制的にレプリケーション更新を行う方法について説明します。

注
ここに記載されている手順は、レプリケーションが設定が完了し、さらにコンシューマを初期化した直後にだけ使用できます。

レプリケーションの再試行アルゴリズム

サプライヤサーバがコンシューマへのレプリケーションに失敗した場合は、時間間隔を増加させながら定期的にレプリケーションを再試行します。再試行パターンは、10、20、40、80 秒と間隔が 5 分になるまで繰り返されます。その後、5 分間隔で無限に再試行が繰り返されます。
サプライヤサーバとコンシューマサーバの間で、常に同期をとるレプリケーションアグリーメントを設定していても、オフライン状態の時間が 5 分を超えたサーバを直ちに最新の状態に戻すのに、これは不十分であることに注意してください。
サーバがオンラインに戻った直後にディレクトリ情報を確実に同期させるには、ディレクトリ情報の参照コピーを保持するサプライヤサーバで Directory Server Console を使用するか、カスタマイズ可能なスクリプトを使用します。

Console を使用したレプリケーションの強制的な更新

コンシューマまたはマルチマスターレプリケーション構成のサプライヤが一定の時間を経過してオンライン状態に復帰したとき、レプリケーション更新をただちに送信させるためには、最新のディレクトリ情報を保持しているサプライヤサーバ上で次の手順を実行します。

Directory Server Console で「構成」タブをクリックし、Replication フォルダとデータベースノードを展開して、更新が必要なレプリカに対応するレプリケーションアグリーメントを選択します。

レプリケーションアグリーメントをマウスの右ボタンでクリックし、ドロップダウンリストから「今すぐ更新」を選択します。

これにより、更新が必要な情報を保持しているサーバに対してレプリケーションが開始されます。

SSL を介したレプリケーション

すべてのレプリケーション操作が SSL 接続を経由するように、レプリケーションに関連する Directory Server を構成できます。
SSL を経由してレプリケーションを使用するには、まず次の手順を実行する必要があります。

サプライヤサーバとコンシューマサーバの両者を、SSL を使用するように構成する

サプライヤサーバの証明書をサプライヤ DN として認識するようにコンシューマサーバを構成するただしこの手順は、単純な認証ではなく SSL クライアント認証を使用する場合にだけ実行すること
手順については、第 11 章「SSL の管理」を参照してください。

注
SSL を経由したレプリケーションは、次の場合には失敗します。

サプライヤの証明書が自己署名である場合

サプライヤの証明書が SSL サーバ専用のものである場合 (SSL ハンドシェークの実行中にクライアントとして動作できない)

サーバが SSL を使用するように構成されている場合、次の方法を使用して、必ず SSL 接続を経由したレプリケーションを実行するようにします。

2 つの Directory Server 間のレプリケーションアグリーメントを設定するときに、レプリケーションウィザードを使用する

最初のレプリケーションアグリーメントを構成したあとで、Directory Server Console を使用する

 レプリケーションウィザードを使用した SSL によるレプリケーションの構成

サプライヤサーバの Directory Server Console で、「構成」タブをクリックし、Replication フォルダを展開して、レプリケーション対象のデータベースを選択します。

データベースをマウスの右ボタンでクリックし、ドロップダウンメニューから「新規レプリケーションアグリーメント」を選択します。

レプリケーションアグリーメントウィザードが表示されます。

レプリケーションアグリーメントウィザードの各ステップを実行していくと、「複製元と複製先」ウィンドウが表示されます。

「接続」セクションで、「暗号化 SSL 接続の使用」をオンにします。

「SSL クライアント認証」または「簡易認証」を選択します。

「SSL クライアント認証」を選択すると、サプライヤサーバとコンシューマサーバは、証明書を使用してお互いを認証し合います。

「簡易認証」を選択すると、サプライヤサーバとコンシューマサーバは、バインド DN とパスワードを使用してお互いを認証し合います。この場合、バインド DN とパスワードをテキストフィールドに入力する必要があります。このオプションを選択すると、セキュリティが確保されたチャネルを経由して単純な認証が実行されますが、証明書は発行されません。

「次」をクリックして、レプリケーションの設定に進みます。

注
SSL を経由したレプリケーションアグリーメントでは、コンシューマサーバのホスト名は完全指定によるドメイン名 (例えば、server.remote.siroe.com など) として指定する必要があります。エイリアス、IP アドレス、またはドメイン名のローカルの部分だけを指定しないでください。SSL を経由したレプリケーションが許可されなくなります。さらに、「man-in-the-middle」による攻撃からレプリケーションを保護できなくなります。
デフォルトでは、サプライヤはコンシューマサーバの証明書のあるパスを有効にします。サプライヤの信頼するCA (認証局) のルートストアは、SSL を経由したレプリケーションまたはクライアント認証に使用されている CA からの証明書のみである必要があります。SSL を経由したレプリケーションで、「man-in-the-middle」による攻撃から保護するため、コンシューマサーバの証明書に CN 属性にサブジェクト識別名があるか、拡張子が完全指定によるドメイン名と一致することが分っている場合、nsSslServerAuth 構成属性は cncheck 値を持つ必要があります。

Console を使用した SSL によるレプリケーションの設定

サプライヤサーバ上で Directory Server Console を起動し、「構成」タブをクリックして Replication フォルダを展開し、修正するレプリケーションアグリーメントを選択して SSL によるレプリケーションを有効にします。

右側のナビゲーションウィンドウで「接続」タブをクリックします。

レプリケーション接続設定が表示されます。

「接続」セクションで、「暗号化 SSL 接続の使用」をオンにします。

「SSL クライアント認証」または「簡易認証」を選択します。

「SSL クライアント認証」を選択すると、サプライヤサーバとコンシューマサーバは、証明書を使用してお互いを認証し合います。

「簡易認証」を選択すると、サプライヤサーバとコンシューマサーバは、バインド DN とパスワードを使用してお互いを認証し合います。この場合、バインド DN とパスワードをテキストフィールドに入力する必要があります。このオプションを選択すると、セキュリティが確保されたチャネルを経由して単純な認証が実行されますが、証明書は発行されません。

「保存」をクリックします。

旧バージョンからのレプリケーション

ここでは、iPlanet Directory Server の旧バージョンからのレプリケーションを最適化する方法について説明します。iPlanet Directory Server 5.1、Directory Server の旧バージョンとのレプリケーションモデルに関係させるには、次の条件を満たす必要があります。

Directory Server 5.1 がコンシューマとしてレプリケーションアグリーメントに定義されている

旧バージョンのサプライヤが Directory Server 4.0 または 4.1x である
この場合、次のような制限があります。

旧バージョンの Directory Server と 5.1 Directory Server は、同じレプリカを更新することはできない。しかし、 5.1 Directory Server は旧バージョンの Directory Server から提供されたものと 5.1 Directory Server から提供されたものの、異なるレプリカを保持することになる

Directory Server 5.1 は、ほかのレプリカのサプライヤ例になることはできない
旧バージョンの Directory Server のコンシューマとして Directory Server 5.1 を使用することのできる利点は、レプリケートされた環境の移行が簡単になることです。

旧バージョンの Directory Server のコンシューマとしての Directory Server 5.1 の構成

Directory Server 5.1 を Directory Server の旧バージョンに対応するコンシューマとして使用する場合は、次のように構成する必要があります。

Directory Server Console で、「構成」タブをクリックします。

「構成」タブで、Replication ノードを選択し、右側の区画で「古いバージョンのコンシューマ設定」タブをクリックします。

「古いバージョンのコンシューマを有効にする」チェックボックスを選択します。

これにより、「認証」ボックスのフィールドが有効になります。

旧バージョンのサプライヤサーバがバインドするために使用するサプライヤ DN を指定します。

サプライヤのパスワードを指定します (任意)。ここでパスワードは、8 文字以上にする必要があります。

「保存」をクリックします。

ここでは、旧バージョンのサプライヤから更新を受け取るそれぞれのレプリカについて、コンシューマ設定を構成する必要があります。

ナビゲーションツリーで Replication ノードを展開し、旧バージョンのサプライヤから更新を受け取るレプリカを選択します。

ウィンドウの右側にある「レプリカの設定」タブの「共通設定」セクションで、「レプリカを有効にする」および「4.x のレプリカによる更新」チェックボックスを選択します。

これらのオプションは、レプリケーションの実行に必要な唯一の設定です。手順 4 で指定したサプライヤ DN が使用されるため、サプライヤ DN の指定は必要ありません。

「保存」をクリックします。

旧バージョンのサプライヤから更新を受け取るコンシューマレプリカに対して、それぞれ手順 7 から手順 8 までを繰り返します。

旧バージョンのレプリケーションの設定を完了するには、Directory Server 5.1 にレプリケートする旧バージョンのサプライヤを構成する必要があります。4.x Directory Server 上にレプリケーションアグリーメントを構成する手順については、旧バージョンの Directory Server のマニュアルを参照してください。

注
Directory Server Console では、データベースのサプライヤレプリカとしての構成と旧バージョンのコンシューマの有効化を防げません。これによって、Directory Server 5.1 への移行後の構成にし、移行の期間だけに限って旧バージョンのコンシューマ設定を有効にすることができるため、移行作業がより簡単になります。

レトロ履歴ログのプラグインの使用

レトロログのプラグインを使用すると、Directory Server 4.x に実装されたログと互換性のある更新履歴ログを維持するように iPlanet Directory Server 5.1 を設定できます。レトロログの維持は、iPlanet Directory Server 5.1 と iPlanet Meta Directory を共存させる場合に重要です。また、Directory Server 4.x スタイルの更新履歴ログに依存しているディレクトリクライアントについても、レトロログを維持する必要がある場合があります。
レトロログのプラグインを使用するには、iPlanet Directory Server 5.1 を単一マスターレプリケーションモデルのサプライヤサーバとして構成する必要があります。
レトロログを維持するように iPlanet Directory Server 5.1 を設定すると、更新履歴ログは cn=changelog という接尾辞の付いた別のデータベースに格納されます。
レトロログは、単一レベルの複数のエントリから構成されます。更新履歴ログの各エントリには changeLogEntry というオブジェクトクラスがあり、表 8-1 にリストされている属性を含めることができます。

表 8-1 レトロ履歴ログエントリの属性

属性

定義

changeNumber

１つの値からなるこの属性は常に存在し、各更新を一意に識別する整数を含む。この番号は、更新の発生した順序に関連し、番号が大きいほど、更新の順序は後ろであることを表す

targetDN

この属性には、LDAP 処理の影響を受けるエントリの DN が含まれる。modrdn 処理の場合、targetDN 属性にはエントリが変更または移動される前のエントリの DN が含まれる

changeTime

この属性は、変更操作が行われた時間を指定する

changeType

LDAP 処理のタイプが指定される。この属性は、add、delete、modify、または modrdn の値のどれか 1 つである

changes

add または modify 処理の場合、エントリに対する更新が LDIF 形式で含まれる

newRDN

modrdn 処理の場合、エントリの新しい RDN が指定される

deleteOldRdn

modrdn 処理の場合、古い RDN が削除されたかどうかが指定される

newSuperior

modrdn 処理の場合、エントリの newSuperior 属性が指定される

この節は、レトロログに関する次の項目で構成されています。

「レトロ履歴ログのプラグインの有効化」

「レトロ履歴ログの削除」

「レトロ履歴ログの検索と変更」

「レトロ履歴ログとアクセス制御ポリシー」

レトロ履歴ログのプラグインの有効化

レトロログプラグインの構成情報は、dse.ldif の cn=Retro Changelog Plugin,cn=plugins,cn=config エントリに保持されています。
Directory Server Console からレトロログのプラグインを有効にする手順は、Directory Server のその他のプラグインの場合と同じです。詳細は、「Server Consoleを使用したプラグインの有効化と無効化」を参照してください。
コマンド行からレトロログのプラグインを有効にするには、次の手順を実行します。

次の LDIF 更新文を含む LDIF ファイルを作成します。
dn: cn=Retro Changelog Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginenabled
nsslapd-pluginenabled:on

ldapmodify コマンドを使用して、LDIF ファイルをディレクトリにインポートします。

サーバを再起動します。

サーバの再起動については、「iPlanet Directory Server の起動と停止」を参照してください。

レトロログは、ディレクトリツリーの cn=changelog という特別な接尾辞の下に作成されます。

レトロ履歴ログの削除

更新履歴ログのエントリは、指定した一定時間後に自動的に削除されます。更新履歴ログからエントリを自動的に削除する期間を指定するには、cn=Retro Changelog Plugin, cn=plugins, cn=config エントリで nsslapd-changelogmaxage 構成属性を設定する必要があります。
nsslapd-changelogmaxage 属性は、次の形式の単一値属性です。
nsslapd-changelogmaxage: Integer timeUnit
ここで、integer は数字を表し、timeUnit の s は秒、m は分、h は時間、d は日数、およびw は週を表します。

注
Integer 変数と timeUnit 変数の間には空白を挿入しません。上の構文では、属性値が 1 つではなく 2 つの変数部からなることを表すために、空白が挿入されています。

nsslapd-changelogmaxage 値の例 :
nsslapd-changelogmaxage: 2d

レトロ履歴ログの検索と変更

このような情報へのアクセスを許可されるのは、認証アプリケーションおよびユーザに制限する必要があります。更新履歴ログは検索処理をサポートしており、次の形式のフィルタを含む検索用に最適化されています。
(&(changeNumber>=X)(changeNumber<=Y))
一般的な規則として、更新履歴ログのサイズを小さくするためにエントリを削除するとしても、レトロログでは追加または変更処理は実行すべきではありません。レトロログで修正処理を実行する必要があるのは、デフォルトのアクセス制御ポリシーを修正する場合だけです。

レトロ履歴ログとアクセス制御ポリシー

レトロログが作成されると、次のアクセス制御規則がデフォルトで適用されます。

レトロログのトップエントリ cn=changelog に対する読み取り、検索、および比較の権限は、すべての認証ユーザ (userdn=anyone のユーザ。userdn=all で指定された匿名アクセスとは異なる) に付与される

ディレクトリマネージャに対する暗黙の了承を除き、書き込みおよび削除アクセスは付与されない
更新履歴ログのエントリにはパスワードなどの重要な情報が含まれている場合があるので、読み取りアクセス権を匿名ユーザに付与しないでください。認証済みのアプリケーションおよびユーザにのみ、この情報に対するアクセス権を付与すべきです。
レトロログに対するデフォルトのアクセス制御ポリシーを変更するには、cn=changelog エントリの aci 属性を変更します。

レプリケーション状態の監視

Directory Server Console を使用して、レプリケーションの状態を監視することができます。
レプリケーション状態の概要を表示するには、次の手順を実行します。

Directory Server Console で、「状態」タブをクリックし、左側のナビゲーションツリーにある「レプリケーション状態」を選択します。

サーバに構成されている各レプリケーションアグリーメントに関する情報が、右側の区画に表示されます。

「再読み込み」をクリックして、タブのコンテンツを更新します。
表示される状態情報については、表 8-2 に記載されています。

表 8-2 Directory Server Console - 「状態」タブ

テーブルの見出し

内容

Agreement

レプリケーションアグリーメントを設定するときに指定する名前を含む

Replica suffix

レプリケートされた接尾辞を含む

Supplier

契約内のサプライヤサーバを表示する

Consumer

契約内のコンシューマサーバを表示する

Number of changes

サーバの起動時からレプリカに対して送られた更新の数を示す

Last replica update began

最終のレプリケーション更新開始日時を示す

Last replica update ended

最終のレプリケーション更新終了日時を示す

Last update message

最終のレプリケーション更新の状態を示す

Consumer initialization

コンシューマ初期化の現在の状態 (実行中かどうか) を示す

Last consumer initialization update message

コンシューマを最後に初期化したときの状態を示す

Last consumer initialization began

コンシューマレプリカの初期化開始日時を示す

Last consumer initialization ended

コンシューマレプリカの初期化終了日時を示す

 よく発生するレプリケーションの競合の解決

マルチマスターレプリケーションでは、疎整合型レプリケーションモデル (Loose Consistency Replication Model) を使用します。つまり、同一のエントリを別々のサーバから同時に変更することができます。同一エントリへの変更が実施されたあと、2 つのサーバ間でレプリケーションが発生した場合、更新の競合を解決する必要があります。ほとんどの場合、各サーバ上での更新に関連したタイムスタンプを基に競合は自動的に解決され、最終の更新が優先されます。
ただし、更新の競合を解決するためにユーザの介入が必要となる場合もあります。レプリケーションプロセスで自動的に解決できない更新の競合があるエントリには、競合マーカー属性 nsds5ReplConflict が含まれます。nsdsReplConflict 属性は操作属性 (operational attribute) です。これによって、この属性を含むエントリを簡単に検索できます。
たとえば、次の ldapsearch コマンドを使用できます。
% ldapsearch -D adminDN -w passwd \
-b "dc=siroe,dc=com" "nsds5ReplConflict=*"
nsds5ReplConflict 属性には、デフォルトでインデックスが設定されています。
ここでは、次の競合を解決する手順について説明します。

「命名の競合の解決」

「親のないエントリの競合の解決」

「潜在的な相互運用性の問題の解決」

命名の競合の解決

レプリケーション中に同一の DN を持つ 2 つのエントリが別々のサーバ上に作成されていた場合、DN にそのエントリの一意の識別子を含めることによって、競合を解決する自動処理により、最後に作成されたエントリの名前が変更されます。各ディレクトリエントリは、操作属性 nsuniqueid によって指定された一意の識別子を持ちます。命名の競合が発生すると、この一意の ID が、一意でない DN に追加されます。
たとえば、サーバ A では t1 という時刻にエントリ uid=adamss,ou=people,dc=siroe,dc=com が作成され、サーバ B では t1 より遅い t 2 という時刻に同一のエントリが作成された場合、レプリケーションが実行されると、サーバ A とサーバ B のエントリは、次のようになります。

uid=adamss,ou=people,dc=siroe,dc=com (t1 の時刻に作成)

nsuniqueid=66446001-1dd211b2+uid=adamss,dc=siroe,dc=com (t2 の時刻に作成)
2 番目のエントリは、 DN が一意になるように名前を変更する必要があります。名前変更の手順は、命名属性が 1 つの値を持つか複数の値を持つかによって異なります。各手順は次のとおりです。

複数の値からなる命名属性を持つエントリの名前変更

複数の値からなる命名属性を持つエントリに対して名前を変更するには、次の手順を実行します。

命名属性の新しい値を使用してエントリの名前を変更し、古い RDN を保持しておきます。たとえば、次のようにします。
prompt% ldapmodify -D adminDN -w passwd
>dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=siroe,dc=com
>changetype: modrdn
>newrdn: uid=NewValue
>deleteoldrdn: 0

命名属性の古い RDN 値と競合マーカー属性を削除します。たとえば、次のようにします。
prompt% ldapmodify -D adminDN -w passwd
dn: uid=NewValue,dc=siroe,dc=com
changetype: modify
delete:uid
uid: adamss
-
delete: nsds5ReplConflict
-

注
一意の識別子属性 nsuniqueid は削除できないため、この処理は 2 段階で実行されます。

ldapmodify コマンドについては、「コマンド行からのエントリの管理」および『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

1 つの値からなる命名属性を持つエントリの名前変更

1 つの値からなる命名属性を持つエントリに対して名前を変更するには、次の手順を実行します。

別の命名属性を使用してエントリの名前を変更し、古い RDN を保持しておきます。たとえば、次のようにします。
prompt% ldapmodify -D adminDN -w passwd
>dn: nsuniqueid=66446001-1dd211b2+dc=pubs,dc=siroe,dc=com
>changetype: modrdn
>newrdn: cn=TempValue
>deleteoldrdn: 0

命名属性の古い RDN 値と競合マーカー属性を削除します。たとえば、次のようにします。
prompt% ldapmodify -D adminDN -w passwd
>dn: cn=TempValue,dc=siroe,dc=com
>changetype: modify
>delete:dc
>dc: pubs
>-
>delete: nsds5ReplConflict
>-

注
一意の識別子属性 nsuniqueid は削除できないため、この処理は 2 段階で実行されます。

目的の属性と値のペアを含むエントリの名前を変更します。たとえば、次のようにします。
prompt% ldapmodify -D adminDN -w passwd
>dn: cn=TempValue,dc=siroe,dc=com
>changetype: modrdn
>newrdn: dc=NewValue
>deleteoldrdn: 1

deleteoldrdn 属性の値に 1 を設定すると、一時的な属性と値のペアである cn=TempValue が削除されます。この属性を保持する場合は、deleteoldrdn 属性の値に 0 を設定します。
ldapmodify コマンドについては、「コマンド行からのエントリの管理」を参照してください。

親のないエントリの競合の解決

エントリの削除操作がレプリケートされたとき、コンシューマサーバが削除されるエントリが子エントリを持つことを検出した場合、競合解決処理によって glue エントリが作成され、親のないエントリをディレクトリに持つことを回避します。
同様に、エントリの追加のあとにレプリケーションが実行され、コンシューマサーバが追加されたエントリの親エントリを検出できなかった場合も、競合解決処理は親を表す glue エントリを作成し、親のないエントリが追加されることを回避します。
glue エントリは、glue および extensibleObject というオブジェクトクラスを持つ一時的なエントリです。glue エントリは、次のいくつかの方法で作成されます。

競合解決処理が、マッチする一意の識別子をともなう削除されるエントリを検出した場合、glue エントリは、glue オブジェクトクラスと nsds5ReplConflict 属性を加えて、そのエントリを復元する

この場合は、glue エントリを修正して glue オブジェクトクラスと nsds5ReplConflict 属性を削除し、通常のエントリに戻すか、または glue エントリとその子エントリを削除します。

サーバによって、glue および extensibleObject オブジェクトクラスを持つ必要最小限のエントリが作成される

このような場合は、意味のあるエントリになるようにエントリを修正するか、またはエントリとその子エントリをすべて削除します。

潜在的な相互運用性の問題の解決

メールサーバのように属性の一意性に依存するアプリケーションとの相互運用性の理由から、nsds5ReplConflict 属性を持つエントリへのアクセスを制限する必要がある場合があります。これらのエントリへのアクセスを制限しない場合は、一つの属性だけを要求するアプリケーションが元のエントリと nsds5ReplConflict を含む競合解決エントリの両方を取得し、処理が失敗します。
アクセスを制限するには、次のコマンドを使用して、匿名の読み取りアクセスを許可するデフォルトの ACI を変更する必要があります。
ldapmodify -h hostname -D "cn=Directory Manager" -w passwd
> dn:dc=siroe,dc=com
>changetype: modify
>delete:aci
>aci: (target ="ldap:///dc=siroe,dc=com")(targetattr !="userPassword")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare)(userdn = "ldap:///anyone");)
> -
>add:aci
> aci: (target="ldap:///dc=siroe,dc=com")(targetattr!="userPassword") (targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare) (userdn="ldap:///anyone");)
> -
新しい ACI は、検索結果から nsds5ReplConflict 属性を持つすべてのエントリを除外します。

属性	定義
changeNumber	１つの値からなるこの属性は常に存在し、各更新を一意に識別する整数を含む。この番号は、更新の発生した順序に関連し、番号が大きいほど、更新の順序は後ろであることを表す
targetDN	この属性には、LDAP 処理の影響を受けるエントリの DN が含まれる。modrdn 処理の場合、targetDN 属性にはエントリが変更または移動される前のエントリの DN が含まれる
changeTime	この属性は、変更操作が行われた時間を指定する
changeType	LDAP 処理のタイプが指定される。この属性は、add、delete、modify、または modrdn の値のどれか 1 つである
changes	add または modify 処理の場合、エントリに対する更新が LDIF 形式で含まれる
newRDN	modrdn 処理の場合、エントリの新しい RDN が指定される
deleteOldRdn	modrdn 処理の場合、古い RDN が削除されたかどうかが指定される
newSuperior	modrdn 処理の場合、エントリの newSuperior 属性が指定される

テーブルの見出し	内容
Agreement	レプリケーションアグリーメントを設定するときに指定する名前を含む
Replica suffix	レプリケートされた接尾辞を含む
Supplier	契約内のサプライヤサーバを表示する
Consumer	契約内のコンシューマサーバを表示する
Number of changes	サーバの起動時からレプリカに対して送られた更新の数を示す
Last replica update began	最終のレプリケーション更新開始日時を示す
Last replica update ended	最終のレプリケーション更新終了日時を示す
Last update message	最終のレプリケーション更新の状態を示す
Consumer initialization	コンシューマ初期化の現在の状態 (実行中かどうか) を示す
Last consumer initialization update message	コンシューマを最後に初期化したときの状態を示す
Last consumer initialization began	コンシューマレプリカの初期化開始日時を示す
Last consumer initialization ended	コンシューマレプリカの初期化終了日時を示す

前へ目次索引 DocHome 次へ
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated March 05, 2002