WO2017183565A1 - ネットワークシステム、パッチファイル適用方法、及び記録媒体 - Google Patents

ネットワークシステム、パッチファイル適用方法、及び記録媒体 Download PDF

Info

Publication number
WO2017183565A1
WO2017183565A1 PCT/JP2017/015222 JP2017015222W WO2017183565A1 WO 2017183565 A1 WO2017183565 A1 WO 2017183565A1 JP 2017015222 W JP2017015222 W JP 2017015222W WO 2017183565 A1 WO2017183565 A1 WO 2017183565A1
Authority
WO
WIPO (PCT)
Prior art keywords
vnf
nfvi
image file
vnfm
vim
Prior art date
Application number
PCT/JP2017/015222
Other languages
English (en)
French (fr)
Inventor
佳彦 星野
Original Assignee
日本電気株式会社
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 日本電気株式会社 filed Critical 日本電気株式会社
Priority to US16/084,651 priority Critical patent/US20190073235A1/en
Priority to JP2018513150A priority patent/JP6677294B2/ja
Publication of WO2017183565A1 publication Critical patent/WO2017183565A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H04L41/0897—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/45595—Network integration; Enabling network access in virtual machine instances

Definitions

  • the present invention relates to a network system, a patch file application method, and a recording medium.
  • NFV Network Functions Virtualization
  • VM Virtual Machine
  • HV hypervisor
  • a VNF (Virtualized Network Function) 22 corresponds to an application or the like that operates on a virtual machine (VM) on the server, and realizes a network function in software.
  • a management function called EMS (Element Management System) 23 is provided for each VNF 22.
  • the EMS 23 is also called a management element (EM: Element Manager).
  • NFVI Network Functions Virtualization Infrastructure 21 is a base that can flexibly handle hardware resources as virtual hardware resources.
  • the hardware resource is computing, storage, network function, physical machine (server), or the like.
  • the virtual hardware resource is virtualized computing, virtualized storage, or virtualized network virtualized by a virtualization layer such as a hypervisor.
  • the NFV Orchestrator (NFVO) 11 of the NFV-MANO (NFV Management & Orchestration) 10 performs the following processing. This processing includes orchestration of resources of the NFVI 21 and life cycle management of a network service (NS) instance.
  • NS network service
  • An NS instance is an instantiation, scaling, termination, update, etc. of an NS instance.
  • VNF Manager VNFM 12 performs life cycle management of VNF instances and event notification.
  • the life cycle management of the VNF instance includes, for example, instantiation, update, query, scaling, and termination.
  • the virtualization infrastructure manager (virtualized infrastructure manager: VIM) 13 executes the following processing. This processing includes NFVI21 computing, storage, network resource management, NFVI21 failure monitoring, NFVI21 resource monitoring, and the like.
  • OSS Operations Support Systems
  • BSS Business Support systems
  • information systems equipment, software, mechanisms, etc.
  • Patent Document 1 discloses a technique related to NFV and the like.
  • Patent Document 2 discloses a technique related to an image file for managing a client terminal.
  • NFVO11, VNFM12, VIM13, etc. mentioned above are functional entities for managing the network system. Under the control of these functional entities, a virtual machine and a VNF are generated on a physical machine (Physical Machine: PM).
  • a plurality of physical machines are arranged together in a regional base that forms part of the network system.
  • the VIM 13 is arranged corresponding to the plurality of physical machines.
  • service support mechanisms such as the OSS / BSS 30 and management mechanisms such as the NFVO 11 and the VNFM 12 are often integrated at a central location.
  • the management mechanism centralized at the central base performs overall resource management over a plurality of regional bases (multiple VIMs).
  • the image file necessary for instantiation of the VNF 22 is provided from the NFVO 11 at the central site to the VIM 13 at the regional site.
  • the VIM 13 at each regional base provides the provided image file to the NFVI 21. Based on the image file, instantiation of the VNF 22 is performed.
  • the VIM 13 (more precisely, the server on which the VIM 13 is installed) arranged at each regional base acquires an image file from the central base. Thereafter, a virtual machine is generated by assigning resources, and an image file is transferred to an HDD (Hard Disk Drive) or the like assigned to the virtual machine, thereby instantiating the VNF 22.
  • HDD Hard Disk Drive
  • the image file used for instantiation of the VNF 22 is developed from the central base to the regional bases scattered throughout the country.
  • the development of the image file takes time and can be a problem in actual operation.
  • the above image file contains data necessary for instantiation of VNF22.
  • the image file includes program data relating to an OS (Operating System), MW (Middleware), and APL (Application) executed in the virtual machine. It is not preferable from the following viewpoint to transmit such a large image file from the central site to the regional site every time the specification of the VNF 22 is changed or the malfunction of the software constituting the VNF 22 is corrected.
  • This viewpoint includes the use efficiency of network resources, the time required for developing an image file, and the like. In particular, in an environment where minor version upgrades of the VNF 22 are frequently performed, the above-described inconvenience becomes more remarkable.
  • An object of the present invention is to provide a network system, a patch file application method, and a recording medium that contribute to efficient deployment of an image file used for VNF instantiation.
  • an NFVI Network Function Virtualization Infrastructure
  • NFVI Network Function Virtualization Infrastructure
  • EMS corresponding to the VNF.
  • NFVO Network Function Virtualization Infrastructure
  • VNFM VNF Manager
  • an NFVI Network Function Virtualization Infrastructure
  • NFVO Network Function Virtualization Infrastructure
  • VNFM VNF Manager
  • a program that is executed by a computer that controls a VNFM (VNF Manager) that manages a life cycle of a virtual network function (VNF) that is implemented by software that operates on a virtual machine. Therefore, a program is provided that causes a patch file used for updating the VNF to be executed by a network function virtualization infrastructure (NFVI) that provides the VNF execution infrastructure.
  • VNFM VNF Manager
  • NFVI network function virtualization infrastructure
  • This program can be recorded on a computer-readable recording medium.
  • the recording medium can be non-transient such as a semiconductor memory, a hard disk, a magnetic recording medium, or an optical recording medium.
  • the present invention can also be embodied as a computer program product.
  • a network system Based on each viewpoint of the present invention, a network system, a patch file application method, and a recording medium that contribute to efficient development of an image file used for instantiation of VNF are provided.
  • FIG. 1 is a diagram for explaining an outline in one embodiment.
  • the network system includes an NFVI 100, an EMS 101, an NFVO 102, and a VNFM 103.
  • the NFVI 100 is implemented based on software that operates on a virtual machine, and provides an execution base for a virtual network function (VNF).
  • the EMS 101 corresponds to VNF.
  • the NFVO 102 implements a network service on the NFVI 100.
  • the VNFM 103 manages the life cycle of the VNF. Any one of the EMS 101, the NFVO 102, and the VNFM 103 provides the NFVI 100 with a patch file used for updating the VNF.
  • the network system directly provides the NFVI 100 with a patch file necessary for changing the VNF from the central base device in which the EMS 101 or the like is arranged. Based on this operation, the image file of a small size is transferred without straddling the device (regional base VIM; not shown in FIG. 1), so that the network system can perform VNF healing or the like that may occur in the network system. The time required can be shortened. That is, in the NFV-MANO that controls the virtual node VNF, it is possible to efficiently deploy the image file (file for starting the VNF) from the NFV-MANO when the VNF patch is applied.
  • FIG. 2 is a diagram illustrating an example of a schematic configuration of the network system according to the first embodiment.
  • a central base 1 and a plurality of regional bases 2-1 to 2-n are included in the network system.
  • the central base 1 and the plurality of regional bases 2-1 to 2-n are connected using a network.
  • the central base 1 includes a server on which functional entities such as the OSS / BSS 30, the EMS 23, the NFVO 11, and the VNFM 12 are mounted.
  • Each of the regional bases 2-1 to 2 -n includes a plurality of physical machines 3-1 to 3 -m (m is a positive integer; hereinafter the same), a server on which the VIM 13 is mounted, a storage server 40, Is included.
  • At least one or more virtual machines can be generated in the physical machine 3 included in the regional base 2.
  • a VNF 22 is instantiated on the virtual machine.
  • the storage server 40 is a server that manages a storage 41 composed of an HDD (Hard Disk Drive) or the like. Data read / write requests to the storage server 40 are made not only from devices included in the regional base 2 (for example, VIM 13), but also from devices included in the central base 1 (for example, EMS 23, NFVO 11, or VNFM 12).
  • the storage 41 is constructed so as to be accessible from the physical machines 3 included in the regional base 2.
  • Boot From Cinder Volume By making at least a part of the storage 41 accessible from the physical machine 3, a so-called Boot From Cinder Volume is realized.
  • the following literature etc. can be referred for the detail of Boot From Cinder Volume. References: “Launching an instance from a volume”, [online] Internet (https://docs.openstack.org/en/user-guide/cli_nova_launch_instance_from_volume.html)
  • the VNFM 12 and the VIM 13 request the storage server 40 to arrange an image file necessary for the instantiation of the VNF 22 in a predetermined area on the storage 41 in order to realize the above Boot Cinder Volume.
  • the network system according to the first embodiment adopts the Boot From Cinder Volume method for instantiation of the VNF 22.
  • the image file is transferred to the storage 41 that is the external storage.
  • FIG. 3 is a block diagram illustrating an example of a hardware configuration of the physical machine 3 according to the first embodiment.
  • the physical machine 3 is a so-called information processing apparatus (computer) and has a configuration illustrated in FIG.
  • the physical machine 3 has the following configuration connected to each other by an internal bus.
  • the configuration includes a CPU (Central Processing Unit) 51, a memory 52, an input / output interface 53, a NIC (Network Interface Card) 54 as a communication means, and the like.
  • the configuration shown in FIG. 3 is not intended to limit the hardware configuration of the physical machine 3.
  • the physical machine 3 may include hardware (not shown).
  • the number of CPUs 51 and the like included in the physical machine 3 is not limited to the example illustrated in FIG.
  • a plurality of CPUs 51 may be included in the physical machine 3.
  • the memory 52 is a RAM (Random Access Memory), a ROM (Read Only Memory), and / or an auxiliary storage device (such as a hard disk).
  • RAM Random Access Memory
  • ROM Read Only Memory
  • auxiliary storage device such as a hard disk
  • the input / output interface 53 is a means to be an interface with a display device and an input device (not shown).
  • the display device is, for example, a liquid crystal display.
  • the input device is a device that accepts user operations such as a keyboard and a mouse, for example.
  • FIG. 4 is a block diagram for explaining the network system according to the first embodiment in terms of functions.
  • VNFM 12 and VIM 13 have the functions (functional blocks) shown in FIG. 4 in addition to the functions described in Non-Patent Documents 1 and 2.
  • the VNFM 12 includes a patch file acquisition unit 201, a patch file registration unit 202, and a VNF activation request unit 203.
  • the patch file acquisition unit 201 is a means for acquiring a patch file to be applied to the VNF 22 from an external device (for example, EMS 23).
  • the image file used for the instantiation of the VNF 22 includes program data related to the OS, MW, and APL (application).
  • the patch file includes only program data related to the application.
  • the patch file registration unit 202 transmits the patch file acquired by the patch file acquisition unit 201 to the storage server 40. At the same time, the patch file registration unit 202 instructs the storage server 40 to rewrite the area corresponding to the application program of the image file stored in the predetermined area of the storage 41 based on the patch file. It should be noted that the decision regarding which area of the storage 41 is to be rewritten by the patch file (instruction to the storage server 40) is made based on the VNF placement destination address information provided from the VIM 13 to be described later and the contents of the patch file. Can do.
  • the VNF placement destination address information includes information in which the identifier of VNF_1 is associated with the head address of the area where the image file for VNF_1 is stored.
  • the patch file registration unit 202 can grasp the address of the APL (application) program in the image file in advance.
  • the VNFM 12 acquires the address where the image file of VNF_1 to which the patch is applied is stored from the VNF placement destination address information. Then, the VNFM 12 instructs the storage server 40 to overwrite the patch file from an address obtained by adding a predetermined offset (an offset calculated from an address related to the application program) from the address.
  • the VNF activation request unit 203 is a means for requesting the VIM 13 to activate the VNF 22 using the image file after the patch file is applied. For example, in the above-described example, if a patch is applied to the image file for VNF_1 in the storage 41, the VNF activation request unit 203 activates VNF_1 while specifying the address where the image file of VNF_1 is stored. Request to the VIM 13 as follows.
  • the VIM 13 includes an image file registration unit 211 and a VNF activation processing unit 212.
  • the image file registration unit 211 is a means for registering the image file of the VNF 22 provided from the NFVO 11 in a predetermined area of the storage 41. Specifically, the image file registration unit 211 provides the image file to the storage server 40 and requests to store the file in the storage 41. The storage server 40 stores the image file in the storage 41 and responds to the VIM 13 (image file registration unit 211) with the address where the image file is stored. The image file registration unit 211 generates VNF placement destination address information by associating the identifier corresponding to the VNF 22 registered in the storage 41 with the address acquired from the storage server 40. The image file registration unit 211 distributes the generated VNF placement destination address information to an entity such as the VNFM 12 or an entity that requires the information, a module, or the like.
  • registering the image file in the storage 41 by the patch file registration unit 202 and the image file registration unit 211 corresponds to providing the NFVI 21 with the image file. This is because the predetermined area of the storage 41 (area where the image file is stored) is configured to be accessible by each physical machine 3 (NFVI 21).
  • the VNF activation processing unit 212 is a means for processing the VNF activation request from the VNFM 12 described above. Specifically, the VNF activation processing unit 212 generates and activates the VNF 22 using the image file after the patch file is applied while designating an address in the storage 41.
  • VNF onboard At the initial startup of the network system, a process of “VNF onboard” and “VNF instantiation” is included.
  • the network system according to the first embodiment performs an operation based on the sequence described in “B.2.1 On-Board VNF Package Flow” on page 104 of Non-Patent Document 1 with respect to “VNF onboard”.
  • VNF instantiation the network system operates in accordance with the sequence described in “B.3.2.2.VNF instantiation from NFVO” on page 116 of the document.
  • the image file shown in FIG. 5 is a file including program data related to the OS, MW, and APL.
  • the NFVO 11 transmits the image file acquired from the EMS 23 to the VIM 13 (step S101).
  • the VIM 13 When the VIM 13 stores the image file in the image repository (Image Repository), the VIM 13 transmits an acknowledgment (ACK) to the NFVO 11 (step S102).
  • ACK acknowledgment
  • the image file When the image file is stored in the image repository, the onboard processing of the VNF 22 is completed.
  • the NFVO 11 requests the VNFM 12 to generate a virtual node (step S201).
  • the VNFM 12 that has received the request requests the VIM 13 to allocate resources (Allocate Resources) (step S202).
  • the VIM 13 allocates the requested resource (step S203). Specifically, the VIM 13 generates and activates a network resource related to the virtual machine at the placement destination of the virtual machine. When the activation ends normally (reception of acknowledgment (ACK) in step S204), the VIM 13 transmits an acknowledgment (ACK) corresponding to the resource allocation request to the VNFM 12 (step S205).
  • ACK acknowledgment
  • the VNFM 12 requests the VIM 13 to start the VNF 22 (step S206).
  • the VIM 13 that has received the request stores the image file in a predetermined area of the storage 41 and then sets a parameter specific to the deployment to activate the VNF 22 (step S207). Specifically, the VIM 13 sets a parameter including an address corresponding to a predetermined area of the storage 41 in which an image file corresponding to the VNF 22 to be instantiated is stored in a virtual machine for which resource allocation has been completed.
  • the VNF 22 is generated and activated from the predetermined area of the storage 41 (step S208).
  • an acknowledgment (ACK) is transmitted from the NFVI 21 to the VIM 13 (step S209).
  • the VIM 13 When the VIM 13 receives the affirmative response (ACK), the VIM 13 transmits an affirmative response (ACK) corresponding to the VNF activation request in step S206 to the VNFM 12 (step S210).
  • the VNFM 12 When receiving the acknowledgment (ACK), the VNFM 12 transmits an acknowledgment (ACK) corresponding to the virtual node generation request in step S201 to the NFVO 11 (step S211).
  • the update of the VNF 22 is realized by applying a patch to the image file of the VNF 22.
  • the update of the VNF 22 is composed of two processes: patch file registration and patch file application. Registration of the patch file is performed using the EMS 23 or the like.
  • Various triggers for applying the patch file can be considered. However, in the first embodiment, a failure occurs in the operating VNF 22, and the recovery (Healing) of the VNF 22 will be described as a trigger for applying the patch file. However, this is not intended to limit the opportunity for updating the VNF 22 to the recovery of the VNF 22.
  • the VNF 22 may be updated when the VNF 22 is scaled out.
  • FIG. 6 is a sequence diagram showing an example of the operation of the network system related to the update of the VNF 22.
  • step S301 the EMS 23 requests the VNFM 12 to apply the patch file.
  • the EMS 23 designates the VNF 22 to be applied with a patch (with an identifier of the VNF 22), and provides the patch file (image file for patch) to the VNFM 12.
  • the VNFM 12 acquires the patch file (step S302), and stores the patch file in a recording medium such as an HDD, and transmits an affirmative response (ACK) to the EMS 23 (step S303).
  • a recording medium such as an HDD
  • the image file used by the operating VNF 22 is stored in a predetermined area of the storage 41. That is, the patch application target VNF 22 is operating in accordance with the image file stored in the predetermined area of the storage 41.
  • step S401 the VIM 13 detects that a failure has occurred (detects a failure) in the operating VNF 22.
  • the VIM 13 notifies the VNFM 12 of the failure occurrence of the VNF 22 (step S402).
  • the VNFM 12 transmits an acknowledgment (ACK) to the notification to the VIM 13 (step S403) and notifies the NFVO 11 that the VNF 22 starts to heal (step S404).
  • ACK acknowledgment
  • the VNFM 12 When the VNFM 12 receives an acknowledgment (ACK) to the notification from the NFVO 11 (step S405), it makes a request to the VIM 13 to delete the failed VNF 22 (step S406).
  • ACK acknowledgment
  • the VIM 13 that has received the request deletes (stops) the failed VNF 22 (step S407).
  • the VIM 13 that has received the affirmative response (ACK) sends an affirmative response (ACK) to the VNFM 12 in response to the VNF 22 deletion request in step S406 (step S410).
  • the VNFM 12 makes a resource allocation request to the VIM 13 (step S411).
  • the VIM 13 allocates the requested resource (step S412). Specifically, the VIM 13 generates and activates a network resource related to the virtual machine at the placement destination of the virtual machine. When the activation ends normally (reception (ACK) reception in step S413), the VIM 13 transmits an acknowledgment (ACK) corresponding to the resource allocation request to the VNFM 12 (step S414).
  • ACK acknowledgment
  • the VNFM 12 that has received the acknowledgment (ACK) instructs the storage server 40 to rewrite a part of the corresponding image file by using the patch file (patch image file) acquired in the patch file registration process. That is, the VNFM 12 that has received the positive response (ACK) registers the patch file in the storage 41 (step S415). Thereafter, the VNFM 12 requests the VIM 13 to start the VNF 22 by applying a patch (step S416). Specifically, the VNFM 12 specifies the VNF 22 to which the patch is applied, and requests the VIM 13 to start the VNF 22.
  • the VIM 13 sets a parameter specific to the deployment including an address corresponding to a predetermined area of the storage 41 in which an image file corresponding to the VNF 22 to be patched is stored in the virtual machine to which the resource is allocated. With this operation, the VIM 13 executes activation of the VNF 22 by applying a patch (step S417).
  • the VNF 22 is generated and activated from the predetermined area of the storage 41 (step S418).
  • an acknowledgment (ACK) is transmitted from the NFVI 21 to the VIM 13 (step S419).
  • the VIM 13 that has received the acknowledgment (ACK) transmits an acknowledgment (ACK) corresponding to the activation request of the VNF 22 by applying the patch in step S416 to the VNFM 12 (step S420).
  • the VNFM 12 transmits a healing completion notification to the NFVO 11 (Step S421) and receives an acknowledgment (ACK) from the NFVO 11 (Step S422), thereby completing the healing process.
  • the configuration and operation of the network system described in the above embodiment are merely examples, and are not intended to limit the configuration of the system.
  • the patch file may be registered in the storage 41 from the EMS 23 or the NFVO 11.
  • any one of the EMS 23, the NFVO 11, and the VNFM 12 may be configured to provide the patch file used for updating the VNF 22 to the NFVI 21 (the patch file is provided to the NFVI 21 without passing through the VIM 13).
  • any one of the EMS 23, the NFVO 11, and the VNFM 12 may provide the patch file to the NFVI 21 and rewrite the corresponding area of the storage allocated to the virtual machine by the NFVI 21. That is, any one of the EMS 23, the NFVO 11, and the VNFM 12 may directly provide the patch file used for updating the VNF 22 to the NFVI 21 without using the storage server 40 (storage 41).
  • the image file including the program data such as OS, MW, or APL is stored in the VIM 13 at the time of major version upgrade such as when the OS is changed. It expands to VNF22 via.
  • the network system according to the above-described embodiment operates as follows at the time of a minor version upgrade at the time of applying a patch that is frequently performed. That is, the network system transfers a partial image file (patch file) limited to the patch application location (for example, only application data) directly from the device at the central site 1 (for example, EMS 23 or VNFM 12) to the VNF 22 directly.
  • FIG. 7 shows an example of image file transfer paths at the time of major version upgrade and minor version upgrade.
  • the patch file is directly developed on the VNF 22 from the device at the central site 1 so that a small-size image file is transferred without straddling the device (the server on which the VIM 13 is mounted). Therefore, the network system can shorten the time required for the healing of the VNF 22 that may occur in the network system. That is, in the first embodiment, since small-sized file transfer that occurs frequently without using the VIM 13 can be realized, efficient operation of the network system can be realized.
  • instantiation of the VNF 22 is realized by using the Boot From Cinder Volume method. Therefore, in the first embodiment, it is not necessary to directly transfer the image file to the physical machine 3 (NFVI 21), and the image file may be transferred to the external storage, and the instantiation of the VNF 22 can be made efficient. It should be noted that an efficient operation of the network system cannot be realized simply by adopting the Boot From Cinder Volume method and deploying the patch file to the VNF 22 via the VIM 13. This is because even if the technology is adopted, the image file is not changed from the central base 1 to all the regional bases 2.
  • Non-Patent Document 1 does not describe activation of VNF 22 using a patch file.
  • Non-Patent Document 1 only describes that when the VNF 22 is updated, an image file including the OS, MW, or APL is provided to the VIM 13 and the VNF 22 is activated (instantiated). (For example, see “B.2.4. Update VNF Package flow” on page 106 of the same document.)
  • each device illustrated in FIG. 4 and the like can be realized based on a computer program that causes a computer mounted on each device to execute each processing described above using its hardware. That is, some or all of each means may be realized based on a program executed by a computer (processor or the like), and the functions performed by each processing module described above may be realized by some hardware and / or software. Any means can be used.
  • the present invention is suitably applied to a system that requires advance reservation of necessary resources of a system that requires 24 hours of non-stop operation without affecting the end user as in the case of non-virtualization, such as a virtualized communication server (VNF22). Is possible. Alternatively, the present invention can be suitably applied to a system that requires simplification of maintenance work and scenario execution in various virtual servers (VNFs 22).
  • [Appendix 1] The network system according to the first aspect described above.
  • [Appendix 2] Further includes VIM (Virtualized Infrastructure Manager) that performs resource management and control of NFVI, Any one of EMS, NFVO and VNFM that provides the patch file to NFVI provides the patch file to NFVI without going through VIM.
  • NFVO is a file used for instantiation of VNF, and provides VIM with an image file including program data related to an operating system, middleware, or application, VIM provides image files to NFVI, The network system according to attachment 2.
  • a storage server for managing externally accessible storage VIM provides the image file to the storage server, The storage server stores the provided image file in a predetermined area of the storage, The VIM activates the VNF using an image file stored in a predetermined area of the storage.
  • the network system according to attachment 3. Any one of EMS, NFVO, and VNFM that provides the patch file to NFVI instructs the storage server to rewrite a part of a predetermined area in which the image file is stored with the patch file.
  • the VNFM requests the VIM to start VNF using the image file partially rewritten after the rewriting of the image file based on the patch file is completed.
  • the network system according to appendix 5 When healing VNF, part of the image file based on the patch file is rewritten, and VNF is activated using the partly rewritten image file.
  • the patch file includes the program data related to the application among the program data included in the image file.
  • Appendix 9 This is the same as the patch file application method according to the second viewpoint described above.
  • Appendix 10 It is as the program which concerns on the above-mentioned 3rd viewpoint. Note that the form of supplementary note 9 and the form of supplementary note 10 can be expanded to the form of supplementary note 2 to the form of supplementary note 8, similarly to the form of supplementary note 1.

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 Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

ＶＮＦのインスタンシエーションに使用されるイメージファイルの効率的な展開に寄与するネットワークシステムを提供するため、本発明のネットワークシステムは、仮想マシン上で動作するソフトウェアによって実装され仮想されたＶＮＦ（Virtual Network Function）の実行基盤を提供するＮＦＶＩと、ＶＮＦに対応するＥＭＳと、ＮＦＶＩの上にて、ネットワークサービスを実現するＮＦＶＯと、ＶＮＦのライフサイクルを管理するＶＮＦＭとを含み、ＥＭＳ、ＮＦＶＯ及びＶＮＦＭのいずれか１つが、ＶＮＦの更新に用いるパッチファイルをＮＦＶＩに提供する。

Description

ネットワークシステム、パッチファイル適用方法、及び記録媒体
　本発明は、ネットワークシステム、パッチファイル適用方法、及び記録媒体に関する。
　ＮＦＶ（Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎｓ　Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）が知られている（例えば、非特許文献１、２参照）。ＮＦＶとは、ネットワーク機器等の機能をソフトウェア的に実現するものである。ＮＦＶは、サーバ上のハイパーバイザ（ＨｙｐｅｒＶｉｓｏｒ：ＨＶ）等の仮想化レイヤ（Ｖｉｒｔｕａｌｉｚａｔｉｏｎ　Ｌａｙｅｒ）上に実装した仮想マシン（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ：ＶＭ）を用いて実現する。
　図８は、非特許文献２の７章、Figure 4を簡略した図面であり、図８を用いてＶＮＦ環境のネットワーク構成の概略を説明する。
　ＶＮＦ（Ｖｉｒｔｕａｌｉｚｅｄ　Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎ）２２は、サーバ上の仮想マシン（ＶＭ）で動作するアプリケーション等に対応し、ネットワーク機能をソフトウェア的に実現する。ＶＮＦ２２ごとにＥＭＳ（Ｅｌｅｍｅｎｔ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）２３という管理機能が設けられる。ＥＭＳ２３は、管理要素（ＥＭ：Ｅｌｅｍｅｎｔ　Ｍａｎａｇｅｒ）とも呼ばれる。
　ＮＦＶＩ（Ｎｅｔｗｏｒｋ　Ｆｕｎｃｔｉｏｎｓ　Ｖｉｒｔｕａｌｉｚａｔｉｏｎ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）２１は、ハードウェア資源を、仮想化ハードウェア資源として柔軟に扱えるようにした基盤である。ハードウェア資源とは、コンピューティング、ストレージ、ネットワーク機能、又は、物理マシン（サーバ）等である。仮想化ハードウェア資源は、ハイパーバイザ等の仮想化レイヤで仮想化した仮想化コンピューティング、仮想化ストレージ、又は仮想化ネットワーク等である。
　ＮＦＶ－ＭＡＮＯ（ＮＦＶ　Ｍａｎａｇｅｍｅｎｔ　＆　Ｏｒｃｈｅｓｔｒａｔｉｏｎ）１０のＮＦＶオーケストレータ（ＮＦＶ　Ｏｒｃｈｅｓｔｒａｔｏｒ：ＮＦＶＯ）１１は、次のような処理を行う。この処理とは、ＮＦＶＩ２１のリソースのオーケストレーション、及び、ネットワークサービス（Ｎｅｔｗｏｒｋ　Ｓｅｒｖｉｃｅ：ＮＳ）インスタンスのライフサイクル管理である。なお、ＮＳインスタンスとは、ＮＳインスタンスのインスタンシエーション（Ｉｎｓｔａｎｔｉａｔｉｏｎ）、スケーリング（Ｓｃａｌｉｎｇ）、ターミネーション（Ｔｅｒｍｉｎａｔｉｏｎ）、及び更新（Ｕｐｄａｔｅ）等である。
　ＶＮＦマネージャ（ＶＮＦ　Ｍａｎａｇｅｒ：ＶＮＦＭ）１２は、ＶＮＦインスタンスのライフサイクル管理、及びイベント通知を行う。ＶＮＦインスタンスのライフサイクル管理とは、例えば、インスタンシエーション（ｉｎｓｔａｎｔｉａｔｉｏｎ）、更新（ｕｐｄａｔｅ）、クエリ（ｑｕｅｒｙ）、スケーリング（ｓｃａｌｉｎｇ）、停止（ｔｅｒｍｉｎａｔｉｏｎ）である。
　仮想化インフラストラクチャマネージャ（Ｖｉｒｔｕａｌｉｚｅｄ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　Ｍａｎａｇｅｒ：ＶＩＭ）１３は、次のような処理を実行する。この処理とは、ＮＦＶＩ２１のコンピューティング、ストレージ、ネットワークのリソース管理、ＮＦＶＩ２１の障害監視、及び、ＮＦＶＩ２１のリソース監視等である。
　ＯＳＳ／ＢＳＳ３０のうちＯＳＳ（Ｏｐｅｒａｔｉｏｎｓ　Ｓｕｐｐｏｒｔ　Ｓｙｓｔｅｍｓ）は、例えば、通信事業者（キャリア）がサービスを構築し、運営していくために必要なシステム（機器やソフトウェア、仕組みなど）を総称したものである。ＢＳＳ（Ｂｕｓｉｎｅｓｓ　Ｓｕｐｐｏｒｔ　ｓｙｓｔｅｍｓ）は、例えば、通信事業者（キャリア）が利用料などの課金、請求、顧客対応などのために使う情報システム（機器やソフトウェア、仕組みなど）の総称である。
　なお、本発明に関連する文献としては、特許文献１及び２がある。特許文献１は、ＮＦＶなどに関連する技術を開示している。特許文献２は、クライアント端末を管理するためのイメージファイルに関連する技術を開示している。
特開２０１５－１９４９４９号公報 特開２０１３－１８６７９３号公報
ETSI GS NFV-MAN 001 V1.1.1 (2014-12)、 "Network Functions Virtualisation (NFV); Management and Orchestration"、 [online]、［２０１６年４月５日検索］、インターネット（URL:http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf） ETSI GS NFV 002 V1.2.1 (2014-12)、"Network Functions Virtualisation (NFV); Architectural Framework"、［online］、［２０１６年４月８日検索］、インターネット（URL:http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf）
　なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。
　上述したＮＦＶＯ１１、ＶＮＦＭ１２、及びＶＩＭ１３等は、ネットワークシステムを管理するための機能エンティティである。これらの機能エンティティの制御に従って、物理マシン（Ｐｈｙｓｉｃａｌ　Ｍａｃｈｉｎｅ：ＰＭ）上に仮想マシン及びＶＮＦが生成される。
　図９に示すように、物理マシンは、ネットワークシステムの一部をなす地域拠点に複数まとめて配置されている。ＶＩＭ１３は、当該複数の物理マシンに対応して配置される。また、ＯＳＳ／ＢＳＳ３０等のサービス支援機構、並びに、ＮＦＶＯ１１及びＶＮＦＭ１２等の管理機構は、中央拠点に集約されていることが多い。中央拠点に集約された管理機構は、複数の地域拠点（複数のＶＩＭ）に跨がる全体の資源管理等を行う。
　図９に示すようなＶＮＦ環境のネットワークシステムにおいて、ＶＮＦ２２のインスタンシエーションに必要なイメージファイルは、中央拠点のＮＦＶＯ１１から地域拠点のＶＩＭ１３に提供される。各地域拠点のＶＩＭ１３は、当該提供されたイメージファイルをＮＦＶＩ２１に提供する。そして、当該イメージファイルに基づいて、ＶＮＦ２２のインスタンシエーションが行われる。
　より具体的には、図１０に示すように、各地域拠点に配置されたＶＩＭ１３（より正確には、ＶＩＭ１３が実装されたサーバ）が、中央拠点からイメージファイルを取得する。その後、リソースの割当てが行われることで仮想マシンが生成され、当該仮想マシンに割り当てられたＨＤＤ（Hard Disk Drive）等にイメージファイルが転送されることで、ＶＮＦ２２のインスタンシエーションが行われる。
　このように、ＶＮＦ２２のインスタンシエーションに使用されるイメージファイルは、中央拠点から全国に点在する地域拠点に展開されるものである。ただし、イメージファイルの展開は、時間が掛かり、実運用上の問題点となり得る。
　上記イメージファイルは、ＶＮＦ２２のインスタンシエーションに必要なデータを含むものである。具体的には、上記イメージファイルは、仮想マシンにて実行されるＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）、ＭＷ（Ｍｉｄｄｌｅｗａｒｅ）、及び、ＡＰＬ（Ａｐｐｌｉｃａｔｉｏｎ）に係るプログラムデータを含むものである。このようなサイズの大きいイメージファイルを、ＶＮＦ２２の仕様変更又はＶＮＦ２２をなすソフトウェアの不具合修正のたびに、中央拠点から地域拠点に送信することは、次のような観点から好ましくない。この観点とは、ネットワークリソースの利用効率及びイメージファイルの展開に要する時間等である。とりわけ、ＶＮＦ２２のマイナーバージョンアップが頻繁に行われるような環境では、上記のような不都合がより顕著となる。
　本発明は、ＶＮＦのインスタンシエーションに使用されるイメージファイルの効率的な展開に寄与する、ネットワークシステム、パッチファイル適用方法、及び記録媒体を提供することを目的とする。
　本発明の第１の視点によれば、仮想マシン上で動作するソフトウェアによって実装され仮想されたＶＮＦ（Virtual Network Function）の実行基盤を提供するＮＦＶＩ（Network Function Virtualization Infrastructure）と、ＶＮＦに対応するＥＭＳ（Element Management System）と、ＮＦＶＩの上にて、ネットワークサービスを実現するＮＦＶＯ（NFV Orchestrator）と、ＶＮＦのライフサイクルを管理するＶＮＦＭ（VNF Manager）とを含み、ＥＭＳ、ＮＦＶＯ及びＶＮＦＭのいずれか１つが、ＶＮＦの更新に用いるパッチファイルをＮＦＶＩに提供する、ネットワークシステムが提供される。
　本発明の第２の視点によれば、仮想マシン上で動作するソフトウェアによって実装され仮想されたＶＮＦ（Virtual Network Function）の実行基盤を提供するＮＦＶＩ（Network Function Virtualization Infrastructure）と、ＶＮＦに対応するＥＭＳ（Element Management System）と、ＮＦＶＩの上にて、ネットワークサービスを実現するＮＦＶＯ（NFV Orchestrator）と、ＶＮＦのライフサイクルを管理するＶＮＦＭ（VNF Manager）とを含むネットワークシステムにおいて、ＥＭＳ、ＮＦＶＯ及びＶＮＦＭのいずれか１つにより、ＶＮＦの更新に用いるパッチファイルがＮＦＶＩに提供され、提供されたパッチファイルを使用したＶＮＦのインスタンシエーションが実行する、パッチファイル適用方法が提供される。
　本発明の第３の視点によれば、仮想マシン上で動作するソフトウェアによって実装され仮想されたＶＮＦ（Virtual Network Function）のライフサイクルを管理するＶＮＦＭ（VNF Manager）を制御するコンピュータに実行させるプログラムであって、ＶＮＦの更新に用いるパッチファイルを、ＶＮＦの実行基盤を提供するＮＦＶＩ（Network Function Virtualization Infrastructure）に提供する処理を実行させる、プログラムが提供される。
　なお、このプログラムは、コンピュータ読み取り可能な記録媒体に記録することができる。記録媒体は、半導体メモリ、ハードディスク、磁気記録媒体、又は光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
　本発明の各視点に基づけば、ＶＮＦのインスタンシエーションに使用されるイメージファイルの効率的な展開に寄与する、ネットワークシステム、パッチファイル適用方法、及び記録媒体が、提供される。
一実施形態の概要を説明するための図である。 第１の実施形態に係るネットワークシステムの概略構成の一例を示す図である。 第１の実施形態に係る物理マシンのハードウェア構成の一例を示すブロック図である。 第１の実施形態に係るネットワークシステムを機能の点で説明するためのブロック図である。 第１の実施形態に係るネットワークシステムの動作の一例を示す図である。 ＶＮＦの更新に関するネットワークシステムの動作の一例を示すシーケンス図である。 第１の実施形態に係るイメージファイルの展開を説明するための図である。 非特許文献２の７章、Figure ４を簡略した図面である。 ＶＮＦ環境のネットワークシステムの構成の一例を示す図である。 イメージファイルの展開を説明するための図である。
　初めに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものである。この概要の記載は、何らの限定を意図するものではない。
　図１は、一実施形態に概要を説明するための図である。
　一実施形態に係るネットワークシステムは、ＮＦＶＩ１００と、ＥＭＳ１０１と、ＮＦＶＯ１０２と、ＶＮＦＭ１０３とを含む。ＮＦＶＩ１００は、仮想マシン上で動作するソフトウェアに基づいて実装され、かつ、仮想されたネットワーク機能（Virtual Network Function:ＶＮＦ）の実行基盤を提供する。ＥＭＳ１０１は、ＶＮＦに対応する。ＮＦＶＯ１０２は、ＮＦＶＩ１００上にて、ネットワークサービスを実現する。ＶＮＦＭ１０３は、ＶＮＦのライフサイクルを管理する。ＥＭＳ１０１、ＮＦＶＯ１０２及びＶＮＦＭ１０３のいずれか１つが、ＶＮＦの更新に用いるパッチファイルをＮＦＶＩ１００に提供する。
　上記実施形態に係るネットワークシステムは、ＥＭＳ１０１等が配置された中央拠点の装置から、ＶＮＦの変更に必要なパッチファイルを直接、ＮＦＶＩ１００に提供する。この動作を基に、小さいサイズのイメージファイルが装置（地域拠点のＶＩＭ；図１に図示せず）を跨がずに転送されるので、ネットワークシステムは、ネットワークシステムに生じうるＶＮＦのヒーリング等に要する時間を短縮することができる。つまり、仮想化されたノードであるＶＮＦを制御するＮＦＶ－ＭＡＮＯにおいて、ＶＮＦパッチ適用時にイメージファイル（ＶＮＦを起動するためのファイル）をＮＦＶ－ＭＡＮＯから効率的に展開することが実現できる。換言するならば、高い頻度で発生するパッチ適用時のマイナーバージョンアップ時は、パッチ適用箇所に限った部分的な（例えば、アプリケーションデータだけの）イメージファイルがＥＭＳ１０１及びＶＮＦＭ１０３経由で直接ＶＮＦに展開される。この動作で、運用効率を向上させることが可能となる。
　以下に、具体的な実施の形態について、図面を参照して、さらに詳しく説明する。なお、同一構成要素には同一の符号を付し、その説明を省略する。
　［第１の実施形態］
　第１の実施形態について、図面を用いて、より詳細に説明する。
　図２は、第１の実施形態に係るネットワークシステムの概略構成の一例を示す図である。図２を参照すると、中央拠点１と、複数の地域拠点２－１～２－ｎ（ｎは正の整数。以下、同じ）とが、ネットワークシステムに含まれる。中央拠点１と複数の地域拠点２－１～２－ｎは、ネットワークを用いて接続されている。
　中央拠点１には、ＯＳＳ／ＢＳＳ３０、ＥＭＳ２３、ＮＦＶＯ１１、及びＶＮＦＭ１２等の各機能エンティティが実装されたサーバが含まれる。地域拠点２－１～２－ｎのそれぞれには、複数の物理マシン３－１～３－ｍ（ｍは正の整数。以下、同じ）と、ＶＩＭ１３が実装されたサーバと、ストレージサーバ４０とが、含まれる。
　なお、以降の説明において、地域拠点２－１～２－ｎを区別する特段の理由がない場合には、単に「地域拠点２」と表記する。同様に、物理マシン３－１～３－ｍを区別する特段の理由がない場合には、単に「物理マシン３」と表記する。
　地域拠点２に含まれる物理マシン３には、少なくとも１以上の仮想マシンが生成可能である。当該仮想マシン上に、ＶＮＦ２２が、インスタンシエーションされる。
　ストレージサーバ４０は、ＨＤＤ（Hard Disk Drive）等からなるストレージ４１を管理するサーバである。ストレージサーバ４０に対するデータの読み書き要求は、地域拠点２に含まれる装置（例えば、ＶＩＭ１３等）だけでなく、中央拠点１に含まれる装置（例えば、ＥＭＳ２３、ＮＦＶＯ１１、又はＶＮＦＭ１２等）からも行われる。また、ストレージ４１は、地域拠点２に含まれる物理マシン３からアクセス可能に構築されている。
　ストレージ４１の少なくとも一部が物理マシン３からアクセス可能とすることで、いわゆる、Ｂｏｏｔ　Ｆｒｏｍ　Ｃｉｎｄｅｒ　Ｖｏｌｕｍｅが実現される。なお、Ｂｏｏｔ　Ｆｒｏｍ　Ｃｉｎｄｅｒ　Ｖｏｌｕｍｅの詳細は、以下の文献等を参考にすることができる。
参考文献：「ボリュームからのインスタンスの起動」、［online］インターネット（https://docs.openstack.org/ja/user-guide/cli_nova_launch_instance_from_volume.html）
　ＶＮＦ２２のインスタンシエーションにおけるＢｏｏｔ　Ｆｒｏｍ　Ｃｉｎｄｅｒ　Ｖｏｌｕｍｅを実現するために、ルートディスクがストレージ４１上の所定領域（予め定めた領域）にマウントされる仮想ノードが生成される。
　ＶＮＦＭ１２及びＶＩＭ１３は、上記Ｂｏｏｔ　Ｆｒｏｍ　Ｃｉｎｄｅｒ　Ｖｏｌｕｍｅを実現するため、ＶＮＦ２２のインスタンシエーションに必要なイメージファイルをストレージ４１上の所定領域に配置するように、ストレージサーバ４０に依頼する。このように、第１の実施形態に係るネットワークシステムは、ＶＮＦ２２のインスタンシエーションにＢｏｏｔ　Ｆｒｏｍ　Ｃｉｎｄｅｒ　Ｖｏｌｕｍｅ方式を採用する。そして、ネットワークシステムには、仮想マシンに割当て可能なハードウェア資源とは異なる資源（仮想マシンに割当てされない外部ストレージ）が存在する。そして、当該外部ストレージであるストレージ４１上にイメージファイルが転送される。
　［ハードウェア構成］
　図３は、第１の実施形態に係る物理マシン３のハードウェア構成の一例を示すブロック図である。物理マシン３は、いわゆる、情報処理装置（コンピュータ）であり、図３に例示する構成を備える。例えば、物理マシン３は、内部バスにより相互に接続される次の構成を備える。その構成とは、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）５１、メモリ５２、入出力インターフェイス５３、及び通信手段であるＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）５４等である。
　なお、図３に示す構成は、物理マシン３のハードウェア構成を限定する趣旨ではない。物理マシン３は、図示しないハードウェアを含んでもよい。あるいは、物理マシン３に含まれるＣＰＵ５１等の数は、図３の例示に限定する趣旨ではない。例えば、複数のＣＰＵ５１が、物理マシン３に含まれていてもよい。
　メモリ５２は、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、及び／又は補助記憶装置（ハードディスク等）である。
　入出力インターフェイス５３は、図示しない表示装置及び入力装置とのインターフェイスとなる手段である。表示装置は、例えば、液晶ディスプレイである。入力装置は、例えば、キーボード及びマウスのようにユーザ操作を受け付ける装置である。
　なお、中央拠点１及び地域拠点２に含まれる他のサーバのハードウェア構成は、上記物理マシン３の構成と基本的に同じであり、当業者にとって明らかなものであるため、その説明を省略する。
　図４は、第１の実施形態に係るネットワークシステムを機能の点で説明するためのブロック図である。図４を参照すると、ＶＮＦＭ１２及びＶＩＭ１３は、非特許文献１及び２に記載された機能に加え、図４に示す機能（機能ブロック）を備える。
　具体的には、ＶＮＦＭ１２は、パッチファイル取得部２０１と、パッチファイル登録部２０２と、ＶＮＦ起動要求部２０３とを備える。
　パッチファイル取得部２０１は、外部装置（例えば、ＥＭＳ２３）からＶＮＦ２２に適用するパッチファイルを取得する手段である。なお、上述のように、ＶＮＦ２２のインスタンシエーションに使用されるイメージファイルには、ＯＳ、ＭＷ、及びＡＰＬ（アプリケーション）に係るプログラムデータが含まれるものである。ただし、パッチファイルには、アプリケーションに関するプログラムデータに限り含まれるものとする。ただし、パッチファイルに含まれるプログラムデータを限定する趣旨ではなく、例えば、ＯＳに係るプログラムにパッチを適用する場合は、ＯＳに係るプログラムデータの全部又は一部がパッチファイルに含まれていてもよい。
　パッチファイル登録部２０２は、パッチファイル取得部２０１が取得したパッチファイルをストレージサーバ４０に送信する。それとともに、パッチファイル登録部２０２は、ストレージサーバ４０に、当該パッチファイルに基づいてストレージ４１の所定領域に格納されているイメージファイルのアプリケーションプログラムに相当する領域を書き換えるように指示する。なお、ストレージ４１のいずれの領域をパッチファイルにより書き換えるかに関する決定（ストレージサーバ４０への指示）は、後述するＶＩＭ１３から提供されるＶＮＦ配置先アドレス情報と、パッチファイルの内容とに基づき、定めることができる。
　例えば、図４において、ストレージ４１の所定領域にＶＮＦ＿１用のイメージファイルが格納されている場合には、次のとおりとなる。すなわち、上記ＶＮＦ配置先アドレス情報には、ＶＮＦ＿１の識別子とＶＮＦ＿１用のイメージファイルが格納されている領域の先頭アドレスとが対応付けられた情報が含まれる。また、パッチファイルがＡＰＬ（アプリケーション）の書換えを意図したものである場合には、パッチファイル登録部２０２は、イメージファイルにおけるＡＰＬ（アプリケーション）プログラムのアドレスを、事前に、把握可能である。ＶＮＦＭ１２は、ＶＮＦ配置先アドレス情報から、パッチ適用するＶＮＦ＿１のイメージファイルが格納されているアドレスを取得する。そして、ＶＮＦＭ１２は、当該アドレスから所定のオフセット（アプリケーションプログラムに係るアドレスから算出されるオフセット）を加えたアドレスからパッチファイルを上書きするように、ストレージサーバ４０に指示する。
　ＶＮＦ起動要求部２０３は、ＶＩＭ１３に対し、パッチファイルが適用された後のイメージファイルを用いてＶＮＦ２２を起動するように要求する手段である。例えば、上述の例では、ストレージ４１のＶＮＦ＿１用のイメージファイルにパッチを適用したのであれば、ＶＮＦ起動要求部２０３は、ＶＮＦ＿１のイメージファイルが格納されているアドレスを指定しつつ、ＶＮＦ＿１を起動するようにＶＩＭ１３に要求する。
　ＶＩＭ１３は、イメージファイル登録部２１１と、ＶＮＦ起動処理部２１２とを備える。
　イメージファイル登録部２１１は、ＮＦＶＯ１１から提供されたＶＮＦ２２のイメージファイルをストレージ４１の所定領域に登録する手段である。具体的には、イメージファイル登録部２１１は、イメージファイルをストレージサーバ４０に提供するとともに、当該ファイルをストレージ４１に格納することを依頼する。ストレージサーバ４０は、イメージファイルをストレージ４１に格納するとともに、当該イメージファイルを格納したアドレスをＶＩＭ１３（イメージファイル登録部２１１）に応答する。イメージファイル登録部２１１は、ストレージ４１に登録したＶＮＦ２２に対応する識別子とストレージサーバ４０から取得した上記アドレスとを対応付けて、ＶＮＦ配置先アドレス情報を生成する。イメージファイル登録部２１１は、生成したＶＮＦ配置先アドレス情報をＶＮＦＭ１２等の当該情報を必要とするエンティティ、又はモジュール等に配布する。
　なお、パッチファイル登録部２０２及びイメージファイル登録部２１１がイメージファイルをストレージ４１に登録することは、ＮＦＶＩ２１にイメージファイルを提供することに相当する。ストレージ４１の所定領域（イメージファイルが格納されている領域）は、各物理マシン３（ＮＦＶＩ２１）がアクセス可能に構成されているためである。
　ＶＮＦ起動処理部２１２は、上述のＶＮＦＭ１２からのＶＮＦ起動要求を処理する手段である。具体的には、ＶＮＦ起動処理部２１２は、ストレージ４１におけるアドレスを指定しつつ、パッチファイルが適用された後のイメージファイルを用いてＶＮＦ２２を生成し、起動する。
　［ネットワークシステムの動作］
　次に、図面を参照しつつ、第１の実施形態に係るネットワークシステムの動作を説明する。
　初めに、ネットワークシステムの初期起動時におけるＶＮＦ２２のインスタンシエーションに関する説明を行う。
　ネットワークシステムの初期起動時には、「ＶＮＦのオンボード」と「ＶＮＦのインスタンシエーション」のプロセスが含まれる。第１の実施形態に係るネットワークシステムは、「ＶＮＦのオンボード」に関し、非特許文献１の１０４ページ「B.2.1 On-Board VNF Package Flow」に記載されたシーケンスに準拠した動作を行う。また、「ＶＮＦのインスタンシエーション」に関しては、ネットワークシステムは、同文献の１１６ページ「B.3.2.2 VNF instantiation from NFVO」に記載されたシーケンスに準拠した動作を行う。
　ここでは、上記２つのシーケンスに関し、図５を参照しつつ、その概略を説明する。なお、図５に示すイメージファイルは、ＯＳ、ＭＷ、ＡＰＬに関するプログラムデータを含むファイルである。
　ＮＦＶＯ１１は、例えば、ＥＭＳ２３から取得したイメージファイルをＶＩＭ１３に送信する（ステップＳ１０１）。
　ＶＩＭ１３は、当該イメージファイルをイメージリポジトリ（Image Repository）に格納すると、肯定応答（ＡＣＫ）をＮＦＶＯ１１に送信する（ステップＳ１０２）。イメージファイルがイメージリポジトリに格納されると、ＶＮＦ２２のオンボード処理が完了する。
　ＶＮＦインスタンシエーションの開始に当たり、ＮＦＶＯ１１は、ＶＮＦＭ１２に対し、仮想ノードの生成を要求する（ステップＳ２０１）。
　当該要求を受けたＶＮＦＭ１２は、ＶＩＭ１３にリソース割当て（Ａｌｌｏｃａｔｅ　Ｒｅｓｏｕｒｃｅｓ）を要求する（ステップＳ２０２）。
　ＶＩＭ１３は、要求されたリソースの割当てを行う（ステップＳ２０３）。具体的には、ＶＩＭ１３は、仮想マシンの配置先において、仮想マシンと関連するネットワークリソースを生成、及び起動する。当該起動が正常に終了すると（ステップＳ２０４による肯定応答（ＡＣＫ）の受信）、ＶＩＭ１３は、ＶＮＦＭ１２にリソース割当て要求に対応する肯定応答（ＡＣＫ）を送信する（ステップＳ２０５）。
　その後、ＶＮＦＭ１２は、ＶＩＭ１３に対してＶＮＦ２２の起動を要求する（ステップＳ２０６）。当該要求を受けたＶＩＭ１３は、イメージファイルをストレージ４１の所定領域に格納した後に、ディプロイメントに固有のパラメータを設定することで、ＶＮＦ２２を起動する（ステップＳ２０７）。具体的には、ＶＩＭ１３は、インスタンシエーションを行うＶＮＦ２２に対応するイメージファイルが格納されているストレージ４１の所定領域に対応するアドレスを含むパラメータを、リソースの割当てが完了した仮想マシンに設定する。
　上記固有のパラメータの設定に基づいて、上記ストレージ４１の所定領域からのＶＮＦ２２の生成、及び起動が行われる（ステップＳ２０８）。ＶＮＦ２２の起動が正常終了すると、ＮＦＶＩ２１からＶＩＭ１３に対して肯定応答（ＡＣＫ）が送信される（ステップＳ２０９）。
　ＶＩＭ１３は、当該肯定応答（ＡＣＫ）を受信すると、ステップＳ２０６におけるＶＮＦ起動要求に対応する肯定応答（ＡＣＫ）をＶＮＦＭ１２に送信する（ステップＳ２１０）。ＶＮＦＭ１２は、当該肯定応答（ＡＣＫ）を受信すると、ステップＳ２０１における仮想ノード生成要求に対応する肯定応答（ＡＣＫ）をＮＦＶＯ１１に送信する（ステップＳ２１１）。
　以上のステップにより、ＶＮＦ２２のインスタンシエーションが完了する。
　次に、ＶＮＦ２２の更新に関する動作を説明する。
　ＶＮＦ２２の更新は、ＶＮＦ２２のイメージファイルにパッチを適用することで実現される。ＶＮＦ２２の更新は、パッチファイルの登録とパッチファイルの適用という２つのプロセスから構成される。パッチファイルの登録は、ＥＭＳ２３等を用いて行われる。また、パッチファイルの適用を開始する契機は種々のものが考えられる。ただし、第１の実施形態では、稼働中のＶＮＦ２２に障害が発生し、ＶＮＦ２２の回復（Ｈｅａｌｉｎｇ）をパッチファイル適用の契機として説明する。ただし、これは、ＶＮＦ２２の更新に関する契機をＶＮＦ２２の回復に限定する趣旨ではない。例えば、ＶＮＦ２２のスケールアウト時にＶＮＦ２２の更新が行われてもよい。
　図６は、ＶＮＦ２２の更新に関するネットワークシステムの動作の一例を示すシーケンス図である。
　ステップＳ３０１において、ＥＭＳ２３からＶＮＦＭ１２に対して、パッチファイルを適用する旨の要求がなされる。その際、ＥＭＳ２３は、パッチ適用するＶＮＦ２２を指定して（ＶＮＦ２２の識別子を伴って）、パッチファイル（パッチ用のイメージファイル）をＶＮＦＭ１２に提供する。
　ＶＮＦＭ１２は、当該パッチファイルを取得し（ステップＳ３０２）、ＨＤＤ等の記録媒体にパッチファイルを格納すると、ＥＭＳ２３に肯定応答（ＡＣＫ）を送信する（ステップＳ３０３）。
　上記ステップで、パッチファイルの登録が完了する。
　なお、パッチファイルが登録された時点では、稼働中のＶＮＦ２２が使用するイメージファイルは、ストレージ４１の所定領域に格納されている。つまり、ストレージ４１の所定領域に格納されたイメージファイルに従って、パッチ適用対象のＶＮＦ２２は稼働している。
　パッチファイルの登録が完了した状態にて、稼働中のＶＮＦ２２、又はＮＦＶＩ２１に障害が発生すると、ＶＮＦ２２のヒーリングが開始する。
　ステップＳ４０１において、ＶＩＭ１３は、稼働中のＶＮＦ２２に障害が発生（障害を検知）したことを検出する。
　ＶＩＭ１３は、ＶＮＦ２２の障害発生をＶＮＦＭ１２に通知する（ステップＳ４０２）。
　ＶＮＦＭ１２は、上記通知に対する肯定応答（ＡＣＫ）をＶＩＭ１３に送信（ステップＳ４０３）するとともに、ＮＦＶＯ１１にＶＮＦ２２のヒーリングを開始する旨を通知する（ステップＳ４０４）。
　ＶＮＦＭ１２は、ＮＦＶＯ１１から上記通知に対する肯定応答（ＡＣＫ）を受信すると（ステップＳ４０５）、障害が発生したＶＮＦ２２を削除する要求をＶＩＭ１３に行う（ステップＳ４０６）。
　当該要求を受けたＶＩＭ１３は、障害の発生したＶＮＦ２２の削除（停止）を行う（ステップＳ４０７）。
　障害の発生したＶＮＦ２２が削除（停止）されると（ステップＳ４０８）、ＶＩＭ１３に対して肯定応答（ＡＣＫ）が送信される（ステップＳ４０９）。
　上記肯定応答（ＡＣＫ）を受信したＶＩＭ１３は、ＶＮＦＭ１２に対し、ステップＳ４０６のＶＮＦ２２の削除要求に対する肯定応答（ＡＣＫ）を行う（ステップＳ４１０）。
　次に、ＶＮＦＭ１２は、ＶＩＭ１３に対して、リソースの割当て要求を行う（ステップＳ４１１）。
　ＶＩＭ１３は、要求されたリソースの割当てを行う（ステップＳ４１２）。具体的には、ＶＩＭ１３は、仮想マシンの配置先において、仮想マシンと関連するネットワークリソースを生成、及び起動する。当該起動が正常に終了すると（ステップＳ４１３による肯定応答（ＡＣＫ）の受信）、ＶＩＭ１３は、ＶＮＦＭ１２にリソース割当て要求に対応する肯定応答（ＡＣＫ）を送信する（ステップＳ４１４）。
　当該肯定応答（ＡＣＫ）を受信したＶＮＦＭ１２は、パッチファイル登録プロセスにおいて取得したパッチファイル（パッチ用のイメージファイル）を用いて対応するイメージファイルの一部を書き換えるようにストレージサーバ４０に指示する。つまり、当該肯定応答（ＡＣＫ）を受信したＶＮＦＭ１２は、パッチファイルをストレージ４１に登録（ステップＳ４１５）する。その後、ＶＮＦＭ１２は、パッチ適用によるＶＮＦ２２の起動をＶＩＭ１３に対して要求する（ステップＳ４１６）。具体的には、ＶＮＦＭ１２は、パッチを適用するＶＮＦ２２を指定して、当該ＶＮＦ２２の起動をＶＩＭ１３に要求する。
　ＶＩＭ１３は、パッチ適用するＶＮＦ２２に対応したイメージファイルが格納されているストレージ４１の所定領域に対応するアドレスを含むディプロイメントに固有のパラメータをリソースの割り当てられた仮想マシンに設定する。この動作で、ＶＩＭ１３は、パッチ適用によるＶＮＦ２２の起動を実行する（ステップＳ４１７）。
　上記固有のパラメータの設定に基づいて、上記ストレージ４１の所定領域からのＶＮＦ２２の生成、及び起動が行われる（ステップＳ４１８）。ＶＮＦ２２の起動が正常終了すると、ＮＦＶＩ２１からＶＩＭ１３に対して肯定応答（ＡＣＫ）が送信される（ステップＳ４１９）。
　当該肯定応答（ＡＣＫ）を受信したＶＩＭ１３は、ステップＳ４１６のパッチ適用によるＶＮＦ２２の起動要求に対応する肯定応答（ＡＣＫ）をＶＮＦＭ１２に送信する（ステップＳ４２０）。
　ＶＮＦＭ１２は、ＮＦＶＯ１１に対して、ヒーリング完了通知を送信（ステップＳ４２１）し、ＮＦＶＯ１１からの肯定応答（ＡＣＫ）を受信（ステップＳ４２２）することで、ヒーリング処理を完了する。
　なお、上述の実施形態にて説明したネットワークシステムの構成及び動作は、例示であり、システムの構成を限定する趣旨ではない。例えば、上述の実施形態では、ＶＮＦＭ１２がパッチファイルをストレージ４１に登録する場合について説明した。しかし、ＥＭＳ２３又はＮＦＶＯ１１から、パッチファイルがストレージ４１に登録されてもよい。すなわち、ＥＭＳ２３、ＮＦＶＯ１１及びＶＮＦＭ１２のいずれか１つが、ＶＮＦ２２の更新に用いるパッチファイルをＮＦＶＩ２１に提供する（パッチファイルがＶＩＭ１３を経由せずにＮＦＶＩ２１に提供される）構成であればよい。
　また、上述の実施形態では、ＶＮＦ２２のインスタンシエーションにＢｏｏｔ　Ｆｒｏｍ　Ｃｉｎｄｅｒ　Ｖｏｌｕｍｅ方式を用いる場合を説明した。しかし、上述の実施形態は、当該方式を採用しなくてもよい。この場合、ＥＭＳ２３、ＮＦＶＯ１１及びＶＮＦＭ１２のいずれか１つが、パッチファイルをＮＦＶＩ２１に提供し、ＮＦＶＩ２１が仮想マシンに割り当てているストレージの該当領域を書き換えればよい。つまり、ＥＭＳ２３、ＮＦＶＯ１１及びＶＮＦＭ１２のいずれか１つが、ＶＮＦ２２の更新に用いるパッチファイルを、ストレージサーバ４０（ストレージ４１）を介さずにＮＦＶＩ２１に直接提供してもよい。
　以上のように、上記実施形態に係るネットワークシステムは、図５に示すように、ＯＳの変更を含む場合のようなメジャーバージョンアップ時にはＯＳ、ＭＷ又はＡＰＬ等のプログラムデータを含むイメージファイルをＶＩＭ１３を経由してＶＮＦ２２に展開する。一方、図６に示すように、上記実施形態に係るネットワークシステムは、高い頻度で行われるようなパッチ適用時のマイナーバージョンアップ時には、次のように動作する。つまり、ネットワークシステムは、パッチ適用箇所に限られた部分的な（例えば、アプリケーションデータだけの）小さいサイズのイメージファイル（パッチファイル）を中央拠点１の装置（例えば、ＥＭＳ２３又はＶＮＦＭ１２）から直接ＶＮＦ２２に展開する。メジャーバージョンアップ時とマイナーバージョンアップ時のイメージファイルの転送経路を示す様子が図７に例示される。
　中央拠点１の装置からパッチファイルを直接、ＶＮＦ２２に展開することで、小さいサイズのイメージファイルが装置（ＶＩＭ１３を実装するサーバ）を跨がずに転送される。そのため、ネットワークシステムは、ネットワークシステムに生じうるＶＮＦ２２のヒーリングに要する時間を短縮することができる。すなわち、第１の実施形態では、ＶＩＭ１３を経由せず、高頻度で発生する小サイズのファイル転送が実現できるため、ネットワークシステムの効率的な運用が実現できる。
　また、第１の実施形態は、Ｂｏｏｔ　Ｆｒｏｍ　Ｃｉｎｄｅｒ　Ｖｏｌｕｍｅ方式を利用して、ＶＮＦ２２のインスタンシエーションを実現している。
そのため、第１の実施形態は、イメージファイルを物理マシン３（ＮＦＶＩ２１）に直接転送する必要はなく、イメージファイルを外部ストレージに転送すればよく、ＶＮＦ２２のインスタンシエーションの効率化を図れる。なお、Ｂｏｏｔ　Ｆｒｏｍ　Ｃｉｎｄｅｒ　Ｖｏｌｕｍｅ方式を採用し、パッチファイルをＶＩＭ１３経由でＶＮＦ２２に展開するだけでは、ネットワークシステムの効率的な運用は実現されない。それは、当該技術を採用したとしても、中央拠点１から全ての地域拠点２にイメージファイルを展開することに変わりないためである。
　また、非特許文献１には、パッチファイルを用いたＶＮＦ２２の起動が、記載されていない。非特許文献１には、ＶＮＦ２２を更新する際には、ＯＳ、ＭＷ、又はＡＰＬを含むイメージファイルをＶＩＭ１３に提供し、ＶＮＦ２２を起動（インスタンシエーション）することが記載されているにすぎない。（例えば、同文献の１０６ページ「B.2.4 Update VNF Package flow」を参照。）
　図４等に例示した各装置が行う処理は、各装置に搭載されたコンピュータに、そのハードウェアを用いて、上述した各処理を実行させるコンピュータプログラムに基づいて実現できる。すなわち、各手段の一部又は全ては、コンピュータ（プロセッサ等）で実行されるプログラムに基づいて実現するようにしてもよく、上述の各処理モジュールが行う機能を何らかのハードウェア、及び／又は、ソフトウェアで実行する手段であればよい。
　上記の説明に基づいて、本発明の産業上の利用可能性は明らかである。本発明は、仮想化された通信サーバ（ＶＮＦ２２）など、非仮想化時と同様にエンドユーザに影響なく２４時間無停止稼働が求められるシステムの必要リソース事前確保を必要とするシステムに好適に適用可能である。あるいは、本発明は、各種の仮想化サーバ（ＶＮＦ２２）における保守業務の簡略化及びシナリオ実行化を必要とするシステムに好適に適用可能である。
　上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
　上述の第１の視点に係るネットワークシステムのとおりである。
［付記２］
　ＮＦＶＩのリソース管理と制御を行うＶＩＭ（Virtualized Infrastructure Manager）をさらに含み、
　パッチファイルをＮＦＶＩに提供するＥＭＳ、ＮＦＶＯ及びＶＮＦＭのいずれか１つは、パッチファイルを、ＶＩＭを経由せずにＮＦＶＩに提供する、
　付記１に記載のネットワークシステム。
［付記３］
　ＮＦＶＯは、ＶＮＦのインスタンシエーションに使用するファイルであって、オペレーティングシステム、ミドルウェア、又はアプリケーションに係るプログラムデータを含むイメージファイルを、ＶＩＭに提供し、
　ＶＩＭは、イメージファイルをＮＦＶＩに提供する、
　付記２に記載のネットワークシステム。
［付記４］
　外部からアクセス可能なストレージを管理するストレージサーバをさらに含み、
　ＶＩＭは、イメージファイルをストレージサーバに提供し、
　ストレージサーバは、提供されたイメージファイルをストレージの所定領域に格納し、
　ＶＩＭは、ストレージの所定領域に格納されたイメージファイルを用いてＶＮＦを起動する、
　付記３に記載のネットワークシステム。
［付記５］
　パッチファイルをＮＦＶＩに提供する、ＥＭＳ、ＮＦＶＯ及びＶＮＦＭのいずれか１つは、ストレージサーバに対し、イメージファイルが格納された所定領域の一部をパッチファイルにて書き換えるように指示する、
　付記４に記載のネットワークシステム。
［付記６］
　ＶＮＦＭは、パッチファイルに基づくイメージファイルの一部の書換えが終了した後に、ＶＩＭに対して一部が書き換えられたイメージファイルを使用したＶＮＦの起動を要求する、
　付記５に記載のネットワークシステム。
［付記７］
　ＶＮＦをヒーリングする際に、パッチファイルに基づくイメージファイルの一部が書き換えられ、一部が書き換えられたイメージファイルを使用したＶＮＦの起動が行われる、
　付記６に記載のネットワークシステム。
［付記８］
　パッチファイルは、イメージファイルが含むプログラムデータのうち、アプリケーションに係るプログラムデータを含む、
　付記３乃至７のいずれか一に記載のネットワークシステム。
［付記９］
　上述の第２の視点に係るパッチファイル適用方法のとおりである。
［付記１０］
　上述の第３の視点に係るプログラムのとおりである。
　なお、付記９の形態及び付記１０の形態は、付記１の形態と同様に、付記２の形態～付記８の形態に展開することが可能である。
　なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更及び調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、及び各図面の各要素等を含む）の多様な組合せ、及び、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、及び、技術的思想にしたがって当業者であればなし得るであろう各種変形及び修正を含むことはもちろんである。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値及び小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
　この出願は、２０１６年　４月２１日に出願された日本出願特願２０１６－０８５０５３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
　１　　中央拠点
　２、２－１～２－ｎ　　地域拠点
　３、３－１～３－ｍ　　物理マシン
　１０　　ＮＦＶ－ＭＡＮＯ
　１１、１０２　　ＮＦＶＯ
　１２、１０３　　ＶＮＦＭ
　１３　　ＶＩＭ
　２１、１００　　ＮＦＶＩ
　２２　　ＶＮＦ
　２３、１０１　　ＥＭＳ
　３０　　ＯＳＳ／ＢＳＳ
　４０　　ストレージサーバ
　４１　　ストレージ
　５１　　ＣＰＵ
　５２　　メモリ
　５３　　入出力インターフェイス
　５４　　ＮＩＣ
　２０１　　パッチファイル取得部
　２０２　　パッチファイル登録部
　２０３　　ＶＮＦ起動要求部
　２１１　　イメージファイル登録部
　２１２　　ＶＮＦ起動処理部

Claims (10)

  1. 　仮想マシン上で動作するソフトウェアによって実装され仮想されたＶＮＦ（Virtual Network Function）の実行基盤を提供するＮＦＶＩ（Network Function Virtualization Infrastructure）と、
    　前記ＶＮＦに対応するＥＭＳ（Element Management System）と、
    　前記ＮＦＶＩの上にて、ネットワークサービスを実現するＮＦＶＯ（NFV Orchestrator）と、
    　前記ＶＮＦのライフサイクルを管理するＶＮＦＭ（VNF Manager）と、
    　を含み、
    　前記ＥＭＳ、前記ＮＦＶＯ及び前記ＶＮＦＭのいずれか１つが、前記ＶＮＦの更新に用いるパッチファイルを前記ＮＦＶＩに提供する、ネットワークシステム。
  2. 　前記ＮＦＶＩのリソース管理と制御を行うＶＩＭ（Virtualized Infrastructure Manager）をさらに含み、
    　前記パッチファイルを前記ＮＦＶＩに提供する前記ＥＭＳ、前記ＮＦＶＯ及び前記ＶＮＦＭのいずれか１つは、前記パッチファイルを、前記ＶＩＭを経由せずに前記ＮＦＶＩに提供する、
    　請求項１に記載のネットワークシステム。
  3. 　前記ＮＦＶＯは、前記ＶＮＦのインスタンシエーションに使用するファイルであって、オペレーティングシステム、ミドルウェア、又はアプリケーションに係るプログラムデータを含むイメージファイルを、前記ＶＩＭに提供し、
    　前記ＶＩＭは、前記イメージファイルを前記ＮＦＶＩに提供する、
    　請求項２に記載のネットワークシステム。
  4. 　外部からアクセス可能なストレージを管理するストレージサーバをさらに含み、
    　前記ＶＩＭは、前記イメージファイルを前記ストレージサーバに提供し、
    　前記ストレージサーバは、提供された前記イメージファイルを前記ストレージの所定領域に格納し、
    　前記ＶＩＭは、前記ストレージの所定領域に格納された前記イメージファイルを用いて前記ＶＮＦを起動する、
    　請求項３に記載のネットワークシステム。
  5. 　前記パッチファイルを前記ＮＦＶＩに提供する、前記ＥＭＳ、前記ＮＦＶＯ及び前記ＶＮＦＭのいずれか１つは、前記ストレージサーバに対し、前記イメージファイルが格納された所定領域の一部を前記パッチファイルにて書き換えるように指示する、
    　請求項４に記載のネットワークシステム。
  6. 　前記ＶＮＦＭは、前記パッチファイルに基づく前記イメージファイルの一部の書換えが終了した後に、前記ＶＩＭに対して一部が書き換えられた前記イメージファイルを使用した前記ＶＮＦの起動を要求する、
    　請求項５に記載のネットワークシステム。
  7. 　前記ＶＮＦをヒーリングする際に、前記パッチファイルに基づく前記イメージファイルの一部が書き換えられ、一部が書き換えられた前記イメージファイルを使用した前記ＶＮＦの起動が行われる、
    　請求項６に記載のネットワークシステム。
  8. 　前記パッチファイルは、前記イメージファイルが含むプログラムデータのうち、アプリケーションに係るプログラムデータを含む、
    　請求項３乃至７のいずれか一項に記載のネットワークシステム。
  9. 　仮想マシン上で動作するソフトウェアによって実装され仮想されたＶＮＦ（Virtual Network Function）の実行基盤を提供するＮＦＶＩ（Network Function Virtualization Infrastructure）と、
    　前記ＶＮＦに対応するＥＭＳ（Element Management System）と、
    　前記ＮＦＶＩの上にて、ネットワークサービスを実現するＮＦＶＯ（NFV Orchestrator）と、
    　前記ＶＮＦのライフサイクルを管理するＶＮＦＭ（VNF Manager）と、
    　を含むネットワークシステムにおいて、
    　前記ＥＭＳ、前記ＮＦＶＯ及び前記ＶＮＦＭのいずれか１つにより、前記ＶＮＦの更新に用いるパッチファイルが前記ＮＦＶＩに提供し、
    　提供された前記パッチファイルを使用した前記ＶＮＦのインスタンシエーションが実行する、
    　パッチファイル適用方法。
  10. 　仮想マシン上で動作するソフトウェアによって実装され仮想されたＶＮＦ（Virtual Network Function）のライフサイクルを管理するＶＮＦＭ（VNF Manager）を制御するコンピュータに実行させるプログラムであって、
    　前記ＶＮＦの更新に用いるパッチファイルを、前記ＶＮＦの実行基盤を提供するＮＦＶＩ（Network Function Virtualization Infrastructure）に提供する処理を実行させる、
    　プログラムをコンピュータ読み取り可能に記録する記録媒体。
PCT/JP2017/015222 2016-04-21 2017-04-14 ネットワークシステム、パッチファイル適用方法、及び記録媒体 WO2017183565A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/084,651 US20190073235A1 (en) 2016-04-21 2017-04-14 Network system, patch file application method, and recording medium
JP2018513150A JP6677294B2 (ja) 2016-04-21 2017-04-14 ネットワークシステム、パッチファイル適用方法、及びプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016085053 2016-04-21
JP2016-085053 2016-04-21

Publications (1)

Publication Number Publication Date
WO2017183565A1 true WO2017183565A1 (ja) 2017-10-26

Family

ID=60116687

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/015222 WO2017183565A1 (ja) 2016-04-21 2017-04-14 ネットワークシステム、パッチファイル適用方法、及び記録媒体

Country Status (3)

Country Link
US (1) US20190073235A1 (ja)
JP (1) JP6677294B2 (ja)
WO (1) WO2017183565A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108804201A (zh) * 2018-06-07 2018-11-13 郑州云海信息技术有限公司 一种基于云平台的虚拟机数据卷的扩容方法及装置
CN109474464A (zh) * 2018-11-13 2019-03-15 电子科技大学 一种基于OpenNF机制的快速网络更新方法
KR102055827B1 (ko) * 2018-10-16 2019-12-13 에스케이텔레콤 주식회사 가상화 네트워크 관리 장치 및 방법
US11418386B2 (en) 2018-03-06 2022-08-16 At&T Intellectual Property I, L.P. Virtual network function creation system

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US11012883B2 (en) * 2017-01-06 2021-05-18 Apple Inc. Measurement job suspension and resumption in network function virtualization
CN109032751B (zh) * 2017-06-12 2022-02-11 华为技术有限公司 一种虚拟机部署方法及omm虚拟机
US10833957B2 (en) * 2018-01-16 2020-11-10 Intel Corporation Managing physical network function instances in a network service instance
CN112346755A (zh) * 2019-08-09 2021-02-09 华为技术有限公司 一种基于网络功能虚拟化的版本升级的方法及设备
CN110727498B (zh) * 2019-09-03 2023-04-07 中国联合网络通信集团有限公司 一种虚拟网络功能的管理方法、nfvo、区块链节点及mano网元

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015146355A1 (ja) * 2014-03-28 2015-10-01 株式会社Ｎｔｔドコモ 更新管理システムおよび更新管理方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1529847A (zh) * 2001-07-16 2004-09-15 任宇清 内嵌软件更新系统
JP2003067208A (ja) * 2001-08-23 2003-03-07 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム
US7685591B2 (en) * 2004-12-20 2010-03-23 Microsoft Corporation Customizing a software application through a patch file
US10114565B2 (en) * 2014-11-04 2018-10-30 Rubrik, Inc. Automated generation of cloned production environments
EP3252600A4 (en) * 2015-01-28 2018-02-28 Nec Corporation Virtual network function management device, system, healing method, and program
FR3038175A1 (fr) * 2015-06-26 2016-12-30 Orange Procede de gestion dynamique d'un service reseau dans un reseau de communication
US9854048B2 (en) * 2015-06-29 2017-12-26 Sprint Communications Company L.P. Network function virtualization (NFV) hardware trust in data communication systems
CN107852337B (zh) * 2015-07-23 2021-07-13 英特尔公司 支持网络功能虚拟化生命周期管理的网络资源模型
KR102021342B1 (ko) * 2015-10-14 2019-09-16 한국전자통신연구원 Nfv 시스템 및 vnfm 연동 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015146355A1 (ja) * 2014-03-28 2015-10-01 株式会社Ｎｔｔドコモ 更新管理システムおよび更新管理方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DAIKI ENDO ET AL.: "A Study of Operation Support System Architecture for Virtualized Carrier Networks", IEICE TECHNICAL REPORT, vol. 114, no. 299, 6 November 2014 (2014-11-06), pages 71 - 74, ISSN: 0913-5685 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11418386B2 (en) 2018-03-06 2022-08-16 At&T Intellectual Property I, L.P. Virtual network function creation system
CN108804201A (zh) * 2018-06-07 2018-11-13 郑州云海信息技术有限公司 一种基于云平台的虚拟机数据卷的扩容方法及装置
KR102055827B1 (ko) * 2018-10-16 2019-12-13 에스케이텔레콤 주식회사 가상화 네트워크 관리 장치 및 방법
CN109474464A (zh) * 2018-11-13 2019-03-15 电子科技大学 一种基于OpenNF机制的快速网络更新方法
CN109474464B (zh) * 2018-11-13 2020-06-16 电子科技大学 一种基于OpenNF机制的快速网络更新方法

Also Published As

Publication number Publication date
JP6677294B2 (ja) 2020-04-08
US20190073235A1 (en) 2019-03-07
JPWO2017183565A1 (ja) 2019-01-17

Similar Documents

Publication Publication Date Title
WO2017183565A1 (ja) ネットワークシステム、パッチファイル適用方法、及び記録媒体
US9760396B2 (en) Managing a server template
JP6954267B2 (ja) ネットワーク機能仮想化管理オーケストレーション装置と方法とプログラム
CN107506258B (zh) 用于数据备份的方法和设备
JP6819296B2 (ja) 仮想化管理・オーケストレーション装置、仮想化管理・オーケストレーション方法、および、プログラム
US9851989B2 (en) Methods and apparatus to manage virtual machines
JP5032191B2 (ja) サーバ仮想化環境におけるクラスタシステム構成方法及びクラスタシステム
WO2018002991A1 (ja) 制御装置、ｖｎｆ配置先選択方法及びプログラム
WO2016121754A1 (ja) システム、仮想化制御装置、仮想化制御装置の制御方法及びプログラム
JP6763429B2 (ja) 制御装置、コンテナの起動方法及びプログラム
JP5346405B2 (ja) ネットワークシステム
US10728169B1 (en) Instance upgrade migration
CN114651233A (zh) 即时容器
EP3746888B1 (en) System and method for preserving entity identifiers for virtual machines
US20190354359A1 (en) Service managers and firmware version selections in distributed computing systems
CN110968392B (zh) 一种升级虚拟化模拟器的方法和装置
KR20210128722A (ko) 멀리 클라우드 서비스 플랫폼 장치 및 방법
US20160266921A1 (en) Virtual appliance management in a virtualized computing environment
KR20200038038A (ko) 다중 클라우드 상에서의 애플리케이션 관리 장치 및 방법
JP2016173741A (ja) 情報処理装置、情報処理方法、及び、プログラム
US11422861B2 (en) Data processing method and computer device
US20140366010A1 (en) Enabling parallel websphere runtime on different computer
JP7184097B2 (ja) ネットワーク機能仮想化システム及びオペレーティングシステム更新方法
US20240160354A1 (en) Node cache migration
WO2013114829A1 (ja) 情報処理システム、データセンタ、システム移行方法、及び、プログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2018513150

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17785903

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17785903

Country of ref document: EP

Kind code of ref document: A1