JPWO2020145242A1 - Network function Virtualization system and operating system update method - Google Patents

Abstract

It provides a network function virtualization system that can update the guest OS version of a virtual machine without interrupting the service being provided. The network function virtualization system includes first and second physical machines and a virtualization control device. The NFVO of the virtualization control device realizes a network service on the NFVI. VNFM manages the life cycle of VNF. VIM manages and controls NFVI resources. The VIM provides the second physical machine with an image file of a new guest OS that is an update of the old guest OS that was operating in the first virtual machine on the first physical machine. In the second physical machine, the second virtual machine operating in the new guest OS is started by using the image file of the new guest OS, and the second virtual machine uses the data from the old guest OS. Convert memory types to be acceptable.

Description

(Description of related application)
The present invention is based on the priority claim of Japanese patent application: Japanese Patent Application No. 2019-000458 (filed on January 07, 2019), and all the contents of the application are incorporated in this document by citation. Shall be.
The present invention relates to a network function virtualization system and an operating system update method.

NFV (Network Functions Virtualization) that realizes the functions of network devices by software by a virtual machine (VM) mounted on a virtualization layer such as a hypervisor (HV) on a server. It is known (see, for example, Non-Patent Documents 1 and 2). FIG. 5 is a simplified drawing of Chapter 7 and Figure 4 of Non-Patent Document 2, and FIG. 5 will be used to outline the network configuration of the VNF environment.

The VNF (Virtualized Network Function) 22 corresponds to an application running on a virtual machine (VM) on a server, and realizes a network function by software. Each VNF 22 is provided with a management function called EM (Element Manager: Element Management) 23 (also referred to as EMS (Element Manage System)).

NFVI (Network Functions Virtualization Infrastructure) 21 is virtualized computing, virtual storage, virtual in which hardware resources of physical machines (servers) such as computing, storage, and network functions are virtualized in a virtualization layer such as a hypervisor. It is a platform that can be flexibly handled as a virtualized hardware resource such as a virtualized network.

The NFV Orchestrator (NFVO) 11 of the NFV-MANO (NFV Management & Orchestration) 10 provides the orchestration of the resources of the NFVI 21 and the life cycle management of the network service (NS) instance (instance of the NS instance). Performs Sation (Instantiation), Scaling (Scaling), Termination (Termination), Update (Update), etc.).

The VNF Manager (VNF Manager) 12 manages the life cycle of VNF instances (for example, instantiation: instantiation: preparing a virtual machine on a physical machine such as a server and launching VNF as an example), and updating (update). ), Query, scaling, termination, etc.) and event notification.

The Virtualized Infrastructure Manager (VIM) 13 performs computing of NFVI21, storage, resource management of network, failure monitoring of NFVI21, resource monitoring of NFVI21, and the like.

Of the OSS / BSS30, OSS (Operations Support Systems) is a general term for systems (devices, software, mechanisms, etc.) necessary for a telecommunications carrier (carrier) to build and operate a service, for example. BSS (Business Support Systems) is a general term for information systems (devices, software, mechanisms, etc.) used by telecommunications carriers (carriers) for billing, billing, customer support, and the like.

Patent Document 1 describes a virtualization infrastructure management device, a virtual network function management device, a virtual machine management method, and a virtual machine management device that can contribute to deterring that a service that has been operating stably is interrupted due to the above healing or scaling. It is stated that it is intended to provide a program.

International Publication No. 2017/002812

ETSI GS NFV-MAN 001 V1.1.1 (2014-12) Network Functions Virtualisation (NFV); Management and Orchestration (searched December 3, 2018) <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 (searched December 3, 2018) <http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002 /01.02.01_60/gs_NFV002v010201p.pdf ＞

In addition, each disclosure of the above prior art documents shall be incorporated into this document by citation. The following analysis was made by the present inventors.

The above-mentioned NFVO11, VNFM12, VIM13 and the like are functional entities for managing the network system. By controlling these functional entities, virtual machines and VNFs are created on the physical machine (PM).

In the network system of the VNF environment, the image file necessary for the instantiation of the VNF 22 is provided to the VIM 13 by OSS or the like. The VIM 13 provides the provided image file to the NFVI 21, and the image file is used to instantiate the VNF 22.

The above image file contains data necessary for instantiation of VNF22, and specifically, program data related to OS (Operating System), MW (Middleware), and APL (Application) executed in a virtual machine. Is included. The operation of the VNF22 instantiated by the image file is determined by the OS, MW, and APL. Therefore, by updating the image file, the function of the VNF 22 is changed or improved.

For example, when updating the OS (guest OS) by a different distributor for the purpose of improving the function of VNF22, or by major version up of the OS by the same distributor (significant function enhancement or performance improvement from the previous version). , Version upgrade with major improvements and corrections such as changes in data format) may be implemented. In this document, the guest OS (OS executed on a virtual machine) is simply "" except when the abbreviation is unclear (for example, when it is necessary to distinguish it from the OS running on a physical machine). It is abbreviated as "OS".

When updating the guest OS, for example, an update procedure (rolling update) using healing is performed. Healing is a series of recovery to a normal state by moving or recreating a virtual machine on a normal physical machine when a hardware failure or virtual machine failure occurs on a physical machine such as a server. Refers to the procedure of. Further, in the rolling update, in a system composed of a plurality of machines or the like, the software of the system can be updated without completely stopping the system by sequentially updating each part. For example, as schematically shown in FIG. 6, it is assumed that the virtual machine VM0 and the virtual machine VM1 are started on the old physical machine (the physical machine on which the virtual machine before the version upgrade is operating). The virtual machine VM0 and the virtual machine VM1 form a redundant system in which one functions as a standby system when one is an active system, and the virtual machine VM0 and the virtual machine VM1 synchronize data (upper part of FIG. 6). reference). This data synchronization is for the virtual machine VM0 and the virtual machine VM1 to synchronize the data as a cluster. For example, when data is updated in an active system (active system) virtual machine, the updated data is transferred to a standby system (standby system) virtual machine as duplicate data and data is transferred between the active system and the standby system. In some cases, it is possible to recover data to the latest state and improve availability by synchronizing the data.

The OS of the virtual machine VM0 and the virtual machine VM1 running on the old physical machine is updated. At that time, the startup destination of the virtual machine VM0 is changed from the old physical machine to the new physical machine. Specifically, healing is performed on the virtual machine VM0, and the virtual machine VM0 with an updated OS is started on the new physical machine. In the following, the OS before the update is referred to as the old OS, and the OS after the update is referred to as the new OS.

Data synchronization is performed between the virtual machine VM1 (virtual machine running on the old OS) running on the old physical machine and the virtual machine VM0 (virtual machine running on the new OS) running on the new physical machine. (See interruption in FIG. 6). After that, healing related to the virtual machine VM1 is performed, and the virtual machine VM1 running on the new OS is started on the new physical machine. The virtual machine VM0 and the virtual machine VM1 running on the new physical machine synchronize data (see the lower part of FIG. 6).

The above is the procedure for updating the OS using healing. In FIG. 6, the shades of color given to the configurations of the virtual machines VM0 and VM1 indicate the difference in OS version.

When updating the OS of the virtual machine, for example, in FIG. 5, the OSS instructs VNFM12 to start healing. The instruction is notified from VNFM12 to VIM13. The VIM 13 stops (deletes) the virtual machine VM0 running on the old physical machine, and instructs the new physical machine to create a new virtual machine VM0. At that time, the VIM 13 provides an image file corresponding to the new OS to the new physical machine, and instructs the new physical machine to start the new virtual machine VM0 with the image file.

After that, data synchronization is performed between the virtual machine VM1 running on the old physical machine and the virtual machine VM0 running on the new physical machine. At this time, if the memory structure of the virtual machine VM1 running on the old OS (variable type and data structure expanded on the memory, etc.) and the memory structure of the virtual machine VM1 running on the new OS match, the above Data synchronization is performed without any problem, and the OS can be updated without interrupting the service.

However, when the OS is updated (updated) by different distributors or the major version upgrade of the OS is performed, the memory structure of the old and new OS is different, and the data is data between the virtual machine VM1 running on the old OS and the virtual machine VM1 running on the new OS. There may be a situation where the synchronization cannot be performed. In other words, if the compatibility between the old and new OS is not supported, such as the type of memory to be synchronized between the virtual machines of the old and new OS is different, the data cannot be synchronized between the virtual machines of the old and new OS. Therefore, the service may be interrupted due to OS update or major version upgrade. As a result, it affects the users who receive the service.

An object of the present invention is to provide a network function virtualization system and an operating system update method that enable an update of a guest OS version of a virtual machine without interrupting the service being provided.

According to the first aspect of the present invention or the disclosure, each has an NFVI (Network Function Virtualization Infrastructure) that provides an execution platform of a virtualized VNF (Virtual Network Function) implemented by software running on a virtual machine. NFVO (NFV-Orchestrator) that realizes network services on the first and second physical machines and the NFVI, VNFM (VNF Manager) that manages the life cycle of the VNF, and resource management and control of the NFVI. The VIM includes a virtualization control device including a VIM (Virtualized Infrastructure Manager) to perform, and the VIM is a new guest OS that updates the old guest OS that was operating in the first virtual machine on the first physical machine. The image file is provided to the second physical machine, and in the second physical machine, the second virtual machine running on the new guest OS is started by using the image file of the new guest OS, and the second virtual machine is started. The virtual machine 2 is provided with a network function virtualization system that converts the memory type so that data from the old guest OS can be accepted.

According to the second aspect of the present invention or the disclosure, each has an NFVI (Network Function Virtualization Infrastructure) that provides an execution platform of a virtualized VNF (Virtual Network Function) implemented by software running on a virtual machine. NFVO (NFV-Orchestrator) that realizes network services on the first and second physical machines and the NFVI, VNFM (VNF Manager) that manages the life cycle of the VNF, and resource management and control of the NFVI. A method of updating an operating system in a system including a virtualization control device equipped with a VIM (Virtualized Infrastructure Manager).
The VIM provides the second physical machine with an image file of a new guest OS that is an update of the old guest OS that was operating in the first virtual machine on the first physical machine.
In the second physical machine, the second virtual machine is started by using the image file of the new guest OS.
The second virtual machine is provided with an operating system update method that converts the memory type so that data from the old guest OS can be accepted.

According to each viewpoint of the present invention or the disclosure, there is provided a network function virtualization system and an operating system update method capable of updating the guest OS version of a virtual machine without interrupting the service being provided.

It is a figure for demonstrating the outline of one Embodiment. It is a figure explaining an example of the structure of the network system which concerns on 1st Embodiment. It is a sequence diagram which illustrates an example of the operation of the virtualization system which concerns on 1st Embodiment. It is a figure which shows an example of the hardware configuration of the virtualization control device which concerns on 1st Embodiment. It is a simplified figure of Chapter 7 and Figure 4 of Non-Patent Document 2. It is a figure which schematically exemplifies an example of OS update using healing.

First, an outline of one embodiment will be described. It should be noted that the drawing reference reference numerals added to this outline are added to each element for convenience as an example for assisting understanding, and the description of this outline is not intended to limit anything. Further, the connecting line between the blocks in each figure includes both bidirectional and unidirectional. The one-way arrow schematically shows the flow of the main signal (data), and does not exclude interactivity. Further, in the circuit diagram, block diagram, internal configuration diagram, connection diagram, and the like shown in the disclosure of the present application, although not explicitly stated, an input port and an output port exist at the input end and the output end of each connection line, respectively. The same applies to the input / output interface.

The network function virtualization system according to one embodiment includes first and second physical machines 101 and 102, and a virtualization control device 103 (see FIG. 1). Each of the first and second physical machines 101 and 102 has an NFVI (Network Function Virtualization Infrastructure) that provides an execution platform of a virtualized VNF (Virtual Network Function) implemented by software running on the virtual machine. .. The virtualization control device 103 includes an NFVO (NFV-Orchestrator) 111, a VNFM (VNF Manager) 112, and a VIM (Virtualized Infrastructure Manager) 113. NFVO111 realizes a network service on NFVI. The VNFM 112 manages the life cycle of the VNF. The VIM 113 manages and controls NFVI resources. The VIM 113 provides the second physical machine 102 with an image file of a new OS corresponding to the old OS that was operating in the first virtual machine on the first physical machine 101. In the second physical machine 102, the new OS is started on the second virtual machine using the provided image file, and the started new OS is from the old OS running on the first physical machine 101. Converts the memory type to accept the data in.

The virtualization control device 103 performs healing in cooperation with NFV-MANO (NFVO, VNFM, VMI) at the restart timing of the OS (guest OS), for example, when updating a VNF file. At that time, by executing the memory type conversion process, the difference in the memory type between the old and new OS is absorbed. As a result, it is possible to update from the old OS to the new OS without interrupting the service being provided (without affecting the user).

Specific embodiments will be described in more detail below with reference to the drawings. In each embodiment, the same components are designated by the same reference numerals, and the description thereof will be omitted.

[First Embodiment]
The first embodiment will be described in more detail with reference to the drawings.

FIG. 2 is a block diagram for explaining the network system (network function virtualization system) according to the first embodiment in terms of functions. Referring to FIG. 2, the VNFM 12 and VIM 13 have the functions (functional blocks) shown in FIG. 2 in addition to the functions described in Non-Patent Documents 1 and 2.

In the first embodiment, a case where the OS (guest OS) of the virtual machine VM running on the physical machine 20-1 is updated will be described. At that time, the virtualization control device (NFV-MANO) 10 according to the first embodiment performs healing of the virtual machine VM on the physical machine 20-2. The NFV-MANO10 updates the OS of the virtual machine VM at the time of the healing.

Each of the physical machines 20-1 and 20-2 has an NFVI (Network Function Virtualization Infrastructure) 21 that provides an execution base of a virtualized VNF (Virtual Network Function) 22 implemented by software running on the virtual machine.

The NFV-MANO 10 is an NFVO (NFV-Orchestrator) 11 that realizes a network service on the NFVI 21, a VNFM (VNF Manager) 12 that manages the life cycle of the VNF 22, and a VIM (Virtualized) that manages and controls the resources of the NFVI 21. Infrastructure Manager) 13.

The VNFM 12 includes a file input unit 201 and a healing control unit 202.

The file input unit 201 is a means for inputting a file for the new OS from an external device (for example, OSS or the like). Specifically, the file input unit 201 acquires a VNF file (VNFD) corresponding to the new OS. The acquired VNF file is a file related to the instantiated VNF, and is stored in a storage unit or the like accessible to the VNFM12.

The file input unit 201 also inputs an image file for the new OS. As described above, the image file used for the instantiation of VNF22 includes the program data related to the OS, MW, and APL (application). The file input unit 201 may acquire an image file containing only the program data of the OS, or may acquire an image file including each program data of the OS, MW, and APL. The acquired image file is stored in a storage unit or the like accessible to the VIM 13.

The healing control unit 202 is a means for controlling healing by the VIM 13. While providing the VNF file for the new OS to the VIM 13, the healing control unit 202 requests the VIM 13 to perform healing of the virtual machine using the file and the image file stored earlier.

The VIM 13 includes an NFVI control unit 211.

The NFVI control unit 211 is a means for processing the healing request and the like from the above-mentioned VNFM12. Specifically, the NFVI control unit 211 instructes the NFVI 21 to generate and start the virtual machine VNF22 using the above files (VNF file, image file).

A virtual machine VM is constructed on the physical machines 20-1 and 20-2. In FIG. 2, the OS of the virtual machine VM running on the physical machine 20-1 is updated. In that case, the physical machine 20-2 heals the updated virtual machine VM (updated VNF), and the OS of the virtual machine VM is updated at the time of the healing. Therefore, the virtual machine VM running on the physical machine 20-2 runs on the new OS. In the following description, the physical machine 20-1 will be referred to as the old physical machine 20-1, and the physical machine 20-2 will be referred to as the new physical machine 20-2.

Subsequently, the operation of the virtualization system according to the first embodiment will be described. FIG. 3 is a sequence diagram showing an example of the operation of the virtualization system according to the first embodiment.

In step S01, data is synchronized between the two virtual machines VM0 and VM1 operating in the old physical machine 20-1 and forming a redundant system.

When updating the OS of the virtual machine, for example, the OSS instructs the old physical machine 20-1 (NFVI21) to start healing (step S02).

The virtual machine VM0 (NFVI21 of the old physical machine 20-1) requests the VNFM12 to start the OS update of the virtual machine VM0 (step S03).

The VNFM 12 instructs the VIM 13 to start healing the virtual machine VM0 while providing the VNF file for the new OS (step S04).

The VIM 13 instructs the old physical machine 20-1 (NFVI21) to delete (stop) the virtual machine VM0 (step S05). In response to the instruction, the virtual machine VM0 is deleted in the old physical machine 20-1.

The VIM 13 instructs the new physical machine 20-2 (NFVI21 of the machine) to generate a new virtual machine VM0 (step S06). At that time, the VIM 13 provides the new physical machine 20-2 with an image file of the OS executed by the new virtual machine VM0, and instructs the new physical machine 20-2 to start the virtual machine VM0 by the image file. Further, the VIM 13 provides the new physical machine 20-2 with a VNF file (configuration file) of the VNF 22 instantiated on the virtual machine VM0, and instructs the new physical machine 20-2 to generate the VNF 22 according to the file.

The NFVI 21 of the new physical machine 20-2 starts a new virtual machine VM0 using the image file (step S07). The virtual machine VM0 on the new physical machine 20-2 runs on the new OS.

In the new physical machine 20-2, a conversion process related to the memory (variable expanded on the memory) is started (step S08). Specifically, the conversion process executed by the virtual machine VM0 on the new physical machine 20-2 converts (extends) the memory type (variable type expanded on the memory, data structure, etc.) and is old. Data from a virtual machine running on the old OS on the physical machine 20-1 can be accepted by the virtual machine VM0 running on the new OS. For example, if the data memory type of the old OS is "data a = 8byte", "data b = 8byte", "data c = 16byte", the conversion process executed by the virtual machine VM0 running on the new OS Converts its memory type according to the new OS, for example, "data a = 16byte", "data b = 16byte", "data c = 16byte". In this way, by expanding the memory type to the maximum corresponding to the new OS, the data from the virtual machine running on the old OS on the old physical machine 20-1 can be transferred to the virtual machine VM0 running on the new OS. Make it acceptable and absorb the difference in memory type of the old and new OS. Alternatively, the new OS may extend the same type of memory type. For example, if the memory type in the new OS is an int type, it may be converted to a Long type (from a 2-byte signed integer to a 4-byte signed integer). Similarly, the float type may be converted to the double type. The memory type conversion process is not limited to the above-mentioned expansion of the data size, but may be a reduction in size or conversion of other attributes and the like.

The VIM 13 provides the new physical machine 20-2 with an image file of a new OS that is an update of the old OS of the virtual machine VM0 (first virtual machine) that was running on the old physical machine 20-1. In the new physical machine 20-2, the new OS of the virtual machine VM0 (second virtual machine) is started by using the provided image file. The started virtual machine VM0 starts a conversion process and converts the memory type so as to accept data from the old OS of the virtual machine VM1 running on the old physical machine 20-1. This makes it possible to take over the memory between the old and new OS.

The virtual machine VM0 of the new physical machine 20-2 synchronizes data with the virtual machine VM1 (third virtual machine) operating on the old physical machine 20-1 (step S09). That is, on the old physical machine 20-1, the virtual machine VM0 and the virtual machine VM1 constituting the redundant system are operating (for example, the VM1 is switched from the standby system (standby system) to the active system (active system) and operates. Data is synchronized between the virtual machine VM1 and the virtual machine VM0 on the new physical machine 20-2. That is, in the virtual machine VM0 (new OS) on the new physical machine 20-2, the memory type is converted so that the data from the virtual machine VM1 (old OS) operating on the old physical machine 20-1 can be accepted. The difference between the old and new guest OS is absorbed. Therefore, data is synchronized between the virtual machines running on the old and new guest OSs.

The OSS instructs the virtual machine VM1 running on the old physical machine 20-1 to start the file update (OS update) (step S10).

The old physical machine 20-1 (NFVI21 of the machine) requests the VNFM12 to start the OS update of the virtual machine VM1 (step S11).

The VNFM 12 instructs the VIM 13 to start healing the virtual machine VM1 (step S12). In this case, the required VNF file is provided to the VIM 13.

The VIM 13 instructs the NFVI 21 of the old physical machine 20-1 to delete (stop) the virtual machine VM1 (step S13). In response to the instruction, the virtual machine VM1 is deleted in the old physical machine 20-1.

The VIM 13 instructs the new physical machine 20-2 (NFVI21 of the machine) to generate a new virtual machine VM1 (step S14). At that time, the VIM 13 provides the new physical machine 20-2 with an image file of the OS executed by the new virtual machine VM1, and instructs the new physical machine 20-2 to start the virtual machine VM1 by the image file.

The NFVI 21 of the new physical machine 20-2 starts a new virtual machine VM1 using the image file (step S15). The virtual machine VM1 runs on the new OS. Also, the new VNF22 will be started on the virtual machine VM1.

Data synchronization is performed between the virtual machines VM0 and VM1 started by the new physical machine 20-2 (step S16). In this way, the VIM 13 starts the virtual machine VM0 on the new physical machine 20-2, and then starts the virtual machine VM1 (fourth virtual machine) that constitutes a redundant system with the virtual machine VM0. Data synchronization is performed between the two virtual machines VM0 and VM1. In the first healed virtual machine VM0 (virtual machine VM0 generated in step S06), since the old and new OS coexist, the memory type conversion process was performed. However, the virtual machine VM1 (virtual machine VM1 generated in step S14) to be started after that operates on the new OS, and the virtual machine VM0 operates on the new OS. No type conversion is required.

[Hardware configuration]
FIG. 4 is a block diagram showing an example of the hardware configuration of the NFV-MANO (virtualization control device) 10 according to the first embodiment. The NFV-MANO 10 is a so-called information processing device (computer), and has the configuration illustrated in FIG. For example, the NFV-MANO 10 includes a CPU (Central Processing Unit) 41, a memory 42, an input / output interface 43, a communication means NIC (Network Interface Card) 44, and the like, which are connected to each other by an internal bus.

The configuration shown in FIG. 4 is not intended to limit the hardware configuration of the NFV-MANO10. The NFV-MANO 10 may include hardware (not shown). Alternatively, the number of CPUs and the like included in the NFV-MANO 10 is not limited to the example shown in FIG. 4, and for example, a plurality of CPUs may be included in the NFV-MANO 10.

The memory 42 is a RAM (Random Access Memory), a ROM (Read Only Memory), and an auxiliary storage device (hard disk or the like).

The input / output interface 43 is a means that serves as an interface for a display device or an input device (not shown). The display device is, for example, a liquid crystal display or the like. The input device is, for example, a device that accepts user operations such as a keyboard and a mouse.

As described above, in the first embodiment, the VNF file and the image file for the new OS are registered in the VNFM12 / VIM13, respectively. After that, when updating the file of VNF22, healing is carried out in cooperation with MANO. Specifically, the image file of the new OS is used to start Healing, and the new OS and the new VNF are started. That is, in the first embodiment, when updating the file of VNF22, the guest OS is restarted in order to activate the replaced file (image file).

When the guest OS is restarted, healing is performed in cooperation with MANO, healing is started using the image file of the new guest OS, and the new guest OS and the new VNF file are started. At that time, memory type conversion is performed, and memory (data) can be taken over between the old and new guest OS before and after the update or major version upgrade. As a result, the guest OS can be updated without affecting the user.

[Modification example]
The configuration and operation of the virtualization system described in the above embodiment are exemplary and can be modified in various ways. For example, in the above embodiment, the mode in which the VNFM 12 acquires the image file or the like has been described, but the NFVO 11 may acquire the image file or the like.

From the above description, the industrial applicability of the present invention is clear, but the present invention does not affect the end user such as a virtualized communication server (VNF) for 24 hours as in the case of non-virtualization. It can be suitably applied to systems that require stop operation.

The cited disclosures of Patent Document 1, Non-Patent Document 1, 2, etc. shall be renormalized and described in this document, and may be used as the basis or a part of the present invention as necessary. It shall be. Within the framework of the entire disclosure (including the scope of claims) of the present invention, it is possible to change or adjust the embodiments or examples based on the basic technical idea thereof. Further, various combinations or selections of various disclosure elements (including each element of each claim, each element of each embodiment or embodiment, each element of each drawing, etc.) within the framework of all disclosure of the present invention. (Including partial deletion) is possible. That is, it goes without saying that the present invention includes all disclosure including claims, and various modifications and modifications that can be made by those skilled in the art in accordance with the technical idea. In particular, with respect to the numerical range described in this document, it should be interpreted that any numerical value or small range included in the range is specifically described even if there is no other description. Further, each of the disclosed matters of the above-cited documents may be used in combination with the matters described in this document in part or in whole as a part of the disclosure of the present invention, if necessary, in accordance with the gist of the present invention. It is considered to be included in the disclosure matters of the present application.

10, 103 Virtualization controller (NFV-MANO)
11,111 NFVO
12, 112 VNFM
13, 113 VIM
20-1, 20-2 Physical Machine 21 NFVI
22 VNF
23 EMS
30 OSS / BSS
41 CPU (Central Processing Unit)
42 Memory 43 Input / output interface 44 NIC (Network Interface Card)
101 First physical machine 102 Second physical machine 201 File input unit 202 Healing control unit 211 NFVI control unit

Claims (9)

A first and second physical machine, each having an NFVI (Network Function Virtualization Infrastructure) that provides an execution platform for a virtualized VNF (Virtual Network Function) implemented by software running on a virtual machine.
NFVO (NFV-Orchestrator), which realizes network services on the NFVI,
A virtualization control device including a VNFM (VNF Manager) that manages the life cycle of the VNF and a VIM (Virtualized Infrastructure Manager) that manages and controls the resources of the NFVI.
Including
The VIM provides the second physical machine with an image file of a new guest OS that is an update of the old guest OS that was operating in the first virtual machine on the first physical machine.
In the second physical machine, the second virtual machine running on the new guest OS is started by using the image file of the new guest OS.
The second virtual machine is a network function virtualization system that converts a memory type so that data from the old guest OS can be accepted. The network function virtual according to claim 1, wherein the VIM provides an image file of the new guest OS to the second physical machine after deleting the first virtual machine on the first physical machine. Virtualization system. On the first physical machine, a third virtual machine operating on the old guest OS constitutes a redundant system with the first virtual machine.
After the first virtual machine is deleted on the first physical machine, the third virtual machine running on the old guest OS on the first physical machine and the second physical machine. The network function virtualization system according to claim 2, wherein data is synchronized with the second virtual machine operating on the new guest OS. After starting the second virtual machine on the second physical machine, the VIM forms a redundant system with the second virtual machine in the second physical machine and operates on the new guest OS. Start the 4th virtual machine and
The network function virtualization system according to claim 3, wherein in the second physical machine, data is synchronized between the second virtual machine and the fourth virtual machine. The VNFM provides the VIM with a file relating to the VNF instantiated on the second and fourth virtual machines.
The network function virtualization according to claim 4, wherein the VIM uses a file related to the VNF to instantiate the VNF on the second physical machine and the second and fourth virtual machines, respectively. system. A first and second physical machine, each having an NFVI (Network Function Virtualization Infrastructure) that provides an execution platform for a virtualized VNF (Virtual Network Function) implemented by software running on a virtual machine.
NFVO (NFV-Orchestrator), which realizes network services on the NFVI,
A virtualization control device including a VNFM (VNF Manager) that manages the life cycle of the VNF and a VIM (Virtualized Infrastructure Manager) that manages and controls the resources of the NFVI.
Is an operating system update method for systems that include
The VIM provides the second physical machine with an image file of a new guest OS that is an update of the old guest OS that was operating in the first virtual machine on the first physical machine.
In the second physical machine, the second virtual machine is started by using the image file of the new guest OS.
The second virtual machine converts the memory type so that it can accept the data from the old guest OS.
How to update the operating system. The operating system update according to claim 6, wherein the VIM provides an image file of the new guest OS to the second physical machine after deleting the first virtual machine on the first physical machine. Method. On the first physical machine, a third virtual machine operating on the old guest OS constitutes a redundant system with the first virtual machine.
After the first virtual machine is deleted on the first physical machine, the third virtual machine running on the old guest OS on the first physical machine and the second physical machine. The operating system update method according to claim 7, wherein data is synchronized with the second virtual machine operating on the new guest OS. After starting the second virtual machine on the second physical machine, the VIM forms a redundant system with the second virtual machine on the second physical machine and operates on the new guest OS. Start the 4th virtual machine and
The operating system update method according to claim 8, wherein in the second physical machine, data is synchronized between the second virtual machine and the fourth virtual machine.

Images