41 レプリケーションの設定

Oracle Internet Directoryのレプリケーションの実行方法、およびLDAPベースのレプリケーションとファンアウトを使用したマルチマスター・レプリケーションの設定方法について理解します。

レプリケーションは、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーし、管理するプロセスです。これにより、問合せを処理するサーバーの数が増え、クライアントの近くにデータを持ってくるため、パフォーマンスが向上します。また、シングル・ポイント障害に関連するリスクを排除することで信頼性が向上します。

この章をお読みになる前に、レプリケーションの基本概念の概要について、「Oracle Internet Directoryレプリケーションの理解」を参照してください。

関連項目:

転送メカニズム: LDAP

高可用性構成でのレプリケーションの設定は、『高可用性ガイド』Oracle Internet Directoryの高可用性に関する項を参照してください。

この項では、次の項目について説明します。

ノート:

この章で言及するOracle Single Sign-OnまたはOracle Delegated Administration Servicesはすべて、Oracle Single Sign-On10g (10.1.4.3.0)以降および12cリリース2 (12.2.1.3.0)の『Oracle Fusion Middleware Oracle Identity Managerでのセルフ・サービス・タスクの実行』のことです。

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

この項では、レプリケーションの設定方法の概要を説明します。

レプリケーションの基本概念について不明な場合は、この概要の前に「Oracle Internet Directoryレプリケーションの理解」を参照してください。

この概要の項目は次のとおりです。

41.1.1 レプリケーション転送メカニズム

Oracle Internet Directoryでは、LDAPベースのレプリケーション転送メカニズムがサポートされます。業界標準のLightweight Directory Access Protocolバージョン3を使用します。

一方向、双方向およびマルチマスター構成でLDAPベースのレプリケーションを設定できます。これは、ほとんどの環境に推奨されるプロトコルです。

41.1.2 レプリケーション設定方法

この項では、レプリケーション設定方法に関する情報を示します。

Oracle Internet Directoryレプリケーションを設定するには、次のいずれかの方法を使用します。

ノート:

次のシナリオでは、レプリケーションを設定および変更するコマンド行ツール(ldifwriteおよびbulkload)を使用する必要があります。

  • 100,000を超えるエントリを持つディレクトリのレプリケーション

41.1.2.1 レプリケーションを設定および変更するコマンド行ツール

コマンド行ツールでLDAPベースのレプリケーションを設定できます。

コマンド行を使用したLDAPベースのレプリケーションの設定方法は、「コマンド行を使用したLDAPベースのレプリケーションの設定」を参照してください。

コマンド行からレプリケーションを設定する場合、レプリケーション・サーバーの停止および開始には、oidctlコマンドを使用します。データをバックアップして他のノードにロードするにはバルク・ツールを使用します。いくつかの操作には、LDAPツールを使用します。

ノート:

コマンド行を使用してレプリケーション・サーバーを起動する場合、停止にもコマンド行を使用する必要があります。

また、初期データの移行には、レプリケーション・サーバーのブートストラップ機能を使用できます。

次のような各種レプリケーション関連タスクを実行するには、レプリケーション環境管理ツールのremtoolを使用します。

  • レプリケーション・グループの設定

  • レプリカの追加および削除

  • ディレクトリ・レプリケーション・グループの管理

  • レプリケーション・バインド識別名パスワードの変更または再設定

  • データベース・レプリケーション・ユーザーREPADMINパスワードの変更

  • 変更ログの伝播に関する様々なエラーおよびステータス情報の表示

  • ディレクトリ・レプリケーション・グループでのレプリケーションの進行状況の追跡

関連項目:

レプリケーション環境管理ツールの詳細は、『Oracle Identity Managementリファレンス』remtoolコマンド行ツールのリファレンスを参照してください

41.1.2.2 既存のホストからレプリケートするデータベース・コピー・プロシージャ

新規ホスト上では、既存ホストからOracle Databaseをコピーしてレプリケーションを設定できます。これは複雑な手順であり、ほとんどの環境では推奨されません。この手順は、「データベース・コピー・プロシージャを使用したディレクトリ・ノードの追加」を参照してください。

41.1.3 レプリケーションのブートストラップ・ルール

初期データの移行には、レプリケーション・サーバーのブートストラップ機能を使用できます。

replicadn下の属性orclreplicastate0に設定してブートストラップ・フラグを設定します。

レプリカがブートストラップ・モードの場合、サプライヤ・ノードはオンライン・モード(orclreplicastate=1)である必要があります。サプライヤとコンシューマを同時にブートストラップに設定しないでください。

ブートストラップは、複数のサプライヤを持つノードでの初期データ移行には使用できません。つまり、ブートストラップは次のタイプのレプリカに制限されています。

  • リーフ・レプリカ。つまり、コンシューマ・レプリカのないレプリカ。

  • 双方向ファンアウト・レプリカがない場合の2ノードによるLDAPベースのマルチマスター・レプリケーション承諾での1次レプリカ。

  • 双方向ファンアウト・レプリカがない場合の複数ノードによるLDAPベースのマルチマスター・レプリケーション承諾での非1次レプリカ。

  • サプライヤが1つのみのファンアウト・レプリカ

他のレプリカのブートストラップ・フラグ(replicadn下のorclreplicastate=0)を設定すると、レプリケーション・サーバーは次のいずれかのメッセージをスローします。

 bootstrapping against non-leaf replica is not allowed
 bootstrap against master replica is not allowed

ノート:

レプリケーションのブートストラップ・プロセス中に、参照整合性を無効にします。参照整合性が有効になると、ブートストラップは失敗します。

41.1.4 レプリケーション承諾

レプリケーションを設定する場合は、各レプリケーション・ホスト上のDIT内にレプリケーション承諾と呼ばれるコンテナを作成します。

レプリケーション承諾エントリの属性は、「レプリケーション承諾エントリの理解」を参照してください。

レプリケーション承諾にはレプリケーション・コンテキストも含まれます。その詳細は、「部分レプリケーションのためのLDAPレプリケーションのフィルタリング」に示します。属性については、「レプリケーション承諾エントリの理解」で説明しています。

41.1.5 その他のレプリケーション構成属性

レプリケーション承諾エントリに加え、DITには、レプリケーションを制御する属性を含む複数のエントリが他にも含まれています。

エントリおよびその属性の詳細は、「レプリケーション構成属性の管理」を参照してください。レプリケーションを設定すると、これらの属性を管理できるようになります。

LDAPツールを使用してレプリケーション属性を変更できます。その方法については、「レプリケーションの管理および監視」で説明しています。

41.1.6 レプリケーション・プロセスとアーキテクチャ

この項では、レプリケーション・アーキテクチャとレプリケーション・プロセスに関する参照情報を示します。

レプリケーション・アーキテクチャとレプリケーション・プロセスの詳細は、「レプリケーションの動作」を参照してください。

41.1.7 LDAPベースのレプリケーションの構成に関する規則

LDAPベースのレプリケーションに適用される規則について学習します。

LDAPベースのレプリケーションに適用される規則は次のとおりです。

  • 同じOracle Databaseを使用するOracle Internet Directoryのインスタンスが複数ある場合は、その1つのインスタンスのみをレプリケーション用に設定できます。

  • LDAPマルチマスター・レプリケーションには、下位互換性がありません。これは、12cリリース2を実行するレプリカ間でのみサポートされています。

  • マルチマスター・レプリケーションまたは双方向ファンアウト・レプリケーションの場合は、すべてのノードで同じリリースのOracle Internet Directoryを実行する必要があります。したがって、ローリング・アップグレードの実行中にはレプリケーションをオフに切り替える必要があります。

  • そのサプライヤより新しいリリースを実行する一方向のファンアウト・レプリカを追加できます。たとえば、図6-5では、ノードFで他のノードより新しいリリースを実行できます。

  • 一般に、より新しいバージョンのOracle Internet Directoryで生成された変更内容は、そのバージョンまでアップグレードされていないノードにはレプリケートしません。レプリケートすると、旧リリースでは正しく解析されない情報が変更内容に含まれてしまいます。

  • 具体的には、新しいOracle Internet Directory 12c リリース (12.2.1.3.0)のノードを既存のDRGに一方向のファンアウト・レプリカとして追加する場合、DRGの他のノードをアップグレードする必要はありません。他のすべてのレプリケーション・タイプについては、DRGのノードをアップグレードしてから新規ノードを追加します。このことは、既存のノードで10g リリースまたは以前の11g リリースのいずれを実行していても、当てはまります。たとえば、図6-5では、Oracle Internet Directory 12c リリース(12.2.1.3.0)のノードをノードEとして追加する前に、まずノードA、B、CおよびGを12c リリース(12.2.1.3.0)に更新する必要があります。

  • LDAPベースのレプリケーションでは、ルートDSEのnamingcontexts属性にリストされているネーミング・コンテキストのみ、コンシューマにレプリケートできます。

  • LDAPベースのレプリカのサプライヤは、レプリケーション・グループのメンバーではないマスター・ノード、マルチマスター・レプリケーション・グループのメンバーまたは別のLDAPベースのレプリカです。

    関連項目:

    Oracle Internet Directoryのインストール方法は、『Oracle Identity Managementのインストールと構成』「Oracle Internet Directoryの構成」を参照してください。

  • LDAPベースのレプリカは、別のLDAPベースのレプリカのコンシューマの場合もあります。そのコンシューマはファンアウト・レプリカと呼ばれます。

    ノート:

    スキーマが同期していることを確認してください。そうでないと、レプリケーション・サーバーがコンシューマ・レプリカに変更を適用できない場合があります。

  • 新規コンシューマ・ノードは空であることが必要です。つまり、Oracle Internet Directoryを新たにインストールする必要があります。

41.1.8 10gノードと11gR1ノードの混在デプロイメントのレプリケーション手順

Oracle Internet Directory 10gノードと11gR1ノードの組合せによるデプロイメントを検討してください。

次に例を示します。

  • それぞれサプライヤ・ノードとコンシューマ・ノードとして使用される2つの10gノード

  • LDAPマルチマスター・レプリケーションを指定した2つの新しい11gR1ノード(たとえば、ノード1および2)

レプリケーションを次のように設定する必要があります。

  1. いずれかの10gノードから11gR1のノード1に一方向のLDAPレプリケーションを設定します。
  2. 11gR1のノード1でレプリケーション・ブートストラップを設定し(エントリ数が100,000未満の場合)、レプリケーション・サーバーを起動します。
  3. ブートストラップが完了したら、11gR1のノード1および2の間にLDAPマルチマスター・レプリケーションを設定します。
  4. 11gR1のノード2でレプリケーション・ブートストラップを設定し、レプリケーション・サーバーを起動します。

11gR1のノード間のレプリケーションを設定する前に、最も重要な10gノードから11gR1ノードへのレプリケーションを設定する必要があります。

41.1.9 レプリケーションのセキュリティ

認証およびSSL暗号化メカニズムを使用して、レプリケーションのセキュリティを確保できます。

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

41.1.9.1 ディレクトリ・レプリケーション・サーバーの認証

認証とは、Oracleディレクトリ・レプリケーション・サーバーが、ディレクトリ・サーバーへの接続時に、サーバー自身の正確なアイデンティティを取得するプロセスです。これは、LDAPセッションがldapbind操作によって確立されたときに発生します。

ディレクトリ・レプリケーション・サーバーが、ディレクトリへのアクセスを許可される前に適切に認証されることが重要です。

ディレクトリ・レプリケーション・サーバーは、一意のアイデンティティとパスワードを使用して、ディレクトリ・サーバーに対する認証を行います。ディレクトリ・レプリケーション・サーバーのアイデンティティは、cn=replication dn,orclreplicaid=unique_identifier_of_node,cn=replication configurationの形式をとります。

ディレクトリ・レプリケーション・サーバーは、起動時、Oracle Internet Directoryのセキュアなウォレットからアイデンティティとパスワードを読み取り、これらの資格証明を使用して認証を行います。レプリケーション・バインド識別名を変更する場合、レプリケーション環境管理ツール-chgpwd-presetpwdまたは-pchgwalpwdオプションを使用する必要があります。レプリケーション・アイデンティティのウォレットは、$DOMAIN_HOME/config/fmwconfig/components/OID/admin/oidpwdrOracle_SIDに存在します。

関連項目:

『Oracle Identity Managementリファレンス』remtoolコマンド行ツールのリファレンス。

ノート:

以前のリリースでは、レプリケーション・サーバーを実行するには、ディレクトリ・サーバーで匿名バインドを許可する必要がありました。このリリースではその必要はありません。

41.1.9.2 Oracle Internet DirectoryレプリケーションでのSSL暗号化の使用

Oracle Internet Directoryレプリケーションは、SSLの使用に関係なくデプロイできます。レプリケーション・サーバーで、Oracle Internet DirectoryインスタンスのSSLポートにバインドしているかどうかを自動的に検出します。そうである場合、Secure Sockets Layer上で動作します。

SSL暗号化を使用するようにLDAPベースのレプリケーションを構成するには、サプライヤ連絡先情報が含まれているorclReplicaURI属性に、SSLポートのポート番号を指定します。

ノート:

12.2.1.3.0以降、レプリケーション・サーバーは、一方向認証または双方向認証が構成されたSSLポートで通信できるようになりました。Oracle Internet Directory 12.2.1.3.0では、購入直後はSSL認証なしモードが無効化されています。SSL認証なしモードを有効にするには、匿名暗号を構成する必要があります。LDIFファイルの構成については、「SSLが有効なODSM接続の構成」を参照してください。

サプライヤ・ノードのSSL双方向構成のサンプル・レプリケーション・エントリ:

dn: orclreplicaid=myhost1_repl1,cn=replication configuration
orclreplicauri:ldap://myhost1:3131/
orclreplicauri;wallet:<location of auto-login wallet>
orclreplicauri;authmode:64
orclreplicatype: 0
orclreplicasecondaryuri:ldap://myhost1:3131/
objectclass:top
objectclass:orclreplicasubentry
orclreplicaid:myhost1_repl1

orclreplicauri;authmodeはSSL認証モードを持ちます(認証なし/一方向/双方向認証の場合、値は1/32/64)

oidrepldを一方向または双方向認証モードで起動する際には、oidctl起動コマンド、sslauthおよびwurlでパラメータの値を渡す必要があります。sslauthはSSL認証モード用で(認証なし/一方向/双方向認証の場合、サポート値は1/2/3)、wurlはウォレットがコンシューマ・ノードに接続する場所です。

コンシューマ・ノードへの双方向認証接続でレプリケーション・サーバーを起動するサンプルのoidctlコマンド:

oidctl connect=inst2 server=oidrepld inst=1 flags=" -h localhost -p 3132 -sslauth 3 -wurl<location of auto-login wallet> start”

41.1.10 部分レプリケーションのためのLDAPレプリケーションのフィルタリング

この項では、LDAP部分レプリケーションでネーミング・コンテキストを指定する場合の規則およびベスト・プラクティスについて説明します。次の項目が含まれます。

41.1.10.1 LDAPレプリケーションでのネーミング・コンテキストのフィルタリング

LDAPベースのレプリケーションでは、特定のネーミング・コンテキストをレプリケーションに追加し、そのネーミング・コンテキスト内の1つ以上のサブツリーをレプリケーションから除外できます。ネーミング・コンテキスト内の1つ以上の属性もレプリケーションから除外できます。

LDAPベースのレプリケーションでは、レプリケーションに含むことを明示的に指定したネーミング・コンテキストのみがレプリケートされます。

41.1.10.2 ネーミング・コンテキストを制御する属性

ネーミング・コンテキストを制御する属性は、「レプリケーションのネーミング・コンテキスト・オブジェクト・エントリの理解」に示します。

41.1.10.3 LDAPレプリケーションでのネーミング・コンテキストのフィルタリング・ルール

レプリケーションに対して複数のネーミング・コンテキストを構成する場合、フィルタリングは次の規則に基づいて行われます。

  • 各ネーミング・コンテキスト・オブジェクトで定義されて含まれているすべてのネーミング・コンテキストの集合が、レプリケーションに含まれる全体的なネーミング・コンテキストになります。

  • 各ネーミング・コンテキスト・オブジェクトで定義された除外ネーミング・コンテキストの集合が、レプリケーションから除外される全体的なネーミング・コンテキストになります。

  • 1つのネーミング・コンテキスト・オブジェクトでの属性の除外は、そのネーミング・コンテキスト・オブジェクトのみに限定されます。

  • 包含されるネーミング・コンテキストと除外されるネーミング・コンテキストとの間で矛盾がある場合は、除外されるネーミング・コンテキストが優先されます。たとえば、ネーミング・コンテキスト・オブジェクトAの包含ネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトBの除外ネーミング・コンテキストのサブツリーだった場合、ネーミング・コンテキスト・オブジェクトBのorclexcludednamingcontextsで指定されているサブツリーは、レプリケートされません。つまり、ネーミング・コンテキスト・オブジェクトAでのレプリケーションのフィルタリングは無視されます。

  • 2つの異なるバージョンのOracle Internet Directory (10g (10.1.4.0.1)と11gリリース1 (11.1.1.0.0)など)間での部分レプリケーションを構成する場合、ネーミング・コンテキストを除外できません。そのかわり、レプリケート対象のネーミング・コンテキストを包含コンテキストとして明示的に指定する必要があります。

41.1.10.4 LDAPレプリケーションでのネーミング・コンテキストのフィルタリングのシナリオ

この項の説明は、図41-1に示すネーミング・コンテキストのサンプルに基づいて行われます。cn=user1cn=user2およびcn=user1000の下には、ユーザー属性リストの一部が示されています。

図41-1 ネーミング・コンテキストのサンプル

この図については本文で説明しています。

関連項目:

レプリケーション・ネーミング・コンテキスト・エントリの属性の説明は、『Oracle Identity Managementリファレンス』Oracleディレクトリ・レプリケーションのスキーマ要素に関する項を参照してください

前述の規則が実際にどのように働くかを次の例で説明します。

41.1.10.4.1 シナリオA: 含まれているネーミング・コンテキストが、別のオブジェクトに含まれているネーミング・コンテキストのサブツリーになっている

使用例A: あるネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストのサブツリーになっている

この例では、ネーミング・コンテキスト・オブジェクト2の包含ネーミング・コンテキストが、オブジェクト1の包含ネーミング・コンテキストのサブツリーになっているとします。

ネーミング・コンテキスト・オブジェクト1

dn:cn=namectx001,
 cn=replication namecontext,
 orclagreementid=unique_identifier_of_the_replication_agreement,
 orclreplicaid=unique_identifier_of_the_supplier,
 cn=replication configuration
orclincludednamingcontexts: cn=mycompany

図41-2に示すように、ネーミング・コンテキスト・オブジェクト1には、cn=myCompanyの下のDIT全体が含まれます。

図41-2 ネーミング・コンテキスト・オブジェクト1

DIT全体が含まれます。

ネーミング・コンテキスト・オブジェクト2

dn:cn=namectx002,
 cn=replication namecontext,
 orclagreementid=unique_identifier_of_the_replication_agreement,
 orclreplicaid=unique_identifier_of_the_supplier,
 cn=replication configuration
orclincludednamingcontexts: cn=hr,c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany
orclexcludedattributes: userPassword

図41-3に示すように、ネーミング・コンテキスト・オブジェクト2には、cn=hr,c=us,cn=mycompanyの下のDITが含まれますが、cn=user1および属性userPasswordは除外されます。

図41-3 ネーミング・コンテキスト・オブジェクト2

この図については本文で説明しています。

ネーミング・コンテキスト・オブジェクトの1と2を組み合せた結果を図41-4に示します。

図41-4 ネーミング・コンテキスト・オブジェクトの1と2を組み合せた結果

この図については本文で説明しています。

このシナリオでは、レプリケートされるネーミング・コンテキストが、orclincludednamingcontexts属性で指定された最上位のコンテキストとなります。除外されたネーミング・コンテキストはレプリケートされません。cn=user1,cn=hr,c=us,cn=mycompany、および除外されているcn=hr,c=us,cn=mycompanyの下の属性userPasswordを除き、サブツリーcn=mycompanyの下の変更すべてがレプリケートされます。ただし、userPasswordの除外はネーミング・コンテキスト・オブジェクト2(cn=hrの下のDITにのみ含まれます)に対してのみ指定されたものであるため、残りのDITの下にある属性userPasswordは、レプリケーションから除外されません。

41.1.10.4.2 シナリオB: 含まれているネーミング・コンテキストが、別のオブジェクトで除外されているネーミング・コンテキストのサブツリーになっている

使用例B: あるネーミング・コンテキスト・オブジェクトで、レプリケーションに含まれるネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトで、レプリケーションから除外されるネーミング・コンテキストのサブツリーになっている

この例では、ネーミング・コンテキスト・オブジェクト4の除外ネーミング・コンテキストが、オブジェクト3で定義されている除外ネーミング・コンテキストのサブツリーになっているとします。

ネーミング・コンテキスト・オブジェクト3

dn:cn=namectx001,cn=replication namecontext,
 orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=us,cn=mycompany	

図41-5に示すように、ネーミング・コンテキスト・オブジェクト3では、c=us,cn=mycompanyの下にあるすべてのものが除外されます。

図41-5 ネーミング・コンテキスト・オブジェクト3

cn=usの下にあるすべてのものが除外されます

ネーミング・コンテキスト・オブジェクト4

dn:cn=namectx002,cn=replication     
 namecontext,orclagreementid=identifier,orclreplicaid=supplier,
 cn=replication configuration
orclincludednamingcontexts: cn=hr, c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr,c=us,cn=mycompany
orclexcludedattributes: userPassword

図41-6に示すように、ネーミング・コンテキスト・オブジェクト4には、cn=hr,c=us,cn=mycompanyの下のDITが含まれますが、user1およびすべてのユーザーのuserPassword属性は除外されます。

図41-6 ネーミング・コンテキスト・オブジェクト4

この図については本文で説明しています。

ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果を図41-7に示します。

図41-7 ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果

ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果

この使用例では、ネーミング・コンテキスト・オブジェクト4に指定した、レプリケーションに含まれるネーミング・コンテキストはレプリケートされません。このネーミング・コンテキストは、ネーミング・コンテキスト・オブジェクト3で指定された除外ネーミング・コンテキストのサブツリーです。その場合、ネーミング・コンテキスト・オブジェクト4は無視され、cn=hr,c=us,cn=mycompanyの下の変更はレプリケートされません。

41.1.10.5 ネーミング・コンテキストおよび属性を含める/除外するためのルール

Oracle Internet Directoryには、ネーミング・コンテキストおよび属性を含めるルールと除外するルールがあります。

次のネーミング・コンテキストはレプリケートできません。

  • DSEルート固有のエントリ

  • orclagreementid=000001,cn=replication configuration

  • cn=subconfigsubentry

  • cn=Oracle Internet Directory

  • cn=subregistrysubentry

次のネーミング・コンテキストはレプリケーションから除外できません。

  • cn=catalogs

  • cn=subschemasubentry

  • cn=oracleschemaversion

  • cn=replication configuration

次の属性は、必須またはオプションに関係なく、レプリケーションから除外できません。これらの属性をレプリケーションから除外するように指定しても、常にレプリケートされます。

  • orclguid

  • creatorsname

  • createtimestamp

  • cn

  • dn

  • attributetypes

  • objectclasses

  • objectclass

  • orclindexedattribute

  • orclproductversion

レプリケーションから必須属性を除外することはできません。たとえば、属性mandatory_attribute_1optional_attribute_1およびoptional_attribute_2を含むmy_object_classという名前のオブジェクト・クラスがあるとします。この場合、レプリケーションからmandatory_attribute_1を除外することはできません。

エントリの必須属性である属性をレプリケーションから除外しようとしても、レプリケーション・サーバーはその属性をレプリケートします。

部分レプリケーションでは、moddn操作を使用してネーミング・コンテキストが包含から除外に変更されると、レプリケーション・サーバーによりコンシューマ側でネーミング・コンテキストが削除されます。同様に、サプライヤ側でmodnを使用してネーミング・コンテキストが除外から包含に変更されると、レプリケーション・サーバーにより、サプライヤからコンシューマまで、ネーミング・コンテキスト全体が同期化されます。

41.1.10.6 部分レプリケーションのネーミング・コンテキストの最適化によるパフォーマンスの向上

部分レプリケーションは慎重に計画して、レプリケーション・プロセスのパフォーマンスを低下させないようにする必要があります。最高のパフォーマンスを得るには、使用するネーミング・コンテキスト・オブジェクトの数をできるだけ少なくします。たとえば、ネーミング・コンテキスト・オブジェクトの5と6を組み合せる場合も、ネーミング・コンテキスト・オブジェクト7を使用する場合も、実行される条件は同じですが、パフォーマンスは、ネーミング・コンテキスト・オブジェクト7を使用する方がよくなります。

ネーミング・コンテキスト・オブジェクト5

cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=europe,cn=mycompany
orclexcludedattributes: userPassword

ネーミング・コンテキスト・オブジェクト5を図41-8に示します。これにはcn=mycompanyの下のDITが含まれますが、c=europeの下にあるすべては除外されます。また、属性userPasswordも除外されます。

図41-8 ネーミング・コンテキスト・オブジェクト5

この図については本文で説明しています。

ネーミング・コンテキスト・オブジェクト6

cn=namectx002,cn=replication namecontext,orclagreementid=<id>,orclreplicaid=<supplier>,cn=replication configuration
orclincludednamingcontexts: cn=hr, c=us,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany
orclexcludedattributes: userPassword

ネーミング・コンテキスト・オブジェクト6を図41-9に示します。これにはcn=hr, c=us, cn=mycompanyの下のDITが含まれますが、user1および属性userPasswordは除外されます。

図41-9 ネーミング・コンテキスト・オブジェクト6

この図については本文で説明しています。

ネーミング・コンテキスト・オブジェクトの5と6を組み合せた場合は、cn=europe,c=mycompanycn=user1,cn=hr,c=us,cn=mycompany、および属性userPasswordを除いて、cn=mycompanyの下の変更がすべてレプリケートされます。

ただし、同じ条件はネーミング・コンテキスト・オブジェクト7でも実現できます。使用するネーミング・コンテキスト・オブジェクトが1つのみの場合、部分レプリケーションのパフォーマンスが向上します。

ネーミング・コンテキスト・オブジェクト7

cn=namectx001,cn=replication namecontext,orclagreementid=identifier,orclreplicaid=supplier,cn=replication configuration
orclincludednamingcontexts: cn=mycompany
orclexcludednamingcontexts: c=europe,cn=mycompany
orclexcludednamingcontexts: cn=user1,cn=hr, c=us,cn=mycompany
orclexcludedattributes: userPassword

ネーミング・コンテキスト・オブジェクト7を図41-10に示します。

図41-10 ネーミング・コンテキスト・オブジェクト7

ネーミング・コンテキスト・オブジェクト7

41.2 Oracle Directory Services Managerを使用したレプリケーションのテスト

次を実行することにより、Oracle Directory Services Managerを使用してディレクトリ・レプリケーションをテストします。

  1. 「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。
  2. タスク選択バーで、「データ・ブラウザ」を選択します。
  3. 「Oracle Directory Services Managerを使用した新規エントリの追加」で説明したように、MDSノード上に単一のエントリを作成します。

    同一のエントリが、RMSに約1から10分後に表示されます。このタイミングは、レプリケーション・サーバーの構成設定エントリで調整できます。エントリがDRGのいずれかのノードで変更されると、その変更はレプリケートされます。

41.3 コマンド行を使用したLDAPベースのレプリケーションの設定

コマンド行を使用してLDAPベースのレプリケーションを設定できます。

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

41.3.1 ldifwriteとbulkloadを使用したLDAPデータのコピー

ldifwriteおよびbulkloadを使用すると、LDAPデータを1つのホストから別のホストへコピーできます。

操作属性を保持してLDAPデータをバックアップするには、ldifwriteユーティリティを使用します。この操作を実行した後は、bulkloadユーティリティを使用して、グループ内のすべてのレプリカにデータをロードします。

まず引数check="TRUE"generate="TRUE"およびrestore="TRUE"を指定し、次に引数load="TRUE"を指定してbulkloadを使用します。すべてのレプリカに同じ中間ファイル(generate="TRUE"引数を使用して生成)を使用することにより、操作属性を保存します。connect="connect_string"をレプリカごとに適切な接続文字列を指定して使用することにより、bulkloadコマンドの1回の起動で複数のレプリカをロードできます。

100万件のエントリがあるディレクトリの場合、この方法では長時間かかります。

41.3.2 カスタム設定を使用したLDAPベースのレプリカの設定

カスタム設定を確立するには、まず新しいノードをインストールする必要があります。

新規ノードをインストールするには、『Oracle Identity Managementのインストールと構成』の手順に従います。

remtoolを使用してLDAPベースのレプリケーションを構成した後、LDAPベースのノードに対してレプリケートされる項目を定義するnamingcontextをカスタマイズできます。

関連項目:

「LDAPベースの部分レプリケーションの意味」のネーミング・コンテキストの説明。

カスタム設定を使用してLDAPベースのレプリカを設定するには、ディレクトリのデータをどのように移行するかによって、2つの方法があります。

  • コマンド行ツールを使用します。ldifwriteを使用してサプライヤ・レプリカのデータをバックアップした後、bulkloadを使用してコンシューマ・レプリカにデータをリストアします。

  • 自動ブートストラップを使用します。これはレプリケーション・サーバーの機能で、レプリケーション構成に基づいてサプライヤ・レプリカからコンシューマ・レプリカにデータを自動的にブートストラップします。

表41-1に、2つの方法の比較を示します。

次の各項では、これらの方法についてさらに詳しく説明しています。

41.3.2.1 ldifwrite/bulkloadを使用したデータ移行と自動ブートストラップを使用したデータ移行の比較

様々な適合シナリオでデータ移行を行うには、ldifwrite/bulkloadまたは自動ブートストラップ方法を使用する必要があります。

表41-1 ldifwrite/bulkloadを使用したデータ移行と自動ブートストラップを使用したデータ移行の比較

ldifwrite/bulkloadを使用した移行 自動ブートストラップを使用した移行

手動プロシージャ

高速パフォーマンス

大量のデータに最適

自動プロシージャ

部分レプリケーションのフィルタ機能を使用

エントリ数が少ない場合に最適

ノート:

次のシナリオでは、レプリケーションを設定および変更するコマンド行ツール(ldifwriteおよびbulkload)を使用する必要があります。

  • 100,000を超えるエントリを持つディレクトリのレプリケーション

他のシナリオでは、どちらの移行方法も使用できます。

41.3.2.2 自動ブートストラップを使用したLDAPベースのレプリカの設定
41.3.2.2.1 サプライヤ・ノードでのディレクトリ・サーバーの特定と起動

LDAPベースのレプリカのサプライヤを特定できます。次のいずれかがサプライヤとなります。

  • レプリケーション・グループのメンバーではないディレクトリ

  • マルチマスター・レプリケーション・グループのノード

  • 別のLDAPベースのレプリカ

サプライヤ・ノードでOracle Internet Directoryサーバーが起動していることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します:

start(name='instance-name',type='OID')
41.3.2.2.2 Oracle Internet Directoryのインストールによる新規コンシューマ・ノードの作成

『Oracle Identity Managementのインストールと構成』の説明に従って、レプリカに新しいOracle Internet Directoryをインストールします。

41.3.2.2.3 新規コンシューマ・ノードのメタデータのバックアップ

カスタム設定を使用して新規ノードをLDAPベースのレプリカとして構成する前に、まず新規ノードのメタデータを次のようにサプライヤ・ノードに移行する必要があります。

  • バックアップ・プロセス(remtool –backupmetadata)が正しく機能するように、「Oracle Internet Directoryのインストールによる新規コンシューマ・ノードの作成」の説明に従って、Oracle Internet Directoryサーバーがサプライヤ・ノードと新規に作成したノードの両方で稼働していることを確認します。

  • 新たに作成したノードから、次のコマンドを実行します。

    remtool –backupmetadata \
            –replica "new_node_host:new_node_port" \
            –master "master_host:master_port" 
    

    master_host:master_portは、対象となるレプリカのサプライヤのホスト名およびポート番号です。レプリケーション識別名のパスワードを要求されます。

    関連項目:

    -backupmetadataを含めたremtoolオプションの詳細は、『Oracle Identity Managementリファレンス』remtoolコマンド行ツールのリファレンスを参照してください。

  • このコマンドは、メタデータをマスター・レプリカにロードする以外に、メタデータのバックアップを含むocbkup.new_replica_id.TO.master_replicaid.timestamp.ldifという名前のファイルを作成します。このファイルは、$DOMAIN_HOME /tools/OID/logsディレクトリに作成されます。このファイルには、LDIF形式でのマスター・レプリカの変更と、SSOのコンテナ・エントリ[orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext]およびDASのURLコンテナ・エントリ[cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext]のコピーが格納されます。

  • メタデータのバックアップに成功した場合、次のメッセージが端末に表示されます。

    Backup of metadata will be stored in $DOMAIN_HOME/tools/OID/logs/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
    
    Metadata copied successfully.
    

    このメッセージには、DOMAIN_HOMEのパスとファイル名が含まれています。

  • メタデータのバックアップに失敗した場合、$DOMAIN_HOME/tools/OID/logs/remtool.logファイルにエラー・メッセージが記録されます。remtoolを端末から起動した場合は、その端末にエラー・メッセージが表示されます。

41.3.2.2.4 レプリケーション環境管理ツールを使用したLDAPベースのレプリカの追加

LDAPベースのレプリカを追加するには、コンシューマ・レプリカで次のように入力します。

remtool -paddnode [-v] [-bind supplier_host_name:port]

replication_dn_passwordの入力を要求されます。

remtoolユーティリティから承諾のタイプの指定を求められます。追加するレプリカのタイプに応じて、一方向LDAP、双方向LDAPまたはマルチマスターLDAPのいずれかを選択します。

サプライヤのレプリカIDを要求されます。これは、ルートDSEエントリの属性orclreplicaidの値です。指定する値を検索するには、次のように入力します:

ldapsearch -D cn=orcladmin -q  -p port -b "" -s base "objectclass=*" orclreplicaid

サプライヤ・レプリカで使用できるネーミング・コンテキストのリストが要求されます。異なるバージョンのOracle Internet Directoryが稼働するサーバー・インスタンス間での部分レプリケーションを設定する場合、「e」と入力します。

remtoolが正常に完了したら、次のようにしてレプリケートされるサブツリーごとに異なるネーミング・コンテキストを追加します。

  1. サプライヤ・レプリカ・ノードとコンシューマ・レプリカ・ノードの両方で次の検索コマンドを実行し、両ノードのレプリカIDを確認します。
    ldapsearch -h host -p port -D cn=orcladmin -q -b "" \
       -s base "objectclass=*" orclreplicaid
    
  2. レプリケーション承諾エントリを確認します。形式は次のとおりです。
    "orclagreementid=unique_identifier_of_the_replication_agreeement,orclreplicaid=supplier_replica_id,cn=replication configuration"
    

    これを検索するには、次のように入力します:

    ldapsearch -D cn=orcladmin -q -h supplier_host -p supplier_port \
       -b "orclreplicaid=supplier_replica_id,cn=replication configuration" \
       -s sub "(&(orclreplicadn=*consumer_replica_id*)(objectclass=orclreplagreemententry))" dn
    
  3. コンシューマ・レプリカ・ノードとサプライヤ・レプリカ・ノードの両方で、レプリケーションに含めるネーミング・コンテキストごとに次のようなエントリを追加します。次のLDIFファイルでは、レプリケーションに含めるネーミング・コンテキスト(サブツリー)およびレプリケーションから除外する属性を指定します。
    dn: cn=includednamingcontext000002,
     cn=replication namecontext,orclagreementid=000003,
     orclreplicaid=stajv18_oid10143,cn=replication configuration
    objectclass: top
    objectclass: orclreplnamectxconfig
    orclincludednamingcontexts: cn=users,dc=small,dc=com
    orclexcludedattributes: userpassword
    orclexcludedattributes: telephonenumber
    cn: includednamingcontext000002
    

    次のLDAP追加コマンドを使用して、コンシューマ・レプリカとサプライヤ・レプリカのOracle Internet DirectoryにLDIFファイルを追加します。

    ldapadd -D cn=orcladmin -q -h host -p port -v -f ldif_file
    
  4. 部分レプリケーションに構成するネーミング・コンテキスト(サブツリー)ごとに、前のステップを繰り返します。

関連項目:

41.3.2.2.5 自動ブートストラップ用のコンシューマ・レプリカの構成

自動ブートストラップ機能を使用するには、コンシューマ側で、次のようにコンシューマ・レプリカのサブエントリのorclReplicaState属性を0に設定します。

  1. サンプル・ファイルmod.ldifを、次のように編集します。
    Dn: orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration
    Changetype:modify
    replace:orclReplicaState
    OrclReplicaState: 0
    

    ノート:

    WindowsシステムではorclReplicaStateの値を0に変更してブートストラップを有効にする前に、レプリケーション・サーバーが稼働していないことを確認します。

  2. コンシューマ側でldapmodifyを使用して、コンシューマ・レプリカのサブエントリのorclreplicastate属性を更新します。
    ldapmodify –D "cn=orcladmin" -q -h consumer_host -p port -f mod.ldif
    

    関連項目:

    LDAPベースのレプリケーションのブートストラップ機能の詳細は、「レプリケーションの管理およびモニタリング」を参照してください

41.3.2.2.6 デフォルトのレプリケーション・パラメータの変更

レプリケーション承諾およびレプリカ・サブエントリのデフォルトのパラメータを変更できます。

41.3.2.2.7 ディレクトリ・レプリケーション・サーバーの起動の確認

レプリケーション・サーバーを起動する正確な手順は、サーバーが一方向レプリカ、双方向レプリカまたはマルチマスター・レプリカのいずれにあるのかによって異なります。

  • 一方向LDAPレプリケーションの場合は、コンシューマでレプリケーション・サーバーを起動する必要があります。たとえば、oid1にあるレプリケーション・サーバーを起動するには、次を入力します。

    oidctl connect=connStr server=oidrepld instance=1 \
      name=asinst_1 component name=oid1 \
      flags="-h consumer_host -p consumer_port" start
    

    ノート:

    読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合、競合解消をオフにすると、パフォーマンス・オーバーヘッドを低減できます。これを行うには、ldapmodifyで次のLDIFファイルを使用して、orclconflresolutionの値を0に変更します。

     dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry   
     changetype: modify
     replace: orclconflresolution
     orclconflresolution: 0 
  • 双方向またはマルチマスターLDAPレプリケーションの場合は、次のように各ノードでOracle Internet Directoryレプリケーション・サーバーを起動する必要があります。

    oidctl connect=connStr server=oidrepld instance=1 \
       name=instance_name componentname=component_name flags="-h \
       LdapHost -p LdapPort" start
    

レプリケーション・サーバーが起動すると、サプライヤからコンシューマへのデータのブートストラップが開始されます。ブートストラップが正常に完了すると、レプリケーション・サーバーが自動的にオンライン・モード(orclreplicastate=1)に変わり、変更内容をサプライヤからコンシューマに適用します。次のコマンド行を使用してorclreplicastateの値をモニターできます。

ldapsearch -p port-h host -D cn=orcladmin -q \
  -b "orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration" \
  -s base "objectclass=*" orclreplicastate 
41.3.2.3 ldifwriteツールを使用したLDAPベースのレプリカの設定

この項では、ldifwriteツールを使用して、LDAPベースのレプリカを構成する場合に実行する一般的なタスクについて説明します。この項の内容は、次のとおりです。

41.3.2.3.1 サプライヤ・ノードとコンシューマ・ノードの両方でのディレクトリ・サーバーの起動

サプライヤ・ノードとコンシューマ・ノードの両方でディレクトリ・サーバーを起動するには:

  1. LDAPベースのレプリカのサプライヤを特定します。次のいずれかがサプライヤとなります。
    • レプリケーション・グループのメンバーではないディレクトリ

    • マルチマスター・レプリケーション・グループのノード

    • 別のLDAPベースのレプリカ

    サプライヤ・ノードでOracle Internet Directoryサーバーが起動していることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します:

    $DOMAIN_HOME/bin/startComponent.sh <instance-name>
    
  2. コンシューマ・ノードを識別し、このノードにOracle Internet Directoryを新しくインストールする必要があります。新しいOracle Internet Directoryをマスターとしてインストールするには、『Oracle Identity Managementのインストールと構成』の指示に従って、Oracle Internet Directoryサーバーが新規コンシューマ・ノードで起動されることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します:
    $DOMAIN_HOME/bin/startComponent.sh <instance-name>
    
41.3.2.3.2 新規コンシューマ・ノードのメタデータのバックアップ

カスタム設定を使用してコンシューマをLDAPベースのレプリカとして構成する前に、まずコンシューマのメタデータを次のようにサプライヤ・ノードに移行する必要があります。

  • バックアップ・プロセス(remtool –backupmetadata)が正しく機能するように、「Oracle Internet Directoryのインストールによる新規コンシューマ・ノードの作成」の説明に従って、Oracle Internet Directoryサーバーがサプライヤ・ノードと新規に作成したノードの両方で稼働していることを確認します。

  • コンシューマ・ノードから、次のコマンドを実行します。

    remtool –backupmetadata \
            –replica "consumer_host:consumer_port" \
            –master "supplier_host:supplier_port"   
    

    パスワードが要求されます。

  • このツールは、メタデータをマスター・レプリカにロードする以外に、メタデータのバックアップを含むocbkup.consumer_replica_id.TO.supplier_replica_id.timestamp.datという名前のファイルを作成します。このファイルは、$DOMAIN_HOME/tools/OID/logsディレクトリに作成されます。このファイルには、LDIF形式でのマスター・レプリカの変更と、SSOのコンテナ・エントリ[orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContext]およびDASのURLコンテナ・エントリ[cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContext]のコピーが格納されます。

  • メタデータのバックアップに成功した場合、remtoolにより次のメッセージが端末に表示されます。

    Backup of metadata will be stored in $DOMAIN_HOME/tools/OID/logs/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
    
    Metadata copied successfully.
    

    このメッセージには、DOMAIN_HOMEのパスが含まれています。

    このメッセージには、DOMAIN_HOMEの実際のパスとファイル名が含まれています。

    メタデータのバックアップに失敗した場合、$DOMAIN_HOME/tools/OID/logs/remtool.logファイルにエラー・メッセージが記録されます。remtoolを端末から起動した場合は、その端末にエラー・メッセージが表示されます。

41.3.2.3.3 サプライヤ側のディレクトリ・サーバーの読取り専用モードへの切替え

データ整合性を保証するために、サプライヤ・ノードのディレクトリ・サーバーを読取り専用モードに切り替えます。サーバーを読取り/書込みモードから読取り専用モードに切り替えるには、「サーバー・モードの変更」の手順のいずれかを使用します。

41.3.2.3.4 レプリケーション環境管理ツールを使用したLDAPベースのレプリカの追加

レプリカを追加するには、コンシューマ・レプリカで次のように入力します。

remtool -paddnode [-v] [-bind supplier_host_name:port]

replication_dn_passwordの入力を要求されます。remtoolユーティリティから承諾のタイプの指定を求められます。追加するレプリカのタイプに応じて、一方向LDAPまたは双方向LDAPのいずれかを選択します。

関連項目:

レプリケーション環境管理ツールの詳細は、『Oracle Identity Managementリファレンス』remtoolコマンド行ツールのリファレンスを参照してください

41.3.2.3.5 レプリケートするネーミング・コンテキストのバックアップ

LDAPベースのレプリカにレプリケートするエントリが、ネーミング・コンテキスト内に大量にある場合は、サプライヤ・ノードでこれらのネーミング・コンテキストをバックアップし、それをLDAPベースのレプリカにロードすることをお薦めします。

ネーミング・コンテキストをバックアップするには:

  1. 「レプリケーション環境管理ツールを使用したLDAPベースのレプリカの追加」で作成したレプリケーション承諾識別名を特定します。
    ldapsearch -h supplier_host -p port \
               -b "orclreplicaid=supplier_replicaID,cn=replication configuration" \
               -s sub "(orclreplicadn= orclreplicaid=consumer_replica_ID, \
                        cn=replication configuration)" dn
  2. サプライヤ側で、DOMAIN_HOMEが設定されていることを確認し、次のコマンドを使用してサプライヤからデータを取得します。ファイルにロードされたデータは、構成済の承諾に基づきます。
    ldifwrite connect="connect_string_of_sponsor_node" \
              baseDN="replication_agreement_dn_retrieved_in_step_1" \
              file="name_of_output_LDIF_file"
    

    関連項目:

41.3.2.3.6 サプライヤ側のディレクトリ・サーバーの読取り/書込みモードへの切替え

「サプライヤ側のディレクトリ・サーバーの読取り専用モードへの切替え」を実行した場合は、サプライヤ側のディレクトリ・サーバーを読取り/書込みモードに戻します。「サーバー・モードの変更」の手順のいずれかを使用します。

41.3.2.3.7 新規コンシューマへのデータのロード

新規コンシューマにデータをロードするには:

  1. 複数のファイルがある場合は、たとえば、backup_data.ldifなどの1つのファイルにまとめます。
  2. LDAPベースのコンシューマ・レプリカにネーミング・コンテキストがある場合は、bulkdeleteを使用して削除します。DOMAIN_HOMEが設定されていることを確認し、次のように入力します。
    bulkdelete connect="connect_string_of_replica" baseDN="naming_context" 

「レプリケートするネーミング・コンテキストのバックアップ」でバックアップしたネーミング・コンテキストについて、このステップを実行します。

コンシューマ側で、bulkloadを追加モードで使用してデータをレプリカにロードします。DOMAIN_HOMEが設定されていることを確認し、次のように入力します。

bulkload connect="connect_string_of_replica" append="TRUE" check="TRUE" \
   generate="TRUE" restore="TRUE" file="backup_data.ldif"

bulkload connect="connect_string_of_replica" load="TRUE"

関連項目:

  • デフォルト・モードまたは追加モードでbulkloadを使用する方法は、『Oracle Identity Managementリファレンス』bulkloadコマンド行ツールのリファレンスを参照してください

  • 『Oracle Identity Managementリファレンス』bulkdeleteコマンド行ツールのリファレンス

41.3.2.3.8 デフォルトのレプリケーション・パラメータの変更

レプリケーション承諾、レプリカ・サブエントリ、およびレプリケーション・ネーミング・コンテキスト構成オブジェクトのデフォルトのパラメータを変更できます。この作業はオプションです。

41.3.2.3.9 ディレクトリ・レプリケーション・サーバーの起動の確認

レプリケーション・サーバーを起動する正確な手順は、サーバーが一方向レプリカまたは双方向レプリカのいずれにあるのかによって異なります。

  • 一方向LDAPレプリケーションの場合は、コンシューマでレプリケーション・サーバーを起動する必要があります。次のように入力します:

    oidctl connect=connStr server=oidrepld instance=1 \
       name=instance_name componentname=oidComponentName \
       flags="-h LdapHost -p LdapPort" start
    

    ノート:

    読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合、競合解消をオフにすると、パフォーマンス・オーバーヘッドを低減できます。これを行うには、ldapmodifyで次のLDIFファイルを使用して、orclconflresolutionの値を0に変更します。

     dn: cn=configset0,cn=osdrepld,cn=subconfigsubentry     
     changetype: modify
     replace: orclconflresolution
     orclconflresolution: 0  
  • 双方向LDAPレプリケーションの場合は、スポンサ・レプリカと新規レプリカの両方で、Oracle Internet Directoryレプリケーション・サーバーを次のように起動する必要があります。

    1. スポンサ・レプリカでレプリケーションを起動または再起動します。次のように入力します:

      oidctl connect=connStr server=oidrepld instance=1 \
         name=instance_name componentname=component_name \
         flags="-h LdapHost -p LdapPort" start
      
    2. 新規レプリカでレプリケーション・サーバーを起動します。次のように入力します:

      oidctl connect=connStr server=oidrepld instance=1 \
         name=instance_name componentname=oidComponentName \
         flags="-h LdapHost -p LdapPort" start
      

41.3.3 LDAPベースのレプリカの削除

この項ではLDAPベースのレプリカを削除する方法について説明します。

この項では、次の項目について説明します。

ノート:

別のレプリカのサプライヤになっているレプリカは、削除できません。このようなレプリカを削除するには、先にそのすべてのコンシューマをレプリケーション・グループから削除する必要があります。

41.3.3.1 削除するノードでのディレクトリ・レプリケーション・サーバーの停止

次のように入力し、Oracleディレクトリ・レプリケーション・サーバーを停止します。

oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \
 flags="-h LdapHost -p LdapPort" stop
41.3.3.2 レプリケーション・グループからのレプリカの削除

レプリケーション環境管理ツールを使用して、レプリケーション・グループからレプリカを削除できます。次のように入力します。

remtool -pdelnode [-v] [-bind hostname:port_number]

パスワードの入力を求められます。replication_dn_passwordの値を入力します。

関連項目:

『Oracle Identity Managementリファレンス』remtoolコマンド行ツールのリファレンス

41.4 シナリオ: ファンアウトと組み合せたマルチマスター・レプリケーション・グループの設定

次のトピックでは、マルチマスター・レプリケーション・グループを設定する方法について説明します。

41.4.1 マルチマスター・レプリケーションの理解

この項では、ファンアウトと組み合せたマルチマスター・レプリケーション・グループの設定に役立つ例を4つのシステムを使用して示します。

表41-2を参照してください。

表41-2 部分レプリケーション・デプロイメント例におけるノード

ノード ホスト名 Port

Node1

mycompany1.com

3000

Node2

mycompany2.com

4000

Node3

mycompany3.com

5000

Node4

mycompany4.com

6000

Node5

mycompany5.com

7000

この例では、ユーザーが次の要件に従って設定を済ませています。

  • 要件1: いずれかのノードに加えられた変更が他のノードにレプリケートされるように、ノード1とノード2とを同期させる必要がありますが、ネーミング・コンテキストcn=private users, cn=mycompanyは、このレプリケーションから除外されます。

  • 要件2: ノード2のou=Americas, cn=mycompanyの下で行われた変更のみがノード3にレプリケートされるように、ノード3のネーミング・コンテキストou=Americas,cn=mycompanyは、ノード2から部分的に同期させます。このレプリケーションから除外される対象は、次のとおりです。

    • cn=customer profile, ou=Americas, cn=mycompanyの下で行われた変更

    • userpassword属性に加えられた変更

  • 要件3: ノード4は、ノード2の完全レプリカとして構成します。つまり、ノード2のすべてのネーミング・コンテキストに対する変更がノード4にレプリケート(一方向)されます。

  • 要件4: ノード5は、ノード1の双方向(更新可能)の完全なレプリカとして構成します。

図41-11 ファンアウト・レプリケーションの例

図41-11の説明が続きます
「図41-11 ファンアウト・レプリケーションの例」の説明

この例の最初の要件を満たすには、ノード1およびノード2のマルチマスター・レプリケーション・グループを設定します。2番目を満たすには、ノード2およびノード3に対して部分レプリカを設定し、3番目を満たすには、ノード2からノード4に対して完全なLDAPレプリケーションを行います。

41.4.2 ノード1およびノード2を対象としたマルチマスター・レプリケーション・グループの設定

この項では、ノード1とノード2にLDAPベースのマルチマスター・レプリケーション・グループを設定する方法を示します。

ノード1とノード2のLDAPベースのマルチマスター・レプリケーション・グループを設定するには、「カスタム設定を使用したLDAPベースのレプリカの設定」の手順に従います

41.4.3 レプリケーション承諾の構成

ノード1とノード2間のレプリケーション承諾では、orclExcludedNamingcontexts属性の値を、cn=private users,cn=mycompanyとして指定します。

次のステップを実行します。

  1. サンプル・ファイルmod.ldifを、次のように編集します。
    dn: orclAgreementID=000001,cn=replication configuration
    Changetype:modify
    Replace: orclExcludedNamingcontexts
    orclExcludedNamingcontexts: cn=private users,cn=mycompany
    
  2. ldapmodifyを使用して、ノード1とノード2のレプリケーション承諾のorclExcludedNamingcontexts属性を更新します。これを行うには、次のように入力します:
    ldapmodify -D "cn=orcladmin" -q -h mycompany1.com -p 3000 -f mod.ldif
    ldapmodify -D "cn=orcladmin" -q -h mycompany2.com -p 4000 -f mod.ldif

41.4.4 ノード1およびノード2でのレプリケーション・サーバーの起動

ノード1およびノード2でレプリケーション・サーバーを起動するには、LDAPベースのレプリケーションを使用する場合、該当する指示に従います

ノード1およびノード2でレプリケーション・サーバーを起動するには、LDAPベースのレプリケーションを使用する場合、該当する指示に従います

41.4.5 ノード1とノード2間のディレクトリ・レプリケーションのテスト

この項の手順に従います。

41.4.6 ノード3をノード2の部分レプリカとしてのインストールと構成

部分レプリケーションのブートストラップ機能を使用する場合は、この項の手順に従います。

部分レプリケーションのブートストラップ機能を使用する場合は、「自動ブートストラップを使用したLDAPベースのレプリカの設定」のタスク1から5に従ってください。

ldifwriteツールを使用してレプリカを構成する場合は、「ldifwriteツールを使用したLDAPベースのレプリカの設定」のタスク1から9に従ってください。

ノード2をサプライヤ、ノード3をコンシューマと指定します。

41.4.7 部分レプリケーション承諾のカスタマイズ

この項の説明に従って、部分レプリケーション承諾をカスタマイズできます。

  • この例の要件2を満たすには、まずノード2とノード3の間にデフォルトのレプリケーションを構成する必要があります。

    部分レプリケーションでは、デフォルトでネーミング・コンテキストcn=oraclecontextがレプリケートされます。このネーミング・コンテキストをサプライヤ(ノード2、mycompany2.com)とコンシューマ(ノード3、mycompany3.com)の両方で削除すれば、レプリケートされることはなくなります。

    ldapdelete -D "cn=orcladmin" -q -h mycompany2.com \
               -p 4000 "cn=includednamingcontext000001, \
                        cn=replication namecontext,orclagreementid=000002, \
                        orclreplicaid==node2_replica_id, \
                        cn=replication configuration"
    
    ldapdelete -D "cn=orcladmin" -q -h mycompany3.com \
               -p 5000 "cn=includednamingcontext000001, \
                        cn=replication namecontext,orclagreementid=000002, \
                        orclreplicaid==node2_replica_id, \
                        cn=replication configuration"
    
  • ネーミング・コンテキストou=Americas,cn=mycompanyをレプリケートし、ネーミング・コンテキストcn=customer profile, ou=Americas, cn=mycompanyおよびuserpassword属性をレプリケーションから除外するには、ネーミング・コンテキスト・オブジェクトを次のように作成します。

    1. サンプル・ファイルmod.ldifを、次のように編集します。

      dn: cn=includednamingcontext000002,cn=replication namecontext,
       orclagreementid=000002,orclreplicaid=node2_replica_id,
       cn=replication configuration
      orclincludednamingcontexts: ou=Americas,cn=mycompany
      orclexcludednamingcontexts: cn=customer profile, ou=Americas, cn=mycompany
      orclexcludedattributes: userpassword
      objectclass: top
      objectclass: orclreplnamectxconfig
      
    2. ldapaddを使用して、部分レプリケーションのネーミング・コンテキスト・オブジェクトをノード2とノード3の両方に追加します。

      ldapadd -D "cn=orcladmin" -q -h mycompany2.com -p 4000 -f mod.ldif
      ldapadd -D "cn=orcladmin" -q -h mycompany3.com -p 5000 -f mod.ldif
      
  • 部分レプリケーションの自動ブートストラップ機能を使用する場合は、サンプル・ファイルmod.ldifを編集し、次にldapmodifyを使用して、ノード2とノード3の両方で部分レプリカのorclreplicastate属性を変更します。詳細は、「自動ブートストラップ用のコンシューマ・レプリカの構成」を参照してください。

41.4.8 ディレクトリ・レプリケーション・グループ内の全ノードでのレプリケーション・サーバーの起動

レプリケーション・プロセスを開始する前に、各ノードでレプリケーション・サーバーを起動します。

このためには、各ノードでレプリケーション・サーバーを起動します。

次のように入力します:

oidctl connect=connStr server=oidrepld instance=1 \
   componentname=oidComponentName flags="-h LdapHost -p LdapPort" start

41.4.9 ノード4をノード2の完全なレプリカとしてのインストールと構成

新規ノードがLDAPレプリカとしてインストールされる場合、完全なレプリカ・レプリケーションがデフォルト構成です。

完全レプリカ・レプリケーションがデフォルト構成であるため、新規ノードをLDAPレプリカとしてインストールする場合は、「コマンド行を使用したLDAPベースのレプリケーションの設定」に記載されている指示に従ってください。サプライヤ情報の入力を求められたら、サプライヤのホスト名mycompany2.com、サプライヤのポート4000、およびスーパーユーザーのパスワードを指定します。

41.4.10 ノード2からノード4へのレプリケーションのテスト

示されている項の指示に従って、このレプリケーションをテストします。

示されている項の指示に従って、このレプリケーションをテストします。

41.4.11 ノード5をノード1の双方向レプリカとしてのインストールと構成

この項の手順に従います。

「コマンド行を使用したLDAPベースのレプリケーションの設定」の手順に従います。サプライヤのホスト名mycompany1.com、サプライヤのポート3000、およびスーパーユーザーのパスワードを指定します。

41.4.12 ノード1とノード5間の双方向レプリケーションのテスト

この項の手順に従います。

ldapaddコマンド行ツールを使用して、ノード1にエントリを作成します。エントリがノード5でレプリケートされるのを待機します。エントリがノード5にレプリケートされた後、ldapmodifyコマンド行ツールを使用して、ノード5の該当するエントリに変更を適用します。この変更はノード1にレプリケートされます。