Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド

書き込みの拡張容易性のための分散の使用

書き込み操作はリソースの消費が大きい操作です。クライアントが書き込み操作を要求すると、データベース上で次の一連のイベントが発生します。

このような複雑な手順により書き込み操作が行われるため、書き込み数が増加するとパフォーマンスも著しく影響を受けます。

企業の規模が拡大すると、より多くのクライアントアプリケーションがディレクトリへの高速な書き込みアクセスを要求するようになります。また、単一の Directory Server に格納される情報が増加すればするほど、ディレクトリデータベースのエントリを追加または変更するためのコストも上昇します。これは、インデックスが肥大化して、インデックスに含まれる情報の操作にかかる時間が長くなることが原因です。

サービスレベル契約を達成するために、すべてのデータをメモリー上にキャッシュとして保持しなければならない場合もあります。ただしその場合、データが大きすぎて 1 台のマシンのメモリーに収まりきれないことも考えられます。

ディレクトリデータの分量がこのレベルにまで増加した時点で、複数のサーバーに格納できるようにデータを分割する必要が生じます。1 つのアプローチは、階層を使用して情報を分割するというものです。何らかの基準に従って情報を複数の分岐に分離することにより、各分岐を別個のサーバーに格納できます。その後、連鎖またはリフェラルを使用して各サーバーを設定し、クライアントが単一点からすべての情報にアクセスできるようにします。

この種の分割では、各サーバーはディレクトリツリーの一部分にのみ責任を持ちます。分散ディレクトリサービスは、ドメインネームサービス (DNS) に似た方法で機能します。DNS では、DNS ネームスペースの個々の部分を特定の DNS サーバーに割り当てます。同様に、ディレクトリのネームスペースを複数のサーバーに分散し、クライアント側からは単一のディレクトリツリーとして見えるように管理することができます。

階層ベースの分散機構には、いくつかの短所があります。主な問題は、この機構では、情報が存在する場所をクライアントの側で正確に把握している必要があるということです。そうでない場合、クライアントは広範な検索を実行してデータを見つけ出す必要があります。もう 1 つの問題は、一部のディレクトリ対応アプリケーションで、複数の分岐に分割された情報を適切に処理できないというものです。

Directory Server では、連鎖機構およびリフェラル機構との組み合わせで階層ベースの分散をサポートします。ただし、分散機能はスマートルーティングをサポートする Directory Proxy Server でも提供されます。この機能により、企業ごとに最適な分散機構を決定することができます。

複数のデータベースの使用

Directory Server では、パフォーマンスの高いディスクベースの LDBM データベースにデータを格納します。各データベースは 1 つのファイルセットで構成され、ファイルセットには、このセットに割り当てられたすべてのデータが含まれます。ディレクトリツリーの異なる部分を別々のデータベースに格納できます。たとえば、次の図に示すように、ディレクトリツリーに 3 つのサブサフィックスが含まれていると仮定します。

図 10–6 3 つのサブサフィックスを持つディレクトリツリー

図では、1 つのサフィックスと 3 つのサブサフィックスを含むディレクトリツリーを示します。

次の図に示すように、3 つのサブサフィックスのデータを 3 つの独立したデータベースに格納できます。

図 10–7 3 つの異なるデータベースに格納された 3 つのサブサフィックス

図では、3 つの独立したデータベースに格納される 3 つのサブサフィックスを示しています。

複数のデータベースにディレクトリツリーを分割するとき、複数のサーバー間にデータベースを分散させることができます。またパフォーマンス改善のために、複数の物理マシンに分散することができます。前の例で示した 3 つのデータベースを、次の図に示すように 2 つのサーバーに格納することができます。

図 10–8 2 つの独立したサーバーに格納される 3 つのデータベース

図では、あるサーバー (A) に格納される 2 つのデータベースと、別のサーバー (B) に格納される 1 つのデータベースを示しています。

データベースを複数のサーバーに分散させると、各サーバーで処理しなければならない作業量は減ります。そのため、ディレクトリを拡張して、1 つのサーバーで保持できる数よりはるかに多くのエントリを保持できるようにすることができます。Directory Server はデータベースの動的追加をサポートするため、ディレクトリ全体を停止させることなく、必要に応じて新しいデータベースを追加できます。

Directory Proxy Server を使用した分散

Directory Proxy Server はディレクトリ情報を複数のサーバーに分割しますが、その際にデータの階層を変更する必要はありません。データ分散にとって重要なことは、データセットを論理的な方法で分割することです。ただし、あるクライアントアプリケーションに対して適切に機能する分散ロジックが、別のクライアントアプリケーションに対しても同じように機能するとはかぎりません。

この理由から、Directory Proxy Server では、データがどのように分散されるか、またディレクトリ要求がどのように経路指定されるべきかをユーザーが指定できます。たとえば、ディレクトリ情報ツリー (DIT) の階層に基づいて、LDAP 操作を複数の異なるディレクトリサーバーに経路指定することができます。操作タイプやカスタムの分散アルゴリズムに基づいて操作を経路指定することもできます。

Directory Proxy Server は、分散の詳細をクライアントアプリケーションから実質的に隠蔽します。クライアントの側からは、発行したディレクトリクエリーは 1 つのディレクトリによって処理されるように見えます。クライアント要求は、特定の分散方法に従って分散されます。以降の節で説明するように、DIT の部分ごとに異なるルーティング方針を各部分に関連付けることができます。

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 インタフェースを使用し、独自のルーティングアルゴリズムを実装することができます。

Directory Proxy Server を使用したバインド DN ベースの要求分散

このシナリオでは、企業は地理的な位置を基準にして、3 つのマスターサーバーに顧客データを分散させます。イギリスに在住する顧客のデータを、ロンドンにあるマスターサーバーに格納します。フランスの顧客のデータはパリにあるマスターサーバーに格納します。日本の顧客のデータは東京にあるマスターサーバーに格納します。顧客は自分自身のデータを、Web ベースの統一されたインタフェースを通して更新できます。

ユーザーはディレクトリ内の自分自身の情報を、Web ベースのアプリケーションを使用して更新できます。認証フェーズの間、ユーザーは電子メールアドレスを入力します。イギリスの顧客の電子メールアドレスは *@uk.example.com という形式です。フランスの顧客の形式は *@fr.example.com であり、日本の顧客は *@ja.example.com です。Directory Proxy Server は、LDAP 対応のクライアントアプリケーション経由でこれらの要求を受信します。Directory Proxy Server はその後、認証時に入力された電子メールアドレスに基づいて、適切なマスターサーバーに要求を経路指定します。

次の図はこのシナリオを例示したものです。

図 10–9 Directory Proxy Server を使用したバインド DN ベースの要求ルーティング

図では、電子メールアドレスに基づいて Directory Proxy Server が要求を分散するしくみを示しています。