| Oracle® Fusion Middleware Oracle Traffic Directorの管理 12c (12.2.1.3.0) E90199-04 |
|
 前 |
 次 |
この章の構成は、次のとおりです。
この項では、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オプションを使用します。
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ベースのセッション持続を維持できるのは、これらのオリジン・サーバーを使用している場合に限定されます。
この項には次のサブセクションが含まれます:
Fusion Middleware Controlで「インスタンス構成デプロイ済」のメッセージが表示されるのはなぜですか。
プール内のオリジン・サーバーをOracle WebLogic Serverに変更した後、これらは自動検出されませんが、動的検出は有効です。なぜですか。
Oracle Traffic Directorによって送受信されたリクエストおよびレスポンス・ヘッダーを表示するにはどのようにすればよいですか。
SSL/TLSが有効なOracle Traffic Directorインスタンスへのテスト・リクエストの発行はどのように行いますか。
Oracle Traffic DirectorインスタンスとOracle WebLogic Serverオリジン・サーバー間のSSL/TLS通信の詳細の表示はどのように行いますか。
SSL/TLSが有効な特定のオリジン・サーバーは、起動しているにもかかわらず、ヘルス・チェックの後オフラインとマークされるのはなぜですか。
Oracle Traffic Directorはオリジン・サーバーにリクエストを転送する前にクライアントのソースIPアドレスを書き換えますか。
Oracle Traffic Director用語としての構成は、Oracle Traffic Directorインスタンスの実行時の動作を決定する一連の構成可能な要素(メタデータ)を指します。
詳細は、「Oracle Traffic Director用語集」を参照してください。
管理サーバーに自己署名証明書があるため、ブラウザによって警告が表示されます。続行するには、証明書を信頼することを選択する必要があります。
Fusion Middleware ControlまたはWLSTのいずれかを使用して構成を編集すると、構成ストア内のファイルが自動的に更新されます。Oracle Traffic Directorドキュメントに指示されている場合を除き、構成ストア内のファイルを手動で編集しないでください。
構成の変更を有効にするには、「構成の変更のアクティブ化」の説明に従ってインスタンスに対する構成をアクティブにする必要があります。
構成を保存すると、行った変更が管理サーバーの構成ストア内に保存されます。構成のインスタンスに変更を反映するには、「構成の変更のアクティブ化」の説明に従って構成をアクティブにする必要があります。
「デプロイメント保留中」のメッセージは、構成を変更して管理サーバーに保存する際に、Fusion Middleware Controlに表示されます。これは、変更が、構成のインスタンスにはまだコピーされていないことを示します。
必要な構成変更を終えたら、「構成の変更のアクティブ化」の説明に従い、Fusion Middleware Controlで「変更のデプロイ」をクリックするか、activate WLSTコマンドを実行することで、変更をすべてのインスタンスにデプロイできます。
インスタンスの構成ファイルを手動で編集すると、インスタンス構成デプロイ済のメッセージがFusion Middleware Controlに表示されます。これは、1つ以上のインスタンスの構成ファイルが、管理サーバーの構成ストア内に格納されている、対応する構成ファイルと異なっていることを示します。
Fusion Middleware Controlセッションは、30分間非アクティブな状態が続くと自動的に終了します。再度ログインする必要があります。
WLSTは、管理サーバーのSSLポートに接続されます。管理サーバーには、自己署名証明書があります管理サーバーに最初に接続するときに表示されるメッセージは、証明書を信頼するかどうかを選択するためのプロンプトです。正しいサーバーおよびポートに接続されていることを確認し、yを入力して証明書を信頼します。その後のWLSTの起動では、警告メッセージは表示されません。
動的検出が有効な場合、Oracle Traffic Directorは、指定された間隔で、特定のヘッダーを含むHTTPリクエストを送信する必要があり、このヘッダーにより、プール内の指定されたオリジン・サーバーがOracle WebLogic Serverインスタンスであるかどうか、およびサーバーがクラスタに属しているかどうかが判別されます。TCPヘルス・チェック・リクエストに対するレスポンスでは、Oracle WebLogic Serverインスタンスの存在を特定するための十分な情報が提供されません。したがって、動的検出が有効な場合、ヘルス・チェック・プロトコルはHTTPに設定されている必要があります。
動的検出が有効な場合、Oracle Traffic Directorインスタンスが起動すると、構成済のオリジン・サーバーがOracle WebLogic Serverインスタンスであるかどうかが判別されます。
このため、たとえば、当初Oracle GlassFish Serverインスタンスをオリジン・サーバーとして構成していた場合、起動時にOracle Traffic Directorによって、オリジン・サーバーはOracle WebLogic Serverインスタンスではないことが判別されます。その後、オリジン・サーバーをOracle WebLogic Serverインスタンスで置き換え、次にOracle Traffic Directorにオリジン・サーバーが現在Oracle WebLogic Serverインスタンスであることをあらためて認識させるには、Oracle Traffic Directorインスタンスを再起動するか、再構成する必要があります。
再起動せずに、Oracle WebLogic Serverインスタンスから別のサーバーへ変更する、またその逆を実行するには、次の操作を行います。
必要なオリジン・サーバーで新しいオリジン・サーバー・プールを作成し、古いプールを削除します。詳細は、「オリジン・サーバー・プールの管理」を参照してください。
「仮想サーバーのルートの構成」の説明に従い、新しいプールをポイントするように適切なルートを更新します。
「再起動が不要なOracle Traffic Directorインスタンスの更新」の説明に従い、softRestart WLSTコマンドを使用して、Oracle Traffic Directorを再構成します。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、適切なルートを変更し、サーバー・ログへのリクエストおよびレスポンス・ヘッダーの記録を有効にできます。
Fusion Middleware Controlの使用
「グラフィカル・ユーザー・インタフェース - Fusion Middleware Control」の説明に従って、Fusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
ルートを構成する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。
ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを編集する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。選択された仮想サーバーに現在定義されているルートがリストされます。
構成するルートの「名前」をクリックします。
ルート設定ページが表示されます。
ルート設定ページの「詳細設定」セクションに移動し、「オリジン・サーバーとの接続用のクライアント構成」サブセクションにスクロール・ダウンします。
「ログ・ヘッダー」チェック・ボックスを選択します。
「OK」をクリックします。
WLSTの使用
次の例に示すように、otd_setRoutePropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['log-headers'] = 'true'
otd_setRouteProperties(props)
このコマンドにより、構成fooの仮想サーバーbar内のroute-1という名前のルートと関連付けられているオリジン・サーバーとの間でOracle Traffic Directorが送受信するヘッダーのロギングが有効化されます。
次の例に示すように、ヘッダーはサーバー・ログに記録されます。
[2011-11-11T03:45:00.000-08:00] [net-test] [NOTIFICATION] [OTD-11008] [] [pid: 8184] for host 10.177.243.152 trying to OPTIONS / while trying to GET /favicon.ico, service-http reports: request headers sent to origin server(soa.example.com:1900) :[[ OPTIONS / HTTP/1.1 Proxy-agent: Oracle-Traffic-Director/12.2.1.0 Surrogate-capability: otd="Surrogate/1.0" Host: dadvma0178:1900 Proxy-ping: true X-weblogic-force-jvmid: unset Via: 1.1 net-test Connection: keep-aliv e ]] [2011-11-11T03:45:00.000-08:00] [net-test] [NOTIFICATION] [OTD-11009] [] [pid: 8184] for host 10.177.243.152 trying to OPTIONS / while trying to GET /favicon.ico, service-http reports: response headers received from origin server(soa.example.com:1900) :[[ HTTP/1.1 200 OK date: Fri, 11 Nov 2011 11:45:00 GMT server: Apache/2.2.17 (Unix) allow: GET,HEAD,POST,OPTIONS,TRACE content-length: 0 keep-alive: timeout=5, max=100 connection: Keep-Alive content-type: text/html]
次のコマンドを実行します。
$ openssl s_client -host hostname -port portnumber -quiet
-quietオプションを省略すると、SSL/TLS接続についての情報(サーバーDN、証明書名、ネゴシエート済暗号スイート)が表示されます。
特定の暗号でテストするには、-cipherオプションを指定します。
SSL/TLS接続が確立された後、次の例に示すように、HTTPリクエストを入力します。
GET /
詳細は、s_client manページを参照してください。
SSL/TLS接続上のリクエストおよびレスポンスを監視するいくつかのツールを使用できます。ツールの1つの例として、ssltapがありますが、このツールは、クライアントとOracle Traffic Director間のシンプルなプロキシとして機能し、転送される接続に関する情報を表示します。
次のコマンドを実行します。
$ ssltap -l -s otd_host:otd_port
たとえば、クライアントと、SSL/TLSが有効なOracle Traffic Directorリスナーsoa.example.com:1905間の通信を監視するには、次のコマンドを実行します。
$ ssltap -l -s soa.example.com:8080
次のメッセージが表示されます:
Looking up "localhost"... Proxy socket ready and listening
デフォルトでは、ssltapはポート1924をリスニングします。ブラウザを使用して、https://localhost:1924を接続します。
次のような出力が表示されます。
Connection #1 [Tue Oct 25 04:29:46 2011]
Connected to localhost:8080
--> [
(177 bytes of 172)
SSLRecord { [Tue Oct 25 04:29:46 2011]
type = 22 (handshake)
version = { 3,1 }
length = 172 (0xac)
handshake {
type = 1 (client_hello)
length = 168 (0x0000a8)
ClientHelloV3 {
client_version = {3, 1}
random = {...}
session ID = {
length = 0
contents = {...}
}
cipher_suites[29] = {
(0x00ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV
(0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA
(0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
(0x0039) TLS/DHE-RSA/AES256-CBC/SHA
(0x0038) TLS/DHE-DSS/AES256-CBC/SHA
(0xc00f) TLS/ECDH-RSA/AES256-CBC/SHA
(0xc005) TLS/ECDH-ECDSA/AES256-CBC/SHA
(0x0035) TLS/RSA/AES256-CBC/SHA
(0xc007) TLS/ECDHE-ECDSA/RC4-128/SHA
(0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA
(0xc011) TLS/ECDHE-RSA/RC4-128/SHA
(0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA
(0x0033) TLS/DHE-RSA/AES128-CBC/SHA
(0x0032) TLS/DHE-DSS/AES128-CBC/SHA
(0xc00c) TLS/ECDH-RSA/RC4-128/SHA
(0xc00e) TLS/ECDH-RSA/AES128-CBC/SHA
(0xc002) TLS/ECDH-ECDSA/RC4-128/SHA
(0xc004) TLS/ECDH-ECDSA/AES128-CBC/SHA
(0x0004) SSL3/RSA/RC4-128/MD5
(0x0005) SSL3/RSA/RC4-128/SHA
(0x002f) TLS/RSA/AES128-CBC/SHA
(0xc008) TLS/ECDHE-ECDSA/3DES-EDE-CBC/SHA
(0xc012) TLS/ECDHE-RSA/3DES-EDE-CBC/SHA
(0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0xc00d) TLS/ECDH-RSA/3DES-EDE-CBC/SHA
(0xc003) TLS/ECDH-ECDSA/3DES-EDE-CBC/SHA
(0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
}
compression[1] = {
(00) NULL
}
extensions[55] = {
extension type server_name, length [29] = {
0: 00 1b 00 00 18 64 61 64 76 6d 61 30 31 37 38 2e | .....soa.
10: 75 73 2e 6f 72 61 63 6c 65 2e 63 6f 6d | example.com
}
extension type elliptic_curves, length [8] = {
0: 00 06 00 17 00 18 00 19 | ........
}
extension type ec_point_formats, length [2] = {
0: 01 00 | ..
}
extension type session_ticket, length [0]
}
}
}
}
これは、ブラウザからOracle Traffic Directorインスタンスに送信されるSSL/TLSのclient helloです。ブラウザから送信される暗号スイートのリストに注目してください。これは、ブラウザが処理するように構成された暗号スイートであり、プリファレンスの順序でソートされています。サーバーは、ハンドシェイク用の暗号スイートを選択します。クライアントによって指定された暗号スイートのいずれもサーバーに構成されていない場合、接続は失敗します。前述の例では、セッションIDが空ですが、これは指定されたサーバーとのキャッシュ済SSL/TLSセッションがブラウザにないことを示します。
Oracle Traffic Directorインスタンスのレスポンスは、次の出力のようになります。
<-- [
(823 bytes of 818)
SSLRecord { [Tue Oct 25 04:29:46 2011]
type = 22 (handshake)
version = { 3,1 }
length = 818 (0x332)
handshake {
type = 2 (server_hello)
length = 77 (0x00004d)
ServerHello {
server_version = {3, 1}
random = {...}
session ID = {
length = 32
contents = {...}
}
cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA
compression method = (00) NULL
extensions[5] = {
extension type renegotiation_info, length [1] = {
0: 00 | .
}
}
}
type = 11 (certificate)
length = 729 (0x0002d9)
CertificateChain {
chainlength = 726 (0x02d6)
Certificate {
size = 723 (0x02d3)
data = { saved in file 'cert.001' }
}
}
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
--> [
サーバーは、クライアントによって後続のリクエストに含められる暗号スイートTLS/RSA/AES256-CBC/SHAとセッションIDを選択しました。
また、サーバーは、ブラウザが確認するための証明書チェーンも送信しました。ssltapによって証明書がファイルcert.001に保存されました。X.509証明書を解析できる任意のツールを使用して証明書を検査できます。たとえば、次のようなコマンドを実行します。
$ openssl x509 -in cert.001 -text -inform DER
注意:
ssltapは、シングル・スレッドのプロキシ・サーバーです。したがって、これを使用して複数のリクエストを発行すると、リクエストはシリアライズされます。SSL/TLSを使用した同時リクエストでのみ発生する、アプリケーションの特定の問題を分析する必要がある場合、複数のssltapインスタンスを実行してください。
サーバーの起動スクリプトに-Dssl.debug=trueシステム・プロパティを追加することで、Oracle WebLogic ServerインスタンスのSSLデバッグを構成します。詳細は、Oracle Fusion Middleware Oracle WebLogic Serverの保護のSSLのデバッグを参照してください。
「ログ・プリファレンスの構成」の説明に従い、ログ・レベルをTRACE:32に設定し、Oracle Traffic Directorサーバー・ログの冗長度を高めてください。
このエラーは、次のオリジン・サーバーで発生する可能性があります。
ホスト名ではなくIPアドレスを使用して、オリジン・サーバー・プールに構成されているSSL/TLSが有効なオリジン・サーバー。
動的に検出された、SSL/TLSが有効なOracle WebLogic Serverオリジン・サーバー。Oracle Traffic Directorは、ホスト名ではなくIPアドレスを使用してこのサーバーを参照します。
Oracle Traffic Directorは、IPアドレスを使用してこのようなオリジン・サーバーを参照しますが、オリジン・サーバーの証明書には、サーバーのホスト名が含まれています。したがって、ヘルス・チェック・リクエストに対して、オリジン・サーバーが証明書を提示すると、Oracle Traffic Directorはそれらの検証を試みますが成功しません。SSL/TLSハンドシェイクが失敗します。結果として、ヘルス・チェックでは、このようなオリジン・サーバーはオフラインと示されます。サーバー証明書の検証は、デフォルトで有効化されていることに注意してください。
サーバー・ログ・レベルをTRACE:32に設定すると、この障害について記録された、次の例に示すようなメッセージを表示できます。
[2011-11-21T09:50:54-08:00] [net-soa] [TRACE:1] [OTD-10969] [] [pid: 22466] trying to OPTIONS /, service-http reports: error sending request (SSL_ERROR_BAD_CERT_DOMAIN: Requested domain name does not match the server's certificate.)
この問題を解決するには、次の例に示すように、otd_setOriginServerPoolSslProperties WLSTコマンドを実行し、オリジン・サーバーのオリジン・サーバー証明書の検証を無効にします。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['validate-server-cert'] = 'false'
otd_setOriginServerPoolSslProperties(props)
詳細は、Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンスのotd_setOriginServerPoolSslPropertiesコマンドを参照してください。
Oracle Traffic DirectorはデフォルトでソースIPアドレスを書き換えます。それでも、クライアントIPアドレスはProxy-client-ipという追加のリクエスト・ヘッダーで送信されます。「仮想サーバーのルートの構成」の説明に従って適切なルートを構成することで、Proxy-client-ipやその他のリクエスト・ヘッダーをブロックしたり転送したりするようにOracle Traffic Directorを設定できます。
HTTPリクエスト・ヘッダーをオリジン・サーバーに転送する際、Oracle Traffic Directorは大文字小文字の区別を維持できません。
HTTPリクエストが定義済ルートに指定されている条件に一致せず、構成にデフォルト(=unconditional)のルートが含まれていない場合、Oracle Traffic Directorから405ステータス・コードが返されます。このエラーはOracle Traffic Directorがリクエストの適切なルートを見つけられなかったことを意味しています。この状況は、obj.conf構成ファイル内でデフォルト・ルート(リクエストが他のどのルートの指定条件にも一致しなかった場合に使用されるルート)が手動で削除された場合にのみ発生する可能性があります。この問題を解決するには、管理者が適切なルートを作成する必要があります。
注意:
デフォルトのルート(=unconditional)は、Fusion Middleware ControlやWLSTでは削除できず、また、手動では削除しないでください。
オラクル社とサービス契約を結んでいる場合、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チェックサム値を指定するようにしてください。
