セッションリカバリ機能とは
セッションリカバリ機能は、Webコンテナのプロセスダウンまたはマシンダウンの場合に、他の運用中のWebコンテナでServletのセッション情報を引き継ぎ、Webアプリケーションの運用を継続して可能にする機能です。
セッション情報は、Webコンテナ内で、Webアプリケーション単位に管理されています。通常、Webコンテナがダウンした場合、そのコンテナ内に格納されたセッション情報は破棄されてしまいます。
セッションリカバリ機能を有効にすると、Webコンテナで生成されたセッション情報が、Session Registry Serverにバックアップされます。異常発生時には、他のWebコンテナにセッション情報をリカバリして引き継ぎ、継続して処理を行うことができます。
また、IJServerクラスタを再起動した場合に、再起動前のServletのセッションを破棄せずに継続して使用することも可能になります。
セッションのバックアップ
セッションのリカバリ
セッションリカバリ機能の構成要素
セッションリカバリ機能は、以下によって構成されています。
Session Registry Serverは、IJServerクラスタで使用しているServletのセッション情報を保存するサーバです。
障害発生時はSession Registry Serverからセッションをリカバリすることで障害発生前のセッション情報を使用し、Webアプリケーションを継続して運用することができます。
Webアプリケーションの実行環境です。
障害発生時にWebアプリケーションを継続して運用するためには多重プロセス、または、複数マシンで環境を構築する必要があります。
Session Registry Clientは、セッションリカバリ機能有効時、IJServerクラスタ(Webコンテナ)にアドインして従来のセッション管理モジュールにかわって動作し、セッションの管理とSession Registry Serverとの通信を行います。
Webサーバコネクタは、Webサーバが受けたリクエストをWebコンテナに転送する役割を持っています。
通常、Webサーバコネクタは、WebブラウザからのリクエストがServletのセッションを持っている場合は、そのセッションを作成したWebコンテナへリクエストを振り分けますが、何らかの原因でWebコンテナにリクエストを振り分けることができなかった場合は、他の運用可能なWebコンテナにリクエストを振り分けることでWebアプリケーションの継続運用を実現しています。
なお、Webサーバを経由しない運用も可能です。
参照
詳細については、「4.6 Webアプリケーションへアクセスする運用形態」を参照してください。
セッションは、Session Registry Serverにバックアップされます。Webコンテナの異常発生時には、Session Registry Serverにバックアップされたセッションを他のWebコンテナにリカバリすることで、他のWebコンテナでセッションを引き継ぎます。
セッションのバックアップの契機
セッションをバックアップする契機は、以下の2種類から選択できます。
リクエストの完了後にセッションをバックアップします。また、WebブラウザへのレスポンスはセッションがSession Registry Serverにバックアップされるのを待ってから完了します。
Webブラウザからのリクエストの処理時間にセッションのバックアップ時間も含まれるため、Webブラウザからのリクエストを処理する時間は一定間隔でバックアップする場合と比較して長くなります。
セッションはリクエスト処理が完了したあとに、Webコンテナによって定期的にバックアップされます。
リクエスト処理とは独立してバックアップが行われるため、個々のリクエスト返却までの性能には直接影響しません。
セッションがSession Registry Serverにバックアップされる前にWebコンテナがダウンした場合、そのセッションはリカバリすることができません。
設定方法
バックアップの契機は、Session Registry Client側のライフサイクルモジュールのプロパティ(backupMode)で設定します。デフォルト値は、「一定間隔でバックアップする」で、バックアップする間隔のデフォルト値は、5秒です。
バックアップの各契機について、以下の関係が成り立ちます。
|
参照
Session Registry Clientの設定については、「4.23.3 Session Registry Clientの設定」を参照してください。
セッションのバックアップに失敗した場合
セッションのバックアップに失敗した場合でも、Webブラウザ、および、Webアプリケーションへエラーの通知は行われません。これは、セッションのバックアップに失敗した場合、Webブラウザ、および、Webアプリケーションにエラーを通知するとセッションリカバリ機能を使用することがアプリケーションの稼働率を下げる要因となってしまうためです。
また、セッションのバックアップに失敗した場合は、以降Session Registry Serverは使用不可とマークされ、使用可能となるまで通信(バックアップ、リカバリ)を行いません。
参照
Session Registry Serverが使用可能になる契機については「2.28.1.4 セッションリカバリ機能の監視」を参照してください。
複数のリクエストでセッションを処理する場合
同じ1つのセッションを扱うすべてのリクエストは、同じ時間には1つのJavaVMで処理しなければならないと規約化されています。したがって、他のWebコンテナにセッションがリカバリされた場合、元のWebコンテナに残ったセッションを破棄する必要があります。
セッションを他のWebコンテナにリカバリする際に、Session Registry Serverは可能な限り、元のWebコンテナに残ったセッションを破棄しようとしますが、ネットワーク異常などで破棄できない可能性があります。その場合、残ったセッションは、そのWebコンテナとSession Registry Server間の通信の復旧時に破棄されます。
セッションのリカバリ処理
Webコンテナは、Webブラウザから通知されてきたセッションIDに該当するセッションを保持していない場合(もともとそのセッションを扱っていたWebコンテナがダウンした場合など)、他のコンテナによりバックアップされているセッションをSession Registry Serverから取得し、リクエストを処理します。
Session Registry Serverは、Webコンテナからセッションの取得要求があった場合、単にバックアップされたセッションを返すのではなく、以下の図のように可能な限り最新のセッションを返して、元のWebコンテナのセッションを破棄します。
Webサーバコネクタは、WebコンテナAにリクエストを送ろうとしましたが、WebコンテナAに障害が発生し、リクエストの送信に失敗しました。
Webサーバコネクタは、WebコンテナBにリクエストを振り分けます。
WebコンテナBに送られてきたセッションは、自分が所有するセッションではないため、WebコンテナBはSession Registry Serverにバックアップされたセッションの取得要求を行います。
Session Registry Serverは、セッションの元々の所有者であるWebコンテナAに最新のセッションを要求します。
WebコンテナAは、セッションをSession Registry Serverに受け渡します。
WebコンテナA上のセッションは、受け渡しにより破棄されます。
この時、HttpSessionListener.sessionDestroyed、HttpSessionBindingListener.valueUnBoundは呼び出されません。
Session Registry Serverは、この受け取った最新のセッションをWebコンテナBにリカバリします。
WebコンテナAとの通信に異常がある場合など、最新のセッションを取得できないときは、Session Registry ServerはすでにバックアップされているセッションをWebコンテナBにリカバリします。
また(4)において、該当の(セッションの元々の所有者である)Webコンテナとの通信ができない場合や、1つのWebコンテナに対する最新セッションの要求処理が高多重となった場合、Session Registry Serverはそれ以上の最新セッションの要求を行わずにSession Registry Serverにバックアップされているセッションを返します。そのため、必ずしも最新のセッションを取得(リカバリ)できるとは限りませんが、指定した契機でバックアップ済みのセッションはリカバリされます。
なお、(5)においてWebコンテナAでセッションを使用中であった場合、使用終了するまでセッションはバックアップされません。どれくらいの時間使用する可能性があるかはアプリケーション処理に依存するため、この最大待ち時間を指定することが可能です。
待ち時間を経過してもセッションを使用中である場合、セッションはWebコンテナBにリカバリされません。
このとき、getSession()、getSession(true)の場合は新規セッション、getSession(false)の場合はnullがアプリケーションに返却されます。
HttpSessionActivationListener
セッションに結びつけられているオブジェクトは、セッションの非活性化や活性化といったコンテナのイベントからの通知を受けることができます。Java VM間でセッションを移動させたりセッションを持続させたりするコンテナは、セッションに結びつけられている属性のうちHttpSessionActivationListener を実装しているすべての属性に通知することを要求されます。
イベント | メソッド | |
|---|---|---|
sessionWillPassivate | sessionDidActivate | |
リカバリ時 | 元のWebコンテナで実行 | リカバリ先のWebコンテナで実行 |
Webコンテナ停止時 | セッションをバックアップする前に実行 | － |
Webコンテナ起動時 | － | セッションがリカバリされた後に実行 |
セッションをリカバリできない場合
セッションリカバリ機能を使用していても、以下の場合、セッションがSession Registry Serverに存在しないため、セッションのリカバリはできません。
[Session Registry Serverで保持するセッションの上限数]を超えてバックアップが行われ、バックアップから破棄された(古い)セッションについてのリカバリが発生した場合
セッションのバックアップの契機を[一定間隔]としている場合に、バックアップされる前にWebコンテナがダウンした時
IJServerクラスタおよびセッションの永続化機能を無効としている場合に、Session Registry Serverを再起動した時
セッションの永続化機能を有効としている場合でも、指定した間隔で永続化が行われる前にSession Registry Serverがダウンし、かつWebコンテナを再起動した時
参照
リカバリされる範囲については、「2.28.2 セッションリカバリ機能のリカバリ範囲」も参照してください。
WebブラウザからのリクエストURIについて、拡張子を指定することにより、静的コンテンツなどに対してセッションリカバリ機能を無効にすることが可能です。
設定方法
セッションリカバリ機能を無効とする拡張子は、Session Registry Client側のライフサイクルモジュールのプロパティ(excludeExt)で設定します。
参照
Session Registry Clientの設定については、「4.23.3 Session Registry Clientの設定」を参照してください。
使用場面
この機能を使用する場面について説明します。
Webブラウザから静的コンテンツへのリクエストがあった場合でも、セッションのlastAccessedTime(セッションに関連付けられた要求をWebブラウザが最後に送信した時刻)が更新されます。これは、静的コンテンツもWebアプリケーションの一部として扱われるためです。
そのため、静的コンテンツに対するリクエストであってもセッションのバックアップが発生します。また、サーバダウンなどが発生した場合には、静的コンテンツに対してもセッションのリカバリが行われます。
しかし、アプリケーションにとって静的コンテンツへのアクセスによるlastAccessedTimeの更新が特に重要ではない場合、性能への影響の防止および不要なリカバリ処理を発生させないために、拡張子を指定することによりセッションのバックアップやリカバリを無効とすることが可能です。
注意
この定義を行ったリソースへアクセスした場合、Session Registry Serverへのバックアップは行われません。
したがって、この定義を行ったリソースだけにアクセスしている場合は、Session Registry Server上では、セッションがタイムアウトし、バックアップから削除される可能性があります。
フォームベース認証使用時には、認証情報はServletのセッションに格納されます。
そのため、以下の場合では、セッションは新規となり、再度認証が必要となることがあります。
セッションリカバリ機能が有効である、かつ
Session Registry Client(Webコンテナ)の[セッションリカバリ設定]において、[セッションを使用しないURLの末尾]として拡張子を指定している、かつ
Webブラウザから、指定した拡張子のコンテンツに対するリクエストを行った、かつ
IJServerクラスタの再起動などの操作を行った、または、IJServerクラスタの停止、異常終了などで、別のWebコンテナにリクエストが振り分けられた、かつ
該当コンテンツが認証の対象になっている。
Webアプリケーションの独自ヘッダ(独自のURLへの埋込み文字列)で負荷分散する場合の注意
次の図のような構成で、Cookieによりセッションを管理し、Webアプリケーションの独自ヘッダ(または独自のURLへの埋込み文字列)によって負荷分散を行う場合、静的コンテンツへのリクエストには、これら独自の値が付加されません。そのため、負荷分散装置は、Servletのセッションを生成したIJServerクラスタ以外のIJServerクラスタにリクエストを振り分けることがあります。この場合、IJServerクラスタは正常に動作しているにもかかわらず、セッションが他のIJServerクラスタにリカバリされることとなります。
そのため、セッションのリカバリが頻繁に動作し、レスポンスの低下を引き起こす原因となります。
アプリケーションの独自ヘッダで振り分けを行っている場合、静的コンテンツへのリクエストは、セッションAがついたリクエストであっても、WebサーバBにリクエストが振り分けられる可能性があります。
リクエストのセッションAは、IJServerクラスタBのものではないため、Webサーバコネクタは振り分け先がありません。その場合、任意のIJServerクラスタ(この場合IJServerクラスタB)に振られます。
(システム構成によっては、内部定義が同じでそのままIJServerクラスタBに振られる場合もあります。)
セッションAは、IJServerクラスタBには存在しないため、Session Registry ServerからセッションAを取得します。WebコンテナAのセッションAは、破棄されます。
上記のような負荷分散の場合、該当のコンテンツについては、セッションリカバリ機能を無効とする必要があります。
セッションリカバリ機能を使用する場合は、IJServerクラスタ、Session Registry Serverは相互に使用可能かどうかを監視します。
障害を検出した場合は、そのIJServerクラスタおよびSession Registry Serverは、使用不可にマークされ使用可能になるまで、処理対象からはずされます。
IJServerクラスタは、Session Registry Serverのポートに対して一定間隔(10秒)で監視用のメッセージを送付し、正常にレスポンスが返ることを確認します。
応答待ち時間(20秒)内にレスポンスが返らない場合、Session Registry Serverは使用不可にマークされセッションのバックアップ対象からはずされます。その後、使用不可にマークしたSession Registry Serverから正常にレスポンスが返るようになった場合、そのSession Registry Serverは使用可能とし、セッションのバックアップが行われます。
Session Registry Serverは、IJServerクラスタから一定間隔(30秒)以内ごとに監視用のメッセージが送付されてくることを確認します。
IJServerクラスタから監視用メッセージが送付されない場合は、そのIJServerクラスタは使用不可にマークされセッションリカバリ時の処理対象からはずされます。
Webサーバコネクタは、WebブラウザからのリクエストをWebコンテナに振り分ける時に初めてWebコンテナの異常を検出します。(Webサーバコネクタが異常を検出するには、数秒から数分かかる場合があります。)
また、Webサーバコネクタは、Webコンテナが復旧したことを検出することはできません。そのため、異常の検出から1分後に、再度Webコンテナへリクエストの振り分けを行います。この時、Webコンテナが復旧していない場合は再度接続に失敗します。
Webサーバコネクタの故障監視を使用することで上記問題を回避することができます。
Webサーバコネクタの故障監視は、IJServerクラスタとWebサーバをそれぞれ別のサーバマシンに分離して負荷分散運用を行う場合に、分散先のIJServerクラスタの稼動状況を監視し、故障したIJServerクラスタを自動的に振り分けの対象から除外することや、故障から復旧したIJServerクラスタを自動的に振り分けの対象に戻すことができます。
セッションリカバリ機能を使用する際は、Webサーバコネクタの故障監視とあわせて使用することをお勧めします。
参照
Webサーバコネクタの故障監視については、「2.8.2 Webサーバコネクタの故障監視」を参照してください。
メモリ不足などのリソース不足によるシステムダウンを回避するために、Session Registry Serverで保持するセッション数を制限することができます。
Session Registry Serverで保持するセッション数は、IJServerクラスタのJVMオプション「-Dcom.fujitsu.interstage.jservlet.sessionrecovery.backup.limit」で指定します。詳細は「4.23.2 Session Registry Serverの設定」を参照してください。
Session Registry Serverで保持しているセッションの数が指定された値を超えた場合は、最も長い間使用されていないセッションのバックアップを破棄し、代わりにバックアップ要求のあったセッションをSession Registry Serverに保持します。
バックアップが破棄されたセッションは、その後バックアップ要求があるまでSession Registry Serverにバックアップが存在しませんので、そのセッションに対するリカバリ要求があった場合(Webコンテナダウン時など)は、そのセッションはリカバリされません。
バックアップが破棄された場合でもセッション自体が破棄されたわけではないため、セッションのリカバリが必要な障害が発生しない限りはそのセッションについての業務は継続可能です。このとき、このセッションは使用されることにより再度バックアップされ、代わりに別の長時間未使用なセッションがバックアップから破棄されます。
Session Registry Serverにバックアップされたセッション情報を永続化することができます。永続化の有効・無効は、IJServerクラスタのJVMオプション「-Dcom.fujitsu.interstage.jservlet.sessionrecovery.session.store」で指定します。
参照
詳細については、「4.23.2.3 Session Registry Serverの環境設定」を参照してください。
セッションの永続化を有効にした場合、Session Registry Serverにバックアップされたセッションは永続化ファイルに書き出されます。
Session Registry Serverを再起動した場合は、永続化ファイルからセッションを読み込み、セッションを復元します。
また、セッションの永続化を有効にした場合はSession Registry Serverを停止する際にもセッションを永続化ファイルに書き出します。
セッションを永続化するタイミングを指定することができます。
Session Registry Serverは指定された間隔ごとにセッションを永続化します。
セッションの永続化ファイルの保管先はSession Registry Serverごとに任意のディレクトリを指定することができます。
指定したディレクトリ配下に「sr」というディレクトリが作成され、このディレクトリ配下に永続化ファイルが出力されます。すでに該当ディレクトリが存在する場合は、そのディレクトリをそのまま使用します。
Session Registry Serverは、セッションの永続化が有効である場合、起動後IJServerクラスタから通信があった時点でこれら永続化ファイルを読み込みます。
注意
セッションの永続化が行われる前にSession Registry Serverを再起動した場合は、最後にバックアップされたセッションの永続化ファイルからセッションが復元されます。
永続化に必要な時間は、以下に依存します。
また、前回の永続化の完了から指定された間隔の経過後、次の永続化が行われます。
セッションの属性に格納したオブジェクトのサイズ
生成/更新したセッションの数
ファイルシステムの性能
永続化機能使用時、以下の場合は、あらかじめ永続化ファイルを削除してください。
アプリケーションの運用を終了(アプリケーションを配備解除、IJServerクラスタを削除)する場合
永続化ファイルの保管先を変更する場合
Session Registry Serverを削除する場合
ただし、永続化ファイルの保管先ディレクトリがSession Registry Serverを配備したディレクトリ配下(デフォルト値含む)の場合は、自動的に削除されます。
Interstage Application Serverをアンインストールする場合
永続化ファイルの保管先にネットワークドライブやUNCパスは指定できません。
業務の初期化やメモリなどの資源を解放するために業務システム上のセッションをすべて消去したい場合、IJServerクラスタおよびSession Registry Serverをいったんすべて停止し、再起動してください。
セッションリカバリの機能上、個々に停止/再起動を行っただけでは、再バックアップや、バックアップされているセッションのリカバリが発生するため、すべてを消去することができません。
また、セッションの永続化の機能を有効としている場合は、永続化ファイルを削除してください。
セッションリカバリ機能が出力するログは、以下の2箇所に出力されます。
IJServerクラスタ
IJServerクラスタのサーバーログに、Session Registry Clientのエラーメッセージ、警告メッセージ、情報が出力されます。
Session Registry Server
Session Registry Serverが動作するIJServerクラスタのサーバーログに、Session Registry Serverのエラーメッセージ、警告メッセージ、情報が出力されます。
設定方法
それぞれのログの出力先、ログファイルのローテーション、ログを保管する世代数は、Interstage Java EE 7管理コンソールまたはasadminコマンドで設定します。
通常、Session Registry Serverは、IJServerクラスタからセッションが無効になったことを通知された時に保持しているセッションを破棄します。
しかし、IJServerクラスタがダウンしている場合は、セッションが無効になったことがIJServerクラスタから通知されないため、不要なセッションがSession Registry Serverに残り、Session Registry Serverのリソースを圧迫します。
そのため、Session Registry Serverは保持しているセッションを一定間隔で監視し、期限切れ(タイムアウト)となっているセッションを破棄することでリソースの圧迫を防ぎます。この監視間隔は、デフォルトでは60秒です。
監視間隔は、IJServerクラスタのJVMオプション「-Dcom.fujitsu.interstage.jservlet.sessionrecovery.clean.interval」で指定します。
この監視機能では、期限切れセッションを単に削除しているだけであるため、IJServerクラスタがダウンしてSession Registry Serverだけにセッションが存在する場合には、以下のセッション破棄関連処理が実行されません。
javax.servlet.http.HttpSessionListener#sessionDestroyed(javax.servlet.http.HttpSessionEvent)
javax.servlet.http.HttpSessionAttributeListener#attributeRemoved(javax.servlet.http.HttpSessionBindingEvent)
javax.servlet.http.HttpSessionBindingListener#valueUnbound(javax.servlet.http.HttpSessionBindingEvent)
上記の処理を実行する必要がある場合は、IJServerクラスタのJVMオプションに以下を指定することにより、Session Registry Serverだけに存在する期限切れセッションを、生存しているIJServerクラスタに送信し、IJServerクラスタでセッション破棄関連処理を実行させることができます。
-Dcom.fujitsu.interstage.jservlet.sessionrecovery.invalid.session.send
-Dcom.fujitsu.interstage.jservlet.sessionrecovery.invalid.session.waiting.time
参照
詳細は「4.23.2.3 Session Registry Serverの環境設定」を参照してください。
Session Registry Serverには、Webコンテナからのバックアップやリカバリ要求の通信を受け付けるためのIPアドレス(図中１・マシンDのIPアドレス)とポート番号を指定します。このとき、通信を許可する相手(Webコンテナ)のIPアドレス(図中マシンB、CのIPアドレス)を指定することにより、指定以外のIPアドレスからの不正な通信を受け付けないようIPアドレスによるアクセス制限を行うことが可能です。
参照
Session Registry Serverの設定については、「4.23.2 Session Registry Serverの設定」を参照してください。また、設定方法の詳細については「8.8.2 HTTPサービスの定義項目」を参照してください。
セッションリカバリ機能を使用する場合は、Session Registry Client側のIJServerクラスタに制御用ポート(図中1、2)を設定する必要があります。
制御用ポートはSession Registry Serverからの要求を処理するために使用します。
また、制御用ポートは通信を許可する相手(本機能の場合はSession Registry Server)のIPアドレス(図中のマシンDのアドレス)を指定することにより、指定以外のIPアドレスからの不正な通信を受け付けないようIPアドレスによるアクセス制限を行うことが可能です。
参照
制御用ポートの設定方法については、「4.23.3 Session Registry Clientの設定」を参照してください。
