Red Hat Training
A Red Hat training course is available for Red Hat JBoss Web Server
HTTP コネクタ負荷分散ガイド
HTTP load balancing for JBoss Enterprise Application Platform and Red Hat JBoss Web Server
エディッション 1.0.2
Samuel Mendenhall
James Livingston
Jim Tyrell
概要
はじめに
1. ファイル命名規則
- JBOSS_EAP_DIST
- JBoss Enterprise Application Platform インスタンスのインストールルート。このフォルダには
/jboss-as、/seam、/resteasyなどの、サーバーを構成する主要なフォルダが含まれます。 - JBOSS_EwP_DIST
- JBoss Enterprise Web Platform インスタンスのインストールルート。このフォルダには
/jboss-as-web、/seam、/resteasy. などの、サーバーを構成する主要なフォルダが含まれます。 - JBOSS_EWS_DIST
- JBoss Enterprise Web Server インスタンスのインストールルート。このフォルダには
/extras、/httpd、/tomcat6などの、サーバーを構成する主要なフォルダが含まれます。 - NATIVE
- JBoss Native zip のインストールルート。JBOSS_EAP_DIST と同じディレクトリレベルに抽出されます。
- SJWS
- Sun Java Web Server インスタンスのインストールルート。この命名規則のデフォルトのファイル場所は以下のとおりです。
- Solaris 9 x86 または SPARC 64 の場合:
/opt/SUNWwbsrv61/ - Solaris 10 x86 または SPARC 64 の場合:
/opt/SUNWwbsrv70/
- HTTPD_DIST
- Apache httpd Server のインストールルート。このフォルダには、
/conf、/webapps、/binなどの、サーバーを構成する主要なフォルダが含まれます。JBoss Enterprise Web Server JBOSS_EWS_DIST ディレクトリには、HTTPD_DIST のルートインストールが含まれます。 - PROFILE
- テスト用または本番稼働用の設定の一部として使用する JBoss サーバープロファイルの名前。サーバープロファイルは、
JBOSS_EAP_DIST/jboss-as/serverまたはJBOSS_EWS_DIST/jboss-as-web/serverに存在します。
パート I. Apache Tomcat Connector
第1章 概要
- セッションステートのレプリケーション
- HTTP 要求の負荷分散
第2章 ダウンロードとインストール
第3章 Apache と mod_jk を使用した負荷分散の設定
タスク : mod_jk をロードするために Apache を設定する。
前提条件
- Apache と mod_jk がインストールされている (Refer to 2章ダウンロードとインストール を参照)。
HTTPD_DIST/conf/httpd.confを開いて、ファイルの最後に 1 行追加します。# Include mod_jk's specific configuration file Include conf/mod-jk.conf
HTTPD_DIST/conf/mod-jk.confという新しいファイルを作成します。mod-jk.confファイルに次の設定を追加します。重要
LoadModuleディレクティブはインストールしたネイティブバイナリに適用可能な mod_jk ライブラリディレクトリの場所を参照する必要があります。注記
JkMountディレクティブは Apache が mod_jk モジュールにどの URL を転送すべきか指定します。ディレクティブの設定に基づき、mod_jk は受信した URL を正しい Servlet コンテナに転送します。Apache が静的コンテンツ (または PHP コンテンツ) に直接対応し、Java アプリケーションにロードバランサを使用可能なようにするためには、推奨される設定は/application/*が mod_jk ロードバランサに送られる URL パスですべての要求を指定します。ロードバランサとして mod_jk だけを使用している場合は、ディレクティブの/*を指定することですべての URL を mod_jk に転送します。# Load mod_jk module # Specify the filename of the mod_jk lib LoadModule jk_module modules/mod_jk.so # Where to find workers.properties JkWorkersFile conf/workers.properties # Where to put jk logs JkLogFile logs/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y]" # JkOptions indicates to send SSK KEY SIZE JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat JkRequestLogFormat "%w %V %T" # Mount your applications JkMount /application/* loadbalancer # Add shared memory. # This directive is present with 1.2.10 and # later versions of mod_jk, and is needed for # for load balancing to work properly JkShmFile logs/jk.shm # Add jkstatus for managing runtime data <Location /jkstatus/> JkMount status Order deny,allow Deny from all Allow from 127.0.0.1 </Location>オプション : JKMountFile ディレクティブ
JkMountディレクティブに加え、JkMountFileディレクティブを使用して、マウントポイント設定ファイルを指定することもできます。その設定ファイルには複数の Tomcat 転送 URL マッピングが含まれています。HTTPD_DIST/confに移動します。uriworkermap.propertiesという名前のファイルを作成します。- 転送する URL と次の構文サンプルをガイドとして使用してワーカー名を指定します。サンプルブロックは mod_jk を設定し、
/jmx-consoleと/web-consoleへの要求を Apache に転送します。必要な構文の形式は/url=worker_nameです。# Simple worker configuration file # Mount the Servlet context to the ajp13 worker /jmx-console=loadbalancer /jmx-console/*=loadbalancer /web-console=loadbalancer /web-console/*=loadbalancer
HTTPD_DIST/conf/mod-jk.confでは、次のディレクティブを追加します。# You can use external file for mount points. # It will be checked for updates each 60 seconds. # The format of the file is: /url=worker # /examples/*=loadbalancer JkMountFile conf/uriworkermap.properties
3.1. mod_jk のワーカーノードの設定
タスク : mod_jk ワーカーノードを設定する。
前提条件
- 付録A workers.properties リファレンス で説明されているとおり
workers.propertiesディレクティブの形式を理解します。
HTTPD_DIST/conf/に移動します。workers.propertiesという名前のファイルを作成します。workers.propertiesファイルに次の情報を追加します。# Define list of workers that will be used # for mapping requests worker.list=loadbalancer,status # Define Node1 # modify the host as your host IP or DNS name. worker.node1.port=8009 worker.node1.host=node1.mydomain.com worker.node1.type=ajp13 worker.node1.ping_mode=A worker.node1.lbfactor=1 # Define Node2 # modify the host as your host IP or DNS name. worker.node2.port=8009 worker.node2.host=node2.mydomain.com worker.node2.type=ajp13 worker.node2.ping_mode=A worker.node2.lbfactor=1 # Load-balancing behavior worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 # Status worker for managing load balancer worker.status.type=status
3.2. mod_jk と動作するよう JBoss を設定する
タスク : mod_jk を使用して JBoss Enterprise Application Platform が動作するよう設定する。
前提条件
- タスク : mod_jk ワーカーノードを設定する。 を完了する。
- クラスタ化したサーバーインスタンスの場所に移動します。
JBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy/jbossweb.sar/server.xmlを開きます。- ノード名を指定するには、
server.xmlの <Engine> 要素に jvmRoute 属性を追加します。jvmRoute 属性値はHTTPD_DIST/conf/workers.propertiesで定義されたノード名です。<!--Preceeding syntax removed for readability --> <Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1"> <!--Proceeding syntax removed for readability --> </Engine>
重要
クラスタ内で複数のサーバーノードを設定するつもりの場合は、このステップを繰り返すたびに jvmRoute 属性値を一意の名前に変更するようにしてください。 server.xmlで、AJP プロトコル <connector> 要素が有効であることを確認してください (非コメント化)。その要素は新しいインストールではデフォルトで非コメント化されています。<Connector protocol="AJP/1.3" port="8009" address="${jboss.bind.address}" redirectPort="8443" />- これで
mod_jkロードバランサを使って Apache httpd Server を正しく設定することができました。これによりクラスタ内のサーブレットコンテナへの呼び出しを分散し、同じサーブレットコンテナ (スティッキーセッション) を使用することができます。
注記
パート II. JBoss HTTP Connector
第4章 概要
4.1. 主な特徴
- Apache HTTP Server ベース
- JBoss HTTP Connector mod-cluster はプロキシサーバーとして Apache を使用します。
- リアルタイムの負荷分散の計算
- JBoss HTTP Connector mod_cluster はワーカーノードとプロキシサーバー間のフィードバックネットワークを作成します。mod_cluster サービスは各ワーカーノードにデプロイされています。このサービスはプロキシサーバーにリアルタイムの負荷情報をフィードします。 次にプロキシサーバーは各ワーカーノードの現在の負荷に基づきワークを割り振る場所に関してインテリジェントな決定を行います。このリアルタイムの適応した負荷分散によりリソースの最適化が向上します。ワーカーノードにより報告された情報およびプロキシにより使用された負荷分散ポリシーは両方ともカスタマイズ可能です。
- リアルタイムアプリケーションライフサイクルに基づいたルーティング
- ワーカーノードにデプロイされた JBoss HTTP Connector mod_cluster サービスはアプリケーションライフサイクルイベントをプロキシサーバーにリレーします。これによりサーバーは動的にそのルーティングテーブルを更新できます。アプリケーションがあるノードでデプロイ解除されると、プロキシサーバーはそのノードに対しそのアプリケーションのトラフィックをルーティングしないようになります。
- プロキシの自動検出
- プロキシサーバーは UDP マルチキャストを介してその存在を知らせるように設定できます。新しいワーカーノードはプロキシサーバーを検出し、それらを自動的に負荷分散クラスタに追加します。これにより必要な設定と管理を大幅に縮小することができます。UDP マルチキャストが使用不可能または希望するものでない場合、ワーカーノードはプロキシの静的リストで設定されます。
- 複数のプロトコル対応
- JBoss HTTP Connector mod_cluster は HTTP、HTTPS、または Apache JServ Protocol (AJP) を使用して、プロキシとワーカーノード間の通信を行うことができます。
4.2. コンポーネント
プロキシサーバー
- Shared Memory Manager:
mod_slotmem.so - Shared Memory Manager モジュールの mod_slotmem はリアルタイムワーカーノード情報を複数の Apache サーバープロセスに対して使用できるようにします。
- Cluster Manager Module:
mod_manager.so - Cluster Manager モジュールの mod_manager はノードからワーカーノード登録、ワーカーノード負荷データ、ワーカーノードのアプリケーションライフサイクルイベントなどのメッセージを受信し、認識します。
- Proxy Balancer Module:
mod_proxy_cluster.so - Proxy Balancer Module の mod_proxy_cluster はクラスタノードに対し要求のルーティングを処理します。Proxy Balancer はクラスタ内のアプリケーションの場所、各クラスタノードの現在のステート、Session ID (要求が確率したセッションの一部の場合) に基づき、要求を転送する該当するノードを選択します。
- Proxy Advertisement Module:
mod_advertise.so - Proxy Advertisement Module の mod_advertise.so は、UDP マルチキャストメッセージを介してプロキシサーバーの存在をブロードキャストします。サーバー告知のメッセージには、負荷分散クラスタに加わりたいノードからの応答に対しプロキシがリッスンする IP アドレスとポート番号が含まれています。
注記
ワーカーノードのコンポーネント
- Worker node service:
mod-cluster.sar - JBoss HTTP Connector クライアントサービスの
mod-cluster.sarは各ワーカーノードにデプロイされています。このサービスはプロキシにワーカーノードのステートのリアルタイム情報を伝え、ライフサイクルイベントの通知を送ります。加えて、ノードが同じネットワークで実行しているすべてのプロキシでそれ自身を検出、登録することができるようにします。
第5章 プロキシサーバーコンポーネントのインストール
5.1. Apache モジュール
5.1.1. mod_manager.so
LoadModule manager_module modules/mod_manager.so
<VirtualHost> 要素で次の関連するディレクティブを定義することもできます。
- MemManagerFile
- mod_manager が設定の詳細を保存するファイルの場所を定義します。mod_manager はまた、共有メモリおよびロックファイルの生成されたキーに対しこの場所を使用します。これは絶対パスの名前でなければなりません。 このパスは NFS 共有ではなく、ローカルドライブにあることが推奨されます。デフォルト値は
/logs/です。 - Maxcontext
- JBoss mod_cluster が使用するコンテキストの最大数です。デフォルト値は
100です。 - Maxnode
- JBoss mod_cluster が使用するワーカーノードの最大数です。デフォルト値は
20です。 - Maxhost
- JBoss mod_cluster が使用するホスト (エイリアス) の最大数です。これはロードバランサの最大数でもあります。デフォルト値は
10です。 - Maxsessionid
- 保存されているアクティブなセッション識別子の最大数です。5 分以内にセッションから受信する情報がない場合はセッションはアクティブでないと見なされます。デフォルト値は
0で、このロジックを無効にします。 - ManagerBalancerName
- ワーカーノードがロードバランサの名前を与えない場合に使用するロードバランサの名前です。デフォルト値は
myclusterです。 - PersistSlots
onに設定すると、ノード、エイリアス、コンテキストはファイルで永続化されます。デフォルト値はoffです。- CheckNonce
onに設定すると、セッション識別子はそれらが一意であり以前に発生したことがないことを確認します。デフォルト値はonです。警告
このディレクティブをoffに設定することで、ご使用のサーバーをリプレーアタックに対し脆弱性を有するようにできます。- SetHandler
- ハンドラを定義し、クラスタ内のワーカーノードに関する情報を表示します。これは
Location要素で定義されます。<Location $LOCATION> SetHandler mod_cluster-manager Order deny,allow Deny from all Allow from 127.0.0.1 </Location>
ブラウザでLocation要素に定義された $LOCATION にアクセスすると、次のようなものが表示されます (この場合、$LOCATION はmod_cluster-handlerとしても定義されます)。

Maxsessionid が 0 の場合は存在しません。
5.1.2. mod_proxy_cluster.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
<VirtualHost> 要素で次の関連するディレクティブを定義し、負荷分散の動作を変更することができます。
mod_proxy_cluster directives
- CreateBalancers
- Apache HTTP Server の仮想ホストでのロードバランサの作成方法について定義します。次の値は
CreateBalancersで有効です。- 0
- Apache HTTP Server で定義されたすべての仮想ホストでロードバランサを作成します。
ProxyPassディレクティブでロードバランサを設定するようにしてください。 - 1
- バランサを作成しません。この値を使用する場合は、
ProxyPassまたはProxyPassMatchでもロードバランサの名前を定義しなければなりません。 - 2
- メインサーバーのみ作成します。これは
CreateBalancersのデフォルト値です。
- UseAlias
- 定義された
AliasがServerNameに対応することを確認するか定義します。次の値はUseAliasで有効です。- 0
- ワーカーノードからの Alias 情報を無視します。これは
UseAliasのデフォルト値です。 - 1
- 定義されたエイリアスがワーカーノードのサーバー名に対応していることを検証します。
- LBstatusRecalTime
- ワーカーノードのステータスを計算するプロキシ間での秒単位の間隔を定義します。デフォルトの間隔は 5 秒です。
- ProxyPassMatch; ProxyPass
ProxyPassはリモートサーバーをローカルサーバーの名前空間にマップします。ローカルサーバーがアドレスhttp://local.com/を持っている場合、次のProxyPassディレクティブはhttp://local.com/requested/file1のローカル要求をhttp://worker.local.com/file1のプロキシ要求に変換します。ProxyPass /requested/ http://worker.local.com/
ProxyPassMatchは Regular Expressions を使用して、プロキシされた URL が適用するべきローカルパスに適合します。いずれのディレクティブの場合でも、!はある特定のパスがローカルであり、そのパスの要求がリモートサーバーにルーティングされるべきではないことを示しています。例えば、次のディレクティブは.gifファイルがローカルに提供されることを指定します。ProxyPassMatch ^(/.*\.gif)$ !
5.1.3. mod_advertise.so
VirtualHost 要素の mod_manager に沿って定義されます。次のコードスニペットの識別子は advertise_module です。
LoadModule advertise_module modules/mod_advertise.so
- ServerAdvertise
- 告知しているメカニズムの使用方法を定義します。
Onに設定した場合、告知しているメカニズムを使用して、ワーカーノードにこのプロキシにステータス情報を送るよう指示します。次の構文ServerAdvertise On http://hostname:port/でホスト名とポートを指定することもできます。これが必要なのは、名前ベースの仮想ホストを使用する場合か、仮想ホストが定義されていない場合だけです。デフォルト値はOffです。offに設定すると、プロキシはその場所を告知しません。 - AdvertiseGroup
- 告知するマルチキャストのアドレスを定義します。構文は
AdvertiseGroup address:portであり、address はAdvertiseGroupAddressに該当し、port はワーカーノードのAdvertisePortに該当するはずです。ワーカーノードが JBoss Enterprise Application Platform ベースで、-uスイッチが起動時に使用される場合は、デフォルトAdvertiseGroupAddressは-uスイッチにより渡された値です。デフォルト値は224.0.1.105:23364です。port が指定されていないと、指定されるデフォルトのポートは23364です。 - AdvertiseFrequency
- IP アドレスとポートを告知するマルチキャストメッセージ間の秒単位の間隔です。デフォルト値は
10です。 - AdvertiseSecurityKey
- JBoss Web の JBoss HTTP Connector mod_cluster を特定するために使用する文字列を定義します。デフォルトでは、このディレクティブは設定されておらず何も情報は送られません。
- AdvertiseManagerUrl
- プロキシサーバーに情報を送るためにワーカーノードが使用する URL を定義します。デフォルトでは、このディレクティブは設定されておらず何も情報は送られません。
- AdvertiseBindAddress
- マルチキャストメッセージを送るアドレスとポートを定義します。構文は
AdvertiseBindAddress address:portです。これにより、複数の IP アドレスを使ってマシンにアドレスを指定できます。デフォルト値は0.0.0.0:23364です。
5.2. プロキシサーバーコンポーネントのインストール
タスク : プロキシサーバーコンポーネントをインストールする
前提条件
- JBoss Enterprise Web Server v1.0.1 またはそれ以降のバージョンがインストールされている。
- JBoss Enterprise Application Platform 5 Native コンポーネントがダウンロードされている。
Native Components ダウンロードから Apache モジュールを抽出します。
4 つのモジュールmod_advertise.so、mod_manager.so、mod_proxy_cluster.so、mod_slotmem.soを使用しているプロセッサアーキテクチャに対してnative/lib/httpd/modulesまたはnative/lib64/httpd/modulesいずれかの適切な Native Components パッケージディレクトリから抽出します。JBoss Enterprise Web Server に Apache モジュールをコピーします。
JBoss HTTP Connector モジュールを JBoss Enterprise Web Server のJBOSS_EWS_DIST/httpd/modulesディレクトリにコピーします。mod_proxy_balancer モジュールを無効にします。
JBoss Enterprise Web Server Apache 設定ファイルであるJBOSS_EWS_DIST/httpd/conf/httpd.confを編集し、#を冒頭に追加することで次の行をコメントアウトします。LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
このモジュールは JBoss HTTP Connector と互換性はありません。JBoss HTTP Connector モジュールにロードするようサーバーを設定します。
- ファイル
JBOSS_EWS_DIST/httpd/conf.d/JBoss_HTTP.confを作成します。 - 次の行をファイル
JBOSS_EWS_DIST/httpd/conf.d/JBoss_HTTP.confに追加します。LoadModule slotmem_module JBOSS_EWS_DIST/modules/mod_slotmem.so LoadModule manager_module JBOSS_EWS_DIST/modules/mod_manager.so LoadModule proxy_cluster_module JBOSS_EWS_DIST/modules/mod_proxy_cluster.so LoadModule advertise_module JBOSS_EWS_DIST/modules/mod_advertise.so
JBoss Enterprise Web Server Apache サービスを再開します。
詳細な方法は JBoss Enterprise Web Server ドキュメントを参照してください。
第6章 基本的なプロキシサーバーの設定
6.1. 基本的なプロキシ設定の概要
- ワーカーノード接続要求とワーカーノードフィードバックを受信するよう Proxy Server リスナを設定します。
- オプション : サーバーの告知を無効にします。
プロキシサーバーは UDP マルチキャストを使用してそれ自身を告知できます。UDP マルチキャストがプロキシサーバーとワーカーノード間のネットワーク上で使用可能な場合、サーバーの告知によってプロキシサーバーに別途設定する必要なく、ワーカーノードに最低限の設定だけでワーカーノードを追加できます。
6.2. HTTP Connector を使用した負荷分散プロキシの設定
タスク : プロキシサーバーリスナを設定する
前提条件
- JBoss Enterprise Web Server をインストールしている。詳細は JBoss Enterprise Web Server 『Installation Guide』 を参照してください。
- JBoss HTTP Connector モジュールをインストールしている。詳細は 5章プロキシサーバーコンポーネントのインストール を参照してください。
プロキシサーバーに対しリッスンディレクティブを作成します。
次を追加して、設定ファイルJBOSS_EWS_DIST/httpd/conf.d/JBoss_HTTP.confを編集します。Listen IP_ADDRESS:PORT_NUMBER
IP_ADDRESS はワーカーノードと通信するためのサーバーネットワークインターフェースの IP アドレスです。PORT_NUMBER はインターフェースがリッスンするポートです。注記
ポート PORT_NUMBER は受信 TCP 接続に対するサーバーファイアウォールでオープンでなくてはなりません。例6.1 Listen ディレクティブのサンプル
Listen 10.33.144.3:6666
仮想ホストを作成します。
次をファイルJBOSS_EWS_DIST/httpd/conf.d/JBoss_HTTP.confに追加します。<VirtualHost IP_ADDRESS:PORT_NUMBER> <Directory /var/www> Order deny,allow Deny from all Allow from 10.33.144. </Directory> KeepAliveTimeout 60 MaxKeepAliveRequests 0 ManagerBalancerName mycluster AdvertiseFrequency 5 </VirtualHost>IP_ADDRESS と PORT_NUMBER は Listen ディレクティブからの値です。オプション : サーバーの告知を無効にします。
AdvertiseFrequencyディレクティブの存在により、UDP マルチキャストを介してサーバーが定期的にサーバー告知メッセージを送るようになります。ここでは 5 秒に設定されています。これらサーバー告知のメッセージには VirtualHost 定義で指定した IP_ADDRESS と PORT_NUMBER が含まれています。サーバー告知に応答するよう設定されたワーカーノードは、この情報を使用してプロキシサーバーを使って登録します。サーバー告知を無効にするには、次のディレクティブをVirtualHost定義に加えます。ServerAdvertise Off
サーバー告知を無効にする、または UDP マルチキャストがプロキシサーバーとワーカーノード間でのネットワークで使用できない場合は、プロキシサーバーの静的リストでワーカーノードを設定する必要があります。JBoss Enterprise Web Server Apache サービスを再開します。
詳細な方法は JBoss Enterprise Web Server ドキュメントを参照してください。
第7章 基本設定でのノードのインストール
7.1. ワーカーノードの要件
対応するワーカーノードのタイプ
- JBoss Enterprise Platform 5 JBoss Web コンポーネント
- JBoss Enterprise Web Server Tomcat サービス
注記
JBoss HTTP Connector Enterprise Web Server ノードの制約
- 非クラスタ化モードのみである。
- 負荷分散係数を計算する場合、1 度に 1 つの負荷メトリックだけしか使えない。
7.2. ワーカーノードのインストールと設定
タスク : JBoss Enterprise Application Platform ワーカーノードのインストールと設定を行う
前提条件
- 対応している JBoss Enterprise Application Platform をインストールしている。
ワーカーノードサービスをデプロイします。
JBOSS_EAP_DIST/mod_clusterディレクトリからmod-cluster.sarをjboss-as/server/PROFILE/deployにコピーします。JBoss Web にリスナを追加します。
次のListener要素をJBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy/jbossweb.sar/server.xmlの他の Listener の下に追加します。<Listener className="org.jboss.web.tomcat.service.deployers.MicrocontainerIntegrationLifecycleListener" delegateBeanName="ModClusterService"/>
サービスの依存性を設定します。
次のdepends要素をJBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy/jbossweb.sar/META-INF/jboss-beans.xmlの他の depends 要素の下に追加します。<depends>ModClusterService</depends>
ワーカーに一意のアイデンティティを加えます。
以下のとおりjvmRoute属性と値をEngine要素に追加し、ファイルJBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy/jbossweb.sar/server.xmlを編集します。<Engine name="jboss.web" defaultHost="localhost" jvmRoute="worker01">
各ノードに一意の jvmRoute 値を使用します。オプション : マルチキャスト Proxy Server 告知を受け取るためにファイアウォールを設定します。
JBoss HTTP Connector を使用するプロキシサービスは、UDP マルチキャストを介してそれ自身を告知できます。ワーカーノードが動的にプロキシサービスを検出できるようにするには、ワーカーノードのファイアウォールで UDP 接続のポート 23364 を開きます。Linux ユーザーの場合/sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 23364 -j ACCEPT -m comment --comment "receive mod_cluster proxy server advertisements" /sbin/iptables save
Automatic Proxy Discovery (プロキシの自動検出 を参照) を使用していない場合、プロキシの静的リストでワーカーノードを設定します。方法は 「静的プロキシの設定」 を参照してください。この場合、次の警告メッセージは安心して無視してください。[warning] mod_advertise: ServerAdvertise Address or Port not defined, Advertise disabled!!!
重要
ノードが Red Hat Enterpise Linux を稼働している別のマシンにある場合は、互いを自動的には認識しません。JBoss Clustering は jGroups が提供する UDP (User Datagram Protocol) マルチキャスティングに依存しています。Red Hat Enterprise Linux に同梱している SELinux 設定はこうしたパケットをデフォルトでブロックします。パケットを許可するには、(ルートで) iptables ルールを修正します。次のコマンドは 192.168.1.x に一致する IP アドレスに適用します。/sbin/iptables -I RH-Firewall-1-INPUT 5 -p udp -D 224.0.1.0/24 -j ACCEPT /etc/init.d/iptables save /sbin/iptables -I RH-Firewall-1-INPUT 5 -p udp -d 224.0.0.0/4 -j ACCEPT /sbin/iptables -I RH-Firewall-1-INPUT 9 -p udp -s 192.168.1.0/24 -j ACCEPT /sbin/iptables -I RH-Firewall-1-INPUT 10 -p tcp -s 192.168.1.0/24 -j ACCEPT /etc/init.d/iptables save
タスク : JBoss Enterprise Web Server Worker Node のインストールと設定を行う
前提条件
- 対応している JBoss Enterprise Web Server をインストールしている。
- 付録B Java プロパティリファレンス で説明されている Proxy Configuration パラメータを理解している。
ワーカーノードサービスをデプロイします。
JBOSS_EAP_DIST/mod_cluster/JBossWeb-Tomcat/libディレクトリのすべてのライブラリファイルをコピーします。これらのファイルをJBOSS_EWS_DIST/tomcat6/lib/に移動します。Tomcat に Listener を追加します。
次のListener要素をJBOSS_EWS_DIST/tomcat6/conf/server.xmlの他の Listener 要素の下に追加します。<Listener className="org.jboss.modcluster.ModClusterListener" advertise="true" stickySession="true" stickySessionForce="false" stickySessionRemove="true"/>
このワーカーに一意のアイデンティティを加えます。
以下のとおりjvmRoute属性と値をEngine要素に追加し、JBOSS_EWS_DIST/tomcat6/conf/server.xmlを編集します。<Engine name="Catalina" defaultHost="localhost" jvmRoute="worker01">
オプション : Proxy Server の告知を受け取るためにファイアウォールを設定します。
JBoss HTTP Connector を使用するプロキシサービスは、UDP マルチキャストを介してそれ自身を告知できます。こうしたマルチキャストメッセージを受け取るには、ワーカーノードのファイアウォールで UDP 接続のポート 23364 を開きます。Linux ユーザーの場合/sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 23364 -j ACCEPT -m comment -comment "receive mod_cluster proxy server advertisements"
Automatic Proxy Discovery (プロキシの自動検出 を参照) を使用していない場合、プロキシの静的リストでワーカーノードを設定します。方法は 「静的プロキシの設定」 を参照してください。この場合、次の警告メッセージは安心して無視してください。[warning] mod_advertise: ServerAdvertise Address or Port not defined, Advertise disabled!!!
第8章 サーバーの追加設定
8.1. Apache サーバーディレクティブ
8.1.1. CreateBalancers
CreateBalancers の値
- 0
- すべての VirtualHosts でバランサを作成します。
- 1
- バランサは作成しません。
- 2
- メインサーバーにのみバランサを作成します。
第9章 高度な設定
9.1. 静的プロキシの設定
タスク : 静的プロキシリストで Application Platform ワーカーノードを設定する
前提条件
- JBoss Enterprise Application Platform ワーカーノードが設定されている。方法は 7章基本設定でのノードのインストール を参照してください。
動的プロキシの検出を無効にします。
ファイルJBOSS_EAP_DIST/jboss-as/server/PROFILE/mod-cluster.sar/META-INF/mod-cluster-jboss-beans.xmlを編集し、advertiseプロパティを false に設定します。<property name="advertise">false</property>
- 次の静的プロキシのオプションからひとつを選択し、実装します。
オプション 1 : 静的プロキシサーバーのリストを作成する。
ファイルJBOSS_EAP_DIST/jboss-as/server/PROFILE/mod-cluster.sar/META-INF/mod-cluster-jboss-beans.xmlを編集し、proxyListプロパティの IP_ADDRESS:PORT の形式でプロキシのコンマで区切られたリストを追加します。例9.1 静的プロキシリストのサンプル
<property name="proxyList">10.33.144.3:6666,10.33.144.1:6666</property>
オプション 2 : パラメータとして静的プロキシリストでワーカーノードを開始する。
JBOSS_EAP_DIST/server/PROFILE/mod-cluster.sar/META-INF/mod-cluster-jboss-beans.xmlを編集します。- 次の行を追加します。
<property name="domain">${jboss.modcluster.domain:}</property> - ノードを開始するとき、
jboss.modcluster.proxyListパラメータとしての IP_ADDRESS:PORT の形式でプロキシのコンマで区切られたリストを追加します。例9.2 静的プロキシリストのパラメータのサンプル
-Djboss.modcluster.domain=10.33.144.3:6666,10.33.144.1:6666
タスク : 静的プロキシリストで Web Server ワーカーノードを設定する。
前提条件
- JBoss Enterprise Web Server ワーカーノードが設定されている。方法は 7章基本設定でのノードのインストール を参照してください。
- 付録B Java プロパティリファレンス で説明されている Proxy Configuration パラメータを理解している。
動的プロキシの検出を無効にします。
ファイルJBOSS_EWS_DIST/tomcat6/conf/server.xmlを編集し、ModClusterListener のadvertiseプロパティを false に設定します。mod_cluster リスナを定義します。
<Listener> 要素をserver.xmlファイルに追加します。<Listener className="org.jboss.modcluster.ModClusterListener" advertise="false" stickySession="true" stickySessionForce="false" stickySessionRemove="true"/>
静的プロキシサーバーのリストを作成します。
ModClusterListener <Listener> 要素のproxyListプロパティとして IP_ADDRESS:PORT の形式でプロキシのコンマで区切られたリストを追加します。例9.3 静的プロキシリストのサンプル
<Listener className="org.jboss.modcluster.ModClusterListener" advertise="false" stickySession="true" stickySessionForce="false" stickySessionRemove="true" proxyList="10.33.144.3:6666,10.33.144.1:6666"/>
9.2. クラスタ化したノードの動作
注記
- JBoss HTTP Connector の非クラスタ化した動作
- 非クラスタモードでは、各ノードは直接プロキシと通信します。
- JBoss HTTP Connector クラスタ化した動作
- クラスタモードでは、複数のワーカーノードが JBoss HA (High Availability) クラスタドメインを形成します。単一のワーカーノードがクラスタドメインの他のノードに代わってプロキシと通信します。
第10章 負荷分散のデモ
jboss-eap-5.1/mod_cluster/demo ディレクトリにあります。
/server/load-demo.war- JBoss Enterprise Application Platform または JBoss Enterprise Web Server でデプロイされる WAR ファイルです。この WAR には多くのサーブレットが含まれています。
/client/lib/mod-cluster-demo.jar- ユーザーがスレッドのプールを起動でき、ロードバランサを介して
load-demo.warのプライマリサーブレットに要求を送信する Web アプリケーション。このアプリケーションは要求を処理するサーバーに関する情報を表示します。また、load-demo.warの負荷生成サーブレットにも個別の要求を送信でき、ユーザーは特定の負荷条件がどのように要求の負荷分散に影響を与えるかを確認できます。
注記
10.1. デモの設定
タスク: デモの起動
前提条件
- ワーカーノードをインストールおよび設定します。「ワーカーノードのインストールと設定」 を参照してください。
- プロキシサーバーをインストールおよび設定します。「静的プロキシの設定」 を参照してください。
プロキシサーバーの起動
HTTPD_DIST/sbinに移動し、プロキシサーバーを起動します。[sbin]$ apachectl start
ワーカーノードの起動
ターミナルで、以下のコマンドを実行します。- JBoss Enterprise Web Server の場合:
[home]$ ./JBOSS_EWS_DIST/tomcat6/bin/startup.sh
- JBoss Enterprise Application Platform の場合:
[home]$ ./JBOSS_EAP_DIST/bin/run.sh
Catalina サービス名の指定
AWAITING CONFIRMATON ON JBPAPP-6550ワーカーノードへのデモ Web アーカイブのデプロイ
JBOSS-EAP_DIST/mod_cluster/demo/serverのload-demo.warを以下のディレクトリにコピーします。- JBoss Enterprise Web Server の場合:
JBOSS_EWS_DIST/tomcat6/webapps - JBoss Enterprise Application Platform の場合:
JBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy
デモの起動
JBOSS_EAP_DIST/mod_cluster/demo/client/に移動し、デモを起動します。[client]$ ./run-demo.sh
結果デモが起動し、[Load Balancing Demonstration] ウィンドウが開きます。タスク: [Client Control] タブフィールドの設定 に進みます。

10.2. デモクライアントの設定
タスク: [Client Control] タブフィールドの設定
前提条件
- [Client Control] タブをクリックします。
- 以下のフィールド定義に基づいて、[Client Control] タブのすべてのフィールドに対して値を指定します。
- Proxy Hostname
- 負荷分散プロキシサーバーのホスト名またはプロキシサーバーが要求をリッスンしている IP アドレス。このフィールドのデフォルト値は
localhostであるか、またはmod_cluster.proxy.hostシステムプロパティにより決定されます (設定されている場合)。デモを使用するたびにこの値を再設定することを回避するために、run-demo.shの-Dmod_cluster.proxy.host=localhost値を編集します。 - Proxy Port
- 負荷分散サーバーが要求をリッスンするポート。デフォルト値は
8000であるか、またはmod_cluster.proxy.portプロパティによって決定されます (設定されている場合)。デモを使用するたびにこの値を再設定することを回避するために、run-demo.shの-Dmod_cluster.proxy.port=8000値を編集します。 - Context Path
- 要求を指定する要求 URL の部分は
load-demo.warです。 - Session Life
- クライアントスレッドがセッションを無効にし、破棄する前にセッションを使用する時間 (秒数)。これは小さい値である必要があります。小さい値でないと、セッションスティッキネスによりサーバー負荷の変化がプロキシサーバーのルーティング決定に影響を与えなくなります。スティッキーセッションが有効な場合 (強く推奨) は、新しいセッションを作成すると、プロキシが負荷を分散します。
- Invalidate
- チェックされた場合、スレッドがセッションの使用を停止したときにセッションがクライアントスレッドにより無効になります。チェックされた場合、セッションは破棄され、セッションタイムアウトが終了するまでワーカーノードに存在します。
- Session Timeout
- ワーカーノードの期限が切れ、セションが削除されるまでセションが未使用のままになる時間 (秒数)。
Invalidateを選択解除し、セッションライフよりも大きい値を設定すると、大量の未使用のセッションがサーバーに蓄積されます。 - Num Threads
- 起動するクライアントスレッドの数。各スレッドは [Stop] ボタンが押されるか、要求が HTTP 200 以外の応答を受けとるまで要求を繰り返し行います。
- Sleep Time
- 要求間にクライアントスレッドがスリープ状態にする (ミリ秒数)。
- Startup Time
- アプリケーションがクライアントスレッドの起動を整理する時間 (秒数)。セッションの起動時間を整理すると、すべてのセッションが開始され、ほとんど同時に終了する非現実的な状況が回避されます。起動時間を整理すると、プロキシが新しいセッションを連続的に確認し、セッションをルーティングする方法を決定します。
- 値を指定したら、タスク: デモとの対話 に進みます。
10.3. デモとの対話
用語
- アクティブセッション
- セッションは、クライアントスレッドがセッションに関連付けられた要求を送信する場合にアクティブと見なされます。クライアントスレッドはセッションの使用を停止すると、セッションを無効にする要求を送信するか、該当するセッションクッキーを含めないようにすることによりセッション破棄します。セッションが破棄されると、セッションは Session Balancing チャートで反映されなくなりますが、セッションタイムアウト値に基づいて削除されるまでワーカーノードに存在し続けます。
- クライアント合計数
- [Start] ボタンがクリックされてから作成されたクライアントスレッドの数。
- ライブクライアント数
- 現在実行されているクライアントスレッド数。
- 失敗したクライアント数
- HTTP 200 応答以外の結果となる要求などを異常終了したクライアントスレッドの数。
タスク: デモとの対話
タスクの前提条件
- タスク: デモの起動 を完了します。
- タスク: [Client Control] タブフィールドの設定 を完了します。
- [Request Balancing] タブをクリックし、各ワーカーノードに送信される要求の数を確認します。
- [Session Balancing] タブをクリックし、各ワーカーノードによりホストされるアクティブセッションの数を確認します。
- いくつかのワーカーノードを停止するか、
load-demo.warをデプロイ解除し、要求およびセッション分散に与える影響を確認します。 - いくつかのワーカーノードを再起動するか、
load-demo.warを再デプロイし、要求およびセッション分散に与える影響を確認します。 - 1 つまたは複数のワーカーノードに人工的な負荷を追加して実験を行い、負荷およびセッション分散に対する影響を確認します (詳細については、「実効的な負荷の生成」 を参照してください)。
10.3.1. 実効的な負荷の生成
- ターゲットホスト名、ターゲットポート
- 負荷を生成するサーバーのホスト名とポート番号。これらの値を設定するには 2 つの方法があります。
- プロキシサーバーのホスト名とポートを使用します。プロキシは負荷をワーカーノードにルーティングします。ただし、クライアントはこれらの要求のセッションクッキーを保持しないため、生成された負荷は同じワーカーに必ずしもルーティングされません。
- ワーカーノードが HttpConnector と AJP コネクタを実行している場合、ワーカーの HttpConnector がリッスンしている IP アドレスとポートを指定できます (デフォルト値は
8080)。
- 負荷作成アクション
- ワーカーノードが生成する負荷の種類を指定します。
利用可能なアクション数
- アクティブセッション
- ターゲットサーバーでセション作成を開始することによりサーバー負荷を生成します。
- データソース使用
- 設定された時間に対して
java:DefaultDSデータソースから接続を取得することによりサーバー負荷を生成します。 - 接続プール使用
- 設定された時間に対する webserver 接続プールのスレッドをブロックすることによりサーバー負荷を生成します。
- ヒープメモリプール使用
- 設定された時間に対して空きヒープメモリの 50% を占有することによりサーバー負荷を生成します。
- CPU 使用
- スレッドでタイトループを開始することによりサーバー CPU 負荷を生成します。
- サーバー受信トラフィック
- 設定された時間の間、1 秒ごとにサーバーに大きいバイトアレイを転送することによりサーバートラフィック受信負荷を生成します。
- サーバー送信トラフィック
- 1 秒ごとに要求 (サーバーが大きいバイトアレイで応答する) を行うことによりサーバートラフィック送信負荷を生成します。
- 要求数
- 複数の要求を行うことによりサーバー負荷を生成し、ターゲットサーバーの要求数を増やします。
- パラメータ
- 指定された負荷作成サーブレットに渡すゼロ以上のパラメータ (スクリーンショットに示された接続数や時間など)。表示されるパラメータ、パラメータ名、およびその意味は選択された負荷作成アクションによって異なります。各パラメータのラベルには、使用方法を説明するヒントが含まれます。
パート III. Internet Server API
第11章 概要
11.1. Internet Server API とは
- 拡張機能 (IIS で実行される完全なアプリケーション)
- フィルタ (IIS の機能に関連する要求を持続的にフィルタリングすることにより IIS 機能を変更または拡張するアプリケーション)。
第12章 Windows での ISAPI コネクタの設定
12.1. 前提となる条件と設定
重要
-b スイッチを使用して JBoss Enterprise Platform のインスタンスをパブリック IP アドレスにバインドします。IP アドレスの変更を反映するよう IIS マシン上の workers.properties ファイルを編集します。
- テクノロジーのいずれかの組み合わせとオペレーティングシステムとアーキテクチャ専用のネイティブバイナリをインストールすることにより、マスターノードを設定します。
- Windows Server 2003 (32 ビット) と Microsoft IIS 6
- Windows Server 2003 (64 ビット) と Microsoft IIS 6
- Windows Server 2008 (32 ビット) と Microsoft IIS 7.0
- Windows Server 2008 (64 ビット) と Microsoft IIS 7.0
- JBoss Enterprise Application Platform 5.1.0 以降をインストールすることによりワーカーノードを設定します。ネイティブコンポーネントはワーカーノードのオプションです。
注記
12.2. ワーカーノードとしてサーバーインスタンスを設定
タスク: ワーカーノードとしてサーバーインスタンスを設定
前提条件
各ワーカーノードのサーバープロファイルを作成します。
ワーカーノードとして設定するdefaultサーバープロファイルのコピーを作成し、default-01に名前を変更します。各インスタンスに一意な名前を付けます。
Edit the following line in thedeploy\jbossweb.sar\server.xmlfile of each new worker instance:<Engine name="jboss.web" defaultHost="localhost">
示されたように、一意なjvmRoute値を追加します。この値はクラスタのこのノードの ID です。default-01サーバープロファイルの場合:<Engine name="jboss.web" defaultHost="localhost" jvmRoute="worker01">
default-02サーバープロファイルの場合:<Engine name="jboss.web" defaultHost="localhost" jvmRoute="worker02">
セッション処理を有効にします。
Uncomment the following line in thedeployers\jbossweb.deployer\META-INF\war-deployers-jboss-beans.xmlfile of each worker node:<property name="useJK">false</property>
このプロパティは、mod_jk および他のコネクタバリアントと調整するために特殊なセッション処理を使用するかどうかを制御します。両方のワーカーノードでこのプロパティをtrueに設定します。<property name="useJK">true</property>
ワーカーノードを起動します。
個別のコマンドラインインターフェースで各ワーカーノードを起動します。--hostスイッチを使用して各ノードが異なる IP アドレスにバインドされるようにします。JBOSS_EAP_DIST\bin\run.bat --host=127.0.0.1 -c default-01
JBOSS_EAP_DIST\bin\run.bat --host=127.0.0.100 -c default
12.3. Microsoft IIS 6 初期クラスタリング設定
タスク: ISAPI フィルタの定義
- マスターサーバーで、IIS マネージャを開きます。
- [スタート] → [実行]、次に
inetmgrと入力します。 - [スタート] → [コントロール パネル] → [管理ツール] → [インターネット インフォメーション サービス (IIS) マネージャ]
[IIS 6 Manager] ウィンドウが開きます。 - ツリービューペインで、[Web サイト] を展開します。
- [既定の Web サイト] を右クリックし、次に [プロパティ] をクリックします。[プロパティ] ウィンドウが開きます。
- [ISAPI フィルタ] をクリックします。
- [追加] ボタンをクリックし、[フィルタのプロパティの追加と編集] ウィンドウで以下の値を指定します。
- [フィルタ名]:
jbossを (記述されたとおりに) 指定します。- [実行可能ファイル]:
- Specify
C:\connectors\jboss-ep-5.1\native\sbin\isapi_redirect.dll
- [OK] をクリックして値を保存し、[フィルタのプロパティの追加と編集] ダイアログを閉じます。
注記
IIS はまだリソースの要求を受け取っていないため、[ISAPI フィルタ] タブではjbossフィルタステータスと優先度が [不明] と表示されます。要求が実行されると、ステータスと優先度はそれぞれ [読み込み済み] と [高] に変わります。
タスク: ISAPI 仮想ディレクトリを定義する
- [既定の Web サイト] を右クリックし、[新規] → [仮想ディレクトリの追加]をクリックします。[仮想ディレクトリの追加] ウィンドウが開きます。
- [仮想ディレクトリの追加] ウィンドウで以下の値を指定します。
- [エイリアス]:
jbossを (記述されたとおりに) 指定します。- [物理パス]:
- Specify
C:\connectors\jboss-ep-5.1\native\sbin\
- [OK] をクリックして値を保存し、[仮想ディレクトリの追加] ウィンドウを閉じます。
- ツリービューペインで、[Web サイト] → [既定の Web サイト]を展開します。
jboss仮想ディレクトリを右クリックし、[プロパティ] をクリックします。- [仮想ディレクトリ] タブをクリックし、以下の変更を行います。
- [実行アクセス許可]:
Scrips and Executablesを選択します。- [Read (読み取り)] チェックボックス:
- 読み取りアクセスを有効にします。
- [OK] をクリックして値を保存し、[jboss Properties] ウィンドウを閉じます。
タスク: ISAPI Web サービス拡張を定義する
- [Web サービス拡張] をクリックし、[タスク] グループで、[新しい Web サービス拡張を追加] を選択します。[新しい Web サービス拡張] ウィンドウが表示されます。
- 以下の値を [新しい Web サービス拡張] ウィンドウに追加します。
- [Extension name (拡張名)]
jbossを指定します。- [必要なファイル]:
- Specify the path
C:\connectors\jboss-ep-5.1\native\sbin\isapi_redirect.dll - [拡張の状態を許可済みに設定する]:
- チェックボックスを選択します。
- [OK] をクリックして値を保存し、[新しい Web サービス拡張] ウィンドウを閉じます。
jbossWeb Service Extension がリストに表示されていることを確認します。
12.4. Microsoft IIS 7 初期クラスタリング設定
APPCMD.EXE コマンドツールを使用してコマンドプロンプトから管理したりできます。
用語
- ISAPI 制限と CGI 制限
- ISAPI 制限と CGI 制限はサーバーでの動的コンテンツの実行を可能にする要求ハンドラです。これらの制限は CGI ファイル (
.exe) または ISAPI 拡張 (.dll) のいずれかです。IIS 設定システムがこれを許可する場合は、カスタム ISAPI 制限または CGI 制限を追加できます。 [http://technet.microsoft.com/en-us/library/cc730912(WS.10).aspx]
タスク: JBoss ネイティブ ISAPI 制限を定義する
- マスターサーバーで、IIS マネージャを開きます。
- [スタート] → [実行]、次に
inetmgrと入力します。 - [スタート] → [コントロール パネル] → [管理ツール] → [インターネット インフォメーション サービス (IIS) マネージャ]
[IIS 7 Manager] ウィンドウが開きます。 - ツリービューペインで、[IIS 7 (Server Home と呼ばれます) を選択します。[IIS 7 Home Features View] が開きます。
- [ISAPI および CGI の制限] をダブルクリックします。[ISAPI および CGI の制限] 機能ビューが開きます。
- [Actions (アクション)] ペインで、[追加] をクリックします。[ISAPI または CGI の制限の追加] ウィンドウが開きます。
- 以下の値を [ISAPI または CGI の制限の追加] ウィンドウで指定します。
- [ISAPI または CGI パス]:
- Specify
c:\connectors\jboss-ep-5.1\native\sbin\isapi_redirect.dll - [説明]:
と指定します (記述されたとおり)。jboss- [拡張パスの実行を許可する]
- チェックボックスを選択します。
- [OK] をクリックして値を保存し、[ISAPI または CGI の制限の追加] ウィンドウを閉じます。
注記
[ISAPI および CGI の制限] 機能ビューに、jboss制限とパスが表示されます。
タスク: JBoss ネイティブ仮想ディレクトリを定義する
- [既定の Web サイト] を右クリックし、[仮想ディレクトリの追加] をクリックします。[仮想ディレクトリの追加] ウィンドウが開きます。
- [仮想ディレクトリの追加] ウィンドウで以下の値を指定します。
- [エイリアス]:
jbossを (記述されたとおりに) 指定します。- [物理パス]:
- Specify
C:\connectors\jboss-ep-5.1\native\sbin\
- [OK] をクリックして値を保存し、[仮想ディレクトリの追加] ウィンドウを閉じます。
タスク: JBoss ネイティブ ISAPI リダイレクトフィルタを定義する
- ツリービューペインで、[サイト] → [既定の Web サイト]を展開します。
- [ISAPI フィルタ] をダブルクリックします。[ISAPI フィルタ] 機能ビューが開きます。
- [Actions (アクション)] ペインで、[追加] をクリックします。[ISAPI フィルタの追加] ウィンドウが開きます。
- 以下の値を [ISAPI フィルタの追加] ウィンドウで指定します。
- [フィルタ名]:
jbossを (記述されたとおりに) 指定します。- [実行可能ファイル]:
- Specify
C:\connectors\jboss-ep-5.1\native\sbin\isapi_redirect.dll
- [OK] をクリックして値を保存し、[ISAPI フィルタの追加] ウィンドウを閉じます。
タスク: ISAPI-dll ハンドラを有効にする
- ツリービューペインで、[IIS 7 (Server Home と呼ばれます) を選択します。[IIS 7 Home Features View] が開きます。
- [ハンドラ マッピング] をダブルクリックします。[ハンドラ マッピング] 機能ビューが開きます。
- [グループ化] ドロップダウンボックスで、[State (状態)] を選択します。ハンドラマッピングが Enabled グループと Disabled グループで表示されます。
ISAPI-dllが Disabled グループに存在する場合は、右クリックして [機能のアクセス許可の編集] を選択します。- [Read (読み取り)]、[Script (スクリプト)]、および [Execute (実行)] チェックボックスが選択されていることを確認します。
- [OK] をクリックして値を保存し、[機能のアクセス許可の編集] ウィンドウを閉じます。
12.5. ISAPI を使用した基本的なクラスタの設定
タスク: 基本的なクラスタを提供するために ISAPI を設定する
注記
前提条件
- 関連する Microsoft IIS クラスタリングセットアップ手順を完了します。詳細については、「Microsoft IIS 6 初期クラスタリング設定」 または 「Microsoft IIS 7 初期クラスタリング設定」 を参照してください。
- The following steps assume that the
C:\connectorsdirectory is used to store logs, properties files, and NSAPI locks.
isapi_redirect.properties ファイルを作成する
Create a new file namedisapi_redirect.propertiesin thedirectory.C:\connectors\jboss-ep-5.1\native\sbin\重要
isapi_redirect.propertiesファイルは、isapi_redirect.dllファイルと同じディレクトリに存在する必要があります。以下の設定に関する行をファイルに追加します。# Configuration file for the ISAPI Redirector # Extension uri definition extension_uri=/jboss/isapi_redirect.dll # Full path to the log file for the ISAPI Redirector log_file=c:\connectors\isapi_redirect.log # Log level (debug, info, warn, error or trace) # Use debug only testing phase, for production switch to info log_level=debug # Full path to the workers.properties file worker_file=c:\connectors\workers.properties # Full path to the uriworkermap.properties file worker_mount_file=c:\connectors\uriworkermap.properties #Full path to the rewrite.properties file rewrite_rule_file=c:\connectors\rewrite.properties
オプション: rewrite.properties ファイルを作成する
rewrite.propertiesファイルを使用すると、アプリケーションに固有の単純な URL 書き換えを指定できます。この設定ファイルはオプションであり、URL 書き換えが必要ない場合はisapi_redirect.propertiesから実行できます。提供される機能は Apache mod_rewrite に類似しますが、それほど強力ではありません。書き換えパスは名前と値のペアを使用して指定します。単純な例では、app_01 アプリケーションが、イメージを含む抽象的なディレクトリ名を持ち、そのディレクトリをもっと直感的なものに再マップします。#Simple example, images are accessible under abc path /app-01/abc/=/app-01/images/
uriworkermap.properties ファイルを作成する
uriworkermap.propertiesファイルには、デプロイされたアプリケーションのマッピング設定情報が含まれます。以下の行をこのファイルに追加します。# images and css files for path /status are provided by worker01 /status=worker01 /images/*=worker01 /css/*=worker01 # Path /web-console is provided by worker02 # IIS (customized) error page is used for http errors with number greater or equal to 400 # css files are provided by worker01 /web-console/*=worker02;use_server_errors=400 /web-console/css/*=worker01 # Example of exclusion from mapping, logo.gif won't be displayed # !/web-console/images/logo.gif=* # Requests to /app-01 or /app-01/something will be routed to worker01 /app-01|/*=worker01 # Requests to /app-02 or /app-02/something will be routed to worker02 /app-02|/*=worker02
workers.properties ファイルを作成する
worker.propertiesファイルには、ワーカーラベルとサーバーインスタンス間のマッピング定義が含まれます。以下の行をこのファイルに追加します。# An entry that lists all the workers defined worker.list=worker01, worker02 # Entries that define the host and port associated with these workers # First EAP server definition, port 8009 is standard port for AJP in EAP worker.worker01.host=127.0.0.1 worker.worker01.port=8009 worker.worker01.type=ajp13 # Second EAP server definition worker.worker02.host= 127.0.0.100 worker.worker02.port=8009 worker.worker02.type=ajp13
IIS を再起動する
変更内容を反映するために IIS サーバーを再起動します。実行している IIS バージョンに対して以下のコマンドを実行します。- IIS 6
C:\> net stop iisadmin /Y C:\> net start w3svc
- IIS 7
C:\> net stop was /Y C:\> net start w3svc
ログを検証する
IIS が再起動されたら ISAPI ログを確認します。このログはisapi_redirect.propertiesの log_file プロパティで指定されたファイルの場所に保存されます。また、他のイベントについて IIS ログとイベントビューアを確認する必要があります。
12.6. ISAPI を使用した負荷分散クラスタの設定
タスク: 負荷分散クラスタを提供するために ISAPI を設定する
前提条件
- 関連する Microsoft IIS クラスタリングセットアップ手順を完了します。詳細については、「Microsoft IIS 6 初期クラスタリング設定」 または 「Microsoft IIS 7 初期クラスタリング設定」 を参照してください。
- The following steps assume that the
C:\connectorsdirectory is used to store logs, properties files, and NSAPI locks.
isapi_redirect.properties ファイルを作成する
Create a new file namedisapi_redirect.propertiesin thedirectory.C:\connectors\jboss-ep-5.1\native\sbin\重要
isapi_redirect.propertiesファイルは、isapi_redirect.dllファイルと同じディレクトリに存在する必要があります。以下の設定に関する行をファイルに追加します。# Configuration file for the ISAPI Redirector # Extension uri definition extension_uri=/jboss/isapi_redirect.dll # Full path to the log file for the ISAPI Redirector log_file=c:\connectors\isapi_redirect.log # Log level (debug, info, warn, error or trace) # Use debug only testing phase, for production switch to info log_level=debug # Full path to the workers.properties file worker_file=c:\connectors\workers.properties # Full path to the uriworkermap.properties file worker_mount_file=c:\connectors\uriworkermap.properties #OPTIONAL: Full path to the rewrite.properties file rewrite_rule_file=c:\connectors\rewrite.properties
オプション: rewrite.properties ファイルを作成する
rewrite.propertiesファイルを使用すると、アプリケーションに固有の単純な URL 書き換えを指定できます。この設定ファイルはオプションであり、URL 書き換えが必要ない場合はisapi_redirect.propertiesから実行できます。提供される機能は Apache mod_rewrite に類似しますが、それほど強力ではありません。書き換えパスは名前と値のペアを使用して指定します。単純な例では、app_01 アプリケーションが、イメージを含む抽象的なディレクトリ名を持ち、そのディレクトリをもっと直感的なものに再マップします。#Simple example, images are accessible under abc path /app-01/abc/=/app-01/images/
uriworkermap.properties ファイルを作成する
uriworkermap.propertiesファイルには、デプロイされたアプリケーションのマッピング設定情報が含まれます。以下の行をこのファイルに追加します。# images, css files, path /status and /web-console will provided by nodes defined in load-balancer /css/*=router /images/*=router /status=router /web-console|/*=router # Example of exclusion from mapping, logo.gif won't be displayed !/web-console/images/logo.gif=* # Requests to /app-01 and /app-02 will be routed to nodes defined in load-balancer /app-01|/*=router /app-02|/*=router # mapping for management console, nodes in cluster can be enabled or disabled here /jkmanager|/*=status
workers.properties ファイルを作成する
worker.propertiesファイルには、ワーカーラベルとサーバーインスタンス間のマッピング定義が含まれます。以下の行をこのファイルに追加します。# The advanced router LB worker worker.list=router,status # First EAP server definition, port 8009 is standard port for AJP in EAP # # lbfactor defines how much the worker will be used. # The higher the number, the more requests are served # lbfactor is useful when one machine is more powerful # ping_mode=A – all possible probes will be used to determine that # connections are still working worker.worker01.port=8009 worker.worker01.host=127.0.0.1 worker.worker01.type=ajp13 worker.worker01.ping_mode=A worker.worker01.socket_timeout=10 worker.worker01.lbfactor=3 # Second EAP server definition worker.worker02.port=8009 worker.worker02.host= 127.0.0.100 worker.worker02.type=ajp13 worker.worker02.ping_mode=A worker.worker02.socket_timeout=10 worker.worker02.lbfactor=1 # Define the LB worker worker.router.type=lb worker.router.balance_workers=worker01,worker02 # Define the status worker for jkmanager worker.status.type=status
注記
workers.propertiesディレクティブについては、付録A workers.properties リファレンス を参照してください。IIS を再起動する
変更内容を反映するために IIS サーバーを再起動します。実行している IIS バージョンに対して以下のコマンドを実行します。- IIS 6
C:\> net stop iisadmin /Y C:\> net start w3svc
- IIS 7
C:\> net stop was /Y C:\> net start w3svc
ログを検証する
IIS が再起動されたら ISAPI ログを確認します。このログはisapi_redirect.propertiesの log_file プロパティで指定されたファイルの場所に保存されます。また、他のイベントについて IIS ログとイベントビューアを確認する必要があります。
パート IV. Netscape Server API
第13章 Netscape Server API とは
- 権限変換
- 名前変換
- パスチェック
- オブジェクトタイプ
- 要求応答
- ログトランザクション
第14章 Solaris での NSAPI コネクタの設定
注記
-b スイッチを使用して JBoss Enterprise Platform のインスタンスをパブリック IP アドレスにバインドします。IP アドレスのこれらの変更を反映させるために、SJWS マシンの workers.properties ファイルを編集してください。
14.1. 前提となる条件と設定
- ワーカーノードが JBoss Enterprise Platform 5.1 以降とともにインストールされていること。ネイティブコンポーネントは NSAPI コネクタの要件ではありません。この前提条件については、『『インストールガイド』』を参照してください。
- マスターノードが以下のいずれかのテクノロジの組み合わせと、オペレーティングシステムとアーキテクチャに適切なネイティブバイナリとともにインストールされていること。このインストールの前提条件については、『『インストールガイド』』を参照してください。
- Solaris 9 x86 と Sun Java System Web Server 6.1 SP12
- Solaris 9 SPARC 64 と Sun Java System Web Server 6.1 SP12
- Solaris 10 x86 と Sun Java System Web Server 7.0 U8
- Solaris 10 SPARC 64 と Sun Java System Web Server 7.0 U8
14.2. ワーカーノードとしてのサーバーインスタンスの設定
タスク: JBoss Enterprise Application Platform ワーカーノードの設定
前提条件
各ワーカーノードに対してサーバープロファイルを作成する
ワーカーノードとして設定するサーバープロファイルのコピーを作成します (この手順ではdefaultサーバープロファイルを使用します)。[user@workstation jboss-ep-5.1]$ cd jboss-as/server [user@workstation server]$ cp -r default/ default-01 [user@workstation server]$ cp -r default/ default-02
各インスタンスに一意の名前を付ける
新しい各ワーカーインスタンスのdeploy/jbossweb.sar/server.xmlファイルの以下の行を編集します。<Engine name="jboss.web" defaultHost="localhost">
示しされたように一意のjvmRoute値を追加します。この値はクラスタ内のこのノードの ID です。default-01サーバープロファイルの場合:<Engine name="jboss.web" defaultHost="localhost" jvmRoute="worker01">
default-02サーバープロファイルの場合:<Engine name="jboss.web" defaultHost="localhost" jvmRoute="worker02">
セッション処理を有効にする
各ワーカーノードのdeployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xmlファイルの以下の行をコメント解除します。<property name="useJK">false</property>
このプロパティは、mod_jk と他のコネクタバリアントを調整するために特別なセッション処理を使用するかどうかを制御します。両方のワーカーノードでこのプロパティをtrueに設定します。<property name="useJK">true</property>
ワーカーノードを起動する
個別のコマンドインターフェースで各ノードワーカーを起動します。-bスイッチを使用して各ノードが異なる IP アドレスにバインドされるようにします。[user@workstation jboss-eap-5.1]$ ./jboss-as/bin/run.sh -b 127.0.0.1 -c default-01
[user@workstation jboss-eap-5.1]$ ./jboss-as/bin/run.sh -b 127.0.0.100 -c default-02
14.3. 初期クラスタリング設定
タスク: 初期クラスタリング動作の設定
前提条件
/tmp/connectors/jboss-ep-native-5.1/に抽出されたネイティブ Zip。この手順では、このパスは NATIVE と呼ばれます。- ディレクトリ
/tmp/connectorsはログ、プロパティファイル、および NSAPI ロックのストレージ場所として使用されます。 - SJWS は、「ファイル命名規則」 の省略された SJWS ファイルパスで指定されたいずれかの場所でインストールされます。
サーブレットマッピングを無効にする
SJWS/PROFILE/config/default-web.xmlファイルの Built In Servlet Mappings 以下で、サンプルコードに示されているように以下のサーブレットのマッピングを無効にします。- default
- invoker
- jsp
<!-- ==================== Built In Servlet Mappings ===================== --> <!-- The servlet mappings for the built in servlets defined above. --> <!-- The mapping for the default servlet --> <!--servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping--> <!-- The mapping for the invoker servlet --> <!--servlet-mapping> <servlet-name>invoker</servlet-name> <url-pattern>/servlet/*</url-pattern> </servlet-mapping--> <!-- The mapping for the JSP servlet --> <!--servlet-mapping> <servlet-name>jsp</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping-->
必要なモジュールとプロパティをロードする
以下の行をSJWS/PROFILE/config/magnus.confファイルに追加します。Init fn="load-modules" funcs="jk_init,jk_service" shlib="NATIVE/lib/nsapi_redirector.so" shlib_flags="(global|now)" Init fn="jk_init" worker_file="/tmp/connectors/workers.properties" log_level="debug" log_file="/tmp/connectors/nsapi.log" shm_file="/tmp/connectors/jk_shm"
これらの行はjk_init関数とjk_service関数により使用されるnsapi_redirector.soモジュールの場所とワーカーノードおよびその属性を定義するworkers.propertiesファイルの場所を定義します。注記
NATIVE/lib/nsapi_redirector.soパスのlibディレクトリは 32 ビットマシンにだけ適用されます。64 ビットマシンでは、このディレクトリはlib64という名前になります。
14.4. NSAPI で基本的なクラスを設定
タスク: NSAPI を使用した基本的なクラスタの設定
/nc パスを提供し、worker01 が /status を提供し、他のすべてのパスが obj.conf ファイルの最初の部分で定義されます。
前提条件
- SJWS は、「ファイル命名規則」 の省略された SJWS ファイルパスで指定されたいずれかの場所でインストールされます。
NSAPI を介して提供するパスを定義する
SJWS/PROFILE/config/obj.confファイルを編集します。示されたように、NSAPI を介して提供するパスをdefaultオブジェクト定義の最後で定義します。<Object name="default"> [...] NameTrans fn="assign-name" from="/status" name="jknsapi" NameTrans fn="assign-name" from="/images(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/css(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/nc(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/jmx-console(|/*)" name="jknsapi" </Object>このobj.confファイルで JBoss Enterprise Platform インスタンスにデプロイされた任意のアプリケーションのパスをマップできます。サンプルコードでは、/ncパスがncという名前以下にデプロイされたアプリケーションにマップされます。各パスを提供するワーカーを定義する
SJWS/PROFILE/config/obj.confファイルを編集し、以下のjknsapiオブジェクト定義をdefaultオブジェクト定義の後に追加します。<Object name="jknsapi"> ObjectType fn=force-type type=text/plain Service fn="jk_service" worker="worker01" path="/status" Service fn="jk_service" worker="worker02" path="/nc(/*)" Service fn="jk_service" worker="worker01" </Object>
このjknsapiオブジェクトはdefaultオブジェクトのname="jknsapi"に割り当てられた各パスを提供するために使用されるワーカーノードを定義します。サンプルコードでは、3 つ目のサービス定義でpath値が指定され、定義されたワーカーノード (worker01) がデフォルトでjknsapiに割り当てられたすべてのパスを提供します。この場合、/statusパスをworker01に割り当てるサンプルコードの最初のサービス定義は余分です。ワーカーとその属性を定義する
ステップ 2 で定義した場所でworkers.propertiesファイルを作成します。このファイルでワーカーノードと各ワーカーノードのプロパティのリストを定義します。# An entry that lists all the workers defined worker.list=worker01, worker02 # Entries that define the host and port associated with these workers worker.worker01.host=127.0.0.1 worker.worker01.port=8009 worker.worker01.type=ajp13 worker.worker02.host=127.0.0.100 worker.worker02.port=8009 worker.worker02.type=ajp13
サーバーを再起動する
Sun Java System Web Server インスタンスを設定した後で、インスタンスを再起動して変更内容を反映します。Sun Java System Web Server 6.1 の場合:SJWS/PROFILE/stop SJWS/PROFILE/start
Sun Java System Web Server 7.0 の場合:SJWS/PROFILE/bin/stopserv SJWS/PROFILE/bin/startserv
14.5. NSAPI を使用した負荷分散されたクラスタの設定
タスク: NSAPI を使用した負荷分散されたクラスタの設定
前提条件
- SJWS は、「ファイル命名規則」 の省略された SJWS ファイルパスで指定されたいずれかの場所でインストールされます。
NSAPI を介して提供するパスを定義する
SJWS/PROFILE/config/obj.confを開き、示されたように、NSAPI を介して提供するパスをdefaultオブジェクト定義の最後に定義します。<Object name="default"> [...] NameTrans fn="assign-name" from="/status" name="jknsapi" NameTrans fn="assign-name" from="/images(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/css(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/nc(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/jmx-console(|/*)" name="jknsapi" NameTrans fn="assign-name" from="/jkmanager/*" name="jknsapi" </Object>このobj.confファイルで JBoss Enterprise Platform インスタンスにデプロイされた任意のアプリケーションのパスをマップできます。サンプルコードでは、/ncパスがncという名前以下にデプロイされたアプリケーションにマップされます。各パスを提供するワーカーを定義する
SJWS/PROFILE/config/obj.confを開き、以下のjknsapiオブジェクト定義をdefaultオブジェクト定義の後に追加します。<Object name="jknsapi"> ObjectType fn=force-type type=text/plain Service fn="jk_service" worker="status" path="/jkmanager(/*)" Service fn="jk_service" worker="router" </Object>
このjknsapiオブジェクトはdefaultオブジェクトのname="jknsapi"に割り当てられた各パスを提供するために使用されるワーカーノードを定義します。ワーカーとその属性を定義する
SJWS/PROFILE/config/workers.propertiesを作成します。このファイルでワーカーノードと各ワーカーノードのプロパティのリストを定義します。注記
workers.propertiesディレクティブについては、付録A workers.properties リファレンス を参照してください。# The advanced router LB worker worker.list=router,status #First EAP server definition, port 8009 is standard port for AJP in EAP # #lbfactor defines how much the worker will be used. #The higher the number, the more requests are served #lbfactor is useful when one machine is more powerful #ping_mode=A – all possible probes will be used to determine that #connections are still working worker.worker01.port=8009 worker.worker01.host=127.0.0.1 worker.worker01.type=ajp13 worker.worker01.ping_mode=A worker.worker01.socket_timeout=10 worker.worker01.lbfactor=3 #Second EAP server definition worker.worker02.port=8009 worker.worker02.host=127.0.0.100 worker.worker02.type=ajp13 worker.worker02.ping_mode=A worker.worker02.socket_timeout=10 worker.worker02.lbfactor=1 # Define the LB worker worker.router.type=lb worker.router.balance_workers=worker01,worker02 # Define the status worker worker.status.type=status
サーバーを再起動する
Sun Java System Web Server インスタンスを設定した後で、インスタンスを再起動して変更内容を反映します。Sun Java System Web Server 6.1 の場合:SJWS/PROFILE/stop SJWS/PROFILE/start
Sun Java System Web Server 7.0 の場合:SJWS/PROFILE/bin/stopserv SJWS/PROFILE/bin/startserv
パート V. 一般的な負荷分散タスク
第15章 HTTP セッションステートレプリケーション
複数のコンピュータサーバー (クラスタ) に HTTP クライアントセッション要求を分散するよう設計された専用のソフトウェアベースのサービス。ソフトウェアロードバランサの主要な目的はリソース使用率を最大化し、要求応答時間を短縮し、サーバーの過負荷を防ぐことです。ロードバランサは、サーバーの負荷と可用性に基づいてクライアントセッション要求をサーバークラスタに転送します。
クライアント (アプリケーション) とサーバー間の半永久的な接続。ロードバランサは、永続化でクライアントセッションが作成されるかどうか、またはサーバーの負荷および可用性い基づいてクライアントセッションが再分散されるかどうかを決定します。
単一のサーバーインスタンスにだけ割り当てられるクライアントセッション。ロードバランサはクライアントセッションに関連付けられたすべての HTTP 要求を割り当てられたサーバーインスタンスにだけルーティングします。セッションの永続化は、一般的にスティッキーセッションと呼ばれます。
セッションの永続化を参照してください。
15.1. アプリケーションでのセッションレプリケーションの有効化
web.xml 記述子でアプリケーションを分散可能としてタグ付けする必要があります。以下に例を示します。
<?xml version="1.0"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<distributable/>
</web-app>jboss-web.xml ファイルで replication-config 要素を使用することにより、セッションレプリケーションを使用できます。ただし、replication-config 要素は、以下で説明された 1 つ以上のデフォルト値を使用できる場合にのみ設定する必要があります。例は以下のとおりです。
<!DOCTYPE jboss-web PUBLIC
-//JBoss//DTD Web Application 5.0//EN
http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd>
<jboss-web>
<replication-config>
<cache-name>custom-session-cache</cache-name>
<replication-trigger>SET</replication-trigger>
<replication-granularity>ATTRIBUTE</replication-granularity>
<replication-field-batch-mode>true</replication-field-batch-mode>
<use-jk>false</use-jk>
<max-unreplicated-interval>30</max-unreplicated-interval>
<snapshot-mode>INSTANT</snapshot-mode>
<snapshot-interval>1000</snapshot-interval>
<session-notification-policy>com.example.CustomSessionNotificationPolicy</session-notification-policy>
</replication-config>
</jboss-web>setAttribute 呼び出しが存在しない場合、オブジェクト (したがって、セッションステートも) が変更され、レプリケートする必要があるかどうかをコンテナが明確に認識できないことです。この要素は 3 つの有効な値を持ちます。
- SET_AND_GET は保守的であり、最適ではありません (パフォーマンスの点で)。内容が変更されず、単にアクセスされた場合であってもセッションデータは常にレプリケートされます。この設定は JBoss Enterprise Application Platform 4 では (ある程度は) 適切です。なぜなら、この設定を使用すると、要求ごとに、セッションのタイムスタンプのレプリケーションがトリガされるためです。
max_unreplicated_intervalを 0 に設定すると、同じことを非常に小さいコストで実現できるため、Enterprise Application Platform 5 でSET_AND_GETを使用することは適切ではありません。 - SET_AND_NON_PRIMITIVE_GET は保守的であり、非プリミティブタイプがアクセスされた場合にのみレプリケートされます (つまり、このオブジェクトは
Integer、Long、Stringなどのよく知られた変更不可能な JDK タイプではありません)。これはデフォルト値です。 - SET を使用する場合は、データをレプリケートする必要があるときに開発者がセッションで
setAttributeを明示的に呼び出すことが前提とされます。この設定では、不必要なレプリケーションが回避され、パフォーマンスが大幅に向上しますが、セッションで保存された変更可能なオブジェクトが変更されたときに常にsetAttributeが呼び出されるようにするために非常に優れたコーディングが必要になります。
setAttribute を呼び出すと、セッションがレプリケーションを必要としているとマークされます。
- SESSION
- 属性が変更されたと見なされた場合に全体のセッション属性マップをレプリケートすることを指定します。レプリケーションは要求側で行われます。このオプションにより、ほとんどのデータがレプリケートされ、レプリケーションコストが最大になります。ただし、すべての属性値は常に一緒にレプリケートされるため、セッションがシリアル化解除されたときに属性値間の参照は破壊されなくなります。このため、これはデフォルト設定になります。
- ATTRIBUTE
- セッションが変更可能と見なす属性のみがレプリケートされることを指定します。レプリケーションは要求側で行われます。大量のデータを扱うセッション (一部のデータが頻繁に更新されない) では、このオプションによりレプリケーションパフォーマンスが大幅に向上することがあります。ただし、これは、お互いに参照を共有する異なる属性のオブジェクトを格納するアプリケーションには適していません (たとえば、
Addressオブジェクトへの参照を "wife" 属性の別のPersonオブジェクトと共有する "husband" 属性のPersonオブジェクト)。これは、属性が別々にレプリケートされ、セッションがリモートノードでシリアル化解除された場合は、共有された参照が破壊されるからです。
replication-config 要素下の他の要素はほとんど使用されません。
- <cacheName>
- 分散可能なセッションを格納し、クラスタでレプリケートするために使用する必要がある JBoss Cache 設定の名前を指定します。この要素を使用すると、さまざまなキャッシュ特性が必要な Web アプリケーションで、個別の別々に設定された JBoss Cache インスタンスの使用を指定できます。JBoss Enterprise Application Platform 4 では、使用するキャッシュは Web アプリケーションごとに変更できず、サーバー全体の設定でした。デフォルト値は
standard-session-cacheです。Web 階層クラスタリングに関する JBoss Cache 設定の詳細については、「セッションステートレプリケーションに使用される JBoss Cache インスタンスの設定」 を参照してください。 - <replication-field-batch-mode>
- 要求に関連付けられたすべてのレプリケーションメッセージを 1 つのメッセージにまとめるかどうかを指定します。これは、
replication-granularityがFIELDの場合にのみ適用できます。replication-field-batch-modeがtrueに設定されている場合は、セッション属性マップに格納されたオブジェクトに加えられた粒度の細かい変更が HTTP 要求が完了したときにレプリケートされます。それ以外の場合、これらの変更は発生したときにレプリケートされます。この値をfalseに設定することは推奨されません。デフォルト値はtrueです。 - <useJK>
- コンテナで、この Web アプリケーションの負荷分散に JK ベースのソフトウェアロードバランサ (mod_jk、mod_proxy、mod_cluster など) を使用することを前提とするかどうかを指定します。
trueに設定されている場合は、コンテナが各要求に関連付けられたセッション ID を調べ、フェールオーバーを検出した場合にセッション ID のjvmRoute部分を置き換えます。これは、URL を JK ロードバランサで処理できない Web アプリケーションに対してのみfalseに設定する必要があります。 - <max-unreplicated-interval>
- 要求の最大間隔を秒単位で設定します。この時間後、要求によりセッションがダーティになったかどうかに関係なくセッションのタイムスタンプのレプリケーションが要求によりトリガされます。このようなレプリケーションにより、クラスタの他のノードはセッションのタイムスタンプの最新の値を認識し、フェールオーバー時にレプリケートされないセッションが間違って時間切れになることがなくなります。また、フェールオーバー後に、
HttpSession.getLastAccessedTime()コールの値が適切になります。デフォルト値はnull(つまり、未指定) です。この場合、セッションマネージャは組み込まれた JBoss WebEngineに関するjvmRoute設定があるかどうかを確認して (「mod_jk と動作するよう JBoss を設定する」 を参照)、JK が使用されているかどうかを調べます。値が0の場合は、セッションがアクセスされたときに必ずタイムスタンプがレプリケートされます。値が-1の場合は、要求中の他のアクティビティ (属性の変更など) により、セッションに関連する他のレプリケーション作業が発生したときにだけタイムスタンプがレプリケートされます。HttpSession.getMaxInactiveInterval()値よりも大きい正の値は設定ミスとして扱われ、0に変換されます。つまり、各要求時にメタデータがレプリケートされます。デフォルト値は60です。 - <snapshot-mode>
- セッションが他のノードにレプリケートされるタイミングを指定します。可能な値は
INSTANT(デフォルト値) とINTERVALです。一般的な値INSTANTは、レプリケーションを実行する要求処理スレッドを使用して要求終了時に変更を他のノードにレプリケートします。この場合、snapshot-intervalプロパティは無視されます。INTERVALモードでは、snapshot-intervalミリ秒ごとに実行されるバックグラウンドタスクが作成され、変更されたセッションをチェックしてレプリケートします。replication-granularityがFIELDに設定されている場合、このプロパティは無効です。FIELDである場合は、instantモードが使用されます。 - <snapshot-interval>
- この Web アプリケーションに対して変更されたセッションをレプリケートするバックグラウンドタスクを開始する頻度 (ミリ秒単位) を定義します。
snapshot-modeがintervalに設定されている場合のみ意味を持ちます。 - <session-notification-policy>
- 登録された任意の
HttpSessionListener、HttpSessionAttributeListener、またはHttpSessionBindingListenerにサーブレット仕様通知を送出するかどうかを管理するために使用する必要があるClusteredSessionNotificationPolicyインターフェースの実装の完全修飾名を指定します。重要
非クラスタ環境で適切なイベント通知がクラスタ環境で必ずしも適切であるとは限りません。通知が適切でない理由の例については、https://jira.jboss.org/jira/browse/JBAS-5778 を参照してください。適切なClusteredSessionNotificationPolicyを設定すると、アプリケーション作成者は発行される通知を細かく制御できます。
15.2. HttpSession パッシブ化およびアクティブ化
比較的未使用のセッションを永続ストレージに保存し、メモリから削除することによりメモリ使用を制御するプロセス。
web.xml ファイルに distributable ディレクティブが含まれるクラスタ化された Web アプリケーションからの HttpSessions パッシブ化をサポートします。
- コンテナが新しい要求の作成を要求するとき。現在アクティブなセッションの数が設定可能な制限を超えると、セッションをパッシブ化し、メモリのスペースを空けることが試行されます。
- JBoss Web バックグラウンドタスクスレッドが実行される周期 (デフォルトでは 10 秒ごと)。
- Web アプリケーションがデプロイされ、他のサーバーでアクティブなセッションのバックアップコピーが新しいデプロイ Web アプリケーションのセッションマネージャにより取得されたとき。
- セッションが設定可能な最大アイドル時間より長い時間使用されていない場合。
- アクティブセッションの数が設定可能な最大値を超え、セッションが設定可能な最小アイドル時間より長い時間使用されていない場合。
15.2.1. HttpSession パッシブ化の設定
WEB-INF ディレクトリの jboss-web.xml デプロイメント記述子により設定されます。
<!DOCTYPE jboss-web PUBLIC
-//JBoss//DTD Web Application 5.0//EN
http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd>
<jboss-web>
<max-active-sessions>20</max-active-sessions>
<passivation-config>
<use-session-passivation>true</use-session-passivation>
<passivation-min-idle-time>60</passivation-min-idle-time>
<passivation-max-idle-time>600</passivation-max-idle-time>
</passivation-config>
</jboss-web>- max-active-session許可されるアクティブセッションの最大数を決定します。セッションマネージャにより管理されるセッションの数がこの値を超え、パッシブ化が有効化される場合、設定された
passivation-min-idle-timeに基づいて超過はパッシブ化されます。パッシブ化が完了した後でも (または、パッシブ化が無効な場合)、アクティブセッションの数がこの制限を超えるは、新しいセションの作成が拒否されます。-1(デフォルト値) に設定された場合、制限はありません。 - use-session-passivationWeb アプリケーションに対してセッションパッシブ化が有効であるかどうかを決定します。デフォルト値は
falseです。 - passivation-min-idle-time
max-active-sessionsにより定義された値に従うアクティブセッション数を削減するために、コンテナがパッシブ化を考慮する前にセッションを無効にする最小時間 (秒単位) を決定します。値が-1(デフォルト値) の場合は、passivation-max-idle-timeより前にセッションのパッシブ化が無効にされます。max-active-sessionsが設定されている場合は、-1の値や大きい値は推奨されません。 - passivation-max-idle-timeコンテナがセッションをパッシブ化してメモリを保存する前にセッションを無効にできる最大時間 (秒数) を決定します。このようなセッション のパッシブ化は、アクティブセッション数が
max-active-sessionsを超えるかどうかに関係なく、実行されます。web.xmlsession-timeout設定よりも小さい必要があります。値が-1(デフォルト値) である場合は、無効の最大時間に基づいてパッシブ化が無効になります。
max-active-sessions を設定する場合はこれを考慮してください。他のノードからレプリケートされたセッションの数は、buddy replication が有効であるかどうかによっても異なります。
numBuddies 設定 (1) を使用する場合、各ノードはメモリ内に 200 個のセッションを保存します。
15.3. セッションステートレプリケーションに使用される JBoss Cache インスタンスの設定
jboss-web.xml の cacheName 要素によって制御されます (「アプリケーションでのセッションレプリケーションの有効化」 を参照)。ほとんどの場合、standard-session-cache のデフォルト値が適切であるため、これを設定する必要はありません。
CacheManager サービスの JBoss Cache 設定では、複数のオプションが利用可能です。
注記
standard-session-cache 設定は Web セッションレプリケーションを使用する場合のためにすでに最適化されており、ほとんどの設定は変更する必要がありません。管理者は以下の設定を変更できます。
- cacheModeデフォルト値は
REPL_ASYNCであり、クラスタに送信されたセッションレプリケーションメッセージが、メッセージが受信され、処理されたことを確認する応答を他のクラスタノードから受け取るまで待たないことを指定します。代わりのモードであるREPL_SYNCは、セッションステートが受信されたが、パフォーマンスが大幅に低下することを確認します。注記
cacheMode に対して他の利用可能なパラメータの詳細については、『『管理設定ガイド』』の節「『キャッシュモード』」を参照してください。 - buddyReplicationConfig セクションの enabled プロパティバディレプリケーションを有効にする場合は、
trueに設定します。デフォルト値はfalseです。注記
cacheMode に対して他の利用可能なパラメータの詳細については、『『管理設定ガイド』』の節「『バディレプリケーション』」を参照してください。 - buddyReplicationConfig セクションの numBuddies プロパティセッションがレプリケートされるバックアップノードの数を増加させる場合はデフォルト値 (
1) よりも大きい値に設定します。バディレプリケーションが有効な場合にのみ重要です。注記
cacheMode に対して他の利用可能なパラメータの詳細については、『『管理設定ガイド』』の節「『バディレプリケーション』」を参照してください。 - buddyReplicationConfig セクションの buddyPoolName プロパティバディレプリケーションが有効な場合に推奨されるレプリケーショングループを指定する方法。JBoss Cache は同じプール名を共有するバディを選択しようとします (利用可能でない場合は他のバディを選択します)。バディレプリケーションが有効な場合のみ重要です。
注記
cacheMode に対して他の利用可能なパラメータの詳細については、『『管理設定ガイド』』の節「『バディレプリケーション』」を参照してください。 - multiplexerStackキャッシュが使用する必要がある JGroups プロトコルスタックの名前。
注記
cacheMode に対して他の利用可能なパラメータの詳細については、『『管理設定ガイド』』の節「『チャネルファクトリサービス』」を参照してください。 - clusterNameJGroups がこのキャッシュのチャネルに使用する名前の指定。これは、このプロパティが他のすべてのキャッシュ設定からの異なる値を持つ必要がある、新しいキャッシュ設定を作成する場合にのみ変更します。
第16章 クラスタ化されたシングルサインオンの使用
org.apache.catalina.authenticator.SingleSignOn バルブの JBoss 固有の拡張機能です。
16.1. 設定
JBOSS_HOME/server/PROFILE/deploy/jbossweb.sar/server.xml ファイルの適切な Host 要素に ClusteredSingleSignOn バルブを追加する必要があります。バルブ要素はすでに標準的なファイルに含まれています。単にコメント解除することが必要なだけです。バルブ設定を以下に示します。
<Valve className="org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn" />
- className は、使用するバルブ実装の Java クラス名を設定するために必要な属性です。これは
org.jboss.web.tomcat.service.sso.ClusteredSingleSignに設定する必要があります。 - cacheConfig クラスタ化された SSO キャッシュに使用するキャッシュ設定の名前です。デフォルト値は
clustered-ssoです。注記
キャッシュ設定の詳細については、『『管理設定ガイド』』の節「『JBoss Enterprise Application Platform の CacheManager サービス』」を参照してください。 - treeCacheName は廃止されました。
cacheConfigを使用してください。クラスタ化された SSO キャッシュに使用する JBoss Cache MBean の JMX ObjectName を指定します。cacheConfigの値を使用して CacheManager サービスからキャッシュを見つけることができない場合は、この ObjectName 以下の JMX で登録された mbean を見つけようとします。デフォルト値はjboss.cache:service=TomcatClusteringCacheです。 - maxEmptyLife は、アクティブセッションがない SSO が要求により使用可能になる最大秒数です。クラスタ化された SSO バルブは SSO に関連するセッションを管理するクラスタノードを追跡します。この属性に正の値を使用すると、SSO に関連付けられた任意のセッションを処理した唯一のノードのシャットダウンが適切に処理されます。このシャットダウンにより、セッションのローカルコピーが無効になり、SSO からすべてのセッションが削除されます。maxEmptyLife がゼロの場合は、SSO がローカルセッションコピーとともに終了します。ただし、セッションのバックアップコピー (クラスタ化された Web アプリケーションからの場合) は他のクラスタノードで利用可能です。管理されたセッションの存続期間を超えて SSO が存在するようにすると、ユーザーには異なるクラスタノードにフェールオーバーできる他の要求を行う時間が与えられ、セッションのバックアップコピーが有効化されます。デフォルト値は
1800(つまり、30 分) です。 - processExpiresInterval は、バルブが 'maxEmptyLife' を超えた SSO を検出し、無効化する処理間の最小秒数です。'processExpiresInterval' ごとにクリーンアップなどの処理が行われるのではなく、その値よりも頻繁に処理が行われないことを意味します。デフォルト値は
60です。 - requireReauthentication はセキュリティ Realm に対して各要求を再認証する必要があるかどうかを決定するフラグです。"true" の場合、このバルブはキャッシュされたセキュリティクレデンシャル (ユーザー名とパスワード) を使用して JBoss Web セキュリティ Realm に対して SSO セッションに関連付けられた各要求を再認証します。
falseの場合は、Realm で再チェックせずにバルブ自体が有効な SSO クッキーの存在に基づいて要求を認証できます。trueに設定すると、異なるsecurity-domain設定を持つ Web アプリケーションが SSO を共有できるようになります。デフォルト値はfalseです。
16.2. SSO の動作
javax.servlet.http.HttpSession.invalidate() メソッドを呼び出すことにより)、すべての Web アプリケーションのユーザーのセッションは無効化されます。
16.3. 制限
- JBoss サーバーのクラスタ内でのみ役に立ちます。SSO は他のリソースに伝播しません。
- コンテナにより管理された認証の使用が必要です (
web.xmlの<login-config>要素を使用)。 - クッキーを必要とします。SSO はクッキーを使用して保守され、URL の書き換えはサポートされていません。
requireReauthenticationがtrueに設定されない限り、同じ SSO バルブに設定されたすべての Web アプリケーションは同じ JBoss WebRealmと JBoss Securitysecurity-domainを共有する必要があります。つまり、以下のようになります。server.xmlで、Realm要素をHost要素 (または周りのEngine要素) 内部にネストできます。ただし、関連するいずれかの Web アプリケーションでパッケージ化されるcontext.xml内部ではネストできません。jboss-web.xmlまたはjboss-app.xmlで設定されたsecurity-domainはすべての Web アプリケーションで同一である必要があります。requireReauthenticationをtrueに設定し、異なる Web アプリケーションに対して異なるsecurity-domain(または、異なるRealm) を使用する場合であっても、さまざまなセキュリティ統合が同じクレデンシャル (ユーザー名やパスワードなど) を受け入れる必要があります。
16.4. クッキードメインの設定
cookieDomain 設定属性をサポートします。この属性により、SSO クッキーのドメイン (ブラウザがクッキーを提供する一連のホスト) を設定することができます。デフォルトでは、ドメインは "/" であり、ブラウザはクッキーを発行したホストにだけクッキーを提供します。cookieDomain 属性により、クッキーの範囲となるドメインは拡張されます。
http://app1.xyz.com と http://app2.xyz.com を持つ 2 つのアプリケーションがあり、SSO コンテキストを共有したいとします。これらのアプリケーションはクラスタ内のさまざまなサーバーで実行できます。または、関連付けられた仮想ホストは複数のエイリアスを持つことができます。これは、以下の設定でサポートされます。
<Valve className="org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn"
cookieDomain="xyz.com" />
第17章 完全な使用例
localhost でリッスンしているプロキシサーバー:
<LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so
Listen 127.0.0.1:6666
<VirtualHost 127.0.0.1:6666>
<Directory />
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Directory>
KeepAliveTimeout 60
MaxKeepAliveRequests 0
ManagerBalancerName mycluster
ServerAdvertise On
AdvertiseFrequency 5
</VirtualHost>
<Location /mod_cluster-manager>
SetHandler mod_cluster-manager
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
JBOSS_EAP_DIST/server/PROFILE/deploy/jbossweb.sar/server.xml のリスナー定義を以下に示します。
<!-- Non-clustered mode --> <Listener className="org.jboss.web.tomcat.service.deployers.MicrocontainerIntegrationLifecycleListener" delegateBeanName="ModClusterService"/> <!-- Clustered mode Listener className="org.jboss.web.tomcat.service.deployers.MicrocontainerIntegrationLifecycleListener" delegateBeanName="HAModClusterService"/-->
Following are the required dependencies for the WebServer bean in JBOSS_EAP_DIST/server/PROFILE/deploy/jbossweb.sar/META-INF/jboss-beans.xml . Add them to the existing dependencies.
<bean name="WebServer" class="org.jboss.web.tomcat.service.deployers.TomcatService"> <!-- ... --> <depends>ModClusterService</depends><!-- Non-clustered mode --> <!--depends>HAModClusterService</depends--><!-- Clustered mode --> <!-- ... --> </bean>
以下は、192.168.1.0/24 サブネットのクラスタノードに対して iptables を使用した場合のファイアウォールルールの例です。
/sbin/iptables -I INPUT 5 -p udp -d 224.0.1.0/24 -j ACCEPT -m comment --comment "mod_cluster traffic" /sbin/iptables -I INPUT 6 -p udp -d 224.0.0.0/4 -j ACCEPT -m comment --comment "JBoss Cluster traffic" /sbin/iptables -I INPUT 9 -p udp -s 192.168.1.0/24 -j ACCEPT -m comment --comment "cluster subnet for inter-node communication" /sbin/iptables -I INPUT 10 -p tcp -s 192.168.1.0/24 -j ACCEPT -m comment --comment "cluster subnet for inter-node communication" /etc/init.d/iptables save
付録A workers.properties リファレンス
HTTPD_DIST/conf/workers.properties で定義されます。このファイルは、さまざまな Servlet コンテナが存在する場所とコールが負荷分散される方法を指定します。
workers.properties ファイルには、以下の 2 つのセクションが含まれます。
- Global Properties
- このセクションには、すべてのワーカーに適用されるディレクティブが含まれます。
- Worker Properties
- このセクションには、個別のワーカーに適用されるディレクティブが含まれます。
worker.worker_name.directive です。
- worker
- すべてのワーカープロパティで同一の接頭辞。
- worker_name
- ワーカーに与えられた任意の名前 (node1、node_01、Node_1 など)。
- directive
- 必要な特定のディレクティブ。
注記
worker.properties 設定ディレクティブの完全なリストについては、『Apache Tomcat Connector - Reference Guide』を参照してください。
worker.properties グローバルディレクティブ
- worker.list
- mod_jk により使用されたワーカー名のリストを指定します。このリストのワーカーは要求をマップするために使用できます。
注記
ロードバランサにより管理されない単一ノード設定はworker.list=[worker name]に設定する必要があります。
workers.properties 必須ディレクティブ
- type
- ワーカーのタイプを指定し、ワーカーに適用可能なディレクティブを決定します。デフォルト値は
ajp13であり、Web サーバーと Apache httpd サーバー間の通信に選択する場合に推奨されるワーカータイプです。他の値にはajp14、lb、statusなどがあります。ajp13 の詳細については、『The Apache Tomcat Connector - AJP Protocol Reference』を参照してください。
workers.properties 接続ディレクティブ
- host
- ワーカーのホスト名または IP アドレス。ワーカーノードは ajp13 プロトコルスタックをサポートする必要があります。デフォルト値は
localhostです。ホスト名または IP アドレスの後にポート番号を付加することによりホストディレクティブの一分としてportディレクティブを指定できます (たとえば、worker.node1.host=192.168.2.1:8009やworker.node1.host=node1.example.com:8009など)。 - port
- 定義されたプロトコル要求をリッスンするリモートサーバーインスタンスのポート番号。デフォルト値は、AJP13 ワーカーのデフォルトリッスンポートである
8009です。AJP14 ワーカーを使用する場合は、このバルブを8011に設定する必要があります。 - ping_mode
- 現在のネットワークの状態を調べるために接続がプローブされる条件を指定します。プローブは CPing に空の AJP13 パケットを使用し、指定されたタイムアウト内に返答として CPong を期待します。ディレクティブフラグの組み合わせを使用して条件を指定します。フラグはカンマ区切りではありません。たとえば、適切なディレクティブフラグセットは
worker.node1.ping_mode=CIです。- C (connect)
- サーバーの接続後に条件がプローブされることを指定します。
connect_timeoutディレクティブを使用してタイムアウトを指定します。指定しない場合は、ping_timeoutの値が使用されます。 - P (prepost)
- サーバーに各要求を送信した後に条件がプローブされることを指定します。
prepost_timeoutディレクティブを使用してタイムアウトを指定します。指定しない場合は、ping_timeoutの値が使用されます。 - I (interval)
- 通常の内部保守サイクルの間に接続がプローブされることを指定します。
connection_ping_intervalディレクティブを使用して各間隔の間のアイドル時間を指定します。指定しない場合は、ping_timeoutの値が使用されます。 - A (all)
- すべてのディレクティブが適用されることを指定する最も一般的な設定。高度な
*_timeoutディレクティブについては、『Apache Tomcat Connector - Reference Guide』を参照してください。
- ping_timeout
- CPing 接続プローブに対する CPong 回答を待機する時間を指定します (
ping_modeを参照)。デフォルト値は 10000 (ミリ秒) です。
worker.properties 負荷分散ディレクティブ
- lbfactor
- 個々のワーカーに対する負荷分散要素を指定します。ロードバランサのメンバーワーカーに対してのみ指定されます。このディレクティブは、ワーカーに分散された HTTP 要求負荷とクラスタ内の他のワーカーの相対的な量を定義します。このディレクティブが適用される一般的な例は、クラスタ内の他のサーバーよりも処理パワーが大きいサーバーを区別する場合です。たとえば、ワーカーが他のワーカーよりも 3 倍の負荷を引き受ける必要がある場合は、
worker.worker name.lbfactor=3を指定します。 - balance_workers
- ロードバランサが管理する必要があるワーカーノードを指定します。ディレクティブは同じロードバランサに対して複数回使用でき、workers.properties ファイルで指定されたカンマ区切りのワーカー名リストから構成されます。
- sticky_session
- SESSION ID を持つワーカーに対する要求が同じワーカーに再びルーティングされるかどうかを指定します。デフォルト値は
0(false) です。1(true) に設定されると、ロードバランサの永続性が有効になります。たとえば、worker.loadbalancer.sticky_session=0を指定する場合、各要求はクラスタ内の各ノード間で負荷分散されます。つまり、同じセッションの異なる要求はサーバーの負荷に基づいて異なるサーバーに送信されます。worker.loadbalancer.sticky_session=1の場合、各セッションはセッションが終了するまで 1 つのサーバーに永続化 (ロック) され、そのサーバーが利用可能になります。
付録B Java プロパティリファレンス
B.1. プロキシ設定
- サーバーの起動時
- アドバタイズメカニズムを介してプロキシが検出されるとき
- エラーリカバリ中にプロキシの設定がリセットされるとき
プロキシ設定値
- stickySession (デフォルト値は
true) - 可能な場合に、該当するセッションの後続要求を同じノードにルーティングするかどうかを指定します。
- stickySessionRemove (デフォルト値は
false) - バランサが固定されたノードに要求をルーティングできない場合に、httpd プロキシがセッションスティッキネスを削除するかどうかを指定します。
stickySessionがfalseの場合、このプロパティは無視されます。 - stickySessionForce (デフォルト値は
true) - バランサが固定されたノードに要求をルーティングできない場合に、httpd プロキシがエラーを返すかどうかを指定します。
stickySessionがfalseの場合、このプロパティは無視されます。 - workerTimeout (デフォルト値は
-1) - ワーカーが要求を処理できるようになるまで待機する時間を秒数で指定します。バランサのすべてのワーカーが使用できない場合、しばらくしてから (workerTimeout/100) mod_cluster が使用可能なワーカーを見つけようとします。値が
-1の場合、httpd はワーカーが利用可能になるまで待機せず、ワーカーが利用可能でない場合はエラーを返します。 - maxAttempts (デフォルト値は
1) - 異常終了するまで httpd プロキシが該当する要求をワーカーに送信しようとする回数を指定します。最小値は 1 であり、異常終了する前に 1 度だけ送信を試行します。
- flushPackets (デフォルト値は
false) - パケットフラッシュが有効であるか、無効であるかを指定します。
- flushWait (デフォルト値は
-1) - パケットを破棄するまで待機する時間を指定します。値が
-1の場合は永遠に待機します。 - ping (デフォルト値は
10) - ping に対して pong 回答を受けとるまで待機する時間 (秒単位)
- smax
- ソフト最大アイドル接続数を指定します。最大値は httpd スレッド設定 (
ThreadsPerChildまたは1) によって決定されます。 - ttl (デフォルト値は
60) - アイドル接続が持続する時間 (秒単位) を指定します。
smaxしきい値より大きくします。 - nodeTimeout (デフォルト値は
-1) - エラーを返すまで mod_cluster がバックエンドサーバーの応答を待機する時間 (秒単位) を指定します。mod_cluster は要求を転送する前に常に cping/cpong を使用します。mod_cluster により使用される
connectiontimeout値は ping 値です。 - balancer (デフォルト値は
mycluster) - ロードバランサの名前を指定します。
- domain (デフォルト値ではありません)
- 同じドメイン内の jvmRoutes で負荷が分散される方法を指定するオプションのパラメータ。分割されたセッションレプリケーション (バディレプリケーションなど) とともに
domainが使用されます。
B.2. 負荷設定
付録C 改訂履歴
| 改訂履歴 | |||
|---|---|---|---|
| 改訂 1.0.2-12.1 | Wed Feb 11 2015 | Lucas Costi | |
| |||
| 改訂 1.0.2-12 | Mon Aug 13 2012 | Misha Husnain Ali | |
| |||
| 改訂 1.0.2-11 | Tue Jun 21 2011 | Rebecca Newton | |
| |||