この章の構成は、次のとおりです。
この項では、Oracle Traffic Directorでの問題を診断および解決するために実行できる一連のタスクについて説明します。
システム構成が正しいかどうかを確認します。
サポートされているプラットフォームおよびオペレーティング・システムの詳細は、次にあるOracle Fusion Middlewareのサポートされるシステム構成を参照してください。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
「一般的なエラーの解決方法」で、問題の解決方法を探します。
「よくある質問」に問題についての情報や解決方法が記載されているかどうかを確認します。
問題の診断を実行します。
サーバー・ログに記録されているメッセージを確認します。タイプがWARNING
、ERROR
およびINCIDENT_ERROR
のメッセージを探します。
エラー・メッセージに、タイプがWARNING
およびERROR
のメッセージがある場合、次の指示に従って問題を解決します。
INCIDENT_ERROR
メッセージは、原因不明の重大な問題を示します。Oracleサポートに連絡する必要があります。
サーバー・ログの冗長度を高め、問題の再現を試みます。
「サーバー・ログ・レベル」にあるように、Oracle Traffic Directorではサーバー・ログについて、いくつかのログ・レベルがサポートされています。デフォルトのログ・レベルは、NOTIFICATION:1
です。最小の冗長度ログ・レベルは、INCIDENT_ERROR
で、このレベルでは、重大なエラー・メッセージのみが記録されます。TRACE:1
、TRACE:16
またはTRACE:32
レベルでは、ログはレベルに応じて冗長度が増しますが、より詳細な情報が提供され、問題の診断に活用できます。
ログの冗長度を高め、問題の再現を試みます。問題が再度発生したら、問題の原因を示すメッセージ・ログを確認します。
サーバー・ログ・レベルの変更の詳細は、「ログ・プリファレンスの構成」を参照してください。
「Oracleサポートへの連絡」の説明に従い、Oracleサポートに連絡します。
この項では、Oracle Traffic Directorの高可用性構成に関する問題を診断および解決するためのタスクについて説明します。
Oracle Traffic Director構成が2つのノード上にデプロイされている必要があります。詳細は、「フェイルオーバー・グループの管理」を参照してください。
各フェイルオーバー・グループのルーターIDは一意である必要があります。
KeepAlivedがインストールされていることを確認します。通常、Oracle Traffic Directorインスタンスが実行されているExalogic計算ノード(またはVM)では、両ノードともデフォルトでKeepAlivedソフトウェアがインストールされています。KeepAlivedがインストールされていることを確認するには、次のコマンドを実行します。
rpm -qa | grep keepalived
KeepAlivedが正しくインストールされている場合、次のような出力が表示されます。
keepalived-1.2.2-1.el5
KeepAlivedがインストールされていない場合、RPMはソフトウェア・リポジトリ内にあります。
KeepAlived特有の情報は、/var/log/messages
にあるログで確認できます。
高可用性構成を正常に完了するには、正しいVIPアドレスと適切なサブネット・マスク(ネットマスク)のビットサイズを指定する必要があります。また、実際のネットマスク値ではなく、ネットマスクのビット数を指定する必要があります。詳細は、「フェイルオーバー・グループの作成」を参照してください。
この項では、次の問題の解決策を示します。
このエラーは、構成内の1つ以上のHTTPリスナーが、他のプロセスによってすでに使用中のTCPポート番号に割り当てられている場合に発生します。
[ERROR:32] startup failure: could not bind to port port (Address already in use) [ERROR:32] [OTD-10380] http-listener-1: http://host:port: Error creating socket (Address already in use) [ERROR:32] [OTD-10376] 1 listen sockets could not be created [ERROR:32] server initialization failed
次のコマンドを実行すると、指定のポートでリスニング中のプロセスを検出できます。
> netstat -npl | grep :port | grep LISTEN
構成済のHTTPリスナー・ポートが他のプロセスで使用中の場合は、ポートを解放するか、「リスナーの変更」の説明に従って変更します。
このエラーは、1024
までのHTTPリスナー・ポート(たとえば80
)を構成していて、Oracle Traffic Directorインスタンスを-root
以外のユーザーとして起動しようとした場合に発生します。
次のメッセージがサーバー・ログに書き込まれます。
[ERROR:32] [OTD-10376] 1 listen sockets could not be created [ERROR:32] [OTD-10380] http-listener-1: http://soa.example.com:80: Error creating socket (No access rights)
1024
までのポート番号は、Internet Assigned Numbers Authority (IANA)によって様々なサービスに割り当てられます。これらのポート番号にアクセスできるのは、root
ユーザーのみです。
この問題を解決するには、次のいずれかを行います。
1024
より上のポート番号(たとえば8080
)でOracle Traffic Directorを構成し、ポート80
で受信したリクエストを構成済Oracle Traffic DirectorポートにリダイレクトするIPパケット・フィルタリング・ルールを次のように作成します。
# /sbin/iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080 # /sbin/iptables -t nat -A PREROUTING -p udp -m udp --dport 80 -j REDIRECT --to-ports 8080
次の例に示すように、chkconfig
コマンドを実行し、サーバーの再起動時にiptables
サービスがデフォルトで起動されることを確認します。
# chkconfig --level 35 iptables on
xinetd
がシステム内にインストールされている場合、/etc/xinetd.d/
ディレクトリに次のエントリを含むファイル(たとえばotd
)を作成します。
service otd { type = UNLISTED disable = no socket_type = stream protocol = tcp user = root wait = no port = 80 redirect = 127.0.0.1 8080 }
このエントリにより、ポート80
で受けたすべての受信TCPトラフィックがローカル・マシンのポート8080
にリダイレクトされます。
詳細は、Linux xinetd
ドキュメントを参照してください。
Oracle Traffic Directorインスタンスの起動時、特定のパラメータの値(キープ・アライブ接続の最大数、接続キューのサイズ、オリジン・サーバーへの最大接続数)が、システムのファイル・ディスクリプタ制限に基づき自動的に割り当てられます。
ファイル・ディスクリプタ制限が非常に高い場合、未定義パラメータに自動割り当てされる値は、必要以上に高くなり、その結果、Oracle Traffic Directorで過度なメモリー量が消費されます。この問題を回避するには、キープ・アライブ接続の最大数(「キープ・アライブ設定のチューニング」)、接続キューのサイズ(「スレッド・プールおよび接続キュー設定のチューニング」)および個々のオリジン・サーバーへの最大接続数(「オリジン・サーバーの変更」)を明示的に構成します。
このLinuxのオペレーティング・システム・エラーは、割り当てられたファイル・ディスクリプタ数がシステムの制限に到達すると発生します。
次のメッセージがサーバー・ログに書き込まれます。
[ERROR:16] [OTD-10546] Insufficient file descriptors for optimum configuration.
このエラーを回避するには、Linuxのファイル・ディスクリプタ制限をデフォルトの1024から合理的な数に増やします。詳細は、「ファイル・ディスクリプタ制限のチューニング」を参照してください。
このエラーは、構成の一時ディレクトリを変更した後、インスタンスを停止せずに変更デプロイし、その後インスタンスを停止しようとすると発生します。一時ディレクトリは、構成のインスタンスのプロセスIDおよびソケット情報が格納される(管理ノード上)のディレクトリです。
このエラーが発生すると、次のメッセージがサーバー・ログに書き込まれます。
OTD-63585 An error occurred while stopping the server. For details, see the server log.
このエラーを回避する手順
構成の一時ディレクトリを変更した場合、構成のすべてのインスタンスをまず停止して、変更をデプロイし、次にインスタンスを起動します。
この問題を回避する手順
Oracle Traffic Directorインスタンスを停止します。
次のいずれかを実行して、構成の現在の一時ディレクトリを検出します。
次の例に示すように、otd_getConfigurationProperties
WLSTコマンドを実行します。
props = {} props['configuration'] = 'foo' otd_getConfigurationProperties(props) temp-path=/tmp/net-test-a46e5844 ...
Fusion Middleware Controlにログインし、必要な構成を選択して「詳細設定」を選択します。結果のページで、「一時ディレクトリ」フィールドを探します。
一時ディレクトリへのパスを記録します。
次のコマンドを実行して、実行中のインスタンスのプロセスIDを検出します。
cat temp_dir/pid
temp_dir
は、手順1で記録した一時ディレクトリへのフル・パスです。
このコマンドによって戻されるプロセスIDを記録します。
次のコマンドを実行して、プロセスを停止します。
kill pid
pid
は、手順2で記録したプロセスIDです。
Linuxシステムでは、デフォルトで/etc/cron.daily/tmpwatch
にあるcronスクリプトtmpwatchが毎日実行されるように設定されています。このスクリプトは、管理サーバー上のすべての/tmp
ディレクトリから240時間(10日)経過したファイルをすべて削除します。そのため、管理サーバーを10日間再起動しなかった場合、デフォルトpidファイルが削除されます。これは、10日後に管理サーバーを再起動できなくなることを意味します。
この問題を回避するには
temp-path
の場所を変更する: <otd-home>/admin-server/config/server.xml
ファイルで、temp-path
の値をサーバー・ユーザーが排他的な権限を持つ場所に変更します。たとえば、<temp-path>/var/tmp/https-test-1234</temp-path>
に変更します。加えて、新しいtemp-path
がtmpwatchスクリプトによって監視されないようにします。
cronスクリプトを変更する: cronスクリプトからtmpwatchの値240 /tmp
を削除します。tmpwatchの監視対象からディレクトリを除外するには、-X
/--exclude-pattern
オプションを使用します。このオプションの詳細は、tmpwatchのmanページを参照してください。
Oracle Traffic Directorではセッションの固定性が次のように維持されます。
Cookieベースのセッション持続
これは一般的なシナリオで、クライアントがWebサーバーやアプリケーション・サーバーからのcookieを受け入れる場合です。このシナリオでは、Oracle Traffic DirectorはHTTPトラフィックのロード・バランシングを行う際に、自身のcookieを使用してセッションを持続します。これにより、固定性リクエストつまりHTTPセッションcookieが含まれているリクエストは、そのcookieの生成元であるバックエンド・アプリケーション・サーバーに常にルーティングされます。
Oracle Traffic Director 11. 1.1.5を使用している場合で、バックエンド・アプリケーション・サーバーがデフォルトのJSESSIONID
以外のHTTPセッションcookieを使用している場合は、セッション持続が履行されるようOracle Traffic Directorを明示的に構成する必要があります。一方、Oracle Traffic Director 11.1.1.6の場合は、オリジン・サーバーからcookieを受信した時点でセッション持続が履行されます。
注意:
Oracle Traffic DirectorでURIベースのセッション固定性を維持するには、WebLogic 10.3.xにパッチを追加する必要があります。
URIベースのセッション持続
このシナリオはあまり一般的ではありません。このシナリオではクライアント側でcookieが無効にされているため、バックエンドのWebサーバーまたはアプリケーション・サーバー側でURIにHTTPセッション情報を付加してセッション持続を維持します。
このシナリオでは、バックエンド・アプリケーション・サーバーによってURIにOracle Traffic DirectorのJRoute
cookieが付加される場合に、Oracle Traffic Directorでセッション持続を履行できます。WebLogic Server 10.3.6.2以上、12.1以上、GlassFish 2.0以上などのオリジン・サーバーには、このJRoute
cookieをURIに付加する機能が備わっています。そのため、Oracle Traffic DirectorでURIベースのセッション持続を維持できるのは、これらのオリジン・サーバーを使用している場合に限定されます。
オラクル社とサービス契約を結んでいる場合、Oracle Traffic Directorの問題について、Oracleサポート(http://support.oracle.com
)に問合せできます。
Oracleサポートに連絡する前に
Oracleサポートに連絡する前に、次のことを行ってください:
このドキュメント(Oracle Traffic Director管理者ガイド)に記載されている適切な診断およびトラブルシューティングのガイドラインをすべて試してください。
発生している問題、または類似する問題が、OTNのディスカッション・フォーラム(http://forums.oracle.com/
)ですでに話し合われていないかどうか確認してください。
フォーラムで参照できる情報だけでは問題を解決できない場合は、フォーラムに質問を投稿します。フォーラムの他のOracle Traffic Directorユーザーが質問に答えてくれる場合があります。
可能な限り、問題が発生する前に実行した一連の操作を記述してください。
可能な場合、システムの元の状態をリストアし、記述した手順を使用して問題の再現を試みてください。再現可能な問題か、間欠的に起こる問題かが、これで確認できます。
問題を再現できる場合は、問題を再現する手順の絞込みを行います。小規模なテスト・ケースで再現できる問題は、大規模なテスト・ケースと比較すると一般的に診断が容易です。
問題を再現する手順の絞込みによって、Oracleサポートは可能性のある問題の解決策をより迅速に提供できます。
Oracleサポートに提供する必要がある情報
Oracleサポートに連絡する際には、次の情報を提供してください。
Oracle Traffic Directorのリリース番号。
問題が発生する直前に実行した操作など、問題についての簡単な説明。
管理インタフェースを使用したサポートが必要な場合、ヘルプを必要とするコマンドライン・サブコマンドの名前、または管理コンソール画面のタイトル。
エラーが発生した構成の構成ファイルが含まれるZipファイル。
INSTANCE_HOME/admin-server/config-store/config_name/current.zip
エラーのない構成の構成ファイルが含まれるZipファイル。
INSTANCE_HOME/admin-server/config-store/config_name/backup/date_time.zip
最新のサーバーおよびアクセス・ログ・ファイル。
注意:
Oracleサポートにファイルを送る場合、Oracleサポートの担当者が、問題のトラブルシューティングにファイルを使用する前にその整合性を確認できるように、各ファイルにMD5チェックサム値を指定するようにしてください。