32 ディレクトリ・データのレプリケーション
トピック
ノート:
レプリケーション・プロセスのメカニズムの詳細は、「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。
32.1 レプリケーションを構成する前の前提条件について
レプリケーションを構成しようとする前に、前提条件を必ず確認してください。
次の点に注意してください。
-
使用しているデプロイメントでデフォルトのマルチマスター・レプリケーション・モデルが適切かどうか判別します。
マルチマスター・レプリケーション・モデルは、デフォルトではゆるやかな一貫性を持つモデルです。つまり、1つのサーバー上で加えられた変更がトポロジ内の他のサーバーに非同期的にレプリケートされます。このため、同一エントリが別々のサーバーで同時に変更される可能性があります。2つのサーバー間で更新が送信された場合、変更の競合を解決する必要があります。WANの各種属性(待機時間など)によってレプリケーションの競合が発生する可能性が高くなる場合があります。競合の解決は一般に自動的に行われます。優先される変更は、いくつかの競合ルールによって判断されます。場合によっては、競合を手動で解決する必要があります。
ノート:
一部のデプロイメント・シナリオでは、デフォルトのゆるやかな一貫性モデルが不適なことがあります。このような場合は、レプリケーションを保証モードで動作するように構成できます。詳細は、「保証レプリケーションの構成」を参照してください。
-
SSLを有効にする必要があります。レプリケーションは必ず、保護された接続を介して行われます。レプリケーション・セッションの双方のサーバーは、SSL証明書を使用して相手側サーバーに対して認証される必要があります。アクセス制御や権限は強制されません。
-
すべてのディレクトリ・サーバーを同じように構成する場合にのみ、Oracle Unified Directoryの初回インストール時にグラフィカルな設定ユーティリティを使用してレプリケーションを設定できます。
-
setup
コマンドを使用してコマンド行モードでレプリケーションを構成することはできません。setup
コマンドでディレクトリ・サーバーを設定する場合は、dsreplication
コマンドを使用してサーバー間のレプリケーションを構成する必要があります。 -
どのトポロジでも、レプリケーション・サーバーに障害が発生した場合の可用性を確保するために、2つのレプリケーション・サーバーが必要とされます。レプリケーション・サーバーは、環境内で発生したあらゆる変更を追跡する役割を担います。各レプリケーション・サーバーには、トポロジ内の他のレプリケーション・サーバーをすべて列挙したリストが格納されます。
ノート:
レプリケーション・アーキテクチャでは、各レプリケーション・サーバーは、トポロジ内の他のすべてのレプリケーション・サーバーに接続されています。 -
レプリケート対象トポロジでDynamic Host Configuration Protocol (DHCP)を使用する場合、最初の構成後レプリケーション・サーバーのホスト名を変更できません。
-
この項の各例では、すでに2つのディレクトリ・サーバーがインストールされており、その一方にデータが移入されていることを前提としています。2つのディレクトリ・サーバーは同じホスト・マシン上にインストールできますが、その場合は別々のポート番号を割り当てる必要があります。
32.2 dsreplication
によるデータ・レプリケーションの理解
32.2.1 dsreplication
による2つのサーバー間のレプリケーションの理解
dsreplication enable
コマンドのインスタンスを複数実行して、複数のディレクトリ・サーバー間のレプリケーションを設定することはできません。トポロジ内のディレクトリとレプリケーション・サーバーのペアごとにdsreplication enable
コマンドを個別に実行する必要があります。
この項には次のトピックが含まれます:
32.2.1.1 dsreplication
による2つのサーバー間のレプリケーションの有効化
2つのディレクトリ・サーバー間のレプリケーションを有効にするには:
dsreplication enable
コマンドを実行します。
次の構成例では、2つのディレクトリ・サーバー(host1
のディレクトリ・サーバーAとhost2
のディレクトリ・サーバーB)間で"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
オプションは、 レプリケーション・ドメインのグローバル管理者を指します。詳細は、「管理者の管理」を参照してください。-X
オプションは、すべてのサーバー証明書を信頼する必要があることを指定します。-n
(--no-prompt
)オプションは、このコマンドを非対話型モードで実行するように指定します。dsreplication
コマンドの全グローバル・オプションの詳細は、コマンド行でdsreplication -help
と入力してください。
ホストが論理IPが構成されたクラスタノードである場合。異なる論理IPでリスニングする単一のクラスタ・ノードに複数のレプリケーション・サーバーが設定されるように、eplication-listen-addressを構成できます。
デフォルトでは、レプリケーション・サーバーは0.0.0.0:<レプリケーション・ポート>でリスニングします。これにより、同じレプリケーション・ポートを持つ単一のクラスタ・ノードに複数のレプリケーション・サーバーを設定することはできません。
次の構成例では、2つのディレクトリ・サーバー(host1 - logical IP1のディレクトリ・サーバーAとhost1 - logical IP2のディレクトリ・サーバーB)間で"dc=example,dc=com"にあるデータのレプリケーションを有効にします。どちらのディレクトリ・サーバーもデフォルトの管理ポート(4444)を使用します。このコマンドは、host1 - logical IP1のポート8989にレプリケーション・サーバー・インスタンスを1つ作成し、host1 - logical IP2のポート8989にもう1つレプリケーション・サーバー・インスタンスを作成します。
$ dsreplication enable
--host1 host1 --port1 4444 --bindDN1 "cn=Directory Manager" \
--bindPasswordFile1 pwd.txt --listenAddress1 logical-ip1 --replicationPort1 8989
\
--host2 host1 --port2 4444 --bindDN2 "cn=Directory Manager" \
--bindPasswordFile2 pwd.txt --listenAddress2 logical-ip2 --replicationPort2 8989
\
--adminUID admin --adminPasswordFile pwd.txt --baseDN "dc=example,dc=com" -X -n
ホストに構成されたネットワーク・インタフェース(ループバック・アドレスを含まない)が複数ある場合は、--host1
および--host2
に値を指定するときにこれらを指定できます。値を区切るには、カンマを使用します。たとえば:
$ dsreplication enable --host1 interface1,interface2,interface3 --port1 4444 --bindDN1 \ "cn=Directory Manager" \ --bindPasswordFile1 pwd.txt --replicationPort1 8989 \ --host2 host2 --port2 4444 --bindDN2 "cn=Directory Manager" \ --bindPasswordFile2 pwd.txt --replicationPort2 8989 \
新しいディレクトリ・サーバーをレプリケーション・トポロジに追加するには、新しいサーバーの接続情報およびすでにレプリケートされているサーバーの情報を指定してdsreplication enable
を実行します。
既存のレプリケーション・トポロジにレプリカを追加するには、追加する各レプリカに対して、次のコマンドを実行します。
$ 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
ここで、--[parameter]1
では、レプリケーション・トポロジにすでに追加されている既存のレプリカを指定し、--[parameter]2
では追加される新しいレプリカを指定します。
32.2.1.2 レプリケーション・サーバーの作成場所の制御
dsreplication enable
を2つのサーバー間で使用すると、それぞれのホスト上でレプリケーション・サーバーが自動的に構成されます。レプリケーション・サーバーを各ホストに作成することなく、2つのディレクトリ・サーバー間のレプリケーションを構成する必要がある場合があります。--noReplicationServer1
オプションまたは--noReplicationServer2
オプションを使用すれば、追加のレプリケーション・サーバーを作成せずに、ディレクトリ・サーバーをトポロジに追加できます。シングル・ポイント障害を回避するために、レプリケートするトポロジ内にはレプリケーション・サーバーが少なくとも2つ必要であることに注意してください。
また、2つのサーバー間のレプリケーションを有効にし、一方のサーバーにのみレプリケーション・サーバー(ディレクトリ・サーバーではありません)を作成するようにも指定できます。これを実現するには、--onlyReplicationServer1
オプションまたは--onlyReplicationServer2
オプションを使用します。このオプションを指定すると、そのサーバーで変更ログとレプリケーション・ポートが構成されます。そのサーバーには、レプリケートされたデータは格納されません。
32.2.2 dsreplication
によるレプリケート対象サーバーの初期化
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
32.2.3 dsreplication
によるトポロジ全体の初期化
トポロジに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
32.2.4 レプリケート・トポロジのテスト
レプリケーションの動作をテストする最も簡単な方法は、1つのディレクトリ・サーバー上で変更を適用し、その変更が別のディレクトリ・サーバーにレプリケートされたことを確認するという方法です。
前述の手順で設定したレプリケーション・トポロジをテストするには:
ldapmodify
を使用して、host1上のエントリを変更します。ldapsearch
を使用して、その変更がhost2に伝播されていることを確認します。
32.2.5 dsreplication
によるレプリケート・トポロジのステータスの取得
トポロジ内の任意のディレクトリ・サーバーの接続詳細を使用して、トポロジ全体のステータスを取得できます。dsreplication status
コマンドを使用すると、トポロジ内のディレクトリ・サーバーのリストが表示され、サーバー間で未伝播の変更があれば一緒に表示されます。
次のコマンドは、前述の手順で設定したトポロジのステータスを表示します:
$ dsreplication status --adminUID admin --adminPasswordFile pwd.txt -X \ --hostname host1 --port 4444
32.2.6 dsreplication
による既存の2つのレプリケート・トポロジのマージ
2つのレプリケート対象トポロジをマージするには、各トポロジの1つのサーバー同士のレプリケーションを有効にします。
-
2つのレプリケート対象トポロジをマージするには、
dsreplication enable
コマンドを使用します。たとえば、レプリケート対象トポロジ(例: トポロジA)にはhost1、host2およびhost3が属しており、レプリケート対象トポロジ(例: トポロジB)にはhost4、host5およびhost6が属している場合、次のコマンドはこの2つのトポロジを効果的にマージします。
$ dsreplication enable \ --host1
host1
--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
コマンドを使用してレプリケーション・サーバーのリストを更新します。
-
既存の2つのレプリケート・トポロジのマージに関する次の制限事項に注意してください。
-
このマージの実行時には、両方のトポロジ内のサーバーがすべて起動され実行されている必要があります。
いずれかのサーバーがオフラインである場合、
dsreplication
ではその構成を更新できません。マージの実行時にオフラインであったサーバーが再びオンラインになっても、このサーバーにもう一方のトポロジ内のレプリケーション・サーバーへの参照が追加されることはありません。 -
ドメインIDまたはレプリケーション・サーバーIDが2つのトポロジ間で競合している場合は、マージを実行できません。
つまり、トポロジAのサーバーがトポロジBのサーバーと同じレプリケーション・サーバーIDやドメインIDを持つことはできません。
IDが競合している場合は、最初のサーバー(
--host1
)のIDを使用して競合が解消されます。その後、--host1
と同じトポロジに属すサーバーをソースとして使用して、最新の状態でないサーバーをすべて再初期化する必要があります。 -
両方のレプリケーション・トポロジで同一のグローバル管理者が定義されている必要があります。
32.2.7 dsreplication
による特定のレプリケーション・ドメインに対するレプリケーションの無効化
dsreplication disable
コマンドを使用して、特定のレプリケーション・ドメインに対するレプリケーションを無効化できます。
レプリケーション・サーバーの無効化に関するノート
レプリケーション・サーバーを無効にすると、レプリケーション構成が削除されますが、レプリケーション・サーバーのデータベースは削除されません。したがって、レプリケーション・サーバーを誤って無効にしてしまった場合には、レプリケーションの変更記録を取得できます。この接尾辞でのレプリケーションを再度有効にする必要がなければ、レプリケーション・サーバーのデータベースを手動で削除してください(たとえば: $rm changelogDB/*
)。
レプリケーションを無効にして再度有効にした場合、その間にそのサーバーで行われた変更はレプリケートされません。このため、レプリケーションを無効にした期間中はそのサーバーでの変更を禁止するか、変更が発生した場合には、そのサーバーからトポロジ内の残りの各サーバーを再同期する必要があります。
32.3 OUDSMを使用したデータ・レプリケーションの構成
Oracle Unified Directory Services Manager (OUDSM)を使用して実行できるサーバー構成の多くは、「Directory Manager」タブから行います。ただし、レプリケーション構成を管理するには、「Directory Manager」タブまたは「トポロジ・マネージャ」タブのいずれかを使用できます。
-
個別のサーバーやレプリケートされた接尾辞に固有のレプリケーション構成プロパティを表示または構成するには、「Directory Manager」タブを選択します。
-
既存のトポロジの管理または新しいトポロジの作成をレプリケーション構成ウィザードを使用して行うには、「トポロジ・マネージャ」タブを選択します。
この項の内容は次のとおりです。
32.3.1 OUDSMを更新する場合の考慮事項
レプリケーション・トポロジでOUDSMの複数インスタンスを使用している場合は、Oracle Unified Directory Services Manager (OUDSM)の更新の準備を行う際に、次の点を必ず考慮してください。
次の点に注意してください。
-
1つのOUDSMインスタンスを更新する場合は、すべてのOUDSMとレプリケートされたインスタンスを更新する必要があります。
-
OUDSMを更新する場合は、Oracle Unified Directoryも同じバージョンに更新する必要があります。更新されたOUDSMのバージョンが、Oracle Unified Directoryの前のバージョンで動作するかどうかは保証されません。
ノート:
Oracle Unified DirectoryおよびOracle Unified Directory Services Managerの更新の詳細は、『Oracle Unified Directoryのインストール』のOracle WebLogic ServerでのOracle Unified Directory Services Managerの更新に関する項を参照してください。
32.3.2 既存のレプリケーション・サーバーの構成の表示または変更
既存のレプリケーション・サーバーの構成を表示または変更するには、Oracle Unified Directory Services Manager (OUDSM)で「Directory Manager」タブを選択します。
既存のレプリケーション・サーバーを表示または変更するには:
32.3.3 レプリケートされた接尾辞の構成の表示または変更
レプリケートされた接尾辞の構成を表示または変更するには、Oracle Unified Directory Services Managerで「Directory Manager」タブを選択します。
レプリケートされた接尾辞の構成を表示または変更するには:
32.3.4 「Directory Manager」タブでのレプリケーション構成ウィザードについて
新しいトポロジを作成したり、既存のトポロジにサーバーを追加するには、レプリケーション構成ウィザードを起動します。
次の条件のいずれかが真の場合、「Directory Manager」タブからレプリケーション構成ウィザードを起動できます。
-
レプリケーション・トポロジが存在しない。「新しいトポロジの最初からの作成」を参照してください。
-
レプリケーション・トポロジは存在するが、現在のサーバーが追加されていないか、現在のサーバーが部分的にレプリケーション用に構成されているのみである。「既存のトポロジへのサーバーの追加」を参照してください。
32.3.5 「トポロジ・マネージャ」タブからのレプリケーション構成ウィザードへのアクセス
新しいトポロジを作成したり、既存のレプリケーション・トポロジにサーバーを追加するには、レプリケーション構成ウィザードを起動します。
次の条件のいずれかが真の場合、「トポロジ・マネージャ」タブからレプリケーション構成ウィザードを起動できます。
-
レプリケーション・トポロジが存在しない。「新しいトポロジの最初からの作成」を参照してください。
-
レプリケーション・トポロジは存在するが、現在のサーバーがトポロジに追加されていない。「既存のレプリケーション・トポロジの管理」を参照してください。
32.4 大規模なレプリケーション・トポロジの構成の理解
大規模なトポロジにおける専用レプリケーション・サーバーと専用ディレクトリ・サーバーのコンテキストの説明および専用レプリケーション・サーバーの構成方法は、これらのトピックを参照してください。
32.4.1 大規模なレプリケート・トポロジについて
特に大規模なトポロジでは、専用レプリケーション・サーバーと専用ディレクトリ・サーバーを構成する方が簡単な場合が多くあります。
-
ディレクトリ・サーバーを含まない専用ディレクトリ・サーバー。これらにはレプリケート対象データは格納されますが、レプリケート対象データに加えられた変更を記録した変更ログは格納されません。また、専用ディレクトリ・サーバーはレプリケーション・ポートも構成されません。
-
専用レプリケーション・サーバーには、レプリケーション・サーバーまたはレプリケート対象データは格納されませんが、トポロジ内の他のサーバーでレプリケート対象データに加えられた変更を記録した変更ログが格納されます。また、専用レプリケーション・サーバーはレプリケーション・ポートも構成します。
ノート:
シングル・ポイント障害を回避するために、どのトポロジにも少なくとも2つのレプリケーション・サーバーが必要です。
詳細およびサンプル・トポロジは、「ディレクトリ・サーバーを使用するデプロイメント・シナリオの理解」を参照してください。
次の図に、1台の専用レプリケーション・サーバー(レプリケーション・サーバー2)、4台の専用ディレクトリ・サーバー、およびレプリケーション・サーバーとディレクトリ・サーバーを兼ねた1台のサーバー(ホスト1)からなる大規模なレプリケーション・トポロジを示します。
32.4.2 専用レプリケーション・サーバーの構成
専用レプリケーション・サーバーを構成するには、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
32.5 dsconfig
によるレプリケーション構成の変更
dsconfig
コマンドを使用して、レプリケーション構成のいくつかの拡張プロパティを変更できます。通常、拡張プロパティはオプションです。または、ほとんどの場合に適したデフォルト値が割り当てられています。
dsconfig
の使用の一般的な情報は、「dsconfigを使用したサーバー構成の管理」を参照してください。
dsconfig
は、ディレクトリ・サーバー間のレプリケーションの設定には使用できません。レプリケーションの設定は、GUIインストール・ユーティリティを使用して自動的に行うか、dsreplication
コマンドを使用して手動で行います。「OUDSMを使用したデータ・レプリケーションの構成」を参照してください。
この項の内容は次のとおりです。
32.5.1 レプリケーション・ドメイン名の取得
レプリケーション・ドメイン名はディレクトリ・サーバーによって生成されます。この名前にはベース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"
32.5.2 レプリケーション・パージ遅延の構成
レプリケーション変更データベースは、レプリケートが完了した更新またはレプリケートが完了していない更新の記録を保持しています。レプリケーション・パージ遅延はレプリケーション・サーバーのプロパティで、レプリケーション変更データベースに対して内部パージ操作を実行するまでの期間を指定します。
この項の内容は次のとおりです。
32.5.2.1 レプリケーション変更記録のパージ動作
パージ遅延の期間を過ぎた変更記録は、すでに適用されたかどうかに関係なく、レプリケーション変更データベースから削除されます。デフォルトのパージ遅延は100時間です。レプリケーション変更データベースのバックアップ間隔がこのパージ遅延の期間より短いと、変更データベースがバックアップされる前に変更記録がクリアされてしまいます。したがって、バックアップからデータをリストアしても、変更記録が失われる可能性があります。
32.5.3 ウィンドウ・サイズの構成
ウィンドウ・サイズはレプリケーション・サーバーのプロパティで、レプリケーション・サーバーがディレクトリ・サーバーからの確認応答を待たずにディレクトリ・サーバーに送信できる変更リクエストの数を指定します。
この項の内容は次のとおりです。
32.5.3.1 ウィンドウ・サイズについて
ウィンドウ・サイズは、ディレクトリ・サーバーからの即時の確認応答なしに送信できる更新メッセージの最大数を表します。各メッセージ後の確認応答を待たずに、素早く連続して多くのメッセージを送信する方が効率的です。適切なウィンドウ・サイズを使用することで、レプリケーション・サーバーが確認応答の到着を待つために費やす時間を排除できます。デフォルトのウィンドウ・サイズは100です。一部のディレクトリ・サーバーで変更のレプリケーションが遅れていることに気付いた場合は、他の調整を行う前に、ウィンドウ・サイズの値を大きくしてレプリケーション・パフォーマンスをもう一度確認してください。
32.5.4 初期化ウィンドウ・サイズの構成
レプリケート対象トポロジ内でのデータ・インポート時に、インポート側のサーバーが遅すぎてエクスポート側のサーバーから送信されるデータについていけないことがあります。このような場合、インポート側サーバーはインポートを妨げるだけでなく、エクスポート側サーバーによる他のレプリケーション変更記録の伝播まで妨げるおそれがあります。
この項の内容は次のとおりです。
32.5.4.1 初期化ウィンドウ・サイズについて
初期化ウィンドウ・サイズを使用することで、エクスポート側サーバーは最も遅いインポート側サーバーからの確認応答を検出し、その遅いインポート側サーバーが受信可能な状態のときのみデータをレプリケーション・ネットワーク上に送信することが可能になります。
デフォルトでは、初期化ウィンドウ・サイズは100
です。トポロジ内に遅いサーバーがない場合は、初期化ウィンドウ・サイズを大きくできます。これにより、エクスポート側サーバーがより多くの更新を、確認応答を待たずに送信できるようになります。トポロジ内に非常に遅いサーバーがある場合は、初期化ウィンドウ・サイズを小さくすることで、そのサーバーがレプリケーションを妨げないようにできます。
32.5.5 ハートビート間隔の構成
ハートビート間隔はレプリケーション・ドメインのプロパティで、レプリケーション・ドメインがレプリケーション・サーバーと通信する間隔を指定します。レプリケーション・ドメインは、レプリケーション・サーバーからこの間隔で定期的にハートビートが届くのを待ちます。ハートビートが受信されない場合、ドメインはその接続を閉じ、トポロジ内の別のレプリケーション・サーバーに接続します。
この項の内容は次のとおりです。
32.5.5.1 ハートビート間隔について
デフォルトのハートビート間隔は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 Unified Directoryのインストール』のJVM、Javaオプションおよびデータベース・キャッシュの構成に関する項を参照してください。
32.5.6 分離ポリシーの変更
分離ポリシーはレプリケーション・ドメインのプロパティです。このプロパティは、レプリケーションが構成されているのに、更新の受信時にレプリケーション・サーバーが1つも起動および実行されていない場合のディレクトリ・サーバーの動作を指定します。この場合のディレクトリ・サーバーのデフォルト動作は、すべての更新を拒否するというものです。
分離ポリシーを変更するには:
32.5.7 暗号化レプリケーションの構成
デフォルトでは、レプリケーションの通信は暗号化されません。暗号化を有効にするには、dsconfig
コマンドを使用して暗号化マネージャのプロパティを設定します。
次のコマンドは、レプリケーションの通信を暗号化するように指定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-crypto-manager-prop --set ssl-encryption:true
32.5.8 レプリケーション・グループの構成
レプリケーション・グループに関するコンテキストに応じた説明と、レプリケーション・グループを構成する手順は、これらのトピックを参照してください。
32.5.8.1 レプリケーション・グループについて
レプリケーション・グループは、マルチデータ・センター・デプロイメントおよび障害回復シナリオをサポートする場合に設計します。
レプリケーション・グループの構成は、同じグループに所属させる個々のディレクトリ・サーバーおよびレプリケーション・サーバーで行います。ディレクトリ・サーバーでは、レプリケート対象ドメインごとにレプリケーション・グループを構成します。レプリケーション・サーバーでは、レプリケーション・サーバー全体に対してグループを構成します。ディレクトリ・サーバーにおけるレプリケーション・グループの設計と実装の詳細は、「レプリケーション・グループについて」を参照してください。
ノート:
レプリケーション・グループの構成を変更すると、保証レプリケーションに影響します。詳細は、「保証レプリケーションの理解」を参照してください。
32.5.9 保証レプリケーションの構成
保証レプリケーションは、通常のレプリケーションの動作の同期性を高める方法です。
この項の内容は次のとおりです。
32.5.9.1 保証レプリケーション構成について
ほとんどのデプロイメント・シナリオでは、ゆるやかな一貫性を持つマルチマスター・レプリケーション・モデルで十分です。しかし、シナリオによっては、レプリカ間のより厳格な一貫性が必要とされる場合もあります。このような場合は、保証レプリケーションを構成できます。保証レプリケーションには、次の利点があります:
-
データの高可用性。サーバーが変更を受信した直後にクラッシュした場合、変更がトポロジ内の他のサーバーにレプリケートされる前に失われるおそれがあります。保証レプリケーションでは、確認応答がクライアント・アプリケーションへ送信される前に、変更がトポロジ内の他のサーバーにリプレイされ、サーバーがクラッシュした場合にデータを失うリスクが最小限になります。
-
即時のデータ可用性。アプリケーションによっては、変更が行われた直後にその変更がトポロジ内の他のサーバーで使用できるようになることが必要な場合があります。
保証レプリケーションはレプリケーション・プロトコルの拡張であり、レプリケート対象ドメイン単位で構成されます。詳細は、「レプリケーション・ドメイン名の取得」を参照してください。
保証レプリケーションは、同期レプリケーションとは異なります。つまり、トポロジ内のすべてのサーバーで同時に変更が行われるわけではありません。ただし、LDAPクライアントに関するかぎり、保証レプリケーションは同期レプリケーションの機能をある程度まで模倣します。変更がトポロジ内の他のサーバーに伝播されるまで、クライアント・アプリケーションへの確認応答を遅らせることによって、これを実現しています。
ノート:
保証レプリケーションは、レプリケーション・グループに依存しています。1つの保証レプリケーション構成で連動するすべてのレプリケーション・サーバーおよびディレクトリ・サーバーが同じレプリケーション・グループに属している必要があります。
保証レプリケーションには次の2つの動作モードがあります:
-
セーフ・データ・モード。更新が正常に完了したという確認応答をクライアントが受信する前に、定義した数のレプリケーション・サーバーへ更新を伝播させる必要があります。
伝播が必須であるレプリケーション・サーバーの数によって安全データ・レベルが既定されます。安全データ・レベルが高ければ高いほど、全体のデータ可用性が高まります。
-
セーフ読取りモード。更新が正常に完了したという確認応答をクライアントが受信する前に、トポロジ内のすべてのディレクトリ・サーバーへ更新を伝播させる必要があります。
安全データ・モードでも安全読取りモードでも、トポロジ内のいくつかのサーバーが使用不可である場合にLDAPクライアント・コールがハングしないように、タイムアウト間隔を設定できます。
-
各ディレクトリ・サーバーでは、ディレクトリ・サーバーがレプリケーション・サーバーに安全データ・モードまたは安全読取りモードで更新を送信すると有効になるグローバル・タイムアウトを構成できます。このタイムアウトに達すると、LDAPクライアント・コールは即座に復帰し、このイベントを追跡するためのメッセージがレプリケーション・ログに書き込まれます。
-
各レプリケーション・サーバーでは、レプリケーション・サーバーがピアのレプリケーション・サーバーまたは別のディレクトリ・サーバーに安全データ・モードまたは安全読取りモードで更新を送信すると有効になるグローバル・タイムアウトを構成できます。このタイムアウトに達すると、開始サーバー(ディレクトリ・サーバーまたはレプリケーション・サーバー)に返される確認応答メッセージに、タイムアウトを示すメッセージが挿入されます。すると、開始ディレクトリ・サーバーは、その更新に対してタイムアウトが発生したというメッセージをログに書き込みます。
ノート:
ほとんどのデプロイメントでは、デフォルトのタイムアウトで問題ありません。ディレクトリ・サーバーは2秒、レプリケーション・サーバーは1秒です。タイムアウトを変更するのは、ログにタイムアウトが記録されており、かつタイムアウトの変更が及ぼす影響を完全に理解している場合のみです。更新がフル・パスを経由して目的のサーバーに届くまでにかかる時間を見越して、タイムアウト値に反映させる必要があります。
ディレクトリ・サーバーのタイムアウト値は、レプリケーション・サーバーの値より必ず大きくしてください。たとえば: DS1(タイムアウト2秒)→RS1(タイムアウト1秒)→RS2(タイムアウト1秒)→DS2
保証レプリケーションのメカニズムと様々な構成オプションの詳細は、「保証レプリケーションの理解」を参照してください。
32.5.9.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-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を構成する手順は、「レプリケーション・グループの構成」を参照してください。
-
保証レプリケーションの現在の構成を表示します。
$ 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を構成する手順は、「レプリケーション・グループの構成」を参照してください
-
32.5.9.3 セーフ読取りモードの保証レプリケーションの構成
保証レプリケーションは、レプリケート対象ドメインごとに構成します。この手順では、トポロジに対して安全読取りモードの保証レプリケーションを構成します。ここでは、レプリケーションがすでに構成されていることを前提としています。
-
トポロジ内の各ディレクトリ・サーバーで次の操作を行います:
-
保証レプリケーションのモードを設定します。
$ 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を構成する手順は、「レプリケーション・グループの構成」を参照してください。グループと保証レプリケーションの詳細は、「保証レプリケーションの理解」を参照してください。
-
保証レプリケーションの現在の構成を表示します。
$ 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
-
機能低下ステータスのしきい値を設定します。
機能低下ステータスのしきい値では、そのディレクトリ・サーバーに対するレプリケーション・サーバーのキューに入っている更新の数に基づいて、サーバーを「遅すぎる」と判断する段階を定義します。詳細は、「低下ステータスとは」を参照してください。
ログにタイムアウトが記録されていないかぎり、この値は調整しないでください。
$ 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を構成する手順は、「レプリケーション・グループの構成」を参照してください。グループと保証レプリケーションの詳細は、「保証レプリケーションの理解」を参照してください。
-
32.5.10 部分レプリケーションの構成
次のトピックでは、トポロジ内の1つ以上のサーバーで部分レプリケーションを構成する手順について説明します。
部分レプリケーション・メカニズムのアーキテクチャの詳細は、「部分レプリケーションの概要」を参照してください。
32.5.10.1 部分レプリケーション構成について
部分レプリケーションでは、ディレクトリ・データの特定部分をトポロジ内の他のレプリカにレプリケートできます。この機能は、次のシナリオで特に有効です:
-
ディスク領域が限られている場合。レプリケートするデータを限定することで、特定のレプリカで必要とされるディスク領域の量を大幅に低減できます。特に、データ量が大きいjpeg写真などの属性のレプリケーションを制限すると効果的です。
-
セキュリティ上の問題。ユーザー・パスワードなどのデータは機密性が高く、一部のレプリカでは不要なことがあります。特に、それらのレプリカで不正アクセスの危険性があるような場合です。
部分レプリケーションの構成は、部分データを受け取るディレクトリ・サーバー上で、属性ベースで行います。次の図を参照してください:
ディレクトリ・サーバーBで部分レプリケーションが構成されています。ldapmodify
操作がディレクトリ・サーバーAに送信されます。この操作全体がレプリケーション・サーバー1、レプリケーション・サーバー2、ディレクトリ・サーバーBの順に転送されていきます。この操作がディレクトリ・サーバーBでレプリケートされるとき、このサーバーの部分レプリケーション構成に基づいて、操作の一部の属性が排除されます。
部分レプリカは、クライアント・アプリケーションから直接書込み可能です。ただし、禁止された属性を含む追加操作や変更操作が部分レプリカに対して試行された場合、その操作は拒否され、サーバーが「実行要求を拒否」エラーを返します。
部分レプリケーションは、次の2つのうちいずれかのモードで構成できます。
-
排他モード。このモードでは、
fractional-exclude
という複数値属性を使用して指定した属性を、受信したLDAP追加操作または変更操作から排除します。除外する属性は、オブジェクト・クラスのオプション属性であることが必要です。
-
包含モード。このモードでは、
fractional-include
という複数値属性を使用して指定した属性のみを、受信したLDAP追加操作または変更操作から受け入れます。その他の属性はすべて(オブジェクト・クラスの必須属性を除き)、サーバー上でレプリケートされる変更から削除されます。
この2つのモードは同時には使用できません。つまり、どちらか一方のモードの属性のみをドメイン構成に追加できます。
部分レプリケーションはレプリケート対象ドメイン単位で構成します(「レプリケーション・ドメイン名の取得」を参照)。部分ドメインは、特定の属性がそのドメインにまったく存在しないことを意味します。これらの属性は操作のリプレイ時に排除されるだけでなく、ドメインの既存データ自体にも存在しません。
レプリケート対象トポロジ全体でデータの一貫性を確保するためには、特定のデータ・セットが部分的であるかどうかを判断する必要があります。したがって、新しい部分ドメインを構成する作業には、そのドメインに禁止の属性が存在しないことと、そのドメインが部分ドメインとして認識可能であることを確認するステップが伴います。詳細は、「部分ドメインの構成および初期化」を参照してください。
ドメインの部分レプリケーションを構成するには、次のようにdsconfig
コマンドを使用します。
32.5.10.2 排他部分レプリケーションの構成
次の例では、オブジェクト・クラスが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
32.5.10.3 包含部分レプリケーションの構成
次の例では、オブジェクト・クラスが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
32.5.11 レプリケーション・ステータスの構成
レプリケート対象トポロジ内の各レプリケート対象ドメインには、トポロジ内での接続状態や、トポロジ内で発生した変更の反映状況に応じて特定のレプリケーション・ステータスが設定されます。
詳細は、「レプリケーション・ステータスの概要」を参照してください。
この項の内容は次のとおりです。
32.5.11.1 レプリケーション・ステータスにある低下ステータスのしきい値パラメータの構成について
レプリケーション・ステータスは、サーバーがレプリケート対象トポロジ内でどの程度最新の状態に保たれているかに応じて自動的に生成されます。構成可能なパラメータは機能低下ステータスしきい値のみです。これは、このレプリケーション・サーバーに接続されているディレクトリ・サーバーのすべてのドメインに対してレプリケーション・サーバーのキューで許容される変更の最大数を定義します。特定のディレクトリ・サーバーに対してこの数に達すると、そのサーバーに機能低下ステータスが割り当てられます。機能低下ステータスは、変更数がこの値を下回るまで維持されます。
ノート:
機能低下ステータスしきい値のデフォルト値は、ほとんどのデプロイメントに適しています。保証レプリケーションが構成されている場合で、ログに複数のタイムアウト・メッセージが記録されているときのみ、この値を変更します。
32.5.11.2 低下ステータスのしきい値の構成
このしきい値で定義されているデフォルトの変更数は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
32.5.12 レプリケーション・サーバーの重みの構成
複数のディレクトリ・サーバーと複数のレプリケーション・サーバーからなる大規模なトポロジでは、あらかじめ定義された方法でディレクトリ・サーバーをレプリケーション・サーバーに分散させた方が効率的です。
トポロジ内の各レプリケーション・サーバーに接続するディレクトリ・サーバーの数を、レプリケーション・サーバーが稼働しているマシンの相対的な能力に応じて指定できます。詳細は、「レプリケーション・サーバーのロード・バランシングの理解」を参照してください。
レプリケーション・サーバーの重みを構成するには、次のように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です。
32.6 データによるレプリケート対象サーバーの初期化
gicadm
コマンドを使用することで、レプリケート対象サーバーを初期化できます。このコマンドでは、SSL経由で管理コネクタを介してサーバー構成にアクセスします。
次のトピックでは、レプリケート対象サーバーをデータで初期化する方法について説明します。
ノート:
詳細は、「サーバーへの管理トラフィックの管理」および「gicadm」を参照してください。
また、この項では、「スタンドアロン・ディレクトリ・サーバーへのデータの移入」に記載されている情報を参照します。先に進む前に、この項を参照してください。
32.6.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
32.6.2 新しいレプリケート対象トポロジの初期化
新しいレプリケート・トポロジでは、単一のディレクトリ・サーバーまたはすべてのディレクトリ・サーバーを同じデータで個別に初期化できます。
-
「スタンドアロン・ディレクトリ・サーバーへのデータの移入」で説明されているいずれかの方法を使用して、すべてのディレクトリ・サーバーを同じデータで個別に初期化します。すべてのディレクトリ・サーバーをデータで初期化したら、サーバー間のレプリケーションを有効にします。
-
「スタンドアロン・ディレクトリ・サーバーへのデータの移入」で説明されているいずれかの方法を使用して、単一のディレクトリ・サーバーを初期化します。すべてのディレクトリ・サーバーに対してレプリケーションを有効にし、
dsreplication intialize-all
コマンドを使用して残りのすべてのサーバーを同時に初期化します。このコマンドはソース・サーバーの詳細を引数としてとり、レプリケーションが有効になっている他のすべてのサーバーを初期化します。たとえば、次のコマンドはすべてのディレクトリ・サーバーを
host1
上のコンテンツで初期化します。$ dsreplication initialize-all --hostname localhost --port 4444 --trustAll \ --baseDN "dc=example,dc=com" --adminUID admin --adminPasswordFile pwd.txt
32.6.3 既存のレプリケート対象トポロジへのディレクトリ・サーバーの追加
既存のレプリケート対象トポロジにディレクトリ・サーバーを追加する場合、トポロジ内の既存のディレクトリ・サーバーと同じデータ生成を新しいサーバーに移入する必要があります。データ生成とは、レプリケーション・ドメインのルート・エントリに格納されているIDです。データ生成が存在しない場合、レプリケーション・メカニズムによってデータ生成が計算され格納されます。
新しいディレクトリ・サーバーがトポロジ内の他のサーバーと同じデータ生成を保持するようにするには、次のいずれかの方法でディレクトリ・サーバーにデータを移入します:
-
他のディレクトリ・サーバーの移入に使用した同じオリジナルLDIFファイル、バックアップ・ファイルまたはバイナリ・コピーを使用します。
-
トポロジ内の別のディレクトリ・サーバーからのエクスポート、バックアップまたはバイナリ・コピーを使用します。
GUIインストールを使用して新しいディレクトリ・サーバーをインストールする場合は、そのサーバーをレプリケート対象トポロジのメンバーにすることを指定すれば、自動的に適切なデータ生成を使用してサーバーが初期化されます。
GUIインストールを使用せずにディレクトリ・サーバーをインストールし、dsreplication
コマンドを使用してレプリケーションを有効にする場合は、前述の項で説明したいずれかの方法により手動でサーバーを初期化する必要があります。
トポロジ内のディレクトリ・サーバーにトポロジ内の他のサーバーと同じデータ生成が格納されていない場合、そのディレクトリ・サーバーとのデータ・レプリケーションはできません。ただし、そのディレクトリ・サーバーもトポロジとの接続は維持されており、レプリケーション・プロトコルによる初期化が可能です。このディレクトリ・サーバー上のレプリケーションは、ダウングレードした状態にあるといいます。
適切なデータ生成を持つディレクトリ・サーバーが既存のトポロジに追加されると、トポロジ内の最初のディレクトリ・サーバーがデータで初期化された時点以降に発生したすべての変更がレプリケーション・メカニズムによって自動的にリプレイされます。この動作より、新しいディレクトリ・サーバーがトポロジ内の他のサーバーと確実に同期されます。
32.6.4 既存のレプリケート対象トポロジにあるデータ・セットの変更
データ・セットを変更するには、完全に新規のデータ・セットをトポロジ内のすべてのディレクトリ・サーバーにインポートします。
データ・セットが変更される際、2つのタスクが実行されます:
-
新しいデータがトポロジ内の各ディレクトリ・サーバーに適用されます。
-
レプリケーション・サーバーに格納されている変更がすべてクリアされます。このタスクには、各ディレクトリ・サーバー上のデータ生成をリセットして新しいデータ生成が使用されるようにする操作も含まれます。
dsreplication initialize
コマンドを使用してデータ・セットを変更すると、これらのタスクの両方が自動的に実行されます。ただし、import-ldif
コマンドまたはバイナリ・コピー方式でデータ・セットを変更する場合は、これらのタスクを手動で行う必要があります。
import-ldif
、バイナリ・コピーまたはrestore
を使用してデータ・セットを変更するには、次のようにします。
32.6.5 既存のレプリケート対象トポロジへのデータの追加
すでに大量のエントリが含まれている既存のレプリケート対象トポロジに大量のエントリをインポートする最も簡単な方法は、import-ldif
コマンドに-a
オプションまたは--append
オプションを指定して使用する方法です。
import-ldif
コマンドを使用してデータをインポートする場合、レプリケート対象データが自動的にはレプリケートされません。このため、import-ldif --append
をトポロジ内のすべてのディレクトリ・サーバーで実行する必要があります。この戦略では、ディレクトリ・サービスを停止せずにデータをインポートできます。
また、トポロジ内の単一のディレクトリ・サーバーにデータをインポートしてから、dsreplication initialize-all
コマンドを使用することもできます。ただし、この戦略ではディレクトリ・サービスが一定期間、使用不可になります。
32.7 外部変更ログの使用
外部変更ログ(ECL)は、ディレクトリ・サーバー・データベース内で発生したすべての変更を公開します。特に、LDAPディレクトリを他のサブシステムと同期させる場合に便利です。
外部変更ログはレプリケーション変更ログからオンラインで構築され、その保管に追加のデータベースは使用されません。通常のJEBバックエンドではないため、索引の構成は不要です。
次のトピックでは、ディレクトリ・サービスで外部変更ログを有効にする方法と、外部変更ログにアクセスできるようにクライアント・アプリケーションを構成する方法について説明します。
32.7.1 外部変更ログの有効化
ディレクトリ・サーバーとレプリケーション・サーバーの両方を含むすべてのサーバー・インスタンスでは、外部変更ログ(ECL)がデフォルトで使用できます。外部変更ログは、ディレクトリ・サーバーがインストール時にレプリケート・トポロジの一部として構成されるか、またはレプリケーションがインストール後に構成された場合に有効化されます。
専用ディレクトリサーバーまたは専用レプリケーション・サーバーのいずれかとして構成されたサーバー・インスタンスでは、外部変更ログがデフォルトでは使用できません(「大規模なレプリケーション・トポロジの構成の理解」を参照)。
次のいずれかの方法でレプリケーションを構成すると、外部変更ログが有効になります:
-
インストール時にレプリケート対象トポロジのメンバーとしてディレクトリ・サーバーを構成する方法。詳細は、『Oracle Unified Directoryのインストール』のインストール時のレプリケーションの設定に関する項を参照してください。
-
インストール後に
dsreplication
コマンドを使用してレプリケーションを構成する方法。詳細は、「OUDSMを使用したデータ・レプリケーションの構成」を参照してください。ノート:
--onlyReplicationServer
オプションまたは--noReplicationServer
オプションを指定してレプリケーションを構成した場合は、外部変更ログが使用できません。
外部変更ログの機能はレプリケーション・メカニズムに基づいていますが、クライアント・アプリケーションによっては、レプリケート対象トポロジの外側のローカル・サーバー上にある外部変更ログ・コンテンツを必要とするものもあります。ローカル・サーバーで特定のベース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
32.7.2 外部変更ログのAPIについて
外部変更ログは、2つの個別の操作モードを有効にする2つのAPIをサポートしています。
2つの個別の操作モードは、次のとおりです。
-
Cookieモード。外部変更ログへのアクセスには、このAPIを使用することをお薦めします。
Cookieモードでは、クライアント・アプリケーションがサーバーへのリクエストで外部変更ログの交換制御を提供します。このモードでは、サーバーから返されるエントリ内のDITとスキーマは、LDAP変更ログ・ドラフト(
http://tools.ietf.org/html/draft-good-ldap-changelog-04
)と互換性がありません。 -
ドラフト互換モード。このモードは、LDAP変更ログ・ドラフトに依存する既存のアプリケーションでのみ使用してください。
このモードでは、サーバーから返されるエントリ内のDITとスキーマは、LDAP変更ログ・ドラフトと互換性があります。
パフォーマンスの向上および簡素化のために、クライアント・アプリケーションを移植してCookieモードを使用してください。詳細は、「他の変更ログに依存するアプリケーションの移植」を参照してください。
32.7.3 クライアント・アプリケーションがCookieモードで外部変更ログを使用する際の動作
外部変更ログのエントリには、それぞれ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の値より新しいとサーバーが判断した場合も、リクエストは却下されます。この場合、外部アプリケーションの完全な再同期を推奨する追加情報が返されます。
ノート:
サーバーがレプリケーション・トポロジから切断され、接続中のクライアントからの変更を処理した場合は、収束を保証できません。
次のリクエストとレスポンスの例で、クライアント・アプリケーションがどのように外部変更ログを使用して検索し、どのように外部変更ログが応答するかを示します。
- リクエスト1
-
外部変更ログの読取りを開始するために、クライアントが
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=*)" "*" +
- レスポンス1
-
サーバーが各変更を
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
- リクエスト2
-
最後に返されたエントリから外部変更ログを読み取るために、クライアントが
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=*)"
ノート:
外部変更ログのコンテンツはBase64でエンコードされています。コンテンツのデコードの詳細は、「base64」を参照してください。
32.7.4 外部変更ログ・エントリの形式
外部変更ログで返されるエントリの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
32.7.5 外部変更ログに含める属性の指定
デフォルトでは、外部変更ログに含まれる属性は、変更操作の影響を受ける属性のみです。したがって、たとえば、エントリのsn
属性が変更される場合、その属性のみが外部変更ログに記述されます。ただし、変更操作の影響を受けるかどうかに関係なく、外部変更ログに含める属性のリストを指定できます。また、この属性リストをすべての種類の操作に対して含めるか、削除操作に対してのみ含めるかも指定できます。
ecl-include
プロパティまたはecl-include-del-only
プロパティを使用して、属性を構成できます。これらのプロパティを使用して属性を構成する手順は、次の項を参照してください。
32.7.5.1 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
属性の値です。
32.7.5.2 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
32.7.6 外部変更ログから除外する属性の指定
外部変更ログを使用するクライアント・アプリケーションは必ずしも、サーバーで実行されたすべてのLDAP操作に関心があるわけではありません。このため、無関連の情報の処理を避けるために、属性のリストをフィルタリングできます。
ecl-blacklist
プロパティを使用すると、外部変更ログから除外する属性を構成できます。すべての変更がブラックリスト対象属性に該当する場合のみ、クライアント・アプリケーションへ送信される変更操作がスキップされます。
ノート:
ブラックリスト・メカニズムを使用するには、Cookieモードを使用する必要があります。blacklistプロパティを構成すると、Cookieモードなしではcn=changelog
にアクセスできなくなります。
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
32.7.7 外部変更ログを使用するクライアント・アプリケーションの初期化
クライアント・アプリケーションでは、外部変更ログを使用するための特定のサーバー構成は必要ありません。ただし、外部変更ログを使用する必要があるクライアント・アプリケーションを初期化する必要があります。
ノート:
外部変更ログを使用するクライアント・アプリケーションを初期化および再初期化する際は、lastExternalChangelogCookie
属性を使用します。lastExternalChangelogCookie
属性には、変更ログからの変更を検索するために必要な情報を含むCookieが含まれます。Oracle Unified Directoryでは、遅延しているサーバーについてトポロジ内の外部変更ログの変更の時系列順が統合されます。ただし、例外的なシナリオでは、外部変更ログの変更が適切な時系列順で伝播されない場合があることに注意する必要があります。
32.7.7.1 外部変更ログを使用するクライアント・アプリケーションの初期化
次の例で、ホスト2をホスト1から初期化するシナリオを示します。ホスト1は初期化操作中も固定されず、変更を受信し続けます。次の手順により、ホスト1で受信された変更がホスト2に漏れなく反映されることが保証されます。
32.7.7.2 ドメイン追加時のクライアント・アプリケーションの再初期化
新しいレプリケーション・ドメインをトポロジに追加すると、そのドメインで外部変更ログがデフォルトで有効になります。外部変更ログを使用するクライアント・アプリケーションを、その新規ドメインに対して再初期化する必要があります。
サーバーでは、提供されたCookieが新規ドメインを参照していなければ検索操作を拒否することによって、この要件を強制します。その操作結果コードは「実行要求を拒否」
です。サーバーは、欠けているドメインのリストと部分的初期化用のCookie値を含む詳細メッセージを提供します。
次のいずれかの方法でクライアント・アプリケーションを再初期化する必要があります:
-
完全な再初期化。アプリケーションをすべてのドメインに対して再初期化します。
-
lastExternalChangelogCookie
属性の値を読み取ります。この値は、新規ドメインを含む、トポロジ内の全ドメインを参照しています。 -
新規ドメインを含む全ドメインを対象にデータベースをエクスポートします。
-
エクスポートの出力を使用してアプリケーションを全ドメインに対して初期化します。詳細は、「外部変更ログを使用するクライアント・アプリケーションの初期化」を参照してください。
-
これで、アプリケーションは
last_cookie_from_dse_root
を使用して外部変更ログを検索できるようになりました。
-
-
部分的再初期化。アプリケーションを新規ドメインに対してのみ再初期化します。
-
新規ドメインのみを対象にデータベースをエクスポートします。
-
エクスポートの出力を使用してアプリケーションを初期化します。エクスポートの出力には、新規ドメイン内のエントリのみが格納されています。詳細は、「外部変更ログを使用するクライアント・アプリケーションの初期化」を参照してください。
-
これで、アプリケーションは、
「実行要求を拒否」
エラーでサーバーから返された部分的初期化用のCookie値を使用して、外部変更ログを検索できるようになりました。ノート:
その結果として、すでに処理が完了している一部の更新がリプレイされることがありますが、これはCookie値がデータベースの初期状態を示しているためです。
-
ノート:
ドラフト互換モードのドラフトAPIでは、アプリケーションが適切に初期化されるようにサーバーが強制することはできません。したがって、ドラフト互換モードでは、新規ドメインが追加されると同時に、そのサーバーにおける変更が外部変更ログに公開されます。
サーバーが新規ドメインに関する変更を公開しないようにするには、「特定のドメインに対する外部変更ログの無効化」を参照してください。特定のドメインに対する変更のみがアプリケーションに通知されるようにするには、そのドメインをベースDNで指定するか(Cookieモードの場合のみ)、targetDN
属性の検索フィルタとして指定します。
32.7.7.3 ドメインの削除時または無効化時のクライアント・アプリケーションの再初期化
レプリケーション・ドメインをトポロジから削除したら(または、外部変更ログを特定のドメインに対して無効にしたら)、以後そのドメインでは変更が発生しないことをクライアント・アプリケーションに通知する必要があります。
サーバーでは、提供されたCookieが、削除されたドメインを参照していれば検索操作を拒否することによって、この要件を強制します。その操作結果コードは「実行要求を拒否」
です。サーバーは、Cookieにあるドメインで削除されたもの(または外部変更ログが無効化されたもの)のリストと継続用のCookie値を含む詳細メッセージを提供します。
クライアント・アプリケーションでは、削除されたドメインを次のいずれかの方法で処理できます:
-
円滑な継続。この場合、アプリケーションはドメインの削除時の処理に関する独自のポリシーを適用できます。このポリシーの作成を支援するために、アプリケーションでは、サーバーからエラー・メッセージで返された継続用のCookie値を提供して外部変更ログを検索できます。
-
完全な再初期化。アプリケーションをすべてのドメインに対して再初期化します。
-
lastExternalChangelogCookie
属性の値を読み取ります。この値は、削除されたドメインを除く、トポロジ内の全ドメインを参照しています。 -
全ドメインを対象にデータベースをエクスポートします。
-
エクスポートの出力を使用してアプリケーションを全ドメインに対して初期化します。詳細は、「外部変更ログを使用するクライアント・アプリケーションの初期化」を参照してください。
-
これで、アプリケーションは
lastExternalChangelogCookie
を使用して外部変更ログを検索できるようになりました。
-
32.7.8 外部変更ログへのアクセスの制御
ECLへのアクセスはグローバルACIで規定されます。これはサーバーで構成できます。デフォルトでは、rootユーザーのみが外部変更ログにアクセスできます。
グローバルACIの構成の詳細は、「dsconfigを使用したグローバルACIの管理」を参照してください。
32.7.9 外部変更ログのパージ
外部変更ログは、レプリケーション変更ログとともにパージされます。
レプリケーション変更ログのパージ間隔の変更の詳細は、「レプリケーション・パージ遅延の構成」を参照してください。
アプリケーションがサーバーに保存されている最も古い変更よりも古いCookie値を指定して、外部変更ログに対する検索リクエストを送信する場合があります。これは、そのアプリケーションからの前回のリクエスト以降にパージが実行されたためです。この場合、サーバーはリクエストを却下し、Cookieが古いことと完全な再同期が必要であることを示します。
32.7.10 サーバーでの外部変更ログの無効化
dsreplication disable-changelog
コマンドを使用し、特定のベースDNについてサーバー上の外部変更ログを無効化します。
$ dsreplication disable-changelog -h localhost -p 4444 -D "cn=directory manager" \ -j pwd-file -b dc=example,dc=com -X -n
32.7.11 特定のドメインに対する外部変更ログの無効化
特定のドメインにおける変更を外部変更ログから除外する必要がある場合があります。特定のレプリケーション・ドメインについて外部変更ログを無効にできます。無効にすると、そのドメインに対する変更が外部変更ログに公開されなくなります。
32.7.12 最後の変更番号の取得
ldapsearch
コマンドを使用して、サーバー上の最後の変更番号属性を取得します。
ノート:
「外部変更ログの有効化」の説明に従って、外部変更ログが有効になっているかどうかを確認します。
次のコマンドを実行します。
./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
32.7.13 他の変更ログに依存するアプリケーションの移植
外部変更ログは、LDAP変更ログ・ドラフトに基づいていますが、この変更ログを厳密にはサポートしていません。LDAP変更ログ・ドラフトでは、変更ログを閲覧するためのキーとして整数を使用するのに対し、外部変更ログではCookieを使用します。
LDAP変更ログ・ドラフトの詳細は、http://tools.ietf.org/html/draft-good-ldap-changelog-04
を参照してください。
クライアント側では、Cookieメカニズムには次の利点があります:
-
外部変更ログ・インスタンス間のフェイルオーバーが可能。
-
複数の外部変更ログ・インスタンス間での負荷分散リクエストが可能。
サーバー側では、Cookieメカニズムには次の利点があります:
-
マルチマスター環境における実装が容易になる
-
サーバーで必要とされるリソースが少なくなる
-
変更を生成する他のアプリケーションに対するパフォーマンスの影響が小さくなる
ノート:
Oracle Directory Server Enterprise Edition (ODSEE)のレトロ変更ログ(RCL)はLDAP変更ログ・ドラフトをサポートしており、固有の追加がいくつかあります。
この節では、以下のトピックについて説明します。
32.7.13.1 外部変更ログとLDAP変更ログ・ドラフトの相違点の理解
次のトピックでは、2つの変更ログの相違点について説明します。これは、クライアント・アプリケーションを移植するときに役立ちます。
32.7.13.1.1 索引の相違点について
LDAP変更ログ・ドラフトでは、変更ログ索引を整数として指定します(changenumber
属性)。この形式は、変更ログ・サービスが単一のサーバーによって提供される場合には効果的です(LDAP変更ログ・ドラフトの仕様が策定された時点ではそうでした)。しかし、変更ログ・サービスが複数のサーバーをサポートする場合や、サーバー間のフェイルオーバーをサポートする場合、この整数の形式は不適切です。
ノート:
Oracle Directory Server Enterprise Editionとの互換性を確保するには、cn=changelog
でreplicationCSN
属性に索引を作成する必要があります。cn=changelog
以外のパラメータでreplicationCSN
属性に索引を作成すると、パフォーマンスに影響するおそれがあります。
32.7.13.1.2 DITおよびスキーマの相違点について
LDAP変更ログ・ドラフトでは、変更ログ内のエントリに対するDNをchangenumber=changenumber,cn=changelog
として指定します。外部変更ログでは、変更ログ内のエントリに次のDNを使用します:
replicationcsn=replicationCSN,replication-domain-DN,cn=changelog
外部変更ログのスキーマはLDAP変更ログ・ドラフトのスキーマに基づいていますが、Oracle Unified Directoryでは外部変更ログ内の索引をchangenumber
属性ではなく、アプリケーションには理解不能なCookieによって管理します。
次の表で、スキーマの相違点について説明します。
元 | 必須 | 任意 |
---|---|---|
LDAP変更ログ・ドラフト |
|
|
ODSEEレトロ変更ログ |
|
|
Oracle Unified Directory外部変更ログ |
|
|
32.7.13.2 外部変更ログとOracle Directory Server Enterprise Editionレトロ変更ログとの相違点の理解
- スキーマおよび実装ベースの値
-
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が古すぎる場合はリクエストを却下します。詳細は、「外部変更ログの使用」を参照してください。
-
lastchangenumber
属性: 最後の(最も新しい)変更ログ索引を整数の変更番号として保持します。Oracle Unified Directoryの外部変更ログは、
lastExternalChangelogCookie
属性に相当する機能をサポートしています。lastExternalChangelogCookie
属性には、変更ログからの変更を検索するために必要な情報を含むCookieが含まれます。詳細は、「外部変更ログの使用」を参照してください。
-
- パージの遅延
-
Oracle Directory Server Enterprise Editionのレトロ変更ログでは、外部変更ログと通常のレプリケーション変更ログが別々のデータベースになっています。Oracle Unified Directoryでは、この2つの変更ログが同じデータベースに格納されています。この設計上の決定には、それぞれの利点があります。この設計上の決定の付加的な結果として、Oracle Directory Server Enterprise Editionでは2つの別々のトリミング・ポリシー(パージの遅延)を設定できるのに対し、Oracle Unified Directoryのトリミング・ポリシーは同一です。
32.7.13.3 LDAP変更ログ・ドラフトおよびOracle Directory Server Enterprise Editionレトロ変更ログとの互換性のためのAPIについて
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エントリの属性として存在します。
互換性APIの制限事項
Oracle Unified Directoryでは、外部変更ログを専用のデータベースに格納しないため、特定の索引など、JEBバックエンドでサポートされている機能の一部をサポートしていません。
また、LDAP変更ログ・ドラフトで指定されたchangenumber
ベースの順序をサポートするために、Oracle Unified Directoryではchangenumber
からレプリケーション状態へのマッピングを格納する必要があります。サーバーはリクエストの処理時に、リクエスト・フィルタで提供されたchangenumber
からレプリケーション・ステータスの取得を試みます。取得できない場合は、リクエストが却下されます。
32.8 Oracle Unified Directoryでのツームストンの管理
Oracle Unified Directoryでは、1つのレプリカで削除されたディレクトリ・エントリを、レプリケーションで不要になるまで維持するために、ツームストン機能がサポートされています。
この項では、次の項目について説明します。
32.8.1 ツームストン・サポートについて
エントリがLDAP削除操作のターゲットである場合、通常、Oracle Unified Directoryにより、このエントリはディレクトリ・データベースから削除されます。ただし、ツームストン作成が有効化されている場合、この削除操作は論理削除となり、このエントリがディレクトリによってデータベースから物理的に削除されることはありません。かわりに、ディレクトリでは、このエントリを特定のオブジェクト・クラスのツームストン・エントリに変換します。ツームストン・エントリでは、そのnsUniqueID
がRDNとして使用されます。
ツームストンにより、管理者は、誤って削除された1つ以上のエントリを必要に応じて元のエントリに復元できます。
ツームストン・サポートは、Oracle Unified Directoryレプリケーションで一部の削除競合を解決する場合に役立ちます。レプリケーション中、ディレクトリ・サーバーとレプリケーション・サーバー間の接続に失敗したことが原因で、サーバーがクラッシュする場合があります。クラッシュ後、一部の操作はディレクトリ・サーバーのデータベースでコミットされたものの、レプリケーション・サーバーに送信されていない可能性があります。このような場合、レプリケーション・サーバーでは、ツームストン・エントリを内部的に使用して競合を解決します。
ノート:
ツームストンを含むレプリカ(Aとします)がパージ間隔を超えてオフラインとなった場合、問題が発生する可能性があります。このレプリケーションがレプリケーション・リングに接続されていると、その他のサーバーとの競合が発生する可能性があり、この場合、これらのツームストン・エントリはパージされることがあります。レプリケーション・トポロジから選択したマスターで、Aを初期化するのが最適です。
32.8.2 ツームストン・エントリについて
ツームストンは読取り専用エントリであり、異なるDNで格納されます。ただし、クライアントの観点からは、ツームストンのDNは削除されたエントリと同じままとなります。
ツームストン・エントリには、tombstone
またはnstombstone
のいずれかの、特別なオブジェクト・クラス値が含まれています。ツームストン・エントリには、元の削除されたエントリのすべての属性またはそれらの一部のみを含めることができます。
dn: cn=u2,cn=users,dc=example,dc=com objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: orclIDXPerson objectClass: nstombstone objectClass: top objectClass: tombstone objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: orclIDXPerson objectClass: top objectClass: tombstone objectClass: nstombstone givenName: useri description: bidule cn: usersSuffix cn: u2 sn: u2 userPassword: {SSHA}zL22oCGjlG80cmbvh9jnzXAIyUfDSO+y4gRi+w== l: London orclGUID: 859b759ea60746a0bb271e4a46007f24 pwdPolicySubentry: cn=Default Password Policy,cn=Password Policies,cn=config deleteTimestamp: 20110922084753Z subschemaSubentry: cn=schema proximity: -1 createTimestamp: 20110922084752Z pwdChangedTime: 20110922084752.126Z structuralObjectClass: orclIDXPerson entryDN: cn=u2,cn=users,dc=example,dc=com entryUUID: 859b759e-a607-46a0-bb27-1e4a46007f24 creatorsName: cn=Internal Client,cn=Root DNs,cn=config modifyTimestamp: 20110922084753Z nscpEntryDN: cn=u2,cn=users,dc=example,dc=com modifiersName: cn=Internal Client,cn=Root DNs,cn=config 1316681273304
32.8.3 ツームストン・サポートの有効化または無効化
Oracle Unified Directoryでは、ツームストン・サポートはデフォルトで有効化されています。DBローカル・バックエンド・ワークフロー要素のtombstone-creation-enabled
拡張プロパティを使用して、ツームストンを無効化または有効化できます。
userRoot
バックエンドに対してツームストンを無効化するには:
dsconfig set-workflow-element-prop \ --element-name userRoot \ --set tombstone-creation-enabled:false \ --hostname localhost \ --port 1444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile /local/tests/password \ --no-prompt
tombstone-creation-enabled拡張プロパティのパラメータの説明は、Oracle Unified Directory構成リファレンスのDBローカル・バックエンド・ワークフロー要素に関する項を参照してください。
32.8.4 ツームストン・エントリの検索
ツームストン・エントリは、検索リクエストの検索フィルタにobjectclass=tombstone
またはobjectclass=nstombstone
を追加しないかぎり、通常の検索操作では表示されません。
次のldapsearch
コマンドでは、dc=example,dc=com
の下にツームストン・エントリが返されます。
$ ldapsearch -h localhost -p 5444 -D "cn=Directory Manager" -j pwd-file.txt -b dc=example,dc=com "(objectclass=nsTombstone)" dn: uid=user.3,ou=people,dc=com postalAddress: Aaron Atrc$59748 Willow Street$Green Bay, TN 66239 postalCode: 66239 description: This is the description for Aaron Atrc. uid: user.3 userPassword: {SSHA512}li0gmRHdPtL326Pc2B2tIfGe/RdITcQXzZshsR96nKl25FaTYFXvp9nq1 rNzafjKKFkgRrhGEwDggn6KaMsjym0Ggzm36oAh employeeNumber: 3 initials: AKA givenName: Aaron objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: nstombstone objectClass: top objectClass: tombstone pager: +1 197 025 3730 mobile: +1 890 430 9077 cn: Aaron Atrc telephoneNumber: +1 094 100 7524 sn: Atrc street: 59748 Willow Street homePhone: +1 332 432 4295 mail: user.3@maildomain.net l: Green Bay st: TN orclGUID: 8264e7f807f438879b9833ca1d0ed04a pwdPolicySubentry: cn=Default Password Policy,cn=Password Policies,cn=config deleteTimestamp: 20150227113328Z subschemaSubentry: cn=schema changelog: cn=changelog structuralObjectClass: inetOrgPerson dssynchist: dn:0000014bcad0132714a000000003:del nsUniqueId: 8264e7f807f438879b9833ca1d0ed04a entryDN: uid=user.3,ou=people,dc=com entryuuid: 8264e7f807f438879b9833ca1d0ed04a nscpEntryDN: uid=user.3,ou=people,dc=com modifyTimestamp: 20150227113328Z modifiersName: cn=directory manager
32.8.5 ツームストン・エントリの自動パージ
ツームストン・エントリはリソース(索引、データベース記憶域)を消費するため、無期限には保管されません。パージ・スレッドは、構成パラメータtombstone-purge-interval
により、特定の間隔で定期的に起動されます。
ツームストン・パージ・スレッドにより、tombstone-lifetime
構成パラメータで指定された時間より古いツームストン・エントリは削除されます。ツームストン・エントリには、デフォルトで1週間の保存期間が設定されています。この遅延後、サーバーにより、これらのエントリは自動的に消去されます。
ノート:
tombstone-lifetime
パラメータの時間間隔が短すぎないようにしてください。ツームストン保存期間の間隔が短いと、パージ対象のツームストンが多数存在する場合、サーバーが応答できない可能性があります。
ツームストン保存期間を特定の間隔に変更するには:
dsconfig set-workflow-element-prop \ --element-name userRoot \ --set tombstone-lifetime:1440\ m \ --hostname localhost \ --port 1444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile /local/tests/password \ --no-prompt
ツームストンのパージ間隔を変更するには:
dsconfig set-workflow-element-prop \ --element-name userRoot \ --set tombstone-purge-interval:6\ m \ --hostname localhost \ --port 1444 \ --trustAll \ --bindDN cn=directory\ manager \ --bindPasswordFile /local/tests/password \ --no-prompt
tombstone-lifetimeおよびtombstone-purge-intervalプロパティのパラメータの説明は、Oracle Unified Directory構成リファレンスのDBローカル・バックエンド・ワークフロー要素に関する説明を参照してください。
32.9 スキーマのレプリケーションの構成
スキーマのレプリケーションはデフォルトで有効になっています。サーバー設定の一部としてレプリケーションを構成すると、トポロジ内の既存のサーバーのスキーマを使用して、新しいサーバーのスキーマが自動的に初期化されます。
この項の内容は次のとおりです。
32.9.1 スキーマ・ソースの指定
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
32.9.2 スキーマのレプリケーションの無効化
環境によっては、スキーマをレプリケートしたくない場合もあります。スキーマは、"cn=schema"
という別個のベースDNの下にレプリケートされます。
この項の内容は次のとおりです。
32.9.2.1 スキーマをレプリケートしないようにする指定
dsreplication enable
コマンドでレプリケーションを構成するとき、スキーマをレプリケートしないように指定するには、--noSchemaReplication
オプションを使用します。
ノート:
QuickSetupを使用してレプリケーションを有効にする場合は、スキーマをレプリケートしないようには指定できません。
32.9.2.2 スキーマのレプリケーションの無効化
現在スキーマがレプリケートされている既存のトポロジでこの機能を無効にするには、スキーマ・ベースDNのレプリケーションを無効にします。次の例では、ローカル・ホストのポート1389
で稼働しているディレクトリ・サーバーのスキーマのレプリケーションを無効にします:
$ dsreplication disable -h localhost -p 1389 -D "cn=directory manager" \ -j pwd-file -b "cn=schema" -X
ノート:
この例は、トポロジ全体のスキーマのレプリケーションを無効にするものではありません。トポロジ全体のスキーマのレプリケーションを無効にするには、トポロジ内の各ディレクトリ・サーバーで同等のコマンドを実行する必要があります。
32.10 読取り専用サーバーへのレプリケーション
Oracle Unified Directoryのレプリケーション・モデルはマルチマスター・モデルです。つまり、トポロジ内のすべてのレプリケーション・サーバーが読取り操作と書込み操作の両方を処理できます。ただし、特定のディレクトリ・サーバーを読取り専用に設定できます。そのサーバーでは、LDAPクライアントからの追加操作、変更操作および削除操作が却下されます。
ノート:
読取り専用ディレクトリ・サーバーは、Oracle Directory Server Enterprise Editionのレプリケーション・モデルにおけるコンシューマ・レプリカと同様に機能します。
この例では、host1とhost2の2つのホストにレプリケーション・サーバーが存在するレプリケーション構成を想定しています。この例では、host2のディレクトリ・サーバーを読取り専用レプリカとして構成します。この例では、dsconfig
コマンドを使用します。このコマンドは、管理コネクタを介してサーバー構成にアクセスします。「サーバーへの管理トラフィックの管理」を参照してください。
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クライアント・アプリケーションによるサーバーへの直接の書込みはできないことを意味します。
32.11 レプリケーションの非一貫性の検出および解決
ディレクトリ・サーバーのレプリケーションは、ハードウェアの故障やディレクトリ・サーバーの再起動、ネットワーク障害が発生しても、レプリケートされたデータベース間で一貫性が維持されるように設計されています。しかし、それでも、ハードウェアの故障(ディスク・エラー、メモリー・エラー)やソフトウェアの不具合(これに起因するメモリーの破損)によってデータベース間に不整合が発生する可能性があります。
次のトピックでは、レプリケーションの非一貫性を検出する方法と、非一貫性が確認された場合にそれを解決する方法について説明します。
32.11.1 レプリケーションの非一貫性の種類について
非一貫性が発生しても、しばらくそれが顕在化しない場合もあれば、レプリケーション・エラーやアプリケーション・エラーが引き起こされる場合もあります。
非一貫性の例を次に示します:
-
あるエントリがレプリケーション・トポロジ内の1つのディレクトリ・サーバーを除くすべてのディレクトリ・サーバーに存在します。
-
あるエントリのDNが1つのディレクトリ・サーバーでのみ、他のディレクトリ・サーバーと異なります。
-
あるエントリの属性が1つのディレクトリ・サーバーでのみ、レプリケーション・トポロジ内の他のディレクトリ・サーバーと異なります。
32.11.2 非一貫性の検出
レプリケーション・ログ・ファイルおよびユーザーから報告されたエラーをチェックして、レプリケーション中に非一貫性を検出できます。
-
レプリケーション・ログ・ファイル内の情報を確認する。レプリケーション・ログ・ファイルはデフォルトで構成されており、レプリケーション・メカニズムによって検出された非一貫性が記録されます。たとえば、トポロジ内の1つのディレクトリ・サーバーに存在しないエントリに対して変更操作が実行されたとします。レプリケーションがこの操作をこのサーバーに対してリプレイしようとすると、問題が検出され、
logs/replication
エラー・ログにエラーが書き込まれます。この種のエラーによってレプリケーションが停止することはありませんが、操作がリプレイされないため、管理者は非一貫性を修正する必要があります。 -
クライアント・アプリケーションまたはユーザーから報告されるエラーに注意する。クライアント・アプリケーションやユーザーがディレクトリ・サーバーへのアクセス時に、レプリケーションの非一貫性に起因する可能性のあるエラーに遭遇する場合があります。
-
データベースの一貫性を定期的に確認する。現行のリリースのディレクトリ・サーバーでは、これらの確認は検索またはデータベース・エクスポートによって手動で行う必要があります。
32.11.3 非一貫性の解決
トポロジ内の単一のディレクトリ・サーバーでレプリケーションの非一貫性が検出された場合、通常の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
属性には、レプリケーションによる変更の競合の解決に使用される履歴情報が保持されています。この属性を参照できるのは管理者のみです。
32.11.4 名前の競合の解決
サーバー同士が互いの変更をレプリケートする前にエントリが作成された場合、同じ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
(ドメイン・コンポーネント)など、競合エントリのネーミング属性が単一値の場合、エントリ名を単純に同じ属性の他の値に変更することはできません。かわりに、次のように仮の名前をエントリに付与する必要があります:
32.12 dsreplication
を使用した証明書の管理
レプリケート対象のOracle Unified Directoryサーバーでは、証明書を使用して認証の実行およびレプリケーション通信の暗号化を行います。
次のdsreplication
サブコマンドを使用して、これらの証明書を管理できます。
ノート:
この項で説明する証明書は、内部のレプリケーション通信プロセスで使用され、LDAPクライアントと通信するためにサーバーで使用される証明書とは異なります。
dsreplication
サブコマンド(構文を含む)の詳細は、「dsreplication」を参照してください。
32.12.1 dsreplication list-certs
を使用した証明書の一覧表示
list-certs
サブコマンドでは、デプロイメントでレプリケート対象サーバーが使用する証明書を表示します。
たとえば、レプリケーション・デプロイメントのすべての証明書を表示する場合
$ dsreplication list-certs -j /tmp/password.txt -X -n Establishing connections ..... Done. Reading Certificates ..... Done. host1.example.com:4444 ============== User DN: CN=host1.example.com, O=Oracle Unified Directory Certificate Validity: From November 7, 2013 1:48:55 PM CET to November 2, 2033 1:48:55 PM CET Issuer: CN=host1.example.com, O=Oracle Unified Directory Certificate host1.example.com:5444 ============== User DN: CN=host1.example.com, O=Oracle Unified Directory Certificate Validity: From November 7, 2013 1:48:55 PM CET to November 2, 2033 1:48:55 PM CET Issuer: CN=host1.example.com, O=Oracle Unified Directory Certificate
32.12.2 dsreplication regenerate-cert
を使用した証明書の再生成
regenerate-cert
サブコマンドでは、レプリケーション・トポロジ内の指定されたサーバーまたはすべてのサーバーで使用される証明書を再生成します。デフォルトでは、Oracle Unified Directoryサーバーはレプリケーションのためにいくつかの証明書を自動的に生成します。このコマンドを使用すると、必要に応じてこれらの証明書を再生成できます(たとえば、証明書の有効期限が間もなく終了する場合)。
ノート:
独自の証明書を指定した場合(たとえば、dsreplication set-cert
サブコマンドを使用した場合)は、これらの証明書の削除が試行されるため、このコマンドの使用はお薦めしません。
たとえば、ポート4444を使用するhost1.example.com
サーバーの証明書を再生成する場合
$ dsreplication regenerate-cert -h host1.example.com -p 4444 -X -j /tmp/password.txt -n --adminUID admin Establishing connections ..... Done. After the generation of the new certificate for server host1.example.com:4444, the references to the old certificate will be removed. Regenerating the Certificate of Server host1.example.com:4444 ..... Done. Propagating certificate public keys ..... Done. Reestablishing replication connections on server host1.example.com:4444 .... Done. Checking registration information ..... Done.
レプリケートされるすべてのサーバーの証明書を再生成するには、--all
オプションを含めます。
このコンテンツは、OUDバンドル・パッチ12.2.1.4.211008以降のリリースにのみ適用されます。
また、データ暗号化も有効になっており、属性が暗号化されて格納されているエントリがある場合は、regenerate-cert
コマンドを使用して自己署名証明書を更新する必要があります。regenerate-cert
コマンドは、レプリケーション・トポロジ内のサーバーの証明書を自動的にリセットし、管理データを同期します。属性の暗号化に必要なデータをエクスポートして再インポートする必要はありません。さらに、サーバーを再起動する必要はありません。
ノート:
Keytoolコマンドを使用してキーストア・ファイルを直接更新しないでください。32.12.3 dsreplication set-cert
を使用した証明書の指定
set-cert
サブコマンドでは、レプリケーション・システムで使用する必要がある証明書を指定できます。また、他のレプリケート対象サーバーとの通信に使用する公開キーを含むキーストアも指定します。
たとえば、keytool
などのユーティリティを使用してmy-ads-keystore
という名前の自己署名証明書を生成した後に、次のようにset-cert
サブコマンドを実行します:
$ dsreplication set-cert -X
>>>> Specify Oracle Unified Directory LDAP connection parameters
Directory server hostname or IP address [host1.example.com]:
Directory server administration port number [4444]:
Global Administrator User ID [admin]:
Password for user 'admin':
Establishing connections ..... Done.
Choose the type of the key store.
1) JKS
2) JCEKS
3) PKCS12
4) PKCS11
5) Other (File Based)
6) Other (Hardware Based)
q) quit
Enter choice [1]:
You must provide the path of the key store containing the certificate to be
used by the replication. The server must have read access rights to thispath.
Key store path: /users/admin/my-ads-truststore
You must provide the path of the file containing the password (PIN) in clear
of the key store. The server must have read access rights to this file.
Key store password (PIN) file: /tmp/password.txt
The server allows to encrypt the key store password file '/tmp/password.txt'.
Note that the server must have write access rights on the file to do so.
Do you want to encrypt the key store password file? (yes / no) [no]:
Choose the Nickname of the Certificate:
1) my-ads-truststore
q) quit
Enter choice [my-ads-truststore]:
Updating the certificate configuration of server host1.example.com:4444 ..... Done.
Propagating certificate public keys ..... Done.
Reestablishing replication connections on server host1.example.com:4444 ........................... Done.
Checking registration information ..... Done.
See /tmp/oud-replication-356794289708010450.log
for a detailed log of this operation.
このコンテンツは、OUDバンドル・パッチ12.2.1.4.211008以降のリリースにのみ適用されます。
また、データ暗号化も有効になっており、属性が暗号化されて格納されているエントリがある場合は、set-cert
コマンドを使用してカスタム証明書またはCA証明書を更新する必要があります(たとえば、証明書の有効期限が間もなく終了する場合)。
新しい秘密キーと公開キーのペアで構成される新しいキーストアへのパスを指定するか、公開証明書の更新のみを行う場合は同じキーストア・パスを指定できます。これにより、レプリケーション・トポロジ内のサーバーとその参照の証明書が自動的にリセットされ、管理データが同期されます。属性の暗号化に必要なデータをエクスポートして再インポートする必要はありません。さらに、サーバーを再起動する必要はありません。
32.12.4 dsreplication verify
を使用した証明書の検証と修正
verify
サブコマンドでは、レプリケート対象サーバーの構成を検証し、必要に応じて(対話モードで)レプリケーション・システムで使用される証明書に関連する問題を修正できます。
レプリケーション・システムで使用される証明書を検証して修正するには、verify
サブコマンドを対話モードで実行します。たとえば:
$ dsreplication -X
What do you want to do?
1) Enable Replication
2) Disable Replication
3) Initialize Replication on one Server
4) Initialize All Servers
5) Pre External Initialization
6) Post External Initialization
7) Display Replication Status
8) Purge Historical
9) Set the Trust Flag of a Directory Server
10) Enable External Changelog
11) Disable External Changelog
12) Verify Server Configuration
13) >>>> Replication Certificate Management
q) quit
Enter choice: 12
>>>> Specify Oracle Unified Directory LDAP connection parameters
Directory server host name or IP address [host1.example.com]:
Directory server administration port number [4444]:
Global Administrator User ID [admin]:
Password for user 'admin':
Establishing connections ..... Done.
No errors were found with the configured host names. The following host names
have been found in the registration information to identify the different
replicated servers:
host1.example.com
host2.example.com
host3.example.com
Do you want to update the host names for the servers? (yes / no) [no]: no
The replication servers are consistently referenced in the configuration.
The replication server values in the configuration are:
- host1.example.com:8989
- host2.example.com:8989
- host3.example.com:9989
What do you want do?
1) Provide directly the replication server values to be used
2) Do not update the configuration
Enter choice [2]:
Checking certificates ..... Done.
The following certificates are missing in the trust store of server host1.example.com:4444:
- Certificate of Server host2.example.com:4444
Do you want to repair the issues with the certificates? (yes / no) [yes]: yes
Fixing certificates ..... Done.
Reestablishing replication connections on server host1.example.com:4444 .......... Done.
Reestablishing replication connections on server host2.example.com:4444 .......... Done.
Reestablishing replication connections on server host3.example.com:4444 .......... Done.
Checking registration information ..... Done.
See /tmp/oud-replication-356794289708010450.log
for a detailed log of this operation.
32.13 verify
サブコマンドの使用
verify
サブコマンドのコンテキストの説明およびdsreplication
とともにverify
サブコマンドを使用する方法の例は、これらのトピックを参照してください。
32.13.1 verify
サブコマンドについて
verify
サブコマンドでは、レプリケート対象サーバーのレプリケーション構成を検証し、必要に応じて(対話モードで)非一貫性を修正できます。
verify
サブコマンドは対話モードで実行することをお薦めします(つまり、--no-prompt
オプションは使用しません)。レプリケーション構成に非一貫性が見つかった場合は表示されるため、対話形式で修正できます。
verify
サブコマンドを使用して次の内容を実行します。
-
到達不能なサーバーへの参照を削除します(たとえば、クラッシュしてリカバリ不能または正常にアンインストールされなかったため)。
-
レプリケーション・システムで使用される証明書に関連する構成の問題を修正します。
-
レプリケーション構成で使用されるホスト名を更新します。
32.13.2 dsreplication verify
を使用したレプリケーション構成の検証と修正
verify
サブコマンドを対話モードで実行して、レプリケーション構成を検証および修正します。
たとえば:
$ dsreplication -X
What do you want to do?
1) Enable Replication
2) Disable Replication
3) Initialize Replication on one Server
4) Initialize All Servers
5) Pre External Initialization
6) Post External Initialization
7) Display Replication Status
8) Purge Historical
9) Set the Trust Flag of a Directory Server
10) Enable External Changelog
11) Disable External Changelog
12) Verify Server Configuration
13) >>>> Replication Certificate Management
q) quit
Enter choice: 12
>>>> Specify Oracle Unified Directory LDAP connection parameters
Directory server host name or IP address [host1.example.com]:
Directory server administration port number [4444]:
Global Administrator User ID [admin]:
Password for user 'admin':
Establishing connections ..... Done.
No errors were found with the configured host names. The following host names
have been found in the registration information to identify the different
replicated servers:
host1.example.com
host2.example.com
host3.example.com
Do you want to update the host names for the servers? (yes / no) [no]:
The following replication servers do not have the complete list of replication
server values in their configuration:
- host2.example.com:8989
The replication servers must have the complete list of replication server
values.
The following replication domains do not have the complete list of replication
server values in their configuration:
- host2.example.com:4444(cn=admin data)
- host2.example.com:4444(cn=schema)
- host2.example.com:4444(dc=example,dc=com)
If they have not been configured this way intentionally, the configuration of
the replication domains should be updated.
The replication server values in the configuration are:
- host1.example.com:8989
- host2.example.com:8989
- host3.example.com:8989
What do you want do?
1) Use the interactive assistant
2) Provide directly the replication server values to be used
3) Do not update the configuration
Enter choice [1]:
The replication server values proposed after running the assistant are:
- host1.example.com:8989
- host2.example.com:8989
- host3.example.com:8989
What do you want to do?
1) Use the values above
2) Use the values above but do not update the replication domains
3) Provide the values again
4) Do not update the configuration
q) quit
Enter choice [1]:
Checking certificates ..... Done.
No problems were found with the certificates used by the replication.
Updating replication server references ..... Done.
See /tmp/oud-replication-6260669521027550543.log
for a detailed log of this operation.
32.14 履歴レプリケーション・データのパージの理解
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
スケジューリング・コマンドの詳細は、「タスクとしてのコマンドの構成」を参照してください。
32.15 分離レプリカの理解
32.15.1 分離レプリカについて
分離レプリカとは、他のレプリカから変更を受け入れてリプレイできるが、接続先のレプリケーション・サーバーに変更を送信できないディレクトリ・サーバーのことをいいます。分離レプリカは、トポロジに対するデータ更新のソースにはなれません。分離レプリカを使用すると、特定のディレクトリ・サーバーをレプリケーション・トポロジ内の他のサーバーから分離できます。
トポロジ内のすべてのディレクトリ・サーバーに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
32.15.2 分離レプリカのデプロイメント・シナリオの理解
分離レプリカをレプリケーション・トポロジ内で使用して、非武装地帯(DMZ)での追加セキュリティを提供したり、ステージング領域内のクライアント・アプリケーションをテストできます。
分離レプリカをレプリケーション・トポロジ内で使用するための次の2つのシナリオに注意してください。
32.15.2.1 DMZでの分離レプリカの使用について
非武装地帯(DMZ)とは、社内ネットワークの中で、インターネットなどの信頼できないネットワークに公開されている領域のことです。DMZは信頼できるネットワークと信頼できないネットワークの間に位置するため、保護層を備えています。外部からの直接アクセスは、DMZの内側に設置されている機器に限定されます。次の図は、DMZでの分離レプリカの使用方法を示しています。
DMZ内に読取り専用ディレクトリ・サーバーを配置することで、危険にさらされているデータが社内ネットワークのプライベート領域内にあるレプリケーション・サーバーに伝播されないようにできます。レプリカをDMZ内にデプロイすると、そのレプリカは社内のファイアウォールで保護されないため、セキュリティが破られる危険性があります。このような場合、不正なユーザーがレプリカの構成にアクセスして、書込み可能なレプリカに変更してしまうおそれがあります。そのため、このようなレプリカに対し、ファイアウォールで保護されているレプリケーション・サーバーは信頼できないというレッテルを貼ります。
DMZ内のサーバーを信頼できないサーバーとして構成することで、悪意のあるデータをそれらのサーバーが受け入れないように保護できます。プライベート領域内のサーバーは、読取りおよび書込みアクセス権を持つように構成されています。この構成により、データ変更がプライベート領域内のディレクトリ・サーバーによってのみレプリケーション・トポロジ全体に伝播されることが保証されます。DMZ内の読取り専用ディレクトリ・サーバーは、プライベート・ネットワークの内側にあるレプリケーション・サーバーからデータ変更を取得します。外部の攻撃者がデータのセキュリティを破ろうとしても、直接アクセス・ポイントはDMZ内の読取り専用サーバーです。DMZ内のディレクトリ・サーバーは信頼できないサーバーなので、悪意のあるデータは伝播できません。したがって、プライベート社内LAN内のサーバー・データの整合性が守られます。
このシナリオには次の構成要件があります:
-
DMZ内の各ディレクトリ・サーバーが信頼できないサーバーかつ読取り専用として構成されていること。
-
トポロジ内の各レプリケーション・サーバーがプライベート社内LANの内側に位置していること。
-
プライベート社内LAN内の各ディレクトリ・サーバーが読取り/書込みアクセス権を持つ信頼できるサーバーとして構成されていること。
トポロジ内の信頼できる各ディレクトリ・サーバーには次のアクセス権が付与されています:
-
接続先のレプリケーション・サーバーに変更を送信できます。この変更は、トポロジ内の他のすべてのディレクトリ・サーバーに伝播されます。
-
接続先のレプリケーション・サーバーから送信された変更をリプレイできます。
-
他のサーバーを初期化するためのオンライン完全更新操作のデータ・ソースになることができます。
トポロジ内の信頼できない各ディレクトリ・サーバーには次のアクセス制限があります:
-
接続先のレプリケーション・サーバーに変更を送信する権限がありません。信頼できないディレクトリ・サーバーが変更を送信すると、その変更は危険にさらされたデータと判定され、レプリケーション・サーバーはその変更を破棄します。
-
接続先のレプリケーション・サーバーから送信された変更をリプレイできます。
-
他のサーバーを初期化するためのオンライン完全更新操作のデータ・ソースになることができません。
32.16 Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーション
Oracle Directory Server Enterprise EditionのデータをOracle Unified Directoryサーバーにレプリケートするために必要なコンテキスト情報と手順は、これらのトピックで確認してください。
32.16.1 Oracle Directory Server Enterprise EditionとOracle Unified Directoryの間のレプリケーションについて
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トポロジがあると仮定した場合、移行前のサーバー・レイアウトは次のようになります。
移行後のサーバー・レイアウトは次のようになります:
32.16.2 Oracle Directory Server Enterprise Editionのスキーマおよび構成の移行
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 (2.a)で説明するユーザー・データのエクスポート時に自動的にデータ変換が行われます。
この項の手順では、ds2oud
コマンドの様々なオプションについて説明します。コマンド行でds2oud
を入力すると、ds2oud
コマンドを完全に対話型で実行できます。対話型モードでは、応答を要求するプロンプトが表示されます。詳細は、「ds2oud」を参照してください。
-
Oracle Directory Server Enterprise Editionディレクトリ・サーバーで、
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
ノート:
前述のコマンドの
-f opends-export
オプションは、Oracle Directory Server Enterprise Edition 11gリリース1 (11.1.1)にのみ適用可能です。 -
データを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ディレクトリ・サーバー上に作成されます。
-
32.16.3 Oracle Directory Server Enterprise EditionとOracle Unified Directory間のレプリケーションの構成
Oracle Directory Server Enterprise EditionとOracle Unified Directoryとの間にレプリケーション・ゲートウェイをインストールして構成する必要があります。
『Oracle Unified Directoryのインストール』のレプリケーション・ゲートウェイの設定に関する項の説明に従って、レプリケーション・ゲートウェイをインストールして構成します。
この時点で、Oracle Unified Directoryサーバーでレプリケーション用のグローバル管理者を構成する必要があります。このサーバーを後で既存のレプリケート対象Oracle Unified Directoryトポロジに接続する予定の場合は、他のOracle Unified Directoryサーバーで定義されている同じグローバル管理者の資格証明を使用します。