| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
レプリケーションにより、同一データのコピーを複数のサーバーで使用できるようになります。Oracle Unified Directoryでは、マルチマスター・レプリケーション・モデルを採用しており、レプリケーション・トポロジ内の全サーバーがreadおよびwrite操作を受け入れることができます。この章では、ディレクトリ・サーバーにレプリケーションを構成する手順について説明します。
レプリケーション・プロセスのメカニズムの詳細は、第7章「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。
この章では、次のトピックを取り扱います:
レプリケーションを構成する前に、次の問題を解決しておく必要があります。
使用しているデプロイメントでデフォルトのマルチマスター・レプリケーション・モデルが適切かどうか判別します。
マルチマスター・レプリケーション・モデルは、デフォルトではゆるやかな一貫性を持つモデルです。つまり、1つのサーバー上で加えられた変更がトポロジ内の他のサーバーに非同期的にレプリケートされます。このため、同一エントリが別々のサーバーで同時に変更される可能性があります。2つのサーバー間で更新が送信された場合、変更の競合を解決する必要があります。WANの各種属性(待機時間など)によってレプリケーションの競合が発生する可能性が高くなる場合があります。競合の解決は一般に自動的に行われます。一連の競合ルールによって、どの変更が優先されるかが決まります。場合によっては、手動で競合を解決する必要があります。
|
注意: 一部のデプロイメント・シナリオでは、デフォルトのゆるやかな一貫性モデルが不適なことがあります。このような場合は、レプリケーションを保証モードで動作するように構成できます。詳細は、第29.5.9項「保証レプリケーションの構成」を参照してください。 |
SSLを有効にする必要があります。レプリケーションは必ず、保護された接続を介して行われます。レプリケーション・セッションの双方のサーバーは、SSL証明書を使用して相手側サーバーに対して認証される必要があります。アクセス制御や権限は強制されません。
すべてのディレクトリ・サーバーを同じように構成する場合にのみ、Oracle Unified Directoryの初回インストール時にグラフィカルな設定ユーティリティを使用してレプリケーションを設定できます。
setupコマンドを使用してコマンド行モードでレプリケーションを構成することはできません。setupコマンドでディレクトリ・サーバーを設定する場合は、dsreplicationコマンドを使用してサーバー間のレプリケーションを構成する必要があります。
どのトポロジでも、レプリケーション・サーバーに障害が発生した場合の可用性を確保するために、2つのレプリケーション・サーバーが必要とされます。レプリケーション・サーバーは、環境内で発生したあらゆる変更を追跡する役割を担います。各レプリケーション・サーバーには、トポロジ内の他のレプリケーション・サーバーをすべて列挙したリストが格納されます。
この項の各例では、すでに2つのディレクトリ・サーバーがインストールされており、その一方にデータが移入されていることを前提としています。2つのディレクトリ・サーバーは同じホスト・マシン上にインストールできますが、その場合は別々のポート番号を割り当てる必要があります。
dsreplicationによるデータ・レプリケーションの構成dsreplicationコマンドは、管理コネクタを介してSSL上でサーバー構成にアクセスします。詳細は、第17.3項「サーバーへの管理トラフィックの管理」を参照してください。
dsreplication enableコマンドのインスタンスを複数実行して、複数のサーバー間のレプリケーションを並列に設定することはできません。かわりに、トポロジ内のレプリケート対象サーバーの組ごとに逐次にdsreplication enableコマンドを実行してください。
レプリケーションを有効にするには、dsreplication enableコマンドを使用します。
次のコマンドは、host1とhost2という2つのディレクトリ・サーバー間で、"dc=example,dc=com"にあるデータのレプリケーションを有効にします。どちらのサーバーもデフォルトの管理ポート(4444)を使用します。このコマンドは、host1のポート8989にレプリケーション・サーバー・インスタンスを1つ作成し、host2のポート8989にもう1つレプリケーション・サーバー・インスタンスを作成します。
$ dsreplication enable --host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \ --bindPasswordFile1 pwd.txt --replicationPort1 8989 \ --host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \ --bindPasswordFile2 pwd.txt --replicationPort2 8989 \ --adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" -X -n
--adminUIDオプションと--adminPasswordFileオプションは、 レプリケーション・ドメインのグローバル管理者を指します。詳細は、第26.6項「グローバル管理者の管理」を参照してください。-Xオプションは、すべてのサーバー証明書を信頼する必要があることを指定します。-n (--no-prompt)オプションは、このコマンドを非対話型モードで実行するように指定します。dsreplicationコマンドの全グローバル・オプションの詳細は、コマンド行でdsreplication -helpと入力してください。
dsreplication enableを2つのサーバー間で使用すると、それぞれのホスト上でレプリケーション・サーバーが自動的に構成されます。レプリケーション・サーバーを各ホストに作成することなく、2つのディレクトリ・サーバー間のレプリケーションを構成する必要がある場合があります。--noReplicationServer1オプションまたは--noReplicationServer2オプションを使用すれば、追加のレプリケーション・サーバーを作成せずに、ディレクトリ・サーバーをトポロジに追加できます。シングル・ポイント障害を回避するために、レプリケートするトポロジ内にはレプリケーション・サーバーが少なくとも2つ必要であることに注意してください。
また、2つのサーバー間のレプリケーションを有効にし、一方のサーバーにのみレプリケーション・サーバー(ディレクトリ・サーバーではありません)を作成するようにも指定できます。これを実現するには、--onlyReplicationServer1オプションまたは--onlyReplicationServer2オプションを使用します。このオプションを指定すると、そのサーバーで変更ログとレプリケーション・ポートが構成されます。そのサーバーには、レプリケートされたデータは格納されません。
レプリケート対象サーバーを別のレプリケート対象サーバーのデータで初期化するには、dsreplication initializeコマンドを使用します。
次のコマンドは、host2のベースDN "dc=example,dc=com"を、host1に格納されているデータによって初期化します:
$ dsreplication initialize --baseDN "dc=example,dc=com" \ --adminUID admin --adminPasswordFile pwd.txt \ --hostSource host1 --portSource 4444 \ --hostDestination host2 --portDestination 4444 -X -n
トポロジに3つ以上のディレクトリ・サーバーがある場合は、dsreplication intialize-allコマンドを使用すると、すべてのレプリカを同時に初期化できます。
このコマンドはソース・ホストの詳細を引数としてとり、レプリケーションが有効になっている他のすべてのサーバーを初期化します。
次のコマンドは、レプリケーションが有効になっているすべてのサーバーを、host1のベースDN "dc=example,dc=com"のコンテンツで初期化します:
$ dsreplication initialize-all --hostname host1 --port 4444 \ --baseDN "dc=example,dc=com" --adminUID admin --adminPasswordFile pwd.txt
レプリケーションの動作をテストする最も簡単な方法は、1つのディレクトリ・サーバー上で変更を適用し、その変更が別のディレクトリ・サーバーにレプリケートされたことを確認するという方法です。前述の手順で設定したレプリケーション・トポロジをテストする手順は、次のとおりです:
ldapmodifyを使用して、host1上のエントリを変更します。
ldapsearchを使用して、その変更がhost2に伝播されていることを確認します。
トポロジ内の任意のディレクトリ・サーバーの接続詳細を使用して、トポロジ全体のステータスを取得できます。
dsreplication statusコマンドを使用すると、トポロジ内のディレクトリ・サーバーのリストが表示され、サーバー間で未伝播の変更があれば一緒に表示されます。
次のコマンドは、前述の手順で設定したトポロジのステータスを表示します:
$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \ --hostname host1 --port 4444
2つのレプリケート対象トポロジをマージするには、各トポロジの1つのサーバー同士のレプリケーションを有効にします。
次の制限に注意してください:
このマージの実行時には、両方のトポロジ内のサーバーがすべて起動され実行されている必要があります。
いずれかのサーバーがオフラインである場合、dsreplicationではその構成を更新できません。マージの実行時にオフラインであったサーバーが再びオンラインになっても、このサーバーにもう一方のトポロジ内のレプリケーション・サーバーへの参照が追加されることはありません。
ドメインIDまたはレプリケーション・サーバーIDが2つのトポロジ間で競合している場合は、マージを実行できません。
つまり、トポロジAのサーバーがトポロジBのサーバーと同じレプリケーション・サーバーIDやドメインIDを持つことはできません。
IDが競合している場合は、最初のサーバー(--host1)のIDを使用して競合が解消されます。その後、--host1と同じトポロジに属すサーバーをソースとして使用して、最新の状態でないサーバーをすべて再初期化する必要があります。
両方のレプリケーション・トポロジで同一のグローバル管理者が定義されている必要があります。
2つのレプリケート対象トポロジをマージするには、dsreplication enableコマンドを使用します。
たとえば、レプリケート対象トポロジ(トポロジA)にはhost1、host2およびhost3が属しており、レプリケート対象トポロジ(トポロジB)にはhost4、host5およびhost6が属している場合、次のコマンドはこの2つのトポロジを効果的にマージします:
$ dsreplication enable \ --host1host1--port1 4444 --bindDN1 "cn=Directory Manager" \ --bindPasswordFile1 pwd.txt --replicationPort1 8989 \ --host2host4--port2 4444 --bindDN2 "cn=Directory Manager" \ --bindPasswordFile2 pwd.txt --replicationPort2 8989 \ --adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" \ -X -n
この例では、host1とhost4の両ホストにディレクトリ・サーバーとレプリケーション・サーバーが1つずつ含まれていると仮定しています。含まれていない場合は、ディレクトリ・サーバーまたはレプリケーション・サーバーが自動的に構成されます。
高可用性を確保するには、マージ時にオフラインまたは使用不可であったすべてのサーバーに対して、次の手順を実行する必要があります:
dsreplication enableを使用して、接尾辞cn=admin dataのコンテンツを初期化します。
マージ時に使用可能であったサーバーの1つを使用して個別にサーバーを初期化することも、dsreplication initialize-allを使用することもできます。
dsconfigコマンドを使用してレプリケーション・サーバーのリストを更新します。
特定のドメインでのレプリケーションを無効にするには、dsreplication disableコマンドを使用します。
次のコマンドは、"dc=example,dc=com"にあるデータのレプリケーションを無効にします。
$ dsreplication disable --hostname host1 --port 4444 --adminUID admin \ --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" -X -n
このコマンドは、そのドメインのディレクトリ・サーバーからレプリケーション構成を削除します。無効にするドメインがこのディレクトリ・サーバー・インスタンス上でレプリケートされている唯一のドメインである場合は、このインスタンス上のレプリケーション・サーバーも無効になります。レプリケーション・サーバーが無効になると、そのレプリケーション・サーバーに接続していた他のディレクトリ・サーバーは切断され、トポロジ内の別のレプリケーション・サーバーに自動的に再接続します。
レプリケーション・サーバー自体を(変更ログとレプリケーション・ポートを含めて)無効にするには、次のコマンドを使用します:
$ dsreplication disable --hostname host1 --port 4444 -X -n \ --adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" \ --disableReplicationServer
レプリケーション・サーバーが無効になると、そのレプリケーション・サーバーに接続していた他のディレクトリ・サーバーは切断され、トポロジ内の別のレプリケーション・サーバーに自動的に再接続します。
レプリケーション・サーバーを無効にすると、レプリケーション構成が削除されますが、レプリケーション・サーバーのデータベースは削除されません。したがって、レプリケーション・サーバーを誤って無効にしてしまった場合には、レプリケーションの変更記録を取得できます。この接尾辞でのレプリケーションを再度有効にする必要がなければ、レプリケーション・サーバーのデータベースを手動で削除してください(例: $rm changelogDB/*)。
レプリケーションを無効にして再度有効にした場合、その間にそのサーバーで行われた変更はレプリケートされません。このため、レプリケーションを無効にした期間中はそのサーバーでの変更を禁止するか、変更が発生した場合には、そのサーバーからトポロジ内の残りの各サーバーを再同期する必要があります。
ODSMを使用したサーバー構成の多くは、「Directory Manager」タブにアクセスして実行します。レプリケーション構成を管理するには、「Directory Manager」タブまたは「トポロジ・マネージャ」タブのいずれかにアクセスできます。
個別のサーバーやレプリケートされた接尾辞に固有のレプリケーション構成プロパティを表示または構成するには、「Directory Manager」タブをクリックします。既存のトポロジを管理したり、新しいトポロジを作成するためにレプリケーション構成ウィザードを起動するには、「トポロジ・マネージャ」タブをクリックします。
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「Directory Manager」タブをクリックします。
構成するサーバーのタブをクリックします。
「構成」サブタブをクリックします。
「一般構成」の下の「ネーミング・コンテキスト」セクションで、「レプリケーション・サーバー」をクリックします。
「レプリケーション・サーバー」ページが表示されます。
「レプリケーション・サーバー」プロパティを表示または変更します。
使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのレプリケーション・サーバーに関する項を参照してください。
変更を保存する場合は「適用」をクリックします。
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「Directory Manager」タブをクリックします。
構成するサーバーのタブをクリックします。
「一般構成」の下の「ネーミング・コンテキスト」セクションで、「レプリケートされたサフィックス」ノードを開いてから表示または変更する接尾辞を選択します。
「メイン」サブタブをクリックします。
「メイン」サブタブのプロパティを表示または変更して、変更を保存する場合は「適用」をクリックします。
使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのレプリケーション・ドメインに関する項を参照してください。
「保証レプリケーション」サブタブをクリックします。
「保証レプリケーション」サブタブのプロパティを表示または変更して、変更を保存する場合は「適用」をクリックします。
使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのレプリケーション・ドメインに関する項を参照してください。
「部分レプリケーション」サブタブをクリックします。
「部分レプリケーション」サブタブのプロパティを表示または変更して、変更を保存する場合は「適用」をクリックします。
使用可能なすべてのプロパティとその値の詳細は、Oracle Unified Directory構成リファレンスのレプリケーション・ドメインに関する項を参照してください。
新しいトポロジを作成したり、既存のトポロジにサーバーを追加するには、レプリケーション構成ウィザードを起動します。次の条件のいずれかが真の場合、「Directory Manager」タブからレプリケーション構成ウィザードを起動できます。
レプリケーション・トポロジが存在しない。第29.3.3.1項「新しいトポロジを最初から作成するには」を参照してください。
レプリケーション・トポロジは存在するが、現在のサーバーが追加されていないか、現在のサーバーが部分的にレプリケーション用に構成されているのみである。第29.3.3.2項「既存のトポロジにサーバーを追加するには」を参照してください。
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「Directory Manager」タブをクリックします。
構成するサーバーのタブをクリックします。
「一般構成」の下の「ネーミング・コンテキスト」ペインで、「レプリケーション構成」を選択します。
「レプリケーション構成」ページが表示されます。
レプリケーション構成ウィザードを起動するには、「構成」をクリックします。
「レプリケーション・オプション」ページで、「新規トポロジを最初から作成しますか。」を選択します。
「次へ」をクリックします。
「サーバーの識別」ページで、構成対象である2つ以上のソース・サーバーについて、次の情報を入力します。
ホスト: 完全修飾ドメイン名を使用してサーバー名を入力します。
管理ポート: 管理ポート番号を入力します。デフォルトは4444です。
管理ユーザー名: サーバーの管理者のDNを入力します。
管理者パスワード: 指定した管理者のパスワードを入力します。
(オプション)このページでは、次のことも行えます。
サーバーに対して構成されている接尾辞をプレビューするには、最後の列の「サフィックスのプレビュー」リンクをクリックします。
構成対象の別のサーバーを追加するには、「追加」をクリックして、前述の手順6を繰り返します。
トポロジからサーバーを削除するには、サーバー名を選択して、「削除」をクリックします。
「次へ」をクリックします。
「グローバル管理者」ページでは、ドメイン管理者はODSMを使用して複数のディレクトリ・サーバー・インスタンスを管理できます。 この管理者は、新しいレプリケーション・トポロジを管理するグローバル管理者です。
グローバル管理者に関する次の情報を指定します。
グローバル管理ユーザーID: トポロジの表示および管理が行える管理者です。
グローバル管理パスワード: 先ほど指定したグローバル管理者のパスワードを入力します。
グローバル管理パスワードの確認: 確認のため、パスワードを再入力します。
「次へ」をクリックします。
「レプリケーション・サーバー」ページの「レプリケーション・サーバーの構成」表に、各レプリケーション・サーバーに関する次の情報が表示されます。
ホスト: レプリケーション・サーバーのホスト名は、ここでは変更できません。
管理ポート: レプリケーション・サーバーの管理ポートは、ここでは変更できません。
レプリケーション・サーバーとして動作: サーバーをレプリケーション・サーバーとして動作させる場合、チェック・ボックスをチェック・マークが表示されるまでクリックします。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。
レプリケーション・ポート: 前述のフィールドでサーバーをレプリケーション・サーバーとして動作するよう有効化した場合、レプリケーション・ポート番号を入力します。
|
注意: 未使用のレプリケーション・ポート番号を入力してください。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。 |
「レプリケーション・データ」ページでは、「レプリケートされたデータの構成」表に、すべてのサーバーの中の2つ以上のサーバーで使用可能なすべての接尾辞が表示されます。トポロジ内の各接尾辞がレプリケートされるかどうかを示します。ここで有効化した接尾辞は、レプリケーション・トポロジ内のすべてのサーバーにレプリケートされます。
ドメインをレプリケーション接尾辞として動作するよう有効化するには、レプリケーションの構成セクションで、「レプリケーションに使用可能」列からドメインを選択し、右矢印をクリックして「レプリケーション用に選択済」列に移動させます。
サーバーをレプリケーション・ドメインとして動作させるよう有効化するには、「サフィックスのレプリケート」チェック・ボックスをチェック・マークが表示されるまでクリックします。
「次へ」をクリックします。
サマリー・ページに、入力したばかりのレプリケーション・サーバーとドメインの情報が表示されます。
表示された情報を変更する必要がある場合は、「戻る」をクリックします。
サマリー情報が正しい場合は、「作成」をクリックします。
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「Directory Manager」タブをクリックします。
構成するサーバーのタブをクリックします。
「一般構成」の下の「ネーミング・コンテキスト」ペインで、「レプリケーション構成」を選択します。
「レプリケーション構成」ページが表示されます。
レプリケーション構成ウィザードを起動するには、「構成」をクリックします。
現在のサーバーがすでに部分的にレプリケーション用に構成されている場合、そのサーバーは、すでに既存のトポロジの一部として存在しています。手順6を省略して、手順7に進みます。
現在のサーバーが部分的にレプリケーション用に構成されていない場合、「レプリケーション・オプション」ページが表示されます。手順6に進みます。
「レプリケーション・オプション」ページで、サーバーを追加したい既存のトポロジがありますか。を選択します。
「次へ」をクリックします。
接続/アイデンティティ・サーバー・ページで、既存トポロジに接続するサーバーについての次の情報が表示されます。
ホスト: 現在のサーバー・ホストがすでにトポロジに含まれている場合、その名前はここでは変更できません。現在のサーバー・ホストがトポロジに含まれていない場合、トポロジ内の既存サーバーのホスト名を入力します。
管理ポート: 現在のサーバー・ホストがすでにトポロジに含まれている場合、その管理ポートはここでは変更できません。現在のサーバーがトポロジに含まれていない場合、先ほど指定したホストの管理ポートを入力します。
グローバル管理ユーザーID: グローバル管理ユーザーIDを入力します。トポロジの表示および管理が行える管理者です。このユーザーIDは、トポロジの作成時に指定したものです。
グローバル管理パスワード: 先ほど指定したグローバル管理者のパスワードを入力します。
「接続」をクリックします。「サーバーのリスト」と「レプリケートされたサフィックスのリスト」が表示されます。
「サーバーのリスト」と「レプリケートされたサフィックスのリスト」で、適切なトポロジにサーバーを追加していることを確認します。
表示されている情報が正しい場合は、「次へ」をクリックします。
「レプリケーション・サーバー」ページの「レプリケーション・サーバーの構成」表に、構成する各レプリケーション・サーバーに関する次の情報が表示されます。
ホスト: レプリケーション・サーバーのホスト名は、ここでは変更できません。
管理ポート: レプリケーション・サーバーの管理ポートは、ここでは変更できません。
レプリケーション・サーバーとして動作: サーバーをレプリケーション・サーバーとして動作させる場合、チェック・ボックスをチェック・マークが表示されるまでクリックします。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。
レプリケーション・ポート: 前述のフィールドでサーバーをレプリケーション・サーバーとして動作するよう有効化した場合、レプリケーション・ポート番号を入力します。
|
注意: 未使用のレプリケーション・ポート番号を入力してください。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。 |
「次へ」をクリックします。
「レプリケーション・データ」ページでは、「レプリケートされたデータの構成」表に、すでにトポロジ内でレプリケーション用に構成された接尾辞を含み、トポロジに追加することを選択したすべてのサーバーが表示されます。トポロジ内の各サーバーが接尾辞をレプリケートするかどうかを示します。
サーバーをレプリケーション・ドメインとして動作させるよう有効化するには、「サフィックスのレプリケート」チェック・ボックスをチェック・マークが表示されるまでクリックします。
「次へ」をクリックします。
サマリー・ページに、入力したばかりのレプリケーション・サーバーとドメインの情報が表示されます。
表示された情報を変更する必要がある場合は、「戻る」をクリックします。
サマリー情報が正しい場合は、「適用」をクリックします。
新しいトポロジを作成したり、既存のレプリケーション・トポロジにサーバーを追加するには、レプリケーション構成ウィザードを起動します。次の条件のいずれかが真の場合、「トポロジ・マネージャ」タブからレプリケーション構成ウィザードを起動できます。
レプリケーション・トポロジが存在しない。第29.3.4.1項「新しいトポロジを最初から作成するには」を参照してください。
レプリケーション・トポロジは存在するが、現在のサーバーがトポロジに追加されていない。第29.3.4.2項「既存レプリケーション・トポロジを管理するには」を参照してください。
ODSMを起動するには、ブラウザのアドレス・フィールドに次のURLを入力します。
http://host:port/odsm
hostは、ODSMが実行されているホストの名前で、portはその管理サーバーのポート番号です。管理サーバーのデフォルトのポート番号は7001です。
「トポロジ・マネージャ」タブをクリックします。
「トポロジ接続」タブが表示されます。
「トポロジ接続」タブの「レプリケーション・トポロジの作成」セクションで、「作成」をクリックします。
「レプリケーション・トポロジの作成」タブが表示されます。
「サーバーの識別」ページで、構成対象である2つ以上のソース・サーバーについて、次の情報を入力します。
ホスト: 完全修飾ドメイン名を使用してホスト名を入力します。
管理ポート: 先ほど名前を付けたサーバーの管理ポート番号を入力します。デフォルトは4444です。
管理ユーザー名: サーバーの管理者のDNを入力します。
管理パスワード: 指定した管理者のパスワードを入力します。
(オプション)このページでは、次のことも行えます。
サーバーに対して構成されている接尾辞をプレビューするには、最後の列の「サフィックスのプレビュー」リンクをクリックします。
構成対象の別のサーバーを追加するには、「追加」をクリックして、前述の手順4を繰り返します。
トポロジからサーバーを削除するには、サーバー名を選択して、「削除」をクリックします。
「次へ」をクリックします。
「グローバル管理者」ページでは、ドメイン管理者はODSMを使用して複数のディレクトリ・サーバー・インスタンスを管理できます。 この管理者は、新しいレプリケーション・トポロジを管理するグローバル管理者です。
グローバル管理者に関する次の情報を指定します。
グローバル管理ユーザーID: トポロジの表示および管理が行える管理者です。
グローバル管理パスワード: 先ほど指定したグローバル管理者のパスワードを入力します。
グローバル管理パスワードの確認: 確認のため、パスワードを再入力します。
「次へ」をクリックします。
「レプリケーション・サーバー」ページの「レプリケーション・サーバーの構成」表に、構成するレプリケーション・サーバーの情報を指定します。
ホスト: サーバー・ホスト名はここでは変更できません。
管理ポート: 管理ポートはここでは変更できません。
レプリケーション・サーバーとして動作: サーバーをレプリケーション・サーバーとして動作させる場合、チェック・ボックスをチェック・マークが表示されるまでクリックします。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。
レプリケーション・ポート: 前述のフィールドでサーバーをレプリケーション・サーバーとして動作するよう有効化した場合、レプリケーション・ポート番号を入力します。
|
注意: 未使用のレプリケーション・ポート番号を入力してください。この設定を変更できない場合、そのサーバーはすでにレプリケーション・サーバーとして構成されています。 |
「次へ」をクリックします。
「レプリケーション・データ」ページでは、「レプリケートされたデータの構成」表に、すべてのサーバーの中の2つ以上で使用可能なすべての接尾辞が表示されます。トポロジ内の各接尾辞がレプリケートされるかどうかを示します。ここで有効化した接尾辞は、レプリケーション・トポロジ内のすべてのサーバーにレプリケートされます。
ドメインをレプリケーション接尾辞として動作するよう有効化するには、レプリケーションの構成セクションで、「レプリケーションに使用可能」列からドメインを選択し、右矢印をクリックして「レプリケーション用に選択済」列に移動させます。
サーバーをレプリケーション・ドメインとして動作させるよう有効化するには、「サフィックスのレプリケート」チェック・ボックスをチェック・マークが表示されるまでクリックします。
「次へ」をクリックします。
サマリー・ページに、入力したばかりのレプリケーション・サーバーとドメインの情報が表示されます。
表示された情報を変更する必要がある場合は、「戻る」をクリックします。
サマリー情報が正しい場合は、「作成」をクリックします。
ODSMを起動するには、ブラウザのアドレス・フィールドに次のURLを入力します。
http://host:port/odsm
hostは、ODSMが実行されているホストの名前で、portはその管理サーバーのポート番号です。管理サーバーのデフォルトのポート番号は7001です。
「トポロジ・マネージャ」サブタブで、次の情報を入力します。
ホスト: レプリケーション・トポロジに含まれる任意のサーバーのホスト名を入力します。完全修飾ドメイン名を使用してサーバー名を使用します。
管理ポート: 先ほど指定したサーバーの管理ポート番号を入力します。
グローバル管理ユーザーID: グローバル管理ユーザーIDを入力します。トポロジの表示および管理が行える管理者です。このユーザーIDは、トポロジの作成時に指定したものです。
グローバル管理パスワード: 先ほど指定したグローバル管理者のパスワードを入力します。
「接続」をクリックします。
「レプリケーション・トポロジ」ページで、トポロジについての情報を表示および管理したり、追加のサーバーをトポロジに追加できます。
レプリケーション・トポロジにサーバーを追加するには、「サーバーの追加」をクリックします。
トポロジ情報を自動的にリフレッシュするには、トポロジ情報を自動的にリフレッシュ・チェック・ボックスをチェック・マークが表示されるまでクリックします。トポロジ情報を手動でリフレッシュするには、最初に自動リフレッシュ機能が無効化されていることを確認し、「リフレッシュ」をクリックします。
トポロジが自動的にリフレッシュされるまでの間隔の値を編集するには、「更新」をクリックします。
レプリケーション・トポロジで最近実行されたタスクを表示するには、「起動されたタスク」セクションで「起動されたタスクの詳細の表示」リンクをクリックします。
「レプリケーション・サーバー」および「レプリケートされたデータ」セクションで、次を実行できます。
ドロップダウン・フィルタ・リストを使用して、レプリケートされた接尾辞、レプリケーション・ホスト名、host:port情報またはレプリケーション・グループ名などの情報のいずれかに基づいて検索結果をフィルタします。
レプリケーション・ポート番号を変更します。
レプリケーションを無効化するには、無効化するレプリケーション・サーバーまたはレプリケートされた接尾辞を選択します。次に、「処理」メニューで「レプリケーションの無効化」を選択します。
レプリケーション・サーバーを別のレプリケーション・グループに割り当てるには、「レプリケーション・サーバー」セクションで「レプリケーション・グループの変更」リンクをクリックします。
サーバーにレプリケートされた接尾辞を構成するには、「レプリケートされたデータ」セクションで、最初に構成するレプリケートされた接尾辞を選択します。その後、次を実行します。
「信頼する/信頼しない」設定を変更するには、「信頼する/信頼しない」をクリックします。信頼できるサーバーおよび信頼できないサーバーの詳細は、第29.12項「分離レプリカの使用」を参照してください。
|
注意: トポロジへの接続に使用されるサーバーが信頼できないサーバーの場合、「信頼する/信頼しない」ボタンが無効化されます。 |
サーバーを初期化するには、「初期化」をクリックします。初期化の詳細は、第7.2.1項「レプリケーションの初期化」を参照してください。
事前外部初期化を開始するには、「事前外部初期化」をクリックします。事前外部初期化の詳細は、第A.2.6項「dsreplication」および第A.2.8項「gicadm」のpre-external-initializationオプションを参照してください。
事後外部初期化を開始するには、「事後外部初期化」をクリックします。事後外部初期化の詳細は、第A.2.6項「dsreplication」および第A.2.8項「gicadm」のpost-external-initializationオプションを参照してください。
履歴データをパージするには、「履歴のパージ」をクリックします。履歴データのパージの詳細は、第7.3.4項「履歴情報のパージ」および第29.11項「履歴レプリケーション・データのパージ」を参照してください。
データ・レプリケーション・グループを変更するには、「レプリケーション・グループの変更」をクリックします。レプリケーション・グループの詳細は、第7.6項「レプリケーション・グループ」を参照してください。
グローバル管理者の資格証明を変更するには、「トポロジ設定」をクリックします。次の情報を指定します。
グローバル管理者ID: トポロジへの接続やトポロジの管理を行える管理者のユーザー名を入力します。このユーザー名は、トポロジの作成時に作成されます。
グローバル管理パスワード: 先ほど名前を付けた管理者のパスワードを入力します。
グローバル管理パスワードの確認: 前述の管理者名のパスワードを再入力します。
「適用」をクリックします。
特に大規模なトポロジでは、専用のレプリケーション・サーバー(ディレクトリ・サーバーを含まないサーバー)と専用のディレクトリ・サーバー(レプリケーション・サーバーを含まないサーバー)を構成する方が簡単な場合が多くあります。
専用ディレクトリ・サーバーにはレプリケート対象データが格納されますが、レプリケート対象データへの変更を記録した変更ログは格納されません。また、専用ディレクトリ・サーバーはレプリケーション・ポートも構成されません。専用レプリケーション・サーバーは、レプリケーション・ポートが構成されます。専用レプリケーション・サーバーにはレプリケート対象データは格納されませんが、トポロジ内の他のサーバーでレプリケート対象データに加えられた変更を記録した変更ログが格納されます。
|
注意: シングル・ポイント障害を回避するために、どのトポロジにも少なくとも2つのレプリケーション・サーバーが必要です。 |
詳細およびトポロジの例は、第2章「ディレクトリ・サーバーを使用するデプロイメントの例」を参照してください。
次の図に、1台の専用レプリケーション・サーバー(レプリケーション・サーバー2)、4台の専用ディレクトリ・サーバー、およびレプリケーション・サーバーとディレクトリ・サーバーを兼ねた1台のサーバー(ホスト1)からなる大規模なレプリケーション・トポロジを示します。
専用レプリケーション・サーバーを構成するには、2つのサーバー間のレプリケーションを有効にするときに--onlyReplicationServer1オプションまたは--onlyReplicationServer2オプションを指定します。
次の例では、前掲の図に示したディレクトリ・サーバーCとレプリケーション・サーバー2の間のレプリケーションを構成します。
$ dsreplication enable \ --host1 host3 --port1 4444 --bindDN1 "cn=Directory Manager" \ --bindPasswordFile1 pwd.txt --noReplicationServer1 \ --host2 host4 --port2 4444 --bindDN2 "cn=Directory Manager" \ --bindPasswordFile2 pwd.txt --onlyReplicationServer2 \ --replicationPort2 8989 --adminUID admin --adminPasswordFile pwd.txt \ --baseDN "dc=example,dc=com" -X -n
dsconfigによるレプリケーション構成の変更この項では、dsconfigコマンドを使用してレプリケーション構成のいくつかの拡張プロパティを変更する方法について説明します。通常、拡張プロパティはオプションです。または、ほとんどの場合に適したデフォルト値が割り当てられています。dsconfigの使用方法の詳細は、第17.1項「dsconfigを使用したサーバー構成の管理」を参照してください。
dsconfigは、ディレクトリ・サーバー間のレプリケーションの設定には使用できません。レプリケーションの設定は、GUIインストール・ユーティリティを使用して自動的に行うか、dsreplicationコマンドを使用して手動で行います。詳細は、第29.3項「ODSMを使用したデータ・レプリケーションの構成」を参照してください。
この項の内容は次のとおりです:
レプリケーション・ドメイン名はディレクトリ・サーバーによって生成されます。この名前にはベースDNと一意の数値識別子が含まれています。
構成されているレプリケーション・ドメインのリストを取得するには、list-replication-domainsサブコマンドを使用します。例:
$ dsconfig -h host1 -p 4444 -D "cn=directory manager" -j pwd-file -n list-replication-domains \ --provider-name "Multimaster Synchronization" Replication Domain : Type : server-id : replication-server : base-dn -------------------:---------:-----------:------------------------:-------------------- cn=admin data : generic : 13981 : host1:8989, host2:8989 : cn=admin data cn=schema : generic : 20284 : host1:8989, host2:8989 : cn=schema dc=example,dc=com : generic : 26560 : host1:8989, host2:8989 : "dc=example,dc=com"
レプリケーション変更データベースは、レプリケートが完了した更新またはレプリケートが完了していない更新の記録を保持しています。レプリケーション・パージ遅延はレプリケーション・サーバーのプロパティで、レプリケーション変更データベースに対して内部パージ操作を実行するまでの期間を指定します。
パージ遅延の期間を過ぎた変更記録は、すでに適用されたかどうかに関係なく、レプリケーション変更データベースから削除されます。デフォルトのパージ遅延は1日です。レプリケーション変更データベースのバックアップ間隔がこのパージ遅延の期間より短いと、変更データベースがバックアップされる前に変更記録がクリアされてしまいます。したがって、バックアップからデータをリストアしても、変更記録が失われる可能性があります。
レプリケーション・パージ遅延の現在値を表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-replication-server-prop \ --provider-name "Multimaster Synchronization" --advanced \ --property replication-purge-delay Property : Value(s) ------------------------:--------- replication-purge-delay : 1 d
パージ遅延を変更します。
次のコマンドは、パージ遅延を1週間に変更します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-server-prop \ --provider-name "Multimaster Synchronization" \ --set replication-purge-delay:1w
ウィンドウ・サイズはレプリケーション・サーバーのプロパティで、レプリケーション・サーバーがディレクトリ・サーバーからの確認応答を待たずにディレクトリ・サーバーに送信できる変更リクエストの数を指定します。
ウィンドウ・サイズは、ディレクトリ・サーバーからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。各メッセージ後の確認応答を待たずに、素早く連続して多くのメッセージを送信する方が効率的です。適切なウィンドウ・サイズを使用することで、レプリケーション・サーバーが確認応答の到着を待つために費やす時間を排除できます。デフォルトのウィンドウ・サイズは100です。一部のディレクトリ・サーバーで変更のレプリケーションが遅れていることに気付いた場合は、他の調整を行う前に、ウィンドウ・サイズの値を大きくしてレプリケーション・パフォーマンスをもう一度確認してください。
ウィンドウ・サイズの現在値を表示します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-replication-server-prop --provider-name "Multimaster Synchronization" \ --advanced --property window-size Property : Value(s) ------------:--------- window-size : 100
ウィンドウ・サイズを変更します。
次のコマンドは、ウィンドウ・サイズを200に変更します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-replication-server-prop \ --provider-name "Multimaster Synchronization" --set window-size:200
レプリケート対象トポロジ内でのデータ・インポート時に、インポート側のサーバーが遅すぎてエクスポート側のサーバーから送信されるデータについていけないことがあります。このような場合、インポート側サーバーはインポートを妨げるだけでなく、エクスポート側サーバーによる他のレプリケーション変更記録の伝播まで妨げるおそれがあります。
初期化ウィンドウ・サイズを使用することで、エクスポート側サーバーは最も遅いインポート側サーバーからの確認応答を検出し、その遅いインポート側サーバーが受信可能な状態のときのみデータをレプリケーション・ネットワーク上に送信することが可能になります。
デフォルトでは、初期化ウィンドウ・サイズは100です。トポロジ内に遅いサーバーがない場合は、初期化ウィンドウ・サイズを大きくできます。これにより、エクスポート側サーバーがより多くの更新を、確認応答を待たずに送信できるようになります。トポロジ内に非常に遅いサーバーがある場合は、初期化ウィンドウ・サイズを小さくすることで、そのサーバーがレプリケーションを妨げないようにできます。
初期化ウィンドウ・サイズの現在値を表示します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name dc=example,dc=com --advanced --property initialization-window-size Property : Value(s) ---------------------------:--------- initialization-window-size : 100
初期化ウィンドウ・サイズを変更します。
次のコマンドは、初期化ウィンドウ・サイズを50に変更します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name dc=example,dc=com --set initialization-window-size:50
ハートビート間隔はレプリケーション・ドメインのプロパティで、レプリケーション・ドメインがレプリケーション・サーバーと通信する間隔を指定します。レプリケーション・ドメインは、レプリケーション・サーバーからこの間隔で定期的にハートビートが届くのを待ちます。ハートビートが受信されない場合、ドメインはその接続を閉じ、トポロジ内の別のレプリケーション・サーバーに接続します。
デフォルトのハートビート間隔は10秒です。応答が遅いWANまたはネットワーク上でレプリケーションを実行している場合は、ハートビート間隔を長くできます。また、次のようなエラーがログに記録されている場合は、おそらくハートビート間隔を長くする必要があります。
[26/May/2011:16:32:50 +0200] category=SYNC severity=NOTICE msgID=15138913 msg=Replication Heartbeat Monitor on RS rserver/192.157.197.62:8989 30382 for dc=example,dc=com in DS 10879 is closing the session because it could not detect a heartbeat
ハートビート間隔はJVMの設定に影響されます。ハートビート間隔をデフォルトより短くする必要がある場合は、必ずJVMの-XX:+UseConcMarkSweepGCオプションを設定して、ガベージ・コレクション中の一時停止時間を短くしてください。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのJVM、Javaオプションおよびデータベース・キャッシュの構成に関する項を参照してください。
ハートビート間隔の現在値を表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 15853)" --advanced \ --property heartbeat-interval Property : Value(s) -------------------:--------- heartbeat-interval : 10 s
ハートビート間隔を変更します。
次のコマンドは、ハートビート間隔を5秒に変更します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 15853)" --set heartbeat-interval:5s
分離ポリシーはレプリケーション・ドメインのプロパティです。このプロパティは、レプリケーションが構成されているのに、更新の受信時にレプリケーション・サーバーが1つも起動および実行されていない場合のディレクトリ・サーバーの動作を指定します。この場合のディレクトリ・サーバーのデフォルト動作は、すべての更新を拒否するというものです。
現在の分離ポリシーを表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ get-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 15853)" \ --advanced --property isolation-policy -n Property : Value(s) -----------------:------------------- isolation-policy : reject-all-updates
分離ポリシーを変更します。
次のコマンドは、このような場合にディレクトリ・サーバーがすべての更新を受け入れるように指定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ set-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 15853)" \ --set isolation-policy:accept-all-updates -n
デフォルトでは、レプリケーションの通信は暗号化されません。暗号化を有効にするには、dsconfigコマンドを使用して暗号化マネージャのプロパティを設定します。
次のコマンドは、レプリケーションの通信を暗号化するように指定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-crypto-manager-prop --set ssl-encryption:true
レプリケーション・グループは、マルチデータ・センター・デプロイメントおよび障害回復シナリオをサポートする場合に設計します。ディレクトリ・サーバーにおけるレプリケーション・グループの設計と実装の詳細は、第7.6項「レプリケーション・グループ」を参照してください。
レプリケーション・グループの構成は、同じグループに所属させる個々のディレクトリ・サーバーおよびレプリケーション・サーバーで行います。ディレクトリ・サーバーでは、レプリケート対象ドメインごとにレプリケーション・グループを構成します。レプリケーション・サーバーでは、レプリケーション・サーバー全体に対してグループを構成します。
レプリケーション・グループを構成するには、それぞれのレプリケート対象ドメインとレプリケーション・サーバーに同じグループIDを割り当てます。次の例では、レプリケート対象ドメインdc=example,dc=comに対してレプリケーション・グループ(1)を構成します。
このグループに所属させる各ディレクトリ・サーバーで、ドメインdc=example,dc=comに対してグループIDを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" --advanced \ --set group-id:1
このグループに所属させる各レプリケーション・サーバーで、グループIDを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-server-prop \ --provider-name "Multimaster Synchronization" --advanced \ --set group-id:1
ほとんどのデプロイメント・シナリオでは、ゆるやかな一貫性を持つマルチマスター・レプリケーション・モデルで十分です。しかし、シナリオによっては、レプリカ間のより厳格な一貫性が必要とされる場合もあります。このような場合は、保証レプリケーションを構成できます。保証レプリケーションには、次の利点があります:
データの高可用性。サーバーが変更を受信した直後にクラッシュした場合、変更がトポロジ内の他のサーバーにレプリケートされる前に失われるおそれがあります。保証レプリケーションでは、確認応答がクライアント・アプリケーションへ送信される前に、すべての変更がトポロジ内の他のサーバーにレプリケートされます。したがって、サーバーがクラッシュした場合にデータが失われる危険性が最小限に抑えられます。
即時のデータ可用性。アプリケーションによっては、変更が行われた直後にその変更がトポロジ内の他のサーバーで使用できるようになることが必要な場合があります。
保証レプリケーションはレプリケーション・プロトコルの拡張であり、レプリケート対象ドメイン単位で構成されます。詳細は、第29.5.1項「レプリケーション・ドメイン名の取得」を参照してください。
保証レプリケーションは、同期レプリケーションとは異なります。つまり、トポロジ内のすべてのサーバーで同時に変更が行われるわけではありません。ただし、LDAPクライアントに関するかぎり、保証レプリケーションは同期レプリケーションの機能をある程度まで模倣します。変更がトポロジ内の他のサーバーに伝播されるまで、クライアント・アプリケーションへの確認応答を遅らせることによって、これを実現しています。
|
注意: 保証レプリケーションは、レプリケーション・グループに依存しています。1つの保証レプリケーション構成で連動するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーが同じレプリケーション・グループに属している必要があります。 |
保証レプリケーションには次の2つの動作モードがあります:
安全データ・モード。更新が正常に完了したという確認応答をクライアントが受信する前に、定義した数のレプリケーション・サーバーへ更新を伝播させる必要があります。
伝播が必須であるレプリケーション・サーバーの数によって安全データ・レベルが既定されます。安全データ・レベルが高ければ高いほど、全体のデータ可用性が高まります。
安全読取りモード。更新が正常に完了したという確認応答をクライアントが受信する前に、トポロジ内のすべてのディレクトリ・サーバーへ更新を伝播させる必要があります。
安全データ・モードでも安全読取りモードでも、トポロジ内のいくつかのサーバーが使用不可である場合にLDAPクライアント・コールがハングしないように、タイムアウト間隔を設定できます。
各ディレクトリ・サーバーでは、ディレクトリ・サーバーがレプリケーション・サーバーに安全データ・モードまたは安全読取りモードで更新を送信すると有効になるグローバル・タイムアウトを構成できます。このタイムアウトに達すると、LDAPクライアント・コールは即座に復帰し、このイベントを追跡するためのメッセージがレプリケーション・ログに書き込まれます。
各レプリケーション・サーバーでは、レプリケーション・サーバーがピアのレプリケーション・サーバーまたは別のディレクトリ・サーバーに安全データ・モードまたは安全読取りモードで更新を送信すると有効になるグローバル・タイムアウトを構成できます。このタイムアウトに達すると、開始サーバー(ディレクトリ・サーバーまたはレプリケーション・サーバー)に返される確認応答メッセージに、タイムアウトを示すメッセージが挿入されます。すると、開始ディレクトリ・サーバーは、その更新に対してタイムアウトが発生したというメッセージをログに書き込みます。
|
注意: ほとんどのデプロイメントでは、デフォルトのタイムアウトで問題ありません。ディレクトリ・サーバーは2秒、レプリケーション・サーバーは1秒です。タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。更新がフル・パスを経由して目的のサーバーに届くまでにかかる時間を見越して、タイムアウト値に反映させる必要があります。 ディレクトリ・サーバーのタイムアウト値は、レプリケーション・サーバーの値より必ず大きくしてください。例: |
保証レプリケーションのメカニズムと様々な構成オプションの詳細は、第7.7項「保証レプリケーション」を参照してください。
この手順では、トポロジに対して安全データ・モードの保証レプリケーションを構成します。ここでは、レプリケーションがすでに構成されていることを前提としています。
トポロジ内の各ディレクトリ・サーバーで次の操作を行います:
保証レプリケーションのモードを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" --advanced \ --set assured-type:safe-data
安全データ・レベルを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" --advanced \ --set assured-sd-level:2
setupまたはdsreplicationを使用してレプリケーションを構成した場合は、レプリケーション・サーバーおよびディレクトリ・サーバーが同一の仮想マシン上に存在します。この場合は、安全データ・レベルを2以上に設定してください。
保証レプリケーションのタイムアウトを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" --advanced\ --set assured-timeout:5s
タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。
ディレクトリ・サーバーのグループIDを確認します。
これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、第29.5.8項「レプリケーション・グループの構成」を参照してください。
保証レプリケーションの現在の構成を表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" --advanced \ --property assured-type --property assured-sd-level --property assured-timeout Property : Value(s) -----------------:------------ assured-sd-level : 2 assured-timeout : 5 s assured-type : safe-data
トポロジ内の各レプリケーション・サーバーで次の操作を行います:
保証レプリケーションの現在の構成を表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-replication-server-prop \ --provider-name "Multimaster Synchronization" --advanced \ --property assured-timeout --property group-id Property : Value(s) --------------------------:--------- assured-timeout : 1 s group-id : 1
保証レプリケーションのタイムアウトを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-server-prop \ --provider-name "Multimaster Synchronization" --advanced \ --set assured-timeout:5s
タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。
レプリケーション・サーバーのグループIDを確認します。
これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、第29.5.8項「レプリケーション・グループの構成」を参照してください。
保証レプリケーションは、レプリケート対象ドメインごとに構成します。この手順では、トポロジに対して安全読取りモードの保証レプリケーションを構成します。ここでは、レプリケーションがすでに構成されていることを前提としています。
トポロジ内の各ディレクトリ・サーバーで次の操作を行います:
保証レプリケーションのモードを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" --advanced \ --set assured-type:safe-read
保証レプリケーションのタイムアウトを設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" --advanced \ --set assured-timeout:5s
タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。
ディレクトリ・サーバーのグループIDを確認します。
これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、第29.5.8項「レプリケーション・グループの構成」を参照してください。グループと保証レプリケーションの詳細は、第7.7項「保証レプリケーション」を参照してください。
保証レプリケーションの現在の構成を表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-replication-domain-prop \ --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" --advanced \ --property assured-type --property assured-timeout --property group-id Property : Value(s) -----------------:------------ assured-timeout : 5 s assured-type : safe-read group-id : 1
トポロジ内の各レプリケーション・サーバーで次の操作を行います:
保証レプリケーションの現在の構成を表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-replication-server-prop \ --provider-name "Multimaster Synchronization" --advanced \ --property assured-timeout --property degraded-status-threshold \ --property group-id Property : Value(s) --------------------------:--------- assured-timeout : 1 s degraded-status-threshold : 5000 group-id : 1
保証レプリケーションのタイムアウトを設定します。
タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-server-prop \ --provider-name "Multimaster Synchronization" --advanced \ --set assured-timeout:5s
機能低下ステータスのしきい値を設定します。
機能低下ステータスのしきい値では、そのディレクトリ・サーバーに対するレプリケーション・サーバーのキューに入っている更新の数に基づいて、サーバーを「遅すぎる」と判断する段階を定義します。詳細は、第7.5.2項「低下ステータス」を参照してください。
ログにタイムアウトが記録されていないかぎり、この値は調整しないでください。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-replication-server-prop \ --provider-name "Multimaster Synchronization" --advanced \ --set degraded-status-threshold:2000
レプリケーション・サーバーのグループIDを確認します。
これは、このレプリケーション・グループを構成するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーで同一である必要があります。グループIDを構成する手順は、第29.5.8項「レプリケーション・グループの構成」を参照してください。グループと保証レプリケーションの詳細は、第7.7項「保証レプリケーション」を参照してください。
部分レプリケーションでは、ディレクトリ・データの特定部分をトポロジ内の他のレプリカにレプリケートできます。この機能は、次のシナリオで特に有効です:
ディスク領域が限られている場合。レプリケートするデータを限定することで、特定のレプリカで必要とされるディスク領域の量を大幅に低減できます。特に、データ量が大きいjpeg写真などの属性のレプリケーションを制限すると効果的です。
セキュリティ上の問題。ユーザー・パスワードなどのデータは機密性が高く、一部のレプリカでは不要なことがあります。特に、それらのレプリカで不正アクセスの危険性があるような場合です。
この項では、トポロジ内の1つ以上のサーバーで部分レプリケーションを構成する手順について説明します。部分レプリケーション・メカニズムのアーキテクチャの詳細は、第7.8項「部分レプリケーション」を参照してください。
部分レプリケーションの構成は、部分データを受け取るディレクトリ・サーバー上で、属性ベースで行います。次の図を参照してください:
ディレクトリ・サーバーBで部分レプリケーションが構成されています。ldapmodify操作がディレクトリ・サーバーAに送信されます。この操作全体がレプリケーション・サーバー1、レプリケーション・サーバー2、ディレクトリ・サーバーBの順に転送されていきます。この操作がディレクトリ・サーバーBでレプリケートされるとき、このサーバーの部分レプリケーション構成に基づいて、操作の一部の属性が排除されます。
部分レプリカは、クライアント・アプリケーションから直接書込み可能です。ただし、禁止された属性を含む追加操作や変更操作が部分レプリカに対して試行された場合、その操作は拒否され、サーバーが「実行要求を拒否」エラーを返します。
部分レプリケーションは、次の2つのうちいずれかのモードで構成できます:
排他モード。このモードでは、fractional-excludeという複数値属性を使用して指定した属性を、受信したLDAP追加操作または変更操作から排除します。
除外する属性は、オブジェクト・クラスのオプション属性であることが必要です。
包含モード。このモードでは、fractional-includeという複数値属性を使用して指定した属性のみを、受信したLDAP追加操作または変更操作から受け入れます。
その他の属性はすべて(オブジェクト・クラスの必須属性を除き)、サーバー上でレプリケートされる変更から削除されます。
この2つのモードは同時には使用できません。つまり、どちらか一方のモードの属性のみをドメイン構成に追加できます。
部分レプリケーションはレプリケート対象ドメイン単位で構成します(第29.5.1項「レプリケーション・ドメイン名の取得」を参照)。部分ドメインは、特定の属性がそのドメインにまったく存在しないことを意味します。これらの属性は操作のリプレイ時に排除されるだけでなく、ドメインの既存データ自体にも存在しません。
レプリケート対象トポロジ全体でデータの一貫性を確保するためには、特定のデータ・セットが部分的であるかどうかを判断する必要があります。したがって、新しい部分ドメインを構成する作業には、そのドメインに禁止の属性が存在しないことと、そのドメインが部分ドメインとして認識可能であることを確認する手順が伴います。詳細は、第29.5.10.3項「部分ドメインを構成および初期化するには」を参照してください。
ドメインの部分レプリケーションを構成するには、次のようにdsconfigコマンドを使用します。
次の例では、オブジェクト・クラスがinetOrgPersonのエントリの作成または変更からphoto属性とjpegPhoto属性を除外するようにレプリカを構成します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" \ --set fractional-exclude:inetOrgPerson:photo,jpegPhoto
オブジェクト・クラスと属性の指定は名前でもOIDでも行えます。したがって、次の例は前の例と同じ結果になります:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" \ --set fractional-exclude:2.16.840.1.113730.3.2.2:0.9.2342.19200300.100.1.7, \ 0.9.2342.19200300.100.1.60
オブジェクト・クラスまたは属性の名前とOIDを併用した場合、両方の値が追加されます。たとえば、次のコマンドは属性名とそのOIDの両方を、除外する属性のリストに追加します:
$ dsconfig set-replication-domain-prop ... --set fractional-exclude:*:jpegPhoto,*:0.9.2342.19200300.100.1.60
この属性をリストから削除するには、属性名とOIDの両方を削除する必要があります。
オブジェクト・クラスを問わず、すべてのエントリの作成または変更からphoto属性とjpegPhoto属性を削除するように指定するには、オブジェクト・クラスのかわりにアスタリスクを使用します。例:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" \ --set fractional-exclude:*:photo,jpegPhoto
次の例では、オブジェクト・クラスがinetOrgPersonのエントリの作成または変更にuid属性とemployeeNumber属性のみを含めるようにレプリケーションを構成します。その他の属性は変更において、オブジェクト・クラスの必須属性を除きすべて無視されます。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" \ --set fractional-include:inetOrgPerson:uid,employeeNumber
オブジェクト・クラスと属性の指定は名前でもOIDでも行えます。したがって、次の例は前の例と同じ結果になります:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" \ --set fractional-include:2.16.840.1.113730.3.2.2:0.9.2342.19200300.100.1.1, \ 2.16.840.1.113730.3.1.3
オブジェクト・クラスまたは属性の名前とOIDを併用した場合、両方の値が追加されます。たとえば、次のコマンドは属性名とそのOIDの両方を、含める属性のリストに追加します:
$ dsconfig set-replication-domain-prop ... --set fractional-include:*:jpegPhoto,*:0.9.2342.19200300.100.1.60
この属性をリストから削除するには、属性名とOIDの両方を削除する必要があります。
オブジェクト・クラスを問わず、すべてのエントリの作成または変更に特定の属性を含めるように指定するには、オブジェクト・クラスのかわりにアスタリスクを使用します。次の例では、すべてのエントリに対する作成操作または変更操作にdescription属性のみを含めます。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name "dc=example,dc=com (domain 10233)" \ --set fractional-include:*:description
新しい部分ドメインを初期化する手順は次のとおりです:
前述の2つの項の説明に従って、排他または包含モードの部分レプリケーションを構成します。
この時点で、ドメインのステータスがbad generation IDになります。詳細は、第7.5項「レプリケーション・ステータスの定義」を参照してください。
このステータスは、データがトポロジ内の他のサーバーと同期されるまで、このドメインでの変更がすべてブロックされることを意味します。
トポロジ内の他のサーバーの1つから新しいデータ・セットをインポートします。
新しいデータ・セットをオンラインでインポートするには、dsreplication initializeを使用するか、import-ldifをオンライン・モードまたはオフライン・モードで使用します。データのインポート元にするサーバーは、完全なレプリカである(つまり、部分レプリカではない)か、またはデータのインポート先のサーバーと同じ部分構成が設定されている必要があります。インポート時には、前述の手順で設定した部分構成に従って、すべてのエントリがフィルタリングされます。
データ・セットをインポートする方法の詳細は、第29.6.1項「単一のレプリケート対象サーバーの初期化」と第20.1項「データのインポートとエクスポート」を参照してください。
データ・インポート後、ドメインのステータスがnormalに戻ります。
詳細は、第7.5項「レプリケーション・ステータスの定義」を参照してください。
これで、ドメインはローカルLDAP操作やトポロジ内の他のサーバーとの同期操作から新規エントリの受入れが可能になりました。ドメイン内のデータに禁止の属性は存在しません。
レプリケート対象トポロジ内の各レプリケート対象ドメインには、トポロジ内での接続状態や、トポロジ内で発生した変更の反映状況に応じて特定のレプリケーション・ステータスが設定されます。詳細は、第7.5項「レプリケーション・ステータスの定義」を参照してください。
レプリケーション・ステータスは、サーバーがレプリケート対象トポロジ内でどの程度最新の状態に保たれているかに応じて自動的に生成されます。設定可能な唯一のパラメータは機能低下ステータスのしきい値です。このパラメータは、レプリケーション・サーバーに接続されているディレクトリ・サーバーのすべてのドメインについて、レプリケーション・サーバーのキューに格納できる最大の変更数を定義するものです。特定のディレクトリ・サーバーに対してこの数に達すると、そのサーバーに機能低下ステータスが割り当てられます。機能低下ステータスは、変更数がこのしきい値を下回るまで維持されます。
|
注意: 機能低下ステータスしきい値のデフォルト値は、ほとんどのデプロイメントに適しています。保証レプリケーションが構成されている場合で、ログに複数のタイムアウト・メッセージが記録されているときのみ、この値を変更します。 |
このしきい値で定義されているデフォルトの変更数は5000です。次の例では、待機時間が長いネットワークを考慮して、しきい値を6000に設定します。
レプリケーション・サーバーでdsconfigを使用して機能低下ステータスしきい値を設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-replication-server-prop --provider-name "Multimaster Synchronization" \ --set degraded-status-threshold:6000
複数のディレクトリ・サーバーと複数のレプリケーション・サーバーからなる大規模なトポロジでは、あらかじめ定義された方法でディレクトリ・サーバーをレプリケーション・サーバーに分散させた方が効率的です。トポロジ内の各レプリケーション・サーバーに接続するディレクトリ・サーバーの数を、レプリケーション・サーバーが稼働しているマシンの相対的な能力に応じて指定できます。詳細は、第7.2.3.2項「レプリケーション・サーバーのロード・バランシング」を参照してください。
レプリケーション・サーバーの重みを構成するには、次のようにdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-replication-server-prop \ --provider-name "Multimaster Synchronization" --set weight:2
デフォルトでは、トポロジ内の各レプリケーション・サーバーの重みは1です。
この項では、dsreplicationコマンドを使用してレプリケート対象サーバーをデータで初期化する方法について説明します。dsreplicationは、SSL経由で管理コネクタを介してサーバー構成にアクセスします。詳細は、第17.3項「サーバーへの管理トラフィックの管理」を参照してください。
この項では、第20.1.1項「スタンドアロン・ディレクトリ・サーバーへのデータの移入」に記載されている情報の一部を参照します。同項を先に一読することをお薦めします。
トポロジ内の単一のディレクトリ・サーバーを初期化する最も簡単な方法は、dsreplicationコマンドを使用して、トポロジ内の別のディレクトリ・サーバーからデータをコピーする方法です。このコマンドを使用するには、コピー元のサーバーとコピー先のサーバー同士のレプリケーションが有効になっている必要があります。このコマンドは、コピー先サーバーの指定したベースDNの下にあるすべてのデータをコピー元サーバーからのデータに置き換えます。
たとえば、次のコマンドはhost2のベースDN "dc=example,dc=com"をhost1のデータで初期化します。
$ dsreplication initialize --baseDN "dc=example,dc=com" \ --adminUID admin --adminPasswordFile pwd.txt \ --hostSource host1 --portSource 4444 \ --hostDestination host2 --portDestination 4444 --trustAll
新しいレプリケート対象トポロジ内のすべてのディレクトリ・サーバーを初期化するには、次のいずれかの方法を使用します:
第20.1.1項「スタンドアロン・ディレクトリ・サーバーへのデータの移入」で説明されているいずれかの方法を使用して、すべてのディレクトリ・サーバーを同じデータで個別に初期化します。すべてのディレクトリ・サーバーをデータで初期化したら、サーバー間のレプリケーションを有効にします。
第20.1.1項「スタンドアロン・ディレクトリ・サーバーへのデータの移入」で説明されているいずれかの方法を使用して、単一のディレクトリ・サーバーを初期化します。すべてのディレクトリ・サーバーに対してレプリケーションを有効にし、dsreplication intialize-allコマンドを使用して残りのすべてのサーバーを同時に初期化します。このコマンドはソース・サーバーの詳細を引数としてとり、レプリケーションが有効になっている他のすべてのサーバーを初期化します。
たとえば、次のコマンドはすべてのディレクトリ・サーバーをhost1上のコンテンツで初期化します。
$ dsreplication initialize-all --hostname localhost --port 4444 --trustAll \ --baseDN "dc=example,dc=com" --adminUID admin --adminPasswordFile pwd.txt
既存のレプリケート対象トポロジにディレクトリ・サーバーを追加する場合、トポロジ内の既存のディレクトリ・サーバーと同じデータ生成を新しいサーバーに移入する必要があります。データ生成とは、レプリケーション・ドメインのルート・エントリに格納されているIDです。データ生成が存在しない場合、レプリケーション・メカニズムによってデータ生成が計算され格納されます。新しいディレクトリ・サーバーがトポロジ内の他のサーバーと同じデータ生成を保持するようにするには、次のいずれかの方法でディレクトリ・サーバーにデータを移入します:
他のディレクトリ・サーバーの移入に使用した同じオリジナルLDIFファイル、バックアップ・ファイルまたはバイナリ・コピーを使用します。
トポロジ内の別のディレクトリ・サーバーからのエクスポート、バックアップまたはバイナリ・コピーを使用します。
GUIインストールを使用して新しいディレクトリ・サーバーをインストールする場合は、そのサーバーをレプリケート対象トポロジのメンバーにすることを指定すれば、自動的に適切なデータ生成を使用してサーバーが初期化されます。
GUIインストールを使用せずにディレクトリ・サーバーをインストールし、dsreplicationコマンドを使用してレプリケーションを有効にする場合は、前述の項で説明したいずれかの方法により手動でサーバーを初期化する必要があります。
トポロジ内のディレクトリ・サーバーにトポロジ内の他のサーバーと同じデータ生成が格納されていない場合、そのディレクトリ・サーバーとのデータ・レプリケーションはできません。ただし、そのディレクトリ・サーバーもトポロジとの接続は維持されており、レプリケーション・プロトコルによる初期化が可能です。このディレクトリ・サーバー上のレプリケーションは、ダウングレードした状態にあるといいます。
適切なデータ生成を持つディレクトリ・サーバーが既存のトポロジに追加されると、トポロジ内の最初のディレクトリ・サーバーがデータで初期化された時点以降に発生したすべての変更がレプリケーション・メカニズムによって自動的にリプレイされます。この動作より、新しいディレクトリ・サーバーがトポロジ内の他のサーバーと確実に同期されます。
データ・セットを変更するには、完全に新規のデータ・セットをトポロジ内のすべてのディレクトリ・サーバーにインポートします。データ・セットが変更される際、2つのタスクが実行されます:
新しいデータがトポロジ内の各ディレクトリ・サーバーに適用されます。
レプリケーション・サーバーに格納されている変更がすべてクリアされます。このタスクには、各ディレクトリ・サーバー上のデータ生成をリセットして新しいデータ生成が使用されるようにする操作も含まれます。
dsreplication initializeコマンドを使用してデータ・セットを変更すると、これらのタスクの両方が自動的に実行されます。ただし、import-ldifコマンドまたはバイナリ・コピー方式でデータ・セットを変更する場合は、次の項の説明に従って、これらのタスクを手動で行う必要があります。
import-ldifまたはバイナリ・コピーを使用してデータ・セットを変更するにはdsreplication pre-external-initializationコマンドを実行して、ディレクトリ・サーバーから生成IDをクリアします。
このコマンドは、トポロジ内の1つのディレクトリ・サーバーで実行するだけで十分です。1つのディレクトリ・サーバーのみを更新対象として指定しないかぎり、トポロジ内のすべてのディレクトリ・サーバーが更新されます。たとえば、次のコマンドは、import-ldifまたはバイナリ・コピーを使用してトポロジ内の全サーバーの初期化を準備します:
$ dsreplication pre-external-initialization -h host1 -p 4444 -X \
-b dc=example,dc=com -I admin -j pwd-file
Are you going to initialize only the contents of server host1:4444 (type
'no' if you will initialize contents of all replicated servers for the given
Base DNs)? (yes / no) [no]:
Preparing base DN dc=example,dc=com to be initialized externally ..... Done.
Now you can proceed to the initialization of the contents of the base DNs on
all the replicated servers. You can use the command import-ldif or the binary
copy to do so. When the initialization is completed you must use the subcommand
{post-external-initialization} for replication to work with the new base DNs contents.
import-ldifまたはバイナリ・コピーを使用して、トポロジ内のすべてのディレクトリ・サーバーをデータで初期化します。
dsreplication post-external-initializationコマンドを実行して生成IDをリセットします。
このコマンドは、トポロジ内の1つのディレクトリ・サーバーで実行するだけで十分です。他のすべてのディレクトリ・サーバーが更新されます。たとえば、次のコマンドは、import-ldifまたはバイナリ・コピーを使用してトポロジ内のすべてのディレクトリ・サーバーの生成IDをリセットします:
$ dsreplication post-external-initialization -h localhost \ -p 4444 -b dc=example,dc=com -I admin -j pwd-file -X Updating replication information on base DN dc=example,dc=com ..... Done. Post initialization procedure completed successfully.
すでに大量のエントリが含まれている既存のレプリケート対象トポロジに大量のエントリをインポートする最も簡単な方法は、import-ldifコマンドに-aオプションまたは--appendオプションを指定して使用する方法です。
import-ldifコマンドを使用してデータをインポートする場合、レプリケート対象データが自動的にはレプリケートされません。このため、import-ldif --appendをトポロジ内のすべてのディレクトリ・サーバーで実行する必要があります。この戦略では、ディレクトリ・サービスを停止せずにデータをインポートできます。
また、トポロジ内の単一のディレクトリ・サーバーにデータをインポートしてから、dsreplication initialize-allコマンドを使用することもできます。ただし、この戦略ではディレクトリ・サービスが一定期間、使用不可になります。
外部変更ログ(ECL)は、ディレクトリ・サーバー・データベース内で発生したすべての変更を公開します。特に、LDAPディレクトリを他のサブシステムと同期させる場合に便利です。
外部変更ログはレプリケーション変更ログからオンラインで構築され、その保管に追加のデータベースは使用されません。通常のJEBバックエンドではないため、索引の構成は不要です。
この項では、ディレクトリ・サービスで外部変更ログを有効にする方法と、外部変更ログにアクセスできるようにクライアント・アプリケーションを構成する方法について説明します。この項の内容は次のとおりです:
ディレクトリ・サーバーおよびレプリケーションの両方を含むサーバー・インスタンスでは、外部変更ログがデフォルトで使用できます。dedicated directory serverまたはdedicated replication serverのいずれかを使用して構成されたサーバー・インスタンスでは、外部変更ログがデフォルトでは使用できません(第29.4項「大規模なレプリケーション・トポロジの構成」を参照)。
次のいずれかの方法でレプリケーションを構成すると、外部変更ログが有効になります:
インストール時にレプリケート対象トポロジのメンバーとしてディレクトリ・サーバーを構成する方法。詳細は、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのインストール時のレプリケーションの設定に関する項を参照してください。
インストール後にdsreplicationコマンドを使用してレプリケーションを構成する方法。詳細は、第29.3項「ODSMを使用したデータ・レプリケーションの構成」を参照してください。
|
注意:
|
外部変更ログの機能はレプリケーション・メカニズムに基づいていますが、クライアント・アプリケーションによっては、レプリケート対象トポロジの外側のローカル・サーバー上にある外部変更ログ・コンテンツを必要とするものもあります。ローカル・サーバーで特定のベースDNに対する外部変更ログを有効にするには、次のコマンドを実行します:
$ dsreplication enable-changelog -h localhost -p 4444 -D "cn=directory manager" \ -j pwd-file -r 8989 -b dc=example,dc=com -X -n
外部変更ログを構成するには、スタンドアロン・サーバーでもレプリケーション・ポート(-r)が必要ですが、これは外部変更ログがレプリケーション・メカニズムに依存しているためです。レプリケーション・ポートを指定する必要があるのは、そのサーバーで変更ログ(またはレプリケーション)があらかじめ構成されていない場合のみです。レプリケーション・ポートのデフォルト値は8989です。
ディレクトリ・サーバー・インスタンス上で外部変更ログが構成されていることを確認するには、次の検索コマンドを実行します:
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \ -s base -b "" "objectclass=*" namingContexts dn: namingContexts: cn=changelog namingContexts: dc=Europe,dc=com namingContexts: dc=us,dc=com
外部変更ログは、次の2種類の操作モードを有効にする2つのAPIをサポートしています:
Cookieモード。外部変更ログへのアクセスには、このAPIを使用することをお薦めします。
Cookieモードでは、クライアント・アプリケーションがサーバーへのリクエストで外部変更ログの交換制御を提供します。このモードでは、サーバーから返されるエントリ内のDITとスキーマは、LDAP変更ログ・ドラフト(http://tools.ietf.org/html/draft-good-ldap-changelog-04)と互換性がありません。
ドラフト互換モード。このモードは、LDAP変更ログ・ドラフトに依存する既存のアプリケーションでのみ使用してください。
このモードでは、サーバーから返されるエントリ内のDITとスキーマは、LDAP変更ログ・ドラフトと互換性があります。
パフォーマンスの向上および簡素化のために、クライアント・アプリケーションを移植してCookieモードを使用してください。詳細は、第29.7.13項「他の変更ログに依存するアプリケーションの移植」を参照してください。
外部変更ログのエントリには、それぞれCookieが関連付けられています。クライアント・アプリケーションは、検索リクエストを送信するとき、(前回の検索の)外部変更ログから読み取った最後のメッセージのCookieまたは空の値のどちらかを提供します。サーバーは、そのCookieに関連付けられた外部変更ログ・エントリを返します。
各エントリがそれぞれに関連付けられたCookieとともに返されます。アプリケーションは接続を切断すると、受信した最後のCookieを格納し、このCookieを次の検索リクエストとともにサーバーへ送信します。
この外部変更ログCookieの送信を次の図に示します。
Cookieのコンテンツは、クライアント・アプリケーションのための公開インタフェースではありません。クライアント・アプリケーションはCookieをリクエスト制御として送信し、サーバーはCookieをレスポンス制御として送信します。
外部変更ログのCookie制御は、1.3.6.1.4.1.26027.1.5.4のOIDを持ちます。アプリケーションから提供されたCookieが破損しているとサーバーが判断した場合、リクエストが却下されます。また、このCookieをアプリケーションに送信した後に外部変更ログの構成が変更されたとサーバーが判断した場合や、外部変更ログがパージされており、格納されている最も古い変更がCookieの値より新しいとサーバーが判断した場合も、リクエストは却下されます。この場合、外部アプリケーションの完全な再同期を推奨する追加情報が返されます。
|
注意: サーバーがレプリケーション・トポロジから切断され、接続中のクライアントからの変更を処理した場合は、収束を保証できません。 |
次のリクエストとレスポンスの例で、クライアント・アプリケーションがどのように外部変更ログを使用して検索し、どのように外部変更ログが応答するかを示します。
外部変更ログの読取りを開始するために、クライアントがcn=changelogに対する最初の検索リクエストを送信します。外部変更ログのCookie制御には空の文字列を指定します。
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \ --control "1.3.6.1.4.1.26027.1.5.4:false:;" -b "cn=changelog" \ "(objectclass=*)" "*" +
サーバーが各変更をSearchResultEntryに格納してクライアントへ送信します。cookie属性では新しいCookieの値を指定します。この値は、外部変更ログのCookie制御にも、エントリとともに送信されます。
# Public changelog exchange control(1.3.6.1.4.1.26027.1.5.4): dc=europe,dc=com:0000012187eae081456200000001;o=example:; dn: replicationcsn=0000012187eae081456200000001,dc=europe,dc=com,cn=changelog objectClass: top objectClass: changeLogEntry replicationCSN: 0000012187eae081456200000001 replicaIdentifier: 17762 targetDN: cn=chek-piao chea,ou=unit1,o=people,dc=europe,dc=com changeTime: 20090528155105Z changes:: cmVwbGFjZTogc2VlQWxzbwpzZWVBbHNvOiBjbj1tY29uZmlnCi0KcmVwbGFjZTogbW9kaW ZpZXJzTmFtZQptb2RpZmllcnNOYW1lOiBjbj1EaXJlY3RvcnkgTWFuYWdlcixjbj1Sb290IEROcyxjb j1jb25maWcKLQpyZXBsYWNlOiBtb2RpZnlUaW1lc3RhbXAKbW9kaWZ5VGltZXN0YW1wOiAyMDA5MDUy ODE1NTEwNVoKLQo= changeType: modify changeLogCookie: dc=europe,dc=com:0000012187eae081456200000001; targetEntryUUID: 08d1830c-02f1-34a6-9cf4-8d1270ec1db0 changeNumber: 0
最後に返されたエントリから外部変更ログを読み取るために、クライアントがcn=changelogに対する検索リクエストを送信します。今度は、外部変更ログのCookie制御で受信した最後のCookieの値を指定します。
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file --control "1.3.6.1.4.1.26027.1.5.4:false:dc=europe,dc=com:0000012187eae081456200000001;" -b "cn=changelog" "(objectclass=*)"
外部変更ログ内の返される各エントリのDNは、次のような形式になっています:
replicationcsn=replicationCSN,replication-domain-DN,cn=changelog
例:
dn: replicationcsn=0000012187eae081456200000001,dc=europe,dc=com,cn=changelog
外部変更ログ・エントリについて次の属性が返されます:
targetDN / MUST changeType / MUST changeTime / MUST changeNumber / MUST // used only for compatibility mode changes / MAY, MUST for add, mod newRDN / MAY, MUST for modrdn deleteOldRDN / MAY, MUST for modrdn newSuperior / MAY, MUST for modrdn replicaIdentifier / MAY, OPERATIONAL / specific OUD value replicationCSN / MAY, OPERATIONAL / specific OUD value targetEntryuuid / MAY, OPERATIONAL / specific OUD value changelogcookie / MAY, OPERATIONAL
デフォルトでは、外部変更ログに含まれる属性は、変更操作の影響を受ける属性のみです。したがって、たとえば、エントリのsn属性が変更される場合、その属性のみが外部変更ログに記述されます。ただし、変更操作の影響を受けるかどうかに関係なく、外部変更ログに含める属性のリストを指定できます。また、この属性リストをすべての種類の操作に対して含めるか、削除操作に対してのみ含めるかも指定できます。
属性の構成には次のプロパティを使用します:
ecl-include
ecl-include-del-only
ecl-includeプロパティの使用方法
ecl-includeプロパティを使用すると、エントリが変更された場合に外部変更ログに含める属性を構成できます。
ecl-includeプロパティの値を設定するには、dsconfigコマンドを使用します。たとえば、エントリが変更された場合に常にcn属性とsn属性を外部変更ログに含めるように指定するには、次のコマンドを実行します:
dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \ set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name dc=example,dc=com \ --add ecl-include:cn --add ecl-include:sn
サーバーが返す外部変更ログ・エントリでは、属性名にtargetという接頭辞が付いています。たとえば、前述の例でいえば、dc=example,dc=comでの変更に対する外部変更ログ・エントリには、targetcn属性とtargetsn属性が必ず含まれています。これらの属性の値は、エントリの変更または移動前のcn属性とsn属性の値です。
ecl-include-del-onlyプロパティの使用方法
ecl-includeプロパティと一緒にecl-include-del-onlyプロパティを使用すると、 削除操作についてのみ追加の属性を取得できます。
ecl-include-del-onlyプロパティの値を設定するには、dsconfigコマンドを使用します。
dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \ set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name dc=example,dc=com \ --add ecl-include:cn --add ecl-include:sn --set ecl-include-del-only:true
外部変更ログを使用するクライアント・アプリケーションは必ずしも、サーバーで実行されたすべてのLDAP操作に関心があるわけではありません。このため、無関連の情報の処理を避けるために、属性のリストをフィルタリングできます。
ecl-blacklistプロパティを使用すると、外部変更ログから除外する属性を構成できます。すべての変更がブラックリスト対象属性に該当する場合のみ、クライアント・アプリケーションへ送信される変更操作がスキップされます。
|
注意: ブラックリスト・メカニズムを使用するには、Cookieモードを使用する必要があります。 |
ecl-blacklistプロパティの値を設定するには、dsconfigコマンドを使用します。たとえば、email属性とtelephonenumber属性に関連する変更操作を外部変更ログから除外するように指定するには、次のコマンドを実行します:
dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -Q -n -X \ set-external-changelog-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name dc=example,dc=com --add ecl-blacklist:email \ --add ecl-blacklist:telephonenumber
クライアントで外部変更ログを使用するために必要なサーバー構成は特にありません。ただし、外部変更ログを使用するクライアント・アプリケーションを、次の各項の説明に従って初期化する必要があります。
次の例で、ホスト2をホスト1から初期化するシナリオを示します。ホスト1は初期化操作中も固定されず、変更を受信し続けます。次の手順により、ホスト1で受信された変更がホスト2に漏れなく反映されることが保証されます。
ホスト1にある最後の外部変更ログCookieの値を読み取って、ホスト1の最新の状態を保存します。
これは、ルートDSEのlastExternalChangelogCookie属性の値です。例:
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \
-s base -b "" "objectclass=*" lastExternalChangelogCookie
dn:
objectClass: top
objectClass: ds-root-dse
lastExternalChangelogCookie: dc=europe:00000121cea5221c04b100000005 \
00000121cea5319e04b400000009;
ホスト1は固定されず、変更を受信し続けることに注意してください。
ホスト2を初期化するために、Oracle Unified Directoryデータベースをホスト1からエクスポートしてホスト2にインポートします。
エクスポートしたデータベースを使用してアプリケーションを初期化します。
手順1で保存した最新の状態を使用して、ホスト2でのレプリケーションを再開します。これで、アプリケーションは最後のCookie値を検索制御の値として提供して、外部変更ログの読取りを開始できます。例:
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file
--control "1.3.6.1.4.1.26027.1.5.4:false:dc=europe:00000121cea5221c04b100000005 \
00000121cea5319e04b400000009" -b "cn=changelog" "(objectclass=*)"
新しいレプリケーション・ドメインをトポロジに追加すると、そのドメインで外部変更ログがデフォルトで有効になります。外部変更ログを使用するクライアント・アプリケーションを、その新規ドメインに対して再初期化する必要があります。
サーバーでは、提供されたCookieが新規ドメインを参照していなければ検索操作を拒否することによって、この要件を強制します。その操作結果コードは「実行要求を拒否」です。サーバーは、欠けているドメインのリストと部分的初期化用のCookie値を含む詳細メッセージを提供します。
次のいずれかの方法でクライアント・アプリケーションを再初期化する必要があります:
完全な再初期化。アプリケーションをすべてのドメインに対して再初期化します。
lastExternalChangelogCookie属性の値を読み取ります。この値は、新規ドメインを含む、トポロジ内の全ドメインを参照しています。
新規ドメインを含む全ドメインを対象にデータベースをエクスポートします。
エクスポートの出力を使用してアプリケーションを全ドメインに対して初期化します。詳細は、第29.7.7.1項「外部変更ログを使用するクライアント・アプリケーションを初期化するには」を参照してください。
これで、アプリケーションはlast_cookie_from_dse_rootを使用して外部変更ログを検索できるようになりました。
部分的再初期化。アプリケーションを新規ドメインに対してのみ再初期化します。
新規ドメインのみを対象にデータベースをエクスポートします。
エクスポートの出力を使用してアプリケーションを初期化します。エクスポートの出力には、新規ドメイン内のエントリのみが格納されています。詳細は、第29.7.7.1項「外部変更ログを使用するクライアント・アプリケーションを初期化するには」を参照してください。
これで、アプリケーションは、「実行要求を拒否」エラーでサーバーから返された部分的初期化用のCookie値を使用して、外部変更ログを検索できるようになりました。その結果として、すでに処理が完了している一部の更新がリプレイされることがありますが、これはCookie値がデータベースの初期状態を示しているためです。
|
注意: ドラフト互換モードのドラフトAPIでは、アプリケーションが適切に初期化されるようにサーバーが強制することはできません。したがって、ドラフト互換モードでは、新規ドメインが追加されると同時に、そのサーバーにおける変更が外部変更ログに公開されます。 サーバーが新規ドメインに関する変更を公開しないようにするには、第29.7.11項「特定のドメインに対する外部変更ログの無効化」を参照してください。特定のドメインに対する変更のみがアプリケーションに通知されるようにするには、そのドメインをベースDNで指定するか(Cookieモードの場合のみ)、 |
レプリケーション・ドメインをトポロジから削除したら(または、外部変更ログを特定のドメインに対して無効にしたら)、以後そのドメインでは変更が発生しないことをクライアント・アプリケーションに通知する必要があります。
サーバーでは、提供されたCookieが、削除されたドメインを参照していれば検索操作を拒否することによって、この要件を強制します。その操作結果コードは「実行要求を拒否」です。サーバーは、Cookieにあるドメインで削除されたもの(または外部変更ログが無効化されたもの)のリストと継続用のCookie値を含む詳細メッセージを提供します。
クライアント・アプリケーションでは、削除されたドメインを次のいずれかの方法で処理できます:
円滑な継続。この場合、アプリケーションはドメインの削除時の処理に関する独自のポリシーを適用できます。このポリシーの作成を支援するために、アプリケーションでは、サーバーからエラー・メッセージで返された継続用のCookie値を提供して外部変更ログを検索できます。
完全な再初期化。アプリケーションをすべてのドメインに対して再初期化します。
lastExternalChangelogCookie属性の値を読み取ります。この値は、削除されたドメインを除く、トポロジ内の全ドメインを参照しています。
全ドメインを対象にデータベースをエクスポートします。
エクスポートの出力を使用してアプリケーションを全ドメインに対して初期化します。詳細は、第29.7.7.1項「外部変更ログを使用するクライアント・アプリケーションを初期化するには」を参照してください。
これで、アプリケーションはlastExternalChangelogCookieを使用して外部変更ログを検索できるようになりました。
外部変更ログへのアクセスは、サーバーで構成可能なグローバルACIによって制御されています。デフォルトでは、rootユーザーのみが外部変更ログにアクセスできます。
グローバルACIの構成の詳細は、第25.1項「dsconfigによるグローバルACIの管理」を参照してください。
外部変更ログは、レプリケーション変更ログとともにパージされます。レプリケーション変更ログのパージ間隔の変更の詳細は、第29.5.2項「レプリケーション・パージ遅延の変更」を参照してください。
アプリケーションがサーバーに保存されている最も古い変更よりも古いCookie値を指定して、外部変更ログに対する検索リクエストを送信する場合があります。これは、そのアプリケーションからの前回のリクエスト以降にパージが実行されたためです。この場合、サーバーはリクエストを却下し、Cookieが古いことと完全な再同期が必要であることを示します。
サーバーで特定のベースDNに対する外部変更ログを無効にするには、次のようにdsreplication disable-changelogコマンドを使用します:
$ dsreplication disable-changelog -h localhost -p 4444 -D "cn=directory manager" \ -j pwd-file -b dc=example,dc=com -X -n
特定のドメインにおける変更を外部変更ログから除外する必要がある場合があります。特定のレプリケーション・ドメインについて外部変更ログを無効にできます。無効にすると、そのドメインに対する変更が外部変更ログに公開されなくなります。
ドメイン名を取得します。詳細は、第29.5.1項「レプリケーション・ドメイン名の取得」を参照してください。
そのドメインの外部変更ログ・ドメイン・プロパティを設定します。
たとえば、スキーマの変更を外部変更ログに公開しないようにするには、次のようにdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-external-changelog-domain-prop \ --provider-name "Multimaster Synchronization" --domain-name cn=schema \ --set enabled:false
サーバーでlastchangenumber属性を取得するには、次のコマンドを実行します。
./ldapsearch -h <hostname> -p <portnumber> -D "cn=Directory Manager" -w <password> -s base -b "" objectclass=* lastchangenumber
例
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -w <password> -s base -b "" "objectclass=*" lastchangenumber
外部変更ログは、LDAP変更ログ・ドラフト(http://tools.ietf.org/html/draft-good-ldap-changelog-04)に基づいていますが、この変更ログを厳密にはサポートしていません。LDAP変更ログ・ドラフトでは、変更ログを閲覧するためのキーとして整数を使用するのに対し、外部変更ログではCookieを使用します。
クライアント側では、Cookieメカニズムには次の利点があります:
外部変更ログ・インスタンス間のフェイルオーバーが可能。
複数の外部変更ログ・インスタンス間での負荷分散リクエストが可能。
サーバー側では、Cookieメカニズムには次の利点があります:
マルチマスター環境における実装が容易になる
サーバーで必要とされるリソースが少なくなる
変更を生成する他のアプリケーションに対するパフォーマンスの影響が小さくなる
|
注意: Oracle Directory Server Enterprise Edition (ODSEE)のレトロ変更ログ(RCL)はLDAP変更ログ・ドラフトをサポートしており、固有の追加がいくつかあります。 |
次の各項では、2つの変更ログの相違点について説明します。これは、クライアント・アプリケーションを移植するときに役立ちます。
LDAP変更ログ・ドラフトでは、変更ログ索引を整数として指定します(changenumber属性)。この形式は、変更ログ・サービスが単一のサーバーによって提供される場合には効果的です(LDAP変更ログ・ドラフトの仕様が策定された時点ではそうでした)。しかし、変更ログ・サービスが複数のサーバーをサポートする場合や、サーバー間のフェイルオーバーをサポートする場合、この整数の形式は不適切です。
Oracle Directory Server Enterprise Editionとの互換性を確保するには、cn=changelogでreplicationCSN属性に索引を作成する必要があります。cn=changelog以外のパラメータでreplicationCSN属性に索引を作成すると、パフォーマンスに影響するおそれがあります。
LDAP変更ログ・ドラフトでは、変更ログ内のエントリに対するDNをchangenumber=changenumer,cn=changelogとして指定します。外部変更ログでは、変更ログ内のエントリに次のDNを使用します:
replicationcsn=replicationCSN,replication-domain-DN,cn=changelog
外部変更ログのスキーマはLDAP変更ログ・ドラフトのスキーマに基づいていますが、Oracle Unified Directoryでは外部変更ログ内の索引をchangenumber属性ではなく、アプリケーションには理解不能なCookieによって管理します。スキーマの違いは次のとおりです:
| オリジン | 必須 | 任意 |
|---|---|---|
|
LDAP変更ログ・ドラフト |
|
|
|
ODSEEレトロ変更ログ |
|
|
|
Oracle Unified Directory外部変更ログ |
|
|
Oracle Directory Server Enterprise Editionのレトロ変更ログは、 ターゲット・エントリの一意IDをtargetuniqueid属性に格納する仕様になっています。この属性値フォーマットは、Oracle Directory Server Enterprise Editionに固有のものです。replicationcsn属性もOracle Directory Server Enterprise Editionに固有の値を保持します。
Oracle Directory Server Enterprise Editionのレトロ変更ログは、ルートDSEエントリの次の属性をサポートしています:
firstchangenumber属性: 最初の(最も古い)変更ログ索引を整数の変更番号として保持します。
この値は、変更ログがパージされると更新されます。アプリケーションは変更ログ・サーバーに接続する前に、最初の変更ログ索引を読み取り、それをアプリケーションが格納した変更ログ索引と比較します。アプリケーションが格納した最後の変更ログ索引よりも最初の変更ログ索引の方が新しければ、アプリケーションの索引から最初の変更ログ索引までの変更がサーバーから返されないことをアプリケーションは認識します。この変更は、すべてのエントリを読み取ることによってのみ取得できます(完全再同期)。
Oracle Unified Directoryの外部変更ログでは、この手続きをアプリケーションが行う必要がありません。かわりに、Oracle Unified Directoryサーバーが確認を行い、Cookieが古すぎる場合はリクエストを却下します。詳細は、第29.7項「外部変更ログの使用」を参照してください。
lastchangenumber属性: 最後の(最も新しい)変更ログ索引を整数の変更番号として保持します。
Oracle Unified Directoryの外部変更ログは、lastExternalChangelogCookie属性に相当する機能をサポートしています。詳細は、第29.7項「外部変更ログの使用」を参照してください。
Oracle Directory Server Enterprise Editionのレトロ変更ログでは、外部変更ログと通常のレプリケーション変更ログが別々のデータベースになっています。Oracle Unified Directoryでは、この2つの変更ログが同じデータベースに格納されています。この設計上の決定には、それぞれの利点があります。この設計上の決定の付加的な結果として、Oracle Directory Server Enterprise Editionでは2つの別々のトリミング・ポリシー(パージの遅延)を設定できるのに対し、Oracle Unified Directoryのトリミング・ポリシーは同一です。
Oracle Unified Directoryは、LDAP変更ログ・ドラフトと互換性のある追加APIを備えているほか、Oracle Directory Server Enterprise Editionのレトロ変更ログの追加機能の大部分をサポートしています。このAPIの使用は、サーバー側のCPUとデータベース(ディスク)領域の面、および外部変更ログ・サーバー間でフェイルオーバーするアプリケーションの計算処理面のパフォーマンスに影響します。
サーバーが外部変更ログに対するリクエストを変更ログCookieなしで受信すると、この互換性API (互換性モード)の使用が構成されます。サーバーは、エントリとともにchangenumber属性を返します。その値は1ずつ増加していく整数です。
クライアントは、changenumberに対するフィルタを指定することで外部変更ログを検索できます。ターゲット・エントリの一意IDは、Oracle Directory Server Enterprise Editionのレトロ変更ログと互換性のある形式でtargetuniqueidという属性に格納されます。最初と最後のchangenumberは、ルートDSEエントリの属性として存在します。
Oracle Unified Directoryでは、外部変更ログを専用のデータベースに格納しないため、特定の索引など、JEBバックエンドでサポートされている機能の一部をサポートしていません。
また、LDAP変更ログ・ドラフトで指定されたchangenumberベースの順序をサポートするために、Oracle Unified Directoryではchangenumberからレプリケーション・ステータスへのマッピングを格納する必要があります。サーバーはリクエストの処理時に、リクエスト・フィルタで提供されたchangenumberからレプリケーション・ステータスの取得を試みます。取得できない場合は、リクエストが却下されます。
スキーマのレプリケーションはデフォルトで有効になっています。サーバー設定の一部としてレプリケーションを構成すると、トポロジ内の既存のサーバーのスキーマを使用して、新しいサーバーのスキーマが自動的に初期化されます。
dsreplication enableコマンドでレプリケーションを構成するとき、2番目のディレクトリ・サーバーを使用して1番目のサーバーのスキーマを初期化するように指定できます。オプションを指定しないと、1番目のディレクトリ・サーバーのスキーマがデフォルトで使用されます。
次の例では、host1のデータを使用してhost2を初期化し、host2のスキーマを使用してhost1のスキーマを初期化します:
$ dsreplication enable --host1 host1 --port1 4444 \ --bindDN1 "cn=Directory Manager" --bindPasswordFile1 pwd.txt \ --replicationPort1 8989 --host2 host2 --port2 4444 \ --bindDN2 "cn=Directory Manager" --bindPasswordFile2 pwd.txt \ --replicationPort2 8989 --adminUID admin --adminPasswordFile pwd.txt \ --baseDN "dc=example,dc=com" --useSecondServerAsSchemaSource -X
環境によっては、スキーマをレプリケートしたくない場合もあります。スキーマは、"cn=schema"という別個のベースDNの下にレプリケートされます。
dsreplication enableコマンドでレプリケーションを構成するとき、スキーマをレプリケートしないように指定するには、--noSchemaReplicationオプションを使用します。
|
注意: QuickSetupを使用してレプリケーションを有効にする場合は、スキーマをレプリケートしないようには指定できません。 |
現在スキーマがレプリケートされている既存のトポロジでこの機能を無効にするには、スキーマ・ベースDNのレプリケーションを無効にします。次の例では、ローカル・ホストのポート1389で稼働しているディレクトリ・サーバーのスキーマのレプリケーションを無効にします:
$ dsreplication disable -h localhost -p 1389 -D "cn=directory manager" \ -j pwd-file -b "cn=schema" -X
|
注意: この例は、トポロジ全体のスキーマのレプリケーションを無効にするものではありません。トポロジ全体のスキーマのレプリケーションを無効にするには、トポロジ内の各ディレクトリ・サーバーで同等のコマンドを実行する必要があります。 |
Oracle Unified Directoryのレプリケーション・モデルはマルチマスター・モデルです。つまり、トポロジ内のすべてのレプリケーション・サーバーが読取り操作と書込み操作の両方を処理できます。ただし、特定のディレクトリ・サーバーを読取り専用に設定できます。そのサーバーでは、LDAPクライアントからの追加操作、変更操作および削除操作が却下されます。
|
注意: 読取り専用ディレクトリ・サーバーは、Oracle Directory Server Enterprise Editionのレプリケーション・モデルにおけるコンシューマ・レプリカと同様に機能します。 |
この例では、host1とhost2の2つのホストにレプリケーション・サーバーが存在するレプリケーション構成を想定しています。この例では、host2のディレクトリ・サーバーを読取り専用レプリカとして構成します。ここでは、dsconfigコマンドを使用します。このコマンドは、管理コネクタを介してサーバー構成にアクセスします。詳細は、第17.3項「サーバーへの管理トラフィックの管理」を参照してください。
dsconfigコマンドを使用してhost2のwritability-modeを設定します。
$ dsconfig -h host2 -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-global-configuration-prop --set writability-mode:internal-only
internal-onlyという書込み可能性モードは、サーバーでレプリケーション操作は処理されるが、LDAPクライアント・アプリケーションによるサーバーへの直接の書込みはできないことを意味します。
ディレクトリ・サーバーのレプリケーションは、ハードウェアの故障やディレクトリ・サーバーの再起動、ネットワーク障害が発生しても、レプリケート対象データベース間の一貫性が維持されるように設計されています。しかし、それでも、ハードウェアの故障(ディスク・エラー、メモリー・エラー)やソフトウェアの不具合(これに起因するメモリーの破損)によってデータベース間に不整合が発生する可能性があります。
ここでは、レプリケーションの非一貫性を検出する方法と、非一貫性が確認された場合にそれを解決する方法について説明します。
非一貫性が発生しても、しばらくそれが顕在化しない場合もあれば、レプリケーション・エラーやアプリケーション・エラーが引き起こされる場合もあります。非一貫性の例を次に示します:
あるエントリがレプリケーション・トポロジ内の1つのディレクトリ・サーバーを除くすべてのディレクトリ・サーバーに存在します。
あるエントリのDNが1つのディレクトリ・サーバーでのみ、他のディレクトリ・サーバーと異なります。
あるエントリの属性が1つのディレクトリ・サーバーでのみ、レプリケーション・トポロジ内の他のディレクトリ・サーバーと異なります。
レプリケーションの非一貫性を確認するには、次の方法があります:
レプリケーション・ログ・ファイル内の情報を確認する。レプリケーション・ログ・ファイルはデフォルトで構成されており、レプリケーション・メカニズムによって検出された非一貫性が記録されます。たとえば、トポロジ内の1つのディレクトリ・サーバーに存在しないエントリに対して変更操作が実行されたとします。レプリケーションがこの操作をこのサーバーに対してリプレイしようとすると、問題が検出され、logs/replicationエラー・ログにエラーが書き込まれます。この種のエラーによってレプリケーションが停止することはありませんが、操作がリプレイされないため、管理者は非一貫性を修正する必要があります。
クライアント・アプリケーションまたはユーザーから報告されるエラーに注意する。クライアント・アプリケーションやユーザーがディレクトリ・サーバーへのアクセス時に、レプリケーションの非一貫性に起因する可能性のあるエラーに遭遇する場合があります。
データベースの一貫性を定期的に確認する。現行のリリースのディレクトリ・サーバーでは、これらの確認は検索またはデータベース・エクスポートによって手動で行う必要があります。
トポロジ内の単一のディレクトリ・サーバーでレプリケーションの非一貫性が検出された場合、通常のLDAP操作でこの非一貫性を修正することはできません。LDAP操作自体がトポロジ内の他のディレクトリ・サーバーにレプリケートされ、それらのサーバーを損傷するおそれがあるためです。また、修正には、ディレクトリ・サーバーによって生成された属性(entryuid属性、modifyTimestamp属性など)の変更が伴う場合もあります。こうした属性は通常のLDAP操作では変更できません。
したがって、レプリケーションの修復操作は、レプリケーション修復制御(OID: 1.3.6.1.4.1.26027.1.5.2)を指定するLDAP操作を使用して行う必要があります。
|
注意: レプリケーション修復制御を使用すると、ディレクトリ・サーバーが通常行ういくつかの制御をスキップできます。このため、レプリケーション修復制御は、一貫性の問題が検出されアサートされた場合にのみ、細心の注意を払って使用してください。 |
修復制御により、操作の通常の処理が次のように変更されます:
entryuuid、ds-sync-histなど通常は変更や追加ができない(NO-USER-MODIFICATION)属性を操作で変更できるようになります。
操作にレプリケーション変更番号が関連付けられません。
操作がレプリケーション・サーバーに公開されず、ローカルのみの操作になります。
レプリケーションが競合の解決を試みないか、この操作の履歴情報を生成しません。
この操作に対しては、ほとんどのスキーマ・チェックが実行されません。
たとえば、次のldapmodify操作は、changes.ldifファイルに格納されている変更を使用して、host1上のエントリのみを修復します:
$ ldapmodify -J 1.3.6.1.4.1.26027.1.5.2 -h localhost -p 1389 \ -D "cn=Directory Manager" -j pwd-file -f changes.ldif
エントリを修復するときには、その通常属性だけでなく、ディレクトリ・サーバーによって生成されたmodifyTimestamp、modifiersName、createTimestamp、creatorsName、ds-sync-histなどの属性もすべて修復する必要があります。これらの属性の値を、正しい値が格納されているディレクトリ・サーバーから読み取り、不適切な値があるサーバーで再作成してください。
ds-sync-hist属性には、レプリケーションによる変更の競合の解決に使用される履歴情報が保持されています。この属性を参照できるのは管理者のみです。
サーバー同士が互いの変更をレプリケートする前にエントリが作成された場合、同じDNを持つエントリが別々のディレクトリ・サーバーで作成される場合があります。リモート操作がローカル・サーバーにレプリケートされると、名前の競合が発生します。名前の競合の結果として、競合エントリがローカル・サーバーに作成されます。
競合エントリは、entryuuid=entryUid+oldRDNという形式の固有のDNを持ちます。どの競合エントリにもds-sync-conflict属性があり、その値は競合する通常エントリのDNです。
たとえば、cn=bjensen,ou=People,dc=example,dc=comというエントリが2つのディレクトリ・サーバー上で同時に作成されたとします。サーバー1のエントリにはuid1という一意IDが割り当てられ、サーバー2のエントリにはuid2という一意IDが割り当てられます。レプリケーション後、どちらのディレクトリ・サーバーにも次の2つのエントリが存在することになります:
cn=bjensen,dc=example,dc=com ... entryuuid=uid2+cn=bjensen,dc=example,dc=com ds-sync-conflict:cn=bjensen,dc=example,dc=com
競合エントリを特定したら、そのエントリの名前を変更して一意のDNを与えることができます。
競合エントリのネーミング属性が複数値の場合、次のようにして競合エントリの名前を変更できます:
古いRDN値を維持しながら、エントリ名を変更します。例:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: entryuuid=uid2+cn=bjensen,dc=example,dc=com changetype: modrdn newrdn: cn=bljensen deleteoldrdn: 0 îD
この手順で古いRDN値は削除できません。これには、削除できないentryuuid操作属性も含まれているためです。
ネーミング属性の古いRDN値と競合マーカー属性を削除します。例:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: cn=bljensen,dc=example,dc=com changetype: modify delete: cn cn: bjensen delete: ds-sync-conflict îD
dc(ドメイン・コンポーネント)など、競合エントリのネーミング属性が単一値の場合、エントリ名を単純に同じ属性の他の値に変更することはできません。かわりに、次のように仮の名前をエントリに付与する必要があります:
異なるネーミング属性を使用してエントリ名を変更し、古いRDN値は維持します。たとえば、次のようになります:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: entryuuid=uid2+dc=HR,dc=example,dc=com changetype: modrdn newrdn: o=TempHR deleteoldrdn: 0 îD
この手順で古いRDN値は削除できません。これには、削除できないentryuuid操作属性も含まれているためです。
目的のネーミング属性を一意の値に変更して、競合マーカー属性を削除します。例:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: o=TempHR,dc=example,dc=com changetype: modify replace: dc dc: NewHR delete: ds-sync-conflict îD
エントリ名を変更して目的のネーミング属性に戻し、仮のRDNを削除します。例:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: dc=NewHR,dc=example,dc=com changetype: modrdn newrdn: dc=NewHR deleteoldrdn: 1 îD
Oracle Unified Directoryは、レプリケーション操作の結果としてサーバーで行われたすべての変更の履歴を維持します。この履歴レプリケーション・データは各ユーザー・エントリの属性に格納され、いずれ大量のディスク領域を占有する可能性があります。そのため、エントリが変更された時点で履歴情報はパージされます。または、管理者が明示的にコマンドを実行してデータをパージすることもできます。
デフォルトでは、1日以上経過した情報がパージされます。パージ対象とするデータの経過時間を指定するには、レプリケーション・ドメインのconflicts-historical-purge-delayプロパティの値を設定します。次の例では、5日以上経過したデータをパージするように指定します。このプロパティの値は分単位で指定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-replication-domain-prop --provider-name "Multimaster Synchronization" \ --domain-name dc=example,dc=com --set conflicts-historical-purge-delay:7200m
また、履歴データを即時にパージしたり、タスクをスケジュールして指定時刻にデータをパージすることもできます。たとえば、あるサーバーを大量のエントリで初期化した後、それらのエントリに相当数の変更を加えたとします。その結果生成されたレプリケーション履歴データにより、データベースのサイズが大幅に増加します。その後、そのサーバーが主に読取り操作に使用された場合、履歴データのパージをトリガーする変更が行われないため、データベースのサイズは大きいままになってしまいます。この場合、1回かぎりのパージ・タスクを実行することで、初期変更によって生成された履歴データを削除し、データベースをより適切なサイズに戻すことができます。
パージ処理にはしばらく時間がかかる場合があるため、パージの最大継続時間を秒単位で指定する必要があります。履歴データを即時にパージするには、次のコマンドを実行します:
$ dsreplication -h localhost -p 4444 --adminUID admin --adminPasswordFile pwd.txt \ purge-historical --maximumDuration 3600 --baseDN dc=example,dc=com -X -n
スケジューリング・コマンドの詳細は、第17.4項「タスクとしてのコマンドの構成」を参照してください。
分離レプリカとは、他のレプリカから変更を受け入れてリプレイできるが、接続先のレプリケーション・サーバーに変更を送信できないディレクトリ・サーバーのことをいいます。分離レプリカは、トポロジに対するデータ更新のソースにはなれません。分離レプリカを使用すると、特定のディレクトリ・サーバーをレプリケーション・トポロジ内の他のサーバーから分離できます。
トポロジ内のすべてのディレクトリ・サーバーにtrusted構成プロパティがあります。このプロパティは、デフォルトではtrueに設定されています。トポロジ内の信頼できないサーバーとして構成すると、つまり、trusted構成プロパティをfalseに設定すると、分離レプリカとして認識されます。信頼できないディレクトリ・サーバーに由来するデータは、レプリケーション・サーバーによって破棄されます。これにより、分離レプリカがレプリケーション・トポロジ内でデータ更新のソースにならないことが保証されます。
信頼できるサーバーか信頼できないサーバーかを構成できるのは、ディレクトリ・サーバーのみです。レプリケーション・サーバーにはtrusted構成フラグがありません。
特定のディレクトリ・サーバーを信頼できないサーバーとして構成するには、次のようにdsreplication set-trustコマンドを使用します:
$ dsreplication --adminUID admin --adminPasswordFile pwd.txt -X \ set-trust --trustedHost host1 --trustedPort 4444 \ --modifiedHost host2 --modifiedPort 5444 --trustValue untrusted
dsreplication set-trustコマンドは、対話型モードと非対話型モードの両方でサポートされています。
信頼できるサーバーと信頼できないサーバーの構成には、次の制限があります:
ディレクトリ・サーバーのtrustフラグは、トポロジ内の別の信頼できるサーバーからのみ構成できます。trustフラグは、構成対象のサーバー自体からは構成できません。したがって、-trustedHostオプションと--modifiedHostオプションが同じディレクトリ・サーバーを参照することはできません。
ディレクトリ・サーバーをuntrustedからtrustedに変更する場合、変更対象のホストが稼働中であることが必要です。稼働していないと、コマンドが失敗します。
ディレクトリ・サーバーをuntrustedからtrustedに変更する場合、信頼できない変更が変更対象のホストに存在しないことが必要です。信頼できない変更とは、信頼できないサーバーで行われた変更のことで、そのため、トポロジ内の他のサーバーには伝播されていない変更のことをいいます。変更対象のホストに信頼できない変更がある場合は、トポロジ内のいずれかの信頼できるサーバーの適切なデータ・セットを使用して、影響を受ける接尾辞を再初期化してから、ホストをtrustedに変更してください。
信頼できないサーバーのスキーマを変更すると、そのサーバーを信頼できるサーバーとして再構成できなくなります。この場合、そのサーバー・インスタンスを削除して作成しなおす必要があります。
ディレクトリ・サーバーが信頼できるサーバーか信頼できないサーバーかを調べるには、dsreplication statusコマンドを使用します。例:
$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \ --hostname host1 --port 4444
分離レプリカをレプリケーション・トポロジ内で使用するための主なシナリオには、次の2つがあります:
非武装地帯(DMZ)にセキュリティを追加するシナリオ
クライアント・アプリケーションをステージング領域でテストするシナリオ
非武装地帯(DMZ)とは、社内ネットワークの中で、インターネットなどの信頼できないネットワークに公開されている領域のことです。DMZは信頼できるネットワークと信頼できないネットワークの間に位置するため、保護層を備えています。外部からの直接アクセスは、DMZの内側に設置されている機器に限定されます。次の図は、DMZでの分離レプリカの使用方法を示しています。
DMZ内に読取り専用ディレクトリ・サーバーを配置することで、危険にさらされているデータが社内ネットワークのプライベート領域内にあるレプリケーション・サーバーに伝播されないようにできます。レプリカをDMZ内にデプロイすると、そのレプリカは社内のファイアウォールで保護されないため、セキュリティが破られる危険性があります。このような場合、不正なユーザーがレプリカの構成にアクセスして、書込み可能なレプリカに変更してしまうおそれがあります。そのため、このようなレプリカに対し、ファイアウォールで保護されているレプリケーション・サーバーは信頼できないというレッテルを貼ります。
DMZ内のサーバーを信頼できないサーバーとして構成することで、悪意のあるデータをそれらのサーバーが受け入れないように保護できます。プライベート領域内のサーバーは、読取りおよび書込みアクセス権を持つように構成されています。この構成により、データ変更がプライベート領域内のディレクトリ・サーバーによってのみレプリケーション・トポロジ全体に伝播されることが保証されます。DMZ内の読取り専用ディレクトリ・サーバーは、プライベート・ネットワークの内側にあるレプリケーション・サーバーからデータ変更を取得します。外部の攻撃者がデータのセキュリティを破ろうとしても、直接アクセス・ポイントはDMZ内の読取り専用サーバーです。DMZ内のディレクトリ・サーバーは信頼できないサーバーなので、悪意のあるデータは伝播できません。したがって、プライベート社内LAN内のサーバー・データの整合性が守られます。
このシナリオには次の構成要件があります:
DMZ内の各ディレクトリ・サーバーが信頼できないサーバーかつ読取り専用として構成されていること。
トポロジ内の各レプリケーション・サーバーがプライベート社内LANの内側に位置していること。
プライベート社内LAN内の各ディレクトリ・サーバーが読取り/書込みアクセス権を持つ信頼できるサーバーとして構成されていること。
トポロジ内の信頼できる各ディレクトリ・サーバーには次のアクセス権が付与されています:
接続先のレプリケーション・サーバーに変更を送信できます。この変更は、トポロジ内の他のすべてのディレクトリ・サーバーに伝播されます。
接続先のレプリケーション・サーバーから送信された変更をリプレイできます。
他のサーバーを初期化するためのオンライン完全更新操作のデータ・ソースになることができます。
トポロジ内の信頼できない各ディレクトリ・サーバーには次のアクセス制限があります:
接続先のレプリケーション・サーバーに変更を送信する権限がありません。信頼できないディレクトリ・サーバーが変更を送信すると、その変更は危険にさらされたデータと判定され、レプリケーション・サーバーはその変更を破棄します。
接続先のレプリケーション・サーバーから送信された変更をリプレイできます。
他のサーバーを初期化するためのオンライン完全更新操作のデータ・ソースになることができません。
ステージング領域でアプリケーションをライブ・データに対してテストするとき、分離レプリカを使用すると便利な場合があります。それには、分離レプリカを信頼できないサーバーとして構成し、読取り/書込みアクセス権を付与します。アプリケーションのアクセス・ポイントは分離レプリカであり、ステージング領域内の分離レプリカにのみデータが書き込まれます。
次の図は、ステージング領域での分離レプリカの使用方法を示しています。
Oracle Unified Directoryは、Oracle Directory Server Enterprise EditionとOracle Unified Directoryの間でデータをレプリケートする仕組みを備えています。このレプリケーション・ゲートウェイの主な目的は、Oracle Directory Server Enterprise EditionからOracle Unified Directoryへの移行を可能にすることです。
この2つの異なるトポロジ間のレプリケーションを設定するには、次の3つのステップが必要になります:
Oracle Directory Server Enterprise Editionのスキーマおよび構成からOracle Unified Directoryサーバーへの移行
Oracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバー間のレプリケーションの構成
Oracle Directory Server Enterprise EditionサーバーのデータによるOracle Unified Directoryサーバーの初期化
各ステップについては、次の手順説明を参照してください。これらの手順は、次の作業が完了していることを前提としています:
Oracle Directory Server Enterprise Editionサーバーがインストールされており、稼働中であること。
Oracle Unified Directoryのレプリケーション・ゲートウェイは、DS6モードのパスワード・ポリシーのみをサポートしています。Oracle Directory Server Enterprise EditionのインスタンスでDS5モードのパスワード・ポリシーを使用している場合は、アップグレードする必要があります。
Oracle Unified Directoryディレクトリ・サーバーがインストールされており、稼働中であること。
Oracle Unified Directoryサーバーは、Oracle Directory Server Enterprise Editionサーバーのデータで初期化されるため、接尾辞なしで構成されている必要があります。
レプリケート対象Oracle Unified Directoryトポロジがすでに存在する場合は、Oracle Unified Directoryサーバー・インスタンスをもう1つ接尾辞なしで作成し、そのサーバーをレプリケーション・ゲートウェイにアタッチします。すべてのds2oudコマンドをその空のOracle Unified Directoryサーバーに対して実行する必要があります。Oracle Directory Server Enterprise EditionサーバーとOracle Unified Directoryサーバーの間のレプリケーションが稼働しているとき、Oracle Unified Directoryサーバーを既存のレプリケート対象Oracle Unified Directoryトポロジに追加できます。
たとえば、既存のOracle Unified Directoryトポロジがあると仮定した場合、移行前のサーバー・レイアウトは次のようになります:
移行後のサーバー・レイアウトは次のようになります:
Oracle Unified Directoryでは、すべてのパッチセットが適用されたSun ONE Directory Server 5.2、Sun Java System Directory Server Enterprise Edition 6.3.1、Sun Directory Server Enterprise Edition 7.0およびOracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)の構成とスキーマを移行できます。このタイプのインスタンスの移行は、ds2oudコマンドを使用して実行できます。これらのバージョンのディレクトリはds2oudツールでのみサポートされていますが、レプリケーション・ゲートウェイ(Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)以上が必須です)の使用についてこのかぎりではありません。
つまり、移行するインスタンスのバージョンによっては、生成されるOracle Unified Directoryインスタンスが完全に機能するためには、手動での補足の手順が必要になります。たとえば、オブジェクト・クラスおよびパスワード・ポリシーに関するデータの変更やメタデータの変換などです。ただし、Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)以上を実行している場合は、この項の手順2 aで説明するユーザー・データのエクスポート時に自動的にデータ変換が行われます。
この項の手順では、ds2oudコマンドの様々なオプションについて説明します。コマンド行でds2oudを入力すると、ds2oudコマンドを完全に対話型で実行できます。対話型モードでは、応答を要求するプロンプトが表示されます。詳細は、第A.2.3項「ds2oud」を参照してください。
Oracle Unified Directoryディレクトリ・サーバーで、ds2oud --diagnoseコマンドにOracle Directory Server Enterprise Editionサーバーの接続詳細を指定して実行します。ds2oudコマンドは、instance_dir/OUD/bin (Linuxの場合)またはinstance_dir\OUD\bat (Windowsの場合)にあります。
このコマンドは、Oracle Directory Server Enterprise Editionサーバー・インスタンスを評価して、いずれかのサーバー構成をOracle Unified Directoryサーバーに移行する必要があるかどうかを報告します。
$ ds2oud --diagnose -h host1.example.com -p 1389 \ -D "cn=directory manager" -j pwdfile
--diagnoseサブコマンドは、Oracle Directory Server Enterprise Editionの次の構成要素を調べます:
有効なユーザー・プラグイン
有効なサブツリー・エントリ・カウンタ・プラグイン(サブツリー・エントリ・カウンタ・プラグインはOracle Unified Directoryではサポートされていません)
デフォルトのスキーマに対する拡張
CoSまたはロール定義
マクロACI
ACI構文の妥当性
パスワード・ポリシーの種類(DS6モードのみがサポートされています)
データ内の競合するエントリ
暗号化された属性(属性の暗号化はOracle Unified Directoryではサポートされていません)
Oracle Unified Directoryスキーマに関するデータのコンプライアンスを検証するために、次の操作を行います:
Oracle Directory Server Enterprise EditionデータをLDIFにエクスポートします。
Oracle Directory Server Enterprise Editionサーバーで、次の例のようにdsconf exportコマンドを実行します:
$ dsconf export -f opends-export -h host1.example.com -p 1389 \ dc=example,dc=com odsee-data.ldif
|
注意: 前述のコマンドの |
データをLDIFにエクスポートしたら、Oracle Unified Directoryでds2oudコマンドを実行します。例:
$ ds2oud --ldifDBFile odsee-data.ldif --userSchemaFile 99user.ldif
odsee-data.ldifは、LDIFにエクスポートされたOracle Directory Server Enterprise Editionのデータです。99user.ldifは、Oracle Directory Server Enterprise Editionのカスタマイズされたスキーマ・ファイルです(Oracle Directory Server Enterprise Editionのスキーマをカスタマイズした場合)。
このコマンドは、Oracle Directory Server Enterprise EditionのデータとOracle Unified Directoryのスキーマの間にスキーマの不整合がないかを調べます。データを移行する前に、Oracle Directory Server Enterprise Editionのデータが必要とするスキーマ拡張をOracle Unified Directoryのスキーマに追加する必要があります。
ds2oudコマンドに1つまたは複数の移行オプションを指定して実行し、スキーマ、サーバー構成またはその両方を移行します。
Oracle Unified Directoryがデータを検証できるように、スキーマを移行してから構成を移行する必要があります。
ds2oud --migrateUserSchemaを実行すると、Oracle Directory Server Enterprise Editionのユーザー・スキーマ(通常は99user.ldifファイルに格納されています)がOracle Unified Directoryのスキーマに追加されます。
Oracle Unified Directoryで集合属性またはパスワード・ポリシーの機能をレプリケートする場合は、これらの機能用にOracle Directory Server Enterprise Editionのスキーマを準備する必要があります。Oracle Unified Directoryでは、次の場所にカスタム・スキーマ・ファイル(99OudSchemaExtract.ldif)が用意されています。
install-dir/OracleUnifiedDirectory/config/ds2oud
このファイルを使用して、Oracle Unified Directory固有のスキーマ要素をOracle Directory Server Enterprise Editionインスタンスに追加できます。
このスキーマ・ファイルをOracle Directory Server Enterprise Editionスキーマに追加する方法の詳細は、Oracle Directory Server Enterprise Edition管理ガイドのカスタム・スキーマ・ファイルによるスキーマの拡張に関する項を参照してください。
ds2oud --migrateConfigurationを実行すると、次の操作が行われます:
Oracle Directory Server Enterprise Editionの既存の接尾辞に基づいてネーミング・コンテキストが作成されます。ネーミング・コンテキストを単一の共有ワークフロー要素(userRoot)に作成するか、接尾辞ごとのワークフロー要素に作成するかを指定できます。構成にサブ接尾辞が含まれている場合は、強制的に接尾辞ごとのワークフロー要素に作成されます。
Oracle Unified Directoryに適用されるいくつかのグローバル構成パラメータ(size-limit、lookthrough-limit、idle-time-limit、max-psearches、bind-with-dn-requires-passwordなど)が移行されます。
グローバルおよびバックエンドallidsthresholdパラメータがOracle Unified Directoryのindex-entry-limitバックエンド・プロパティに移行されます。
構成されている索引があれば追加され、索引または索引タイプ上の固有のallidsthresholdパラメータが新しい索引に移行されます。
DSE ACIがds-cfg-global-aciに翻訳され、Oracle Unified Directoryの構文検証を使用してACIの妥当性が確認されます。
可能な場合は、7ビット・チェック、UID一意性、参照整合性、強力なパスワード・ポリシー・チェックの各プラグインの構成が移行されます。
パスワード・ポリシーが設定され、デフォルトのパスワード・ポリシーがOracle Directory Server Enterprise Editionのデフォルトのパスワード・ポリシーに対応するように構成されます。移行が可能なのは、DS6モードのパスワード・ポリシーを使用しているOracle Directory Server Enterprise Editionサーバーの場合のみです。
スキーマおよび構成パラメータを移行するには、次のコマンドを実行します:
$ ds2oud --migrateAll -D "cn=directory manager" -j pwdfile \ -h host1.example.com -p 1389 \ --oudBindDN "cn=directory manager" --oudBindPasswordFile pwdfile \ --oudHostname localhost --oudAdminPort 4444 --oudPort 1389
-D、-j、-hおよび-pには、Oracle Directory Server Enterprise Editionインスタンスの接続パラメータを指定します。
ほんどのACIはエントリ自体に格納されています。したがって、Oracle Directory Server Enterprise EditionインスタンスからデータをエクスポートしてOracle Unified Directoryインスタンスにインポートするときに移行されます。--migrateAllサブコマンドは、構成に格納されているグローバルACIのみを移行します。
Oracle Unified Directoryの構成に関連する追加情報の入力を求められます。このコマンドにより、互換性のある構成がOracle Unified Directoryディレクトリ・サーバー上に作成されます。
Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのレプリケーション・ゲートウェイの設定に関する項の説明に従って、レプリケーション・ゲートウェイをインストールして構成します。
この時点で、Oracle Unified Directoryサーバーでレプリケーション用のグローバル管理者を構成する必要があります。このサーバーを後で既存のレプリケート対象Oracle Unified Directoryトポロジに接続する予定の場合は、他のOracle Unified Directoryサーバーで定義されている同じグローバル管理者の資格証明を使用します。
初期化するOracle Unified Directoryサーバーを準備します。例:
$ dsreplication pre-external-initialization -h localhost -p 4444 \ --adminUID admin --adminPasswordFile pwd.txt --baseDN dc=example,dc=com \ -X -n --noPropertiesFile
Oracle Directory Server Enterprise Editionサーバーで、次のコマンドを実行してデータ・セットをエクスポートします:
$ dsadm export -f opends-export dsee-instance-path baseDN exportedLDIFPath
exportedLDIFPathは生成されるLDIFファイルのパスです。このファイルにレプリケート対象データが格納されます。
Oracle Directory Server Enterprise Editionデータに暗号化された属性が含まれている場合は、--decrypt-attrオプションを指定して復号化します。
|
注意:
|
手順2で生成されたLDIFファイルを、Oracle Unified Directoryサーバーがアクセスできるディレクトリにコピーします。LDIFファイルのファイル権限でサーバーによる読取りアクセスが許可されていることを確認します。
Oracle Unified Directoryサーバーで、次のようにLDIFデータをインポートします:
$ import-ldif -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \
--includeBranch dc=example,dc=com --ldifFile path/to/exportedLDIFFile \
--clearBackend --trustAll --noPropertiesFile
LDIFファイルの相対パスを指定する場合、相対パスのルートは現在の作業ディレクトリではなく、インスタンスのルートであることに注意してください。したがって、たとえば、imports/odsee-data.ldifというパスはinstance-root/imports/odsee-data.ldifを指します。
移行時にopends-exportオプションを使用すると、DSEE固有の属性が一部のエントリに存在する場合があり、これらのエントリがインポートされないようにできます。たとえば、nds5replconflictがOracle Directory Server Enterprise Editionのデータに存在する場合があります。そのため、Oracle Unified Directoryへのインポート時に、次のインポート・オプションを使用してこの属性をフィルタする必要があります。
--excludeAttribute "nsds5replconflict"
Oracle Unified Directoryサーバーで初期化後のスクリプトを実行します。例:
$ dsreplication post-external-initialization -h localhost -p 4444 \ --adminUID admin --adminPasswordFile pwd.txt --baseDN dc=example,dc=com \ -X -n --noPropertiesFile
レプリケーションが正常に動作することをテストするために、各Oracle Directory Server Enterprise Editionサーバーで少なくとも1つのエントリを変更し、Oracle Unified Directoryサーバーで変更を確認します。
