第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/>要素を追加します。例: 配布可能なアプリケーションの最低限の設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、必要な場合はデフォルトのレプリケーションの動作を変更します。セッションレプリケーションに影響する値を変更する場合は、アプリケーションの
WEB-INF/jboss-web.xmlファイルにある<jboss-web>内の<replication-config>要素内でこれらの値をオーバーライドできます。該当する要素で、デフォルト値をオーバーライドする場合のみ値を含めます。例: <replication-config> 値
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
<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 ファイル
<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;
@Resource(lookup = "java:jboss/clustering/group/channel-name") private Group channelGroup;Copy to Clipboard Copied! Toggle word wrap Toggle overflow org.wildfly.clustering.dispatcher.CommandDispatcherCommandDispatcherFactoryサービスは、クラスター内のノードでコマンドを実行するためにディスパッチャーを作成するメカニズムを提供します。結果として得られるCommandDispatcherは、以前の JBoss EAP リリースのリフレクションベースのGroupRpcDispatcherに類似したコマンドパターンです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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サービスを作成します。サービスクラスコード例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow org.jboss.msc.service.ServiceActivatorインターフェースを実装し、activate()メソッドでHATimerServiceをクラスタ化されたシングルトンとしてインストールするサービスアクティベーターを作成します。この例では、node1がシングルトンサービスを開始するよう指定します。サービスアクティベーターコード例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アプリケーションの
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
org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow initialize()およびstop()メソッドを含むSchedulerインターフェースを作成します。スケジューラーインターフェースコード例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Schedulerインターフェースを実装するSingletonBean を作成します。この Bean はクラスター全体のシングルトンタイマーとして使用されます。重要SingletonBean はリモートインターフェースを持たないようにし、すべてのアプリケーションの別の EJB からローカルインターフェースを参照しないようにする必要があります。これにより、クライアントや他のコンポーネントをルックアップできなくなり、HATimerServiceがSingletonを完全に制御するようになります。シングルトン Bean コード例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
このアプリケーションの完全な稼働サンプルについては、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 xmlns="urn:jboss:singleton-deployment:1.0"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のシングルトンポリシーを使用したシングルトンデプロイメント記述子の例:
<?xml version="1.0" encoding="UTF-8"?> <singleton-deployment policy="my-new-policy" 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"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、
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><?xml version="1.0" encoding="UTF-8"?> <jboss xmlns="urn:jboss:1.0"> <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/> </jboss>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のシングルトンポリシーを使用した
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><?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>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
シングルトンデプロイメントの作成
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
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-batchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記新しく作成されたポリシー
my-new-policyをデフォルトとして設定するには、以下のコマンドを実行します。/subsystem=singleton:write-attribute(name=default, value=my-new-policy)
/subsystem=singleton:write-attribute(name=default, value=my-new-policy)Copy to Clipboard Copied! Toggle word wrap Toggle overflow standalone-ha.xmlを使用して位置が-1に設定された状態でsimple-election-policyを設定する例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow ランダムな選択ポリシー
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
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-batchCopy to Clipboard Copied! Toggle word wrap Toggle overflow standalone-ha.xmlを使用してrandom-election-policyを設定する例:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ポリシーを追加する前に、
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)
/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
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)
/subsystem=singleton:write-attribute(name=default, value=my-new-policy)
standalone-ha.xml で socket-binding-preferences を使用して random-election-policy を設定する例:
クォーラム
ネットワークパーティションは、シングルトンデプロイメントに対して特に問題となります。これは、同時に実行する同じデプロイメントに対して複数のシングルトンプロバイダーをトリガーできるためです。このシナリオを回避するために、シングルトンポリシーにより、シングルトンプロバイダー選択が行われる前に、存在する必要があるノードの最小数を規定するクォーラムを定義できます。通常のデプロイメントシナリオでは、N/2 + 1 のクォーラムが使用されます (ここで、N は予想されるクラスターサイズです)。この値は実行時に更新でき、各シングルトンポリシーを使用するすべてのシングルトンデプロイメントにすぐに影響を与えます。
standalone-ha.xml ファイルでのクォーラム宣言の例:
管理 CLI を使用したクォーラム宣言の例:
/subsystem=singleton/singleton-policy=foo:write-attribute(name=quorum, value=3)
/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 を実行中であり、遷移状態にあることを示します。
-load > 0 : 負荷係数の値が 1 であると、ワーカーノードがオーバーロードされます。負荷係数が 100 の場合は、負荷がないノードであることを意味します。 -load = 0 : 負荷係数の値が 0 であると、ワーカーノードはスタンドバイモードになります。これは、他のノードが使用できなくなるまで (および他のノードが利用不可でない限り) セッション要求がこのノードにルーティングされないことを意味します。 -load = -1 : 負荷係数の値が -1 の場合は、ワーカーノードがエラー状態にあることを示します。 -load = -2 : 負荷係数の値が -2 の場合は、ワーカーノードが CPing/CPong を実行中であり、遷移状態にあることを示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
JBoss EAP 7.0 の場合は、ロードバランサーとして Undertow を使用することもできます。