test

Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド

ロードバランサの設定

ロードバランサ設定は、domain.xml ファイル内にある設定です。ロードバランサ設定は非常に柔軟性があります。

この節では、ロードバランサ設定を作成、変更、および使用する方法について説明します。ここで説明する内容は次のとおりです。

HTTP ロードバランサ設定の作成

asadmin コマンドの create-http-lb-config を使用して、ロードバランサ設定を作成します。パラメータについては、表 5–1 で説明しています。詳細については、create-http-lb-config、delete-http-lb-config、および list-http-lb-configs のドキュメントを参照してください。

表 5–1 ロードバランサ設定のパラメータ

パラメータ 

説明 

応答タイムアウト 

サーバーインスタンスが応答を返すまでの秒数。タイムアウト時間内に応答が着信しない場合、サーバーが正常でないと判断されます。デフォルトは 60 です。

HTTPS ルーティング 

ロードバランサに対する HTTPS 要求の結果が、サーバーインスタンスに対する HTTPS または HTTP 要求となるかどうかを指定します。詳細については、「HTTPS ルーティングの設定」を参照してください。

再読み込み間隔 

ロードバランサ設定ファイル loadbalancer.xml に対する変更をチェックする間隔。チェックによって変更が検出されると、設定ファイルが再読み込みされます。この値が 0 の場合は、再読み込みが無効になります。詳細については、「動的再設定の有効化」を参照してください。

監視 

ロードバランサで監視が有効かどうかを指定します。 

ルート Cookie 

ロードバランサプラグインがルート情報を記録するために使用する Cookie の名前を指定します。HTTP クライアントは Cookie をサポートする必要があります。Cookie を格納する前にブラウザが確認してくるように設定すると、Cookie の名前は「JROUTE」となります。

ターゲット 

ロードバランサ設定のターゲットを指定します。ターゲットを指定すると、設定に参照を追加した場合と同じ結果になります。ターゲットは、クラスタまたはスタンドアロンインスタンスです。

HTTP ロードバランサ参照の作成

ロードバランサでスタンドアロンのサーバーまたはクラスタへの参照を作成すると、ロードバランサが制御するターゲットサーバーおよびクラスタの一覧に、参照先のサーバーまたはクラスタが追加されます。この場合でも、参照先のサーバーまたはクラスタに対する要求を負荷分散するには、enable-http-lb-server を使用してそのサーバーまたはクラスタを有効化する必要があります。ターゲットを指定してロードバランサ設定を作成した場合、そのターゲットはすでに参照として追加されています。

create-http-lb-ref を使用して参照を作成します。ロードバランサ設定名と、ターゲットサーバーインスタンスまたはクラスタを指定する必要があります。

参照を削除するには、delete-http-lb-ref を使用します。参照を削除する前に、disable-http-lb-server を使用して参照先のサーバーまたはクラスタを無効にする必要があります。

詳細については、create-http-lb-ref および delete-http-lb-ref のドキュメントを参照してください。

負荷分散のためのサーバーインスタンスの有効化

サーバーインスタンスまたはクラスタへの参照を作成したら、enable-http-lb-server を使用してサーバーインスタンスまたはクラスタを有効にします。ロードバランサ設定の作成時にサーバーインスタンスまたはクラスタをターゲットとして使用した場合は、それを有効にする必要があります。

詳細については、enable-http-lb-server のドキュメントを参照してください。

負荷分散のためのアプリケーションの有効化

ロードバランサによって管理されるすべてのサーバーは、アプリケーションの同じセットが配備されていることを含め、同じように設定されている必要があります。アプリケーションが配備されてアクセス可能になると (配備手順の実行中または完了後)、負荷分散を有効にする必要があります。アプリケーションで負荷分散が有効化されていない場合、そのアプリケーションが配備されているサーバーへの要求が負荷分散およびフェイルオーバーされていても、アプリケーションへの要求は負荷分散およびフェイルオーバーされません。

アプリケーションを有効にする際に、アプリケーション名とターゲットを指定します。ロードバランサが複数のターゲット (2 つのクラスタなど) を管理している場合は、すべてのターゲットでアプリケーションを有効にしてください。

詳細については、enable-http-lb-application のオンラインヘルプを参照してください。

新しいアプリケーションを配備する場合にも、アプリケーションで負荷分散を有効にして、再度ロードバランサ設定をエクスポートする必要があります。

HTTP 診断プログラムの作成

ロードバランサの診断プログラムは、設定されている Application Server インスタンスの中で、正常ではないとしてマークされているすべてのインスタンスを定期的にチェックします。診断プログラムは必須ではありませんが、このプログラムが存在しない場合、または無効になっている場合は、正常でないインスタンスの定期的な診断プログラムは実行されません。ロードバランサは、正常でないインスタンスが正常になるタイミングを判断することはできません。

ロードバランサの診断プログラムメカニズムは、HTTP を使用してアプリケーションサーバーと通信します。診断プログラムは、指定された URL に HTTP 要求を送信し、応答を待ちます。HTTP 応答ヘッダー内の状態コードが 100 〜 500 の間であれば、インスタンスが正常であることを示します。

診断プログラムの作成

診断プログラムを作成するには、asadmin create-http-health-checker コマンドを使用します。次のパラメータを指定します。

表 5–2 診断プログラムのパラメータ

パラメータ 

説明 

デフォルト 

url 

ロードバランサが健康状態を判断するためにチェックするリスナーの URL を指定します。 

“/” 

interval 

インスタンスの診断プログラムを実行する間隔を秒単位で指定します。0 を指定すると、診断プログラムが無効になります。 

30 秒 

timeout 

正常だとみなされるリスナーが応答を受け取るまでのタイムアウトを秒単位で指定します。 

10 秒 

アプリケーションサーバーインスタンスが正常でないとマークされている場合、診断プログラムが正常ではないインスタンスをポーリングして、インスタンスが正常になったかどうかを判断します。診断プログラムは、指定された URL を使用して正常でないアプリケーションサーバーインスタンスをすべてチェックし、それらが正常な状態に戻っているかどうかを判断します。

診断プログラムにより、正常ではないインスタンスが正常になったことが確認されると、そのインスタンスが正常なインスタンスのリストに加えられます。

詳細については、create-http-health-checker および delete-http-health-checker のドキュメントを参照してください。

正常なインスタンス用診断プログラムの追加プロパティー

create-http-health-checker によって作成された診断プログラムは、正常ではないインスタンスのみをチェックします。正常なインスタンスを定期的にチェックするには、エクスポートした loadbalancer.xml ファイルに追加のプロパティーをいくつか設定します。

注 –

これらのプロパティーは、loadbalancer.xml ファイルをエクスポートしたあとに手動で編集することによってのみ設定できます。同機能を持つ asadmin コマンドはありません。

正常なインスタンスをチェックするには、次のプロパティーを設定します。

表 5–3 診断プログラムの手動のプロパティー

プロパティー 

定義 

active-healthcheck-enabled

サーバーインスタンスが正常であるかどうかを調べるために、それらに対して Ping を実行するかどうかを示す true/false フラグ。サーバーインスタンスに対して Ping を実行するには、このフラグを true に設定します。 

number-healthcheck-retries

ロードバランサの診断プログラムが、応答しないサーバーインスタンスを正常でないとマークするまでに、それらに対して Ping を実行する回数を指定します。有効な範囲は 1 〜 1000 です。デフォルト値は 3 に設定します。 

loadbalancer.xml ファイルを編集して、プロパティーを設定します。次に例を示します。

<property name="active-healthcheck-enabled" value="true"/>
<property name="number-healthcheck-retries" value="3"/>

これらのプロパティーを追加し、続いて loadbalancer.xml ファイルをふたたび編集およびエクスポートする場合、新しくエクスポートされた設定には追加のプロパティーが含まれません。したがって、新しくエクスポートされた設定にこれらのプロパティーを再度追加する必要があります。

ロードバランサ設定ファイルのエクスポート

Sun Java System Application Server に同梱されているロードバランサプラグインは、loadbalancer.xml という設定ファイルを使用します。asadmin ユーティリティーを使用して、domain.xml ファイルにロードバランサ設定を作成します。負荷分散環境を設定したら、その環境を domain.xml から loadbalancer.xml ファイルにエクスポートします。

Procedureロードバランサ設定をエクスポートする

  1. asadmin コマンドの export-http-lb-config を使用して、loadbalancer.xml ファイルをエクスポートします。

    特定のロードバランサ設定の loadbalancer.xml ファイルをエクスポートします。パスまたは別のファイル名を指定できます。ファイル名を指定しない場合、ファイルには loadbalancer.xml. load-balancer-config-name という名前が付けられます。パスを指定しない場合、ファイルは domain-dir/generated ディレクトリに作成されます。

    Windows でパスを指定する場合は、パスを引用符で囲みます。たとえば、"C:\Sun\AppServer\loadbalancer.xml" のように指定します。

  2. エクスポートしたロードバランサ設定ファイルを、Web サーバーの設定ディレクトリにコピーします。

    たとえば、Sun Java System Web Server の場合、通常のコピー先は web-server-root /config となります。

    Web サーバーの設定ディレクトリ内のロードバランサ設定ファイルには、loadbalancer.xml という名前を付ける必要があります。loadbalancer.xml. load-balancer-config-name などの別の名前を付けた場合は、変更する必要があります。

ロードバランサ設定の変更

サーバーへの参照の作成または削除、新しいアプリケーションの配備、サーバーまたはアプリケーションの有効化/無効化などによってロードバランサ設定を変更する場合は、ロードバランサ設定ファイルをふたたびエクスポートして、Web サーバーの config ディレクトリにコピーします。詳細については、「ロードバランサ設定ファイルのエクスポート」を参照してください。

ロードバランサプラグインは、ロードバランサ設定で指定した再読み込み間隔に従って、更新された設定を定期的にチェックします。指定した時間が経過して、ロードバランサが新しい設定ファイルを検出した場合は、その設定を使用して再読み込みが開始されます。

動的再設定の有効化

動的再設定で、ロードバランサプラグインは更新された設定がないかどうかを定期的にチェックします。

動的再設定を有効にするには、次の手順に従います。

注 –

ロードバランサがそれ自体の再設定を試みているときにハードディスク読み込みエラーが発生した場合、ロードバランサは現在メモリーに格納されている設定を使用します。ロードバランサはまた、既存の設定を上書きする前に、変更された設定データが必ず DTD に準拠するようにします。

ディスク読み込みエラーが発生すると、Web サーバーのエラーログファイルに警告メッセージが記録されます。

Sun Java System Web Server のエラーログは、次の場所にあります。web-server-install-dir /web-server-instance /logs/ です。

サーバーインスタンスまたはクラスタの無効化 (停止)

何らかの理由でアプリケーションサーバーを停止する前に、インスタンスが要求の処理を完了している必要があります。サーバーインスタンスまたはクラスタを正常に無効にするプロセスは、停止と呼ばれます。

ロードバランサは、アプリケーションサーバーインスタンスを停止するために、次のポリシーを使用します。

Procedureサーバーインスタンスまたはクラスタを無効にする

  1. asadmin disable-http-lb-server を実行して、タイムアウトを分単位で設定します。

  2. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。

  3. エクスポートした設定を Web サーバーの config ディレクトリにコピーします。

  4. サーバーインスタンスを停止します。

アプリケーションの無効化 (停止)

Web アプリケーションの配備を取り消す前に、アプリケーションで要求の処理が完了される必要があります。アプリケーションを正常に無効にするプロセスは、停止と呼ばれます。アプリケーションを停止する場合は、タイムアウトピリオドを指定します。ロードバランサは、指定されたタイムアウトピリオドに基づいて、アプリケーションを停止するために次のポリシーを使用します。

Procedureアプリケーションを無効にする

  1. asadmin disable-http-lb-application を使用して、次のパラメータを指定します。

    • タイムアウト (分単位)

    • 無効にするアプリケーションの名前

    • 無効化を実行するターゲットクラスタまたはインスタンス

  2. asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。

  3. エクスポートした設定を Web サーバーの config ディレクトリにコピーします。

HTTP および HTTPS のフェイルオーバーの設定

HTTP/HTTPS セッションが接続されていた元のアプリケーションサーバーインスタンスが無効化された場合、ロードバランサプラグインは、そのセッションを別のアプリケーションサーバーインスタンスにフェイルオーバーします。この節では、HTTP/HTTPS ルーティングとセッションフェイルオーバーを有効にするようにロードバランサプラグインを設定する方法について説明します。

HTTPS ルーティング

ロードバランサプラグインは、すべての着信 HTTP または HTTPS 要求をアプリケーションサーバーインスタンスにルーティングします。ただし、HTTPS ルーティングが有効になっている場合、ロードバランサプラグインは HTTPS ポートのみを使用して HTTPS 要求をアプリケーションサーバーに転送します。HTTPS ルーティングは、新しい要求とスティッキ要求の両方について実行されます。

HTTPS 要求が受信され、処理中のセッションがない場合、ロードバランサプラグインは設定されている HTTPS ポートを使用して使用可能なアプリケーションサーバーインスタンスを選択し、要求をそのインスタンスに転送します。

処理中の HTTP セッションで、同じセッションに対して新しい HTTPS 要求が受信された場合、HTTP セッション中に保存されたセッションおよびスティッキ情報を使用して HTTPS 要求がルーティングされます。新しい HTTPS 要求は、最後の HTTP 要求が処理された同じサーバーにルーティングされます。ただし、HTTPS ポートが使用されます。

HTTPS ルーティングの設定

create-http-lb-config コマンドの httpsrouting オプションは、負荷分散に関わるすべてのアプリケーションサーバーに対して HTTPS ルーティングが有効か無効かを制御します。このオプションが false に設定されている場合、すべての HTTP および HTTPS 要求は HTTP として転送されます。true に設定されている場合、HTTPS は HTTPS 要求として転送されます。新しいロードバランサ設定を作成する場合、または、作成後に asadmin set コマンドを使用して変更する場合には、HTTPS ルーティングを設定してください。

注 –

既知の問題

ロードバランサには、HTTP/HTTPS 要求の処理に関する次の制限事項があります。

ロードバランサによるリダイレクトの使用

リダイレクトを使用して、ある URL から別の URL へ要求をリダイレクトします。たとえば、リダイレクトを使用して、ユーザーを別の Web サイトに送信したり (旧バージョンのアプリケーションから新しいバージョンへリダイレクトする場合など)、HTTP から HTTPS へ、または HTTPS から HTTP へ送信したりします。アプリケーション内でリダイレクトを有効にする方法はいくつもあります (たとえば、servlet ベースのリダイレクト、web.xml リダイレクト)。ただし、ロードバランサを通してリダイレクト URL を送信するには、Application Server またはロードバランサに対していくつか追加設定が必要な場合があります。リダイレクトは HTTPS ルーティングを使用して転送される要求とは異なるので注意してください。リダイレクトを使用するときには、lhttpsrouting を false に設定します。HTTPS 要求を HTTP に転送するように設定する場合は、「HTTPS ルーティング」を使用します。

リダイレクトに影響するプロパティーは次のとおりです。HTTP サービスまたは HTTP リスナーの authPassthroughEnabled および proxyHandler プロパティーと、loadbalancer.xml ファイル内の rewrite-location プロパティー。

authPassthroughEnabled プロパティー

Application Server authPassthroughEnabled プロパティーを true に設定した場合、カスタムな要求ヘッダーを使用して、元のクライアント要求に関する情報 (クライアント IP アドレス、SSL キーサイズ、認証されたクライアント認証チェーンなど) が HTTP リスナーへ送信されます。authPassThroughEnabled プロパティーを使用すると、ハードウェアアクセラレータ (インストールされている場合) を利用して SSL 認証をより高速にできます。ハードウェアアクセラレータの設定は、クラスタ化されたそれぞれの Application Server インスタンス上よりも、ロードバランサ上で行う方が簡単です。

注意 – 注意 –

authPassthroughEnabled は、Application Server がファイアウォールの後ろにある場合のみ true に設定します。

asadmin set コマンドを使用して、HTTP サービスまたは個別の HTTP リスナー上に authPassthroughEnabled プロパティーを設定します。個別の HTTP リスナーに対する設定は、HTTP サービスに対する設定よりも優先されます。

すべての HTTP および HTTPS リスナー上に authPassthroughEnabled プロパティーを設定するには、次のコマンドを使用します。

asadmin set cluster-name-config.http-service.property.authPassthroughEnabled=true

このプロパティーを個別のリスナー上に設定するには、次のコマンドを使用します。

asadmin set cluster-name-config.http-service.http-listener.listener-name.property.authPassthroughEnabled=true

proxyHandler プロパティー

Application Server のプロキシハンドラは、プロキシサーバー (この場合はロードバランサ) によって遮断されて Application Server に転送された元のクライアント要求に関する情報を取得し、クライアント要求のターゲットである (Application Server 上に配備された) Web アプリケーションでこの情報を使用できるようにする役目を担っています。遮断するプロキシサーバーが SSL 終了をする場合、プロキシハンドラは、元の要求が HTTPS 要求であったのか、SSL クライアント認証が有効なのかなど元の要求に関する追加の情報を取得して使用可能にします。 proxyHandler プロパティーは、authPassThroughEnabled が true に設定されている場合のみ使用します。

プロキシハンドラは、プロキシサーバーが元のクライアント要求に関する情報を伝達するのに使用するカスタムな要求ヘッダーについて着信要求を調べ、標準の ServletRequest API を使用してこの情報を Application Server 上の Web アプリケーションで使用できるようにします。

プロキシハンドラの実装は、proxyHandler プロパティーを使用して、HTTP サービスレベルでグローバルに設定することも、個別の HTTP リスナーに対して設定することもできます。このプロパティーの値は、com.sun.appserv.ProxyHandler 抽象クラスの実装の完全修飾クラス名を指定します。設定可能なプロキシハンドラの実装が、HTTP 要求ヘッダー名について認識し、プロキシサーバーが元のクライアント要求に関する情報を伝達するのに使用する値の書式を理解しているかぎり、プロキシハンドラの実装によって Application Server は任意のプロキシサーバーで動作できます。

Application Server のプロキシハンドラは、要求ヘッダーから SSL 認証チェーンを読み込んで解析します。これによって、バックエンドアプリケーションのサーバーインスタンスは、SSL 終了をするプロキシサーバー (ここではロードバランサ) によって遮断された元のクライアント要求に関する情報を取得できるようになります。デフォルトのプロキシハンドラ設定を使用することも、HTTP サービスまたは HTTP/HTTPS リスナーの proxyHandler プロパティーを使用してユーザー設定することもできます。proxyHandler プロパティーでは、そのリスナーまたはすべてのリスナーによって使用される com.sun.appserv.ProxyHandler 抽象クラスのカスタム実装の完全修飾クラス名を指定します。

この抽象クラスの実装は、Application Server インスタンスへの元のクライアント要求に関する情報を伝達するためにプロキシサーバーが使用するカスタム要求ヘッダーに対して行われる特定の要求を調べ、その情報を呼び出し元に返します。デフォルトの実装では、Proxy-ip という名前の HTTP 要求ヘッダーからクライアント IP アドレスを、Proxy-keysize という名前の HTTP 要求ヘッダーから SSL キーサイズを、Proxy-auth-cert という名前の HTTP 要求ヘッダーから SSL クライアント認証チェーンを読み取ります。Proxy-auth-cert 値には、BEGIN CERTIFICATE および END CERTIFICATE の境界がなく、\n が % d% a によって置き換えられた BASE-64 エンコードのクライアント認証チェーンを含む必要があります。

このプロパティーは、authPassThroughEnabled を true に設定した場合のみ使用できます。個別の HTTP または HTTPS リスナー上に proxyHandler プロパティーを設定すると、すべてのリスナーのデフォルト設定が上書きされます。

asadmin set コマンドを使用して、HTTP サービスまたは個別の HTTP リスナー上に proxyHandler プロパティーを設定します。

proxyHandler プロパティーを、すべての HTTP および HTTPS リスナー上に設定するには、次のコマンドを使用します。

asadmin set cluster-name-config.http-service.property.proxyHandler=classname

このプロパティーを個別のリスナー上に設定するには、次のコマンドを使用します。

asadmin set cluster-name-config.http-service.http-listener.listener-name.property.proxyHandler=classname

rewrite-location プロパティー

rewrite-location プロパティーを true に設定すると、元の要求情報が書き換えられ、プロトコル (HTTP または HTTPS)、ホスト、およびポートの情報が追加されます。デフォルトでは、以前のリリースの Application Server との後方互換性を保つために、rewrite-location プロパティーは true に設定されます。

rewrite-location プロパティーは、asasmin create-http-lb-config または asadmin set コマンドを介して使用することはできません。このプロパティーを使用するには、ロードバランサ設定をエクスポートしてから、loadbalancer.xml ファイルにこのプロパティーを手動で追加します。たとえば、エクスポートした loadbalancer.xml ファイルに、次の内容を追加します。

<property name="rewrite-location" value="false"/>

rewrite-location プロパティーを設定するときには、次の点に注意します。

べき等 URL の設定

べき等要求とは、再試行時にアプリケーションに変更や不一致をもたらさないタイプの要求です。HTTP の場合、GET などの一部のメソッドはべき等的ですが、POST などその他のメソッドはそうではありません。べき等 URL の再試行では、サーバーまたはデータベースの値が変更されてはいけません。ユーザーが受信する応答が変更されるだけです。

べき等要求の例としては、検索エンジンクエリーやデータベースクエリーがあります。基礎となる原則は、再試行によってデータの更新や変更が発生しないことです。

配備されたアプリケーションの可用性を向上させるには、ロードバランサによって処理されたすべてのアプリケーションサーバーインスタンスに、失敗したべき等の HTTP 要求を再試行する環境を設定します。このオプションは、検索要求の再試行など、読み取り専用の要求に使用されます。

sun-web.xml ファイルに、べき等 URL を設定します。ロードバランサ設定をエクスポートする場合、べき等 URL の情報は自動的に loadbalancer.xml ファイルに追加されます。

べき等 URL の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide』の「Configuring Idempotent URL Requests」を参照してください。