セッションレプリケーションの設定項目について

[Tally Saito]

チップワンストップの斉藤と申します。

以前、弊社中村よりご相談のメールをinfo@にお送りさせて頂いております。

Date: 2016/7/7, Thu 01:47

Subject: [C1S-Java7] <相談> GassFish3.1.2 の安定化に向けた助言のお願い

その際に、Payaraサーバーへの移行をご推奨頂き、この度ようやく、ある程度環境が

できた状態となりました。

しかしながら、残課題として、セッションレプリケーションの部分で、期待した通りの動きが

できる場合と、できない場合が発生しております。

構成は以下の通りとなります。

CentOS release 6.7 (Final)

Apache httpd-2.2.29

Payara Server 4.1.1.163 #badassfish (build 215)

Apache - Payara 間をmod_proxy_ajpで接続

パーシステンス設定

　Apache側：　BalancerMember ... route=

　Payara側：　-DjvmRoute

(本来不要ですが、搭載するアプリの中でシリアライズ未実装の

 ものもあるため、パーシステンス設定を残しております)

確認方法としまして、FireFoxのFireBugを使用し、Cookie内JSESSIONIDの

jvmRoute部分を変更し、意図的に他のインスタンスに振り分け、それでもセッション値が

参照できることを、レプリケーションの成功として確認しております。

一度はうまく稼働したことを確認できているのですが、インスタンス、管理サーバーの

停止、起動を繰り返す間に、セッション値の参照ができなくなってしまうことがあります。

レプリケーションの方式としましては、Hazelcast はまだ使用しておらず、まずは旧来の

セッションレプリケーションで進めようと考えております。

改めて、設定・挙動の確認をしたく、必要なポイントをお教え頂くことはできますでしょうか。

また、ご確認頂くために必要な情報がありましたらご指示ください。

以上、よろしくお願い申し上げます。

[Kenji HASUNUMA]

蓮沼です。

Shoalベースのクラスタの場合、GlassFish 3.1からロードバランサ内包を除いて大きな変更点はないのですが、クラスタの構成の可用性サービスで、可用性サービスのチェックがONかつ永続性のタイプが「replicated」になっているでしょうか？これが「memory」または「file」の場合はレプリケーションが行われず、また「hazelcast」の場合はShoalではなくHazelcastベースのクラスタにする必要があります。

Webアプリケーション側はすべてをSerializableにする必要はありませんが、セッション情報として保持するクラスについては漏れなくSerializableにする必要があります。Serializableでないセッション情報はレプリケーションが失敗しその際ログにNotSerializableExceptionなどを出力していると思われます。念のためPayaraのログをご確認頂ければと思います。payara41/glassfish/domains/domain1/logs/server.log

Payaraに起因するエラーは上記ログに出力される仕様になっています（もしクラスタ構成に不具合があればそれもログに出力されています）。逆に、ログに不審な点がないにも関わらず挙動がおかしい場合は、Apacheかmod_proxy_ajpに問題があると考えられます。

なお、mod_proxy_ajpとPayaraの間をAJP通信にしている場合、PayaraのHTTP設定のいくつかが無視され、mod_proxy_ajpの設定（設定はTomcatに類似）が優先されるようです。

[Tally Saito]

蓮沼様

ご連絡ありがとうございました。

> クラスタの構成の可用性サービスで、可用性サービスのチェックがONかつ永続性のタイプが「replicated」になっているでしょうか？

こちらはその通りに設定しております。

> Payaraに起因するエラーは上記ログに出力される仕様になっています（もしクラスタ構成に不具合があればそれもログに出力されています）。逆に、ログに不審な点がないにも関わらず挙動がおかしい場合は、Apacheかmod_proxy_ajpに問題があると考えられます。

ログには明らかなエラーは見つけられていませんが、状況によってレプリケーションできている場合とできていない場合があります。

以下、複数のサーバーで確認した概要です。

それぞれ別のLinux KVMで稼働する仮想ノードとなります。

Aグループ、Bグループで、管理サーバーとインスタンスノード2つの、3ノードずつの構成とし、構成組み換えを試しています。

1台の同じApacheサーバーから、各インスタンスノード2つに接続し、ノードが切り替わった際のセッション維持状況を確認した結果です。

各テストごとにmod_proxy.confの接続先を、テスト対象ノードの2つに変更して実施しています。

Admin_A; Inst_A1, Inst_A2 ... OK

Admin_B; Inst_B1, Inst_B2 ... NG

Admin_A; Inst_B1, Inst_B2 ... OK

Admin_B; Inst_A1, Inst_A2 ... NG

「Admin_A」のpayaraディレクトリを「Admin_B」にコピー

Admin_B; Inst_B1, Inst_B2 ... NG

KVMホスト側で、「Admin_A」のKVMイメージを Admin_B のKVMホストにコピーし、「Admin_B」ノードを再構築

Admin_B; Inst_B1, Inst_B2 ... NG

KVMホスト側で、「Admin_B」のKVMイメージを Admin_A のKVMホストにコピーして起動

Admin_B; Inst_B1, Inst_B2 ... OK

同じApacheサーバーを使用して結果に差異が出ていますので、

Apacheやmod_proxy_ajpは大丈夫ではないかと考えています。

上記の結果より、Admin_B のKVMホストに原因がある可能性がでてきました。

しかし、他のKVMホストとの明確な違いが見つけられずにいます。

セッションレプリケーションを稼働させるために必要な設定、状態、または確認ポイント、あるべき通信状況など

お教え頂くことはできますでしょうか。

特に、KVMホスト上の仮想ノードの場合に必要となるものがありますと助かります。

また、セッションレプリケーションにおける管理サーバーの役割もお教え頂けますでしょうか。

セッションレプリケーションは、各インスタンスノードでレプリケーションし、管理サーバーは

仮に停止していても影響ないものと考えておりましたが、今回、おそらく管理サーバーの

状況によって、セッションレプリケーションができなくなっていると予想しています。

以上、よろしくお願い申し上げます。

[Kenji HASUNUMA]

斉藤様

蓮沼です。

セッションレプリケーションを稼働させるために必要な設定、状態、または確認ポイント、あるべき通信状況など

お教え頂くことはできますでしょうか。

特に、KVMホスト上の仮想ノードの場合に必要となるものがありますと助かります。

GlassFish 3.1以降、およびPayaraのShoalベース・クラスタ構成では、クラスタが正常に構築できた段階でセッションレプリケーションが稼働します（Apacheおよびmod_proxy_ajpの設定ミスで不具合が生じることはあるかもしれません）。

Shoalベース・クラスタのOS側必須要件は、おおよそ以下の通りとなります。

• ノードは物理・仮想マシンのいずれにも構築可能です。KVM特有の設定も存在しません。
  
• ノード構築時にsshが有効であること（面倒な場合はsshdの設定でrootでのパスワードログインを許可すると良いです）。ノード構築後は基本的にsshは不要となりますが、構成変更時に必要となるため設定は維持しておいた方が良いです。
  
• 各ノードのOSは、種類とバージョンを厳密に一致させておくのが望ましいです。異なるOS間でも「CONFIG」ノードという特殊なノードを構築することでクラスタを構成すること自体は可能ですが、動作は非常に危ういです。
  
• Shoalは同一サブネット内での動作が前提で、マルチキャストおよびブロードキャストを許可しておく必要があります。Solarisではその点は野放しのためそのまま繋がりますが、LinuxはSELinuxの関連で繋がらないケースがあるかもしれません。
  
• Shoalは通常のリクエストとノード間通信に同一のネットワーク回線を使用します。使用帯域はライバル製品より抑えられているはずですが、相応の負荷にはなるため、できるだけ高速なネットワークを用意してください。参考まで、私がSolarisで24ノードのクラスタを構築したときは、1000BASE-Tを用いても限界がありました（安価なNICに頼ったこともありますが）。

Shoalベースのクラスタの場合、クラスタさえ構築できていればデフォルトでセッションレプリケーションは有効になっています。Payara/GlassFishのクラスタはインメモリ・セッションレプリケーションだけをサポートしますが、完成度はかなり高いもので、正しく構築されていれば失敗することはまずありません（GlassFish v2やTomcatのセッションレプリケーションに関する情報の中には意味がなかったり、あるいは現行のPayara/GlassFishに有害な設定が含まれている可能性があるため注意してください）。

また、セッションレプリケーションにおける管理サーバーの役割もお教え頂けますでしょうか。

ドメイン管理サーバー(DAS)は、GlassFish のドメインとクラスタを管轄する中枢です。ドメイン共通の設定情報や、クラスタ構成情報のマスタは、すべてDASが保持しています（一応、クラスタの各インスタンスも構成情報の複製は持っています）。 Payara/GlassFishは最初にDASが起動し(DASの起動だけは asadmin start-domain コマンドで行います)、必要に応じてDASから各インスタンスを起動するような仕組みになっています。DASがクラスタに介入するのは、主にクラスタ構成を変更するときですが、それ以外にもクラスタ全体を制御する役割を担っています（セッションレプリケーションもそのうちのひとつ）。そのため、システム稼働中に安易にDASを停止することは現に慎まなければなりません。DASはドメインとクラスタの終了処理も行うため、Payara/GlassFishを停止する場合には asadmin stop-domain コマンドを使用するようにしてください（killコマンドによる終了は、asadminが反応しなくなったときの最終手段だと思ってください）。

DASはドメインに必ず 1 つだけ存在する特殊なノードです。ShoalベースのクラスタでDASを冗長化することは基本的にできないと思ってください。Hazelcastを用いて遠隔地にある同一構成のクラスタ間でフェールオーバーを成功させたという事例は存在しますが（日本マイクロソフトが今年のde:codeでデモをやったようです）、これは特殊な事例です。

DASが異なる＝ドメインが異なる＝クラスタも異なると見なして、それほど外してはいないと思います。今回の事例ではDASが2セット存在するように見えるのが非常に不可解なのですが、DASの冗長化を意図しているのでしょうか？DASの冗長化は、先の遠隔地フェールオーバーのような特殊例を除き、構成情報のコンフリクト等を起こしやすいため、行わないのが安全です。