| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
様々なタイプのデプロイメントでOracle Unified Directoryプロキシを正常に使用できます。次に、プロキシの動作の理解に役立つデプロイメントを示します。
この章では、次のトピックを取り扱います:
プロキシを使用する主なデプロイメント・タイプとして、ロード・バランシングと分散の2つがあります。
使用するデプロイメント・タイプを決定するには、データを格納する場所と方法および処理するデータ量について検討します。
レプリケートされるデータ・ストアにすべてのデータが格納される場合、ロード・バランシングを使用するデプロイメントを使用します。「構成1: 単純なロード・バランシング」を参照してください。
データがパーティション化されている場合、またはデータベースのサイズが大きいので複数のデータ・ソースにパーティション化されるようにデータを分割する必要がある場合、分散を使用するデプロイメントを使用します。第3.2.2項「構成2: 単純な分散」を参照してください。
ロード・バランシングと分散を組み合せる、さらに複雑なデプロイメント・シナリオも定義できます。ロード・バランシングまたは分散のどちらが必要なのか、あるいは両方が必要なのかを検討する必要があります。
この後は、単純なロード・バランシングおよび単純な分散に加えて、次のデプロイメント例について説明します:
たとえば、地理的に異なる場所にデータ・センターを配置する場合、ロード・バランシングされた2つのデータ・センターの間にフェイルオーバーをデプロイできます。第3.2.3項「構成3: データ・センター間のフェイルオーバー」を参照してください。
分散を使用し、さらにデータ・パーティションをレプリケートする場合、ロード・バランサにルーティングされる分散を使用するプロキシ・サーバーをデプロイできます。第3.2.4項「構成4: 分散とロード・バランシングの併用」を参照してください。
分散を使用し、データ・パーティションをレプリケートすると同時に、可用性とディザスタ・リカバリのためにパーティションを1つのデータ・センター内でレプリケートするだけでなく、地理的に異なる2つの場所にあるデータ・センター間でレプリケートする場合、第3.2.5項「構成5: 分散とデータ・センター間のフェイルオーバーの併用」と同様のアーキテクチャをデプロイできます。
分散を使用してグローバル索引カタログをデプロイメントに追加することによって、エントリを特定のパーティションにマップできます。これにより、ブロードキャストの使用を最小限に抑えることができます。グローバル索引カタログの構成の詳細は、第18.1.7項「コマンド行を使用したグローバル索引の構成」を参照してください。
様々なタイプのデプロイメントでOracle Unified Directoryプロキシを正常に使用できます。この項では、デプロイメントについて説明します。これは、プロキシの動作を理解するために役立ちます。
この項には次のトピックが含まれます:
プロキシをデプロイしてロード・バランシングを実現する場合、プロキシが受信したリクエストはすべて、いずれかのリモートLDAPサーバーにルーティングされます。図3-1に示すように、リモートLDAPサーバーはレプリケートされるので、格納されるデータは同じです。サポートするリモートLDAPサーバーの数に制限はありません。
デプロイメントの際に設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。
ロード・バランシング・アルゴリズムには、次の種類があります:
failover
generic
optimal
proportional
saturation
searchfilter
各種ロード・バランシング・アルゴリズムの詳細は、第12.1項「プロキシを使用したロード・バランシング」を参照してください。
このアルゴリズムは、クライアント接続アフィニティによりバイパスできます。クライアント接続アフィニティを設定した場合、プロキシは、最初のリクエストの処理ではロード・バランシング・アルゴリズムを使用しますが、それ以降のリクエストの処理では設定されているロード・バランシング・アルゴリズムを無視し、たとえば設定されているクライアント・アフィニティのタイプに応じて、同じクライアント接続上の新しい操作に同じルートを再利用しようとします。詳細は、第18.1.3.5.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.2項「プロキシを使用したデータ分散」を参照してください。
分散を使用するデプロイメントの場合、1秒当たりの更新数をスケーリングできるという利点があります。分散を使用する場合、グローバル索引カタログを追加してブロードキャストの数を減らすことができます。グローバル索引カタログの詳細は、第18.1.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が飽和状態になった場合、もう一方のデータ・センターが超過分のトラフィックを引き受けることができます。
各種ロード・バランシング・アルゴリズムの詳細は、「プロキシを使用したロード・バランシング」を参照してください。
この構成のデプロイの詳細は、「フェイルオーバー・ロード・バランシング」を参照してください。
分散とロード・バランシングを併用するデプロイメントでは、データがパーティションに分割され、リモート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.1項「プロキシを使用したロード・バランシング」を参照してください。
このデプロイメントには、データが分散されることにより更新が速いこと、およびデータの高可用性という利点があります。
各種分散アルゴリズムの詳細は、第12.2項「プロキシを使用したデータ分散」を参照してください。
各種ロード・バランシング・アルゴリズムの詳細は、第12.1項「プロキシを使用したロード・バランシング」を参照してください。
この構成のデプロイの詳細は、第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.1項「プロキシを使用したロード・バランシング」を参照してください。
この構成のデプロイの詳細は、第19.5項「データ・センター間のフェイルオーバーを使用した分散の構成」を参照してください。
エンタープライズ・ユーザー・セキュリティ(EUS)のためにプロキシをデプロイする場合、構成の詳細はローカルのOracle Unified Directoryに格納され、リモートの外部LDAPディレクトリにはエンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが格納されます。
図3-6に示すように、リモートの外部LDAPディレクトリには、エンタープライズ・ユーザーとエンタープライズ・グループの詳細のみが格納されます。
デプロイメントの際に設定されたロード・バランシング・アルゴリズムに基づいて、リクエストはどちらかのリモートLDAPサーバーにルーティングされます。
ロード・バランシング・アルゴリズムには、次の種類があります:
failover
optimal
proportional
saturation
各種ロード・バランシング・アルゴリズムの詳細は、第12.1項「プロキシを使用したロード・バランシング」を参照してください。
このプロキシ・デプロイメントを構成するには、次の手順に従います:
Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのエンタープライズ・ユーザー・セキュリティの構成に関する項の説明に従って、プロキシ・サーバーを構成します。
第28章「Oracleエンタープライズ・ユーザー・セキュリティへのOracle Unified Directoryの統合」の説明に従って、Oracle Unified Directoryとエンタープライズ・ユーザー・セキュリティを統合します。
シングル・ポイント障害を回避するには、デプロイメントに冗長性を持たせることを保証する必要があります。通常は、図3-7に示すように、サード・パーティ・ハードウェア・ロード・バランサをインストールすることによってそれを実現できます。
ハードウェア・ロード・バランサを使用すると、物理的に異なるマシンまたは地理的に異なる場所にある複数のプロキシ・インスタンスを管理できます。
グローバル索引カタログを使用する分散デプロイメントで複数のプロキシ・インスタンスを実行する場合、グローバル索引カタログをレプリケートする必要があります。グローバル索引カタログのレプリケートの詳細は、第18.1.7.2項「グローバル索引カタログのレプリケーション」を参照してください。
このプロキシ・デプロイメントを構成するには、Oracle Fusion Middleware Oracle Unified Directoryインストレーション・ガイドのプロキシ・サーバーの設定に関する項を参照してください。
