test

Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド

第 11 章 Directory Server のレプリケーション

レプリケーションは、Directory Server のディレクトリの内容を別の 1 つまたは複数の Directory Server に自動的にコピーするメカニズムです。すべての書き込み操作が自動的に他の Directory Server にミラー化されます。レプリケーションは、サポートされているさまざまなプラットフォーム間でできます。サポートされているプラットフォームのリストについては、『Sun Java System Directory Server Enterprise Edition 6.3 リリースノート』の「プラットフォームのサポート」を参照してください。レプリケーションの概念、レプリケーションの導入例、特定のディレクトリ配備でのレプリケーションの計画方法の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』を参照してください。

レプリケーショントポロジでは、一般にサーバー上のサフィックスとサーバー上の別のサフィックス間でレプリケートします。このため、レプリカ、レプリケートされたサフィックス、レプリケートされたサーバーという語は同じ意味で使うことができます。

この章では、コマンド行を使用したレプリケーションのさまざまな導入例の設定作業について説明します。説明する内容は次のとおりです。

レプリケーション配備の計画

無限の数のマスターによるレプリケーション配備を設定できます。配備にハブやコンシューマを含める必要はありません。ハブやコンシューマのレプリケーションを設定する手順も、この章で説明しますが、必須の作業ではありません。

レプリケーションの設定を始める前に、組織でレプリケーションを配備する方法を十分に理解している必要があります。『Sun Java System Directory Server Enterprise Edition 6.3 Reference 』で説明するレプリケーションの概念を理解する必要があります。さらに、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』で説明している設計ガイドラインを使用して、今後のレプリケーション設定を慎重に計画することも必要です。

レプリケーションの設定と管理に推奨されるインタフェース

最も簡単にレプリケーションを設定し、管理する方法は、Directory Service Control Center (DSCC) を使用することです。DSCC を使用すると、自動的にレプリケーションを設定できます。レプリケーショントポロジの設定に必要な自動化のレベルを選択できます。たとえば、レプリケーションの設定時にサフィックスを初期化するかどうかを選択できます。DSCC には、エラーを回避できるチェックも備えられています。さらに、DSCC ではレプリケーショントポロジをグラフィカルに表示します。

DSCC のオンラインヘルプに、DSCC を使用してレプリケーションを設定する手順を説明しています。

注 –

この章で説明するコマンド行の手順は、レプリケーションの設定に DSCC を使用できない場合にのみ使用してください。

レプリケーションの設定手順の概要

「レプリケーションの設定手順の概要」では、1 つのサフィックスをレプリケートすることを前提としています。複数のサフィックスをレプリケートする場合は、各サーバーでサフィックスを並行して設定する必要があります。つまり、複数サフィックスのレプリケーションを設定するには、各手順を繰り返す必要があります。

この章の後半で、レプリケーションの設定方法を詳しく説明します。

Procedureレプリケーションの設定手順の概要

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

レプリケーショントポロジを設定するには、次の手順で説明するような一般的な手順に従います。

  1. すべてのサーバーで次の操作を実行し、サーバー上に専用のコンシューマレプリカを作成します。

    1. コンシューマのレプリカサフィックス用の空のサフィックスを作成します。

      「コンシューマのレプリカサフィックスを作成する」を参照してください。

    2. コンシューマのレプリカサフィックスを有効にします。

      「コンシューマレプリカを有効にする」を参照してください。

    3. (省略可能) コンシューマの詳細設定を行います。

      「コンシューマの詳細設定を行う」を参照してください。

  2. ハブの設定が必要な場合は、すべてのサーバーで次の手順を実行し、ハブのレプリカサフィックスをサーバー上に作成します。

    1. ハブのレプリカサフィックス用の空のサフィックスを作成します。

      「ハブのレプリカサフィックスを作成する」を参照してください。

    2. ハブのレプリカサフィックスを有効にします。

      「ハブレプリカを有効にする」を参照してください。

    3. (省略可能) ハブの詳細設定を行います。

      「ハブレプリカの更新履歴ログ設定を変更する」を参照してください。

  3. すべてのサーバーで次の手順を実行し、マスターのレプリカサフィックスをサーバー上に作成します。

    1. マスターのレプリカサフィックス用のサフィックスを作成します。

      「マスターレプリカのサフィックスを作成する」を参照してください。

    2. マスターのレプリカサフィックスを有効にします。

      「マスターレプリカを有効にする」を参照してください。

    3. (省略可能) マスターの詳細設定を行います。

      「マスターレプリカの更新履歴ログ設定を変更する」を参照してください。

    注 –

    レプリケーションアグリーメントを作成する前に、すべてのレプリカを有効にし、レプリケーションアグリーメントの作成後すぐにコンシューマレプリカを初期化できるようにします。コンシューマの初期化は、常にレプリケーションの設定の最後の段階で実行します。

  4. レプリケーションマネージャーの設定が完了していることを確認します。

  5. 次のようにして、すべてのマスターレプリカにレプリケーションアグリーメントを作成します。

    1. マルチマスタートポロジのマスター間

    2. マスターと専用コンシューマの間

    3. マスターとハブレプリカの間

    「レプリケーションアグリーメントの作成と変更」を参照してください。

  6. (省略可能) 部分レプリケーションを使用する場合は、ここで設定します。

    「部分レプリケーション」を参照してください。

  7. (省略可能) レプリケーションの優先順位を使用する場合は、ここで設定します。

    「レプリケーションの優先順位」を参照してください。

  8. ハブレプリカとそのコンシューマとの間のレプリケーションアグリーメントを設定します。

    「レプリケーションアグリーメントの作成と変更」を参照してください。

  9. マルチマスターレプリケーションでは、データのオリジナルコピーを含むマスターレプリカから順にすべてのマスターを初期化します。

    「レプリカの初期化」を参照してください。

  10. ハブとコンシューマレプリカを初期化します。

    「レプリカの初期化」を参照してください。

専用コンシューマ上でのレプリケーションの有効化

専用コンシューマは、レプリケートされたサフィックスの読み取り専用コピーです。専用コンシューマは、レプリケーションマネージャーとしてバインドされたサーバーから更新を受け取り、変更を行います。コンシューマサーバーの設定では、レプリカサフィックス用に空のサフィックスを準備し、そのサフィックスのレプリケーションを有効にします。オプションの詳細設定では、リフェラルの設定、削除の遅延の変更、プロパティーの変更などが含まれます。

次の節では、サーバー上で、専用コンシューマ用にレプリケートされたサフィックスを設定する方法について説明します。専用コンシューマ用にレプリケートされたサフィックスを設定したいすべてのサーバーに対して、同じ手順を繰り返してください。

Procedureコンシューマのレプリカサフィックスを作成する

  1. 空のサフィックスをまだ作成していない場合は、レプリケーションの対象となるマスターレプリカと同じ DN を使用してコンシューマに空のサフィックスを作成します。

    手順については、「サフィックスの作成」を参照してください。

    注意 – 注意 –

    すでにサフィックスが存在し、それが空でない場合は、マスターからレプリケートされたサフィックスが初期化されたときにそのサフィックスの内容は失われます。

Procedureコンシューマレプリカを有効にする

空のサフィックスを作成したら、コンシューマのレプリカサフィックスを有効にする必要があります。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. コンシューマのレプリカサフィックスを有効にします。


    $ dsconf enable-repl -h host -p port consumer suffix-DN

    次に例を示します。


    $ dsconf enable-repl -h host1 -p 1389 consumer dc=example,dc=com

Procedureコンシューマの詳細設定を行う

高度な機能を使用するため、コンシューマのレプリカサフィックスを設定する場合は、ここで実行します。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. リフェラルに 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 を使用してマスターにバインドするオプションをクライアントに提供するには、ldaps:// servername :port という形式でリフェラルを追加します。port にはセキュリティー保護された接続に使うポート番号を指定します。マスターがセキュリティー保護された接続のみに設定されていれば、URL はデフォルトでセキュリティー保護されたポートを指定します。

    リフェラルとして 1 つまたは複数の LDAP URL を追加したときは、コンシューマがマスターレプリカのリフェラルではなく、これらの LDAP URL のリフェラルを送信するようにすることができます。たとえば、クライアントが常にデフォルトのポートではなく、マスターサーバーのセキュリティー保護されたポートを参照するようにするとします。これらのセキュリティー保護されたポートの LDAP URL のリストを作成し、これらのリフェラルを使用して、プロパティーを設定します。すべての更新を処理する特定のマスターまたは Directory Server プロキシを指定する場合も、排他的なリフェラルを使用することができます。

  2. コンシューマのレプリケーション削除の遅延を変更する場合は、次のコマンドを使用します。


    $ 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

    コンシューマサーバーは、レプリケートされたサフィックスの内容に加えられる変更に関する内部情報を格納し、削除の遅延はこの情報を保持する期間を決定します。削除の遅延は、コンシューマとマスター間のレプリケーションを中断して、なお正常に回復できる期間を決定する要素の一つとなります。この値は、サプライヤサーバーの更新履歴ログの MaxAge パラメータと関連付けられています。これらの 2 つのパラメータのうち、短いほうの設定が、2 つのサーバー間のレプリケーションが無効になった、またはダウンした場合でも正常な状態に復元できる最長期間を決定します。ほとんどの場合には、デフォルトの 7 日間が適当です。

ハブ上でのレプリケーションの有効化

ハブレプリカは、コンシューマとしてだけではなく、マスターとしても機能し、レプリケートされたデータをより多くのコンシューマに配信します。このため、レプリケーションの更新をそれぞれのサプライヤから受信して、レプリケーションの更新をそれぞれのコンシューマに送信します。ハブレプリカは変更を受け付けませんが、マスターにリフェラルを返します。

ハブサーバーの設定では、レプリカサフィックス用に空のサフィックスを準備し、そのサフィックスのレプリケーションを有効にします。必要に応じて、異なるレプリケーションマネージャーの選択、リフェラルの設定、削除の遅延の設定、更新履歴ログパラメータの変更など、詳細な設定も行うことができます。

次の節では、1 つのハブサーバーを設定する方法を説明します。ハブのレプリカサフィックスを含むすべてのサーバーで、同じ手順を繰り返してください。

Procedureハブのレプリカサフィックスを作成する

  1. 空のサフィックスをまだ作成していない場合は、レプリケーションの対象となるマスターレプリカと同じ DN を使用してハブサーバーに空のサフィックスを作成します。

    手順については、「サフィックスの作成」を参照してください。

    すでにサフィックスが存在し、それが空でない場合は、マスターからレプリケートされたサフィックスが初期化されたときにそのサフィックスの内容は失われます。

Procedureハブレプリカを有効にする

ハブレプリカがある場合は、それらをここで有効にします。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. ハブのレプリカサフィックスを有効にします。


    $ dsconf enable-repl -h host -p port hub suffix-DN

    次に例を示します。


    $ dsconf enable-repl -h host1 -p 1389 hub dc=example,dc=com

Procedureハブレプリカの更新履歴ログ設定を変更する

ハブの詳細設定で、変更する必要があるパラメータは更新履歴ログに関するものだけです。サプライヤとして、ハブサーバーは更新履歴ログが必要です。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. ハブの更新履歴ログ設定を変更するには、次のいずれかのコマンドを使用します。


    $ dsconf set-suffix-prop -h host -p port suffix-DN repl-cl-max-age:value


    $ dsconf set-suffix-prop -h host -p port suffix-DN repl-cl-max-entry-count:value

マスターレプリカ上でのレプリケーションの有効化

マスターレプリカにはデータのマスターコピーが含まれ、更新を他のすべてのレプリカに配信する前に、すべての変更を集中的に管理します。マスターはすべての変更を記録し、関連する各コンシューマの状態を確認して、必要に応じて更新を送信します。マルチマスターレプリケーションでは、マスターレプリカが他のマスターから更新を受け取ることもあります。

マスターサーバーを設定するときは、マスターレプリカを含むサフィックスを決定し、マスターレプリカを有効にします。また、必要に応じてレプリケーションの詳細設定を行います。

次の節では、1 つのマスターサーバーを設定する方法を説明します。特定のマスターのレプリカサフィックスを含むすべてのサーバーで、同じ手順を繰り返してください。

Procedureマスターレプリカのサフィックスを作成する

  1. レプリケートするエントリを保存するマスターサーバー上でサフィックスを選択、または作成します。

    手順については、「サフィックスの作成」を参照してください。

    マルチマスター設定と初期化を正しく実行するため、データを含む 1 つのマスターのみを読み込みます。他のレプリケートされたサフィックスのデータは上書きされます。

Procedureマスターレプリカを有効にする

マスターのレプリケーションを有効にする場合は、レプリケーション ID を割り当てる必要があります。レプリケーション ID は、更新ステートメントの所有者を区別し、マルチマスターレプリケーションで発生する可能性のある競合を解決するために使用します。そのため、このサフィックスのすべてのマスターレプリカで、レプリケーション ID が一意である必要があります。レプリケーション ID は設定すると変更できません。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. マスターのレプリカサフィックスを有効にします。


    $ 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

Procedureマスターレプリカの更新履歴ログ設定を変更する

マスターの詳細設定では、更新履歴ログ設定を変更する場合があります。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. マスターの更新履歴ログ設定を変更する場合は、次のいずれかのコマンドを使用します。


    $ dsconf set-server-prop -h host -p port suffix-DN repl-cl-max-age:value


    $ dsconf set-server-prop -h host -p port suffix-DN repl-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 とそのパスワードは、あとからこのコンシューマのサプライヤとの間でレプリケーションアグリーメントを作成するときに必要です。

Procedureデフォルト以外のレプリケーションマネージャーを設定する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. すべてのコンシューマ (ターゲット) のレプリカサフィックスに対して、新しいレプリケーションマネージャーとパスワードを作成します。


    $ 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

  2. すべてのコンシューマ (ターゲット) のレプリカサフィックスに対して、レプリケーションマネージャーバインド 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"

  3. すべてのサプライヤ (ソース) のレプリカサフィックスに作成したすべてのレプリケーションアグリーメントに、レプリケーションマネージャーバインド DN を設定します。

    1. 新しいレプリケーションマネージャーパスワードを設定する一時ファイルを作成します。

      このファイルが一度読み取られ、パスワードは将来使用するために格納されます。


      $ echo password > password-file

    2. 更新の実行時に、レプリケーションメカニズムで使用するレプリケーションマネージャーバインド 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

    3. 一時パスワードファイルを削除します。


      $ rm password-file

Procedureデフォルトのレプリケーションマネージャーパスワードを変更する

  1. レプリケーションマネージャーパスワードを設定するための一時ファイルを作成します。

    このファイルが一度読み取られ、パスワードは将来使用するために格納されます。


    $ echo password > password-file

  2. レプリケーショントポロジのすべてのコンシューマ (ターゲット) サーバーに、レプリケーションマネージャーバインドパスワードを設定します。


    $ 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

  3. 一時パスワードファイルを削除します。


    $ rm password-file

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

レプリケーションアグリーメントはサプライヤのパラメータのセットで、指定したコンシューマに更新を送信する方法を設定し、制御します。コンシューマに更新を送信するサプライヤのレプリカサフィックスには、レプリケーションアグリーメントを作成する必要があります。更新するすべてのコンシューマのサプライヤにレプリケーションアグリーメントを作成する必要があります。

Procedureレプリケーションアグリーメントを作成する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

DSCC を使用して、新しいレプリケーションアグリーメントを作成する場合、既存のレプリケーションアグリーメントから一部またはすべてのレプリケーションアグリーメント設定をコピーすることができます。

  1. マスターサーバーから、レプリケートする各コンシューマのレプリケーションアグリーメントを作成します。


    $ 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) で新しいアグリーメントを作成する必要があります。

  2. レプリケーションアグリーメントが正しく作成されていることを確認します。


    $ dsconf show-repl-agmt-status -h host -p port suffix-DN consumer-host:consumer-port

  3. 認証状態が OK でない場合は、dsconf accord-repl-agmt コマンドを実行します。

    注 –

    コマンド 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

Procedureレプリケーションアグリーメントの対象を変更する

この手順では、既存のレプリケーションアグリーメントで指定されたリモートレプリカを変更します。既存のアグリーメントのサフィックス DN と設定は同じままです。

  1. レプリケーションアグリーメントのリモートレプリカのホスト名とポート番号を変更します。


    $ dsconf change-repl-dest -h host -p port suffix-DN host:port new-host:new-port

    このコマンドで -A protocol オプションを指定して実行すると、レプリケーションで使用される認証プロトコルを変更できます。

部分レプリケーション

デフォルトでは、レプリケーション操作によって、レプリケートされたサフィックスに含まれるすべてのエントリがコンシューマレプリカにコピーされます。部分レプリケーション機能を用いると、選択したサフィックスのどの属性をレプリケーションの対象とし、どの属性を対象外とするかを選択できます。部分レプリケーションはレプリケーションアグリーメントに設定されるので、マスターのコンシューマのレプリカサフィックスごとに属性セットを定義できます。配信するデータを制御し、レプリケーションの帯域幅とコンシューマリソースをより効率的に利用できます。

たとえば、photo、jpegPhoto、audio のように一般に値が大きい属性をレプリケーションの対象外とすることで、レプリケーションの帯域幅を節約できます。この場合、コンシューマではこれらの属性を利用できなくなります。また、認証に必要な uid 属性と userpassword 属性だけをコンシューマサーバーにレプリケートすることもできます。

部分レプリケーションに関する注意点

注 –

部分レプリケーションは、Directory Server 5.2 より前のバージョンの製品では使用できません。部分レプリケーションアグリーメントを設定する場合は、マスターとコンシューマレプリカが共に Directory Server 5.2 以上を使用している必要があります。

属性の部分的なセットを有効化または変更するには、コンシューマレプリカを初期化し直す必要があります。このため、配備前に部分レプリケーションの必要性を検討し、レプリケートされたサフィックスを初期化する前に属性セットを設定しておく必要があります。

ACI、ロール、CoS などの複雑な機能が特定の属性に依存する小規模な属性セットをレプリケートするときは、慎重な対応が必要です。さらに、ACI、ロール、または CoS メカニズムの指示子やフィルタで示されているその他の属性をレプリケートしないと、データのセキュリティーが損なわれる可能性があります。レプリケートしないと、検索で返される属性セットが異なる可能性もあります。レプリケーションの対象に含める属性のリストを管理するよりも、除外する属性のリストを管理する方法が安全であり、人的なミスも少なくなります。

レプリケートするすべてのエントリがスキーマに準拠しない属性セットをレプリケートするときは、コンシューマサーバーのスキーマチェックを無効にする必要があります。スキーマに準拠しないエントリをレプリケートしても、レプリケーションメカニズムはコンシューマ上でのスキーマチェックを行わないため、エラーは発生しません。しかし、スキーマに準拠しないエントリがコンシューマに含まれるようになるので、クライアントにとって一貫した状態にする必要があるためスキーマチェックを無効にする必要があります。

部分レプリケーションは、ハブと専用コンシューマのマスターレプリカのレプリケーションアグリーメントに設定します。マルチマスターレプリケーション環境の 2 つのマスターレプリカ間での部分レプリケーションは設定できません。また、複数のマスターが同じレプリカとの間でレプリケーションアグリーメントを持つ場合、同じ属性セットをレプリケートするようにすべてのアグリーメントを設定する必要があります。

Procedure部分レプリケーションを設定する

部分レプリケーションを設定するには、サフィックスを指定し、そのサフィックスの属性を含めるか除外するかを決定して、含めるかまたは除外する属性を選択します。サフィックスの属性を除外するように選択すると、他のすべての属性が自動的に含まれます。同様に、サフィックスの特定の属性を含めるように選択すると、他のすべての属性が自動的に除外されます。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. ソースサーバーに存在するレプリケーションアグリーメントに部分レプリケーションを設定します。


    $ 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-att
r+:attribute

レプリケーションの優先順位

レプリケーションの優先順位の指定は必須の作業ではありません。ユーザーパスワードの更新などの特定の変更を高い優先順位でレプリケートするように指定するレプリケーションルールを作成できます。レプリケーションルールに指定されたすべての変更は、高い優先順位でレプリケートされ、ほかのすべての変更は、通常の優先順位でレプリケートされます。

注 –

レプリケーションの優先順位ルールは、マスターサーバーにのみ作成する必要があります。ハブやコンシューマの設定は必要ありません。

Procedureレプリケーションの優先順位を設定する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. マスターに新しいレプリケーションの優先順位ルールを作成するには、次のコマンドを使用します。


    $ dsconf create-repl-priority -h host -p port suffix-DN priority-name property:value

    次のプロパティーを使用して、レプリケーションの優先順位を設定できます。

    • 操作のタイプ、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(1M) のマニュアルページを参照してください。

レプリカの初期化

レプリケーションアグリーメントを作成し、両方のレプリカを設定したら、レプリケーションを開始する前に、コンシューマのレプリカサフィックスを初期化する必要があります。初期化時は、サプライヤのレプリカサフィックスからコンシューマのレプリカサフィックスにデータが物理的にコピーされます。

さらに、特定のエラーが発生した場合、または設定を変更した場合は、レプリカを初期化し直す必要があります。たとえば、何らかの理由で 1 つのマスターのレプリカサフィックスをバックアップから復元した場合、そのレプリカが更新するすべてのレプリカを初期化し直す必要があります。

初期化し直したときは、コンシューマ側のレプリケートされたサフィックスは削除され、マスター側のサフィックスの内容に置き換えられます。これにより、レプリカの同期が確保され、レプリケーションの更新が再開されます。この節で説明するどの方法で初期化を行なっても、コンシューマレプリカのインデックスは自動的にふたたび作成されるため、クライアントからの読み取り要求にもただちに正しく対応できます。

マルチマスターレプリケーションでは、トポロジのほかのマスターによって更新されたコンシューマであれば、初期化し直す必要がない場合もあります。

Procedureレプリケートされたサフィックスをリモート (サプライヤ) サーバーから初期化する

既存のレプリケーションアグリーメントを使用して、リモートサーバーからサフィックスを初期化できます。この初期化方法は、他の方法より簡単なため、可能な限りこの方法を使用します。データが大量でインポートに時間がかかりすぎる場合にのみ他の方法を使用してください。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

DSCC を使用したレプリケートされたサフィックスのオンライン初期化は、コンシューマを初期化または再初期化する簡単な方法です。ただし、大量のエントリを初期化する場合、この処理には時間がかかることがあります。この場合は、コマンド行によるコンシューマのオフライン初期化の方が効率的な場合があります。

  1. レプリカを初期化します。


    $ dsconf init-repl-dest -h host -p port suffix-DN destination-host:destination-port [destination-host:destination-port]

    destination-host:destination-port はホストおよびターゲットサーバーのポートで、リモートサーバーから初期化します。

  2. (省略可能) 各アグリーメントで、サフィックスが初期化済みとなっていることを確認します。


    $ dsconf show-repl-agmt-status -h host -p port suffix-DN destination-host:destination-port

LDIF からのレプリカの初期化

ProcedureLDIF からレプリケートされたサフィックスを初期化する

次の手順では、LDIF ファイルからレプリケートされたサフィックスを初期化するために使用する一般的な手順を説明します。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

DSCC を使用したレプリケートされたサフィックスのオンライン初期化は、コンシューマを初期化または再初期化する簡単な方法です。ただし、大量のエントリを初期化する場合、この処理には時間がかかることがあります。この場合は、コマンド行によるコンシューマのオフライン初期化の方が効率的な場合があります。

  1. レプリケーションアグリーメントを設定していることを確認します。

    この操作は、レプリカを初期化する前に実行する必要があります。

  2. マスターのレプリカサフィックスから、元のサフィックスデータのコピーを LDIF ファイルにエクスポートします。

    「レプリケートされたサフィックスを LDIF にエクスポートする」を参照してください。

    マルチマスターレプリケーション環境では、オリジナルマスターからエクスポートした LDIF ファイルを使用して他のマスターとコンシューマの両方を初期化できます。カスケード型のレプリケーションでは、同じファイルを使用してハブレプリカとそのコンシューマを初期化できます。

    どの場合にも、設定が完了しているマスターレプリカからエクスポートした LDIF ファイルから開始する必要があります。これ以外の任意の LDIF ファイルにはレプリケーションメタデータが含まれないため、これを使用してすべてのレプリカを初期化することはできません。

  3. 部分レプリカを初期化する場合、ファイルをフィルタして、レプリケートされる属性のみを維持し、そのファイルをすべてのコンシューマサーバーに転送します。

    「部分レプリケーションのための LDIF ファイルのフィルタリング」を参照してください。

  4. レプリカを初期化します。

    次のいずれかの操作を行います。

    • オフライン (停止している) サーバーで高速に初期化する場合、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(1M) および dsconf(1M) を参照してください。

  5. (省略可能) 各アグリーメントで、サフィックスが初期化済みとなっていることを確認します。


    $ dsconf show-repl-agmt-status -h host -p port suffix-DN destination-host:destination-port

Procedureレプリケートされたサフィックスを LDIF にエクスポートする

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. 次のいずれかのコマンドを使用して、レプリケートされたサフィックスの内容を LDIF ファイルにエクスポートします。

    • オフラインエクスポートの場合、次のように入力します。


      $ dsadm export instance-path suffix-DN LDIF_file

    • オンラインエクスポートの場合、次のように入力します。


      $ dsconf export -h host -p port suffix-DN LDIF_file

    次の例では、レプリケートされたサフィックス dc=example,dc=com 全体とレプリケーション情報をファイル example_replica_export.ldif にエクスポートします。


    $ dsconf export -h host2 -p 1389 dc=example,dc=com  \
 /local/ds/ldif/example_export_replica.ldif

    詳細については、「LDIF へのバックアップ」 および dsadm(1M) および dsconf(1M) のマニュアルページを参照してください。

部分レプリケーションのための LDIF ファイルのフィルタリング

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(1) のマニュアルページを参照してください。

fildif ツールを使用して作成した filtered.ldif ファイルを使用して、このレプリケーションアグリーメントの対象となるコンシューマを初期化できます。このファイルをコンシューマサーバーに転送し、「LDIF ファイルからのデータのインポート」で説明するとおりにインポートします。

バイナリコピーを使用したレプリケートされたサフィックスの初期化

バイナリコピーにより、サーバーのバイナリバックアップファイルを使用して、別のサーバーに同じディレクトリの内容を復元することで、サーバー全体のクローンを作成できます。バイナリコピーを使用して、マスターまたはハブサーバーのバイナリコピーから任意のサーバーを初期化または再初期化できます。または別のコンシューマサーバーのバイナリコピーからコンシューマを初期化または再初期化できます。

注 –

この高度な手順では、Directory Server 上のデータベースファイルとの間で情報をやり取りします。この機能は、経験が豊富な管理者以外は使用しないでください。

この機能にはある種の制限が適用されるため、処理時間の短縮を見込めるのは、たとえば百万件単位のエントリを含むレプリカなど、大容量のデータベースファイルを持つレプリカだけです。

レプリケーションでのバイナリコピーの使用の制限

バイナリコピーは、あるマシンから別のマシンにデータベースファイルを移動するため、次の制限が厳密に適用されます。

サーバーを初期化するためのバイナリコピーの作成

この節では、サーバーを初期化するためのバイナリコピーの作成方法と、使用ディスク容量が最小になるバイナリコピーの作成方法について説明します。

Procedureサーバーを初期化するためのバイナリコピーを作成する

次の手順を使用して、レプリケートするサーバーを初期化するためのバイナリコピーを実行します。通常のバックアップ機能を使用して、サーバーのデータベースファイルのコピーを作成するためです。通常のバックアップを実行することで、サーバーを停止しなくても、すべてのデータベースファイルを一定の状態に維持できます。

この手順には特定の制限があります。バックアップと復元の処理によって、同じマシンにデータベースファイルのコピーが作成されるため、各マシンでこれらのファイルが占有するディスクスペースの容量が 2 倍になります。また、これらのファイルに対する実際のコピー処理は、ディレクトリに G バイト単位のデータが含まれる場合、時間がかかることがあります。

この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。

  1. 新しくレプリケートされたサフィックスのターゲットマシンに Directory Server をインストールし、必要に応じてサーバーの新しいインスタンスを作成して、「レプリケーションでのバイナリコピーの使用の制限」に従って、サーバーを設定します。

  2. このレプリケートされたサフィックスに関連するレプリケーショントポロジにすべてのレプリケーションアグリーメントを作成します。

    サプライヤからこのレプリカにアグリーメントを含めます。このレプリカが専用コンシューマでない場合は、このレプリカからそのコンシューマにアグリーメントを含めます。「レプリケーションアグリーメントの作成と変更」を参照してください。

  3. 初期化するレプリカと同じ種類 (マスター、ハブ、コンシューマのいずれか) の、完全に設定され、初期化されたレプリカを選択し、「バイナリバックアップ」の手順に従って通常のバックアップ処理を行います。

  4. バックアップディレクトリからターゲットマシンのディレクトリにファイルをコピーまたは転送します。この操作には、ftp コマンドなどを使います。

  5. マルチマスターレプリケーションの状況で新しいマスターを初期化した場合、「マルチマスターモデルでのマスターの復元」の手順に従います。

Procedure最小のディスク容量でサーバーの初期化を行うためにバイナリコピーを使用する

この手順では、データベースファイルのバックアップコピーを作成しないため、ディスクスペースの消費が少なく、処理に要する時間も少なくなります。ただし、データベースファイルを一貫した状態に保つため、クローン作成の対象となるサーバーを停止する必要があります。

注意 – 注意 –

マルチマスターレプリケーションにすでに組み込まれているマスターの再初期化に、この手順を使うことはできません。この手順を利用できるのは、コンシューマサーバーの再初期化、または新しいマスターサーバーの初期化だけです。既存のマスターレプリカを再初期化するには、オンライン初期化を使用して、LDIF ファイルをインポートするか、「サーバーを初期化するためのバイナリコピーの作成」の手順に従います。

この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。

  1. 新しくレプリケートされたサフィックスのターゲットマシンに Directory Server をインストールし、必要に応じてサーバーの新しいインスタンスを作成して、「レプリケーションでのバイナリコピーの使用の制限」に従って、サーバーを設定します。

  2. このレプリカに関連するレプリケーショントポロジにすべてのレプリケーションアグリーメントを作成します。

    サプライヤからこのレプリカにアグリーメントを含めます。このレプリカが専用コンシューマでない場合は、このレプリカからそのコンシューマにアグリーメントを含めます。「レプリケーションアグリーメントの作成と変更」を参照してください。

  3. 「Directory Server インスタンスの起動、停止、および再起動」で説明するように、初期化または再初期化するターゲットサーバーを停止します。

  4. 初期化するレプリカと同じ種類 (マスター、ハブ、コンシューマのいずれか) の、完全に設定され、初期化されたレプリカを選択し、このサーバーも停止します。

    マルチマスター設定に組み込まれているマスターレプリカのクローンを作成するときは、それを停止する前に、その他のマスターから最新のすべての変更が完全に反映されていることを確認する必要があります。

  5. トランザクションログ、更新履歴ログ、地域ファイル (__db.xxx ファイル) など、すべてのデータベースファイルをターゲットサーバーから削除します。

    ファイルの位置を変更していないかぎり、データベースファイルとトランザクションログは instance-path/db ディレクトリに保存されています。

  6. ftp コマンドなどを使用して、トランザクションログや更新履歴ログを含むすべてのデータベースファイルをソースレプリカマシンからターゲットマシンにコピーするか、転送します。

    ファイルの位置を変更していないかぎり、データベースファイルとトランザクションログは instance-path/db ディレクトリに保存されています。

    マスターまたはハブレプリカを初期化する場合は、更新履歴ログにあるすべてのファイルもコピーする必要があります。更新履歴ログはデフォルトで instance-path /changelog にあります。

  7. ソースサーバーとターゲットサーバーの両方を再起動します。

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

カスケード型レプリケーションの場合、常に次の手順に示す順番でレプリカを初期化します。

Procedureカスケード型レプリケーションでレプリカを初期化する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. マルチマスターレプリケーションもある場合、1 つのマスターにレプリケートするすべてのデータセットが存在することを確認し、このマスターを使用して、ほかの各マスターのレプリカを初期化します。

  2. それぞれのマスターレプリカから、最初の階層のハブレプリカに属するレプリカを初期化します。

  3. ハブの構成が複数の階層に分かれている場合、各階層を上から順に初期化していきます。

  4. 最後の階層のハブレプリカから専用コンシューマのレプリカを初期化します。

レプリケートされたサフィックスのインデックス生成

インデックスは、別のサーバーインスタンスに自動的にレプリケートされません。レプリケートされたサフィックスを保持するすべてのサーバーインスタンスの属性のインデックスを生成するには、次のいずれかの操作を実行します。

大量のレプリケートされたサフィックスへの多数のエントリの段階的追加

きわめて大量のエントリを含むディレクトリがあり、大量のエントリを追加する場合、時間がかかりすぎるため、ldapmodify -a を使用しないでください。代わりに、dsconf import コマンドにレプリケートされるトポロジにエントリを追加するオプションを付けて実行し、新しいエントリを段階的に追加します。エントリをインポートすると、レプリケーションメタデータと共に追加エントリを含む LDIF ファイルが生成されます。次にこの生成された LDIF ファイルを他のレプリカにインポートします。生成された LDIF ファイルにより、データを追加するレプリカ全体で、レプリケーションの同期が定期的に行われます。

Procedure大量のレプリケートされたサフィックスに多数のエントリを追加する

始める前に

この手順により、大きな LDIF ファイルが生成されます。最初の dsconf import コマンドを実行する前に、生成される LDIF ファイル用に十分なディスク容量があることを確認します。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

注意 – 注意 –

この手順を使用して、サーバーパスに大量のエントリがあるサーバーを初期化することができます。ただし、いずれかのインポートが失敗すると、データベース全体が失われる可能性があります。各インポートの前にデータをバックアップしてください。

  1. マスターレプリカで、エントリをインポートします。


    $ dsconf import -h host -p port -K generated-LDIF-file suffix-DN

    -K オプションにより、既存のデータが削除されません。さらに、新しいエントリとレプリケーションプロセスに必要な情報を格納するファイル generated-LDIF-file も生成されます。

  2. 他のすべてのレプリカで、前の手順で生成されたファイルをインポートします。


    $ dsconf import -h host -p port \
-K -f incremental-output=no generated-LDIF-file suffix-DN

    オプション -f incremental-output=no は追加の LDIF ファイルを生成しないことを示します。この手順で必要となる生成された LDIF ファイルは 1 つだけです。

レプリケーションと参照の完全性

レプリケーションで参照の完全性プラグインを使用する場合、それをすべてのマスターサーバで有効にする必要があります。ハブサーバーまたはコンシューマサーバー上のプラグインを有効にする必要はありません。

次に、レプリケーション環境における参照の完全性の使用に関する制限を示します。

参照の完全性プラグインの設定の詳細については、「参照の完全性プラグインを設定する」を参照してください。

SSL を経由するレプリケーション

すべてのレプリケーション操作が SSL 接続で行われるように、レプリケーションに関わる Directory Server を構成することができます。

ProcedureSSL 用にレプリケーション操作を設定する

次の手順に、2 つのマスターを持つレプリケーショントポロジでレプリケーションを設定するコマンド例を示します。

注 –

この例では、自己署名証明書を使用した簡単なレプリケーション設定を示しています。本稼働環境に SSL によるレプリケーションを設定する場合、証明機関によって信頼された証明書を使用する方がセキュリティーが向上します。

サプライヤサーバー証明書が、SSL ハンドシェイク時にクライアントとして機能できない SSL サーバー専用証明書である場合、SSL を経由するレプリケーションは失敗します。

レプリケーションが SSL によってセキュリティー保護されていても、レプリケーションマネージャーの認証はまだ簡単なバインドとパスワードを使用して行われます。クライアントベースの認証を使用して、レプリケーションのセキュリティーを完全に保護することができますが、これには、複雑な設定が必要です。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. 新しいサーバーを作成し、それらを起動します。


    $ dsadm create -p 1389 -P 1636 /local/ds1
$ dsadm create -p 2389 -P 2636 /local/ds2

$ dsadm start /local/ds1
$ dsadm start /local/ds2

  2. すべてのサーバーで、空のサフィックスを作成します。


    $ dsconf create-suffix -e -i -w password-file -p 1389 dc=example,dc=com
$ dsconf create-suffix -e -i -w password-file -p 2389 dc=example,dc=com

  3. すべてのサーバーで、マルチマスターパスワードファイルを設定します。


    $ 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

  4. すべてのサーバーで、レプリケーションを有効にします。


    $ 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

  5. すべてのサーバーで、既存のデフォルトの証明書を表示します。


    $ dsadm show-cert -F der -o certfile1 /local/ds1 defaultCert
$ dsadm show-cert -F der -o certfile2 /local/ds2 defaultCert

  6. すべてのサーバーに、ほかのすべてのサーバーからの CA によって信頼された証明書を追加します。


    $ dsadm add-cert --ca /local/ds1 "ds2 Repl Manager Cert" certfile2
$ dsadm add-cert --ca /local/ds2 "ds1 Repl Manager Cert" certfile1

  7. すべてのマスターサーバーとハブ (ソース) サーバーで、すべてのコンシューマ (ターゲット) サーバーとのレプリケーションアグリーメントを作成します。

    レプリケーションアグリーメントにはセキュリティー保護された 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

  8. すべてのレプリケーションアグリーメントで、認証パスワードファイルを、レプリケーションアグリーメント内のコンシューマ (ターゲット) サーバーのレプリケーションマネージャーパスワードファイルとして設定します。


    $ 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 からカスタマーの初期化を行う場合も、セキュリティー保護された接続が使われます。

  9. すべてのサーバーで、設定の変更を反映するため、サーバーを再起動します。


    $ dsadm restart /local/ds1
$ dsadm restart /local/ds2

  10. いずれかのマスターサーバーで、サフィックスを初期化します。


    $ dsconf import -h example1.server -p 1389 -e -i \
-w password-file /tmp/Example.ldif dc=example,dc=com

  11. まだ初期化されていないすべてのサーバーで、レプリケーションアグリーメントを使用して、サーバーを初期化します。


    $ dsconf init-repl-dest -e -i -w password-file \
-h example1.server -p 1389 dc=example,dc=com example1.server:2636

WAN を経由するレプリケーション

Directory Server では、広域ネットワーク (WAN) によって接続されたマシン間のマルチマスターレプリケーションを含むあらゆる形式のレプリケーションを実行できます。このレプリケーションにより、サプライヤサーバーは、待ち時間が大きく、帯域幅が小さいネットワーク経由で、最適な帯域幅を使用することによりコンシューマを初期化し、更新することができます。

注 –

WAN 経由でレプリケートするレプリケーショントポロジの配備またはトラブルシューティングを行う場合、ネットワークの速度、待ち時間、およびパケットロスを調べる必要があります。これらのいずれかの点で、ネットワークの問題があると、レプリケーションの遅延が発生する可能性があります。

さらに、レプリケーションデータの転送率は、使用可能な物理媒体が帯域幅に関して許可している転送率を常に下回ります。レプリカ間の更新量を使用可能な帯域幅と物理的に適合させることができない場合、更新負荷が大きくなったときにレプリカ間に差異が生じることを、チューニングによって回避できなくなります。レプリケーションの遅延と更新のパフォーマンスは、さまざまな要因によります。次のような要因がありますが、これだけに限定されません。変更の頻度、エントリサイズ、サーバーハードウェア、エラー率、平均待ち時間、平均帯域幅。

環境でのレプリケーションに関する疑問がある場合は、Sun サービスプロバイダに問い合わせてください。

デフォルトでは、レプリケーションメカニズムの内部パラメータは WAN に合わせて最適化されています。ただし、前述の要因などが原因でレプリケーションが遅くなるときは、ウィンドウサイズとグループサイズのパラメータを調節してみてください。また、ネットワークのピーク時を避けてレプリケーションをスケジュールすることで、ネットワークの全体的な利用率を高めることができます。最後に、Directory Server は、帯域幅の使用を最適化するためにレプリケーションデータの圧縮に対応しています。

ネットワークパラメータの設定

ネットワーク経由でエントリをより効率的に送信するために、レプリケーションメカニズムがエントリをグループ化する方法は、ウィンドウとグループネットワークパラメータによって決定されます。これらのパラメータは、サプライヤとコンシューマがレプリケーション更新メッセージと、その確認応答を交換する方法に影響します。すべてのレプリケーションアグリーメントのパラメータは設定可能であるため、各コンシューマの特定のネットワーク状況に従ってレプリケーションパフォーマンスを調整することができます。

変更の効果を監視して、必要に応じてパラメータを調整します。手順については、「レプリケーションの状態の取得」を参照してください。ウィンドウとグループのサイズパラメータを変更するときに、レプリケーションを中断する必要はありません。

ウィンドウサイズの設定

ウィンドウサイズ (デフォルト値は 10) は、コンシューマからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。

各コンシューマからの確認応答を待機するよりも、短時間に連続して多数のメッセージを送信する方が効果的です。適切なウィンドウサイズを使用することで、レプリケーション更新や確認応答の到着を待機するためにレプリカが費やす時間を排除できます。

コンシューマレプリカがサプライヤよりも遅れている場合、詳細な調整を行う前に、ウィンドウサイズをデフォルトよりも大きい数字 (100 など) に設定して、レプリケーションのパフォーマンスをもう一度確認してみます。レプリケーションの更新頻度が高く、更新間隔が短い場合、ローカルエリアネットワーク (LAN) 接続されたレプリカでもウィンドウサイズを大きくすることでパフォーマンスが向上する可能性があります。

Procedureウィンドウサイズを設定する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. ウィンドウサイズを変更します。


    $ 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 など) に設定して、レプリケーションのパフォーマンスを再確認してみます。

グループサイズを大きくする場合、次のことがあてはまることを確認します。

Procedureグループサイズを設定する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. グループサイズを変更します。


    $ 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 日の特定の時間にレプリケーションを開始および終了するようにスケジュールできます。これは、レプリケーションアグリーメントによって、コンシューマごとに個別に実行できます。新しいスケジュールはただちに有効になり、対応するコンシューマに対する次回のデータのレプリケーションは、スケジュールと合致する日時になった時点で行われます。

Procedureレプリケーションアクティビティーをスケジュールする

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. レプリケーションスケジュールを変更します。


    $ 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 ではこのパラメータを設定しないでください。圧縮と圧縮解除の計算により、レプリケーションが遅くなります。

Procedureレプリケーションの圧縮を設定する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. マスターサーバーのレプリケーションアグリーメントエントリにレプリケーションの圧縮を設定します。


    $ 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

    圧縮レベルの設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference 』を参照してください。

レプリケーショントポロジの変更

ここでは、既存のレプリケーショントポロジの管理の以下の側面について説明します。

レプリケーションマネージャーの変更

レプリケーションアグリーメントを編集して、コンシューマサーバーへのバインドに使われるレプリケーションマネージャーの識別情報を変更できます。レプリケーションが中断されないように、レプリケーションアグリーメントを変更する前に、新しいレプリケーションマネージャーエントリまたはコンシューマの証明書エントリを定義する必要があります。ただし、バインドの失敗によってレプリケーションが中断された場合、レプリケーション回復設定の制限内でエラーを修正したときは、レプリケーションメカニズムによって必要なすべての更新が自動的に送信されます。手順については、「デフォルト以外のレプリケーションマネージャーの使用」を参照してください。

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

レプリケーションアグリーメントを無効化、有効化、または削除できます。

レプリケーションアグリーメントの無効化

レプリケーションアグリーメントを無効にすると、そのアグリーメントに指定されているコンシューマに対してマスターが更新を送信しなくなります。そのサーバーのレプリケーションは停止されますが、アグリーメントに記録されているすべての設定は残されます。あとからまたアグリーメントを有効にすることで、レプリケーションを再開できます。中断後にレプリケーションメカニズムを再開することについては、「レプリケーションアグリーメントの有効化」を参照してください。

Procedureレプリケーションアグリーメントを無効にする

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. レプリケーションアグリーメントを無効にします。


    $ 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

レプリケーションアグリーメントの有効化

レプリケーションアグリーメントを有効にすると、指定のコンシューマのレプリケーションが再開されます。ただし、レプリケーションの回復設定で許容される時間より長くレプリケーションを中断していた場合は、別のサプライヤによるコンシューマの更新が行われないため、コンシューマを初期化し直す必要があります。レプリケーションの回復設定は、最大サイズとこのサプライヤの更新履歴ログの経過時間とコンシューマの削除の遅延です (「コンシューマの詳細設定を行う」を参照)。

中断時間が短く、レプリケーションが回復された場合は、アグリーメントがふたたび有効になったときに、マスターが自動的にそのコンシューマを更新します。

Procedureレプリケーションアグリーメントを有効にする

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. レプリケーションアグリーメントを有効にします。


    $ 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

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

レプリケーションアグリーメントを削除すると、対応するコンシューマのレプリケーションは停止され、アグリーメントに関するすべての設定情報が失われます。後日レプリケーションを再開する場合は、「レプリケーションアグリーメントの無効化」で説明するように、アグリーメントを無効にします。

Procedureレプリケーションアグリーメントを削除する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. レプリケーションアグリーメントを削除します。


    $ 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

レプリカの昇格と降格

レプリカの昇格と降格は、レプリケーショントポロジで、レプリカの役割を変更することを意味します。専用コンシューマをハブに変更したり、ハブをマスターに変更したりできます。また、マスターをハブに変更したり、ハブを専用コンシューマに変更したりすることもできます。ただし、マスターを直接コンシューマに格下げしたり、コンシューマを直接マスターに格上げすることはできません。

マルチマスターレプリケーションのメカニズムでレプリカの役割を変更できることで、トポロジがとても柔軟になります。コンシューマレプリカが処理を担当していたサイトの負荷が増え、複数のレプリカを持つハブによる処理が必要になることもあります。レプリカの内容に対して多数の変更が含まれるときは、ハブをマスターに昇格させることで、ローカルな変更に迅速に対応し、その変更を他のサイトの他のマスターにレプリケートできます。

レプリカを昇格または降格させる場合は、次のことに注意します。

Procedureレプリカの役割を変更する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. レプリカの役割を変更するには、次のいずれかのコマンドを使用します。


    $ dsconf promote-repl -h host -p port role suffix-DN


    $ dsconf demote-repl -h host -p port role suffix-DN

    role は master、 hub、または consumer です。

レプリケートされたサフィックスの無効化

レプリケートされたサフィックスを無効にすると、それはレプリケーショントポロジから除外されます。設定されている役割 (マスター、ハブ、またはコンシューマ) に応じて、そのレプリケートされたサフィックスは更新されなくなり、更新を送信しなくなります。サプライヤサーバーのサフィックスを無効にすると、すべてのレプリケーションアグリーメントが削除されます。そのレプリカをふたたび有効にするときは、これらのアグリーメントを作成し直す必要があります。

Procedureレプリケートされたサフィックスを無効にする

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. レプリケートされたサフィックスを無効にします。


    $ dsconf disable-repl -h host -p port suffix-DN

    次に例を示します。


    $ dsconf disable-repl -h host2 -p 1389 dc=example,dc=com

レプリケートされたサフィックスの同期の維持

定期的に行う保守のために、レプリケーションに関わる Directory Server を停止したあと、オンラインに戻す場合、レプリケーションによってただちに更新されるようにする必要があります。特に、マルチマスター環境のマスターサーバーでは、マルチマスターセットのもう一つのサーバーからディレクトリ情報を更新する必要があります。マルチマスター以外の環境でも、ハブサーバーや専用コンシューマサーバーが保守のためにオフラインになった場合、オンラインに復帰したときは、マスターサーバー側から更新を行う必要があります。

ここでは、レプリケーションの再試行アルゴリズムおよび次の実行まで待たずに、強制的にレプリケーション更新を行う方法について説明します。

注 –

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

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

ソースレプリカのターゲットへのレプリケーションが失敗すると、増分的間隔で、定期的に再試行されます。再試行の間隔はエラーの種類によって異なります。

ソースレプリカとターゲットレプリカの間で、常に同期をとるレプリケーションアグリーメントを設定していても、オフライン状態の時間が 5 分を超えたレプリカをただちに更新するには、この方法では不十分です。

Procedureレプリケーションの更新を強制的に実行する

レプリケーションを停止した場合、ターゲットのサフィックスに対して、レプリケーションの更新を強制的に実行することができます。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. ソースサーバーで、ターゲットサーバーへのレプリケーションの更新を再起動します。


    $ 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 を使用するには、次のようにコマンド行を使用してこの作業を実行する必要があります。

Procedure既存のレプリケーショントポロジからマスターを削除する

始める前に

マスターからのすべての変更がすでにレプリケートされていることを確認します。

  1. 可能であれば、バイナリコピーを使用してマスターをバックアップして、変更が失われないようにします。

  2. マスターレプリカをハブレプリカに降格させます。

    「レプリカの昇格と降格」を参照してください。

  3. ハブがほかのサーバーにレプリケートを開始するのを待ちます。

    ハブでトポロジのほかのサーバーに対するレプリケーションセッションが開かれると、ハブは RUV にとどまりますが、リフェラルでは使用されなくなります。

  4. ハブを停止します。

    「Directory Server インスタンスの起動、停止、および再起動」を参照してください。

  5. トポロジからハブを削除します。

    「レプリケートされたサフィックスの無効化」を参照してください。

Procedureマスターを既存のレプリケーショントポロジに追加する

  1. 同じレプリカ ID を使用して、マスターレプリカを追加します。

    「マスターレプリカ上でのレプリケーションの有効化」を参照してください。

  2. そのマスターからトポロジのほかのマスターにレプリケーションアグリーメントを再作成します。

  3. 新しいマスターを初期化します。

    1. マスターをバックアップできていた場合は、そのバックアップからマスターを初期化します。

    2. マシン障害が起きてマスターをバックアップできなかった場合は、トポロジの別のマスターからマスターを初期化します。

Directory Server 6.x 以前のリリースでのレプリケーション

ここでは、6.x 以前の Directory Server のリリースでのレプリケーションの設定方法について説明します。

Directory Server 6.3 と Directory Server 5.1 または 5.2 間のレプリケート

Directory Server 5.1、5.2、および 6.x は、レプリケーション設定に関して互換性がありますが、次の例外があります。

旧バージョン形式の更新履歴ログの使用

旧バージョン形式の更新履歴ログは LDAP クライアントが Directory Server データに対して行われた変更履歴を確認するために使用します。旧バージョン形式の更新履歴ログは、cn=changelog というサフィックスの下で、Directory Server の更新履歴ログに対する独立したデータベースに格納されます。

旧バージョン形式の更新履歴ログは、スタンドアロンサーバーまたはレプリケーショントポロジ内の各サーバー上で有効にできます。サーバー上で旧バージョン形式の更新履歴ログが有効になっている場合、デフォルトでは、そのサーバー上のすべてのサフィックスに対する更新がログファイルに記録されます。旧バージョン形式の更新履歴ログは、指定したサフィックスに対する更新のみをログファイルに記録するように設定できます。

レプリケーショントポロジで、旧バージョン形式の更新履歴ログを使用する方法および旧バージョン形式の更新履歴ログの使用の制限については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Replication and the Retro Change Log Plug-In」を参照してください。

旧バージョン形式の更新履歴ログのエントリの属性については、changeLogEntry(5dsoc) のマニュアルページを参照してください。

旧バージョン形式の更新履歴ログの変更の詳細については、dsconf(1M) のマニュアルページを参照してください。

この節では、旧バージョン形式の更新履歴ログを使用するさまざまな方法について説明します。

Procedure旧バージョン形式の更新履歴ログを有効にする

旧バージョン形式の更新履歴ログを使用するには、ログを有効にする必要があります。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 旧バージョン形式の更新履歴ログ設定エントリを変更します。


    $ dsconf set-server-prop -h host -p port retro-cl-enabled:on

  2. サーバーを再起動します。

    詳細については、「Directory Server インスタンスの起動、停止、および再起動」を参照してください。

Procedure指定したサフィックスに対する更新を記録するための旧バージョン形式の更新履歴ログを設定する

サーバー上で旧バージョン形式の更新履歴ログが有効になっている場合、デフォルトでは、そのサーバー上のすべてのサフィックスに対する更新がログファイルに記録されます。この手順では、指定したサフィックスに対する更新のみを記録するように、旧バージョン形式の更新履歴ログを設定する方法について説明します。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 旧バージョン形式の更新履歴ログ設定エントリを変更します。


    $ 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

  2. サーバーを再起動します。

    詳細については、「Directory Server インスタンスの起動、停止、および再起動」を参照してください。

Procedure削除したエントリの属性を記録するための旧バージョン形式の更新履歴ログを設定する

この手順では、エントリが削除されたときにそのエントリの指定された属性を記録するように旧バージョン形式の更新履歴ログを設定する方法について説明します。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 記録する属性を指定します。


    $ 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

  2. サーバーを再起動します。

    詳細については、「Directory Server インスタンスの起動、停止、および再起動」を参照してください。

Procedure旧バージョン形式の更新履歴ログを削除する

旧バージョン形式の更新履歴ログのエントリは、指定した期間の経過後に自動的に削除することができます。エントリを自動的に削除する期間を設定するには、cn=Retro Changelog Plugin, cn=plugins, cn=config エントリに nsslapd-changelogmaxage 設定属性を設定します。

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 旧バージョン形式の更新履歴ログが有効にされていることを確認します。


    $ dsconf get-server-prop -h host -p port retro-cl-enabled

  2. 旧バージョン形式の更新履歴ログが有効にされていなければ、有効にします。


    $ dsconf set-server-prop -h host -p port retro-cl-enabled:on

  3. 更新履歴ログの最大経過時間を設定します。


    $ 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 属性を変更する必要があります。第 7 章「Directory Server のアクセス制御」を参照してください。

レプリケーションの状態の取得

DSCC またはコマンド行ツールを使用して、レプリケーションの状態を取得できます。

DSCC でのレプリケーションの状態の取得

「サフィックス」タブを使用して、レプリケーションアグリーメントやレプリケーションの遅延など、レプリケーションをグラフィカルに表示できます。詳細については、DSCC オンラインヘルプを参照してください。

さらに、DSCC を使用して、次の図に示すように、レプリケーショントポロジを表示することができます。

図 11–1 レプリケーショントポロジの例

DSCC でのレプリケーショントポロジの例。

コマンド行を使用する場合レプリケーション状態の取得

DSCC を使用できない場合は、コマンド行ツールを使用して、レプリケーション配備に関する情報を取得します。

これらのツールの完全なコマンド行構文と使用例については、マニュアルページを参照してください。

これらのコマンドの配置されているディレクトリを見つけるには、「コマンドの場所」を参照してください。

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

マルチマスターレプリケーションでは、疎整合型レプリケーションモデル (Loose Consistency Replication Model) を使用します。つまり、同一のエントリを別々のサーバーから同時に変更できます。2 つのサーバー間で更新が送信された場合、更新の競合を解決する必要があります。たいていは自動的に解決されます。たとえば、各サーバーの変更に関するタイムスタンプは、優先される最近の変更によって解決されます。しかし、一部の更新の競合では、解決に至るまでに、手動の調整が必要になることもあります。

この節の内容は、次のとおりです。

DSCC によるレプリケーションの競合の解決

レプリケーションの競合を解決するもっとも簡単な方法は、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 内に含めることで名前を変更します。

たとえば、2 つのマスターで uid=bjensen,ou=People,dc=example,dc=com というエントリが同時に作成されると、レプリケーション後の 2 つのエントリは、次のようになります。

2 つ目のエントリには、有効な DN を指定する必要があります。競合しているエントリを削除し、競合しない名前で追加し直すことができます。ただし、エントリの名前を変更しても、その内容は変更されていません。名前変更の手順は、ネーミング属性が 1 つの値を持つか複数の値を持つかによって異なります。そのための手順は次のとおりです。

Procedure複数の値からなるネーミング属性を持つ競合エントリの名前を変更する

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. 古い 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 も含まれているからです。

  2. ネーミング属性の古い 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

Procedure1 つの値からなるネーミング属性を持つ競合エントリの名前を変更する

dc (ドメインコンポーネント) など、重複したエントリのネーミング属性が 1 つの値の場合は、エントリの名前を単に同じ属性の別の値に変更することはできません。代わりに一時的な名前を付ける必要があります。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. 別のネーミング属性を使用してエントリの名前を変更し、古い 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 も含まれているからです。

  2. 必要なネーミング属性を一意の値に変更し、競合マーカー属性を削除します。たとえば、次のように入力します。


    $ 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

  3. エントリの名前を変更し、指定したネーミング属性に戻します。たとえば、次のように入力します。


    $ 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 エントリは、次のさまざまな方法で作成されます。

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

メールサーバーのように属性の一意性に依存するアプリケーションとの相互運用性のため、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 属性を持つエントリが保持されます。