| Oracle® Fusion Middleware Oracle WebLogic Serverプロキシ・プラグインの使用 12c (12.2.1.2.0) E82686-02 |
|
 前 |
 次 |
この章では、オラクル社提供のプラグインの構成において、すべてのWebサーバーに共通するタスクを説明します。次の項で構成されます。
バージョン12c (12.2.1.1.0)プラグインでは、IPv6がサポートされています。具体的には、WebLogicHostおよびWebLogicCluster構成パラメータ(「WebLogicCluster」および「WebLogicHost」を参照)でIPv6アドレスをサポートするようになりました。次にその例を示します。
<IfModule mod_weblogic.c> WebLogicHost [a:b:c:d:e:f] WebLogicPort 7002 ... </IfModule>
または
<IfModule mod_weblogic.c> WebLogicCluster [a:b:c:d:e:f]:<port>, [g:h:i:j:k:l]:<port> .... </IfModule>
IPv6アドレスにマップされているホスト名を使用することもできます。
注意:
Windows 2008以降、DNSサーバーは、IPv4アドレスよりもIPv6アドレスを優先して返します。IPv4を使用してWindows 2008以降のシステムに接続している場合は、最初にリンクローカルIPv6アドレス形式が試みられ、それによって遅延が顕著となり、パフォーマンスが低下する可能性があります。IPv4アドレス形式を使用するには、構成ファイルでかわりのIPアドレスを使用するようシステムを構成するか、IPv4アドレスをetc/hostsファイルに追加します。
また、mod_wl_ohs.conf/mod_wl.conf/iisproxy.iniファイル内でDynamicServerListプロパティをOFFに設定することによっても、IPv6でのパフォーマンスが向上する可能性があります。OFFに設定すると、プラグインは、プラグインからプロキシされたロード・バランシング・リクエストに使用される動的クラスタ・リストを無視し、WebLogicClusterパラメータで指定された静的リストを使用します。
プラグインでは、WebLogic Serverへの接続を試みるときに、様々な構成パラメータを使用することで、WebLogic Serverホストへの接続を待機する時間と接続確立後にレスポンスを待機する時間が決定されます。接続できないかレスポンスがない場合、プラグインは、クラスタ内の別のWebLogic Serverインスタンスへの接続とリクエストの送信を試みます。接続に失敗するか、クラスタ内のどのWebLogic Serverからもレスポンスがない場合は、エラー・メッセージが送信されます。
図7-1に、プラグインでのフェイルオーバーの処理方法を示します。
この項の内容は次のとおりです。
WebLogic Serverホストで接続リクエストに対する応答に失敗する場合は、次のような問題が考えられます。
ホスト・マシンの物理的な問題
ネットワークの問題
その他のサーバー障害
すべてのWebLogic Serverインスタンスで応答に失敗する場合は、次のような問題が考えられます。
WebLogic Serverが実行されていないか使用不可である
サーバーのハング
データベースの問題
アプリケーション固有の障害
負荷がかかると、プラグインはバックエンドのWebLogic ServerインスタンスからCONNECTION_REFUSEDエラーを受け取ることがあります。CONNECTION_REFUSEDエラーを減らすには、チューニングに関する次のヒントに従ってください。
WebLogic Serverドメインの構成において、AcceptBackLogの設定値を大きくします。
待機時間を短くします。この設定は、使用するオペレーティング・システムに応じて異なります。次にその例を示します。
Windows NTの場合は、プロキシおよびWebLogic ServerサーバーのTcpTimedWaitDelayの設定値を小さくします。HKEY_LOCAL_MACHINEの下の次のレジストリ・キーを編集することで、Windows NTでのTIME_WAIT間隔を設定します。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay
このキーが存在しない場合は、DWORD値としてこれを作成できます。数値は待機する秒数であり、30から240までの任意の値を設定できます。設定しない場合、Windows NTでは、TIME_WAITにデフォルトの240秒が設定されます。
Windows 2000の場合は、HKEY_LOCAL_MACHINEの下の次のレジストリ・キーを編集することで、TcpTimedWaitDelayの値を小さくします。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Solarisの場合は、tcp_time_wait_intervalの設定を1秒に減らします(可能な場合は、WebLogic ServerマシンとApacheマシンの両方に対して設定)。
$ndd /dev/tcp param name to set - tcp_time_wait_interval value=1000
マシン上でオープン・ファイル・ディスクリプタの制限値を大きくします。この制限は、オペレーティング・システムによって異なります。limit (.csh)またはulimit (.sh)ディレクティブを使用して、制限値を大きくするスクリプトを作成できます。次にその例を示します。
#!/bin/sh ulimit -S -n 100 exec httpd
Solarisの場合は、WebLogic Serverマシン上の次のチューニング可能項目の値を大きくします。
tcp_conn_req_max_q tcp_conn_req_max_q0
WebLogic Serverインスタンスが1つしか実行されていない場合、プラグインは、WebLogicHostパラメータで定義されているサーバーのみに接続を試みます。失敗すると、HTTP 503エラー・メッセージが返されます。プラグインは、ConnectTimeoutSecsとConnectRetrySecsの比で指定されている最大再試行回数まで、同じWebLogic Serverインスタンスへの接続の試行を続けます。
WebLogicClusterパラメータは、クラスタ化されたバックエンド・サーバーのリストにプロキシしたり、クラスタ化されていない管理対象サーバー・インスタンスのロード・バランシングを実行するために必要となります。
クラスタ化された管理対象サーバーにプロキシする場合、WebLogicClusterパラメータを使用してWebLogic Serverのリストを指定すると、プラグインは、クラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つにルーティングされた後、クラスタ内のサーバーの更新されたリストを含む動的サーバー・リストが返されます。
更新されたリストでは、クラスタ内の新しいサーバーが追加され、停止されたサーバー、一時停止されたサーバー、クラスタ・メンバーではなくなったサーバーおよびリクエストに応答しなかったサーバーは削除されます。この機能は、DynamicServerListを使用して制御可能です。たとえば、この機能を無効にするには、DynamicServerListをOFFに設定します。
DynamicServerList ONは、推奨されるパフォーマンス・チューニング・パラメータです。クラスタのメンバーが保守のために一時的に停止されている場合や、管理者が別のメンバーを追加することを決定し、Webサーバーの再起動が必要ない場合などに役立ちます。
注意:
DynamicServerListをONに設定し、WebLogicClusterで指定されたバックエンドWebLogic Serverのリストがクラスタにない場合、動作は未定義になります。
リクエストに、CookieやPOSTデータに格納されているかURLでエンコードされたセッション情報が含まれている場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼ばれる)への参照が含まれています。Cookieが含まれるリクエストは、プライマリ・サーバーへの接続を試みます。その試みが失敗すると、プラグインは、ラウンドロビン方式で、リスト内にある次に使用可能なサーバーへの接続を試みます。そのサーバーが元のセカンダリ・サーバーからセッションを取得し、そのサーバー自体が同一セッションの新しいプライマリ・サーバーになります。図7-1を参照してください。
注意:
POSTデータが64Kより大きい場合、プラグインは、セッションIDを取得するため、POSTデータを解析しません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリ・サーバーまたはセカンダリ・サーバーにルーティングできず、セッション・データが失われる可能性があります。
この図の赤色のループに許容されている最大試行回数はConnectTimeoutSecs/ConnectRetrySecsの値と等しくなります。
ほとんどの構成では、iPlanet Web Server用Oracle WebLogic Serverプロキシ・プラグイン12c (12.2.1.1.0)は、リクエストをクラスタのプライマリ・インスタンスに送信します。そのインスタンスを使用できないと、リクエストはセカンダリ・インスタンスにフェイルオーバーします。ただし、ファイアウォールとロード・ディレクタを組み合せて使用する一部の構成では、WebLogic Serverのプライマリ・インスタンスを使用できなくても、いずれか1つのサーバー(ファイアウォールまたはロード・ディレクタ)がリクエストを受け入れ、正常な接続を返します。WebLogic Serverの使用できないプライマリ・インスタンスへのリクエストの送信が試みられると、リクエストは接続リセットとしてプラグインに返されます。
ファイアウォールの組合せを介して(ロード・ディレクタの有無に関係なく)実行されるリクエストは、WebLogic Serverによって処理されます。つまり、接続リセットのレスポンスは、WebLogic Serverのセカンダリ・インスタンスにフェイルオーバーします。このような構成では、接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変である必要があります。そうでない場合は、トランザクションの処理が重複する可能性があります。
WebLogic Server 12c (12.2.1.1.0)では、WebSocketアプリケーションのデプロイがサポートされています。Oracle HTTP Server 12c (12.2.1.1.0)とApache HTTP Server 2.2.xおよび2.4.x用のOracle WebLogic Serverプロキシ・プラグイン12c (12.2.1.1.0)では、そのようなWebSocket接続アップグレード・リクエストを処理して、WebLogic Server 12c (12.2.1.1.0)以降でホストされるWebSocketアプリケーションに対して効率的にプロキシできるようになりました。このサポートが追加されたことで、新しい構成パラメータであるWLMaxWebSocketClientsが導入されています。
WLMaxWebSocketClientsパラメータは、アクティブなWebSocket接続の数をいつでも制限します。このパラメータに設定できる最大値は、ThreadsPerChildの75% (Windowsの場合)またはMaxRequestWorkersの75% (Windows以外の場合)となります。したがって、HTTPサーバーのWebSocket接続アップグレード・リクエストの最大数を調整するには、MaxRequestWorkersまたはThreadsPerChildをWebSocket接続にも対応できる値に設定してください。また、WLMaxWebSocketClientsがMaxRequestWorkers/ThreadsPerChildの75%に設定されていることを確認してください。
手動構成を一部行うことで、Oracle WebLogic Serverプロキシ・プラグインは、Oracle WebLogic Server MT (マルチテナンシ)のフロントエンドになることができます。
この項の内容は次のとおりです。
注意:
この項では、Oracle WebLogic Serverプロキシ・プラグインに適用する場合に限定して、パーティションとマルチテナンシについて説明します。Oracle WebLogic Server MT、パーティションおよびマルチテナンシの詳細は、『Oracle Fusion Middleware WebLogic Server MTの使用』を参照してください。
パーティションをOracle WebLogic Server MT側で追加した場合、新しいパーティションのフロントになるように、対応する変更を必ずWebサーバー構成に加える必要があります。パーティション自体の追加の詳細は、Oracle WebLogic Server MTのドキュメントに記載されています(『Oracle Fusion Middleware WebLogic Server MTの使用』のドメイン・パーティションの構成に関する項を参照)。
次の項では、Oracle WebLogic Server MTで新規追加したパーティションのフロントエンドになるように、対応する変更をWebサーバー構成に加える方法について説明します。
注意:
次の項では、Oracle WebLogic Serverに1つ以上のドメイン・パーティションがすでに作成されていることが前提になります。ドメイン・パーティションの作成の詳細は、『Oracle Fusion Middleware WebLogic Server MTの使用』のドメイン・パーティションの構成に関する項を参照してください。
次に、新しいパーティションを追加するたびに、Oracle HTTP ServerまたはApacheプラグインの構成ファイル(httpd.conf)に追加する必要があるサンプル構成を示します。構成によって、パーティションのホスト名とポート、サーバーとそれが属するWebLogicクラスタ、パーティションに構成されるオプションのURIが識別されます。
次の例では、様々な使用例のサンプル構成を示します。
例1: クライアントでパーティション・パスを構成できない
ドメインに2つのパーティションがあるとします。
VirtualTarget1のホスト名はwww.myCompany1.com、URI接頭辞(パーティション・パス)は、Oracle WebLogic Serverで構成されているnullになります。
VirtualTarget2のホスト名はwww.myCompany2.com、URI接頭辞(パーティション・パス)は、Oracle WebLogic Serverで構成されているnullになります。
この場合、パーティション・パスを構成する必要はありません
LoadModule weblogic_module modules/mod_wl_24.so <VirtualHost *:8080> <IfModule mod_weblogic.c> ServerName www.myCompany1.com WebLogicCluster wls1:7001,wls2:7001,wls3:7001 SetHandler weblogic-handler </IfModule> </VirtualHost> <VirtualHost *:8080> <IfModule mod_weblogic.c> ServerName www.myCompany2.com WebLogicCluster wls1:7002,wls2:7002,wls3:7002 SetHandler weblogic-handler </IfModule> </VirtualHost>
この構成では、myCompany1.com:8080またはmyCompany1.comへのリクエストはすべて、管理対象サーバーwls1:7001、wls2:7001およびwls3:7001にプロキシされます。同様に、myCompany2.com:8080またはmyCompany2.comへのリクエストはすべて、管理対象サーバーwls1:7002、wls2:7002およびwls3:7002にプロキシされます。
例2: クライアントでパーティション・パスによってWebサイトが分割される
ドメインに2つのパーティションがあるとします。
VirtualTarget1のホスト名はwww.foo.com、URI接頭辞(パーティション・パス)は、Oracle WebLogic Serverで構成されている/myCompany1になります。
VirtualTarget2のホスト名はwww.foo.com、URI接頭辞(パーティション・パス)は、Oracle WebLogic Serverで構成されている/myCompany2になります。
この場合、パーティション・パスを構成する必要はありません。
<VirtualHost *:8080> <IfModule mod_weblogic.c> ServerName server1 WebLogicCluster wls1:7001,wls2:7001,wls3:7001 SetHandler weblogic-handler </IfModule> </VirtualHost>
使用可能なURLは次のとおりです。
www.foo.com:8080/myCompany1
www.foo.com:8080/myCompany2
パーティション移行は、Oracle WebLogic Server MTの機能です。Oracle WebLogic Serverプロキシ・プラグイン側でパーティションは移行できません。パーティションを移行したら、新しいパーティション情報を使用するには、Oracle WebLogic Serverプロキシ・プラグイン構成を手動で更新する必要があります。
パーティション移行の詳細は、『Oracle Fusion Middleware WebLogic Server MTの使用』のパーティションのエクスポートとインポートに関する項を参照してください。
Oracle WebLogic Server側でパーティションを変更する場合、対応する変更をプラグイン構成に加える必要があります。Oracle WebLogic Server側では、通常、VirtualHostパラメータ(ホストとポート)およびオプションでURIを変更できます。この場合、プラグイン構成でServerNameおよびPathPrependパラメータを編集する必要があります。
Oracle WebLogic Server側で管理対象サーバーを追加、削除または移行する場合、対応する変更をプラグイン構成でも加える必要があります。
たとえば、次のOracle HTTP Server (またはApache)プラグイン構成があるとします。
<VirtualHost *:8080> <IfModule mod_weblogic.c> ServerName server1 WebLogicCluster wls1:7001,wls2:7001,wls3:7001 SetHandler weblogic-handler </IfModule> </VirtualHost>
管理対象サーバーwls4をパーティションに追加する場合、wls4をWebLogicClusterパラメータに追加します。
<VirtualHost *:8080>
<IfModule mod_weblogic.c>
ServerName server1
WebLogicCluster wls1:7001,wls2:7001,wls3:7001,wls4:7001
SetHandler weblogic-handler
</IfModule>
</VirtualHost>
管理対象サーバーwls1をパーティションから削除する場合、wls1をWebLogicClusterパラメータから削除します。
<VirtualHost *:8080> <IfModule mod_weblogic.c> ServerName server1 WebLogicCluster wls2:7001,wls3:7001,wls4:7001 SetHandler weblogic-handler </IfModule> </VirtualHost>
管理対象サーバーwls2をwls5に移行する場合、wls2を削除して、wls5をWebLogicClusterパラメータに追加します。
<VirtualHost *:8080>
<IfModule mod_weblogic.c>
ServerName server1
WebLogicCluster wls3:7001,wls4:7001,wls5:7001
SetHandler weblogic-handler
</IfModule>
Oracle WebLogic Server側のパーティションの変更の詳細は、『Oracle Fusion Middleware WebLogic Server MTの使用』のドメイン・パーティションの構成に関する項、仮想ターゲットの構成に関する項およびパーティションのエクスポートとインポートに関する項を参照してください。
Oracle WebLogic Serverの場合と同様にOracle WebLogic Server MTでSSLを構成しますが、同じホスト名を対象とするパーティションには同じ証明書が必要になります。
クラスタ変更の動的検出は、Oracle WebLogic Serverプロキシ・プラグインとOracle WebLogic Serverの両方の機能です。マルチテナンシによる影響はありません。この機能は、DynamicServerListパラメータを使用して制御可能です。詳細は、「DynamicServerList」を参照してください。
