1. Oracle WebLogic Serverプロキシ・プラグインの使用
  2. Oracle WebLogic Serverプロキシ・プラグインのトラブルシューティングとチューニング

6 Oracle WebLogic Serverプロキシ・プラグインのトラブルシューティングとチューニング

WLSプロキシ・プラグインの使用時に問題が発生することがあります。これらの問題の解決方法について説明します。

この章の内容は次のとおりです。

  • WebSocketアップグレード・リクエストのスループットを高めるためのOracle HTTP Serverのチューニング
    Oracle WebLogic Server 14c (14.1.2.0.0)では、WebSocketアプリケーションのデプロイがサポートされます。14.1.2.0.0 WLS OHSプラグインでは、WebSocket接続アップグレード・リクエストなどを処理し、Oracle WebLogic Server 14c (14.1.1.0.0)以降でホストされているWebSocketアプリケーションに効果的にプロキシできます。
  • 接続エラーとクラスタリング・フェイルオーバーの理解
    プロキシ・プラグインがOracle WebLogic Serverへの接続を試行すると、プロキシ・プラグインは複数の構成パラメータを使用して、Oracle WebLogic Serverホストへの接続を待機する時間、および接続が確立された後、プロキシ・プラグインがレスポンスを待機する時間を決定します。
  • Oracle WebLogic Serverのセッションの問題
    WLSプロキシ・プラグインは、リクエストをバックエンドのOracle WebLogic Serverまたはクラスタにルーティングします。Oracle WebLogic Serverでは、同一クライアントからの後続リクエストが同一サーバーにルーティングされるようにセッションを維持します。
  • NO_RESOURCESエラー
    場合によっては、負荷の高い状況下でいくつかのリクエストが失敗し、エラー・ログ・ファイルにエラーが記録されることがあります。
  • POSTデータ・ファイルの問題
    /tmp/_wl_proxyは固定ディレクトリで、HTTPサーバーのユーザーが所有します。異なるユーザーによって複数のHTTPサーバーがインストールされている場合は、一部のHTTPサーバーがこのディレクトリに書き込めない場合があります。このような状況では、エラーが発生します。

WebSocketアップグレード・リクエストのスループットを高めるためのOracle HTTP Serverのチューニング

Oracle WebLogic Server 14c (14.1.2.0.0)では、WebSocketアプリケーションのデプロイがサポートされます。14.1.2.0.0 WLS OHSプラグインでは、WebSocket接続アップグレード・リクエストなどを処理し、Oracle WebLogic Server 14c (14.1.1.0.0)以降でホストされているWebSocketアプリケーションに効果的にプロキシできます。

このサポートが追加されたことで、新しい構成パラメータであるWLMaxWebSocketClientsが導入されています。

WLMaxWebSocketClientsパラメータは、任意の時点でのアクティブなWebSocket接続の数を制限します。このパラメータに設定できる最大値は、ThreadsPerChildの75% (Windowsの場合)またはMaxRequestWorkersの75% (Windows以外の場合)となります。したがって、WebSocket接続アップグレード・リクエストが最大になるようにHTTPサーバーをチューニングするには、MaxRequestWorkers/ThreadsPerChildをWebSocket接続も考慮した値に設定します。また、WLMaxWebSocketClientsがMaxRequestWorkers/ThreadsPerChildの75%に設定されていることを確認します。

親トピック: Oracle WebLogic Serverプロキシ・プラグインのトラブルシューティングとチューニング

接続エラーとクラスタリング・フェイルオーバーの理解

プロキシ・プラグインがOracle WebLogic Serverへの接続を試行すると、プロキシ・プラグインは複数の構成パラメータを使用して、Oracle WebLogic Serverホストへの接続を待機する時間、および接続が確立された後、プロキシ・プラグインがレスポンスを待機する時間を決定します。

プロキシ・プラグインが接続できない場合、またはレスポンスを受信しない場合、プロキシ・プラグインは、クラスタ内の他のOracle WebLogic Serverインスタンスに接続してリクエストを送信しようとします。接続が失敗した場合、またはクラスタ内のどのOracle WebLogic Serverからもレスポンスがない場合、エラー・メッセージが送信されます。プロキシ・プラグインによるフェイルオーバーの処理方法の図については、図6-1を参照してください。

この項には次のトピックが含まれます:

親トピック: Oracle WebLogic Serverプロキシ・プラグインのトラブルシューティングとチューニング

接続障害についての考えられる原因

Oracle WebLogic Serverホストが接続リクエストに応答しない場合、次のような問題がある可能性があります:

  • ホスト・マシンの物理的な問題(電源停止、ハードウェアの故障、オペレーティング・システムのクラッシュなど)。
  • ネットワークの問題。
  • その他のサーバー障害。

Oracle WebLogic Serverインスタンスが応答しない場合、次のような問題がある可能性があります:

  • Oracle WebLogic Serverが実行されていないか、使用できません。
  • サーバーのハング。
  • データベースの問題。
  • アプリケーション固有の障害。

親トピック: 接続エラーとクラスタリング・フェイルオーバーの理解

CONNECTION_REFUSEDエラーを減らすためのヒント

負荷がかかると、プロキシ・プラグインはバックエンドのOracle WebLogic ServerインスタンスからCONNECTION_REFUSEDエラーを受け取ることがあります。たとえば、次のエラーがログ・ファイルに記録されます:

weblogic: Trying GET /uri at backend host 'xx.xx.xx.xx/port; got exception 'CONNECTION_REFUSED [os error=xxx, line xxxx of URL.cpp]: apr_socket_connect call failed with error=xxx, host=xx.xx.xx.xx, port=xxxx'

Oracle WebLogic Serverのバックログ接続が、最大許容数に達した可能性があります。CONNECTION_REFUSEDエラーを減らすには、チューニングに関する次のヒントに従ってください。

  • Oracle WebLogic Serverドメインの構成でAcceptBackLog設定を増やします。
  • 待機時間を短くします。この設定は、使用するオペレーティング・システムに応じて異なります。たとえば、Linuxでは、/etc/sysctl.confファイルでnet.ipv4.tcp_fin_timeoutパラメータを低い値に設定します。
  • マシン上でオープン・ファイル・ディスクリプタの制限値を大きくします。この制限は、オペレーティング・システムによって異なります。limit (.csh)またはulimit (.sh)ディレクティブを使用して、制限値を大きくするスクリプトを作成できます。

親トピック: 接続エラーとクラスタリング・フェイルオーバーの理解

クラスタ化されていない単一のOracle WebLogic Serverでのフェイルオーバー

単一のOracle WebLogic Serverインスタンスのみを実行する場合、プロキシ・プラグインはWebLogicHostパラメータで定義されたサーバーへの接続のみを試行します。失敗すると、HTTP 503エラー・メッセージが返されます。プロキシ・プラグインは、ConnectTimeoutSecsとConnectRetrySecsの比率で指定されている最大再試行回数まで、同じOracle WebLogic Serverインスタンスへの接続を試行し続けます。

親トピック: 接続エラーとクラスタリング・フェイルオーバーの理解

動的サーバー・リスト

WebLogicClusterパラメータは、クラスタ化されたバックエンド・サーバーのリストにプロキシしたり、クラスタ化されていない管理対象サーバー・インスタンスのロード・バランシングを実行するために必要となります。

クラスタ化された管理対象サーバーへのプロキシの場合、WebLogicClusterパラメータを使用してOracle WebLogic Serverのリストを指定すると、プロキシ・プラグインはそのリストをクラスタのメンバー間のロード・バランシングの開始点として使用します。最初のリクエストがそれらのサーバーの1つにルーティングされた後、クラスタ内のサーバーの更新されたリストを含む動的サーバー・リストが返されます。

更新されたリストでは、クラスタ内の新しいサーバーが追加され、停止されたサーバー、一時停止されたサーバー、クラスタ・メンバーではなくなったサーバーおよびリクエストに応答しなかったサーバーは削除されます。この機能は、DynamicServerListを使用して制御可能です。たとえば、この機能を無効にするには、DynamicServerListをOFFに設定します。

DynamicServerList ONは、推奨されるパフォーマンス・チューニング・パラメータです。クラスタのメンバーが保守のために一時的に停止されている場合や、管理者が別のメンバーを追加することを決定し、Webサーバーの再起動が必要ない場合などに役立ちます。

ノート:

DynamicServerListがONに設定されており、WebLogicClusterで指定されたバックエンドOracle WebLogic Serverのリストがクラスタ内にない場合、動作は未定義になります。

親トピック: 接続エラーとクラスタリング・フェイルオーバーの理解

フェイルオーバー、CookieおよびHTTPセッション

リクエストに、CookieやPOSTデータに格納されているかURLでエンコードされたセッション情報が含まれている場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼ばれる)への参照が含まれています。Cookieが含まれるリクエストは、プライマリ・サーバーへの接続を試みます。その試行が失敗した場合、プロキシ・プラグインはリスト内の次に使用可能なサーバーへの接続をラウンドロビン方式で試行します。そのサーバーが元のセカンダリ・サーバーからセッションを取得し、そのサーバー自体が同一セッションの新しいプライマリ・サーバーになります。図6-1を参照してください。

ノート:

POSTデータが64Kより大きい場合、プロキシ・プラグインはPOSTデータを解析してセッションIDを取得しません。したがって、セッションIDをPOSTデータに格納すると、プロキシ・プラグインはリクエストを正しいプライマリまたはセカンダリ・サーバーにルーティングできないため、セッションデータが失われる可能性があります。

図6-1 接続のフェイルオーバー

図6-1の説明が続きます
「図6-1 接続のフェイルオーバー」の説明

この図の赤色のループに許容されている最大試行回数はConnectTimeoutSecs/ConnectRetrySecsの値と等しくなります。

親トピック: 接続エラーとクラスタリング・フェイルオーバーの理解

ファイアウォールとロード・ディレクタを使用する場合のフェイルオーバー動作

ファイアウォールとロード・ディレクタを組み合せて使用する一部の構成では、Oracle WebLogic Serverのプライマリ・インスタンスが使用できない場合、いずれか1つのサーバー(ファイアウォールまたはロード・ディレクタ)がリクエストを受け入れ、正常な接続を返します。Oracle WebLogic Serverのプライマリ・インスタンス(使用不可)へのリクエストの送信が試行された後、リクエストは「接続リセット」としてプロキシ・プラグインに戻されます。

ファイアウォールの組合せ(ロード・ダイレクタの有無にかかわらず)を介して実行されるリクエストは、Oracle WebLogic Serverによって処理されます。つまり、接続リセットのレスポンスはOracle WebLogic Serverのセカンダリ・インスタンスにフェイルオーバーします。このような構成では、接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変である必要があります。そうでない場合は、トランザクションの処理が重複する可能性があります。

親トピック: 接続エラーとクラスタリング・フェイルオーバーの理解

Oracle WebLogic Serverのセッションの問題

WLSプロキシ・プラグインは、リクエストをバックエンドのOracle WebLogic Serverまたはクラスタにルーティングします。Oracle WebLogic Serverでは、同一クライアントからの後続リクエストが同一サーバーにルーティングされるようにセッションを維持します。ただし、様々な理由で、WLSプロキシ・プラグインがOracle WebLogic Serverサーバーと通信できない場合、リクエストは次のように処理されます:
  • リクエストが単一のOracle WebLogic Serverインスタンスにルーティングされる場合、WLSプロキシ・プラグインは、ConnectTimeoutSecsとConnectRetrySecsの比率で指定されている最大再試行回数まで、同じOracle WebLogic Serverインスタンスへの接続を試行し続けます。すべての試みが失敗すると、クライアントにHTTP 503エラー・メッセージが返されます。
  • リクエストがWebLogicクラスタにルーティングされる場合、現在のOracle WebLogic Serverが不良とマークされ、リクエストは次の使用可能なOracle WebLogic Serverにルーティングされます。すべての試みが失敗すると、クライアントにHTTP 503エラー・メッセージが返されます。

HTTP 503エラー・メッセージが送信されるほか、レスポンスとしてHTTPクライアントで次のメッセージが表示されます。

Failure of Web Server bridge:
No backend server available for connection: timed out after xx seconds or idempotent set to OFF or method not idempotent.

親トピック: Oracle WebLogic Serverプロキシ・プラグインのトラブルシューティングとチューニング

NO_RESOURCESエラー

場合によっては、負荷の高い状況下でいくつかのリクエストが失敗し、エラー・ログ・ファイルにエラーが記録されることがあります。

次のエラーがログ・ファイルに記録されます:

weblogic: *******Exception type [NO_RESOURCES] (apr_socket_connect call failed with error=70007, host=xx.xx.xx.xx, port=xxxx) raised at line xxxx of URL.cpp

これは通常、Oracle WebLogic Serverがビジー状態でWLSプロキシ・プラグインからの接続リクエストに応答できない場合に発生します。WLSocketTimeoutSecsの値を大きくすることで解決される場合があります。これにより、WLSプロキシ・プラグインが、接続リクエストに対するOracle WebLogic Serverのレスポンスを待機する時間が長くなります。

親トピック: Oracle WebLogic Serverプロキシ・プラグインのトラブルシューティングとチューニング

POSTデータ・ファイルの問題

UNIXの場合、一時POSTファイルは/tmp/_wl_proxyの下にあります。Windowsの場合は、次の場所にあります(WLTempDirを指定していない場合)。
  • 環境変数TMP
  • 環境変数TEMP
  • C:\Temp
/tmp/_wl_proxyは固定ディレクトリで、HTTPサーバーのユーザーが所有します。異なるユーザーによって複数のHTTPサーバーがインストールされている場合は、一部のHTTPサーバーがこのディレクトリに書き込めない場合があります。このような状況では、エラーが発生します。

この問題を解決するには、WLTempDirパラメータを使用して、POSTデータ・ファイル用の_wl_proxyディレクトリに別の場所を指定します。

親トピック: Oracle WebLogic Serverプロキシ・プラグインのトラブルシューティングとチューニング