41 レプリケーションの設定
レプリケーションは、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーし、管理するプロセスです。これにより、問合せを処理するサーバーの数が増え、クライアントの近くにデータを持ってくるため、パフォーマンスが向上します。また、シングル・ポイント障害に関連するリスクを排除することで信頼性が向上します。
この章をお読みになる前に、レプリケーションの基本概念の概要について、「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
下の属性orclreplicastate
を0
に設定してブートストラップ・フラグを設定します。
レプリカがブートストラップ・モードの場合、サプライヤ・ノードはオンライン・モード(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)
レプリケーションを次のように設定する必要があります。
- いずれかの10gノードから11gR1のノード1に一方向のLDAPレプリケーションを設定します。
- 11gR1のノード1でレプリケーション・ブートストラップを設定し(エントリ数が100,000未満の場合)、レプリケーション・サーバーを起動します。
- ブートストラップが完了したら、11gR1のノード1および2の間にLDAPマルチマスター・レプリケーションを設定します。
- 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/oidpwdr
Oracle_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.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=user1
、cn=user2
およびcn=user1000
の下には、ユーザー属性リストの一部が示されています。
図41-1 ネーミング・コンテキストのサンプル
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag125.gif)
関連項目:
レプリケーション・ネーミング・コンテキスト・エントリの属性の説明は、『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全体が含まれます。 DIT全体が含まれます。](img/oidag129.gif)
ネーミング・コンテキスト・オブジェクト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
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag130.gif)
ネーミング・コンテキスト・オブジェクトの1と2を組み合せた結果を図41-4に示します。
図41-4 ネーミング・コンテキスト・オブジェクトの1と2を組み合せた結果
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag134.gif)
このシナリオでは、レプリケートされるネーミング・コンテキストが、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の下にあるすべてのものが除外されます cn=usの下にあるすべてのものが除外されます](img/oidag131.gif)
ネーミング・コンテキスト・オブジェクト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
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag130.gif)
ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果を図41-7に示します。
図41-7 ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果
![ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果 ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果](img/oidag131.gif)
この使用例では、ネーミング・コンテキスト・オブジェクト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_1
、optional_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
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag135.gif)
ネーミング・コンテキスト・オブジェクト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
![この図については本文で説明しています。 この図については本文で説明しています。](img/oidag130.gif)
ネーミング・コンテキスト・オブジェクトの5と6を組み合せた場合は、cn=europe,c=mycompany
、cn=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 ネーミング・コンテキスト・オブジェクト7](img/oidag136.gif)
41.2 Oracle Directory Services Managerを使用したレプリケーションのテスト
次を実行することにより、Oracle Directory Services Managerを使用してディレクトリ・レプリケーションをテストします。
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万件のエントリがあるディレクトリの場合、この方法では長時間かかります。
関連項目:
-
『Oracle Identity Managementリファレンス』のコマンド行ツールの概要に関する項
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ベースのレプリカの設定
次の8つのタスクを実行すると、自動ブートストラップを使用して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
が正常に完了したら、次のようにしてレプリケートされるサブツリーごとに異なるネーミング・コンテキストを追加します。
関連項目:
-
レプリケーション環境管理ツールの詳細は、『Oracle Identity Managementリファレンス』の
remtool
コマンド行ツールのリファレンスを参照してください
41.3.2.2.5 自動ブートストラップ用のコンシューマ・レプリカの構成
自動ブートストラップ機能を使用するには、コンシューマ側で、次のようにコンシューマ・レプリカのサブエントリのorclReplicaState
属性を0
に設定します。
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.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ベースのレプリカにロードすることをお薦めします。
ネーミング・コンテキストをバックアップするには:
41.3.2.3.6 サプライヤ側のディレクトリ・サーバーの読取り/書込みモードへの切替え
「サプライヤ側のディレクトリ・サーバーの読取り専用モードへの切替え」を実行した場合は、サプライヤ側のディレクトリ・サーバーを読取り/書込みモードに戻します。「サーバー・モードの変更」の手順のいずれかを使用します。
41.3.2.3.7 新規コンシューマへのデータのロード
新規コンシューマにデータをロードするには:
「レプリケートするネーミング・コンテキストのバックアップ」でバックアップしたネーミング・コンテキストについて、このステップを実行します。
コンシューマ側で、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レプリケーション・サーバーを次のように起動する必要があります。
-
スポンサ・レプリカでレプリケーションを起動または再起動します。次のように入力します:
oidctl connect=connStr server=oidrepld instance=1 \ name=instance_name componentname=component_name \ flags="-h LdapHost -p LdapPort" start
-
新規レプリカでレプリケーション・サーバーを起動します。次のように入力します:
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の双方向(更新可能)の完全なレプリカとして構成します。
この例の最初の要件を満たすには、ノード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
として指定します。
次のステップを実行します。
41.4.4 ノード1およびノード2でのレプリケーション・サーバーの起動
ノード1およびノード2でレプリケーション・サーバーを起動するには、LDAPベースのレプリケーションを使用する場合、該当する指示に従います
ノード1およびノード2でレプリケーション・サーバーを起動するには、LDAPベースのレプリケーションを使用する場合、該当する指示に従います
41.4.5 ノード1とノード2間のディレクトリ・レプリケーションのテスト
この項の手順に従います。
そのためには、「Oracle Directory Services Managerを使用したレプリケーションのテスト」の指示に従います。
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
属性をレプリケーションから除外するには、ネーミング・コンテキスト・オブジェクトを次のように作成します。-
サンプル・ファイル
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
-
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
、およびスーパーユーザーのパスワードを指定します。