第 9 章「基本的な配備の設計」で説明した基本的な配備では、1 つの Directory Server で、組織の読み取り要件および書き込み要件を十分に満たせることを前提としています。読み取りまたは書き込み要件がそれよりも厳しい (多数のクライアントがディレクトリデータに同時アクセスを試みる) 組織では、拡張配備を使用する必要があります。
一般に、すべてのデータをキャッシュするための十分なメモリーが搭載されているという仮定のもとで、Directory Server インスタンスが 1 秒あたりに実行できる検索の件数は、サーバーの CPU の数および速度と直接関係します。水平的な読み取りの拡張容易性は、2 台以上のサーバーに負荷を分散させることによって達成できます。これは通常、データの追加コピーを用意して、クライアントが複数のソースからデータを読み取れるようにすることを意味します。
書き込み操作は水平的には拡張しません。それは、マスターサーバーへの書き込み操作の結果として、すべてのレプリカへの書き込み操作が発生するためです。書き込み操作を水平的に拡張する唯一の方法は、ディレクトリデータを複数のデータベースに分割し、それらのデータベースを複数の異なるサーバーに配置することです。
この章では、読み取りおよび書き込みの処理可能件数を増やすために Directory Server Enterprise Edition 配備を拡張する各種の方法について説明します。この章の内容は次のとおりです。
負荷分散は、読み取り負荷を複数のサーバーに拡散させることによってパフォーマンスを高めます。負荷分散は、レプリケーション、Directory Proxy Server、またはこの両者の組み合わせを使用して実現できます。
レプリケーションは、ディレクトリデータをコピーし、あるディレクトリサーバーから別のディレクトリサーバーに切り替える処理を自動的に行う機構です。レプリケーションを使用することで、ディレクトリツリー、またはそのツリーに固有のサフィックスに格納されるサブツリーをサーバー間でコピーできます。
設定または監視情報のサブツリーはコピーできません。
ディレクトリデータをサーバー間でレプリケートすることにより、1 台のマシンにかかるアクセス負荷を軽減して、サーバーの応答時間を短縮し、読み取りの拡張容易性を提供することができます。ディレクトリのエントリをユーザーに近い場所にレプリケートすることで、ディレクトリの応答時間を短縮することもできます。レプリケーションは一般的に、書き込みの拡張容易性のためのソリューションではありません。
レプリケーション機構については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 4 章「Directory Server Replication」で詳しく説明しています。次の節では、この章の後半で説明するサンプルトポロジを検討する前に理解しておく必要がある基本的な情報を示します。
レプリケーションに関与するデータベースを「レプリカ」と呼びます。
Directory Server では、3 種類のレプリカを区別しています。
マスターレプリカ (読み書き可能レプリカ): ディレクトリデータのマスターコピーを含む読み書き可能データベース。マスターレプリカは、ディレクトリクライアントからの更新要求を処理できます。複数のマスターを含むトポロジのことを「マルチマスター」トポロジと呼びます。
コンシューマレプリカ: マスターレプリカ内の情報のコピーを保持する読み取り専用データベース。コンシューマレプリカは、ディレクトリクライアントからの検索要求を処理できますが、更新要求はマスターレプリカを照会します。
ハブレプリカ: コンシューマレプリカと同様の読み取り専用データベース。1 つ以上のコンシューマレプリカを「供給」する Directory Server 上に格納されます。
次の図は、レプリケーショントポロジ内でのこれらの各レプリカのロールを示したものです。
この図は例示のみを目的としたものであり、必ずしも推奨されるトポロジではありません。マルチマスタートポロジで、Directory Server 6.x がサポートするマスター数は無制限です。ほとんどの場合、マスターのみのトポロジが推奨されます。
ほかのサーバーにレプリケートする Directory Server のことを「サプライヤ」と呼びます。また、ほかのサーバーによって更新される Directory Server のことを「コンシューマ」と呼びます。サプライヤは、特別に設計された LDAP v3 拡張処理により、コンシューマ上のすべての更新を再現します。このためサプライヤは、パフォーマンスの面ではコンシューマに対する要件の多いクライアントアプリケーションに似ています。
次のような状況で、サーバーはサプライヤとコンシューマの両方になることができます。
2 つの異なる Directory Server 上にそれぞれマスターレプリカが配置されているマルチマスターレプリケーション環境では、一方のサーバーは、他方のサーバーのサプライヤとして、またコンシューマとしての役割を果たします。
サーバーにハブレプリカが含まれるとき、サーバーはサプライヤから更新を受け取り、変更内容をコンシューマにレプリケートします。
コンシューマのロールのみを果たすサーバーのことを「専用コンシューマ」と呼びます。
「マスターレプリカ」の役割をするサーバーは次のことを行う必要があります。
ディレクトリクライアントからの更新要求に応答する
履歴情報および変更履歴ログを維持する
コンシューマへのレプリケーションを開始する
マスターレプリカを含むサーバーは、マスターレプリカに対して行われたすべての変更を記録する処理と、これらの変更をコンシューマにレプリケートする処理を受け持ちます。
「ハブレプリカ」の役割をするサーバーは次のことを行う必要があります。
読み取り要求に応答する
マスターレプリカを保持するサーバーに更新要求を送信する
履歴情報および変更履歴ログを維持する
コンシューマへのレプリケーションを開始する
「コンシューマレプリカ」の役割をするサーバーは次のことを行う必要があります。
読み取り要求に応答する
履歴情報を維持する
マスターレプリカを保持するサーバーに更新要求を送信する
マルチマスターレプリケーション設定では、データは異なる場所で同時に更新することができます。各マスターは、そのレプリカの変更履歴ログを維持します。各マスター上で発生した変更は、ほかのサーバーにレプリケートされます。
マルチマスター設定には、次の利点があります。
1 つのマスターにアクセスできなくなった場合でも、自動的に書き込み処理のフェイルオーバーが発生します。
地理的に分散されている環境では、ローカルのマスターで更新処理を実行できます。
マルチマスターレプリケーションでは、疎整合レプリケーションモデルを使用します。つまり、同一のエントリを別々のサーバーから同時に変更できます。2 つのサーバー間で更新が送信された場合、更新の競合を解決する必要があります。待ち時間などの WAN の各種特性により、レプリケーション競合の可能性が高まる可能性があります。競合の解決は通常、自動的に行われます。どの変更が優先されるかは、競合規則によって決定されます。競合を手動で解決しなければならない場合もあります。詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「よく発生するレプリケーションの競合の解決」を参照してください。
マルチマスタートポロジでサポートされるマスターの数は、理論上は無制限です。同様に、コンシューマとハブの数も理論上は無制限です。ただし、1 つのサプライヤから何個のコンシューマにレプリケーションを実行できるかは、サプライヤサーバーの能力に依存します。サプライヤサーバーの能力を評価するために、SLAMD 分散負荷生成エンジン (SLAMD) を使用できます。SLAMD の詳細および SLAMD ソフトウェアのダウンロードについては、http://www.slamd.com を参照してください。
レプリケーションの最小単位はサフィックスです。レプリケーション機構では、サフィックスとデータベースが 1 対 1 で対応している必要があります。カスタム分散ロジックを使用している 2 つ以上のデータベースにまたがって分散されているサフィックス (またはネームスペース) はレプリケートできません。レプリケーション単位は、コンシューマとサプライヤの両方に適用されます。つまり、1 つのサフィックスだけを保持するコンシューマに 2 つのサフィックスをレプリケートすることはできません。
サプライヤとして機能するすべてのサーバーは更新履歴ログを維持します。「更新履歴ログ」は、マスターレプリカに対して行われた変更を記述した記録です。サプライヤは、この変更をコンシューマ上で再現します。エントリの変更、名称変更、追加、または削除が行われると、LDAP 操作を記述する変更レコードが更新履歴ログに記録されます。
Directory Server では、レプリケーションアグリーメントを使用して、2 つのサーバー間でレプリケーションがどのように行われるかを定義します。「レプリケーションアグリーメント」は、1 つのサプライヤと 1 つのコンシューマの間のレプリケーションを定義します。
レプリケーションアグリーメントは次のものを識別します。
レプリケートするサフィックス
データがレプリケートされるコンシューマサーバー
レプリケーションを実行できる時間帯
サプライヤがコンシューマへのバインドに使用する必要があるバインド DN と資格
接続をセキュリティー保護する方法 (SSL やクライアント認証など)
この特定のアグリーメントのレプリケーションの状態に関する情報
レプリケーションフィルタについての情報
Directory Server 6.x よりも前のバージョンの Directory Server では、更新は時系列順にレプリケートされていました。本バージョンでは、更新のレプリケーションに優先順位を付けることができます。優先度はブール型の機能であり、オンまたはオフを選択できます。優先度のレベルはありません。レプリケーションを待機している更新のキュー内で、優先度がオンの更新は、優先度がオフの更新よりも先にレプリケートされます。レプリケーションを待機している更新のキュー内で、優先度がオンの更新は、優先度がオフの更新よりも先にレプリケートされます。
優先度規則は、次のパラメータに従って設定されます。
クライアントのアイデンティティー
更新のタイプ
更新されたエントリまたはサブツリー
更新によって変更される属性
詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Prioritized Replication」を参照してください。
ディレクトリサービスのレプリケーションを成功させるには、本稼働環境での徹底的なテストおよび分析が必要です。ただし、次の基本的な計算を使用して、レプリケートされるトポロジの設計を開始することができます。以降の節では、レプリケートされるトポロジ設計の基礎として、この計算の結果を使用します。
使用状況がピークに達する時間帯で、1 秒あたり最大何件の検索を処理できる必要があるかを見積もります。
この見積もり値を「総検索数」とします。
単一のホストで処理できる 1 秒あたりの検索数をテストします。
この見積もり値を「ホストあたりの検索数」とします。このテストは「レプリケーションを有効にした」状態で行う必要があります。
ホストが処理できる検索数は、さまざまな変動要因の影響を受けます。特に影響が大きいのは、エントリのサイズ、ホストの容量、およびネットワークの速度です。これらのテスト作業に役立つパフォーマンステストツールが、サードパーティーから多数提供されています。SLAMD 分散負荷生成エンジン (SLAMD) は、ネットワークベースアプリケーションの負荷テストおよびパフォーマンス分析の用途向けに設計された、オープンソースの Java アプリケーションです。SLAMD を利用することで、レプリケーション評価のこの段階の作業を効率的に実行できます。SLAMD の詳細および SLAMD ソフトウェアのダウンロードについては、http://www.slamd.com を参照してください。
必要なホスト数を計算します。
ホスト数 = 総検索数/ホストあたりの検索数
レプリケーションにより、Directory Server への負荷を次のように分散させることができます。
検索アクティビティーを複数のサーバーに分散する
特定のサーバーを特定のタスクまたはアプリケーションの処理に専念させる
一般に、完全接続型トポロジにおいて、「初期レプリケーション要件の評価」で計算した「ホスト数」が 16 前後であるか、それよりも極端に大きくなければ、トポロジにはマスターサーバーのみを含めることをお勧めします。完全接続型とは、すべてのマスターが、トポロジ内のほかのマスターすべてにレプリケートするという意味です。
計算で得られた「ホスト数」は概算値であり、ハードウェア構成や、配備のその他の詳細条件によって変動します。
次の図では、「ホスト数」が 2 であると仮定しています。クライアントアプリケーションのタイプに基づいて、LDAP 操作が 2 つのマスターサーバーに分割されます。この方針により、各サーバーにかかる負荷が減少し、配備全体で処理できる合計の操作数は増加します。
グローバル配備における類似のシナリオについては、「WAN を介したマルチマスターレプリケーションの使用」を参照してください。
対象の配備で必要な「ホスト数」が 16 を大きく超える場合、専用コンシューマをトポロジに追加しなければならない場合があります。
次の図では「ホスト数」が 24 であると仮定し、簡略化のためにトポロジの一部のみを示しています。残り 10 台のサーバーも同一の構成であり、合計で 8 個のマスターと 16 個のコンシューマが存在します。
次のことを行う必要がある場合、該当する任意のコンシューマに対して更新履歴ログを有効にできます。
機能停止の発生時にコンシューマをマスターにプロモートする
マスターからどれか 1 つのコンシューマへのバイナリ初期化を実行する
「ホスト数」が数百に達する場合は、トポロジにハブを追加することを検討してください。そのような場合、ハブの数はマスターの数よりも多くしてください。具体的には、マスター 1 個あたり最大で 10 個のハブを使用し、各ハブでは 20 個程度までのコンシューマへのレプリケーションを処理するようにします。
どのようなトポロジでも、ハブ数とマスター数、またはハブ数とコンシューマ数が同じになるような構成は避けてください。
「ホスト数」が大きい場合、「サーバーグループ」を使用してトポロジを簡素化し、リソースの使用効率を改善することができます。16 個のマスターが存在するトポロジで、4 つのサーバーグループを使用してそれぞれに 4 つのマスターを配置すると、16 個のマスターを完全メッシュ構成にする場合よりも管理が容易になります。
そのようなトポロジを設定するために必要な手順は、次のとおりです。
16 個のマスターを設定します。この時点ではレプリケーションアグリーメントは設定しません。
4 つのサーバーグループを作成し、各グループに 4 つのマスターを含めます。
単一グループ内のすべてのマスター間でレプリケーションアグリーメントを設定します。
各グループの最初のマスター間、各グループの 2 番目のマスター間、というように順次レプリケーションアグリーメントを設定します。
次の図に最終的なトポロジを示します。
Directory Proxy Server では、複数のサーバーを使用することにより、単一データソースの負荷を分散させることができます。また Directory Proxy Server は、サーバーのうち 1 台が停止した場合でもデータの継続的な可用性を保証できます。Directory Proxy Server はデータの分散だけでなく、操作のタイプに基づいた負荷分散機能も提供します。この機能では、サーバーは操作の「タイプ」に基づいて、クライアント操作を特定の Directory Server に経路指定できます。
Directory Proxy Server は操作のタイプに基づいた負荷分散に加えて、作業負荷が Directory Server 間でどのように共有されるかを決定する各種の負荷分散アルゴリズムをサポートします。これらの各アルゴリズムの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 16 章「Directory Proxy Server Load Balancing and Client Affinity」を参照してください。
次の図は、比例アルゴリズムを使用して 2 つのサーバー間で読み取り負荷を分散させる方法を例示しています。操作のタイプに基づいた負荷分散では、マスター 1 のサーバーで障害が発生しないかぎり、すべての書き込みがマスター 1 に経路指定されます。マスター 1 のサーバーで障害が発生すると、すべての読み取りと書き込みはマスター 2 に経路指定されます。
1 つのサーバーインスタンスで障害が発生しても、負荷分散の設定は再計算されません。比例型の負荷分散を使用し、サーバーの負荷分散ウェイトを 0 に設定しても、「ホットスタンバイ」サーバーを作成することはできません。
たとえば、3 つのサーバー A、B、および C が存在するとします。また、サーバー A と B がそれぞれ 50% の負荷を受け持つように比例型負荷分散が設定されています。サーバー C は、スタンバイ専用のサーバーとして、0% の負荷を受け持つように設定されています。サーバー A で障害が発生すると、負荷の 100% が自動的にサーバー B に振り分けられます。サーバー B でも障害が発生した場合にはじめて、サーバー C に負荷が分散されます。そのため、負荷分散に常時参加しているインスタンスが、常に負荷を受け持ち、それらのインスタンスすべてで障害が発生した場合にかぎり、スタンバイ状態のサーバーに負荷が振り分けられることになります。
飽和負荷分散アルゴリズムを使用し、スタンバイサーバーに低いウェイトを適用することにより、ホットスタンバイと同様の効果を達成できます。そのようなサーバーは本来の意味のスタンバイサーバーではありませんが、メインのサーバーの負荷が極端に高まった場合にのみこのサーバーに要求が分散されるように、アルゴリズムを設定することができます。メインサーバーの 1 つが無効になり、それに伴ってほかのメインサーバーの受け持つ負荷がかなり上昇すると、スタンバイサーバーに対して負荷の分散が行われます。
書き込み操作はリソースの消費が大きい操作です。クライアントが書き込み操作を要求すると、データベース上で次の一連のイベントが発生します。
バックエンドデータベースがロックされる
データベースキャッシュ内でエントリがロックされる
アクセス制御チェックプラグインが呼び出される
バックエンド操作前プラグインが呼び出される
データベーストランザクションが開始される
データベースファイルが更新される
古いエントリキャッシュが新しいデータに置き換えられる
データベーストランザクションがコミットされる
バックエンド操作後プラグインが呼び出される
バックエンドデータベースがロック解除される
このような複雑な手順により書き込み操作が行われるため、書き込み数が増加するとパフォーマンスも著しく影響を受けます。
企業の規模が拡大すると、より多くのクライアントアプリケーションがディレクトリへの高速な書き込みアクセスを要求するようになります。また、単一の Directory Server に格納される情報が増加すればするほど、ディレクトリデータベースのエントリを追加または変更するためのコストも上昇します。これは、インデックスが肥大化して、インデックスに含まれる情報の操作にかかる時間が長くなることが原因です。
サービスレベル契約を達成するために、すべてのデータをメモリー上にキャッシュとして保持しなければならない場合もあります。ただしその場合、データが大きすぎて 1 台のマシンのメモリーに収まりきれないことも考えられます。
ディレクトリデータの分量がこのレベルにまで増加した時点で、複数のサーバーに格納できるようにデータを分割する必要が生じます。1 つのアプローチは、階層を使用して情報を分割するというものです。何らかの基準に従って情報を複数の分岐に分離することにより、各分岐を別個のサーバーに格納できます。その後、連鎖またはリフェラルを使用して各サーバーを設定し、クライアントが単一点からすべての情報にアクセスできるようにします。
この種の分割では、各サーバーはディレクトリツリーの一部分にのみ責任を持ちます。分散ディレクトリサービスは、ドメインネームサービス (DNS) に似た方法で機能します。DNS では、DNS ネームスペースの個々の部分を特定の DNS サーバーに割り当てます。同様に、ディレクトリのネームスペースを複数のサーバーに分散し、クライアント側からは単一のディレクトリツリーとして見えるように管理することができます。
階層ベースの分散機構には、いくつかの短所があります。主な問題は、この機構では、情報が存在する場所をクライアントの側で正確に把握している必要があるということです。そうでない場合、クライアントは広範な検索を実行してデータを見つけ出す必要があります。もう 1 つの問題は、一部のディレクトリ対応アプリケーションで、複数の分岐に分割された情報を適切に処理できないというものです。
Directory Server では、連鎖機構およびリフェラル機構との組み合わせで階層ベースの分散をサポートします。ただし、分散機能はスマートルーティングをサポートする Directory Proxy Server でも提供されます。この機能により、企業ごとに最適な分散機構を決定することができます。
Directory Server では、パフォーマンスの高いディスクベースの LDBM データベースにデータを格納します。各データベースは 1 つのファイルセットで構成され、ファイルセットには、このセットに割り当てられたすべてのデータが含まれます。ディレクトリツリーの異なる部分を別々のデータベースに格納できます。たとえば、次の図に示すように、ディレクトリツリーに 3 つのサブサフィックスが含まれていると仮定します。
次の図に示すように、3 つのサブサフィックスのデータを 3 つの独立したデータベースに格納できます。
複数のデータベースにディレクトリツリーを分割するとき、複数のサーバー間にデータベースを分散させることができます。またパフォーマンス改善のために、複数の物理マシンに分散することができます。前の例で示した 3 つのデータベースを、次の図に示すように 2 つのサーバーに格納することができます。
データベースを複数のサーバーに分散させると、各サーバーで処理しなければならない作業量は減ります。そのため、ディレクトリを拡張して、1 つのサーバーで保持できる数よりはるかに多くのエントリを保持できるようにすることができます。Directory Server はデータベースの動的追加をサポートするため、ディレクトリ全体を停止させることなく、必要に応じて新しいデータベースを追加できます。
Directory Proxy Server はディレクトリ情報を複数のサーバーに分割しますが、その際にデータの階層を変更する必要はありません。データ分散にとって重要なことは、データセットを論理的な方法で分割することです。ただし、あるクライアントアプリケーションに対して適切に機能する分散ロジックが、別のクライアントアプリケーションに対しても同じように機能するとはかぎりません。
この理由から、Directory Proxy Server では、データがどのように分散されるか、またディレクトリ要求がどのように経路指定されるべきかをユーザーが指定できます。たとえば、ディレクトリ情報ツリー (DIT) の階層に基づいて、LDAP 操作を複数の異なるディレクトリサーバーに経路指定することができます。操作タイプやカスタムの分散アルゴリズムに基づいて操作を経路指定することもできます。
Directory Proxy Server は、分散の詳細をクライアントアプリケーションから実質的に隠蔽します。クライアントの側からは、発行したディレクトリクエリーは 1 つのディレクトリによって処理されるように見えます。クライアント要求は、特定の分散方法に従って分散されます。以降の節で説明するように、DIT の部分ごとに異なるルーティング方針を各部分に関連付けることができます。
この方針は、DIT の構造に基づいてディレクトリエントリを分散させるために使用できます。たとえば、サブツリー「o=sales,dc=example,dc=com」内のエントリを、Directory Server A に、サブツリー「o=hr,dc=example,dc=com」内のエントリを Directory Server B にそれぞれ経路指定できます。
DIT に基づくルーティング以外の方法でエントリを複数のディレクトリサーバーに分散させたい場合もあるでしょう。たとえば、あるサービスプロバイダで、登録者を表すエントリを「ou=subscribers,dc=example,dc=com」内に格納するとします。登録者の数が増えるにつれ、登録者 ID の範囲に基づいて登録者を複数のサーバーに分散させることが必要になる場合があります。カスタムのルーティングアルゴリズムを使用して、ID が 1〜10000 の範囲の登録者エントリを Directory Server A に、ID が 10001 以降の範囲の登録者エントリを Directory Server B に配置できます。サーバー B 上のデータが増えすぎた場合、分散アルゴリズムを変更して、ID が 20001 以降のエントリを新しいサーバー C に配置することができます。
Directory Proxy Server の DistributionAlgorithm インタフェースを使用し、独自のルーティングアルゴリズムを実装することができます。
このシナリオでは、企業は地理的な位置を基準にして、3 つのマスターサーバーに顧客データを分散させます。イギリスに在住する顧客のデータを、ロンドンにあるマスターサーバーに格納します。フランスの顧客のデータはパリにあるマスターサーバーに格納します。日本の顧客のデータは東京にあるマスターサーバーに格納します。顧客は自分自身のデータを、Web ベースの統一されたインタフェースを通して更新できます。
ユーザーはディレクトリ内の自分自身の情報を、Web ベースのアプリケーションを使用して更新できます。認証フェーズの間、ユーザーは電子メールアドレスを入力します。イギリスの顧客の電子メールアドレスは *@uk.example.com という形式です。フランスの顧客の形式は *@fr.example.com であり、日本の顧客は *@ja.example.com です。Directory Proxy Server は、LDAP 対応のクライアントアプリケーション経由でこれらの要求を受信します。Directory Proxy Server はその後、認証時に入力された電子メールアドレスに基づいて、適切なマスターサーバーに要求を経路指定します。
次の図はこのシナリオを例示したものです。
多くの場合、DIT の頂点でのデータ分散は必要ありません。ただし、ツリーの上位にあるエントリが、ツリーの分散済み部分にあるエントリによって必要とされる場合があります。この節では、サンプルのシナリオを通して、このようなケースでの分散方針を設計する方法を示します。
Example.com には、グループに対応する 1 つのサブツリーと、人に対応する 1 つの独立したサブツリーがあります。グループ定義の数は少なくあまり変化しませんが、人を表すエントリの数は多く、増加し続けます。そのため Example.com では、人のエントリだけを 3 つのサーバーに分散させる必要があります。ただし、people サブツリー下のすべてのエントリにアクセスするには、グループ定義、グループ定義の ACI、およびネーミングコンテキストの最上位に位置する ACI が必要です。
次の図は、データ分散要件の論理ビューを示したものです
ou=people サブツリーは、各エントリの sn 属性の先頭文字に従って、3 つのサーバーに分散されます。ネーミングコンテキスト (dc=example,dc=com) および ou=groups コンテナは、各サーバー上の 1 つのデータベースに格納されます。ou=people 下のエントリがこのデータベースにアクセスできます。ou=people コンテナは、このコンテナ専用のデータベースに格納されます。
次の図は、個々の Directory Server 上にデータがどのように格納されるかを示したものです。
ou=people コンテナはトップコンテナのサブサフィックスではありません。
これまでに説明した各サーバーは、分散チャンク (chunk) として理解することができます。ネーミングコンテキストおよび ou=groups 下のエントリを含むサフィックスは、各チャンク上で同じです。したがって、3 つのチャンクのそれぞれにまたがって、このサフィックスに対してマルチマスターレプリケーションアグリーメントを設定します。
また、可用性のために各チャンクはレプリケートされています。したがって、各チャンクに対して少なくとも 2 つのマスターレプリカが定義されています。
次の図は、各チャンクに対して 3 つのレプリカが定義された Directory Server 設定を示しています。簡略化のため、1 つのチャンクに対するレプリケーションアグリーメントのみを示していますが、ほかの 2 つのチャンクに対しても同じアグリーメントが定義されています。
クライアントによる Directory Proxy Server 経由でのディレクトリデータへのアクセスは「データビュー」を通して提供されます。データビューの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 17 章「Directory Proxy Server Distribution」を参照してください。
このシナリオでは、分散される各サフィックスに対して 1 つのデータビューが必要であり、ネーミングコンテキスト (dc=example,dc=com) および ou=groups サブツリーに対して 1 つのデータビューが必要です。
次の図では、分散データへのアクセスを提供するための Directory Proxy Server データビューの設定を示しています。
分散されるデータは、分散アルゴリズムに従って分割されます。使用する分散アルゴリズムを決定するときは、データの分量が変化する可能性があることと、分散方針は拡張性のあるものでなければならないことに留意してください。データの完全な再分散を必要とするようなアルゴリズムを使用しないでください。
たとえば、uid などの数値に基づく分散アルゴリズムは、比較的簡単に拡張できます。uid=0-999 および uid=1000–1999 の 2 つのデータセグメントから開始する場合、uid=2000–2999 という 3 番目のセグメントをあとから追加することは容易です。
リフェラルはサーバーによって返される情報であり、操作要求を進めるためにどのサーバーと通信すればよいかをクライアントアプリケーションに通知します。分散ロジックの管理に Directory Proxy Server を使用しない場合、分散されるデータ間の関係を別の方法で定義する必要があります。関係を定義する 1 つの方法は「リフェラル」の使用です。
Directory Server では、リフェラル返送の形式とタイミングを 3 つの方法で設定できます。
デフォルトリフェラル: クライアントアプリケーションが提示した DN に対応するサフィックスがサーバーにない場合、ディレクトリはデフォルトリフェラルを返します。
サフィックスリフェラル: サフィックス全体がメンテナンスまたはセキュリティー上の理由でオフラインになった場合、サーバーはサフィックスに定義されているリフェラルを返します。クライアントが書き込み処理を要求する場合、サフィックスの読み取り専用レプリカも、マスターサーバーにリフェラルを返します。
スマートリフェラル: スマートリフェラルは、ディレクトリ自体のエントリに格納されています。このリフェラルは、そのスマートリフェラルが格納されているエントリの DN と一致する DN を持つサブツリーに関する情報を保有している Directory Server を指します。
次の図は、リフェラルを使用して、グローバルトポロジ内の適切なサーバーにイギリスの顧客を誘導する方法を例示したものです。このシナリオでは、クライアントアプリケーションがリフェラルに従うためには、クライアントアプリケーションがトポロジ内のすべてのサーバーに (TCP/IP レベルで) 接続できる必要があります。
Directory Proxy Server とリフェラル機構を組み合わせて使用することにより、同じ結果を達成することができます。この目的のために Directory Proxy Server を使用することの利点は、クライアントアプリケーションの負荷および複雑さが軽減されることです。クライアントアプリケーションは Directory Proxy Server の URL のみを認識します。何らかの理由で分散ロジックが変更された場合でも、この変更はクライアントアプリケーションに対して透過的です。
次の図は、前に説明したシナリオを、Directory Proxy Server を使用することによって簡略化する方法を例示しています。クライアントアプリケーションは常に Proxy Server と通信し、リフェラル自体は Proxy Server によって処理されます。