3 プロキシ・サーバーを使用するデプロイメントの理解

プロキシ・サーバーの主な役割は、ディレクトリ・サービス・トポロジにデプロイされているディレクトリ・サーバーに、クライアントからのLDAPリクエストをルーティングすることです。

次の各トピックでは、プロキシ・サーバーの動作の理解に役立つデプロイメントの例をいくつか示します。

• プロキシ・デプロイメント・タイプの理解

• サポートされているプロキシ・デプロイメント

3.1 プロキシ・デプロイメント・タイプの理解

プロキシ・サーバーを正常にデプロイできる、数種類のシナリオがあります。要件に応じてネットワークを構築するには、様々なデプロイメント・タイプを理解することが不可欠です。

プロキシを使用するデプロイメントの最も一般的な2つのタイプは次のとおりです。:

• ロード・バランシング

• 分散

使用するデプロイメント・タイプを決定するには、データを格納する場所と方法および処理するデータ量について検討します。

• レプリケートされるデータ・ストアにすべてのデータが格納される場合、ロード・バランシングを使用するデプロイメントを使用します。「構成1: 単純なロード・バランシング」を参照してください。

• データがパーティション化されている場合、またはデータベースのサイズが大きいので複数のデータ・ソースにパーティション化されるようにデータを分割する必要がある場合、分散を使用するデプロイメントを使用します。「構成2: 単純な分散」を参照してください。

ロード・バランシングと分散を組み合せる、さらに複雑なデプロイメント・シナリオも定義できます。ロード・バランシングまたは分散のどちらが必要なのか、あるいは両方が必要なのかを検討する必要があります。

• 地理的に異なる場所にデータ・センターを配置する必要がある場合、ロード・バランシングされた2つのデータ・センターの間にフェイルオーバーをデプロイできます。「構成3: データ・センター間のフェイルオーバー」を参照してください。

• 分散を使用し、さらにデータ・パーティションをレプリケートする場合、ロード・バランサにルーティングされる分散を使用するプロキシ・サーバーをデプロイできます。「構成4: 分散とロード・バランシングの併用」を参照してください。

• 分散を使用し、データ・パーティションをレプリケートすると同時に、可用性と障害時リカバリのためにパーティションを1つのデータ・センター内でレプリケートするだけでなく、地理的に異なる2つの場所にあるデータ・センター間でレプリケートする場合、「構成5: 分散とデータ・センター間のフェイルオーバーの併用」と同様のアーキテクチャをデプロイできます。

ノート:

特定のパーティションにエントリをマップするには、分散を使用してグローバル索引カタログをデプロイメントに追加します。グローバル索引カタログを追加することで、ブロードキャストの使用を最小限に抑えられます。「コマンド行を使用したグローバル索引の構成」を参照してください。

3.2 サポートされているプロキシ・デプロイメント

後続の項の例を使用すると、プロキシの動作と、Oracle Unified Directoryがサポートする様々なデプロイメント構成を理解できます。

• 構成1: 単純なロード・バランシング

• 構成2: 単純な分散

• 構成3: データ・センター間のフェイルオーバー

• 構成4: 分散とロード・バランシングの併用

• 構成5: 分散とデータ・センター間のフェイルオーバーの併用

• 構成6: エンタープライズ・ユーザー・セキュリティ

• 構成7: レプリケートされる複数のプロキシ

• 構成8: 仮想化

3.2.1 構成1: 単純なロード・バランシング

ロード・バランシングは、着信リクエストを複数のリソースに分散することによってパフォーマンスを最適化するための方法です。これにより、単一のリソースのオーバーロードが回避されます。この例は、単純なロード・バランシングを設定する方法を示しています。

プロキシをデプロイしてロード・バランシングを実現する場合、プロキシが受信したリクエストはすべて、いずれかのリモートLDAPサーバーにルーティングされます。図3-1に示すように、リモートLDAPサーバーはレプリケートされるので、格納されるデータは同じです。サポートするリモートLDAPサーバーの数に制限はありません。

図3-1 単純なロード・バランシング

「図3-1 単純なロード・バランシング」の説明

デプロイメントの際に設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。

ロード・バランシング・アルゴリズムには、次の種類があります:

• failover

• generic

• optimal

• proportional

• saturation

• searchfilter

各種ロード・バランシング・アルゴリズムの詳細は、「プロキシを使用したロード・バランシングの概要」を参照してください。

このアルゴリズムは、クライアント接続アフィニティによりバイパスできます。クライアント接続アフィニティを設定した場合、プロキシは、最初のリクエストの処理ではロード・バランシング・アルゴリズムを使用しますが、それ以降のリクエストの処理では設定されているロード・バランシング・アルゴリズムを無視し、たとえば設定されているクライアント・アフィニティのタイプに応じて、同じクライアント接続上の新しい操作に同じルートを再利用しようとします。「クライアント接続アフィニティの設定」を参照してください。

ロード・バランシング・デプロイメントを使用する場合、データの高可用性およびリモートLDAPサーバーに適応した処理負荷が実現されるという利点があります。たとえば、構成されているリモートLDAPサーバーの1つに障害が発生した場合、ロード・バランシングによってリクエストは別のリモートLDAPサーバーにルーティングされます。この場合、障害が発生したことをクライアントが認識することはなく、サービスの中断も発生しません。

単純なロード・バランシング・デプロイメントは、プロキシをインストールする際に簡単に構成できます。

3.2.2 構成2: 単純な分散

データ分散を使用すると、複数のサーバーを横断してディレクトリをスケーリングできます。各サーバーは、データの一部のみを担当します。このため、分散トポロジでは、1つのサーバーで可能であるよりも多数のデータを保持できます。

プロキシをデプロイして単純な分散を実現する場合、データはパーティションに分割されます。図3-2に示すように、データの各パーティションは個別のリモートLDAPサーバーに保持されます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。プロキシが受信したリクエストはすべて、該当するデータが格納されるリモートLDAPサーバーにルーティングされます。

データがパーティション化されるリモートLDAPサーバーの数は、分割するデータベースのサイズによって決まります。図3-2は、2つのパーティションを使用する単純な分散アルゴリズムを示しますが、パーティションの数を増やした構成も可能です。

図3-2 単純な分散

「図3-2 単純な分散」の説明

デプロイメントの際に設定された分散アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。

分散アルゴリズムには、次の種類があります:

• capacity

• numeric

• lexico

• dnpattern

各種分散アルゴリズムの詳細は、「プロキシを使用したデータ分散の概要」を参照してください。

分散を使用するデプロイメントの場合、1秒当たりの更新数をスケーリングできるという利点があります。分散を使用する場合、グローバル索引カタログを追加してブロードキャストの数を減らすことができます。「コマンド行を使用したグローバル索引の構成」を参照してください

単純な分散デプロイメントは、プロキシをインストールする際に簡単に構成できます。

3.2.3 構成3: データ・センター間のフェイルオーバー

データ・センター間にフェイルオーバーを構成することは、実質的にはプロキシ内に2レベルのロード・バランサをデプロイすることです。これにより、高可用性を向上させることができます。

フェイルオーバーのシナリオを確認しましょう。このデプロイメント・トポロジでは、データ・センターがレプリケートされ、データ・センター内のリモートLDAPサーバーもレプリケートされます。このデプロイメントでは、フェイルオーバーまたは飽和のどちらかが、最初のロード・バランシング要素になります。次の例では、最初のロード・バランシング要素としてフェイルオーバー・アルゴリズムが選択されていることを前提としています。

図3-3に示すように、リクエストはすべて、フェイルオーバー・ロード・バランサによってメイン・ルート経由で2番目のロード・バランシング要素にルーティングされ、そこでData Center 1の内部にあるサーバーにリクエストが送信されます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。Data Center 1が停止するか、またはパフォーマンスが低下した場合、トラフィックは、フェイルオーバー・ロード・バランサによってバックアップ・ルート経由でData Center 2の内部にあるサーバーにルーティングされます。

図3-3 データ・センター間のフェイルオーバー

「図3-3 データ・センター間のフェイルオーバー」の説明

設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはデータ・センター内のリモートLDAPサーバーにルーティングされます。データ・センターごとに異なるロード・バランシング・アルゴリズムを使用できます。たとえば、ロード・バランシング・アルゴリズムとして、Data Center 1ではproportionalを設定し、Data Center 2ではsaturationを設定できます。

通常、このタイプのデプロイメントは、2つの地理的地域にデプロイする場合に使用します。このデプロイメントでは、リモートLDAPサーバーだけでなく、データ・センターもレプリケートされるので、単純なロード・バランシング・デプロイメントに高可用性が加わります。

通常、2つのデータ・センターは地理的に異なる2つの場所に配置します。この場合、一方の場所で問題が発生すると、もう一方の場所のデータ・センターがバックアップとして動作します。別の例として、最初のロード・バランサをsaturationと設定する場合を考えます。この場合、一方の地理的な場所(たとえば特定のタイムゾーン)にあるData Center 1が飽和状態になった場合、もう一方のデータ・センターが超過分のトラフィックを引き受けることができます。

関連項目:

• 各種ロード・バランシング・アルゴリズムの詳細は、「プロキシを使用したロード・バランシングの概要」を参照してください

• この構成のデプロイの詳細は、「フェイルオーバー・ロード・バランシングの理解」を参照してください

• ユースケース例については、「データ・センター間でのフェイルオーバー・デプロイメントの構成」を参照してください

3.2.4 構成4: 分散とロード・バランシングの併用

ロード・バランシングとともに分散を構成すると、データはパーティションに分割されます。また、データはリモートLDAPサーバーにレプリケートされます。

このような状況では、プロキシに送信されたリクエストは、まずデータが格納されているパーティションに分散され、次に設定されているロード・バランシング・アルゴリズムに応じていずれかのリモートLDAPサーバーにルーティングされます。パーティション化されたデータを保持するリモートLDAPサーバーは、レプリケートされます。

図3-4に示すように、プロキシはリクエストを受信すると、分散によって正しいパーティションに振り分けます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。たとえば、cnがたとえばGarryであるエントリに対するリクエストは、パーティション1のA..Lのデータを保持するサーバーに転送されます。さらに、ロード・バランサによって、レプリケートされているいずれかのリモートLDAPサーバーに転送されます。

図3-4 分散とロード・バランシングの併用

「図3-4 分散とロード・バランシングの併用」の説明

設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはデータ・センター内のリモートLDAPサーバーにルーティングされます。各種ロード・バランシング・アルゴリズムの詳細は、「プロキシを使用したロード・バランシングの概要」を参照してください。

このデプロイメントには、データが分散されることにより更新が速いこと、およびデータの高可用性という利点があります。

関連項目:

• 各種分散アルゴリズムの詳細は、「プロキシを使用したデータ分散の概要」を参照してください

• 各種ロード・バランシング・アルゴリズムの詳細は、「プロキシを使用したロード・バランシングの概要」を参照してください

• この構成のデプロイの詳細は、「プロキシ、分散および仮想化機能の理解」を参照してください

3.2.5 構成5: 分散とデータ・センター間のフェイルオーバーの併用

フェイルオーバー・ロード・バランシングを使用する分散を含むトポロジを構成できます。このようなシナリオでは、データが2つのデータ・センターの間のパーティションに分割され、各パーティションはフェイルオーバー・ロード・バランシング・ルートによって管理されます。

次のシナリオについて考えます。図3-5に示すように、パーティション化されたデータを保持するリモートLDAPサーバーが1つのデータ・センター内でレプリケートされるだけでなく、さらにデータ・センターがレプリケートされ、一方のデータ・センターがバックアップとして動作します。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。

図3-5 分散とデータ・センター間のフェイルオーバーの併用

「図3-5 分散とデータ・センター間のフェイルオーバーの併用」の説明

言い換えると、プロキシに送信されたリクエストは、まずデータが格納されているパーティションに分散されます。たとえば、cnがたとえばGarryであるエントリに対するリクエストは、パーティション1に転送されます。さらに、設定されているロード・バランシング・アルゴリズムに基づいて、フェイルオーバー・ロード・バランサによってメイン・ルート経由でA..Lのデータが格納されているいずれかのリモートLDAPサーバーに転送されます。

図3-5に示すデプロイメントでは、Data Center 2はバックアップとして動作し、Data Center 1で障害が発生した場合にのみ使用されます。ただし、これと同じデプロイメントを、フェイルオーバー・ロード・バランサではなく、saturationを使用するように構成できます。この場合、一方の地理的な場所(たとえば特定のタイムゾーン)にあるData Center 1が飽和状態になった場合、もう一方のデータ・センターが超過分のトラフィックを引き受けることができます。

このデプロイメントには、分散アルゴリズムを使用することにより読取りが速いことに加えて、リモートLDAPサーバーがレプリケートされ、1つのデータ・センターがバックアップとして動作するために高可用性が実現するという利点があります。

関連項目:

• 各種ロード・バランシング・アルゴリズムの詳細は、「プロキシを使用したロード・バランシングの概要」を参照してください

• 各種分散アルゴリズムの詳細は、「プロキシを使用したデータ分散の概要」を参照してください

• ユースケース例については、「分散とデータ・センター間のフェイルオーバー・デプロイメントの併用の構成」を参照してください

3.2.6 構成6: エンタープライズ・ユーザー・セキュリティ

エンタープライズ・ユーザー・セキュリティ(EUS)のためにプロキシを構成する場合、構成の詳細はローカルのOracle Unified Directoryディレクトリ・サーバーに格納され、リモートの外部LDAPディレクトリにはエンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが格納されます。

図3-6に示すように、リモートの外部LDAPディレクトリには、エンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが格納されます。

図3-6 プロキシ・エンタープライズ・ユーザー・セキュリティ

「図3-6 プロキシ・エンタープライズ・ユーザー・セキュリティ」の説明

デプロイメントの際に設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。

ロード・バランシング・アルゴリズムには、次の種類があります:

• failover

• optimal

• proportional

• saturation

各種ロード・バランシング・アルゴリズムの詳細は、「プロキシを使用したロード・バランシングの概要」を参照してください。

エンタープライズ・ユーザー・セキュリティのためにプロキシをデプロイするには、「Oracle Enterprise User SecurityへのOracle Unified Directoryの統合」を参照してください。

3.2.7 構成7: レプリケートされる複数のプロキシ

ハードウェア・ロード・バランサを使用して、物理的に異なるマシンまたは地理的に異なる場所にある複数のプロキシ・インスタンスを管理します。

シングル・ポイント障害を回避するには、デプロイメントに冗長性を持たせることを保証する必要があります。通常は、図3-7に示すように、サード・パーティ・ハードウェア・ロード・バランサをインストールすることによってそれを実現できます。

この例では、ハードウェア・ロード・バランサを使用して、複数のプロキシ・インスタンスを管理する方法を示しています。

図3-7 複数のプロキシ・インスタンス

「図3-7 複数のプロキシ・インスタンス」の説明

グローバル索引カタログを使用する分散デプロイメントで複数のプロキシ・インスタンスを実行する場合、グローバル索引カタログをレプリケートする必要があります。グローバル索引カタログのレプリケートの詳細は、「グローバル索引カタログのレプリケーション」を参照してください。

このプロキシ・デプロイメントを構成するには、『Oracle Unified Directoryのインストール』のOracle Unified Directoryのプロキシ・サーバーとしての設定に関する項を参照してください。

3.2.8 構成8: 仮想化

Oracle Unified Directoryの仮想化機能を使用して、バックエンド・データの各種ビューを作成し、仮想ディレクトリおよびデータ・ソースからデータを取得できます。

ノート:

ここで説明されている仮想ディレクトリ機能を使用するには、有効なOracle Directory Service Plusライセンスが必要です。

たとえば:

• サーバー側のDNおよび属性と対応していないクライアント側のDNおよび属性がある場合は、「DNリネーム」を使用して、サーバーの値と一致するようにクライアント側のDNおよび属性の名前を変更できます。

  たとえば、クライアントではou=org, dc=server, dc=comエントリを予期しているが、LDAPサーバーにはou=people, dc=server, dc=comエントリが含まれているとします。

  クライアントがリクエストを実行すると、DNリネーム・ワークフロー要素によって、エントリDNおよびDNまたは名前とオプションUID構文のいずれかを含む属性にDNリネーム変換が適用されます。結果がクライアントに返されると、DNと属性はクライアントのリクエストと一致するよう元に戻されます。

• 相対識別名(RDN)の値をソース・ディレクトリからOracle Unified Directoryに名前変更または置換する必要がある場合は、RDN変更を使用できます。

• LDAPクライアント・アプリケーションのデータ構造がLDAPリポジトリのデータ構造と異なる場合は、変換を使用してその物理データを別の方法で表示できます。変換では、特定のアクションが特定の方向で実行されます(リクエスト中または応答中(あるいはその両方))。

  たとえば、クライアント・アプリケーションに値がactivatedおよびdeactivatedのmyuseraccountcontrol属性があり、これをDSEE (SunONE)バックエンドで値がfalseおよびtrueのnsAccountLock属性に変換する必要があるとします。この場合、読取りおよび書込み操作をマップする必要があります。

  (ソースまたはクライアント) Oracle Unified Directoryがデータと相互作用する場所および変換が適用される方向を定義する変換ワークフロー要素を作成できます。

関連項目:

• プロキシ・デプロイメントの仮想化機能の詳細は、「プロキシ、分散および仮想化機能の理解」を参照してください

• これらの機能の構成の詳細は、「仮想化の構成」を参照してください