第24章 高可用性の設定
24.1. 高可用性
JBoss EAP はデプロイされた Jakarta EE アプリケーションの可用性を保証するために以下の高可用性サービスを提供します。
- ロードバランシング
- 複数のサーバーにワークロードを分散し、サービスが大量のリクエストを処理できるようにします。リクエストが大量に発生しても、クライアントはサービスからタイムリーに応答を受け取ることができます。
- フェイルオーバー
- ハードウェアやネットワークの障害が発生してもクライアントのサービスへのアクセスが中断しないようにします。サービスに障害が発生すると、別のクラスターメンバーがクライアントのリクエストを引き継ぎ、処理が続行されます。
クラスタリングはこれらすべての機能を包括する言葉です。クラスターのメンバーを設定すると、ロードバランシングと呼ばれるワークロードの共有や、フェイルオーバーと呼ばれる他のクラスターメンバーの障害時におけるクライアント処理の引き継ぎを行うことができます。
選択した JBoss EAP の操作モード (スタンドアロンサーバーまたは管理対象ドメイン) によってサーバーの管理方法が異なることに注意してください。操作モードに関係なく JBoss EAP で高可用性サービスを設定できます。
JBoss EAP は、さまざまなコンポーネントを使用した異なるレベルの高可用性をサポートします。高可用性を実現できるランタイムのコンポーネントおよびアプリケーションの一部は以下のとおりです。
- アプリケーションサーバーのインスタンス
- 内部 JBoss Web Server、Apache HTTP Server、Microsoft IIS、または Oracle iPlanet Web Server と併用される Web アプリケーション
- ステートフルおよびステートレスセッション Enterprise JavaBean (EJB)
- シングルサインオン (SSO) メカニズム
- HTTP セッション
- JMS サービスおよびメッセージ駆動型 Bean (MDB)
- シングルトン MSC サービス
- シングルトンデプロイメント
JBoss EAP では、jgroups
、 infinispan
、および modcluster
サブシステムによってクラスタリングが使用できるようになります。ha および full-ha プロファイルではこれらのシステム有効になっています。JBoss EAP では、これらのサービスは必要に応じて起動およびシャットダウンしますが、分散可能と設定されたアプリケーションがサーバーにデプロイされた場合のみ起動します。
アプリケーションを分散可能とする方法は、JBoss EAP 『開発ガイド』 を 参照してください。
24.2. JGroups を用いたクラスター通信
24.2.1. JGroups
JGroups は信頼できるメッセージングのためのツールキットで、お互いにメッセージを送信するノードを持つクラスターを作成するために使用できます。
jgroups
サブシステムは JBoss EAP で高可用性サービスのグループ通信サポートを提供します。これにより、名前付きのチャネルおよびプロトコルスタックを設定でき、チャネルのランタイム統計を表示することもできます。jgroups
サブシステムは高可用性の機能を提供する設定を使用する場合に使用できます (管理対象ドメインでは ha や full-ha プロファイル、スタンドアロンサーバーは standalone-ha.xml
や standalone-full-ha.xml
設定ファイルなど)。
JBoss EAP には 2 つの JGroups スタックが事前に設定されています。
- udp
- クラスターのノードは UDP (User Datagram Protocol) マルチキャストを使用してお互いに通信します。これはデフォルトのスタックです。
- tcp
- クラスターのノードは TCP (Transmission Control Protocol) を使用してお互いに通信します。
TCP はエラーのチェック、パケットの順番、および輻輳制御を処理するため、TCP のオーバーヘッドは UDP よりも大きく、速度も遅くなると考えられます。JGroups は UDP のこれらの機能を処理しますが、TCP はこれらの機能を独自で処理します。信頼できないネットワークや輻輳度の高いネットワークで JGroups を使用する場合やマルチキャストが使用できない場合は、TCP を選択するとよいでしょう。
事前設定されたスタックを使用できますが、システムの要件に合うように独自に定義をすることもできます。使用できるプロトコルとそれらの属性については、以下の項を参照してください。
24.2.2. デフォルトの JGroups チャネルが TCP を使用するよう設定
デフォルトでは、クラスターノードは UDP プロトコルを使用して通信します。デフォルトの ee
JGroups は事前定義された udp
プロトコルスタックを使用します。
<channels default="ee"> <channel name="ee" stack="udp"/> </channels> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> ... </stack> <stack name="tcp"> <transport type="TCP" socket-binding="jgroups-tcp"/> <protocol type="MPING" socket-binding="jgroups-mping"/> ... </stack> </stacks>
一部のネットワークでは TCP のみを使用できます。以下の管理 CLI コマンドを使用して、ee
チャネルが事前設定された tcp
スタックを使用するようにします。
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
このデフォルトの tcp
スタックは、IP マルチキャストを使用して初期クラスターメンバーシップを検出する MPING
プロトコルを使用します。他のメンバーシップ検出プロトコルに対してスタックを設定する場合は以下の項を参照してください。
24.2.3. TCPPING の設定
この手順は TCPPING
プロトコルを使用する新しい JGroups スタックを作成し、静的クラスターメンバーシップのリストを定義します。ベーススクリプトは、tcpping
スタックを作成し、この新しいスタックを使用するようデフォルトの ee
チャネルを設定します。このスクリプトの管理 CLI コマンドは環境に合わせてカスタマイズする必要があり、バッチで処理されます。
以下のスクリプトをテキストエディターにコピーし、ローカルファイルシステムに保存します。
# Define the socket bindings /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-a:add(host=HOST_A,port=7600) /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-b:add(host=HOST_B,port=7600) batch # Add the tcpping stack /subsystem=jgroups/stack=tcpping:add /subsystem=jgroups/stack=tcpping/transport=TCP:add(socket-binding=jgroups-tcp) /subsystem=jgroups/stack=tcpping/protocol=TCPPING:add(socket-bindings=[jgroups-host-a,jgroups-host-b]) /subsystem=jgroups/stack=tcpping/protocol=MERGE3:add /subsystem=jgroups/stack=tcpping/protocol=FD_SOCK:add /subsystem=jgroups/stack=tcpping/protocol=FD_ALL:add /subsystem=jgroups/stack=tcpping/protocol=VERIFY_SUSPECT:add /subsystem=jgroups/stack=tcpping/protocol=pbcast.NAKACK2:add /subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add /subsystem=jgroups/stack=tcpping/protocol=pbcast.STABLE:add /subsystem=jgroups/stack=tcpping/protocol=pbcast.GMS:add /subsystem=jgroups/stack=tcpping/protocol=MFC:add /subsystem=jgroups/stack=tcpping/protocol=FRAG2:add # Set tcpping as the stack for the ee channel /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcpping) run-batch reload
定義されたプロトコルの順番が重要になることに注意してください。また、
add-index
の値をadd
コマンドに渡すと、特定のインデックスでプロトコルを挿入できます。インデックスはゼロベースであるため、以下の管理 CLI コマンドはUNICAST3
プロトコルを 7 つ目のプロトコルとして追加します。/subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add(add-index=6)
環境に合わせてスクリプトを変更します。
-
管理対象ドメインで実行している場合は、
/subsystem=jgroups
コマンドの前に/profile=PROFILE_NAME
を追加し、更新するプロファイルを指定する必要があります。 以下のプロパティーを環境に合わせて調整します。
-
socket-bindings
: ウェルノウンとして見なされ、最初のメンバーシップの検索に利用できるホストとポートの組み合わせのカンマ区切りリスト。ソケットバインディングの定義に関する詳細は、「ソケットバインディングの設定」を参照してください -
initial_hosts
: ウェルノウンとして見なされ、最初のメンバーシップの検索に使用できるHOST[PORT]
という構文を使用したホストとポートの組み合わせのカンマ区切りリスト (例:host1[1000],host2[2000]
)。 -
port_range
: このプロパティーは、initial_hosts
ポート範囲を指定した値の分拡張するために使用されます。たとえば、initial_hosts
をhost1[1000],host2[2000]
に設定し、port_range
を1
に設定した場合initial_hosts
設定はhost1[1000],host1[1001],host2[2000],host2[2001]
に拡張されます。このプロパティーはinitial_hosts
プロパティーと併用した場合のみ有効です。
-
-
管理対象ドメインで実行している場合は、
スクリプトファイルを管理 CLI に渡してスクリプトを実行します。
$ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME
TCPPING スタックが使用できるようになり、ネットワークの通信に TCP が使用されます。
24.2.4. TCPGOSSIP の設定
この手順は、TCPGOSSIP
プロトコルを使用する新しい JGroups スタックを作成し、外部ゴシップルーターを使用してクラスターのメンバーを検索します。ベーススクリプトは、tcpgossip
スタックを作成し、この新しいスタックを使用するようデフォルトの ee
チャネルを設定します。このスクリプトの管理 CLI コマンドは環境に合わせてカスタマイズする必要があり、バッチで処理されます。
以下のスクリプトをテキストエディターにコピーし、ローカルファイルシステムに保存します。
# Define the socket bindings /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-a:add(host=HOST_A,port=13001) batch # Add the tcpgossip stack /subsystem=jgroups/stack=tcpgossip:add /subsystem=jgroups/stack=tcpgossip/transport=TCP:add(socket-binding=jgroups-tcp) /subsystem=jgroups/stack=tcpgossip/protocol=TCPGOSSIP:add(socket-bindings=[jgroups-host-a]) /subsystem=jgroups/stack=tcpgossip/protocol=MERGE3:add /subsystem=jgroups/stack=tcpgossip/protocol=FD_SOCK:add /subsystem=jgroups/stack=tcpgossip/protocol=FD_ALL:add /subsystem=jgroups/stack=tcpgossip/protocol=VERIFY_SUSPECT:add /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.NAKACK2:add /subsystem=jgroups/stack=tcpgossip/protocol=UNICAST3:add /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.STABLE:add /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.GMS:add /subsystem=jgroups/stack=tcpgossip/protocol=MFC:add /subsystem=jgroups/stack=tcpgossip/protocol=FRAG2:add # Set tcpgossip as the stack for the ee channel /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcpgossip) run-batch reload
定義されたプロトコルの順番が重要になることに注意してください。また、
add-index
の値をadd
コマンドに渡すと、特定のインデックスでプロトコルを挿入できます。インデックスはゼロベースであるため、以下の管理 CLI コマンドはUNICAST3
プロトコルを 7 つ目のプロトコルとして追加します。/subsystem=jgroups/stack=tcpgossip/protocol=UNICAST3:add(add-index=6)
環境に合わせてスクリプトを変更します。
-
管理対象ドメインで実行している場合は、
/subsystem=jgroups
コマンドの前に/profile=PROFILE_NAME
を追加し、更新するプロファイルを指定する必要があります。 以下のプロパティーを環境に合わせて調整します。
-
socket-bindings
: ウェルノウンとして見なされ、最初のメンバーシップの検索に利用できるホストとポートの組み合わせのカンマ区切りリスト。ソケットバインディングの定義に関する詳細は、「ソケットバインディングの設定」を参照してください -
initial_hosts
: ウェルノウンとして見なされ、最初のメンバーシップの検索に使用できるHOST[PORT]
という構文を使用したホストとポートの組み合わせのカンマ区切りリスト (例:host1[1000],host2[2000]
)。 -
port_range
: このプロパティーは、initial_hosts
ポート範囲を指定した値の分拡張するために使用されます。たとえば、initial_hosts
をhost1[1000],host2[2000]
に設定し、port_range
を1
に設定した場合initial_hosts
設定はhost1[1000],host1[1001],host2[2000],host2[2001]
に拡張されます。このプロパティーはinitial_hosts
プロパティーと併用した場合のみ有効です。 -
reconnect_interval
: 接続が切断されたスタブがゴシップルーターへの再接続を試みる間隔 (ミリ秒単位)。 -
sock_conn_timeout
: ソケット作成の最大時間。デフォルトは1000
ミリ秒です。 -
sock_read_timeout
: 読み取りがブロックされる最大時間 (ミリ秒単位)。0
を値として指定すると無制限にブロックされます。
-
-
管理対象ドメインで実行している場合は、
スクリプトファイルを管理 CLI に渡してスクリプトを実行します。
$ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME
TCPGOSSIP スタックが使用できるようになり、ネットワークの通信に TCP が使用されます。このスタックはゴシップルーターと使用するように設定されるため、JGroups メンバーは他のクラスターメンバーを見つけることができます。
24.2.5. JDBC_PING の設定
JDBC_PING
プロトコルを使用して、クラスターでメンバーシップを管理および検出できます。
JDBC_PING はデータソースに指定されたデータベースを使用して、クラスターのメンバーを一覧表示します。
- クラスターメンバーシップの管理に使用するデータベースに接続するデータソースを作成します。
以下のスクリプトをテキストエディターにコピーし、ローカルファイルシステムに保存します。
batch # Add the JDBC_PING stack /subsystem=jgroups/stack=JDBC_PING:add /subsystem=jgroups/stack=JDBC_PING/transport=TCP:add(socket-binding=jgroups-tcp) /subsystem=jgroups/stack=JDBC_PING/protocol=JDBC_PING:add(data-source=ExampleDS) /subsystem=jgroups/stack=JDBC_PING/protocol=MERGE3:add /subsystem=jgroups/stack=JDBC_PING/protocol=FD_SOCK:add /subsystem=jgroups/stack=JDBC_PING/protocol=FD_ALL:add /subsystem=jgroups/stack=JDBC_PING/protocol=VERIFY_SUSPECT:add /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.NAKACK2:add /subsystem=jgroups/stack=JDBC_PING/protocol=UNICAST3:add /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.STABLE:add /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.GMS:add /subsystem=jgroups/stack=JDBC_PING/protocol=MFC:add /subsystem=jgroups/stack=JDBC_PING/protocol=FRAG2:add # Set JDBC_PING as the stack for the ee channel /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=JDBC_PING) run-batch reload
定義されたプロトコルの順番が重要になることに注意してください。また、
add-index
の値をadd
コマンドに渡すと、特定のインデックスでプロトコルを挿入できます。インデックスはゼロベースであるため、以下の管理 CLI コマンドはUNICAST3
プロトコルを 7 つ目のプロトコルとして追加します。/subsystem=jgroups/stack=JDBC_PING/protocol=UNICAST3:add(add-index=6)
環境に合わせてスクリプトを変更します。
-
管理対象ドメインで実行している場合は、
/subsystem=jgroups
コマンドの前に/profile=PROFILE_NAME
を追加し、更新するプロファイルを指定する必要があります。 - 「ExampleDS」を、手順 1 で定義したデータソースの名前に置き換えます。
-
管理対象ドメインで実行している場合は、
スクリプトファイルを管理 CLI に渡してスクリプトを実行します。
$ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME
JDBC_PING スタックが使用できるようになり、ネットワークの通信に TCP が使用されます。
関連情報
JDBC_PING: https://developer.jboss.org/wiki/JDBCPING
データソースの作成: 「JBoss EAP データソース」
24.2.6. JGroups のネットワークインターフェースへのバインディング
デフォルトでは、JGroups は private
ネットワークインターフェースのみへバインドし、デフォルト設定でローカルホストへ示されます。クラスタリングのトラフィックはパブリックネットワークインターフェースで公開するべきではないため、セキュリティー上の理由で JGroups は JBoss EAP の起動中に指定された -b
引数によって定義されたネットワークインターフェースにはバインドしません。
ネットワークインターフェースの設定方法については「ネットワークおよびポート設定」の章を参照してください。
セキュリティー上の理由で、JGroups はパブリックではないネットワークインターフェースのみにバインドされる必要があります。また、パフォーマンス上の理由で JGroups トラフィックのネットワークインターフェースは専用の VLAN (Virtual Local Area Network) の一部にすることが推奨されます。
24.2.7. クラスターのセキュア化
クラスターをセキュアに実行するには、複数の課題に対応する必要があります。
24.2.7.1. 認証の設定
JGroups の認証は AUTH
プロトコルによって実行されます。認証されたノードのみがクラスターに参加できるようにすることが目的です。
該当のサーバー設定ファイルに AUTH
プロトコルと適切なプロパティー設定を追加します。AUTH
プロトコルは pbcast.GMS
プロトコルの直前に設定する必要があります。
以下は、AUTH
を異なる承認トークンと使用する例になります。
AUTH とシンプルトークン
...
<protocol type="pbcast.STABLE"/>
<auth-protocol type="AUTH">
<plain-token>
<shared-secret-reference clear-text="my_password"/>
</plain-token>
</auth-protocol>
<protocol type="pbcast.GMS"/>
...
AUTH とダイジェストアルゴリズムトークン
この形式は、MD5 や SHA-2 など、どのダイジェストアルゴリズムでも使用できます。JBoss EAP 7.4 でのデフォルトのダイジェストアルゴリズムは SHA-256 で、これは JVM によるサポートに必要な最強のダイジェストアルゴリズムです。多くの JVM は、追加で SHA-512 を実装します。
...
<protocol type="pbcast.STABLE"/>
<auth-protocol type="AUTH">
<digest-token algorithm="SHA-512">
<shared-secret-reference clear-text="my_password"/>
</digest-token>
</auth-protocol>
<protocol type="pbcast.GMS"/>
...
AUTH と X509 トークン
この例は、elytron
サブシステムで新しいキーストアを作成し、JGroups の AUTH
設定で参照します。
キーストアを作成します。
$ keytool -genkeypair -alias jgroups_key -keypass my_password -storepass my_password -storetype jks -keystore jgroups.keystore -keyalg RSA
管理 CLI を使用して、キーストアを
elytron
サブシステムに追加します。/subsystem=elytron/key-store=jgroups-token-store:add(type=jks,path=/path/to/jgroups.keystore,credential-reference={clear-text=my_password}, required=true)
JGroups のスタック定義で
AUTH
を設定してキーストアを使用するようにします。... <protocol type="pbcast.STABLE"/> <auth-protocol type="AUTH"> <cipher-token algorithm="RSA" key-alias="jgroups_key" key-store="jgroups-token-store"> <shared-secret-reference clear-text="my_password"/> <key-credential-reference clear-text="my_password"/> </cipher-token> </auth-protocol> <protocol type="pbcast.GMS"/> ...
24.2.7.2. 暗号化の設定
JGroups はクラスターのメンバーが共有する秘密鍵を使用してメッセージを暗号化します。送信元は共有する秘密鍵を使用してメッセージを暗号化し、受信先は同じ秘密鍵を使用してメッセージを復号化します。対称暗号化は SYM_ENCRYPT
プロトコルを使用して設定され、ノードは共有のキーストアを使用して秘密鍵を取得します。非対称暗号化は ASYM_ENCRYPT
プロトコルを使用して設定され、ノードは AUTH
を使用して認証された後にクラスターのコーディネーターから秘密鍵を取得します。
対称暗号化の使用
SYM_ENCRYPT
を使用するには、各ノードの JGroups 設定で参照されるキーストアを設定する必要があります。
キーストアを作成します。
以下のコマンドでは、
VERSION
を適切な JGroups JAR バージョンに置き換え、PASSWORD
をキーストアパスワードに置き換えます。$ java -cp EAP_HOME/modules/system/layers/base/org/jgroups/main/jgroups-VERSION.jar org.jgroups.demos.KeyStoreGenerator --alg AES --size 128 --storeName defaultStore.keystore --storepass PASSWORD --alias mykey
これにより、JGroups 設定で参照される
defaultStore.keystore
ファイルが生成されます。キーストアが生成されたら、2 つの方法の 1 つを使用して
SYM_PROTOCOL
で定義されます。- キーストアを 直接設定に 定義します。
- Elytron サブシステムを使用 してキーストアを参照します。
SYM_ENCRYPT
を使用する場合、AUTH
の設定は任意です。
キーストアを直接参照して対称暗号化を使用
jgroups
サブシステムでSYM_ENCRYPT
プロトコルを設定します。該当するサーバー設定ファイルに、
SYM_ENCRYPT
プロトコルと適切なプロパティー設定を追加します。このプロトコルは、以前作成されたキーストアを参照します。SYM_ENCRYPT
プロトコルはpbcast.NAKACK2
の直前に設定する必要があります。<subsystem xmlns="urn:jboss:domain:jgroups:6.0"> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <protocol type="SYM_ENCRYPT"> <property name="provider">SunJCE</property> <property name="sym_algorithm">AES</property> <property name="encrypt_entire_message">true</property> <property name="keystore_name">/path/to/defaultStore.keystore</property> <property name="store_password">PASSWORD</property> <property name="alias">mykey</property> </protocol> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG2"/> </stack> </stacks> </subsystem>
Elytron と対称暗号化の使用
管理 CLI を使用して、
対称暗号化を使用して
作成されたdefaultStore.keystore
を参照するキーストアを elytron サブシステムに作成します。/subsystem=elytron/key-store=jgroups-keystore:add(path=/path/to/defaultStore.keystore,credential-reference={clear-text=PASSWORD},type=JCEKS)
SYM_ENCRYPT
プロトコルと適切なプロパティー設定をjgroups
サブシステムに追加します。以下の設定どおり、SYM_ENCRYPT
プロトコルはpbcast.NAKACK2
プロトコルの直前に設定する必要があります。<subsystem xmlns="urn:jboss:domain:jgroups:6.0"> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <encrypt-protocol type="SYM_ENCRYPT" key-alias="mykey" key-store="jgroups-keystore"> <key-credential-reference clear-text="PASSWORD"/> <property name="provider">SunJCE</property> <property name="encrypt_entire_message">true</property> </encrypt-protocol> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG2"/> </stack> </stacks> </subsystem>
注記上記の例はクリアテキストのパスワードを使用しますが、認証情報ストアを定義して設定ファイル外部にパスワードを定義することもできます。クレデンシャルストアの設定に関する詳細は、『 How to Configure Server Security 』の「 Credential Store 」を参照してください。
非対称暗号化の使用
ASYM_ENCRYPT
を使用するには AUTH
プロトコルを定義する必要があります。AUTH プロトコルを jgroups
サブシステムで設定する手順は、「認証の設定
」を参照してください。
ASYM_ENCRYPT
は 2 つの方法の 1 つで設定されます。
- 秘密鍵を生成し、設定で直接 参照します。
- キーストアを作成し、Elytron サブシステムを使用して 参照します。
秘密鍵を生成して非対象暗号化を使用
jgroups
サブシステムでASYM_ENCRYPT
プロトコルを設定します。該当のサーバー設定ファイルに
ASYM_ENCRYPT
プロトコルと適切なプロパティー設定を追加します。以下の設定どおり、ASYM_ENCRYPT
プロトコルはpbcast.NAKACK2
プロトコルの直前に設定する必要があります。<subsystem xmlns="urn:jboss:domain:jgroups:6.0"> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <protocol type="ASYM_ENCRYPT"> <property name="encrypt_entire_message">true</property> <property name="sym_keylength">128</property> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property> <property name="asym_keylength">512</property> <property name="asym_algorithm">RSA</property> </protocol> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <!-- Configure AUTH protocol here --> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG2"/> </stack> </stacks> </subsystem>
Elytron と非対称暗号化の使用
キーペアが含まれるキーストアを作成します。以下のコマンドは、
mykey
というエイリアスでキーストアを作成します。$ keytool -genkeypair -alias mykey -keyalg RSA -keysize 1024 -keystore defaultKeystore.keystore -dname "CN=localhost" -keypass secret -storepass secret
管理 CLI を使用して、
defaultStore.keystore
を参照するキーストアをelytron
サブシステムに作成します。/subsystem=elytron/key-store=jgroups-keystore:add(path=/path/to/defaultStore.keystore,credential-reference={clear-text=PASSWORD},type=JCEKS)
ASYM_ENCRYPT
プロトコルと適切なプロパティー設定をjgroups
サブシステムに追加します。以下の設定どおり、ASYM_ENCRYPT
プロトコルはpbcast.NAKACK2
プロトコルの直前に設定する必要があります。<subsystem xmlns="urn:jboss:domain:jgroups:6.0"> <stacks> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <protocol type="PING"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <encrypt-protocol type="ASYM_ENCRYPT" key-alias="mykey" key-store="jgroups-keystore"> <key-credential-reference clear-text="secret" /> <property name="encrypt_entire_message">true</property> </encrypt-protocol> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <!-- Configure AUTH protocol here --> <protocol type="pbcast.GMS"/> <protocol type="UFC"/> <protocol type="MFC"/> <protocol type="FRAG2"/> </stack> </stacks> </subsystem>
注記上記の例はクリアテキストのパスワードを使用しますが、認証情報ストアを定義して設定ファイル外部にパスワードを定義することもできます。クレデンシャルストアの設定に関する詳細は、『 How to Configure Server Security 』の「 Credential Store 」を参照してください。
24.2.8. JGroups スレッドプールの設定
jgroups
サブシステムには default
、internal
、oob
、および timer
スレッドプールが含まれます。これらのプールはすべての JGroups スタックに設定できます。
以下の表は、各スレッドプールに設定できる属性とデフォルト値を表しています。
スレッドプール名 | keepalive-time | max-threads | min-threads | queue-length |
---|---|---|---|---|
default | 60000L | 300 | 20 | 100 |
internal | 60000L | 4 | 2 | 100 |
oob | 60000L | 300 | 20 | 0 |
timer | 5000L | 4 | 2 | 500 |
以下の構文を使用して、管理 CLI で JGroups スレッドプールを設定します。
/subsystem=jgroups/stack=STACK_TYPE/transport=TRANSPORT_TYPE/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)
以下は、 udp
スタックの default
スレッドプールで max-threads
の値を 500
に設定する管理 CLI コマンドの例になります。
/subsystem=jgroups/stack=udp/transport=UDP/thread-pool=default:write-attribute(name="max-threads", value="500")
24.2.9. JGroups の送受信バッファーの設定
バッファーサイズ警告の解決
デフォルトでは、JGroups は特定の送受信バッファー値で設定されています。しかし、可能なバッファーサイズがオペレーティングシステムによって制限され、JBoss EAP が設定されたバッファー値を使用できないことがあります。このような場合、以下と似た警告が JBoss EAP のログに記録されます。
WARNING [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 68) JGRP000015: the send buffer of socket DatagramSocket was set to 640KB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux) WARNING [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 68) JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
これに対応するには、オペレーティングシステムのマニュアルでバッファーサイズを増やす方法を参照してください。Red Hat Enterprise Linux システムの場合は、root ユーザーとして /etc/sysctl.conf
を編集し、システムの再起動後も維持されるバッファーサイズの最大値を設定します。例を以下に示します。
# Allow a 25MB UDP receive buffer for JGroups net.core.rmem_max = 26214400 # Allow a 1MB UDP send buffer for JGroups net.core.wmem_max = 1048576
/etc/sysctl.conf
を編集後、sysctl -p
を実行して変更を反映します。
JGroups バッファーサイズの設定
以下のトランスポートプロパティーを UDP および TCP JGroups スタックに設定すると、JBoss EAP が使用する JGroups バッファーサイズを設定できます。
- UDP スタック
-
ucast_recv_buf_size
-
ucast_send_buf_size
-
mcast_recv_buf_size
-
mcast_send_buf_size
-
- TCP スタック
-
recv_buf_size
-
send_buf_size
-
JGroups バッファーサイズは、管理コンソールまたは管理 CLI を使用して設定できます。
以下の構文を使用して、管理 CLI で JGroups バッファーサイズプロパティーを設定します。
/subsystem=jgroups/stack=STACK_NAME/transport=TRANSPORT/property=PROPERTY_NAME:add(value=BUFFER_SIZE)
以下は、tcp
スタックで recv_buf_size
プロパティーを 20000000
に設定する管理 CLI コマンドの例になります。
/subsystem=jgroups/stack=tcp/transport=TRANSPORT/property=recv_buf_size:add(value=20000000)
JGroups バッファーサイズは管理コンソールを使用して設定することもできます。 Configuration タブで JGroups サブシステムを選択し、表示 をクリックして Stack タブを選択し、該当するスタックを選びます。 Transport をクリックし、 Properties フィールドを編集します。
24.2.10. JGroups サブシステムの調整
jgroups
サブシステムのパフォーマンスを監視および最適化するための情報は、『 パフォーマンスチューニングガイド』の「 JGroups サブシステムの調整」の項を参照してください。
24.2.11. JGroups トラブルシューティング
24.2.11.1. ノードがクラスターを形成しない
マシンで IP マルチキャストが正しくセットアップされていることを確認します。JBoss EAP には、IP マルチキャストのテストに使用できる McastReceiverTest
と McastSenderTest
の 2 つのテストプログラムが含まれています。
ターミナルで McastReceiverTest
を開始します。
$ java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastReceiverTest -mcast_addr 230.11.11.11 -port 5555
別のターミナルウインドウで McastSenderTest
を開始します。
$ java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastSenderTest -mcast_addr 230.11.11.11 -port 5555
特定のネットワークインターフェースカード (NIC) をバインドする場合は、-bind_addr YOUR_BIND_ADDRESS
を使用します。YOUR_BIND_ADDRESS
はバインドする NIC の IP アドレスに置き換えます。送信側と受信側の両方にこのパラメーターを使用します。
McastSenderTest
ターミナルウインドウで入力すると McastReceiverTest
ウインドウに出力が表示されます。表示されない場合は以下の手順に従います。
-
送信側のコマンドに
-ttl VALUE
を追加して、マルチキャストパケットの TTL (time-to-live) を増やします。このテストプログラムによって使用されるデフォルトの値は32
で、VALUE
は255
以下である必要があります。 - マシンに複数のインターフェースがある場合は、適切なインターフェースを使用していることを確認します。
- システム管理者に連絡し、マルチキャストが選択したインターフェースで動作することを確認します。
クラスターの各マシンでマルチキャストが適切に動作したら、送信側と受信側を別々のマシンに配置し、テストを繰り返します。
24.2.11.2. 障害検出での不明なハートビートの原因
ハートビートの確認が一定時間 (T
) 受信されないと、障害検出 (FD) によってクラスターメンバーが原因として疑われることがあります。T は timeout
および max_tries
によって定義されます。
たとえば、ノード A、B、C、および D のクラスターがあり、A が B、B が C、C が D、D が A を ping する場合、以下のいずれかの理由で C が疑われます。
-
B または C が CPU の使用率が 100% の状態で
T
秒よりも長く稼働している場合。この場合、 C がハートビート確認を B に送信しても CPU の使用率が 100% であるため B が確認を処理できないことがあります。 - B または C がガベッジコレクションを実行している場合、上記と同じ結果になります。
- 上記 2 件の組み合わせ。
- ネットワークによるパケットの損失が発生する場合。通常、ネットワークに大量のトラフィックがあり、スイッチがパケットを破棄すると発生します (通常は最初にブロードキャスト、次に IP マルチキャスト、そして最後に TCP パケットが破棄されます)。
-
B または C がコールバックを処理する場合。C が処理に
T
+ 1 秒かかるリモートメソッド呼び出しをチャネル上で受信した場合、C はハートビートを含む他のメッセージを処理できません。そのため、B はハートビート確認を受信せず、C が疑われます。
24.3. Infinispan
24.3.1. Infinispan
Infinispan は Java データグリッドプラットフォームで、キャッシュされたデータの管理に JSR-107 準拠のキャッシュインターフェースを提供します。キャッシュされたデータの管理と同等の Jakarta は Jakarta Persistence 2.2 です。
Infinispan の機能や設定オプションの詳細は Infinispan のドキュメント を参照してください。
infinispan
サブシステムは JBoss EAP のキャッシュサポートを提供します。名前付きのキャッシュコンテナーやキャッシュのランタイムメトリックスを設定および表示できます。
高可用性の機能を提供する設定を使用する場合 (管理対象ドメインでは ha や full-ha プロファイル、スタンドアロンサーバーは standalone-ha.xml
や standalone-full-ha.xml
設定ファイル)、infinispan
サブシステムはキャッシング、状態のレプリケーション、および状態分散サポートを提供します。高可用性でない設定では、infinispan
サブシステムはローカルのキャッシュサポートを提供します。
Infinispan は JBoss EAP のプライベートモジュールとして含まれ、JBoss EAP のキャッシュ機能を提供します。アプリケーションによる Infinispan の直接使用はサポートされません。
24.3.2. キャッシュコンテナー
キャッシュコンテナーはサブシステムによって使用されるキャッシュのリポジトリーです。各キャッシュコンテナーは、使用されるデフォルトのキャッシュを定義します。
JBoss EAP 7 は以下のデフォルト Infinispan キャッシュコンテナーを定義します。
-
server
(シングルトンキャッシング) -
web
(Web セッションクラスタリング) -
ejb
(ステートフルセッション Bean クラスタリング) -
hibernate
(エンティティーキャッシング)
例: Infinispan のデフォルト設定
<subsystem xmlns="urn:jboss:domain:infinispan:7.0"> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server"> <transport lock-timeout="60000"/> <replicated-cache name="default"> <transaction mode="BATCH"/> </replicated-cache> </cache-container> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan"> <transport lock-timeout="60000"/> <distributed-cache name="dist"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <file-store/> </distributed-cache> </cache-container> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> <transport lock-timeout="60000"/> <distributed-cache name="dist"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <file-store/> </distributed-cache> </cache-container> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> <transport lock-timeout="60000"/> <local-cache name="local-query"> <object-memory size="1000"/> <expiration max-idle="100000"/> </local-cache> <invalidation-cache name="entity"> <transaction mode="NON_XA"/> <object-memory size="1000"/> <expiration max-idle="100000"/> </invalidation-cache> <replicated-cache name="timestamps" mode="ASYNC"/> </cache-container> </subsystem>
各キャッシュコンテナーで定義されたデフォルトのキャッシュに注目してください。この例では、web
キャッシュコンテナーは dist
分散キャッシュをデフォルトとして定義します。そのため、Web セッションのクラスタリングでは dist
キャッシュが使用されます。
デフォルトキャッシュの変更やキャッシュの追加に関する詳細は、「キャッシュコンテナーの設定」を参照してください。
HTTP セッション、ステートフルセッション Bean、シングルトンサービスやデプロイメントなどのキャッシュやキャッシュコンテナーを追加できます。ユーザーアプリケーションによるこれらのキャッシュの直接使用はサポートされません。
24.3.2.1. キャッシュコンテナーの設定
キャッシュコンテナーやキャッシュ属性は、管理コンソールまたは管理 CLI を使用して設定できます。
設定の他のコンポーネントが参照する可能性があるため、キャッシュまたはキャッシュコンテナーの名前を変更しないでください。
管理コンソールを使用したキャッシュの設定
管理コンソールの Configuration タブで Infinispan サブシステムを選択するとキャッシュやキャッシュコンテナーを設定できます。管理対象ドメインでは設定するプロファイルを選択してください。
キャッシュコンテナーを追加します。
Cache Container の横にある追加 (+) ボタンをクリックし、Cache Container を追加 を選択して新しいキャッシュコンテナーの設定を入力します。
キャッシュコンテナー設定を更新します。
該当するキャッシュコンテナーを選択し、表示 を選択します。必要に応じてキャッシュコンテナーの設定を行います。
キャッシュコンテナートランスポート設定を更新します。
該当するキャッシュコンテナーを選択し、表示 を選択します。Transport タブで、必要に応じてキャッシュコンテナートランスポートを設定します。
キャッシュを設定します。
該当するキャッシュコンテナーを選択し、表示 を選択します。キャッシュタブ (Replicated Cache など) でキャッシュを追加、更新、および削除できます。
管理 CLI を使用したキャッシュの設定
管理 CLI を使用してキャッシュおよびキャッシュコンテナーを設定できます。管理対象ドメインではコマンドの前に /profile=PROFILE_NAME
を追加して更新するプロファイルを指定する必要があります。
キャッシュコンテナーを追加します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER:add
レプリケートされたキャッシュを追加します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE:add(mode=MODE)
キャッシュコンテナーのデフォルトキャッシュを設定します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=default-cache,value=CACHE)
レプリケートされたキャッシュのバッチ処理を設定します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE/component=transaction:write-attribute(name=mode,value=BATCH)
以下の例は、concurrent
分散キャッシュを web
キャッシュコンテナーに追加する方法を表しています。このキャッシュ設定はデフォルトキャッシュのロック制約を緩和し、複数の同時リクエストが同じ web セッションに同時にアクセスできるようにします。これは、ロックのない読み取りを許可し、排他的ロックをより頻繁により短期間で取得することで実現されます。
以下の CLI コマンドを使用して concurrent
分散キャッシュを web
キャッシュコンテナーに追加し、デフォルトのキャッシュにします。
batch /subsystem=infinispan/cache-container=web/distributed-cache=concurrent:add /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=concurrent) /subsystem=infinispan/cache-container=web/distributed-cache=concurrent/store=file:add run-batch
これにより、サーバーが以下のように設定されます。
<cache-container name="web" default-cache="concurrent" module="org.wildfly.clustering.web.infinispan"> ... <distributed-cache name="concurrent"> <file-store/> </distributed-cache> </cache-container>
デフォルト EJB キャッシュコンテナーの変更
以下のようにキャッシュコンテナーを ejb3
サブシステムで使用できます。
-
EJB セッション bean のパッシベーションをサポートするには、
infinispan
サブシステムに定義されたejb
キャッシュコンテナーを使用してセッションを保存できます。 - サーバー上でクラスター化されたデプロイメントに接続するリモート EJB クライアントの場合、クラスタートポロジーの情報をこれらのクライアントに提供して、これらのクライアントが対話するノードに障害が発生したときにクラスターの別のノードにフェイルオーバーできるようにする必要があります。
パッシベーションやトポロジー情報の提供をサポートするデフォルトのキャッシュコンテナー ejb
を変更する場合や、その名前を変更する場合、以下の例のように cache-container
属性を passivation-stores
要素に追加し、cluster
属性を remote
要素に追加する必要があります。独自に使用するために新しいキャッシュを追加する場合は、このような変更を加える必要はありません。
<subsystem xmlns="urn:jboss:domain:ejb3:5.0"> <passivation-stores> <passivation-store name="infinispan" cache-container="ejb-cltest" max-size="10000"/> </passivation-stores> <remote cluster="ejb-cltest" connector-ref="http-remoting-connector" thread-pool-name="default"/> </subsystem> <subsystem xmlns="urn:jboss:domain:infinispan:7.0"> ... <cache-container name="ejb-cltest" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan"> </subsystem>
Hibernate キャッシュコンテナーのエビクション機能
hibernate
キャッシュコンテナーのエビクション機能は、メモリーからキャッシュエントリーを削除します。この機能は、サブシステムのメモリー負荷を軽減するのに役立ちます。
size
属性は、キャッシュエントリーのエビクションの開始前に保存されるキャッシュエントリーの最大数を設定します。
例:エビクション機能
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan"> <transport lock-timeout="60000"/> <local-cache name="local-query"> <object-memory size="1000"/> <expiration max-idle="100000"/>
エビクションはメモリー内でのみ実行されることに注意してください。キャッシュストアは、情報の永続的な損失を防ぐためにエビクトされたキャッシュエントリーを保持します。エビクション 機能についての詳細は、『Infinispan ユーザーガイド』の「エビクションおよびデータコンテナー」セクションを参照し てください。
24.3.3. クラスタリングモード
JBoss EAP で Infinispan を使用すると、2 つの方法でクラスタリングを設定できます。ご使用のアプリケーションに最も適した方法は要件によって異なります。各モードでは可用性、一貫性、信頼性、およびスケーラビリティーのトレードオフが発生します。クラスタリングモードを選択する前に、ネットワークで最も重要な点を特定し、これらの要件のバランスを取ることが必要となります。
キャッシュモード
- Replication (レプリケーション)
- Replication (レプリケーション) モードはクラスターの新しいインスタンスを自動的に検出し、追加します。これらのインスタンスに加えられた変更は、クラスター上のすべてのノードにレプリケートされます。ネットワークでレプリケートされる情報量が多いため、通常 Replication モードは小型のクラスターでの使用に最も適しています。UDP マルチキャストを使用するよう Infinispan を設定すると、ネットワークトラフィックの輻輳をある程度軽減できます。
- Distribution (分散)
Distribution (分散) モードでは、Infinispan はクラスターを線形にスケールできます。Distribution モードは一貫性のあるハッシュアルゴリズムを使用して、クラスター内で新しいノードを配置する場所を決定します。保持する情報のコピー数 (または所有者数) は設定可能です。保持するコピー数、データの永続性、およびパフォーマンスにはトレードオフが生じます。保持するコピー数が多いほどパフォーマンスへの影響が大きくなりますが、サーバーの障害時にデータを損失する可能性は低くなります。ハッシュアルゴリズムは、メタデータのマルチキャストや保存を行わずにエントリーを配置し、ネットワークトラフィックを軽減します。
クラスターサイズが 6-8 ノードを超える場合は Distribution モードをキャッシュストラテジーとして使用することを考慮してください。Distribution モードでは、データはクラスター内のすべてのノードではなくノードのサブセットのみに分散されます。
- Scattered (散在)
Scattered (散在) モードは、一貫したハッシュアルゴリズムを使用して所有者を判断する Distribution モードと似ています。しかし、所有者は 2 名のメンバーに限定され、オリジネーター (指定のセッションのリクエストを受信するノード) は常にロックを調整する所有者やキャッシュエントリーのアップデートを想定します。2 名の所有者を持つ分散キャッシュが頻繁に 2 つの RPC 呼び出しを使用できる場合、Scattered モードで使用されるキャッシュ書き込みアルゴリズムは、書き込み操作の結果が単一の RPC 呼び出しになることを保証します。これは、ロードバランサーのフェイルオーバーがプライマリー以外の所有者やバックアップノードにトラフィックを向ける可能性があるため、分散 Web セッションに便利です。これにより、競合の可能性を下げ、クラスタートポロジーの変更後にパフォーマンスを向上することが可能になります。
Scattered モードは、トランザクションや L1 キャッシュをサポートしません。しかし、一貫したハッシュによると所有者ではない場合でも、指定エントリーのキャッシュの書き込みを開始するノードは一定の期間は継続してそのエントリーの読み取りを継続する、バイアス読み取り (Biased read) をサポートします。バイアス読み取りと L1 キャッシュの設定属性は異なりますが、L1 キャッシュと同様の効果があります。
同期および非同期のレプリケーション
レプリケーションは同期または非同期モードで実行でき、選択するモードは要件やアプリケーションモードによって異なります。
JBoss EAP 7.1 以降では、常に同期 (SYNC
) キャッシュモードを使用する必要があります。sync
はデフォルトのキャッシュモードです。非同期 (ASYNC
) モードの使用は有効ではないため、ロック競合が発生します。セッションレプリケーションと適切なキャッシュモードの詳細は、「How to configure and tune the session replication for EAP」を参照してください。
- 同期のレプリケーション
- 同期のレプリケーションでは、レプリケーションプロセスはユーザーのリクエストを処理するのと同じスレッドで実行されます。セッションレプリケーションは、完了した応答がクライアントに返送された後に開始され、スレッドはレプリケーションの完了後のみに解放されます。同期レプリケーションはクラスターの各ノードからの応答を必要とするため、ネットワークトラフィックに影響を与えます。ただし、クラスターのすべてのノードへ確実に変更が加えられる利点があります。
- 非同期のレプリケーション
- 非同期のレプリケーションでは、Infinispan はスレードプールを使用してバックグラウンドでレプリケーションを実行します。送信元はクラスターの他のノードからの返答を待ちません。しかし、同じセッションを読み取るキャッシュはその前のレプリケーションが完了するまでブロックされるため、陳腐データは読み取られません。レプリケーションは時間ベースまたはキューのサイズによって引き起こされます。失敗したレプリケーションはログに書き込まれ、リアルタイムで通知されません。
24.3.3.1. キャッシュモードの設定
管理 CLI を使用してデフォルトキャッシュを変更できます。
ここでは、デフォルトが Distribution モードである Web セッションキャッシュの設定に固有する手順を説明します。手順と管理 CLI コマンドは、他のキャッシュコンテナー向けに簡単に調整できます。
Replication キャッシュモードへの変更
Web セッションキャッシュのデフォルトの JBoss EAP 7 設定には、レプリケートされたキャッシュ repl
が含まれていません。最初にこのキャッシュを追加する必要があります。
以下はスタンドアロンサーバーの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan
コマンドの前に /profile=PROFILE_NAME
を追加し、更新するプロファイルを指定する必要があります。
レプリケーションキャッシュ
repl
を追加し、デフォルトのキャッシュとして設定します。batch /subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode=ASYNC) /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=transaction:add(mode=BATCH) /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=locking:add(isolation=REPEATABLE_READ) /subsystem=infinispan/cache-container=web/replicated-cache=repl/store=file:add /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=repl) run-batch
サーバーをリロードします。
reload
Distribution キャッシュモードへの変更
Web セッションキャッシュのデフォルトの JBoss EAP 7 設定にはすでに dist
分散キャッシュが含まれています。
以下はスタンドアロンサーバーの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan
コマンドの前に /profile=PROFILE_NAME
を追加し、更新するプロファイルを指定する必要があります。
デフォルトのキャッシュを
dist
分散キャッシュに変更します。/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=dist)
分散キャッシュの所有者数を設定します。以下のコマンドは所有者の数を
5
に設定します。デフォルトは2
です。/subsystem=infinispan/cache-container=web/distributed-cache=dist:write-attribute(name=owners,value=5)
サーバーをリロードします。
reload
Scattered キャッシュモードの変更
web セッションキャッシュのデフォルトの JBoss EAP 設定には scattered-cache
が含まれていません。以下の例は、scattered キャッシュを追加し、デフォルトのキャッシュとして設定する管理 CLI コマンドを示しています。
以下は、HA プロファイルを使用するスタンドアロンサーバー向けの管理 CLI コマンドになります。管理対象ドメインで実行している場合は、/subsystem=infinispan
コマンドの前に /profile=PROFILE_NAME
を追加し、更新するプロファイルを指定する必要があります。
読み取りのバイアスライフスパンがデフォルトの web セッションタイムアウト値 (30 分) と同じになるよう、scattered キャッシュを作成します。
/subsystem=infinispan/cache-container=web/scattered-cache=scattered:add(bias-lifespan=1800000)
scattered
をデフォルトキャッシュとして設定します。/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=scattered)
これにより、サーバーが以下のように設定されます。
<cache-container name="web" default-cache="scattered" module="org.wildfly.clustering.web.infinispan"> ... <scattered-cache name="scattered" bias-lifespan="1800000"/> ... </cache-container>
24.3.3.2. キャッシュストラテジーのパフォーマンス
SYNC
キャッシュストラテジーを使用すると、レプリケーションが完了するまでリクエストが完了しないため、レプリケーションのコストを簡単に評価でき、直接応答時間に影響します。
ASYNC
キャッシュストラテジーの応答時間は SYNC
キャッシュストラテジーよりも短いと思われがちですが、一定の状況下でのみ短くなります。ASYNC
キャッシュストラテジーの評価はより困難ですが、リクエスト間の時間がキャッシュ操作を完了できるほど長い場合はパフォーマンスが SYNC
よりも良くなります。これは、レプリケーションのコストが応答時間に即影響しないためです。
同じセッションのリクエストの作成が早すぎると、先行リクエストからのレプリケーションが完了するまで待機しなければならないため、先行リクエストのレプリケーションコストが後続リクエストの前に移動します。応答の受信直後に後続リクエストが送信され、リクエストが急速に発生する場合、 ASYNC
キャッシュストラテジーのパフォーマンスは SYNC
よりも劣化します。そのため、同じセッションのリクエストの間には、SYNC
キャッシュストラテジーのパフォーマンスが ASYNC
キャッシュストラテジーよりも良くなる期間のしきい値があります。実際の使用状態では、通常同じセッションのリクエストが立て続けに受信されることはありませんが、一般的にリクエストの間に数秒程度の時間が存在します。その代わりに、通常、要求間に数秒以上の時間が経過します。この場合、ASYNC
キャッシュストラテジーが適切なデフォルトで、応答時間が早くなります。
24.3.4. 状態遷移
状態遷移は、基本的なデータグリッドとクラスター化されたキャッシュ機能の両方です。状態遷移がない状態では、ノードがクラスターに追加されたり、クラスターから削除されるとデータが失われます。
状態遷移は、キャッシュメンバーシップの変更に応じて、キャッシュの内部状態を調整します。この変更は、ノードがクラスターに参加または退出するとき、2 つ以上のクラスターパーティションがマージするとき、またはこれらのイベントの組み合わせが発生した後に自動的に行われます。新しいキャッシュは、以下のキャッシュのモードを基にして、最大量の状態を受け取る必要があるため、新たに開始されたキャッシュの最初の状態遷移は最も多くのリソースが必要となります。
timeout
属性を使用すると、新たに開始されたキャッシュが状態を受け取る待ち時間を制御することができます。timeout
属性が正の値である場合、キャッシュはすべての初期状態を受け取るまで待機した後、リクエストに対応できるようになります。状態遷移が指定時間内 (デフォルトは 240000
ミリ秒) に完了しなかった場合、キャッシュによってエラーが発生し、開始がキャンセルされます。timeout
を 0
に設定するとキャッシュは即座に利用可能になり、バックグラウンド操作中に最初の状態を受け取ります。最初の状態遷移が完了するまで、キャッシュが受け取っていないキャッシュエントリーのリクエストは、リモートノードから取得する必要があります。
timeout
属性を 0
に設定するには、以下のコマンドを実行します。
/subsystem=infinispan/cache-container=server/CACHE_TYPE=CACHE/component=state-transfer:write-attribute(name=timeout,value=0)
状態遷移の挙動はキャッシュのモードによって決まります。
- Replicated (レプリケート) モードでは、キャッシュに参加する新規ノードは既存ノードからキャッシュの状態をすべて受け取ります。ノードがクラスターから退出すると、状態遷移はありません。
-
Distribution (分散) モードでは、新しいノードは既存のノードから状態の一部のみを受け取り、既存のノードは一貫したハッシュの決定どおりに、各キーの
owners
コピーを維持するために状態の一部を削除します。ノードがクラスターから退出する場合、分散キャッシュはそのノードに保存されたキーの追加コピーを作成し、各キーの所有者が存続するようにする必要デフォルトがあります。 - Invalidation (インバリデーション) モードでは、最初の状態推移は Replicated モードと似ていますが、ノードが同じ状態でいられる保証がないことが唯一の違いです。ノードがクラスターから退出すると、状態遷移はありません。
デフォルトでは、状態遷移はインメモリーおよび永続状態の両方を遷移しますが、設定で無効にすることもできます。状態遷移が無効になっている場合、ClusterLoader
を設定しないと、データをキャッシュにロードせずにノードがキーの所有者またはバックアップ所有者になります。さらに、Distribution モードで状態遷移が無効になっていると、キャッシュでキーのコピーが owners
コピーよりも少なくなることがあります。
24.3.5. Infinispan スレッドプールの設定
infinispan
サブシステムには async-operations
、expiration
、listener
、persistence
、remote-command
、state-transfer
、および transport
スレッドプールが含まれます。これらのプールはすべての Infinispan キャッシュコンテナーに設定できます。
以下の表は、infinispan
サブシステムの各スレッドプールに設定できる属性とデフォルト値を表しています。
スレッドプール名 | keepalive-time | max-threads | min-threads | queue-length |
---|---|---|---|---|
async-operations | 60000L | 25 | 25 | 1000 |
expiration | 60000L | 1 | 該当なし | 該当なし |
listener | 60000L | 1 | 1 | 100000 |
persistence | 60000L | 4 | 1 | 0 |
remote-command | 60000L | 200 | 1 | 0 |
state-transfer | 60000L | 60 | 1 | 0 |
transport | 60000L | 25 | 25 | 100000 |
以下の構文を使用して、管理 CLI で Infinispan スレッドプールを設定します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER_NAME/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)
以下は、 server
キャッシュコンテナーの persistence
スレッドプールで max-threads
の値を 10
に設定する管理 CLI コマンドの例になります。
/subsystem=infinispan/cache-container=server/thread-pool=persistence:write-attribute(name="max-threads", value="10")
24.3.6. Infinispan の統計
監視目的で、Infinispan キャッシュやキャッシュコンテナーに関する実行時統計を有効にできます。パフォーマンス上の理由で、統計の収集はデフォルトでは無効になっています。
統計収集は、各キャッシュコンテナー、キャッシュ、または両方に対して有効にできます。各キャッシュの統計オプションはキャッシュコンテナーのオプションをオーバーライドします。キャッシュコンテナーの統計収集を無効または有効にすると、独自の設定が明示的に指定されている場合以外はそのコンテナーのすべてのキャッシュが設定を継承します。
24.3.6.1. Infinispan 統計の有効化
Infinispan の統計を有効にすると、infinispan
サブシステムのパフォーマンスに影響する可能性があります。統計は必要な場合のみ有効にしてください。
管理コンソールまたは管理 CLI を使用すると Infinispan の統計収集を有効または無効にできます。管理コンソールでは、Configuration タブで Infinispan サブシステム選択してキャッシュまたはキャッシュコンテナーを選択し、Statistics Enabled 属性を編集します。管理 CLI を使用する場合は以下のコマンドを実行して統計を有効にします。
キャッシュコンテナーの統計収集を有効にします。サーバーをリロードする必要があります。
/subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=statistics-enabled,value=true)
キャッシュの統計収集を有効にします。サーバーをリロードする必要があります。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:write-attribute(name=statistics-enabled,value=true)
以下のコマンドを使用すると、キャッシュの statistics-enabled
属性の定義が解除され、キャッシュコンテナーの statistics-enabled
属性の設定を継承します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:undefine-attribute(name=statistics-enabled)
24.3.7. Infinispan パーティションの処理
Infinispan クラスターは、データが保存される複数のノードで構築されます。複数のノードに障害が発生した場合のデータの損失を防ぐため、Infinispan は複数のノードで同じデータをコピーします。このレベルのデータ冗長性は owners
属性を使用して設定されます。設定されたノードの数未満のノードが同時にクラッシュしても、Infinispan はデータのコピーを利用できます。
しかし、クラスターから大量のノードが消滅すると最悪の事態を招く可能性があります。
- スプリットブレイン
スプリットブレインはクラスターを独立して動作する 2 つ以上のパーティションまたはサブクラスターに分割します。このような場合、異なるパーティションから読み書きする複数のクライアントが同じキャッシュエントリーの異なるバージョンを見ることになり、多くのアプリケーションにとって問題となります。
注記スプリットブレインの発生を軽減する方法には、冗長化ネットワークや IP ボンディングなどがあります。 しかし、これらの方法は問題発生のリードタイムを削減するだけです。
- 複数ノードの連続クラッシュ
- 複数のノード (所有者の数) が連続してクラッシュし、Infinispan がクラッシュ間の状態を適切に調整する時間がない場合、結果として部分的なデータの損失が発生します。
スプリットブレインや複数ノードの連続クラッシュが原因で、不適切なデータがユーザーに返されないようにすることが大切です。
24.3.7.1. スプリットブレイン
スプリットブレインが発生した場合、各ネットワークパーティションが独自の JGroups ビューをインストールし、他のパーティションからノードを削除します。パーティションはお互いを認識しないため、クラスターが 2 つ以上のパーティションに分割されたかどうかを直接判断することはできません。そのため、明示的な脱退メッセージを送信せずに、1 つ以上のノードが JGroups クラスターから消滅した場合にクラスターが分割されたと判断します。
パーティション処理が無効の場合、各パーティションは継続して独立したクラスターとして機能します。各パーティションはデータの一部のみを認識できる可能性があり、競合する更新をキャッシュに書き込む可能性があります。
パーティション処理が有効の場合、スプリットを検出したときに各パーティションは即座にリバランスを行わず、degrade モードにするかどうかを最初にチェックします。
- 1 つ以上のセグメントがすべての所有者を失った場合 (最後に行ったリバランスが完了した後に指定した所有者の数以上が脱退した場合)、パーティションは degrade モードになります。
- 最新の安定したトポロジーでパーティションに単純多数のノード (floor(numNodes/2) + 1) が含まれない場合も、パーティションは degrade モードになります。
- その他の場合は、パーティションは通常通り動作し、リバランスを開始します。
安定したトポロジーは、リバランス操作が終了するたびに更新され、コーディネーターによって他のリバランスが必要ないと判断された場合に毎回更新されます。これらのルールは、1 つのパーティションが available モードを維持し、他のパーティションが degraded モードになるようにします。
パーティションが degraded モードの場合、完全に所有されたキーへのアクセスのみを許可します。
- このパーティション内のノード上のコピーをすべて持つエントリーのリクエスト (読み取りおよび書き込み) は許可されます。
-
消滅したノードによって完全所有または一部所有されたエントリーのリクエストは
AvailabilityException
によって拒否されます。
これにより、パーティションが同じキーに異なる値を書き込めないようにし (キャッシュの一貫性を保つ) 、さらにパーティションが他のパーティションで更新されたキーを読み取れないようにします (陳腐データをなくす)。
2 つのパーティションは分離して開始できます。これらのパーティションはマージされなければ不整合なデータを読み書きできます。 将来的に、この状況に対処できるカスタムの可用性ストラテジーが許可される可能性があります (例: 特定のノードがクラスターの一部であるかを確認、外部のマシンにアクセスできるかどうかを確認など)。
24.3.7.2. パーティション処理の設定
現在、パーティションの処理はデフォルトで無効になっています。パーティションの処理を有効にするには、以下の管理 CLI コマンドを使用します。
/subsystem=infinispan/cache-container=web/distributed-cache=dist/component=partition-handling:write-attribute(name=enabled, value=true)
24.3.8. リモートキャッシュコンテナーの設定
管理対象ドメインのすべてのサーバーグループに対してリモートキャッシュを設定する必要があります。指定の remote-cache-container および関連するランタイムキャッシュのメトリクスのコレクションを
属性で有効にできます。
statistics-
enabled
24.3.8.1. リモートキャッシュコンテナーの作成
管理対象ドメインの各サーバーグループには、一意のリモートキャッシュが必要です。このキャッシュは、同じデータグリッドに所属することができます。そのため、ユーザーは、サーバーグループのソケットバインディングを定義し、ソケットバインディングをリモートキャッシュコンテナーに関連付けることにより、すべてのサーバーグループのリモートキャッシュを設定する必要があります。
手順
socket-binding
を定義します。 クラスターの各リモート Red Hat Data Grid インスタンスの必要に応じて、コマンドを繰り返し実行します。/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=SOCKET_BINDING:add(host=HOSTNAME,port=PORT)
新規作成されたソケットバインディングを参照する
remote-cache-container
を定義します。batch /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER:add(default-remote-cluster=data-grid-cluster) /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/remote-cluster=data-grid-cluster:add(socket-bindings=[SOCKET_BINDING,SOCKET_BINDING_2,...]) run-batch
24.3.8.2. リモートキャッシュコンテナーの統計の有効化
statistics-enabled
属性により、指定の remote-cache-container
および関連するランタイムキャッシュについてのメトリクスのコレクションが有効になります。
-
「foo」という
remote-cache-container
場合は、次の操作を使用して統計を有効にします。
/subsystem=infinispan/remote-cache-container=foo:write-attribute(name=statistics-enabled, value=true)
-
「foo」という
remote-cache-container
については、以下のメトリクスがランタイム時に表示されます。
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=connections) /subsystem=infinispan/remote-cache-container=foo:read-attribute(name=active-connections) /subsystem=infinispan/remote-cache-container=foo:read-attribute(name=idle-connections)
-
これらのメトリクスの説明は、
remote-cache-container
に read-resource-description 操作を実行します。
/subsystem=infinispan/remote-cache-container=foo:read-resource-description
- 以下のメトリクスは、選択したデプロイメントによって使用されるリモートキャッシュに固有のものです。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource(include-runtime=true, recursive=true) { "average-read-time" : 1, "average-remove-time" : 0, "average-write-time" : 2, "hits" : 9, "misses" : 0, "near-cache-hits" : 7, "near-cache-invalidations" : 8, "near-cache-misses" : 9, "near-cache-size" : 1, "removes" : 0, "time-since-reset" : 82344, "writes" : 8 }
- これらのメトリクスの説明は、リモートキャッシュに対して read-resource-description 操作を実行します。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource-description
- これらのメトリクスの一部は計算値 (例: average- *) であり、ヒットやミスなどのその他は集計値です。この集計メトリクスは、以下の操作でリセットできます。
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:reset-statistics()
24.3.9. HTTP セッションの Red Hat Data Grid への外部化
この機能を使用するには Red Hat Data Grid のサブスクリプションが必要です。
Red Hat Data Grid は、HTTP セッションなどの JBoss EAP のアプリケーション固有データの外部キャッシュコンテナーとして使用できます。これにより、アプリケーションとは独立したデータレイヤーのスケーリングが可能になり、さまざまなドメインに存在する可能性がある異なる JBoss EAP クラスターが同じ Red Hat Data Grid クラスターからデータにアクセスできるようになります。また、他のアプリケーションは Red Hat Data Grid によって提供されたキャッシュと対話できます。
以下の例は、HTTP セッションを外部化する方法を説明しています。これは、JBoss EAP のスタンドアロンインスタンスと管理対象ドメインの両方に適用されます。
-
remote-cache-container
を作成します。詳細は、「リモートキャッシュコンテナーの設定」を参照してください。 HotRod ストアを設定します。HotRod ストアは、JBoss EAP サーバーによって作成された各キャッシュに対して専用のリモートキャッシュを 1 つ使用します。通常、以下の CLI スクリプトのように、JBoss EAP サーバーで 1 つのインバリデーション キャッシュが使用されます。
注記Red Hat JDG サーバーでリモートキャッシュを手作業で設定する必要があります。これらのキャッシュに推奨される設定は、楽観的ロックを持つトランザクション分散モードです。キャッシュ名はデプロイメントファイル名に対応する必要があります (例:
test.war
)。リモートキャッシュコンテナーが設定されたら、
hotrod
ストアを設定して既存のストアを置き換えることができます。以下の CLI スクリプトは、インバリデーションキャッシュとともにセッションをオフロードする典型的なユースケースを示しています。batch /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME:add() /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/store=hotrod:add(remote-cache-container=CACHE_CONTAINER,fetch-state=false,purge=false,passivation=false,shared=true) /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=transaction:add(mode=BATCH) /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=locking:add(isolation=REPEATABLE_READ) /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=CACHE_NAME) run-batch
このスクリプトは新しいインバリデーションキャッシュを設定します。作成後、セッションデータはパフォーマンスの目的でキャッシュに維持され、復元の目的でストアに書き込まれます。
@Resource
アノテーションを使用すると、HotRod クライアントを直接 Jakarta EE アプリケーションにインジェクトすることができます。@Resource
アノテーションはhotrod-client.properties
ファイルで、クラスパスの設定プロパティーを検索します。@Resource(lookup = "java:jboss/infinispan/remote-container/web-sessions") private org.infinispan.client.hotrod.RemoteCacheContainer client;
例:
hotrod-client.properties
ファイルinfinispan.client.hotrod.transport_factory = org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory infinispan.client.hotrod.server_list = 127.0.0.1:11222 infinispan.client.hotrod.marshaller = org.infinispan.commons.marshall.jboss.GenericJBossMarshaller infinispan.client.hotrod.async_executor_factory = org.infinispan.client.hotrod.impl.async.DefaultAsyncExecutorFactory infinispan.client.hotrod.default_executor_factory.pool_size = 1 infinispan.client.hotrod.default_executor_factory.queue_size = 10000 infinispan.client.hotrod.hash_function_impl.1 = org.infinispan.client.hotrod.impl.consistenthash.ConsistentHashV1 infinispan.client.hotrod.tcp_no_delay = true infinispan.client.hotrod.ping_on_startup = true infinispan.client.hotrod.request_balancing_strategy = org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy infinispan.client.hotrod.key_size_estimate = 64 infinispan.client.hotrod.value_size_estimate = 512 infinispan.client.hotrod.force_return_values = false ## below is connection pooling config maxActive=-1 maxTotal = -1 maxIdle = -1 whenExhaustedAction = 1 timeBetweenEvictionRunsMillis=120000 minEvictableIdleTimeMillis=300000 testWhileIdle = true minIdle = 1
リモートキャッシュコンテナーのセキュア化
SSL を使用してリモート Red Hat Data Grid インスタンスへの通信をセキュアにすることが可能です。これを行うには、JBoss EAP インスタンスで remote-cache-container
を設定し、Red Hat Data Grid インスタンスで hotrod コネクターを調整してアクティブなセキュリティーレルムを使用するようにします。
JBoss EAP で
client-ssl-context
を作成します。他の elytron コンポーネントの生成など、client-ssl-context
の作成に関する詳細は、JBoss EAP『 How to Configure Server Security 』の「 Using a client-ssl-context 」を参照してください。/subsystem=elytron/client-ssl-context=CLIENT_SSL_CONTEXT:add(key-manager=KEY_MANAGER,trust-manager=TRUST_MANAGER)
クライアント SSL コンテキストを使用するよう、リモートキャッシュコンテナーを設定します。
/subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/component=security:write-attribute(name=ssl-context,value=CLIENT_SSL_CONTEXT)
リモート Red Hat Data Grid インスタンスをセキュアにします。各インスタンスの必要に応じて手順を繰り返します。
-
client-ssl-context
で使用されるキーストアをリモート Red Hat Data Grid インスタンスにコピーします。 ApplicationRealm
を設定して、このキーストアを使用するようにします。/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:add(keystore-path="KEYSTORE_NAME",keystore-relative-to="jboss.server.config.dir",keystore-password="KEYSTORE_PASSWORD")
hotrod コネクターを調整して、このセキュリティーレルムを示すようにします。
/subsystem=datagrid-infinispan-endpoint/hotrod-connector=hotrod-connector/encryption=ENCRYPTION:add(require-ssl-client-auth=false,security-realm="ApplicationRealm")
リモート Red Hat Data Grid インスタンスをリロードします。
reload
-
24.3.10. リモートストアを使用した HTTP セッションの Red Hat Data Grid への外部化
この機能を使用するには Red Hat Data Grid のサブスクリプションが必要です。
この手順は、セッションを外部化する旧式の方法になります。JBoss EAP 7.2 には、elytron
サブシステムと統合する HotRod プロトコルをベースとするカスタムの最適化されたキャッシュストアが導入されました。「HTTP セッションの JBoss Data Grid への外部化
」の説明にしたがって、新しい hotrod ストアを使用することが推奨されます。
分散可能なアプリケーションごとに完全に新しいキャッシュを作成する必要があります。新しいキャッシュは web
などの既存のキャッシュコンテナーに作成できます。
HTTP セッションを外部化するには、以下を行います。
ネットワーク情報を
socket-binding-group
に追加することにより、リモート Red Hat Data Grid サーバーの場所を定義します。例: リモートソケットバインディングの追加
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server1:add(host=RHDGHostName1, port=11222) /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server2:add(host=RHDGHostName2, port=11222)
結果の XML
<socket-binding-group name="standard-sockets" ... > ... <outbound-socket-binding name="remote-rhdg-server1"> <remote-destination host="RHDGHostName1" port="11222"/> </outbound-socket-binding> <outbound-socket-binding name="remote-rhdg-server2"> <remote-destination host="RHDGHostName2" port="11222"/> </outbound-socket-binding> </socket-binding-group>
注記各 Red Hat Data Grid サーバーにリモートソケットバインディングを設定する必要があります。
リモートキャッシュコンテナーが JBoss EAP の
infinispan
サブシステムで定義されているようにしてください。 以下の例では、remote-store
要素のcache
属性によって、リモート Red Hat Data Grid サーバーのキャッシュ名が定義されます。管理対象ドメインで実行している場合は、コマンドの前に
/profile=PROFILE_NAME
を追加してください。例: リモートキャッシュコンテナーの追加
/subsystem=infinispan/cache-container=web/invalidation-cache=rhdg:add(mode=SYNC) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=locking:write-attribute(name=isolation,value=REPEATABLE_READ) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=transaction:write-attribute(name=mode,value=BATCH) /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/store=remote:add(remote-servers=["remote-rhdg-server1","remote-rhdg-server2"], cache=default, socket-timeout=60000, passivation=false, purge=false, shared=true)
結果の XML
<subsystem xmlns="urn:jboss:domain:infinispan:7.0"> ... <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan" statistics-enabled="true"> <transport lock-timeout="60000"/> <invalidation-cache name="rhdg" mode="SYNC"> <locking isolation="REPEATABLE_READ"/> <transaction mode="BATCH"/> <remote-store cache="default" socket-timeout="60000" remote-servers="remote-rhdg-server1 remote-rhdg-server2" passivation="false" purge="false" shared="true"/> </invalidation-cache> ... </cache-container> </subsystem>
キャッシュ情報をアプリケーションの
jboss-web.xml
ファイルに追加します。以下の例では、web
はキャッシュコンテナーの名前で、rhdg
はこのコンテナーにある適切なキャッシュの名前になります。例:
jboss-web.xml
ファイル<?xml version="1.0" encoding="UTF-8"?> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd" version="10.0"> <replication-config> <replication-granularity>SESSION</replication-granularity> <cache-name>web.rhdg</cache-name> </replication-config> </jboss-web>
24.4. JBoss EAP をフロントエンドロードバランサーとして設定
バックエンド JBoss EAP サーバーへリクエストをプロキシーするフロントエンドロードバランサーとして動作するよう JBoss EAP と undertow
サブシステムを設定できます。Undertow は非同期 IO を使用するため、リクエストに関与するスレッドは接続用の IO スレッドのみになります。同じスレッドがバックエンドサーバーへの接続に使用されます。
以下のプロトコルを使用できます。
-
HTTP/1 および HTTP/2 (
h2c
) をサポートするプレーンテキスト上の HTTP (http
) -
HTTP/1 および HTTP/2 (
h2c
) をサポートするセキュアの接続上の HTTP (http
) -
AJP (
ajp
)
静的ロードバランサーを定義して設定でバックエンドホストを指定するか、mod_cluster フロントエンドを使用してホストを動的に更新します。
HTTP/2 を使用するよう Undertow を設定する手順は、「HTTP/2 の設定」を参照してください。
24.4.1. mod_cluster を使用して Undertow をロードバランサーとして設定
組み込みの mod_cluster フロントエンドロードバランサーを使用して、他の EAP インスタンスを負荷分散できます。
この手順では、管理対象ドメインを実行し、以下が設定済みであることを前提としています。
ロードバランサーとして動作する JBoss EAP サーバー。
このサーバーは、
load-balancer-sockets
ソケットバインディンググループにバインドされるload-balancer
プロファイルを使用します。注記このサーバーをフロントエンドロードバランサーとして使用するため、
load-balancer
プロファイルには、ソケットバインディング、mod-cluster Undertow フィルター、およびデフォルトホストでのフィルターへの参照がすでに事前設定されています。
バックエンドサーバーとして動作する 2 つの JBoss EAP サーバー。
-
これらのサーバーはクラスターで実行され、
ha-sockets
ソケットバインディンググループにバインドされるha
プロファイルを使用します。
-
これらのサーバーはクラスターで実行され、
- バックエンドサーバーにデプロイされた負荷分散される分散可能なアプリケーション。
mod_cluster フロントエンドロードバランサーの設定
以下の手順は、管理対象ドメインのサーバーを負荷分散しますが、手順を変更するとスタンドアロンサーバーのセットに適用することができます。ご使用の環境に応じて管理 CLI コマンドの値を変更してください。
mod_cluster アドバタイズセキュリティーキーを設定します。
アドバタイズセキュリティーキーを追加すると、ロードバランサーとサーバーが検出中に認証されます。
以下の管理 CLI コマンドを使用して、mod_cluster アドバタイズセキュリティーキーを設定します。
/profile=ha/subsystem=modcluster/proxy=default:write-attribute(name=advertise-security-key, value=mypassword)
mod_cluster ロードバランサーのセキュリティーキーを更新します。
以下の管理 CLI コマンドを使用して、mod_cluster フィルターのセキュリティーキーを設定します。
/profile=load-balancer/subsystem=undertow/configuration=filter/mod-cluster=load-balancer:write-attribute(name=security-key,value=mypassword)
mod_cluster によって使用される管理およびアドバタイズソケットバインディングが内部ネットワークのみで公開され、パブリック IP アドレスで公開されないことが推奨されます。
ロードバランサーである JBoss EAP サーバーが 2 つのバックエンドである JBoss EAP サーバーを負荷分散できるようになります。
複数の mod_cluster 設定
mod_cluster
サブシステムは名前の付いたプロキシー設定を複数サポートし、デフォルトでない undertow
サーバーをリバースプロキシーに登録できます。さらに、単一のアプリケーションサーバーノードを異なるグループのプロキシーサーバーに登録することができます。
以下の例は、ajp-listener
、サーバー、および undertow
サーバーへのホストを追加します。また、アドバタイズのメカニズムを使用してホストを登録する新しい mod_cluster
設定も追加します。
/socket-binding-group=standard-sockets/socket-binding=ajp-other:add(port=8010) /subsystem=undertow/server=other-server:add /subsystem=undertow/server=other-server/ajp-listener=ajp-other:add(socket-binding=ajp-other) /subsystem=undertow/server=other-server/host=other-host:add(default-web-module=root-other.war) /subsystem=undertow/server=other-server/host=other-host /location=other:add(handler=welcome-content) /subsystem=undertow/server=other-server/host=other-host:write-attribute(name=alias,value=[localhost])) /socket-binding-group=standard-sockets/socket-binding=modcluster-other:add(multicast-address=224.0.1.106,multicast-port=23364) /subsystem=modcluster/proxy=other:add(advertise-socket=modcluster-other,balancer=other-balancer,connector=ajp-other) reload
24.4.2. ロードバランサーでのランク付けされたセッションアフィニティーの有効化
distributable-web
サブシステムで複数の順序付けされたルートを持つセッションアフィニティーを設定するには、ランク付けされたセッションアフィニティーをロードバランサーで有効にする必要があります。distributable-web
サブシステムと各種アフィニティオプションの詳細 は、JBoss EAP 『開発ガイド』 の「分散可能な Web セッション設定の distributable-web サブシステム 」を参照してください。
ノードルートを分離するデフォルトの区切り文字は .
です。別の値が必要な場合は、affinity
リソースの delimiter
属性を設定できます。
手順
ロードバランサーに対して、ランク付けされたセッションアフィニティを有効にします。
/subsystem=undertow/configuration=filter/mod-cluster=load-balancer/affinity=ranked:add
オプション:
affinity
リソースのdelimiter
属性を設定します。/subsystem=undertow/configuration=filter/mod-cluster=load-balancer/affinity=ranked:write-attribute(name=delimiter,value=':')
24.4.3. Undertow を静的ロードバランサーとして設定
Undertow の静的ロードバランサーを設定するには、undertow
サブシステムでプロキシーハンドラーを設定する必要があります。Undertow でプロキシーハンドラーを設定するには、静的ロードバランサーとして動作する JBoss EAP インスタンスで以下を行う必要があります。
- リバースプロキシーハンドラーを追加します。
- 各リモートホストのアウトバウンドソケットバインディングを定義します。
- 各リモートホストをリバースプロキシーハンドラーへ追加します。
- リバースプロキシーの場所を追加します。
以下の例は、JBoss EAP インスタンスを静的ロードバランサーとして設定する方法を示しています。JBoss EAP インスタンスは lb.example.com
にあり、2 つの追加サーバーである server1.example.com
と server2.example.com
との間で負荷分散を行います。ロードバランサーは /app
に逆プロキシーを行い、AJP プロトコルを使用します。
リバースプロキシーハンドラーを追加するには、以下を指定します。
/subsystem=undertow/configuration=handler/reverse-proxy=my-handler:add
各リモートホストのアウトバウンドソケットバインディングを定義するには、以下を指定します。
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-host1/:add(host=server1.example.com, port=8009) /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-host2/:add(host=server2.example.com, port=8009)
各リモートホストをリバースプロキシーハンドラーに追加するには、以下を指定します。
/subsystem=undertow/configuration=handler/reverse-proxy=my-handler/host=host1:add(outbound-socket-binding=remote-host1, scheme=ajp, instance-id=myroute1, path=/test) /subsystem=undertow/configuration=handler/reverse-proxy=my-handler/host=host2:add(outbound-socket-binding=remote-host2, scheme=ajp, instance-id=myroute2, path=/test)
リバースプロキシーの場所を追加するには、以下を指定します。
/subsystem=undertow/server=default-server/host=default-host/location=\/test:add(handler=my-handler)
lb.example.com:8080/app
にアクセスすると、server1.example.com
および server2.example.com
からプロキシーされた内容が表示されるようになります。
24.5. 外部 Web サーバーのプロキシーサーバーとしての使用
JBoss EAP は、外部 Web サーバーの設定に応じて、サポートされる HTTP、HTTPS、または AJP プロトコルを使用して外部 Web サーバーからリクエストを許可できます。
各 Web サーバーのサポートされる HTTP コネクターの詳細は、「HTTP コネクターの概要」を参照してください。使用する Web サーバーと HTTP コネクターを決定したら、適切なコネクターの設定情報の項を参照してください。
- Apache HTTP Server の場合は、「mod_cluster」、「mod_jk」、または「mod_proxy」の項を参照してください。
- Microsoft IIS の場合は、「ISAPI コネクター」の項を参照してください。
- Oracle iPlanet Web Server の場合は、「NSAPI コネクター」の項を参照してください。
HTTP コネクターのサポートされる構成に関する最新情報は、「JBoss EAP でサポートされる構成」を参照してください。
また、JBoss EAP が外部 Web サーバーからのリクエストを許可するよう設定されている必要があります。
24.5.1. HTTP コネクターの概要
JBoss EAP には、Apache HTTP Server、Microsoft IIS、Oracle iPlanet などの外部 Web サーバーや Undertow より構築された負荷分散およびクラスタリングメカニズムを使用する機能があります。JBoss EAP はコネクターを使用して Web サーバーと通信します。これらのコネクターは JBoss EAP の undertow
サブシステム内に設定されます。
Web サーバーには、HTTP リクエストが JBoss EAP ノードにルーティングされる方法を制御するソフトウェアモジュールが含まれています。これらのモジュールの挙動や設定方法はモジュールごとに異なります。モジュールは、複数の JBoss EAP ノード全体でワークロードを分散したり、障害発生時にワークロードを他のサーバーに移動したりするために設定されます。
JBoss EAP は複数のコネクターをサポートします。使用中の Web サーバーや必要な機能に応じてコネクターを選択します。以下の表を参照して、サポートされる構成と、JBoss EAP と互換性のある HTTP コネクターの機能を比較してください。
JBoss EAP 7 をマルチプラットフォームロードバランサーとして使用する場合は 「mod_cluster を使用して Undertow をロードバランサーとして設定」を参照してください。
HTTP コネクターのサポートされる構成に関する最新情報は、「JBoss EAP でサポートされる構成」を参照してください。
コネクター | Web Server | サポート対象オペレーティングシステム | サポート対象プロトコル |
---|---|---|---|
Red Hat JBoss Core Services の Apache HTTP Server、Red Hat JBoss Web Server の Apache HTTP Server、JBoss EAP (Undertow) | Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris | HTTP、HTTPS、AJP、WebSocket | |
Red Hat JBoss Core Services の Apache HTTP Server、Red Hat JBoss Web Server の Apache HTTP Server | Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris | AJP | |
Red Hat JBoss Core Services の Apache HTTP Server、Red Hat JBoss Web Server の Apache HTTP Server | Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris | HTTP、HTTPS、AJP | |
Microsoft IIS | Microsoft Windows Server | AJP | |
Oracle iPlanet Web Server | Oracle Solaris | AJP |
コネクター | スティッキーセッションのサポート | デプロイメント状態への適合 |
---|---|---|
○ | 可。アプリケーションのデプロイメントとアンデプロイメントを検出し、アプリケーションがそのサーバーにデプロイされたかどうかに基づいて、サーバーにクライアント要求を送信するかどうかを動的に決定します。 | |
○ | 不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。 | |
○ | 不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。 | |
○ | 不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。 | |
○ | 不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。 |
24.5.2. Apache HTTP Server
スタンドアロン Apache HTTP Server バンドルは、Red Hat JBoss Core Services の個別ダウンロードとして利用できるようになりました。これにより、インストールと設定が容易になり、更新の一貫性が保たれます。
24.5.2.1. Apache HTTP Server のインストール
Apache HTTP Server のインストールに関する詳細は、JBoss Core Services の『Apache HTTP Server Installation Guide』を参照してください。
24.5.3. 外部 Web サーバーからのリクエストの許可
JBoss EAP に AJP、HTTP、 HTTPS などの適切なプロトコルハンドラーが設定されていれば、プロキシーサーバーからのリクエストを許可するための特別な設定は必要ありません。
プロキシーサーバーが mod_jk、mod_proxy、ISAPI、または NSAPI を使用する場合、リクエストを JBoss EAP に送信し、JBoss EAP は応答を返信します。mod_cluster の場合、リクエストをどこにルーティングするかを判断できるようにするため、JBoss EAP が現在の負荷、アプリケーションライフサイクルイベント、ヘルス状態などの情報をプロキシーサーバーへ送信できるようネットワークを設定する必要もあります。mod_cluster プロキシーサーバーの設定に関する詳細は「mod_cluster HTTP コネクター」を参照してください。
JBoss EAP 設定の更新
以下の手順では、例で使用されているプロトコルやポートを実際に設定する必要があるプロトコルやポートに置き換えてください。
Undertow の
instance-id
属性を設定します。外部 Web サーバーは
instance-id
を使用してコネクター設定の JBoss EAP インスタンスを識別します。以下の管理 CLI コマンドを使用して、Undertow でinstance-id
属性を設定します。/subsystem=undertow:write-attribute(name=instance-id,value=node1)
上記の例では、外部 Web サーバーは現在の JBoss EAP インスタンスを
node1
として識別します。必要なリスナーを Undertow に追加します。
外部 Web サーバーが JBoss EAP に接続するには、Undertow にリスナーが必要です。各プロトコルにはソケットバインディングに関連する独自のリスナーが必要です。
注記プロトコルやポート設定によってはこの手順は必要でないことがあります。HTTP リスナーはデフォルトの JBoss EAP 設定すべてに設定されており、ha または full-ha プロファイルを使用している場合、AJP リスナーは設定されています。
デフォルトのサーバー設定を確認すると、必要なリスナーが設定済みであるかどうかを確認できます。
/subsystem=undertow/server=default-server:read-resource
リスナーを Undertow に追加するには、ソケットバインディングが必要です。ソケットバインディングは、サーバーまたはサーバーグループによって使用されるソケットバインディンググループに追加されます。以下の管理 CLI コマンドを使用すると
ajp
ソケットバインディングが追加され、ポート8009
とstandard-sockets
ソケットバインディンググループにバインドされます。/socket-binding-group=standard-sockets/socket-binding=ajp:add(port=8009)
以下の管理 CLI コマンドを使用すると
ajp
ソケットバインディングを使用してajp
リスナーが Undertow に追加されます。/subsystem=undertow/server=default-server/ajp-listener=ajp:add(socket-binding=ajp)
24.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 サブシステムの属性」を参照してください。
24.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 Server『HTTP Connectors and Load Balancing Guide』の「Configure Load Balancing Using Apache HTTP Server and mod_cluster」を参照してください。
24.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/proxy=default: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/proxy=default:list-add(name=proxies,value=proxy1) /profile=full-ha/subsystem=modcluster/proxy=default:list-add(name=proxies,value=proxy2)
Apache HTTP Server のバランサーがその存在をワーカーノードにアドバタイズしなくなり、UDP マルチキャストが使用されないようになります。
24.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:9990},security-realm="ManagementRealm")
これにより、host-slave.xml ファイルの XML が次のように変更されます。
<domain-controller> <remote host="DOMAIN_CONTROLLER_IP_ADDRESS" port="${jboss.domain.master.port:9990}" 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.sh
スクリプト出力 (抜粋)$ 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 EAP『 How 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 EAP『 How To Configure Server Security 』の「 Configuring the Slave Controllers to Use the Credential 」を参照してください。
ホストを設定し、認証情報ストアからパスワードを取得します。
秘密の値を認証情報ストアに保存した場合、以下のコマンドを使用してサーバーの秘密の値が認証情報ストアからの値になるよう設定できます。
/host=SLAVE_HOST_NAME/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(credential-reference={store=STORE_NAME,alias=ALIAS}
サーバーをリロードする必要があります。
--host
引数はスタンドアロンサーバーには適用されません。reload --host=HOST_NAME
詳細は、JBoss EAP『 How To Configure Server Security 』の「 Credential Store 」を参照してください。
ホストを設定し、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 サーバーまたはロードバランサーからのリクエストを許可できます。クラスターの各ノードは、デフォルトで自動検出を使用して他のノードを検出します。
24.6.4. mod_cluster の fail_on_status パラメーターの設定
fail_on_status
パラメーターは、クラスターのワーカーノードによって返されるとそのノードの失敗を意味する HTTP ステータスコードをリストします。ロードバランサーはその後のリクエストをクラスターの別のワーカーノードに送信します。失敗したワーカーノードは、ロードバランサーに STATUS
メッセージを送信するまで NOTOK
の状態になります。
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
24.6.5. クラスター間のトラフィックの移行
JBoss EAP を使用して新しいクラスターを作成した後、アップグレードプロセスの一部として以前のクラスターから新しいクラスターへトラフィックを移行できます。ここでは、停止時間やダウンライムを最小限に抑えてトラフィックを移行する方法について説明します。
- 新しいクラスターの設定。このクラスターを ClusterNEW と呼びます。
- 不要となった古いクラスターの設定。このクラスターを ClusterOLD と呼びます。
クラスターのアップグレードプロセス - ロードバランシンググループ
- 前提条件に従って、新しいクラスターを設定します。
ClusterNEW および ClusterOLD の両方で、設定オプション
sticky-session
をデフォルト設定のtrue
に設定してください。このオプションを有効にすると、クラスターのクラスターノードへの新しいリクエストはすべてそのクラスターノードに送信されます。/profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=sticky-session,value=true)
ClusterOLD のすべてのクラスターノードは ClusterOLD ロードバランシンググループのメンバーであることを仮定し、
load-balancing-group
をClusterOLD
に設定します。/profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=load-balancing-group,value=ClusterOLD)
「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)
コンテキストを無効にすると、バランサーがこのコンテキストで新しいセッションを作成しないよう指示します。
24.7. Apache mod_jk HTTP コネクター
Apache mod_jk は、互換性の維持を目的に提供される HTTP コネクターです。
JBoss EAP は Apache HTTP プロキシーサーバーからのワークロードを許可します。プロキシーサーバーは Web フロントエンドからのクライアントリクエストを許可し、ワークを参加する JBoss EAP サーバーへ渡します。スティッキーセッションが有効な場合、同じクライアントリクエストは常に同じ JBoss EAP サーバーに送信されます (同じサーバーが使用できない場合を除く)。
mod_jk は AJP 1.3 プロトコルを介して通信します。mod_cluster または mod_proxy には他のプロトコルを使用できます。詳細は「HTTP コネクターの概要」を参照してください。
mod_cluster は mod_jk よりも高度なロードバランサーで、推奨される HTTP コネクターです。mod_cluster は mod_jk のすべての機能と、それ以外の追加機能を提供します。JBoss EAP の mod_cluster HTTP コネクターとは違い、Apache mod_jk HTTP コネクターはサーバーまたはサーバーグループのデプロイメントの状態を認識せず、ワークの送信先に順応できません。
詳細は、Apache mod_jk ドキュメントを参照してください。
24.7.1. Apache HTTP Server での mod_jk の設定
JBoss Core Services Apache HTTP Server のインストール時または JBoss Web Server の使用時に mod_jk モジュールである mod_jk.so
はすでに含まれていますが、デフォルトではロードされません。
JBoss Web Server バージョン 3.1.0 より、Apache HTTP Server は配布されないようになりました。
以下の手順に従って、Apache HTTP Server の mod_jk をロードおよび設定します。この手順では、Apache HTTP Server の httpd/
ディレクトリーがカレントディレクトリーであることを前提としていますが、このディレクトリーはプラットフォームによって異なります。ご使用のプラットフォームに対応するインストール手順は、JBoss Core Services の『Apache HTTP Server Installation Guide』を参照してください。
Red Hat のお客様は Red Hat カスタマーポータルにある Load Balancer Configuration Tool を使用して mod_jk やその他のコネクターに最適な設定テンプレートを迅速に生成することもできます。このツールを使用するにはログインする必要があります。
mod_jk モジュールを設定します。
注記mod_jk 設定ファイルの例は
conf.d/mod_jk.conf.sample
にあります。独自のファイルを作成せずにこのファイルを使用するには、.sample
拡張子を削除し、必要に応じて内容を変更します。conf.d/mod_jk.conf
という新しいファイルを作成します。以下の設定をファイルに追加し、必要に応じて内容を変更します。# 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.d/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 Require ip 127.0.0.1 </Location>
注記JkMount ディレクティブは、Apache HTTP Server が mod_jk モジュールに転送する必要がある URL を指定します。ディレクティブの設定に基づき、mod_jk は受信した URL を適切なワーカーに送信します。直接静的コンテンツに対応し、Java アプリケーションのロードバランサーのみを使用するには、URL パスは
/application/*
である必要があります。mod_jk をロードバランサーとして使用するには、値/*
を使用してすべての URL を mod_jk に転送します。一般的な mod_jk の設定の他に、このファイルは
mod_jk.so
モジュールをロードするよう指定し、workers.properties
ファイルの場所を定義します。mod_jk ワーカーノードを設定します。
注記ワーカー設定ファイルの例は
conf.d/workers.properties.sample
にあります。独自のファイルを作成せずにこのファイルを使用するには、.sample
拡張子を削除し、必要に応じて内容を変更します。conf.d/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
mod_jk
workers.properties
ファイルの構文の詳細およびその他の高度な設定オプションの詳細は、「mod_jk ワーカープロパティー」を参照してください。任意で JKMountFile ディレクティブを指定します。
mod-jk.conf
の JKMount ディレクティブの他に、mod_jk に転送される複数の URL パターンが含まれるファイルを指定できます。uriworkermap.properties
ファイルを作成します。注記URI ワーカーマップ設定ファイルの例は
conf.d/uriworkermap.properties.sample
にあります。独自のファイルを作成せずにこのファイルを使用するには、.sample
拡張子を削除し、必要に応じて内容を変更します。conf.d/uriworkermap.properties
という新しいファイルを作成します。以下の例のように、一致する各 URL パターンの行を追加します。# Simple worker configuration file /*=loadbalancer
uriworkermap.properties
ファイルを示すよう、設定を更新します。conf.d/mod_jk.conf
の最後に以下を追加します。# 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.d/uriworkermap.properties
mod_jk の設定に関する詳細は、 JBoss Web Server『HTTP Connectors and Load Balancing Guide』の「Configuring Apache HTTP Server to Load mod_jk」を参照してください。
24.7.2. JBoss EAP が mod_jk と通信するよう設定
JBoss EAP の undertow
サブシステムは、外部 Web サーバーからのリクエストを許可し、外部 Web サーバーへ返答を返送するために、リスナーを指定する必要があります。mod_jk は AJP プロトコルを使用するため、AJP リスナーを設定する必要があります。
デフォルトの高可用性設定の 1 つ (ha または full-ha) を使用している場合は、AJP リスナーはすでに設定されています。
手順は「外部 Web サーバーからのリクエストの許可」を参照してください。
24.8. Apache mod_proxy HTTP コネクター
Apache mod_proxy は、AJP、HTTP、および HTTPS プロトコルを介して接続をサポートする HTTP コネクターです。 mod_proxy は負荷分散された設定と負荷分散されていない設定が可能で、スティッキーセッションをサポートします。
mod_proxy モジュールを使用するには、使用するプロトコルに応じて JBoss EAP の undertow
サブシステムに HTTP、HTTPS または AJP リスナーを設定する必要があります。
mod_cluster は mod_proxy よりも高度なロードバランサーで、推奨される HTTP コネクターです。mod_cluster は mod_proxy のすべての機能と、それ以外の追加機能を提供します。JBoss EAP の mod_cluster HTTP コネクターとは違い、Apache mod_proxy HTTP コネクターはサーバーまたはサーバーグループのデプロイメントの状態を認識せず、ワークの送信先に順応できません。
詳細は Apache mod_proxy ドキュメント を参照してください。
24.8.1. Apache HTTP Server での mod_proxy の設定
JBoss Core Services Apache HTTP Server をインストールする場合や JBoss Web Server を使用する場合、mod_proxy モジュールはすでに含まれており、デフォルトでロードされます。
JBoss Web Server バージョン 3.1.0 より、Apache HTTP Server は配布されないようになりました。
基本の ロードバランシング または 非ロードバランシング プロキシーを設定するには、以下のセクションを参照してください。この手順では、Apache HTTP Server の httpd/
ディレクトリーがカレントディレクトリーであることを前提としていますが、このディレクトリーはプラットフォームによって異なります。ご使用のプラットフォームに対応するインストール手順は、JBoss Core Services の『Apache HTTP Server Installation Guide』を参照してください。また、この手順は JBoss EAP の undertow
サブシステムに必要な HTTP リスナーが設定されていることを前提としています。
Red Hat のお客様は Red Hat カスタマーポータルにある Load Balancer Configuration Tool を使用して mod_proxy やその他のコネクターに最適な設定テンプレートを迅速に生成することもできます。このツールを使用するにはログインする必要があります。
非ロードバランシングプロキシーの追加
以下の設定を、他の <VirtualHost>
ディレクティブの直下にある conf/httpd.conf
ファイルに追加します。値を設定に適切な値に置き換えます。
<VirtualHost *:80>
# Your domain name
ServerName YOUR_DOMAIN_NAME
ProxyPreserveHost On
# The IP and port of JBoss
# These represent the default values, if your httpd is on the same host
# as your JBoss managed domain or server
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
# The location of the HTML files, and access control information
DocumentRoot /var/www
<Directory /var/www>
Options -Indexes
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
ロードバランシングプロキシーの追加
デフォルトの Apache HTTP Server は mod_cluster との互換性がないため、mod_proxy_balancer.so
モジュールが無効になっています。この作業を行うには、このモジュールをロードし、mod_cluster を無効にする必要があります。
mod_proxy をロードバランサーとして使用し、ワークを複数の JBoss EAP インスタンスに送信するには、以下の設定を conf/httpd.conf
ファイルに追加する必要があります。IP アドレスの例は以下のようになります。ご使用の環境に適切な値に置き換えてください。
<Proxy balancer://mycluster>
Order deny,allow
Allow from all
# Add each JBoss Enterprise Application Server by IP address and port.
# If the route values are unique like this, one node will not fail over to the other.
BalancerMember http://192.168.1.1:8080 route=node1
BalancerMember http://192.168.1.2:8180 route=node2
</Proxy>
<VirtualHost *:80>
# Your domain name
ServerName YOUR_DOMAIN_NAME
ProxyPreserveHost On
ProxyPass / balancer://mycluster/
# The location of the HTML files, and access control information DocumentRoot /var/www
<Directory /var/www>
Options -Indexes
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
上記の例はすべて HTTP プロトコルを使用して通信します。適切な mod_proxy モジュールをロードすれば AJP または HTTPS プロトコルを使用することもできます。詳細は Apache mod_proxy ドキュメントを参照してください。
スティッキーセッションの有効化
スティッキーセッション を使用すると、クライアントリクエストが特定の JBoss EAP ワーカーに送信された場合に、ワーカーが利用不可能にならない限り、後続のリクエストがすべて同じワーカーに送信されます。これは、ほとんどの場合で推奨される動作です。
mod_proxy のスティッキーセッションを有効にするには、stickysession
パラメーターを ProxyPass
ステートメントに追加します。
ProxyPass / balancer://mycluster stickysession=JSESSIONID
追加のパラメーターを lbmethod
や nofailover
などの ProxyPass
ステートメントに指定できます。使用可能なパラメーターの詳細は、Apache mod_proxy ドキュメントを参照してください。
24.8.2. JBoss EAP が mod_proxy と通信するよう設定
JBoss EAP の undertow
サブシステムは、外部 Web サーバーからのリクエストを許可し、外部 Web サーバーへ返答を返送するために、リスナーを指定する必要があります。使用するプロトコルによっては、リスナーを設定する必要があることがあります。
HTTP リスナーは JBoss EAP のデフォルト設定に設定されます。デフォルトの高可用性設定である ha または full-ha のいずれかを使用している場合は、AJP リスナーも事前設定されています。
手順は「外部 Web サーバーからのリクエストの許可」を参照してください。
24.9. Microsoft ISAPI コネクター
Internet Server API (ISAPI) は、Microsoft のインターネット情報サービス(IIS)などの Web サーバー用の Digital Server 拡張やフィルターを書き込むために使用される API のセットです。ISAPI_redirect.dll
は IIS 向けに調整された mod_jk の拡張機能です。ISAPI_redirect.dll
を使用すると、JBoss EAP インスタンスをワーカーノードとしてロードバランサーとして設定できます。
Windows Server および IIS のサポートされる構成については、「JBoss Enterprise Application Platform (EAP) 7 でサポートされる構成」を参照してください。
24.9.1. Microsoft IIS が ISAPI コネクターを使用するよう設定
Red Hat カスタマーポータルから ISAPI コネクターをダウンロードします。
- ブラウザーを開き、Red Hat カスタマーポータルで JBoss の Software Downloads ページにログインします。
- Product ドロップダウンメニューから Web Connectors を選択します。
- Version ドロップダウンメニューで最新バージョンの JBoss Core Services を選択します。
- リストで Red Hat JBoss Core Services ISAPI Connector を見つけ、Download リンクをクリックします。
-
アーカイブを抽出し、
sbin
ディレクトリーの内容をサーバーの場所にコピーします。以下の手順は、内容がC:\connectors\
にコピーされたことを前提としています。
IIS マネージャー (IIS 7) を使用して IIS リディレクターを設定するには、以下を行います。
-
Start
Runとクリックして IIS マネージャーを開き、 inetmgr
と入力します。 - 左側のツリービューペインで IIS 7 を展開します。
- ISAPI and CGI Registrations をダブルクリックし、新しいウインドウで開きます。
- Actions ペインで Add をクリックします。Add ISAPI or CGI Restriction ウインドウが開きます。
以下の値を指定します。
-
ISAPI or CGI Path:
C:\connectors\isapi_redirect.dll
-
Description:
jboss
- Allow extension path to execute: チェックボックスを選択します。
-
ISAPI or CGI Path:
- OK をクリックして Add ISAPI or CGI Restriction ウインドウを閉じます。
JBoss ネイティブ仮想ディレクトリーの定義
- Default Web Site を右クリックし、Add Virtual Directory をクリックします。Add Virtual Directory ウインドウが開きます。
以下の値を指定して仮想ディレクトリーを追加します。
-
Alias:
jboss
-
Physical Path:
C:\connectors\
-
Alias:
- OK をクリックして値を保存し、Add Virtual Directory ウインドウを閉じます。
JBoss ネイティブ ISAPI リダイレクトフィルターの定義
-
ツリービューペインで Sites
Default Web Site と展開します。 - ISAPI Filters をダブルクリックします。ISAPI Filters Features ビューが表示されます。
- Actions ペインで Add をクリックします。Add ISAPI Filter ウインドウが表示されます。
以下の値を Add ISAPI Filter ウインドウに指定します。
-
Filter name:
jboss
-
Executable:
C:\connectors\isapi_redirect.dll
-
Filter name:
- OK をクリックして値を保存し、Add ISAPI Filter ウインドウを閉じます。
-
ツリービューペインで Sites
ISAPI-dll ハンドラーの有効化
- ツリービューペインの IIS 7 をダブルクリックします。IIS 7 Home Features View が開きます。
- Handler Mappings をダブルクリックします。Handler Mappings Features View が表示されます。
- Group by コンボボックスで State を選択します。Handler Mappings が Enabled and Disabled Groups に表示されます。
-
ISAPI-dll
を見つけます。Disabled グループにある場合は右クリックし、Edit Feature Permissions を選択します。 以下のパーミッションを有効にします。
- Read
- Script
- Execute
- OK をクリックして値を保存し、Edit Feature Permissions ウインドウを閉じます。
これで、ISAPI コネクターを使用するよう Microsoft IIS が設定されます。
24.9.2. ISAPI コネクターがクライアントリクエストを JBoss EAP に送信するよう設定
このタスクでは、JBoss EAP サーバーのグループが ISAPI コネクターからのリクエストを受け入れるよう設定します。ロードバランシングまたは高可用性フェイルオーバーの設定は含まれません。
この設定は IIS サーバーで行われ、外部 Web サーバーからのリクエストを許可するよう JBoss EAP が設定されていることを前提としています。また、IIS への完全な管理者アクセスが必要で、IIS が ISAPI コネクターを使用するよう設定されている必要があります。
プロパティーファイルの作成およびリダイレクトの設定
ログ、プロパティーファイル、およびロックファイルを格納するディレクトリーを作成します。
以下の手順では、ディレクトリー
C:\connectors\
の使用を前提としています。異なるディレクトリーを使用する場合は、適切に手順を変更してください。isapi_redirect.properties
ファイルを作成します。C:\connectors\isapi_redirect.properties
という新しいファイルを作成します。このファイルに次の内容をコピーします。# Configuration file for the ISAPI Connector # Extension uri definition extension_uri=/jboss/isapi_redirect.dll # Full path to the log file for the ISAPI Connector log_file=c:\connectors\isapi_redirect.log # Log level (debug, info, warn, error or trace) log_level=info # 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
ファイルを使用しない場合は、行の先頭に#
文字を記入して最後の行をコメントアウトします。uriworkermap.properties
ファイルの作成uriworkermap.properties
ファイルには、デプロイされたアプリケーション URL と、それらへの要求を処理するワーカー間のマッピングが含まれます。以下のサンプルファイルはファイルの構文を示しています。uriworkermap.properties
ファイルをC:\connectors\
に格納します。# 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
ファイルを作成します。workers.properties
ファイルには、ワーカーラベルとサーバーインスタンス間のマッピング定義が含まれます。このファイルは、 Apache mod_jk ワーカープロパティー 設定で使用される同じファイルの構文を使用します。以下は
workers.properties
ファイルの例になります。ワーカー名、worker01
、およびworker02
は、JBoss EAP の undertow サブシステムで設定
されたinstance-id
に一致する必要があります。このファイルを
C:\connectors\
ディレクトリーに格納してください。# An entry that lists all the workers defined worker.list=worker01, worker02 # Entries that define the host and port associated with these workers # First JBoss 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 JBoss EAP server definition worker.worker02.host=127.0.0.100 worker.worker02.port=8009 worker.worker02.type=ajp13
rewrite.properties
ファイルを作成します。rewrite.properties
ファイルには、特定のアプリケーションの単純な URL 書き換えルールが含まれます。以下の例で示されているように、書き換えられたパスは名前と値のペアを使用して指定されます。このファイルをC:\connectors\
ディレクトリーに格納してください。#Simple example # Images are accessible under abc path /app-01/abc/=/app-01/images/
net stop
およびnet start
コマンドを使用して IIS サーバーを再起動します。C:\> net stop was /Y C:\> net start w3svc
アプリケーションごとに、設定した特定の JBoss EAP サーバーにクライアントリクエストを送信するよう IIS サーバーが設定されます。
24.9.3. ISAPI コネクターがクライアントリクエストを複数の JBoss EAP サーバーで分散するよう設定
この設定は、指定する JBoss EAP サーバー全体でクライアントリクエストを分散します。この設定は IIS サーバーで行われ、外部 Web サーバーからのリクエストを許可するよう JBoss EAP が設定されていることを前提としています。また、IIS への完全な管理者アクセスが必要で、IIS が ISAPI コネクターを使用するよう設定されている必要があります。
複数のサーバー間でのクライアント要求の分散
ログ、プロパティーファイル、およびロックファイルを格納するディレクトリーを作成します。
以下の手順では、ディレクトリー
C:\connectors\
の使用を前提としています。異なるディレクトリーを使用する場合は、適切に手順を変更してください。isapi_redirect.properties
ファイルを作成します。C:\connectors\isapi_redirect.properties
という新しいファイルを作成します。このファイルに次の内容をコピーします。# Configuration file for the ISAPI Connector # Extension uri definition extension_uri=/jboss/isapi_redirect.dll # Full path to the log file for the ISAPI Connector log_file=c:\connectors\isapi_redirect.log # Log level (debug, info, warn, error or trace) log_level=info # 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
ファイルを使用しない場合は、行の先頭に#
文字を記入して最後の行をコメントアウトします。uriworkermap.properties
ファイルを作成します。uriworkermap.properties
ファイルには、デプロイされたアプリケーション URL と、それらへの要求を処理するワーカー間のマッピングが含まれます。以下のサンプルファイルは負荷分散が設定されたファイルの構文を示しています。ワイルドカード (*
) はさまざまな URL サブディレクトリーのすべてのリクエストを router という名前のロードバランサーに送信します。ロードバランサーの設定は次のステップで説明します。uriworkermap.properties
ファイルをC:\connectors\
に格納します。# images, css files, path /status and /web-console will be # provided by nodes defined in the load-balancer called "router" /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 the load-balancer called "router" /app-01|/*=router /app-02|/*=router # mapping for management console, nodes in cluster can be enabled or disabled here /jkmanager|/*=status
workers.properties
ファイルを作成します。workers.properties
ファイルには、ワーカーラベルとサーバーインスタンス間のマッピング定義が含まれます。このファイルは、 Apache mod_jk ワーカープロパティー 設定で使用される同じファイルの構文を使用します。以下は
workers.properties
ファイルの例になります。ロードバランサーはファイルの末尾付近に設定され、ワーカーworker01
およびworker02
で構成されます。これらのワーカーは、JBoss EAP の undertow サブシステムで設定
されたinstance-id
に一致する必要があります。このファイルを
C:\connectors\
ディレクトリーに格納してください。# 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
rewrite.properties
ファイルを作成します。rewrite.properties
ファイルには、特定のアプリケーションの単純な URL 書き換えルールが含まれます。以下の例で示されているように、書き換えられたパスは名前と値のペアを使用して指定されます。このファイルをC:\connectors\
ディレクトリーに格納してください。#Simple example # Images are accessible under abc path /app-01/abc/=/app-01/images/ Restart the IIS server. Restart your IIS server by using the net stop and net start commands. C:\> net stop was /Y C:\> net start w3svc
IIS サーバーは、workers.properties
ファイルで参照された JBoss EAP サーバーにクライアントリクエストを送信し、サーバー間で負荷を 1:3
の比率で分散するよう設定されます。この比率は、各サーバーに割り当てられた負荷分散係数 lbfactor
から派生します。
24.10. Oracle NSAPI コネクター
Netscape Server API (NSAPI) は、拡張機能をサーバーに実装するために Oracle iPlanet Web Server (旧名 Netscape Web Server) によって提供される API です。これらの拡張機能はサーバープラグインと呼ばれます。NSAPI コネクターは、Oracle iPlanet Web Server 向けに調整された mod_jk の拡張機能である nsapi_redirector.so
で使用されます。NSAPI コネクターを使用すると、JBoss EAP インスタンスをワーカーノード、Oracle iPlanet Web Server をロードバランサーとして設定できます。
Solaris および Oracle iPlanet Web Server のサポートされる構成については、「JBoss Enterprise Application Platform (EAP) 7 でサポートされる構成」を参照してください。
24.10.1. iPlanet Web Server が NSAPI コネクターを使用するよう設定
要件
- ワーカーとして動作する各サーバーに JBoss EAP がインストールおよび設定されます。
Red Hat カスタマーポータルから NSAPI コネクターをダウンロードします。
- ブラウザーを開き、Red Hat カスタマーポータルで JBoss の Software Downloads ページにログインします。
- Product ドロップダウンメニューから Web Connectors を選択します。
- Version ドロップダウンメニューで最新バージョンの JBoss Core Services を選択します。
- システムのプラットフォームとアーキテクチャーに対応する Red Hat JBoss Core Services NSAPI Connector を見つけ、Download リンクをクリックします。
-
lib/
またはlib64/
ディレクトリーにあるnsapi_redirector.so
ファイルを、IPLANET_CONFIG/lib/
またはIPLANET_CONFIG/lib64/
ディレクトリーに展開します。
NSAPI コネクターを設定します。
これらの手順では、IPLANET_CONFIG
は Oracle iPlanet の設定ディレクトリーを意味します (通常 /opt/oracle/webserver7/config/
になります)。Oracle iPlanet 設定ディレクトリーが異なる場合は、適切に手順を変更してください。
サーブレットマッピングを無効にします。
IPLANET_CONFIG/default.web.xml
ファイルを開き、Built In Server Mappings という見出しのセクションを見つけます。次の 3 つのサーブレットを XML コメント文字 (<!--
および-->
) で囲み、これらのサーブレットへのマッピングを無効にします。- 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-->
ファイルを保存し、終了します。
iPlanet Web Server が NSAPI コネクターモジュールをロードするよう設定します。
IPLANET_CONFIG/magnus.conf
ファイルの最後に次の行を追加し、設定に合わせてファイルパスを変更します。これらの行は、nsapi_redirector.so
モジュールと、ワーカーおよびそのプロパティーがリストされたworkers.properties
ファイルの場所を定義します。Init fn="load-modules" funcs="jk_init,jk_service" shlib="/lib/nsapi_redirector.so" shlib_flags="(global|now)" Init fn="jk_init" worker_file="IPLANET_CONFIG/connectors/workers.properties" log_level="info" log_file="IPLANET_CONFIG/connectors/nsapi.log" shm_file="IPLANET_CONFIG/connectors/tmp/jk_shm"
上記の設定は 32 ビットアーキテクチャー向けです。64 ビット Solaris を使用している場合は、文字列
lib/nsapi_redirector.so
をlib64/nsapi_redirector.so
に変更します。ファイルを保存し、終了します。
NSAPI コネクターを設定します。
負荷分散のない基本設定または負荷分散設定向けに NSAPI コネクターを設定できます。以下のいずれかのオプションを選択します。 その後、設定が完了します。
24.10.2. NSAPI コネクターがクライアントリクエストを JBoss EAP に送信するよう設定
このタスクでは、NSAPI コネクターが負荷分散またはフェイルオーバーなしでクライアントリクエストを JBoss EAP サーバーにリダイレクトするよう設定します。リダイレクトは、デプロイメントごとに (つまり、URL ごとに) 行われます。
このタスクを続行するには、NSAPI コネクターが設定されている必要があります。
基本的な HTTP コネクターの設定
JBoss EAP サーバーにリダイレクトする URL パスを定義します。
注記IPLANET_CONFIG/obj.conf
では、前の行から継続する行以外は、行の最初にスペースを挿入しないでください。IPLANET_CONFIG/obj.conf
ファイルを編集します。<Object name="default"> で始まるセクションを見つけ、一致する各 URL パターンを次のサンプルファイルで示された形式で追加します。文字列 jknsapi は、次の手順で定義される HTTP コネクターを示します。例は、ワイルドカードを使用したパターン一致を示しています。<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>
各パスを提供するワーカーを定義します。
IPLANET_CONFIG/obj.conf
ファイルの編集を続行します。編集したセクションの終了タグのすぐ後に、</Object> を追加します。<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>
上記の例は、URL パス /status へのリクエストを worker01 という名前のワーカーにリダイレクトし、
/nc/
以下のすべての URL パスを worker02 という名前のワーカーにリダイレクトします。3 番目の行は、前の行で一致しない jknsapi オブジェクトに割り当てられたすべての URL が worker01 に提供されることを示しています。ファイルを保存し、終了します。
ワーカーとその属性を定義します。
IPLANET_CONFIG/connectors/
ディレクトリーに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
workers.properties
ファイルは Apache mod_jk と同じ構文を使用します。ファイルを保存し、終了します。
iPlanet Web Server の再起動
以下のコマンドを実行し、iPlanet Web Server を再起動します。
IPLANET_CONFIG/../bin/stopserv IPLANET_CONFIG/../bin/startserv
iPlanet Web Server が、JBoss EAP のデプロイメントに設定した URL へクライアントリクエストを送信します。
24.10.3. NSAPI コネクターがクライアントリクエストを複数の JBoss EAP サーバーで分散するよう設定
このタスクは、負荷分散の設定でクライアントリクエストを JBoss EAP サーバーに送信するよう NSAPI コネクターを設定します。
このタスクを続行するには、NSAPI コネクターが設定されている必要があります。
ロードバランシングのコネクターの設定
JBoss EAP サーバーにリダイレクトする URL パスを定義します。
注記IPLANET_CONFIG/obj.conf
では、前の行から継続する行以外は、行の最初にスペースを挿入しないでください。IPLANET_CONFIG/obj.conf
ファイルを編集します。<Object name="default">
で始まるセクションを見つけ、一致する各 URL パターンを次のサンプルファイルで示された形式で追加します。文字列jknsapi
は、次の手順で定義される HTTP コネクターを示します。例は、ワイルドカードを使用したパターン一致を示しています。<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>
各パスを提供するワーカーを定義します。
IPLANET_CONFIG/obj.conf
ファイルの編集を続行します。前の手順で変更したセクションの終了タグ (</Object>
) のすぐ後に、以下の新しいセクションを追加し、必要に応じて変更します。<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>
この
jksnapi
オブジェクトは、default
オブジェクトのname="jksnapi"
マッピングにマップされた各パスを提供するために使用されるワーカーノードを定義します。/jkmanager/*
に一致する URL 以外のすべてが、router
という名前のワーカーにリダイレクトされます。ワーカーとその属性を定義します。
workers.properties
という名前のファイルをIPLANET_CONFIG/connector/
で作成します。以下の内容をそのファイルに貼り付けし、お使いの環境に合わせて変更します。# The advanced router LB worker # A list of each worker worker.list=router,status # First JBoss EAP server # (worker node) definition. # Port 8009 is the standard port for AJP # 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 JBoss EAP server 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 load-balancer called "router" worker.router.type=lb worker.router.balance_workers=worker01,worker02 # Define the status worker worker.status.type=status
workers.properties
ファイルは Apache mod_jk と同じ構文を使用します。ファイルを保存し、終了します。
iPlanet Web Server 7.0 を再起動します。
IPLANET_CONFIG/../bin/stopserv IPLANET_CONFIG/../bin/startserv
iPlanet Web Server は、設定した URL パターンを負荷分散設定の JBoss EAP サーバーにリダイレクトします。