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

更新管理システムおよび更新管理方法 Download PDF

Info

Publication number
WO2015146355A1
WO2015146355A1 PCT/JP2015/054023 JP2015054023W WO2015146355A1 WO 2015146355 A1 WO2015146355 A1 WO 2015146355A1 JP 2015054023 W JP2015054023 W JP 2015054023W WO 2015146355 A1 WO2015146355 A1 WO 2015146355A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual
virtual server
new version
old
vnf
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2015/054023
Other languages
English (en)
French (fr)
Inventor
祐介 高野
清水　敬司
基 田村
英則 浅羽
健生 山▲崎▼
正昭 小杉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Docomo Inc
Original Assignee
NTT Docomo Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Docomo Inc filed Critical NTT Docomo Inc
Priority to EP15769695.6A priority Critical patent/EP3125117B1/en
Priority to JP2016510115A priority patent/JP6026705B2/ja
Priority to US15/121,427 priority patent/US10140112B2/en
Publication of WO2015146355A1 publication Critical patent/WO2015146355A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing

Definitions

  • the present invention relates to an update management system and an update management method for managing update of an application running on a virtual server.
  • the present invention has been made to solve the above-described problems, and an object thereof is to realize an efficient and seamless update-related work for a communication service application.
  • An update management system manages each of virtual resources including a physical server on which a virtual server that executes a communication service is generated, and creates a new version virtual server based on a new version virtual server generation instruction.
  • a virtual communication function management node that generates new and old correspondence data representing correspondence between the server and the old version virtual server, and notifies the service monitoring means that the new version virtual server is activated based on the new and old correspondence data;
  • the virtual communication function management node with respect to the virtual resource management node.
  • the service monitoring means performs synchronization with the setting information of the old version virtual server for the new version virtual server based on the new and old correspondence data obtained based on the notification from the virtual communication function management node.
  • the virtual communication function management node instructs the virtual resource management node to switch the network from the old version virtual server to the new version virtual server after the synchronization is completed, and the virtual resource management node Network switching to the new version virtual server may be executed based on the network switching instruction. This makes it possible to synchronize the new version virtual server with the setting information of the old version virtual server in a unified processing procedure regardless of the type of application. Can be realized.
  • the virtual communication function management node may be configured to monitor the new version virtual server based on the new and old correspondence data when there is an abnormality in the new version communication service executed by the new version virtual server. And the virtual resource management node is requested to execute network switchback from the new version virtual server to the old version virtual server, and the virtual resource management node Based on the request, a network switchback from the new version virtual server to the old version virtual server may be performed. This makes it possible to perform network switch-back from the new version virtual server to the old version virtual server with a uniform processing procedure regardless of the type of application, thereby realizing efficient and seamless update-related work. .
  • the above update management system may be configured to further include an orchestrator for managing the entire virtualization resource.
  • an orchestrator for managing the entire virtualization resource.
  • the update management system further includes an orchestrator that manages the entire virtualization resource, and the orchestrator receives a request for updating the communication service application to a new version, and receives a new version virtual server.
  • Resource information for the virtual communication function management node is acquired from the virtual communication function management node, a resource for the new version virtual server is reserved for the virtual resource management node, and the reserved resource information and an instruction to update to the new version
  • the virtual communication function management node may instruct the virtual resource management node to generate a new version virtual server using the reserved resource. This makes it possible to reserve a resource for a new version virtual server and generate a new version virtual server using the reserved resource in a unified processing procedure regardless of the type of application. And seamless update-related work.
  • the service monitoring means performs synchronization with the setting information of the old version virtual server for the new version virtual server based on the new and old correspondence data obtained based on the notification from the virtual communication function management node.
  • the orchestrator may instruct the virtual resource management node to switch the network from the old version virtual server to the new version virtual server after the synchronization is completed.
  • the orchestrator is configured to monitor the new version virtual server and the old version based on the new and old correspondence data when there is an abnormality in the new version communication service executed by the new version virtual server.
  • a virtual server may be specified and a network switchback from the new version virtual server to the old version virtual server may be requested to the virtual resource management node. This makes it possible to execute a network switchback instruction from the new version virtual server to the old version virtual server by the orchestrator with a unified processing procedure regardless of the type of application, and it is efficient and seamless update related Work can be realized.
  • the invention relating to the “update management system” described above can also be regarded as an invention relating to the “update management method”, and can be described as follows.
  • the invention relating to the following update management method has the same operations and effects.
  • An update management method includes a virtual resource management node that manages each of virtual resources including a physical server on which a virtual server that executes a communication service is generated, and communication that is executed by the virtual server.
  • An update management method executed in an update management system comprising service monitoring means for monitoring a service and a virtual communication function management node for managing the virtual server, wherein the virtual communication function management node is a new version virtual
  • the virtual resource management node is instructed to generate a server, and new and old correspondence data representing correspondence between the new version virtual server and the old version virtual server is generated, and the service monitoring means is based on the new and old correspondence data.
  • the virtual resource management node In the “step of performing network switching”, the virtual resource management node initially connects the new version virtual server to the network without disconnecting the old version virtual server from the network, and externally within the update management system.
  • the distribution means for allocating the destination of the packet allocates the packet destination to the new version virtual server in order from the newly started processing, and when there is no processing to continue from before switching, or a predetermined new version monitoring period When it expires, the virtual resource management node may execute a series of processes such as disconnecting the old version virtual server from the network.
  • the network switching as described above can be applied to a communication service in which processing is completed by a round trip of a plurality of signals, and even in such a type of communication service, abnormal termination during processing due to network switching is prevented. be able to.
  • 1 is an overall configuration diagram of an update management system according to an embodiment of one aspect of the present invention. It is a functional block block diagram of 1st Embodiment. It is a figure which shows the hardware structural example of the node contained in an update management system. It is a figure which shows the data hold
  • FIG. 1 shows an overall configuration diagram of an update management system 1 according to the present embodiment.
  • the update management system 1 includes an orchestrator 20, a VNFM 30, a VIM (Virtualized Infrastructure Manager) 40, an OSS / BSS (Operations Support System / Business Support System) 50, and an NFVI (Network Functions Virtualization Infrastructure). ) 60, a VNF (Virtual Network Function) 70, and an EMS (Element Management System) 80.
  • components that need to transmit and receive information to each other are connected by wire or the like so that information can be transmitted and received.
  • Such an update management system 1 is included in a so-called mobile communication system.
  • a communication service is provided to a mobile communication terminal by an application operating on a virtual server realized on a physical server. That is, the communication service is provided to the mobile communication terminal by executing an application corresponding to the communication service by the virtual server.
  • the NFVI 60 is a physical resource, a virtualization layer, and a virtualization resource that constitute a virtualization environment.
  • Physical resources include computing resources, storage resources, and transmission resources.
  • the virtualization layer virtualizes physical resources and provides them to the VNF 70 (APL) (for example, a hypervisor).
  • the virtualized resource is a virtualized infrastructure resource provided to the VNF 70.
  • the NFVI 60 is a virtualized resource that includes a physical server that is a physical server device that performs communication processing in a mobile communication system.
  • the NFVI 60 includes virtual hardware 62A and 62B, a virtual network 61, and a distribution device 63 described later.
  • the physical server includes a storage unit such as a CPU (core, processor), a memory, and a hard disk.
  • a plurality of physical servers constituting the NFVI 60 are arranged together at a base such as a data center (DC).
  • the arranged physical servers are connected by a network inside the data center, and can exchange information with each other.
  • the update management system 1 is provided with a plurality of data centers. Data centers are connected by a network, and physical servers provided in different data centers can transmit / receive information to / from each other via the network.
  • the VNF 70 is a virtual server (a function for executing communication processing) that is a virtual communication processing node that provides a communication service.
  • the VNF 70 is realized in the NFVI 60.
  • the virtual machine (VM) technology is used for the VNF 70
  • the CPU provided in the NFVI 60 is allocated for the VNF 70
  • the virtual machine is realized on the allocated CPU
  • the program is executed on the virtual machine. It is realized by.
  • the VNF 70 is normally generated (implemented) according to the communication process to be executed.
  • the VNF 70 is configured to include one or a plurality of VNFCs (Virtual Network Function Components) that are its constituent elements.
  • VNFCs Virtual Network Function Components
  • the update management system 1 includes one or more (or a plurality of) VNFs 70.
  • the VNF 70 corresponds to a node such as CSCF (Call Session Control Function) or AS (Application Server) in IMS.
  • the VNF 70 is a GPRS (General Packet Radio Service) system, which is one of mobile communication systems, for example, an SGSN (Serving GPRS Support Node), or an LTE / EPC (Long Term Evolution / Evolved Packet Core) system, an MME ( It corresponds to nodes such as Mobility Management Entity) and S-GW (Serving Gateway).
  • GPRS General Packet Radio Service
  • MME Long Term Evolution / Evolved Packet Core
  • EMS 80 is a node that monitors and controls the VNF 70.
  • the EMS 80 is also virtually realized in the NFVI 60 like the VNF 70.
  • the EMS 80 is generated in association with the VNF 70.
  • the EMS 80 monitors and controls the associated VNF 70.
  • the EMS 80 performs FCAPS (fault, configuration, billing, performance, security) management of the VNF 70.
  • FCAPS fault, configuration, billing, performance, security
  • the OSS / BSS 50 is a node that performs service management in the update management system 1 and instructs the orchestrator 20 and the like regarding the communication function. For example, the OSS / BSS 50 instructs the orchestrator 20 to activate a new communication service. The OSS / BSS 50 receives information from the EMS 80 and instructs the orchestrator 20 and the EMS 80 based on the information.
  • the orchestrator 20 is an overall management node (functional entity) that manages the entire NFVI 60 that is a virtualization resource.
  • the orchestrator 20 receives an instruction from the OSS / BSS 50 and performs processing according to the instruction.
  • the orchestrator 20 manages the entire virtualized resources of the mobile communication network for infrastructure and communication services.
  • the orchestrator 20 realizes a communication service composed of a plurality of VNFs 70 at an appropriate location via the VNFM 30 and the VIM 40.
  • service life cycle management (specifically, for example, generation, update, scale control, event collection), resource distribution / reservation / allocation management, service / instance management, and policy management (in the mobile communication network) Specifically, for example, resource reservation / allocation, optimal placement based on geography / laws, etc.) is performed.
  • the VNFM 30 is a virtual communication function management node (functional entity) that manages the VNF 70.
  • a plurality of VNFMs 30 may be provided in the update management system 1. In that case, the VNFM 30 managed for each VNF 70 may be determined in advance.
  • the VNFM 30 performs life cycle management of the VNF 70 (APL).
  • the VNFM 30 performs overall control related to the virtualization of the VNF 70. For example, VNF70 instance generation, update, scale control, termination, and auto healing (automatic healing) are performed.
  • the VIM 40 is a virtual resource management node (functional entity) that manages each virtual resource (infrastructure resource) in a unit in which the VNF 70 in the NFVI 60 is realized. Specifically, resource allocation / update / recovery management, association between virtual resources and physics, and management of hardware resources and SW resources (hypervisor) list are performed. Usually, the VIM 40 performs management for each data center (station building). The management of virtual resources can be performed by a method according to the data center. Data center management methods (management resource implementation methods) include OPENSTACK and vCenter. Normally, the VIM 40 is provided for each data center management method.
  • the update management system 1 includes a plurality of VIMs 40 that manage the respective virtual resources in units in which the VNFs 70 in the NFVI 60 are realized in different ways.
  • the units of virtual resources managed by different management methods do not necessarily have to be data center units.
  • the orchestrator 20, the VNFM 30, and the VIM 40 are realized by executing a program on a physical server device (however, they are not limited to being realized on virtualization, and the management system is separated) Above, may be realized on virtualization).
  • the orchestrator 20, the VNFM 30, and the VIM 40 may be realized by separate physical server devices, or may be realized by the same server device.
  • the orchestrator 20, the VNFM 30, and the VIM 40 (programs for realizing) may be provided from different vendors.
  • FIG. 2 shows a functional block configuration in the first embodiment.
  • the “service monitoring means” in the claims can correspond to the one including the EMS 80 and the OSS / BSS 50 in FIG. 2, but here, the EMS 80 that monitors the VNF that executes the service is the monitoring unit 83 or the like. An example provided with will be described.
  • the function block configuration related to the generation of the new version VNF includes the following.
  • the orchestrator 20 receives a request for updating to the new version of the communication service application, acquires the resource information for the new version VNF from the VNFM, and obtains the resource for the new version VNF for the VIM. Reserving the resource reservation unit 23 and instructing the VIM to generate a new version VNF using the reserved resource, and generating / holding old and new correspondence data indicating the correspondence between the new version VNF and the old version VNF, in the VNFM A VNF generation instructing unit 24 for notification.
  • the VIM 40 includes a VNF generation unit 41 that generates a new version VNF based on a new version VNF generation instruction.
  • the VNFM 30 includes a VNF activation notification unit 32 that receives the notification of the new and old correspondence data and notifies the EMS 80 that the new version VNF is activated.
  • the EMS 80 includes a synchronization execution unit 82 that synchronizes the new version VNF with the setting information of the old version VNF based on the new and old correspondence data obtained based on the notification from the VNFM 30.
  • the “new / old correspondence data” is generated, for example, as one record in a table format database and is stored in the table format database. Specific examples will be described later with reference to FIGS.
  • the orchestrator 20 includes a switching instruction unit 25 that instructs the VIM 40 to switch the network from the old version VNF to the new version VNF after the synchronization is completed.
  • the VIM 40 includes a switching execution unit 42 that executes network switching to the new version VNF based on a network switching instruction.
  • the EMS 80 includes a monitoring unit 83 that monitors a new version communication service executed by the new version VNF.
  • the orchestrator 20 identifies the new version VNF and the old version VNF based on the new and old correspondence data when the trouble is found in the new version communication service by monitoring by the EMS 80, and changes the new version VNF to the old version VNF.
  • a switchback request unit 26 that requests the VIM to perform a network switchback is provided.
  • the VIM 40 includes a switch back execution unit 43 that executes network switch back from the new version VNF to the old version VNF based on the network switch back request.
  • the orchestrator 20, the VNFM 30, and the EMS 80 are provided with data holding units 21, 31, 81 that hold data such as new and old correspondence data, which will be described later.
  • FIG. 3 shows a hardware configuration of a server device that constitutes the orchestrator 20, the VNFM 30, and the VIM 40.
  • the server device includes a CPU 101, a RAM (Random Access Memory) 102 and a ROM (Read Only Memory) 103, which are main storage devices, a communication module 104 for communication, and an auxiliary storage device such as a hard disk.
  • the computer is configured to include a computer having hardware such as 105.
  • the orchestrator 20, the VNFM 30, and the VIM 40 may be configured by a computer system including a plurality of server devices. Further, nodes other than those described above included in the update management system 1 may also be realized by a server device having the above hardware configuration.
  • the orchestrator 20 holds, in the data holding unit 21, the old and new correspondence data illustrated in FIG. 4A, the VNF configuration data illustrated in FIG. 4B, and the VNFC configuration data illustrated in FIG. Among these, the new / old correspondence data is generated when the orchestrator 20 acquires necessary information from the VNFM 30 in response to the update notification, and is deleted when the update is confirmed or the network is switched back.
  • the old and new correspondence data includes a reception number, a new VNF number, an old VNF number, a VNF type, a version, a network configuration, and a state.
  • the VNF configuration data includes a VNF number, a VNF type, a version, and configuration information.
  • the orchestrator 20 switches the network to the VIM 40 as in the first embodiment. ⁇ Hold only when switching back is instructed.
  • the VNFC configuration data includes the VNFC number, the VNFC type, the version, and the configuration information.
  • the VNFC configuration data is transmitted from the orchestrator 20 to the VIM 40 as in the first embodiment. It is retained only when switching back is instructed.
  • the VNFM 30 stores the update condition data illustrated in FIG. 5A, the old and new correspondence data illustrated in FIG. 5B, the VNF configuration data illustrated in FIG. 5C, and the data holding unit 31 in FIG.
  • the old and new correspondence data is generated by the VNFM 30 at the time of update notification, and is deleted at the time of subsequent update confirmation or network switchback.
  • the new / old correspondence data includes a reception number, a new VNF number, an old VNF number, a VNF type, a version, and a state.
  • the VNF configuration data is generated when the VNF is generated, and the VNF configuration data includes a VNF number, a VNF type, a version, and configuration information as shown in FIG.
  • the VNFC configuration data includes a VNFC number, a VNFC type, a version, and configuration information as shown in FIG. 5 (d).
  • the VNFC configuration data is switched from the VNFM 30 to the VIM 40 as in the second embodiment described later. It is retained only when switching back is instructed.
  • the EMS 80 holds, in the data holding unit 81, the old and new correspondence data illustrated in FIG. 6A, the VNF configuration data illustrated in FIG. 6B, and the setting data illustrated in FIG. Among them, the new and old correspondence data is generated when the update notification is received by the EMS 80, and is deleted when the new VNF is deleted or the old VNF is deleted.
  • the new / old correspondence data includes a new VNF number, an old VNF number, a version, and a state as shown in FIG.
  • the VNF configuration data includes a VNF number, a VNF type, a version, and configuration information.
  • the setting data includes a VNF number and setting data as shown in FIG.
  • FIG. 7 shows a processing flow until generation of a new version VNF
  • FIG. 8 shows a processing flow related to setting synchronization and network switching
  • FIG. 9 shows a processing flow when the new version VNF is operating normally (when no defect is detected).
  • FIG. 10 shows a processing flow when an abnormality occurs in the new version VNF (when a defect is detected), which will be described below in order.
  • network is abbreviated as “NW”.
  • the OSS / BSS requests the orchestrator to update by specifying the VNF in the target service (step S1).
  • the correspondence between the target service, the VNF type, and the current version is held in the OSS / BSS in advance or at the time of VNF generation.
  • the signal transmitted at this time is an update request signal including (communication service, VNF type, version information), and (communication service: communication service 1, VNF type: VNF10, version: 1.5) is exemplified as a setting example. .
  • the orchestrator makes an update request acceptance response (step S2), and then inquires VNFM about resource information necessary for the specified version of VNF in order to generate the VNF to be updated (step S3).
  • the signal transmitted at this time is a necessary resource inquiry signal including (event number, VNF type, performance condition), and as a setting example (event number: xxxxx (note: number for request-response association) ), VNF type: VNF10, performance condition: 100, version: 1.5).
  • the resource information inquiry may be omitted by registering VNF information in advance in the orchestrator.
  • the VNFM responds to the orchestrator with resource information that meets the performance conditions of the specified version of the requested VNF (step S4).
  • the performance conditions, the VNF version, and the resource information are stored in advance by the VNFM.
  • the signal transmitted at this time is a necessary information response signal including necessary resource information, and a setting example (CPU: LOW, number of VMs: 4, network bandwidth: 1 Gbps, DC separable) is exemplified.
  • the orchestrator makes a reservation with the VIM based on the information obtained from the necessary resource inquiry (step S5).
  • the signal transmitted at this time is a resource reservation request signal including (DC, necessary resource information (VM, network)).
  • DC necessary resource information
  • VM network
  • DC1 ⁇ DataCenter led by orchestrator from necessary resources, necessary resource information CPU: High, number of VMs: 1, network bandwidth: 1 Gbps
  • CPU High, number of VMs: 1, network bandwidth: 1 Gbps
  • the VIM makes a reservation based on the reservation request information and the managed resource information (step S6), and responds to the orchestrator with the completion of the reservation (step S7).
  • the signal transmitted at this time is a resource reservation response signal including a reservation number.
  • the orchestrator issues an ID to the updated VNF, generates and holds a record in the new / old correspondence table (that is, the new / old correspondence data in FIG. 4A), and manages the update target VNF.
  • An update start is notified to VNFM in advance (step S8).
  • the VNF type corresponding to the notification destination VNFM is held by the orchestrator.
  • the signal transmitted at this time is an update start notification signal including (VNF type, old VNF number, new VNF number, update version).
  • VNF type VNF10, old VNF number: VNF10_1, new VNF number
  • the VNFM that has received the update start notification signal generates and holds a record of the old and new correspondence table (that is, the old and new correspondence data in FIG. 5B) based on the information in the received update start notification signal. Then, in order to synchronize the setting information with the VNF activated in the new version, the VNFM notifies the EMS that performs VNF setting management in advance of the update start (step S9).
  • the signal notified at this time is an update start notification signal including (old VNF number, new VNF number, update version), and as a setting example (old VNF number: VNF10_1, new VNF number: VNF10_2, version: 1.5 ) Is exemplified.
  • the EMS responds with Ack after receiving the request (step S10).
  • the EMS generates and holds a record of the new / old correspondence table (that is, the new / old correspondence data in FIG. 6A) based on the information in the signal from the VNFM.
  • the VNFM When the VNFM receives an Ack response from the EMS, the VNFM responds with an Ack to the orchestrator (step S11). In this response, the VNFM adds VNF configuration / arrangement / activation information.
  • the signal transmitted at this time is an Ack signal including VNF configuration / arrangement / startup information, and as a setting example (VNFC type, number, configuration information (Image: VNFCI_100_1, NIC_1: 1G: ON, NIC_2: OFF)) Illustrated.
  • the orchestrator makes a VNF generation request to the VIM after completing the update start notification (step S12).
  • a network connection state is designated so that the new version of VNF is not connected to the network until the switching timing.
  • the signal transmitted at this time is a VNF generation request signal including (reservation number, arrangement / activation information, network configuration information (bandwidth, configuration, network connection status)), and (configuration / activation information: DC: DC2, CPU: High, VM count: 1, VNFC type: VNFC100, VNFCI_100_2, network configuration information (bandwidth: 1Gbps, configuration: ⁇ NIC_1, IP address, ON ⁇ , ⁇ NIC_2, IP address, OFF ⁇ ) .
  • the VIM receives the generation request and performs server generation / activation for the NFVI (step S13). After the server generation / startup, the VIM notifies a VNF generation response (step S14).
  • the signal transmitted at this time is a VNF generation response signal including (reservation number, success / failure, server identification number). As a setting example, (reservation number: reservation number at generation, success / failure: activation success / failure, server identification number: activation)
  • the completed virtual server identifier VNFC100_2) is illustrated.
  • NFVI starts VNF2 (new version of VNF) by server generation / startup in step S15. If there are a plurality of servers, they are repeatedly generated.
  • the EMS After the application is started, the EMS refers to the stored old / old correspondence table to identify the new version of VNF (VNF2) and the old version of VNF (VNF1), and communicates with these VNFs 1 and 2, while VNF2 On the other hand, synchronization with the setting information of the old version VNF1 is performed (step S17).
  • the EMS When the synchronization is completed, the EMS notifies the VNFM and the OSS / BSS of the start completion (Steps S18 and S19).
  • the signal transmitted at this time is an activation / setting completion signal including a VNF number, and (VNF number: VNF10_2) is exemplified as a setting example. However, at this time, the VNF 1 is still processing a signal related to the service (step S20).
  • the OSS / BSS requests the orchestrator to switch the network after confirming that the new VNF has been activated and set up (step S21).
  • the signal transmitted at this time is a network switching request signal including (reception number, VNF type, switching source VNF number).
  • (reception number: reception number issued at the time of an update request, VNF type: The update target VNF type (VNF10), switching source VNF number: switching target VNF number (VNF10_1)) are exemplified.
  • the orchestrator receives the switching request, checks the new / old correspondence table using the switching source VNF number (old VNF number) as a key, identifies the switching target VNF number (new VNF number), and switches the switching target VNF (new VNF).
  • a network switching instruction is transmitted to the VIM that manages (step S22).
  • the network switching instruction when connection to the distribution device 63 in FIG. 1 is necessary, predetermined information necessary for connection is given. The distribution by the distribution device 63 will be described later with reference to FIG.
  • the signal transmitted at this time is a network switching instruction signal including (reservation number, server identification number, network configuration information). As a setting example, (reservation number: resource reservation number, server identification number: switching) Server identification number and network configuration information (bandwidth: 1 Gbps, configuration: NIC_2, IP address, ON (connection to switching device)).
  • the VIM performs network switching for the NFVI in response to the network switching instruction (step S23).
  • the NFVI performs network switching (step S24), whereby a service-related signal is transmitted to the VNF 2.
  • a service-related signal is transmitted to the VNF 2.
  • the same IP address is assigned to server 1 and server 2, and a flow (combination of several fields in an IP packet and an Ether frame) like OpenFlow.
  • Network switching is realized by changing the destination NIC (virtual port) for the same given IP packet using the mechanism for changing the destination on a base basis.
  • the signal regarding a service is transmitted to the server 2 (step S25), and the process by the server 2 is started to be executed.
  • the VIM transmits a network switching completion notification to the orchestrator (step S26), and the orchestrator transmits a network switching response to the OSS / BSS (step S27).
  • the EMS and VNF 2 notify the OSS / BSS of the service status (number of processing success / failure etc.) (steps S28 and S29). Note that the state of notification differs depending on the service.
  • the OSS / BSS monitors the service status notification and monitors the service for a certain period of time (step S30).
  • the OSS / BSS transmits an update confirmation request to the orchestrator (step S41).
  • This transmission trigger is determined by a person or automatically transmitted after a certain period.
  • the signal transmitted at this time is an update confirmation request signal including a reception number, and a setting example (reception number: reception number issued at the time of an update request) is exemplified.
  • the orchestrator obtains the VNF number of the old version VNF (VNF1) to be deleted by referring to the stored old / old correspondence table using the VNF number of the new version VNF as a key, and notifies the update confirmation notification to the VNFM (step) (S42), a request to delete the old VNF is transmitted to the VIM (step S43).
  • an update confirmation notification signal including (VNF type: VNF100, VNF number: VNF100_1) is transmitted.
  • a VNF deletion request signal including (reservation number, VNF number: VNF100_1) is transmitted, and (reservation number: reservation number when generating old VNF) is exemplified as a setting example.
  • VNFM notifies the update confirmation notice to EMS (step S44).
  • the signal transmitted at this time is an update confirmation notification signal including (VNF type: VNF100, VNF number: VNF100_1).
  • EMS receives the update confirmation notification and performs the process of stopping the old VNF application (step S45).
  • saving of the log of the old VNF may be included.
  • the VIM performs server stop / deletion for the NFVI (step S46), returns the execution result to the orchestrator (step S48), and releases resources.
  • the signal transmitted at this time is a VNF deletion response signal including a reservation number. As a result, VNF1 disappears due to the deletion in step S47.
  • the orchestrator receives the deletion response and notifies the update confirmation response to the OSS / BSS (step S49).
  • FIG. 10 Processing flow when abnormality of new version VNF occurs (when a defect is detected)
  • VNF2 new VNF
  • the EMS detects the failure (step S61), and the EMS notifies the OSS / BSS that there is an abnormality in service processing (step S62).
  • the OSS / BSS requests an update failback request from the overall management in order to return it before the update (step S63).
  • the signal transmitted at this time is an update failback request signal including (acceptance number, deletion necessity).
  • the orchestrator receives the update failback request, refers to the stored old / old correspondence table, grasps the correspondence between the old and new versions of VNF, obtains the VNF number of the new version VNF (VNF2), and sends a failback notification to VNFM.
  • the network switchback request is transmitted to the VIM (step S65).
  • a switchback notification signal including (VNF number: VNF100_2) is transmitted.
  • a network switchback request signal including a reservation number for reserving the new VNF is transmitted.
  • VNFM transmits a switchback notification to EMS (step S66).
  • the signal transmitted at this time is a switchback notification signal including (VNF number: VNF100_2).
  • EMS that manages VNF2 stops the application of VNF2 (step S67).
  • the VIM instructs the NFVI to switch the network (step S68), and transmits a network switchback response to the orchestrator (step S69).
  • the NFVI performs network switching (step S70). As a result, a service-related signal is transmitted to the VNF 1 (step S71).
  • the orchestrator receives the network switchback response from the VIM and notifies the OSS / BSS of the update switchback response (step S75). At this time, the orchestrator performs server deletion processing in accordance with the necessity of deletion in the failback request. That is, the orchestrator transmits a server deletion request to the VIM (step S72), the VIM instructs the NFVI to delete the server (step S73), and the NFVI deletes the server (VNF2) (step S74).
  • old and new correspondence data (corresponding record in the old and new correspondence table) held by the orchestrator and VNFM is deleted at the time of update confirmation or network switchback.
  • the old and new correspondence data (corresponding record in the old and new correspondence table) held by the EMS is deleted when the new VNF or the old VNF is deleted.
  • the “update state” of the orchestrator 20 is the initial state when the orchestrator 20 receives an update request, transmits a resource reservation, and generates a table related to the current update. Transition from “Before update start / after completion” to “Reserving”. If the reservation fails and the table is deleted, the update state returns to the initial state.
  • the update state transitions from “Reserving” to “Updating”.
  • the update state returns to the initial state.
  • the update state transitions from “Updating” to “Monitoring”. Thereafter, when the update is confirmed or the network is switched back and the table is deleted, the update state returns to the initial state.
  • the “update state” of the VNFM 30 starts from the initial state (before / after update start) when the VNFM 30 receives the update notification and generates a table related to the current update. Transition to “Updating / Monitoring”. Thereafter, when an update confirmation notification or network switchback notification is received and the table is deleted, the update state returns to the initial state.
  • Network switching method Here, a method of network switching to the new version VNF will be described.
  • a new version of VNF2 whose settings are synchronized with the old version of VNF1 is generated, and the network data flow is switched from VNF1 to VNF2, thereby executing network switching to VNF2.
  • Examples of the network switching method at this time include a method of switching at a time at a certain timing (first method), and a method of distributing packet destinations to VNF 2 in order from the newly started processing (second method). Is done.
  • the first method can be applied to a service that completes processing with one round-trip request / response
  • the second method can be applied to a service that completes processing with multiple round-trip signals.
  • FIG. 12A shows a configuration diagram when the first method is executed. That is, a virtual switch 61A on the virtual network is generated in the NFVI 60.
  • the virtual switch 61A includes a port 3 serving as an interface for an external packet, and a port 1 connected to the virtual interface 64A of the old version VNF1.
  • the port 2 connected to the virtual interface 64B of the new version VNF2 is generated.
  • the virtual switch is abbreviated as “virtual SW”, and the virtual interface is abbreviated as “virtual I / F”.
  • the virtual switch 61A holds the flow table shown in FIG. 12B and switches the data transfer destination according to the contents of the flow table.
  • the virtual switch 61A forwards the packet entered from the port 3 (the packet addressed to the VNF IP from the external network) to the port 1 before the network switching. Then, transfer to the old version of VNF1.
  • the virtual switch 61A changes the “forwarding destination” of the flow table to the port 2, thereby transferring the VNF IP addressed packet from the subsequent external network to the port 2.
  • the network switching to the new version of VNF 2 is executed normally.
  • the virtual switch 61A changes the “forwarding destination” of the flow table to port 1 so that the packet addressed to the IP of the VNF from the subsequent external network To port 1.
  • the network switchback to the old version of VNF 1 is normally executed.
  • FIG. 13A shows a configuration diagram when the second method is executed. That is, the virtual switch 61A and the distribution device 63 on the virtual network are generated in the NFVI 60, and the virtual switch 61A outputs to the distribution device 63 in addition to the ports 1 to 3 as in FIG. And a port 5 for receiving an input from the sorting device 63 are generated.
  • the distribution method of the distribution device 63 is not limited to a specific method.
  • the distribution device 63 may be realized by temporarily connecting an existing virtual server or generated temporarily. You may implement
  • the virtual switch 61A holds a flow table as shown in FIGS. 13B to 13D and switches the data transfer destination according to the contents of the flow table.
  • the virtual switch 61A forwards the packet entered from the port 3 (packet addressed to the VNF IP from the external network) to the port 1 as shown in the flow table of FIG.
  • the data is transferred to the old version of VNF1.
  • the virtual switch 61A transfers the packet entered from the port 3 (the packet addressed to the VNF IP from the external network) as shown in the flow table of FIG. By transferring to 4, the data is transferred to the sorting device 63.
  • the distribution device 63 determines whether the received packet is an ongoing process packet or a new process packet. If the received packet is an ongoing process packet, attribute information (for example, VLAN ((Virtual Local Area Network) VLAN) )) Is marked with "100" and transferred to the virtual switch 61A, and in the case of a newly processed packet, the attribute information (for example, VLAN) of the packet is marked with "200" and transferred to the virtual switch 61A.
  • attribute information for example, VLAN ((Virtual Local Area Network) VLAN)
  • the virtual switch 61A confirms the VLAN of the packet entered from the port 5 (packet from the distribution device 63), and the packet whose VLAN is “100” (continuation) A packet with a VLAN of “200” (a packet with a new process) is transferred to port 2.
  • the ongoing process packet is transferred to the old version of VNF1, and the new process packet is transferred to the new version of VNF2.
  • the virtual switch 61A As shown in the flow table of FIG. 13 (d), the packet entered from the port 3 (VNF from the external network).
  • the packet addressed to IP is transferred to port 2 to transfer to the new version of VNF2. This completes the network switching to the new version of VNF2.
  • the transfer may be performed based on the flow table of FIG.
  • the second method as described above can prevent abnormal termination in the middle of processing due to network switching even for a service in which processing is completed by multiple round trips of signals.
  • FIG. 14 shows a functional block configuration in the second embodiment.
  • the function block configuration related to the generation of the new version VNF includes the following.
  • the orchestrator 20 receives a request for updating to the new version of the communication service application, acquires the resource information for the new version VNF from the VNFM, and the resource for the new version VNF to the VIM 40 And a resource reservation unit 23 for making reservations and transmitting the reserved resource information and an instruction to update the new version to the VNFM.
  • the VNFM 30 instructs the VIM 40 to generate a new version VNF using the reserved resource, and also generates a VNF generation instruction unit 33 that generates and holds old and new correspondence data indicating correspondence between the new version VNF and the old version VNF.
  • a VNF activation notifying unit 32A for notifying the EMS 80 that the new version VNF is activated based on the new / old correspondence data.
  • the VIM 40 includes a VNF generation unit 41 that generates a new version VNF based on a new version VNF generation instruction.
  • the EMS 80 includes a synchronization execution unit 82 that synchronizes the new version VNF with the setting information of the old version VNF based on the new and old correspondence data obtained based on the notification from the VNFM 30.
  • the VNFM 30 further includes a switching instruction unit 34 that instructs the VIM 40 to switch the network from the old version VNF to the new version VNF after the synchronization is completed.
  • the VIM 40 further includes a switching execution unit 42 that executes network switching to the new version VNF based on a network switching instruction.
  • the EMS 80 further includes a monitoring unit 83 that monitors a new version communication service executed by the new version VNF.
  • the VNFM 30 When the VNFM 30 further detects a failure in the new version communication service through monitoring by the EMS 80, the new version VNF and the old version VNF are identified based on the retained old and new correspondence data, and the network from the new version VNF to the old version VNF is identified.
  • a switch-back request unit 35 that requests the VIM 40 to switch back is provided.
  • the VIM 40 further includes a switch back execution unit 43 that executes network switch back from the new version VNF to the old version VNF based on the network switch back request.
  • the orchestrator 20, the VNFM 30, and the EMS 80 are provided with data holding units 21, 31, 81 that hold data such as old and new correspondence data described in the first embodiment, respectively.
  • FIGS. 15 to 18 show a processing flow until generation of a new version VNF
  • FIG. 16 shows a processing flow related to setting synchronization and network switching
  • FIG. 17 shows a processing flow when the new version VNF is operating normally (when no defect is detected).
  • FIG. 18 shows a processing flow when an abnormality occurs in the new version VNF (when a defect is detected), which will be described in the following order. Note that the detailed method of network switching (FIGS. 12 and 13) is the same as that in the first embodiment, and thus description thereof is omitted below.
  • the OSS / BSS requests the orchestrator to update by specifying the VNF in the target service (step S101).
  • the correspondence between the target service, the VNF type, and the current version is held in the OSS / BSS in advance or at the time of VNF generation.
  • the signal transmitted at this time is an update request signal including (communication service, VNF type, version information), and (communication service: communication service 1, VNF type: VNF10, version: 1.5) is exemplified as a setting example. .
  • the orchestrator makes an update request acceptance response (step S102), and then inquires VNFM about resource information necessary for the specified version of the VNF to be updated (step S103).
  • the signal transmitted at this time is a necessary resource inquiry signal including (event number, candidate resource, VNF type, version).
  • a VIM list or the like is set in “candidate resource”.
  • the VNFM selects from the candidate resources and responds with necessary resource information for each DC (step S104).
  • the signal transmitted at this time is a required resource inquiry response signal including (event number, required resource information).
  • event number number specified in the inquiry
  • required resource information resource information assigned to each DC (CPU, number of VMs, network bandwidth)).
  • the orchestrator makes a resource reservation based on the necessary resource information (step S105).
  • the signal transmitted at this time is a resource reservation request signal including (DC, necessary resource information).
  • the VIM makes a reservation based on the reservation request information and the managed resource information (step S106).
  • the VIM responds that the reservation is complete (step S107).
  • the signal transmitted at this time is a resource reservation response signal including a reservation number.
  • the orchestrator requests the VNFM to start updating (step S108).
  • the signal transmitted at this time is an update start request signal including (event number, version information, reservation number).
  • event number number used in necessary resource inquiry, version information: 1.5, reservation number: Completed reservation number).
  • the VNFM issues an ID (new VNF number (for example, VNF100_2)) for the new version of the VNF, and generates and holds a record of the old / new correspondence table (that is, the old / old correspondence data in FIG. 5B). Then, the VNFM notifies the update start to the EMS that manages the setting of the VNF in order to synchronize the setting information with the VNF activated in the new version (step S109).
  • the signal transmitted at this time is an update start notification signal including (old VNF number: VNF100_1, new VNF number: VNF100_2, update version).
  • the EMS When the EMS receives the notification from the VNFM, the EMS responds with an Ack signal (step S110). At this time, the EMS generates and holds a record of the new / old correspondence table (that is, the new / old correspondence data in FIG. 6A) based on the information in the signal from the VNFM.
  • the VNFM receives a response from the EMS and makes a VNF generation request to the VIM (step S111).
  • the signal transmitted at this time is a VNF generation request signal including (reservation number, arrangement / activation information, network configuration information (bandwidth, configuration, network connection status)). Since the VNF generation request signal at this time is the same as that in the first embodiment, a duplicate description is omitted.
  • the VIM receives the VNF generation request, and performs server generation / activation for the NFVI (step S112). After the server generation / startup, the VIM notifies the VNF generation response (step S113).
  • the signal transmitted at this time is a VNF generation response signal including (reservation number, success / failure, server identification number). As a setting example, (reservation number: reservation number at generation, success / failure: activation success / failure, server identification number: activation)
  • the completed virtual server identifier VNFC100_2 is illustrated.
  • NFVI starts VNF2 (new version of VNF) by the server generation / start-up in step S112 (step S114). If there are a plurality of servers, they are repeatedly generated.
  • the VNFM that has received the VNF generation response returns an Ack signal as an update start request response to the orchestrator (step S115).
  • the orchestrator is notified of information required to generate the old and new correspondence data such as the old VNF number, the new VNF number, and the updated version, and the orchestrator uses the information to record the old and new correspondence table (that is, FIG. 4).
  • (A) New and old correspondence data) is generated and held.
  • FIG. 16 Processing flow for setting synchronization and network switching
  • the server is booted and the application is started (step S116).
  • the EMS After the application is started, the EMS refers to the stored old / old correspondence table to identify the new version of VNF (VNF2) and the old version of VNF (VNF1), and communicates with these VNFs 1 and 2, while VNF2 On the other hand, synchronization with the setting information of the old version VNF1 is performed (step S117).
  • the EMS When the synchronization is completed, the EMS notifies the VNFM and the OSS / BSS of the start completion (Steps S118 and S119).
  • the signal transmitted at this time is an activation / setting completion signal including a VNF number, and (VNF number: VNF10_2) is exemplified as a setting example. However, at this time, the VNF 1 is still processing a signal related to the service (step S120).
  • the OSS / BSS requests the orchestrator to switch the network after confirming that the new VNF has been started and set up (step S121).
  • the signal transmitted at this time is a network switching request signal including (reception number, VNF type, switching source VNF number).
  • VNF type reception number issued at the time of an update request
  • VNF type The update target VNF type (VNF10)
  • switching source VNF number switching target VNF number (VNF10_1)
  • the orchestrator receives the switching request, checks the old / new correspondence table using the switching source VNF number (old VNF number) as a key, identifies the number of the VNF to be switched (new VNF number), and requests the VNFM to switch ( Step S122).
  • the signal transmitted at this time is a network switching request signal including (event number, VNF number: VNF100_1).
  • VNFM requests network switching to VIM (step S123).
  • the signal transmitted at this time is a network switching instruction signal including (reservation number, VNF number, network configuration information).
  • (reservation number: number for resource reservation, VNF number: server identification to be switched) No., network configuration information: configuration NIC_2, IP address, ON (connection to distribution device)).
  • the VIM performs network switching for the NFVI in response to the network switching instruction (step S124).
  • the NFVI performs network switching (step S125), whereby a service-related signal is transmitted to the VNF 2.
  • a service-related signal is transmitted to the VNF 2.
  • the same IP address is assigned to server 1 and server 2, and a flow (combination of several fields in an IP packet and an Ether frame) like OpenFlow.
  • Network switching is realized by changing the destination NIC (virtual port) for the same given IP packet using the mechanism for changing the destination on a base basis.
  • the signal regarding a service is transmitted to the server 2 (step S126), and the process by the server 2 is started to be executed.
  • the VIM transmits a network switching completion notification to the VNFM (step S127), the VNFM transmits a network switching response to the orchestrator (step S128), and the orchestrator transmits a network switching response to the OSS / BSS (step S128). S129).
  • the EMS monitors the service provided by the new version of VNF2 (step S130), and notifies the OSS / BSS of the service status (processing success / failure number, etc.) provided by the VNF2 (step S131).
  • the state notified by the service (the number of processing successes or the like) is different.
  • the OSS / BSS monitors the service status notification and monitors the service for a certain period of time (step S132).
  • the OSS / BSS transmits an update confirmation request to the orchestrator (step S141).
  • This transmission trigger is determined by a person or automatically transmitted after a certain period.
  • the signal transmitted at this time is an update confirmation request signal including a reception number, and a setting example (reception number: reception number issued at the time of an update request) is exemplified.
  • the orchestrator notifies the update confirmation notification including (event number, VNF type) to the VNFM (step S142).
  • the VNFM obtains the VNF number of the old version VNF (VNF1) to be deleted by referring to the held old and new correspondence table using the VNF number of the new version VNF as a key, and notifies the update confirmation notification to the EMS (step S143). ), A request to delete the old VNF is transmitted to the VIM (step S144).
  • an update confirmation notification signal including (VNF type: VNF100, VNF number: VNF100_1) is transmitted.
  • a VNF deletion request signal including (reservation number, VNF number: VNF100_1) is transmitted, and (reservation number: reservation number when generating old VNF) is exemplified as a setting example.
  • EMS receives the update confirmation notification and performs the process of stopping the old VNF application (step S145).
  • saving of the log of the old VNF may be included.
  • the VIM performs server stop / deletion for the NFVI (step S146), returns the execution result to the VNFM (step S148), and releases the resources.
  • the signal transmitted at this time is a VNF deletion response signal including a reservation number. As a result, VNF1 disappears due to the deletion in step S147.
  • VNFM receives the delete response and notifies the update confirmation response to the orchestrator (step S149), and the orchestrator receives the update confirmation response and notifies the update confirmation response to the OSS / BSS (step S150).
  • FIG. 18 Processing flow when abnormality of new version VNF occurs (when a defect is detected)
  • VNF2 new VNF
  • the EMS detects the failure (step S161), and the EMS notifies the OSS / BSS that there is an abnormality in service processing (step S162).
  • the OSS / BSS requests an update failback request to the overall management in order to return it before the update (step S163).
  • the signal transmitted at this time is an update failback request signal including (acceptance number, deletion necessity).
  • the orchestrator receives the update failback request and sends a failback notification to the VNFM (step S164).
  • the VNFM receives the update failback notification, refers to the stored old / old correspondence table, grasps the correspondence relationship between the old and new versions of the VNF, obtains the VNF number of the new version VNF (VNF2), and sends the failback notification to the EMS.
  • the signal transmitted at this time is a switchback notification signal including (VNF number: VNF100_2).
  • the VNFM transmits a network switchback request to the VIM (step S166).
  • a network switchback request signal including a reservation number for reserving a new VNF is transmitted.
  • EMS that manages VNF2 stops the application of VNF2 (step S167).
  • the VIM instructs the NFVI to switch the network (step S168), and transmits a network switchback response to the VNFM (step S171).
  • the NFVI performs network switching (step S169). As a result, a service-related signal is transmitted to the VNF 1 (step S170).
  • the VNFM receives the network switchback response from the VIM, notifies the orchestrator of the update switchback response (step S172), and the orchestrator notifies the OSS / BSS of the update switchback response (step S176). At this time, the VNFM performs server deletion processing according to whether or not deletion is required in the failback request. That is, the VNFM transmits a server deletion request to the VIM (step S173), the VIM instructs the NFVI to delete the server (step S174), and the NFVI deletes the server (VNF2) (step S175).
  • old and new correspondence data (corresponding record in the old and new correspondence table) held by the orchestrator and VNFM is deleted at the time of update confirmation or network switchback.
  • the old and new correspondence data (corresponding record in the old and new correspondence table) held by the EMS is deleted when the new VNF or the old VNF is deleted.
  • the “update state” of the orchestrator 20 is the initial state when the orchestrator 20 receives an update request, transmits a resource reservation, and generates a table related to the current update. Transition from “Before update start / after completion” to “Reserving”. If the reservation fails and the table is deleted, the update state returns to the initial state.
  • the update state transitions from “Reserving” to “Updating”.
  • the update state returns to the initial state.
  • the update state transitions from “Updating” to “Monitoring”. Thereafter, when the update is confirmed or the network is switched back and the table is deleted, the update state returns to the initial state.
  • the “update state” of the VNFM 30 is the initial state (update activation) when the VNFM 30 receives the update start request, instructs the VNF generation, and generates a table related to the current update. Transition from “Before / After” to “Updating”.
  • the update state returns to the initial state.
  • the update state transitions from “Updating” to “Monitoring”. Thereafter, when the update is confirmed or the network is switched back and the table is deleted, the update state returns to the initial state.
  • the update-related work including the update to the new version and the recovery process to the old version can be performed in a unified processing procedure regardless of the type of application. It can be executed efficiently. That is, efficient and seamless update-related work can be realized.
  • DESCRIPTION OF SYMBOLS 1 ... Update management system, 20 ... Orchestrator, 21 ... Data holding part, 22 ... Resource information acquisition part, 23 ... Resource reservation part, 24 ... VNF production

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Stored Programmes (AREA)

Abstract

　通信サービスを実行する複数のサーバを含んで構成される更新管理システムにおいて、旧バージョンのアプリケーションが稼動するサーバ（ＶＮＦ１）と並行して、新バージョンのアプリケーションが稼動するネットワーク未接続のサーバ（ＶＮＦ２）を生成しておき、新旧バージョンのサーバ間の新旧対応データを生成し利用することで、ネットワーク上のフローを旧バージョンサーバ（ＶＮＦ１）から新バージョンサーバ（ＶＮＦ２）への切替を実行し、新バージョンの不具合発生時には新旧対応データを参照して旧バージョンサーバ（ＶＮＦ１）への切り戻しを実行する。

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. 　前記ネットワーク切替を実行するステップでは、
    　前記仮想化資源管理ノードが、当初はネットワークから旧バージョン仮想サーバを切り離すことなく新バージョン仮想サーバをネットワークに接続し、
    　前記更新管理システム内で外部からのパケットのあて先を振り分ける振分手段が、新規に開始された処理から順にパケットのあて先を新バージョン仮想サーバへ振り分けていき、
    　切替前から継続する処理が無くなったとき又は所定の新バージョン監視期間が満了したときに、前記仮想化資源管理ノードが、ネットワークから旧バージョン仮想サーバを切り離す、
    　ことを特徴とする請求項７に記載の更新管理方法。
     
PCT/JP2015/054023 2014-03-28 2015-02-13 更新管理システムおよび更新管理方法 Ceased WO2015146355A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP15769695.6A EP3125117B1 (en) 2014-03-28 2015-02-13 Update management system and update management method
JP2016510115A JP6026705B2 (ja) 2014-03-28 2015-02-13 更新管理システムおよび更新管理方法
US15/121,427 US10140112B2 (en) 2014-03-28 2015-02-13 Update management system and update management method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-069216 2014-03-28
JP2014069216 2014-03-28

Publications (1)

Publication Number Publication Date
WO2015146355A1 true WO2015146355A1 (ja) 2015-10-01

Family

ID=54194893

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/054023 Ceased WO2015146355A1 (ja) 2014-03-28 2015-02-13 更新管理システムおよび更新管理方法

Country Status (4)

Country Link
US (1) US10140112B2 (ja)
EP (1) EP3125117B1 (ja)
JP (1) JP6026705B2 (ja)
WO (1) WO2015146355A1 (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2549574A (en) * 2016-03-21 2017-10-25 Ibm Replacing a virtual network function in a network service
WO2017183565A1 (ja) * 2016-04-21 2017-10-26 日本電気株式会社 ネットワークシステム、パッチファイル適用方法、及び記録媒体
JP2018032940A (ja) * 2016-08-23 2018-03-01 日本電気株式会社 仮想マシン制御装置とその制御方法、及び、管理装置とその制御方法
CN107967140A (zh) * 2016-10-18 2018-04-27 华为技术有限公司 软件修改的发起方法、发布元数据的方法及装置
JP2019522436A (ja) * 2016-07-21 2019-08-08 日本電気株式会社 通信装置、システム、ロールバック方法及びプログラム
CN113703917A (zh) * 2021-08-26 2021-11-26 上海道客网络科技有限公司 一种多集群资源数据处理系统与方法、非暂态存储介质
US12086017B2 (en) 2021-06-30 2024-09-10 Rakuten Mobile, Inc. Server management apparatus and server management method
US12242838B2 (en) 2021-06-30 2025-03-04 Rakuten Mobile, Inc. Server management apparatus and server management method

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101938623B1 (ko) * 2014-06-03 2019-01-15 후아웨이 테크놀러지 컴퍼니 리미티드 오픈 플로우 통신 방법, 시스템, 제어기 및 서비스 게이트웨이
CN105323085A (zh) * 2014-07-10 2016-02-10 中兴通讯股份有限公司 创建性能测量任务、性能测量结果的处理方法及装置
US11665061B2 (en) * 2015-02-03 2023-05-30 Nec Corporation Virtual network system, virtual network control method, virtual network function database, orchestration apparatus, control apparatus, and control method and control program of control apparatus
CN106464667B (zh) * 2015-02-09 2020-01-10 华为技术有限公司 一种证书管理方法、设备及系统
JP2017004120A (ja) * 2015-06-05 2017-01-05 キヤノン株式会社 システム、サーバーシステム、方法、およびプログラム
CN116488995A (zh) * 2016-01-08 2023-07-25 苹果公司 用于虚拟化网络功能的实例化和终止的技术
WO2017125161A1 (en) 2016-01-21 2017-07-27 Hewlett Packard Enterprise Development Lp Resource allocation
US11175966B2 (en) * 2016-02-26 2021-11-16 Arista Networks, Inc. System and method of a managing multiple data centers
US10671376B2 (en) * 2016-03-15 2020-06-02 Shenzhen Skyworth-Rgb Electronic Co., Ltd. Server program hot upgrading method and device
US10454771B2 (en) 2016-04-06 2019-10-22 Alcatel Lucent Virtual infrastructure
US10547511B2 (en) 2016-05-04 2020-01-28 Alcatel Lucent Infrastructure resource states
WO2017222613A1 (en) * 2016-06-20 2017-12-28 Intel IP Corporation End-to-end techniques to create pm (performance measurement) thresholds at nfv (network function virtualization) infrastructure
US11063993B2 (en) * 2016-06-29 2021-07-13 Telefonaktiebolaget Lm Ericsson (Publ) Network function virtualization
US10305788B2 (en) 2016-06-30 2019-05-28 Alcatel Lucent Near-real-time and real-time communications
US10169028B2 (en) * 2016-12-13 2019-01-01 Ciena Corporation Systems and methods for on demand applications and workflow management in distributed network functions virtualization
CN107197042B (zh) * 2017-07-04 2020-02-14 郑州云海信息技术有限公司 一种资源同步方法及装置
US11003516B2 (en) * 2017-07-24 2021-05-11 At&T Intellectual Property I, L.P. Geographical redundancy and dynamic scaling for virtual network functions
JP6951171B2 (ja) * 2017-09-19 2021-10-20 シャープ株式会社 ファイル管理装置、複合機及び情報処理装置、ファイル管理方法並びにファイル管理用プログラム
CN109639449B (zh) * 2017-10-09 2021-09-03 中兴通讯股份有限公司 虚拟化流镜像策略自动化管理的方法、设备及介质
CA3084719C (en) 2017-10-17 2024-01-23 Telefonaktiebolaget Lm Ericsson (Publ) Service registration in a communications network
US10778506B1 (en) 2017-11-30 2020-09-15 Open Invention Network Llc Coordinated switch of activity in virtual network function components
US10432524B2 (en) * 2017-12-20 2019-10-01 At&T Intellectual Property I, L.P. Parallelism for virtual network functions in service function chains
KR102190767B1 (ko) * 2018-06-20 2020-12-15 숭실대학교산학협력단 네트워크 기능 가상화 운영 장치 및 방법
KR102036731B1 (ko) * 2018-09-06 2019-10-25 숭실대학교산학협력단 가상화 네트워크 기능 클러스터링 구성 시스템 및 방법
JP7163739B2 (ja) * 2018-11-27 2022-11-01 株式会社リコー 情報処理装置、プログラム更新方法、及びプログラム
CN109450701B (zh) * 2018-12-07 2020-04-17 北京金山云网络技术有限公司 一种虚拟交换机切换方法、装置、宿主机及计算机可读存储介质
JP7411467B2 (ja) * 2020-03-19 2024-01-11 株式会社デンソーテン 電子制御装置及びプログラム書き換え制御方法
US11409619B2 (en) 2020-04-29 2022-08-09 The Research Foundation For The State University Of New York Recovering a virtual machine after failure of post-copy live migration
CN114553692A (zh) 2020-11-25 2022-05-27 中兴通讯股份有限公司 网络切片升级的方法及装置
CN114614985B (zh) * 2022-05-12 2022-08-05 施维智能计量系统服务(长沙)有限公司 通信秘钥更新方法、秘钥服务器及可读存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011170528A (ja) * 2010-02-17 2011-09-01 Nec Corp 分散型情報処理システム及び分散ストレージシステム

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3951364B2 (ja) 1997-06-26 2007-08-01 株式会社日立製作所 ソフトウエア保守方法およびその装置
US7788665B2 (en) * 2006-02-28 2010-08-31 Microsoft Corporation Migrating a virtual machine that owns a resource such as a hardware device
JP5246388B2 (ja) 2007-03-08 2013-07-24 日本電気株式会社 仮想装置構成システム、及びその方法
JP5223596B2 (ja) * 2008-10-30 2013-06-26 富士通株式会社 仮想計算機システム及びその管理方法、管理プログラム並びに記録媒体、制御方法
JP5428581B2 (ja) * 2009-06-30 2014-02-26 富士通株式会社 仮想マシン管理プログラム及び仮想マシン管理方法
US8359594B1 (en) * 2009-06-30 2013-01-22 Sychron Advanced Technologies, Inc. Automated rapid virtual machine provisioning system
US8954962B2 (en) * 2010-09-22 2015-02-10 Juniper Networks, Inc. Automatically reconfiguring physical switches to be in synchronization with changes made to associated virtual system
US9110727B2 (en) * 2010-10-05 2015-08-18 Unisys Corporation Automatic replication of virtual machines
JP5594049B2 (ja) * 2010-10-18 2014-09-24 富士通株式会社 仮想計算機移動方法、コンピュータ及びプログラム
US8813076B2 (en) * 2011-11-17 2014-08-19 International Business Machines Corporation Virtual machine updates
IN2014CN03995A (ja) * 2011-12-08 2015-09-04 Ibm
US9323563B2 (en) * 2012-02-28 2016-04-26 Red Hat Israel, Ltd. Determining virtual machine migration in view of a migration rule
US9069640B2 (en) * 2012-03-23 2015-06-30 Hitachi, Ltd. Patch applying method for virtual machine, storage system adopting patch applying method, and computer system
GB2510874B (en) * 2013-02-15 2020-09-16 Ncr Corp Server system supporting remotely managed IT services
US9628290B2 (en) * 2013-10-09 2017-04-18 International Business Machines Corporation Traffic migration acceleration for overlay virtual environments

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011170528A (ja) * 2010-02-17 2011-09-01 Nec Corp 分散型情報処理システム及び分散ストレージシステム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ETSI GS NFV 002, vol. 1. 1.1, October 2013 (2013-10-01), XP055292127, Retrieved from the Internet <URL:http://www.etsi.org/deliver/etsi_gs/nfv/001_ 099/D02/01.01.01_60/gs-nfv002v010101p.pdf> [retrieved on 20150318] *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2549574A (en) * 2016-03-21 2017-10-25 Ibm Replacing a virtual network function in a network service
GB2549574B (en) * 2016-03-21 2019-06-05 Ibm Replacing a virtual network function in a network service
US10362122B2 (en) 2016-03-21 2019-07-23 International Business Machines Corporation Replacing a virtual network function in a network service
US10547696B2 (en) 2016-03-21 2020-01-28 International Business Machines Corporation Replacing a virtual network function in a network service
WO2017183565A1 (ja) * 2016-04-21 2017-10-26 日本電気株式会社 ネットワークシステム、パッチファイル適用方法、及び記録媒体
JPWO2017183565A1 (ja) * 2016-04-21 2019-01-17 日本電気株式会社 ネットワークシステム、パッチファイル適用方法、及びプログラム
US11431569B2 (en) 2016-07-21 2022-08-30 Nec Corporation Communication apparatus, system, rollback method, and non-transitory medium
JP2019522436A (ja) * 2016-07-21 2019-08-08 日本電気株式会社 通信装置、システム、ロールバック方法及びプログラム
JP2018032940A (ja) * 2016-08-23 2018-03-01 日本電気株式会社 仮想マシン制御装置とその制御方法、及び、管理装置とその制御方法
CN107967140A (zh) * 2016-10-18 2018-04-27 华为技术有限公司 软件修改的发起方法、发布元数据的方法及装置
CN107967140B (zh) * 2016-10-18 2021-08-03 华为技术有限公司 软件修改的发起方法、发布元数据的方法及装置
US12086017B2 (en) 2021-06-30 2024-09-10 Rakuten Mobile, Inc. Server management apparatus and server management method
US12242838B2 (en) 2021-06-30 2025-03-04 Rakuten Mobile, Inc. Server management apparatus and server management method
CN113703917A (zh) * 2021-08-26 2021-11-26 上海道客网络科技有限公司 一种多集群资源数据处理系统与方法、非暂态存储介质
CN113703917B (zh) * 2021-08-26 2022-10-14 上海道客网络科技有限公司 一种多集群资源数据处理系统与方法、非暂态存储介质

Also Published As

Publication number Publication date
US10140112B2 (en) 2018-11-27
JPWO2015146355A1 (ja) 2017-04-13
US20160364226A1 (en) 2016-12-15
JP6026705B2 (ja) 2016-11-16
EP3125117A4 (en) 2017-04-05
EP3125117B1 (en) 2020-09-23
EP3125117A1 (en) 2017-02-01

Similar Documents

Publication Publication Date Title
JP6026705B2 (ja) 更新管理システムおよび更新管理方法
US12020055B2 (en) VNF service instantiation method and apparatus
US11307943B2 (en) Disaster recovery deployment method, apparatus, and system
JP6466003B2 (ja) Ｖｎｆフェイルオーバの方法及び装置
CN110536330B (zh) 一种ue迁移方法、装置、系统及存储介质
US10120710B2 (en) Virtualized resource management node and virtual migration method for seamless virtual machine integration
US11099869B2 (en) Management of network functions virtualization and orchestration apparatus, system, management method, and program
KR102059251B1 (ko) 노드 시스템, 서버 장치, 스케일링 제어 방법 및 프로그램
EP3490224A1 (en) Data synchronization method and system
CN104935672B (zh) 负载均衡服务高可用实现方法和设备
WO2016121834A1 (ja) ネットワーク機能仮想化管理方法とシステムと装置とプログラム
CN104158707A (zh) 一种检测并处理集群脑裂的方法和装置
JP2015191246A (ja) 通信システムおよび管理方法
CN104503861A (zh) 一种异常处理方法及系统、代理设备与控制装置
WO2018137520A1 (zh) 一种业务恢复方法及装置
CN110943928A (zh) 转发信息状态同步方法、控制器、网络转发设备及存储介质
CN107707413A (zh) 一种集群容灾方法及装置
CN105591780B (zh) 集群监测方法和设备
CN114422567A (zh) 数据请求的处理方法、装置、系统、计算机设备及介质
CN113300878A (zh) 数据平滑的实现方法及装置
KR20200011079A (ko) 가상화 네트워크 장치 또는 시스템의 소프트웨어 갱신을 위한 시스템 및 그 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15769695

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016510115

Country of ref document: JP

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2015769695

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015769695

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 15121427

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE