JP2014192856A - 管理システム及び管理方法 - Google Patents

Abstract

【課題】 大規模災害時であっても、適切に通信サービスを提供する。
【解決手段】 管理システム１０は、音声通信及び音声通信以外の通信を含む複数の種別の通信の何れかの通信処理を実行する仮想サーバ２１が生成される１以上の物理サーバ２０を含んで構成される移動体通信システム１に含まれる。管理システム１０は、仮想サーバ２１における通信の種別毎の通信処理の要求量を検出する要求量検出部１１と、複数の種別のうちの予め優先的な種別として設定された種別の通信について、検出された要求量に対して予め設定された処理率の通信処理が可能か否かを判断する処理率判断部１２と、当該判断に基づいて、優先的な種別として設定された種別の通信処理を実行する仮想サーバ２１を物理サーバ２０上に生成する仮想サーバ生成部１３とを備える。
【選択図】 図１

Description

本発明は、移動体通信システムに含まれる管理システム及び管理方法に関する。

従来から、携帯電話網等の移動体通信システムのネットワークにおいて、音声通信やメール等の複数の種別の通信サービスが提供されている（例えば、特許文献１参照）。

特開２００２−３００３１２号公報

従来の移動体通信システムにおいては、通信サービスを提供するサーバやネットワーク資源は、提供するサービスの割付が決まっている。例えば、音声通信であれば音声通信用のサーバやネットワーク資源が、メールであればメール用のサーバやネットワーク資源が設けられている。これらのサーバやネットワーク資源は、予め想定したサービス毎の要求数が考慮されて設備量が算出されて、ネットワークに配備される。

このため、大規模災害の発生時には、想定したサービス要求数を大きく超える状況となる。そのため、サーバ等で規制処理が行われてサービス要求が破棄されることとなる。その結果、音声通話等の通信サービスがつながりにくくなり、サービスの疎通率が低下する。

例えば、東日本大震災の直後は、移動体通信システムにおいて、地震直前と比べて５０〜６０倍のトラヒックが発生したと想定されている。このように、大規模災害時には、広い範囲（例えば、東北から関東まで）で通常時と比べて著しく多量の通信需要が発生する。また、メール等の通信と比べて音声通信の需要急増が顕著である。即ち、大規模災害時には、ネットワークは通常時とは余りにも異なる状況となる。

大規模災害時のサービス要求に応えるために、それに応じた設備をネットワークに設けておくことも考えられる。しかし、その方法では通常時の余剰設備が大きくなりすぎて、例えば、通信料金等のコストが大きくなってしまう。通常、ネットワークに対しては、品質のよいサービスを安価に提供してほしいというユーザからの要求がある。上記のように大規模災害時と通常時との要求は相反するものであり、それらを両立することは難しい。

本発明は、上記の問題点に鑑みてなされたものであり、大規模災害時であっても、適切に通信サービスを提供することを可能とする管理システム及び管理方法を提供することを目的とする。

上記の目的を達成するために、本発明に係る管理システムは、音声通信及び音声通信以外の通信を含む複数の種別の通信の何れかの通信処理を実行する仮想サーバが生成される１以上の物理サーバを含んで構成される移動体通信システムに含まれる管理システムであって、仮想サーバにおける通信の種別毎の通信処理の要求量を検出する要求量検出手段と、複数の種別のうちの予め優先的な種別として設定された種別の通信について、予め記憶した当該種別の通信処理を実行する仮想サーバの処理能力に基づいて要求量検出手段によって検出された要求量に対して予め設定された処理率の通信処理が可能か否かを判断する処理率判断手段と、処理率判断手段による判断に基づいて、優先的な種別として設定された種別の通信処理を実行する仮想サーバを物理サーバ上に生成する仮想サーバ生成手段と、を備える。

本発明に係る管理システムによれば、大規模災害によって膨大な数の通信処理が発生して、優先的な種別として設定された種別の通信について予め設定された処理率（疎通率）の通信処理が可能でなくなった場合に、新たに当該種別の通信処理を実行する仮想サーバを物理サーバ上に生成することができる。従って、本発明に係る管理システムによれば、大規模災害時であっても、適切に通信サービスを提供することが可能となる。

優先的な種別として設定された種別の通信は、音声通信及びメールの少なくとも何れかであることとしてもよい。この構成によれば、大規模災害時に重要となる通信手段である、音声通信及びメールの少なくとも何れかについて適切に通信サービスを提供することが可能となる。

仮想サーバ生成手段は、優先的な種別として設定されていない種別の通信処理を実行する仮想サーバを、優先的な種別として設定された種別の通信処理を実行する仮想サーバに割り当てることで仮想サーバを物理サーバ上に生成することとしてもよい。この構成によれば、通常時は優先的な種別として設定されていない種別の通信処理を実行する仮想サーバを、大規模災害時に重要となる通信手段となる種別の通信に割り当てることができる。従って、リソースの効率的な利用と災害時に確実に優先的な通信を行わせることができる。

ところで、本発明は、上記のように管理システムの発明として記述できる他に、以下のように管理方法の発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。

即ち、本発明に係る管理方法は、音声通信及び音声通信以外の通信を含む複数の種別の通信の何れかの通信処理を実行する仮想サーバが生成される１以上の物理サーバを含んで構成される移動体通信システムに含まれる管理システムによる管理方法であって、仮想サーバにおける通信の種別毎の通信処理の要求量を検出する要求量検出ステップと、複数の種別のうちの予め優先的な種別として設定された種別の通信について、予め記憶した当該種別の通信処理を実行する仮想サーバの処理能力に基づいて要求量検出ステップにおいて検出された要求量に対して予め設定された処理率の通信処理が可能か否かを判断する処理率判断ステップと、処理率判断ステップにおける判断に基づいて、優先的な種別として設定された種別の通信処理を実行する仮想サーバを物理サーバ上に生成する仮想サーバ生成ステップと、を含む。

本発明によれば、大規模災害によって膨大な数の通信処理が発生して、優先的な種別として設定された種別の通信について予め設定された処理率（疎通率）の通信処理が可能でなくなった場合に、新たに当該種別の通信処理を実行する仮想サーバを物理サーバ上に生成することができる。従って、本発明によれば、大規模災害時であっても、適切に通信サービスを提供することが可能となる。

本発明の実施形態に係る管理システムの機能構成、及び当該管理システムを含む移動体通信システムを示す図である。 管理システムにおいて仮想サーバ毎の通信処理の要求量を管理するための情報を格納するリソース管理テーブルである。 管理システムにおいて通信の種別毎の通信処理の要求量を管理するための情報を格納するサービス管理テーブルである。 管理システムにおいて実施形態に係る機能を実現するための情報を格納する条件テーブルである。 大規模災害時においてサービス要求が増加した場合のリソース管理テーブルである。 大規模災害時においてサービス要求が増加した場合のサービス管理テーブルである。 仮想サーバの割当変更について概念的に示した図である。 割当変更が行われた場合のリソース管理テーブルである。 割当変更が行われた場合のサービス管理テーブルである。 本発明の実施形態に係る管理システムのハードウェア構成を示す図である。 本発明の実施形態に係る管理システムで実行される処理（管理方法）を示すフローチャートである。

以下、図面と共に本発明に係る管理システム及び管理方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。また、本実施形態では説明を分かりやすくするため、数値例を示すが、これは必ずしも実際の値とは一致していない。

図１に本実施形態に係る管理システム１０を含む移動体通信システム１の構成を示す。移動体通信システム１は、図示しない移動通信端末（移動機）に移動体通信の機能を提供するシステムである。移動通信端末は、ユーザにより用いられて移動体通信システム（移動体通信網）に無線通信によって接続して移動体通信を行う装置である。具体的には、移動通信端末は、携帯電話機等に相当する。移動通信端末は、例えば、移動体通信システム１を介して対向ノードとの間で呼接続を確立して通信を行う。対向ノードは、例えば、別の移動通信端末や移動通信端末に様々なサービスを提供するサーバ装置、あるいは他の通信網に接続するための装置（例えば、ＭＭＥ（Mobility Management Entity）、Ｓ−ＧＷ（ServingGateway）、Ｐ−ＧＷ（PDN Gateway））等に相当する。移動通信端末は、例えば、移動通信端末のユーザが移動体通信システム１の通信事業者と契約することによって移動体通信を行うことが可能になる。なお、移動通信端末は、従来の移動通信端末と同様のものでよい。

移動体通信システム１は、複数の種別の通信（通信サービス）を移動通信端末に提供する。通信（通信サービス）は、具体的には、音声通信（音声電話）及び音声通信以外の通信である。音声通信は例えば、ＩＭＳ（IP Multimedia Subsystem）によって行われる。音声通信以外の通信としては、例えば、メール、動画（リッチメディア）を送受信する通信等である。メールや動画に係る通信は例えば、ＥＰＣ（Evolved Packet Core）によって行われる。

図１に示すように、移動体通信システム１は、管理システム１０と、１以上（あるいは複数）の物理サーバ（物理マシン、ＰＭ）２０と、オープンフローネットワーク３０とを含んで構成されている。なお、これらの構成１０，２０，３０は、移動体通信システム１（移動体通信網）のコアネットワークを構成するものである。

物理サーバ２０は、移動体通信システム１において通信処理を行う物理的な装置である。通信処理は、行われる通信が音声通信である場合には呼処理である。呼処理は、例えば、音声通信を行うために移動通信端末と対向ノードとの呼接続に係る処理であり、具体的には、移動通信端末と対向ノードとの間の呼接続（通信セッション接続とも呼ばれる）を確立する処理、あるいは切断する処理等である。また、通信処理は、行われる通信がメールである場合には、移動通信端末と対向ノードとの間でメールを中継する処理である。また、通信処理は、行われる通信が動画等を送受信するものである場合（リッチメディア通信である場合）には、移動通信端末と対向ノードとの間で当該動画等を中継する処理である。また、通信処理は、上述した処理以外の移動体通信に係る任意の処理を含んでいてもよい。

通信処理は、実際には物理サーバ２０で実現される仮想サーバ（ＶＭ：Virtual Machine）２１によって実行される。物理サーバ２０は、図１に示すようにオープンフローネットワーク３０を介して、移動通信端末及び対向ノードと接続されており、情報の送受信を行うことができるようになっている。移動体通信システム１には、１以上（あるいは複数）の物理サーバ２０が含まれる。また、複数の物理サーバ２０間も接続されており、物理サーバ２０同志で情報の送受信を行うことができるようになっていてもよい。図１に示すように、拠点（データセンタ等の場所）２を設け、拠点２に１つ以上の物理サーバ２０を設けるようにすることとしてもよい。

仮想サーバ２１は、通信処理を行う、仮想的な通信処理ノードである。仮想サーバ２１は、物理サーバ２０の何れかにおいて実現される。仮想サーバ２１は、例えば、仮想マシン（ＶＭ）技術が利用されて、物理サーバ２０が備えるコア（プロセッサ、ＣＰＵ）が仮想サーバ２１用に割り当てられて、割り当てられたコア上においてプログラムが実行されることにより実現される。なお、１つの物理サーバ２０に複数の仮想サーバ２１を実現することもできる。例えば、図１に示すように１つの物理サーバ２０に４コア含まれている場合には、１つの仮想サーバ２１に対して２コアを割り当てて２つの仮想サーバ２１を実現することができる。図１に示す例では、“＃１”、“＃２”及び“＃３”の物理サーバ２０上に、“ＶＭ１”及び“ＶＭ２”、“ＶＭ３”及び“ＶＭ４”、並びに“ＶＭ５”及び“ＶＭ６”の仮想サーバ２１が実現されている。

移動体通信システム１には、１以上（あるいは複数）の仮想サーバ２１が含まれる。仮想サーバ２１は、ＩＭＳでは、ＣＳＣＦ（Call Session Control Function）、ＡＳ（ApplicationServer）等のノードに相当する。あるいは、仮想サーバ２１は、移動体通信システムの一つであるＧＰＲＳ（GeneralPacket Radio Service）システムでは例えば、ＳＧＳＮ（Serving GPRSSupport Node）、ＬＴＥ／ＥＰＣ（Long Term Evolution/EvolvedPacket Core）システムでは、ＭＭＥ（Mobility Management Entity）やＳ−ＧＷ（Serving Gateway）等のノードに相当する。

各仮想サーバ２１は、通信の種別に応じた通信処理を行うように構成されている。例えば、音声通信に係る通信処理、メールに係る通信処理、動画に係る通信処理の何れかを行うように構成されている。具体的には、仮想サーバ２１において、これらの種別の通信処理を行うためのプログラムが実行されることで上記の構成が実現される。例えば、図１の例では、“ＶＭ１”の仮想サーバ２１ではＩＭＳによる音声通信に係る通信処理が、“ＶＭ２”の仮想サーバ２１ではＥＰＣによるメールに係る通信処理が、“ＶＭ３”〜“ＶＭ６”の仮想サーバ２１ではＥＰＣによる動画に係る通信処理が、それぞれ実行されるように構成されている。なお、動画に係る通信処理には、動画以外に係る通信処理が含まれていてもよい。

仮想サーバ２１において実行されるプログラムが入れ替えられることにより、別の種別に係る通信処理を行うようにすることができる。例えば、“ＶＭ３”の仮想サーバ２１を、ＥＰＣによる動画に係る通信処理を行うものからＩＭＳによる音声通信に係る通信処理を行うものにさせることができる。通常、通信処理の種別が異なるものとなると、信号の流れも異なるものとなる。そのため、仮想サーバ２１において実行される通信処理の種別が変更されると、オープンフローネットワーク３０を含むコアネットワークにおいて仮想サーバ２１との間で入出力される信号の流れも適宜、変更される。仮想サーバ２１における通信処理を行う通信の種別の変更は、例えば、後述するように管理システム１０によって行われる。

仮想サーバ２１は、移動通信端末からの要求（サービス要求、通信要求、トラヒック要求）を受信すること等をトリガとして通信処理を行う。この要求は、例えば、発信要求（呼接続確立の要求）やメールの送受信要求である。仮想サーバ２１は、通信処理の際に、移動通信端末からの要求に含まれる情報を必要に応じて参照する。また、仮想サーバ２１は、通信処理の際、移動通信端末の加入者プロファイルや位置登録情報が格納された、移動体通信システム１に含まれるデータベースを必要に応じて参照、あるいは書き込みする。なお、同一の種別の通信の通信処理を行う仮想サーバ２１が、複数ある場合には、移動体通信システム１においてそれらの仮想サーバ２１のうち一つが選択されて要求が送信される。仮想サーバ２１の選択（要求の振り分け）は、例えば、仮想サーバ２１における負荷がなるべく均一になるように、オープンフローネットワーク３０よって行われる。

仮想サーバ２１は、物理サーバ２０や割り当てられるコアの数等に応じた処理能力がある。例えば、物理サーバ２０において２コアが割り当てられた仮想サーバ２１は、一定時間（例えば、１時間）あたり、音声通信であれば８万、メールであれば１６万、動画であれば４万のサービス要求に対して通信処理を行うことができる。なお、この値は定格処理数であり、概ねＣＰＵ使用率が８０％のときに処理できる値である。通常、ＣＰＵ使用率が１００％に近づくと、仮想サーバ２１が正常に動作しなくなるおそれがあるため、一定のＣＰＵ使用率（上記の例では８０％）が上限となるようにされる。ＣＰＵ使用率が８０％を超えると、それ以上の通信処理が行われないように規制（制御）がなされる。この規制は、仮想サーバ２１自身によって行われてもよいし、管理システム１０によって行われてもよい。

通常、物理サーバ２０の数、及び物理サーバ２０において仮想サーバ２１が設けられる数は、通常時（大規模災害が発生していない時）に発生する通信の種別毎のサービス要求の数が想定されて決められている。しかしながら、災害発生時等には、想定したサービス要求数を大きくこえるサービス要求が仮想サーバ２１に入力されることがある。仮想サーバ２１に定格処理数以上のサービス要求が入力されると、仮想サーバ２１は定格処理数を超えた分のサービス要求を破棄する。この場合、仮想サーバ２１に入力される要求数に対して全ての通信処理が行われないため、入力されたサービス要求のうち処理された（疎通された）サービス要求の率（割合）である疎通率（完了率、処理率）が低下する。即ち、サービスがつながりにくくなる。

オープンフローネットワーク３０は、管理システム１０、物理サーバ２０、並びに図示しない移動通信端末及び対向ノードとそれぞれ接続されており、それらの装置の間の通信路を構成するフロー制御ネットワークである。なお、通常、オープンフローネットワーク３０と移動通信端末とは、基地局や無線制御装置（ＲＮＣ）を介して接続されている。オープンフローネットワーク３０は、互いに接続されているオープンフロースイッチである複数のノード３１によって構成されている。ノード３１は、通常オープンフローネットワークのオープンフロースイッチ（ＳＷ）として用いられる装置に相当する。後述するように、オープンフローネットワーク３０は、管理システム１０のオープンフローコントローラからの制御を受けて情報の送受信を行う。具体的には、オープンフローネットワーク３０の各ノード３１が、自身が受信した情報をどのノードに送信するかを示すフローエントリを、管理システム１０から受信して当該フローエントリに従った情報の送受信を行う。本説明では、オープンフローネットワークとして説明を行うが、ＳＤＮ（Softwarer difined network）と呼ばれる、同様のフロー制御とその制御に従ってフロー転送処理を行うネットワークでもよい。

引き続いて、本実施形態に係る管理システム１０について説明する。管理システム１０は、本実施形態に係る機能として物理サーバ２０上における仮想サーバ２１の実現（実装）を制御する制御ノードである。より具体的には、管理システム１０は、仮想サーバ２１による通信処理の種別を変更する制御を行う。また、管理システム１０は、本実施形態に付随する機能としてオープンフローネットワーク３０における情報の送受信を制御する。管理システム１０における情報の送受信の制御は、例えば、管理システム１０が備える、負荷分散制御等を行うオープンフローコントローラによって行われる。具体的にどのような制御を行うかについては後述する。管理システム１０は、物理サーバ２０のそれぞれと接続されており、情報の送受信を行うことができる。

管理システム１０は、ネットワーク管理制御システムを構成する。ネットワーク管理制御システムには、ネットワーク運用ポリシ、ネットワーク運用・制御シナリオ、ネットワークリソース管理、ネットワークトポロジ管理、ネットワークトポロジ変更、ネットワークリソース制御、仮想サーバ制御及びフロー制御の機能を有している。ネットワーク運用ポリシは、ネットワークリソース管理が把握した状態（輻輳や故障等）に基づいて、どのようにネットワークを制御するかを決定するための判断基準（サービスに関わる品質条件や確保すべき帯域等）を保持する機能である。ネットワーク運用・制御シナリオは、ネットワークリソース運用ポリシを参照して、ネットワーク管理が把握した状態を、ポリシを満たす状態にするための制御手順を与える機能である。ネットワークリソース管理は、ネットワーク内に配備されるサーバやスイッチ等から情報を受信して把握する機能である。

ネットワークトポロジ管理は、ネットワークリソース管理により把握した情報から、ネットワーク内の装置接続状況を把握して管理する機能である。ネットワークトポロジ変更は、仮想化サーバの仮想化マシンの配置・移動制御やスイッチ等の設定変更制御により、ネットワークの装置接続状態を変更する機能である。ネットワークリソース制御は、仮想化サーバの仮想マシンの配置・移動制御やスイッチ等の設定変更制御である。仮想サーバ制御は、仮想化サーバ（物理サーバに同じ）から、サーバの情報を受信してサーバの状態を把握する機能である（ＣＰＵ使用率や故障の有無等）。フロー制御は、オープンフローネットワーク３０のフロー制御を行う機能である。本実施形態に係る管理システム１０は、上記の機能を利用したものである。

図１に示すように管理システム１０は、要求量検出部１１と、処理率判断部１２と、仮想サーバ生成部１３とを備えて構成される。

要求量検出部１１は、仮想サーバ２１における通信の種別毎の通信処理の要求量を検出する要求量検出手段である。要求量検出部１１は、音声通信、メール、動画といった種別毎に仮想サーバ２１における通信処理の要求量を検出する。具体的には、各仮想サーバ２１は、一定時間毎（例えば、１時間毎）に自身に入力された要求の数を管理システム１０に通知する。要求量検出部１１は、仮想サーバ２１からの通知を受け取ることで、各仮想サーバ２１における要求数を一定時間あたりの要求量として検出する。管理システム１０において、何れの仮想サーバ２１が何れの種別の通信の通信処理を行うかは、予め把握されている。

管理システム１０では、要求量検出部１１によって検出された情報が図２に示すリソース管理テーブルによって記憶、管理される。図２に示すようにリソース管理テーブルでは、「物理サーバ」、「仮想サーバ」、「割当量」、「サービス」、「ＣＰＵ使用率」、「要求数／時」及び「疎通率（完了率）」をそれぞれ示す情報が対応付けられて格納されている。「物理サーバ」は、仮想サーバ２１が実現される物理サーバ２０を特定する情報であり、例えば、各物理サーバ２０に一意に割り当てられたＩＤである。「仮想サーバ」は、仮想サーバ２１を特定する情報であり、例えば、各仮想サーバ２１に一意に割り当てられたＩＤである。なお、１つの物理サーバ２０に、複数の仮想サーバ２１が割り当てられている場合は、それに応じて１つの「物理サーバ」の情報に複数の「仮想サーバ」の情報が対応付けられる。

「割当量」は、物理サーバ２０に備えられるコアのうち、仮想サーバ２１に割り当てられている割当数である。図２の例では、各仮想サーバ２１に対して、それぞれ２コアが割り当てられている。「割当量」には、仮想サーバ２１に対するコアの割当に応じた値が予め入力されている。「サービス」は、仮想サーバ２１が通信処理を行う通信の種別を示す情報である。例えば、音声（音声通信）、メール、動画を示す情報である。「サービス」には、仮想サーバ２１に応じた情報が予め入力されている。

「ＣＰＵ使用率」は、仮想サーバ２１が、割り当てられたコアの能力のうち使用している率（割合）を示した値である。「ＣＰＵ使用率」を示す情報については、例えば、各物理サーバ２０あるいは各仮想サーバ２１自身がコアの使用率の検出を行って管理システム１０に通知する。この検出及び通知は、サービス要求の数の通知と同じタイミングで行われてもよい。管理システム１０は、当該通知を受け取り、当該通知に係る情報を図２に示すテーブルに格納する。

「要求数／時」は、要求量検出部１１によって検出された、仮想サーバ２１に係る一定時間毎のサービス要求の数である。仮想サーバ２１は、検出した値を仮想サーバ２１毎に格納する。「疎通率（完了率）」は、仮想サーバ２１に入力されたサービス要求のうち処理された（疎通された）サービス要求の率（割合）を示した値である。より詳細には後述する。

要求量検出部１１は、上記のようにして検出された各仮想サーバ２１の要求数から、通信の種別（サービス）毎の要求数を算出する。管理システム１０では、要求量検出部１１によって算出された情報が図３に示すサービス管理テーブルによって記憶、管理される。図３に示すようにサービス管理テーブルでは、「サービス」、「リソース割当量（全体）」、「定格処理数（全体）」、「サービス要求数（全体）」、及び「疎通率（全体平均）」をそれぞれ示す情報が対応付けられて格納されている。「サービス」は、仮想サーバ２１が通信処理を行う通信の種別を示す情報であり、リソース管理テーブルの「サービス」に対応している。サービス管理テーブルでは、「サービス」毎に情報が格納される。即ち、図３に示すように音声、メール、動画を示す情報毎に各情報が格納される。「リソース割当数」は、物理サーバ２０に備えられるコアのうち、「サービス」で示される種別の通信の通信処理を行う仮想サーバ２１に割り当てられている割当数である。この値は、リソース管理テーブルにおける「割当量」の「サービス」毎の和となる。

「定格処理数（全体）」は、「サービス」で示される種別の通信の通信処理の仮想サーバ２１（全体）による処理能力を示す値である。例えば、一定時間あたりに処理可能な要求数である。「サービス要求数（全体）」は、「サービス」で示される種別毎の一定時間毎のサービス要求の数である。要求量検出部１１は、検出した各仮想サーバ２１に係る要求数の値について種別毎に和をとって、種別毎の通信要求の数を算出する。要求量検出部１１は、算出した値を種別毎に格納する。「疎通率（全体平均）」は、仮想サーバ２１に入力されたサービス要求のうち処理された（疎通された）サービス要求の、種別毎の率（割合）を示した値である。

要求量検出部１１は、例えば、各仮想サーバ２１から通知が行われると、当該通知に係る情報に基づいてリソース管理テーブルの「要求数／時」及びサービス管理テーブルの「サービス要求数（全体）」の欄の値を更新する。また、合わせてリソース管理テーブルの「ＣＰＵ使用率」を更新することとしてもよい。なお、要求量検出部１１により検出あるいは算出される値は、必ずしも上記の方法で取得される必要はなく、従来技術等で用いられえる任意の方法で取得されてもよい。

処理率判断部１２は、通信処理の複数の種別のうちの予め優先的な種別として設定された種別の通信について、要求量検出部１１によって検出された要求量に対して予め設定された処理率の通信処理が可能か否かを判断する処理率判断手段である。処理率判断部１２は、この判断を、予め記憶した当該種別の通信処理を実行する仮想サーバ２１の処理能力に基づいて行う。優先的な種別とは、災害時に優先的に通信処理を行うべき通信の種別である。

例えば、安否確認等の重要な通信は、音声通信やメール等で行われる。一方で動画の通信は災害時には必ずしも必要なく、音声通信やメール等と比べて重要性が下がるものである。従って、優先的な種別は、音声通信及びメールとするのがよい。これらの両方を優先的な種別としてもよいし、何れか一方のみを優先的な種別としてもよい。本実施形態では、音声通信及びメールの両方を優先的な種別として設定されたものとして説明する。優先的な種別は、例えば、移動体通信システム１の管理者である通信事業者等によって予め設定されて、当該種別を示す情報が管理システム１０に入力されている。

優先的な種別と設定された種別の通信には、合わせて最低疎通率が設定される。最低疎通率とは、移動体通信システム１において発生した通信処理のサービス要求、即ち、仮想サーバ２１に入力された通信処理のサービス要求に対して、最低でも処理されるべきサービス要求の処理率（割合）である。最低疎通率は、例えば、移動体通信システム１の管理者である通信事業者等によって予め設定されて、当該最低疎通率を示す情報（値）が管理システム１０に入力されている。

処理率判断部１２における判断を行うため、管理システム１０では、図４に示す条件テーブルに情報が格納されている。図４に示すように条件テーブルでは、「サービス」、「優先度」、「最低疎通率」及び「定格処理数／２コア」をそれぞれ示す情報が対応付けられて格納されている。

「サービス」は、仮想サーバ２１が通信処理を行う通信の種別を示す情報であり、リソース管理テーブル及びサービス管理テーブルの「サービス」に対応している。条件テーブルでは、「サービス」毎に情報が格納される。即ち、図４に示すように音声、メール、動画を示す情報毎に各情報が格納される。「優先度」は、「サービス」で示される種別が優先的な種別であるか、非優先の種別であるかを示す情報である。

「最低疎通率」は、優先的な種別の通信に対して設定された上記の最低疎通率である。例えば、最低疎通率は２５％（４の発呼に対して１呼）とされる。「定格処理数／２コア」は、物理サーバ２０の２コアが割り当てられた場合の仮想サーバ２１における定格処理数である。定格処理数は、上述したように仮想サーバ２１の処理能力を示す値である。定格処理数は、上述したように物理サーバ２０や割り当てられるコアの数等に応じた、通信の種別毎に異なる値である。定格処理数は、一定時間（例えば、１時間）あたりの値である。

処理率判断部１２は、図３に示すサービス管理テーブルにおける、「定格処理数（全体）」の値と「サービス要求数（全体）」の値とから、通信の種別（サービス）毎の疎通率（サービス管理テーブルにおける「疎通率（全体平均）」）を算出する。処理率判断部１２は、「サービス要求数（全体）」の値が「定格処理数（全体）」の値以下であるか否かを判断する。「サービス要求数（全体）」の値が「定格処理数（全体）」の値以下であれば、処理率判断部１２は疎通率を１００％とする。「サービス要求数（全体）」の値が「定格処理数（全体）」の値を超える場合には、破棄されるサービス要求が発生するため疎通率は１００％から下がる。その場合は、処理率判断部１２は、「サービス要求数（全体）」の値を「定格処理数（全体）」で割ることで疎通率を算出する。

このとき、処理率判断部１２は、図３に示すサービス管理テーブルにおける「疎通率（全体平均）」の値だけでなく、図２に示すリソース管理テーブルにおける各仮想サーバ２１の「疎通率（完了率）」を算出することとしてもよい。この場合の算出方法もサービス毎の疎通率の算出方法と同様である。この場合、各仮想サーバ２１の定格処理数は、図４に示す条件テーブルの「定格処理数／２コア」の値を用いることができる。

続いて、処理率判断部１２は、優先的な種別として設定された種別について、算出した通信の種別（サービス）毎の疎通率と図４に示す条件テーブルの「最低疎通率」とを比較する。比較の結果、処理率判断部１２は、最低疎通率よりも算出した疎通率が小さいと判断した場合には、その旨を仮想サーバ生成部１３に通知する。最低疎通率よりも算出した疎通率が小さくないと判断した場合には、特段の処理は必要ない。

各仮想サーバ２１に入力されるサービス要求の数が図２に示すリソース管理テーブルのような状況であり、通信の種別（サービス）毎のサービス要求の数が図３に示すサービス管理テーブルのような状況であった場合には、全ての種別についての疎通率は１００％となる。その場合、処理率判断部１２は、優先的な種別である音声及びメールについて、算出した疎通率が最低疎通率である２５％よりも大きいと判断する。

一方で、各仮想サーバ２１に入力されるサービス要求の数が図５に示すリソース管理テーブルのような状況となり、通信の種別（サービス）毎のサービス要求の数が図６に示すサービス管理テーブルのような状況となったものとする。これは、大規模災害が発生し、それにより音声通信やメールが劇的に増加し、異常なサービス要求増加が発生する場合である。図５に示すように音声通信の時間当たりの要求数は９６万となり、通常の５０倍となる。また、メールの時間当たりの要求数は１２８万となり、通常のおよそ２１倍となる。この例では、音声通信及びメールに割り当てられた仮想サーバ２１は、それぞれ１つであるので定格処理数を考慮すると図５及び図６に示すように疎通率はそれぞれ８％、１２．５％となる。このように優先的な種別である音声通信やメールの疎通率が低下する。また、この場合、仮想サーバ２１では定格処理数の通信処理が行われており、ＣＰＵ使用率も定格処理数に応じた８０％となっている。また、仮想サーバ２１ではＣＰＵ使用率が８０％を超えないように、定格処理数以上の通信処理が行われないように規制が行われる。

その場合、処理率判断部１２は、優先的な種別である音声及びメールについて、算出した疎通率が最低疎通率である２５％よりも小さいと判断し、仮想サーバ生成部１３にその旨を通知する。即ち、処理率判断部１２は、優先サービスについて疎通率が最低疎通率よりも低下したことを検出する。

処理率判断部１２は、例えば、要求量検出部１１によるリソース管理テーブル及びサービス管理テーブルの更新が行われると、上記の疎通率の算出及び最低疎通率との比較を行う。また、処理率判断部１２は、予め設定した一定間隔毎に上記の疎通率の算出及び最低疎通率との比較を行うこととしてもよい。

仮想サーバ生成部１３は、処理率判断部１２による判断に基づいて、優先的な種別として設定された種別の通信処理を実行する仮想サーバ２１を物理サーバ２０上に生成する仮想サーバ生成手段である。具体的には、仮想サーバ生成部１３は、以下の処理を行う。仮想サーバ生成部１３は、優先的な種別である音声及びメールについて処理率判断部１２から疎通率が最低疎通率よりも低下したことが通知されると、以下のように最低疎通率を達成するために必要な不足リソース量を算出する。ここではリソース数は、物理サーバ２０のコア数で算出される。

仮想サーバ生成部１３は、対象となっている種別の通信について、サービス管理テーブルから、処理対象となる通信処理の要求数を示す「サービス要求数（全体）」の値を取得する。また、対象となっている種別の通信について、条件テーブルから、「リソース割当量（全体）」、「最低疎通率」及び「定格処理数／２コア」の値を取得する。仮想サーバ生成部１３は、「サービス要求数（全体）」の値を「定格処理数／２コア」の値で割り、「最低疎通率」を掛けることで最低疎通率を達成するために必要な必要リソース数を算出する。仮想サーバ生成部１３は、算出した必要リソース数から現時点のリソース数である「リソース割当量（全体）」を引くことで不足リソースを算出する。

図４に示す条件テーブル、図６に示すサービス管理テーブルの場合、音声通信の例では、必要リソース＝（９６万÷８万（２コア定格）＝２４コア）×２５％＝６コアとなる。また、不足リソース＝（必要リソース）６コア−（現リソース）２コア＝（不足）４コアと算出される。なお、不足リソースが仮想サーバ２１に割り当てられる単位（本実施形態の例では２コア）に満たない場合には、仮想リソースが当該単位となるように繰り上げてもよい。

仮想サーバ生成部１３は、上記のように算出された不足リソースについて、非優先の種別の通信処理に割り当てられているリソースから割り当てる。本実施形態の例では、動画の種別が非優先の種別であるので、動画の種別の通信処理を行う仮想サーバ２１のリソースが、音声又はメールのリソースに割り当てられる。図４に示す条件テーブル、図６に示すサービス管理テーブルの場合、音声のリソースは４コア、メールのリソースは２コア不足している。動画に割り当てられたリソースは８コアであるので、そのリソースから音声及びメールの不足リソースが割り当てられる。

仮想サーバ生成部１３は、動画に係る通信処理を実行する仮想サーバ２１を、音声通信又はメールに係る通信処理を実行する仮想サーバ２１に動的に割り当てる（変更する）ことで、音声通信又はメールに係る通信処理を実行する仮想サーバ２１を物理サーバ２０上に生成する。上記の割当の変更は、例えば、物理サーバ２０上で実行されるプログラム（通信処理を実行するためのプログラム）を変更することで実現される。このプログラムは、割当変更が行われる際に管理システム１０の仮想サーバ生成部１３から物理サーバ２０に送信されて実行されてもよい。あるいは、予め物理サーバ２０上に複数種類のプログラムを記憶させておき、管理システム１０の仮想サーバ生成部１３からの制御によって、それまで実行されていた動画に係る通信処理を実行するためのプログラムを停止し、音声通信又はメールに係る通信処理を実行するためのプログラムを実行させることとしてもよい。なお、割当変更の方法は上記の方法に限られず、従来技術等で用いられえる任意の方法で行われてもよい。

上記のように割当変更が行われると、例えば、図７に示すように、“＃２”の物理サーバ２０において実現される“ＶＭ３”及び“ＶＭ４”の仮想サーバ２１が、動画に係る通信処理を行うものからＩＭＳによる音声通信に係る通信処理を行うものに変更される。また、“＃３”の物理サーバ２０において実現される“ＶＭ５”の仮想サーバ２１が、動画に係る通信処理を行うものからＥＰＣによるメールに係る通信処理を行うものに変更される。

また、仮想サーバ生成部１３は、上記の仮想サーバ２１の割当の変更に伴って、移動体通信システム１のコアネットワークにおいて信号が適切に処理されるような制御を行う。例えば、動画に係る通信処理を行う仮想サーバ２１から別の通信処理を行うものに変更された仮想サーバ２１に、動画に係る通信処理の要求が入力されないように制御を行う。また、新たに音声通信又はメールに係る通信処理を行うものとされた仮想サーバ２１に、音声通信又はメールに係る通信処理が入力されるように制御を行う。これらの制御は、例えば、オープンフローネットワーク３０のフローエントリを変更すること等により行われる。

仮想サーバ生成部１３によるこれらの変更によって、図８に示すリソース管理テーブル、及び図９に示すサービス管理テーブルのように優先的な種別である音声及びメールについて、条件テーブルに設定された最低疎通率が実現される。

また、仮想サーバ生成部１３は、上記のような割当変更を行った後、図１に示すような通常時の仮想サーバ２１の構成（音声：１、メール：１、動画：４の構成）に戻しても、優先的な種別である音声及びメールについて最低疎通率が実現されることを検出して、通常時の仮想サーバ２１の構成に戻すこととしてもよい。以上が、本実施形態に係る管理システム１０の機能構成である。

図１０に本実施形態に係る管理システム１０を構成するサーバ装置のハードウェア構成を示す。図１０に示すように当該サーバ装置は、ＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２及びＲＯＭ（Read OnlyMemory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述した管理システム１０の機能が発揮される。なお、管理システム１０は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。また、物理サーバ２０及びオープンフローネットワーク３０のノード３１も上記のハードウェア構成を有するサーバ装置によって実現される。以上が、本実施形態に係る管理システム１０の構成である。

引き続いて、図１１のフローチャートを用いて、本実施形態に係る管理システム１０で実行される処理である管理方法を説明する。管理システム１０では、要求量検出部１１によって、仮想サーバ２１における通信の種別毎の通信処理の要求量が検出される（Ｓ０１、要求量検出ステップ）。上述したように例えば、要求量として、音声通信、メール及び動画といったサービス種別毎に時間当たりの要求数が検出される。要求量検出部１１によって検出された要求量を示す情報は、管理システム１０で管理されているリソース管理テーブル及びサービス管理テーブルに格納される。

続いて、処理率判断部１２によって、通信処理の複数の種別のうち、予め優先的な種別として設定された種別の通信について、要求量検出部１１によって検出された要求量に対して通信処理がなされる率である疎通率が算出される（Ｓ０２、処理率判断ステップ）。優先的な種別とされる通信は、上述したように例えば音声通信あるいはメールである。上述したように疎通率は定格処理数に基づいて算出される。

続いて、処理率判断部１２によって、算出された疎通率が予め設定された処理率である最低疎通率以上か否かが判断される（Ｓ０３、処理率判断ステップ）。即ち、優先的な種別として設定された種別の通信について、検出された要求量に対して予め設定された処理率（最低疎通率）の通信処理が可能か否かが判断される。算出された疎通率が最低疎通率以上であると判断された場合（Ｓ０３のＹＥＳ）には、本処理が終了する。

算出された疎通率が最低疎通率以上でない（疎通率が最低疎通率より小さい）と判断された場合（Ｓ０３のＮＯ）には、その旨が処理率判断部１２から仮想サーバ生成部１３に通知される。続いて、仮想サーバ生成部１３によって、疎通率が最低疎通率以上でなかった種別について、疎通率が最低疎通率以上となるように物理サーバ２０上に仮想サーバ２１が生成される（Ｓ０４、仮想サーバ生成ステップ）。仮想サーバ２１の生成は、非優先とされた種別の通信処理に係る仮想サーバ２１が、優先的な種別とされる通信処理に係る仮想サーバに割当変更されることによって行われる。この割当変更によって、優先的な種別とされる通信において最低疎通率以上の疎通率が実現される。以上が、本実施形態に係る管理システム１０で実行される処理である管理方法である。

上述したように本実施形態によれば、大規模災害によって膨大な数の通信処理が発生して、優先的な種別として設定された種別の通信について予め設定された最低疎通率の通信処理が可能でなくなった場合に、当該最低疎通率の通信処理を可能にできるように新たに当該種別の通信処理を実行する仮想サーバ２１を物理サーバ２０上に生成することができる。従って、本実施形態によれば、大規模災害時であっても、適切に通信サービスを提供することが可能となる。

また、本実施形態のように、優先的な通信としては音声通信及びメールを設定することとすることができる。この構成によれば、大規模災害時に重要となる通信手段である、音声通信及びメールについて適切に通信サービスを提供することが可能となる。

また、本実施形態のように非優先とされている動画の通信処理を行う仮想サーバ２１を、音声通信やメールの通信処理を行う仮想サーバ２１に切り替えることとすることができる。このように柔軟に割当を変更することで、通常時は優先的な種別として設定されていない種別の通信処理を実行する仮想サーバを大規模災害時に重要となる通信手段となる種別の通信に割り当てることができる。従って、リソースの効率的な利用と災害時に確実に優先的な通信を行わせることができる。即ち、優先的な種別について通常時にも膨大な数の通信処理を可能とするリソースを用意しておく必要がないため、経済的合理性を満たしつつ最大限に接続を可能とすることができる。

１…移動体通信システム、２…拠点、１０…管理システム、１１…要求量検出部、１２…処理率判断部、１３…仮想サーバ生成部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置、２０…物理サーバ、２１…仮想サーバ、３０…オープンフローネットワーク、３１…ノード。

Claims (4)

1. 音声通信及び音声通信以外の通信を含む複数の種別の通信の何れかの通信処理を実行する仮想サーバが生成される１以上の物理サーバを含んで構成される移動体通信システムに含まれる管理システムであって、
   前記仮想サーバにおける前記通信の種別毎の通信処理の要求量を検出する要求量検出手段と、
   前記複数の種別のうちの予め優先的な種別として設定された種別の通信について、予め記憶した当該種別の通信処理を実行する仮想サーバの処理能力に基づいて前記要求量検出手段によって検出された要求量に対して予め設定された処理率の通信処理が可能か否かを判断する処理率判断手段と、
   前記処理率判断手段による判断に基づいて、前記優先的な種別として設定された種別の通信処理を実行する仮想サーバを前記物理サーバ上に生成する仮想サーバ生成手段と、
   を備える管理システム。
2. 前記優先的な種別として設定された種別の通信は、音声通信及びメールの少なくとも何れかである請求項１に記載の管理システム。
3. 前記仮想サーバ生成手段は、前記優先的な種別として設定されていない種別の通信処理を実行する仮想サーバを、前記優先的な種別として設定された種別の通信処理を実行する仮想サーバに割り当てることで仮想サーバを前記物理サーバ上に生成する請求項１又は２に記載の管理システム。
4. 音声通信及び音声通信以外の通信を含む複数の種別の通信の何れかの通信処理を実行する仮想サーバが生成される１以上の物理サーバを含んで構成される移動体通信システムに含まれる管理システムによる管理方法であって、
   前記仮想サーバにおける前記通信の種別毎の通信処理の要求量を検出する要求量検出ステップと、
   前記複数の種別のうちの予め優先的な種別として設定された種別の通信について、予め記憶した当該種別の通信処理を実行する仮想サーバの処理能力に基づいて前記要求量検出ステップにおいて検出された要求量に対して予め設定された処理率の通信処理が可能か否かを判断する処理率判断ステップと、
   前記処理率判断ステップにおける判断に基づいて、前記優先的な種別として設定された種別の通信処理を実行する仮想サーバを前記物理サーバ上に生成する仮想サーバ生成ステップと、
   を含む管理方法。

Images