| Oracle® Fusion Middleware Oracle Traffic Directorの管理 12c (12.2.1.3.0) E90199-04 |
|
 前 |
 次 |
オリジン・サーバー・プールを構成内に定義し、特定のプールにクライアント・リクエストをルーティングするようにOracle Traffic Directorインスタンス内に各仮想サーバーを構成できます。
オリジン・サーバーは、バックエンドのサーバーであり、Oracle Traffic Directorはクライアントから受信したリクエストをこのサーバーに転送し、クライアント・リクエストに対するレスポンスをこのサーバーから受信します。たとえば、オリジン・サーバーには、Oracle WebLogic ServerインスタンスまたはOracle iPlanet Web Serverインスタンスなどが該当します。同じサービスを提供する、または同じコンテンツを提供するオリジン・サーバーのグループは、オリジン・サーバー・プールと呼ばれます。
この章では、このようなオリジン・サーバー・プールを作成および管理する方法を説明します。内容は次のとおりです。
オリジン・サーバー・プールを構成内に定義し、特定のプールにクライアント・リクエストをルーティングするようにOracle Traffic Directorインスタンス内に各仮想サーバーを構成できます。
始める前に
オリジン・サーバー・プールの作成を開始する前に、次の項目を決定します。
オリジン・サーバー・プールの一意の名前。オリジン・サーバー・プールを作成した後は名前を変更できないため、名前は慎重に選択してください。
オリジン・サーバー・プール内のサーバーのhost:portの組合せ。
注意:
プールを作成するオリジン・サーバーが、クラスタ内のOracle WebLogic Server管理対象サーバーの場合、管理対象サーバーのいずれか1つをオリジン・サーバーとして使用してプールを作成すれば十分です。その後、プール内のその他の管理対象サーバーを動的に検出するようにOracle Traffic Directorを構成することができます。「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。
プール内のサーバーの通信プロトコル(HTTP、HTTPSまたはTCP)。
オリジン・サーバー・プール内のサーバーがリクエストのリスニングに使用するアドレス・ファミリ。
サポートされているアドレス・ファミリは次のとおりです。
inet (IPv4)
inet6 (IPv6)
inet-sdp (ソケット・ダイレクト・プロトコル): オリジン・サーバー・プール内のサーバーがインフィニバンド・ファブリック上にあり、SDPインタフェースでリスニングしている場合(Oracle ExalogicマシンにデプロイされているOracle WebLogic Serverなど)、このファミリを選択します。
注意:
オリジン・サーバー・プールを作成すると、実質的には構成が変更されます。新しいオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。内容
次のトピックの説明に従い、Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールを作成できます。
Fusion Middleware Controlを使用してオリジン・サーバー・プールを作成するには、次を実行します。
オリジン・サーバー・プールを作成するには、otd_createOriginServerPoolコマンドを実行します。
たとえば、次のコマンドは、構成foo内にオリジン・サーバーwww.example.com:12345を含むオリジン・サーバー・プールorigin-server-pool-1を作成します。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['origin-server'] = 'www.example.com:12345'
otd_createOriginServerPool(props)
HTTP転送プロキシ・サーバーの指定
otd_createOriginServerPoolコマンドはオプションとしてproxy-serverを受け取り、このオプションは、プールのメンバーであるすべてのオリジン・サーバーが構成済転送プロキシ・サーバーを介して通信するように、オリジン・サーバー・プールに関連付けるHTTP転送プロキシ・サーバーの指定に使用できます。タイプは、httpまたはhttpsである必要があります。
次に例を示します。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['origin-server'] = 'www.example.com:12345'
props['type'] = 'http'
props['proxy-server'] = 'proxy.example.com:12345'
otd_createOriginServerPool(props)
構成にオリジン・サーバー・プールを作成した後、オリジン・サーバー・プールに関連付けられたOracle Traffic Directorインスタンスのリストを表示できます。オリジン・サーバー・プールのリストを表示するには、otd_listOriginServerPoolコマンドを実行します。
次のトピックの説明に従い、Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールのリストを表示できます。
Fusion Middleware Controlを使用してオリジン・サーバー・プールのリストを表示するには、次を実行します。
オリジン・サーバー・プールのリストを表示するには、次の例に示すように、otd_listOriginServerPoolsコマンドを実行します。
props = {}
props['configuration'] = 'foo'
otd_listOriginServerPools(props)
otd_getOriginServerPoolPropertiesおよびotd_getHealthCheckPropertiesコマンドのそれぞれを実行して、オリジン・サーバー・プールの一般的なプロパティおよびヘルス・チェック設定を表示できます。
オリジン・サーバー・プールを作成した後、設定の一部(ネットワーク・プロトコル、プロキシ・サーバー、ロード・バランシング・メソッドなど)を変更する必要がある場合があります。
内容
次のトピックの説明に従い、Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成を変更できます。
注意:
オリジン・サーバー・プールを変更すると、実質的には構成が変更されます。更新されたオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。
Fusion Middleware Controlを使用してオリジン・サーバー・プールのプロパティを変更するには、次を実行します。
オリジン・サーバー・プールのネットワーク・プロトコルおよびロード・バランシング・メソッドを変更するには、otd_setOriginServerPoolPropertiesコマンドを実行します。
たとえば、次のコマンドを実行すると、構成fooのオリジン・サーバー・プールorigin-server-pool-1のロード・バランシング・メソッドが最小接続件数メソッドに変更されます。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['load-distribution'] = 'least-connection-count'
otd_setOriginServerPoolProperties(props)
オリジン・サーバー・プールのヘルス・チェック・パラメータを変更するには、otd_setHealthCheckPropertiesコマンドを実行します。
たとえば、次のコマンドは、構成fooのオリジン・サーバー・プールorigin-server-pool-1内のサーバーのレスポンス本文のサイズを4096バイトに変更します。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['response-body-match-size'] = '4096'
otd_setHealthCheckProperties(props)
不要になったオリジン・サーバー・プールを削除できます。構成のオリジン・サーバー・プール・インスタンスを削除するには、otd_deleteOriginServerPoolコマンドを実行します。
注意:
仮想サーバーの1つ以上のルートに関連付けられているオリジン・サーバー・プールは削除できません。
ルートに関連付けられているオリジン・サーバー・プールを削除するには、「ルートの構成」の説明に従い、そのルートをまず削除する必要があります。
オリジン・サーバー・プールを作成すると、実質的には構成が削除されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。
内容
次のトピックの説明に従い、Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールを削除できます。Oracle Traffic Directorを、クラスタ内のその他のOracle WebLogic Serverインスタンスの存在を動的に検出し、オリジン・サーバーとして構成されている管理対象サーバー、および同じクラスタ内の動的に検出された管理対象サーバーにクライアント・リクエストを分散するように構成できます。
Oracle WebLogic Server管理対象サーバーのクラスタを表すオリジン・サーバー・プールを作成する場合、クラスタ内の各管理対象サーバーをオリジン・サーバーとして指定する必要はありません。管理対象サーバーのいずれかを、プール内の1つのオリジン・サーバーとして指定するだけで十分です。
動的検出が有効な場合、クラスタ内の管理対象サーバーのいずれかが停止、追加または削除されたとき、オリジン・サーバー・プールの定義を更新する必要はありません。ただし、Oracle WebLogic Serverクラスタ内の変更を検出するために、Oracle Traffic Directorは、指定された間隔でヘルス・チェック・リクエストを送信するため、多少のオーバーヘッドが発生します。
注意:
Oracle Traffic Directorは、WebLogic Serverプラグインで提供される一部の一般機能をビルトイン機能によってサポートします。そのため、WebLogic Serverとの相互運用性を実現するためにOracle Traffic Directorにプラグインを追加する必要はありません。
オリジン・サーバー・プールの動的検出が有効な場合、Oracle Traffic Directorは次に示すように、クラスタ内の残りのOracle WebLogic Server管理対象サーバーを検出します。
Oracle Traffic Directorインスタンスは起動時に、プール内で指定済のオリジン・サーバーがOracle WebLogic Server管理対象サーバーであるかどうか、およびサーバーがクラスタに属しているかどうかを、各構成済オリジン・サーバーにHTTPヘルス・チェック・リクエストを送信することでチェックします。
オリジン・サーバーのレスポンスにより、サーバーがOracle WebLogic Server管理対象サーバーであるかどうかが示されます。オリジン・サーバーが、クラスタに属するOracle WebLogic Server管理対象サーバーである場合、レスポンスには、クラスタ内の管理対象サーバーのリストが含まれます。
Oracle Traffic Directorは、オリジン・サーバーからのレスポンス内の情報を使用して、検出された管理対象サーバーの構成を更新します。
動的に検出されたオリジン・サーバーでは、構成済オリジン・サーバーに指定されたすべてのプロパティ(重み、最大接続数など)が継承されます。
続いて、オリジン・サーバー・プールに構成された各ヘルス・チェック間隔(デフォルト: 30秒)で、Oracle Traffic Directorは、プール内でオリジン・サーバーとして構成されているOracle WebLogic Serverインスタンスに動的検出ヘルス・チェック・リクエストを送信し、変更の検出を試みます。
レスポンスに、前回のヘルス・チェック後クラスタ内に変更(管理対象サーバーの削除または追加)があることが示されている場合、Oracle Traffic Directorにより、動的に検出されたオリジン・サーバーの新しいセットで構成が更新されます。
注意:
動的に検出されたオリジン・サーバーは、インスタンス構成のオリジン・サーバー・プール定義に永久的に格納されません。したがって、Oracle Traffic Directorインスタンスを再起動すると、動的検出のプロセスは再び最初から開始されます。
Oracle Traffic Directorが動的検出のために送信するHTTPリクエスト・タイプは、オリジン・サーバー・プールに現在構成されているヘルス・チェック・リクエスト・タイプ(OPTIONS(デフォルト)またはGET)です。「オリジン・サーバー・プールのヘルス・チェック設定の構成」を参照してください。
オリジン・サーバー・プールの作成時、クラスタ内のOracle WebLogic Server管理対象サーバーの動的検出は、デフォルトでは有効化されません。Fusion Middleware ControlまたはWLSTのいずれかを使用して、動的検出を有効にできます。
注意:
オリジン・サーバー・プールを変更すると、実質的には構成が変更されます。更新されたオリジン・サーバー・プールの設定をOracle Traffic Directorインスタンスに反映するには、「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。
Fusion Middleware Controlを使用した動的検出の有効化
Fusion Middleware Controlを使用してクラスタ内のWebLogic Server管理対象サーバーの動的検出を有効にするには、次を実行します。
WLSTを使用した動的検出の有効化
クラスタ内のOracle WebLogic Server管理対象サーバーの動的検出を有効にするには、otd_setHealthCheckPropertiesコマンドを実行します。
たとえば、次のコマンドでは、origin-server-pool-1オリジン・サーバー・プールであるWebLogic Serverクラスタの管理対象サーバーの動的検出が有効になります。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['dynamic-server-discovery'] = '4096'
otd_setHealthCheckProperties(props)
注意:
TCPが現在のヘルス・チェック・プロトコルの場合、動的検出を有効化するために、プロトコルをHTTPに変更する必要があることを示すエラー・メッセージが表示されます。
バックエンド・サーバーのメンテナンスが必要な場合に、カスタム・レスポンス・コードおよびHTMLページを提供するようにOracle Traffic Directorのカスタム・メンテナンス・ページを構成できます。
オリジン・サーバー・プールのメンテナンスが有効化されている場合、次のようになります。
response-codeとresponse-fileの両方が構成されていない場合、Oracle Traffic Directorへのすべてのリクエストは503レスポンス・コードで中断されます。
response-codeのみが構成されている場合、Oracle Traffic Directorへのすべてのリクエストはresponse-codeの値をレスポンス・コードとして中断されます。
両方が指定されている場合、Oracle Traffic Directorへのすべてのリクエストは中断されず、response-fileコンテンツおよびresponse-codeの値をレスポンス・コードとして応答されます。
そのオリジン・サーバーのヘルス・チェックは無効になります。
オリジン・サーバー・プールのメンテナンスが無効だが、オリジン・サーバーが構成されていなく、有効にもなっていない場合、次のようになります。
Oracle Traffic Directorへのすべてのリクエストは503レスポンス・コードで中断されます。
そのオリジン・サーバーのヘルス・チェックは無効になります。
メンテナンスでのオリジン・サーバー・プールの統計の監視
オリジン・サーバー・プールがメンテナンス状態の場合、オリジン・サーバー・プールおよびオリジン・サーバーの統計はありません。統計はアクティブ・オリジン・サーバー・プールおよびアクティブ・オリジン・サーバーに対してのみ有効になります。
WLSTを使用したオリジン・サーバー・プールのメンテナンスの有効化または無効化
オリジン・サーバー・プールのメンテナンスを有効にするには、otd_enableOriginServerPoolMaintenanceコマンドを実行します。
たとえば、次のコマンドはorigin-server-pool-1オリジン・サーバー・プールのメンテナンスを有効にし、503のレスポンス・コードを指定します。このコマンドはresponse-codeとresponse-fileをオプションのプロパティとして使用します。200のresponse-codeはresponse-fileなしでは指定できません。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['response-code'] = '503'
otd_enableOriginServerPoolMaintenance(props)
メンテナンスを無効にするには、otd_disableOriginServerPoolMaintenanceコマンドを使用します。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_disableOriginServerPoolMaintenance(props)
オリジン・サーバー・プールのenabled、response-fileおよびresponse-codeプロパティを取得するには、otd_getOriginServerPoolMaintenancePropertiesコマンドを使用します。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_getOriginServerPoolMaintenanceProperties(props)
リクエストを受信できる使用可能なオリジン・サーバーにのみリクエストが分散されるように、Oracle Traffic Directorはヘルス・チェック・リクエストをプール内のすべてのオリジン・サーバーに送信することでオリジン・サーバーの可用性および状態を監視します。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールのヘルス・チェック・パラメータを構成できます。
注意:
オリジン・サーバー・プールのヘルス・チェック設定を構成すると、実質的には構成が変更されます。更新された構成をOracle Traffic Directorインスタンスに反映するには、「構成の変更のアクティブ化」の説明に従って構成を再デプロイする必要があります。
Oracle Traffic Directorがヘルス・チェック・リクエストを送信するタイミング
Oracle Traffic Directorインスタンスの起動時に、構成済のすべてのオリジン・サーバー・プール内のすべてのオリジン・サーバーに対して初期ヘルス・チェックが実行されます。
初期ヘルス・チェックでオリジン・サーバーの状態が正常であると判明すると、次の状況の場合のみOracle Traffic Directorはさらにヘルス・チェック・リクエストをオリジン・サーバーに送信します。
前回のヘルス・チェック間隔全体を通して、サーバーによってリクエストが正常に処理されませんでした。
動的検出が、このオリジン・サーバー・プールで有効に設定されています。「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。
ヘルス・チェック(初期または後続のチェックのいずれか)でオリジン・サーバーが使用不可であることが判明した場合、Oracle Traffic Directorは、指定されたヘルス・チェック間隔でヘルス・チェックを繰り返します。
構成可能なヘルス・チェック設定
表7-1は、構成内の各オリジン・サーバー・プールについて構成できるヘルス・チェック設定を示しています。
表7-1 ヘルス・チェック・パラメータ
| パラメータ | デフォルト値 |
|---|---|
Oracle Traffic Directorが、オリジン・サーバーの状態を判別するために使用するオリジン・サーバーとの接続のタイプ(HTTPまたはTCP)。
|
HTTP |
ヘルス・チェック・リクエストが送信される頻度。 |
30秒 |
オリジン・サーバーからレスポンスが返されなかった場合、ヘルス・チェック・リクエストがタイムアウトとなるまでの時間。 |
5秒 |
Oracle Traffic Directorがプール内のオリジン・サーバーに接続を試行する場合に、接続不可と判断されるまでの試行回数。 |
5 |
送信する必要のあるHTTPリクエスト・メソッド(GETまたはOPTIONS)。 |
オプション |
HTTPリクエストに送信されるURI。 |
/ |
正常なオリジン・サーバーのインジケータとしてOracle Traffic Directorが受け入れられるHTTPレスポンス・コード。 デフォルトでは、Oracle Traffic Directorは、正常なオリジン・サーバーのインジケータとして |
|
HTTP GETヘルス・チェック・リクエストの場合、正常なオリジン・サーバーのインジケータとしてOracle Traffic Directorが受け入れられるスポンス本文の正規表現。 |
|
HTTP GETヘルス・チェック・リクエストの場合、Oracle Traffic Directorが、レスポンス本文を指定済の受入れ可能なレスポンス本文と比較するときに考慮する、レスポンス本文の最大バイト数。 |
2048 |
オリジン・サーバーが使用可能で正常と見なされる条件
構成されたヘルス・チェック接続タイプがTCPである場合、接続が正常に確立され、サーバーがそのサービス・ポートをアクティブにリスニングしていると、オリジン・サーバーは使用可能と見なされます。
構成されたヘルス・チェック接続タイプがHTTPである場合、次の条件がすべて満たされた場合、オリジン・サーバーは使用可能と見なされます。
HTTPリクエストの送信中にエラーが発生していません。
タイムアウト時間に達する前にレスポンスを受信しています。
レスポンス内のステータス・コードが、受入れ可能なレスポンス・コード(指定されている場合)のいずれかと一致しています。
デフォルトでは、Oracle Traffic Directorは、正常なオリジン・サーバーのインジケータとして1xxから4xxまでのレスポンス・コード受け入れます。
レスポンス本文が、受入れ可能なレスポンス本文(指定されている場合)と一致しています。
otd_getHealthCheckPropertiesコマンドを実行します。props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
otd_getHealthCheckProperties(props)
protocol=HTTP
interval=30
timeout=5
failover-threshold=3
request-method=OPTIONS
request-uri=/
response-body-match-size=2048
dynamic-server-discovery=false
構成内のオリジン・サーバー・プールのヘルス・チェック設定を変更するには、otd_setHealthCheckPropertiesコマンドを実行します。
たとえば、次のコマンドにより、構成foo内のオリジン・サーバー・プールorigin-server-pool-1のヘルス・チェック間隔が60秒に変更され、ヘルス・チェックのタイムアウト時間が10秒に変更されます。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['interval'] = '60'
props['timeout'] = '10'
otd_setHealthCheckProperties(props)
Oracle Traffic Directorは一般的なヘルス・チェック連結メカニズムをサポートしたことで、自分達のヘルス・チェックのプログラム/スクリプトを記述して特定のオリジン・サーバーのヘルスを監視できるようになりました。外部実行可能ファイルは、オリジン・サーバーのプロトコル・レベルのヘルス・チェック・モニターとして特に有用です。
外部実行可能ファイルを使用してサーバーの状態をチェックするようにOracle Traffic Directorを構成すると、Oracle Traffic Directorは定期的に実行可能ファイルを呼び出し、特定のパラメータを引数および環境変数として渡します。実行可能ファイルが、タイムアウトする前に正常にステータス・コード0を戻すと、Oracle Traffic Directorはサーバー・ステータスをオンラインに設定します。実行可能ファイルが0以外の値を戻すか、実行が終了する前にタイムアウトが発生すると、Oracle Traffic Directorは再試行することなく即座にサーバー・ステータスをオフラインに設定し、タイムアウトの場合には実行可能ファイルを停止します。実行可能ファイルが0以外のステータス・コードを戻すには様々な理由があります(コア・ダンプ、シグナル停止、外部実行可能ファイル自体のロジックが含まれます)。Oracle Traffic Directorは、戻りステータスが0以外の場合は常にサーバーをオフラインにマークします。
また、Oracle Traffic Directorは、実行可能ファイルの標準出力および標準エラーを取得し、イベント・ログ(サーバー・ログ)にメッセージをロギングします。
外部実行可能ファイルは実際のヘルス・チェック・ジョブを処理します。これには、オリジン・サーバーの接続の確立、リクエスト/応答の送信/受信、(該当する場合)SSLの処理、(必要に応じて)再試行ロジックなどが含まれます。実行可能ファイルは、ヘルス・チェック処理終了後、ステータス0で終了しサーバー・ステータスをオンラインに設定することが想定されています。実行可能ファイルがイベント・ログにメッセージをロギングするようにするには、標準出力にそれらのメッセージを出力します。
構成内のオリジン・サーバー・プールのヘルス・チェック設定を、外部の実行可能ファイルを使用するように構成するには、otd_setHealthCheckPropertiesコマンドを実行します。
たとえば、次のコマンドはヘルス・チェック・メソッドをcommandに設定し、外部のヘルス・チェック実行可能ファイルのパスとして/path/myhcscriptを指定します。間隔およびタイムアウト・プロパティも指定されます。
props = {}
props['configuration'] = 'foo'
props['origin-server-pool'] = 'origin-server-pool-1'
props['protocol'] = 'command'
props['interval'] = '60'
props['timeout'] = '10'
props['command'] = '/path/myhcscript'
otd_setHealthCheckProperties(props)
注意:
オリジン・サーバー・プールのHTTPタイプの場合、COMMANDヘルス・チェック・プロトコルは次の場合には考慮されません。
オリジン・サーバー・タイプがUNDETECTEDの場合、または
オリジン・サーバー・タイプがWLSで、動的検出が設定されている場合。
更新された構成を有効にするには、activateコマンドを使用して、Oracle Traffic Directorインスタンスに構成をデプロイする必要があります。
Oracle Traffic Directorは、パラメータを外部ヘルス・チェック実行可能ファイルへ2つの方法で渡します。特に、Oracle Traffic Directorは、引数でオリジン・サーバー・ホスト、オリジン・サーバー・ポートおよびタイムアウト値を渡し、ORACLE_HOME、INSTANCE_HOME、INSTANCE_NAME、DOMAIN_HOMEおよびOTD_LOG_LEVELに加えて既存の環境変数をすべて環境変数として渡します。引数パラメータは、次のコマンドの例で示すように、コマンドライン・オプションの形式で渡されます。
/path/myhcscript -h server1.myserver.com -p 389 -t 10
ここで、-h、-pおよび-tは、それぞれホスト、ポートおよびタイムアウトを表します。
表7-2 引数パラメータ
| オプション | 意味 |
|---|---|
|
オリジン・サーバーのホスト。 |
|
オリジン・サーバーのポート。 |
|
ヘルス・チェック・タイムアウト。 |
その他のパラメータは、次のようにcommandパラメータに追加のオプション引数を指定することで外部実行可能ファイルに渡すことができます。
/path/myhcscript --secure -d /dbpath
同様に、Oracle Traffic Directorは追加引数を次のように外部実行可能ファイルに渡します。
/path/myhcscript --secure -d /dbpath -h server1.myserver.com -p 389 -t 10
Oracle Traffic Directorは、オリジン・サーバー・ポート・タイプ(LDAP over SSLなど)を自動的には実行可能ファイルに渡しません。実行可能ファイルにタイプ情報が必要な場合、コマンド文字列で追加引数としてタイプ情報を指定するか(前述の例)、またはヘルス・チェック・プログラム/スクリプトでタイプ情報をハードコード化したり他のリソースから取得したり(たとえば、それ自体の構成ファイルまたは環境変数)することができます。
さらに、外部実行可能ファイルではタイムアウト値を考慮し、タイムアウトする前に実行を終了してステータスを戻すことをお薦めします。タイムアウトが発生し実行が終了していない場合、Oracle Traffic Directorはプロセスを終了してサーバー・ステータスをオフラインに設定します。
Oracle Traffic Directorは、環境変数OTD_LOG_LEVELを通じて外部プログラムに構成済ロギング・レベルを渡し、その環境変数の値は整数です。外部実行可能ファイルでは、ロギング・レベルに基づいてロギング・メッセージの量をカスタマイズできます。次の表は、Oracle Traffic Directorロギング・レベルと引数値の間のマッピングを定義します。
表7-3 Oracle Traffic Directorロギング・レベルおよび引数値のマッピング
| 値 | Oracle Traffic Directorロギング・レベル |
|---|---|
0 |
NOTIFICATION:1以上 |
1 |
TRACE:1 |
2 |
TRACE:16 |
3 |
TRACE:32 |
Oracle Traffic Directorは、内容を外部実行可能ファイルのサーバー・ログの単一ログ・エントリで標準出力および標準エラーの両方にロギングします。コマンド・ヘルス・チェック・スクリプトの終了ステータスが0の場合、メッセージはTRACE:1レベルでロギングされます。そうでない場合、標準出力がNOTIFICATION:1レベルでロギングされ、標準エラーがWARNING:1レベルでロギングされます。
