検索

第6章 Web アプリケーションのクラスター化

download PDF

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

  1. 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;
        }
    }
  2. クエリーサービスを作成します。シングルトンサービスの 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();
        }
    }
  3. 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.");
        }
    }
  4. 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 設定。
重要

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-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 クイックスタートを参照してください。

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 Administration Web Page 図 - 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 粒度よりも効率的ですが、クロス属性オブジェクト参照は維持しません。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.