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 アプリケーションのクラスタリングを有効にするには、アプリケーションが配布可能になるよう設定する必要があります。アプリケーションが配布可能でないと、そのセッションは配布されません。

アプリケーションを配布可能にする
  1. アプリケーションの 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>

  2. 次に、必要な場合はデフォルトのレプリケーションの動作を変更します。セッションレプリケーションに影響する値を変更する場合は、アプリケーションの 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_LISTEMPTY_MAPEMPTY_SET
  • 値の型がまたは既知の変更不能な型である、または既知の変更不能な型を実装する:

    • java.lang.BooleanCharacterByteShortIntegerLongFloatDouble
    • java.lang.ClassEnumStackTraceElementString
    • java.io.Filejava.nio.file.Path
    • java.math.BigDecimalBigIntegerMathContext
    • java.net.Inet4AddressInet6AddressInetSocketAddressURIURL
    • java.security.Permission
    • java.util.CurrencyLocaleTimeZoneUUID
    • java.time.ClockDurationInstantLocalDateLocalDateTimeLocalTimeMonthDayPeriodYearYearMonthZoneIdZoneOffsetZonedDateTime
    • java.time.chrono.ChronoLocalDateChronologyEra
    • java.time.format.DateTimeFormatterDecimalStyle
    • java.time.temporal.TemporalFieldTemporalUnitValueRangeWeekFields
    • java.time.zone.ZoneOffsetTransitionZoneOffsetTransitionRuleZoneRules
  • 値の型に以下のアノテーションが付けられる:

    • @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 つのサーバーにアプリケーションをデプロイする必要があります。シングルトンサービスが同じノードで実行されているかまたは値がリモートで取得されているかは透過的です。

  1. 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();
        }
    }
  2. クエリーサービスを作成します。シングルトンサービスの 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;
        }
    
    }
  3. 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);
            }
        }
    }
  4. 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-policyposition 属性で示された特定のメンバーを選択します (該当するアプリケーションがデプロイされます)。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-containerdefault-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 ページ 図 - 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 を使用することもできます。