| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
たとえば、NYDCの各Webゲートでプライマリ・サーバーをssonode1.ny.acme.com、ssonode2.ny.acme.comなどと構成するかわりに、すべてが同じ仮想ホスト名(たとえばsso.ny.acme.com)を指し、ロード・バランサがDNSを解決してクラスタ内の各ノードに転送することもできます。ただし、Access Managerコンポーネント間にロード・バランサを導入するときは、次の制約事項に注意してください。
OAP接続は永続的であり、アイドル状態になっている場合でも、構成可能な期間の間はそれらの接続をオープンしておく必要があります。
ロード・バランサが接続を終了する前に、接続をリサイクルするようにWebゲートを構成する必要があります。ただし、ロード・バランサがTCPリセットをWebゲートとサーバーの両方に送信でき、確実に接続がクリーンアップされる場合は除きます。
ロード・バランサは、OAP接続を各WebゲートのアクティブなAccess Managerサーバー間で均等に分散する(OAP接続を接続元IPに従って分散する)必要があります。このようにしない場合は、負荷の偏りが発生する可能性があります。
図17-11に、ローカルのロード・バランサ(LBR 3およびLBR 4)が各データ・センターのクラスタのフロント・エンドとなっているデプロイメント・トポロジのバリエーションを示します。mod_wl_ohsによって、これらのローカル・ロード・バランサとしてOracle HTTP Server (OHS)を使用できます。OAPトラフィックはデータ・センター内のWebゲートとAccess Managerクラスタとの間を流れますが、ロード・バランサがDNSルーティングを実行することによって、仮想ホスト名が使用できるようになります。
ノート:
使用中のロード・バランサによるAccess Managerサーバーのヘルスのモニタリングの詳細は、「Access Managerサーバーのヘルスのモニタリング」を参照してください。
図17-12に、デプロイメント・トポロジのもう1つのバリエーションを示します。このトポロジでは、グローバル・ロード・バランサ(GLBR2)が導入されており、ローカル・ロード・バランサ(LBR3およびLBR4)のフロント・エンドとなっています。この場合は、データ・センター内だけでなく、データ・センター間でのホスト名の仮想化が可能になります。各データ・センター内のWebゲートは、ロード・バランシングはローカルで行うが、フェイルオーバーはリモートで行うように構成されます。このトポロジの主な利点の1つは、スタックの全レイヤーで高可用性が保証されることです。データ・センターのAccess Managerクラスタ全体が停止した場合でも、そのデータ・センターのWebゲートは他のデータ・センターのAccess Managerクラスタにフェイルオーバーします。
