サポート > リポジトリ > 環境 > クラスタリング環境で運用する

ビルドしたアプリケーションをクラスタリング環境で運用することができます。(ただしパブリッククラウドで運用する場合、もう一つの「オートスケール」運用を推奨します。)

オンプレミス環境もしくはAWS や Azure などのパブリッククラウド環境で、2台(以上)のインスタンスによる「クラスタリング」運用を行うことができます。負荷分散、耐障害性の向上につなげることができます。

図1 Wagbyのクラスタリング環境

特徴は次のとおりです。

ロードバランサは Sticky Session の設定が必要

ロードバランサでは Sticky Session を有効にしてください。利用者が最初にログオンしたインスタンスを記憶し、以降はログオフするまで同じインスタンスを使う必要があります。

セッション情報を共有しない

Wagby ではログオンする利用者ごとに「セッション」を作成します。セッションには利用者固有の情報が格納されており、ログオフするまでこれらは保持されています。

クラスタリング環境では、このセッション情報の共有を行いません。そのため、あるインスタンスがダウンしたとき、そのインスタンスの利用者は再ログオンを行って別のインスタンスに接続しなおす必要があります。

キャッシュの整合性

クラスタリング環境では、個々のインスタンスに割り当てられるIPアドレスを事前に指定します。インスタンスごとに保持しているキャッシュ情報の整合性を保つためにインスタンス同士で直接、メッセージをやりとりします。

"環境 > サーバ > クラスタリング" 欄を設定します。

図2 クラスタリングの設定
設定欄 説明
クラスタリング構成を使用する クラスタリングを行う場合、有効にしてください。
接続リトライ回数 クラスタリングサーバ同士で通信を行なっています。その通信が失敗したときのリトライ回数の上限を指定します。リトライがこの上限に達した場合、失敗したマシンはクラスタリング対象から除外されます。(後述する「クラスタリング管理」メニューで復帰させることができます。)
接続待機時間 リトライを行うためのインターバル時間を指定します。単位はミリ秒です。
サーバ名 クラスタリングを行うマシン名(ホスト名)を記載します。重複しないようにしてください。
IPアドレス 上記マシンのIPアドレスを指定します。ドメイン名を指定することはできません。
JMXポート 1024から65535の範囲で、適当な番号を割り当ててください。RMIポートと重複することはできません。(*1)(*2)
RMIポート 1024から65535の範囲で、適当な番号を割り当ててください。JMXポートと重複することはできません。(*1)(*2)
自サーバ ビルドしたアプリケーションが稼働するサーバを指定してください。このサーバはビルドしたアプリケーションをそのまま利用できます。このアプリケーションをコピーする2台目以降のサーバは手動で設定を変更する必要があります。[後述]
1. サーバ OS のファイアウォール機能を有効にしている場合、JMX ポート番号と RMI ポート番号の通信は 2 台のサーバ間で許可するようにして下さい。
2. すでに同一ネットワーク内で利用済みのポート番号は指定できません。どのポート番号が利用できるかの詳細は貴組織のネットワーク管理者にご相談ください。

3台のマシンでクラスタリングを行うテストの設定例を図3に示します。

図3 クラスタリングの設定例

次の手順で設定します。

1. ビルドされた wagbyappフォルダをコピーし、それぞれ wagbyapp2, wagbyapp3 とする。

2. ポート番号を変更する。wagbyapp2,wagbyapp3 の修正箇所は次の通り。

wagbyapp2

wagbyapp2/conf/server.xml

  • Server/@port=8005を18005に変更
  • Connector/@port=8921を18921に変更
  • Connector/@port=8009を18009に変更
  • Connector/@redirectPort=8443を18443に変更

wagbyapp2/webapps/wagby/WEB-INF/classes/jfccluster.properties

  • cluster_list.thismachine.1=trueをfalseに変更
  • cluster_list.thismachine.2=falseをtrueに変更

wagbyapp3

wagbyapp3/conf/server.xml

  • Server/@port=8005を28005に変更
  • Connector/@port=8921を28921に変更
  • Connector/@port=8009を28009に変更
  • Connector/@redirectPort=8443を28443に変更

wagbyapp3/webapps/wagby/WEB-INF/classes/jfccluster.properties

  • cluster_list.thismachine.1=trueをfalseに変更
  • cluster_list.thismachine.3=falseをtrueに変更

動作テスト

1. 3つの wagbyapp を起動します。

2. 異なるブラウザ(例 Chrome,Edge,IE) にて次のURLにアクセスし、adminでログオンします。

  • http://localhost:8921/wagby/
  • http://localhost:18921/wagby/
  • http://localhost:28921/wagby/

ロックテスト

  1. Chromeにてmodel1のデータを作成し、更新画面を開く。
  2. Edgeにて管理処理のロック情報管理にアクセスし、該当のデータがロックされていることを確認する。
  3. Edge,IEにてmodel1の更新画面を開こうとする。
  4. ロックされているというメッセージ表示される。[OK]

キャッシュテスト

  1. Chromeにてmodel1のデータを変更する。
  2. Edge,IEにてmodel1の詳細画面を再度表示する。
  3. キャッシュが自動的にクリアされて、Chromeにて修正した値が表示される。[OK]

クラスタリングの設定を有効にすると、メニューの「管理処理」に次の機能が追加されます。

クラスタ管理

現在のクラスタ構成のマシンの状況を表示します。 自マシンや他のマシンのロックをすべて解除できます。 自マシンが稼動していることを通知することができます。 自マシンにて認識している他のマシンの稼動情報を修正できます。

図4 クラスタ管理画面

ロック情報検索

現在どのマシンがどのデータをロックしているかを表示します。 ロック情報を1件づつ削除することができます。

ログオンユーザ管理

マシン名が表示されるようになります。

クラスタリング環境でロック方式を「悲観ロック」としたモデルは、悲観ロック情報をテーブルで管理するようになります。

Wagbyが提供するジョブスケジュールは、指定時刻になったとき、起動されているすべてのインスタンスでジョブが実行されます。(いずれか一つのインスタンスだけでジョブを実行するという制御は行えません。なおオートスケール環境ではこの制御に対応しています。