22.6. mod_cluster HTTP コネクター
mod_cluster コネクターは Apache HTTP Server ベースのロードバランサーです。通信チャネルを使用して、リクエストを Apache HTTP Server からアプリケーションサーバーノードのセットの 1 つに転送します。
他のコネクターと比べて mod_cluster コネクターには複数の利点があります。
- mod_cluster Management Protocol (MCMP) は、JBoss EAP サーバーと mod_cluster が有効な Apache HTTP Server との間の追加的な接続です。HTTP メソッドのカスタムセットを使用してサーバー側の負荷分散係数およびライフサイクルイベントを Apache HTTP Server サーバーに返信するために JBoss EAP サーバーによって使用されます。
- mod_cluster がある Apache HTTP Server を動的に設定すると、手動設定を行わずに JBoss EAP サーバーが負荷分散に参加できます。
- JBoss EAP は、mod_cluster がある Apache HTTP Server に依存せずに負荷分散係数の計算を行います。これにより、負荷分散メトリックが他のコネクターよりも正確になります。
- mod_cluster コネクターにより、アプリケーションライフサイクルを細かく制御できるようになります。各 JBoss EAP サーバーは Web アプリケーションコンテキストライフサイクルイベントを Apache HTTP Server サーバーに転送し、指定コンテキストのルーティングリクエストを開始または停止するよう通知します。これにより、リソースを使用できないことが原因の HTTP エラーがエンドユーザーに表示されないようになります。
- AJP、HTTP、または HTTPS トランスポートを使用できます。
modcluster
サブシステムの特定の設定オプションに関する詳細は、ModCluster サブシステムの属性 を参照してください。
22.6.1. Apache HTTP Server の mod_cluster の設定
JBoss Core Services Apache HTTP Server をインストールする場合や JBoss Web Server を使用する場合、mod_cluster モジュールはすでに含まれており、デフォルトでロードされます。
JBoss Web Server バージョン 3.1.0 より、Apache HTTP Server は配布されないようになりました。
以下の手順を参照し、お使いの環境に合った mod_cluster モジュールを設定します。
Red Hat のお客様は Red Hat カスタマーポータルにある Load Balancer Configuration Tool を使用して mod_cluster やその他のコネクターに最適な設定テンプレートを迅速に生成することもできます。このツールを使用するにはログインする必要があります。
mod_cluster の設定
Apache HTTP Server には、mod_cluster モジュールをロードし、基本設定を提供する mod_cluster 設定ファイル mod_cluster.conf
がすでに含まれています。このファイルに指定されている IP アドレス、ポート、およびその他の設定 (以下参照) は必要に応じて変更できます。
# mod_proxy_balancer should be disabled when mod_cluster is used LoadModule proxy_cluster_module modules/mod_proxy_cluster.so LoadModule cluster_slotmem_module modules/mod_cluster_slotmem.so LoadModule manager_module modules/mod_manager.so LoadModule advertise_module modules/mod_advertise.so MemManagerFile cache/mod_cluster <IfModule manager_module> Listen 6666 <VirtualHost *:6666> <Directory /> Require ip 127.0.0.1 </Directory> ServerAdvertise on EnableMCPMReceive <Location /mod_cluster_manager> SetHandler mod_cluster-manager Require ip 127.0.0.1 </Location> </VirtualHost> </IfModule>
Apache HTTP Server サーバーはロードバランサーとして設定でき、JBoss EAP で実行されている modcluster
サブシステムと動作します。JBoss EAP が mod_cluster を認識するよう mod_cluster ワーカーノードを設定 する必要があります。
mod_cluster のアドバタイズを無効にし、代わりに静的プロキシーリストを設定する場合は mod_cluster のアドバタイズの無効化 を参照してください。Apache HTTP Server で使用できる mod_cluster 設定オプションの詳細は、Apache HTTP Server の mod_cluster ディレクティブ を参照してください。
mod_cluster の設定に関する詳細は、JBoss Web ServerHTTP Connectors and Load Balancing Guide のConfigure Load Balancing Using Apache HTTP Server and mod_clusterを参照してください。
22.6.2. mod_cluster のアドバタイズの無効化
デフォルトでは、modcluster
サブシステムのバランサーはマルチキャスト UDP を使用して可用性をバックグラウンドワーカーにアドバタイズします。アドバタイズを無効にし、代わりにプロキシーリストを使用する場合は、以下の手順に従ってください。
以下の手順の管理 CLI コマンドは、マネージドドメインで full-ha
プロファイルを使用していることを前提としています。full-ha
以外のプロファイルを使用している場合は、コマンドに適切なプロファイル名を使用してください。スタンドアロンサーバーを実行している場合は /profile=full-ha
を削除してください。
Apache HTTP Server 設定を変更します。
httpd.conf
Apache HTTP Server 設定ファイルを編集します。EnableMCPMReceive
ディレクティブを使用して、MCPM リクエストをリッスンする仮想ホストに以下の更新を加えてください。サーバーアドバタイズメントを無効にするディレクティブを追加します。
ServerAdvertise
ディレクティブをOff
に設定し、サーバーのアドバタイズを無効にします。ServerAdvertise Off
アドバタイズの頻度を無効にします。
設定に
AdvertiseFrequency
が指定されている場合は#
文字を使用してコメントアウトします。# AdvertiseFrequency 5
MCPM メッセージの受信機能を有効にします。
Web サーバーがワーカーノードから MCPM メッセージを受信できるようにするため、必ず
EnableMCPMReceive
ディレクティブが存在するようにしてください。EnableMCPMReceive
modcluster
サブシステムでアドバタイズを無効にします。以下の管理 CLI コマンドを使用してアドバタイズを無効にします。
/profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=advertise,value=false)
重要必ず次のステップでプロキシーのリストを提供してください。プロキシーのリストが空であるとアドバタイズが無効になりません。
JBoss EAP の
modcluster
サブシステムにプロキシーのリストを提供します。アドバタイズが無効になっていると
modcluster
サブシステムは自動的にプロキシーを検出できないため、プロキシーのリストを提供する必要があります。最初に、適切なソケットバインディンググループにアウトバウンドソケットバインディングを定義します。
/socket-binding-group=full-ha-sockets/remote-destination-outbound-socket-binding=proxy1:add(host=10.33.144.3,port=6666) /socket-binding-group=full-ha-sockets/remote-destination-outbound-socket-binding=proxy2:add(host=10.33.144.1,port=6666)
次に、プロキシーを mod_cluster 設定に追加します。
/profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration:list-add(name=proxies,value=proxy1) /profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration:list-add(name=proxies,value=proxy2)
Apache HTTP Server のバランサーがその存在をワーカーノードにアドバタイズしなくなり、UDP マルチキャストが使用されないようになります。
22.6.3. mod_cluster ワーカーノードの設定
mod_cluster ワーカーノードは、JBoss EAP サーバーで設定されます。このサーバーは、スタンドアロンサーバーまたはマネージドドメインのサーバーグループの一部になります。個別のプロセスが JBoss EAP 内で実行され、クラスターのワーカーノードをすべて管理します。これはマスターと呼ばれます。
マネージドドメインのワーカーノードは、サーバーグループ全体で同じ設定を共有します。スタンドアロンサーバーとして実行しているワーカーノードは個別に設定されます。設定手順は同じです。
- スタンドアロンサーバーは standalone-ha または standalone-full-ha プロファイルで起動する必要があります。
- マネージドドメインのサーバーグループは ha または full-ha プロファイルを使用し、 ha-sockets または full-ha-sockets ソケットバインディンググループを使用する必要があります。JBoss EAP にはこれらの要件を満たし、クラスターが有効になっている other-server-group というサーバーグループが含まれます。
ワーカーノードの設定
この手順の管理 CLI コマンドは、full-ha
プロファイルのマネージドドメインを使用していることを前提としています。スタンドアロンサーバーを実行している場合は、コマンドの /profile=full-ha
の部分を削除してください。
ネットワークインターフェイスの設定
デフォルトでは、ネットワークインターフェイスがすべて
127.0.0.1
に設定されます。スタンドアロンサーバーまたはサーバーグループ内の 1 つまたは複数のサーバーをホストする各物理ホストでは、インターフェイスが他のサーバーが見つけることができるパブリック IP アドレスを使用するよう設定する必要があります。以下の管理 CLI コマンドを使用して、ご使用の環境に合うよう
management
、public
、およびunsecure
インターフェイスの外部 IP アドレスを変更します。コマンドの EXTERNAL_IP_ADDRESS をホストの実際の外部 IP アドレスに置き換えてください。/interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:EXTERNAL_IP_ADDRESS}") /interface=public:write-attribute(name=inet-address,value="${jboss.bind.address.public:EXTERNAL_IP_ADDRESS}") /interface=unsecure:write-attribute(name=inet-address,value="${jboss.bind.address.unsecure:EXTERNAL_IP_ADDRESS}")
サーバーをリロードします。
reload
ホスト名を設定します。
マネージドドメインに参加する各ホストに一意なホスト名を設定します。この名前はスレーブ全体で一意になる必要があり、スレーブがクラスターを識別するために使用されるため、使用する名前を覚えておくようにしてください。
適切な
host.xml
設定ファイルを使用して JBoss EAP のスレーブホストを起動します。$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
以下の管理 CLI コマンドを使用して、一意なホスト名を設定します。この例では、
slave1
が新しいホスト名として使用されます。/host=EXISTING_HOST_NAME:write-attribute(name=name,value=slave1)
ホスト名の設定に関する詳細は、ホスト名の設定 を参照してください。
ドメインコントローラーに接続する各ホストを設定します。
注記このステップはスタンドアロンサーバーには適用されません。
新たに設定されたホストがマネージドドメインに参加する必要がある場合、ローカル要素を削除し、ドメインコントローラーを示すリモート要素ホスト属性を追加する必要があります。
適切な
host.xml
設定ファイルを使用して JBoss EAP のスレーブホストを起動します。$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
以下の管理 CLI コマンドを使用して、ドメインコントローラーを設定します。
/host=SLAVE_HOST_NAME:write-remote-domain-controller(host=DOMAIN_CONTROLLER_IP_ADDRESS,port=${jboss.domain.master.port:9999},security-realm="ManagementRealm")
これにより、host-slave.xml ファイルの XML が次のように変更されます。
<domain-controller> <remote host="DOMAIN_CONTROLLER_IP_ADDRESS" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> </domain-controller>
詳細は、ドメインコントローラーへの接続を参照してください。
各スレーブホストの認証を設定します。
各スレーブサーバーには、ドメインコントローラーまたはスタンドアロンマスターの ManagementRealm で作成されたユーザー名とパスワードが必要です。ドメインコントローラーまたはスタンドアロンマスターで、各ホストに対して
EAP_HOME/bin/add-user.sh
コマンドを実行します。スレーブのホスト名と一致するユーザー名で、各ホストの管理ユーザーを追加します。秘密の値が提供されるようにするため、必ず最後の質問 (Is this new user going to be used for one AS process to connect to another AS process?) に
yes
と返答してください。add-user スクリプトの出力例 (省略)
$ EAP_HOME/bin/add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a): a Username : slave1 Password : changeme Re-enter Password : changeme What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]: About to add user 'slave1' for realm 'ManagementRealm' Is this correct yes/no? yes Is this new user going to be used for one AS process to connect to another AS process? e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls. yes/no? yes To represent the user add the following to the server-identities definition <secret value="SECRET_VALUE" />
ここで出力された Base64 でエンコードされた秘密の値
SECRET_VALUE
をコピーします。 この値は次のステップで使用することがあります。詳細は、JBoss EAPHow To Configure Server Securityの Adding a User to the Master Domain Controller を参照してください。
新しい認証を使用するようスレーブホストのセキュリティーレルムを変更します。
サーバー設定に秘密の値を指定する方法、認証情報ストアまたは vault からパスワードを取得する方法、またはパスワードをシステムプロパティーとして渡す方法のいずれかでパスワードを指定できます。
管理 CLI を使用して、サーバー設定ファイルに Base64 でエンコードされたパスワード値を指定します。
以下の管理 CLI コマンドを使用して秘密の値を指定します。必ず
SECRET_VALUE
を前のステップの add-user 出力から返された秘密の値に置き換えてください。/host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="SECRET_VALUE")
サーバーをリロードする必要があります。
--host
引数はスタンドアロンサーバーには適用されません。reload --host=HOST_NAME
詳細は、JBoss EAPHow To Configure Server Securityの Configuring the Slave Controllers to Use the Credential を参照してください。
ホストを設定し、vault よりパスワードを取得します。
EAP_HOME/bin/vault.sh
スクリプトを使用してマスクされたパスワードを生成します。以下のような VAULT::secret::password::VAULT_SECRET_VALUE
形式の文字列が生成されます。VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0.
注記vault でパスワードを作成する場合、Base64 エンコードではなくプレーンテキストで指定する必要があります。
以下の管理 CLI コマンドを使用して秘密の値を指定します。必ず
VAULT_SECRET_VALUE
を前のステップで生成したマスクされたパスワードに置き換えてください。/host=master/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${VAULT::secret::password::VAULT_SECRET_VALUE}")
サーバーをリロードする必要があります。
--host
引数はスタンドアロンサーバーには適用されません。reload --host=HOST_NAME
詳細は、JBoss EAP How To Configure Server Securityの Password Vault を参照してください。
システムプロパティーとしてパスワードを指定します。
次の例は、
server.identity.password
をパスワードのシステムプロパティー名として使用します。サーバー設定ファイルでパスワードのシステムプロパティーを指定します。
以下の管理 CLI コマンドを使用して、システムプロパティーを使用する秘密のアイデンティティーを設定します。
/host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${server.identity.password}")
サーバーをリロードする必要があります。
--host
引数はスタンドアロンサーバーには適用されません。reload --host=master
サーバーの起動時にシステムプロパティーのパスワードを設定します。
server.identity.password
システムプロパティーを設定するには、このプロパティーをコマンドライン引数として渡すか、プロパティーファイルで渡します。プレーンテキストのコマンドライン引数として渡します。
サーバーを起動し、
server.identity.password
プロパティーを渡します。$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Dserver.identity.password=changeme
警告パスワードはプレーンテキストで入力する必要があります。
ps -ef
コマンドを実行すると、このパスワードを確認できます。プロパティーファイルでプロパティーを設定します。
プロパティーファイルを作成し、キーバリューペアをプロパティーファイルに追加します。 例を以下に示します。
server.identity.password=changeme
警告パスワードはプレーンテキストで、このプロパティーファイルにアクセスできるユーザーはパスワードを確認できます。
コマンドライン引数を使用してサーバーを起動します。
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --properties=PATH_TO_PROPERTIES_FILE
サーバーを再起動します。
ホスト名をユーザー名として使用し、暗号化された文字列をパスワードとして使用してスレーブがマスターに対して認証されます。
スタンドアロンサーバーまたはマネージドドメインのサーバーグループ内のサーバーが mod_cluster ワーカーノードとして設定されます。クラスター化されたアプリケーションをデプロイする場合、セッションはフェイルオーバーのためにすべてのクラスターサーバーに複製され、外部 Web サーバーまたはロードバランサーからのリクエストを許可できます。クラスターの各ノードは、デフォルトで自動検出を使用して他のノードを検出します。
22.6.4. mod_cluster の fail_on_status パラメーターの設定
fail_on_status
パラメーターは、クラスターのワーカーノードによって返されるとそのノードの失敗を意味する HTTP ステータスコードをリストします。ロードバランサーはその後のリクエストをクラスターの別のワーカーノードに送信します。失敗したワーカーノードは、ロードバランサーに STATUS
メッセージを送信するまで NOTOK
の状態になります。
fail_on_status
パラメーターは、Hewlett-Packard の HP-UX v11.3 hpws httpd B.2.2.15.15 ではサポートされていないため、使用できません。
fail_on_status
パラメーターはロードバランサーの httpd
設定ファイルに設定する必要があります。fail_on_status
の HTTP ステータスコードが複数ある場合はコンマで区切って指定します。以下の例は、HTTP ステータスコード 203
および 204
を fail_on_status
に指定します。
例 fail_on_status 設定
ProxyPass / balancer://MyBalancer stickysession=JSESSIONID|jsessionid nofailover=on failonstatus=203,204 ProxyPassReverse / balancer://MyBalancer ProxyPreserveHost on
22.6.5. クラスター間のトラフィックの移行
JBoss EAP を使用して新しいクラスターを作成した後、アップグレードプロセスの一部として以前のクラスターから新しいクラスターへトラフィックを移行できます。ここでは、停止時間やダウンライムを最小限に抑えてトラフィックを移行する方法について説明します。
- 新しいクラスターのセットアップ: (このクラスターを ClusterNEW と呼びます)。
- 不要となった古いクラスターの設定 (このクラスターを Cluster OLD とします)。
クラスターのアップグレードプロセス - ロードバランシンググループ
- 前提条件に従って、新しいクラスターを設定します。
ClusterNEW と ClusterOLD の 両方で、設定オプション
Sticky-session
がtrue
に設定されていることを確認します (このオプションはデフォルトでtrue
に設定されています)。このオプションを有効にすると、クラスターのクラスターノードへの新しいリクエストはすべてそのクラスターノードに送信されます。/profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=sticky-session,value=true)
ClusterOLD のすべてのクラスターノードは ClusterOLD ロードバランシンググループのメンバーであることを仮定し、
load-balancing-group
をClusterOLD
に設定します。/profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=load-balancing-group,value=ClusterOLD)
<subsystem xmlns="urn:jboss:domain:modcluster:2.0"> <mod-cluster-config load-balancing-group="ClusterOLD" advertise-socket="modcluster" connector="ajp"> <dynamic-load-provider> <load-metric type="cpu"/> </dynamic-load-provider> </mod-cluster-config> </subsystem>
mod_cluster ワーカーノードの設定の手順に従って ClusterNEW のノードを個別に mod_cluster 設定に追加します。また、この手順を使用してロードバランシンググループを ClusterNEW に設定します。
この時点で、以下の簡易例に似た出力が mod_cluster-manager コンソールに表示されます。
mod_cluster/<version> LBGroup ClusterOLD: [Enable Nodes] [Disable Nodes] [Stop Nodes] Node node-1-jvmroute (ajp://node1.oldcluster.example:8009): [Enable Contexts] [Disable Contexts] [Stop Contexts] Balancer: qacluster, LBGroup: ClusterOLD, Flushpackets: Off, ..., Load: 100 Virtual Host 1: Contexts: /my-deployed-application-context, Status: ENABLED Request: 0 [Disable] [Stop] Node node-2-jvmroute (ajp://node2.oldcluster.example:8009): [Enable Contexts] [Disable Contexts] [Stop Contexts] Balancer: qacluster, LBGroup: ClusterOLD, Flushpackets: Off, ..., Load: 100 Virtual Host 1: Contexts: /my-deployed-application-context, Status: ENABLED Request: 0 [Disable] [Stop] LBGroup ClusterNEW: [Enable Nodes] [Disable Nodes] [Stop Nodes] Node node-3-jvmroute (ajp://node3.newcluster.example:8009): [Enable Contexts] [Disable Contexts] [Stop Contexts] Balancer: qacluster, LBGroup: ClusterNEW, Flushpackets: Off, ..., Load: 100 Virtual Host 1: Contexts: /my-deployed-application-context, Status: ENABLED Request: 0 [Disable] [Stop] Node node-4-jvmroute (ajp://node4.newcluster.example:8009): [Enable Contexts] [Disable Contexts] [Stop Contexts] Balancer: qacluster, LBGroup: ClusterNEW, Flushpackets: Off, ..., Load: 100 Virtual Host 1: Contexts: /my-deployed-application-context, Status: ENABLED Request: 0 [Disable] [Stop]
ClusterOLD グループ内に古いアクティブなセッションがあり、新しいセッションは ClusterOLD または CLusterNEW グループ内に作成されます。次に、現在アクティブなクライアントのセッションにエラーを発生させずにクラスターノードの電源をオフにできるように、ClusterOLD グループ全体を無効にします。
mod_cluster-manager Web コンソールで LBGroup ClusterOLD の Disable Nodes リンクをクリックします。
この後、すでに確立されたセッションに属するリクエストのみが ClusterOLD ロードバランシンググループのメンバーにルーティングされます。新しいクライアントのセッションは ClusterNEW グループのみに作成されます。ClusterOLD グループ内にアクティブなセッションがなくなったら、そのメンバーを安全に削除できます。
注記Stop Nodes を使用すると、即座にこのドメインへのリクエストのルーティングを停止するようロードバランサーが指示されます。これにより、別のロードバランシンググループへのフェイルオーバーが強制され、ClusterNEW と ClusterOLD の間にセッションレプリケーションがない場合はクライアントへのセッションデータが損失する原因となります。
デフォルトのロードバランシンググループ
mod_cluster-manager コンソールの LBGroup を確認して、現在の ClusterOLD 設定にロードバランシンググループの設定が含まれていない場合でも、ClusterOLD ノードの無効化を利用できます。この場合、各 ClusterOLD ノードの Disable Contexts をクリックします。これらのノードのコンテンツは無効化され、アクティブなセッションがなくなったら削除することができます。新しいクライアントのセッションは、有効なコンテンツを持つノードのみに作成されます (この例では ClusterOLD メンバー)。
管理 CLI の使用
mod_cluster-manager web コンソールを使用する他に、JBoss EAP 管理 CLI を使用して特定のコンテキストを停止または無効化することもできます。
コンテキストの停止
/host=master/server=server-one/subsystem=modcluster:stop-context(context=/my-deployed-application-context, virtualhost=default-host, waittime=0)
waittime
を 0
に設定してタイムアウトがない状態でコンテキストを停止すると、すべてのリクエストのルーティングを即座に停止するようバランサーに指示を出し、利用できる他のコンテキストへのフェイルオーバーを強制します。
waittime
引数を使用してタイムアウト値を設定すると、このコンテキストでは新しいセッションは作成されませんが、既存のセッションが完了するか、指定のタイムアウト値を経過するまで、既存のセッションはこのノードに引き続き転送されます。waittime
引数のデフォルト値は 10
秒です。
コンテキストの無効化
/host=master/server=server-one/subsystem=modcluster:disable-context(context=/my-deployed-application-context, virtualhost=default-host)
コンテキストを無効にすると、バランサーがこのコンテキストで新しいセッションを作成しないよう指示します。