6 共通の構成タスク
この章では、オラクル社提供のプラグインの構成において、すべてのWebサーバーに共通するタスクを説明します。内容は次のとおりです。
プラグインでのIPv6の構成
バージョン12c (12.2.1.4.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からもレスポンスがない場合は、エラー・メッセージが送信されます。
図6-1に、プラグインでのフェイルオーバーの処理方法を示します。
この項の内容は次のとおりです。
接続障害についての考えられる原因
WebLogic Serverホストで接続リクエストに対する応答に失敗する場合は、次のような問題が考えられます。
-
ホスト・マシンの物理的な問題
-
ネットワークの問題
-
その他のサーバー障害
すべてのWebLogic Serverインスタンスで応答に失敗する場合は、次のような問題が考えられます。
-
WebLogic Serverが実行されていないか使用不可である
-
サーバーのハング
-
データベースの問題
-
アプリケーション固有の障害
CONNECTION_REFUSEDエラーを減らすためのヒント
負荷がかかると、プラグインはバックエンドの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でのフェイルオーバー
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およびHTTPセッション
リクエストに、CookieやPOSTデータに格納されているかURLでエンコードされたセッション情報が含まれている場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼ばれる)への参照が含まれています。Cookieが含まれるリクエストは、プライマリ・サーバーへの接続を試みます。その試みが失敗すると、プラグインは、ラウンドロビン方式で、リスト内にある次に使用可能なサーバーへの接続を試みます。そのサーバーが元のセカンダリ・サーバーからセッションを取得し、そのサーバー自体が同一セッションの新しいプライマリ・サーバーになります。図6-1を参照してください。
ノート:
POSTデータが64Kより大きい場合、プラグインは、セッションIDを取得するため、POSTデータを解析しません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリ・サーバーまたはセカンダリ・サーバーにルーティングできず、セッション・データが失われる可能性があります。
この図の赤色のループに許容されている最大試行回数はConnectTimeoutSecs/ConnectRetrySecs
の値と等しくなります。
ファイアウォールとロード・ディレクタを使用する場合のフェイルオーバー動作
ファイアウォールとロード・ディレクタを組み合せて使用する一部の構成では、WebLogic Serverのプライマリ・インスタンスを使用できなくても、いずれか1つのサーバー(ファイアウォールまたはロード・ディレクタ)がリクエストを受け入れ、正常な接続を返します。WebLogic Serverの使用できないプライマリ・インスタンスへのリクエストの送信が試みられると、リクエストは接続リセットとしてプラグインに返されます。
ファイアウォールの組合せを介して(ロード・ディレクタの有無に関係なく)実行されるリクエストは、WebLogic Serverによって処理されます。つまり、接続リセットのレスポンスは、WebLogic Serverのセカンダリ・インスタンスにフェイルオーバーします。このような構成では、接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変である必要があります。そうでない場合は、トランザクションの処理が重複する可能性があります。
WebSocketアップグレード・リクエストのスループットを高めるためのOracle HTTP ServerとApache HTTP Serverのチューニング
WebLogic Server 12c (12.2.1.4.0)では、WebSocketアプリケーションのデプロイがサポートされています。Oracle HTTP Server 12c (12.2.1.4.0)とApache HTTP Server 2.4.x用のOracle WebLogic Serverプロキシ・プラグイン12c (12.2.1.4.0)では、そのようなWebSocket接続アップグレード・リクエストを処理して、WebLogic Server 12c (12.2.1.4.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 (マルチテナンシ)のフロントエンドになることができます。
ノート:
WebLogic Server Multitenantドメイン・パーティション、リソース・グループ、リソース・グループ・テンプレート、仮想ターゲットおよびリソース消費管理は、WebLogic Server 12.2.1.4.0で非推奨になり、次のリリースで削除されます。この項の内容は次のとおりです。
ノート:
この項では、Oracle WebLogic Serverプロキシ・プラグインに適用する場合に限定して、パーティションとマルチテナンシについて説明します。Oracle WebLogic Server MT、パーティションおよびマルチテナンシの詳細は、『Oracle Fusion Middleware WebLogic Server Multitenantの使用(非推奨)』を参照してください。
パーティションの追加
パーティションをOracle WebLogic Server MT側で追加した場合、新しいパーティションのフロントになるように、対応する変更を必ずWebサーバー構成に加える必要があります。パーティションそのものの追加方法の詳細は、Oracle WebLogic Server MTによって説明されます。
次の項では、Oracle WebLogic Server MTで新規追加したパーティションのフロントエンドになるように、対応する変更をWebサーバー構成に加える方法について説明します。
ノート:
次の項では、Oracle WebLogic Serverに1つ以上のドメイン・パーティションがすでに作成されていることが前提になります。ドメイン・パーティションの作成の詳細は、『Oracle Fusion Middleware WebLogic Server Multitenantの使用(非推奨)』のドメイン・パーティションの構成に関する項を参照してください。
この項には次のトピックが含まれます:
Apache ServerおよびOracle HTTP Serverの構成の変更
次に、新しいパーティションを追加するたびに、Oracle HTTP ServerまたはApacheプラグインの構成ファイル(httpd.conf
)に追加する必要があるサンプル構成を示します。構成によって、パーティションのホスト名とポート、サーバーとそれが属するWebLogicクラスタ、パーティションに構成されるオプションのURIが識別されます。
Oracle HTTP Server/Apacheプラグインの例
次の例では、様々な使用例のサンプル構成を示します。
例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 Multitenantの使用(非推奨)』のパーティションのエクスポートとインポートに関する項を参照してください。
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 Multitenantの使用(非推奨)』のドメイン・パーティションの構成、仮想ターゲットの構成およびパーティションのエクスポートおよびインポートに関する項を参照してください。
Web ServerとOracle WebLogic Serverとの間のSSLの構成
Oracle WebLogic Serverの場合と同様にOracle WebLogic Server MTでSSLを構成しますが、同じホスト名を対象とするパーティションには同じ証明書が必要になります。
クラスタ変更の動的検出
クラスタ変更の動的検出は、Oracle WebLogic Serverプロキシ・プラグインとOracle WebLogic Serverの両方の機能です。マルチテナンシによる影響はありません。この機能は、DynamicServerList
パラメータを使用して制御可能です。「DynamicServerList」を参照してください。