HTTP コネクタ負荷分散ガイド
JBoss Enterprise Application Platform 向け HTTP 負荷分散
エディッション 5.1.2
Jared Morgan
Lead Writer および Content Architectjmorgan@redhat.com
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 (mod_jk)
第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 (mod_cluster)
第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
仮想ホストを作成します。
次の <VirtualHost> ブロックをJBOSS_EWS_DIST/httpd/conf.d/JBoss_HTTP.conf
ファイルに追加します。<VirtualHost IP_ADDRESS:PORT_NUMBER> <Directory> 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 Web Server 上で実行Sul場合は、jvm メトリクスのみが Load-demo アプリケーションで利用可能となっています。 - JBoss Enterprise Application Platform の場合:
[home]$ ./JBOSS_EAP_DIST/bin/run.sh
JBoss Enterprise Web Server では、Catalina Service Name を指定します。
重要
この手順は JBoss Enterprise Web Server で Tomcat 6 を利用する場合のみ該当します。JBoss Enterprise Application サーバーでデモアプリケーションを実行する場合はこの手順を飛ばしてください。$JBOSS_EWS_DIST/mod_cluster/src/demo/resources/web.xml
にて、<web-app> 配下に、サービスとして Catalina を指定する <context-param> ディレクティブを追加します。<context-param> <param-name>service-name</param-name> <param-value>Catalina</param-value> </context-param>
ワーカーノードへのデモ 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 (ISAPI)
第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
に名前を変更します。各インスタンスに一意の名前を付ける
新しい各ワーカーインスタンスの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>
ワーカーノードを起動します。
個別のコマンドラインインターフェースで各ワーカーノードを起動します。--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
を (記述されたとおりに) 指定します。- [実行可能ファイル]:
C:\connectors\jboss-ep-5.1\native\sbin\isapi_redirect.dll
- [OK] をクリックして値を保存し、[フィルタのプロパティの追加と編集] ダイアログを閉じます。
注記
IIS はまだリソースの要求を受け取っていないため、[ISAPI フィルタ] タブではjboss
フィルタステータスと優先度が [不明] と表示されます。要求が実行されると、ステータスと優先度はそれぞれ [読み込み済み] と [高] に変わります。
タスク: ISAPI 仮想ディレクトリを定義する
- [既定の Web サイト] を右クリックし、[新規] → [仮想ディレクトリの追加]をクリックします。[仮想ディレクトリの追加] ウィンドウが開きます。
- [仮想ディレクトリの追加] ウィンドウで以下の値を指定します。
- [エイリアス]:
jboss
を (記述されたとおりに) 指定します。- [物理パス]:
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
を指定します。- [必要なファイル]:
- パス
C:\connectors\jboss-ep-5.1\native\sbin\isapi_redirect.dll
- [拡張の状態を許可済みに設定する]:
- チェックボックスを選択します。
- [OK] をクリックして値を保存し、[新しい Web サービス拡張] ウィンドウを閉じます。
jboss
Web 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 パス]:
c:\connectors\jboss-ep-5.1\native\sbin\isapi_redirect.dll
と指定します。- [説明]:
jboss
- [拡張パスの実行を許可する]
- チェックボックスを選択します。
- [OK] をクリックして値を保存し、[ISAPI または CGI の制限の追加] ウィンドウを閉じます。
注記
[ISAPI および CGI の制限] 機能ビューに、jboss
制限とパスが表示されます。
タスク: JBoss ネイティブ仮想ディレクトリを定義する
- [既定の Web サイト] を右クリックし、[仮想ディレクトリの追加] をクリックします。[仮想ディレクトリの追加] ウィンドウが開きます。
- [仮想ディレクトリの追加] ウィンドウで以下の値を指定します。
- [エイリアス]:
jboss
を (記述されたとおりに) 指定します。- [物理パス]:
C:\connectors\jboss-ep-5.1\native\sbin\
- [OK] をクリックして値を保存し、[仮想ディレクトリの追加] ウィンドウを閉じます。
タスク: JBoss ネイティブ ISAPI リダイレクトフィルタを定義する
- ツリービューペインで、[サイト] → [既定の Web サイト]を展開します。
- [ISAPI フィルタ] をダブルクリックします。[ISAPI フィルタ] 機能ビューが開きます。
- [Actions (アクション)] ペインで、[追加] をクリックします。[ISAPI フィルタの追加] ウィンドウが開きます。
- 以下の値を [ISAPI フィルタの追加] ウィンドウで指定します。
- [フィルタ名]:
jboss
を (記述されたとおりに) 指定します。- [実行可能ファイル]:
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 初期クラスタリング設定」 を参照してください。
- 以下の手順では、ログ、プロパティファイル、および NSAPI ロックを保存するために
C:\connectors
ディレクトリが使用されていることを前提としています。
isapi_redirect.properties ファイルを作成する
C:\connectors\jboss-ep-5.1\native\sbin\
isapi_redirect.properties
という名前の新しいファイルを作成します。重要
isapi_redirect.properties
ファイルは、isapi_redirect.dll
ファイルと同じディレクトリに存在する必要があります。isapi_redirect.properties
に次の情報を追加します。# 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 初期クラスタリング設定」 を参照してください。
- 以下の手順では、ログ、プロパティファイル、および NSAPI ロックを保存するために
C:\connectors
ディレクトリが使用されていることを前提としています。
isapi_redirect.properties ファイルを作成する
C:\connectors\jboss-ep-5.1\native\sbin\
isapi_redirect.properties
という名前の新しいファイルを作成します。重要
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 (NSAPI)
第13章 Netscape Server API とは
- 権限変換
- 名前変換
- パスチェック
- オブジェクトタイプ
- 要求応答
- ログトランザクション
第14章 Solaris での NSAPI Connector の設定
注記
-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.xml
session-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章 クラスター化されたシングルサインオン (SSO) の使用
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
が使用されます。
付録C 改訂履歴
改訂履歴 | |||
---|---|---|---|
改訂 5.1.2-2.400 | 2013-10-30 | Rüdiger Landmann | |
| |||
改訂 5.1.2-2 | 2012-07-18 | Anthony Towns | |
| |||
改訂 5.1.2-100 | Thu Dec 8 2011 | Jared Morgan | |
| |||
改訂 5.1.1-100 | Mon Jul 18 2011 | Jared Morgan | |
|