第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!"; // Exclude node1 and node3 from the executeOnCluster try (CommandDispatcher<String> dispatcher = this.factory.createCommandDispatcher(context)) { dispatcher.executeOnGroup(new StdOutCommand(), node1, node3); } } 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 が導入されました。
SingletonServiceConfigurator
実装により、サービスは非同期的に開始されるようインストールされ、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 シングルトンサービス選択リスナー
新しいプライマリーシングルトンサービスプロバイダーを選択すると、登録されたすべての SingletonElectionListener
がトリガーされ、新しいプライマリープロバイダーに関するクラスターのすべてのメンバーに通知します。以下は、SingletonElectionListener
の使用例です。
public class MySingletonElectionListener implements SingletonElectionListener { @Override public void elected(List<Node> candidates, Node primary) { // ... } } public class MyServiceActivator implements ServiceActivator { @Override public void activate(ServiceActivatorContext context) { String containerName = "foo"; SingletonElectionPolicy policy = new MySingletonElectionPolicy(); SingletonElectionListener listener = new MySingletonElectionListener(); int quorum = 3; ServiceName name = ServiceName.parse("my.service.name"); // Use a SingletonServiceConfiguratorFactory backed by default cache of "foo" container Supplier<SingletonServiceConfiguratorFactory> factory = new ActiveServiceSupplier<>(context.getServiceTarget(), ServiceName.parse(SingletonDefaultCacheRequirement.SINGLETON_SERVICE_CONFIGURATOR_FACTORY.resolve(containerName).getName())); ServiceBuilder<?> builder = factory.get().createSingletonServiceConfigurator(name) .electionListener(listener) .electionPolicy(policy) .requireQuorum(quorum) .build(context.getServiceTarget()); Service service = new MyService(); builder.setInstance(service).install(); } }
HA シングルトンサービスアプリケーションの作成
以下に、アプリケーションを作成し、クラスター全体のシングルトンサービスとしてデプロイするのに必要な手順の簡単な例を示します。この例では、頻繁にシングルトンサービスをクエリーし、そのシングルトンサービスが実行されているノードの名前を取得します。
シングルトンの挙動を確認するには、最低でも 2 つのサーバーにアプリケーションをデプロイする必要があります。シングルトンサービスが同じノードで実行されているかまたは値がリモートで取得されているかは透過的です。
SingletonService
クラスを作成します。クエリーサービスによって呼び出されるgetValue()
メソッドは、実行されているノードに関する情報を提供します。class SingletonService implements Service { private Logger LOG = Logger.getLogger(this.getClass()); private Node node; private Supplier<Group> groupSupplier; private Consumer<Node> nodeConsumer; SingletonService(Supplier<Group> groupSupplier, Consumer<Node> nodeConsumer) { this.groupSupplier = groupSupplier; this.nodeConsumer = nodeConsumer; } @Override public void start(StartContext context) { this.node = this.groupSupplier.get().getLocalMember(); this.nodeConsumer.accept(this.node); LOG.infof("Singleton service is started on node '%s'.", this.node); } @Override public void stop(StopContext context) { LOG.infof("Singleton service is stopping on node '%s'.", this.node); this.node = null; } }
クエリーサービスを作成します。シングルトンサービスの
getValue()
メソッドを呼び出し、それが稼働しているノードの名前を取得して、サーバーログに結果を書き込みます。class QueryingService implements Service { private Logger LOG = Logger.getLogger(this.getClass()); private ScheduledExecutorService executor; @Override public void start(StartContext context) throws { LOG.info("Querying service is starting."); executor = Executors.newSingleThreadScheduledExecutor(); executor.scheduleAtFixedRate(() -> { Supplier<Node> node = new PassiveServiceSupplier<>(context.getController().getServiceContainer(), SingletonServiceActivator.SINGLETON_SERVICE_NAME); if (node.get() != null) { LOG.infof("Singleton service is running on this (%s) node.", node.get()); } else { LOG.infof("Singleton service is not running on this node."); } }, 5, 5, TimeUnit.SECONDS); } @Override public void stop(StopContext context) { LOG.info("Querying service is stopping."); executor.shutdown(); } }
SingletonServiceActivator
クラスを実装し、シングルトンサービスとクエリーサービスの両方を構築およびインストールします。public class SingletonServiceActivator implements ServiceActivator { private final Logger LOG = Logger.getLogger(SingletonServiceActivator.class); static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.parse("org.jboss.as.quickstarts.ha.singleton.service"); private static final ServiceName QUERYING_SERVICE_NAME = ServiceName.parse("org.jboss.as.quickstarts.ha.singleton.service.querying"); @Override public void activate(ServiceActivatorContext serviceActivatorContext) { SingletonPolicy policy = new ActiveServiceSupplier<SingletonPolicy>( serviceActivatorContext.getServiceRegistry(), ServiceName.parse(SingletonDefaultRequirement.POLICY.getName())).get(); ServiceTarget target = serviceActivatorContext.getServiceTarget(); ServiceBuilder<?> builder = policy.createSingletonServiceConfigurator(SINGLETON_SERVICE_NAME).build(target); Consumer<Node> member = builder.provides(SINGLETON_SERVICE_NAME); Supplier<Group> group = builder.requires(ServiceName.parse("org.wildfly.clustering.default-group")); builder.setInstance(new SingletonService(group, member)).install(); serviceActivatorContext.getServiceTarget() .addService(QUERYING_SERVICE_NAME, new QueryingService()) .setInitialMode(ServiceController.Mode.ACTIVE) .install(); serviceActivatorContext.getServiceTarget().addService(QUERYING_SERVICE_NAME).setInstance(new QueryingService()).install(); LOG.info("Singleton and querying services activated."); } }
-
ServiceActivator
クラスの名前 (例:org.jboss.as.quickstarts.ha.singleton.service.SingletonServiceActivator
) が含まれる、org.jboss.msc.service.ServiceActivator
という名前のファイルをMETA-INF/services/
ディレクトリーに作成します。
完全な作業例は、JBoss EAP に同梱される ha-singleton-service
クイックスタートを参照してください。このクイックスタートには、バックアップサービスでインストールされるシングルトンサービスを実証する 2 つ目の例も含まれています。バックアップサービスは、シングルトンサービスの実行用に選択されていないすべてのノード上で実行されます。また、このクイックスタートは異なる選択ポリシーの設定方法についても実証します。
6.5. HA シングルトンデプロイメント
アプリケーションをシングルトンデプロイメントとしてデプロイできます。クラスタ化されたサーバーのグループにデプロイされる場合、シングルトンデプロイメントでは該当するタイミングで単一のノードにのみデプロイされます。デプロイメントがアクティブなノードが停止または失敗すると、デプロイメントは別のノードで自動的に開始されます。
以下の状況では、シングルトンデプロイメントを複数のノードにデプロイできます。
- 特定のノード上のクラスター化されたサーバーのグループは、構成の問題やネットワークの問題により接続を確立できません。
以下の設定ファイルなど、HA 以外の設定が使用されます。
-
Java EE 8 Web Profile、または Java EE 8 Web Profile をサポートする
standalone.xml
設定または、Java EE 8 Full Platform プロファイルをサポートするstandalone-full.xml
。 -
デフォルトのドメインプロファイルまたはフルドメインプロファイルのいずれかで構成される
domain.xml
設定。
-
Java EE 8 Web Profile、または Java EE 8 Web Profile をサポートする
HA 以外の設定には、デフォルトで singleton サブシステムが有効になっていません。このデフォルト設定を使用する場合、アプリケーションのデプロイメントを正常にプロモートするために singleton-deployment.xml
ファイルは無視されます。
ただし、HA 以外の設定を使用すると、jboss-all.xml
記述子ファイルのエラーが発生する可能性があります。これらのエラーを回避するには、singleton-deployment.xml
記述子に単一のデプロイメントを追加します。その後、任意のプロファイルタイプを使用してアプリケーションをデプロイできます。
HA シングルトンの動作を制御するポリシーは、新しい singleton
サブシステムによって管理されます。デプロイメントは特定のシングルトンポリシーを指定するか、デフォルトのサブシステムポリシーを使用します。
デプロイメントは、デプロイメントオーバーレイとして既存のデプロイメントに適用される META-INF/singleton-deployment.xml
デプロイメント記述子を使用して、シングルトンデプロイメントとして識別されます。また、必要なシングルトン設定を既存の jboss-all.xml
ファイル内に組み込むこともできます。
シングルトンデプロイメントの定義または選択
デプロイメントをシングルトンデプロイメントとして定義するには、アプリケーションアーカイブに META-INF/singleton-deployment.xml
記述子を含めます。
Maven WAR プラグインがすでに存在する場合、プラグインを META-INF
ディレクトリー (**/src/main/webapp/META-INF
) に移行できます。
手順
アプリケーションが EAR ファイルにデプロイされている場合は、
jboss-all.xml
ファイル内にあるsingleton-deployment.xml
記述子またはsingleton- deployment
要素をMETA-INF
ディレクトリーの最上位に移動します。例: シングルトンデプロイメント記述子
<?xml version="1.0" encoding="UTF-8"?> <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>
アプリケーションデプロイメントを WAR ファイルまたは JAR ファイルとして追加するには、
singleton-deployment.xml
記述子をアプリケーションアーカイブの/META-INF
ディレクトリーの最上位に移動します。例: 特定のシングルトンポリシーを使用したシングルトンデプロイメント記述子
<?xml version="1.0" encoding="UTF-8"?> <singleton-deployment policy="my-new-policy" xmlns="urn:jboss:singleton-deployment:1.0"/>
オプション:
jboss-all.xml
ファイルでsingleton-deployment
を定義するには、jboss-all.xml
記述子をアプリケーションアーカイブの/META-INF
ディレクトリーの最上位に移動します。例:
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>
オプション: singleton ポリシーを使用して
jboss-all.xml
ファイルでsingleton-deployment
を定義します。jboss-all.xml
記述子をアプリケーションアーカイブの/META-INF
ディレクトリーの最上位に移動します。例: 特定のシングルトンポリシーを使用した
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
クイックスタートを参照してください。
CLI を使用したプライマリーシングルトンサービスプロバイダーの決定
singleton
サブシステムは、特定のシングルトンポリシーから作成された各シングルトンデプロイメントまたはサービスのランタイムリソースを公開します。これは、CLI を使用したプライマリーシングルトンプロバイダーの判断に役立ちます。
現在シングルトンプロバイダーとして動作するクラスターメンバーの名前を表示できます。例を以下に示します。
/subsystem=singleton/singleton-policy=default/deployment=singleton.jar:read-attribute(name=primary-provider) { "outcome" => "success", "result" => "node1" }
また、シングルトンデプロイメントまたはサービスがインストールされているノードの名前を表示することもできます。例を以下に示します。
/subsystem=singleton/singleton-policy=default/deployment=singleton.jar:read-attribute(name=providers) { "outcome" => "success", "result" => [ "node1", "node2" ] }
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 : A load factor with value 1 indicates that the worker node is overloaded. A load factor of 100 denotes a free and not-loaded node. -load = 0 : A load factor of value 0 indicates that the worker node is in standby mode. This means that no session requests will be routed to this node until and unless the other worker nodes are unavailable. -load = -1 : A load factor of value -1 indicates that the worker node is in an error state. -load = -2 : A load factor of value -2 indicates that the worker node is undergoing CPing/CPong and is in a transition state.
JBoss EAP 7.4 では、ロードバランサーとして Undertow を使用することもできます。
6.7. 分散可能な Web セッション設定の distributable-web サブシステム
distributable-web
サブシステムは、柔軟で分散可能な Web セッション設定を実現します。このサブシステムは、一連の分散可能な Web セッション管理プロファイルを定義します。これらのプロファイルのいずれかが、デフォルトのプロファイルとして指定されます。これは、分散可能な Web アプリケーションのデフォルト動作を定義します。例を以下に示します。
[standalone@embedded /] /subsystem=distributable-web:read-attribute(name=default-session-management) { "outcome" => "success", "result" => "default" }
デフォルトのセッション管理では、以下の例が示すように、Web セッションデータを Infinispan キャッシュに格納します。
[standalone@embedded /] /subsystem=distributable-web/infinispan-session-management=default:read-resource { "outcome" => "success", "result" => { "cache" => undefined, "cache-container" => "web", "granularity" => "SESSION", "affinity" => {"primary-owner" => undefined} } }
この例と利用できる値で使用される属性は以下になります。
-
cache
: 関連するキャッシュコンテナー内のキャッシュ。Web アプリケーションのキャッシュは、このキャッシュの設定に基づいています。定義されていない場合は、関連付けられたキャッシュコンテナーのデフォルトキャッシュが使用されます。 -
cache-container
: セッションデータが格納されるInfinispan
サブシステムで定義されたキャッシュコンテナー。 granularity
: セッションマネージャーがセッションを個別のキャッシュエントリーにマッピングする方法を定義します。以下の値が使用できます。-
SESSION
: 単一のキャッシュエントリー内にすべてのセッション属性を保存します。ATTRIBUTE
粒度よりも大きいですが、クロス属性オブジェクト参照を保持します。 -
ATTRIBUTE
: 各セッション属性を個別のキャッシュエントリー内に保存します。SESSION
粒度よりも効率的ですが、クロス属性オブジェクト参照は維持しません。
-
affinity
: Web リクエストがサーバーに必要とするアフィニティーを定義します。関連する Web セッションのアフィニティーでは、セッション ID に追加されるルートを生成するアルゴリズムが決まります。以下の値が使用できます。-
affinity=none
: Web リクエストには、いかなるノードへのアフィニティーもありません。Web セッションの状態がアプリケーションサーバー内で維持されていない場合は、これを使用します。 -
affinity=local
: Web リクエストには、セッションに対する要求を最後に処理したサーバーにアフィニティーが設定されます。このオプションは、スティッキーセッションの動作に一致します。 -
affinity=primary-owner
: Web リクエストには、セッションのプライマリー所有者に対してアフィニティーがあります。これは、この分散セッションマネージャーのデフォルトのアフィニティーです。バッキングキャッシュが分散または複製されていない場合は、affinity=local
と同じように動作します。 -
affinity=ranked
: Web リクエストには、プライマリーおよびバックアップ所有者を含む一覧の先頭のメンバーと、最後にセッションを処理したメンバーのアフィニティーがあります。 -
affinity=ranked delimiter
: エンコーディングしたセッション識別子内の個別のルートを分離するために使用される区切り文字。 -
affinity=ranked max routes
: セッション識別子にエンコードするルートの最大数。
-
複数の順序付けされたルートを持つセッションアフィニティーを設定するには、ランク付けされたセッションアフィニティーをロードバランサーで有効にする必要があります。詳細は、JBoss EAP 『設定ガイド』 の「 Enabling Ranked Session Affinity in Your Load Balancer 」を参照してください。
セッション管理プロファイルを名前で参照するか、デプロイメント固有のセッション管理設定を指定して、デフォルトの分散可能なセッション管理動作をオーバーライドすることができます。詳細は、「 Overide Default Distributable Session Management Behavior」 を参照してください。
6.7.1. リモート Red Hat Data Grid での Web セッションデータの格納
distributable-web
サブシステムを設定すると、HotRod プロトコルを使用して、リモート Red Hat Data Grid クラスターに Web セッションデータを格納できます。Web セッションデータをリモートクラスターに格納すると、キャッシュレイヤーはアプリケーションサーバーとは独立してスケーリングできます。
設定例:
[standalone@embedded /]/subsystem=distributable-web/hotrod-session-management=ExampleRemoteSessionStore:add(remote-cache-container=datagrid, cache-configuration=__REMOTE_CACHE_CONFIG_NAME__, granularity=ATTRIBUTE) { "outcome" => "success" }
この例と利用できる値で使用される属性は以下になります。
-
remote-cache-container
: web セッションデータを格納するためにInfinispan
サブシステムに定義されたリモートキャッシュコンテナー。 cache-configuration
: Red Hat Data Grid クラスターのキャッシュ設定の名前。新しく作成されたデプロイメント固有のキャッシュは、この設定に基づいています。名前に一致するリモートキャッシュ設定が見つからない場合は、リモートコンテナーに新しいキャッシュ設定が作成されます。
granularity
: セッションマネージャーがセッションを個別のキャッシュエントリーにマッピングする方法を定義します。以下の値が使用できます。-
SESSION
: 単一のキャッシュエントリー内にすべてのセッション属性を保存します。ATTRIBUTE
粒度よりも大きいですが、クロス属性オブジェクト参照を保持します。 -
ATTRIBUTE
: 各セッション属性を個別のキャッシュエントリー内に保存します。SESSION
粒度よりも効率的ですが、クロス属性オブジェクト参照は維持しません。
-