7 ロード・バランサとのWebLogic RMIの統合
この章には次の項が含まれます:
WebLogic Serverでのロード・バランサのサポート
RMIを使用するWebLogic Serverクライアントは、次のメカニズムを使用してロード・バランサと相互運用できます。
-
HTTP/HTTPSでT3をトンネリングする場合、WebLogic Clusterへのリクエスト転送メカニズムでスティッキーなセッション・ルーティングの使用が構成されているかぎり、WebLogic Serveでは、ハードウェア・ロード・バランサ、またはWebサーバー・プラグインを含むWebサーバーによるルーティングがサポートされます。「HTTPトンネリングT3ロード・バランシング」を参照してください
-
T3を直接使用する場合、JNDI
InitialContext
の作成時にロード・バランサを指し示すPROVIDER_URL
を指定することで、WebLogic Serverでは、クラスタへの初期T3接続をブートストラップするハードウェア・ロード・バランサの使用がサポートされます。「ネイティブT3ロード・バランシング」を参照してください
ノート:
WebLogic RMIでハードウェア・ロード・バランサを使用するその他の方法は、それらが機能するかどうかに関係なくサポートされません。
HTTPトンネリングT3ロード・バランシング
HTTP(またはHTTPS)でT3をトンネリングする場合、WebLogic Serverランタイムは、RMIセッションごとにHttpSession
を作成し、通常のHTTPメカニズムを使用して、クライアントとサーバー間でセッションIDの受渡しを行います。これにより、Webサーバー・プラグインまたはハードウェア・ロード・バランサは、該当セッションの期間中に、クラスタ内の同じサーバーに特定のクライアントからのすべてのRMIリクエストをルーティングできます。
ノート:
外部ロード・バランサは、T3およびデフォルト・チャネルを介して、Javaクライアントからの初期コンテキスト・リクエストを分散します。ただし、ロード・バランサ経由で初期コンテキスト・リクエストに続くクライアント・リクエストをルーティングしないでください。外部ロード・バランサとT3プロトコルを併用するとき、初期コンテキスト・リクエストのみがロード・バランサを通してルーティングされ、後続のリクエストがWebLogic Serverのロード・バランシングを使用してルーティングおよび制御されていることを確認する必要があります。
外部リスニング・アドレスの構成方法
WebLogic Serverには、クライアントがNetwork Address Translating (NAT)ファイアウォール経由でサーバーに接続できるように、RMIスタブで使用するIPアドレスを提供する「外部リスニング・アドレス」
があります。NATファイアウォールが一意の外部IPアドレスを、サーバーの一意の内部IPアドレスにマップしているかぎり、クライアントに配信される各スタブは、プロキシ対象のオブジェクトを保持するクラスタ・メンバーを一意に識別します。「外部リスニング・アドレス」
は、デフォルトおよびカスタムのネットワーク・チャネルに対して個別に設定されます。
-
デフォルト・チャネルの場合、ServerMBeanで
ExternalDNSName
属性を使用します。Oracle WebLogic Server MBeanリファレンスのExternalDNSNameに関する項を参照してください。 -
カスタム・チャネルの場合、NetworkAccessMBeanで
PublicAddress
とPublicPort
を使用します。Oracle WebLogic Server MBeanリファレンスのNetworkAccessPointMBeanに関する項を参照してください。
ロード・バランサのカスタム・チャネル構成の例
クラスタのすべてのWebLogic ServerインスタンスでT3ネットワーク・チャネルを構成します。ネットワーク・チャネルは、ロード・バランサからトンネリングされたトラフィックを受け入れます。すべてのクライアント・リクエストがロード・バランサ経由でルーティングされるようにするには、ロード・バランサ(Webサーバー)がクライアントからトラフィックを受け入れるエンド・ポイントに「外部リスニング・アドレス」
を設定します。HTTP
プロトコルを有効にして、tunneling-enabled=true
を設定します。WebLogic Serverにhttpトラフィックをルーティングするように、ロード・バランサまたはWebサーバーを構成します。Oracle HTTP Server (OHS)をWebサーバーとして使用する場合は、httpd.conf
構成ファイルを変更してください。たとえば:
WebLogic Serverのconfig.xml
:
<network-access-point> <name>tunnelChannel</name> <protocol>t3</protocol> <listen-address>example.com</listen-address> <listen-port>11001</listen-port> <http-enabled-for-this-protocol>true</http-enabled-for-this-protocol> <tunneling-enabled>true</tunneling-enabled> <outbound-enabled>false</outbound-enabled> <enabled>true</enabled> <two-way-ssl-enabled>false</two-way-ssl-enabled> <client-certificate-enforced>false</client-certificate-enforced> </network-access-point><network-access-point> . . .
OHS/Web層のhttpd.conf
ファイル
<LocationMatch ^/bea_wls_internal/> SetHandler weblogic-handler WeblogicCluster example.com:11001 </LocationMatch> . . .
セッション・フェイルオーバー
セッション・フェイルオーバーは、クライアントに対して透過的です。サーバーが停止すると、クライアントのRJVMはPeerGone
例外を受信します。このため、HTTPClientJVMConnection
が終了します。次のリクエストが同じクライアントから生じると、ステートレスBeanとステートフルBeanのどちらの場合も、リクエストはクラスタの次のメンバーにフェイルオーバーされます。例外がリクエストの処理中に生じた場合、そのリクエストはフェイルオーバーされず、例外がクライアントに伝播されます。
確保済オブジェクト
クラスタでは、オブジェクトが確保されていてreplicate_bindings!= false
の場合でも、スタブはクラスタのすべてのメンバーにレプリケートされます。トンネリングは、正常な確保済オブジェクトの動作に影響を与えません。
ネイティブT3ロード・バランシング
クラスタ・メンバーに障害が発生した場合、ファイアウォールが別のクラスタ・メンバーにリクエストをリダイレクトしようとしないため、非クラスタ対応のスタブに対するクライアントの呼出しも失敗します。クラスタ対応のスタブ呼出しの場合、クラスタ対応のスタブに含まれる「外部リスニング・アドレス」
を使用して、障害を回避するための透過的なリクエスト・ルーティングの実行や別のクラスタ・メンバーの呼出しを行う必要があります。「外部リスニング・アドレスの構成方法」を参照してください
ハードウェア・ロード・バランサを使用して、JNDIのInitialContext
の作成時に初期T3接続リクエストをロード・バランシングするには、ロード・バランサを指し示すPROVIDER_URL
を指定します(「外部リスニング・アドレス」
がハードウェア・ロード・バランサを指し示している場合を除く)。初期TCP接続リクエストをいずれかの管理対象サーバーにルーティングする際にのみハードウェア・ロード・バランサが呼び出されるため、この構成は機能します。 接続が確立されると、スタブがプロキシしているサーバーを一意に識別するサーバーのListenAddress
(NATファイアウォールの場合は「外部リスニング・アドレス」
)が、すべてのRMIスタブに含められます。
フェイルオーバー・サポート
WebLogic RMIは、ハードウェア・ロードバランサで使用される場合、フェイルオーバーをサポートしません。
WebLogic Server RMIによるフェイルオーバーの処理については、「RMIオブジェクトのフェイルオーバーとロード・バランシング」を参照してください