ロードバランスの設定

この章では、HTTP 要求のロードバランスの設定方法、およびロードバランスプラグインの設定方法と管理方法を説明します。

ロードバランスについて

SunTM Open Net Environment (ONE) Application Server 7, Enterprise Edition は、ロードバランスと HTTP セッションの持続性を提供します。ロードバランスの目的は、複数の Sun ONE Application Server インスタンスの作業負荷を均等に分散させて、システム全体のスループットを向上させることです。

ロードバランスプラグインは、Sun ONE Application Server 7, Standard Edition で使われる HTTP リバースプロキシプラグインの拡張バージョンです。リバースプロキシプラグインの詳細は、『Sun ONE Application Server 7, Standard Edition 管理者ガイド』の第 7 章「Web サーバープラグインの設定」を参照してください。

ロードバランスのアルゴリズム

Sun ONE Application Server のロードバランサでは、着信した HTTP 要求や HTTPS 要求のロードバランスを行うために、スティッキーなラウンドロビンアルゴリズムを使います。つまり、1 つのセッションのすべての要求が同じアプリケーションサーバーインスタンスに送信されます。スティッキーなロードバランサでは、セッションデータは、1 つのクラスタ内のすべてのインスタンスに分散させる必要はなく、1 つのアプリケーションサーバーにキャッシュできます。

したがって、スティッキーなラウンドロビン方式によりパフォーマンスが大幅に改善され、通常は、純粋なラウンドロビン方式でより均等にロードバランスを行う場合よりも大きな効果が得られます。

スティッキーなラウンドロビンアルゴリズムによるロードバランスについて

新しい HTTP 要求がロードバランスプラブインに送信されると、その要求は単純なラウンドロビン方式に基づいてアプリケーションサーバーインスタンスに転送されます。その後、この要求は、cookie の使用または URL の明示的な書き換えによって、その特定のアプリケーションサーバーインスタンスに「貼り付け」されます。

ロードバランスプラグインでは最初に、スティキーの情報に基づいて、その要求の転送元のインスタンスを特定します。転送元のインスタンスが正常であると判定された場合、ロードバランスプラグインはその要求を特定のアプリケーションサーバーインスタンスに転送します。したがって、1 つのセッションに対応するすべての要求が同じアプリケーションサーバーインスタンスに送信されます。

ロードバランスプラグインでは、次の方法でセッションのスティック状態を判定します。

Cookie に基づく方法

cookie に基づく方法の場合、ロードバランスプラグインはルーティング情報の記録に個別の cookie を使います。

URL の明示的な書き換えによる方法

URL の明示的な書き換えによる方法の場合、スティッキーの情報は URL に付加されます。この方法は、ブラウザが cookie をサポートしていない場合でも実行できます。

ロードバランスの要件

ロードバランスプラグインを使用するには、次の要件を満たしている必要があります。


注	cookie に基づく方法を行うには、ブラウザが cookie をサポートしている必要があります。

ロードバランスプラグインの設定

Web サーバーの設定の変更

ロードバランスプラグインのインストールプログラムは、Web サーバーの設定ファイルにいくつかの変更を加えます。この節では、次の Web サーバーの設定ファイルに対する変更について詳しく説明します。

Sun ONE Web Server の設定の変更

Apache Web サーバーの設定の変更



注	ロードバランスプラグインは、Sun ONE Application Server 7, Enterprise Edition とともにインストールすることも、ロードバランスプラグインがサポートする Web ブラウザが稼働できるマシンに独立してインストールすることもできます。インストール手順の詳細は、『Sun ONE Application Server インストールガイド』を参照してください。

Sun ONE Web Server の設定の変更

インストールプログラムは、Sun ONE Web Server の設定ファイルに次のような変更を加えます。

Web サーバーインスタンスの magnus.conf ファイルに、ロードバランスプラグイン固有の次のようなエントリを追加します。

##EE lb-plugin
Init fn="load-modules" shlib="webserver_install_dir/webserver_instance/plugins/lbplugin/bin/libpassthrough.so" funcs="init-passthrough,service-passthrough,name-trans-passthrough" Thread="no"

Init fn="init-passthrough"

##end addition for EE lb-plugin

Web サーバーインスタンスの obj.conf ファイルに、ロードバランスプラグイン固有の次のようなエントリを追加します。

NameTrans fn="name-trans-passthrough" name="lbplugin" config-file="webserver_install_dir/webserver_instance/config/loadbalancer.xml"

<Object name="lbplugin">
ObjectType fn="force-type" type="magnus-internal/lbplugin"
PathCheck fn="deny-existence" path="*/WEB-INF/*"
Service type="magnus-internal/lbplugin" fn="service-passthrough"
Error reason="Bad Gateway" fn="send-error" uri="$docroot/badgateway.html"
</object>

lbplugin は Object を一意に特定する名前、webserver_install_dir/webserver_instance/config/loadbalancer.xml は、ロードバランサを実行するように設定された仮想サーバーの XML 設定ファイルの場所です。

ここで、loadbalancer.xml 設定ファイルを編集して、ロードバランスプラグインを設定する必要があります。loadbalancer.xml ファイルの編集方法の詳細は、「ロードバランサの設定ファイルの作成」を参照してください。

Apache Web サーバーの設定の変更

ロードバランスプラグインのインストールプログラムは、Web サーバーのルートディレクトリの下にある modules フォルダに必要なファイルを抽出します。また、Web サーバーインスタンスの httpd.conf ファイルにロードバランスプラグイン固有の次のエントリを追加します。

LoadModule apachelbplugin_module libexec/mod_loadbalancer.so
#AddModule mod_apachelbplugin.cpp
<IfModule mod_apachelbplugin.cpp>
config-file webserver_instance/config/loadbalancer.xml
locale en
</IfModule>

<VirtualHost machine_ip_address>
DocumentRoot "webserver_instance/apache/htdocs"
ServerName server_name
</VirtualHost>



注	Apache Web サーバーは、ロードバランスプラグインと正常に協調して動作するように、保護モードで実行する必要がある最初にすべての要求がロードバランスプラグインに転送されるようにするため、URL パターンを / に設定することを推奨。インストールされているアプリケーションと要求が一致しない場合、その要求は Web サーバーにリダイレクトされる apache_install_dir の下に sec_db_files という名前のディレクトリを作成し、apache_install_dir/sec_db_files に <S1AS_installables_dir/sec_db_files/* をコピーする Apache の子のプロセスを複数実行しているとき、各プロセスはそれぞれ独自のロードバランスラウンドロビンシーケンスを持つたとえば、Apache の子のプロセスを 2 つ実行している場合、ロードバランスプラグインは 2 つのアプリケーションサーバーインスタンスに対してロードバランスを行う。つまり、最初の要求はインスタンス #1 に送信され、2 番目の要求もインスタンス #1 に送信される。続いて、3 番目の要求はインスタンス #2 に送信され、4 番目の要求もインスタンス #2 に送信される。このパターン (インスタンス #1、インスタンス #1、インスタンス #2、インスタンス #2、以後同様) が繰り返されるこの動作は、通常ユーザーが考えるパターン (インスタンス #1、インスタンス #2、インスタンス #1、インスタンス #2) とは異なる。このような動作になるのは、Application Server 7, Enterprise Edition では Apache のロードバランスプラグインは、各 Apache プロセスのロードバランスインスタンスをインスタンス化し、その結果、独立したロードバランスシーケンスを作成するためであるロードバランスプラグインの使用は、開発システムのみでサポートされていて、本稼働環境のシステムではサポートされていない

これで、Apache Web サーバーへのロードバランスプラグインのインストールが完了します。

次の各節では、loadbalancer.xml ファイルの作成方法および必要な設定情報の指定方法について説明します。

ロードバランサの設定ファイルの作成

loadbalancer.xml ファイルは、ロードバランサのインストール時に同時にインストールされる sun-loadbalancer_1_0.dtd ファイルと loadbalancer.xml.example ファイルに基づいて作成する必要があります。これらのファイルは、次の場所にあります。

サンプル loadbalancer.xml ファイル

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE loadbalancer PUBLIC "-//Sun Microsystems Inc.//DTD Sun ONE Web Server 6.0//EN" "file:///webserver_install_dir/webserver_instance/config/sun-loadbalancer_1_0.dtd">

<web-module context-root="webapps-simple" enabled="true"/>

</cluster>

</loadbalancer>



注	ロードバランスプラグインの設定時に、次の要件を検討する必要があります。 1 つのロードバランスインスタンスに、名前が同一である 2 つのクラスタを指定することはできない 1 つのクラスタに、名前が同一である 2 つの instance 要素を指定することはできない 1 つのクラスタに、コンテキストルートが同一である 2 つの web-module 要素を指定することはできない listeners は、サーバーまたはクラスタ全体で一意である必要がある listeners 属性は、スペースで区切られた、アプリケーションサーバーインスタンスのリスナーの URL のリストである。したがって、1 つのクラスタ内でも、複数のクラスタ間でも、複数のサーバーインスタンスのリスナー URL を同一にはできないリスナーの属性は次の形式で記述する必要がある http://hostname.domain:port 例: http://austen.sun.com:80 この例で、http://austen.sun.com はアプリケーションサーバーインスタンスのアドレスであり、その後にポート番号 80 が付加されている instance name は変数であり、server1 などのように適切な名前に置き換えることができる HTTPS ルーティングの場合、各アプリケーションサーバーインスタンスの下に専用の HTTPS リスナーを作成することを推奨する例: listeners="http://austen.sun.com:80 https://austen.sun.com:443" この例で、https://austen.sun.com はアプリケーションサーバーインスタンスのアドレスであり、その後にポート番号 443 が付加されている

loadbalancer.xml ファイルに加えられた変更を保存して、Web サーバーを再起動します。



注	Apache Web サーバーの場合、DTD ファイルは conf ディレクトリに格納される。したがって、DTD ファイルを作成する場所は、次の例のように指定する必要がある "file:///webserver_install_dir/webserver_instance/conf/sun-loadbalancer_1_0.dtd"> アプリケーションサーバーインスタンスの作成方法と設定方法については、第 4 章「アプリケーションサーバーインスタンスの使用」を参照 response-timeout-in-seconds プロパティは、ロードバランスが行われた要求の応答を待機するタイムアウト間隔を指定する。この時間内に応答が得られない場合は、エラーページが表示されるクラスタリングの詳細は、第 17 章「クラスタの管理」を参照

複数の Web サーバーインスタンスの設定

Sun ONE Application Server 7, Enterprise Edition のインストーラでは、1 台のマシンに複数のロードバランスプラグインをインストールできません。1 つのクラスタ内であるか複数のクラスタにわたるかに関係なく、1 台のマシン上で (ロードバランスプラグインを持つ) 複数の Web サーバーを使う必要がある場合は、ロードバランスプラグインを手動で設定する必要があります。

複数の Web サーバーインスタンスのロードバランスプラグインを設定するには、次の節に示す手順に従ってください。

複数の Sun ONE Web Server インスタンスの設定

ロードバランスプラグインを設定する Web サーバーインスタンスの magnus.conf ファイルに、次の変更を加えます。

Init fn="load-modules" shlib="webserver_install_dir/webserver_instance/plugins/lbplugin/bin/libpassthrough.so" funcs="init-passthrough,service-passthrough,name-trans-passthrough" Thread="no"

Init fn="init-passthrough"

ロードバランスプラグインを設定する Web サーバーインスタンスの obj.conf ファイルに、次の変更を加えます。

NameTrans fn="name-trans-passthrough" name="lbplugin" config-file="webserver_install_dir/webserver_instance/config/loadbalancer.xml"

<Object name="lbplugin">
ObjectType fn="force-type" type="magnus-internal/lbplugin"
PathCheck fn="deny-existence" path="*/WEB-INF/*"
Service type="magnus-internal/lbplugin" fn="service-passthrough"
Error reason="Bad Gateway" fn="send-error" uri="$docroot/badgateway.html"
</object>

sun-loadbalancer_1_0.dtd ファイルおよび loadbalancer.xml ファイルを、(ロードバランスプラグインで設定済みの) 既存の Web サーバーインスタンスの config ディレクトリからロードバランサで設定済みの新しいインスタンスの config ディレクトリにコピーします。

「ロードバランサの設定ファイルの作成」での説明のとおりに、loadbalancer.xml ファイルを編集します。

複数の Apache Web サーバーインスタンスの設定

Web サーバーインスタンスの httpd.conf ファイルに、ロードバランスプラグイン固有の次のようなエントリを追加します。

##Addition for EE lb-plugin

LoadFile /usr/lib/libCstd.so.1

<VirtualHost machine_ip_address>
DocumentRoot "webserver_instance/apache/htdocs"
ServerName server_name
</VirtualHost>

##END EE LB Plugin Parameters

sun-loadbalancer_1_0.dtd ファイルおよび loadbalancer.xml ファイルを、(ロードバランスプラグインで設定済みの) 既存の Web サーバーインスタンスの conf ディレクトリからロードバランサで設定済みの新しいインスタンスの conf ディレクトリにコピーします。

「ロードバランサの設定ファイルの作成」での説明のとおりに、loadbalancer.xml ファイルを編集します。

応答タイムアウトの設定

ロードバランサの設定ファイル (loadbalancer.xml) には、ロードバランスが行われた要求の応答を待機するタイムアウト間隔を示す response-timeout-in-seconds プロパティが指定されています。この時間内に応答が得られない場合は、エラーページが表示されます。デフォルト値は 60 秒です。

response-timeout-in-seconds プロパティを設定するときには、実行中のすべてのアプリケーションの最長タイムアウト時間を考慮する必要があります。このプロパティの値は、すべてのアプリケーションの最長応答時間に設定する必要があります。

HTTPS ルーティングの設定

この節では、Web サーバーと Sun ONE Application Server の間で HTTP/HTTPS ルーティングとセッションフェイルオーバーを有効化するための、ロードバランスプラグインの設定方法について説明します。あるセッションの接続先となる本来のアプリケーションサーバーインスタンスが利用できなくなった場合に、ロードバランスプラグインでは HTTP/HTTPS セッションを別のアプリケーションサーバーインスタンスにフェイルオーバーします。

HTTPS ルーティングについて

HTTP であるか HTTPS (セキュリティ保護された HTTP) であるかに関係なく、受信したすべての要求はロードバランスプラグインによってアプリケーションサーバーインスタンスにルーティングされます。ただし、HTTPS ルーティングが有効化されている場合、HTTPS 要求はロードバランスプラグインによって、HTTPS ポートを使用するアプリケーションサーバーのみに転送されます。HTTPS ルーティングは、新しい要求およびスティッキーな要求の両方に対して実行されます。

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

実行中の HTTP セッションでは、同じセッションに対する新しい HTTPS 要求が着信すると、HTTP セッションの際に保存されたセッション情報とスティッキーの情報を使って HTTPS 要求を転送します。新しい HTTPS 要求は、最後に HTTP 要求を処理したサーバー (ただし、HTTPS ポートがあるもの) にルーティングされます。

HTTPS ルーティングの設定

https-routing プロパティでは、ロードバランスの対象となるすべてのアプリケーションサーバーについて、HTTPS ルーティングを有効にするか無効にするかを制御します。このプロパティを false に設定した場合、HTTP 要求と HTTPS 要求はすべて HTTP として転送されます。

HTTPS ルーティングとフェイルオーバーを設定するには、次の手順に従います。

ヘルスチェッカの設定


注	HTTPS ルーティングが正常に機能するように、1 つ以上の HTTPS リスナーを設定しておく必要がある https-routing が true に設定されているときに、新しい要求またはスティッキーな要求が着信した場合、クラスタ内に正常な HTTPS リスナーが存在しないとその要求は失敗する

ロードバランサは、health-checker 要素に指定した値に基づいて、設定済みのすべての Sun ONE Application Server インスタンスで異常としてマーク付けされたものがないかどうかを定期的に確認します。ヘルスチェッカの有効化の指定は省略できます。ヘルスチェッカが有効化されていない場合、異常なインスタンスに関する定期的なヘルスチェックは実行されません。

ロードバランサのヘルスチェックメカニズムでは、HTTP を使ってアプリケーションサーバーインスタンスと通信します。ヘルスチェッカは、指定された URL に HTTP 要求を送信し、その応答を待機します。HTTP 応答ヘッダーの状態コードが 100 ～ 500 の範囲であれば、インスタンスが正常であると判定できます。

ヘルスチェッカを有効化するには、loadbalancer.xml ファイル内の次のプロパティを編集します。

アプリケーションサーバーインスタンスが異常としてマーク付けされている場合、ヘルスチェッカは異常なインスタンスのポーリングを行い、そのインスタンスが正常になっているかどうかを確認します。ヘルスチェッカは url 属性を使って、すべての異常なアプリケーションサーバーインスタンスについて、これらが正常な状態に戻っているかどうかを確認します。

ヘルスチェッカは、異常なインスタンスが正常な状態に戻っていることを確認できた場合、そのインスタンスを正常なインスタンスのリストに追加します。

静止の設定

静止とは、アプリケーションサーバーインスタンスや Web アプリケーションを適切に無効化するプロセスのことです。ユーザーは静止時間と呼ばれる有効期限を設定できます。この時間内に、ロードバランスプラグインはスティッキーな要求をクラスタ内の正常な別のインスタンスにフェイルオーバーします。

何らかの理由で (たとえば、JDBC リソースを追加するために) アプリケーションサーバーインスタンスを停止する場合、そのインスタンスでの要求の処理が完了した後に停止したいことがあります。また、クラスタから Web アプリケーションの配備を取り消す場合、そのアプリケーションで要求の処理が完了した後に配備を取り消したいこともあります。そのためには、静止プロセスを使用します。

アプリケーションまたはアプリケーションサーバーインスタンスを静止させることができます。次の各節では、それぞれの静止方法について説明します。

インスタンスの静止

ロードバランサでは、アプリケーションサーバーインスタンスの静止に次のポリシーを適用します。

インスタンスが無効化されていて、タイムアウトの有効期限に達していない場合、スティッキーな要求は引き続きそのインスタンスに配信される。ただし、新しい要求は無効化されているインスタンスに送信されない

タイムアウトの有効期限を過ぎると、インスタンスは無効化される。そのインスタンスに貼り付けられているすべてのセッションが有効な場合でも、ロードバランサはそのインスタンスに要求を送信しない。ロードバランサからこのインスタンスに対して開かれているすべての接続は、閉じられる。ロードバランサは代わりに、スティッキーな要求を同じクラスタ内にある正常な別のインスタンスにフェイルオーバーする

アプリケーションの静止

ロードバランサでは、アプリケーションの静止に次のポリシーを適用します。

アプリケーションが無効化されていて、タイムアウトの有効期限に達していない場合、ロードバランサは無効化されているアプリケーションに対する新しい要求を転送しない。このような要求は、Web サーバーに返される。スティッキーな要求は、タイムアウトの有効期限を過ぎるまで、転送が続行される

タイムアウトの有効期限を過ぎると、アプリケーションは無効化される。ロードバランサは、スティッキーな要求を含め、このアプリケーションに対するすべての要求を受け入れない



注	アプリケーションを静止すると、無効化されたアプリケーションのユーザーは、そのアプリケーションが再び有効化されるまでそのアプリケーションのサービスを利用できなくなります。

動的再設定について

ロードバランスプラグインは、loadbalancer.xml ファイルのタイムスタンプを確認することによって、設定の変更を検出します。loadbalancer.xml ファイルに変更が加えられている場合、ロードバランサ自体の設定が自動的に再設定されます。

ロードバランサが loadbalancer.xml ファイルのタイムスタンプを確認する時間間隔は、loadbalancer.xml ファイルの reload-poll-interval-in-seconds プロパティで指定できます。デフォルトでは、このプロパティの値は 0 秒に設定されていて、動的再設定は無効化されています。



注	sun-loadbalancer_1_0.dtd で指定したとおりの正しい形式で loadbalancer.xml ファイルが変更されていない場合、再設定の処理は失敗する。失敗の通知メッセージが、Web サーバーのエラーログファイルに表示されるロードバランサは、すでにメモリに読み込まれている以前の設定を引き続き使用するロードバランサがそれ自身の再設定を試行しているときにハードディスクの読み込みエラーが発生した場合、ロードバランサはその時点でメモリ内にある設定を使用する。また、ロードバランサは、既存の設定を上書きする前に、変更後の設定データが DTD に準拠しているかどうかを確認するディスクの読み込みエラーが発生した場合、警告メッセージが Web サーバーのエラーログファイルに記録される Sun ONE Web Server のエラーログファイルは次の場所にある webserver_install_dir/webserver_instance/logs/

ロードバランスプラグインの監視

ログメッセージの設定

ロードバランスプラグインでは、Web サーバーのログメカニズムを使ってログメッセージを書き込みます。ロードバランスプラグインは、各 Web サーバーのデフォルトのログレベルを使います (Sun ONE Web Server では INFO、Apache Web Server では WARN)。アプリケーションサーバーのログレベル (FINE、FINER、および FINEST) は、Web サーバーの DEBUG レベルにマップされています。

これらのログメッセージは、スクリプトで解析可能な生データの形式で Web サーバーのログファイルに書き込まれ、必要に応じてメトリックの計算のためにスプレッドシートにインポートされます。

監視の設定

ロードバランスプラグインのログメッセージを有効化するには、次の手順に従います。

ロードバランスプラグインのログに、次の情報が記録されます。

すべての要求について、要求の開始と停止に関する情報がログに記録されます。

異常なインスタンスから正常なインスタンスに要求がフェイルオーバーされた場合は、フェイルオーバーされた要求の情報がログに記録されます。

各ヘルスチェックサイクルの終了時に、異常なインスタンスのリストがログに記録されます。



注	ロードバランスプラグインでログが有効化されている場合に、Web サーバーのログレベルが DEBUG に設定されているとき、または詳細メッセージを表示するように設定されているときに、ロードバランサは Web サーバーのログファイルに HTTP セッションの ID を書き込みます。したがって、ロードバランスプラグインをホストする Web サーバーが DMZ 内にある場合、本稼働環境では DEBUG またはこれに類似するログレベルの使用はお勧めできません。 DEBUG ログレベルを使う必要がある場合は、loadbalancer.xml ファイルの require-monitor-data プロパティを false に設定して、ロードバランサのログを無効化してください。

監視メッセージについて

ロードバランスプラグインのログメッセージの形式は、次のとおりです。

RequestStart Sticky(New) <req-id> <time-stamp> <URL>

タイムスタンプの値は、1970 年 1 月 1 日からのミリ秒数。例 :

RequestStart New 123456 602983 http://austen.sun.com/Webapps-simple/servlet/Example1

RequestExit Sticky(New) <req-id> <time-stamp> <URL> <listener-id> <response-time> Failure-<reason for error>(incase of a failure)

例 :

RequestExit New 123456 603001 http://austen.sun.com/Webapps-simple/servlet/Example1 http://austen:2222 18



注	RequestExit メッセージの <response-time> は、ロードバランスプラグインから見た要求の合計ターンアラウンドタイムをミリ秒単位で表しています。

UnhealthyInstances <cluster-id> <time-stamp> <listener-id>, <listener-id>...

例 :

UnhealthyInstances cluster1 701923 http://austen:2210, http://austen:3010

FailedoverRequest <req-id> <time-stamp> <URL> <session-id> <failed-over-listener-id> <unhealthy-listener-id>

例 :

FailedoverRequest 239496 705623 http://austen.sun.com/Apps/servlet/SessionTest 16dfdac3c7e80a40 http://austen:4044 http://austen:4045

ロードバランサの設定ファイル

loadbalancer.xml ファイルには、SunTM Open Net Environment (ONE) Application Server インスタンスのロードバランスを行うための設定情報が保存されています。このファイルは、フロントエンドの Web サーバーのロードバランスプラグインの一部です。このファイルは Web サーバー内にありますが、その重要性および Sun ONE Application Server との関連性から、このマニュアルでも説明します。

一般的な UNIX テキストエディタとの互換性を維持するため、loadbalancer.xml ファイルのエンコーディングは UTF-8 になっています。スキーマファイル sun-loadbalancer_1_0.dtd は、loadbalancer.xml ファイルの書式と内容を定義します。

この章には、loadbalancer.xml ファイルおよび sun-loadbalancer_1_0.dtd ファイルについて説明する次の節があります。

sun-loadbalancer_1_0.dtd ファイル

sun-loadbalancer_1_0.dtd ファイルは、loadbalancer.xml ファイルの構造を定義します。つまり、loadbalancer.xml に記述できるさまざまな要素と、その要素が持つことのできるサブ要素や属性を定義しています。

DTD ファイルおよび XML の全般的な情報については、次のサイトにある XML 仕様を参照してください。

DTD ファイルに定義された各要素 (対応する XML ファイル内に置かれている場合もある) には、次の要素が含まれています。

サブ要素


注	sun-loadbalancer_1_0.dtd ファイルを編集しないでください。このファイルの内容は、Sun ONE Application Server, Enterprise Edition のバージョンの改訂にともなって変更されます。


注	sun-loadbalancer_1_0.dtd インタフェースは、不確定です。不確定なインタフェースは試験的または一時的なインタフェースであるため、次のリリースで互換性がなくなったり、削除されたり、または安定したインタフェースに置き換えられたりする場合があります。

要素にはサブ要素を含めることができます。たとえば、次のファイルコードは cluster 要素を定義します。

この ELEMENT タグは、cluster 要素に instance、web-module、および health-checker 要素をこの順番で含めることができることを示しています。

次の表に、サブ要素のサフィックス文字 (省略可能) によって決まる必要指定数、つまり指定可能なサブ要素の数を示します。左の列にサブ要素の末尾文字、右の列に対応する必要指定数を示します。

表 16-1 必要指定数とサブ要素のサフィックス
サブ要素のサフィックス	必要指定数
element*	このサブ要素を含まないか、1 個以上含めることができる
element?	このサブ要素を含まないか、1 個含めることができる
element+	このサブ要素を 1 個以上含まなければならない
element (サフィックスなし)	このサブ要素を 1 個だけ含まなければならない

要素にほかの要素を含めることができない場合は、カッコで囲まれた要素名のリストの代わりに、EMPTY または (#PCDATA) が表示されます。

データ

要素の中には、サブ要素の代わりに文字データを含むものもあります。これらの要素は、次の形式で定義されます。

loadbalancer.xml ファイル内では、データ要素内の空白スペースはデータの一部として扱われます。そのため、データ要素で区切られたデータの前後には余分な空白がないようにする必要があります。次に例を示します。

属性

ATTLIST タグを持つ要素には属性 (名前 - 値のペア) が含まれています。次に例を示します。

<!ATTLIST instance   name           CDATA      #REQUIRED
                     enabled        %boolean;  "true"
                     disable-timeout-in-minutes  CDATA  "31"
                     listeners      CDATA      #REQUIRED>

instance 要素には、name、enabled、disable-timeout-in-minutes、および listeners という属性を指定することができます。

#REQUIRED ラベルは、値を指定する必要があることを示します。#IMPLIED ラベルは、その属性の指定は省略可能であり、Sun ONE Application Server がデフォルト値を生成することを示します。可能な場合は、"true" などの明示的なデフォルト値が示されます。

属性宣言は、属性のタイプを指定します。たとえば、CDATA は文字データ、%boolean は事前定義された列挙型データを表します。

loadbalancer.xml ファイル内の要素

この節では、loadbalancer.xml ファイル内の XML 要素について説明します。

loadbalancer


注	特に指定しない限り、サブ要素は各サブ要素欄に示されている順に定義する必要があります。

ロードバランサを定義します。これはルート要素であり、loadbalancer.xml ファイル内には loadbalancer 要素が 1 つだけ存在します。

サブ要素

次の表では、loadbalancer 要素のサブ要素について説明しています。左の列にサブ要素名、中央の列に必要指定数、右の列に要素の説明を示します。

表 16-2 loadbalancer のサブ要素
要素	必要指定数	説明
cluster	0 または 1 個以上	サーバーインスタンスのクラスタを定義する
property	0 または 1 個以上	ロードバランサのプロパティを指定する

属性

property

サブ要素

次の表に、property 要素のサブ要素を示します。左の列にサブ要素名、中央の列に必要指定数、右の列に要素の説明を示します。

属性

表 16-3 property のサブ要素
要素	必要指定数	説明
description	0 または 1 個	この要素を説明するテキストを含む

次の表に、property 要素の属性を示します。左の列に属性の名前、中央の列にデフォルト値、右の列にその属性の説明を示します。

表 16-4 property の属性
属性	デフォルト値	説明
name	なし	プロパティの名前を指定する
value	なし	プロパティの値を指定する

プロパティ

次の表に、ロードバランサのプロパティを示します。左の列にプロパテイの名前、中央の列にデフォルト値、右の列にそのプロパテイの説明を示します。

表 16-5 ロードバランサのプロパティ
プロパティ名	デフォルト値	説明
response-timeout-in-seconds	60	ロードバランスが行われた要求の応答を待機するタイムアウト間隔を指定する。この時間内に応答が得られない場合は、クライアントにエラーページが送信される
reload-poll-interval-in-seconds	0	loadbalancer.xml ファイルのタイムスタンプが変更されているかどうかをロードバランサが確認する間隔を指定する。変更されている場合、ロードバランサはファイルを再読み込みする 0 の場合、ポーリングは無効化される
https-routing	false	着信した HTTPS 要求を、ロードバランサが HTTPS 要求としてインスタンスにルーティングするかどうかを指定する
require-monitor-data	false	ロードバランサによる監視を有効化するかどうかを指定する

description

サブ要素

属性

cluster

サブ要素

次の表では、cluster 要素のサブ要素について説明しています。左の列にサブ要素名、中央の列に必要指定数、右の列に要素の説明を示します。

表 16-6 cluster のサブ要素
要素	必要指定数	説明
instance	0 または 1 個以上	サーバーインスタンスを定義する
web-module	0 または 1 個以上	Web モジュールを定義する
health-checker	0 または 1 個	クラスタのヘルスチェッカを設定する

属性

次の表では、cluster 要素の属性について説明しています。左の列に属性の名前、中央の列にデフォルト値、右の列にその属性の説明を示します。

instance

サブ要素

属性

表 16-7 cluster の属性
属性	デフォルト値	説明
name	なし	クラスタの名前を指定する。クラスタの名前は、1 つのロードバランサ内で一意にする必要がある

次の表では、instance 要素の属性について説明しています。左の列に属性の名前、中央の列にデフォルト値、右の列にその属性の説明を示します。

表 16-8 instance の属性
属性	デフォルト値	説明
name	なし	サーバーインスタンスの名前を指定する。インスタンスの名前は、1 つのクラスタ内で一意にする必要がある
enabled	true	(省略可能) ロードバランスの対象となる要求に対応するインスタンスをアクティブにする (有効化する) かどうかを指定する
disable-timeout-in-minutes	31	(省略可能) 静止のタイムアウト間隔を指定する。この時間の経過後に、ロードバランサはインスタンスを無効化し、そのインスタンスに対して開かれているすべての接続を閉じる
listeners	なし	スペースで区切られたリストで、インスタンスのリスナーの URL を指定する。リスナーの URL は、1 つのクラスタ内で一意にする必要がある

web-module

サブ要素

属性

次の表は、web-module 要素の属性を示します。左の列に属性の名前、中央の列にデフォルト値、右の列にその属性の説明を示します。

表 16-9 web-module の属性
属性	デフォルト値	説明
context-root	なし	Web モジュールのコンテキストルートを指定する。コンテキストルートは、1 つのクラスタ内で一意にする必要があるデフォルトのコンテキストルートは、スペース (" ") またはスラッシュ ("/") で指定できる。また、先頭にスラッシュ (/) を付けて指定することもできるクラスタ内で空のコンテキストルートが具体的なコンテキストルートとともに使われる場合、ロードバランスプラグインでは具体的なコンテキストルートが優先される
enabled	true	(省略可能) ロードバランスの対象となる要求に対応する Web モジュールをアクティブにする (有効化する) かどうかを指定する
disable-timeout-in-minutes	31	(省略可能) 静止のタイムアウト間隔を指定する。この時間の経過後に、ロードバランサは Web モジュールを無効化し、その Web モジュールに対して開かれているすべての接続を閉じる

health-checker

サブ要素

属性

次の表では、health-checker 要素の属性について説明しています。左の列に属性の名前、中央の列にデフォルト値、右の列にその属性の説明を示します。

表 16-10 health-checker のプロパティ
属性	デフォルト値	説明
url	/	(省略可能) リスナーの状態が正常であるかどうかを ping で確認するための URL を指定する
interval-in-seconds	30	(省略可能) インスタンスのヘルスチェックの実行間隔を指定します。
timeout-in-seconds	10	(省略可能) リスナーの応答を待機する時間について、正常と認識されるタイムアウト間隔を指定する

ロードバランスの要求に関する既知の問題

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

第 16 章 ロードバランスの設定

ロードバランスについて

ロードバランスのアルゴリズム

スティッキーなラウンドロビンアルゴリズムによるロードバランスについて

Cookie に基づく方法

URL の明示的な書き換えによる方法

ロードバランスの要件

ロードバランスプラグインの設定

Web サーバーの設定の変更

Sun ONE Web Server の設定の変更

Apache Web サーバーの設定の変更

ロードバランサの設定ファイルの作成

サンプル loadbalancer.xml ファイル

複数の Web サーバーインスタンスの設定

複数の Sun ONE Web Server インスタンスの設定

複数の Apache Web サーバーインスタンスの設定

応答タイムアウトの設定

HTTPS ルーティングの設定

HTTPS ルーティングについて

HTTPS ルーティングの設定

ヘルスチェッカの設定

静止の設定

インスタンスの静止

アプリケーションの静止

動的再設定について

ロードバランスプラグインの監視

ログメッセージの設定

監視の設定

監視メッセージについて

ロードバランサの設定ファイル

sun-loadbalancer_1_0.dtd ファイル

サブ要素

データ

属性

loadbalancer.xml ファイル内の要素

loadbalancer

サブ要素

属性

property

サブ要素

属性

プロパティ

description

サブ要素

属性

cluster

サブ要素

属性

instance

サブ要素

属性

web-module

サブ要素

属性

health-checker

サブ要素

属性

ロードバランスの要求に関する既知の問題

第 16 章
ロードバランスの設定