レプリケーションは、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーし、管理するプロセスです。これにより、問合せを処理するサーバーの数が増え、クライアントの近くにデータを持ってくるため、パフォーマンスが向上します。また、シングル・ポイント障害に関連するリスクを排除することで信頼性が向上します。
この章をお読みになる前に、レプリケーションの基本概念の概要について、第6章「Oracle Internet Directoryレプリケーションの理解」を参照してください。
この章では、アドバンスト・レプリケーション・ベースのレプリケーションおよびLDAPベースのレプリケーションの両方に共通する情報を示します。この章の手順項目では、LDAPベースのレプリケーション、およびファンアウトと組み合せたマルチマスター・レプリケーションの設定方法について説明します。Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションに固有の情報および手順は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」を参照してください。
関連項目: 高可用性構成でのレプリケーション設定の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。 |
この章の項目は次のとおりです。
注意: この章で言及するOracle Single Sign-OnまたはOracle Delegated Administration ServicesはすべてOracle Single Sign-On 10g(10.1.4.3.0)以上またはOracle Delegated Administration Services 10g(10.1.4.3.0)以上のことです。 |
レプリケーションの基本概念について不明な場合は、この概要の前に第6章「Oracle Internet Directoryレプリケーションの理解」を参照してください。
この概要の項目は次のとおりです。
Oracle Internet Directoryでは、2つのレプリケーション転送メカニズムがサポートされます。
LDAPベースのレプリケーションでは、業界標準のLightweight Directory Access Protocolバージョン3を使用します。一方向、双方向およびマルチマスター構成でLDAPベースのレプリケーションを設定できます。これは、ほとんどの環境に推奨されるプロトコルです。
Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションでは、Oracle Databaseのレプリケーション機能を使用します。マルチマスター構成のみがサポートされます。(グループ内の1つを除き他のすべてのノードを読取り専用モードに切り替えることにより、単一のマスターDRGを作成できます。)
Oracle Single Sign-Onデータをレプリケートする必要がある場合、Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションを使用する必要があります。アドバンスト・レプリケーション・ベースのレプリケーションに固有の情報および手順は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」を参照してください。
remtool -asr2ldap
を使用すると、既存のOracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター承諾をLDAPベースのマルチマスター承諾に変換できます。第39.2項「アドバンスト・レプリケーション・ベースの承諾のLDAPベースの承諾への変換」を参照してください。
関連項目: レプリケーション環境管理ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtool コマンドライン・ツールのリファレンスを参照してください。 |
Oracle Internet Directoryレプリケーションの設定には次の方法を使用できます。
LDAPベース・レプリケーションの設定には、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用する方法をお薦めします。手順は、第39.3項「レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の設定」を参照してください。第42.2.4項「レプリケーション・ウィザードを使用したレプリケーション設定の表示または変更」および第42.2.5項「レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の削除」で説明するように、このウィザードを使用して既存のレプリケーション承諾を変更することもできます。
アドバンスト・レプリケーション・ベースのレプリケーションを設定するには、コマンドライン・ツールを使用する必要があります。また、コマンドライン・ツールでLDAPベースのレプリケーションも設定できます。
コマンドラインを使用したLDAPベースのレプリケーションの設定方法は、第39.5項「コマンドラインを使用したLDAPベースのレプリケーションの設定」を参照してください。コマンドラインを使用したアドバンスト・レプリケーション・ベースのレプリケーションの設定方法は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」を参照してください。
コマンドラインからレプリケーションを設定する場合、レプリケーション・サーバーの停止および開始には、oidctl
コマンドを使用します。データをバックアップして他のノードにロードするにはバルク・ツールを使用します。いくつかの操作には、LDAPツールを使用します。
また、初期データの移行には、レプリケーション・サーバーのブートストラップ機能を使用できます。
次のような各種レプリケーション関連タスクを実行するには、レプリケーション環境管理ツールのremtool
を使用します。
レプリケーション・グループの設定
既存のOracle Databaseアドバンスト・レプリケーション・ベース承諾からLDAPマルチマスター承諾への変換
レプリカの追加および削除
ディレクトリ・レプリケーション・グループの管理
レプリケーション・バインド識別名パスワードの変更または再設定
データベース・レプリケーション・ユーザーREPADMINパスワードの変更
変更ログの伝播に関する様々なエラーおよびステータス情報の表示
ディレクトリ・レプリケーション・グループでのレプリケーションの進行状況の追跡
関連項目: レプリケーション環境管理ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtool コマンドライン・ツールのリファレンスを参照してください。 |
新規ホスト上では、既存ホストからOracle Databaseをコピーしてレプリケーションを設定できます。これは複雑な手順であり、ほとんどの環境では推奨されません。この手順は、付録L「データベース・コピー・プロシージャを使用したディレクトリ・ノードの追加」を参照してください。
Fusion Middleware Controlのレプリケーション・ウィザードを使用する場合もコマンドラインを使用する場合も、初期データの移行にレプリケーション・サーバーのブートストラップ機能を使用できます。
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
注意:
|
レプリケーションを設定する場合は、各レプリケーション・ホスト上のDIT内にレプリケーション承諾と呼ばれるコンテナを作成します。レプリケーション承諾エントリの属性は、第41.1.3項「レプリケーション承諾エントリ」を参照してください。
Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用する場合は、ウィザードの「設定」ページでの選択に応じて、接続とスケジューリングを制御するレプリケーション承諾属性が指定されます。
このページの選択肢には次があります。
レプリケーション・サーバーが、複数のLDAP操作の実行に同じ接続を使用する(キープ・アライブ)か、LDAP操作ごとに新しい接続を開く(常に新規の接続を使用)のどちらか。
レプリケーションの発生頻度(レプリケーション頻度)。
レプリケーション・サーバーが変更適用プロセスを繰り返す間隔(管理者操作キュー・スケジュール)。変更適用プロセスと管理者操作キューの詳細は、第D.5.1項「マルチマスター・レプリケーション・プロセスがコンシューマに新規エントリを追加する動作」を参照してください。
レプリケーション承諾にはレプリケーション・コンテキストも含まれます。詳細は、第39.1.9項「部分レプリケーションのためのLDAPレプリケーションのフィルタリング」を参照してください。その属性は、第41.1.3項「レプリケーション承諾エントリ」を参照してください。
レプリケーション承諾エントリに加え、DITには、レプリケーションを制御する属性を含む複数のエントリが他にも含まれています。エントリおよびその属性の詳細は、第41章「レプリケーション構成属性の管理」を参照してください。レプリケーションを設定した後で、これらの属性を管理できます。
Oracle Enterprise Manager Fusion Middleware Controlにはレプリケーション・ウィザードから独立した「レプリケーション」ページがあり、これを使用してレプリケーション属性を構成できます。LDAPツールを使用してレプリケーション属性を変更することもできます。その方法については、第42章「レプリケーションの管理および監視」で説明しています。
レプリケーション・アーキテクチャとレプリケーション・プロセスの詳細は、付録D「レプリケーションの動作」を参照してください。
LDAPベースのレプリケーションには次の規則が適用されます。
同じOracle Databaseを使用するOracle Internet Directoryのインスタンスが複数ある場合は、その1つのインスタンスのみをレプリケーション用に設定できます。
LDAPマルチマスター・レプリケーションには、下位互換性がありません。これは、11g リリース1(11.1.1)を実行するレプリカ間でのみサポートされています。
マルチマスター・レプリケーションまたは双方向ファンアウト・レプリケーションの場合は、すべてのノードで同じリリースのOracle Internet Directoryを実行する必要があります。したがって、ローリング・アップグレードの実行中にはレプリケーションをオフに切り替える必要があります。
そのサプライヤより新しいリリースを実行する一方向のファンアウト・レプリカを追加できます。たとえば、図6-5「ファンアウト・レプリケーションの例」では、ノードFで他のノードより新しいリリースを実行できます。
一般に、より新しいバージョンのOracle Internet Directoryで生成された変更内容は、そのバージョンまでアップグレードされていないノードにはレプリケートしません。レプリケートすると、旧リリースでは正しく解析されない情報が変更内容に含まれてしまいます。
具体的には、新しいOracle Internet Directory 11g リリース1(11.1.1.6)のノードを既存のDRGに一方向のファンアウト・レプリカとして追加する場合、DRGの他のノードをアップグレードする必要はありません。他のすべてのレプリケーション・タイプについては、DRGのノードをアップグレードしてから新規ノードを追加します。このことは、既存のノードで10g リリースまたは以前の11g リリースのいずれを実行していても、当てはまります。たとえば、図6-5「ファンアウト・レプリケーションの例」では、Oracle Internet Directory 11g リリース1(11.1.1.6)のノードをノードEとして追加する前に、まずノードA、B、CおよびGを11g リリース1(11.1.1.6)に更新する必要があります。
LDAPベースのレプリケーションでは、ルートDSEのnamingcontexts
属性にリストされているネーミング・コンテキストのみ、コンシューマにレプリケートできます。
関連項目: namingcontextsの詳細は、次の項を参照してください。 |
LDAPベースのレプリカのサプライヤは、レプリケーション・グループのメンバーではないマスター・ノード、マルチマスター・レプリケーション・グループのメンバーまたは別のLDAPベースのレプリカです。
関連項目: Oracle Internet Directoryのインストール方法は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。 |
LDAPベースのレプリカは、別のLDAPベースのレプリカのコンシューマの場合もあります。そのコンシューマはファンアウト・レプリカと呼ばれます。
注意: スキーマが同期していることを確認してください。そうでないと、レプリケーション・サーバーがコンシューマ・レプリカに変更を適用できない場合があります。 |
新規コンシューマ・ノードは空であることが必要です。つまり、Oracle Internet Directoryを新たにインストールする必要があります。
この項の項目は次のとおりです。
認証とは、Oracleディレクトリ・レプリケーション・サーバーが、ディレクトリ・サーバーへの接続時に、サーバー自身の正確なアイデンティティを取得するプロセスです。これは、LDAPセッションがldapbind操作によって確立されたときに発生します。
ディレクトリ・レプリケーション・サーバーが、ディレクトリへのアクセスを許可される前に適切に認証されることが重要です。
ディレクトリ・レプリケーション・サーバーは、一意のアイデンティティとパスワードを使用して、ディレクトリ・サーバーに対する認証を行います。ディレクトリ・レプリケーション・サーバーのアイデンティティは、cn=replication dn,orclreplicaid=
unique_identifier_of_node
,cn=replication configuration
の形式をとります。
ディレクトリ・レプリケーション・サーバーは、起動時、Oracle Internet Directoryのセキュアなウォレットからアイデンティティとパスワードを読み取り、これらの資格証明を使用して認証を行います。レプリケーション・バインド識別名を変更する場合、レプリケーション環境管理ツールの-chgpwd
、-presetpwd
または-pchgwalpwd
オプションを使用する必要があります。レプリケーションのアイデンティティのウォレットは、ORACLE_INSTANCE/OID/admin/oidpwdr
Oracle_SID
にあります。
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtool コマンドライン・ツールのリファレンスを参照してください。 |
注意: 以前のリリースでは、レプリケーション・サーバーを実行するには、ディレクトリ・サーバーで匿名バインドを許可する必要がありました。このリリースではその必要はありません。 |
Oracle Internet Directoryレプリケーションは、SSLの使用に関係なくデプロイできます。レプリケーション・サーバーで、Oracle Internet DirectoryインスタンスのSSLポートにバインドしているかどうかを自動的に検出します。そうである場合、Secure Sockets Layer上で動作します。
SSL暗号化を使用するようにLDAPベースのレプリケーションを構成するには、サプライヤ連絡先情報が含まれているorclReplicaURI
属性に、SSLポートのポート番号を指定します。
SSL暗号化を使用するようにOracle Databaseアドバンスト・レプリケーションを構成するには、Oracle Database Advanced Securityを使用します。『Oracle Database Advanced Security管理者ガイド』のSecure Sockets Layerに関する章を参照してください。
この項では、LDAP部分レプリケーションでネーミング・コンテキストを指定する場合の規則およびベスト・プラクティスについて説明します。この付録には、次の項があります。
LDAPベースのレプリケーションでは、特定のネーミング・コンテキストをレプリケーションに追加し、そのネーミング・コンテキスト内の1つ以上のサブツリーをレプリケーションから除外できます。ネーミング・コンテキスト内の1つ以上の属性もレプリケーションから除外できます。
LDAPベースのレプリケーションでは、レプリケーションに含むことを明示的に指定したネーミング・コンテキストのみがレプリケートされます。しかし、Oracle Databaseアドバンスト・レプリケーションの場合は、デフォルトですべてのネーミング・コンテキストが含まれます。
ネーミング・コンテキストを制御する属性は、第41.1.5項「レプリケーションのネーミング・コンテキスト・オブジェクト・エントリ」を参照してください。Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用してレプリケーションを設定する場合は、各属性を「有効範囲」ページで設定します。
レプリケーションに対して複数のネーミング・コンテキストを構成する場合、フィルタリングは次の規則に基づいて行われます。
各ネーミング・コンテキスト・オブジェクトで定義されて含まれているすべてのネーミング・コンテキストの集合が、レプリケーションに含まれる全体的なネーミング・コンテキストになります。
各ネーミング・コンテキスト・オブジェクトで定義された除外ネーミング・コンテキストの集合が、レプリケーションから除外される全体的なネーミング・コンテキストになります。
1つのネーミング・コンテキスト・オブジェクトでの属性の除外は、そのネーミング・コンテキスト・オブジェクトのみに限定されます。
包含されるネーミング・コンテキストと除外されるネーミング・コンテキストとの間で矛盾がある場合は、除外されるネーミング・コンテキストが優先されます。たとえば、ネーミング・コンテキスト・オブジェクトAの包含ネーミング・コンテキストが、別のネーミング・コンテキスト・オブジェクトBの除外ネーミング・コンテキストのサブツリーだった場合、ネーミング・コンテキスト・オブジェクトBのorclexcludednamingcontexts
で指定されているサブツリーは、レプリケートされません。つまり、ネーミング・コンテキスト・オブジェクトAでのレプリケーションのフィルタリングは無視されます。
2つの異なるバージョンのOracle Internet Directory(10g(10.1.4.0.1)と11g リリース1(11.1.1)など)間での部分レプリケーションを構成する場合、ネーミング・コンテキストを除外できません。そのかわり、レプリケート対象のネーミング・コンテキストを包含コンテキストとして明示的に指定する必要があります。
この項の説明は、図39-1に示すネーミング・コンテキストのサンプルに基づいて行われます。cn=user1
、cn=user2
およびcn=user1000
の下には、ユーザー属性リストの一部が示されています。
関連項目: レプリケーション・ネーミング・コンテキスト・エントリの属性の説明は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のレプリケーション・スキーマ要素に関する説明を参照してください。 |
前述の規則が実際にどのように働くかを次の例で説明します。
使用例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
図39-2に示すように、ネーミング・コンテキスト・オブジェクト1には、cn=myCompany
の下の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
図39-3に示すように、ネーミング・コンテキスト・オブジェクト2には、cn=hr,c=us,cn=mycompany
の下のDITが含まれますが、cn=user1
および属性userPassword
は除外されます。
ネーミング・コンテキスト・オブジェクトの1と2を組み合せた結果を図39-4に示します。
このシナリオでは、レプリケートされるネーミング・コンテキストが、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
は、レプリケーションから除外されません。
使用例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
図39-5に示すように、ネーミング・コンテキスト・オブジェクト3では、c=us,cn=mycompany
の下にあるすべてのものが除外されます。
ネーミング・コンテキスト・オブジェクト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
図39-6に示すように、ネーミング・コンテキスト・オブジェクト4には、cn=hr,c=us,cn=mycompany
の下のDITが含まれますが、user1
およびすべてのユーザーの属性userPassword
は除外されます。
ネーミング・コンテキスト・オブジェクトの3と4を組み合せた結果を図39-7に示します。
この使用例では、ネーミング・コンテキスト・オブジェクト4に指定した、レプリケーションに含まれるネーミング・コンテキストはレプリケートされません。このネーミング・コンテキストは、ネーミング・コンテキスト・オブジェクト3で指定された除外ネーミング・コンテキストのサブツリーです。その場合、ネーミング・コンテキスト・オブジェクト4は無視され、cn=hr,c=us,cn=mycompany
の下の変更はレプリケートされません。
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を使用してネーミング・コンテキストが除外から包含に変更されると、レプリケーション・サーバーにより、サプライヤからコンシューマまで、ネーミング・コンテキスト全体が同期化されます。
部分レプリケーションは慎重に計画して、レプリケーション・プロセスのパフォーマンスを低下させないようにする必要があります。最高のパフォーマンスを得るには、使用するネーミング・コンテキスト・オブジェクトの数をできるだけ少なくします。たとえば、ネーミング・コンテキスト・オブジェクトの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を図39-8に示します。これにはcn=mycompany
の下のDITが含まれますが、c=europe
の下にあるすべては除外されます。また、属性userPassword
も除外されます。
ネーミング・コンテキスト・オブジェクト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を図39-9に示します。これにはcn=hr, c=us, cn=mycompany
の下のDITが含まれますが、user1
および属性userPassword
は除外されます。
ネーミング・コンテキスト・オブジェクトの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を図39-10に示します。
remtool -asr2ldap
を使用して、複数のノード間の既存のOracle Databaseアドバンスト・レプリケーション・ベースの承諾をLDAPマルチマスター承諾に変換できます。情報を入力するようツールから要求されます。次に例を示します。
remtool -asr2ldap
Enter replication administrator's name : repadmin Enter replication administrator's password : Enter global name of MDS : inst1.regress.rdbms.dev.example.com Directory Replication Group (DRG) details : -------- ------------- ----------------------- ------------- ------------- ---- Instance Host Name Global Name Version Replicaid Site Name Type -------- ------------- ----------------------- ------------- ------------- ---- tst1 stacu14 INST1.REGRESS.RDBMS.DEV OID 11.1.1.0. stacu14_tst1 MDS tst12 stacu14 INST2.REGRESS.RDBMS.DEV OID 11.1.1.0. stacu14_tst12 RMS -------- ------------- ----------------------- ------------- ------------- ---- Do you want to continue? [y/n] : y ------------------------------------------------------------------------------ Migrating ASR agreement to LDAP MM agreement... Enter "SYSTEM" user password for "INST2.REGRESS.RDBMS.DEV.EXAMPLE.COM" database at "stacu14" host : Enter "SYSTEM" user password for "INST1.REGRESS.RDBMS.DEV.example.com" database at "stacu14" host : ------------------------------------------------------------------------------ ASR setup has been cleaned up.------------------------------------------------------------------------------
一方向、双方向またはマルチマスターLDAPレプリカを構成するには、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用します。
注意: Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション承諾は、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードを使用して構成できません。これはコマンドラインから行う必要があります。 |
次のようにしてLDAPレプリケーション承諾を構成します。
ホームページの「Oracle Internet Directory」メニューから、「管理」、「レプリケーション管理」の順に選択します。
レプリケーション識別名アカウントへのログインを要求されます。ホスト、ポート、レプリケーション識別名およびレプリケーション識別名のパスワードを入力します。このOIDコンポーネントで匿名ユーザーによるバインドが有効な場合には、レプリケーション識別名、ホストおよびポートの各フィールドは自動的に入力され、グレー表示されます。パスワードの入力のみが必要です。
「作成」アイコンをクリックします。
「タイプ」画面でレプリケーション・タイプ(「一方向レプリケーション」、「双方向レプリケーション」または「マルチマスター・レプリケーション」)を選択します。
「次へ」をクリックします。選択したレプリケーション・タイプが「レプリカ」画面に表示されます。
承諾名を指定します。この名前はすべてのノードで一意である必要があります。
一方向レプリケーションまたは双方向レプリケーションでは、コンシューマ・ノードのホスト、ポート、ユーザー名(レプリケーション識別名)およびレプリケーションのパスワードを入力します。サプライヤ・ノードのフィールドは移入されグレー表示されます。
マルチマスター・レプリケーションでは、セカンダリ・ノードのホスト、ポート、ユーザー名(レプリケーション識別名)およびレプリケーションのパスワードを入力します。プライマリ・ノードのフィールドは移入されグレー表示されます。
「次へ」をクリックして、「設定」ページに移動します。
複数のLDAP操作の実行に同じ接続をレプリケーション・サーバーで使用する場合は、「LDAP接続」フィールドで、「キープ・アライブ」を選択します。サーバーでそれぞれのLDAP操作について新規の接続を開始するには、「常に新規の接続を使用」を選択します。
「レプリケーション頻度」を入力します。
「管理者操作キュー・スケジュール」を入力します。これは、ディレクトリ・レプリケーション・サーバーが変更適用プロセスを繰り返す間隔(秒単位)です。
承諾タイプとして「双方向レプリケーション」または「マルチマスター・レプリケーション」を指定した場合、「レプリケーション・サーバー起動詳細」というセクションが設定ページに含まれます。「サーバーの起動」を選択してサーバー・インスタンスを起動したり、「ブートストラップの有効化」を選択してブートストラップを有効にできます。まずホストを選択し、ホストの「インスタンス名」と「コンポーネント名」を選択します。次に「サーバーの起動」または「ブートストラップの有効化」、あるいはその両方を選択します。
「次へ」をクリックして、「有効範囲」ページに移動します。デフォルトのプライマリ・ネーミング・コンテキストが入力されます。
デフォルト・プライマリ・ネーミング・コンテキスト内でセカンダリ・ネーミング・コンテキストを除外するには、プライマリ・ネーミング・コンテキストを選択して「作成」ボタンをクリックします。その後、手順16に進みます。
別のプライマリ・ネーミング・コンテキストを作成するには、「プライマリ・ネーミング・コンテキストの作成」ボタンをクリックします。これにより、「プライマリ・ネーミング・コンテキスト」ダイアログが起動します。
プライマリ・ネーミング・コンテキストを指定するには、「プライマリ・ネーミング・コンテキスト」フィールドに識別名を手動で入力するか、または「選択」をクリックしてプライマリ・ネーミング・コンテキストとして使用する識別名を参照します。コンテナを選択し、「OK」をクリックします。
セカンダリ・ネーミング・コンテキストを除外するには、「除外されたセカンダリ・ネーミング・コンテキスト」フィールドの下にある「追加」アイコンをクリックします。これによって「除外するセカンダリ・ネーミング・コンテキストの選択」ダイアログが起動されます。ネーミング・コンテキストを選択し、「OK」をクリックします。「除外されたセカンダリ・ネーミング・コンテキスト」フィールドにネーミング・コンテキストが表示されます。
属性を除外するには、「除外された属性」フィールドの下にある「追加」アイコンをクリックします。これによって除外する属性の選択画面が起動されます。除外する属性を選択して「OK」をクリックします。「除外された属性」フィールドにその属性が表示されます。
「OK」をクリックします。プライマリ・ネーミング・コンテキストが「有効範囲」ページに表示されます。
「次へ」をクリックします。作成するレプリケーション承諾の概要が「サマリー」ページに表示されます。
次を実行することにより、Oracle Directory Services Managerを使用してディレクトリ・レプリケーションをテストします。
第7.4.5項「Oracle Directory Services Managerの起動」の説明に従って、Oracle Directory Services Managerを起動し、Oracle Internet Directoryサーバーに接続します。
タスク選択バーで、「データ・ブラウザ」を選択します。
第13.2.6項「Oracle Directory Services Managerを使用した新規エントリの追加」の説明に従って、MDSノード上で単一エントリを作成します。
同一のエントリが、RMSに約1から10分後に表示されます。このタイミングは、レプリケーション・サーバーの構成設定エントリで調整できます。エントリがDRGのいずれかのノードで変更されると、その変更はレプリケートされます。
この項の項目は次のとおりです。
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 Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従ってください。
remtool
を使用してLDAPベースのレプリケーションを構成した後、LDAPベースのノードに対してレプリケートされる項目を定義するnamingcontext
をカスタマイズできます。
カスタム設定を使用してLDAPベースのレプリカを設定するには、ディレクトリのデータをどのように移行するかによって、2つの方法があります。
コマンドライン・ツールを使用します。ldifwrite
を使用してサプライヤ・レプリカのデータをバックアップした後、bulkload
を使用してコンシューマ・レプリカにデータをリストアします。
自動ブートストラップを使用します。これはレプリケーション・サーバーの機能で、レプリケーション構成に基づいてサプライヤ・レプリカからコンシューマ・レプリカにデータを自動的にブートストラップします。
表39-1に、2つの方法の比較を示します。
表39-1 ldifwrite/bulkloadを使用したデータ移行と自動ブートストラップを使用したデータ移行の比較
ldifwrite/bulkloadを使用した移行 | 自動ブートストラップを使用した移行 |
---|---|
手動プロシージャ 高速パフォーマンス 大量のデータに最適 |
自動プロシージャ 部分レプリケーションのフィルタ機能を使用 エントリ数が少ない場合に最適 |
データ移行方法として自動ブートストラップを選択した場合は、第39.5.2.1項「自動ブートストラップを使用したLDAPベースのレプリカの設定」の指示に従って、LDAPベースのレプリカをカスタマイズします。
データ移行方法としてldifwrite/bulkloadを選択した場合は、第39.5.2.2項「ldifwriteツールを使用したLDAPベースのレプリカの設定」の指示に従って、LDAPベースのレプリカを構成します。
次の8つのタスクを実行すると、自動ブートストラップを使用してLDAPベースのレプリカを構成できます。各タスクの詳細は、このリストの後で説明します。
LDAPベースのレプリカのサプライヤを特定します。次のいずれかがサプライヤとなります。
レプリケーション・グループのメンバーではないディレクトリ
マルチマスター・レプリケーション・グループのノード
別のLDAPベースのレプリカ
サプライヤ・ノードでOracle Internet Directoryサーバーが起動していることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します。
opmnctl startproc ias_component=oid1
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の説明に従って、新しいOracle Internet Directoryをレプリカにインストールします。
カスタム設定を使用して新規ノードをLDAPベースのレプリカとして構成する前に、まず新規ノードのメタデータを次のようにサプライヤ・ノードに移行する必要があります。
バックアップ・プロセス(remtool –backupmetadata)が正しく機能するように、Oracle Internet Directoryサーバーがサプライヤ・ノードとタスク2で作成した新規ノードの両方で稼働していることを確認します。
新たに作成したノードから、次のコマンドを実行します。
remtool –backupmetadata \ –replica "new_node_host:new_node_port" \ –master "master_host:master_port"
master_host:master_portは、対象となるレプリカのサプライヤのホスト名およびポート番号です。レプリケーション識別名のパスワードを要求されます。
注意: Oracle Delegated Administration Servicesが構成されていない場合、remtool を-backupmetadata オプションを指定して実行すると、次のようなエラー・メッセージが表示されます。
Failed to add "orclApplicationCommonName=ias.example.com, cn=IAS Instances, cn=IAS, cn=Products, cn=OracleContext" as "uniquemember" to entry "cn=Associated Mid-tiers, orclapplicationcommonname=DASApp, cn=DAS,cn=products, cn=OracleContext at replica ldap://myhost:3060 このエラー・メッセージは無視してください。 |
関連項目: -backupmetadata を含めたremtool オプションの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtool コマンドライン・ツールのリファレンスを参照してください。 |
このコマンドは、メタデータをマスター・レプリカにロードする以外に、メタデータのバックアップを含むocbkup.
new_replica_id
.TO.
master_replicaid
.
timestamp
.ldif
という名前のファイルを作成します。このファイルはORACLE_INSTANCE
/diagnostics/logs/OID/tools
ディレクトリに作成されます。このファイルには、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 ORACLE_INSTANCE/diagnostics
/logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
Metadata copied successfully.
このメッセージには、ORACLE_INSTANCE
のパスとファイル名が含まれます。
メタデータのバックアップに失敗した場合、ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.log
ファイルにエラー・メッセージが記録されます。remtool
を端末から起動した場合は、その端末にエラー・メッセージが表示されます。
レプリカを追加するには、コンシューマ・レプリカで次のように入力します。
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
が正常に完了したら、次のようにしてレプリケートされるサブツリーごとに異なるネーミング・コンテキストを追加します。
サプライヤ・レプリカ・ノードとコンシューマ・レプリカ・ノードの両方で次の検索コマンドを実行し、両ノードのレプリカIDを確認します。
ldapsearch -h host -p port -D cn=orcladmin -q -b "" \ -s base "objectclass=*" orclreplicaid
レプリケーション承諾エントリを確認します。形式は次のとおりです。
"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
コンシューマ・レプリカ・ノードとサプライヤ・レプリカ・ノードの両方で、レプリケーションに含めるネーミング・コンテキストごとに次のようなエントリを追加します。次の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
部分レプリケーションに構成するネーミング・コンテキスト(サブツリー)ごとに、手順3を繰り返します。
関連項目:
|
自動ブートストラップ機能を使用するには、コンシューマ側で、次のようにコンシューマ・レプリカのサブエントリのorclReplicaState
属性を0
に設定します。
サンプル・ファイルmod.ldif
を、次のように編集します。
Dn: orclreplicaid=unique_replicaID_of_consumer, cn=replication configuration
Changetype:modify
replace:orclReplicaState
OrclReplicaState: 0
注意: WindowsシステムではorclReplicaState の値を0 に変更してブートストラップを有効にする前に、レプリケーション・サーバーが稼働していないことを確認します。 |
コンシューマ側でldapmodify
を使用して、コンシューマ・レプリカのサブエントリのorclreplicastate
属性を更新します。
ldapmodify –D "cn=orcladmin" -q -h consumer_host -p port -f mod.ldif
レプリケーション承諾およびレプリカ・サブエントリのデフォルトのパラメータを変更できます。
レプリケーション・サーバーを起動する正確な手順は、サーバーが一方向レプリカ、双方向レプリカまたはマルチマスター・レプリカのいずれにあるのかによって異なります。
一方向LDAPレプリケーションの場合は、コンシューマでレプリケーション・サーバーを起動する必要があります。たとえば、oid1にあるレプリケーション・サーバーを起動するには、次を入力します。
oidctl connect=connStr server=oidrepld instance=1 \ name=asinst_1component name=oid1 \ flags="-h consumer_host -p consumer_port" start
双方向またはマルチマスター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
Oracle Delegated Administration ServicesおよびOracle Single Sign-Onのエントリは、各サービスのローカル・インスタンスを参照する必要があります。しかし、レプリケーションをサプライヤからコンシューマに最初にダウンロードしたときには、サプライヤからレプリケートされた値を使用してこれらのエントリが作成されます。各サービスが実際にはコンシューマ・ノードに構成されている場合、これらの値をコンシューマ・ノードに適した正しい情報に置き換える必要があります。
Delegated Administration Service(DAS)がコンシューマ・ノードに構成されている場合、次の手順に従ってDASをリストアする必要があります。
タスク3により作成したocbkup.
new_replicaid
.TO.
master_replicaid
.
timestamp
.ldif
ファイルで、DAS URLを見つけてコピーします。DAS URLコンテナ・エントリの識別名は、cn=OperationURLs, cn=DAS, cn=Products, cn=OracleContextです。通常、これがファイルの最後から2番目のエントリです。
関連項目: 10g(10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』および『Oracle Application Server Single Sign-On管理者ガイド』 |
LDIFファイルchange_das_url.ldif
を作成します。このファイルの内容は次のとおりです。
dn: cn=OperationURLs,cn=DAS,cn=Products,cn=OracleContext
changetype: modify
replace: orcldasurlbase
orcldasurlbase: copy_paste_the_URL_from_backup_file
次のコマンドを実行して、DASのURLを変更します。
ldapmodify –p consumer_port -h consumer_host -D super_user_DN \ -q -f change_das_URL.ldif
同様に、Single Sign-On(SSO)がコンシューマ・ノードに構成されている場合、次の手順に従ってSSOをリストアする必要があります。
タスク3により作成したocbkup.
timestamp
.dat
ファイルで、SSOコンテナ・エントリを見つけてコピーします。手順2に示す属性のみをコピーします。SSOコンテナ・エントリの識別名は、orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO, cn=Products, cn=OracleContextです。通常、これがファイルの最後のエントリです。
関連項目: 10g(10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』 |
LDIFファイルadd_SSO_container.ldif
を作成します。このファイルの内容は次のとおりです。
dn: orclApplicationCommonName=ORASSO_SSOSERVER,
cn=SSO,cn=Products,cn=OracleContext
orclapplicationcommonname: ORASSO_SSOSERVER
orclappfullname: ORASSO_SSOSERVER
orclversion: 10.1.2.0.0
objectclass: orclApplicationEntity
objectclass: top
userpassword: userpassword_copied_from_backup_file
注意: authpassword;oid 、createtimestamp 、creatorsname 、modifiersname 、modifytimestamp 、orclguid の各属性はコピーしないでください。 |
次のコマンドを実行して、SSOのコンテナ・エントリを追加します。
ldapadd –p consumer_port -h consumer_host -D super_user_DN \ -q -f add_SSO_container.ldif
LDIFファイルmod.ldif
を作成します。このファイルの内容は次のとおりです。
dn: cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext changetype:modify add: uniquemember uniquemember: orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO,cn=Products,cn=OracleContext dn: cn=verifierServices, cn=Groups,cn=OracleContext changetype:modify add: uniquemember uniquemember: orclApplicationCommonName=ORASSO_SSOSERVER, cn=SSO,cn=Products,cn=OracleContext
次のコマンドを実行して、mod.ldif
を適用します。
ldapmodify -p consumer_port -h consumer_host -D super_user_DN \ -q -f mod.ldif
ブラウザを使用して、Oracle Delegated Administration ServicesページとOracle Single Sign-Onページをテストします。
Oracle Delegated Administration Servicesをテストするには、adminユーザーorcladmin
としてOracle Delegated Administration Servicesページ(http(s)://
new_node_hostname
:
new_node_http_port
/oiddas/
)にログインします。ログインできない場合、10g(10.1.4.0.1)ライブラリの『Oracle Identity Management委任管理ガイド』のトラブルシューティングに関する付録を参照してください。
Oracle Single Sign-Onをテストするには、super adminユーザーorcladmin
としてOracle Single Sign-Onページ(http(s)://
new_node_hostname
:
new_node_http_port
/pls/orasso/
)にログインします。ログインできない場合、10g(10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』のトラブルシューティングに関する付録を参照してください。
この項では、ldifwriteツールを使用して、LDAPベースのレプリカを構成する場合に実行する一般的なタスクについて説明します。この項の内容は、次のとおりです。
LDAPベースのレプリカのサプライヤを特定します。次のいずれかがサプライヤとなります。
レプリケーション・グループのメンバーではないディレクトリ
マルチマスター・レプリケーション・グループのノード
別のLDAPベースのレプリカ
サプライヤ・ノードでOracle Internet Directoryサーバーが起動していることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します。
opmnctl startproc ias_component=oid1
コンシューマ・ノードを識別し、このノードにOracle Internet Directoryを新しくインストールする必要があります。新しいOracle Internet Directoryをマスターとしてインストールするには、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の指示に従い、Oracle Internet Directoryサーバーが新規コンシューマ・ノードで起動されることを確認します。ディレクトリ・サーバーを起動するには、次のコマンドを入力します。
opmnctl startproc ias-component=oid1
カスタム設定を使用してコンシューマをLDAPベースのレプリカとして構成する前に、まずコンシューマのメタデータを次のようにサプライヤ・ノードに移行する必要があります。
バックアップ・プロセス(remtool –backupmetadata)が正しく機能するように、Oracle Internet Directoryサーバーがサプライヤ・ノードとタスク2で作成した新規ノードの両方で稼働していることを確認します。
コンシューマ・ノードから、次のコマンドを実行します。
remtool –backupmetadata \ –replica "consumer_host:consumer_port" \ –master "supplier_host:supplier_port"
パスワードが要求されます。
このツールは、メタデータをマスター・レプリカにロードする以外に、メタデータのバックアップを含むocbkup.
consumer_replica_id
.TO.
supplier_replica_id
.
timestamp
.dat
という名前のファイルを作成します。このファイルはORACLE_INSTANCE/diagnostics/logs/OID/tools
ディレクトリに作成されます。このファイルには、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 ORACLE_INSTANCE/diagnostics
/logs/OID/tools/ocbkup.replicaid_pilot.TO.replcicaid_master.timestamp.ldif.
Metadata copied successfully.
メッセージには、ORACLE_INSTANCE
のパスが含まれます。
このメッセージには、ORACLE_INSTANCE
の実際のパスとファイル名が含まれます。
メタデータのバックアップに失敗した場合、ORACLE_INSTANCE/diagnostics/logs/OID/tools/remtool.log
ファイルにエラー・メッセージが記録されます。remtool
を端末から起動した場合は、その端末にエラー・メッセージが表示されます。
データ整合性を保証するために、サプライヤ・ノードのディレクトリ・サーバーを読取り専用モードに切り替えます。サーバーを読取り/書込みモードから読取り専用モードに切り替えるには、第15.2項「サーバー・モードの変更」の手順のいずれかを使用します。
レプリカを追加するには、コンシューマ・レプリカで次のように入力します。
remtool -paddnode [-v] [-bind supplier_host_name:port]
replication_dn_password
の入力を要求されます。remtoolユーティリティから承諾のタイプの指定を求められます。追加するレプリカのタイプに応じて、一方向LDAPまたは双方向LDAPのいずれかを選択します。
関連項目: レプリケーション環境管理ツールの詳細は、『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtool コマンドライン・ツールのリファレンスを参照してください。 |
LDAPベースのレプリカにレプリケートするエントリが、ネーミング・コンテキスト内に大量にある場合は、サプライヤ・ノードでこれらのネーミング・コンテキストをバックアップし、それをLDAPベースのレプリカにロードすることをお薦めします。
ネーミング・コンテキストをバックアップする手順は、次のとおりです。
「タスク4: レプリケーション環境管理ツールを使用した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
サプライヤ側で、ORACLE_INSTANCE
が設定されていることを確認し、次のコマンドを使用してサプライヤからデータを取得します。ファイルにロードされたデータは、構成済の承諾に基づきます。
ldifwrite connect="connect_string_of_sponsor_node" \ baseDN="replication_agreement_dn_retrieved_in_step_1" \ file="name_of_output_LDIF_file"
関連項目:
|
「タスク3: サプライヤ側のディレクトリ・サーバーの読取り専用モードへの切替え」を実行した場合は、サプライヤ側のディレクトリ・サーバーを読取り/書込みモードに戻します。第15.2項「サーバー・モードの変更」の手順のいずれかを使用します。
この手順は、次のとおりです。
複数のファイルがある場合は、たとえば、backup_data.ldif
などの1つのファイルにまとめます。
LDAPベースのコンシューマ・レプリカにネーミング・コンテキストがある場合は、bulkdeleteを使用して削除します。ORACLE_INSTANCE
が設定されていることを確認し、次のように入力します。
bulkdelete connect="connect_string_of_replica" baseDN="naming_context"
「タスク5: レプリケートするネーミング・コンテキストのバックアップ」でバックアップしたネーミング・コンテキストについて、この手順を実行します。
コンシューマ側で、bulkloadを追加モードで使用してデータをレプリカにロードします。ORACLE_INSTANCE
が設定されていることを確認し、次のように入力します。
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"
注意: Oracle Internet Directoryの旧リリース(10g リリース2(10.1.2.0.2)など)のデータを、11g リリース1(11.1.1)が稼働しているノードにロードする場合、第39.5.3項「パスワード・ポリシーとファンアウト・レプリケーション」の説明に従って、パスワード・ポリシー・エントリを更新する必要があります。 |
関連項目:
|
「タスク8: 新規ノードにOracle Delegated Administration ServicesまたはOracle Single Sign-Onがインストールされている場合、新規ノードのディレクトリ内のエントリをリストア」に記載されている手順に従います。
レプリケーション承諾、レプリカ・サブエントリ、およびレプリケーション・ネーミング・コンテキスト構成オブジェクトのデフォルトのパラメータを変更できます。
レプリケーション・サーバーを起動する正確な手順は、サーバーが一方向レプリカまたは双方向レプリカのいずれにあるのかによって異なります。
一方向LDAPレプリケーションの場合は、コンシューマでレプリケーション・サーバーを起動する必要があります。次のように入力します。
oidctl connect=connStr server=oidrepld instance=1 \ name=instance_name componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" start
双方向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
Oracle Internet Directory 11g リリース1(11.1.1)では、10g リリース2(10.1.2.0.2)より前のリリースより細かいパスワード・ポリシーをサポートしています。このため、マスター・ノードが旧リリース(10g リリース2(10.1.2.0.2)など)で、新規のファンアウト・ノードが11g リリース1(11.1.1)の場合、問題が発生する可能性があります。マスター・ノードのパスワード・ポリシー・エントリは、ブートストラップやファンアウト・ノードへの移行の際に、予想どおりに動作しない場合があります。この問題を解決するには、ファンアウト・ノードの設定の一部として、マスターのデータをブートストラップするか移行した後、Javaクラスoracle.ldap.oidinstall.backend.OIDUpgradePasswordPolicies
を起動することにより、パスワード・ポリシー・エントリを更新する必要があります。コマンドライン構文は次のとおりです。
java –cp ORACLE_HOME/ldap/lib/oidca.jar:ORACLE_HOME/ldap/jlib/ldapjclnt10.jar \ oracle.ldap.oidinstall.backend.OIDUpgradePasswordPolicies host port bindDN \ bindPassword ORACLE_HOME[protocol]
表39-2に、コマンドラインのパラメータを示します。
表39-2 OIDUpgradePasswordPoliciesに対するコマンドライン・パラメータ
パラメータ | 説明 |
---|---|
|
11g リリース1(11.1.1)ディレクトリ・サーバーが稼働しているホスト |
|
11g リリース1(11.1.1)ディレクトリ・サーバーがリスニングしているポート。プロトコルが |
|
権限を持つ管理ユーザーは通常 |
|
bindDNに関連付けられたユーザー・パスワード |
|
Oracle Internet DirectoryのこのインスタンスのOracleホーム |
|
オプション・パラメータ。これは、SSL環境では |
ツールにより実行されるアクションはすべて、ORACLE_HOME
\ldap\log
ディレクトリにあるppUpgrade.log
に記録されます。
注意: ツールを実行する前に、該当する環境変数が正しく設定されていることを確認します。
|
この項ではLDAPベースのレプリカを削除する方法について説明します。この項の内容は、次のとおりです。
注意: 別のレプリカのサプライヤになっているレプリカは、削除できません。このようなレプリカを削除するには、先にそのすべてのコンシューマをレプリケーション・グループから削除する必要があります。 |
次のように入力し、Oracleディレクトリ・レプリケーション・サーバーを停止します。
oidctl connect=connStr server=oidrepld instance=1 componentname=oidComponentName \ flags="-h LdapHost -p LdapPort" stop
このタスクは、レプリケーション環境管理ツールを使用して行います。次のように入力します。
remtool -pdelnode [-v] [-bind hostname:port_number]
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のremtool コマンドライン・ツールのリファレンスを参照してください |
replication_dn_password
の入力を要求されます。
この項では、ファンアウトと組み合せたマルチマスター・レプリケーション・グループの設定に役立つ例を表39-3に示す4つのシステムを使用して示します。
表39-3 部分レプリケーション・デプロイメント例におけるノード
ノード | ホスト名 | ポート |
---|---|---|
ノード1 |
mycompany1.com |
3000 |
ノード2 |
mycompany2.com |
4000 |
ノード3 |
mycompany3.com |
5000 |
ノード4 |
mycompany4.com |
6000 |
ノード5 |
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レプリケーションを行います。
この項の項目は次のとおりです。
タスク1: ノード1およびノード2を対象としたマルチマスター・レプリケーション・グループの設定
ノード1とノード2のLDAPベースのマルチマスター・レプリケーション・グループを設定するには、第39.5.2項「カスタム設定を使用したLDAPベースのレプリカの設定」の手順に従います。
マルチマスター・レプリケーション・グループにアドバンスト・レプリケーション・ベースのレプリケーションを使用する場合は、第C.2.2項「アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーション・グループの設定」のタスク1から5に従います。
タスク2: レプリケーション承諾の構成
ノード1とノード2間のレプリケーション承諾では、orclExcludedNamingcontexts
属性の値を、cn=private users,cn=mycompany
として指定します。この手順は、次のとおりです。
サンプル・ファイルmod.ldif
を、次のように編集します。
dn: orclAgreementID=000001,cn=replication configuration Changetype:modify Replace: orclExcludedNamingcontexts orclExcludedNamingcontexts: cn=private users,cn=mycompany
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
タスク3: ノード1およびノード2でのレプリケーション・サーバーの起動
これを行うには、LDAPベースのレプリケーションを使用する場合、該当する指示に従います。
アドバンスト・レプリケーションを使用している場合は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」の「タスク6: DRGの全ノードでのレプリケーション・サーバーの起動」の指示に従います。
タスク4: ノード1とノード2間のディレクトリ・レプリケーションのテスト
そのためには、第39.4項「Oracle Directory Services Managerを使用したレプリケーションのテスト」の指示に従います。
タスク5: ノード3をノード2の部分レプリカとしてインストールし、構成
部分レプリケーションのブートストラップ機能を使用する場合は、第39.5.2.1項「自動ブートストラップを使用したLDAPベースのレプリカの設定」のタスク1から5に従います。
ldifwriteツールを使用してレプリカを構成する場合は、第39.5.2.2項「ldifwriteツールを使用したLDAPベースのレプリカの設定」のタスク1から9に従います。
ノード2をサプライヤ、ノード3をコンシューマと指定します。
タスク6: 部分レプリケーション承諾のカスタマイズ
この手順は、次のとおりです。
この例の要件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
属性を変更します。詳細は、「タスク5: コンシューマ側でコンシューマ・レプリカを自動ブートストラップ用に構成」を参照してください。
タスク7: DRGの全ノードでのレプリケーション・サーバーの起動
このためには、各ノードでレプリケーション・サーバーを起動します。
次のように入力します。
oidctl connect=connStr server=oidrepld instance=1 \ componentname=oidComponentName flags="-h LdapHost -p LdapPort" start
タスク8: ノード4をノード2の完全なレプリカとしてインストールし、構成
完全レプリカ・レプリケーションがデフォルト構成であるため、新規ノードをLDAPレプリカとしてインストールする場合は、第39.5項「コマンドラインを使用したLDAPベースのレプリケーションの設定」に記載されている指示に従います。インストーラからサプライヤ情報の入力を求められたときに、サプライヤ・ホスト名mycompany2.com
、サプライヤ・ポート4000
およびスーパーユーザー・パスワードを入力します。
タスク9: ノード2からノード4へのレプリケーションのテスト
示されている項の指示に従って、このレプリケーションをテストします。
アドバンスト・レプリケーションを使用している場合は、付録C「Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーションの設定」の「タスク7: ディレクトリ・レプリケーションのテスト」の指示に従います。
タスク10: ノード5をノード1の双方向レプリカとしてインストールし、構成
第39.3項「レプリケーション・ウィザードを使用したLDAPベースのレプリケーション承諾の設定」または第39.5項「コマンドラインを使用したLDAPベースのレプリケーションの設定」に記載されている指示に従います。サプライヤ・ホスト名mycompany1.com
、サプライヤ・ポート3000
およびスーパーユーザー・パスワードを指定します。
タスク11: ノード1とノード5間の双方向レプリケーションのテスト
Oracle Enterprise Managerまたはldapadd
コマンドライン・ツールを使用して、ノード1にエントリを作成します。エントリがノード5でレプリケートされるのを待機します。エントリがノード5にレプリケートされた後、ldapmodify
コマンドライン・ツールまたはOracle Enterprise Managerのいずれかを使用して、ノード5の該当するエントリに変更を適用します。この変更はノード1にレプリケートされます。