オリジン・サーバーは、バックエンドのサーバーであり、Oracle Traffic Directorはクライアントから受信したリクエストをこのサーバーに転送し、クライアント・リクエストに対するレスポンスをこのサーバーから受信します。たとえば、オリジン・サーバーには、Oracle WebLogic ServerインスタンスまたはOracle iPlanet Web Serverインスタンスなどが該当します。同じサービスを提供する、または同じコンテンツを提供するオリジン・サーバーのグループは、オリジン・サーバー・プールと呼ばれます。このようなオリジン・サーバー・プールを構成内にいくつか定義し、特定のプールにクライアント・リクエストをルーティングするようにOracle Traffic Directorインスタンス内に各仮想サーバーを構成できます。
この章では、オリジン・サーバー・プールを作成および管理する方法を説明します。ここの内容は、次のとおりです。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールを作成できます。
注意:
|
始める前に
オリジン・サーバー・プールの作成を開始する前に、次の項目を決定します。
オリジン・サーバー・プールの一意の名前。オリジン・サーバー・プールを作成した後は名前を変更できないため、名前は慎重に選択してください。
オリジン・サーバー・プール内のサーバーのhost:port
の組合せ。
注意: プールを作成するオリジン・サーバーが、クラスタ内のOracle WebLogic Server管理対象サーバーの場合、管理対象サーバーのいずれか1つをオリジン・サーバーとして使用してプールを作成すれば十分です。その後、プール内のその他の管理対象サーバーを動的に検出するようにOracle Traffic Directorを構成することができます。詳細は、5.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。 |
プール内のサーバーの通信プロトコル(HTTP/SまたはTCP)。
オリジン・サーバー・プール内のサーバーがリクエストのリスニングに使用するアドレス・ファミリ。
サポートされているアドレス・ファミリは次のとおりです。
inet
(IPv4)
inet6
(IPv6)
inet-sdp
(ソケット・ダイレクト・プロトコル): オリジン・サーバー・プール内のサーバーがインフィニバンド・ファブリック上にあり、SDPインタフェースでリスニングしている場合(Oracle ExalogicマシンにデプロイされているOracle WebLogic Serverなど)、このファミリを選択します。
注意: Oracle Traffic DirectorとWebLogic Serverの通信をSDPで行うには、WebLogic Server側に追加の構成手順が必要になります。これらの構成手順の詳細は、Oracle Fusion Middleware Exalogic Enterpriseデプロイメント・ガイドのクラスタレベルのセッション・レプリケーション強化の有効化に関する項を参照してください。 |
Fusion Middleware Controlを使用したオリジン・サーバー・プールの作成
Fusion Middleware Controlを使用してオリジン・サーバー・プールを作成するには、次を実行します。
1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
オリジン・サーバー・プールを必要とする構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。その構成に定義されているサーバー・プール(HTTP/SおよびTCPサーバー・プール)のリストが表示されます。
構成するサーバー・プールを選択します。
「共通タスク」ペインで、「作成」ボタンをクリックします。
「オリジン・サーバー・プールの作成」ページが表示されます。
画面上のプロンプトに従い、前に決定した詳細(名前、タイプなど)を使用して、オリジン・サーバー・プールの作成を完了します。
オリジン・サーバー・プールが定義されたら、画面の右上にある「OK」をクリックします。「新規オリジン・サーバー・プール」の結果画面に、オリジン・サーバー・プールの作成が成功したことを示すメッセージが表示されます。
作成したオリジン・サーバー・プールの詳細が、「オリジン・サーバー・プール」ページに表示されます。
さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。
WLSTを使用したオリジン・サーバー・プールの作成
オリジン・サーバー・プールを作成するには、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)
otd_createOriginServerPool
の詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
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)
otd_createOriginServerPool
の詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールのリストを表示できます。
Fusion Middleware Controlを使用したオリジン・サーバー・プールのリストの表示
Fusion Middleware Controlを使用してオリジン・サーバー・プールのリストを表示するには、次を実行します。
1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
オリジン・サーバー・プールを表示する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。
その構成に定義されているオリジン・サーバー・プールのリストが表示されます。
名前をクリックすると、オリジン・サーバー・プールのプロパティの詳細を表示できます。
WLSTを使用したオリジン・サーバー・プール・リストの表示
オリジン・サーバー・プールのリストを表示するには、次の例に示すように、otd_listOriginServerPools
コマンドを実行します。
props = {} props['configuration'] = 'foo' otd_listOriginServerPools(props)
otd_getOriginServerPoolProperties
およびotd_getHealthCheckProperties
コマンドのそれぞれを実行して、オリジン・サーバー・プールの一般的なプロパティおよびヘルスチェック設定を表示できます。
この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールのプロパティを変更できます。
注意:
|
Fusion Middleware Controlを使用したオリジン・サーバー・プールのプロパティの変更
Fusion Middleware Controlを使用してオリジン・サーバー・プールのプロパティを変更するには、次を実行します。
1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
オリジン・サーバー・プールを変更する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。
構成に定義されているオリジン・サーバー・プールのリストが表示されます。
変更するオリジン・サーバー・プールの名前をクリックします。
「共通タスク」ペインにある「編集」ボタンをクリックします
オリジン・サーバー・プール設定ページが表示されます。このページで、次の処理が可能です。
プール内のサーバーのネットワーク・プロトコル(IPv4、IPv6またはSDP)の変更。
プロキシ・サーバーを通じたオリジン・サーバーへの接続に関する項に従ってプロキシ・サーバーを設定します。この設定は、HTTP転送プロキシ・サーバーをオリジン・サーバー・プールへ関連付けるように指定するため、プールのすべてのメンバー・オリジン・サーバーは構成済HTTP転送プロキシ・サーバーを通じて通信されます。
Oracle Traffic Directorがクライアント・リクエストをプールに分散する際に使用するロード・バランシング方法の変更。
最小接続件数(デフォルト): リクエストの処理時、Oracle Traffic Directorは、各オリジン・サーバーで現在アクティブである接続数を評価し、アクティブな接続数が最も少ないオリジン・サーバーにリクエストを転送します。
最小接続件数メソッドは、より処理の速いオリジン・サーバーに少ないアクティブ接続数しかなく、そのため、より多くの負荷をかけられるという前提の場合に機能します。ロード分散をオリジン・サーバーの容量に基づいてより詳細に調整するには、相対的な重みをオリジン・サーバーに割当てできます。
注意: WebSocket接続は長期にわたって存続する可能性があり、接続が閉じられるまではアクティブの接続としてカウントされます。そのため、最小接続件数によるロード・バランシング・アルゴリズムに影響することがあります。 |
最小レスポンス時間: ほとんどのワークロードは最小接続件数で効率よく処理できますが、同量のワークロードに対するレスポンス時間が、指定されたプール内の各オリジン・サーバーによって異なるケースも考えられます。例:
- 指定されたプール内のオリジン・サーバーがハードウェア仕様の異なるマシンにそれぞれデプロイされている場合。
- 一部のオリジン・サーバー・ノードが他のサービスで使用されている場合。
- ネットワーク接続性が各ノードで異なる場合、または一部のネットワーク・インタフェースに他のインタフェースよりも高い負荷がかかっている場合。
このような状況では最小レスポンス時間の使用が効果的です。これは動的な重み付け最小接続アルゴリズムであり、重みはレスポンス時間に基づいて計算されます。これらの重みはオリジン・サーバーのレスポンス状況に応じて常に調整されます。最小レスポンス時間では、最小接続アルゴリズムで必要な手動の重み調整が不要です。
ラウンド・ロビン: Oracle Traffic Directorは、1番目のリクエストをプール内の1番目のオリジン・サーバーに、2番目のリクエストを次のオリジン・サーバーというように、使用可能なオリジン・サーバーにリクエストを順次転送します。プール内の最後のオリジン・サーバーにリクエストが送信された後、最初のオリジン・サーバーから再び始まります。
ラウンド・ロビン・メソッドは、単純で予測可能であり、処理のオーバーヘッドが少なくて済みますが、オリジン・サーバーの能力の差が無視されます。このため、時間の経過とともに、特に処理速度が遅いオリジン・サーバーにリクエストが累積する可能性があります。この問題を解決するには、相対的な重みをオリジン・サーバーに割り当て、重み付けされたラウンド・ロビン・メソッドを使用できます。
IPハッシュ: 同じクライアントIPアドレスからのすべての受信リクエストは、同じコンテンツ作成サーバーに向けられます。このロード・バランシング・ポリシーは、TCPのロード・バランシングのコンテキストで特に役立ち、Oracle Traffic Directorでは、このロード・バランシング・ポリシーを使用するように顧客に提案しています。
オリジン・サーバーへの重みの割当ての詳細は、6.3項「オリジン・サーバーの変更」を参照してください。
ヘルス・チェック設定の構成。詳細は、5.7項「オリジン・サーバー・プールのヘルス・チェック設定の構成」を参照してください。
Oracle Traffic Directorが、クラスタ内のOracle WebLogic Server管理対象サーバーを自動検出するかどうかの指定。詳細は、5.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。
注意: プール内のオリジン・サーバーの追加、変更および削除は、ナビゲーション・ペインで「オリジン・サーバー」を選択することで実行できます。詳細は、第6章「オリジン・サーバーの管理」を参照してください。 |
変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。
「取消」ボタンをクリックすることで、いつでも変更を破棄できます。
必要な変更を行った後、「OK」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。
さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。3.3項「構成の変更のアクティブ化」の説明に従い、「変更のデプロイ」をクリックして更新した構成を即時にデプロイすることも、さらに変更を行って、その後でデプロイすることもできます。
WLSTを使用したオリジン・サーバー・プールのプロパティの変更
オリジン・サーバー・プールのネットワーク・プロトコルおよびロード・バランシング・メソッドを変更するには、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_setOriginServerPoolProperties
およびotd_setHealthCheckProperties
コマンドを使用して設定または変更できるプロパティのリストは、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールを削除できます。
注意:
|
Fusion Middleware Controlを使用したオリジン・サーバー・プールの削除
Fusion Middleware Controlを使用してオリジン・サーバー・プールを削除するには、次を実行します。
1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
オリジン・サーバー・プールを削除する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。
構成に定義されているオリジン・サーバー・プールのリストが表示されます。
使用可能リストから削除するプールを選択します。
「共通タスク」ペインにある「削除」ボタンをクリックします。
オリジン・サーバー・プールが仮想サーバーの1つ以上のルートに関連付けられている場合、プールを削除できないことを示すメッセージが表示されます。
オリジン・サーバー・プールが仮想サーバーに関連付けられていない場合、削除を確認するプロンプトが表示されます。
「はい」をクリックします。
オリジン・サーバー・プールが削除されます。
WLSTを使用したオリジン・サーバー・プールの削除
オリジン・サーバー・プールを削除するには、次の例に示すように、otd_deleteOriginServerPool
コマンドを実行します。
props = {} props['configuration'] = 'foo' props['origin-server-pool'] = 'origin-server-pool-1' otd_deleteOriginServerPool(props)
otd_deleteOriginServerPool
の詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
注意: Oracle Traffic Directorは、WebLogic Serverプラグインで提供される一部の一般機能をビルトイン機能によってサポートします。そのため、WebLogic Serverとの相互運用性を実現するためにOracle Traffic Directorにプラグインを追加する必要はありません。 |
Oracle WebLogic Server管理対象サーバーのクラスタを表すオリジン・サーバー・プールを作成する場合、クラスタ内の各管理対象サーバーをオリジン・サーバーとして指定する必要はありません。管理対象サーバーのいずれかを、プール内の1つのオリジン・サーバーとして指定するだけで十分です。Oracle Traffic Directorを、クラスタ内のその他のOracle WebLogic Serverインスタンスの存在を動的に検出し、オリジン・サーバーとして構成されている管理対象サーバー、および同じクラスタ内の動的に検出された管理対象サーバーにクライアント・リクエストを分散するように構成できます。
動的検出が有効な場合、クラスタ内の管理対象サーバーのいずれかが停止、追加または削除されたとき、オリジン・サーバー・プールの定義を更新する必要はありません。ただし、Oracle 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 WebLogic Server管理対象サーバーの動的検出は、デフォルトでは有効化されません。Fusion Middleware ControlまたはWLSTのいずれかを使用して、動的検出を有効にできます。
注意:
|
Fusion Middleware Controlを使用した動的検出の有効化
Fusion Middleware Controlを使用してクラスタ内のWebLogic Server管理対象サーバーの動的検出を有効にするには、次を実行します。
1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
動的検出を有効化する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「サーバー・プール」を選択します。
「サーバー・プール」ページが表示されます。
構成に定義されているオリジン・サーバー・プールのリストが表示されます。
使用可能リストから動的検出を有効にするプールを選択します。
ページの「詳細設定」セクションに移動します。
「ヘルス・チェック」サブセクションで、「プロトコル」がHTTPであることを確認し、「動的検出」チェック・ボックスを選択します。
ウィンドウの右上隅にある「OK」ボタンをクリックします。
注意: 現在のヘルス・チェック・プロトコルがTCPの場合、動的検出を有効化するために、プロトコルをHTTPに変更する必要があることを示すエラー・メッセージが表示されます。 |
「コンソール・メッセージ」ペインに、更新されたヘルス・チェック設定が保存されたことを確認するメッセージが表示されます。
WLSTを使用した動的検出の有効化
クラスタ内のOracle WebLogic Server管理対象サーバーの動的検出を有効にするには、otd_setHealthCheckProperties
コマンドを実行します。
たとえば、次のコマンドでは、origin-server-pool-1
オリジン・サーバー・プールであるOracle WebLogic Serverクラスタの管理対象サーバーの動的検出が有効になります。
props = {} props['configuration'] = 'foo' props['origin-server-pool'] = 'origin-server-pool-1' props['dynamic-server-discovery'] = '4096' otd_setHealthCheckProperties(props)
注意: 現在のヘルス・チェック・プロトコルがTCPの場合、動的検出を有効化するために、プロトコルをHTTPに変更する必要があることを示すエラー・メッセージが表示されます。 |
otd_setHealthCheckProperties
の詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
バックエンド・サーバーのメンテナンスが必要な場合に、カスタム・レスポンス・コードおよび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)
otd_enableOriginServerPoolMaintenance
、otd_disableOriginServerPoolMaintenance
およびotd_getOriginServerPoolMaintenanceProperties
の詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
リクエストを受信できる使用可能なオリジン・サーバーにのみリクエストが分散されるように、Oracle Traffic Directorはヘルス・チェック・リクエストをプール内のすべてのオリジン・サーバーに送信することでオリジン・サーバーの可用性および状態を監視します。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、オリジン・サーバー・プールのヘルス・チェック・パラメータを構成できます。
Oracle Traffic Directorがヘルス・チェック・リクエストを送信するタイミング
Oracle Traffic Directorインスタンスの起動時に、構成済のすべてのオリジン・サーバー・プール内のすべてのオリジン・サーバーに対して初期ヘルス・チェックが実行されます。
初期ヘルス・チェックでオリジン・サーバーの状態が正常であると判明すると、次の状況の場合のみOracle Traffic Directorはさらにヘルス・チェック・リクエストをオリジン・サーバーに送信します。
前回のヘルス・チェック間隔全体を通して、サーバーによってリクエストが正常に処理されませんでした。
動的検出が、このオリジン・サーバー・プールで有効に設定されています。詳細は、5.5項「Oracle WebLogic Server Clusterのオリジン・サーバー・プールとしての構成」を参照してください。
ヘルス・チェック(初期または後続のチェックのいずれか)でオリジン・サーバーが使用不可であることが判明した場合、Oracle Traffic Directorは、指定されたヘルス・チェック間隔でヘルス・チェックを繰り返します。
構成可能なヘルス・チェック設定
表5-1は、構成内の各オリジン・サーバー・プールについて構成できるヘルス・チェック設定を示しています。
表5-1 ヘルス・チェック・パラメータ
パラメータ | デフォルト値 |
---|---|
Oracle Traffic Directorが、オリジン・サーバーの状態を判別するために使用するオリジン・サーバーとの接続のタイプ(HTTP、TCPまたはCOMMAND)。
|
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
までのレスポンス・コード受け入れます。
レスポンス本文が、受入れ可能なレスポンス本文(指定されている場合)と一致しています。
Fusion Middleware Controlを使用したオリジン・サーバーのヘルス・チェック設定の構成
Fusion Middleware Controlを使用してプール内のオリジン・サーバーのヘルス・チェック設定を表示および変更するには、次を実行します。
1.7.2項「Fusion Middleware Controlの表示」の説明に従ってFusion Middleware Controlにログインします。
ページの左上隅にある「構成」ボタンをクリックします。
使用可能な構成のリストが表示されます。
オリジン・サーバーのヘルス・チェック設定を表示または変更する、構成を選択します。
ナビゲーション・ペインで、「オリジン・サーバー・プール」を展開し、ヘルス・チェック設定を表示または変更するオリジン・サーバー・プールを選択します。
「オリジン・サーバー・プール」ページが表示されます。構成に定義されたオリジン・サーバー・プールのリストが表示されます。
変更するオリジン・サーバー・プールの名前をクリックします。
「サーバー・プール設定」ページが表示されます。
ページの「詳細設定」セクションに移動します。
変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。
「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。
必要な変更を行った後、「保存」をクリックします。
WLSTを使用したオリジン・サーバーのヘルス・チェック設定の構成
構成内のオリジン・サーバー・プールの現在のヘルス・チェック設定を表示するには、次の例に示すように、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 WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。
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 ヘルス・チェック・プロトコルは次の場合には考慮されません。
|
更新された構成を有効にするには、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
は、それぞれホスト、ポートおよびタイムアウトを表します。
その他のパラメータは、次のように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ロギング・レベルと引数値の間のマッピングを定義します。
表5-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レベルでロギングされます。