ロードバランサ設定は、domain.xml ファイル内で名前を付けられている設定です。ロードバランサ設定は非常に柔軟性があります。
各ロードバランサ設定は、関連する複数のロードバランサを持つことができます。ただし、1 つのロードバランサには、1 つのロードバランサ設定しかできません。
ロードバランサがサービスを提供するドメインは 1 つだけですが、ドメインは関連する複数のロードバランサを持つことができます。
この節では、ロードバランサ設定を作成、変更、および使用する方法について説明します。ここで説明する内容は次のとおりです。
asadmin コマンドの create-http-lb-config を使用して、ロードバランサ設定を作成します。パラメータについては、「HTTP ロードバランサ設定の作成」で説明されています。詳細については、create-http-lb-config、delete-http-lb-config、および list-http-lb-configs のドキュメントを参照してください。
表 4–1 ロードバランサ設定のパラメータ
パラメータ |
説明 |
---|---|
応答タイムアウト |
サーバーインスタンスが応答を返すまでの秒単位のタイムアウト。タイムアウト時間内に応答が着信しない場合、サーバーが正常でないと判断されます。デフォルトは 60 です。 |
ロードバランサに対する HTTPS 要求の結果が、サーバーインスタンスに対する HTTPS または HTTP 要求となるかどうかを指定します。詳細については、「HTTPS ルーティングの設定」を参照してください。 |
|
再読み込み間隔 |
ロードバランサ設定ファイル loadbalancer.xml に対する変更をチェックする間隔。チェックによって変更が検出されると、設定ファイルが再読み込みされます。この値が 0 の場合は、再読み込みが無効になります。詳細については、「動的再設定の有効化」を参照してください。 |
監視 |
ロードバランサで監視が有効かどうかを指定します。 |
ロードバランサプラグインがルート情報を記録するために使用する Cookie の名前を指定します。HTTP クライアントは Cookie をサポートする必要があります。Cookie を格納する前にブラウザが確認してくるように設定すると、Cookie の名前は「JROUTE」となります。 |
|
ターゲット |
ロードバランサ設定のターゲットを指定します。ターゲットを指定すると、設定に参照を追加した場合と同じ結果になります。ターゲットは、クラスタまたはスタンドアロンインスタンスです。 |
ロードバランサでスタンドアロンのサーバーまたはクラスタへの参照を作成すると、ロードバランサが制御するターゲットサーバーおよびクラスタの一覧に、参照先のサーバーまたはクラスタが追加されます。この場合でも、参照先のサーバーまたはクラスタに対する要求を負荷分散するには、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 のオンラインヘルプを参照してください。
新しいアプリケーションを配備する場合にも、アプリケーションで負荷分散を有効にして、再度ロードバランサ設定をエクスポートする必要があります。
ロードバランサの診断プログラムは、設定されている Application Server インスタンスの中で、正常ではないとしてマークされているすべてのインスタンスを定期的にチェックします。診断プログラムは必須ではありませんが、このプログラムが存在しない場合、または無効になっている場合は、正常でないインスタンスの定期的な診断プログラムは実行されません。
ロードバランサの診断プログラムメカニズムは、HTTP を使用してアプリケーションサーバーと通信します。診断プログラムは、指定された URL に HTTP 要求を送信し、応答を待ちます。HTTP 応答ヘッダー内の状態コードが 100 〜 500 の間であれば、インスタンスが正常であることを示します。
診断プログラムを作成するには、asadmin create-http-health-checker コマンドを使用します。次のパラメータを指定します。
表 4–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 コマンドはありません。
正常なインスタンスをチェックするには、次のプロパティーを設定します。
表 4–3 診断プログラムの手動のプロパティー
プロパティー |
定義 |
---|---|
サーバーインスタンスが正常であるかどうかを調べるために、それらに対して Ping を実行するかどうかを示す true/false フラグ。サーバーインスタンスに対して Ping を実行するには、このフラグを true に設定します。 |
|
ロードバランサの診断プログラムが、応答しないサーバーインスタンスを正常でないとマークするまでに、それらに対して 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 ファイルにロードバランサ設定を作成します。負荷分散環境を設定したら、その環境をファイルにエクスポートします。
asadmin コマンドの export-http-lb-config を使用して、loadbalancer.xml ファイルをエクスポートします。
特定のロードバランサ設定の loadbalancer.xml ファイルをエクスポートします。パスまたは別のファイル名を指定できます。ファイル名を指定しない場合、ファイルには loadbalancer.xml.load_balancer_config_name という名前が付けられます。パスを指定しない場合、ファイルは application_server_install_dir /domains/domain_name/generated ディレクトリに作成されます。
Windowd でパスを指定する場合は、パスを引用符で囲みます。たとえば、"c:\sun\AppServer\loadbalancer.xml" のように指定します。
エクスポートしたロードバランサ設定ファイルを、Web サーバーの設定ディレクトリにコピーします。
たとえば、Sun Java System Web Server の場合、コピー先は web_server_root/config となります。
Web サーバーの設定ディレクトリ内のロードバランサ設定ファイルには、loadbalancer.xml という名前を付ける必要があります。loadbalancer.xml.load_balancer_config_name などの別の名前を付けた場合は、変更する必要があります。
サーバーへの参照の作成または削除、新しいアプリケーションの配備、サーバーまたはアプリケーションの有効化/無効化などによってロードバランサ設定を変更する場合は、ロードバランサ設定ファイルをふたたびエクスポートして、Web サーバーの config ディレクトリにコピーします。詳細については、「ロードバランサ設定ファイルのエクスポート」を参照してください。
ロードバランサプラグインは、ロードバランサ設定で指定した再読み込み間隔に従って、更新された設定を定期的にチェックします。指定した時間が経過して、ロードバランサが新しい設定ファイルを検出した場合は、その設定を使用して再読み込みが開始されます。
動的再設定で、ロードバランサプラグインは更新された設定がないかどうかを定期的にチェックします。
動的再設定を有効にするには、次の手順に従います。
ロードバランサ設定を作成するときに、asadmin create-http-lb-config で --reloadinterval オプションを使用します。
このオプションは、ロードバランサ設定ファイル loadbalancer.xml に対する変更のチェックの間隔を設定します。この値が 0 の場合は、動的再設定が無効になります。デフォルトでは、動的再設定が有効になり、再読み込み間隔は 60 秒に設定されます。
以前に動的再設定を無効にしていた場合、または再読み込み間隔を変更する場合は、asadmin set コマンドを使用します。
再読み込み間隔を変更したら、ロードバランサ設定ファイルをふたたびエクスポートして、Web サーバーの config ディレクトリにコピーしたあと、Web サーバーを再起動します。
ロードバランサがそれ自体の再設定を試みているときにハードディスク読み込みエラーが発生した場合、ロードバランサは現在メモリーに格納されている設定を使用します。ロードバランサはまた、既存の設定を上書きする前に、変更された設定データが必ず DTD に準拠するようにします。
ディスク読み込みエラーが発生すると、Web サーバーのエラーログファイルに警告メッセージが記録されます。
Sun Java System Web Server のエラーログは、次の場所にあります。 web_server_install_dir/webserver_instance /logs/。
何らかの理由でアプリケーションサーバーを停止する場合は、その前に、インスタンスで要求の処理が完了される必要があります。サーバーインスタンスまたはクラスタを正常に無効にするプロセスは、停止と呼ばれます。
ロードバランサは、アプリケーションサーバーインスタンスを停止するために、次のポリシーを使用します。
あるインスタンス (スタンドアロンまたはクラスタの 1 部分) が削除され、タイムアウトが経過していない場合、スティッキ要求はインスタンスに配信され続けます。ただし、新しい要求は無効化されたインスタンスに送信されません。
タイムアウトを経過すると、インスタンスは無効化されます。ロードバランサからインスタンスへのすべてのオープン接続が閉じられます。このインスタンスに固定されている一部のセッションが無効化されなかった場合でも、ロードバランサはこのインスタンスに要求を送りません。ロードバランサはスティッキ要求を別の正常なインスタンスにフェイルオーバーします。
asadmin disable-http-lb-server を実行して、タイムアウトを分単位で設定します。
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
エクスポートした設定を Web サーバーの config ディレクトリにコピーします。
サーバーインスタンスを停止します。
Web アプリケーションの配備を取り消す前に、アプリケーションで要求の処理が完了される必要があります。アプリケーションを正常に無効にするプロセスは、停止と呼ばれます。アプリケーションを停止する場合は、タイムアウトピリオドを指定します。ロードバランサは、指定されたタイムアウトピリオドに基づいて、アプリケーションを停止するために次のポリシーを使用します。
タイムアウトピリオドが経過していない場合、ロードバランサは新しい要求をアプリケーションには転送せずに、Web サーバーに返します。ただし、タイムアウトピリオドが経過するまで、スティッキ要求の転送は引き続き行います。
タイムアウトピリオドを経過すると、ロードバランサは、スティッキ要求を含むアプリケーションへのすべての要求を受け付けなくなります。
ロードバランサが参照するすべてのサーバーインスタンスまたはクラスタから、あるアプリケーションを無効にする場合、無効化されたアプリケーションのユーザーは、アプリケーションが再度有効化されるまでサービスを受けられません。1 つのサーバーインスタンスまたはクラスタからアプリケーションを無効にして、別のサーバーインスタンスまたはクラスタでは有効にする場合、ユーザーは引き続きアプリケーションにアクセスできます。
asadmin disable-http-lb-application を使用して、次のパラメータを指定します。
タイムアウト (分単位)
無効にするアプリケーションの名前
無効化を実行するターゲットクラスタまたはインスタンス
asadmin export-http-lb-config を使用して、ロードバランサ設定ファイルをエクスポートします。
エクスポートした設定を Web サーバーの config ディレクトリにコピーします。
HTTP/HTTPS セッションが接続されていた元のアプリケーションサーバーインスタンスが無効化された場合、ロードバランサプラグインは、そのセッションを別のアプリケーションサーバーインスタンスにフェイルオーバーします。この節では、HTTP/HTTPS ルーティングとセッションフェイルオーバーを有効にするようにロードバランサプラグインを設定する方法について説明します。
ここで説明する内容は次のとおりです。
HTTPS (HTTP Secure) プロトコルは、SSL (Secure Socket Layer) を使用して、セキュリティー保護された通信のための HTTP 要求の暗号化および復号化を実現します。HTTPS ルーティングを動作させるには、1 つまたは複数の HTTPS リスナーを設定する必要があります。
ロードバランサプラグインは、すべての着信 HTTP または HTTPS 要求をアプリケーションサーバーインスタンスにルーティングします。ただし、HTTPS ルーティングが有効になっている場合、ロードバランサプラグインは HTTPS ポートのみを使用して HTTPS 要求をアプリケーションサーバーに転送します。HTTPS ルーティングは、新しい要求とスティッキ要求の両方について実行されます。
HTTPS 要求が受信され、処理中のセッションがない場合、ロードバランサプラグインは設定されている HTTPS ポートを使用して使用可能なアプリケーションサーバーインスタンスを選択し、要求をそのインスタンスに転送します。
処理中の HTTP セッションで、同じセッションに対して新しい HTTPS 要求が受信された場合、HTTP セッション中に保存されたセッションおよびスティッキ情報を使用して HTTPS 要求がルーティングされます。新しい HTTPS 要求は、最後の HTTP 要求が処理された同じサーバーにルーティングされます。ただし、HTTPS ポートが使用されます。
create-http-lb-config コマンドの httpsrouting オプションは、負荷分散に関わるすべてのアプリケーションサーバーに対して HTTPS ルーティングが有効か無効かを制御します。このオプションが false に設定されている場合、すべての HTTP および HTTPS 要求は HTTP として転送されます。新しいロードバランサ設定を作成する場合、または、作成後に asadmin set コマンドを使用して変更する場合には、このオプションを true に設定してください。
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 の場合、GET などの一部のメソッドはべき等的ですが、POST などその他のメソッドはそうではありません。べき等 URL の再試行では、サーバーまたはデータベースの値が変更されてはいけません。ユーザーが受信する応答が変更されるだけです。
べき等要求の例としては、検索エンジンクエリーやデータベースクエリーがあります。基礎となる原則は、再試行によってデータの更新や変更が発生しないことです。
配備されたアプリケーションの可用性を向上させるには、ロードバランサによって処理されたすべてのアプリケーションサーバーインスタンスに、失敗したべき等の HTTP 要求を再試行するを環境を設定します。このオプションは、検索要求の再試行など、読み取り専用の要求に使用されます。
sun-web.xml ファイルに、べき等 URL を設定します。ロードバランサ設定をエクスポートする場合、べき等 URL の情報は自動的に loadbalancer.xml ファイルに追加されます。
べき等 URL の設定の詳細については、『Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide』の「Configuring Idempotent URL Requests」を参照してください。