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