JP6026705B2 - 更新管理システムおよび更新管理方法 - Google Patents

Description

本発明は、仮想サーバで稼動するアプリケーションの更新管理を行う更新管理システムおよび更新管理方法に関する。

一般的に、情報処理サービスのためのさまざまなアプリケーションは、稼動期間の経過とともに、徐々にバージョンアップ（更新）されていく（特許文献１参照）。このような情報処理サービスのアプリケーションの更新作業は、サービス提供を一時的に中断して行われるのが一般的である。

ところが、移動体通信などの通信サービスは社会的に非常に重要なインフラサービスであるため、通信サービスのためのアプリケーションの更新作業は、サービス提供を一時的に中断して行うことは困難であり、また、仮に更新作業の直後に新バージョンに不具合があった場合には、速やかに旧バージョンに戻す復旧処理を行うことで、利用者への影響を最小にしている。

特開平１１−１５６４７号公報

従来の通信サービスのアプリケーションは、ハードウェアおよびソフトウェアに強い結びつきがあり、多くのアプリケーションの更新は、当該アプリケーションが備える１つの機能として提供されていた。そのため、個々のアプリケーションによって更新作業の手順が異なっており、作業の効率化が困難であった。また、そもそも更新の機能を備えていないアプリケーションについては、例えば旧バージョンのアンインストール後に新バージョンを再インストールするといった手間のかかる作業を行う必要があり、作業の効率化が困難であった。一方、新バージョンに不具合があった場合の旧バージョンへの復旧処理についても、上記と同様の事情により作業の効率化が困難であった。以上のような事情から、新バージョンへの更新および旧バージョンへの復旧処理を含む更新関連作業を、アプリケーションの種類を問わずに効率的に実行することが待望されていた。

そこで、本発明は、上記課題を解決するために成されたものであり、通信サービスのアプリケーションについての効率的でシームレスな更新関連作業を実現することを目的とする。

本発明の一側面に係る更新管理システムは、通信サービスを実行する仮想サーバが生成される物理サーバを含む仮想化資源の各々を管理し、新バージョン仮想サーバの生成指示に基づき新バージョン仮想サーバを生成する仮想化資源管理ノードと、前記仮想サーバにより実行される通信サービスを監視するサービス監視手段と、前記新バージョン仮想サーバを生成するよう前記仮想化資源管理ノードに指示するとともに、前記新バージョン仮想サーバと旧バージョン仮想サーバ間の対応を表す新旧対応データを生成し、当該新旧対応データに基づき、前記サービス監視手段に新バージョン仮想サーバの起動があることを通知する仮想通信機能管理ノードと、を備え、前記仮想通信機能管理ノードは、前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示し、前記仮想化資源管理ノードは、当該ネットワーク切替の指示に基づき新バージョン仮想サーバへのネットワーク切替を実行することを特徴とする。このような更新管理システムにより、アプリケーションの種類を問わずに、統一的な処理手順で、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を実行することができ、効率的でシームレスな更新関連作業を実現できる。

また、上記のサービス監視手段は、前記仮想通信機能管理ノードからの通知に基づき得られる前記新旧対応データに基づいて、新バージョン仮想サーバに対し、旧バージョン仮想サーバの設定情報との同期を実施し、前記仮想通信機能管理ノードは、当該同期の完了後に、前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示し、前記仮想化資源管理ノードは、当該ネットワーク切替指示に基づき新バージョン仮想サーバへのネットワーク切替を実行してもよい。これにより、アプリケーションの種類を問わずに、統一的な処理手順で、新バージョン仮想サーバに対し、旧バージョン仮想サーバの設定情報との同期を実施することができ、効率的でシームレスな更新関連作業を実現できる。

また、上記の仮想通信機能管理ノードは、前記サービス監視手段による監視で、前記新バージョン仮想サーバにより実行される新バージョン通信サービスに異常がある場合に、前記新旧対応データに基づいて新バージョン仮想サーバおよび旧バージョン仮想サーバを特定し、新バージョン仮想サーバから旧バージョン仮想サーバへのネットワーク切り戻しを実行するよう、前記仮想化資源管理ノードに要求し、前記仮想化資源管理ノードは、当該ネットワーク切り戻し要求に基づいて、新バージョン仮想サーバから旧バージョン仮想サーバへのネットワーク切り戻しを実行してもよい。これにより、アプリケーションの種類を問わずに、統一的な処理手順で、新バージョン仮想サーバから旧バージョン仮想サーバへのネットワーク切り戻しを実行することができ、効率的でシームレスな更新関連作業を実現できる。

ところで、上記の更新管理システムは、仮想化資源の全体の管理を行うオーケストレータを更に備えた構成としてもよい。この場合、以下のような態様を採用してもよい。

即ち、上記の更新管理システムは、仮想化資源の全体の管理を行うオーケストレータ、を更に備え、上記のオーケストレータは、通信サービスのアプリケーションの新バージョンへの更新要求を受けて、新バージョン仮想サーバのためのリソース情報を前記仮想通信機能管理ノードから取得し、前記仮想化資源管理ノードに対し新バージョン仮想サーバ用のリソースを予約するとともに、予約したリソース情報および新バージョンへの更新指示を前記仮想通信機能管理ノードに送信し、前記仮想通信機能管理ノードは、予約したリソースを用いて新バージョン仮想サーバを生成するよう、前記仮想化資源管理ノードに指示してもよい。これにより、アプリケーションの種類を問わずに、統一的な処理手順で、新バージョン仮想サーバ用のリソースの予約、および当該予約したリソースを用いた新バージョン仮想サーバの生成を実行することができ、効率的でシームレスな更新関連作業を実現できる。

また、上記のサービス監視手段は、前記仮想通信機能管理ノードからの通知に基づき得られる前記新旧対応データに基づいて、新バージョン仮想サーバに対し、旧バージョン仮想サーバの設定情報との同期を実施し、オーケストレータは、当該同期の完了後に、前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示してもよい。これにより、アプリケーションの種類を問わずに、統一的な処理手順で、オーケストレータによる旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替指示を実行することができ、効率的でシームレスな更新関連作業を実現できる。

さらに、上記のオーケストレータは、前記サービス監視手段による監視で、前記新バージョン仮想サーバにより実行される新バージョン通信サービスに異常がある場合に、前記新旧対応データに基づいて新バージョン仮想サーバおよび旧バージョン仮想サーバを特定し、新バージョン仮想サーバから旧バージョン仮想サーバへのネットワーク切り戻しを前記仮想化資源管理ノードに要求してもよい。これにより、アプリケーションの種類を問わずに、統一的な処理手順で、オーケストレータによる新バージョン仮想サーバから旧バージョン仮想サーバへのネットワーク切り戻し指示を実行することができ、効率的でシームレスな更新関連作業を実現できる。

上述した「更新管理システム」に係る発明は、「更新管理方法」に係る発明として捉えることもでき、以下のように記述することができる。以下の更新管理方法に係る発明は、同様の作用・効果を奏する。

本発明の一側面に係る更新管理方法は、通信サービスを実行する仮想サーバが生成される物理サーバを含む仮想化資源の各々を管理する仮想化資源管理ノードと、前記仮想サーバにより実行される通信サービスを監視するサービス監視手段と、前記仮想サーバを管理する仮想通信機能管理ノードと、を備える更新管理システム、において実行される更新管理方法であって、前記仮想通信機能管理ノードが、新バージョン仮想サーバを生成するよう前記仮想化資源管理ノードに指示するとともに、前記新バージョン仮想サーバと旧バージョン仮想サーバ間の対応を表す新旧対応データを生成し、当該新旧対応データに基づき、前記サービス監視手段に新バージョン仮想サーバの起動があることを通知するステップと、前記仮想化資源管理ノードが、前記新バージョン仮想サーバの生成指示に基づき前記新バージョン仮想サーバを生成するステップと、前記仮想通信機能管理ノードが、前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示するステップと、前記仮想化資源管理ノードが、当該ネットワーク切替の指示に基づき新バージョン仮想サーバへのネットワーク切替を実行するステップと、を含むことを特徴とする。

上記の「ネットワーク切替を実行するステップ」では、前記仮想化資源管理ノードが、当初はネットワークから旧バージョン仮想サーバを切り離すことなく新バージョン仮想サーバをネットワークに接続し、前記更新管理システム内で外部からのパケットのあて先を振り分ける振分手段が、新規に開始された処理から順にパケットのあて先を新バージョン仮想サーバへ振り分けていき、切替前から継続する処理が無くなったとき又は所定の新バージョン監視期間が満了したときに、前記仮想化資源管理ノードが、ネットワークから旧バージョン仮想サーバを切り離す、といった一連の処理を実行してもよい。上記のようなネットワーク切替は、複数の信号の往復で処理が完了する通信サービスに適用可能であり、このようなタイプの通信サービスであっても、ネットワーク切替による処理途中での異常終了を防止することができる。

本発明の一側面によれば、通信サービスのアプリケーションについての効率的でシームレスな更新関連作業を実現することができる。

本発明の一側面の実施形態に係る更新管理システムの全体構成図である。 第１実施形態の機能ブロック構成図である。 更新管理システムに含まれるノードのハードウェア構成例を示す図である。 オーケストレータにより保持されるデータを示す図であり、（ａ）は新旧対応データを、（ｂ）はＶＮＦ構成データを、（ｃ）はＶＮＦＣ構成データを、それぞれ示す。 ＶＮＦＭにより保持されるデータを示す図であり、（ａ）は更新条件データを、（ｂ）は新旧対応データを、（ｃ）はＶＮＦ構成データを、（ｄ）はＶＮＦＣ構成データを、それぞれ示す。 ＥＭＳにより保持されるデータを示す図であり、（ａ）は新旧対応データを、（ｂ）はＶＮＦ構成データを、（ｃ）は設定データを、それぞれ示す。 第１実施形態における新バージョンＶＮＦの生成までの処理フロー図である。 第１実施形態における設定同期およびネットワーク切替に関する処理フロー図である。 第１実施形態における新バージョンＶＮＦの正常稼動時（不具合未検出時）の処理フロー図である。 第１実施形態における新バージョンＶＮＦの異常発生時（不具合検出時）の処理フロー図である。 第１実施形態における更新の状態遷移を説明する図であり、（ａ）はオーケストレータにおける更新の状態遷移を、（ｂ）はＶＮＦＭにおける更新の状態遷移を、それぞれ示す。 ネットワーク切替の第１の方法を説明する図であり、（ａ）は第１の方法を実行する際の構成図を、（ｂ）はフローテーブルを、それぞれ示す。 ネットワーク切替の第２の方法を説明する図であり、（ａ）は第２の方法を実行する際の構成図を、（ｂ）は操作前のフローテーブルを、（ｃ）は監視中のフローテーブルを、（ｄ）は確定後のフローテーブルを、それぞれ示す。 第２実施形態の機能ブロック構成図である。 第２実施形態における新バージョンＶＮＦの生成までの処理フロー図である。 第２実施形態における設定同期およびネットワーク切替に関する処理フロー図である。 第２実施形態における新バージョンＶＮＦの正常稼動時（不具合未検出時）の処理フロー図である。 第２実施形態における新バージョンＶＮＦの異常発生時（不具合検出時）の処理フロー図である。 第２実施形態における更新の状態遷移を説明する図であり、（ａ）はオーケストレータにおける更新の状態遷移を、（ｂ）はＶＮＦＭにおける更新の状態遷移を、それぞれ示す。

以下、図面と共に本発明の一側面に係る更新管理システム及び更新管理方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

［第１実施形態］
以下、第１実施形態として、「オーケストレータ」が中心的に動作する更新管理方法（第１の方法）に関する実施形態を説明する。

［更新管理システムの全体構成］
図１に本実施形態に係る更新管理システム１の全体構成図を示す。図１に示すように更新管理システム１は、オーケストレータ２０と、ＶＮＦＭ３０と、ＶＩＭ（Virtualised Infrastructure Manager）４０と、ＯＳＳ／ＢＳＳ（Operations Support System／Business Support System）５０と、ＮＦＶＩ（Network Functions Virtualisation 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）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述及び後述するオーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０の機能が発揮される。なお、オーケストレータ２０、ＶＮＦＭ３０及びＶＩＭ４０は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。また、更新管理システム１に含まれる上記以外のノードも上記のハードウェア構成を有するサーバ装置によって実現されてもよい。

［保持されるデータについて］
以下、オーケストレータ２０、ＶＮＦＭ３０およびＥＭＳ８０により保持されるデータについて説明する。

オーケストレータ２０は、データ保持部２１に、図４（ａ）に例示する新旧対応データ、図４（ｂ）に例示するＶＮＦ構成データ、図４（ｃ）に例示するＶＮＦＣ構成データを保持する。このうち、新旧対応データは、更新通知の応答にてオーケストレータ２０がＶＮＦＭ３０から必要な情報を取得することにより生成され、その後の更新確定又はネットワーク切り戻しの際に削除される。新旧対応データには、図４（ａ）のように受付番号、新ＶＮＦ番号、旧ＶＮＦ番号、ＶＮＦ種別、バージョン、ネットワーク構成、および状態が含まれる。ＶＮＦ構成データには、図４（ｂ）のようにＶＮＦ番号、ＶＮＦ種別、バージョン、および構成情報が含まれ、このうち構成情報は、第１実施形態のようにオーケストレータ２０がＶＩＭ４０にネットワーク切替・切り戻し等を指示する場合のみ保持される。ＶＮＦＣ構成データには、図４（ｃ）のようにＶＮＦＣ番号、ＶＮＦＣ種別、バージョン、および構成情報が含まれ、このＶＮＦＣ構成データは第１実施形態のようにオーケストレータ２０がＶＩＭ４０にネットワーク切替・切り戻し等を指示する場合のみ保持される。

ＶＮＦＭ３０は、データ保持部３１に、図５（ａ）に例示する更新条件データ、図５（ｂ）に例示する新旧対応データ、図５（ｃ）に例示するＶＮＦ構成データ、図５（ｄ）に例示するＶＮＦＣ構成データを保持する。このうち、更新条件データは事前に保持されているものであり、更新条件データには、図５（ａ）のようにＶＮＦ種別、旧バージョン、新バージョン、およびネットワーク構成が含まれる。新旧対応データは、ＶＮＦＭ３０により更新通知時に生成され、その後の更新確定又はネットワーク切り戻しの際に削除される。この新旧対応データには、図５（ｂ）のように受付番号、新ＶＮＦ番号、旧ＶＮＦ番号、ＶＮＦ種別、バージョン、および状態が含まれる。ＶＮＦ構成データはＶＮＦ生成時に生成され、ＶＮＦ構成データには、図５（ｃ）のようにＶＮＦ番号、ＶＮＦ種別、バージョン、および構成情報が含まれる。ＶＮＦＣ構成データには、図５（ｄ）のようにＶＮＦＣ番号、ＶＮＦＣ種別、バージョン、および構成情報が含まれ、このＶＮＦＣ構成データは後述の第２実施形態のようにＶＮＦＭ３０がＶＩＭ４０にネットワーク切替・切り戻し等を指示する場合のみ保持される。

ＥＭＳ８０は、データ保持部８１に、図６（ａ）に例示する新旧対応データ、図６（ｂ）に例示するＶＮＦ構成データ、図６（ｃ）に例示する設定データを保持する。このうち、新旧対応データは、ＥＭＳ８０により更新通知受信時に生成され、その後の新ＶＮＦ削除時若しくは旧ＶＮＦ削除時に削除される。この新旧対応データには、図６（ａ）のように新ＶＮＦ番号、旧ＶＮＦ番号、バージョン、および状態が含まれる。ＶＮＦ構成データには、図６（ｂ）のようにＶＮＦ番号、ＶＮＦ種別、バージョン、および構成情報が含まれる。設定データには、図６（ｃ）のようにＶＮＦ番号および設定データが含まれる。

［第１実施形態における処理内容］
以下、図７〜図１０を用いて第１実施形態における処理内容を説明する。図７には新バージョンＶＮＦの生成までの処理フローが、図８には設定同期およびネットワーク切替に関する処理フローが、図９には新バージョンＶＮＦの正常稼動時（不具合未検出時）の処理フローが、図１０には新バージョンＶＮＦの異常発生時（不具合検出時）の処理フローが、それぞれ示されており、以下順に説明する。なお、図面上では、「ネットワーク」を「ＮＷ」と略記する。

（図７：新バージョンＶＮＦの生成までの処理フロー）
ＯＳＳ／ＢＳＳは、すでに生成したＶＮＦを新バージョンに適用するため、対象サービス内のＶＮＦを指定して、オーケストレータに更新を要求する（ステップＳ１）。なお、対象サービス、ＶＮＦ種別、現行バージョンの対応に関しては、事前に若しくはＶＮＦ生成時に、ＯＳＳ／ＢＳＳにて保持されている。このとき送信される信号は、（通信サービス、ＶＮＦ種別、バージョン情報）を含む更新要求信号であり、設定例として（通信サービス：通信サービス１、ＶＮＦ種別：VNF10、バージョン：1.5）が例示される。

オーケストレータは、更新要求の受付応答を行った（ステップＳ２）後、更新対象のＶＮＦを生成するため、ＶＮＦの指定バージョンに必要となる資源情報をＶＮＦＭへ問い合わせる（ステップＳ３）。このとき送信される信号は、（イベント番号、ＶＮＦ種別、性能条件）を含む必要資源問い合わせ信号であり、設定例として（イベント番号：xxxxx（注：Request-Responseの対応付けのための番号である）、ＶＮＦ種別：VNF10、性能条件：100、バージョン：1.5）が例示される。または、オーケストレータへあらかじめＶＮＦの情報を登録しておくことにより、資源情報の問い合わせを省略してもよい。

ＶＮＦＭは、要求のあったＶＮＦの指定バージョンの性能条件に合う資源情報をオーケストレータへ応答する（ステップＳ４）。なお、性能条件、ＶＮＦバージョン、資源情報は、事前にＶＮＦＭが保持している。このとき送信される信号は、必要資源情報を含む必要情報応答信号であり、設定例として（CPU:LOW、ＶＭ数：４、ネットワーク帯域：1Gbps、DC分離可）が例示される。

オーケストレータは、必要資源問い合わせにより得た情報をもとにＶＩＭへ予約を行う（ステップＳ５）。このとき送信される信号は、（DC、必要資源情報（ＶＭ、ネットワーク））を含む資源予約要求信号であり、設定例として（DC：DC1→オーケストレータが必要資源から導いたDataCenter、必要資源情報（CPU：High、ＶＭ数：１、ネットワーク帯域：１Gbps））が例示される。なお、これ以降の手順は、更新を要求されたＶＮＦ種別のＶＮＦすべてに対して実施するため、繰り返し処理されるか又は並行処理される。または、オーケストレータにすべてのＶＩＭ制御下の資源情報を事前登録することにより、オーケストレータによって予約がなされてもよく、この場合ＶＩＭへの問い合わせを省略してもよい。

ＶＩＭは、予約要求の情報と管理下のリソース情報により予約を実施し（ステップＳ６）、その予約完了をオーケストレータへ応答する（ステップＳ７）。このとき送信される信号は、予約番号を含む資源予約応答信号である。

オーケストレータは、予約が完了すると、更新後のＶＮＦへIDを発行して、新旧対応テーブルのレコード（即ち、図４（ａ）の新旧対応データ）を生成・保持し、更新対象ＶＮＦを管理するＶＮＦＭに対し事前に更新開始を通知する（ステップＳ８）。なお、通知先ＶＮＦＭと対応するＶＮＦ種別は、オーケストレータで保持している。このとき送信される信号は、（ＶＮＦ種別、旧ＶＮＦ番号、新ＶＮＦ番号、更新バージョン）を含む更新開始通知信号であり、設定例として（ＶＮＦ種別：VNF10、旧ＶＮＦ番号：VNF10_1、新ＶＮＦ番号：VNF10_2、バージョン：1.5）が例示される。

更新開始通知信号を受信したＶＮＦＭは、受信した更新開始通知信号内の情報を基に新旧対応テーブルのレコード（即ち、図５（ｂ）の新旧対応データ）を生成・保持する。そして、ＶＮＦＭは、新バージョンにて起動したＶＮＦへ設定情報を同期するため、ＶＮＦの設定管理を行うＥＭＳに対し更新開始を事前に通知する（ステップＳ９）。なお、このとき通知される信号は、（旧ＶＮＦ番号、新ＶＮＦ番号、更新バージョン）を含む更新開始通知信号であり、設定例として（旧ＶＮＦ番号：VNF10_1、新ＶＮＦ番号：VNF10_2、バージョン:1.5）が例示される。

ＥＭＳは、要求受信後、Ackを応答する（ステップＳ１０）。このとき、ＥＭＳは、ＶＮＦＭからの信号内の情報を基に、新旧対応テーブルのレコード（即ち、図６（ａ）の新旧対応データ）を生成・保持する。

ＶＮＦＭは、ＥＭＳからのAck応答を受けると、オーケストレータへAckを応答する（ステップＳ１１）。この応答の際にＶＮＦＭはＶＮＦ構成・配置・起動情報を付与する。このとき送信される信号は、ＶＮＦ構成・配置・起動情報を含むAck信号であり、設定例として（ＶＮＦＣ種別、個数、構成情報（Image:VNFCI_100_1、NIC_1:1G:ON、NIC_2:OFF））が例示される。

オーケストレータは、更新開始通知の完了後、ＶＩＭへＶＮＦ生成要求を行う（ステップＳ１２）。ただし、ＶＮＦ生成の際に、ネットワーク切替のため、ネットワーク構成情報に加えて、ネットワーク接続状態を指定し、切替タイミングまで新バージョンのＶＮＦをネットワークに接続しないようにする。このとき送信される信号は、（予約番号、配置・起動情報、ネットワーク構成情報（帯域、構成、ネットワーク接続状態））を含むＶＮＦ生成要求信号であり、設定例として（配置・起動情報：DC:DC2、CPU：High、ＶＭ数:１、ＶＮＦＣ種別：VNFC100、VNFCI_100_2、ネットワーク構成情報（帯域：１Gbps、構成：{NIC_1、IPアドレス、ON}、{NIC_2、IPアドレス、OFF}）が例示される。

ＶＩＭは、生成要求を受け、ＮＦＶＩに対して、サーバ生成・起動を実施する（ステップＳ１３）。そして、サーバ生成・起動実施後に、ＶＩＭはＶＮＦ生成応答を通知する（ステップＳ１４）。このとき送信される信号は、（予約番号、成否、サーバ識別番号）を含むＶＮＦ生成応答信号であり、設定例として（予約番号：生成時の予約番号、成否：起動成否、サーバ識別番号：起動完了した仮想サーバの識別子VNFC100_2）が例示される。

これにより、ＮＦＶＩは、ステップＳ１５のサーバ生成・起動によりＶＮＦ２（新バージョンのＶＮＦ）を起動する。なお、サーバが複数ある場合は繰り返し生成される。

（図８：設定同期およびネットワーク切替に関する処理フロー）
新バージョンのＶＮＦ２は、サーバのブートが実行されアプリケーションが起動する（ステップＳ１６）。

そして、アプリケーションの起動後、ＥＭＳは、保持した新旧対応テーブルを参照して新バージョンのＶＮＦ（ＶＮＦ２）および旧バージョンのＶＮＦ（ＶＮＦ１）を特定し、これらＶＮＦ１、２と相互に通信しながら、ＶＮＦ２に対し、旧バージョンのＶＮＦ１の設定情報との同期を実施する（ステップＳ１７）。

ＥＭＳは、同期が完了すると、ＶＮＦＭおよびＯＳＳ／ＢＳＳへ起動完了を通知する（ステップＳ１８、Ｓ１９）。このとき送信される信号は、ＶＮＦ番号を含む起動・設定完了信号であり、設定例として（ＶＮＦ番号：VNF10_2）が例示される。ただし、この時点ではまだ、ＶＮＦ１がサービスに係る信号を処理している（ステップＳ２０）。

ＯＳＳ／ＢＳＳは、新ＶＮＦが起動・設定完了を確認後、オーケストレータへネットワーク切替を要求する（ステップＳ２１）。このとき送信される信号は、（受付番号、ＶＮＦ種別、切替元ＶＮＦ番号）を含むネットワーク切替要求信号であり、設定例として（受付番号：更新要求の際に発行された受付番号、ＶＮＦ種別：更新対象のＶＮＦ種別（VNF10）、切替元ＶＮＦ番号：切替対象のＶＮＦ番号（VNF10_1））が例示される。

オーケストレータは、切替要求を受け、切替元ＶＮＦ番号（旧ＶＮＦ番号）をキーに新旧対応テーブルを確認して切替対象のＶＮＦの番号（新ＶＮＦ番号）を特定し、切替対象のＶＮＦ（新ＶＮＦ）を管理するＶＩＭに対し、ネットワーク切替指示を送信する（ステップＳ２２）。ネットワーク切替指示において、図１の振分装置６３への接続が必要な場合は、接続に必要な所定の情報を付与する。振分装置６３による振分けについては図１３を用いて後述する。なお、このとき送信される信号は、（予約番号、サーバ識別番号、ネットワーク構成情報）を含むネットワーク切替指示信号であり、設定例として（予約番号：資源予約の際の番号、サーバ識別番号：切替を行うサーバ識別番号、ネットワーク構成情報（帯域：１Gbps、構成：NIC_2、IPアドレス、ON(切替装置への接続)）が例示される。

ＶＩＭは、ネットワーク切替指示に応じて、ＮＦＶＩに対してネットワーク切替を実施する（ステップＳ２３）。

ＮＦＶＩは、ネットワーク切替を実施し（ステップＳ２４）、これにより、サービスに関する信号がＶＮＦ２へ送信されることとなる。具体的には、ネットワークの切替には、サーバ１、サーバ２に関して、同一のIPアドレスを付与し、OpenFlow（オープンフロー）のように、フロー（IPパケットおよびEtherフレーム内のいくつかのフィールドの組み合わせで定義）ベースで宛先を変更する仕組みを利用し、付与した同一のIPパケットに対する送信先NIC（仮想ポート）を変更することで、ネットワーク切替を実現する。これにより、サービスに関する信号がサーバ２へ送信され（ステップＳ２５）、サーバ２による処理が実行開始される。

ＶＩＭは、ネットワーク切替完了通知をオーケストレータへ送信し（ステップＳ２６）、オーケストレータは、ネットワーク切替応答をＯＳＳ／ＢＳＳへ送信する（ステップＳ２７）。

ＥＭＳおよびＶＮＦ２は、サービスの状態（処理成否数等）をＯＳＳ／ＢＳＳへ通知する（ステップＳ２８、Ｓ２９）。なお、サービスによって通知する状態は異なる。

ＯＳＳ／ＢＳＳは、サービスの状態の通知を監視し、不具合がないかのサービス監視を一定期間行う（ステップＳ３０）。

（図９：新バージョンＶＮＦの正常稼動時（不具合未検出時）の処理フロー）
決められたサービス監視期間が満了し、不具合が検出されなかった場合の処理は以下である。

ＯＳＳ／ＢＳＳは、オーケストレータへ更新確定要求を送信する（ステップＳ４１）。この送信トリガーとしては、人が判断するもしくは一定期間経過後に自動送信とする。このとき送信される信号は、受付番号を含む更新確定要求信号であり、設定例として（受付番号：更新要求時に発行された受付番号）が例示される。

オーケストレータは、新バージョンＶＮＦのＶＮＦ番号をキーに、保持した新旧対応テーブルを参照して、削除すべき旧バージョンＶＮＦ（ＶＮＦ１）のＶＮＦ番号を取得し、更新確定通知をＶＮＦＭへ通知し（ステップＳ４２）、ＶＩＭへ旧ＶＮＦの削除要求を送信する（ステップＳ４３）。このときの更新確定通知としては、（ＶＮＦ種別：VNF100、ＶＮＦ番号：VNF100_1）を含む更新確定通知信号が送信される。また、削除要求としては、（予約番号、ＶＮＦ番号：VNF100_1）を含むＶＮＦ削除要求信号が送信され、設定例として（予約番号：旧ＶＮＦを生成した際の予約番号）が例示される。

ＶＮＦＭは、更新確定通知をＥＭＳへ通知する（ステップＳ４４）。このとき送信される信号は、（ＶＮＦ種別：VNF100、ＶＮＦ番号：VNF100_1）を含む更新確定通知信号である。

ＥＭＳは、更新確定通知をうけ、旧ＶＮＦアプリケーションの停止処理を実施する（ステップＳ４５）。なお、停止処理の際に、旧ＶＮＦのログの退避等も含めてもよい。

ＶＩＭは、削除要求を受けＮＦＶＩに対し、サーバ停止・削除を行い（ステップＳ４６）、その実行結果をオーケストレータに応答し（ステップＳ４８）、資源を解放する。このとき送信される信号は、予約番号を含むＶＮＦ削除応答信号である。これにより、ＶＮＦ１は、ステップＳ４７の削除実施により消滅する。

オーケストレータは、削除応答をうけ、ＯＳＳ／ＢＳＳへ更新確定応答を通知する（ステップＳ４９）。

（図１０：新バージョンＶＮＦの異常発生時（不具合検出時）の処理フロー）
新ＶＮＦ（ＶＮＦ２）上で不具合が発生すると、ＥＭＳが不具合を検出し（ステップＳ６１）、ＥＭＳはＯＳＳ／ＢＳＳに対しサービス処理の異常があることを通知する（ステップＳ６２）。

ＯＳＳ／ＢＳＳは、更新前に戻すため、更新切戻し要求を全体管理へ要求する（ステップＳ６３）。このとき送信される信号は、（受付番号、削除要否）を含む更新切戻し要求信号である。

オーケストレータは、更新切戻し要求を受け、保持した新旧対応テーブルを参照して新旧バージョンのＶＮＦの対応関係を把握し、新バージョンＶＮＦ（ＶＮＦ２）のＶＮＦ番号を取得し、ＶＮＦＭへ切戻し通知を送信し（ステップＳ６４）、ＶＩＭへネットワーク切戻し要求を送信する（ステップＳ６５）。このときの切戻し通知としては、（ＶＮＦ番号：VNF100_2）を含む切戻し通知信号が送信される。また、ネットワーク切戻し要求としては、新ＶＮＦを予約した予約番号を含むネットワーク切戻し要求信号が送信される。

ＶＮＦＭは、ＥＭＳへ切戻し通知を送信する（ステップＳ６６）。このとき送信される信号は、（ＶＮＦ番号：VNF100_2）を含む切戻し通知信号である。

ＶＮＦ２を管理するＥＭＳは、ＶＮＦ２のアプリケーションを停止する（ステップＳ６７）。

ＶＩＭは、ＮＦＶＩへネットワーク切替を指示し（ステップＳ６８）、ネットワーク切戻し応答をオーケストレータへ送信する（ステップＳ６９）。

ＮＦＶＩは、ネットワーク切替を実施する（ステップＳ７０）。これにより、サービス関連の信号がＶＮＦ１へ送信されることとなる（ステップＳ７１）。

オーケストレータは、ＶＩＭからのネットワーク切戻し応答を受けて、ＯＳＳ／ＢＳＳへ更新切戻し応答を通知する（ステップＳ７５）。この際に、オーケストレータは、切戻し要求での削除要否に応じてサーバ削除処理を行う。即ち、オーケストレータは、ＶＩＭへサーバ削除要求を送信し（ステップＳ７２）、ＶＩＭはＮＦＶＩへサーバ削除を指示し（ステップＳ７３）、ＮＦＶＩはサーバ（ＶＮＦ２）を削除する（ステップＳ７４）。

なお、オーケストレータおよびＶＮＦＭにより保持された新旧対応データ（新旧対応テーブル内の該当レコード）は、更新確定又はネットワーク切戻しの際に削除される。ＥＭＳにより保持された新旧対応データ（新旧対応テーブル内の該当レコード）は、新ＶＮＦ又は旧ＶＮＦの削除時に削除される。

［更新の状態遷移について］
ここで、図１１を用いて、第１実施形態におけるオーケストレータ２０およびＶＮＦＭ３０それぞれの更新の状態遷移について説明する。なお、図１１に記載した「テーブル」とは、新旧対応データの１レコードを意味する。

図１１（ａ）に示すように、オーケストレータ２０の「更新の状態」は、オーケストレータ２０が更新要求を受信し資源予約を送信するとともに今回の更新に関連したテーブルを生成したとき、初期状態（更新起動前／完了後）から「予約中」へ遷移する。ここで、予約が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

次に、オーケストレータ２０が更新通知を送信しＶＮＦ生成を指示したとき、更新の状態は、「予約中」から「更新中」へ遷移する。ここで、ＶＮＦ生成が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

さらに、オーケストレータ２０がネットワーク切替要求を受信しネットワーク切替を実施したとき、更新の状態は、「更新中」から「監視中」へ遷移する。その後、更新確定又はネットワーク切り戻しとなり上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

図１１（ｂ）に示すように、ＶＮＦＭ３０の「更新の状態」は、ＶＮＦＭ３０が更新通知を受信するとともに今回の更新に関連したテーブルを生成したとき、初期状態（更新起動前／完了後）から「更新中／監視中」へ遷移する。その後、更新確定通知又はネットワーク切り戻し通知を受信し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

［ネットワーク切替の方法について］
ここで、新バージョンＶＮＦへのネットワーク切替の方法を説明する。本実施形態では、旧バージョンのＶＮＦ１と設定を同期させた新バージョンのＶＮＦ２を生成し、ネットワークのデータフローをＶＮＦ１からＶＮＦ２へ切り替えることで、ＶＮＦ２へのネットワーク切替を実行する。このときのネットワーク切替方法として、あるタイミングで一度に切り替える方法（第１の方法）と、新規に開始された処理から順にパケットのあて先をＶＮＦ２へ振り分けていく方法（第２の方法）とが例示される。第１の方法は、一往復のリクエスト／レスポンスで処理が完了するサービスに適用可能であり、第２の方法は、複数回にわたる信号の往復で処理が完了するサービスに適用可能である。以下、これらを順に説明する。

（第１の方法）
図１２（ａ）に第１の方法を実行する際の構成図を示す。即ち、ＮＦＶＩ６０には、仮想ネットワーク上の仮想スイッチ６１Ａが生成され、仮想スイッチ６１Ａには、外部からのパケットのインタフェースとなるポート３と、旧バージョンのＶＮＦ１の仮想インタフェース６４Ａと接続されたポート１と、新バージョンのＶＮＦ２の仮想インタフェース６４Ｂと接続されたポート２とが生成される。なお、図面上では、仮想スイッチは「仮想ＳＷ」、仮想インタフェースは「仮想Ｉ／Ｆ」と略記する。

仮想スイッチ６１Ａは、図１２（ｂ）に示すフローテーブルを内部に保持し、このフローテーブルの内容にしたがってデータの転送先を切り替える。この例では、仮想スイッチ６１Ａは、図１２（ｂ）のフローテーブルに示すように、ネットワーク切替前は、ポート３から入ったパケット（外部ネットワークからのＶＮＦのＩＰ宛パケット）をポート１へ転送することで、旧バージョンのＶＮＦ１へ転送する。そして、ネットワーク切替指示のタイミングで、仮想スイッチ６１Ａは、フローテーブルの「転送先」をポート２に変更することで、これ以降の外部ネットワークからのＶＮＦのＩＰ宛パケットをポート２へ転送する。これにより、新バージョンのＶＮＦ２へのネットワーク切替が正常に実行される。その後、ＶＮＦ２に不具合が発生した場合のネットワーク切戻しのタイミングでは、仮想スイッチ６１Ａは、フローテーブルの「転送先」をポート１に変更することで、これ以降の外部ネットワークからのＶＮＦのＩＰ宛パケットをポート１へ転送する。これにより、旧バージョンのＶＮＦ１へのネットワーク切戻しが正常に実行される。

（第２の方法）
図１３（ａ）に第２の方法を実行する際の構成図を示す。即ち、ＮＦＶＩ６０には、仮想ネットワーク上の仮想スイッチ６１Ａと振分装置６３とが生成され、仮想スイッチ６１Ａには、図１２（ａ）と同様のポート１〜３に加え、振分装置６３へ出力するためのポート４と、振分装置６３からの入力を受け入れるためのポート５とが生成される。なお、振分装置６３は、その実現方法は特定の方法に限定されるものではなく、例えば、既存の仮想サーバを一時的に接続することで実現してもよいし、一時的に生成された仮想サーバにより実現してもよい。

仮想スイッチ６１Ａは、図１３（ｂ）〜（ｄ）に示すようなフローテーブルを内部に保持し、このフローテーブルの内容にしたがってデータの転送先を切り替える。ここで、仮想スイッチ６１Ａは、ネットワーク切替の操作前は、図１３（ｂ）のフローテーブルに示すように、ポート３から入ったパケット（外部ネットワークからのＶＮＦのＩＰ宛パケット）をポート１へ転送することで、旧バージョンのＶＮＦ１へ転送する。そして、ネットワーク切替指示後の監視中の状態では、仮想スイッチ６１Ａは、図１３（ｃ）のフローテーブルに示すように、ポート３から入ったパケット（外部ネットワークからのＶＮＦのＩＰ宛パケット）をポート４へ転送することで、振分装置６３へ転送する。

振分装置６３は、受信したパケットが継続中の処理のパケットか新規処理のパケットかを判別し、継続中の処理のパケットの場合は当該パケットの属性情報（例えばＶＬＡＮ（（Virtual Local Area Network）））に「100」をマーキングして仮想スイッチ６１Ａへ転送し、新規処理のパケットの場合は当該パケットの属性情報（例えばＶＬＡＮ）に「200」をマーキングして仮想スイッチ６１Ａへ転送する。

そして、仮想スイッチ６１Ａは、図１３（ｃ）のフローテーブルに示すように、ポート５から入ったパケット（振分装置６３からのパケット）のＶＬＡＮを確認し、ＶＬＡＮが「100」のパケット（継続中の処理のパケット）をポート１へ転送し、ＶＬＡＮが「200」のパケット（新規処理のパケット）をポート２へ転送する。これにより、継続中の処理のパケットは旧バージョンのＶＮＦ１へ転送され、新規処理のパケットは新バージョンのＶＮＦ２へ転送される。

その後、所定の新バージョン監視期間が満了して切替が確定した後は、仮想スイッチ６１Ａは、図１３（ｄ）のフローテーブルに示すように、ポート３から入ったパケット（外部ネットワークからのＶＮＦのＩＰ宛パケット）をポート２へ転送することで、新バージョンのＶＮＦ２へ転送する。これにより、新バージョンのＶＮＦ２へのネットワーク切替が完了する。なお、所定の新バージョン監視期間満了以外に、継続中の処理のパケットが無くなったタイミングで図１３（ｄ）のフローテーブルに基づく転送に移行しても構わない。

上記のような第２の方法により、複数回にわたる信号の往復で処理が完了するサービスであっても、ネットワーク切替による処理途中での異常終了を防止することができる。

以上説明した第１実施形態により、アプリケーションの種類を問わずに、統一的な処理手順で、新バージョンへの更新および旧バージョンへの復旧処理を含む更新関連作業を効率的に実行することができる。即ち、効率的でシームレスな更新関連作業を実現できる。

［第２実施形態］
以下、第２実施形態として、「仮想通信機能管理ノード（ＶＦＮＭ）」が中心的に動作する更新管理方法（第２の方法）に関する実施形態を説明する。

［更新管理システム１における機能ブロック構成］
図１４に、第２実施形態における機能ブロック構成を示す。

まず、新バージョンＶＮＦの生成に関連した機能ブロック構成として以下が挙げられる。

オーケストレータ２０が、通信サービスのアプリケーションの新バージョンへの更新要求を受けて、新バージョンＶＮＦのためのリソース情報をＶＮＦＭから取得するリソース情報取得部２２と、ＶＩＭ４０に対し新バージョンＶＮＦ用のリソースを予約するとともに、予約したリソース情報および新バージョンへの更新指示をＶＮＦＭに送信するリソース予約部２３と、を備える。ＶＮＦＭ３０が、予約したリソースを用いて新バージョンＶＮＦを生成するようＶＩＭ４０に指示するとともに、新バージョンＶＮＦと旧バージョンＶＮＦ間の対応を表す新旧対応データを生成・保持するＶＮＦ生成指示部３３と、生成した新旧対応データに基づき、ＥＭＳ８０に新バージョンＶＮＦの起動があることを通知するＶＮＦ起動通知部３２Ａと、を備える。ＶＩＭ４０が、新バージョンＶＮＦの生成指示に基づき新バージョンＶＮＦを生成するＶＮＦ生成部４１、を備える。ＥＭＳ８０が、ＶＮＦＭ３０からの通知に基づき得られる新旧対応データに基づいて、新バージョンＶＮＦに対し、旧バージョンＶＮＦの設定情報との同期を実施する同期実施部８２、を備える。

次に、設定同期およびネットワーク切替に関連した機能ブロック構成として以下が挙げられる。

ＶＮＦＭ３０がさらに、同期完了後にＶＩＭ４０に対し、旧バージョンＶＮＦから新バージョンＶＮＦへのネットワーク切替を指示する切替指示部３４、を備える。ＶＩＭ４０がさらに、ネットワーク切替指示に基づき新バージョンＶＮＦへのネットワーク切替を実行する切替実行部４２、を備える。ＥＭＳ８０がさらに、新バージョンＶＮＦにより実行される新バージョン通信サービスを監視する監視部８３、を備える。

さらに、ネットワーク切り戻しに関連した機能ブロック構成として以下が挙げられる。

ＶＮＦＭ３０がさらに、ＥＭＳ８０による監視で新バージョン通信サービスに不具合が発見された場合に、保持した新旧対応データに基づいて新バージョンＶＮＦおよび旧バージョンＶＮＦを特定し、新バージョンＶＮＦから旧バージョンＶＮＦへのネットワーク切り戻しをＶＩＭ４０に要求する切り戻し要求部３５、を備える。ＶＩＭ４０がさらに、ネットワーク切り戻し要求に基づいて、新バージョンＶＮＦから旧バージョンＶＮＦへのネットワーク切り戻しを実行する切り戻し実行部４３、を備える。

さらに、オーケストレータ２０、ＶＮＦＭ３０およびＥＭＳ８０は、第１実施形態で説明した新旧対応データ等のデータを保持するデータ保持部２１、３１、８１をそれぞれ備える。

なお、ハードウェア構成（図３）は第１実施形態と同様であるため、説明を省略する。また、保持されるデータ（図４〜図６）についても、第１実施形態と同様であるため、重複した説明を省略する。

［第２実施形態における処理内容］
以下、図１５〜図１８を用いて第２実施形態における処理内容を説明する。図１５には新バージョンＶＮＦの生成までの処理フローが、図１６には設定同期およびネットワーク切替に関する処理フローが、図１７には新バージョンＶＮＦの正常稼動時（不具合未検出時）の処理フローが、図１８には新バージョンＶＮＦの異常発生時（不具合検出時）の処理フローが、それぞれ示されており、以下順に説明する。なお、ネットワーク切替の詳細な方法（図１２、図１３）は、第１実施形態と同様であるため、以下では説明を省略する。

（図１５：新バージョンＶＮＦの生成までの処理フロー）
ＯＳＳ／ＢＳＳは、すでに生成したＶＮＦを新バージョンに適用するため、対象サービス内のＶＮＦを指定して、オーケストレータに更新を要求する（ステップＳ１０１）。なお、対象サービス、ＶＮＦ種別、現行バージョンの対応に関しては、事前に若しくはＶＮＦ生成時に、ＯＳＳ／ＢＳＳにて保持されている。このとき送信される信号は、（通信サービス、ＶＮＦ種別、バージョン情報）を含む更新要求信号であり、設定例として（通信サービス：通信サービス１、ＶＮＦ種別：VNF10、バージョン：1.5）が例示される。

オーケストレータは、更新要求の受付応答を行った（ステップＳ１０２）後、更新対象のＶＮＦの指定バージョンに必要となる資源情報をＶＮＦＭへ問い合わせる（ステップＳ１０３）。このとき送信される信号は、（イベント番号、候補リソース、ＶＮＦ種別、バージョン）を含む必要資源問い合わせ信号であり、このとき「候補リソース」にはＶＩＭのリスト等が設定される。

ＶＮＦＭは、候補リソースから選択し、DC毎の必要資源情報を応答する（ステップＳ１０４）。このとき送信される信号は、（イベント番号、必要資源情報）を含む必要資源問い合わせ応答信号であり、設定例として（イベント番号：問い合わせで指定された番号、必要資源情報：各DCに割り当てる資源情報（CPU、ＶＭ数、ネットワーク帯域））が例示される。

オーケストレータは、必要資源情報をもとに資源予約を実施する（ステップＳ１０５）。このとき送信される信号は、（DC、必要資源情報）を含む資源予約要求信号である。

ＶＩＭは、予約要求の情報と管理下のリソース情報により予約を実施する（ステップＳ１０６）。そして、ＶＩＭは予約完了を応答する（ステップＳ１０７）。このとき送信される信号は、予約番号を含む資源予約応答信号である。

オーケストレータは、予約が完了すると、ＶＮＦＭへ更新開始を要求する（ステップＳ１０８）。このとき送信される信号は、（イベント番号、バージョン情報、予約番号）を含む更新開始要求信号であり、設定例として（イベント番号：必要資源問い合わせで使用した番号、バージョン情報：1.5、予約番号：完了した予約番号）が例示される。

ＶＮＦＭは、新バージョンのＶＮＦ用のID（新ＶＮＦ番号（例えばVNF100_2））を発行して、新旧対応テーブルのレコード（即ち、図５（ｂ）の新旧対応データ）を生成・保持する。そして、ＶＮＦＭは、新バージョンにて起動したＶＮＦへ設定情報を同期するため、ＶＮＦの設定管理を行うＥＭＳに対し更新開始を通知する（ステップＳ１０９）。なお、このとき送信される信号は、（旧ＶＮＦ番号：VNF100_1、新ＶＮＦ番号：VNF100_2、更新バージョン）を含む更新開始通知信号である。

ＥＭＳは、ＶＮＦＭからの通知を受信すると、Ack信号を応答する（ステップＳ１１０）。このとき、ＥＭＳは、ＶＮＦＭからの信号内の情報を基に、新旧対応テーブルのレコード（即ち、図６（ａ）の新旧対応データ）を生成・保持する。

ＶＮＦＭは、ＥＭＳからの応答を受け、ＶＩＭへＶＮＦ生成要求を行う（ステップＳ１１１）。このとき送信される信号は、（予約番号、配置・起動情報、ネットワーク構成情報（帯域、構成、ネットワーク接続状態））を含むＶＮＦ生成要求信号である。このときのＶＮＦ生成要求信号は、第１実施形態と同様であるので、重複した説明は省略する。

ＶＩＭは、ＶＮＦ生成要求を受け、ＮＦＶＩに対して、サーバ生成・起動を実施する（ステップＳ１１２）。そして、サーバ生成・起動実施後に、ＶＩＭはＶＮＦ生成応答を通知する（ステップＳ１１３）。このとき送信される信号は、（予約番号、成否、サーバ識別番号）を含むＶＮＦ生成応答信号であり、設定例として（予約番号：生成時の予約番号、成否：起動成否、サーバ識別番号：起動完了した仮想サーバの識別子VNFC100_2）が例示される。

これにより、ＮＦＶＩは、ステップＳ１１２のサーバ生成・起動によりＶＮＦ２（新バージョンのＶＮＦ）を起動する（ステップＳ１１４）。なお、サーバが複数ある場合は繰り返し生成される。

ＶＮＦ生成応答を受信したＶＮＦＭは、オーケストレータへ更新開始要求応答のAck信号を応答する（ステップＳ１１５）。このとき、旧ＶＮＦ番号、新ＶＮＦ番号、更新バージョンなどの新旧対応データ生成に要する情報がオーケストレータへ通知され、オーケストレータはこれらの情報をもとに、新旧対応テーブルのレコード（即ち、図４（ａ）の新旧対応データ）を生成・保持する。

（図１６：設定同期およびネットワーク切替に関する処理フロー）
ＶＮＦ２は、サーバのブートが実行されアプリケーションが起動する（ステップＳ１１６）。

そして、アプリケーションの起動後、ＥＭＳは、保持した新旧対応テーブルを参照して新バージョンのＶＮＦ（ＶＮＦ２）および旧バージョンのＶＮＦ（ＶＮＦ１）を特定し、これらＶＮＦ１、２と相互に通信しながら、ＶＮＦ２に対し、旧バージョンのＶＮＦ１の設定情報との同期を実施する（ステップＳ１１７）。

ＥＭＳは、同期が完了すると、ＶＮＦＭおよびＯＳＳ／ＢＳＳへ起動完了を通知する（ステップＳ１１８、Ｓ１１９）。このとき送信される信号は、ＶＮＦ番号を含む起動・設定完了信号であり、設定例として（ＶＮＦ番号：VNF10_2）が例示される。ただし、この時点ではまだ、ＶＮＦ１がサービスに係る信号を処理している（ステップＳ１２０）。

ＯＳＳ／ＢＳＳは、新ＶＮＦが起動・設定完了を確認後、オーケストレータへネットワーク切替を要求する（ステップＳ１２１）。このとき送信される信号は、（受付番号、ＶＮＦ種別、切替元ＶＮＦ番号）を含むネットワーク切替要求信号であり、設定例として（受付番号：更新要求の際に発行された受付番号、ＶＮＦ種別：更新対象のＶＮＦ種別（VNF10）、切替元ＶＮＦ番号：切替対象のＶＮＦ番号（VNF10_1））が例示される。

オーケストレータは、切替要求を受け、切替元ＶＮＦ番号（旧ＶＮＦ番号）をキーに新旧対応テーブルを確認して切替対象のＶＮＦの番号（新ＶＮＦ番号）を特定し、ＶＮＦＭへ切替を要求する（ステップＳ１２２）。このとき送信される信号は、（イベント番号、ＶＮＦ番号：VNF100_1）を含むネットワーク切替要求信号である。

ＶＮＦＭは、ＶＩＭに対して、ネットワーク切替を要求する（ステップＳ１２３）。このとき送信される信号は、（予約番号、ＶＮＦ番号、ネットワーク構成情報）を含むネットワーク切替指示信号であり、設定例として（予約番号：資源予約の際の番号、ＶＮＦ番号：切替対象のサーバ識別番号、ネットワーク構成情報：構成NIC_2、IPアドレス、ON（振分装置への接続））が例示される。

ＶＩＭは、ネットワーク切替指示に応じて、ＮＦＶＩに対してネットワーク切替を実施する（ステップＳ１２４）。

ＮＦＶＩは、ネットワーク切替を実施し（ステップＳ１２５）、これにより、サービスに関する信号がＶＮＦ２へ送信されることとなる。具体的には、ネットワークの切替には、サーバ１、サーバ２に関して、同一のIPアドレスを付与し、OpenFlow（オープンフロー）のように、フロー（IPパケットおよびEtherフレーム内のいくつかのフィールドの組み合わせで定義）ベースで宛先を変更する仕組みを利用し、付与した同一のIPパケットに対する送信先NIC（仮想ポート）を変更することで、ネットワーク切替を実現する。これにより、サービスに関する信号がサーバ２へ送信され（ステップＳ１２６）、サーバ２による処理が実行開始される。

ＶＩＭは、ネットワーク切替完了通知をＶＮＦＭへ送信し（ステップＳ１２７）、ＶＮＦＭは、ネットワーク切替応答をオーケストレータへ送信し（ステップＳ１２８）、オーケストレータは、ネットワーク切替応答をＯＳＳ／ＢＳＳへ送信する（ステップＳ１２９）。

ＥＭＳは、新バージョンのＶＮＦ２によるサービスを監視し（ステップＳ１３０）、ＶＮＦ２によるサービスの状態（処理成否数等）をＯＳＳ／ＢＳＳへ通知する（ステップＳ１３１）。もちろん、サービスによって通知される状態（処理成否数等）は異なる。

ＯＳＳ／ＢＳＳは、サービスの状態の通知を監視し、不具合がないかのサービス監視を一定期間行う（ステップＳ１３２）。

（図１７：新バージョンＶＮＦの正常稼動時（不具合未検出時）の処理フロー）
決められたサービス監視期間が満了し、不具合が検出されなかった場合の処理は以下である。

ＯＳＳ／ＢＳＳは、オーケストレータへ更新確定要求を送信する（ステップＳ１４１）。この送信トリガーとしては、人が判断するもしくは一定期間経過後に自動送信とする。このとき送信される信号は、受付番号を含む更新確定要求信号であり、設定例として（受付番号：更新要求時に発行された受付番号）が例示される。

オーケストレータは、（イベント番号、ＶＮＦ種別）を含む更新確定通知をＶＮＦＭへ通知する（ステップＳ１４２）。

ＶＮＦＭは、新バージョンＶＮＦのＶＮＦ番号をキーに、保持した新旧対応テーブルを参照して、削除すべき旧バージョンＶＮＦ（ＶＮＦ１）のＶＮＦ番号を取得し、更新確定通知をＥＭＳへ通知し（ステップＳ１４３）、ＶＩＭへ旧ＶＮＦの削除要求を送信する（ステップＳ１４４）。このときの更新確定通知としては、（ＶＮＦ種別：VNF100、ＶＮＦ番号：VNF100_1）を含む更新確定通知信号が送信される。また、削除要求としては、（予約番号、ＶＮＦ番号：VNF100_1）を含むＶＮＦ削除要求信号が送信され、設定例として（予約番号：旧ＶＮＦを生成した際の予約番号）が例示される。

ＥＭＳは、更新確定通知をうけ、旧ＶＮＦアプリケーションの停止処理を実施する（ステップＳ１４５）。なお、停止処理の際に、旧ＶＮＦのログの退避等も含めてもよい。

ＶＩＭは、削除要求を受けＮＦＶＩに対し、サーバ停止・削除を行い（ステップＳ１４６）、その実行結果をＶＮＦＭに応答し（ステップＳ１４８）、資源を解放する。このとき送信される信号は、予約番号を含むＶＮＦ削除応答信号である。これにより、ＶＮＦ１は、ステップＳ１４７の削除実施により消滅する。

ＶＮＦＭは、削除応答を受け、オーケストレータへ更新確定応答を通知し（ステップＳ１４９）、オーケストレータは更新確定応答を受け、ＯＳＳ／ＢＳＳへ更新確定応答を通知する（ステップＳ１５０）。

（図１８：新バージョンＶＮＦの異常発生時（不具合検出時）の処理フロー）
新ＶＮＦ（ＶＮＦ２）上で不具合が発生すると、ＥＭＳが不具合を検出し（ステップＳ１６１）、ＥＭＳはＯＳＳ／ＢＳＳに対しサービス処理の異常があることを通知する（ステップＳ１６２）。

ＯＳＳ／ＢＳＳは、更新前に戻すため、更新切戻し要求を全体管理へ要求する（ステップＳ１６３）。このとき送信される信号は、（受付番号、削除要否）を含む更新切戻し要求信号である。

オーケストレータは、更新切戻し要求を受け、ＶＮＦＭへ切戻し通知を送信する（ステップＳ１６４）。

ＶＮＦＭは、更新切戻し通知を受け、保持した新旧対応テーブルを参照して新旧バージョンのＶＮＦの対応関係を把握し、新バージョンＶＮＦ（ＶＮＦ２）のＶＮＦ番号を取得し、ＥＭＳへ切戻し通知を送信する（ステップＳ１６５）。このとき送信される信号は、（ＶＮＦ番号：VNF100_2）を含む切戻し通知信号である。また、ＶＮＦＭは、ＶＩＭへネットワーク切戻し要求を送信する（ステップＳ１６６）。このとき送信される信号は、新ＶＮＦを予約した予約番号を含むネットワーク切戻し要求信号が送信される。

ＶＮＦ２を管理するＥＭＳは、ＶＮＦ２のアプリケーションを停止する（ステップＳ１６７）。

ＶＩＭは、ＮＦＶＩへネットワーク切替を指示し（ステップＳ１６８）、ネットワーク切戻し応答をＶＮＦＭへ送信する（ステップＳ１７１）。

ＮＦＶＩは、ネットワーク切替を実施する（ステップＳ１６９）。これにより、サービス関連の信号がＶＮＦ１へ送信されることとなる（ステップＳ１７０）。

ＶＮＦＭは、ＶＩＭからのネットワーク切戻し応答を受けて、オーケストレータへ更新切戻し応答を通知し（ステップＳ１７２）、オーケストレータはＯＳＳ／ＢＳＳへ更新切戻し応答を通知する（ステップＳ１７６）。この際に、ＶＮＦＭは、切戻し要求での削除要否に応じてサーバ削除処理を行う。即ち、ＶＮＦＭは、ＶＩＭへサーバ削除要求を送信し（ステップＳ１７３）、ＶＩＭはＮＦＶＩへサーバ削除を指示し（ステップＳ１７４）、ＮＦＶＩはサーバ（ＶＮＦ２）を削除する（ステップＳ１７５）。

なお、オーケストレータおよびＶＮＦＭにより保持された新旧対応データ（新旧対応テーブル内の該当レコード）は、更新確定又はネットワーク切戻しの際に削除される。ＥＭＳにより保持された新旧対応データ（新旧対応テーブル内の該当レコード）は、新ＶＮＦ又は旧ＶＮＦの削除時に削除される。

［更新の状態遷移について］
ここで、図１９を用いて、第２実施形態におけるオーケストレータ２０およびＶＮＦＭ３０それぞれの更新の状態遷移について説明する。なお、図１９に記載した「テーブル」とは、新旧対応データの１レコードを意味する。

図１９（ａ）に示すように、オーケストレータ２０の「更新の状態」は、オーケストレータ２０が更新要求を受信し資源予約を送信するとともに今回の更新に関連したテーブルを生成したとき、初期状態（更新起動前／完了後）から「予約中」へ遷移する。ここで、予約が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

次に、オーケストレータ２０が更新通知を送信したとき、更新の状態は、「予約中」から「更新中」へ遷移する。ここで、ＶＮＦ生成が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

さらに、オーケストレータ２０がネットワーク切替要求を受信しネットワーク切替要求を転送したとき、更新の状態は、「更新中」から「監視中」へ遷移する。その後、更新確定又はネットワーク切り戻しとなり上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

図１９（ｂ）に示すように、ＶＮＦＭ３０の「更新の状態」は、ＶＮＦＭ３０が更新開始要求を受信しＶＮＦ生成を指示するとともに今回の更新に関連したテーブルを生成したとき、初期状態（更新起動前／完了後）から「更新中」へ遷移する。ここで、ＶＮＦ生成が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

次に、ＶＮＦＭ３０がネットワーク切替要求を受信しネットワーク切替を実施したとき、更新の状態は、「更新中」から「監視中」へ遷移する。その後、更新確定又はネットワーク切り戻しとなり上記テーブルを削除した場合、更新の状態は初期状態へ戻る。

以上説明した第２実施形態により、第１実施形態と同様に、アプリケーションの種類を問わずに、統一的な処理手順で、新バージョンへの更新および旧バージョンへの復旧処理を含む更新関連作業を効率的に実行することができる。即ち、効率的でシームレスな更新関連作業を実現できる。

１…更新管理システム、２０…オーケストレータ、２１…データ保持部、２２…リソース情報取得部、２３…リソース予約部、２４…ＶＮＦ生成指示部、２５…切替指示部、２６…切り戻し要求部、３０…ＶＮＦＭ、３１…データ保持部、３２、３２Ａ…ＶＮＦ起動通知部、３３…ＶＮＦ生成指示部、３４…切替指示部、３５…切り戻し要求部、４０…ＶＩＭ、４１…ＶＮＦ生成部、４２…切替実行部、４３…切り戻し実行部、５０…ＯＳＳ／ＢＳＳ、６０…ＮＦＶＩ、６１…仮想ネットワーク、６１Ａ…仮想スイッチ、６２Ａ、６２Ｂ…仮想ハードウェア、６３…振分装置、６４Ａ、６４Ｂ…仮想インタフェース、８０…ＥＭＳ、８１…データ保持部、８２…同期実施部、８３…監視部、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置。

Claims (8)

1. 通信サービスを実行する仮想サーバが生成される物理サーバを含む仮想化資源の各々を管理し、新バージョン仮想サーバの生成指示に基づき新バージョン仮想サーバを生成する仮想化資源管理ノードと、
   前記仮想サーバにより実行される通信サービスを監視するサービス監視手段と、
   前記新バージョン仮想サーバを生成するよう前記仮想化資源管理ノードに指示するとともに、前記新バージョン仮想サーバと旧バージョン仮想サーバ間の対応を表す新旧対応データを生成し、当該新旧対応データに基づき、前記サービス監視手段に新バージョン仮想サーバの起動があることを通知する仮想通信機能管理ノードと、
   を備え、
   前記仮想通信機能管理ノードは、
   前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示し、
   前記仮想化資源管理ノードは、
   当該ネットワーク切替の指示に基づき新バージョン仮想サーバへのネットワーク切替を実行する、
   ことを特徴とする更新管理システム。
2. 前記サービス監視手段は、
   前記仮想通信機能管理ノードからの通知に基づき得られる前記新旧対応データに基づいて、新バージョン仮想サーバに対し、旧バージョン仮想サーバの設定情報との同期を実施し、
   前記仮想通信機能管理ノードは、
   当該同期の完了後に、前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示し、
   前記仮想化資源管理ノードは、
   当該ネットワーク切替の指示に基づき新バージョン仮想サーバへのネットワーク切替を実行する、
   ことを特徴とする請求項１に記載の更新管理システム。
3. 前記仮想通信機能管理ノードは、
   前記サービス監視手段による監視で、前記新バージョン仮想サーバにより実行される新バージョン通信サービスに異常がある場合に、前記新旧対応データに基づいて新バージョン仮想サーバおよび旧バージョン仮想サーバを特定し、新バージョン仮想サーバから旧バージョン仮想サーバへのネットワーク切り戻しを実行するよう、前記仮想化資源管理ノードに要求し、
   前記仮想化資源管理ノードは、
   当該ネットワーク切り戻し要求に基づいて、新バージョン仮想サーバから旧バージョン仮想サーバへのネットワーク切り戻しを実行する、
   ことを特徴とする請求項１又は２に記載の更新管理システム。
4. 前記更新管理システムは、
   前記仮想化資源の全体の管理を行うオーケストレータ、を更に備え、
   前記オーケストレータは、
   通信サービスのアプリケーションの新バージョンへの更新要求を受けて、新バージョン仮想サーバのためのリソース情報を前記仮想通信機能管理ノードから取得し、
   前記仮想化資源管理ノードに対し新バージョン仮想サーバ用のリソースを予約するとともに、予約したリソース情報および新バージョンへの更新指示を前記仮想通信機能管理ノードに送信し、
   前記仮想通信機能管理ノードは、
   予約したリソースを用いて新バージョン仮想サーバを生成するよう、前記仮想化資源管理ノードに指示する、
   ことを特徴とする請求項１に記載の更新管理システム。
5. 前記サービス監視手段は、
   前記仮想通信機能管理ノードからの通知に基づき得られる前記新旧対応データに基づいて、新バージョン仮想サーバに対し、旧バージョン仮想サーバの設定情報との同期を実施し、
   前記オーケストレータは、
   当該同期の完了後に、前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示する、
   ことを特徴とする請求項４に記載の更新管理システム。
6. 前記オーケストレータは、
   前記サービス監視手段による監視で、前記新バージョン仮想サーバにより実行される新バージョン通信サービスに異常がある場合に、前記新旧対応データに基づいて新バージョン仮想サーバおよび旧バージョン仮想サーバを特定し、新バージョン仮想サーバから旧バージョン仮想サーバへのネットワーク切り戻しを前記仮想化資源管理ノードに要求する、
   ことを特徴とする請求項５に記載の更新管理システム。
7. 通信サービスを実行する仮想サーバが生成される物理サーバを含む仮想化資源の各々を管理する仮想化資源管理ノードと、前記仮想サーバにより実行される通信サービスを監視するサービス監視手段と、前記仮想サーバを管理する仮想通信機能管理ノードと、を備える更新管理システム、において実行される更新管理方法であって、
   前記仮想通信機能管理ノードが、新バージョン仮想サーバを生成するよう前記仮想化資源管理ノードに指示するとともに、前記新バージョン仮想サーバと旧バージョン仮想サーバ間の対応を表す新旧対応データを生成し、当該新旧対応データに基づき、前記サービス監視手段に新バージョン仮想サーバの起動があることを通知するステップと、
   前記仮想化資源管理ノードが、前記新バージョン仮想サーバの生成指示に基づき前記新バージョン仮想サーバを生成するステップと、
   前記仮想通信機能管理ノードが、前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示するステップと、
   前記仮想化資源管理ノードが、当該ネットワーク切替の指示に基づき新バージョン仮想サーバへのネットワーク切替を実行するステップと、
   を含む更新管理方法。
8. 前記ネットワーク切替を実行するステップでは、
   前記仮想化資源管理ノードが、当初はネットワークから旧バージョン仮想サーバを切り離すことなく新バージョン仮想サーバをネットワークに接続し、
   前記更新管理システム内で外部からのパケットのあて先を振り分ける振分手段が、新規に開始された処理から順にパケットのあて先を新バージョン仮想サーバへ振り分けていき、
   切替前から継続する処理が無くなったとき又は所定の新バージョン監視期間が満了したときに、前記仮想化資源管理ノードが、ネットワークから旧バージョン仮想サーバを切り離す、
   ことを特徴とする請求項７に記載の更新管理方法。
   

Images