| Oracle® Fusion Middleware Oracle WebLogic Server RMIアプリケーションの開発 12c (12.2.1.1.0) E79316-01 |
|
 前 |
 次 |
この章には次の項が含まれます:
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(または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管理コンソール・オンライン・ヘルプのExternalDNSNameを参照してください。
カスタム・チャネルの場合、NetworkAccessMBeanでPublicAddressとPublicPortを使用します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの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>foo.bar.Company.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 foo.oracle.com:11001 </LocationMatch> . . .
セッション・フェイルオーバーは、クライアントに対して透過的です。サーバーが停止すると、クライアントのRJVMはPeerGone例外を受信します。このため、HTTPClientJVMConnectionが終了します。次のリクエストが同じクライアントから生じると、ステートレスBeanとステートフルBeanのどちらの場合も、リクエストはクラスタの次のメンバーにフェイルオーバーされます。例外がリクエストの処理中に生じた場合、そのリクエストはフェイルオーバーされず、例外がクライアントに伝播されます。
クラスタでは、オブジェクトが確保されていてreplicate_bindings!= falseの場合でも、スタブはクラスタのすべてのメンバーにレプリケートされます。トンネリングは、正常な確保済オブジェクトの動作に影響を与えません。
クラスタ・メンバーに障害が発生した場合、ファイアウォールが別のクラスタ・メンバーにリクエストをリダイレクトしようとしないため、非クラスタ対応のスタブに対するクライアントの呼出しも失敗します。クラスタ対応のスタブ呼出しの場合、クラスタ対応のスタブに含まれる「外部リスニング・アドレス」を使用して、障害を回避するための透過的なリクエスト・ルーティングの実行や別のクラスタ・メンバーの呼出しを行う必要があります。「外部リスニング・アドレスの構成方法」を参照してください
ハードウェア・ロード・バランサを使用して、JNDIのInitialContextの作成時に初期T3接続リクエストをロード・バランシングするには、ロード・バランサを指し示すPROVIDER_URLを指定します(「外部リスニング・アドレス」がハードウェア・ロード・バランサを指し示している場合を除く)。初期TCP接続リクエストをいずれかの管理対象サーバーにルーティングする際にのみハードウェア・ロード・バランサが呼び出されるため、この構成は機能します。 接続が確立されると、スタブがプロキシしているサーバーを一意に識別するサーバーのListenAddress (NATファイアウォールの場合は「外部リスニング・アドレス」)が、すべてのRMIスタブに含められます。
WebLogic RMIは、ハードウェア・ロードバランサで使用される場合、フェイルオーバーをサポートしません。
WebLogic Server RMIによるフェイルオーバーの処理については、「RMIオブジェクトのフェイルオーバーとロード・バランシング」を参照してください
