| Oracle® Fusion Middleware Oracle Unified Directoryの管理 11g リリース2 (11.1.2.3) E61945-07 |
|
 前 |
 次 |
この章では、プロキシ・サーバーの動作を理解するのに役立つデプロイメントの例を示します。
この章には次のセクションが含まれます:
様々なタイプのデプロイメントでプロキシを正常に使用できます。プロキシを使用するデプロイメントの最も一般的な2つのタイプは次のとおりです。
ロード・バランシング
分散
使用するデプロイメント・タイプを決定するには、データを格納する場所と方法および処理するデータ量について検討します。
レプリケートされるデータ・ストアにすべてのデータが格納される場合、ロード・バランシングを使用するデプロイメントを使用します。第3.2.1項「構成1: 単純なロード・バランシング」を参照してください。
データがパーティション化されている場合、またはデータベースのサイズが大きいので複数のデータ・ソースにパーティション化されるようにデータを分割する必要がある場合、分散を使用するデプロイメントを使用します。第3.2.2項「構成2: 単純な分散」を参照してください。
ロード・バランシングと分散を組み合せる、さらに複雑なデプロイメント・シナリオも定義できます。ロード・バランシングまたは分散のどちらが必要なのか、あるいは両方が必要なのかを検討する必要があります。
地理的に異なる場所にデータ・センターを配置する必要がある場合、ロード・バランシングされた2つのデータ・センターの間にフェイルオーバーをデプロイできます。第3.2.3項「構成3: データ・センター間のフェイルオーバー」を参照してください。
分散を使用し、さらにデータ・パーティションをレプリケートする場合、ロード・バランサにルーティングされる分散を使用するプロキシ・サーバーをデプロイできます。第3.2.4項「構成4: 分散とロード・バランシングの併用」を参照してください。
分散を使用し、データ・パーティションをレプリケートすると同時に、可用性とディザスタ・リカバリのためにパーティションを1つのデータ・センター内でレプリケートするだけでなく、地理的に異なる2つの場所にあるデータ・センター間でレプリケートする場合、第3.2.5項「構成5: 分散とデータ・センター間のフェイルオーバーの併用」と同様のアーキテクチャをデプロイできます。
|
注意: 特定のパーティションにエントリをマップするには、分散を使用してグローバル索引カタログをデプロイメントに追加します。グローバル索引カタログを追加することで、ブロードキャストの使用を最小限に抑えられます。グローバル索引カタログの構成の詳細は、第23.7項「コマンド行を使用したグローバル索引の構成」を参照してください。 |
この項では、Oracle Unified Directoryによってサポートされる様々なデプロイメント構成について説明します。これらの例を使用して、プロキシの動作を理解してください。
この項には、次の構成例が含まれます。
プロキシをデプロイしてロード・バランシングを実現する場合、プロキシが受信したリクエストはすべて、いずれかのリモートLDAPサーバーにルーティングされます。図3-1に示すように、リモートLDAPサーバーはレプリケートされるので、格納されるデータは同じです。サポートするリモートLDAPサーバーの数に制限はありません。
デプロイメントの際に設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。
ロード・バランシング・アルゴリズムには、次の種類があります:
failover
generic
optimal
proportional
saturation
searchfilter
各種ロード・バランシング・アルゴリズムの詳細は、第12.2項「プロキシを使用したロード・バランシングの理解」を参照してください。
このアルゴリズムは、クライアント接続アフィニティによりバイパスできます。クライアント接続アフィニティを設定した場合、プロキシは、最初のリクエストの処理ではロード・バランシング・アルゴリズムを使用しますが、それ以降のリクエストの処理では設定されているロード・バランシング・アルゴリズムを無視し、たとえば設定されているクライアント・アフィニティのタイプに応じて、同じクライアント接続上の新しい操作に同じルートを再利用しようとします。詳細は、第21.1.4.7項「クライアント接続アフィニティの設定」を参照してください。
ロード・バランシング・デプロイメントを使用する場合、データの高可用性およびリモートLDAPサーバーに適応した処理負荷が実現されるという利点があります。たとえば、構成されているリモートLDAPサーバーの1つに障害が発生した場合、ロード・バランシングによってリクエストは別のリモートLDAPサーバーにルーティングされます。この場合、障害が発生したことをクライアントが認識することはなく、サービスの中断も発生しません。
単純なロード・バランシング・デプロイメントは、プロキシをインストールする際に簡単に構成できます。
プロキシをデプロイして単純な分散を実現する場合、データはパーティションに分割されます。図3-2に示すように、データの各パーティションは個別のリモートLDAPサーバーに保持されます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。プロキシが受信したリクエストはすべて、該当するデータが格納されるリモートLDAPサーバーにルーティングされます。
データがパーティション化されるリモートLDAPサーバーの数は、分割するデータベースのサイズによって決まります。図3-2は、2つのパーティションを使用する単純な分散アルゴリズムを示しますが、パーティションの数を増やした構成も可能です。
デプロイメントの際に設定された分散アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。
分散アルゴリズムには、次の種類があります:
capacity
numeric
lexico
dnpattern
各種分散アルゴリズムの詳細は、第12.3項「プロキシを使用したデータ分散の理解」を参照してください。
分散を使用するデプロイメントの場合、1秒当たりの更新数をスケーリングできるという利点があります。分散を使用する場合、グローバル索引カタログを追加してブロードキャストの数を減らすことができます。グローバル索引カタログの詳細は、第23.7項「コマンド行を使用したグローバル索引の構成」を参照してください。
単純な分散デプロイメントは、プロキシをインストールする際に簡単に構成できます。
データ・センター間にフェイルオーバーを構成することは、実質的にはプロキシ内に2レベルのロード・バランサをデプロイすることです。このデプロイメントでは、データ・センターがレプリケートされ、データ・センター内のリモートLDAPサーバーもレプリケートされます。このデプロイメントでは、フェイルオーバーまたは飽和のどちらかが、最初のロード・バランシング要素になります。次の例では、最初のロード・バランシング要素としてフェイルオーバー・アルゴリズムが選択されていることを前提としています。
図3-3に示すように、リクエストはすべて、フェイルオーバー・ロード・バランサによってメイン・ルート経由で2番目のロード・バランシング要素にルーティングされ、そこでData Center 1の内部にあるサーバーにリクエストが送信されます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。Data Center 1が停止するか、またはパフォーマンスが低下した場合、トラフィックは、フェイルオーバー・ロード・バランサによってバックアップ・ルート経由でData Center 2の内部にあるサーバーにルーティングされます。
設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはデータ・センター内のリモートLDAPサーバーにルーティングされます。データ・センターごとに異なるロード・バランシング・アルゴリズムを使用できます。たとえば、ロード・バランシング・アルゴリズムとして、Data Center 1ではproportionalを設定し、Data Center 2ではsaturationを設定できます。
通常、このタイプのデプロイメントは、2つの地理的地域にデプロイする場合に使用します。このデプロイメントでは、リモートLDAPサーバーだけでなく、データ・センターもレプリケートされるので、単純なロード・バランシング・デプロイメントに高可用性が加わります。
通常、2つのデータ・センターは地理的に異なる2つの場所に配置します。この場合、一方の場所で問題が発生すると、もう一方の場所のデータ・センターがバックアップとして動作します。別の例として、最初のロード・バランサをsaturationと設定する場合を考えます。この場合、一方の地理的な場所(たとえば特定のタイムゾーン)にあるData Center 1が飽和状態になった場合、もう一方のデータ・センターが超過分のトラフィックを引き受けることができます。
各種ロード・バランシング・アルゴリズムの詳細は、第12.2項「プロキシを使用したロード・バランシングの理解」を参照してください。
この構成のデプロイの詳細は、第12.2.1項「フェイルオーバー・ロード・バランシング」を参照してください。
ユースケースの例は、第25.4項「データ・センター間のフェイルオーバーの構成例」を参照してください。
分散とロード・バランシングを併用するデプロイメントでは、データがパーティションに分割され、リモートLDAPサーバー上でデータがレプリケートされます。プロキシに送信されたリクエストは、まずデータが格納されているパーティションに分散され、次に設定されているロード・バランシング・アルゴリズムに応じていずれかのリモートLDAPサーバーにルーティングされます。パーティション化されたデータを保持するリモートLDAPサーバーは、レプリケートされます。
図3-4に示すように、プロキシはリクエストを受信すると、分散によって正しいパーティションに振り分けます。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。たとえば、cnがたとえばGarryであるエントリに対するリクエストは、パーティション1のA..Lのデータを保持するサーバーに転送されます。さらに、ロード・バランサによって、レプリケートされているいずれかのリモートLDAPサーバーに転送されます。
設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはデータ・センター内のリモートLDAPサーバーにルーティングされます。各種ロード・バランシング・アルゴリズムの詳細は、第12.2項「プロキシを使用したロード・バランシングの理解」を参照してください。
このデプロイメントには、データが分散されることにより更新が速いこと、およびデータの高可用性という利点があります。
各種分散アルゴリズムの詳細は、第12.3項「プロキシを使用したデータ分散の理解」を参照してください。
各種ロード・バランシング・アルゴリズムの詳細は、第12.2項「プロキシを使用したロード・バランシングの理解」を参照してください。
この構成のデプロイの詳細は、第12章「プロキシ、分散および仮想化機能の理解」を参照してください。
分散と2つのデータ・センターの間のフェイルオーバー・ロード・バランシングを併用するデプロイメントでは、データがパーティションに分割され、各パーティションはフェイルオーバー・ロード・バランシング・ルートによって管理されます。図3-5に示すように、パーティション化されたデータを保持するリモートLDAPサーバーが1つのデータ・センター内でレプリケートされるだけでなく、さらにデータ・センターがレプリケートされ、一方のデータ・センターがバックアップとして動作します。この図の「LDAP Server A...L」は、名前の先頭がAからLまでのユーザーのエントリが格納されるサーバーです。同様に、「LDAP Server M...Z」には、名前の先頭がMからZまでのユーザーのエントリが格納されます。
言い換えると、プロキシに送信されたリクエストは、まずデータが格納されているパーティションに分散されます。たとえば、cnがたとえばGarryであるエントリに対するリクエストは、パーティション1に転送されます。さらに、設定されているロード・バランシング・アルゴリズムに基づいて、フェイルオーバー・ロード・バランサによってメイン・ルート経由でA..Lのデータが格納されているいずれかのリモートLDAPサーバーに転送されます。
図3-5に示すデプロイメントでは、Data Center 2はバックアップとして動作し、Data Center 1で障害が発生した場合にのみ使用されます。ただし、これと同じデプロイメントを、フェイルオーバー・ロード・バランサではなく、saturationを使用するように構成できます。この場合、一方の地理的な場所(たとえば特定のタイムゾーン)にあるData Center 1が飽和状態になった場合、もう一方のデータ・センターが超過分のトラフィックを引き受けることができます。
このデプロイメントには、分散アルゴリズムを使用することにより読取りが速いことに加えて、リモートLDAPサーバーがレプリケートされ、1つのデータ・センターがバックアップとして動作するために高可用性が実現するという利点があります。
各種ロード・バランシング・アルゴリズムの詳細は、第12.2項「プロキシを使用したロード・バランシングの理解」を参照してください。
各種分散アルゴリズムの詳細は、第12.3項「プロキシを使用したデータ分散の理解」を参照してください。
ユースケースの例は、第25.5項「データ・センター間のフェイルオーバーを使用した分散の構成」を参照してください。
エンタープライズ・ユーザー・セキュリティ(EUS)のためにプロキシをデプロイする場合、構成の詳細はローカルのOracle Unified Directoryディレクトリ・サーバーに格納され、リモートの外部LDAPディレクトリにはエンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが格納されます。
図3-6に示すように、リモートの外部LDAPディレクトリには、エンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが格納されます。
デプロイメントの際に設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。
ロード・バランシング・アルゴリズムには、次の種類があります:
failover
optimal
proportional
saturation
各種ロード・バランシング・アルゴリズムの詳細は、第12.2項「プロキシを使用したロード・バランシングの理解」を参照してください。
エンタープライズ・ユーザー・セキュリティのためにプロキシをデプロイするには、第31章「Oracle Enterprise User SecurityへのOracle Unified Directoryの統合」を参照してください。
シングル・ポイント障害を回避するには、デプロイメントに冗長性を持たせることを保証する必要があります。通常は、図3-7に示すように、サード・パーティ・ハードウェア・ロード・バランサをインストールすることによってそれを実現できます。
ハードウェア・ロード・バランサを使用すると、物理的に異なるマシンまたは地理的に異なる場所にある複数のプロキシ・インスタンスを管理できます。
グローバル索引カタログを使用する分散デプロイメントで複数のプロキシ・インスタンスを実行する場合、グローバル索引カタログをレプリケートする必要があります。グローバル索引カタログのレプリケートの詳細は、第23.7.2項「グローバル索引カタログのレプリケーション」を参照してください。
このプロキシ・デプロイメントを構成するには、Oracle Unified Directoryのインストールのプロキシ・サーバーの設定に関する項を参照してください。
Oracle Unified Directoryの仮想化機能を使用して、バックエンド・データの各種ビューを作成し、仮想ディレクトリおよびデータ・ソースからデータを取得できます。
次に例を示します。
サーバー側の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がデータと相互作用する場所および変換が適用される方向を定義する変換ワークフロー要素を作成できます。
プロキシ・デプロイメント用のこれらおよびその他の仮想化機能の詳細は、第12章「プロキシ、分散および仮想化機能の理解」を参照してください。
これらの機能の構成の詳細は、第24章「仮想化の構成」を参照してください。
