| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
レプリケーションとは、あるDirectory Serverから1つ以上の別のDirectory Serverへディレクトリ内容を自動的にコピーするメカニズムです。すべての書込み操作は、別のDirectory Serverに自動的にミラーリングされます。サポートされている様々なプラットフォーム間のレプリケーションも可能です。サポートされているプラットフォームのリストは、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionリリース・ノート』のプラットフォームのサポートに関する項を参照してください。レプリケーションの概念、レプリケーション・シナリオ、およびディレクトリのデプロイメントにおけるレプリケーションの計画方法の詳細は、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』を参照してください。
レプリケーションのトポロジでは一般に、サーバー上の接尾辞とサーバー上の別の接尾辞間でレプリケートが行われます。このため、レプリカ、レプリケートされた接尾辞、レプリケートされたサーバーという語は同じ意味で使用できます。
この章では、コマンドラインを使用した各種レプリケーション・シナリオを設定するための実行タスクを説明します。説明する内容は次のとおりです。
無限の数のマスターでレプリケーション・デプロイメントを構成できます。デプロイメントにハブまたはコンシューマを含める必要はありません。ハブおよびコンシューマのレプリケーション構成手順もこの章に記載していますが、それらはオプションとなります。
レプリケーションの構成を開始する前に、組織内におけるレプリケーションのデプロイ方法を明確に理解する必要があります。Oracle Directory Server Enterprise Editionのリファレンスで説明されているレプリケーションの概念を理解する必要があります。『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』で説明する設計ガイドラインを使用して、今後のレプリケーション構成を慎重に計画しておくことも必要です。
最も簡単にレプリケーションを構成および管理する方法は、Directory Service Control Center(DSCC)を使用することです。DSCCを使用すれば、自動的にレプリケーションを構成できます。レプリケーション・トポロジの設定に必要な自動化のレベル(レプリケーション構成時に接尾辞を初期化するかどうかなど)を選択できます。DSCCにはエラーを回避できるチェック機能も備えられています。さらに、DSCCではレプリケーション・トポロジをグラフィカルに表示します。
DSCCオンライン・ヘルプでは、DSCCを使用したレプリケーション設定の手順を説明しています。
|
注意: この章で説明するコマンドラインの手順は、レプリケーションの設定にDSCCを使用できない場合にのみ使用してください。 |
「レプリケーション構成手順の概要」では、単一接尾辞をレプリケートすることを前提としています。複数の接尾辞をレプリケートする場合、各サーバーで並行して接尾辞を構成できます。つまり、各手順を繰り返すことで、複数の接尾辞でレプリケーションを構成できます。
この章の残りの部分で、レプリケーションの構成方法の詳細を説明します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
レプリケーション・トポロジを構成するには、次の手順で説明するような一般的な手順に従ってください。
専用コンシューマ・レプリカを含むすべてのサーバーで次を実行します。
コンシューマのレプリケートされた接尾辞に対して空の接尾辞を作成します。
「コンシューマ・レプリカの接尾辞を作成するには:」を参照してください。
コンシューマのレプリケートされた接尾辞を有効にします。
「コンシューマ・レプリカを有効にするには:」を参照してください。
詳細コンシューマ設定を構成します。
「詳細コンシューマ構成を実行するには:」を参照してください。
該当する場合、ハブのレプリケートされた接尾辞を含むすべてのサーバーで次を実行します。
ハブのレプリケートされた接尾辞に対して空の接尾辞を作成します。
「ハブ・レプリカの接尾辞を作成するには:」を参照してください。
ハブのレプリケートされた接尾辞を有効にします。
「ハブ・レプリカを有効にするには:」を参照してください。
詳細ハブ設定を構成します。
「ハブ・レプリカの変更ログ設定を変更するには:」を参照してください。
マスターのレプリケートされた接尾辞を含むすべてのサーバーで次を実行します。
マスターのレプリケートされた接尾辞に対して接尾辞を作成します。
「マスター・レプリカの接尾辞を作成するには:」を参照してください。
マスターのレプリケートされた接尾辞を有効にします。
「マスター・レプリカを有効にするには:」を参照してください。
詳細マスター設定を構成します。
「マスター・レプリカの変更ログ設定を変更するには:」を参照してください。
|
注意: レプリケーション承諾を作成する前に、すべてのレプリカを有効にして、レプリケーション承諾の作成直後にコンシューマ・レプリカを初期化できるようにします。コンシューマの初期化は常にレプリケーション設定の最終段階となります。 |
レプリケーション・マネージャの構成が完了していることを確認します。
デフォルトのマネージャを使用する場合、すべてのサーバーでデフォルトのレプリケーション・マネージャのパスワードを設定します。「デフォルトのレプリケーション・マネージャのパスワードを変更するには:」を参照してください。
デフォルト以外のレプリケーション・マネージャを使用する場合、すべてのサーバーでかわりのレプリケーション・マネージャのエントリを定義します。「デフォルト以外のレプリケーション・マネージャの使用方法」を参照してください。
次のように、すべてのマスター・レプリカでレプリケーション承諾を作成します。
マルチマスター・トポロジのマスター間
マスターとそれらの専用コンシューマ間
マスターとハブ・レプリカ間
「レプリケーション承諾の作成および変更」を参照してください。
部分レプリケーションを使用する場合、この時点で構成します。
「部分レプリケーション」を参照してください。
レプリケーションの優先順位を使用する場合、この時点で構成します。
「レプリケーションの優先順位」を参照してください。
ハブ・レプリカとそれらのコンシューマ間のレプリケーション承諾を構成します。
「レプリケーション承諾の作成および変更」を参照してください。
マルチマスター・レプリケーションに対しては、データのオリジナル・コピー含む同一マスター・レプリカからすべてのマスターを初期化します。
「レプリカの初期化」を参照してください。
ハブ・レプリカおよびコンシューマ・レプリカを初期化します。
「レプリカの初期化」を参照してください。
専用コンシューマはレプリケートされた接尾辞の読取り専用コピーです。専用コンシューマは、レプリケーション・マネージャとしてバインドするサーバーから更新を受け取り、変更を行います。コンシューマ・サーバーの構成には、レプリケートされた接尾辞を保持するための空の接尾辞の準備、およびその接尾辞のレプリケーション有効化が含まれます。オプションの詳細構成には、リフェラルの設定、パージ遅延の変更およびプロパティの修正を含めることができます。
次の各項では、サーバーにある専用コンシューマのレプリケートされた接尾辞を1つ構成する方法を説明します。専用コンシューマのレプリケートされた接尾辞を含むことになる各サーバーで、この手順をすべて繰り返します。
空の接尾辞がまだ存在しない場合、目的のマスター・レプリカと同じDNでコンシューマに空の接尾辞を作成します。
詳細は、「接尾辞の作成」を参照してください。
|
注意: 接尾辞が存在していても、空でない場合、その接尾辞の内容は、レプリケートされた接尾辞をマスターから初期化すると失われます。 |
空の接尾辞の作成後、コンシューマのレプリケートされた接尾辞を有効にする必要があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
コンシューマのレプリケートされた接尾辞を有効にします。
$ dsconf enable-repl -h host -p port consumer suffix-DN
次に例を示します。
$ dsconf enable-repl -h host1 -p 1389 consumer dc=example,dc=com
高度な機能を使用するため、コンシューマのレプリケートされた接尾辞を構成する場合は、この時点で行います。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
レフェラルにSSLを使用する場合、セキュアなリフェラルを設定します。
$ dsconf set-suffix-prop -h host -p port suffix-DN referral-url:ldaps://servername:port
次に例を示します。
$ dsconf set-suffix-prop -h host1 -p 1389 dc=example,dc=com \ referral-url:ldaps://server2:2389
レプリケーション・メカニズムでは、レプリケーション・トポロジに含まれるすべての既知のマスターのリフェラルを返すよう、コンシューマを自動的に構成します。これらのデフォルトのリフェラルは、クライアントの標準的な接続で簡易認証を使用することを前提としています。セキュアな接続のためにSSLを使用して、マスターにバインドするオプションをクライアントに提供する場合、セキュアなport番号を使用するリフェラルをldaps://servername :portの形式で追加します。マスターがセキュアな接続のみに構成されている場合、URLはデフォルトでそれらのセキュアなポートを指定します。
リフェラルとして、LDAPのURLを1つ以上追加している場合、コンシューマがマスターレプリカのリフェラルではなく、これらのLDAP URLのリフェラルを送信するようにできます。たとえば、クライアントが常にデフォルトのポートではなく、マスターサーバーのセキュアなポートを使用するようにするとします。この場合、それらのセキュアなポートのLDAP URLのリストを作成して、それらのリフェラルを使用するためのプロパティを設定します。すべての更新を処理する特定のマスターまたはDirectory Serverプロキシを指定する場合も、排他的なリフェラルを使用できます。
コンシューマのレプリケーションのパージ遅延を変更する場合、次のコマンドを使用します。
$ dsconf set-suffix-prop -h host -p port suffix-DN repl-purge-delay:time
たとえば、パージ遅延を2日に設定するには、次を入力します。
$ dsconf set-suffix-prop -h host1 -p 1389 edc=example,dc=com repl-purge-delay:2d
ハブ・レプリカはコンシューマおよびマスターの両方として機能し、さらにより多くのコンシューマにレプリケートされたデータを配信します。ハブ・レプリカは自身のサプライヤからレプリケーションの更新を受信し、自身のコンシューマにレプリケーションの更新を送信します。ハブ・レプリカは変更を受け付けないかわりに、マスターにリフェラルを返します。
ハブ・サーバーの構成では、レプリケートされた接尾辞を保持するための空の接尾辞の準備、およびその接尾辞でのレプリケーションの有効化を行います。必要に応じて、別のレプリケーション・マネージャの選択、リフェラルの設定、パージ遅延の設定、および変更ログ・パラメータの変更などの詳細な構成も行うことができます。
次の各項では、1つのハブ・サーバーを構成する方法について説明します。ハブのレプリケートされた接尾辞を含む各サーバーで、この手順をすべて繰り返します。
空の接尾辞がまだ存在しない場合、これを目的のマスター・レプリカと同じDNでハブ・サーバーに作成します。
詳細は、「接尾辞の作成」を参照してください。
接尾辞が存在していても、空でない場合、その接尾辞の内容は、レプリケートされた接尾辞をマスターから初期化すると失われます。
ハブ・レプリカがある場合、この時点でそれらを有効にします。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
ハブのレプリケートされた接尾辞を有効にします。
$ dsconf enable-repl -h host -p port hub suffix-DN
次に例を示します。
$ dsconf enable-repl -h host1 -p 1389 hub dc=example,dc=com
詳細ハブ構成では、変更できるパラメータは変更ログに関するもののみとなります。サプライヤでもあるので、ハブ・サーバーには変更ログが必要となります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
ハブの変更ログ設定を変更するには、次のコマンドのいずれかを使用します。
$ dsconf set-suffix-prop -h host -p port suffix-DNrepl-cl-max-age:value $ dsconf set-suffix-prop -h host -p port suffix-DNrepl-cl-max-entry-count:value
マスター・レプリカにはデータのマスターコピーが含まれ、更新を他のすべてのレプリカに伝播させる前に、すべての変更を集中的に管理します。マスターはすべての変更を記録し、自身のコンシューマのステータスをチェックして、必要に応じて更新をコンシューマに送信します。マルチマスター・レプリケーションでは、マスター・レプリカは他のマスターから更新を受け取ることもあります。
マスター・サーバーの構成では、マスター・レプリカを含む接尾辞の定義、マスター・レプリカの有効化、および必要に応じての詳細レプリケーション構成を行います。
次の各項では、1つマスター・サーバーを構成する方法について説明します。マスターのレプリケートされた接尾辞を含む各サーバーで、この手順をすべて繰り返します。
レプリケートするエントリを含むマスター・サーバーで接尾辞を選択または作成します。
手順は、「接尾辞の作成」を参照してください。
適切にマルチマスターの構成および初期化を行うために、データを含むマスターを1つのみロードします。他のレプリケートされた接尾辞のデータはいずれも上書きされます。
マスターのレプリケーションを有効にする場合、レプリケーションIDの割当てが必要になります。レプリケーションIDは、更新ステートメントの所有者を識別するため、また、マルチマスター・レプリケーションで発生する可能性のある競合を解決するために使用されます。したがって、レプリケーションIDはこの接尾辞のすべてのマスター・レプリカで一意である必要があります。一度設定したレプリケーションIDは変更しないでください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
マスターのレプリケートされた接尾辞を有効にします。
$ dsconf enable-repl -h host -p port -d ReplicaID master suffix-DN
ReplicaIDは1から65534までの整数です。
たとえば、レプリカID 1でマスターのレプリケートされた接尾辞を作成するには、次のコマンドを使用します。
$ dsconf enable-repl -h host1 -p 1389 -d 1 master dc=example,dc=com
詳細マスター構成では、変更ログ設定を変更する場合もあります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
マスターの変更ログ設定を変更するには、次のコマンドのいずれかを使用します。
$ dsconf set-server-prop -h host -p port suffix-DNrepl-cl-max-age:value $ dsconf set-server-prop -h host -p port suffix-DNrepl-cl-max-entry-count:value
この項では、デフォルト以外のレプリケーション・マネージャの構成方法、およびデフォルトのレプリケーション・マネージャのパスワードの設定方法について説明します。
レプリケーション・マネージャとは、サプライヤがレプリケーション更新を送信する場合に、コンシューマ・サーバーにバインドするために使用するユーザーです。更新を受信する接尾辞を含むすべてのサーバーでは、少なくとも1つのレプリケーション・マネージャ・エントリが必要です。
Directory Serverにはデフォルトのレプリケーション・マネージャ・エントリcn=replication manager,cn=replication,cn=configがあり、特に単純なレプリケーション・シナリオの場合に、すべてのサーバーで使用できます。レプリケーション・メカニズムは、このユーザーを使用してコンシューマ・レプリカを自動的に設定するので、レプリカのデプロイメントが簡素化されます。
複雑なレプリケーション・シナリオの場合は、レプリケートされた接尾辞ごとに異なるパスワードを持つ複数のレプリケーション・マネージャを指定できます。既存のデフォルト・レプリケーション・マネージャを1つ以上の新しいレプリケーション・マネージャで置き換えられます。
|
注意: レプリケーション・マネージャのDNおよびパスワードを使用して、バインドを実行したり、サーバー上で処理を行うことはできません。レプリケーション・マネージャはレプリケーション・メカニズム専用となります。その他の用途では、レプリカの再初期化が必要となる場合があります。 ディレクトリ・マネージャはレプリケーション・マネージャとして使用できません。cn=admin,cn=Administrators,cn=configエントリは他の管理タスクでも使用されるので、このユーザーまたは管理者グループの他のどのユーザーもレプリケーション・マネージャとして使用できません。 |
各コンシューマのレプリケーション・マネージャを選択したら、選択または作成したレプリケーション・マネージャのDNを覚えておきます。このDNとパスワードは、後でサプライヤ上でこのコンシューマとのレプリケーション承諾を作成する場合に必要になります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
すべてのコンシューマ(ターゲット)のレプリケートされた接尾辞で、新しいレプリケーション・マネージャとパスワードを作成します。
$ ldapmodify -a -h host -p port -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn:"cn=new-replication-manager,cn=replication,cn=config" objectclass: top objectclass: person userpassword:password sn:new-replication-manager
次に例を示します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn:"cn=ReplicationManager3,cn=replication,cn=config" objectclass: top objectclass: person userpassword:secret sn:ReplicationManager3
すべてのコンシューマ(ターゲット)のレプリケートされた接尾辞で、レプリケーション・マネージャのバインドDNを設定します。
$ dsconf set-suffix-prop -h host -p port suffix-DN \ repl-manager-bind-dn:"cn=new-replication-manager,cn=replication,cn=config"
次に例を示します。
$ dsconf set-suffix-prop -h host1 -p 1389 dc=example,dc=com \ repl-manager-bind-dn:"cn=ReplicationManager3,cn=replication,cn=config"
すべてのサプライヤ(ソース)のレプリケートされた接尾辞で作成したすべてのレプリケーション承諾に対して、レプリケーション・マネージャのバインドDNを設定します。
新しいレプリケーション・マネージャのパスワード設定用に、一時ファイルを作成します。
このファイルが一度読み取られ、パスワードは将来使用するために保存されます。
$ echo password> password-file
更新の実行時にレプリケーション・メカニズムで使用するレプリケーション・マネージャのバインドDNとパスワードを設定します。
$ dsconf set-repl-agmt-prop -h host -p port suffix-DN host:port \ auth-bind-dn:"cn=new-replication-manager,cn=replication,cn=config" \ auth-pwd-file:password-file
次に例を示します。
$ dsconf set-repl-agmt-prop -h host2 -p 1389 dc=example,dc=com host1:1389 \ auth-bind-dn:"cn=ReplicationManager3,cn=replication,cn=config" \ auth-pwd-file:pwd.txt
一時パスワード・ファイルを削除します。
$ rm password-file
レプリケーション・マネージャのパスワード設定用に、一時ファイルを作成します。
このファイルが一度読み取られ、パスワードは将来使用するために保存されます。
$ echo password> password-file
レプリケーション・トポロジのすべてのコンシューマ(ターゲット)サーバーに、レプリケーション・マネージャのバインド・パスワードを設定します。
$ dsconf set-server-prop -h host -p port def-repl-manager-pwd-file:password-file
次に例を示します。
$ dsconf set-server-prop -h host1 -p 1389 def-repl-manager-pwd-file:pwd.txt
一時パスワード・ファイルを削除します。
$ rm password-file
dsconf accord-repl-agmtコマンドを実行します。
$ dsconf accord-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port
レプリケーション承諾とは、指定したコンシューマに更新を送信する方法を構成および制御するサプライヤでの一連のパラメータのことです。コンシューマに更新を送付するサプライヤのレプリケートされた接尾辞には、レプリケーション承諾を作成する必要があります。更新すべてのコンシューマに対して、サプライヤでのレプリケーション承諾を作成する必要があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
DSCCを使用して新しいレプリケーション承諾を作成する場合、既存のレプリケーション承諾からレプリケーション承諾の構成設定を一部またはすべてコピーとすることもできます。
マスター・サーバーから、レプリケートする各コンシューマに対してレプリケーション承諾を作成します。
$ dsconf create-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port\ [consumer-host:consumer-port]
次に例を示します。
$ dsconf create-repl-agmt -h host1 -p 1389 dc=example,dc=com host2:1389
コマンドラインを使用して既存のレプリケーション承諾をリストするには、dsconf list-repl-agmtsコマンドを使用します。
|
注意: レプリケーションの実行中に、マスターのポート番号を変更しても、サーバーを初期化しなおす必要はありません。ただし、旧アドレス(host:old-port)を指定した古いレプリケーション承諾は使用できなくなります。ポート番号を変更する前と同様のレプリケーションを続ける場合、新しいアドレス(host:new-port)で新しい承諾を作成する必要があります。 |
レプリケーション承諾が正常に作成されたことを確認します。
$ dsconf show-repl-agmt-status -h host -p port suffix-DN consumer-host:consumer-port
認証ステータスがOKでない場合は、dsconf accord-repl-agmtコマンドを実行します。
|
注意:
|
dsconf accord-repl-agmtコマンドにより、サプライヤとターゲット・サーバーが同じレプリケーション承認設定を共有します。
$ dsconf accord-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port
次に例を示します。
$ dsconf accord-repl-agmt -h host2 -p 1389 dc=example,dc=com host1:1389
この手順では、既存のレプリケーション承諾で指定されたリモート・レプリカを変更します。既存の承諾の接尾辞DNと構成は変わりません。
レプリケーション承諾のリモート・レプリカのホスト名とポート番号を変更します。
$ dsconf change-repl-dest -h host -p port suffix-DN host:port new-host:new-port
このコマンドを-A protocolオプション付きで実行する場合、レプリケーションで使用する認証プロトコルを変更できます。
デフォルトでのレプリケーション操作では、レプリケートされた接尾辞のエントリ全体がコンシューマ・レプリカにコピーされます。部分レプリケーション機能を使用すれば、使用する接尾辞および、どの属性をレプリケーションの対象とし、どの属性を対象外とするかを選択できます。部分レプリケーションはレプリケーション承諾で構成されるので、マスターのコンシューマのレプリケートされた接尾辞ごとに属性セットを定義できます。配信するデータを制御し、レプリケーションの帯域幅とコンシューマ・リソースをより効率的に利用できます。
たとえば、レプリケーション帯域幅を削減する場合、photo、jpegPhoto、audioなど、一般的に大きな値を伴う属性をレプリケート対象外にすることもできます。これにより、それらの属性はコンシューマでは使用できなくなります。他の例として、uidおよびuserpassword属性のみを、認証の実行専用のコンシューマ・サーバーにレプリケートすることもできます。
属性の部分的なセットを有効化または変更するには、コンシューマ・レプリカを初期化しなおす必要があります。したがって、デプロイメントの前に部分レプリケーションのニーズを特定し、最初にレプリケートされた接尾辞を初期化する前に属性セットを定義する必要があります。
ACI、ロール、CoSなどの複雑な機能が特定の属性に依存している場合、小規模な属性セットをレプリケートする際は、注意して進める必要があります。また、ACI、ロールまたはCoSメカニズムの指示子やフィルタで指定されるその他の属性をレプリケートしないと、データのセキュリティが損われる場合があります。レプリケートしないと、検索で異なる属性セットが返される場合もあります。レプリケーションの対象に含める属性のリストを管理するよりも、除外する属性のリストを管理する方法が安全であり、人的なミスも少なくなります。
レプリケートする属性セットにより、レプリケートされるすべてのエントリがスキーマに準拠できない場合、コンシューマ・サーバーでのスキーマ・チェックをオフにする必要があります。スキーマに準拠しないエントリをレプリケートしても、レプリケーション・メカニズムはコンシューマ上でのスキーマ・チェックを行わないため、エラーは発生しません。ただし、スキーマに準拠しないエントリがコンシューマに含まれるようになるので、クライアントに対して一貫した状態にするにはスキーマ・チェックをオフにする必要があります。
部分レプリケーションは、マスター・レプリカのハブおよび専用コンシューマとのレプリケーション承諾に構成されます。マルチマスター・レプリケーション環境の2つのマスター・レプリカ間での部分レプリケーションの構成はサポートされていません。また、複数のマスターが同じレプリカとのレプリケーション承諾を持つ場合、これらすべての承諾で同じ属性セットをレプリケートする必要があります。
部分レプリケーションを構成するには、接尾辞を指定し、その接尾辞で属性を含めるか除外するかを決定して、どの属性を含めるまたは除外するかを選択します。ある接尾辞の属性を除外するように選択した場合、他のすべての属性が自動的に含まれます。同様に、ある接尾辞の属性を含めるように選択した場合、他のすべての属性は自動的に除外されます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
ソース・サーバーにあるレプリケーション承諾で部分レプリケーションを構成します。
$ dsconf set-repl-agmt-prop -h host -p port suffix-DN consumer-host:consumer-port\ property:value
propertyは、repl-fractional-exclude-attrまたはrepl-fractional-include-attrです。
たとえば、JPEGとTIFFの画像を接尾辞dc=example,dc=comでレプリケート対象外にするよう部分承諾を構成する場合、次のコマンドを使用します。
$ dsconf set-repl-agmt-prop -h host2 -p 1389 dc=example,dc=com host1:1389 repl-fractional-exclude-attr:jpegPhoto repl-fractional-exclude-attr:tiffPhoto
除外する属性の既存リストに属性を追加するには、次のコマンドを使用します。
$ dsconf set-repl-agmt-prop -h host -p port suffix-DN consumer-host:consumer-port\ repl-fractional-exclude-attr+:attribute
レプリケーションの優先順位の指定は必須ではありません。ユーザー・パスワードの更新などの特定の変更を高い優先順位でレプリケートするように指定するレプリケーション・ルールを作成できます。レプリケーション・ルールに指定されたすべての変更は、高い優先順位でレプリケートされ、他のすべての変更は、通常の優先順位でレプリケートされます。
|
注意: バージョン6以降では、レプリケーションの優先順位ルールはマスター・サーバーのみで作成する必要があります。ハブおよびコンシューマでの構成は必要ありません。 |
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
マスターに新しいレプリケーションの優先順位ルールを作成するには、次のコマンドを使用します。
$ dsconf create-repl-priority -h host -p port suffix-DN priority-name property:value
次の優先順位を1つ以上使用して、レプリケーション優先順位を設定できます。
操作タイプ、op-type
バインドDN、bind-dn
ベースDN、base-dn
属性タイプ、attr
priority-nameはユーザー定義となります。
たとえば、ユーザー・パスワードの変更を高い優先順位でレプリケートするように指定するレプリケーション・ルールを作成するには、次のコマンドを使用します。
$ dsconf create-repl-priority -h host2 -p 1389 dc=example,dc=com pw-rule \ attr:userPassword
現在のレプリケーション・ルールを表示するには、dsconf list-repl-priorities -vコマンドを使用します。-vオプション付きでこのコマンドを使用した場合、優先順位付きレプリケーション・ルールに関する追加情報が表示されます。
$ dsconf list-repl-priorities -h host2 -p 1389 -v
詳細は、dsconfに関する説明のマニュアル・ページを参照してください。
レプリケーション承諾を作成し、両方のレプリカを構成したら、レプリケーションを開始する前に、コンシューマのレプリケートされた接尾辞を初期化する必要があります。初期化の際は、サプライヤのレプリケートされた接尾辞からコンシューマのレプリケートされた接尾辞へ物理的にデータをコピーします。
また、特定のエラーが発生した場合、または構成を変更した場合は、レプリカを初期化しなおす必要があります。たとえば、なんらかの理由で1つのマスターのレプリケートされた接尾辞をバックアップからリストアした場合、更新されるすべてのレプリカを初期化しなおす必要があります。
再初期化時には、コンシューマのレプリケートされた接尾辞の内容は削除され、マスターの接尾辞の内容で置換されます。これにより、レプリカの同期が確保され、レプリケーションの更新が再開されます。この項で説明するどの方法で初期化を行っても、コンシューマ・レプリカの索引は自動的に再作成されるため、クライアントからの読取りリクエストにもただちに正しく対応できます。
マルチマスター・レプリケーションでは、トポロジの他のマスターによって更新されたコンシューマであれば、初期化しなおす必要がない場合もあります
既存のレプリケーション承諾を使用して、リモート・サーバーから接尾辞を初期化できます。この方法は他の方法ほど複雑ではないので、できるかぎりこの方法を使用してください。データが大量でインポートに時間がかかりすぎる場合にのみ他の方法を使用してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
DSCCを使用して、オンラインでレプリケートされた接尾辞を初期化する方法により、簡単にコンシューマの初期化または再初期化が行えます。ただし、多数のエントリを初期化する場合、このプロセスでは時間がかかる可能性があります。このような場合、コマンドラインによるオフラインでのコンシューマの初期化がより効率的となることもあります。
レプリカを初期化します。
$ dsconf init-repl-dest -h host -p port suffix-DN destination-host:destination-port\ [destination-host:destination-port]
destination-host:destination-portは、リモート・サーバーから初期化するターゲット・サーバーのホストおよびポートです。
各承諾に対して、接尾辞が初期化済となっていることをチェックします。
$ dsconf show-repl-agmt-status -h host -p port suffix-DN destination-host:destination-port
次の手順では、LDIFファイルからレプリケートされた接尾辞を初期化するために使用する一般的な手順について説明します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
DSCCを使用して、オンラインでレプリケートされた接尾辞を初期化する方法により、簡単にコンシューマの初期化または再初期化が行えます。ただし、多数のエントリを初期化する場合、このプロセスでは時間がかかる可能性があります。このような場合、コマンドラインによるオフラインでのコンシューマの初期化がより効率的となることもあります。
レプリケーション承諾が設定されていることを確認します。
レプリカの初期化の前に、これを行う必要があります。
接尾辞データのオリジナル・コピーをマスターのレプリケートされた接尾辞からLDIFファイルにエクスポートします。
「レプリケートされた接尾辞をLDIFにエクスポートするには:」を参照してください。
マルチマスター・レプリケーション環境では、オリジナルのマスターからエクスポートされたLDIFファイルを使用して、他のマスターおよびあらゆるコンシューマを初期化できます。カスケード型のレプリケーション環境では、同じファイルを使用して、ハブ・レプリカとそのコンシューマを初期化できます。
すべての場合において、構成したマスター・レプリカからエクスポートされたLDIFファイルで開始する必要があります。任意のLDIFファイルにはレプリケーション・メタデータが含まれないので、これを使用してすべてのレプリカを初期化することはできません。
部分レプリカを初期化する場合、ファイルのフィルタ処理により、レプリケートされる属性のみを保持した後、そのファイルをすべてのコンシューマ・サーバーに転送します。
「部分レプリケーションに対するLDIFファイルのフィルタ処理」を参照してください。
レプリカを初期化します。
次のいずれかを実行します。
オフライン(停止中)のサーバーで高速の初期化を行うためには、dsadm importコマンドを使用します。
$ dsadm import instance-path LDIF_file suffix-DN
オンラインで、LDIFファイルからレプリカを初期化するには、dsconf importコマンドを使用します。
$ dsconf import -h host -p port LDIF_file suffix-DN
dsconf importを使用すると、dsadm importを使用した場合よりも遅くなりますが、インポート操作の実行中にサーバーを停止させる必要がありません。
接尾辞の初期化の詳細およびその例は、「接尾辞の初期化」を参照してください。コマンド使用方法の詳細は、dsadmについての説明およびdsconfについての説明を参照してください。
各承諾に対して、接尾辞が初期化済となっていることをチェックします。
$ dsconf show-repl-agmt-status -h host -p port suffix-DN destination-host:destination-port
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次のコマンドのいずれかを使用して、レプリケートされた接尾辞の内容をLDIFファイルにエクスポートします。
オフラインでのエクスポートでは、次を入力します。
$ dsadm export instance-path suffix-DN LDIF_file
オンラインでのエクスポートでは、次を入力します。
$ dsconf export -h host -p portsuffix-DN LDIF_file
次の例では、dc=example,dc=comのレプリケートされた接尾辞全体とレプリケーション情報をファイルexample_replica_export.ldifにエクスポートします。
$ dsconf export -h host2 -p 1389 dc=example,dc=com \ /local/dsInst/ldif/example_export_replica.ldif
詳細は、「LDIFへのバックアップ」、dsadmについての説明およびdsconfについての説明のマニュアル・ページを参照してください。
DSCCの使用時には、部分レプリケーションが構成されたレプリカの初期化は透過的なものとなります。初期化時は、選択された属性のみがコンシューマに送信されます。
部分レプリケーションを構成した場合、エクスポートしたLDIFファイルをコンシューマ・サーバーにコピーする前に、使用しない属性をフィルタで除外する必要があります。Directory Serverでは、このためのfildifツールが用意されています。このツールは、指定したLDIFファイルをフィルタ処理し、レプリケーション承諾に定義されている属性セットが許可する属性のみを残します。
このツールではサーバー構成を読み取り、属性セットの定義を特定します。構成ファイルを読み取るには、fildifツールをrootとして実行するか、プロセスとファイルを所有するユーザー(nsslapd-localuser属性により指定)として実行する必要があります。たとえば、次のコマンドでは前述の例でdc=example,dc=com接尾辞からエクスポートされたファイルをフィルタ処理します。
$ fildif -i /local/ds1/ldif/example_master.ldif \ -o /local/ds1/ldif/filtered.ldif -b "cn=host2.example.com:1389, \ cn=replica,cn=\\"dc=example,dc=com\\",cn=mapping tree,cn=config" -p /local/ds1
fildifコマンドの場所は、「コマンドの場所」を参照してください。
-iおよび-oオプションは、それぞれ入力ファイルおよび出力ファイルです。-bオプションは、部分レプリケーションを定義するレプリケーション承諾のDNです。このDNは、次のコマンドを使用して検索できます。
$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b "cn=config" "(&(objectclass=nsds5replicationagreement)\ (nsDS5ReplicaPort=replica-port) (nsDS5ReplicaHost=replica-host))" dn
次に例を示します。
$ ldapsearch -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "cn=config" "(&(objectclass=nsds5replicationagreement) \ (nsDS5ReplicaPort=2090)(nsDS5ReplicaHost=host2))" dn Enter bind password: version: 1 dn: cn=host2:1389,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config
fildifツールのすべてのコマンドライン構文は、fildifのマニュアル・ページを参照してください。
さらに、fildifで生成されたfiltered.ldifファイルを使用して、このレプリケーション承諾のコンシューマを初期化できます。ファイルをコンシューマ・サーバーに転送して、「LDIFファイルからのデータのインポート」の説明どおりにインポートします。
バイナリ・コピーにより、サーバーからのバイナリ・バックアップ・ファイルを使用して別のサーバーに同じディレクトリ内容をリストアすることで、サーバー全体をクローニングできます。バイナリ・コピーを使用して、マスターまたはハブ・サーバーのバイナリ・コピーから任意のサーバーを初期化または再初期化できます。または別のコンシューマ・サーバーのバイナリ・コピーからコンシューマを初期化または再初期化できます
|
注意: この高度な手順では、Directory Server上のデータベース・ファイルとの間で情報をやり取りするため、経験が豊富な管理者以外は使用しないでください。 この機能にはある種の制限が適用されるため、処理時間の短縮を見込めるのは、たとえば100万件単位のエントリを含むレプリカなど、大容量のデータベース・ファイルを持つレプリカのみです。 |
バイナリ・コピーは、あるマシンから別のマシンにデータベース・ファイルを移動するため、次の制限が厳密に適用されます。
両方のマシンが同じオペレーティング・システム(サービス・パックやパッチも含む)を実行している必要があります。
両方のマシンで同じプロセッサ・アーキテクチャを使用している必要があります。たとえば、2つのUltraSPARC T1プロセッサ間ではバイナリ・コピーを実行できますが、UltraSPARC T1とAMD Opteronプロセッサ間では実行できません。
両方のマシンがビッグ・エンディアンかリトル・エンディアンである必要があります。
両方のマシンがメモリーを同じようにマップしている必要があります。たとえば、2つの64ビット・システム上のサーバー・インスタンス間でのバイナリ・コピーは実行できますが、32ビット・システムのサーバー・インスタンスと64ビット・システムのサーバー・インスタンス間では実行できません。
両方のマシンに同じバージョンの(バイナリ形式(32ビットまたは64ビット)、サービス・パック、パッチも含まれる)Directory Serverがインストールされている必要があります。
両方のサーバーは、同じ接尾辞に分岐する同じディレクトリ・ツリーを持つ必要があります。すべての接尾辞のデータベース・ファイルが一緒にコピーされる必要があります。接尾辞は個別にコピーできません。
各接尾辞は、両方のサーバーで構成された同じ索引(VLV(仮想リスト表示)索引を含む)を持つ必要があります。接尾辞のデータベースは、同じ名前である必要があります。
各サーバーは、レプリカとして構成された同じ接尾辞を持つ必要があります。
部分レプリケーションが構成されている場合、すべてのサーバーが同じように構成されている必要があります。
どちらのサーバーでも属性の暗号化は使用しないでください。
属性値の一意性プラグインが有効な場合は、両方のサーバーで同じ設定にします。また、次の手順で、新しいコピーを設定しなおす必要があります
次の手順では、バイナリ・コピーを実行する別の方法(サーバー停止を必要としないバイナリ・コピー、およびディスク領域が最小ですむバイナリ・コピー)を説明します。
この項では、サーバーを初期化するためのバイナリ・コピーの作成方法、および使用ディスク容量が最小になるバイナリ・コピーの作成方法を説明します。
次の手順を使用して、レプリケートするサーバーを初期化するためのバイナリ・コピーを実行します(通常のバックアップ機能を使用して、サーバーのデータベース・ファイルのコピーを作成するためです)。標準バックアップを実行することにより、サーバー停止の必要なしにすべてのデータベース・ファイルを一定の状態に維持できます。
この手順には、特定の制限があります。バックアップおよびリストア操作では、同じマシンにデータベース・ファイルのコピーを作成するので、各マシンでこれらのファイルが占有するディスク容量が2倍になります。また、ディレクトリがGB単位のデータを含んでいる場合、それらのファイルの実際のコピー操作には非常に時間がかかる場合があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
新しくレプリケートされた接尾辞用のターゲット・マシンにDirectory Serverをインストールして、必要に応じてサーバーの新しいインスタンスを作成した後、「レプリケーションでのバイナリ・コピー使用に関する制限事項」に従ってサーバーを構成します。
このレプリケートされた接尾辞に関連するレプリケーション・トポロジにすべてのレプリケーション承諾を作成します。
サプライヤからこのレプリカに承諾を含めます。このレプリカが専用コンシューマでない場合は、このレプリカからコンシューマに承諾を含めます。「レプリケーション承諾の作成および変更」を参照してください。
初期化するもの(マスター、ハブまたはコンシューマ)と同じ種類の、完全に設定され、初期化されたレプリカを選択し、「バイナリ・バックアップ」に従って通常のバックアップを実行します。
たとえば、ftpコマンドを使用して、バックアップ・ディレクトリからターゲット・マシンのディレクトリにファイルをコピーまたは転送します。
マルチマスター・レプリケーションのシナリオにおいて、新しいマスターを初期化した場合、「マルチマスター・シナリオでのマスターのリストア」の手順に従います。
この手順では、データベース・ファイルのバックアップ・コピーを作成しないため、少ないディスク領域ですみ、時間もかかりません。ただし、データベース・ファイルの整合状態を保証するために、クローニング中のサーバーを停止させる必要があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
新しくレプリケートされた接尾辞用のターゲット・マシンにDirectory Serverをインストールして、必要に応じてサーバーの新しいインスタンスを作成した後、「レプリケーションでのバイナリ・コピー使用に関する制限事項」に従ってサーバーを構成します。
このレプリカに関連するレプリケーション・トポロジにすべてのレプリケーション承諾を作成します。
サプライヤからこのレプリカに承諾を含めます。このレプリカが専用コンシューマでない場合は、このレプリカからコンシューマに承諾を含めます。「レプリケーション承諾の作成および変更」を参照してください。
初期化または再初期化するターゲット・サーバーを、「Directory Serverインスタンスの起動、停止および再起動」の説明のとおりに停止させます。
初期化するもの(マスター、ハブまたはコンシューマ)と同じタイプの完全に構成され初期化されたレプリカを選択し、このサーバーも停止します。
マルチマスター構成でマスター・レプリカをクローニングしている場合、停止する前に、他のマスターからのすべての最新の変更が完全に反映されていることを確認します。
ソースおよびターゲット・サーバーを再起動します。
カスケード型レプリケーションの場合、常に次の手順で示す順番で、レプリカを初期化します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
マルチマスター・レプリケーションもある場合、1つのマスターにレプリケートするすべてのデータセットが存在することを確認し、このマスターを使用して、他の各マスターのレプリカを初期化します。
それぞれのマスター・レプリカから、最初のレベルのハブ・レプリカのレプリカを初期化します。
ハブのレベルがいくつかある場合、以前に初期化したハブ・レベルから各レベルを初期化します。
最後のレベルのハブ・レプリカから、専用コンシューマのレプリカを初期化します。
索引はサーバーから別のサーバーへ自動的にレプリケートされません。レプリケートされた接尾辞を保持するすべてのサーバー・インスタンスの属性の索引を作成するには、次のいずれかの操作を実行します。
DSCCを使用して、レプリケートされた接尾辞を保持するすべてのサーバー・インスタンスをサーバー・グループとして管理します。索引をグループ内の1つのサーバーに追加した後、サーバー構成のコピー・アクションを使用して、グループ内の他のサーバーに索引設定をコピーします。
DSCCの詳細は、「Directory Service Control Centerのインタフェース」を参照してください。
第12章「Directory Serverの索引付け」の説明のとおりに、dsconfコマンドを使用して、各サーバー・インスタンスの索引を管理します。
「バイナリ・コピーを使用したレプリケートされた接尾辞の初期化」の説明のとおりに、バイナリ・コピーを使用して接尾辞を初期化します。
膨大なエントリ数があるディレクトリに、さらに大量のエントリを追加する場合、時間がかかりすぎるため、ldapmodify -aの使用は避けてください。そのかわりに、dsconf importコマンドにレプリケートされるトポロジにエントリを追加するオプションを付けて実行し、新しいエントリを増分的に追加します。エントリをインポートすると、レプリケーション・メタデータとともに追加分を含んだLDIFファイルが生成されます。次に、この生成されたLDIFファイルを他のレプリカにインポートします。この生成されたLDIFファイルにより、データを追加するレプリカ全体でレプリケーションの同期が確実に保たれます。
開始する前に
この手順により、大規模なLDIFファイルが生成されます。最初のdsconf importコマンドを実行する前に、生成されるLDIFファイルに対して使用できるディスク領域が十分にあることを確認してください。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
|
注意: この手順を使用して、複数のパスに大量のエントリがあるサーバーを初期化できます。ただし、いずれかのインポートが失敗すると、データベース全体が消失する可能性があります。各インポートの前には、必ずデータをバックアップしてください。 |
任意のマスター・レプリカで、エントリをインポートします。
$ dsconf import -h host -p port -K generated-LDIF-file suffix-DN
-Kオプションにより、既存データが削除されません。さらに、新しいエントリとレプリケーション・プロセスに必要な情報を格納するファイルgenerated-LDIF-fileも生成されます。
他のすべてのレプリカで、前の手順で作成されたファイルをインポートします。
$ dsconf import -h host -p port \ -K -f incremental-output=no generated-LDIF-file suffix-DN
オプション-f incremental-output=noは、追加のLDIFファイルを生成しないことを示します。この手順で必要となる生成済LDIFファイルは1つのみです。
レプリケーションで参照整合性プラグインを使用している場合、すべてのマスター・サーバーでそれを有効にする必要があります。ハブまたはコンシューマ・サーバーで有効にする必要はありません。
次に、レプリケーション環境における参照整合性プラグインの使用に関する制限を示します。
このプラグインはマスター・レプリカを含むすべてのサーバーで有効とする必要があります。
すべてのサーバーで、同じ構成によりプラグインを有効にする必要があります。
ハブまたはコンシューマ・レプリカのみを含むサーバーで有効にしても意味がありません。
参照整合性プラグインの構成の詳細は、「参照整合性プラグインを構成するには:」を参照してください。
すべてのレプリケーション操作がSSL接続で行われるように、レプリケーションに関わるDirectory Serverを構成できます。
次の手順では、2つのマスターを持つレプリケーション・トポロジーで、レプリケーションを構成するコマンド例を示します。
|
注意: この例では、インスタンス作成中に生成された自己署名証明書を使用した、簡単なレプリケーション構成を示します。本番環境では、SSLでのレプリケーションを設定している場合、認証局(CA)によって信頼された証明書をかわりに使用すると、セキュリティが強化されます。 サプライヤ・サーバーの証明書が、SSLハンドシェイク時にクライアントとして機能できないSSLサーバー専用の証明書である場合、SSLでのレプリケーションは正常に機能しません。 |
レプリケーションがSSLによってセキュリティ保護されていても、レプリケーション・マネージャの認証はまだ簡単なバインドとパスワードを使用して行われます。クライアントベースの認証を使用すれば、レプリケーションのセキュリティを万全にできますが、より複雑な設定が必要になります。クライアントベースの認証を使用したレプリケーションの詳細は、「SSL用クライアント認証ベースのレプリケーションを構成するには:」を参照してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
新しいサーバーを作成し、それらを起動します。
$ dsadm create -p 1389 -P 1636 /local/ds1 $ dsadm create -p 2389 -P 2636 /local/ds2 $ dsadm start /local/ds1 $ dsadm start /local/ds2
SSL構成の詳細は、「Directory ServerでのSSLの使用方法」を参照してください。
すべてのサーバーで、空の接尾辞を作成します。
$ dsconf create-suffix -e -w password-file -p 1389 dc=example,dc=com $ dsconf create-suffix -e -w password-file -p 2389 dc=example,dc=com
すべてのサーバーで、マルチマスターのパスワード・ファイルを設定します。
$ dsconf set-server-prop -e -i -w password-file -h example1.server -p 1389 \ def-repl-manager-pwd-file:/local/ds1/replmanrpwd1.txt $ dsconf set-server-prop -e -i -w password-file -h example2.server -p 2389 \ def-repl-manager-pwd-file:/local/ds1/replmanrpwd2.txt
すべてのサーバーで、レプリケーションを有効にします。
$ dsconf enable-repl -h example1.server -p 1389 -e -i -w password-file \ -d 1 master dc=example,dc=com $ dsconf enable-repl -h example2.server -p 2389 -e -i -w password-file \ -d 2 master dc=example,dc=com
すべてのサーバーで、既存のデフォルト証明書をエクスポートします。
$ dsadm show-cert -F der -o certfile1 /local/ds1 defaultCert $ dsadm show-cert -F der -o certfile2 /local/ds2 defaultCert
すべてのサーバーで、他のすべてのサーバーから証明書を追加します。
$ dsadm add-cert --ca /local/ds1 "ds2 Repl Manager Cert" certfile2 $ dsadm add-cert --ca /local/ds2 "ds1 Repl Manager Cert" certfile1
構成したサーバー間でレプリケーション承諾を作成します。
レプリケーション承諾には、セキュアなLDAPポートを使用します。
$ dsconf create-repl-agmt -h example1.server -p 1389 -e -i -w password-file\ --auth-protocol "ssl-simple" dc=example,dc=com example2.server:2636 $ dsconf create-repl-agmt -h example2.server -p 2389 -e -i -w password-file\ --auth-protocol "ssl-simple" dc=example,dc=com example1.server:1636
すべてのレプリケーション承諾で、認証パスワード・ファイルを、レプリケーション承諾内のコンシューマ(ターゲット)サーバーのレプリケーション・マネージャ・パスワード・ファイルとして設定します。
$ dsconf set-repl-agmt-prop -h example1.server -p 1389 -e -i -w password-file\ dc=example,dc=com example2.server:2636 auth-pwd-file:/local/ds1/replmanrpwd2.txt $ dsconf set-repl-agmt-prop -h example2.server -p 2389 -e -i -w password-file\ dc=example,dc=com example1.server:1636 auth-pwd-file:/local/ds1/replmanrpwd1.txt
接尾辞の初期化後、サプライヤはすべてのレプリケーション更新メッセージをコンシューマにSSLで送信します。オプションで選択されている場合には証明書が使用されます。また、SSL用の承諾構成を使用して、DSCCからカスタマの初期化を実行する場合も、セキュアな接続が使用されます。
すべてのサーバーで、構成の変更を反映するため、サーバーを再起動します。
$ dsadm restart /local/ds1 $ dsadm restart /local/ds2
いずれかのマスター・サーバーで、接尾辞を初期化します。
$ dsconf import -h example1.server -p 1389 -e -i \
-w password-file /tmp/Example.ldif dc=example,dc=com
まだ初期化されていないすべてのサーバーで、レプリケーション承諾を使用してサーバーを初期化します。
$ dsconf init-repl-dest -e -i -w password-file \
-h example1.server -p 1389 dc=example,dc=com example1.server:2636
次の手順では、信頼できる認証局(CA)からの適切に署名された証明書/鍵のペアをリクエスト済で、かつそれらの認証局のCA証明書がすべてのセキュリティ・データベースに存在することを前提としています。
証明書/鍵のペアはレプリケーションの権限を持つユーザーに対して発行する必要があります。つまり、証明書の対象はサーバー間のレプリケーション・データ転送を許可されたユーザーのDNとなります。次の例では、それらのユーザーはou=user1,o=usersおよびou=user1,o=usersであり、セキュリティ・データベースの証明書の略名はそれぞれreplmgr1およびreplmgr2となります。
新しいサーバーを作成します。
$ dsadm create -p 1389 -P 1636 /local/ds1 $ dsadm create -p 2389 -P 2636 /local/ds2
CAで受け取られたユーザー証明書/鍵のペアを、各サーバーに追加します。
$ dsadm import-cert /local/ds1 user1.der $ dsadm import-cert /local/ds2 user2.der
user1.derおよびuser2.derはCAから提供されるファイルです。
後で使用するため、ユーザー証明書をエクスポートします。
$ dsadm show-cert -F ascii /local/ds1 replmgr1> user1.ldif $ dsadm show-cert -F ascii /local/ds2 replmgr2> user2.ldif
このファイルには、base64でエンコードしたバイナリ証明書を含める必要があります。
サーバーを起動します。
$ dsadm start /local/ds1 $ dsadm start /local/ds2
すべてのサーバーで空の接尾辞を作成します。ユーザーおよびユーザー証明書はそこに格納されることになります。
$ dsconf create-suffix -p 1389 -e o=example.com $ dsconf create-suffix -p 2389 -e o=example.com $ dsconf create-suffix -p 1389 -e o=users $ dsconf create-suffix -p 2389 -e o=users
|
注意: ユーザーおよびユーザー証明書を別の接尾辞に入れることもできます。レプリケートされる接尾辞そのものにユーザーを含めることはお薦めできません。 |
すべてのサーバーで、レプリケーションを有効にします。
$ dsconf enable-repl -p 1389 -e -d 1 master o=example.com $ dsconf enable-repl -p 2389 -e -d 1 master o=example.com
レプリケーション・マネージャとして設定されるユーザーを用意します。user1.ldifおよびuser2.ldifを次のように編集します。
dn: cn=user1,o=users objectclass: top objectclass: inetorgperson sn: user1 userCertificate;binary:: MIIBqDCCARGgAwIBAgI <...> dXNlcnMwHh <...> <...>
ファイルは有効なLDIFファイルである必要があります。
BEGIN CERTIFICATEおよびEND CERTIFICATEの行を削除します。userCertificate;binary::の値は、単にbase64でエンコードされたものです。これが複数行に及ぶ場合、行の最初の文字をスペースにする必要があります。
ユーザーがレプリケートを許可される予定のサーバーで、ユーザー定義を追加します。
$ ldapmodify -p 1389 -D binddn -w password -a < user2.ldif $ ldapmodify -p 2389 -D binddn -w password -a < user1.ldif
|
注意:
|
サーバー間レプリケートを許可されたユーザーをレプリケーション・マネージャとして設定します。
$ dsconf -p 1389 set-suffix-prop repl-manager-bind-dn: cn=user2,o=users $ dsconf -p 2389 set-suffix-prop repl-manager-bind-dn: cn=user1,o=users
ユーザー証明書/鍵を自身のものとして使用するようサーバー証明書を設定します。
$ dsconf -p 1389 set-server-prop ssl-rsa-cert-name:replmgr1 $ dsconf -p 2389 set-server-prop ssl-rsa-cert-name:replmgr2
新しい変更が反映されるようにサーバーを再起動します。
$ dsadm restart /local/ds1 $ dsadm restart /local/ds2
レプリケーション承諾を作成します。
$ dsconf create-repl-agmt -p 1389 -e -A ssl-client o=example.com hostname:2636 $ dsconf create-repl-agmt -p 2389 -e -A ssl-client o=example.com hostname:1636
Directory Serverでは、広域ネットワーク(WAN)によって接続されたマシン間のマルチマスター・レプリケーションを含むあらゆる形式のレプリケーションを実行できます。このレプリケーションにより、サプライヤ・サーバーは、待機時間が大きく、帯域幅が小さいネットワーク経由で、最適な帯域幅を使用することによりコンシューマを初期化し、更新できます。
|
注意: WAN経由でレプリケートするレプリケーション・トポロジのデプロイメントまたはトラブルシューティングを行う場合、ネットワークの速度、待機時間、およびパケット・ロスを調べる必要があります。これらのいずれかの点で、ネットワークの問題があると、レプリケーションの遅延が発生する可能性があります。 また、レプリケーション・データの転送率は、使用可能な物理媒体が帯域幅に関して許可している転送率を常に下回ります。レプリカ間の更新が有効帯域幅と物理的に見合わないほどの量である場合、更新負荷が大きくなったときにレプリカ間に差異が生じることを、チューニングによって回避できなくなります。レプリケーションの遅延と更新のパフォーマンスは、様々な要因によります。それらには変更率、エントリ・サイズ、サーバー・ハードウェア、エラー率、平均待機時間および平均帯域幅が含まれますが、これらのみに限られるわけではありません。 使用している環境でのレプリケーションについて質問は、Sunサービス・プロバイダまでお問合せください。 |
レプリケーション・メカニズムの内部パラメータは、デフォルトでWAN用に最適化されています。ただし、前述の要因などが原因でレプリケーションが遅くなるときは、ウィンドウ・サイズとグループ・サイズのパラメータを調節してみてください。また、ネットワークのピーク時を避けてレプリケーションをスケジュールすることで、ネットワークの全体的な利用率を高めることができますさらに、Directory Serverでは、帯域幅の使用率を最適化するためにレプリケーション・データ圧縮をサポートしています。
ネットワーク経由でエントリをより効率的に送信するために、レプリケーション・メカニズムがエントリをグループ化する方法は、ウィンドウとグループ・ネットワーク・パラメータによって決定されます。これらのパラメータは、サプライヤおよびコンシューマのレプリケーションの更新メッセージや確認応答の交換方法にも反映されます。すべてのレプリケーション承諾のパラメータは構成可能であるため、各コンシューマの特定のネットワーク状況に従ってレプリケーション・パフォーマンスを調整できます。
変更の効果を任意に監視して、適宜パラメータを調整します。手順は、「レプリケーション・ステータスの取得」を参照してください。ウィンドウとグループのサイズ・パラメータを変更するときに、レプリケーションを中断する必要はありません。
ウィンドウ・サイズ(デフォルト値10)は、コンシューマからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。
各メッセージ後の確認応答を待たずに、素早く連続して多くのメッセージを送信した方が効率が上がります。適切なウィンドウ・サイズを使用することにより、レプリカがレプリケーション更新または確認応答の着信を待つ間に費やす時間を削減できます。
コンシューマ・レプリカがサプライヤに遅れをとっている場合、さらに調整を行う前にウィンドウ・サイズをデフォルトよりも高い値(100など)に設定して、レプリケーション・パフォーマンスを再度チェックします。レプリケーションの更新頻度が高く、更新間隔が短い場合は、LAN(ローカル・エリア・ネットワーク)接続のレプリカでも、ウィンドウ・サイズを大きくすることでパフォーマンスが向上する可能性があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
ウィンドウ・サイズを変更します。
$ dsconf set-repl-agmt-prop -h host -p port suffix-DN consumer-host:consumer-port\ transport-window-size:value
次に例を示します。
$ dsconf set-repl-agmt-prop -h host2 -p 1389 dc=example,dc=com host1:1389 \ transport-window-size:20
グループ・サイズ(デフォルト値1)は、1つの更新メッセージにバンドルできるデータ変更の最大数を表します。ネットワーク接続によりレプリケーションが阻害されているような場合、グループ・サイズをデフォルトよりも高い値(10など)に設定して、レプリケーション・パフォーマンスを再度チェックします。
グループ・サイズを増加させる場合は、次のことが該当することを確認します。
ウィンドウ・サイズがグループ・サイズよりも大幅に高く設定されている。
ウィンドウ・サイズをグループ・サイズで割った数は、コンシューマのcn=configの下にあるnsslapd-maxThreadsPerConnの値を大きく上回っている(標準は2倍)。
グループ・サイズが1より高く設定されている場合、サプライヤはグループが満たされるのを待たずに、コンシューマへ更新を送信します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
グループ・サイズを変更します。
$ dsconf set-repl-agmt-prop -h host -p port suffix-DN \ consumer-host:consumer-port transport-group-size:value
次に例を示します。
$ dsconf set-repl-agmt-prop -h host2 -p 1389 dc=example,dc=com host1:1389 \ transport-group-size:10
レプリカ間の即時同期が重要でない場合、ネットワークの使用量が少ない時間にレプリケーションをスケジュールできます。ネットワークの使用が空いているほど、データのレプリケーションの完了は大幅に早まります。
日または週単位で、1 日の特定の時間にレプリケーションを開始および終了するようにスケジュールできます。これは、レプリケーション承諾により、コンシューマごとに個別に実行できます。新しいスケジュールはただちに有効になり、対応するコンシューマに対する次回のデータのレプリケーションは、スケジュールと合致する日時になった時点で行われます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
レプリケーション・スケジュールを変更します。
$ dsconf set-repl-agmt-prop -h host -p port suffix-DN \ host:port repl-schedule:value
たとえば、レプリケーションを毎晩 2:00 から 4:00 までの間に行うように設定する場合、次のように入力します。
$ dsconf set-repl-agmt-prop -h host2 -p 1389 dc=example,dc=com host1:1389 \ repl-schedule:"0200-0400 0123456"
0123456は曜日を示し、0は日曜日、1は月曜日のように表します。
レプリケーションで使用する帯域幅を削減するために、コンシューマの更新時に送信されるデータを圧縮するようにレプリケーションを設定できます。レプリケーション・メカニズムでは、Zlib圧縮ライブラリが使用されます。圧縮を有効にするには、SolarisまたはLinuxプラットフォームでサプライヤとコンシューマの両方が稼働している必要があります。
WAN環境で予想されるレプリケーションの利用状況に対して、最高の結果が得られる圧縮レベルを実験的にテストし、選択する必要があります。ネットワーク帯域幅が広いLANではこのパラメータを設定しないでください。圧縮と圧縮解除の計算により、レプリケーションが遅くなります。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
マスター・サーバーのレプリケーション承諾エントリでレプリケーション圧縮を構成します。
$ dsconf set-repl-agmt-prop -h host -p port suffix-DN \ consumer-host:consumer-port transport-compression:level
levelには、high、medium、lowまたはnoneを指定できます。
たとえば、host1:1389のコンシューマにレプリケーション更新を送信する場合、最速の圧縮を使用するには、次を入力します。
$ dsconf set-repl-agmt-prop -h host2 -p 1389 dc=example,dc=com host1:1389 \ transport-compression:high
圧縮レベル設定の詳細は、Oracle Directory Server Enterprise Editionのリファレンスを参照してください。
この項では、既存レプリケーション・トポロジの管理の次の側面について説明します。
レプリケーション承諾を編集して、コンシューマ・サーバーへのバインドに使用するレプリケーション・マネージャ・アイデンティティを変更できます。レプリケーションが中断されないように、レプリケーション承諾を変更する前に、新しいレプリケーション・マネージャ・エントリまたはコンシューマの証明書エントリを定義する必要があります。バインドの失敗によってレプリケーションが中断された場合、レプリケーション・リカバリ設定の制限内でエラーを修正したときは、レプリケーション・メカニズムによって必要なすべての更新が自動的に送信されます。手順は、「デフォルト以外のレプリケーション・マネージャの使用方法」を参照してください。
レプリケーション承諾は、無効化、有効化または削除できます。
レプリケーション承諾が無効になると、マスターは指定のコンシューマへの更新の送信を停止します。そのサーバーに対するレプリケーションは停止しますが、承諾内の設定はすべて保存されています。後で承諾を再度有効にすることにより、レプリケーションを再開できます。中断後のレプリケーション・メカニズムの再開については、「レプリケーション承諾の有効化」を参照してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
レプリケーション承諾を無効化します。
$ dsconf disable-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port
次に例を示します。
$ dsconf disable-repl-agmt -h host2 -p 1389 dc=example,dc=com host1:1389
レプリケーション承諾を有効にすると、指定コンシューマでレプリケーションが再開されます。ただし、レプリケーション・リカバリ設定の許容時間よりもレプリケーション中断時間が長く、別のサプライヤによるそのコンシューマの更新がなかった場合は、そのコンシューマは初期化しなおす必要があります。レプリケーション・リカバリ設定には、サプライヤの変更ログの最大サイズと最大経過時間、およびコンシューマのパージ遅延があります(「詳細コンシューマ構成を実行するには」を参照)。
中断時間が短く、レプリケーションがリカバリできる場合は、承諾が再度有効になったときにマスターがコンシューマを自動的に更新します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
レプリケーション承諾を有効にします。
$ dsconf enable-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port
次に例を示します。
$ dsconf enable-repl-agmt -h host2 -p 1389 dc=example,dc=com host1:1389
レプリケーション承諾を削除すると、対応するコンシューマのレプリケーションは停止され、承諾に関するすべての設定情報が失われます。後日、レプリケーションを再開する場合は、「レプリケーション承諾の無効化」の説明に従って、かわりに承諾を無効にします。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
レプリケーション承諾を削除します。
$ dsconf delete-repl-agmt -h host -p port suffix-DN consumer-host:consumer-port
次に例を示します。
$ dsconf delete-repl-agmt -h host2 -p 1389 dc=example,dc=com host1:1389
レプリカの昇格または降格により、レプリケーション・トポロジにおけるレプリカのロールが変化します。専用コンシューマはハブに昇格でき、ハブはマスターに昇格できます。マスターはハブに降格でき、ハブも専用コンシューマに降格できます。ただし、マスターは直接コンシューマには降格できず、同様にコンシューマも直接マスターに昇格できません。
マルチマスター・レプリケーション・メカニズム内で許される昇格および降格により、トポロジがとても柔軟になります。以前はコンシューマ・レプリカにより提供されていたサイトが大きくなると、負荷を処理するため、いくつかのレプリカを持つハブが必要になります。負荷にレプリカの内容に対する変更が多く含まれている場合、ハブはマスターとなり、他のサイトの他のマスターへのレプリケートが可能なより迅速なローカルな変更を行うことができます。
レプリカの昇格または降格時は、次のことに注意してください。
コンシューマを昇格させるとハブになります。ハブを昇格させるとマスターになります。サーバーをコンシューマからマスターに直接昇格させることはできません。まず、コンシューマをハブに昇格させてから、ハブをマスターに昇格させる必要があります。同様に、マスターをコンシューマに降格させる場合、マスターをハブに降格させた後にハブをコンシューマに降格させる必要があります。
マスターをハブに降格させる場合、レプリカは読取り専用となり、残りのマスターにレフェラルを送信するように構成されます。この新しいハブは、そのコンシューマ(ハブまたは専用コンシューマ)をすべて維持します。
シングル・マスターがハブに降格することにより、マスター・レプリカのないトポロジが作成されます。Directory Serverでは、新しいマスターが定義されることを前提に、これが認められます。ただし、新しいマスターをマルチマスターとして追加し、他のマスターを降格させる前に、その新しいマスターを初期化できるようにしておくことをお薦めします。
ハブをコンシューマに降格させる前に、そのハブとのレプリケーション承諾をすべて無効にするか削除する必要があります。これを行わないと、降格操作は、LDAP_OPERATIONS_ERROR "Unable to demote a hub to a read-only replica if some agreements are enabled"というエラーを伴い、失敗することになります。
このハブの下のコンシューマが、他のハブまたはマスターによって更新されていなかった場合、このコンシューマは更新されなくなります。これらのコンシューマが更新されるように、残りのハブまたはマスターに新しい承諾を作成する必要があります。
コンシューマをハブに昇格させると、変更ログが有効になり、コンシューマとの間で新しい承諾を定義できます。
ハブをマスターに昇格させると、レプリカは変更リクエストを受け付けて、他のマスター、ハブまたは専用コンシューマとの間で新しい承諾を定義できます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次のコマンドのいずれかを使用して、レプリカを昇格または降格させます。
dsconf promote-repl [-d REPL_ID] SUFFIX_DN [SUFFIX_DN...] $ dsconf promote-repl -h host -p port [-d REPL_ID] SUFFIX_DN [SUFFIX_DN...] $ dsconf demote-repl -h host -p port SUFFIX_DN [SUFFIX_DN...]
レプリケートされた接尾辞を無効にすると、それはレプリケーション・トポロジから削除されます。設定されている役割 (マスター、ハブ、またはコンシューマ) に応じて、そのレプリケートされたサフィックスは更新されなくなり、更新を送信しなくなります。サプライヤ・サーバーの接尾辞を無効にすると、すべてのレプリケーション承諾が削除され、再びレプリカを有効にするときは、これらの承諾を作成しなおす必要があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
レプリケートされた接尾辞を無効にします。
$ dsconf disable-repl -h host -p port suffix-DN
次に例を示します。
$ dsconf disable-repl -h host2 -p 1389 dc=example,dc=com
定期メンテナンスのためにレプリケーションに関わるDirectory Serverを停止させた後、オンラインに戻す場合、レプリケーションによってただちに更新されるようにする必要があります。マルチマスター環境のマスターの場合、マルチマスターセットのもう一つのサーバーからディレクトリ情報を更新する必要があります。マルチマスター以外の環境でも、ハブ・サーバーや専用コンシューマ・サーバーがメンテナンスのためにオフラインとなった後、オンラインに復帰したときには、マスター・サーバーによりそれらを更新する必要があります。
この項では、レプリケーションの再試行アルゴリズムおよび、次回の再試行まで待たずに強制的にレプリケーション更新を行う方法を説明します。
|
注意: ここで説明されている手順を利用できるのは、レプリケーションの設定が完了し、およびコンシューマが初期化済である場合にかぎります。 |
ソース・レプリカのターゲットへのレプリケーションが失敗すると、間隔を増加させながら定期的に再試行が行われます。再試行の間隔はエラー・タイプにより異なります。
ソース・レプリカとターゲット・レプリカの間で、常に同期をとるレプリケーション承諾を設定していても、オフライン状態の時間が5分を超えたレプリカをただちに更新するには、この方法では不十分です。
レプリケーションを停止した場合、ターゲットの接尾辞に対して、レプリケーションの更新を強制的に実行できます。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
ソース・サーバーで、ターゲット・サーバーに対するレプリケーション更新を再起動します。
$ dsconf update-repl-dest-now -h host -p port suffix-DN destination-host:destination-port
次に例を示します。
$ dsconf update-repl-dest-now -h host2 -p 1389 dc=example,dc=com host1:1389
状況によっては、マスター・レプリカを別のマシンへ移動することが必要になる場合があります。同じホスト名およびポート番号を使用する必要がない場合、dsconf change-repl-destを使用してリモート・レプリカのホスト名とポート番号を変更します。詳細は、「レプリケーション承諾の対象を変更するには:」を参照してください。
同じホスト名およびポート番号を維持する必要がある場合は、既存のトポロジからマスターを削除した後、トポロジにマスターを再度追加する必要があります。
DSCCでは、影響を受けるレプリケーション承諾をすべて管理しているので、DSCCを使用してこの作業を実行するほうがずっと簡単です。ただし、DSCCを使用する場合、マスターがトポロジで元々持っていたものと同じレプリカIDは指定できません。同じレプリカIDを使用するには、次のようにコマンドラインを使用して、これらのタスクを実行する必要があります。
開始する前に
マスターからのすべての変更がレプリケート済であることを確認します。
可能であれば、バイナリ・コピーを使用してマスターのバックアップを行い、変更が失われないようにします。
マスター・レプリカをハブ・レプリカに降格させます。
「レプリカの昇格と降格」を参照してください。
ハブが他のサーバーに対するレプリケートを開始するのを待ちます。
ハブがトポロジ内の他のサーバーに対してレプリケーション・セッションを開くと、そのセッションはRUVに残りますが、レフェラルでは使用されなくなります。
ハブを停止します。
「Directory Serverインスタンスの起動、停止および再起動」を参照してください。
トポロジからハブを削除します。
「レプリケートされた接尾辞の無効化」を参照してください。
同じレプリカIDを使用して、マスター・レプリカを追加します。
「マスター・レプリカでのレプリケーションの有効化」を参照してください。
このマスターからトポロジ内の他のレプリカへのレプリケーション承諾を再度作成します。
新しいマスターを初期化します。
マスターのバックアップが可能だった場合は、そのバックアップから新しいマスターを初期化します。
マスターのバックアップができなかった場合(マシン・クラッシュの場合)は、トポロジ内の別のマスターからマスターを初期化します。
このセクションでは、Directory Server 11gリリース1 (11.1.1.6)より前のリリースでのレプリケーションの構成方法について説明します。
Directory Server 11gリリース1 (11.1.1.6)、6および5.2は、レプリケーションの構成に関して互換性がありますが、次の例外があります。
バージョン5.2では、レプリケーションの優先順位をサポートしていません。11gリリース1 (11.1.1.6)のマスター・レプリカでレプリケーションの優先順位を構成する場合、レプリケーションの優先順位はDirectory Server 11gリリース1 (11.1.1.6)を実行するコンシューマには転送されますが、それよりも前のバージョンのDirectory Serverを実行するコンシューマには転送されません。
無制限のマスター数は、Directory Server 5.2のマスターを含むレプリケーション・トポロジではサポートされません。Directory Server 11gリリース1 (11.1.1.6)では、レプリケーション・トポロジ内の無制限のマスター数をサポートしていますが、Directory Server 5.2のマスター・サーバーを含むレプリケーション・トポロジでは、その数は4に制限されます。
レトロ変更ログは、Directory Serverのデータに対する変更の履歴を確認するため、LDAPクライアントで使用されるものです。レトロ変更ログは接尾辞cn=changelogの下に、Directory Serverの変更ログとは別のデータベースに格納されます。
レトロ変更ログは、スタンドアロン・サーバーまたはレプリケーション・トポロジ内の各サーバーで有効にできます。サーバーでレトロ変更ログが有効になっている場合、デフォルトではそのサーバー上のすべての接尾辞に対する更新がログに記録されます。レトロ変更ログは、指定した接尾辞に対する更新のみを記録するように構成することもできます。
レプリケートされるトポロジでレトロ変更ログを使用する方法、およびレトロ変更ログの使用上の制限事項については、Oracle Directory Server Enterprise Editionのリファレンスのレプリケーションとレトロ変更ログ・プラグインに関する項を参照してください。
レトロ変更ログのエントリの属性については、changeLogEntryのマニュアル・ページを参照してください。
レトロ変更ログの変更の詳細は、dsconfについての説明のマニュアル・ページを参照してください。
この項では、レトロ変更ログの様々な使用方法について説明します。
レトロ変更ログを使用にするには、これを有効にする必要があります。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
レトロ変更ログの構成エントリを変更します。
$ dsconf set-server-prop -h host -p port retro-cl-enabled:on
サーバーを再起動します。
詳細は、「Directory Serverインスタンスの起動、停止および再起動」を参照してください。
サーバーでレトロ変更ログが有効になっている場合、デフォルトではサーバー上のすべての接尾辞に対する更新が記録されます。この手順では、指定した接尾辞の更新のみを記録するよう、レトロ変更ログを構成する方法について説明します。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
レトロ変更ログの構成エントリを変更します。
$ dsconf set-server-prop -h host -p port retro-cl-suffix-dn:suffix-DN
たとえば、cn=Contractors,dc=example,dc=com接尾辞とou=People,dc=example,dc=com接尾辞の変更のみを記録するには、次のコマンドを使用します。
$ dsconf set-server-prop -h host2 -p 1389 \ retro-cl-suffix-dn:"cn=Contractors,dc=example,dc=com" \ retro-cl-suffix-dn:"ou=People,dc=example,dc=com"
指定した接尾辞の既存のリストに接尾辞を追加するには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port retro-cl-suffix-dn+:suffix-DN
サーバーを再起動します。
詳細は、「Directory Serverインスタンスの起動、停止および再起動」を参照してください。
この手順では、エントリが削除されたときにそのエントリの指定された属性を記録するようにレトロ変更ログを構成する方法について説明します。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
記録する必要がある属性を指定します。
$ dsconf set-server-prop -h host -p port retro-cl-deleted-entry-attr: \ attribute1 attribute2
たとえば、削除されたエントリのUID属性を記録するようにレトロ変更ログを設定するには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port retro-cl-deleted-entry-attr:uid
指定された属性の既存のリストに属性を追加するには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port retro-cl-deleted-entry-attr+:attribute
サーバーを再起動します。
詳細は、「Directory Serverインスタンスの起動、停止および再起動」を参照してください。
レトロ変更ログのエントリは、指定した期間の経過後に自動的に削除できます。エントリを自動的に削除するまでの期間を構成するには、レトロ変更ログが有効であることを確認してから、cn=Retro Changelog Plugin, cn=plugins, cn=configエントリにnsslapd-changelogmaxage構成属性を設定します。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
レトロ変更ログが有効であることを確認します。
$ dsconf get-server-prop -h host -p port retro-cl-enabled
レトロ変更ログが有効でない場合は、それを有効にします。
$ dsconf set-server-prop -h host -p port retro-cl-enabled:on
ロギングする変更の最大経過時間を設定します。
$ dsconf set-server-prop -h host -p port retro-cl-max-age:duration
durationは、undefined(経過時間無制限)または次のいずれかにできます。
s (秒)
m (分)
h (時間)
d (日)
w (週)
たとえば、レトロ変更ログの最大経過時間を2日に設定するには、次を入力します。
$ dsconf set-server-prop -h host 2 -p 1389 retro-cl-max-age:2d
この期間を過ぎたエントリは、5分ごとに変更ログから削除されます。
レトロ変更ログでは、検索操作をサポートしています。これは、次の形式のフィルタを含む検索用に最適化されています。
(&(changeNumber>=X)(changeNumber<=Y))
原則として、レトロ変更ログのエントリでの追加および変更操作は行わないでください。ログ・サイズを縮小するには、エントリを削除できます。レトロ変更ログでの変更操作の実行が必要になるのは、デフォルトのアクセス制御ポリシーを変更する場合のみです。
レトロ変更ログが作成されると、デフォルトで次のアクセス制御ルールが適用されます。
読取り、検索および比較の権限はディレクトリ・マネージャに付与されます。
書込みおよび削除アクセスは認められません。ただし、ディレクトリ・マネージャには暗黙的に認められます。
レトロ変更ログのエントリにはパスワードなどの機密情報が含まれる場合があるので、匿名のユーザーには読取りアクセス権を付与しないでください。認証されたユーザーにもログ内容の閲覧を許可しない場合、レトロ変更ログの内容へのアクセス制限を強化することもできます。
レトロ変更ログに適用されるデフォルトのアクセス制御ポリシーを変更するには、cn=changelogエントリのaci属性を変更します。第6章「Directory Serverのアクセス制御」を参照してください。
レプリケーション・ステータスは、DSCCまたはコマンドライン・ツールを使用して取得できます。
「接尾辞」タブの使用により、レプリケーション承諾およびレプリケーション遅延を含めたレプリケーションのグラフィカル表示が可能です。詳細は、DSCCのオンライン・ヘルプを参照してください。
さらにDSCCを使用して、レプリケーション・トポロジを表示することもできます。
DSCCが使用できない場合は、コマンドライン・ツールを使用して、レプリケーション・デプロイメントについての情報を取得します。
マニュアル・ページでは、これらのツールの全コマンドライン構文と使用例を提供しています。
repldisc - レプリケーション・デプロイメント内のすべての既知のサーバーを検出して、それらの表を構築します。repldiscについての説明のマニュアル・ページを参照してください。
insync - サプライヤ・レプリカと1つ以上のコンシューマ・レプリカとの間の同期状態を示します。insyncについての説明のマニュアル・ページを参照してください。
entrycmp - 複数レプリカの内の同じエントリを比較します。entrycmpについての説明のマニュアル・ページを参照してください。
これらのコマンドがあるディレクトリを見つけるには、「コマンドの場所」を参照してください。
マルチマスター・レプリケーションでは、ゆるやかな一貫性を持つレプリケーション・モデルを使用します。これは同一エントリを別々のサーバーで同時に変更できることを意味します。2つのサーバー間で更新が送信された場合、変更の競合を解決する必要があります。ほとんどの場合、解決は自動で行われます。たとえば、各サーバーの変更に関連付けられたタイムスタンプは優先される直近の変更により解決されます。しかし、一部の変更の競合には、解決に至るまでに手動操作が必要になるものもあります。
この項の内容は次のとおりです。
レプリケーションの競合を解決する最も簡単な方法は、DSCCを使用することです。詳細は、DSCCのオンライン・ヘルプを参照してください。
コマンドラインの使用により、レプリケーション競合を解決できます。レプリケーション・プロセスでの自動解決が不可能な変更の競合があるエントリには、競合マーカーとしての操作属性nsds5ReplConflictが含まれます。
競合するエントリを検出するには、定期的にこの属性を含むエントリを検索します。たとえば、次のldapsearchコマンドを使用して、競合のあるエントリを検索できます。
$ ldapsearch -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config \ -w - -b "dc=example,dc=com" "(nsds5ReplConflict=*)"
nsds5ReplConflict属性はデフォルトで索引が付けられます。
サーバー同士が互いの変更をレプリケートする前に、エントリが作成された場合、同じDNを持つエントリが別々のマスターで作成される場合があります。レプリケーションでは、競合解決のメカニズムにより2番目に作成されたエントリの名前が自動的に変更されます。
DNの名前が競合するエントリは、操作属性nsuniqueidにより指定される一意の識別子をDN内に含めることで名前を変更します。
たとえば、エントリuid=bjensen,ou=People,dc=example,dc=comが2つのマスターで同時に作成された場合、レプリケーション後の2つのエントリは次のようになります。
uid=bjensen,ou=People,dc=example,dc=com
nsuniqueid=66446001-1dd211b2-66225011-2ee211db+uid=bjensen,dc=example,dc=com
2番目のエントリには、実用的なDNを与える必要があります。競合するエントリを削除して、競合しない名前を付けて再度追加することもできます。ただし、エントリ名の変更により、内容まで変わってしまうことはありません。名前の変更手順は、ネーミング属性が単一値を持つか複数値を持つかかにより異なります。次の手順を参照してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
古いRDN値を維持しながら、エントリ名を変更します。たとえば、次のようになります。
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: nsuniqueid=66446001-1dd211b2-66225011-2ee211db+uid=bjensen,dc=example,dc=com changetype: modrdn newrdn: uid=bj66446001 deleteoldrdn: 0 ^D
この手順で古いRDN値は削除できません。これが削除できないnsuniqueidの操作属性を含むためです。
ネーミング属性の古いRDN値と競合マーカー属性を削除します。たとえば、次のようになります。
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bj66446001,dc=example,dc=com changetype: modify delete: uid uid: bjensen - delete: nsds5ReplConflict ^D
dc(ドメイン・コンポーネント)など、重複エントリのネーミング属性が単一値の場合、エントリ名を単純に同じ属性の他の値に変更することはできません。かわりに、エントリには一時的な名前を付与する必要があります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
異なるネーミング属性を使用してエントリ名を変更し、古いRDN値は維持します。たとえば、次のようになります。
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: nsuniqueid=66446001-1dd211b2-66225011-2ee211db+dc=HR,dc=example,dc=com changetype: modrdn newrdn: o=TempHREntry deleteoldrdn: 0 ^D
この手順で古いRDN値は削除できません。これが削除できないnsuniqueidの操作属性を含むためです。
目的のネーミング属性を一意の値に変更して、競合マーカー属性を削除します。たとえば、次のようになります。
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: o=TempHREntry,dc=example,dc=com changetype: modify replace: dc dc: NewHR delete: nsds5ReplConflict ^D
エントリ名を変更して、目的のネーミング属性に戻します。たとえば、次のようになります。
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: dc=NewHR,dc=example,dc=com changetype: modrdn newrdn: dc=HR deleteoldrdn: 1 ^D
deleteoldrdn属性の値を1に設定することにより、一時的な属性と値のペアo=TempHREntryを削除します。この属性を維持する場合は、deleteoldrdn属性の値を0に設定します。
削除操作がレプリケートされ、かつコンシューマ・サーバーで削除するエントリに子エントリがあることが判明した場合、競合解決プロシージャによってglueエントリが作成され、ディレクトリに親のないエントリが生じる事態を回避します。
同様に、追加操作がレプリケートされ、かつコンシューマ・サーバーで親エントリを検出できない場合も、競合解決プロシージャにより親を表すglueエントリが作成され、新しいエントリが親のないエントリとなる事態を回避します。
glueエントリは、オブジェクト・クラスglueおよびextensibleObjectを持つ一時的なエントリです。glueエントリは、次の様々な方法で作成できます。
競合解決プロシージャにより、一致する一意の識別子を持つ削除されたエントリが見つかった場合は、glueエントリはそのエントリの復元となります。これにはglueオブジェクト・クラスとnsds5ReplConflict属性も含まれます。
このような場合では、glueエントリを変更してglueオブジェクト・クラスとnsds5ReplConflict属性を削除し、通常のエントリとして維持するか、またはglueエントリとその子エントリを削除します。
サーバーにより、glueおよびextensibleObjectオブジェクト・クラスを持つ最小限のエントリが作成されます。
このような場合には、エントリを変更して意味のあるエントリとするか、またはエントリとそのすべての子エントリ削除します。
メール・サーバーのように属性の一意性に依存するアプリケーションとの相互運用性のため、nsds5ReplConflict属性を持つエントリへのアクセス制限が必要となる場合があります。これらのエントリに対するアクセスを制限しない場合は、1つの属性のみを要求するアプリケーションが元のエントリとnsds5ReplConflictを含む競合解決エントリの両方を取得し、処理が失敗します。
アクセスを制限するには、次のコマンドを使用して、匿名の読取りアクセスを許可するデフォルトのACIを変更する必要があります。
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: dc=example,dc=com changetype: modify delete: aci aci: (target ="ldap:///dc=example,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=example,dc=com") (targetattr!="userPassword") (targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare) (userdn="ldap:///anyone");) ^D
新しいACIは、nsds5ReplConflict属性を含むエントリが検索結果として返されないようにします。
