JP6374362B2 - 呼処理装置、セッション復旧方法及び呼処理サーバプログラム - Google Patents

Description

本発明は、呼処理装置、セッション復旧方法及び呼処理サーバプログラムに関する。

近年、ネットワークシステムにおいて、通信サービスに係る呼を処理する呼処理サーバと、通信サービスの加入者データを格納する加入者データサーバとを連携させた加入者データサーバ連携方式が提唱されている。呼処理サーバは、サーバリソースの集約及び効率的利用によるコスト削減のために仮想化基盤上で動作する仮想マシンで実現される。そして、呼処理サーバは、高可用性を確保するためにスナップショットが定期的に取得される。スナップショットは、取得時点での仮想マシン上で動作する呼処理サーバのディスクイメージ及びメモリイメージを含む。呼処理サーバは、障害が発生した際には、最新のスナップショットからディスクイメージ及びメモリイメージが復元されることで、障害から復旧される。

3GPP（登録商標） TS 23.228 v13.2.0（2015-03） 3rd Generation Partnership Project；Technical Specification Group Services and System Aspects；IP Multimedia Subsystem(IMS)；Stage2（Release13）、［online］、3GPP、［平成２７年７月７日検索］、インターネット＜ＵＲＬ：http://www.3gpp.org/ftp/Specs/archive/23_series/23.228/23228-d20.zip＞

しかしながら、上記技術では、呼処理サーバは、障害復旧の際に、スナップショット取得時点での状態で復旧される。このため、ステートフルサーバである呼処理サーバは、対向する呼処理サーバ等の対向装置との間で、状態矛盾が発生したり、セッションの有効期限を示すセッションタイマの更新ができずにセッションが切断されたりするという問題がある。状態矛盾は、例えば、現在は存在しないセッションが復旧される等である。

本願が開示する実施形態の一例は、呼処理サーバの障害復旧の際に、対向装置との間で状態矛盾の発生防止を目的とする。

本願の実施形態の一例において、呼処理装置は、記憶部、判定部、復旧処理部を備える。記憶部は、対向装置とのセッションに係るセッション情報と、加入者データを記憶する。判定部は、自呼処理装置がスナップショットから復旧されたものである場合に、スナップショットの取得時刻から現在時刻までの経過時間が所定閾値以下であるか否かを判定する。復旧処理部は、判定部により経過時間が所定閾値以下であると判定された際に、セッション情報毎に、対向装置に対してセッションの更新要求を送信し、更新要求に対して対向装置から正常応答があった場合にはセッションを更新し、更新要求に対して対向装置から正常応答以外の応答があった場合にはセッションを切断してセッションに割り当てられたコンピュータリソースを解放する。また、復旧処理部は、判定部により経過時間が所定閾値を越えると判定された際に、記憶部に記憶されている全てのセッション情報についてセッションを切断してセッションに割り当てられたコンピュータリソースを解放する。

本願が開示する実施形態の一例によれば、例えば、呼処理サーバの障害復旧の際に、対向装置との間で状態矛盾が発生することを防止できる。

図１は、実施形態に係るネットワークシステムの一例を示す図である。 図２Ａは、実施形態に係る加入者データの一例を示す図である。 図２Ｂは、実施形態に係るセッション情報の一例を示す図である。 図３Ａは、実施形態に係るセッション復旧処理の一例を示すシーケンス図である。 図３Ｂは、実施形態に係るセッション復旧処理の一例を示すシーケンス図である。 図４は、実施形態に係るスナップショット取得間隔とＣＰＵ使用率との関係の一例を示す図である。 図５は、実施形態に係るスナップショット取得間隔とスナップショット数との関係の一例を示す図である。 図６は、プログラムが実行されることにより、実施形態に係る呼処理サーバが実現されるコンピュータの一例を示す図である。

以下、本願が開示する呼処理装置、セッション復旧方法及び呼処理サーバプログラムの実施形態の一例について、図面を参照して説明する。なお、以下の実施形態により、本願が開示する技術が限定されるものではない。また、以下の実施形態及びその他の実施形態は、適宜組合せてもよい。

（実施形態に係るネットワークシステム）
図１は、実施形態に係るネットワークシステムの一例を示す図である。実施形態に係るネットワークシステム１は、仮想化基盤上でのサーバ運用技術、例えばＫＶＭ（Kernel-based Virtual Machine）、VMware vSphere（登録商標）等により呼処理サーバが実現されるＩＰ（Internet Protocol）電話サービスシステムである。また、ネットワークシステム１は、３ＧＰＰにより提唱されている次世代ネットワーク（IP Multimedia Subsystem）である、加入者データ原本を格納する加入者データサーバと呼処理制御を行う呼処理制御サーバとを連携した加入者データサーバ連携方式による呼処理方式を前提とする。

ネットワークシステム１は、ＩＰ電話端末２、物理サーバ１００、対向呼処理サーバ２００、加入者管理サーバ３００、対向ＩＰ電話端末３を含む。ＩＰ電話端末２は、物理サーバ１００と所定通信回線を介して接続される。また、物理サーバ１００は、対向呼処理サーバ２００と所定通信回線を介して接続される。また、物理サーバ１００は、加入者管理サーバ３００と所定通信回線を介して接続される。また、対向ＩＰ電話端末３は、対向呼処理サーバ２００と所定通信回線を介して接続される。

なお、図１では、ＩＰ電話端末２、物理サーバ１００、対向呼処理サーバ２００、加入者管理サーバ３００、対向ＩＰ電話端末３の数は、それぞれ１つのみ示すが、複数であってもよい。

ＩＰ電話端末２及び対向ＩＰ電話端末３は、加入者がＩＰ電話サービスを利用する際に用いられる端末である。

物理サーバ１００は、ホストＯＳ（Operating System）上のゲストＯＳ上で稼働する仮想マシンにて呼処理サーバが実現されるサーバ装置である。物理サーバ１００は、１以上のＣＰＵ（Central Processing Unit）等の処理装置、１以上のＲＡＭ（Random Access Memory）等の一時記憶装置、１以上のＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等の外部記憶装置を含んで構成される。

物理サーバ１００は、ホストＯＳ実行部１１０、ゲストＯＳ実行部１２０を含む。ホストＯＳ実行部１１０及びゲストＯＳ実行部１２０は、物理サーバ１００の物理資源を共有する。すなわち、ゲストＯＳ実行部１２０は、物理サーバ１００の全物理資源のうち、ホストＯＳ実行部１１０に用いられる部分以外を用いる。なお、図１では、ホストＯＳ実行部１１０及びホストＯＳ実行部１１０上で動作するゲストＯＳ実行部１２０は、１つのみ示すが、複数であってもよい。

ホストＯＳ実行部１１０は、スナップショット取得部１１１、スナップショット記憶部１１２、障害復旧処理部１１３を含む。スナップショット取得部１１１は、ゲストＯＳ実行部１２０又は後述の呼処理サーバ実行部１３０の実行中イメージであるメモリ状態及びディスク状態等のスナップショットを、取得間隔ｔで取得する。スナップショット取得部１１１は、取得した最新のスナップショットを、取得日時とともに、スナップショット記憶部１１２へ保存する。なお、取得間隔ｔについては、後述する。

障害復旧処理部１１３は、呼処理サーバ実行部１３０において障害が発生すると、スナップショット記憶部１１２に保存されるスナップショットを用いて、呼処理サーバ実行部１３０を復旧後、再稼働させる。障害復旧処理部１１３により再稼働された呼処理サーバ実行部１３０の記憶部１３２が保存する後述の加入者データ１３２ａ及びセッション情報１３２ｂは、スナップショットにより復旧されたデータとなる。そして、障害復旧処理部１１３は、再稼働させた呼処理サーバ実行部１３０に対して、スナップショットを用いて復旧されたことを示す、スナップショットの取得日時を含む復旧通知を通知する。

ゲストＯＳ実行部１２０は、ホストＯＳ実行部１１０上で動作する仮想マシンである。ゲストＯＳ実行部１２０は、呼処理サーバ実行部１３０を含む。呼処理サーバ実行部１３０は、呼処理部１３１、記憶部１３２、セッション復旧処理部１３３を含む。呼処理部１３１は、例えばＩＰ電話端末２及び対向ＩＰ電話端末３間のＩＰ電話通信サービスのセッションに係る呼を処理する。

記憶部１３２は、加入者データ１３２ａ及びセッション情報１３２ｂを記憶する。記憶部１３２は、呼処理サーバ実行部１３０の起動時は、加入者データ１３２ａ及びセッション情報１３２ｂを保持していない。呼処理部１３１は、INVITE/REGISTERの受信時、加入者データの原本を格納する加入者管理サーバ３００へアクセスして加入者データを取得後、記憶部１３２へ保存する。以後、呼処理部１３１は、記憶部１３２へ保存した加入者データ１３２ａを用いて呼処理を実行する。記憶部１３２は、一度保存した加入者データを呼処理終了後も保持し続けてもよい。この場合、呼処理部１３１は、INVITE/REGISTERの受信時、記憶部１３２に保存されている加入者データ１３２ａを参照して呼処理を実行する。また、呼処理部１３１は、確立したセッションに係るセッション管理情報をセッション情報１３２ｂにて管理する。なお、呼処理サーバ実行部１３０と、加入者管理サーバ３００とは、多対多での接続が可能である。

図２Ａに一例を示すように、加入者データ１３２ａは、加入者単位で、加入者ＩＤ、更新フラグ、加入者情報、その他の情報を含む。加入者ＩＤは、加入者の識別情報である。更新フラグは、後述するセッション復旧処理における加入者情報の最新化処理の完了及び未完了を示すフラグである。加入者情報は、ユーザ毎の契約情報、例えば留守番サービス契約している、転送サービス契約している等の情報である。図２Ａでは、加入者ＩＤ、更新フラグ、加入者情報以外の情報は、図示を省略している。また、図２Ｂに一例を示すように、セッション情報１３２ｂは、セッション単位で、セッションＩＤ、セッション管理情報、その他の情報を含む。セッションＩＤは、セッションの識別情報である。セッション管理情報は、呼処理サーバ実行部１３０を介したＩＰ電話サービスに係るセッションを管理する情報であり、例えば当該セッションに係るＩＰ電話端末や呼処理サーバの接続情報、セッションの有効期限を示すセッションタイマ等を含む。図２Ｂでは、セッションＩＤ、セッション管理情報以外の情報は、図示を省略している。

セッション復旧処理部１３３は、ホストＯＳ実行部１１０の障害復旧処理部１１３から、復旧通知を通知されると、復旧された加入者データ１３２ａの更新フラグを全てＯＮ（ビット１）にする。そして、セッション復旧処理部１３３は、復旧通知に含まれるスナップショットの取得日時と、現在日時との差分を算出する。そして、セッション復旧処理部１３３は、スナップショットの取得日時と、現在日時との差分が所定閾値Ｔｈ以下であるか否かを判定する。所定閾値Ｔｈは、運用サービスの特性上、復旧を要するセッションが存在するか否かを判定する閾値であり、サービスの種別に応じて適宜定められる閾値である。

セッション復旧処理部１３３は、スナップショットの取得日時と、現在日時との差分が所定閾値Ｔｈ以下である場合には、復旧された呼処理サーバ実行部１３０が記憶部１３２のセッション情報１３２ｂに保持するセッション（例えばセッションタイマが０でないセッション）について、対向呼処理サーバ２００又は対向ＩＰ電話端末３に対してセッションの更新を要求し、更新要求に対する正常応答を用いてセッション情報１３２ｂに保持されているセッションを更新する。セッションの更新は、有効期限、ＩＰ電話端末２及び対向ＩＰ電話端末３の接続情報等を含むセッション管理情報の更新や、その他の情報の更新を含む。

セッション復旧処理部１３３は、スナップショットの取得日時と、現在日時との差分が所定閾値Ｔｈより大である場合には、復旧された呼処理サーバ実行部１３０には復旧を要するセッションが存在しないと判定し、記憶部１３２のセッション情報１３２ｂに保持されている全てのセッションを切断し、切断したセッションに割り当てられていた全てのリソース（物理サーバ１００の物理資源）を解放する。また、セッション復旧処理部１３３は、復旧された呼処理サーバ実行部１３０が記憶部１３２のセッション情報１３２ｂに保持するセッションについて、対向呼処理サーバ２００又は対向ＩＰ電話端末３に対してセッションの更新を要求したが、更新要求に対して正常応答以外の応答を受信した場合も、当該セッションを切断し、当該セッションに割り当てられていたリソースを解放する。

また、セッション復旧処理部１３３は、復旧された呼処理サーバ実行部１３０の記憶部１３２が保持する加入者データ１３２ａのうち、更新フラグがＯＮ（ビット１）かつセッションが張られていない全ての加入者データについて、加入者管理サーバ３００に対して最新の加入者データを問合わせた結果をもとに、加入者データ１３２ａを更新する。また、セッション復旧処理部１３３は、復旧された呼処理サーバ実行部１３０の記憶部１３２が保持する加入者データ１３２ａのうち、呼処理部１３１がＩＰ電話端末２から新たに受け付けたセッション開始要求に該当する加入者データについて、更新フラグが１である場合に、加入者管理サーバ３００に対して最新の加入者データを問合わせた結果をもとに、加入者データ１３２ａを更新する。

呼処理部１３１は、上記のようにして最新化された加入者情報１３２ａ及び更新されたセッション情報１３２ｂを用いて処理を継続する。

（実施形態に係るセッション復旧処理）
図３Ａ及び図３Ｂは、実施形態に係るセッション復旧処理の一例を示すシーケンス図である。先ず、図３Ａにおいて、ホストＯＳ実行部１１０は、取得間隔ｔで、呼処理サーバ実行部１３０のスナップショットを取得する（ステップＳ１１）。ホストＯＳ実行部１１０は、ステップＳ１１の処理を取得間隔ｔで繰り返す。

ホストＯＳ実行部１１０は、呼処理サーバ（呼処理サーバ実行部１３０）の障害を検知すると（ステップＳ１２）、スナップショット記憶部１１２に保存される最新のスナップショットを用いて、障害を検知した呼処理サーバ（呼処理サーバ実行部１３０）を復旧、再稼働させる（ステップＳ１３）。そして、ホストＯＳ実行部１１０は、再稼働させた呼処理サーバ実行部１３０に対して、スナップショット取得日時を含む復旧通知を送信する（ステップＳ１４）。

呼処理サーバ実行部１３０は、ホストＯＳ実行部１１から復旧通知を受信すると、呼処理サーバ実行部１３０がスナップショットから復旧されたことを認識して、加入者データ１３２ａの更新フラグを全てＯＮ（ビット１）にする（ステップＳ１５）。次に、呼処理サーバ実行部１３０は、スナップショットの取得日時と、現在日時との差分時間Ｔを計算する（ステップＳ１６）。次に、呼処理サーバ実行部１３０は、差分時間Ｔが所定閾値Ｔｈ以下であるか否かを判定する（ステップＳ１７）。呼処理サーバ実行部１３０は、差分時間Ｔが所定閾値Ｔｈ以下である場合（ステップＳ１７：Ｙｅｓ）、ステップＳ１８へ処理を移す。一方、呼処理サーバ実行部１３０は、差分時間Ｔが所定閾値Ｔｈより大である場合（ステップＳ１７：Ｎｏ）、ステップＳ２３へ処理を移す。

ステップＳ１８では、呼処理サーバ実行部１３０は、差分時間Ｔが所定閾値Ｔｈ以下であるため、復旧すべき有効なセッションが存在する可能性があることから、セッション情報１３２ｂが保持するセッションについて、該当セッションの更新要求（例えばINVITE or UPDATE）を、該当の対向呼処理サーバ２００又は対向ＩＰ電話端末３へ送信する。そして、呼処理サーバ実行部１３０は、対向呼処理サーバ２００又は対向ＩＰ電話端末３から、セッションの更新要求に対する応答（例えば200 or それ以外）を受信する（ステップＳ１９）。

次に、呼処理サーバ実行部１３０は、ステップＳ１９で受信した応答が正常応答（例えば200）であるか否かを判定する（ステップＳ２０）。呼処理サーバ実行部１３０は、受信した応答が正常応答である場合（ステップＳ２０：Ｙｅｓ）、ステップＳ２１へ処理を移す。一方、呼処理サーバ実行部１３０は、受信した応答が正常応答でない場合（ステップＳ２０：Ｎｏ）、ステップＳ２２へ処理を移す。ステップＳ２０：Ｙｅｓ、すなわち、受信した応答が正常応答である場合は、対向呼処理サーバ２００又は対向ＩＰ電話端末３において該当セッションは存在しており、ステップＳ１８のセッションの更新要求によりセッションタイマの更新も完了している場合である。また、ステップＳ２０：Ｎｏ、すなわち、受信した応答が正常応答でない場合は、対向呼処理サーバ２００又は対向ＩＰ電話端末３において該当セッションは既に存在しない場合である。

ステップＳ２１では、呼処理サーバ実行部１３０は、ステップＳ１９で対向呼処理サーバ２００又は対向ＩＰ電話端末３から受信した応答に含まれるセッション情報をもとにセッション情報１３２ｂの該当セッションを更新（最新化）する。呼処理サーバ実行部１３０は、ステップＳ２１の処理が終了すると、ステップＳ２４へ処理を移す。一方、ステップＳ２２では、呼処理サーバ実行部１３０は、ステップＳ１９で受信した正常でない応答に該当するセッションに割り当てられた物理サーバ１００のリソース（物理資源）を解放する。呼処理サーバ実行部１３０は、ステップＳ１８〜Ｓ１９の処理を、セッション情報１３２ｂに保存される保持セッション分だけ繰り返す。

他方、ステップＳ２３では、呼処理サーバ実行部１３０は、差分時間Ｔが所定閾値Ｔｈより大であるため、復旧すべき有効なセッションが存在しないと判定されるため、加入者データ１３２ａに保存される全ての加入者データについて張られていたセッションを切断し、切断したセッションに割り当てられていた物理サーバ１００のリソース（物理資源）を解放する。ステップＳ２３の処理が終了すると、呼処理サーバ実行部１３０は、ステップＳ２４へ処理を移す。

ステップＳ２４では、呼処理サーバ実行部１３０は、新規セッション開始要求を受け付けたか否かを判定する。呼処理サーバ実行部１３０は、新規セッション開始要求を受け付けた場合（ステップＳ２４：Ｙｅｓ）、ステップＳ３１（図３Ｂ）へ処理を移す。一方、呼処理サーバ実行部１３０は、新規セッション開始要求を受け付けていない場合（ステップＳ２４：Ｎｏ）、ステップＳ２５へ処理を移す。なお、ステップＳ２４は、呼処理サーバ実行部１３０は、加入者データ１３２ａのうち、受け付けた新規セッション開始要求に該当する加入者データについてステップＳ３１〜Ｓ３９の処理を実行し、その他の加入者データについてステップＳ２５〜Ｓ２８の処理を実行し、ステップＳ２５〜Ｓ２８と、ステップＳ３１〜Ｓ３９とを並行して実行することを示す。

ステップＳ２５では、呼処理サーバ実行部１３０は、加入者データ１３２ａに保持される加入者データのうちの１つの加入者データについて、更新フラグがＯＮ（ビット１）かつセッションが張られていないかを判定する。呼処理サーバ実行部１３０は、更新フラグがＯＮ（ビット１）かつセッションが張られていない場合（ステップＳ２５：Ｙｅｓ）、ステップＳ２６へ処理を移す。一方、呼処理サーバ実行部１３０は、更新フラグがＯＦＦ（ビット０）又はセッションが張られている場合（ステップＳ２５：Ｎｏ）、セッション復旧処理を終了する。

ステップＳ２６では、呼処理サーバ実行部１３０は、加入者管理サーバ３００に対して、加入者データ要求（SAR）を送信する。そして、呼処理サーバ実行部１３０は、加入者管理サーバ３００から、加入者データ要求（SAR）に対する応答である最新の加入者データを受信（SAA）する（ステップＳ２７）。そして、呼処理サーバ実行部１３０は、受信した加入車データで加入者データ１３２ａを最新化し、加入者データ１３２ａの該当加入者データの更新フラグをＯＦＦ（ビット０）にする（ステップＳ２８）。ステップＳ２８が終了すると、呼処理サーバ実行部１３０は、セッション復旧処理を終了する。呼処理サーバ実行部１３０は、ステップＳ２６〜Ｓ２７の処理を、加入者データ１３２ａに保存される加入者データ分だけ繰り返す。

一方、ステップＳ３１では、呼処理サーバ実行部１３０は、対向呼処理サーバ２００又は対向ＩＰ電話端末３から、新規リクエスト（INVITE or REGISTER）を受信する。そして、呼処理サーバ実行部１３０は、対向呼処理サーバ２００又は対向ＩＰ電話端末３に対して、ステップＳ３１の新規リクエスト（INVITE or REGISTER）に対する応答として、100 Trying（INVITE）を送信する（ステップＳ３２）。なお、呼処理サーバ実行部１３０と、対向呼処理サーバ２００又は対向ＩＰ電話端末３とは、ステップＳ３２とステップＳ３３との間で中継信号の送受信を行うが、図示を省略している。

次に、呼処理サーバ実行部１３０は、加入者データ１３２ａに保持される加入者データのうち、ステップＳ３２で送信した100 Trying（INVITE）に該当する加入者データの更新フラグがＯＮ（ビット１）であるか否かを判定する（ステップＳ３３）。呼処理サーバ実行部１３０は、ステップＳ３２で送信した100 Trying（INVITE）に該当する加入者データの更新フラグがＯＮ（ビット１）である場合（ステップＳ３３：Ｙｅｓ）、ステップＳ３４へ処理を移す。一方、呼処理サーバ実行部１３０は、ステップＳ３２で送信した100 Trying（INVITE）に該当する加入者データの更新フラグがＯＦＦ（ビット０）である場合（ステップＳ３３：Ｎｏ）、ステップＳ３７へ処理を移す。

ステップＳ３４では、呼処理サーバ実行部１３０は、加入者管理サーバ３００に対して、加入者データ要求（SAR）を送信する。そして、呼処理サーバ実行部１３０は、加入者管理サーバ３００から、加入者データ要求（SAR）に対する応答である最新の加入者データを受信する（SAA）（ステップＳ３５）。そして、呼処理サーバ実行部１３０は、受信した加入車データで加入者データ１３２ａを最新化し、加入者データ１３２ａの該当加入者データの更新フラグをＯＦＦ（ビット０）にする（ステップＳ３６）。ステップＳ３６が終了すると、呼処理サーバ実行部１３０は、ステップＳ３７へ処理を移す。

ステップＳ３７では、呼処理サーバ実行部１３０は、対向呼処理サーバ２００又は対向ＩＰ電話端末３に対して、180 Ringing（INVITE）を送信する。そして、呼処理サーバ実行部１３０は、ステップＳ３７で送信した180 Ringing（INVITE）に引き続き、対向呼処理サーバ２００又は対向ＩＰ電話端末３に対して、200 OK（INVITE or REGISTER）を送信する（ステップＳ３８）。そして、呼処理サーバ実行部１３０は、対向呼処理サーバ２００又は対向ＩＰ電話端末３から、ステップＳ３８で送信した200 OK（INVITE or REGISTER）に対する応答として、ACK（INVITE）を受信する（ステップＳ３９）。ステップＳ３９以降、呼処理サーバ実行部１３０と、対向呼処理サーバ２００又は対向ＩＰ電話端末３とは、ＳＩＰシーケンスを実行するが、図示を省略している。ＳＩＰシーケンスが終了すると、セッション復旧処理は終了する。

（実施形態に係るスナップショット取得間隔とＣＰＵ使用率との関係）
図４は、実施形態に係るスナップショット取得間隔とＣＰＵ使用率との関係の一例を示す図である。スナップショットに使用可能なＣＰＵリソースは、スナップショット取得間隔に連動する。ここで、図４に示すように、スナップショットを取得する取得間隔をｔとする。また、スナップショットを取得開始して取得完了するまでに要する１回あたりの取得に要する時間をＴとする。また、スナップショットを取得しないときのＣＰＵリソースの使用率を１としたときの、スナップショットを取得する際に使用するＣＰＵリソースの使用率の上昇割合をＣとする。すると、呼処理サービスに使用可能なＣＰＵリソースの割合は、下記の（１）式により見積もることができる。

ここで、呼処理サービスで使用可能な物理サーバ１００のＣＰＵリソースの割合は、冗長化方式の種類（例えばＡＣＴ−ＳＢＹ方式やＮ−ＡＣＴ方式等）により変化するため、ここでは変数αとする。変数αは、冗長化方式の種類によって定まる所定数（０＜α＜１）である。よって、上記の（１）式で示される呼処理サービスに使用可能なＣＰＵリソースの割合が、下記の（２）式で示されるように、α以上であれば、スナップショット方式が効率的であると評価できる。

上記の（２）式をｔについて変形すると、下記の（３）式に示すように、取得間隔ｔの下限が求まる。

なお、上記の（３）式は、ＣＰＵリソースに基づいて算出した評価式であるが、ＣＰＵリソースに限らず、ＣＰＵ使用率、メモリ使用率、外部記憶装置の使用率、メモリアクセス時間、外部記憶装置のアクセス時間等、１以上のハードウェアリソースのスループット（性能指標）に基づいて同様に算出してもよい。

（実施形態に係るスナップショット取得間隔とスナップショット数との関係）
図５は、実施形態に係るスナップショット取得間隔とスナップショット数との関係の一例を示す図である。呼処理サーバが故障した場合、セッションの有効期限内（セッションタイマ満了前）に復旧させることができなければ、対向する他の呼処理サーバやＩＰ電話端末によってセッションが切断される。

ここで、セッション開始後の初回のスナップショットを取得するまでの間に呼処理サーバに故障が発生した場合、セッション情報がスナップショットに含まれていないため、該当セッションを復旧させることができない。また、スナップショットの取得間隔ｔが大きいほど、スナップショット方式におけるＣＰＵリソースの使用効率は良くなるが、初回のスナップショットを取得するまでの時間が長くなるため、スナップショットに含まれないセッションが多くなる。

例えば、図５に示すタイミングでセッションタイマが開始、更新され、終了するセッションの場合、タイミングＢで呼処理サーバの故障発生の場合は、該当セッションは（ｎ＋１回目）のスナップショットに含まれるため、復旧できる。しかし、タイミングＡで呼処理サーバの故障発生の場合は、該当セッションは（ｎ回目）のスナップショットに含まれないため、復旧できない。

すなわち、セッションの生起以降、スナップショットに含まれないセッション数は、セッション平均生起率（呼/秒）と初回のスナップショット取得間隔の積（＝スナップショット取得間隔内に生起されるセッション数）で算出できる。よって、取得間隔をｔ、平均セッション保持時間をｔ_ｓ、セッション平均生起率をｘ、スナップショットに含まれないセッションの割合の上限値をｒ（ただし、ｔ_ｓ、ｘは、サービスの特性により定まり、ｒはスナップショットの要求品質により定まる）とすると、下記の（４）式のように、スナップショットに含まれないセッションの割合の評価式が導かれる。

上記の（４）式をｔについて変形すると、下記の（５）式のようになる。

よって、上記の（３）式及び（５）式から、下記の（６）式のように、取得間隔ｔの評価式が求まる。下記の（６）式において、取得間隔ｔは、上限により近い値であればあるほど、ＣＰＵリソース効率が高まる一方、下限により近い値であればあるほど、スナップショットに含まれないセッションの数を減らすことができスナップショットの品質を高めることができる。すなわち、取得間隔ｔは、要求仕様に応じて、下記の（６）式の範囲内で適宜定めることができる。

呼処理サーバの運用において、呼処理サーバの可用性は確保したいが、ＡＣＴ−ＳＢＹやＮ−ＡＣＴ等の冗長化方式では、別の待機サーバを準備するコストがかかる。そこで、実施形態では、ハードウェアコストを低減するために、仮想化基盤を利用し、仮想化基盤上で動作する仮想マシンにより呼処理サーバを実現する。また、実施形態では、呼処理サーバの可用性を実現するために、定期的に呼処理サーバのスナップショットを取得し、呼処理サーバの故障等で呼処理サービスが停止した場合に、スナップショットから復旧させる。

しかし、スナップショットから復旧させる方式では、スナップショット取得時点での状態で復旧されるため、呼処理サーバ等のステートフルサーバでは、対向装置との状態矛盾（現在は存在しないセッションが復旧される）が発生したり、セッションタイマ（セッションの有効期限）の更新ができずにセッションが切断されたりする可能性がある。

また、スナップショット取得後に生起したセッションは復旧できないことから、復旧できるセッション数を増加させるために、スナップショットの取得間隔を小さくする方法があるが、スナップショットの取得間隔を小さくすることによりスナップショット取得に多くのＣＰＵリソースが使用され、呼処理サービスで使用可能なＣＰＵリソースが少なくなる。

そこで、実施形態は、スナップショットからの復旧後、スナップショットの取得時刻と現在時刻の差分からセッション整合要否を判定する。そして、実施形態は、整合が必要な場合、対向装置にセッション更新要求を送信し、その応答により復旧された呼処理サーバの内部状態の合わせこみを行う。

また、実施形態は、「スナップショットの取得間隔に対する復旧できないセッション数」、「スナップショットの取得間隔に対するサービスに利用可能なＣＰＵリソースの割合」からスナップショットの取得間隔の評価式を算出する。

よって、実施形態によれば、スナップショットからの復旧後に、対向装置との状態矛盾の解消（現在存在しないセッションは削除）、セッションタイマや加入者データの最新状態への更新が可能となる。また、実施形態によれば、呼処理サービスに求められるＣＰＵリソースの利用効率と品質要件（故障時に復旧できないセッション数の割合）から、最適なスナップショットの取得間隔を決定することができる。

（その他の実施形態）
（１）ネットワークシステム１について
実施形態では、ネットワークシステム１は、ＩＰ電話サービスシステムであるとした。しかし、開示の技術は、これに限定されず、セッション単位で通信が管理される各種の通信システムであっても適用可能である。

（２）呼処理サーバの実装について
実施形態では、呼処理サーバは、物理サーバ１００のホストＯＳ実行部１１０上で動作するゲストＯＳ実行部１２０上で稼働する呼処理サーバ実行部１３０により実現されるとした。すなわち、実施形態において、呼処理サーバは、物理基盤上の仮想基盤で稼働する仮想マシンにより実装されるとした。しかし、開示の技術は、これに限定されず、物理サーバ毎に仮想基盤を設けず呼処理サーバを物理サーバ上で直接稼働させてもよい。

（３）復旧及び再稼働の対象について
実施形態では、呼処理サーバ実行部１３０の障害を検知して呼処理サーバ実行部１３０の復旧及び再稼働を行うとした。しかし、開示の技術は、これに限定されず、呼処理サーバ実行部１３０を稼働させる仮想化基盤であるゲストＯＳ実行部１２０の障害を検知し、ゲストＯＳ実行部１２０及びゲストＯＳ実行部１２０上で稼働する呼処理サーバである呼処理サーバ実行部１３０の復旧及び再稼働を行うとしてもよい。ゲストＯＳ実行部１２０上で稼働する呼処理サーバ実行部１３０が複数である場合には、図３Ａ及び図３Ｂに示したセッション復旧処理は、呼処理サーバ実行部１３０毎に行われる。

また、物理サーバ１００において行われる各処理は、全部又は任意の一部が、ＣＰＵ等の処理装置及び処理装置により解析実行されるプログラムにて実現されてもよい。また、物理サーバ１００において行われる各処理は、ワイヤードロジックによるハードウェアとして実現されてもよい。

また、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともできる。もしくは、実施形態において説明した各処理のうち、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述及び図示の処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて適宜変更することができる。

（プログラムについて）
図６は、プログラムが実行されることにより、物理サーバが実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。コンピュータ１０００において、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１０４１に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１０６１に接続される。

ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、物理サーバ１００の各処理を規定するプログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュール１０９３として、例えばハードディスクドライブ１０３１に記憶される。例えば、物理サーバ１００における機能構成と同様の情報処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。

また、実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１０４１等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３やプログラムデータ１０９４は、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

実施形態及びその他の実施形態は、本願が開示する技術に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ ネットワークシステム
２ ＩＰ電話端末
３ 対向ＩＰ電話端末
１００ 物理サーバ
１１０ ホストＯＳ実行部
１１１ スナップショット取得部
１１２ スナップショット記憶部
１１３ 障害復旧処理部
１２０ ゲストＯＳ実行部
１３０ 呼処理サーバ実行部
１３１ 呼処理部
１３２ 記憶部
１３２ａ 加入者データ
１３２ｂ セッション情報
１３３ セッション復旧処理部
２００ 対向呼処理サーバ
３００ 加入者管理サーバ
１０００ コンピュータ
１０１０ メモリ
１０２０ ＣＰＵ

Claims (5)

1. 対向装置とのセッションに係るセッション情報と、加入者データを記憶する記憶部と、
   自呼処理装置がスナップショットから復旧されたものである場合に、前記スナップショットの取得時刻から現在時刻までの経過時間が所定閾値以下であるか否かを判定する判定部と、
   前記判定部により前記経過時間が所定閾値以下であると判定された際に、前記セッション情報毎に、前記対向装置に対して前記セッションの更新要求を送信し、前記更新要求に対して前記対向装置から正常応答があった場合には前記セッションを更新し、前記更新要求に対して前記対向装置から正常応答以外の応答があった場合には前記セッションを切断して前記セッションに割り当てられたコンピュータリソースを解放し、前記判定部により前記経過時間が所定閾値を越えると判定された際に、前記記憶部に記憶されている全ての前記セッション情報について前記セッションを切断して前記セッションに割り当てられたコンピュータリソースを解放する復旧処理部と
   を備えることを特徴とする呼処理装置。
2. 前記復旧処理部は、
   加入者管理サーバから取得した加入者データで前記記憶部に記憶されている前記加入者データを最新化する
   ことを特徴とする請求項１に記載の呼処理装置。
3. 自呼処理装置が備える前記記憶部を含む記憶装置の取得時点における状態を含む前記スナップショットが、下記の（１）式により定められる取得間隔ｔで取得される
   ことを特徴とする請求項１又は２に記載の呼処理装置。
   

   
4. 呼処理装置が実行するセッション復旧方法であって、
   前記呼処理装置は、対向装置とのセッションに係るセッション情報と、加入者データを記憶する記憶部を備え、
   前記呼処理装置がスナップショットから復旧されたものである場合に、前記スナップショットの取得時刻から現在時刻までの経過時間が所定閾値以下であるか否かを判定する判定ステップと、
   前記判定ステップにより前記経過時間が所定閾値以下であると判定された際に、前記セッション情報毎に、前記対向装置に対して前記セッションの更新要求を送信し、前記更新要求に対して前記対向装置から正常応答があった場合には前記セッションを更新し、前記更新要求に対して前記対向装置から正常応答以外の応答があった場合には前記セッションを切断して前記セッションに割り当てられたコンピュータリソースを解放し、前記判定ステップにより前記経過時間が所定閾値を越えると判定された際に、前記記憶部に記憶されている全ての前記セッション情報について前記セッションを切断して前記セッションに割り当てられたコンピュータリソースを解放する復旧処理ステップと
   を含んだことを特徴とするセッション復旧方法。
5. 請求項１、２又は３に記載の呼処理装置としてコンピュータを機能させるための呼処理サーバプログラム。

Images