第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 EAP7 の場合、セッションレプリケーションはセッションが変更された場合、またはセッションの変更可能な属性がアクセスされた場合にトリガーされます。以下のいずれかの条件に該当しない限り、セッション属性は変更可能であると見なされます。
値が既知の変更不能な値である
-
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 Config Guide の Configure the Cache Mode を参照してください。たとえば、各ノードが 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-singleton を起動する優先度がある場合は、ServiceActivator
クラスで選択ポリシーを設定できます。
JBoss EAP は、以下の 2 つの選択ポリシーを提供します。
単純な選択ポリシー
単純な選択ポリシーでは、相対的な経過時間に基づいてマスターノードが選択されます。必要な経過時間は、利用可能なノードのリストのインデックスである position プロパティーで設定されます。この場合は、以下のように設定されます。
- position = 0 – 最も古いノードを参照する (デフォルト)
position = 1 – 2 番目に古いノードを参照する
position をマイナスにして最も新しいノードを示すこともできます。
- position = -1 – 最も新しいノードを参照する
- position = -2 – 2 番目に新しいノードを参照する
ランダムな選択ポリシー
ランダムな選択ポリシーでは、シングルトンサービスのプロバイダーとなるランダムなメンバーが選択されます。
HA シングルトンサービスアプリケーションの作成
以下に、アプリケーションを作成し、クラスター全体シングルトンサービスとしてデプロイするのに必要な手順の簡単な例を示します。この例のサービスにより、クラスターで 1 度だけ開始されるスケジュールタイマーがアクティブ化されます。
org.jboss.msc.service.Service
インターフェースを実装し、getValue()
、start()
、およびstop()
メソッドを含むHATimerService
サービスを作成します。サービスクラスコード例
public class HATimerService implements Service<String> { private static final Logger LOGGER = Logger.getLogger(HATimerService.class.toString()); public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton", "timer"); /** * A flag whether the service is started. */ private final AtomicBoolean started = new AtomicBoolean(false); /** * @return the name of the server node */ public String getValue() throws IllegalStateException, IllegalArgumentException { LOGGER.info(String.format("%s is %s at %s", HATimerService.class.getSimpleName(), (started.get() ? "started" : "not started"), System.getProperty("jboss.node.name"))); return System.getProperty("jboss.node.name"); } public void start(StartContext arg0) throws StartException { if (!started.compareAndSet(false, true)) { throw new StartException("The service is still started!"); } LOGGER.info("Start HASingleton timer service '" + this.getClass().getName() + "'"); final String node = System.getProperty("jboss.node.name"); try { InitialContext ic = new InitialContext(); ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")) .initialize("HASingleton timer @" + node + " " + new Date()); } catch (NamingException e) { throw new StartException("Could not initialize timer", e); } } public void stop(StopContext arg0) { if (!started.compareAndSet(true, false)) { LOGGER.warning("The service '" + this.getClass().getName() + "' is not active!"); } else { LOGGER.info("Stop HASingleton timer service '" + this.getClass().getName() + "'"); try { InitialContext ic = new InitialContext(); ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).stop(); } catch (NamingException e) { LOGGER.info("Could not stop timer:" + e.getMessage()); } } } }
org.jboss.msc.service.ServiceActivator
インターフェースを実装し、activate()
メソッドでHATimerService
をクラスタ化されたシングルトンとしてインストールするサービスアクティベーターを作成します。この例では、node1
がシングルトンサービスを開始するよう指定します。サービスアクティベーターコード例
public class HATimerServiceActivator implements ServiceActivator { private final Logger log = Logger.getLogger(this.getClass().toString()); @Override public void activate(ServiceActivatorContext context) { log.info("HATimerService will be installed!"); HATimerService service = new HATimerService(); ServiceName factoryServiceName = SingletonServiceName.BUILDER.getServiceName("server", "default"); ServiceController<?> factoryService = context.getServiceRegistry().getRequiredService(factoryServiceName); SingletonServiceBuilderFactory factory = (SingletonServiceBuilderFactory) factoryService.getValue(); ServiceName ejbComponentService = ServiceName.of("jboss", "deployment", "unit", "jboss-cluster-ha-singleton-service.jar", "component", "SchedulerBean", "START"); factory.createSingletonServiceBuilder(HATimerService.SINGLETON_SERVICE_NAME, service) .electionPolicy(new PreferredSingletonElectionPolicy(new SimpleSingletonElectionPolicy(), new NamePreference("node1/singleton"))) .build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry())) .setInitialMode(ServiceController.Mode.ACTIVE) .addDependency(ejbComponentService) .install(); } }
アプリケーションの
META-INF/services/
ディレクトリーでorg.jboss.msc.service.ServiceActivator
という名前のファイルを作成し、前の手順で作成されたServiceActivator
クラスの完全修飾名を含む行を追加します。META-INF/services/org.jboss.msc.service.ServiceActivator ファイル例
org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator
initialize()
およびstop()
メソッドを含むScheduler
インターフェースを作成します。スケジューラーインターフェースコード例
public interface Scheduler { void initialize(String info); void stop(); }
Scheduler
インターフェースを実装するSingleton
Bean を作成します。この Bean はクラスター全体のシングルトンタイマーとして使用されます。重要Singleton
Bean はリモートインターフェースを持たないようにし、すべてのアプリケーションの別の EJB からローカルインターフェースを参照しないようにする必要があります。これにより、クライアントや他のコンポーネントをルックアップできなくなり、HATimerService
がSingleton
を完全に制御するようになります。シングルトン Bean コード例
@Singleton public class SchedulerBean implements Scheduler { private static Logger LOGGER = Logger.getLogger(SchedulerBean.class.toString()); @Resource private TimerService timerService; @Timeout public void scheduler(Timer timer) { LOGGER.info("HASingletonTimer: Info=" + timer.getInfo()); } @Override public void initialize(String info) { ScheduleExpression sexpr = new ScheduleExpression(); // set schedule to every 10 seconds for demonstration sexpr.hour("*").minute("*").second("0/10"); // persistent must be false because the timer is started by the HASingleton service timerService.createCalendarTimer(sexpr, new TimerConfig(info, false)); } @Override public void stop() { LOGGER.info("Stop all existing HASingleton timers"); for (Timer timer : timerService.getTimers()) { LOGGER.fine("Stop HASingleton timer: " + timer.getInfo()); timer.cancel(); } } }
このアプリケーションの完全な稼働サンプルについては、JBoss EAP に同梱される cluster-ha-singleton
クイックスタートを参照してください。クイックスタートは、アプリケーションをビルドおよびデプロイする詳細な手順を提供します。
6.5. HA シングルトンデプロイメント
JBoss EAP 7 には、該当するアプリケーションをシングルトンデプロイメントとしてデプロイする機能が追加されます。
クラスタ化されたサーバーのグループにデプロイされる場合、シングルトンデプロイメントでは該当するタイミングで単一のノードにのみデプロイされます。デプロイメントがアクティブなノードが停止または失敗すると、デプロイメントは別のノードで自動的に開始されます。
HA シングルトンの動作を制御するポリシーは、新しいシングルトンサブシステムによって管理されます。デプロイメントは特定のシングルトンポリシーを指定するか、デフォルトのサブシステムポリシーを使用します。デプロイメントは、デプロイメントオーバーレイとして既存のデプロイメントに最も簡単に適用される /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)
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.0 の場合は、ロードバランサーとして Undertow を使用することもできます。