Red Hat Training
A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform
第6章 Web アプリケーションのクラスター化
6.1. セッションレプリケーション
6.1.1. HTTP セッションレプリケーション
セッションレプリケーションは、配布可能なアプリケーションのクライアントセッションが、クラスター内のノードのフェイルオーバーによって中断されないようにします。クラスター内の各ノードは実行中のセッションの情報を共有するため、ノードが消滅してもセッションを引き継くことができます。
セッションレプリケーションは、mod_cluster、mod_jk、mod_proxy、ISAPI、および NSAPI クラスターにより高可用性を確保する仕組みのことです。
6.1.2. アプリケーションにおけるセッションレプリケーションの有効化
JBoss EAP の高可用性 (HA) 機能を利用し、Web アプリケーションのクラスタリングを有効にするには、アプリケーションが配布可能になるよう設定する必要があります。アプリケーションが配布可能でないと、そのセッションは配布されません。
アプリケーションを配布可能にする
アプリケーションの
web.xml
記述子ファイルの<web-app>
タグ内に<distributable/>
要素を追加します。例: 配布可能なアプリケーションの最低限の設定
<?xml version="1.0"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_3_0.xsd" version="3.0"> <distributable/> </web-app>
次に、必要な場合はデフォルトのレプリケーションの動作を変更します。セッションレプリケーションに影響する値を変更する場合は、アプリケーションの
WEB-INF/jboss-web.xml
ファイルにある<jboss-web>
内の<replication-config>
要素内でこれらの値をオーバーライドできます。該当する要素で、デフォルト値をオーバーライドする場合のみ値を含めます。例:
<replication-config>
の値<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"> <replication-config> <replication-granularity>SESSION</replication-granularity> </replication-config> </jboss-web>
<replication-granularity>
パラメーターは、レプリケートされるデータの粒度を決定します。デフォルト値は SESSION
ですが、ATTRIBUTE
を設定すると、ほとんどの属性は変更されずにセッションのパフォーマンスを向上させることができます。
<replication-granularity>
の有効値は以下のとおりです。
-
SESSION
: デフォルト値です。属性がダーティーである場合に、セッションオブジェクト全体がレプリケートされます。このポリシーは、オブジェクト参照が複数のセッション属性で共有される 場合に必要です。共有されるオブジェクト参照は、1 つのユニットでセッション全体がシリアライズされるため、リモートノードで維持されます。 -
ATTRIBUTE
: これは、セッションのダーティーな属性と一部のセッションデータ (最後にアクセスされたタイムスタンプなど) にのみに使用できる値です。
変更不能なセッション属性
JBoss EAP 7 の場合、セッションレプリケーションはセッションが変更された場合、またはセッションの変更可能な属性がアクセスされた場合にトリガーされます。以下のいずれかの条件に該当しない限り、セッション属性は変更可能であると見なされます。
値が既知の変更不能な値である:
-
null
-
java.util.Collections.EMPTY_LIST
、EMPTY_MAP
、EMPTY_SET
-
値の型がまたは既知の変更不能な型である、または既知の変更不能な型を実装する:
-
java.lang.Boolean
、Character
、Byte
、Short
、Integer
、Long
、Float
、Double
-
java.lang.Class
、Enum
、StackTraceElement
、String
-
java.io.File
、java.nio.file.Path
-
java.math.BigDecimal
、BigInteger
、MathContext
-
java.net.Inet4Address
、Inet6Address
、InetSocketAddress
、URI
、URL
-
java.security.Permission
-
java.util.Currency
、Locale
、TimeZone
、UUID
-
java.time.Clock
、Duration
、Instant
、LocalDate
、LocalDateTime
、LocalTime
、MonthDay
、Period
、Year
、YearMonth
、ZoneId
、ZoneOffset
、ZonedDateTime
-
java.time.chrono.ChronoLocalDate
、Chronology
、Era
-
java.time.format.DateTimeFormatter
、DecimalStyle
-
java.time.temporal.TemporalField
、TemporalUnit
、ValueRange
、WeekFields
-
java.time.zone.ZoneOffsetTransition
、ZoneOffsetTransitionRule
、ZoneRules
-
値の型に以下のアノテーションが付けられる:
-
@org.wildfly.clustering.web.annotation.Immutable
-
@net.jcip.annotations.Immutable
-
6.2. HTTP セッションパッシベーションおよびアクティベーション
6.2.1. HTTP セッションパッシベーションおよびアクティベーション
パッシベーションとは、比較的利用されていないセッションをメモリーから削除し、永続ストレージへ保存することでメモリーの使用量を制御するプロセスのことです。
アクティベーションとは、パッシベートされたデータを永続ストレージから取得し、メモリーに戻すことです。
パッシベーションは HTTP セッションのライフタイムの異なるタイミングで実行されます。
- コンテナーが新規セッションの作成を要求するときに現在アクティブなセッションの数が設定上限を超えている場合、サーバーはセッションの一部をパッシベートして新規セッションのスペースを作成しようとします。
- Web アプリケーションがデプロイされ、他のサーバーでアクティブなセッションのバックアップコピーが、新たにデプロイされる Web アプリケーションのセッションマネージャーによって取得された場合、セッションはパッシベートされることがあります。
アクティブなセッションが設定可能な最大数を超えると、セッションはパッシベートされます。
セッションは常に LRU (Least Recently Used) アルゴリズムを使ってパッシベートされます。
6.2.2. アプリケーションでの HTTP セッションパッシベーションの設定
HTTP セッションパッシベーションは、アプリケーションの WEB-INF/jboss-web.xml
および META-INF/jboss-web.xml
ファイルで設定されます。
例: jboss-web.xml
ファイル
<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"> <max-active-sessions>20</max-active-sessions> </jboss-web>
<max-active-sessions>
要素により、許可されるアクティブなセッションの最大数が設定され、セッションパッシベーションが有効になります。セッションの作成によって、アクティブなセッションの数が <max-active-sessions>
を超える場合は、新しいセッションのスペースを確保するために、セッションマネージャーが認識する最も古いセッションがパッシベートされます。
メモリーのセッションの合計数には、このノードでアクセスされていない他のクラスターノードからレプリケートされたセッションが含まれます。これを考慮して <max-active-sessions>
を設定してください。また、他のノードからレプリケートされるセッションの数は、REPL
または DIST
キャッシュモードが有効であるかどうかによっても異なります。REPL
キャッシュモードでは、各セッションは各ノードにレプリケートされます。DIST
キャッシュモードでは、各セッションは、owners
パラメーターによって指定された数のノードにのみレプリケートされます。セッションキャッシュモードの設定については、JBoss EAP『設定ガイド』の「キャッシュモードの設定」を参照してください。たとえば、各ノードが 100 ユーザーからの要求を処理する 8 つのノードクラスターがあるとします。この場合、REPL
キャッシュモードでは、各ノードのメモリーに 800 のセッションが格納されます。DIST
キャッシュモードが有効であり、デフォルトの owners
設定が 2
であるときは、各ノードのメモリーには 200 のセッションが格納されます。
6.3. クラスタリングサービスのパブリック API
JBoss EAP 7 には、アプリケーションが使用する改善されたパブリッククラスタリング API が導入されました。新しいサービスは、ライトウェイトで簡単に挿入できるよう設計されています。外部の依存関係は必要ありません。
org.wildfly.clustering.group.Group
グループサービスは、JGroups チャネルのクラスタートポロジーを参照し、トポロジーの変更時に通知するメカニズムを提供します。
@Resource(lookup = "java:jboss/clustering/group/channel-name") private Group channelGroup;
org.wildfly.clustering.dispatcher.CommandDispatcher
CommandDispatcherFactory
サービスは、クラスター内のノードでコマンドを実行するためにディスパッチャーを作成するメカニズムを提供します。結果として得られるCommandDispatcher
は、以前の JBoss EAP リリースのリフレクションベースのGroupRpcDispatcher
に類似したコマンドパターンです。@Resource(lookup = "java:jboss/clustering/dispatcher/channel-name") private CommandDispatcherFactory factory; public void foo() { String context = "Hello world!"; try (CommandDispatcher<String> dispatcher = this.factory.createCommandDispatcher(context)) { dispatcher.executeOnCluster(new StdOutCommand()); } } public static class StdOutCommand implements Command<Void, String> { @Override public Void execute(String context) { System.out.println(context); return null; } }
6.4. HA シングルトンサービス
クラスター化されたシングルトンサービス (高可用性 (HA) シングルトンとも呼ばれます) は、クラスターの複数のノードにデプロイされるサービスです。このサービスはいずれかのノードでのみ提供されます。シングルトンサービスが実行されているノードは、通常マスターノードと呼ばれます。
マスターノードが失敗またはシャットダウンした場合に、残りのノードから別のマスターが選択され、新しいマスターでサービスが再開されます。マスターが停止し、別のマスターが引き継ぐまでの短い間を除き、サービスは 1 つのノードのみによって提供されます。
HA シングルトン ServiceBuilder API
JBoss EAP 7 では、プロセスを大幅に簡略化するシングルトンサービスを構築するための新しいパブリック API が導入されます。
SingletonServiceBuilder
実装により、サービスは非同期的に開始されるようインストールされ、Modular Service Container (MSC) のデッドロックが回避されます。
HA シングルトンサービス選択ポリシー
HA シングルトンを起動するノードの優先順位がある場合は、ServiceActivator
クラスで選択ポリシーを設定できます。
JBoss EAP は、以下の 2 つの選択ポリシーを提供します。
単純な選択ポリシー
単純な選択ポリシーでは、相対的な経過時間に基づいてマスターノードが選択されます。必要な経過時間は、利用可能なノードのリストのインデックスである position プロパティーで、以下のように設定されます。
- position = 0 最も古いノードを参照します。これはデフォルトです。
- position = 1 2 番目に古いノードを参照します。
position を負の値にして最も新しいノードを示すこともできます。
- position = -1 最も新しいノードを参照します。
- position = -2 2 番目に新しいノードを参照します。
ランダムな選択ポリシー
ランダムな選択ポリシーでは、シングルトンサービスのプロバイダーとなるランダムなメンバーが選択されます。
HA シングルトンサービスの優先度
HA シングルトンサービスの選択ポリシーは、任意で 1 つ以上の優先されるサーバーを指定することができます。優先されるサーバーが利用できる場合は、そのポリシーにおけるすべてのシングルトンアプリケーションでそのサーバーがマスターになります。
優先度は、ノード名またはアウトバウンドソケットバインディング名を介して定義することができます。
ノードの優先度は常に選択ポリシーの結果よりも優先されます。
デフォルトでは、JBoss EAP の高可用性設定によって、優先されるサーバーがない default
という名前の簡単な選択ポリシーが提供されます。優先度を設定するには、カスタムポリシーを作成し、優先されるサーバーを定義します。
クォーラム
ネットワークパーティションがある場合、シングルトンサービスに潜在的な問題が存在します。この問題はスプリットブレインと呼ばれ、ノードの各サブセットは他のサブセットと通信できません。サーバーの各セットは他のセットのすべてのサーバーに障害が発生したと見なし、唯一障害が発生していないクラスターとして動作します。これによってデータの整合性に問題が発生する可能性があります。
JBoss EAP では、選択ポリシーでクォーラムを指定してスプリットブレインを防ぐことができます。クォーラムは、シングルトンプロバイダーの選択が行われる前に存在するノードの最小数を指定します。
典型的なデプロイメントでは、N/2 + 1 をクォーラムとして使用します。N は予想されるクラスターサイズになります。この値は実行時に更新でき、アクティブなすべてのシングルトンサービスに即時反映されます。
HA シングルトンサービスアプリケーションの作成
以下に、アプリケーションを作成し、クラスター全体のシングルトンサービスとしてデプロイするのに必要な手順の簡単な例を示します。この例では、頻繁にシングルトンサービスをクエリーし、そのシングルトンサービスが実行されているノードの名前を取得します。
シングルトンの挙動を確認するには、最低でも 2 つのサーバーにアプリケーションをデプロイする必要があります。シングルトンサービスが同じノードで実行されているかまたは値がリモートで取得されているかは透過的です。
SingletonService
クラスを作成します。クエリーサービスによって呼び出されるgetValue()
メソッドは、実行されているノードに関する情報を提供します。class SingletonService implements Service<Node> { private Logger LOG = Logger.getLogger(this.getClass()); private InjectedValue<Group> group; SingletonService(InjectedValue<Group> group) { this.group = group; } @Override public void start(StartContext context) throws StartException { LOG.infof("Singleton service is starting on node '%s'.", this.group.getValue().getLocalNode()); } @Override public void stop(StopContext context) { LOG.infof("Singleton service is stopping on node '%s'.", this.group.getValue().getLocalNode()); } @Override public Node getValue() throws IllegalStateException, IllegalArgumentException { return this.group.getValue().getLocalNode(); } }
クエリーサービスを作成します。シングルトンサービスの
getValue()
メソッドを呼び出し、それが稼働しているノードの名前を取得して、サーバーログに結果を書き込みます。class QueryingService implements Service<Void> { private Logger LOG = Logger.getLogger(this.getClass()); private ScheduledExecutorService executor; @Override public void start(StartContext context) throws StartException { LOG.info("Querying service is starting."); executor = Executors.newSingleThreadScheduledExecutor(); executor.scheduleAtFixedRate(() -> { @SuppressWarnings("unchecked") ServiceController<Node> service = (ServiceController<Node>) context.getController().getServiceContainer() .getService(ServiceActivator.SINGLETON_SERVICE_NAME); try { Node node = service.awaitValue(5, TimeUnit.SECONDS); LOG.infof("Singleton service is running on node '%s'.", node); } catch (InterruptedException | TimeoutException | IllegalStateException e) { LOG.warn("Failed to query singleton service."); } }, 5, 5, TimeUnit.SECONDS); } @Override public void stop(StopContext context) { LOG.info("Querying service is stopping."); executor.shutdown(); } @Override public Void getValue() throws IllegalStateException, IllegalArgumentException { return null; } }
ServiceActivator
クラスを実装し、シングルトンサービスとクエリーサービスの両方を構築およびインストールします。public class ServiceActivator implements org.jboss.msc.service.ServiceActivator { private final Logger LOG = Logger.getLogger(ServiceActivator.class); static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.parse("org.jboss.as.quickstarts.ha.singleton.service.primary-only"); private static final ServiceName QUERYING_SERVICE_NAME = ServiceName.parse("org.jboss.as.quickstarts.ha.singleton.service.primary-only.querying"); @Override public void activate(ServiceActivatorContext serviceActivatorContext) { try { SingletonPolicy policy = (SingletonPolicy) serviceActivatorContext .getServiceRegistry() .getRequiredService(ServiceName.parse(SingletonDefaultRequirement.SINGLETON_POLICY.getName())) .awaitValue(); InjectedValue<Group> group = new InjectedValue<>(); Service<Node> service = new SingletonService(group); policy.createSingletonServiceBuilder(SINGLETON_SERVICE_NAME, service) .build(serviceActivatorContext.getServiceTarget()) .addDependency(ServiceName.parse("org.wildfly.clustering.default-group"), Group.class, group) .install(); serviceActivatorContext.getServiceTarget() .addService(QUERYING_SERVICE_NAME, new QueryingService()) .setInitialMode(ServiceController.Mode.ACTIVE) .install(); LOG.info("Singleton and querying services activated."); } catch (InterruptedException e) { throw new ServiceRegistryException(e); } } }
-
ServiceActivator
クラスの名前 (例:org.jboss.as.quickstarts.ha.singleton.service.primary.ServiceActivator
) が含まれる、org.jboss.msc.service.ServiceActivator
という名前のファイルをMETA-INF/services/
ディレクトリーに作成します。
完全な作業例は、JBoss EAP に同梱される ha-singleton-service
クイックスタートを参照してください。このクイックスタートには、バックアップサービスでインストールされるシングルトンサービスを実証する 2 つ目の例も含まれています。バックアップサービスは、シングルトンサービスの実行用に選択されていないすべてのノード上で実行されます。また、このクイックスタートは異なる選択ポリシーの設定方法についても実証します。
6.5. HA シングルトンデプロイメント
JBoss EAP 7 には、該当するアプリケーションをシングルトンデプロイメントとしてデプロイする機能が追加されます。
クラスタ化されたサーバーのグループにデプロイされる場合、シングルトンデプロイメントでは該当するタイミングで単一のノードにのみデプロイされます。デプロイメントがアクティブなノードが停止または失敗すると、デプロイメントは別のノードで自動的に開始されます。
HA シングルトンの動作を制御するポリシーは、新しい singleton
サブシステムによって管理されます。デプロイメントは特定のシングルトンポリシーを指定するか、デフォルトのサブシステムポリシーを使用します。デプロイメントは、デプロイメントオーバーレイとして既存のデプロイメントに最も簡単に適用される META-INF/singleton-deployment.xml
デプロイメント記述子を使用して、シングルトンデプロイメントとして識別されます。また、必要なシングルトン設定を既存の jboss-all.xml
ファイル内に組み込むこともできます。
シングルトンデプロイメントの定義または選択
デプロイメントをシングルトンデプロイメントとして定義するには、アプリケーションアーカイブに
META-INF/singleton-deployment.xml
記述子を含めます。例: シングルトンデプロイメント記述子
<?xml version="1.0" encoding="UTF-8"?> <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>
例: 特定のシングルトンポリシーを使用したシングルトンデプロイメント記述子
<?xml version="1.0" encoding="UTF-8"?> <singleton-deployment policy="my-new-policy" xmlns="urn:jboss:singleton-deployment:1.0"/>
または、
singleton-deployment
要素をjboss-all.xml
記述子ファイルに追加することもできます。例:
jboss-all.xml
でのsingleton-deployment
の定義<?xml version="1.0" encoding="UTF-8"?> <jboss xmlns="urn:jboss:1.0"> <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/> </jboss>
例: 特定のシングルトンポリシーを使用した
jboss-all.xml
でのsingleton-deployment
の定義<?xml version="1.0" encoding="UTF-8"?> <jboss xmlns="urn:jboss:1.0"> <singleton-deployment policy="my-new-policy" xmlns="urn:jboss:singleton-deployment:1.0"/> </jboss>
シングルトンデプロイメントの作成
JBoss EAP は、以下の 2 つの選択ポリシーを提供します。
単純な選択ポリシー
simple-election-policy
はposition
属性で示された特定のメンバーを選択します (該当するアプリケーションがデプロイされます)。position
属性は、降順の経過時間でソートされた候補のリストから選択するノードのインデックスを決定します (0
は最も古いノード、1
は 2 番目に古いノード、-1
は最も新しいノード、-2
は 2 番目に新しいノードを示します)。指定された位置が候補の数を超えると、モジュロ演算が適用されます。例: 管理 CLI を使用して
simple-election-policy
で新しいシングルトンポリシーを作成し、位置を-1
に設定batch /subsystem=singleton/singleton-policy=my-new-policy:add(cache-container=server) /subsystem=singleton/singleton-policy=my-new-policy/election- policy=simple:add(position=-1) run-batch
注記新しく作成されたポリシー
my-new-policy
をデフォルトとして設定するには、以下のコマンドを実行します。/subsystem=singleton:write-attribute(name=default, value=my-new-policy)
例:
standalone-ha.xml
で位置を-1
としてsimple-election-policy
を設定<subsystem xmlns="urn:jboss:domain:singleton:1.0"> <singleton-policies default="my-new-policy"> <singleton-policy name="my-new-policy" cache-container="server"> <simple-election-policy position="-1"/> </singleton-policy> </singleton-policies> </subsystem>
ランダムな選択ポリシー
random-election-policy
は、該当するアプリケーションがデプロイされるランダムなメンバーを選択します。例: 管理 CLI を使用して
random-election-policy
で新しいシングルトンポリシーを作成batch /subsystem=singleton/singleton-policy=my-other-new-policy:add(cache-container=server) /subsystem=singleton/singleton-policy=my-other-new-policy/election-policy=random:add() run-batch
例:
standalone-ha.xml
を使用したrandom-election-policy
の設定<subsystem xmlns="urn:jboss:domain:singleton:1.0"> <singleton-policies default="my-other-new-policy"> <singleton-policy name="my-other-new-policy" cache-container="server"> <random-election-policy/> </singleton-policy> </singleton-policies> </subsystem>
注記ポリシーを追加する前に、
cache-container
のdefault-cache
属性を定義する必要があります。定義しないと、カスタムキャッシュコンテナーを使用する場合に、エラーメッセージが表示されることがあります。
設定
また、シングルトン選択ポリシーを使用して、クラスターの 1 つ以上のメンバーの優先順位を指定することもできます。優先順位は、ノード名またはアウトバウンドソケットバインド名を使用して定義できます。ノードの優先順位は、常に選択ポリシーの結果よりも優先されます。
例: 管理 CLI を使用した既存のシングルトンポリシーの優先順位の指定
/subsystem=singleton/singleton-policy=foo/election-policy=simple:list-add(name=name-preferences, value=nodeA) /subsystem=singleton/singleton-policy=bar/election-policy=random:list-add(name=socket-binding-preferences, value=binding1)
例: 管理 CLI を使用して simple-election-policy
および name-preferences
で新しいシングルトンポリシーを設定
batch /subsystem=singleton/singleton-policy=my-new-policy:add(cache-container=server) /subsystem=singleton/singleton-policy=my-new-policy/election-policy=simple:add(name-preferences=[node1, node2, node3, node4]) run-batch
新しく作成されたポリシー my-new-policy
をデフォルトとして設定するには、以下のコマンドを実行します。
/subsystem=singleton:write-attribute(name=default, value=my-new-policy)
例: standalone-ha.xml
を使用した socket-binding-preferences
での random-election-policy
の設定
<subsystem xmlns="urn:jboss:domain:singleton:1.0"> <singleton-policies default="my-other-new-policy"> <singleton-policy name="my-other-new-policy" cache-container="server"> <random-election-policy> <socket-binding-preferences>binding1 binding2 binding3 binding4</socket-binding-preferences> </random-election-policy> </singleton-policy> </singleton-policies> </subsystem>
クォーラムの定義
ネットワークパーティションは、シングルトンデプロイメントに対して特に問題となります。これは、同時に実行する同じデプロイメントに対して複数のシングルトンプロバイダーをトリガーできるためです。このような状況を回避するために、シングルトンポリシーはシングルトンプロバイダーの選択が行われる前に、最小数のノードが存在することを必要とするクォーラムを定義できます。通常のデプロイメントでは、N/2 + 1 のクォーラムが使用されます (ここで、N は予想されるクラスターサイズです)。この値は実行時に更新でき、対応するシングルトンポリシーを使用するすべてのシングルトンサービスに即時反映されます。
例: standalone-ha.xml
ファイルでのクォーラム宣言
<subsystem xmlns="urn:jboss:domain:singleton:1.0"> <singleton-policies default="default"> <singleton-policy name="default" cache-container="server" quorum="4"> <simple-election-policy/> </singleton-policy> </singleton-policies> </subsystem>
例: 管理 CLI を使用したクォーラム宣言
/subsystem=singleton/singleton-policy=foo:write-attribute(name=quorum, value=3)
シングルトンデプロイメントを使用したクラスター全体のシングルトンとしてアプリケーションにパッケージ化されたサービスの完全な作業例は、JBoss EAP に同梱される ha-singleton-deployment
クイックスタートを参照してください。
6.6. Apache mod_cluster-manager アプリケーション
6.6.1. mod_cluster-manager アプリケーション
mod_cluster-manager アプリケーションは、Apache HTTP サーバーで利用可能な管理 Web ページです。接続されたワーカーノードを監視し、コンテキストの有効化または無効化やクラスター内のワーカーノードの負荷分散プロパティーの設定などのさまざまな管理タスクを実行するために使用されます。
mod_cluster-manager アプリケーションの使用
mod_cluster-manager アプリケーションは、ワーカーノードでさまざまな管理タスクを実行するために使用されます。
図 - mod_cluster 管理 Web ページ
- [1] mod_cluster/1.3.1.Final: mod_cluster ネイティブライブラリーのバージョン。
- [2] ajp://192.168.122.204:8099: 使用されるプロトコル (AJP、HTTP、または HTTPS)、ワーカーノードのホスト名または IP アドレス、およびポート。
- [3] jboss-eap-7.0-2: ワーカーノードの JVMRoute。
- [4] Virtual Host 1: ワーカーノードで設定された仮想ホスト。
- [5] Disable: 特定のコンテキストで新しいセッションの作成を無効にするために使用できる管理オプション。ただし、現在のセッションは無効にされず、そのまま処理されます。
-
[6] Stop: コンテキストへのセッション要求のルーティングを停止するために使用できる管理オプション。
sticky-session-force
プロパティーがtrue
に設定されない限り、残りのセッションは別のノードにフェイルオーバーされます。 - [7] Enable Contexts Disable Contexts Stop Contexts: ノード全体で実行できる操作。これらのいずれかのオプションを選択すると、すべての仮想ホストのノードのコンテキストすべてが影響を受けます。
[8] Load balancing group (LBGroup): すべてのワーカーノードをカスタム負荷分散グループにグループ化するために、
load-balancing-group
プロパティーは JBoss EAP 設定のmodcluster
サブシステムで設定されます。負荷分散グループ (LBGroup) は、設定されたすべての負荷分散グループに関する情報を提供する情報フィールドです。このフィールドが設定されていないと、すべてのワーカーノードは単一のデフォルト負荷分散グループにグループ化されます。注記これは唯一の情報フィールドであるため、
load-balancing-group
プロパティーの設定に使用できません。このプロパティーは JBoss EAP 設定のmodcluster
サブシステムで設定する必要があります。[9] Load (value): ワーカーノードの負荷係数。負荷係数は以下のように評価されます。
-load > 0 : 負荷係数の値が 1 であると、ワーカーノードがオーバーロードされます。負荷係数が 100 の場合は、負荷がないノードであることを意味します。 -load = 0 : 負荷係数の値が 0 であると、ワーカーノードはスタンドバイモードになります。これは、他のノードが使用できなくなるまで (および他のノードが利用不可でない限り) セッション要求がこのノードにルーティングされないことを意味します。 -load = -1 : 負荷係数の値が -1 の場合は、ワーカーノードがエラー状態にあることを示します。 -load = -2 : 負荷係数の値が -2 の場合は、ワーカーノードが CPing/CPong を実行中であり、遷移状態にあることを示します。
JBoss EAP 7.1 の場合は、ロードバランサーとして Undertow を使用することもできます。