| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
Oracle Unified Directoryレプリケーションは、ゆるやかな一貫性を持つマルチマスター・モデルを使用しています。レプリケーション・トポロジ内のディレクトリ・サーバーはすべて、読取り操作と書込み操作が可能です。
この後のアーキテクチャに関する各項は、開発者およびレプリケーション・メカニズムの仕組みに興味があるユーザーを対象として書かれています。レプリケーションを使用できるようになるためだけに、それらの各項を読む必要はありません。レプリケーションの構成と使用の詳細は、第29章「ディレクトリ・データのレプリケーション」を参照してください。
次の各項では、Oracle Unified Directoryレプリケーション機能のアーキテクチャについて説明します。
Oracle Unified Directoryレプリケーション・モデルは、ゆるやかな一貫性を持つマルチマスター・モデルです。言い換えると、レプリケートされるトポロジのすべてのディレクトリ・サーバーが、読取り操作と書込み操作の両方を処理できます。
レプリケーションは、パブリッシュ・サブスクライブ・アーキテクチャを中心に構築されています。各ディレクトリ・サーバーは、中央サービスと通信し、自身の変更のパブリッシュおよび他のディレクトリ・サーバーの変更通知の受信を行うために中央サービスを使用します。この中央サービスは、レプリケーション・サービスと呼ばれます。
レプリケーション・サービスは、複数のホストで動作する複数のサーバー・インスタンスを使用することで、高可用性を持たせることができます。レプリケーション・アーキテクチャ内でレプリケーション・サービスを提供するサーバー・インスタンスは、レプリケーション・サーバーと呼ばれます。ディレクトリ・サービスを提供するサーバー・インスタンスは、ディレクトリ・サーバーと呼ばれます。
レプリケーション・セッションの参加者は、SSL証明書を使用してお互いを認証します。提示された証明書がADSトラスト・ストアに存在する場合、接続は許可されます。アクセス制御や権限は強制されません。
次の各項では、レプリケーション・アーキテクチャおよびそれを構成する様々な要素について説明します。
次の図は、基本的なレプリケーション・アーキテクチャを示します。
各ディレクトリ・サーバーは、起動時にレプリケーション・サーバーを1つ選択して接続します。ディレクトリ・サーバーは、処理したすべての変更をレプリケーション・サーバーに送信し、トポロジ内の他のサーバー上のすべての変更をレプリケーション・サーバー経由で受信します。各レプリケーション・サーバーは、トポロジ内の他のすべてのレプリケーション・サーバーに接続します。
レプリケーション・サーバーは、ディレクトリ・サーバーから変更を受信すると、その変更をトポロジ内の他のすべてのレプリケーション・サーバーに転送します。それらのレプリケーション・サーバーは、その変更を接続しているすべてのディレクトリ・サーバーに転送します。レプリケーション・サーバーは、別のレプリケーション・サーバーから変更を受信したとき、その変更を接続しているディレクトリ・サーバーには転送しますが、他のレプリケーション・サーバーには転送しません。ディレクトリ・サーバーが別のディレクトリ・サーバーに直接変更を送信することはありません。このアーキテクチャにより、複雑なネゴシエーションを行わなくても、すべての変更がすべてのサーバーに転送されることが保証されます。
すべての変更には、それを最初に処理したディレクトリ・サーバーにより、変更番号が割り当てられます。変更番号は、変更を処理するすべての過程を通じてその変更を識別するために使用されます。レプリケーション・サーバーは、変更発生時に接続されていなかったディレクトリ・サーバーまたは動作が遅れたために処理された変更をすべて受信することが一時的にできなくなったディレクトリ・サーバーに過去の変更を再送信できるように、永続記憶域に変更を保持します。詳細は、第7.1.3項「レプリケーション変更番号」を参照してください。
各ディレクトリ・サーバーの現在の更新状態は、ディレクトリ・サーバーが最後に処理した変更を記録することで管理されます。ディレクトリ・サーバーがレプリケーション・サーバーに接続すると、レプリケーション・サーバーはこの記録を使用して、更新リストからディレクトリ・サーバーに送信する最初の変更を特定します。
複数のディレクトリ・サーバーが同時に更新を処理できるので、あるディレクトリ・サーバー上の更新操作が、同じエントリに作用する別のディレクトリ・サーバー上の別の更新操作と競合する可能性があります。各ディレクトリ・サーバーが他のディレクトリ・サーバーから受信した操作をリプレイする際に競合を解消することにより、最終的にはすべてのディレクトリ・サーバーのデータが収束します。
競合は、変更の競合と呼ばれる競合する変更操作によって発生する可能性があります。また、名前の競合と呼ばれる、競合する追加、削除またはmodRDNの各操作によって発生する可能性もあります。ディレクトリ・サーバーは、一貫性のある方法で競合を解消するために、エントリごとに一連の変更履歴を保持します。この履歴は、履歴情報と呼ばれます。履歴情報は、変更が発生したエントリ内に操作属性として格納されます。詳細は、第7.3項「履歴情報と競合解消」を参照してください。
レプリケーション・サーバーは、次のタスクを実行します:
ディレクトリ・サーバーからの接続の管理
他のレプリケーション・サーバーへの接続
他のレプリケーション・サーバーからの接続のリスニング
ディレクトリ・サーバーからの変更の受信
ディレクトリ・サーバーおよび他のレプリケーション・サーバーへの変更の転送
安定したストレージへの変更の保存(古い操作の切捨てが含まれます)
レプリケーション・サーバーは、ディレクトリ・サーバーと同じではありません。ただし、ディレクトリ・サーバーと同様、レプリケーション・サーバーは構成ファイルを使用し、オンラインで構成および監視でき、バックアップおよびリストアが可能です。そのため、レプリケーション・サーバーは、ディレクトリ・データを格納していなくても、常にLDAPサーバーまたはJMXサーバーです。
レプリケーションのためにディレクトリ・サーバー・インスタンスを構成すると、レプリケーション・サーバーは、自動作成なしを指定した場合を除いて、自動作成されます。レプリケーション・サーバーとディレクトリ・サーバーは、同一JVM内でも、別々のJVM内でも、動作できます。
小規模トポロジ(ディレクトリ・サーバーの数が最大4つ)では、各サーバーをディレクトリ・サーバー兼レプリケーション・サーバーとして構成することが合理的です。大規模トポロジ(ディレクトリ・サーバーの数が20を超えている)では、ディレクトリ・サーバー・インスタンスとレプリケーション・サーバー・インスタンスを別々のJVMに分けて、レプリケーション・サーバーの数を制限することをお薦めします。
この2つの極端なトポロジの中間の規模の場合は、要件に合せて最適な構成を決定できます。すべてのサーバーをディレクトリ・サーバー兼レプリケーション・サーバーとして動作させるほうが、一般にはトポロジが単純になり、管理しやすくなります。ディレクトリ・サーバーとレプリケーション・サーバーを分ける場合、ディレクトリ・サーバー・インスタンスはレプリケーション変更ログを保存する必要がないので必要なディスク容量が少なくなります。
変更番号は、LDAPディレクトリ・サーバー上で行われた変更を一意に識別します。また、変更番号により、一貫した変更の順序が提供されます。変更番号順序は、競合の解消および転送された変更のリプレイ順の決定に使用されます。
変更番号は、次の要素で構成されています:
タイムスタンプ(ミリ秒単位)。タイムスタンプは、システム時刻を使用して生成されます。変更番号は、サーバーによってすでに処理されているすべての変更番号よりも、生成される各変更番号のほうが必ず大きくなるように生成されます。変更番号が常に増加し続けることにより、それ以前に行われた操作に依存する操作が一貫して正しい順序でリプレイされることが保証されます。エントリの追加操作の直後に実行される変更操作は、それ以前の操作に依存する操作の例です。
順序番号。同じミリ秒内に発生した変更ごとに値が増える連番です。
レプリカ識別子。トポロジ内の各レプリカに割り当てられる一意の整数識別子です。(レプリケーション・トポロジは、特定のデータ・セットのすべてのレプリカの集合です。たとえば、example.comのレプリケーション・トポロジは、ディレクトリ・サービス全体のdc=example,dc=com接尾辞のすべてのコピーである可能性があります。)
レプリカ識別子は、同じ識別子が異なる2つのサーバーによって異なる2つの変更に割り当てられることがないことを保証します。ディレクトリ・サーバーの将来のリリースでは、レプリカ識別子が自動的に割り当てられるアルゴリズムが使用される可能性があります。
ディレクトリ・サーバーがレプリケーション・サーバーに接続すると、レプリケーション・サーバーは、ディレクトリ・サーバーがまだ参照していない変更を送信するために、ディレクトリ・サーバー・データがどの程度最新なのかを決定する必要があります。このディレクトリ・サーバーの「最新」状態は、レプリケーション・サーバー状態と呼ばれます。
あるサーバーが、別のリモート・サーバーからの比較的古い変更をまだ受信していないかもしれないのに、近くのサーバーからのそれより新しい変更をすでに参照して処理している可能性があります。そのため、レプリカ識別子を使用して、各レプリカで最後に処理された変更番号を記録することでサーバー状態を管理します。
管理者がサーバーを停止して再起動する可能性があるので、サーバー状態は安定したストレージに保存する必要があります。理想的なのは、ローカルな変更またはレプリケートによる変更が行われるたびにサーバー状態を保存することです。ただし、変更のたびにデータベースに情報を保存すると、かなりの量のオーバーヘッドが発生します。そのため、サーバー状態はメモリー内で維持し、定期的に、またはサーバーを正しくシャットダウンする際に、データベースに保存します。
サーバー接続のkill操作やシステム・クラッシュなどの重大な中断によって、サーバーは処理済の変更を追跡できなくなる可能性があります。この場合、サーバーの再起動時に非一貫性を修正する必要がある可能性があります。クラッシュ・リカバリの管理方法の詳細は、第7.2.6項「ディレクトリ・サーバーのクラッシュ」を参照してください。
サーバー接続のkill操作やシステム・クラッシュなどの重大な中断によって、サーバーは処理済の変更を追跡できなくなる可能性があります。
ある操作を、別の操作が完了するまで、リプレイできない可能性があります。たとえば、同じエントリに対して追加操作の後に変更操作が行われた場合、サーバーは変更操作を開始する前に追加操作の完了を待機する必要があります。
このような依存性は非常にまれであり、一般には依存性が必要な操作は限られています。通常、操作は変更操作なので、依存性はありません。したがって、そのような場合、マルチCPUサーバーを使用して最適なパフォーマンスを得るには、操作を並行してリプレイする必要があります。
レプリケーション・モデルは、操作の依存性はまれであるという前提に基づいて構築されています。したがって、レプリケーション・メカニズムは、並行して操作をリプレイすることを試みて、操作のリプレイに失敗した場合のみ操作の依存性の処理に切り替えます。
次の各項では、レプリケーション・プロセスに関するメカニズムおよび特定の機能の実現方法について説明します。
サーバーがレプリケートされたトポロジに参加するには、そのサーバーをデータで初期化する必要があります。すなわち、完全なデータ・セットをなんらかの方法でサーバーにコピーする必要があります。サーバーをデータで初期化する方法の詳細は、第29.6項「データによるレプリケート対象サーバーの初期化」を参照してください。
データのレプリケーションは自動実行されますが、構成のレプリケーションは手動でトリガーする必要があります。
Oracle Unified Directory構成は、ファイルinstance-path/config/oud.ldifで指定されています。この項では、レプリケーション元のインスタンスからレプリケーション先のインスタンスに手動でレプリケートする必要がある特定の構成属性をリストして説明します。
次の構成属性の値を移行できます:
グローバル構成属性。書込み可能性モード、サイズ制限および時間制限など。
セキュリティ構成属性。暗号化マネージャ、キー・マネージャ、信頼マネージャ、アイデンティティ・マッピングおよびSASLなど。
接続ハンドラ。
パフォーマンス・チューニング属性。キャッシュ、スレッドおよび他のデータベース構成パラメータなど。
レプリケーション構成属性。
パスワード・ポリシー構成属性。
プラグイン構成属性。
機能構成属性。アイデンティティ・マッピング、索引など。
ディレクトリ・サーバーで変更が発生すると、ディレクトリ・サーバー上のレプリケーション・コードが次のタスクを実行します:
変更番号の割当て
履歴情報の生成
変更のレプリケーション・サーバーへの転送
サーバー状態の更新
履歴情報はエントリに格納されるので、サーバーがバックエンドに書き込む前に、操作に含まれている必要があります。サーバーは、履歴情報を生成する際に変更番号を使用します。したがって、変更番号は履歴情報の前に生成されます。変更番号と履歴情報の両方は、操作前フェーズの一部として実行されます。
操作は、操作をリクエストしたクライアント・アプリケーションに更新の確認が送信される前に、レプリケーション・サーバーに送信されます。これにより、同期した保証アプリケーション・モードを実装できます。詳細は、第7.7項「保証レプリケーション」を参照してください。したがって、確認は操作後フェーズの一部として送信されます。
変更は、変更番号で定義される順序で送信されます。正しい順序で送信することにより、レプリケーション・サーバーがすべての変更を他のディレクトリ・サーバーに送信することを保証できます。
ディレクトリ・サーバーはマルチスレッドで動作するので、同じ操作に対して、操作後プラグインが操作前プラグインと異なる順序で呼び出される可能性があります。レプリケーション・コードは、保留中の変更のリストを管理します。このリストには、開始されて変更番号は生成済ですが、まだレプリケーション・サーバーに送信されていない変更が含まれます。変更は、操作前フェーズで保留中の変更のリストに追加されます。また、レプリケーション・サーバーに送信されると、リストから削除されます。特定の操作が、その変更番号で定義される位置よりも早く操作後フェーズに到達した場合、その操作は、それより前の操作が送信されるまで待機した後で、レプリケーション・サーバーに送信されます。
操作がレプリケーション・サーバーに送信されると、サーバー状態が更新されます。詳細は、第7.1.4項「レプリケーション・サーバーの状態」を参照してください。
ディレクトリ・サーバーが起動されたとき(または接続しているレプリケーション・サーバーが停止したとき)、ディレクトリ・サーバーは、変更をパブリッシュおよび受信するための適切なレプリケーション・サーバーを選択します。この項では、レプリケーション・サーバーの選択方法について説明します。
ディレクトリ・サーバーは、次の原則に従って、適切なレプリケーション・サーバーを選択します:
フィルタリング。ディレクトリ・サーバーはまず、トポロジ内で構成されているすべてのレプリケーション・サーバーから、選択可能なレプリケーション・サーバーのリストを作成します。このリストは、次の条件に基づいて作成されます:
ディレクトリ・サーバーと同じグループID (または地理的識別子)を持つレプリケーション・サーバー
ディレクトリ・サーバーと同じ生成ID (初期データ・セット)を持つレプリケーション・サーバー
そのディレクトリ・サーバーで生成された最新の更新がすべて存在するレプリケーション・サーバー
ディレクトリ・サーバーと同じ仮想マシンで動作しているレプリケーション・サーバー
|
注意: このリストの条件は、望ましい順序で並んでいます。したがって、たとえば、あるレプリケーション・サーバーがディレクトリ・サーバーと同じ生成ID (2番目の条件)を持っていても、同じグループID (1番目の条件)を持っていない場合、トポロジ内にディレクトリ・サーバーと同じグループIDを持つレプリケーション・サーバーが1つも存在しない場合を除いて、このレプリケーション・サーバーはリストに追加されません。 |
ロード・バランシング。ディレクトリ・サーバーが選択可能なレプリケーション・サーバーのリストを編集する際、トポロジ内のすべてのレプリケーション・サーバーに負荷が分散されるようにレプリケーション・サーバーを選択します。この選択は、トポロジ内のレプリケーション・サーバーの重みに従って行われます。詳細は、第7.2.3.2項「レプリケーション・サーバーのロード・バランシング」を参照してください。
複数のディレクトリ・サーバーと複数のレプリケーション・サーバーからなる大規模なトポロジでは、あらかじめ定義された方法でディレクトリ・サーバーをレプリケーション・サーバーに分散させた方が効率的です。これは、レプリケーション・サーバーを異なるタイプの異なる能力を持つマシンで実行している場合に、特に重要です。予想されるマシンの全体的能力がレプリケーション・サーバー間で大幅に異なる場合は、その能力に従ってレプリケーション・サーバーに負荷を分散させることが有効です。
レプリケーション・サーバーごとに接続されるディレクトリ・サーバーの数が効率的に分散されるように、レプリケーション・サーバーに比例した重みを構成できます。レプリケーション・サーバーの重みは、整数(1..n)として定義されます。トポロジ内の各レプリケーション・サーバーのデフォルトの重みは1です。この重みは、トポロジ内の他のレプリケーション・サーバーの重みと比較する際にのみ意味を持ちます。
レプリケーション・サーバーの重みによって、トポロジ内に現在存在し、この特定のレプリケーション・サーバーに接続する必要があるディレクトリ・サーバーの比率が決まります。レプリケーション・サーバーの重みは、トポロジ内のすべてのレプリケーション・サーバーの予想される全体的能力の比率として構成します。たとえば、レプリケーション・サーバーAにレプリケーション・サーバーBの2倍の能力があると予想される場合、レプリケーション・サーバーAの重みはレプリケーション・サーバーBの重みの2倍である必要があります。
特定のレプリケーション・サーバーの負荷の比率は、nをそのレプリケーション・サーバーの重み、dをトポロジ内のすべてのレプリケーション・サーバーの重みの合計として、(n/d)で表すことができます。
レプリケーション・サーバーの重みの構成の詳細は、第29.5.12項「レプリケーション・サーバーの重みの構成」を参照してください。
レプリケートされたディレクトリ・サーバーで変更をリプレイすることは、マルチコアおよびマルチCPUのシステムで効率的に実行されます。ディレクトリ・サーバーでは、レプリケーション・サーバーから送信された変更を、複数のスレッドが読み取ります。
操作をすぐにリプレイできるかどうかを判断するために、依存性情報を使用します。サーバーは、サーバー状態および現在の操作が依存する操作のリストをチェックして、それらの操作がリプレイ済かどうかを判断します。それらの操作がリプレイされていない場合、サーバーは、依存性操作を保持するキューに現在の操作を追加します。現在の操作をリプレイできる場合、サーバーは、レプリケーション・サーバーから送信された情報に基づいて内部操作を構築します。その後、サーバーは内部リプレイ操作を実行します。
レプリケーション・サーバーから送信された操作から構築された内部リプレイ操作は、それ以前の操作と競合する可能性があります。したがって、そのような内部操作は、常に発生元のディレクトリ・サーバーで実行したときと同じようにリプレイできるとはかぎりません。サーバーは、handleConflictResolutionフェーズを処理する際に競合をチェックします。
ほとんどの場合、内部リプレイ操作がそれ以前の操作と競合することはありません。その場合は、handleConflictResolutionフェーズでは何も実行しません。したがって、レプリケーション・コードはすぐに戻るように最適化されます。
競合が発生した場合、handleConflictResolutionコードは競合を解消するための適切なアクションを実行します。変更操作が競合する場合、handleConflictResolutionコードは、最新の変更が残るように変更操作を変更します。
競合解消の処理では、ローカル操作に関する履歴情報を更新します。それによって、この操作をコア・サーバーで処理できるようになります。最後に、操作が終了したら、サーバー状態を更新します。
操作が完了すると、その操作を処理しているサーバー・スレッドは、現在の操作の完了を待機している操作が依存性キューに存在するかどうかをチェックします。存在する場合、その操作はリプレイ可能なので、そのリプレイ・プロセスを開始します。存在しない場合、レプリケーション・サーバーをリスニングして、さらに操作が送信されるまで待機します。
サーバーの同期を維持する処理が実行されていても、ディレクトリ・サーバーが一貫しないデータを示しはじめる可能性があります。これは、通常、次の状況で発生します:
格納されているデータがディスク・エラーによって損なわれた場合
データ処理中にメモリー・エラーによりエラーが発生した場合
ソフトウェアの不具合により不正なデータが発生したり変更が失われたりした場合
このような状況では、変更を記録してリプレイするだけでは、一貫しないデータを同期するには不十分です。
提供されている自動修復メカニズムは、エントリ内の履歴情報を使用して、一貫性のあるデータがどうあるべきかを判断します。その後、レプリケーション・メカニズムは、不正なデータが存在するか、またはデータが欠落しているディレクトリ・サーバー上でデータを修復します。自動修復メカニズムは、LDAPアプリケーションとして実装され、レプリケーション・サーバーが動作するホスト上で動作します。
自動修復アプリケーションは、様々なモードで実行できます。実行モードに応じて、次のタスクを実行します:
サーバーが変更をリプレイしたときにエラーとして示された非一貫性を修復します。
管理者が検出した非一貫性を修復します。
ディレクトリ・エントリを定期的にスキャンして非一貫性を検出して修復します。
ディレクトリ・サーバーがクラッシュした場合、レプリケーション・サーバーへの接続は切断されます。このとき、ディレクトリ・サーバーが処理して、自身のデータベースにコミットした最新の変更が、まだどのレプリケーション・サーバーにも送信されていない可能性があります。
そのため、ディレクトリ・サーバーが再起動したときに、その状態を、ディレクトリ・サーバーが接続するレプリケーション・サーバーで保持されているサーバー状態と比較する必要があります。ディレクトリ・サーバーは、変更が失われていて、まだレプリケーション・サーバーに送信されていないことを検出すると、履歴情報から仮の操作を構築します。そして、これらの仮の操作をレプリケーション・サーバーに送信します。
ローカルのサーバー状態は操作のたびに保存されるわけではないので、クラッシュ後にディレクトリ・サーバーに保持されているサーバー状態は信頼できません。かわりに、自身のサーバー更新状態を、履歴情報から再計算します。
レプリケーション・サーバーがクラッシュした場合、ディレクトリ・サーバーはトポロジ内の別のレプリケーション・サーバーに接続します。そこで欠落している変更の有無をチェックして、必要に応じて再送信します。
この項では、履歴情報を保持する方法およびレプリケーション競合を解消するために履歴情報を使用する方法について説明します。
競合は、1つ以上のエントリが複数のサーバー上で同時に更新され、それらの変更に互換性がないか、またはそれらの変更が更新の間に相互作用を引き起こす場合に発生します。競合が発生するのは、更新操作がレプリケーション・トポロジ内のすべてのレプリカで同時に実行されるわけではないためです。実際には、更新はまずあるサーバーで処理され、その後で他のサーバーにレプリケートされます。
次の例では、異なる2つのディレクトリ・サーバー上で同時に1つの属性が変更された場合に発生する競合について説明します。
読取りと書込みを行う2つのレプリカが存在するトポロジについて考えます。変更操作により、一方のサーバー上でエントリの姓を示すsn属性をSmithに変更します。その変更を処理するサーバーがもう一方のサーバーと同期する前に、もう一方のサーバー上でそのエントリのsn属性の値がJonesに置換されたとします。競合管理が行われていない場合、レプリケーションによって、現在値Jonesが保持されているサーバー上で、Smithへの変更がリプレイされます。同時に、レプリケーションによって、値Smithが保持されているサーバー上で、Jonesへの変更がリプレイされます。そのため、これらのサーバーは、変更されたエントリのsn属性の値として一貫しない値を保持することになります。
次のリストに、発生する可能性がある他の競合を示します。
あるサーバー上でエントリが削除され、その属性値の1つが別のサーバー上で変更された場合
あるサーバー上でエントリの名前が変更され、その属性値の1つが別のサーバー上で再変更された場合
あるサーバー上でエントリの削除およびそれと同じ識別名(DN)を持つ別のエントリの追加が行われ、その属性値の1つが別のサーバー上で変更された場合
親エントリが削除され、別のサーバー上で追加操作または名前変更操作のどちらかによってそのエントリの子が作成された場合
同じDNを持つ異なる2つのエントリが異なる2つのサーバー上で同時に追加された場合
異なるサーバー上の単一値属性の値が異なる2つの値で同時に置換される場合
同じエントリの変更のみが含まれる競合は、変更の競合と呼ばれます。変更以外の操作が少なくとも1つ含まれる競合は、名前の競合と呼ばれます。
すべての変更の競合と大部分の名前の競合は、発生順に操作をリプレイすることで自動的に解消できます。ただし、次に示す名前の競合は、発生することはまれですが、自動的に解消することができません。
新しいエントリの追加または既存エントリの名前の変更によって、同じDNの2つのエントリが異なるサーバー上で同時に作成された場合。
親エントリの削除とその子の作成が同時に行われた場合。子エントリは、新しいエントリが追加されたときか、既存のエントリの名前が変更されたときに、作成される可能性があります。
変更の競合は、変更操作でのみ発生します。
特定の一連の操作の結果を決定するために、操作はグローバルかつ論理的に順序付けされます。この順序を定義するために、変更番号を使用します。
レプリケーション競合の解消機能により、すべての操作が変更番号で定義された順序ですべての場所でリプレイされたかのように、すべてのサーバーが最終的に同じ状態に到達することが保証されます。このことは、変更が複数のサーバー上で異なる順序でリプレイされる可能性があっても、同じように成立します。snの値としてSmithとJonesが存在した前述の変更の競合の例では、1番目のサーバー上で値がSmithに設定された後に、2番目のサーバー上で値がJonesに設定されたと想定しています。結果的には、2番目のサーバー上でSmithに置換する変更がリプレイされた後であっても、両方のサーバー上の属性値がJonesになります。
各エントリの履歴情報は、現在の競合する操作の変更番号よりも新しい変更番号で、競合する操作がすでにリプレイされたかどうかをチェックするために保持されます。変更操作のたびに、履歴情報を使用して、まず競合が存在するかどうかをチェックし、存在する場合は操作の正しい結果を決定します。
変更の競合が発生した場合、サーバーは、現在の属性値を保持する必要があるかどうか、または変更を適用する必要があるかどうかを判断します。これを評価するには、現在の属性値のみでは不十分です。サーバーは、いつ(どの変更番号で)それ以前の変更が実行されたのかも確認します。したがって、履歴情報には、次の要素が含まれます:
属性が最後に削除された日付
特定の値が最後に追加された日付
特定の値が最後に削除された日付
属性が削除されるか、完全に置換された場合、それ以前の情報は必要なくなります。その時点で、それ以前の履歴情報は削除されます。
履歴情報に対して次の処理が行われます:
ds-sync-hist属性に保存されます(管理者のみ参照可能です)
通常の操作の場合に更新されます(ただし使用されません)
レプリケートされた操作の場合に更新および使用されます。
競合解消は、操作のリプレイの際、handleConflictResolutionフェーズの操作前処理の後に実行されます。
競合解消は、modifyOperationのList<Modification>フィールドを変更して、エントリのユーザー属性に対して実際に行う必要がある変更と一致させ、履歴情報の格納に使用されるds-sync-hist属性を変更することによって実行します。
名前の競合は、リプレイされた操作でのみ発生します。サーバーは、次の方法で名前の競合を解消します:
一意のIDを使用して、名前が変更されたエントリも含めて、エントリを識別します。
まず各操作のリプレイを試みて、競合が発生した場合のみアクションを実行します。
操作前処理で、操作のリプレイ時に検出できなかった競合をチェックします。
ツームストン・エントリ(削除マークが付けられていて、まだ削除されていないエントリ)は保持しません。
ディレクトリ・エントリは名前が変更される可能性があるので、DNはそのエントリの不変な値ではありません。したがって、DNを使用して、レプリケーションのためにエントリを識別することはできません。そのため、エントリの作成時に一意の不変な識別子が生成され、エントリの操作属性として追加されます。この一意のIDをDNのかわりに使用して、ディレクトリ・サーバーとレプリケーション・サーバーの間で送信される変更のエントリを識別します。
操作には、レプリケーション・コンテキストがアタッチされます。レプリケーション・コンテキストには、変更番号、エントリIDおよび親エントリIDなど、競合を解消するために必要なプライベート・レプリケーション情報が格納されています。
履歴情報は、サーバー・データベースに格納されます。したがって、履歴情報は、領域およびI/O帯域幅を消費し、キャッシュ効率を低下させます。履歴情報は、それより新しい変更がトポロジ内の他のすべてのサーバーによって確認されたらすぐに削除できます。
履歴情報が削除されるのは、次の場合です:
エントリに対して新しい変更が実行されたとき。
定期的にトリガー可能なパージ・プロセスを使用する場合。パージ・プロセスにより空き領域は増えますが、パージ処理のために余分にCPUを消費します。そのため、パージ・プロセスは構成可能です。詳細は、第29.5.2項「レプリケーション・パージ遅延の変更」を参照してください。
この項では、スキーマ・レプリケーション・アーキテクチャの詳細を理解する必要があるユーザー向けに、スキーマ・レプリケーションの実装方法について説明します。
スキーマには、ディレクトリ・サーバーに格納可能なエントリを記述します。スキーマ管理は、ディレクトリ・サービスの中核機能です。レプリケーションも、ディレクトリ・サービスの中心的機能であり、スケーラブルな高可用性サービスに必要不可欠です。
したがって、個々のディレクトリ・サーバーのスキーマに対してなんらかの変更が行われた場合、同一のサービスを提供するすべてのディレクトリ・サーバーに、その変更をレプリケートする必要があります。
スキーマ・レプリケーションは、次のいずれかの方法でスキーマが変更された場合に実行されます:
サーバーがオンラインのときにcn=schema接尾辞が変更された場合
サーバーがオンラインのときにファイルを使用して動的なスキーマ更新を実行する専用タスクが使用された場合
サーバーがオフラインのときに基礎となるバックエンド・ファイルが直接変更された場合
一般に、スキーマ変更は、新しいアプリケーションまたは新しいタイプのデータをデプロイした場合にのみ発生します。したがって、スキーマの変更頻度は多くありません。そのため、スキーマ・レプリケーションの実装では、スケーラビリティよりも単純さが優先されます。
スキーマのレプリケーションはデフォルトで有効になっています。特定の場合に、複数のディレクトリ・サーバー上で、それらがデータをすべてまたは一部共有している場合でも、複数のスキーマを使用する必要がある場合があります。そのような場合は、スキーマ・レプリケーションを無効にするか、またはスキーマ・レプリケーションに参加する限られた数のサーバーのリストを指定することができます。詳細は、第29.8項「スキーマのレプリケーションの構成」を参照してください。
スキーマ・レプリケーション・アーキテクチャは、一般的なレプリケーション・アーキテクチャに基づいています。したがって、この項を読む前に、一般的なレプリケーション・アーキテクチャについて理解する必要があります。詳細は、第7.1項「レプリケーション・アーキテクチャの概要」を参照してください。
ディレクトリ・サーバーは、ローカル・スキーマに対する変更について、レプリケーション・サーバーに通知します。データ・レプリケーションの場合と同様に、レプリケーション・サーバーはスキーマ変更を他のレプリケーション・サーバーに伝播し、それらのサーバーは受信した変更をトポロジ内の他のディレクトリ・サーバー上でリプレイします。
スキーマ・レプリケーションは、任意のサブツリーに使用されるレプリケーション構成と同じ構成を共有します:
dn: cn=example,cn=domains,cn=Multimaster Synchronization,\ cn=Synchronization Providers,cn=config objectClass: top objectClass: ds-cfg-replication-domain cn: example ds-cfg-base-dn: cn=schema ds-cfg-replication-server: <server1>:<port1> ds-cfg-replication-server: <server2>:<port2> ds-cfg-server-id: <unique-server-id>
スキーマ・レプリケーションは、次の点でデータ・レプリケーションと異なります:
エントリの一意のID。エントリは名前が変更されたり削除されたりする可能性があるので、データ・レプリケーションには一意のIDが必要です。
スキーマの場合、エントリは1つのみであり、そのエントリを削除したり名前を変更したりすることはできません。したがって、スキーマ・エントリには、一意のIDとしてスキーマ・エントリのDNを使用します。
履歴情報。履歴情報は、エントリに対する変更の履歴を保存するために使用されます。この情報により、変更の競合を解消できます。
スキーマ・レプリケーションの場合、唯一可能な操作は値の追加と値の削除です。したがって、スキーマに対する変更の場合、履歴情報は保持されません。
永続サーバー状態。ディレクトリ・サーバーが起動すると、レプリケーション・プラグインがレプリケーション・サーバーとの接続を確立します。レプリケーション・サーバーは、変更ログで変更をチェックして、ディレクトリ・サーバーに適用されていない変更があれば、それを送信します。
レプリケーション・プラグインは、変更ログのチェックを開始する位置を知るために、サーバーを停止して起動しても残る情報を格納します。この永続情報は、レプリケーションのbase-dnエントリに格納されます。
スキーマ・バックエンドを使用すると、永続状態を格納するために使用される特定の操作属性ds-sync-stateを変更できます。
レプリケーション・ドメインはデータを含んだディレクトリ・サーバーです。レプリケートされたトポロジ内のレプリケートされたドメインにはそれぞれ、特定のレプリケーション・ステータスが付けられます。レプリケーションのステータスは、トポロジ内のレプリケーション・ドメイン接続と、トポロジを通じて発生した変更を基にレプリケーション・ドメインがどのように更新されるかで決定されます。
ドメインのレプリケーション・ステータスを知ることで、レプリケートされるトポロジで次のことを実行できます:
保証レプリケーションの特定の側面の管理
特定の管理タスクの有効化
レプリケーションの効果的な管理と監視
詳細は、第32.7項「レプリケートされたトポロジの監視」を参照してください。
次の各項では、レプリケートされるドメインの取りうる複数のステータスについて説明します。
データを含んだディレクトリ・サーバー(レプリケーション・ドメイン)の場合、ステータスは次のいずれかになります。
正常。レプリケーション・サーバーへの接続は、正しいデータ・セットで確立されます。レプリケーションが機能しています。確実なモードを使用すると、このディレクトリ・サーバーからの確認が送信されます。
遅延。レプリケーション・サーバーへの接続は、正しいデータ・セットで確立されます。ディレクトリ・サーバーの持つ欠落している変更の数がレプリケーション・サーバー構成で定義されたしきい値を超えると、レプリケーションは遅延とマークされます。変更の数がこのしきい値を下回ると、ステータスは正常に戻ります。
完全更新。レプリケーション・サーバーとの接続が確立され、ローカル・バックエンドを初期化するために、新しいデータ・セットがこの接続から受信されます(オンライン・インポート)。
不正データ・セット。レプリケーション・サーバーとの接続が、トポロジの他のディレクトリ・サーバーとは異なるデータ・セットで確立されます。レプリケーションは動作しません。トポロジの他のディレクトリ・サーバーを互換性のあるデータ・セットを使用して初期化する必要があるか、またはこのサーバーを他のサーバーと互換性のある別のデータ・セットを使用して初期化する必要があります。
未接続。ディレクトリ・サーバーは、どのレプリケーション・サーバーとも接続されていません。
不明。ステータスを特定できません。これは、主にサーバーが停止中または到達不能な場合に起こりますが、別のサーバーの監視で参照されます。
無効。これは、内部使用のためのものです。ディレクトリ・サーバーの状態が変わり、ステート・マシンに従った遷移が困難な場合、INVALID_STATUSが返されます。
変更のリプレイの速度が低下しているディレクトリ・サーバーには、DEGRADED_STATUSが割り当てられます。サーバーが遅すぎると見なされる段階は、低下ステータスのしきい値によって定義され、レプリケーション・サーバーでそのディレクトリ・サーバーに対するキューに追加されている更新の数に基づいて構成可能です。
低下ステータスのしきい値に達すると、ディレクトリ・サーバーに低下ステータスが割り当てられ、時間内に確認を送信できないと見なされます。このステータスのサーバーは、保証レプリケーションに影響を及ぼします。なぜなら、これ以降のレプリケーション・サーバーは、自身が確認を返す前に、このサーバーからの確認を待機しなくなるからです。
低下ステータスが割り当てられたことは別にして、ディレクトリ・サーバーは、管理者がトポロジで次のいずれかのタスクを実行した場合、ステータスを変更できます:
完全更新。レプリケートされたドメインがトポロジ内の別のサーバーからオンラインで初期化された場合、そのドメインでのディレクトリ・サーバーのステータスはFULL_UPDATE_STATUSに変更されます。完全更新が完了すると、ディレクトリ・サーバーはトポロジへの接続を再初期化して、ステータスはNORMAL_STATUSにリセットされます。
ローカルのインポートまたはリストア。レプリケートされたドメインがローカルのインポートまたはリストアの手順を使用して再初期化された場合、そのドメインでのディレクトリ・サーバーのステータスはNOT_CONNECTED_STATUSに変更されます。
生成IDのリセット。レプリケートされたドメインの生成IDが、接続したレプリケーション・サーバーの生成IDと異なる場合、ドメインにBAD_GEN_IDステータスが割り当てられます。オンラインの完全更新、ローカル・インポート、またはレプリケーション・サーバーと異なる生成IDを持つ一連のデータによるリストアの後に再接続が行われた場合も、このステータスがドメインに割り当てられる可能性があります。
それ以外に、ディレクトリ・サーバー上で生成IDリセット・タスクを実行することによって、トポロジ内のすべてのレプリケーション・サーバーの生成IDをリセットする必要がある場合もあります。これにより、トポロジ内のすべてのレプリケーション・サーバーのIDは、接続しているディレクトリ・サーバーのIDと異なる値になります。この場合は、ディレクトリ・サーバーにBAD_GEN_IDステータスが割り当てられます。
レプリケーション・グループは、マルチデータ・センター・デプロイメントおよび障害回復シナリオをサポートする場合に設計します。レプリケーション・グループは、グループIDによって定義されます。グループIDは、ディレクトリ・サーバー上のレプリケートされるドメインに割り当てられる一意の数です(レプリケートされるドメインごとに1つのグループID)。グループIDは、レプリケーション・サーバーにも割り当てられます(レプリケーション・サーバー全体に対して1つのグループID)。
グループIDによって、ディレクトリ・サーバー・ドメインが利用可能なレプリケーション・サーバーに接続する方法が決まります。ディレクトリ・サーバーは、構成済のレプリケーション・サーバーのリストを参照して、自身のグループIDと同じグループIDを持つレプリケーション・サーバーに接続を試みます。ディレクトリ・サーバーは、互換性のあるグループIDを持つレプリケーション・サーバーが見つからない場合は、異なるグループIDを持つレプリケーション・サーバーに接続します。この選択プロセスの詳細は、次の項を参照してください。
レプリケーション・グループの構成方法は、第29.5.8項「レプリケーション・グループの構成」を参照してください。
この後の項を読む前に、基本的なレプリケーションの概念について理解している必要があります。ディレクトリ・サーバーと対比してレプリケーション・サーバーがどのような存在であるかを認識し、レプリケートされるトポロジ内でのレプリケーション・サーバーの動作を理解する必要があります。該当しない場合は、少なくとも第7.1項「レプリケーション・アーキテクチャの概要」を読んで、ディレクトリ・サーバーでの通常のレプリケーションの動作について理解してください。
標準のレプリケートされるトポロジでは、変更は、他のレプリケートされるサーバーに対してベストエフォート・モードでリプレイされます。LDAPサーバー上で行われた変更は、トポロジ内の他のサーバー上で、できるかぎり速やかに、ただし非同期で、リプレイされます。これは、パフォーマンス面では好都合ですが、当初のLDAPクライアント・コールが完了するまでに他のサーバーに変更が伝播済になることは保証しません。
これは、一部のデプロイメントでは許容されます。すなわち、最初のサーバー上での変更からピア・サーバー上でのリプレイまでの時間が十分に短く、デプロイメントの用件を満たしている場合です。たとえば、国際組織が、様々な地理的な場所にまたがるレプリケートされるトポロジで従業員のユーザー・アカウントを格納するとします。新しい従業員が雇用され、そのアカウントが特定の場所の特定のLDAPサーバーで作成された場合、LDAPクライアント・コールが終了してから数ミリ秒後に他のLDAPサーバー上で作成がリプレイされることは許容される可能性があります。このユーザーが、ユーザー・アカウントが作成されて1秒以内に、他のいずれかのLDAPサーバーにアクセスするホスト・ログインを実行する可能性はほとんどありません。
一方で、レプリケーション・プロセスで同期の必要性が高い場合があります。特定のホストに障害が発生した場合、そのホストで行われたあらゆる変更がトポロジ内の他の場所に伝播済であることが不可欠な場合があります。また、デプロイメントによっては、変更のLDAPクライアント・コールがサーバーから戻った時点で、トポロジ内のすべてのピア・サーバーがその変更を受信済であることを保証する必要がある場合があります。トポロジ内の任意の場所からそのエントリを読み取る他のクライアントは、確実にその変更を取得します。
保証レプリケーションは、通常のレプリケーションの動作の同期性を高める方法です。この項では、保証レプリケーションの動作について、アーキテクチャの観点から説明します。保証レプリケーションの構成の詳細は、第29.5.9項「保証レプリケーションの構成」を参照してください。
次の項では、保証レプリケーションの実装について説明します:
ディレクトリ・サーバーは現在、必要な同期レベル、レプリケートされるトポロジの目的および許容されるパフォーマンスへの影響に応じて、2つの保証レプリケーション・モードをサポートしています。
セーフ・データ・モードでは、あらゆる変更は、LDAPクライアント・コールが戻る前に、トポロジ内の指定された数のサーバーに伝播されます。変更が行われたLDAPサーバーに障害が発生した場合、その変更が少なくとも指定された数のサーバーに伝播済であることは保証されます。
この指定されたサーバーの数(N)は、セーフ・データ・レベルを定義します。セーフ・データ・レベルに関して使用されるのは、レプリケーション・サーバーからの確認のみです。言い換えると、LDAPサーバーから送信された更新メッセージは、更新を開始したLDAPクライアント・コールから戻る前に、少なくともN (N>1)個のレプリケーション・サーバーによって確認される必要があります。
セーフ・データ・レベルが大きいほど、更新を受信済であることが保証されるマシンの数が増えて、その結果、データの信頼性が高くなります。ただし、セーフ・データ・レベルが増えるにつれて、LDAPクライアント・コールが戻る前に必要な確認の数が増えるので、全体的なパフォーマンスは低下します。
セーフ・データ・レベルは、ベスト・エフォート・モードで動作します。すなわち、セーフ・データ・レベルが3に設定され、トポロジ内で使用可能なレプリケーション・サーバーが一時的に2つになった場合、3番目(使用不可)のレプリケーション・サーバーから確認を受信することは、このサーバーが再度使用可能になるまで期待できません。
レプリケーション・グループを使用する場合、セーフ・データ・モードが影響を受けます。保証レプリケーションはグループ境界内で行われるので、グループIDが1のレプリケーション・サーバーは、同じグループIDを持つ他のレプリケーション・サーバーからの確認を待機して、異なるグループIDを持つレプリケーション・サーバーからの確認は待機しません。詳細は、第7.6項「レプリケーション・グループ」を参照してください。
|
注意: 現在のレプリケーションの実装では、 このようなデプロイメントを構成できるのは、現在は |
例7-1 セーフ・データ・レベルが1の場合
セーフ・データ・レベルを1に設定すると、最初のレプリケーション・サーバーが、更新を受信してすぐにディレクトリ・サーバーに確認を返すことが保証されます。このレプリケーション・サーバーは、トポロジ内の他のレプリケーション・サーバーからの確認を待機しません。変更が別の(変更が行われたディレクトリ・サーバー以外の) 1つのサーバー上に存在することが保証されます。
この例を構成できるのは、dsconfigのみであり、setupコマンドまたはdsreplicationコマンドはサポートしていません。
例7-2 セーフ・データ・レベルが2の場合(RSとDSが異なるホスト上に存在)
セーフ・データ・レベルを2に設定すると、最初のレプリケーション・サーバーは、ディレクトリ・サーバーに確認を返す前に、1つのピア・レプリケーション・サーバーからの確認を待機することが保証されます。変更が別の(変更が行われたディレクトリ・サーバー以外の) 2つのサーバー上に存在することが保証されます。
この例を構成できるのは、dsconfigのみであり、setupコマンドまたはdsreplicationコマンドはサポートしていません。
例7-3 セーフ・データ・レベルが2の場合(RSとDSが同じホスト上に存在)
現在のレプリケーションの実装では、setupコマンドとdsreplicationコマンドは、レプリケーションがディレクトリ・サーバーと同じマシンに存在する構成のみサポートします。この実装では、変更が別の少なくとも1つのホストに送信されることを保証する必要がある場合、セーフ・データ・レベルを2に設定する必要があります。
セーフ読取りモードは、特定のディレクトリ・サーバー上で行われたあらゆる変更が、LDAPコールが戻る前に、トポロジ内の他のすべてのディレクトリ・サーバーに対してリプレイ済であることを保証します。このモードでは、別のLDAPクライアントがトポロジ内の別のディレクトリ・サーバー上で読取り操作を実行する場合、そのクライアントは直前に実行された変更を読み取ることが保証されます。セーフ読取りモードは、レプリケーションを構成できる最も同期性の高い方法です。ただし、このモードは、書込み時間という点で、パフォーマンスに及ぼす影響も最大です。
セーフ読取りモードに関して使用されるのは、トポロジ内のレプリケーション・サーバーではなく、LDAPサーバーからの確認です。ディレクトリ・サーバー上で変更が行われると、対応するレプリケーション・サーバーに更新が送信されます。このレプリケーション・サーバーは、トポロジ内の他のレプリケーション・サーバーに更新を転送します。これらのレプリケーション・サーバーは、変更が転送されたすべてのディレクトリ・サーバー上で変更がリプレイされたことの確認を待機します。トポロジ内のすべてのディレクトリ・サーバーで変更がリプレイされると、レプリケーション・サーバーは最初のレプリケーション・サーバーに確認を送信し、このサーバーは当初のディレクトリ・サーバーに確認を送信します。
最初のレプリケーション・サーバーは、他に直接接続しているディレクトリ・サーバーが存在する場合は、当初のディレクトリ・サーバーに確認を送信する前に、それらからの確認も待機します。当初のディレクトリ・サーバーがレプリケーション・サーバーから確認を受信した場合のみ、最後にLDAPクライアントに操作のコールの終了を返します。
この時点で、トポロジ内のすべてのディレクトリ・サーバーに変更が存在しています。したがって、LDAPクライアントが任意のディレクトリ・サーバーからデータを読み取った場合、確実に変更を取得しています。
レプリケーション・グループは、マルチデータ・センターのレプリケーションと高可用性をサポートします。レプリケーション・グループの詳細は、第7.6項「レプリケーション・グループ」を参照してください。保証レプリケーションを使用する場合、レプリケーション・グループを使用すると、一連のディレクトリ・サーバーがセーフ読取りモードで連携して動作できます。同期を取って連携して動作するディレクトリ・サーバーはすべて、同じグループIDを持つ必要があります。このグループIDは、同期したトポロジ内で動作するすべてのレプリケーション・サーバーにも割り当てられる必要があります。保証レプリケーションは、グループ境界内で行われます。
特定のグループID (N)を持つディレクトリ・サーバーで変更が行われた場合、グループIDがNである他のすべてのディレクトリ・サーバーが変更の確認を返す前に、LDAPコールが戻ることはありません。
レプリケーション・グループを使用すると、セーフ読取りモードを使用するレプリケートされるトポロジの柔軟性が高まります。
単一データ・センター・デプロイメントでは、完全に同期する必要があるディレクトリ・サーバーのサブセットを定義できます。同じグループIDを持つディレクトリ・サーバーのみが、同じグループIDを持つピアからの確認を待機します。レプリケーション・サーバーはすべて、同じグループIDを持っています。
マルチデータ・センター・デプロイメントでは、1つのデータ・センター内のすべてのディレクトリ・サーバーが完全に同期するように指定できます。ディレクトリ・サーバーは、LDAPコールが戻る前に、同一データ・センター内に存在するピアからの確認のみ待機します。確認を待機するのは、ディレクトリ・サーバーが同じグループIDを持つレプリケーション・サーバーに接続している場合のみです。
例7-4 1つのグループが存在する単一データ・センター内のセーフ読取りモード
次の図は、すべてのノードが同一データ・センター内に存在し、同一レプリケーション・グループの一部であるデプロイメントを示します。各ディレクトリ・サーバーと各レプリケーション・サーバーは、同一グループIDを持っています。変更は、LDAPクライアント・コールが戻る前に、トポロジ内のすべてのディレクトリ・サーバーでリプレイされる必要があります。その後は、トポロジ内のどのディレクトリ・サーバーのLDAP読取り操作でも、前の変更が読み取られることが保証されます。
このようなシナリオは、たとえば、レプリケートされるディレクトリ・サーバー・プールの前にLDAPロード・バランサが存在する場合に便利です。ロード・バランサがLDAP変更をリダイレクトするディレクトリ・サーバーを判断することは不可能なので、その後の読取り操作は、必ずしも変更が行われたディレクトリ・サーバーにはルーティングされません。この場合、LDAPクライアント・コールが戻る前に、トポロジ内のすべてのサーバー上で変更を行うことが不可欠です。
例7-5 複数のグループが存在する単一データ・センター内のセーフ読取りモード
次の図は、すべてのノードが同一データ・センター内に存在しますが、ディレクトリ・サーバーのサブセットでのみ保証レプリケーションが構成されているデプロイメントを示します。サーバーのこのサブセットはレプリケーション・グループを構成し、各サーバーに同一グループID (1)が割り当てられます。レプリケーション・グループ内のいずれかのディレクトリ・サーバーで変更が行われた場合、当初のLDAPコールがクライアントに戻る前に、グループ内のすべてのディレクトリ・サーバーからの確認を受信する必要があります。トポロジ内のそれ以外のディレクトリ・サーバーは変更のリプレイを続行しますが、それらからの確認を、LDAPコールが戻る前に受信する必要はありません。グループ外のいずれかのサーバーで変更が行われた場合は、LDAPコールがクライアントに戻る前に、他のディレクトリ・サーバーからの確認を受信する必要はありません。
この例では、レプリケーション・グループに属さないディレクトリ・サーバーに接続しているレプリケーション・サーバーにも、グループIDとして1が割り当てられています。この構成では、別のレプリケーション・サーバーがオフラインになった場合のフェイルオーバーが保証されます。この場合、レプリケーション・グループ内のディレクトリ・サーバーがこの特定のレプリケーション・サーバーに接続している場合は、保証レプリケーションは依然として動作します。フェイルオーバーが動作するには、グループ内のディレクトリ・サーバーがいずれ接続する可能性があるレプリケーション・サーバーが存在する場合は、それにも同じグループIDを割り当てる必要があります。
例7-6 マルチデータ・センター・デプロイメント内のセーフ読取りモード
次の図は、2つの(異なる地理的な場所にある)データ・センターで構成されるデプロイメントを示します。各データ・センター内には、ローカルにセーフ読取りモードが構成されています。同一データ・センター内のすべてのディレクトリ・サーバーとレプリケーション・サーバーには、同じグループID (1番目のデータ・センターでは1、2番目のデータ・センターでは2)が割り当てられています。同一データ・センター内のディレクトリ・サーバーは、非常に厳しく一貫して同期を取って動作しています。ディレクトリ・サーバー上で変更が行われた場合、LDAPクライアント・コールが戻る前に、同じデータ・センター内のすべてのディレクトリ・サーバー上で変更がリプレイされ、確認を受信する必要があります。
この例では、データは2つのデータ・センター間で同期されますが、特定のディレクトリ・サーバー上で行われた変更は、すぐに同じデータ・センター内の他のすべてのディレクトリ・サーバーで参照できるようになります。このシナリオは、データ・センターのディレクトリ・サーバーの前にLDAPロード・バランサが存在する場合に便利です。リモート・データ・センターのサーバーからの確認は必要ないので、書込みに関してパフォーマンスにそれほど大きな影響はありません。
このシナリオでは、レプリケーション・サーバーのグループIDが重要です。グループIDがNのディレクトリ・サーバーから変更を受信した場合、レプリケーション・サーバーはそのグループIDとNを比較して、次のアクションを実行します:
レプリケーション・サーバーが同じグループID (N)を持っている場合、直接接続しているすべてのレプリケーション・サーバーとディレクトリ・サーバーに変更を転送します。ただし、最初のディレクトリ・サーバーに自身の確認を送信する前に待機するのは、同じグループID (N)を持つサーバーからの確認のみです。
レプリケーション・サーバーが異なるグループIDを持っている場合、すべてのレプリケーション・サーバーとディレクトリ・サーバーに変更を転送しますが、確認は一切待機しません。
これまでの項で説明したシナリオを実装する際、トポロジ内のディレクトリ・サーバーは、次のアルゴリズムを使用して、接続する必要があるレプリケーション・サーバーを選択します:
構成されているレプリケーション・サーバーのリストの各レプリケーション・サーバーに接続して、そのサーバー状態とグループIDを取得します。
ディレクトリ・サーバー上の最新の変更を保持し、ディレクトリ・サーバーと同じグループIDを持つレプリケーション・サーバーのリストから、トポロジ内の他のディレクトリ・サーバーからの更新を最も多く保持しているレプリケーション・サーバーを選択します。ディレクトリ・サーバーと同じグループIDを持つレプリケーション・サーバーが1つも存在しない場合は、最新の内容を持つレプリケーション・サーバーを選択します。
このアルゴリズムにより、ディレクトリ・サーバーと同じグループIDを持つレプリケーション・サーバーに高い優先度が割り当てられることが保証されます。したがって、ディレクトリ・サーバーは、同じデータ・センター内に存在するレプリケーション・サーバーを優先します。
(同じデータ・センター内で)同じグループIDを持つレプリケーション・サーバーに接続することにより、セーフ読取りモード機能が提供されます。異なるグループIDを持つレプリケーション・サーバーに接続することにより、(ローカル・データ・センター内のすべてのレプリケーション・サーバーで障害が発生した場合の)もう1つのデータ・センターへのフェイルオーバーが提供されます。この場合、更新メッセージを異なるグループIDを持つレプリケーション・サーバーに送信しても、確認は要求されないので、セーフ読取りモードは無効になります。レプリケーションは続行されますが、低下モードになります。(すなわち、構成の際に要求されたセーフ読取りモードは適用されません。)
正常なレプリケーションに戻すために、ディレクトリ・サーバーは定期的に構成リストをポーリングして、同じグループIDを持つレプリケーション・サーバーの出現をチェックします。ディレクトリ・サーバーは、同じグループIDを持つレプリケーション・サーバーが使用可能になったことを検出すると、現在のレプリケーション・サーバー(グループIDが異なる)を切断して、検出した同じグループIDを持つレプリケーション・サーバーに再接続します。これにより、セーフ読取りモードが再び有効になり、レプリケーションは構成されたモードに戻ります。
レプリケーション・サーバーが、トポロジ内で行われた全体的な更新に関して同期外れになっているディレクトリ・サーバーを検出した場合、そのディレクトリ・サーバーは低下ステータスであると見なされます。同期外れのディレクトリ・サーバーは、タイムアウトにならないよう時間内にレプリケーション・サーバーに期待されている確認を送信することはほぼ不可能です。したがって、このサーバーは、保持する更新が許容できるレベルに達するまで、低下ステータスになります。低下ステータスのディレクトリ・サーバーは、正常ステータスに戻るまでの間、レプリケーション・サーバーに確認を送信することは期待されません。
低下ステータスのディレクトリ・サーバーは確認を送信できないので、セーフ読取りモードでのLDAP操作の同期は保証できません。言い換えると、このディレクトリ・サーバーから読み取ったデータには、トポロジ内の別のディレクトリ・サーバーで行われた変更が含まれていない可能性があります。
詳細は、第7.5.1項「レプリケーション・ステータスの定義」を参照してください。
保証レプリケーション・メカニズムには、メカニズムの正常動作を監視するための様々な属性が定義されています。次の表は、トポロジ内のディレクトリ・サーバーとレプリケーション・サーバーで定義されている監視属性を示します。
これらの属性は、ディレクトリ・サーバーの場合は、レプリケートされているDNのmonitorエントリの下にあります。たとえば、レプリケートされるドメインdc=example,dc=comに関する監視情報は、監視エントリcn=Replication Domain,dc=example,dc=com,server-id,cn=monitorの下にあります。
レプリケーション・サーバーの場合は、保証レプリケーションに関する監視情報が接続ごとに存在します。監視属性は、現在のレプリケーション・サーバーに接続しているディレクトリ・サーバーまたはレプリケーション・サーバーの監視エントリに存在します。たとえば、特定のレプリケーション・サーバーでは、接続しているディレクトリ・サーバーに関する監視情報は、監視エントリcn=Directory Server dc=example,dc=com ds-host,server-id,cn=monitorの下にあります。接続しているレプリケーション・サーバーに関する監視情報は、監視エントリcn=Remote Replication Server dc=example,dc=com repl-server-host:repl-port,server-id,cn=monitorの下にあります。
表7-1 ディレクトリ・サーバーの監視属性
| 属性名 | 属性のタイプ | 説明 |
|---|---|---|
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで送信した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで送信し、正常に確認した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで送信し、(タイムアウト、不正なステータスまたはリプレイ時のエラーのいずれかの理由で)正常に確認していない更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで送信し、タイムアウトが理由で正常に確認していない更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで送信し、不正なステータスが理由で正常に確認していない更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで送信し、リプレイ時のエラーが理由で正常に確認していない更新の数。 |
|
|
文字列 |
複数の値を設定可能: 保証レプリケーションのセーフ読取りモードで送信し、特定のサーバー(ディレクトリ・サーバーまたはレプリケーション・サーバー)について(タイムアウト、不正なステータスまたはリプレイ時のエラーのいずれかの理由で)正常に確認していない更新の数。文字列形式: サーバーid:失敗した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで受信した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで受信し、エラーなしで確認した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードで受信し、エラーありで確認した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ・データ・モードで送信した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ・データ・モードで送信し、正常に確認した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ・データ・モードで送信し、タイムアウトが理由で正常に確認していない更新の数。 |
|
|
文字列 |
複数の値を設定可能: 保証レプリケーションのセーフ・データ・モードで送信し、特定のRSについて(タイムアウトが理由で)正常に確認していない更新の数。文字列形式: サーバーid:失敗した更新の数。 |
表7-2 レプリケーション・サーバーの監視属性
| 属性名 | 属性のタイプ | 説明 |
|---|---|---|
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードでリモート・サーバーから受信した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードでリモート・サーバーから受信し、転送する際にタイムアウトした更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードでリモート・サーバーに送信した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ読取りモードでリモート・サーバーに送信し、タイムアウトした更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ・データでリモート・サーバーから受信した更新の数。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ日付モードでリモート・サーバーから受信し、転送する際にタイムアウトした更新の数。リモート・サーバーがレプリケーション・サーバーの場合、この属性に意味はありません。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ・データ・モードでリモート・サーバーに送信した更新の数。リモート・サーバーがディレクトリ・サーバーの場合、この属性に意味はありません。 |
|
|
整数(0..N) |
保証レプリケーションのセーフ・データ・モードでリモート・サーバーに送信し、タイムアウトした更新の数。リモート・サーバーがディレクトリ・サーバーの場合、この属性に意味はありません。 |
部分レプリケーション機能を使用して、トポロジ内の特定のサーバーで変更操作がリプレイされるときに、特定の属性を除外できます。部分レプリケーションの構成の詳細は、第29.5.10項「部分レプリケーションの構成」を参照してください。
この項では、部分レプリケーション・メカニズムのアーキテクチャについて説明します。内容は次のとおりです:
部分データ・セットは、レプリケートされるドメインのルート・エントリに格納される次の操作属性によって特定されます:
ds-sync-fractional-exclude
ds-sync-fractional-include
これらの属性の構文と意味は対応する構成属性と同じです。詳細は、第29.5.10項「Configuring Fractional Replication」を参照してください。これらの操作属性の役割は、データ・セットが部分であることを示すタグを付けることです。それらの属性がドメインに存在することは、このデータ・セットが部分ドメインであり、特定の属性が除外されていることを示します。
ドメインのルート・エントリに格納される部分構成と、生成ID (ds-sync-generation-id)およびレプリケーション状態(ds-sync-state)を合せて、部分シグネチャと見なすことができます。
ドメインを有効にすると(たとえば、その部分構成を変更した後で)、サーバーは、ドメインの部分構成(cn=configの下)とドメインのルート・エントリの部分構成属性を比較します。両方の構成が一致した場合、ドメインは正常ステータスであると見なし、LDAP操作を受け付けることができます。構成が一致しない場合、ドメインは不正な生成IDステータスであると見なし、LDAP操作を受け付けるには、(データ・セットをインポートして)データ・セットを同期する必要があります。
インポートするデータ・セットは、次のどちらかである必要があります:
そのルート・エントリにある部分構成が、ローカル・ドメインのcn=configの下にある部分構成と同じであること。この場合、データ・セットはそのままインポートされます。
そのルート・エントリに部分構成が存在しないこと。この場合、データ・セットはインポートされてから、ローカル・ドメインの部分構成(cn=configの下)で定義されている属性フィルタリング・ルールに従ってフィルタされます。その後、ローカル・ドメインの部分構成をコピーすることによって、インポートされたデータのルート・エントリにds-sync-fractional-exclude属性またはds-sync-fractional-include属性が作成されます。
ドメインが部分として構成されている場合、リプレイを目的としてネットワークから着信するADD、MODIFYおよびMODIFYDNのすべての操作はフィルタ処理されます。これらの操作は、部分構成に従って操作の属性がすべてフィルタ処理された場合、最終的に中止される可能性があります。
LDAPクライアントが部分レプリカに対して直接実行した操作が部分構成に一致しない場合、その操作は禁止され、サーバーは「実行要求を拒否」エラーを返します。
たとえば、部分レプリカがfractional-exclude: *:jpegPhotoで構成されている場合、LDAPクライアントがjpegPhoto属性を含む新しいエントリを追加しようとすると、「実行要求を拒否」エラーで拒否されます。この動作により、このドメインにはjpegPhoto属性が存在できないことを意味する部分構成定義に関して、ドメインの一貫性が維持されることが保証されます。
