【文献】
“Network Functions Virtualisation (NFV); Architectural Framework”,ETSI GS NFV 002, [online],ETSI,2013年10月,V1.1.1,pp.1-21,[検索日 2015.3.18],URL,http://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf
(58)【調査した分野】(Int.Cl.,DB名)
通信サービスを実行する仮想サーバが生成される物理サーバを含む仮想化資源の各々を管理し、新バージョン仮想サーバの生成指示に基づき新バージョン仮想サーバを生成する仮想化資源管理ノードと、
前記仮想サーバにより実行される通信サービスを監視するサービス監視手段と、
前記新バージョン仮想サーバを生成するよう前記仮想化資源管理ノードに指示するとともに、前記新バージョン仮想サーバと旧バージョン仮想サーバ間の対応を表す新旧対応データを生成し、当該新旧対応データに基づき、前記サービス監視手段に新バージョン仮想サーバの起動があることを通知する仮想通信機能管理ノードと、
を備え、
前記仮想通信機能管理ノードは、
前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示し、
前記仮想化資源管理ノードは、
当該ネットワーク切替の指示に基づき新バージョン仮想サーバへのネットワーク切替を実行する、
ことを特徴とする更新管理システム。
通信サービスを実行する仮想サーバが生成される物理サーバを含む仮想化資源の各々を管理する仮想化資源管理ノードと、前記仮想サーバにより実行される通信サービスを監視するサービス監視手段と、前記仮想サーバを管理する仮想通信機能管理ノードと、を備える更新管理システム、において実行される更新管理方法であって、
前記仮想通信機能管理ノードが、新バージョン仮想サーバを生成するよう前記仮想化資源管理ノードに指示するとともに、前記新バージョン仮想サーバと旧バージョン仮想サーバ間の対応を表す新旧対応データを生成し、当該新旧対応データに基づき、前記サービス監視手段に新バージョン仮想サーバの起動があることを通知するステップと、
前記仮想化資源管理ノードが、前記新バージョン仮想サーバの生成指示に基づき前記新バージョン仮想サーバを生成するステップと、
前記仮想通信機能管理ノードが、前記仮想化資源管理ノードに対し、旧バージョン仮想サーバから新バージョン仮想サーバへのネットワーク切替を指示するステップと、
前記仮想化資源管理ノードが、当該ネットワーク切替の指示に基づき新バージョン仮想サーバへのネットワーク切替を実行するステップと、
を含む更新管理方法。
【発明を実施するための形態】
【0019】
以下、図面と共に本発明の一側面に係る更新管理システム及び更新管理方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。
【0020】
[第1実施形態]
以下、第1実施形態として、「オーケストレータ」が中心的に動作する更新管理方法(第1の方法)に関する実施形態を説明する。
【0021】
[更新管理システムの全体構成]
図1に本実施形態に係る更新管理システム1の全体構成図を示す。
図1に示すように更新管理システム1は、オーケストレータ20と、VNFM30と、VIM(Virtualised Infrastructure Manager)40と、OSS/BSS(Operations Support System/Business Support System)50と、NFVI(Network Functions Virtualisation Infrastructure)60と、VNF(Virtual Network Function)70と、EMS(Element Management System)80とを含んで構成される。なお、互いに情報の送受信が必要な構成要素間は、有線等で接続されており情報の送受信が可能となっている。このような更新管理システム1は、いわゆる移動体通信システム内に含まれる。
【0022】
本実施形態に係る更新管理システム1では、物理サーバ上に実現される仮想サーバにて動作するアプリケーションによって移動通信端末に対して通信サービスが提供される。即ち、通信サービスは、仮想サーバによって通信サービスに応じたアプリケーションを実行することで、移動通信端末に対して提供される。
【0023】
NFVI60は、仮想化環境を構成する物理資源、仮想化層、仮想化資源である。物理資源には、計算資源、記憶資源、伝送資源が含まれる。仮想化層は、物理資源を仮想化しVNF70(APL)に提供する(例えば、ハイパーバイザー)。仮想化資源は、VNF70に提供される仮想化されたインフラ資源である。即ち、NFVI60は、移動体通信システムにおいて通信処理を行う物理的なサーバ装置である物理サーバを含んで構成されている仮想化資源である。例えば、
図1に示すように、NFVI60は、仮想ハードウェア62A、62B、仮想ネットワーク61、及び後述する振分装置63を含む。なお、図面上では、仮想ハードウェアは「仮想HW」、仮想ネットワークは「仮想NW」と略記する。上記の物理サーバは、CPU(コア、プロセッサ)、メモリ、及びハードディスク等の記憶手段を備えて構成される。通常、NFVI60を構成する物理サーバは、複数まとめてデータセンタ(DC)等の拠点に配置される。データセンタでは、配置された物理サーバがデータセンタ内部のネットワークによって接続されており、互いに情報の送受信を行うことができるようになっている。また、更新管理システム1には、複数のデータセンタが設けられている。データセンタ間はネットワークで接続されており、異なるデータセンタに設けられた物理サーバはそのネットワークを介して互いに情報の送受信を行うことができる。
【0024】
VNF70は、通信サービスを提供する仮想的な通信処理ノードである仮想サーバ(が有する通信処理を実行する機能)である。VNF70は、NFVI60において実現される。VNF70は、例えば、仮想マシン(VM)技術が利用されて、NFVI60が備えるCPUがVNF70用に割り当てられて、割り当てられたCPU上において仮想マシンが実現され、仮想マシン上でプログラムが実行されることにより実現される。VNF70は、通常、実行する通信処理に応じて生成(実現)される。なお、図示は省略したが、VNF70は、その構成要素であるVNFC(Virtual Network Function Components)を1つ又は複数含むものとして構成される。
【0025】
更新管理システム1には、1以上(あるいは複数)のVNF70が含まれる。VNF70は、IMSでは、CSCF(Call Session Control Function)、AS(Application Server)等のノードに相当する。あるいは、VNF70は、移動体通信システムの一つであるGPRS(General Packet Radio Service)システムでは例えば、SGSN(Serving GPRS Support Node)、LTE/EPC(Long Term Evolution/Evolved Packet Core)システムでは、MME(Mobility Management Entity)およびS−GW(Serving Gateway)等のノードに相当する。
【0026】
EMS80は、VNF70を監視及び制御するノードである。EMS80も、VNF70と同様にNFVI60において仮想的に実現される。EMS80は、VNF70に対応付けられて生成される。EMS80は、対応付けられたVNF70の監視及び制御を行う。EMS80は、VNF70のFCAPS(障害、構成、課金、性能、セキュリティ)管理を行う。EMS80は、前述の説明のように仮想的に実現しても良いし、FCAPS管理を行う上で管理の複雑性を避けるために物理的に実現しても良い。
【0027】
OSS/BSS50は、更新管理システム1におけるサービス管理を行い、オーケストレータ20等に通信機能に係る指示を行うノードである。例えば、OSS/BSS50は、オーケストレータ20に対して、新たな通信サービスを起動するように指示を行う。また、OSS/BSS50は、EMS80から情報を受け取り、その情報に基づいてオーケストレータ20およびEMS80に対して指示を行う。
【0028】
オーケストレータ20は、仮想化資源であるNFVI60全体の管理を行う全体管理ノード(機能エンティティ)である。オーケストレータ20は、OSS/BSS50からの指示を受信し、当該指示に応じた処理を行う。オーケストレータ20は、インフラと通信サービスの移動体通信網の仮想化資源全体にわたる管理を行う。オーケストレータ20は、複数のVNF70から構成される通信サービスをVNFM30及びVIM40を経由して適切な場所に実現する。例えば、サービスのライフサイクル管理(具体的には例えば、生成、更新、スケール制御、イベント収集)、移動体通信網内全体にわたる資源の分散・予約・割当管理、サービス・インスタンス管理、及びポリシー管理(具体的には例えば、リソースの予約・割当、地理・法令等に基づく最適配置)を行う。
【0029】
VNFM30は、VNF70を管理する仮想通信機能管理ノード(機能エンティティ)である。VNFM30は、更新管理システム1に複数、設けられていてもよい。その場合、VNF70毎に管理されるVNFM30が予め定められていてもよい。VNFM30は、VNF70(APL)のライフサイクル管理を行う。VNFM30は、VNF70の仮想化に関わる制御全般を行う。例えば、VNF70インスンタスの生成、更新、スケール制御、終了、オートヒーリング(自動ヒーリング)を行う。
【0030】
VIM40は、NFVI60におけるVNF70が実現される単位の仮想化資源(インフラリソース)各々を管理する仮想化資源管理ノード(機能エンティティ)である。具体的には、資源の割当・更新・回収の管理、仮想資源と物理との関連付け、ハードウェア資源とSW資源(ハイパーバイザー)一覧の管理を行う。通常、VIM40は、データセンタ(局舎)毎に管理を行う。仮想化資源の管理は、データセンタに応じた方式で行われえる。データセンタの管理方式(管理資源の実装方式)は、OPENSTACK、vCenter等の種類がある。通常、VIM40は、データセンタの管理方式毎に設けられる。即ち、更新管理システム1には、互いに異なる方式で、NFVI60におけるVNF70が実現される単位の仮想化資源各々を管理する複数のVIM40が含まれる。なお、異なる管理方式で管理される仮想化資源の単位は、必ずしもデータセンタ単位でなくてもよい。
【0031】
なお、オーケストレータ20、VNFM30及びVIM40は、物理的なサーバ装置上でプログラムが実行されることにより実現される(但し仮想化上で実現されることを制限するものでは無く、管理系統を分離した上で、仮想化上で実現してもよい)。オーケストレータ20、VNFM30及びVIM40は、それぞれ別々の物理的なサーバ装置で実現されていてもよいし、同じサーバ装置で実現されていてもよい。オーケストレータ20、VNFM30及びVIM40(を実現するためのプログラム)は、別々のベンダから提供されていてもよい。
【0032】
[更新管理システム1における機能ブロック構成]
図2に、第1実施形態における機能ブロック構成を示す。なお、特許請求の範囲の「サービス監視手段」は、
図2のEMS80とOSS/BSS50を含めたものに対応しうるが、ここでは、サービスを実行するVNFを監視するEMS80が、監視部83等を備える例を説明する。
【0033】
まず、新バージョンVNFの生成に関連した機能ブロック構成として以下が挙げられる。
【0034】
オーケストレータ20が、通信サービスのアプリケーションの新バージョンへの更新要求を受けて、新バージョンVNFのためのリソース情報をVNFMから取得するリソース情報取得部22と、VIMに対し新バージョンVNF用のリソースを予約するリソース予約部23と、予約したリソースを用いて新バージョンVNFを生成するようVIMに指示するとともに、新バージョンVNFと旧バージョンVNF間の対応を表す新旧対応データを生成・保持し、VNFMに通知するVNF生成指示部24と、を備える。VIM40が、新バージョンVNFの生成指示に基づき新バージョンVNFを生成するVNF生成部41、を備える。VNFM30が、新旧対応データの通知を受けて、EMS80に新バージョンVNFの起動があることを通知するVNF起動通知部32、を備える。EMS80が、VNFM30からの通知に基づき得られる新旧対応データに基づいて、新バージョンVNFに対し、旧バージョンVNFの設定情報との同期を実施する同期実施部82、を備える。なお、「新旧対応データ」は、例えば、テーブル形式のデータベースの1つのレコードとして生成され、テーブル形式のデータベース内に保持される。具体例は
図4〜
図6を用いて後述する。
【0035】
次に、設定同期およびネットワーク切替に関連した機能ブロック構成として以下が挙げられる。
【0036】
オーケストレータ20が、同期完了後にVIM40に対し、旧バージョンVNFから新バージョンVNFへのネットワーク切替を指示する切替指示部25、を備える。VIM40が、ネットワーク切替指示に基づき新バージョンVNFへのネットワーク切替を実行する切替実行部42を備える。EMS80が、新バージョンVNFにより実行される新バージョン通信サービスを監視する監視部83、を備える。
【0037】
さらに、ネットワーク切り戻しに関連した機能ブロック構成として以下が挙げられる。
【0038】
オーケストレータ20が、EMS80による監視で新バージョン通信サービスに不具合が発見された場合に、保持した新旧対応データに基づいて新バージョンVNFおよび旧バージョンVNFを特定し、新バージョンVNFから旧バージョンVNFへのネットワーク切り戻しをVIMに要求する切り戻し要求部26、を備える。VIM40が、ネットワーク切り戻し要求に基づいて、新バージョンVNFから旧バージョンVNFへのネットワーク切り戻しを実行する切り戻し実行部43を備える。
【0039】
さらに、オーケストレータ20、VNFM30およびEMS80は、後述する新旧対応データ等のデータを保持するデータ保持部21、31、81をそれぞれ備える。
【0040】
図3には、オーケストレータ20、VNFM30及びVIM40を構成するサーバ装置のハードウェア構成を示す。
図3に示すように当該サーバ装置は、CPU101、主記憶装置であるRAM(Random Access Memory)102及びROM(Read Only Memory)103、通信を行うための通信モジュール104、並びにハードディスク等の補助記憶装置105等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述及び後述するオーケストレータ20、VNFM30及びVIM40の機能が発揮される。なお、オーケストレータ20、VNFM30及びVIM40は複数のサーバ装置からなるコンピュータシステムによって構成されていてもよい。また、更新管理システム1に含まれる上記以外のノードも上記のハードウェア構成を有するサーバ装置によって実現されてもよい。
【0041】
[保持されるデータについて]
以下、オーケストレータ20、VNFM30およびEMS80により保持されるデータについて説明する。
【0042】
オーケストレータ20は、データ保持部21に、
図4(a)に例示する新旧対応データ、
図4(b)に例示するVNF構成データ、
図4(c)に例示するVNFC構成データを保持する。このうち、新旧対応データは、更新通知の応答にてオーケストレータ20がVNFM30から必要な情報を取得することにより生成され、その後の更新確定又はネットワーク切り戻しの際に削除される。新旧対応データには、
図4(a)のように受付番号、新VNF番号、旧VNF番号、VNF種別、バージョン、ネットワーク構成、および状態が含まれる。VNF構成データには、
図4(b)のようにVNF番号、VNF種別、バージョン、および構成情報が含まれ、このうち構成情報は、第1実施形態のようにオーケストレータ20がVIM40にネットワーク切替・切り戻し等を指示する場合のみ保持される。VNFC構成データには、
図4(c)のようにVNFC番号、VNFC種別、バージョン、および構成情報が含まれ、このVNFC構成データは第1実施形態のようにオーケストレータ20がVIM40にネットワーク切替・切り戻し等を指示する場合のみ保持される。
【0043】
VNFM30は、データ保持部31に、
図5(a)に例示する更新条件データ、
図5(b)に例示する新旧対応データ、
図5(c)に例示するVNF構成データ、
図5(d)に例示するVNFC構成データを保持する。このうち、更新条件データは事前に保持されているものであり、更新条件データには、
図5(a)のようにVNF種別、旧バージョン、新バージョン、およびネットワーク構成が含まれる。新旧対応データは、VNFM30により更新通知時に生成され、その後の更新確定又はネットワーク切り戻しの際に削除される。この新旧対応データには、
図5(b)のように受付番号、新VNF番号、旧VNF番号、VNF種別、バージョン、および状態が含まれる。VNF構成データはVNF生成時に生成され、VNF構成データには、
図5(c)のようにVNF番号、VNF種別、バージョン、および構成情報が含まれる。VNFC構成データには、
図5(d)のようにVNFC番号、VNFC種別、バージョン、および構成情報が含まれ、このVNFC構成データは後述の第2実施形態のようにVNFM30がVIM40にネットワーク切替・切り戻し等を指示する場合のみ保持される。
【0044】
EMS80は、データ保持部81に、
図6(a)に例示する新旧対応データ、
図6(b)に例示するVNF構成データ、
図6(c)に例示する設定データを保持する。このうち、新旧対応データは、EMS80により更新通知受信時に生成され、その後の新VNF削除時若しくは旧VNF削除時に削除される。この新旧対応データには、
図6(a)のように新VNF番号、旧VNF番号、バージョン、および状態が含まれる。VNF構成データには、
図6(b)のようにVNF番号、VNF種別、バージョン、および構成情報が含まれる。設定データには、
図6(c)のようにVNF番号および設定データが含まれる。
【0045】
[第1実施形態における処理内容]
以下、
図7〜
図10を用いて第1実施形態における処理内容を説明する。
図7には新バージョンVNFの生成までの処理フローが、
図8には設定同期およびネットワーク切替に関する処理フローが、
図9には新バージョンVNFの正常稼動時(不具合未検出時)の処理フローが、
図10には新バージョンVNFの異常発生時(不具合検出時)の処理フローが、それぞれ示されており、以下順に説明する。なお、図面上では、「ネットワーク」を「NW」と略記する。
【0046】
(
図7:新バージョンVNFの生成までの処理フロー)
OSS/BSSは、すでに生成したVNFを新バージョンに適用するため、対象サービス内のVNFを指定して、オーケストレータに更新を要求する(ステップS1)。なお、対象サービス、VNF種別、現行バージョンの対応に関しては、事前に若しくはVNF生成時に、OSS/BSSにて保持されている。このとき送信される信号は、(通信サービス、VNF種別、バージョン情報)を含む更新要求信号であり、設定例として(通信サービス:通信サービス1、VNF種別:VNF10、バージョン:1.5)が例示される。
【0047】
オーケストレータは、更新要求の受付応答を行った(ステップS2)後、更新対象のVNFを生成するため、VNFの指定バージョンに必要となる資源情報をVNFMへ問い合わせる(ステップS3)。このとき送信される信号は、(イベント番号、VNF種別、性能条件)を含む必要資源問い合わせ信号であり、設定例として(イベント番号:xxxxx(注:Request-Responseの対応付けのための番号である)、VNF種別:VNF10、性能条件:100、バージョン:1.5)が例示される。または、オーケストレータへあらかじめVNFの情報を登録しておくことにより、資源情報の問い合わせを省略してもよい。
【0048】
VNFMは、要求のあったVNFの指定バージョンの性能条件に合う資源情報をオーケストレータへ応答する(ステップS4)。なお、性能条件、VNFバージョン、資源情報は、事前にVNFMが保持している。このとき送信される信号は、必要資源情報を含む必要情報応答信号であり、設定例として(CPU:LOW、VM数:4、ネットワーク帯域:1Gbps、DC分離可)が例示される。
【0049】
オーケストレータは、必要資源問い合わせにより得た情報をもとにVIMへ予約を行う(ステップS5)。このとき送信される信号は、(DC、必要資源情報(VM、ネットワーク))を含む資源予約要求信号であり、設定例として(DC:DC1→オーケストレータが必要資源から導いたDataCenter、必要資源情報(CPU:High、VM数:1、ネットワーク帯域:1Gbps))が例示される。なお、これ以降の手順は、更新を要求されたVNF種別のVNFすべてに対して実施するため、繰り返し処理されるか又は並行処理される。または、オーケストレータにすべてのVIM制御下の資源情報を事前登録することにより、オーケストレータによって予約がなされてもよく、この場合VIMへの問い合わせを省略してもよい。
【0050】
VIMは、予約要求の情報と管理下のリソース情報により予約を実施し(ステップS6)、その予約完了をオーケストレータへ応答する(ステップS7)。このとき送信される信号は、予約番号を含む資源予約応答信号である。
【0051】
オーケストレータは、予約が完了すると、更新後のVNFへIDを発行して、新旧対応テーブルのレコード(即ち、
図4(a)の新旧対応データ)を生成・保持し、更新対象VNFを管理するVNFMに対し事前に更新開始を通知する(ステップS8)。なお、通知先VNFMと対応するVNF種別は、オーケストレータで保持している。このとき送信される信号は、(VNF種別、旧VNF番号、新VNF番号、更新バージョン)を含む更新開始通知信号であり、設定例として(VNF種別:VNF10、旧VNF番号:VNF10_1、新VNF番号:VNF10_2、バージョン:1.5)が例示される。
【0052】
更新開始通知信号を受信したVNFMは、受信した更新開始通知信号内の情報を基に新旧対応テーブルのレコード(即ち、
図5(b)の新旧対応データ)を生成・保持する。そして、VNFMは、新バージョンにて起動したVNFへ設定情報を同期するため、VNFの設定管理を行うEMSに対し更新開始を事前に通知する(ステップS9)。なお、このとき通知される信号は、(旧VNF番号、新VNF番号、更新バージョン)を含む更新開始通知信号であり、設定例として(旧VNF番号:VNF10_1、新VNF番号:VNF10_2、バージョン:1.5)が例示される。
【0053】
EMSは、要求受信後、Ackを応答する(ステップS10)。このとき、EMSは、VNFMからの信号内の情報を基に、新旧対応テーブルのレコード(即ち、
図6(a)の新旧対応データ)を生成・保持する。
【0054】
VNFMは、EMSからのAck応答を受けると、オーケストレータへAckを応答する(ステップS11)。この応答の際にVNFMはVNF構成・配置・起動情報を付与する。このとき送信される信号は、VNF構成・配置・起動情報を含むAck信号であり、設定例として(VNFC種別、個数、構成情報(Image:VNFCI_100_1、NIC_1:1G:ON、NIC_2:OFF))が例示される。
【0055】
オーケストレータは、更新開始通知の完了後、VIMへVNF生成要求を行う(ステップS12)。ただし、VNF生成の際に、ネットワーク切替のため、ネットワーク構成情報に加えて、ネットワーク接続状態を指定し、切替タイミングまで新バージョンのVNFをネットワークに接続しないようにする。このとき送信される信号は、(予約番号、配置・起動情報、ネットワーク構成情報(帯域、構成、ネットワーク接続状態))を含むVNF生成要求信号であり、設定例として(配置・起動情報:DC:DC2、CPU:High、VM数:1、VNFC種別:VNFC100、VNFCI_100_2、ネットワーク構成情報(帯域:1Gbps、構成:{NIC_1、IPアドレス、ON}、{NIC_2、IPアドレス、OFF})が例示される。
【0056】
VIMは、生成要求を受け、NFVIに対して、サーバ生成・起動を実施する(ステップS13)。そして、サーバ生成・起動実施後に、VIMはVNF生成応答を通知する(ステップS14)。このとき送信される信号は、(予約番号、成否、サーバ識別番号)を含むVNF生成応答信号であり、設定例として(予約番号:生成時の予約番号、成否:起動成否、サーバ識別番号:起動完了した仮想サーバの識別子VNFC100_2)が例示される。
【0057】
これにより、NFVIは、ステップS15のサーバ生成・起動によりVNF2(新バージョンのVNF)を起動する。なお、サーバが複数ある場合は繰り返し生成される。
【0058】
(
図8:設定同期およびネットワーク切替に関する処理フロー)
新バージョンのVNF2は、サーバのブートが実行されアプリケーションが起動する(ステップS16)。
【0059】
そして、アプリケーションの起動後、EMSは、保持した新旧対応テーブルを参照して新バージョンのVNF(VNF2)および旧バージョンのVNF(VNF1)を特定し、これらVNF1、2と相互に通信しながら、VNF2に対し、旧バージョンのVNF1の設定情報との同期を実施する(ステップS17)。
【0060】
EMSは、同期が完了すると、VNFMおよびOSS/BSSへ起動完了を通知する(ステップS18、S19)。このとき送信される信号は、VNF番号を含む起動・設定完了信号であり、設定例として(VNF番号:VNF10_2)が例示される。ただし、この時点ではまだ、VNF1がサービスに係る信号を処理している(ステップS20)。
【0061】
OSS/BSSは、新VNFが起動・設定完了を確認後、オーケストレータへネットワーク切替を要求する(ステップS21)。このとき送信される信号は、(受付番号、VNF種別、切替元VNF番号)を含むネットワーク切替要求信号であり、設定例として(受付番号:更新要求の際に発行された受付番号、VNF種別:更新対象のVNF種別(VNF10)、切替元VNF番号:切替対象のVNF番号(VNF10_1))が例示される。
【0062】
オーケストレータは、切替要求を受け、切替元VNF番号(旧VNF番号)をキーに新旧対応テーブルを確認して切替対象のVNFの番号(新VNF番号)を特定し、切替対象のVNF(新VNF)を管理するVIMに対し、ネットワーク切替指示を送信する(ステップS22)。ネットワーク切替指示において、
図1の振分装置63への接続が必要な場合は、接続に必要な所定の情報を付与する。振分装置63による振分けについては
図13を用いて後述する。なお、このとき送信される信号は、(予約番号、サーバ識別番号、ネットワーク構成情報)を含むネットワーク切替指示信号であり、設定例として(予約番号:資源予約の際の番号、サーバ識別番号:切替を行うサーバ識別番号、ネットワーク構成情報(帯域:1Gbps、構成:NIC_2、IPアドレス、ON(切替装置への接続))が例示される。
【0063】
VIMは、ネットワーク切替指示に応じて、NFVIに対してネットワーク切替を実施する(ステップS23)。
【0064】
NFVIは、ネットワーク切替を実施し(ステップS24)、これにより、サービスに関する信号がVNF2へ送信されることとなる。具体的には、ネットワークの切替には、サーバ1、サーバ2に関して、同一のIPアドレスを付与し、OpenFlow(オープンフロー)のように、フロー(IPパケットおよびEtherフレーム内のいくつかのフィールドの組み合わせで定義)ベースで宛先を変更する仕組みを利用し、付与した同一のIPパケットに対する送信先NIC(仮想ポート)を変更することで、ネットワーク切替を実現する。これにより、サービスに関する信号がサーバ2へ送信され(ステップS25)、サーバ2による処理が実行開始される。
【0065】
VIMは、ネットワーク切替完了通知をオーケストレータへ送信し(ステップS26)、オーケストレータは、ネットワーク切替応答をOSS/BSSへ送信する(ステップS27)。
【0066】
EMSおよびVNF2は、サービスの状態(処理成否数等)をOSS/BSSへ通知する(ステップS28、S29)。なお、サービスによって通知する状態は異なる。
【0067】
OSS/BSSは、サービスの状態の通知を監視し、不具合がないかのサービス監視を一定期間行う(ステップS30)。
【0068】
(
図9:新バージョンVNFの正常稼動時(不具合未検出時)の処理フロー)
決められたサービス監視期間が満了し、不具合が検出されなかった場合の処理は以下である。
【0069】
OSS/BSSは、オーケストレータへ更新確定要求を送信する(ステップS41)。この送信トリガーとしては、人が判断するもしくは一定期間経過後に自動送信とする。このとき送信される信号は、受付番号を含む更新確定要求信号であり、設定例として(受付番号:更新要求時に発行された受付番号)が例示される。
【0070】
オーケストレータは、新バージョンVNFのVNF番号をキーに、保持した新旧対応テーブルを参照して、削除すべき旧バージョンVNF(VNF1)のVNF番号を取得し、更新確定通知をVNFMへ通知し(ステップS42)、VIMへ旧VNFの削除要求を送信する(ステップS43)。このときの更新確定通知としては、(VNF種別:VNF100、VNF番号:VNF100_1)を含む更新確定通知信号が送信される。また、削除要求としては、(予約番号、VNF番号:VNF100_1)を含むVNF削除要求信号が送信され、設定例として(予約番号:旧VNFを生成した際の予約番号)が例示される。
【0071】
VNFMは、更新確定通知をEMSへ通知する(ステップS44)。このとき送信される信号は、(VNF種別:VNF100、VNF番号:VNF100_1)を含む更新確定通知信号である。
【0072】
EMSは、更新確定通知をうけ、旧VNFアプリケーションの停止処理を実施する(ステップS45)。なお、停止処理の際に、旧VNFのログの退避等も含めてもよい。
【0073】
VIMは、削除要求を受けNFVIに対し、サーバ停止・削除を行い(ステップS46)、その実行結果をオーケストレータに応答し(ステップS48)、資源を解放する。このとき送信される信号は、予約番号を含むVNF削除応答信号である。これにより、VNF1は、ステップS47の削除実施により消滅する。
【0074】
オーケストレータは、削除応答をうけ、OSS/BSSへ更新確定応答を通知する(ステップS49)。
【0075】
(
図10:新バージョンVNFの異常発生時(不具合検出時)の処理フロー)
新VNF(VNF2)上で不具合が発生すると、EMSが不具合を検出し(ステップS61)、EMSはOSS/BSSに対しサービス処理の異常があることを通知する(ステップS62)。
【0076】
OSS/BSSは、更新前に戻すため、更新切戻し要求を全体管理へ要求する(ステップS63)。このとき送信される信号は、(受付番号、削除要否)を含む更新切戻し要求信号である。
【0077】
オーケストレータは、更新切戻し要求を受け、保持した新旧対応テーブルを参照して新旧バージョンのVNFの対応関係を把握し、新バージョンVNF(VNF2)のVNF番号を取得し、VNFMへ切戻し通知を送信し(ステップS64)、VIMへネットワーク切戻し要求を送信する(ステップS65)。このときの切戻し通知としては、(VNF番号:VNF100_2)を含む切戻し通知信号が送信される。また、ネットワーク切戻し要求としては、新VNFを予約した予約番号を含むネットワーク切戻し要求信号が送信される。
【0078】
VNFMは、EMSへ切戻し通知を送信する(ステップS66)。このとき送信される信号は、(VNF番号:VNF100_2)を含む切戻し通知信号である。
【0079】
VNF2を管理するEMSは、VNF2のアプリケーションを停止する(ステップS67)。
【0080】
VIMは、NFVIへネットワーク切替を指示し(ステップS68)、ネットワーク切戻し応答をオーケストレータへ送信する(ステップS69)。
【0081】
NFVIは、ネットワーク切替を実施する(ステップS70)。これにより、サービス関連の信号がVNF1へ送信されることとなる(ステップS71)。
【0082】
オーケストレータは、VIMからのネットワーク切戻し応答を受けて、OSS/BSSへ更新切戻し応答を通知する(ステップS75)。この際に、オーケストレータは、切戻し要求での削除要否に応じてサーバ削除処理を行う。即ち、オーケストレータは、VIMへサーバ削除要求を送信し(ステップS72)、VIMはNFVIへサーバ削除を指示し(ステップS73)、NFVIはサーバ(VNF2)を削除する(ステップS74)。
【0083】
なお、オーケストレータおよびVNFMにより保持された新旧対応データ(新旧対応テーブル内の該当レコード)は、更新確定又はネットワーク切戻しの際に削除される。EMSにより保持された新旧対応データ(新旧対応テーブル内の該当レコード)は、新VNF又は旧VNFの削除時に削除される。
【0084】
[更新の状態遷移について]
ここで、
図11を用いて、第1実施形態におけるオーケストレータ20およびVNFM30それぞれの更新の状態遷移について説明する。なお、
図11に記載した「テーブル」とは、新旧対応データの1レコードを意味する。
【0085】
図11(a)に示すように、オーケストレータ20の「更新の状態」は、オーケストレータ20が更新要求を受信し資源予約を送信するとともに今回の更新に関連したテーブルを生成したとき、初期状態(更新起動前/完了後)から「予約中」へ遷移する。ここで、予約が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0086】
次に、オーケストレータ20が更新通知を送信しVNF生成を指示したとき、更新の状態は、「予約中」から「更新中」へ遷移する。ここで、VNF生成が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0087】
さらに、オーケストレータ20がネットワーク切替要求を受信しネットワーク切替を実施したとき、更新の状態は、「更新中」から「監視中」へ遷移する。その後、更新確定又はネットワーク切り戻しとなり上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0088】
図11(b)に示すように、VNFM30の「更新の状態」は、VNFM30が更新通知を受信するとともに今回の更新に関連したテーブルを生成したとき、初期状態(更新起動前/完了後)から「更新中/監視中」へ遷移する。その後、更新確定通知又はネットワーク切り戻し通知を受信し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0089】
[ネットワーク切替の方法について]
ここで、新バージョンVNFへのネットワーク切替の方法を説明する。本実施形態では、旧バージョンのVNF1と設定を同期させた新バージョンのVNF2を生成し、ネットワークのデータフローをVNF1からVNF2へ切り替えることで、VNF2へのネットワーク切替を実行する。このときのネットワーク切替方法として、あるタイミングで一度に切り替える方法(第1の方法)と、新規に開始された処理から順にパケットのあて先をVNF2へ振り分けていく方法(第2の方法)とが例示される。第1の方法は、一往復のリクエスト/レスポンスで処理が完了するサービスに適用可能であり、第2の方法は、複数回にわたる信号の往復で処理が完了するサービスに適用可能である。以下、これらを順に説明する。
【0090】
(第1の方法)
図12(a)に第1の方法を実行する際の構成図を示す。即ち、NFVI60には、仮想ネットワーク上の仮想スイッチ61Aが生成され、仮想スイッチ61Aには、外部からのパケットのインタフェースとなるポート3と、旧バージョンのVNF1の仮想インタフェース64Aと接続されたポート1と、新バージョンのVNF2の仮想インタフェース64Bと接続されたポート2とが生成される。なお、図面上では、仮想スイッチは「仮想SW」、仮想インタフェースは「仮想I/F」と略記する。
【0091】
仮想スイッチ61Aは、
図12(b)に示すフローテーブルを内部に保持し、このフローテーブルの内容にしたがってデータの転送先を切り替える。この例では、仮想スイッチ61Aは、
図12(b)のフローテーブルに示すように、ネットワーク切替前は、ポート3から入ったパケット(外部ネットワークからのVNFのIP宛パケット)をポート1へ転送することで、旧バージョンのVNF1へ転送する。そして、ネットワーク切替指示のタイミングで、仮想スイッチ61Aは、フローテーブルの「転送先」をポート2に変更することで、これ以降の外部ネットワークからのVNFのIP宛パケットをポート2へ転送する。これにより、新バージョンのVNF2へのネットワーク切替が正常に実行される。その後、VNF2に不具合が発生した場合のネットワーク切戻しのタイミングでは、仮想スイッチ61Aは、フローテーブルの「転送先」をポート1に変更することで、これ以降の外部ネットワークからのVNFのIP宛パケットをポート1へ転送する。これにより、旧バージョンのVNF1へのネットワーク切戻しが正常に実行される。
【0092】
(第2の方法)
図13(a)に第2の方法を実行する際の構成図を示す。即ち、NFVI60には、仮想ネットワーク上の仮想スイッチ61Aと振分装置63とが生成され、仮想スイッチ61Aには、
図12(a)と同様のポート1〜3に加え、振分装置63へ出力するためのポート4と、振分装置63からの入力を受け入れるためのポート5とが生成される。なお、振分装置63は、その実現方法は特定の方法に限定されるものではなく、例えば、既存の仮想サーバを一時的に接続することで実現してもよいし、一時的に生成された仮想サーバにより実現してもよい。
【0093】
仮想スイッチ61Aは、
図13(b)〜(d)に示すようなフローテーブルを内部に保持し、このフローテーブルの内容にしたがってデータの転送先を切り替える。ここで、仮想スイッチ61Aは、ネットワーク切替の操作前は、
図13(b)のフローテーブルに示すように、ポート3から入ったパケット(外部ネットワークからのVNFのIP宛パケット)をポート1へ転送することで、旧バージョンのVNF1へ転送する。そして、ネットワーク切替指示後の監視中の状態では、仮想スイッチ61Aは、
図13(c)のフローテーブルに示すように、ポート3から入ったパケット(外部ネットワークからのVNFのIP宛パケット)をポート4へ転送することで、振分装置63へ転送する。
【0094】
振分装置63は、受信したパケットが継続中の処理のパケットか新規処理のパケットかを判別し、継続中の処理のパケットの場合は当該パケットの属性情報(例えばVLAN((Virtual Local Area Network)))に「100」をマーキングして仮想スイッチ61Aへ転送し、新規処理のパケットの場合は当該パケットの属性情報(例えばVLAN)に「200」をマーキングして仮想スイッチ61Aへ転送する。
【0095】
そして、仮想スイッチ61Aは、
図13(c)のフローテーブルに示すように、ポート5から入ったパケット(振分装置63からのパケット)のVLANを確認し、VLANが「100」のパケット(継続中の処理のパケット)をポート1へ転送し、VLANが「200」のパケット(新規処理のパケット)をポート2へ転送する。これにより、継続中の処理のパケットは旧バージョンのVNF1へ転送され、新規処理のパケットは新バージョンのVNF2へ転送される。
【0096】
その後、所定の新バージョン監視期間が満了して切替が確定した後は、仮想スイッチ61Aは、
図13(d)のフローテーブルに示すように、ポート3から入ったパケット(外部ネットワークからのVNFのIP宛パケット)をポート2へ転送することで、新バージョンのVNF2へ転送する。これにより、新バージョンのVNF2へのネットワーク切替が完了する。なお、所定の新バージョン監視期間満了以外に、継続中の処理のパケットが無くなったタイミングで
図13(d)のフローテーブルに基づく転送に移行しても構わない。
【0097】
上記のような第2の方法により、複数回にわたる信号の往復で処理が完了するサービスであっても、ネットワーク切替による処理途中での異常終了を防止することができる。
【0098】
以上説明した第1実施形態により、アプリケーションの種類を問わずに、統一的な処理手順で、新バージョンへの更新および旧バージョンへの復旧処理を含む更新関連作業を効率的に実行することができる。即ち、効率的でシームレスな更新関連作業を実現できる。
【0099】
[第2実施形態]
以下、第2実施形態として、「仮想通信機能管理ノード(VFNM)」が中心的に動作する更新管理方法(第2の方法)に関する実施形態を説明する。
【0100】
[更新管理システム1における機能ブロック構成]
図14に、第2実施形態における機能ブロック構成を示す。
【0101】
まず、新バージョンVNFの生成に関連した機能ブロック構成として以下が挙げられる。
【0102】
オーケストレータ20が、通信サービスのアプリケーションの新バージョンへの更新要求を受けて、新バージョンVNFのためのリソース情報をVNFMから取得するリソース情報取得部22と、VIM40に対し新バージョンVNF用のリソースを予約するとともに、予約したリソース情報および新バージョンへの更新指示をVNFMに送信するリソース予約部23と、を備える。VNFM30が、予約したリソースを用いて新バージョンVNFを生成するようVIM40に指示するとともに、新バージョンVNFと旧バージョンVNF間の対応を表す新旧対応データを生成・保持するVNF生成指示部33と、生成した新旧対応データに基づき、EMS80に新バージョンVNFの起動があることを通知するVNF起動通知部32Aと、を備える。VIM40が、新バージョンVNFの生成指示に基づき新バージョンVNFを生成するVNF生成部41、を備える。EMS80が、VNFM30からの通知に基づき得られる新旧対応データに基づいて、新バージョンVNFに対し、旧バージョンVNFの設定情報との同期を実施する同期実施部82、を備える。
【0103】
次に、設定同期およびネットワーク切替に関連した機能ブロック構成として以下が挙げられる。
【0104】
VNFM30がさらに、同期完了後にVIM40に対し、旧バージョンVNFから新バージョンVNFへのネットワーク切替を指示する切替指示部34、を備える。VIM40がさらに、ネットワーク切替指示に基づき新バージョンVNFへのネットワーク切替を実行する切替実行部42、を備える。EMS80がさらに、新バージョンVNFにより実行される新バージョン通信サービスを監視する監視部83、を備える。
【0105】
さらに、ネットワーク切り戻しに関連した機能ブロック構成として以下が挙げられる。
【0106】
VNFM30がさらに、EMS80による監視で新バージョン通信サービスに不具合が発見された場合に、保持した新旧対応データに基づいて新バージョンVNFおよび旧バージョンVNFを特定し、新バージョンVNFから旧バージョンVNFへのネットワーク切り戻しをVIM40に要求する切り戻し要求部35、を備える。VIM40がさらに、ネットワーク切り戻し要求に基づいて、新バージョンVNFから旧バージョンVNFへのネットワーク切り戻しを実行する切り戻し実行部43、を備える。
【0107】
さらに、オーケストレータ20、VNFM30およびEMS80は、第1実施形態で説明した新旧対応データ等のデータを保持するデータ保持部21、31、81をそれぞれ備える。
【0108】
なお、ハードウェア構成(
図3)は第1実施形態と同様であるため、説明を省略する。また、保持されるデータ(
図4〜
図6)についても、第1実施形態と同様であるため、重複した説明を省略する。
【0109】
[第2実施形態における処理内容]
以下、
図15〜
図18を用いて第2実施形態における処理内容を説明する。
図15には新バージョンVNFの生成までの処理フローが、
図16には設定同期およびネットワーク切替に関する処理フローが、
図17には新バージョンVNFの正常稼動時(不具合未検出時)の処理フローが、
図18には新バージョンVNFの異常発生時(不具合検出時)の処理フローが、それぞれ示されており、以下順に説明する。なお、ネットワーク切替の詳細な方法(
図12、
図13)は、第1実施形態と同様であるため、以下では説明を省略する。
【0110】
(
図15:新バージョンVNFの生成までの処理フロー)
OSS/BSSは、すでに生成したVNFを新バージョンに適用するため、対象サービス内のVNFを指定して、オーケストレータに更新を要求する(ステップS101)。なお、対象サービス、VNF種別、現行バージョンの対応に関しては、事前に若しくはVNF生成時に、OSS/BSSにて保持されている。このとき送信される信号は、(通信サービス、VNF種別、バージョン情報)を含む更新要求信号であり、設定例として(通信サービス:通信サービス1、VNF種別:VNF10、バージョン:1.5)が例示される。
【0111】
オーケストレータは、更新要求の受付応答を行った(ステップS102)後、更新対象のVNFの指定バージョンに必要となる資源情報をVNFMへ問い合わせる(ステップS103)。このとき送信される信号は、(イベント番号、候補リソース、VNF種別、バージョン)を含む必要資源問い合わせ信号であり、このとき「候補リソース」にはVIMのリスト等が設定される。
【0112】
VNFMは、候補リソースから選択し、DC毎の必要資源情報を応答する(ステップS104)。このとき送信される信号は、(イベント番号、必要資源情報)を含む必要資源問い合わせ応答信号であり、設定例として(イベント番号:問い合わせで指定された番号、必要資源情報:各DCに割り当てる資源情報(CPU、VM数、ネットワーク帯域))が例示される。
【0113】
オーケストレータは、必要資源情報をもとに資源予約を実施する(ステップS105)。このとき送信される信号は、(DC、必要資源情報)を含む資源予約要求信号である。
【0114】
VIMは、予約要求の情報と管理下のリソース情報により予約を実施する(ステップS106)。そして、VIMは予約完了を応答する(ステップS107)。このとき送信される信号は、予約番号を含む資源予約応答信号である。
【0115】
オーケストレータは、予約が完了すると、VNFMへ更新開始を要求する(ステップS108)。このとき送信される信号は、(イベント番号、バージョン情報、予約番号)を含む更新開始要求信号であり、設定例として(イベント番号:必要資源問い合わせで使用した番号、バージョン情報:1.5、予約番号:完了した予約番号)が例示される。
【0116】
VNFMは、新バージョンのVNF用のID(新VNF番号(例えばVNF100_2))を発行して、新旧対応テーブルのレコード(即ち、
図5(b)の新旧対応データ)を生成・保持する。そして、VNFMは、新バージョンにて起動したVNFへ設定情報を同期するため、VNFの設定管理を行うEMSに対し更新開始を通知する(ステップS109)。なお、このとき送信される信号は、(旧VNF番号:VNF100_1、新VNF番号:VNF100_2、更新バージョン)を含む更新開始通知信号である。
【0117】
EMSは、VNFMからの通知を受信すると、Ack信号を応答する(ステップS110)。このとき、EMSは、VNFMからの信号内の情報を基に、新旧対応テーブルのレコード(即ち、
図6(a)の新旧対応データ)を生成・保持する。
【0118】
VNFMは、EMSからの応答を受け、VIMへVNF生成要求を行う(ステップS111)。このとき送信される信号は、(予約番号、配置・起動情報、ネットワーク構成情報(帯域、構成、ネットワーク接続状態))を含むVNF生成要求信号である。このときのVNF生成要求信号は、第1実施形態と同様であるので、重複した説明は省略する。
【0119】
VIMは、VNF生成要求を受け、NFVIに対して、サーバ生成・起動を実施する(ステップS112)。そして、サーバ生成・起動実施後に、VIMはVNF生成応答を通知する(ステップS113)。このとき送信される信号は、(予約番号、成否、サーバ識別番号)を含むVNF生成応答信号であり、設定例として(予約番号:生成時の予約番号、成否:起動成否、サーバ識別番号:起動完了した仮想サーバの識別子VNFC100_2)が例示される。
【0120】
これにより、NFVIは、ステップS112のサーバ生成・起動によりVNF2(新バージョンのVNF)を起動する(ステップS114)。なお、サーバが複数ある場合は繰り返し生成される。
【0121】
VNF生成応答を受信したVNFMは、オーケストレータへ更新開始要求応答のAck信号を応答する(ステップS115)。このとき、旧VNF番号、新VNF番号、更新バージョンなどの新旧対応データ生成に要する情報がオーケストレータへ通知され、オーケストレータはこれらの情報をもとに、新旧対応テーブルのレコード(即ち、
図4(a)の新旧対応データ)を生成・保持する。
【0122】
(
図16:設定同期およびネットワーク切替に関する処理フロー)
VNF2は、サーバのブートが実行されアプリケーションが起動する(ステップS116)。
【0123】
そして、アプリケーションの起動後、EMSは、保持した新旧対応テーブルを参照して新バージョンのVNF(VNF2)および旧バージョンのVNF(VNF1)を特定し、これらVNF1、2と相互に通信しながら、VNF2に対し、旧バージョンのVNF1の設定情報との同期を実施する(ステップS117)。
【0124】
EMSは、同期が完了すると、VNFMおよびOSS/BSSへ起動完了を通知する(ステップS118、S119)。このとき送信される信号は、VNF番号を含む起動・設定完了信号であり、設定例として(VNF番号:VNF10_2)が例示される。ただし、この時点ではまだ、VNF1がサービスに係る信号を処理している(ステップS120)。
【0125】
OSS/BSSは、新VNFが起動・設定完了を確認後、オーケストレータへネットワーク切替を要求する(ステップS121)。このとき送信される信号は、(受付番号、VNF種別、切替元VNF番号)を含むネットワーク切替要求信号であり、設定例として(受付番号:更新要求の際に発行された受付番号、VNF種別:更新対象のVNF種別(VNF10)、切替元VNF番号:切替対象のVNF番号(VNF10_1))が例示される。
【0126】
オーケストレータは、切替要求を受け、切替元VNF番号(旧VNF番号)をキーに新旧対応テーブルを確認して切替対象のVNFの番号(新VNF番号)を特定し、VNFMへ切替を要求する(ステップS122)。このとき送信される信号は、(イベント番号、VNF番号:VNF100_1)を含むネットワーク切替要求信号である。
【0127】
VNFMは、VIMに対して、ネットワーク切替を要求する(ステップS123)。このとき送信される信号は、(予約番号、VNF番号、ネットワーク構成情報)を含むネットワーク切替指示信号であり、設定例として(予約番号:資源予約の際の番号、VNF番号:切替対象のサーバ識別番号、ネットワーク構成情報:構成NIC_2、IPアドレス、ON(振分装置への接続))が例示される。
【0128】
VIMは、ネットワーク切替指示に応じて、NFVIに対してネットワーク切替を実施する(ステップS124)。
【0129】
NFVIは、ネットワーク切替を実施し(ステップS125)、これにより、サービスに関する信号がVNF2へ送信されることとなる。具体的には、ネットワークの切替には、サーバ1、サーバ2に関して、同一のIPアドレスを付与し、OpenFlow(オープンフロー)のように、フロー(IPパケットおよびEtherフレーム内のいくつかのフィールドの組み合わせで定義)ベースで宛先を変更する仕組みを利用し、付与した同一のIPパケットに対する送信先NIC(仮想ポート)を変更することで、ネットワーク切替を実現する。これにより、サービスに関する信号がサーバ2へ送信され(ステップS126)、サーバ2による処理が実行開始される。
【0130】
VIMは、ネットワーク切替完了通知をVNFMへ送信し(ステップS127)、VNFMは、ネットワーク切替応答をオーケストレータへ送信し(ステップS128)、オーケストレータは、ネットワーク切替応答をOSS/BSSへ送信する(ステップS129)。
【0131】
EMSは、新バージョンのVNF2によるサービスを監視し(ステップS130)、VNF2によるサービスの状態(処理成否数等)をOSS/BSSへ通知する(ステップS131)。もちろん、サービスによって通知される状態(処理成否数等)は異なる。
【0132】
OSS/BSSは、サービスの状態の通知を監視し、不具合がないかのサービス監視を一定期間行う(ステップS132)。
【0133】
(
図17:新バージョンVNFの正常稼動時(不具合未検出時)の処理フロー)
決められたサービス監視期間が満了し、不具合が検出されなかった場合の処理は以下である。
【0134】
OSS/BSSは、オーケストレータへ更新確定要求を送信する(ステップS141)。この送信トリガーとしては、人が判断するもしくは一定期間経過後に自動送信とする。このとき送信される信号は、受付番号を含む更新確定要求信号であり、設定例として(受付番号:更新要求時に発行された受付番号)が例示される。
【0135】
オーケストレータは、(イベント番号、VNF種別)を含む更新確定通知をVNFMへ通知する(ステップS142)。
【0136】
VNFMは、新バージョンVNFのVNF番号をキーに、保持した新旧対応テーブルを参照して、削除すべき旧バージョンVNF(VNF1)のVNF番号を取得し、更新確定通知をEMSへ通知し(ステップS143)、VIMへ旧VNFの削除要求を送信する(ステップS144)。このときの更新確定通知としては、(VNF種別:VNF100、VNF番号:VNF100_1)を含む更新確定通知信号が送信される。また、削除要求としては、(予約番号、VNF番号:VNF100_1)を含むVNF削除要求信号が送信され、設定例として(予約番号:旧VNFを生成した際の予約番号)が例示される。
【0137】
EMSは、更新確定通知をうけ、旧VNFアプリケーションの停止処理を実施する(ステップS145)。なお、停止処理の際に、旧VNFのログの退避等も含めてもよい。
【0138】
VIMは、削除要求を受けNFVIに対し、サーバ停止・削除を行い(ステップS146)、その実行結果をVNFMに応答し(ステップS148)、資源を解放する。このとき送信される信号は、予約番号を含むVNF削除応答信号である。これにより、VNF1は、ステップS147の削除実施により消滅する。
【0139】
VNFMは、削除応答を受け、オーケストレータへ更新確定応答を通知し(ステップS149)、オーケストレータは更新確定応答を受け、OSS/BSSへ更新確定応答を通知する(ステップS150)。
【0140】
(
図18:新バージョンVNFの異常発生時(不具合検出時)の処理フロー)
新VNF(VNF2)上で不具合が発生すると、EMSが不具合を検出し(ステップS161)、EMSはOSS/BSSに対しサービス処理の異常があることを通知する(ステップS162)。
【0141】
OSS/BSSは、更新前に戻すため、更新切戻し要求を全体管理へ要求する(ステップS163)。このとき送信される信号は、(受付番号、削除要否)を含む更新切戻し要求信号である。
【0142】
オーケストレータは、更新切戻し要求を受け、VNFMへ切戻し通知を送信する(ステップS164)。
【0143】
VNFMは、更新切戻し通知を受け、保持した新旧対応テーブルを参照して新旧バージョンのVNFの対応関係を把握し、新バージョンVNF(VNF2)のVNF番号を取得し、EMSへ切戻し通知を送信する(ステップS165)。このとき送信される信号は、(VNF番号:VNF100_2)を含む切戻し通知信号である。また、VNFMは、VIMへネットワーク切戻し要求を送信する(ステップS166)。このとき送信される信号は、新VNFを予約した予約番号を含むネットワーク切戻し要求信号が送信される。
【0144】
VNF2を管理するEMSは、VNF2のアプリケーションを停止する(ステップS167)。
【0145】
VIMは、NFVIへネットワーク切替を指示し(ステップS168)、ネットワーク切戻し応答をVNFMへ送信する(ステップS171)。
【0146】
NFVIは、ネットワーク切替を実施する(ステップS169)。これにより、サービス関連の信号がVNF1へ送信されることとなる(ステップS170)。
【0147】
VNFMは、VIMからのネットワーク切戻し応答を受けて、オーケストレータへ更新切戻し応答を通知し(ステップS172)、オーケストレータはOSS/BSSへ更新切戻し応答を通知する(ステップS176)。この際に、VNFMは、切戻し要求での削除要否に応じてサーバ削除処理を行う。即ち、VNFMは、VIMへサーバ削除要求を送信し(ステップS173)、VIMはNFVIへサーバ削除を指示し(ステップS174)、NFVIはサーバ(VNF2)を削除する(ステップS175)。
【0148】
なお、オーケストレータおよびVNFMにより保持された新旧対応データ(新旧対応テーブル内の該当レコード)は、更新確定又はネットワーク切戻しの際に削除される。EMSにより保持された新旧対応データ(新旧対応テーブル内の該当レコード)は、新VNF又は旧VNFの削除時に削除される。
【0149】
[更新の状態遷移について]
ここで、
図19を用いて、第2実施形態におけるオーケストレータ20およびVNFM30それぞれの更新の状態遷移について説明する。なお、
図19に記載した「テーブル」とは、新旧対応データの1レコードを意味する。
【0150】
図19(a)に示すように、オーケストレータ20の「更新の状態」は、オーケストレータ20が更新要求を受信し資源予約を送信するとともに今回の更新に関連したテーブルを生成したとき、初期状態(更新起動前/完了後)から「予約中」へ遷移する。ここで、予約が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0151】
次に、オーケストレータ20が更新通知を送信したとき、更新の状態は、「予約中」から「更新中」へ遷移する。ここで、VNF生成が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0152】
さらに、オーケストレータ20がネットワーク切替要求を受信しネットワーク切替要求を転送したとき、更新の状態は、「更新中」から「監視中」へ遷移する。その後、更新確定又はネットワーク切り戻しとなり上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0153】
図19(b)に示すように、VNFM30の「更新の状態」は、VNFM30が更新開始要求を受信しVNF生成を指示するとともに今回の更新に関連したテーブルを生成したとき、初期状態(更新起動前/完了後)から「更新中」へ遷移する。ここで、VNF生成が失敗し上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0154】
次に、VNFM30がネットワーク切替要求を受信しネットワーク切替を実施したとき、更新の状態は、「更新中」から「監視中」へ遷移する。その後、更新確定又はネットワーク切り戻しとなり上記テーブルを削除した場合、更新の状態は初期状態へ戻る。
【0155】
以上説明した第2実施形態により、第1実施形態と同様に、アプリケーションの種類を問わずに、統一的な処理手順で、新バージョンへの更新および旧バージョンへの復旧処理を含む更新関連作業を効率的に実行することができる。即ち、効率的でシームレスな更新関連作業を実現できる。