Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11g リリース1(11.1.1) B55919-02 |
|
前 |
次 |
この章では、Oracle Internet Directoryレプリケーションの概要について説明します。レプリケーションは、複数のディレクトリ・サーバーに同じネーミング・コンテキストをコピーし、管理するプロセスです。これにより、問合せを処理するサーバーの数が増え、クライアントの近くにデータを持ってくるため、パフォーマンスが向上します。また、シングル・ポイント障害に関連するリスクを排除することで信頼性が向上します。
図6-1に、レプリケート・ディレクトリを示します。
レプリケーションを実装する理由の多くは、次のようなものです。
多くの企業は世界中の様々な地域で活動しており、それらの活動には共通ディレクトリが必要です。複数の中継ルーターを含む、低帯域幅のリンクで各地域が相互接続されているとします。地域の外部からディレクトリ・サーバーにアクセスしているクライアントは、長い待機時間や不十分なスループットを体験する場合があります。このような場合には、地域レプリカが必要です。
ディレクトリ・アクセスが既存のサーバーの容量を超えると、追加のサーバーが負荷を共有できます。デプロイメントが負荷を満たしている場合でも、1つのハイエンド・システムよりも2つの比較的安価なシステムをメンテナンスする方が、費用がかからない場合があります。
ディレクトリ・レプリケーションを実装する最も重要な理由の1つは、システム全体の可用性を増すことです。1つのサーバーが使用できない場合、通信量は他の使用可能なサーバーに送られます。これはクライアントには透過的です。
この項では、レプリケーションの基本的な概念を簡単に紹介します。
この項の項目は次のとおりです。
レプリケーションの設定時には、DITを1つのノードから別のノードにどの程度レプリケートするかを決定する必要があります。選択肢は次の2つです。
完全レプリケーションでは、DIT全体を別のノードに伝播します。このタイプのレプリケーションでは、ディレクトリ全体の高可用性が保証されます。このレプリケーションを使用して、ディレクトリ全体の操作を様々なノードに分散することもできます。完全レプリケーションは、LDAPまたはOracle Databaseアドバンスト・レプリケーションのどちらかに基づきます。
部分レプリケーションでは、DIT全体ではなく、1つ以上のサブツリーを別のノードに伝播できます。この方法でディレクトリを分散することによって、サーバー間の作業負荷を均衡化し、フォルト・トレランスおよびフェイルオーバー機能を備え、可用性に優れた分散ディレクトリを構築することができます。コマンドライン・ツールまたはOracle Enterprise Managerのレプリケーション・ウィザードを使用して、部分レプリケーションを設定できます。部分レプリケーションは、ほとんどの場合LDAPベースです。
図6-2に、部分レプリケーションの例を示します。
レプリケーションの方向には、一方向、双方向またはpeer-to-peerがあります。
表6-2 レプリケーションの方向
方向 | 説明 |
---|---|
一方向 |
一方のノードがサプライヤとして、もう一方がコンシューマとして構成されます。コンシューマは読取り専用です。 |
双方向 |
どちらのノードも、サプライヤとコンシューマの両方の役割を果します。読取りと書込みの両方が可能、つまり更新可能です。 |
peer-to-peer |
レプリケーション・グループ内のすべてのノードが、他のノードすべてに対してサプライヤでありコンシューマでもあります。 |
読取り専用や読取り/書込みという用語は、レプリケーションの方向を説明するために使用されることがあります。一方向レプリケーション承諾では、コンシューマ・ノードは読取り専用と言われます。つまり、他のノードに対する変更をそのノードに書き込むことで伝播できません。双方向レプリケーション承諾では、両方のノードが読取り/書込み兼用と考えられます。読取り/書込みは、更新可能とも呼ばれます。
場合によっては、peer-to-peerにかわりにマルチマスターという用語が使用されます。マルチマスターは、「ディレクトリ・レプリケーション・グループ(DRG)タイプ: 単一マスター、マルチマスターまたはファンアウト」に示すように、実際にはレプリケーション・グループのタイプを示します。
Oracle Internet Directoryでは、1つのノードから別のノードへのデータのレプリケーションに使用できる2つのプロトコルをサポートしています。プロトコルは次のとおりです。
表6-3 転送プロトコル
転送メカニズム | 説明 |
---|---|
LDAP |
業界標準のLightweight Directory Access Protocolバージョン3を使用します。これは、Oracle Single Sign-Onレプリケーションも実行する場合を除き、レプリケーションに使用する推奨プロトコルです。 |
Oracle Databaseアドバンスト・レプリケーション |
Oracle Databaseのレプリケーション機能を使用します。アドバンスト・レプリケーションとも呼ばれます。現在、Oracle Single Sign-Onレプリケーションではこのレプリケーション・プロトコルが必要です。 |
LDAPレプリケーションは、peer-to-peer、一方向または双方向のいずれかに構成できます。アドバンスト・レプリケーションは、通常peer-to-peerです。
指定したネーミング・コンテキストのレプリケーションの対象となるディレクトリ・サーバーは、ディレクトリ・レプリケーション・グループ(DRG)を形成します。DRGを構成するディレクトリ・サーバー間の関係は、各ノード上でレプリケーション承諾と呼ばれる特別なディレクトリ・エントリによって表されます。レプリケーション承諾は、一方向または双方向のいずれかです。
サーバー内に格納されているネーミング・コンテキストの各コピーは、レプリカと呼ばれます。他のサーバーに更新情報を送信するサーバーをサプライヤといいます。その更新情報を受け取るサーバーをコンシューマといいます。サーバーは、サプライヤとコンシューマのどちらにもなることができます。
ディレクトリ・レプリケーション・グループは、表6-4で説明するように、単一マスター、マルチマスターまたはファンアウトになります。
表6-4 ディレクトリ・レプリケーション・グループのタイプ
グループ | 説明 |
---|---|
単一マスター |
1つ以上のコンシューマに変更をレプリケートするサプライヤが1つのみ存在します。クライアントはマスター・ノードのみを更新でき、コンシューマのデータの読取りのみを行うことができます。このタイプのグループでは、通常はLDAPを使用します。1つのグループ内で1ノードを除くすべてのノードを読取り専用モードに切り替えることにより、アドバンスト・レプリケーションを単一マスターとして構成することもできます。 |
同等のものとして機能する複数のサイトが、レプリケートされたデータのグループを管理できるようにします。マルチマスター・レプリケーション環境では、各ノードはサプライヤとコンシューマ・ノードのどちらにもなります。マルチマスター・レプリケーションでは、転送メカニズムとしてLDAPまたはアドバンスト・レプリケーションを使用できます。完全なDITが各ノードにレプリケートされます。レプリケーションは常にpeer-to-peerです。 |
|
point-to-pointレプリケーション・グループとも呼ばれ、コンシューマに直接レプリケートするサプライヤが含まれています。コンシューマは1つ以上の他のコンシューマにレプリケートできます。ファンアウト・レプリケーションでは、転送メカニズムにLDAPを使用します。レプリケーションには、完全レプリケーションと部分レプリケーションがあります。これは一方向または双方向のいずれかです。 |
図6-3「単一マスター・レプリケーションの例」に、単一マスター・レプリケーション環境を示します。
図6-3の各円は、Oracle Internet Directoryのノードを表しています。ノードAはサプライヤであり、コンシューマ・ノードBおよびCをレプリケートします。ノードAは読取り/書込み可能、ノードBとCは読取り専用です。データ転送プロトコルはLDAPです。
図6-4の例に、マルチマスター・レプリケーション・グループ内で相互に更新する3つのノード(A、B、C)を示します。ノード間のレプリケーションは双方向です。
図6-4では、すべてのレプリケーションは双方向です。
注意: Oracle Single Sign-Onでサポートされているレプリケーション方式はマルチマスター・レプリケーションのみです。詳細は、10g(10.1.4.0.1)ライブラリの『Oracle Application Server Single Sign-On管理者ガイド』の高可用性に関する章でレプリケーション用Oracle Single Sign-Onの構成に関する項を参照してください。 |
図6-5に、ファンアウト・レプリケーション環境を示します。
表6-5で、サプライヤAは、BとCの2つのコンシューマに対してレプリケーションを行います。コンシューマ・ノードBにはAの部分レプリカが含まれ、コンシューマ・ノードCにはAの完全レプリカが含まれます。
続いてこれらの各ノードが、データを他の2つのコンシューマに対してレプリケートするサプライヤとして機能し、ノードBはノードDおよびEに対して部分レプリケーションを行い、ノードCはノードFおよびGに対して完全レプリケーションを行います。ノードDおよびFは読取り専用です。
ファンアウト・レプリケーションでは、ノードはLDAPを使用してデータを転送します。
ディレクトリ・レプリケーション・アーキテクチャはゆるやかな一貫性モデルに基づいており、レプリケーション承諾がなされた2つのレプリケートされたノードが、リアルタイムで一貫性を持つかどうかは保証されません。これにより、相互接続されたすべてのノードが使用可能でなくてもクライアントでデータを変更できるため、ディレクトリ・ネットワークの全体的な柔軟性と可用性が向上します。たとえば、1つのノードが使用できないか、または高負荷であるとします。マルチマスター・レプリケーションを使用すると、操作を代替ノードで実行でき、相互接続されたすべてのノードは徐々に同期化されます。
表6-5は、LDAPとOracle Databaseアドバンスト・レプリケーションの2つの転送メカニズムを示すとともに、各タイプを他のレプリケーションの概念と組み合せる方法を示しています。
表6-5 ディレクトリ・レプリケーション・グループでのノード間のデータ転送のタイプ
概念 | LDAPベースのレプリケーション | Oracle Databaseアドバンスト・レプリケーション・ベースのレプリケーション |
---|---|---|
レプリケートされるコンテンツ |
完全レプリカ 部分レプリカ |
完全レプリカ(通常) |
レプケーションの方向 |
peer-to-peer 一方向 双方向 |
peer-to-peer |
DRGタイプ |
マルチマスター・レプリケーション 単一マスター・レプリケーション ファンアウト・レプリケーション |
マルチマスター・レプリケーション 単一マスター・レプリケーション(マルチマスター構成内の1つを除く他のすべてのマスターを読取り専用モードに切り替えた場合) |
Oracle Internet Directoryは、マルチマスター・レプリケーション・グループ内の任意のノードが、ファンアウト・レプリケーション承諾の対象にもなるようにします。マルチマスター・レプリケーション承諾内では、ノード間のデータ転送はOracle Databaseアドバンスト・レプリケーションまたはLDAPを介して行われます。ファンアウト・レプリケーション承諾内では、サプライヤからコンシューマへのデータ転送はLDAPを介して行われ、一方向または双方向のどちらも可能です。
図6-6に、ファンアウト・レプリケーションとともに使用するマルチマスター・レプリケーションの例を示します。
図6-6の例では、3つのノード(A、B、C)がマルチマスター・レプリケーション・グループを形成しています。これらのノード間では、LDAPまたはアドバンスト・レプリケーションを使用してデータを転送します。
ノードBは、ディレクトリ全体のレプリカであるノードDに変更を提供します。ノードDは、LDAPベースのレプリケーションを使用して、ノードFおよびGに変更を提供します。ノードFおよびGは、ディレクトリ全体のレプリカです。同様にノードEはノードCの完全なレプリカです。ノードEは、LDAPベースのレプリケーションを使用して、ディレクトリ全体のレプリカであるノードHおよび部分レプリカであるノードIに変更を提供します。ノードFおよびHは、読取り専用です。
関連項目: ファンアウト・レプリケーションの詳細は、29-23ページの「LDAPベースのレプリケーション」を参照 |
必要なレプリケーションのタイプは、その企業の重要な機能によって異なります。この項では、ローカルな可用性、ロード・バランシングおよび高可用性の3つの機能を満たすために使用するレプリケーションのタイプについて説明します。
ローカルな可用性は次の状況で重要になります。
ローカル・サイトに固有のマスター・データのローカル・コピーが必要な場合。このようなローカル・コピーには、DITの全体または一部が考えられます。
複数のサーバーに作業負荷を分散することで実現可能なスケーラビリティとパフォーマンスの強化が必要な場合。
ユーザーがローカル・サイトからマスター・サイトに接続することで生じるネットワークの依存性と負荷を軽減する場合。
ローカル・サイトでデータを更新しない場合、マスター・ノードからローカル・ノードへの一方向レプリケーションを使用します。
ローカル・サイトはデータの更新を必要とせず、マスター・サイトに更新を再度レプリケートする必要がある場合、マスター・ノードとローカル・ノードの間で双方向レプリケーションを使用します。
ロード・バランシングは次の状況で重要になります。
複数のサーバーに作業負荷を分散することでスケーラビリティとパフォーマンスを強化する場合。
特定のサーバーを、シングル・サインオンまたは電子メールなどの特定のアプリケーション専用にする場合。
ネットワークのロード・バランシングが必要な場合。
LDAPマルチマスター・レプリケーションを使用すると、2つ以上のノード間でデータをレプリケートできます。Oracle Single Sign-On 10g(10.1.4.3.0)以上もインストールされており、Oracle Single Sign-Onスキーマをロード・バランシングでレプリケートする必要がある場合は、Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションを使用します。それ以外の場合は、LDAPベースのマルチマスター・レプリケーションを使用できます。
注意: レプリケーションで使用するためにロード・バランサを構成する場合は、ラウンドロビン・ルーティングではなくスティッキー・ルーティングを使用します。本来、レプリケーションは非同期であるため、一方のノードに行った変更が、他方のノードで即座に有効になるわけではありません。 |
高可用性は次の状況で重要になります。
単一サーバー障害による損失を防ぐために1つ以上のバックアップ・サーバーを備えた高可用性ソリューションが必要な場合。
デプロイメントを地理的に分散することによって災害からアプリケーションを守る障害回復ソリューションが必要な場合。
通常、LDAPベースのマルチマスター・レプリケーションを使用すると、2つ以上のノード間でデータをレプリケートできます。ただし、Oracle Internet DirectoryとともにOracle Single Sign-On 10g(10.1.4.3.0)以上もインストールされている場合は、Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションを使用します。