HTTP ロードバランサの設定

ロードバランサ設定は domain.xml ファイルに保持されます。ロードバランサの設定は非常に柔軟性があります。

• ロードバランサがサービスを提供するドメインは 1 つだけですが、ドメインは関連する複数のロードバランサを持つことができます。

• 各ロードバランサ設定は、関連する複数のロードバランサを持つことができます。ただし、1 つのロードバランサには、1 つのロードバランサ設定しかできません。

以下の節では、ロードバランサ設定を作成、変更、および使用する方法についてさらに詳しく説明します。

• 「 DAS 上での HTTP ロードバランサの設定」

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

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

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

• 「HTTP 健全性検査の作成」

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

• 「HTTP ロードバランサ設定の変更」

• 「動的再設定を有効にする」

• 「サーバーインスタンスまたはクラスタの無効化 (休止)」

• 「アプリケーションの無効化 (休止)」

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

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

• 「べき等 URL の設定」

DAS 上での HTTP ロードバランサの設定

管理コンソールまたは asadmin コマンドの create-http-lb を使用して、DAS 上のロードバランサ設定を作成できます。以降の手順ではその方法を説明します。asadmin コマンドの詳細については、man ページまたは『Reference Manual』で create-http-lb、delete-http-lb、および list-http-lbs を参照してください。

管理コンソールの左区画で下にスクロールして「HTTP ロードバランサ」ノードをクリックし、右側の「HTTP ロードバランサ」ページで「新規」をクリックします。「新しい HTTP ロードバランサ」ページで、ロードバランサのホストになるマシンについて次の情報を指定します。

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

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

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

管理コンソールを使用して参照を作成するには、左側の区画で「HTTP ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。「ターゲット」タブを開き、「ターゲットを管理」をクリックします。「ロードバランサのターゲットを管理」ページで、必要なターゲットを選択します。別の方法として、create-http-lb-ref を使用して参照を作成することもできます。ロードバランサ設定名と、ターゲットサーバーインスタンスまたはクラスタを指定する必要があります。

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

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

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

サーバーインスタンスまたはクラスタへの参照を作成したら、enable-http-lb-server を使用してサーバーインスタンスまたはクラスタを有効にします。ロードバランサ設定の作成時にサーバーインスタンスまたはクラスタをターゲットとして使用した場合は、それを有効にする必要があります。管理コンソールを使用してこれを行うには、左側の区画で「HTTP ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。ここで「ターゲット」タブを開き、「ターゲット」テーブルで、有効にするインスタンスの隣のチェックボックスにチェックマークを付け、「有効」をクリックします。

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

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

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

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

管理コンソールを使用してアプリケーションを有効化するには、左側の区画で「HTTP ロードバランサ」ノードをクリックし、ノードの下に表示されるリストから目的のロードバランサをクリックします。前の手順の説明に従って「ターゲット」タブを開き、必要なクラスタをクリックします。ここで「アプリケーション」タブを開き、必要なアプリケーションを選択し、「その他の操作」ドロップダウンリストから、「ロードバランサ有効」を選択します。コマンド行からこれを行う場合、コマンド asadmin enable-http-lb-application を使用できます。コマンドの詳細については、man ページを参照してください。

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

HTTP 健全性検査の作成

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

ロードバランサの健全性検査メカニズムは、HTTP を使用してインスタンスと通信します。健全性検査は、指定された URL に HTTP 要求を送信し、応答を待ちます。HTTP 応答ヘッダー内の状態コードが 100 ～ 500 の間であれば、インスタンスが正常であることを示します。

ロードバランサがクラスタに対するフロントエンドであり、クライアント証明書認証を有効にしてセキュリティー保護ポートを使用しているインスタンスがそのクラスタに含まれる配備状況では、健全性検査はインスタンスの診断を実行できません。したがって、そのようなインスタンスは常に正常でないと認識され、それらのインスタンスには要求は送られません。

健全性検査の作成

健全性検査のプロパティーを指定するために、管理コンソールまたは asadmin create-http-health-checker コマンドを使用できます。管理コンソールでこれを行うには、「HTTP ロードバランサ」ノードに移動し、ノードを展開してロードバランサを選択します。次に「ターゲット」タブを開き、「ターゲット」テーブルで目的のターゲットの「健全性検査を編集」リンクをクリックします。次のパラメータを指定します。

インスタンスが正常でないとマークされている場合、健全性検査が正常ではないインスタンスをポーリングして、インスタンスが正常になったかどうかを判断します。健全性検査は、指定された URL を使用して正常でないインスタンスをすべてチェックし、それらが正常な状態に戻っているかどうかを判断します。

健全性検査により、正常ではないインスタンスが正常になったことが確認されると、そのインスタンスが正常なインスタンスのリストに加えられます。

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

正常なインスタンス用健全性検査の追加プロパティー

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

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

asadmin set コマンドを使用して、プロパティーを設定します。次に例を示します。

asadmin set domain.lb-configs.load-balancer-config.property.active-healthcheck-enabled=true

asadmin set domain.lb-configs.load-balancer-config.property.number-healthcheck-retries=5

これらのプロパティーを追加したあと、loadbalancer.xml ファイルをふたたび編集およびエクスポートする場合、新しくエクスポートした設定にはこれらのプロパティーが含まれます。

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

Sun GlassFish Enterprise Server で提供されるロードバランサプラグインは、loadbalancer.xml という設定ファイルを使用します。ロードバランサを設定したあとで、設定の詳細を domain.xml から loadbalancer.xml ファイルにエクスポートできます。これは、管理コンソールまたは asadmin ユーティリティーを使用して行うことができます。

管理コンソールを使用してロードバランサ設定をエクスポートする

1. 「HTTP ロードバランサ」ノードに移動し、ノードを展開します。

2. 目的のロードバランサをクリックします。

   すべてのロードバランサ設定の詳細が「一般」、「設定」、および「ターゲット」の各タブに表示されます。

3. 「エクスポート」タブを開き、「今すぐエクスポート」をクリックします。

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

asadmin ツールを使用してロードバランサ設定をエクスポートする

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 などの別の名前になっている場合は、名前を変更する必要があります。

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

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

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

動的再設定を有効にする

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

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

• ロードバランサ設定を作成するときに、asadmin create-http-lb で --reloadinterval オプションを使用します。

  このオプションは、ロードバランサ設定ファイル loadbalancer.xml に対する変更のチェックの間隔を設定します。この値が 0 の場合は、動的再設定が無効になります。デフォルトでは、動的再設定が有効になり、再読み込み間隔は 60 秒に設定されます。

• 以前に動的再設定を無効にしていた場合、または再読み込み間隔を変更する場合は、asadmin set コマンドを使用します。

  再読み込み間隔を変更したら、ロードバランサ設定ファイルをふたたびエクスポートして、Web サーバーの config ディレクトリにコピーしたあと、Web サーバーを再起動します。

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

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

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

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

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

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

• あるインスタンス (スタンドアロンまたはクラスタの一部分) が無効化され、タイムアウトが経過していない場合、スティッキ要求はインスタンスに配信され続けます。ただし、新しい要求は無効化されたインスタンスに送信されません。

• タイムアウトを経過すると、インスタンスは無効化されます。ロードバランサからインスタンスへのすべてのオープン接続が閉じられます。このインスタンスに固定されている一部のセッションが無効化されなかった場合でも、ロードバランサはこのインスタンスに要求を送りません。ロードバランサはスティッキ要求を別の正常なインスタンスにフェイルオーバーします。

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

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

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

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

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

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

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

• タイムアウトピリオドが経過していない場合、ロードバランサは新しい要求をアプリケーションには転送せずに、Web サーバーに返します。ただし、タイムアウトピリオドが経過するまで、スティッキ要求の転送は引き続き行います。

• タイムアウトピリオドを経過すると、ロードバランサは、スティッキ要求を含むアプリケーションへのすべての要求を受け付けなくなります。

  ロードバランサが参照するすべてのサーバーインスタンスまたはクラスタから、あるアプリケーションを無効にする場合、無効化されたアプリケーションのユーザーは、アプリケーションが再度有効化されるまでサービスを受けられません。1 つのサーバーインスタンスまたはクラスタからアプリケーションを無効にして、別のサーバーインスタンスまたはクラスタでは有効にする場合、ユーザーは引き続きアプリケーションにアクセスできます。詳細については、「可用性を低下させないアプリケーションのアップグレード」を参照してください。

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

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 ルーティングを設定してください。

• HTTPS ルーティングを動作させるには、1 つまたは複数の HTTPS リスナーを設定する必要があります。

• https-routing が true に設定されていて、クラスタ内に正常な HTTPS リスナーが存在していない状態で新しい要求またはスティッキ要求が着信した場合、その要求はエラーを生成します。

既知の問題

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

• あるセッションが HTTP 要求と HTTPS 要求を組み合わせて使用する場合、最初の要求は必ず HTTP 要求にする必要があります。最初の要求が HTTPS 要求の場合、そのあと HTTP 要求を続けられません。これは、HTTPS セッションに関連付けられている Cookie がブラウザによって返されないからです。ブラウザは、異なる 2 つのプロトコルを異なる 2 つのサーバーと解釈し、新しいセッションを開始します。この制限は、httpsrouting が true に設定されている場合のみ有効です。

• あるセッションに HTTP 要求と HTTPS 要求の組み合わせが含まれる場合、インスタンスは HTTP リスナーと HTTPS リスナーの両方を使用して設定される必要があります。この制限は、httpsrouting が true に設定されている場合のみ有効です。

• あるセッションに HTTP 要求と HTTPS 要求の組み合わせが含まれる場合、インスタンスは、標準ポート番号 (HTTP では 80、HTTPS では 443) を使用する HTTP および HTTPS リスナーによって設定される必要があります。この制限は、httpsrouting に設定された値に関係なく適用されます。

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

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

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

authPassthroughEnabled プロパティー

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

authPassthroughEnabled は、Enterprise 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 プロパティー

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

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

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

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

この抽象クラスの実装は、インスタンスへの元のクライアント要求に関する情報を伝達するためにプロキシサーバーが使用するカスタム要求ヘッダーに対して行われる特定の要求を調べ、その情報を呼び出し元に返します。デフォルトの実装では、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)、ホスト、およびポートの情報が追加されます。デフォルトでは、以前のリリースの Enterprise Server との後方互換性を保つために、rewrite-location プロパティーは true に設定されます。

rewrite-location プロパティーは、asadmin create-http-lb-config コマンドを介して使用することはできません。プロパティーを使用するには、次のように asadmin set コマンドを使用します。

asadmin set domain.lb-configs.load-balancer-config.property.rewrite-location=false

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

• httpsrouting が false で、Enterprise Server 上で authPassthroughEnabled が有効でない場合は、rewrite-location プロパティーを true に設定します。authPassthroughEnabled が有効でない場合、Enterprise Server は元の要求のプロトコル (HTTP または HTTPS) を認識しません。rewrite-location を true に設定することで、ロードバランサは書き換えの場所のプロトコル部分を適切に変更します。つまり、クライアントが HTTPS 要求を送信していれば、ロードバランサはクライアントをロードバランサ上の HTTPS が有効になっているリスナーポートにリダイレクトします。このプロセスは HTTP 要求の場合と同じです。

• httpsrouting が false で、authPassthroughEnabled が Enterprise Server 上で有効になっている場合、Enterprise Server はクライアント要求が HTTP と HTTPS のどちらであるのかを認識しているので、rewrite-location を true または false に設定することができます。authPassthroughEnabled が有効になっている場合、Enterprise Server は書き換えの場所のプロトコル部分を適切に変更します。rewrite-location が false に設定されている場合、ロードバランサはリダイレクトされた URL の場所を書き換えません。true に設定されている場合は、リダイレクトされた URL の場所を書き換えます。しかしこの書き換えは、Enterprise Server がクライアントからの HTTPS 接続を認識していれば必要ありません。また、アプリケーションが HTTP から HTTPS または HTTPS から HTTP にリダイレクトする必要のある場合、rewrite-location パラメータを false に設定する必要があります。

べき等 URL の設定

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

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

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

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

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