| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
前 |
次 |
この章では、次の項目について説明します。
レプリケーションは、2つ以上の参加者が必ず関係するトポロジ全体の機能です。
レプリケーションは次のように機能します。
マスターが変更を受信します。変更をデータベース内のエントリに適用後、サーバーはマスターのため、その変更を変更ログ・データベースに格納します。
マスターは、自身のレプリカ更新ベクトル(RUV)を更新します。
マスターは、新しい変更が変更ログに記録されたことをレプリケーション・スレッドに通知します。
これらのレプリケーション・スレッドはレプリケーション・パートナーに接続し、情報を伝播します。
たとえば、マスター1が変更を受信すると、それをエントリに適用して自身の変更ログを更新します。マスター1がコンシューマに接続する際、コンシューマは、そのマスター・レプリカに対して自身のRUVを示します。マスターはそのRUVを参照し、自身のRUVと比較して、コンシューマより新しい変更が含まれているかどうかを確認します。たとえば、コンシューマにより高いRUVが含まれていることを確認した場合、マスターは変更を送信しません。より最新の変更がマスターに含まれている場合は、レプリカID 1のロックを依頼する別のリクエストをコンシューマに送信し、更新を実行できるようにします。ロックが使用できない場合は、更新は後で実行されます。ロックが使用できる場合は、マスターは変更を続行します。
レプリケーションの概要の内容は、次のとおりです。
他のサーバーに対してレプリケートするDirectory Serverは、サプライヤと呼ばれます。他のサーバーによって更新されるDirectory Serverは、コンシューマと呼ばれます。サプライヤは、特別に設計されたLDAP v3拡張操作を使用して、コンシューマ上ですべての更新をリプレイします。そのため、パフォーマンスの面では、サプライヤはコンシューマにとっては必要性の高いクライアント・アプリケーションとなる可能性があります。
サーバーは、次のような場合に、サプライヤとコンシューマの両方になれます。
マルチマスター・レプリケーションで、マスター・レプリカが2つの異なるDirectory Serverにマスターされている場合。各サーバーは、他のサーバーに対して、サプライヤおよびコンシューマとして動作します。
サーバーにハブ・レプリカが含まれている場合、サーバーはサプライヤから更新を受け取り、変更をコンシューマにレプリケートします。
コンシューマの役割のみを実行するサーバーは、専用コンシューマと呼ばれます。
マスター・レプリカの場合、サーバーは次を行う必要があります。
ディレクトリ・クライアントからの更新リクエストに応答します。
履歴情報および変更ログを保持します。
コンシューマに対してレプリケーションを開始します。
マスター・レプリカを含むサーバーは、マスター・レプリカに対して行われたすべての変更を記録し、それらの変更をコンシューマにレプリケートする責任を負います。
ハブ・レプリカの場合、サーバーは次を行う必要があります。
読取りリクエストに応答します。
マスター・レプリカを含むサーバーに更新リクエストを照会します。
履歴情報および変更ログを保持します。
コンシューマに対してレプリケーションを開始します。
コンシューマ・レプリカの場合、サーバーは次を行う必要があります。
読取りリクエストに応答します。
履歴情報を保持します。
マスター・レプリカを含むサーバーに更新リクエストを照会します。
レプリケーションの最小の論理単位は、ネーミング・コンテキストとも呼ばれるサフィックスです。サフィックスという用語は、ネーミング・コンテキストに対するベースDNが、そのコンテキスト内のすべてのDNに対するサフィックスであることに起因します。たとえば、サフィックスdc=example,dc=comには、Example.comネーミング・コンテキスト内のすべてのディレクトリ・エントリが含まれます。
レプリケーション・メカニズムでは、1つのデータベースに対応する1つのサフィックスが必要です。レプリケーションの単位は、サプライヤおよびコンシューマの両方に適用されます。したがって、マスター・レプリカ上の2つのサフィックスは、コンシューマ・レプリカ上の1つのサフィックスに対してレプリケートできません(逆の場合も同じです)。
マスター・レプリカには、1から65534の間の16ビット整数である、一意のレプリカ識別子が必要です。コンシューマ・レプリカおよびハブ・レプリカのレプリカIDはすべて65535です。レプリカIDによって変更が行われたレプリカが識別されます。
複数のサフィックスが1つのマスターに構成されている場合、マスター上のそれぞれのサフィックスで同じレプリカIDを使用できます。この方法では、そのレプリカIDで変更が行われた場合、変更が行われたサーバーの特定が可能です。
レプリケーションに参加しているサフィックスをレプリカと呼びます。レプリカには次の3つの種類があります。
マスター・レプリカは、ディレクトリ・データのマスター・コピーが含まれている読取り-書込みデータベースです。マスター・レプリカは次のタスクを実行できます。
ディレクトリ・クライアントからの更新リクエストおよび読取りリクエストに応答します。
そのレプリカの履歴情報および変更ログを保持します。
コンシューマまたはハブに対してレプリケーションを開始します。
コンシューマ・レプリカは、マスター・レプリカに格納されている情報のコピーを含む読取り専用データベースです。コンシューマ・レプリカは次のタスクを実行できます。
読取りリクエストに応答します。
そのレプリカの履歴情報を保持します。
マスター・レプリカを含むサーバーに更新リクエストを照会します。
ハブ・レプリカは、コンシューマ・レプリカと同様に読取り専用のデータベースですが、1つ以上のコンシューマ・レプリカを提供するディレクトリ・サーバー上に格納されます。ハブ・レプリカは次のタスクを実行できます。
読取りリクエストに応答します。
そのレプリカの履歴情報および変更ログを保持します。
コンシューマに対してレプリケーションを開始します。
マスター・レプリカを含むサーバーに更新リクエストを照会します。
Directory Serverの単一のインスタンスは、複数のレプリカを管理するために構成できます。
レプリカは、更新のサプライヤとして、または更新のコンシューマとして、あるいはその両方として動作できます。
サプライヤは、別のレプリカに情報をコピーするレプリカです。
マスター・レプリカは、ハブ・レプリカおよびコンシューマ・レプリカのサプライヤになることができます。ハブ・レプリカは、コンシューマ・レプリカのサプライヤになることができます。マルチマスター・レプリケーションでは、1つのマスター・レプリカは、別のマスター・レプリカに対してサプライヤになることができます。
コンシューマは、別のレプリカから更新を受信するレプリカです。
ハブ・レプリカおよびコンシューマ・レプリカは、マスター・レプリカのコンシューマになることができます。コンシューマ・レプリカは、ハブ・レプリカのコンシューマになることができます。マルチマスター・レプリケーションでは、1つのマスター・レプリカは、別のマスター・レプリカに対してコンシューマになることができます。
レプリカは、他のレプリカに対する動作を変更するために昇格または降格できます。専用コンシューマはハブに昇格でき、ハブはマスターに昇格できます。マスターはハブに降格でき、ハブは専用コンシューマに降格できます。
コンシューマ・レプリカのみを含むサーバーは、専用コンシューマと呼ばれます。
レプリケーション承諾によって、サプライヤとコンシューマ間の関係が定義されます。レプリケーション承諾は、サプライヤ上で構成されます。レプリケーション承諾には、次のレプリケーション・パラメータが含まれます。
レプリケートするためのサフィックス。
データのプッシュ先のコンシューマ・サーバー。
レプリケーション・スケジュール。
コンシューマをバインドするためにマスターが使用する必要のあるバインドDNおよび資格証明。
接続の保護方法。
部分レプリケーションが構成されている場合に、部分レプリケーションで除外するまたは含む属性。
1つのリクエストにグループ化可能な変更の数およびコンシューマ承認が必要になる前に送信可能なリクエストの数を構成するためのグループおよびウィンドウのサイズ。
この承諾のレプリケーション・ステータスに関する情報。
SolarisおよびLinuxシステムでレプリケーションに使用される圧縮レベル。
マスターがコンシューマを更新可能になる前に、コンシューマは、Replication Managerエントリと呼ばれる特別なエントリを使用することで、そのマスターを認証します。マスターは、Replication Managerエントリを使用して、コンシューマにバインドします。
Replication Managerエントリには、コンシューマ・サーバー上に定義されているすべてのアクセス制御ルールを省略する特別なユーザー・プロファイルがあります。この特別なユーザー・プロファイルは、レプリケーション内でのみ有効です。
Replication Managerエントリには、次の特性があります。
コンシューマ・サーバーでは、Replication Managerは更新の実行が許可されているユーザーです。Replication Managerに対するエントリは、すべてのレプリカに存在する必要があります。
Replication ManagerエントリのバインドDNは、レプリケーション承諾で設定されています。バインドDNは、ハブまたはマスターで既存のReplication Managerエントリを指すように構成される必要があります。
初期化およびセキュリティ上の理由から、Replication Managerエントリは、レプリケートされたデータの一部になることはできません。
Replication Managerエントリは、ブラウザベースのインタフェースであるDirectory Service Control Centerを使用してレプリケーションを構成したときにデフォルトで作成されます。独自のReplication Managerエントリを作成することもできます。Replication Managerエントリの作成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のデフォルト以外のReplication Managerの使用方法に関する説明を参照してください。
レプリケーションでのSSLに対して、認証は次の方法で実行できます。
SSLサーバー認証では、認証するサーバーにReplication Managerエントリおよび関連付けられているパスワードが必要です。
SSLクライアント認証では、認証するサーバーに証明書が含まれるエントリが必要です。このエントリは、Replication Managerエントリにマップされる場合とされない場合があります。
マスター・レプリカによって受信されたすべての変更は、変更ログに記録されます。変更ログは、すべてのマスター・レプリカおよびハブ・レプリカで保持されます。
アプリケーションで変更ログを読み取る必要がある場合は、下位互換性用にレトロ変更ログ・プラグインを使用します。レトロ変更ログ・プラグインの詳細は、「レプリケーションおよびレトロ変更ログ・プラグイン」を参照してください。
マスター・レプリカに対する各変更は、変更順序番号(CSN)で特定されます。CSNはマスター・サーバーで生成され、クライアント・アプリケーションには表示されません。CSNには、タイムスタンプ、順序番号、レプリカIDおよびサブシーケンス番号が含まれます。変更ログはCSN順になっています。
レプリケーションは順次的であり、これはエントリが順序正しい方法でレプリケートされることを意味します。レプリケーションは順序立っているため、マスターによって生成されたすべての変更は、変更順序番号(CSN)によってラベル付けされ、マルチマスター・トポロジ内の各変更に対して一意です。CSNは16進文字列で、ログには次のように表示されます。
41e6ee93000e00640000
16進数の最初の8桁は、マスターで変更が生成された時間を表します。この時間は、1970年1月1日を基準とした秒単位で表されます。
次の4桁は順序番号、または変更が発生した現在の秒での順序です。たとえば、秒41e6ee93で複数の変更が発生します。順序番号は、変更の進行形の番号付けを示します。
次の4桁は、変更を最初に受信したマスターのレプリカIDを示します。
最後の4桁は予備です。ほとんどの場合、それらは0000です。
CSNは、ローカル・トラフィックによってレプリカに対して新しい変更が送信されたときにのみ生成されます。そのため、更新を受信するマスターのみがCSNを生成します。受信するすべての更新がレプリケーションを介して行われるため、コンシューマは、常にマスターを参照します。
レプリカ更新ベクトル(RUV)は、トポロジ内の各レプリカの状態を識別します。サプライヤおよびコンシューマ上に格納されるRUVは、レプリケートする必要のある変更を確立するために使用されます。RUVは、サプライヤのURL、サプライヤのID、最小CSNおよび最大CSNを格納します。
レプリケーション・トポロジ内のすべてのレプリカは、レプリカ更新ベクトル(RUV)に現行のレプリケーション状態を格納します。RUVは実行中のプロセスによってメモリーに格納され、このレプリカ自身およびレプリケーション・トポロジ内のその他すべての参加者に関する正確な情報を提供します。指定されたサーバー上のRUVエントリには、レプリケーション・トポロジに参加している各マスターに対する行が含まれています。各行には、マスターのうちの1つの識別子、レプリカのURLおよびサーバーで最初および最後に行われた変更のCSNが含まれます。CSNは、必ずしもマスターによって行われた最新の変更ではなく、サーバーで認識される最初および最後の変更のみが記録されます。
RUVは、主にメモリーにあり、cn=replica,cn=suffix,cn=mapping tree,cn=configエントリ上のldapsearchを使用してアクセスできます。たとえば、ou=peopleサフィックスに対するldapsearchでは、次の結果が生成される可能性があります。
# ldapsearch -h host1 -p 1389 -D "cn=Directory Manager" -w secret \
-b "cn=replica,cn=ou=people,cn=mapping tree,cn=config" \
-s base objectclass=* nsds50ruv
nsds50ruv: {replicageneration} 45e8296c000000010000
nsds50ruv: {replica 1 ldap://server1:1389} 45ed8751000000010000 4600f252000000010000
nsds50ruv: {replica 2 ldap://server1:2389} 45eec0e1000000020000 45f03214000000020000
明確にするために、RUVの構文をCSNchangenumber-replicaidに簡略化します。change-numberは、マスター上で発生した連続した変更のうち、RUVが対応する変更を示します。たとえば、45ed8751000000010000はCSN05-1として書き込まれます。前述の図には、マスター1には次のRUVが含まれています。
replica 1: CSN05-1 CSN43-1 replica 2: CSN05-2 CSN40-2
最初の行は、レプリカID 1で示されている、このレプリカが自身(マスター1)について認識している最初および最後の変更に関する情報を提供しています。2番目の行は、このレプリカがマスター2から認識する最初および最後の変更に関する情報を提供しています。最も関心をひく情報は、最後の変更です。通常の操作では、マスター1は、受信する更新についてマスター2より認識しているはずです。このことを、マスター2のRUVを参照して確認します。
replica 2: CSN05-2 CSN50-2 replica 1: CSN01-1 CSN35-1
最後の変更を見ると、マスター2は受信した最後の変更(CSN50-2)について、マスター1 (最後の変更はCSN40-2で発生)よりも認識しています。一方、マスター1は自身の最後の変更(CSN43-1)については、マスター2 (CSN35-1)よりも認識しています。
レプリケーションに関する問題をトラブルシューティングする場合、CSNは問題を特定するのに役立ちます。変更は最初にマスター1に適用されその後レプリケートされるため、マスター1は、少なくともレプリケーション・トポロジ内の他の参加者と同様に自身のレプリカIDについて常に認識している必要があります。そのため、CSN43-1は、トポロジ内でレプリカID 1に属する最大値です。
たとえば、30分後にマスター1のRUVがまだCSN40-2で、マスター2ではRUVがCSN67-2まで大幅に増加した場合、問題が特定されます。これは、マスター2からマスター1へのレプリケーションが発生していないことを示します。
障害が発生し、できるかぎりデータを保存しながらトポロジを再初期化する必要がある場合は、RUVピクチャを使用して、最新の変更が含まれているマシンを判別できます。たとえば、前述のレプリケーション・トポロジには、次のRUVを含むハブがあります。
2: CSN05-2 CSN50-2 1: CSN05-1 CSN43-1
この場合、サーバー1が最新の変更を提供するために適した候補のようです。
RUVは、nsds50ruvからds6ruv属性を読み取ることができます。
レプリカ上で削除されたディレクトリ・エントリは、レプリケーションで必要がなくなるまでDirectory Serverによって保持されます。このような削除済エントリは、それらがobjectclass: nsTombstoneを持つため、ツームストンと呼ばれます。まれに、LDAPを介して手動でツームストンを削除する必要がある場合があります。
ツームストンはディレクトリ・マネージャに対してのみ表示されます。さらに、ツームストンは、フィルタ(objectclass=nsTombstone)を使用した検索でのみ表示されます。次のldapsearchコマンドでは、dc=example,dc=comの下にツームストン・エントリが返されます。
$ ldapsearch -D "cn=Directory Manager" -b dc=example,dc=com "(objectclass=nsTombstone)"
コンシューマの初期化(合計更新)時に、すべてのデータがマスターからコンシューマに物理的にコピーされます。レプリケーション承諾を作成している場合、その承諾によって定義されているコンシューマを初期化する必要があります。コンシューマが初期化されると、マスターはコンシューマに対してリプレイ(レプリケート)または更新操作を開始できます。通常の状況では、コンシューマでその後の初期化が必要になることはありません。ただし、マスター上のデータがバックアップからリストアされた場合は、そのマスターに依存するコンシューマの再初期化が必要になる場合があります。
マルチマスター・レプリケーション・トポロジでは、バックアップまたはLDIFファイルから再初期化された読取り-書込みレプリカのデフォルトの動作では、クライアントの更新リクエストが拒否されます。デフォルトでは、更新を再び受け入れるように構成されるまで、レプリカは読取り専用モードのままになります。読取り専用レプリカ上に最も古い更新がある場合は、dsconf set-suffix-propコマンドを使用してサフィックスのプロパティrepl-accept-client-update-enabledをonに設定します。
コンシューマの初期化後に、サプライヤで変更が行われると、レプリケーション更新がコンシューマに送信されます。これらの更新は、増分更新と呼ばれます。更新が複数のレプリカIDから発生した場合は、コンシューマは複数のサプライヤから同時に増分更新できます。
バイナリ・コピー機能は、1つのサーバーのバイナリ・バックアップ・ファイルを使用して別のサーバーにリストアすることで、マスター・レプリカまたはコンシューマ・レプリカをクローニングするために使用できます。レプリケーション用のバイナリ・コピーの使用方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のバイナリ・コピーを使用したレプリケートされたサフィックスの初期化に関する説明を参照してください。
コンシューマがデータを変更するためのリクエストを受信すると、マスター・レプリカを含むサーバーにはそのリクエストを転送しません。かわりに、そのリクエストを満たすことができるマスターのURLのリストをクライアントに返します。これらのURLは、リフェラルと呼ばれます。
レプリケーション・メカニズムでは、レプリケーション・トポロジに含まれるすべての既知のマスターのリフェラルを返すよう、コンシューマを自動的に構成します。ただし、独自のリフェラルを追加して、サーバーによって自動的に設定されたリフェラルを上書きすることもできます。リフェラルを制御する機能は、次のタスクを実行するのに役立ちます。
ポートを保護する目的のみのポイント・リフェラル
ロード・バランシングではなくDirectory Proxy Serverを指定
WANによってサーバーが分離されている場合のみローカル・サーバーにリダイレクト
4方向マルチマスター・トポロジでリフェラルをマスターのサブセットに制限
Directory Proxy Serverはリフェラルに従うことができます。
レトロ変更ログは、Directory Serverの以前のバージョンとのアプリケーション互換性を保持するためにLDAPクライアントによって使用されるプラグインです。レトロ変更ログは、サフィックスcn=changelogの下に、Directory Serverの変更ログとは別のデータベースに格納されます。
レトロ変更ログは、スタンドアロン・サーバーまたはレプリケーション・トポロジ内の各サーバーで有効にできます。サーバーでレトロ変更ログが有効になっている場合、デフォルトではそのサーバー上のすべてのサフィックスに対する更新が記録されます。
レトロ変更ログは、トポロジ内のすべてのマスター・レプリカから更新を受信します。各マスター・レプリカからの更新はレトロ変更ログに結合されます。レトロ変更ログは、アプリケーションによる同期を可能にするために、アプリケーションに対して変更を追跡するための方法を提供します。Directory Serverを使用することで、マルチマスター・トポロジ内の任意のマスターでレトロ変更ログの一貫性のあるバージョンにアクセスできます。また、変更番号に従ってその状態を管理するためにアプリケーションを更新できます。これにより、異なるサーバー上のレトロ変更ログ間でのフェイルオーバーが可能になります。
グローバル・レトロ変更ログには、すべての変更が含まれています。2つの異なる場所で同じエントリに対して2つの変更が発生した場合、レトロ変更ログは、順序付けられた変更の説明を提供します。任意のサーバーからレトロ変更ログに問い合わせた場合、同様の情報が含まれます。
レトロ変更ログの使用方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレトロ変更ログの使用に関する説明を参照してください。
次の図に、マルチマスター・トポロジ内の2つのサーバー上のレトロ変更ログを示します。
レトロ変更ログは、レプリケーション時に次の属性を使用します。
changeNumber (cN)レトロ変更ログに記録される更新の順序を特定
replicationCSN (CSN)指定されたレプリカに対して更新を行う時間を特定
replicaIdentifier (RI)レトロ変更ログを更新するレプリカを特定
図では、レトロ変更ログRCL1およびRCL2には同じ更新のリストが含まれていますが、更新は同じ順序で行われないことを示しています。ただし、指定されたreplicaIdentifierについては、更新は各レトロ変更ログで同じ順序に記録されます。更新がレトロ変更ログに記録される順序は、changeNumber属性で指定されます。
次の図に、簡略化したレプリケーション・トポロジを示しますが、ここではクライアントがコンシューマ・サーバー上のレトロ変更ログを読み取ります。
トポロジ内の各マスター・レプリカに対して行われるすべての更新は、トポロジ内の各レトロ変更ログに記録されます。
クライアント・アプリケーションはDirectory Server 3のレトロ変更ログを読み取り、各レプリカ識別子に対する最後のCSNを格納します。各レプリカ識別子の最後のCSNは、replicationCSN属性によって指定されます。
次の図に、Directory Server 3の障害発生後のクライアントによるDirectory Server 2への読取りのリダイレクトを示します。
フェイルオーバー後、クライアント・アプリケーションはDirectory Server 2のレトロ変更ログ(RCL2)を使用して、自身の更新を管理する必要があります。RCL2での更新の順序がRCL3での順序と同じではないため、クライアントは自身の更新をRCL2と同期する必要があります。
クライアントはRCL2を確認して、各レプリカ識別子に対する最後のCSNのレコードが対応するcNを特定します。レトロ変更ログのフェイルオーバーの例では、クライアントは、最後のCSNとcN間の次の対応関係を確認します。
RI1からのCSN 1はRCL2上のcN4に対応
RI2からのCSN 2はRCL2上のcN5に対応
RI3からのCSN 3はRCL2上のcN7に対応
RI4からのCSN 1はRCL2上のcN6に対応
クライアントは、このリストの最小のcNに対応する更新を特定します。レトロ変更ログのフェイルオーバーの例では、リスト内の最小のcNはcN4です。クライアントですべての更新が確実に処理されるようにするには、cN4以降にRCL2に記録されたすべての更新を処理する必要があります。クライアントは、cN4より前にRCL2に記録された更新は処理せず、cN4に対応する更新も処理しません。
レプリケーションの競合が発生した場合、Directory Serverは、競合を解消するための操作を実行します。レトロ変更ログが実行中で、changeIsReplFixupOp属性がtrueに設定されている場合、操作に関する次の情報がchangeHasReplFixupOp属性に記録されます。
操作のターゲットDN
更新のタイプ
実行された変更
これらの属性の詳細は、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスを参照してください。
レプリケートされたトポロジでは、レプリケートされたサーバー上のレトロ変更ログは、互いに最新にする必要があります。これにより、レトロ変更ログのスイッチオーバーが可能になります。レトロ変更ログのフェイルオーバーの例を使用すると、RCL3上の各レプリカIDの最後のCSNは、RCL2上に存在する必要があります。
