JP7184097B2 - Network function virtualization system and operating system update method - Google Patents

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 7, 2019), and the entire description of the application is incorporated herein by reference. shall be
The present invention relates to a network function virtualization system and an operating system update method.

NFV (Network Functions Virtualization) realizes the functions of network devices, etc. in software by means of a virtual machine (VM) implemented on a virtualization layer such as a hypervisor (HV) on a server. known (see, for example, Non-Patent Documents 1 and 2). FIG. 5 is a simplified drawing of Chapter 7 of Non-Patent Document 2, FIG.

A VNF (Virtualized Network Function) 22 corresponds to an application or the like that operates on a virtual machine (VM) on a server, and implements a network function by software. A management function called EM (Element Manager) 23 (also called EMS (Element Manage System)) is provided for each VNF 22 .

NFVI (Network Functions Virtualization Infrastructure) 21 is a virtualized computing, virtualized storage, virtual It is a platform that can be flexibly handled as a virtualized hardware resource such as a virtualized network.

NFV Orchestrator (NFV Orchestrator: NFVO) 11 of NFV-MANO (NFV Management & Orchestration) 10 performs resource orchestration of NFVI 21 and network service (NS) instance life cycle management (NS instance instance Instantiation, Scaling, Termination, Update, etc.).

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

A virtualized infrastructure manager (VIM) 13 performs computing, storage, and network resource management of the NFVI 21, fault monitoring of the NFVI 21, resource monitoring of the NFVI 21, and the like.

OSS (Operations Support Systems) of the OSS/BSS 30 is a general term for systems (equipment, software, mechanism, etc.) necessary for, for example, a communication carrier (carrier) to build and operate services. BSS (Business Support Systems) is a general term for information systems (equipment, software, mechanism, etc.) used by, for example, telecommunications carriers (carriers) for billing such as usage fees, billing, customer correspondence, and the like.

Patent Document 1 discloses a virtual infrastructure management device, a virtual network function management device, a virtual machine management method, and a virtual machine management method that can contribute to preventing interruption of a service that has been stably running due to the above-mentioned healing and scaling. It is stated that the purpose is to provide a program.

WO2017/002812

ETSI GS NFV-MAN 001 V1.1.1 (2014-12) Network Functions Virtualization (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 Virtualization (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 is incorporated into this document by reference. The following analysis was made by the inventors.

The NFVO 11, VNFM 12, VIM 13, etc. mentioned above are functional entities for managing the network system. The control of these functional entities creates virtual machines and VNFs on physical machines (PMs).

In a VNF environment network system, an image file required for instantiation of the VNF 22 is provided to the VIM 13 from the OSS or the like. The VIM 13 provides the provided image file to the NFVI 21, and the VNF 22 is instantiated by the image file.

The image file contains data necessary for instantiation of the VNF 22. Specifically, program data related to OS (Operating System), MW (Middleware), and APL (Application) executed in the virtual machine. includes. The VNF 22 instantiated by the image file has its behavior 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, for the purpose of improving the functions of the VNF 22, updating the OS (guest OS) by a different distributor, or major version up of the OS by the same distributor (significant functional enhancement and performance improvement from the old version) , a version upgrade that makes significant improvements and corrections, such as changing the data format) may be implemented. In this document, the guest OS (OS that runs on a virtual machine) is simply " It is abbreviated as OS.

When updating the guest OS, for example, an update procedure (rolling update) using healing is performed. Healing is a process of restoring 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. procedure. Also, in a rolling update, in a system that consists of multiple machines, etc., by sequentially updating each part, it is possible to update the software of the system without completely stopping the system. 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 version upgrade is running). The virtual machine VM0 and the virtual machine VM1 constitute a redundant system in which one functions as the active system while the other functions as a standby system. reference). This data synchronization is for synchronizing data between the virtual machine VM0 and the virtual machine VM1 as a cluster. For example, when data is updated in a working (active) virtual machine, the updated data is transferred to a standby (standby) virtual machine as replicated data, and the data is transferred between the working and standby systems. Synchronization is sometimes done to enable recovery of data to the most recent state and increase availability.

The OSs of the virtual machine VM0 and the virtual machine VM1 operating on the old physical machine are updated. At that time, the boot destination of the virtual machine VM0 is changed from the old physical machine to the new physical machine. Specifically, the virtual machine VM0 is healed, and the virtual machine VM0 with the updated OS is activated on the new physical machine. Hereinafter, the OS before the update is called the old OS, and the OS after the update is called 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 break in FIG. 6). After that, the virtual machine VM1 is healed, and the virtual machine VM1 running on the new OS is activated on the new physical machine. The virtual machine VM0 and the virtual machine VM1 operating on the new physical machine perform data synchronization (see the lower part of FIG. 6).

The above is the OS update procedure using healing. In FIG. 6, the shades of colors assigned to the configurations of the virtual machines VM0 and VM1 indicate different versions of the OS.

When updating the OS of the virtual machine, for example, in FIG. 5, the OSS issues a healing start instruction to the VNFM 12 . The instruction is notified from VNFM 12 to VIM 13 . 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 the new physical machine with an image file corresponding to the new OS, and instructs the image file to start up the new virtual machine VM0.

Thereafter, data synchronization is performed between the virtual machine VM1 operating on the old physical machine and the virtual machine VM0 operating on the new physical machine. At this time, if the memory structure of the virtual machine VM1 running on the old OS (variable types and data structures expanded on the memory, etc.) matches the memory structure of the virtual machine VM1 running on the new OS, the above Data syncing works fine, and OS updates can be done without service interruption.

However, with OS updates (updates) by different distributors and major OS version upgrades, the memory structures of the old and new OSs are different, and data is transferred between the virtual machine VM1 running on the old OS and the virtual machine VM1 running on the new OS. Synchronization may not be possible. In other words, if the compatibility between the old and new OSs is not supported, such as the type of memory that should be synchronized between the virtual machines of the old and new OSs, the data cannot be synchronized between the virtual machines of the old and new OSs. Therefore, service may be interrupted due to OS updates, major version upgrades, and the like. As a result, the users receiving the service will be affected.

SUMMARY OF THE INVENTION The main object of the present invention is to provide a network function virtualization system and an operating system update method that enable the version of the guest OS of a virtual machine to be updated without interrupting the service being provided.

According to the first aspect of the present invention or disclosure, each has an NFVI (Network Function Virtualization Infrastructure) that provides an execution base for a VNF (Virtual Network Function) implemented and virtualized by software running on a virtual machine NFVO (NFV-Orchestrator) that realizes network services, VNFM (VNF Manager) that manages the life cycle of the VNF, and resource management and control of the NFVI on the first and second physical machines and the NFVI. and a virtualization control device comprising a VIM (Virtualized Infrastructure Manager) that performs the new guest OS that updates the old guest OS running in the first virtual machine on the first physical machine. An image file is provided to the second physical machine, and in the second physical machine, a second virtual machine running on the new guest OS is activated using the image file of the new guest OS, and 2 is provided with a network function virtualization system that converts memory types to accept data from the old guest OS.

According to a second aspect of the present invention or disclosure, each has an NFVI (Network Function Virtualization Infrastructure) that provides an execution base for a VNF (Virtual Network Function) implemented and virtualized by software running on a virtual machine. NFVO (NFV-Orchestrator) that realizes network services, VNFM (VNF Manager) that manages the life cycle of the VNF, and resource management and control of the NFVI on the first and second physical machines and the NFVI. and a virtualization controller comprising a VIM (Virtualized Infrastructure Manager) that performs an operating system update method in a system,
The VIM provides, to the second physical machine, an image file of a new guest OS, which is an updated version of the old guest OS running on the first virtual machine on the first physical machine;
In the second physical machine, a second virtual machine is activated using the image file of the new guest OS,
An operating system update method is provided in which the second virtual machine converts a memory type to accept data from the old guest OS.

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

1 is a diagram for explaining an overview of an embodiment; FIG. 1 is a diagram illustrating an example of a configuration of a network system according to a first embodiment; FIG. 4 is a sequence diagram illustrating an example of the operation of the virtualization system according to the first embodiment; FIG. 3 is a diagram illustrating an example of a hardware configuration of a virtualization control device according to the first embodiment; FIG. 7 is a simplified diagram of Figure 4 in Chapter 7 of Non-Patent Document 2. FIG. FIG. 4 is a diagram schematically illustrating an example of OS update using healing;

First, an overview of one embodiment will be described. It should be noted that the drawing reference numerals added to this outline are added to each element for convenience as an example to aid understanding, and the description of this outline does not intend any limitation. Also, connecting lines between blocks in each figure include both bi-directional and uni-directional. The unidirectional arrows schematically show the flow of main signals (data) and do not exclude bidirectionality. Furthermore, in the circuit diagrams, block diagrams, internal configuration diagrams, connection diagrams, etc. disclosed in the present application, an input port and an output port exist at the input end and the output end of each connection line, respectively, although not explicitly shown. Input/output interfaces are similar.

A network function virtualization system according to one embodiment includes first and second physical machines 101 and 102 and a virtualization controller 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 base for a VNF (Virtual Network Function) implemented and virtualized by software running on a virtual machine. . The virtualization controller 103 includes an NFVO (NFV-Orchestrator) 111 , a VNFM (VNF Manager) 112 and a VIM (Virtualized Infrastructure Manager) 113 . The NFVO 111 implements network services on the NFVI. VNFM 112 manages the VNF lifecycle. VIM 113 performs resource management and control of NFVI. The VIM 113 provides the second physical machine 102 with the image file of the new OS corresponding to the old OS running on the first virtual machine on the first physical machine 101 . In the second physical machine 102, the provided image file is used to boot the new OS on the second virtual machine, and the booted new OS is transferred from the old OS running on the first physical machine 101. convert the memory type to accept the data of

The virtualization control device 103 performs healing by cooperation of NFV-MANO (NFVO, VNFM, VMI) at the restart timing of the OS (guest OS) when updating the VNF file, for example. At that time, by executing a memory type conversion process, differences in memory types between the old and new OSs are 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 addition, the same code|symbol is attached|subjected to the same component in each embodiment, and the description is abbreviate|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 functions of the network system (network function virtualization system) according to the first embodiment. 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 of updating the OS (guest OS) of the virtual machine VM running on the physical machine 20-1 will be described. At that time, the virtualization controller (NFV-MANO) 10 according to the first embodiment heals the virtual machine VM in the physical machine 20-2. The NFV-MANO 10 updates the OS of the virtual machine VM during 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 for a VNF (Virtual Network Function) 22 implemented and virtualized by software operating on a virtual machine.

NFV-MANO 10 consists of NFVO (NFV-Orchestrator) 11 that realizes network services on NFVI 21, VNFM (VNF Manager) 12 that manages the lifecycle of VNF 22, and VIM (Virtualized VIM) that manages and controls resources of NFVI 21. Infrastructure Manager) 13;

The VNFM 12 has a file input section 201 and a healing control section 202 .

The file input unit 201 is means for inputting a file for the new OS from an external device (for example, OSS). 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 VNF to be instantiated, and is stored in a storage unit or the like accessible by the VNFM 12 .

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

A healing control unit 202 is means for controlling healing by the VIM 13 . The healing control unit 202 provides the VNF file for the new OS to the VIM 13 and requests the VIM 13 to perform healing of the virtual machine using this file and the previously stored image file.

The VIM 13 has an NFVI control section 211 .

The NFVI control unit 211 is means for processing healing requests and the like from the VNFM 12 described above. Specifically, the NFVI control unit 211 uses the files (VNF file, image file) to generate the virtual machine VNF 22 and instructs the NFVI 21 to start it.

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 virtual machine VM to be updated (VNF to be updated), and the OS of the virtual machine VM is updated during 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.

Next, operations of the virtualization system according to the first embodiment will be described. FIG. 3 is a sequence diagram illustrating an example of the operation of the virtualization system according to the first embodiment;

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

When updating the OS of the virtual machine, for example, the OSS issues a healing start instruction to the old physical machine 20-1 (NFVI 21) (step S02).

The virtual machine VM0 (NFVI 21 of the old physical machine 20-1) requests the VNFM 12 to start updating the OS of the virtual machine VM0 (step S03).

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

The VIM 13 instructs the old physical machine 20-1 (NFVI 21) to delete (stop) the virtual machine VM0 (step S05). In accordance with the instruction, the virtual machine VM0 is deleted from the old physical machine 20-1.

The VIM 13 instructs the new physical machine 20-2 (the NFVI 21 of this machine) to create a new virtual machine VM0 (step S06). At this time, the VIM 13 provides the new physical machine 20-2 with an image file of the OS to be executed in the new virtual machine VM0, and instructs the virtual machine VM0 to start up with the image file. The VIM 13 also provides the new physical machine 20-2 with the VNF file (setting file) of the VNF 22 instantiated on the virtual machine VM0, and instructs the generation of the VNF 22 according to the file.

The NFVI 21 of the new physical machine 20-2 uses the image file to activate the new virtual machine VM0 (step S07). The virtual machine VM0 on the new physical machine 20-2 operates with the new OS.

In the new physical machine 20-2, a conversion process for memory (variables developed 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, data structure, etc. expanded on the memory), 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 types of the old OS are "data a = 8byte", "data b = 8byte", and "data c = 16byte", the conversion process executed by the virtual machine VM0 running on the new OS converts the memory type to correspond 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 extent 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. It is acceptable and absorbs the difference in memory types of the old and new OSs. Alternatively, the new OS may extend the same kind of memory type. For example, if the memory type in the new OS is int type, it may be converted to Long type (2-byte signed integer to 4-byte signed integer). Similarly, float type may be converted to double type. The memory type conversion processing is not limited to expansion of the data size described above, and may be size reduction or conversion of other attributes.

The VIM 13 provides the new physical machine 20-2 with an image file of the new OS, which is the updated old OS of the virtual machine VM0 (first virtual machine) 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 using the provided image file. The activated virtual machine VM0 starts a conversion process and converts the memory type so that data from the old OS of the virtual machine VM1 running on the old physical machine 20-1 can be accepted. As a result, memory can be handed over between the old and new OSs.

The virtual machine VM0 of the new physical machine 20-2 synchronizes data with the virtual machine VM1 (third virtual machine) running on the old physical machine 20-1 (step S09). That is, on the old physical machine 20-1, a virtual machine VM1 that constitutes a redundant system with the virtual machine VM0 is operating (VM1 is switched from a standby system to an active system, for example, and operates). ), data synchronization is performed 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 it can accept data from the virtual machine VM1 (old OS) running on the old physical machine 20-1. Then, the difference between the new and old guest OS is absorbed. Therefore, data synchronization is performed between the virtual machines running on the new and old guest OSs.

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

The old physical machine 20-1 (NFVI 21 of the machine) requests the VNFM 12 to start updating the OS of the virtual machine VM1 (step S11).

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

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 from the old physical machine 20-1.

The VIM 13 instructs the new physical machine 20-2 (NFVI 21 of the machine) to create a new virtual machine VM1 (step S14). At this time, the VIM 13 provides the new physical machine 20-2 with an image file of the OS to be executed by the new virtual machine VM1, and instructs the virtual machine VM1 to start up with the image file.

The NFVI 21 of the new physical machine 20-2 uses the image file to activate the new virtual machine VM1 (step S15). The virtual machine VM1 operates on the new OS. A new VNF 22 is also activated 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, after starting the virtual machine VM0 on the new physical machine 20-2, the VIM 13 starts the virtual machine VM1 (fourth virtual machine) forming 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), the old and new OSs coexist, so the memory type conversion process was performed. However, the virtual machine VM1 (virtual machine VM1 generated in step S14) to be started later 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 such as a NIC (Network Interface Card) 44, etc., which are interconnected by an internal bus.

Note that the configuration shown in FIG. 4 is not intended to limit the hardware configuration of the NFV-MANO 10. FIG. NFV-MANO 10 may include hardware not shown. Alternatively, the number of CPUs included in the NFV-MANO 10 is not limited to the example shown in FIG. 4, and the NFV-MANO 10 may include a plurality of CPUs.

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

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

As described above, in the first embodiment, the VNF file for the new OS and the image file are registered in the VNFM 12/VIM 13, respectively. After that, when the VNF 22 file is updated, healing will be performed in cooperation with MANO. Specifically, Healing is activated using the image file of the new OS, and the new OS and the new VNF are activated. That is, in the first embodiment, the guest OS is restarted in order to validate the replaced file (image file) when updating the file of the VNF 22 .

When the guest OS is restarted, healing is performed by 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 handed over between new and old guest OSs before and after updates and major version upgrades. As a result, it is possible to update the guest OS without affecting the user.

[Modification]
The configuration and operation of the virtualization system described in the above embodiments are examples, and various modifications are possible. For example, in the above embodiment, the VNFM 12 acquires the image file and the like, but the NFVO 11 may acquire the image file and the like.

From the above description, the industrial applicability of the present invention is clear. It can be suitably applied to a system that requires stop operation.

It should be noted that the disclosures of the above cited Patent Document 1, Non-Patent Documents 1, 2, etc. are incorporated herein by reference, and can be used as the basis or part of the present invention as necessary. shall be Within the framework of the full disclosure of the present invention (including the scope of claims), modifications and adjustments of the embodiments and examples are possible based on the basic technical concept thereof. Also, various combinations or selections of various disclosure elements (including each element of each claim, each element of each embodiment or example, each element of each drawing, etc.) within the framework of the full disclosure of the present invention (including partial deletion) is possible. That is, the present invention naturally includes various variations and modifications that can be made by those skilled in the art according to the entire disclosure including claims and technical ideas. In particular, any numerical range recited herein should be construed as specifically recited for any numerical value or subrange within that range, even if not otherwise stated. Furthermore, each disclosure item of the above-cited document can be used in combination with the items described in this document as part of the disclosure of the present invention in accordance with the spirit of the present invention, if necessary. are considered to be included in the disclosure of the present application.

10, 103 Virtualization control device (NFV-MANO)
11, 111 NFVO
12, 112 VNFM
13, 113 VIM
20-1, 20-2 physical machine 21 NFVI
22 VNFs
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 (8)

first and second physical machines each having a NFVI (Network Function Virtualization Infrastructure) that provides an execution base for a VNF (Virtual Network Function) implemented and virtualized by software running on the virtual machine;
NFVO (NFV-Orchestrator) for realizing network services on the NFVI,
a virtualization controller comprising a VNFM (VNF Manager) for managing the life cycle of the VNF and a VIM (Virtualized Infrastructure Manager) for managing and controlling the resources of the NFVI;
including
The VIM provides, to the second physical machine, an image file of a new guest OS (Operating System), which is an updated version of an old guest OS (Operating System) running in the first virtual machine on the first physical machine;
In the second physical machine, a second virtual machine running on the new guest OS is activated using the image file of the new guest OS,
The second virtual machine converts a memory type so that data from the old guest OS can be accepted,
A network function virtualization system, 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. On the first physical machine, a third virtual machine running on the old guest OS configures 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 on the second physical machine 2. The network function virtualization system according to claim 1 , wherein data synchronization is performed with said second virtual machine running on said new guest OS. After starting the second virtual machine on the second physical machine, the VIM configures a redundant system with the second virtual machine and operates on the new guest OS in the second physical machine. Start a fourth virtual machine,
3. The network function virtualization system according to claim 2 , wherein data synchronization is performed between said second virtual machine and said fourth virtual machine in said second physical machine. the VNFM provides the VIM with files relating to VNFs instantiated on the second and fourth virtual machines;
4. The network function virtualization of claim 3 , wherein the VIM uses a file for the VNF to instantiate the VNF on the second and fourth virtual machines, respectively, on the second physical machine. system. first and second physical machines each having a NFVI (Network Function Virtualization Infrastructure) that provides an execution base for a VNF (Virtual Network Function) implemented and virtualized by software running on the virtual machine;
NFVO (NFV-Orchestrator) for realizing network services on the NFVI,
a virtualization controller comprising a VNFM (VNF Manager) for managing the life cycle of the VNF and a VIM (Virtualized Infrastructure Manager) for managing and controlling the resources of the NFVI;
A method for updating an operating system in a system comprising:
The VIM provides, to the second physical machine, an image file of a new guest OS (Operating System), which is an updated version of an old guest OS (Operating System) running in the first virtual machine on the first physical machine;
In the second physical machine, a second virtual machine is activated using the image file of the new guest OS,
The second virtual machine converts a memory type so that data from the old guest OS can be accepted,
The operating system update method, 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. A third virtual machine running on the old guest OS on the first physical machine forms 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 on the second physical machine 6. The operating system update method according to claim 5 , wherein data synchronization is performed with said second virtual machine running on said new guest OS. After starting the second virtual machine on the second physical machine, the VIM configures a redundant system with the second virtual machine on the second physical machine and operates on the new guest OS. Start a fourth virtual machine that
7. The operating system update method according to claim 6 , wherein data synchronization is performed between said second virtual machine and said fourth virtual machine in said second physical machine. the VNFM provides the VIM with files relating to VNFs instantiated on the second and fourth virtual machines;
8. The method of claim 7, wherein the VIM instantiates the VNFs on the second and fourth virtual machines, respectively, on the second physical machine using files related to the VNFs. .

Images