(57)【要約】【課題】設備コストの増大を回避しつつ故障時のユーザ影響を小さくし、故障時の円滑な対応を可能とする。【解決手段】管理システム１０において、アプリケーションが稼働しているアクティブ系、特定のアプリケーションが稼働せずに当該特定のアプリケーションがスタンバイしているスタンバイ系、および、特定のアプリケーションに対応付けられていない予備系、を含む３つの構成で管理されている仮想マシンのうち、あるアクティブ系に異常が発生した場合、当該アクティブ系、スタンバイ系およびアプリケーション間の対応情報が保持されたアプリケーションテーブルを参照し、異常が発生した当該アクティブ系のアプリケーションに対応付けられたスタンバイ系を特定し、特定されたスタンバイ系を、当該アプリケーションが稼働するアクティブ系に切り替える一連の制御が行われる。【選択図】図２
2015191246.tif 000002
【特許請求の範囲】
【請求項１】
通信処理を実行するアプリケーションの稼働環境となる仮想マシン、が実現される物理サーバを含む仮想化資源と、
アプリケーションが稼働しているアクティブ系、特定のアプリケーションが稼働せずに当該特定のアプリケーションがスタンバイしているスタンバイ系、および、特定のアプリケーションに対応付けられていない予備系、を含む３つの構成で管理されている前記仮想マシンのうち、あるアクティブ系に異常が発生した場合に、
当該アクティブ系、前記スタンバイ系およびアプリケーション間の対応情報が保持されたアプリケーションテーブルを参照し、
異常が発生した当該アクティブ系のアプリケーションに対応付けられたスタンバイ系を特定し、
特定されたスタンバイ系を、当該アプリケーションが稼働するアクティブ系に切り替えることで、
前記仮想マシンを管理する管理システムと、
を含む通信システム。
【請求項２】
前記管理システムは、前記特定されたスタンバイ系から前記アクティブ系への切り替え後に、当該スタンバイ系を前記予備系から補充するよう制御する、
ことを特徴とする請求項１に記載の通信システム。
【請求項３】
前記管理システムは、アプリケーション共通の予備リソースとして、前記予備系を一定数以上確保するよう制御する、
ことを特徴とする請求項１又は２に記載の通信システム。
【請求項４】
前記予備系は、イメージファイルのダウンロードおよび仮想マシン用リソースの確保が実行されることで準備が完了する、
ことを特徴とする請求項１〜３の何れか一項に記載の通信システム。
【請求項５】
前記通信システムは、
前記仮想化資源全体の管理を行うオーケストレータと、
前記仮想マシンをアプリケーションごとに仮想通信機能コンポーネントとして管理する仮想通信機能部と、
前記仮想通信機能部を管理する仮想通信機能管理ノードと、
を含んで構成され、
前記仮想通信機能部は、あるアクティブ系に異常が発生した場合、当該アクティブ系の異常を前記仮想通信機能管理ノードへ通知し、
前記仮想通信機能管理ノードは、前記アプリケーションテーブルを参照することで、前記異常が発生したアクティブ系のアプリケーションに対応付けられたスタンバイ系の仮想マシンを含む仮想通信機能コンポーネントを特定し、
前記仮想通信機能管理ノードは、特定された仮想通信機能コンポーネントに属する何れかの仮想マシンに対しアクティブ系になるよう指示するとともに、前記オーケストレータに対し、前記異常が発生したアクティブ系へのネットワークのルーティングを、前記アクティブ系になるよう指示した仮想マシンに切り替えるよう依頼し、
前記オーケストレータは、前記依頼に応じて、前記異常が発生したアクティブ系へのネットワークのルーティングを、前記アクティブ系になるよう指示した仮想マシンに切り替える、
ことを特徴とする請求項１〜４の何れか一項に記載の通信システム。
【請求項６】
前記アプリケーションテーブルは、前記仮想通信機能管理ノードに搭載されている、
ことを特徴とする請求項５に記載の通信システム。
【請求項７】
通信処理を実行するアプリケーションの稼働環境となる仮想マシンを管理する管理システム、により実行される管理方法であって、
アプリケーションが稼働しているアクティブ系、特定のアプリケーションが稼働せずに当該特定のアプリケーションがスタンバイしているスタンバイ系、および、特定のアプリケーションに対応付けられていない予備系、を含む３つの構成で管理されている前記仮想マシンのうち、あるアクティブ系に異常が発生した場合に、
当該アクティブ系、前記スタンバイ系およびアプリケーション間の対応情報が保持されたアプリケーションテーブルを参照し、
異常が発生した当該アクティブ系のアプリケーションに対応付けられたスタンバイ系を特定し、
特定されたスタンバイ系を、当該アプリケーションが稼働するアクティブ系に切り替える、
ことを特徴とする管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションの稼働環境となる仮想マシンを管理する管理システムを含む通信システム、および、当該管理システムにより実行される管理方法に関する。
【背景技術】
【０００２】
従来から、様々な目的で、サーバ仮想化技術によってコンピュータを仮想マシン（ＶＭ：Virtual Machine）とすることが行われている。また、この技術によって、移動体通信網（移動通信ネットワーク）のコアネットワークにおけるノードをＶＭとすることが検討されている（例えば、非特許文献１参照）。
【０００３】
移動体通信網のコアネットワークにおけるノードは、例えば、ＶＭ上の仮想化された通信機能であるＶＮＦ（Virtual Network Function）によって実現される。上記のような移動体通信網の管理を、ＶＮＦＭ（ＶＮＦ Manager）、ＶＩＭ（Virtualised Infrastructure Manager）およびオーケストレータ（Orchestrator）の３つの機能エンティティで行うことが考えられる。ＶＮＦＭは、ＶＮＦをＶＭ上で実現するための詳細情報を保持し、ＶＮＦの管理機能を有する。ＶＩＭは、ＶＭが実現される物理サーバ（物理的なサーバ、仮想化資源）の状況を監視し、ＶＮＦＭ又はオーケストレータからの制御によって物理サーバ上にＶＭおよびＶＮＦを生成、削除する。
【０００４】
なお、物理サーバは、通常、データセンタに複数まとめて配置されており、ＶＩＭは、１つ以上のデータセンタに設置された物理サーバ群に対する処理を行う。また、データセンタにおける物理サーバ群の管理（資源管理）は、ＯＰＥＮＳＴＡＣＫ（登録商標）あるいはｖＣｅｎｔｅｒといった異なる実装方式で行われている。ＶＩＭは、データセンタにおける実装方式毎に設けられている。オーケストレータは、複数のＶＩＭにまたがる全体の資源管理を行う。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ETSI Group Specification (ETSI GS NFV 002 v1.1.1(2013.10))  Network Functions Virtualisation (NFV); Architectural Framework
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、上記のような仮想化環境では、アプリケーション稼動中であるＶＭ（以下「アクティブ系」と称する）の故障等に備えて、仮想化資源が確保された予備のハードウェアを複数用意し、予備のハードウェア群を複数のアプリケーションの共用として確保しておくといった運用が考えられる。この運用では、個々のアプリケーションで１対１に対応付けされたアクティブ系から予備のハードウェアへ切り替える所謂１対１対応の予備系切り替えではなく、複数のアプリケーションにわたるＮ個のアクティブ系から共用の予備のハードウェアへ切り替える所謂Ｎ対１対応の予備系切り替えが行われる。
【０００７】
しかし、このような運用では、故障したＶＭから予備のＶＭへ切り替える際に、故障したＶＭで稼働していたアプリケーションを、新たなハードウェア上にＶＭ用リソースを確保し，ＶＭを立ち上げたうえでインストールする必要があるため、切替に時間がかかってしまい、ユーザ影響が大きくなってしまう。そこで、このような故障時のユーザ影響を小さくするため、リソース確保、ＶＭ立ち上げを行い，特定のアプリケーションを予めインストールした予備のＶＭ群（特定のアプリケーション用にスタンバイしたＶＭという意味で以下「スタンバイ系」と称する）をアプリケーションごとに用意するという策が考えられる。
【０００８】
ところが、アプリケーションごとにスタンバイ系を用意するには、実際には多数のスタンバイ系が必要となり、設備コストの増大が懸念される。また、上記のような冗長構成運用時には、故障したアクティブ系と、該アクティブ系に紐づけられるアプリケーションおよびスタンバイ系との間の対応関係の把握が肝要であり、このような把握が不十分だと、新規のＶＭを立ち上げてもアプリケーションと紐づけて適正にスタンバイ系を管理することができないというおそれがある。
【０００９】
そこで、本発明は、上記課題を解決するために成されたものであり、設備コストの増大を回避しつつ故障時のユーザ影響を小さくし、故障時の円滑な対応を可能とすることを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係る通信システムは、通信処理を実行するアプリケーションの稼働環境となる仮想マシン、が実現される物理サーバを含む仮想化資源と、アプリケーションが稼働しているアクティブ系、特定のアプリケーションが稼働せずに当該特定のアプリケーションがスタンバイしているスタンバイ系、および、特定のアプリケーションに対応付けられていない予備系、を含む３つの構成で管理されている前記仮想マシンのうち、あるアクティブ系に異常が発生した場合に、当該アクティブ系、前記スタンバイ系およびアプリケーション間の対応情報が保持されたアプリケーションテーブルを参照し、異常が発生した当該アクティブ系のアプリケーションに対応付けられたスタンバイ系を特定し、特定されたスタンバイ系を、当該アプリケーションが稼働するアクティブ系に切り替えることで、前記仮想マシンを管理する管理システムと、を含むことを特徴とする。
【００１１】
本発明に係る管理方法は、通信処理を実行するアプリケーションの稼働環境となる仮想マシンを管理する管理システム、により実行される管理方法であって、アプリケーションが稼働しているアクティブ系、特定のアプリケーションが稼働せずに当該特定のアプリケーションがスタンバイしているスタンバイ系、および、特定のアプリケーションに対応付けられていない予備系、を含む３つの構成で管理されている前記仮想マシンのうち、あるアクティブ系に異常が発生した場合に、当該アクティブ系、前記スタンバイ系およびアプリケーション間の対応情報が保持されたアプリケーションテーブルを参照し、異常が発生した当該アクティブ系のアプリケーションに対応付けられたスタンバイ系を特定し、特定されたスタンバイ系を、当該アプリケーションが稼働するアクティブ系に切り替える、ことを特徴とする。
【００１２】
上記の通信システムおよび管理方法では、アプリケーションが稼働しているアクティブ系、特定のアプリケーションが稼働せずに当該特定のアプリケーションがスタンバイしているスタンバイ系、および、特定のアプリケーションに対応付けられていない予備系、を含む３つの構成で管理されている前記仮想マシンのうち、あるアクティブ系に異常が発生した場合に、当該アクティブ系、前記スタンバイ系およびアプリケーション間の対応情報が保持されたアプリケーションテーブルを参照し、異常が発生した当該アクティブ系のアプリケーションに対応付けられたスタンバイ系を特定し、特定されたスタンバイ系を、当該アプリケーションが稼働するアクティブ系に切り替える。これにより、切り替えに要する時間を短縮してユーザ影響を小さくし、仮想マシンの切替えを円滑に実行することができる。また、アクティブ系とスタンバイ系に加え、特定のアプリケーションに対応付けられていない予備系を設けたことで、例えばアプリケーションごとに多数のスタンバイ系を用意しておくといった対応は不要となり、設備コストの増大回避に資することができる。
【００１３】
なお、管理システムは、特定されたスタンバイ系からアクティブ系への切り替え後に、当該スタンバイ系を予備系から補充するよう制御してもよく、スタンバイ系を一定数確保しておくことが可能となる。
【００１４】
また、管理システムは、アプリケーション共通の予備リソースとして、予備系を一定数以上確保するよう制御してもよい。
【００１５】
上記の予備系は、イメージファイルのダウンロードおよび仮想マシン用リソースの確保が実行されることで準備が完了する。
【００１６】
上記の通信システムは、仮想化資源全体の管理を行うオーケストレータと、仮想マシンをアプリケーションごとに仮想通信機能コンポーネントとして管理する仮想通信機能部と、前記仮想通信機能部を管理する仮想通信機能管理ノードと、を含んで構成され、前記仮想通信機能部は、あるアクティブ系に異常が発生した場合、当該アクティブ系の異常を前記仮想通信機能管理ノードへ通知し、前記仮想通信機能管理ノードは、前記アプリケーションテーブルを参照することで、前記異常が発生したアクティブ系のアプリケーションに対応付けられたスタンバイ系の仮想マシンを含む仮想通信機能コンポーネントを特定し、前記仮想通信機能管理ノードは、特定された仮想通信機能コンポーネントに属する何れかの仮想マシンに対しアクティブ系になるよう指示するとともに、オーケストレータに対し、前記異常が発生したアクティブ系へのネットワークのルーティングを、前記アクティブ系になるよう指示した仮想マシンに切り替えるよう依頼し、前記オーケストレータは、前記依頼に応じて、前記異常が発生したアクティブ系へのネットワークのルーティングを、前記アクティブ系になるよう指示した仮想マシンに切り替える、といった制御をしてもよい。
【００１７】
また、アプリケーションテーブルは、仮想通信機能管理ノードに搭載された構成としてもよい。
【発明の効果】
【００１８】
本発明によれば、設備コストの増大を回避しつつ故障時のユーザ影響を小さくし、故障時の円滑な対応が可能となる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態に係る管理システムの構成、及び当該管理システムを含む移動体通信システムを示す図である。
【図２】管理システムの機能構成を示す図である。
【図３】管理システムに含まれるノードのハードウェア構成を示す図である。
【図４】管理システムにおける階層構造を示す図である。
【図５】予備系、スタンバイ系およびアクティブ系を準備するための処理を示すフロー図である。
【図６】管理システムにおける切替処理の概要を示す図である。
【図７】管理システムにおける１台故障時の切替処理を示すフロー図である。
【図８】図７の処理中のアプリケーションテーブル内容の遷移を示す図であり、（ａ）は初期段階の内容を、（ｂ）は処理(b2)の段階の内容を、（ｃ）は処理(b9)の段階の内容を、（ｄ）は処理(b11)の段階の内容をそれぞれ示す。
【図９】管理システムにおけるスタンバイ系の増設処理を示すフロー図である。
【図１０】図９の処理中のアプリケーションテーブル内容の遷移を示す図であり、（ａ）は初期段階の内容を、（ｂ）は処理(c3)の段階の内容をそれぞれ示す。
【図１１】管理システムにおける２台故障時の切替処理を示すフロー図である。
【図１２】図１１の処理前半のアプリケーションテーブル内容の遷移を示す図であり、（ａ）は初期段階の内容を、（ｂ）は処理(d2)の段階の内容を、（ｃ）は処理(d9)の段階の内容をそれぞれ示す。
【図１３】図１１の処理後半のアプリケーションテーブル内容の遷移を示す図であり、（ａ）は処理(d12)の段階の内容を、（ｂ）は処理(d14)の段階の内容をそれぞれ示す。
【発明を実施するための形態】
【００２０】
以下、図面と共に本発明に係る管理システム、仮想通信機能管理ノードおよび管理方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。
【００２１】
［システム構成について］
図１に本実施形態に係る管理システム１０を含む移動体通信システム１の構成を示す。移動体通信システム１は、図示しない移動通信端末（移動機）に移動体通信の機能を提供するシステムである。移動通信端末は、ユーザにより用いられて移動体通信システム（移動体通信網）に無線通信によって接続して移動体通信を行う装置である。具体的には、移動通信端末は、携帯電話機等に相当する。移動通信端末は、例えば、移動体通信システム１を介して対向ノードとの間で呼接続を確立して通信を行う。対向ノードは、例えば、別の移動通信端末や移動通信端末に様々なサービスを提供するサーバ装置、あるいは他の通信網に接続するための装置（例えば、ＭＭＥ（Mobility Management Entity）、Ｓ−ＧＷ（Serving Gateway）、Ｐ−ＧＷ（PDN Gateway））等に相当する。移動通信端末は、例えば、移動通信端末のユーザが移動体通信システム１の通信事業者と契約することによって移動体通信を行うことが可能になる。なお、移動通信端末は、従来の移動通信端末と同様のものでよい。
【００２２】
図１に示すように管理システム１０は、オーケストレータ２０と、ＶＮＦＭ３０と、ＶＩＭ４０と、本発明の特徴的な構成であるアプリケーションテーブル管理装置９０（アプリケーションテーブル管理手段）と、を含んで構成されている。ただし、アプリケーションテーブル管理装置９０は各ＶＮＦＭ３０の内部に設けてもよい。また、移動体通信システム１には、ＯＳＳ／ＢＳＳ（Operations Support System／Business Support System）５０と、ＮＦＶＩ（ＮＦＶ  Infrastructure）６０と、ＶＮＦ（Virtual Network Function）７０と、ＥＭＳ（Element Management System）８０とを含んで構成されている。これらの構成要素は、移動体通信システム１（移動体通信網）のコアネットワークを構成するものである。なお、互いに情報の送受信が必要な構成要素間は、有線等で接続されており情報の送受信が可能となっている。
【００２３】
本実施形態に係る移動体通信システム１は、物理サーバ上に実現される仮想マシンにおいて動作する仮想サーバによって移動通信端末に対して通信機能が提供される。即ち、移動体通信システム１は、仮想化された移動体通信ネットワークである。通信機能は、仮想マシンによって当該通信機能に応じた通信処理を実行することで移動通信端末に対して提供される。
【００２４】
ＮＦＶＩ６０は、仮想化環境を構成する物理資源、仮想化層、仮想化資源である。物理資源には、計算資源、記憶資源、伝送資源が含まれる。仮想化層は、物理資源を仮想化しＶＮＦ７０に提供する（例えば、ハイパーバイザー）。仮想化資源は、ＶＮＦ７０に提供される仮想化されたインフラ資源である。即ち、ＮＦＶＩ６０は、移動体通信システム１において通信処理を行う物理的なサーバ装置である物理サーバを含んで構成されている仮想化資源である。物理サーバは、ＣＰＵ（コア、プロセッサ）、メモリ、およびハードディスク等の記憶手段を備えて構成される。通常、ＮＦＶＩ６０を構成する物理サーバは、複数まとめてデータセンタ（ＤＣ）等の拠点に配置される。データセンタでは、配置された物理サーバがデータセンタ内部のネットワークによって接続されており、互いに情報の送受信を行うことができるようになっている。また、移動体通信システム１には、複数のデータセンタが設けられている。データセンタ間はネットワークで接続されており、異なるデータセンタに設けられた物理サーバはそのネットワークを介して互いに情報の送受信を行うことができる。
【００２５】
ＶＮＦ７０は、例えば、通信処理を実行する仮想的な通信処理ノードである仮想サーバ（が有する通信処理を実行する機能）として構成される。但し、ＶＮＦ７０は、必ずしも仮想サーバとは限らず、ソフトウェア的に複数の仮想サーバをまとめるコンポーネントとして機能するものであってもよい。ＶＮＦ７０は、ＮＦＶＩ６０において実現される。ＶＮＦ７０は、例えば、仮想マシン（ＶＭ）技術が利用されて、ＮＦＶＩ６０が備えるＣＰＵがＶＮＦ７０用に割り当てられて、割り当てられたＣＰＵ上において仮想マシンが実現され、仮想マシン上でプログラムが実行されることにより実現される。ＶＮＦ７０は、通常、実行する通信処理に応じて生成（実現）される。また、ＶＮＦ７０は、その構成要素であるＶＮＦＣ（Virtual Network Function Components）を複数含むものとして構成されていてもよい。
【００２６】
移動体通信システム１には、１以上（あるいは複数）のＶＮＦ７０が含まれる。ＶＮＦ７０は、ＩＭＳでは、ＣＳＣＦ（Call Session Control Function）、ＡＳ（Application Server）等のノードに相当する。あるいは、ＶＮＦ７０は、移動体通信システムの一つであるＧＰＲＳ（General Packet Radio Service）システムでは例えば、ＳＧＳＮ（Serving GPRS Support Node）、ＬＴＥ／ＥＰＣ（Long Term Evolution/Evolved Packet Core）システムでは、ＭＭＥ（Mobility Management Entity）やＳ−ＧＷ（Serving Gateway）等のノードに相当する。
【００２７】
ＥＭＳ８０は、ＶＮＦ７０を監視および制御するノードである。ＥＭＳ８０も、ＶＮＦ７０と同様にＮＦＶＩ６０において仮想的に実現される。ＥＭＳ８０は、ＶＮＦ７０に対応付けられて（例えば、図１に示すようにＶＮＦ７０と一対一の関係で）生成される。ＥＭＳ８０は、対応付けられたＶＮＦ７０の監視および制御を行う。ＥＭＳ８０は、ＶＮＦ７０のＦＣＡＰＳ（障害、構成、課金、性能、セキュリティ）管理を行う。ＥＭＳ８０は、前述の説明のように仮想的に実現しても良いし、ＦＣＡＰＳ管理を行う上で管理の複雑性を避けるために物理的に実現しても良い。
【００２８】
ＯＳＳ／ＢＳＳ５０は、移動体通信システム１におけるサービス管理を行い、管理システム１０に移動体通信システム１での通信機能に係る指示を行うノードである。例えば、ＯＳＳ／ＢＳＳ５０は、管理システム１０に対して、新たな通信機能（通信サービス）を起動するように指示を行う。また、ＯＳＳ／ＢＳＳ５０は、ＥＭＳ８０から情報を受け取り、その情報に基づいて管理システム１０又はＥＭＳ８０に対して指示を行う。また、ＯＳＳ／ＢＳＳ５０は、移動体通信システム１に係る通信事業者によって操作されえる。
【００２９】
管理システム１０の構成要素であるオーケストレータ２０は、仮想化資源であるＮＦＶＩ６０全体の管理を行う全体管理ノード（機能エンティティ）である。オーケストレータ２０は、ＯＳＳ／ＢＳＳ５０（のうちのＯＳＳ５１）からの指示を受信し、当該指示に応じた処理を行う。オーケストレータ２０は、インフラと通信サービスの移動体通信網の仮想化資源全体にわたる管理を行う。オーケストレータ２０は、複数のＶＮＦ７０から構成される通信サービスをＶＮＦＭ３０およびＶＩＭ４０を経由して適切な場所に実現する。例えば、サービスのライフサイクル管理（具体的には例えば、生成、更新、スケール制御、イベント収集）、移動体通信網内全体にわたる資源の分散・予約・割当管理、サービス・インスタンス管理、およびポリシー管理（具体的には例えば、リソースの予約・割当、地理・法令等に基づく最適配置）を行う。
【００３０】
管理システム１０の構成要素であるＶＮＦＭ３０は、ＶＮＦ７０を管理する仮想通信機能管理ノード（機能エンティティ）である。ＶＮＦＭ３０は、移動体通信システム１に複数、設けられていてもよい。その場合、ＶＮＦ７０毎に管理されるＶＮＦＭ３０が予め定められていてもよい。ＶＮＦＭ３０は、ＶＮＦ７０のライフサイクル管理を行う。ＶＮＦＭ３０は、ＶＮＦ７０の仮想化に関わる制御全般を行う。例えば、ＶＮＦ７０はインスタンスの生成、更新、スケール制御、終了、オートヒーリング（自動ヒーリング）を行う。
【００３１】
管理システム１０の構成要素であるＶＩＭ４０は、ＮＦＶＩ６０におけるＶＮＦ７０が実現される単位の仮想化資源（インフラリソース）各々を管理する仮想化資源管理ノード（機能エンティティ）である。具体的には、資源の割当・更新・回収の管理、仮想資源と物理との関連付け、ハードウェア資源とＳＷ資源（ハイパーバイザー）一覧の管理を行う。通常、ＶＩＭ４０は、データセンタ（局舎）毎に管理を行う。仮想化資源の管理は、データセンタに応じた方式で行われえる。データセンタの管理方式（管理資源の実装方式）は、ＯＰＥＮＳＴＡＣＫやｖＣｅｎｔｅｒ等の種類がある。通常、ＶＩＭ４０は、データセンタの管理方式毎に設けられる。即ち、管理システム１０には、互いに異なる方式で、ＮＦＶＩ６０におけるＶＮＦ７０が実現される単位の仮想化資源各々を管理する複数のＶＩＭ４０が含まれる。なお、異なる管理方式で管理される仮想化資源の単位は、必ずしもデータセンタ単位でなくてもよい。
【００３２】
管理システム１０では、ＶＭは、アプリケーション稼働中のアクティブ系、特定のアプリケーション用にスタンバイしたスタンバイ系、および、特定のアプリケーションに対応付けられていない予備系、を含む３つの構成で管理されており、管理システム１０の構成要素であるアプリケーションテーブル管理装置９０は、詳細は後述するが、アクティブ系、スタンバイ系およびアプリケーション間の対応情報を保持し管理する。
【００３３】
なお、オーケストレータ２０、ＶＮＦＭ３０、ＶＩＭ４０およびアプリケーションテーブル管理装置９０は、物理的なサーバ装置上でプログラムが実行されることにより実現される（但し仮想化上で実現されることを制限するものでは無く、管理系統を分離した上で、仮想化上で実現してもよい）。オーケストレータ２０、ＶＮＦＭ３０、ＶＩＭ４０およびアプリケーションテーブル管理装置９０は、それぞれ別々の物理的なサーバ装置で実現されていてもよいし、同じサーバ装置で実現されていてもよい。オーケストレータ２０、ＶＮＦＭ３０、ＶＩＭ４０およびアプリケーションテーブル管理装置９０、又は、これらを実現するためのプログラムは、別々のベンダから提供されていてもよい。
【００３４】
なお、移動体通信システム１には、移動体通信機能を実現するために、上記以外の構成要素が含まれていてもよい、例えば、移動体通信システム１には、基地局の装置およびオープンフローネットワーク（上記のような仮想化されたものも含む）等が含まれていてもよい。
【００３５】
引き続いて、管理システム１０が有する、本実施形態に係る機能を説明する。図２に示すようにアプリケーションテーブル管理装置９０は、アプリケーションテーブル９１とテーブル管理部９２とを備える。アプリケーションテーブル９１は、アクティブ系、スタンバイ系およびアプリケーション間の対応情報を保持したテーブル形式のデータベースであり、テーブル管理部９２はアプリケーションテーブル９１の情報の読み出しや更新を行う機能構成である。
【００３６】
図２に示すようにＶＮＦＭ３０は、切替制御部３１と補充制御部３２とを備える。切替制御部３１は、あるアクティブ系が故障した場合に、アプリケーションテーブル９１により保持された対応情報を参照することで、故障したアクティブ系にて稼働するアプリケーションに対応付けられたスタンバイ系を特定し、特定されたスタンバイ系を、代替となるアクティブ系に切り替えるよう制御する機能構成である。補充制御部３２は、スタンバイ系から代替となるアクティブ系への切り替え後に、当該スタンバイ系を予備系のＶＭ群から補充するよう制御する機能構成である。
【００３７】
図３に本実施形態に係る管理システム１０に含まれるオーケストレータ２０、ＶＮＦＭ３０、ＶＩＭ４０およびアプリケーションテーブル管理装置９０を構成するサーバ装置のハードウェア構成例を示す。図３に示すように当該サーバ装置は、ＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２およびＲＯＭ（Read Only Memory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述および後述するオーケストレータ２０、ＶＮＦＭ３０、ＶＩＭ４０およびアプリケーションテーブル管理装置９０の機能が発揮される。なお、オーケストレータ２０、ＶＮＦＭ３０、ＶＩＭ４０およびアプリケーションテーブル管理装置９０は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。また、移動体通信システム１に含まれる上記以外のノードも上記のハードウェア構成を有するサーバ装置によって実現されてもよい。
【００３８】
図４には、管理システム１０における多数のＶＭ（仮想マシン）７４を管理するための階層構造を示す。ＶＮＦ７０は、図１のＮＦＶＩ６０が備えるＣＰＵがＶＮＦ７０用に割り当てられ、割り当てられたＣＰＵ上においてＶＭ７４が実現され、ＶＭ７４上でプログラムが実行されることによって、実現される。ＶＮＦ７０で稼動するＶＭ７４は、アプリケーションの種類（例えば、呼処理、認証など）ごとに管理され、同じ種類のアプリケーションが稼動するＶＭ群は、ＶＮＦＣ（Virtual Network Function Components）７２を構成し、ＶＮＦ７０は、複数のＶＮＦＣ７２を含むものとして構成される。したがって、図４のように、ＶＭ７４の上位にＶＮＦＣ７２が位置づけられ、ＶＮＦＣ７２の上位にＶＮＦ７０が位置づけられる。
【００３９】
また、ＶＮＦ７０の上位には、ＶＮＦ７０を管理するＶＮＦＭ３０が位置づけられ、ＶＮＦＭ３０の上位には、全体を管理するオーケストレータ２０が位置づけられる。
【００４０】
本実施形態では、アプリケーションテーブル管理装置９０がＶＮＦＭ３０の外部に設けられ、複数のＶＮＦＭ３０によりアプリケーションテーブル管理装置９０が利用される。ただし、アプリケーションテーブル管理装置９０がＶＮＦＭ３０それぞれに搭載された構成を採用してもよい。
【００４１】
［予備系、スタンバイ系およびアクティブ系の準備について］
ここで、図５を用いて、管理システム１０において、予備系、スタンバイ系、およびアクティブ系を準備するための処理を説明する。
【００４２】
図５に示すように、ＶＭ用リソースの確保（ステップＳ１）とイメージファイルのダウンロード（ステップＳ２）が実行されることで、予備系の準備が完了する。この段階では、予備系にはアプリケーションは対応付けられていない。
【００４３】
次に、予備系に対し、ＶＭ立ち上げ（ステップＳ３）とＶＮＦＣ共通部分（当該ＶＮＦＣのアプリケーション）のインストール（ステップＳ４）が実行されることで、スタンバイ系の準備が完了する。この段階で、スタンバイ系となったＶＭには、アプリケーション、当該アプリケーションが稼動するＶＮＦＣおよびＶＮＦが対応付けられる。
【００４４】
さらに、スタンバイ系に対し、個別部分の設定・ネットワーク設定（ステップＳ５）とフロー流し込み（ステップＳ６）が実行されることで、アクティブ系の準備が完了する。
【００４５】
［切替処理の概要］
次に、図６を用いて、管理システム１０における切替処理の概要を説明する。図６に例示する仮想環境では、アクティブ系のＶＮＦ＿０およびＶＮＦ＿１と、スタンバイ系のＶＮＦ＿２とが存在する。このうちＶＮＦ＿１は、呼処理が稼動中のＶＮＦＣ＿１と、認証が稼動中のＶＮＦＣ＿ｙとを含んで構成され、このうち呼処理のＶＮＦＣ＿１は、ＶＭ＿１（IDが１であるＶＭを意味する。以下同様）を含んで構成される。ＶＮＦ＿２は、呼処理用に準備されたＶＮＦＣ＿２と、認証用に準備されたＶＮＦＣ＿ｚとを含んで構成され、このうち呼処理用のＶＮＦＣ＿２はＶＭ＿２（IDが２であるＶＭを意味する。以下同様）、ＶＭ＿３（IDが３であるＶＭを意味する。以下同様）、ＶＭ＿４（IDが４であるＶＭを意味する。以下同様）を含んで構成される。なお、スタンバイ系のＶＮＦＣ構成は、対応するアクティブ系のＶＮＦＣ構成と必ずしも同じでなくてもよい。例えば、図６において呼処理のＶＭのみを含むＶＮＦＣ構成とされたＶＮＦがスタンバイ系に存在してもよい。
【００４６】
このような環境で、呼処理稼動中のアクティブ系のＶＭ＿１に故障が発生すると、ＶＭ＿１の故障がＶＮＦＭへ通知される（処理(a1)）。通知を受けたＶＮＦＭは、アプリケーションテーブル管理装置９０に、ＶＭ＿１に対応付けられたスタンバイ系のＶＮＦＣを問い合わせることで、どのＶＮＦＣで故障切替を行うかを判断する（処理(a2)）。ここでは、ＶＮＦＣ＿２で故障切替を行うと判断される。
【００４７】
次に、ＶＮＦＭは、ＶＮＦＣ＿２と、共通予備リソースを全体管理するオーケストレータとに対し、以下のように切替を依頼する（処理(a3)）。具体的には、ＶＮＦＭは、ＶＮＦＣ＿２のＶＭ＿２に対しアクティブ系になるよう指示するとともに、オーケストレータに対し、従前のＶＭ＿１へのネットワークのルーティングをＶＭ＿２に切り替える点およびＶＮＦＣ＿２にスタンバイ系を１台補充（オートヒーリング）する点を依頼する。
【００４８】
これにより、ＶＭ＿１へのネットワークのルーティングがＶＭ＿２に切り替えられ、ＶＭ＿２は呼処理が稼動するアクティブ系となる（処理(a4)）。このような故障切替完了後に、ＶＮＦＣ＿２にスタンバイ系が１台補充（オートヒーリング）される（処理(a5)）。
【００４９】
以上により、管理システム１０における切替処理が完了する。
【００５０】
［切替処理の具体例１］
以下、管理システム１０における切替処理の具体例を順に説明する。まず、切替処理の具体例１として、１台故障時の切替処理について図７、図８を用いて説明する。ここでは、図７に示すように初期段階でインスタンシエーション（提供するアプリケーションに応じたＶＮＦの生成処理）は完了しており、ＶＮＦＭは配下のアクティブ系のＶＮＦＣ＿１とハートビートをやりとりしている。図８（ａ）〜（ｄ）は切替処理中のアプリケーションテーブル内容の遷移を示すが、図８（ａ）に示すように初期段階でスタンバイ系は２台以上確保されているものとする。
【００５１】
図７に示すようにＶＮＦＭは、ＶＮＦＣ＿１のＶＭ＿１が故障したことを検知すると、アプリケーションテーブル管理装置にどのＶＮＦＣが、ＶＭ＿１に対応付けられたスタンバイ系かを問い合わせる（処理(b1)）。
【００５２】
アプリケーションテーブル管理装置は、ＶＮＦＣ＿２が、ＶＭ＿１に対応付けられたスタンバイ系であることをＶＮＦＭに応答する。これにより、ＶＭ＿１の故障後にＶＭ＿２がアクティブ系のために予約されたＶＭになるため、アプリケーションテーブル管理装置は、図８の（ａ）および（ｂ）に示すように、ＶＭ＿１について、アプリケーションを「呼処理」から「故障」に変更し、「ＳＢＹ系ＶＮＦＣのＩＤ」と「ＳＢＹ系ＶＮＦのＩＤ」それぞれを「２」から「なし」へ変更し、ＶＭ＿２について、アプリケーションを「スタンバイ」から「予約」に変更する（処理(b2)）。なお、図８、図１０、図１２、図１３に記載した「ＳＢＹ系」はスタンバイ系を意味する。
【００５３】
ＶＮＦＭは、ＶＮＦＣ＿２のＶＭ＿２にアクティブ系になるよう指示する（処理(b3)）。また、ＶＮＦＭは、オーケストレータに以下２つの処理Ａ１、Ａ２を依頼する（処理(b4)）。
処理Ａ１：ＶＭ＿１のネットワークをＶＭ＿２に切り替える処理
処理Ａ２：ＶＮＦＣ＿２にスタンバイ系を１台オートヒーリングする処理
【００５４】
ＶＮＦＣ＿２は、ＶＭ＿２のＡＣＴ切り替えが完了した旨をＶＮＦＭに伝える（処理(b5)）。また、オーケストレータは、ＶＩＭに上記処理Ａ１、Ａ２の順に実行するよう依頼する（処理(b6)）。
【００５５】
ＶＩＭは、処理Ａ１（ＶＭ＿２へのネットワーク切替え）を実行する（処理(b7)）。そして、ＶＩＭは、処理Ａ１が完了した旨をオーケストレータ経由でＶＮＦＭに伝える。これを受けたＶＮＦＭは、ＶＭ＿２をＶＮＦＣ＿１の管理下に置く（処理(b8)）。
【００５６】
また、ＶＮＦＭは、ＶＭ＿１からＶＭ＿２への故障切替が完了したため、アプリケーションテーブル管理装置により以下のようにアプリケーションテーブルを更新させる。即ち、図８（ｃ）に示すように、ＶＭ＿２について、「ＶＮＦＣのＩＤ」と「ＶＮＦのＩＤ」それぞれを「２」から「１」へ変更し、アプリケーションを「予約」から「呼処理」に変更し、「ＳＢＹ系ＶＮＦＣのＩＤ」と「ＳＢＹ系ＶＮＦのＩＤ」それぞれを「なし」から「２」へ変更させる（処理(b9)）。
【００５７】
ＶＩＭは、処理Ａ２（ＶＮＦＣ＿２へのスタンバイ系１台のオートヒーリング）を実行し、実行が完了すると、処理Ａ２が完了した旨をオーケストレータ経由でＶＮＦＭに伝える。これを受けたＶＮＦＭは、新規に作成されたＶＭ＿４をＶＮＦＣ＿２の管理下に置く（処理(b10)）。
【００５８】
ＶＮＦＭは、ＶＭ＿４が増えたため、アプリケーションテーブル管理装置により以下のようにアプリケーションテーブルを更新させる。即ち、図８（ｄ）に示すように、ＶＭ＿４のレコードを追加し、「ＶＭのＩＤ」を「４」に設定し、「ＶＮＦＣのＩＤ」と「ＶＮＦのＩＤ」それぞれを「２」に設定し、アプリケーションを「スタンバイ」に設定し、「ＳＢＹ系ＶＮＦＣのＩＤ」と「ＳＢＹ系ＶＮＦのＩＤ」それぞれを「なし」に設定する（処理(b11)）。
【００５９】
以上により、１台故障時の切替処理が完了する。
【００６０】
［切替処理の具体例２］
次に、切替処理の具体例２として、スタンバイ系の増設処理について図９、図１０を用いて説明する。
【００６１】
図９に示すように、管理者からオーケストレータに対しスタンバイ系を１台増やしてほしい旨の依頼があった場合、オーケストレータは、ＶＩＭに対し新規のスタンバイ系を１台作成するよう指示する（処理(c1)）。
【００６２】
ＶＩＭは、新規のスタンバイ系を１台作成し、作成が完了すると、新規のスタンバイ系の作成が完了した旨をオーケストレータ経由でＶＮＦＭに伝える。これを受けたＶＮＦＭは、新規に作成されたスタンバイ系（ＶＭ＿３）をＶＮＦＣ＿２の管理下に置く（処理(c2)）。
【００６３】
ＶＮＦＭは、ＶＮＦＣ＿２の管理下のＶＭの台数が増えたため、アプリケーションテーブル管理装置により以下のようにアプリケーションテーブルを更新させる。即ち、図１０（ｂ）に示すように、ＶＭ＿３のレコードを追加し、「ＶＭのＩＤ」を「３」に設定し、「ＶＮＦＣのＩＤ」と「ＶＮＦのＩＤ」それぞれを「２」に設定し、アプリケーションを「スタンバイ」に設定し、「ＳＢＹ系ＶＮＦＣのＩＤ」と「ＳＢＹ系ＶＮＦのＩＤ」それぞれを「なし」に設定する（処理(c3)）。
【００６４】
以上により、スタンバイ系の増設処理が完了する。
【００６５】
［切替処理の具体例３］
次に、切替処理の具体例３として、２台故障時の切替処理について図１１〜図１３を用いて説明する。
【００６６】
図１１に示すようにＶＮＦＭは、ＶＮＦＣ＿１のＶＭ＿１とＶＭ＿２が故障したことを検知すると、アプリケーションテーブル管理装置にどのＶＮＦＣが、ＶＭ＿１とＶＭ＿２に対応付けられたスタンバイ系かを問い合わせる（処理(d1)）。
【００６７】
アプリケーションテーブル管理装置は、ＶＮＦＣ＿２がＶＭ＿１とＶＭ＿２に対応付けられたスタンバイ系である点とスタンバイ系の数が足りない点とをＶＮＦＭに応答する。ここでは一例として、ＶＭ＿１とＶＭ＿２のうち、ＶＭ＿１を優先するものとし、ＶＭ＿３を、ＶＭ＿１の代替となるＶＭ（予約されたＶＭ）とするため、アプリケーションテーブル管理装置は、図１２の（ａ）および（ｂ）に示すように、ＶＭ＿１およびＶＭ＿２について、アプリケーションを「呼処理」から「故障」に変更し、「ＳＢＹ系ＶＮＦＣのＩＤ」と「ＳＢＹ系ＶＮＦのＩＤ」それぞれを「２」から「なし」へ変更し、ＶＭ＿３について、アプリケーションを「スタンバイ」から「予約」に変更する（処理(d2)）。
【００６８】
ＶＮＦＭは、ＶＮＦＣ＿２のＶＭ＿３にアクティブ系になるよう指示する（処理(d3)）。また、ＶＮＦＭは、オーケストレータに以下３つの処理Ｂ１、Ｂ２、Ｂ３を依頼する（処理(d4)）。
処理Ｂ１：ＶＭ＿１のネットワークをＶＭ＿３に切り替える処理
処理Ｂ２：ＶＮＦＣ＿１にアクティブ系のＶＭ＿４を１台オートヒーリングし、ＶＭ＿２のネットワークをＶＭ＿４に切り替える処理
処理Ｂ３：ＶＮＦＣ＿２にスタンバイ系を１台オートヒーリングする処理
【００６９】
ＶＮＦＣ＿２は、ＶＭ＿３のＡＣＴ切り替えが完了した旨をＶＮＦＭに伝える（処理(d5)）。また、オーケストレータは、ＶＩＭに上記処理Ｂ１、Ｂ２、Ｂ３の順に実行するよう依頼する（処理(d6)）。
【００７０】
ＶＩＭは、処理Ｂ１（ＶＭ＿３へのネットワーク切替え）を実行する（処理(d7)）。そして、ＶＩＭは、処理Ｂ１が完了した旨をオーケストレータ経由でＶＮＦＭに伝える。これを受けたＶＮＦＭは、ＶＭ＿３をＶＮＦＣ＿１の管理下に置く（処理(d8)）。
【００７１】
また、ＶＮＦＭは、ＶＭ＿１からＶＭ＿３への故障切替が完了したため、アプリケーションテーブル管理装置により以下のようにアプリケーションテーブルを更新させる。即ち、図１２（ｃ）に示すように、ＶＭ＿３について、「ＶＮＦＣのＩＤ」と「ＶＮＦのＩＤ」それぞれを「２」から「１」へ変更し、アプリケーションを「予約」から「呼処理」に変更し、「ＳＢＹ系ＶＮＦＣのＩＤ」と「ＳＢＹ系ＶＮＦのＩＤ」それぞれを「なし」から「２」へ変更させる（処理(d9)）。
【００７２】
ＶＩＭは、処理Ｂ２（ＶＮＦＣ＿１へのアクティブ系１台のオートヒーリング、ＶＭ＿４へのネットワーク切替え）を実行する（処理(d10)）。実行が完了すると、ＶＩＭは、処理Ｂ２が完了した旨をオーケストレータ経由でＶＮＦＭに伝える。これを受けたＶＮＦＭは、新規に作成されたＶＭ＿４をＶＮＦＣ＿１の管理下に置く（処理(d11)）。
【００７３】
ＶＮＦＭは、ＶＭ＿２からＶＭ＿４への故障切替が完了したため、アプリケーションテーブル管理装置により以下のようにアプリケーションテーブルを更新させる。即ち、図１３（ａ）に示すように、ＶＭ＿４のレコードを追加し、「ＶＭのＩＤ」を「４」に設定し、「ＶＮＦＣのＩＤ」と「ＶＮＦのＩＤ」それぞれを「１」に設定し、アプリケーションを「呼処理」に設定し、「ＳＢＹ系ＶＮＦＣのＩＤ」と「ＳＢＹ系ＶＮＦのＩＤ」それぞれを「２」に設定する（処理(d12)）。
【００７４】
ＶＩＭは、処理Ｂ３（ＶＮＦＣ＿２へのスタンバイ系１台のオートヒーリング）を実行し、実行が完了すると、処理Ｂ３が完了した旨をオーケストレータ経由でＶＮＦＭに伝える。これを受けたＶＮＦＭは、新規に作成されたＶＭ＿５をＶＮＦＣ＿２の管理下に置く（処理(d13)）。
【００７５】
ＶＮＦＭは、ＶＭ＿５が増えたため、アプリケーションテーブル管理装置により以下のようにアプリケーションテーブルを更新させる。即ち、図１３（ｂ）に示すように、ＶＭ＿５のレコードを追加し、「ＶＭのＩＤ」を「５」に設定し、「ＶＮＦＣのＩＤ」と「ＶＮＦのＩＤ」それぞれを「２」に設定し、アプリケーションを「スタンバイ」に設定し、「ＳＢＹ系ＶＮＦＣのＩＤ」と「ＳＢＹ系ＶＮＦのＩＤ」それぞれを「なし」に設定する（処理(d14)）。以上により、２台故障時の切替処理が完了する。
【００７６】
以上説明した実施形態により、管理システムにおいて、多数のＶＭを、アクティブ系、スタンバイ系および予備系の３つの構成で管理した上で、アクティブ系、スタンバイ系およびアプリケーション間の対応情報を保持し管理するためのアプリケーションテーブルを用いたことで、アクティブ系が１台又は複数台故障した時でも、切り替えに要する時間を短縮してユーザ影響を小さくし、ＶＭの切替えを円滑に実行することができる。また、アクティブ系とスタンバイ系に加え、特定のアプリケーションに対応付けられていない予備系を設けたことで、例えばアプリケーションごとにスタンバイ系を用意しておくといった対応は不要となり、設備コストの増大回避に資することができる。
【００７７】
なお、上記の管理システムでは、以下のようにして、アプリケーション共通の予備リソースとしての「予備系」を一定数以上確保しておくことが望ましい。即ち、予備系の台数を監視し、予備系の台数が一定以下になったとき、管理者に警告（例えば警告メッセージやアラーム音など）を出力する。この警告を受けた管理者は、新しいハードウェア資源を用意し、予備系として追加する。以上のようなしくみにより、「予備系」を一定数以上確保することができ、システムの可用性を高く維持することができる。
【符号の説明】
【００７８】
１…移動体通信システム、１０…管理システム、２０…オーケストレータ、３０…ＶＮＦＭ、３１…切替制御部、３２…補充制御部、４０…ＶＩＭ、５０…ＯＳＳ／ＢＳＳ、５１…ＯＳＳ、６０…ＮＦＶＩ、７０…ＶＮＦ、７２…ＶＮＦＣ、７４…ＶＭ、８０…ＥＭＳ、９０…アプリケーションテーブル管理装置、９１…アプリケーションテーブル、９２…テーブル管理部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…記憶装置。
【図１】
2015191246.tif 000003
【図２】
2015191246.tif 000004
【図３】
2015191246.tif 000005
【図４】
2015191246.tif 000006
【図５】
2015191246.tif 000007
【図６】
2015191246.tif 000008
【図７】
2015191246.tif 000009
【図８】
2015191246.tif 000010
【図９】
2015191246.tif 000011
【図１０】
2015191246.tif 000012
【図１１】
2015191246.tif 000013
【図１２】
2015191246.tif 000014
【図１３】
2015191246.tif 000015