Software update control device and software update control method

Abstract

This software update control device includes: a generation unit configured to generate, for each of an old version of a first system and an old version of a second system that are an active system and a standby system, respectively, of a virtual environment before software is updated, a new version for which the software has been updated and which has different address information than the old version; a first switching unit configured to stop the old version second system, assign the same address information as that of the old version to the new version second system, and switch over the active system to the new version second system; and a second switching unit configured to stop the old version first system, assign the same address information as that of the old version to the new version first system, and switch over the active system to the new version first system. With this configuration, the software update control device enables efficient software update while enabling rollback whenever possible.

Description

Software update control device and software update control method

[0001] The present invention relates to a software update control device and a software update control method.

[0002] Network Functions Virtualization (NFV) is a technology that virtualizes the network functions of multiple devices on a virtualization platform such as a general-purpose server, building them as Virtualized Network Functions (VNFs). VNFs such as routers and UPFs (5GC) are made highly available by using a redundant configuration such as an Active / Standby configuration.

[0003] Therefore, it is required to avoid communication interruptions as much as possible even during software updates related to VNFs, and to be able to roll back if a problem occurs after the update.

[0004] Conventional software update techniques for an active / standby configuration include rolling update and blue-green deployment (also called "blue-green update").

[0005] As shown in FIG. 1, rolling update is a technology for performing an uninterrupted update by switching between Active and Standby and updating each of them (Non-Patent Document 1).

[0006] Blue-green deployment is a technology in which a new version is created (deployed) while maintaining the currently running VNF, and the old version is deleted (undeployed) after the switchover, as shown in Figure 2 (Non-Patent Document 2).

[0007] 1 and 2 show an example of updating a VNF that functions as a device for routing packets between network devices.

[0008] Cisco Systems, "In-Service Software Upgrade (ISSU)," [online], Internet <URL: https: / / www.cisco.com / c / ja_jp / td / docs / switches / lan / catalyst_standalones / b-in-service-software-upgrade-issu.html> Red Hat, "What is Blue-Green Deployment?" [online], Internet <URL: https: / / www.redhat.com / ja / topics / devops / what-is-blue-green-deployment>

[0009] While a rolling update has the advantage of allowing updates without increasing the amount of resources used, it has the disadvantage that it is difficult to roll back (roll back from the new version to the old version) if a problem occurs after the update.

[0010] While blue-green deployment has the advantage of allowing rollback if a problem occurs after an update because the old version remains, it also has the disadvantage of temporarily increasing resource usage during the update. Furthermore, with blue-green deployment, the MAC and IP addresses of the VNF interfaces change before and after the update. While IP addresses can be shared between old and new versions using virtual IP (VIP) technology or load balancers, the same MAC address of a VNF interface cannot be used simultaneously. Therefore, the impact of changes to the MAC and IP addresses of VNF interfaces ripples through to the opposing communication nodes. For example, an orchestrator that controls a VNF may recognize the updated VNF as a separate resource due to a change in the VNF's MAC address. The orchestrator issues control commands to the VNF, such as deploying, undeploying, and changing data. However, because the old and new VNFs are recognized as separate entities, control commands issued to the old version of the VNF are not carried over to the new version, causing inconvenience to VNF operators. Therefore, it is necessary to switch (rewrite) the MAC addresses stored in the peer communication node and to switch the VNF control history association stored in the orchestrator DB between the old and new versions. However, performing such a switch for all VNFs to be updated would result in high operational costs. Note that when blue-green deployment is applied to web applications rather than VNFs, such operational cost issues do not arise because DNS or a load balancer can be used to switch from the old version to the new version by switching the IP address that responds to domain name or IP address queries from web application clients. However, VNFs are virtual network devices such as virtual routers and virtual switches, and the peer device recognizes and communicates the MAC address and IP address pair information. However, switching at the layer like a DNS or load balancer is not possible for MAC addresses, making it difficult to apply DNS or a load balancer.

[0011] The present invention has been made in view of the above points, and an object of the present invention is to make it possible to perform efficient software updates while enabling switchback as much as possible.

[0012] In order to solve the above problem, the software update control device has a generation unit configured to generate a new version in which the software is updated, with address information different from that of the old version for each of the first system, which is the active system, and the second system, which is the standby system, of the old version of the virtual environment before the software update; a first switching unit configured to stop the second system of the old version, assign the second system of the new version the same address information as that of the old version, and switch the active system to the second system of the new version; and a second switching unit configured to stop the first system of the old version, assign the first system of the new version the same address information as that of the old version, and switch the active system to the first system of the new version.

[0013] This makes it possible to perform efficient software updates while allowing switchback as much as possible.

[0014] FIG. 1 is a diagram for explaining a rolling update. FIG. 2 is a diagram for explaining a blue-green deployment. FIG. 3 is a diagram showing a configuration example of a software update control system 1 in a first embodiment. FIG. 4 is a diagram showing a hardware configuration example of a software update control device 10 in a first embodiment. FIG. 5 is a diagram showing a functional configuration example of the software update control device 10 in a first embodiment. FIG. 6 is a diagram showing a configuration example of an address information storage unit 13. FIG. 7 is a diagram showing a configuration example of address remainder information. FIG. 8 is a diagram for explaining a VNF update method in a first embodiment. FIG. 9 is a diagram for explaining a VNF update method in a second embodiment.

[0015] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Fig. 3 is a diagram showing an example of the configuration of a software update control system 1 according to a first embodiment. In Fig. 3, a software update control device 10 is capable of communicating with one or more virtualization platforms 20 via a network.

[0016] The virtualization platform 20 is software capable of deploying virtualized nodes. The virtualization platform 20 is, for example, a Network Functions Virtualization (NFV) platform capable of deploying one or more Virtualized Network Functions (VNFs). The virtualization platform 20 has a one-to-one correspondence with nodes. A node is realized by one or more computers (physical servers) that constitute a cluster. The virtualization platform 20 may be a virtualization platform 20 in an on-premise environment such as OpenStack (registered trademark) or VMware (registered trademark), or may be a cloud platform such as AWS.

[0017] A VNF is a virtualizable network function (an example of a virtual environment that functions as a device that handles packets, such as a virtual router or a UPF). A VNF may be realized by a virtual machine (VM), or may be realized by a container or a virtual routing and forwarding (VRF) that virtually separates functions.

[0018] The software update control device 10 is one or more computers (for example, general-purpose servers) that control software updates (hereinafter simply referred to as "updates" or "updates") for VNFs.

[0019] 4 is a diagram showing an example of the hardware configuration of the software update control device 10 according to the first embodiment. The software update control device 10 in FIG. 4 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a processor 104, and an interface device 105, all of which are interconnected via a bus B.

[0020] A program that realizes the processing in the software update control device 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program does not necessarily have to be installed from the recording medium 101, but may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program as well as necessary files, data, etc.

[0021] When an instruction to start a program is received, the memory device 103 reads and stores the program from the auxiliary storage device 102. The processor 104 is a CPU or a GPU (Graphics Processing Unit), or a CPU and a GPU, and executes functions related to the software update control device 10 in accordance with the program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network.

[0022] Fig. 5 is a diagram showing an example of the functional configuration of the software update control device 10 according to the first embodiment. In Fig. 5, each of the multiple virtualization platforms 20 includes a resource management unit 21 in addition to one or more VNFs. The resource management unit 21 manages the usage status (in other words, availability) of resources (CPU, RAM, DISK, NW (list of assignable IP addresses and MAC addresses)) of the node functioning as the virtualization platform 20. The resource management unit 21 also assigns address information such as a MAC address and an IP address when a VNF is created (deployed), and releases the assigned address information when the VNF is deleted.

[0023] In Figure 5, differences between VNFs are distinguished by the type of VNF-N. Figure 5 shows an example in which three types of VNFs are deployed, since there are VNFs with N values ​​of 1, 2, and 3. Furthermore, for each VNF-N, the system marked "Act" indicates the active system, and the system marked "Sby" indicates the standby system. Therefore, Figure 5 shows an example in which VNF-1 Act is deployed as the active system for VNF-1, and VNF-1 Sby is deployed as the standby system. Furthermore, Figure 5 shows an example in which VNF-2 Act is deployed as the active system for VNF-2, and VNF-2 Sby is deployed as the standby system. Furthermore, Figure 5 shows an example in which VNF-3 Act is deployed as the active system for VNF-3, and VNF-3 Sby is deployed as the standby system. In Figure 5, for convenience, the active system (Act) and standby system (Sby) for each VNF appear to be deployed on the same virtualization platform 20, but in reality, the active system and standby system for each VNF are deployed on different virtualization platforms 20 to reduce the impact of a single physical failure.

[0024] On the other hand, the software update control device 10 has a resource status monitoring unit 11 and an update control unit 12. Each of these units is realized by processing executed by the processor 104 of one or more programs installed in the software update control device 10. The software update control device 10 also uses an address information storage unit 13. The address information storage unit 13 can be realized using, for example, an auxiliary storage device 102 or a storage device connectable to the software update control device 10 via a network.

[0025] As shown in FIG. 6, the address information storage unit 13 stores address information including a MAC address and an IP address assigned to a virtual interface of each VNF.

[0026] The resource status monitoring unit 11 monitors information (hereinafter referred to as "address remaining information") indicating how much address information (IP addresses and MAC addresses) each virtualization platform 20 has remaining that can be assigned to VNFs, and stores the address remaining information in the memory device 103 or the auxiliary storage device 102.

[0027] Fig. 7 is a diagram showing an example of the configuration of address remaining information. As shown in Fig. 7, the address remaining information includes, for each virtualization platform 20, the ratio of the remaining number to the number that can be assigned for MAC addresses and IP addresses (hereinafter referred to as "remaining rate"). Note that Fig. 7 shows an example in which the number of MAC addresses and IP addresses that can be assigned or the number of assigned addresses vary. Note that a list of IP addresses and MAC addresses that a certain virtualization platform 20 can assign to VNFs can be obtained from the resource management unit 21 of that virtualization platform 20.

[0028] When updating a VNF, the update control unit 12 checks the availability of a list of IP addresses and MAC addresses that can be assigned to the virtualization platform 20 on which the VNF is deployed, and if there are one or more IP addresses and one or more MAC addresses that can be assigned to the VNF to be updated (that is, if the remaining rates of both the IP address and MAC address of the VNF in the address remaining information (FIG. 7) are not 0), the update control unit 12 executes the update of the VNF. The update control unit 12 includes a generation unit 121, a first switching unit 122, and a second switching unit 123.

[0029] Note that a VNF update refers to an OS update or software version upgrade at the VM level (virtual resources such as VMs and containers).

[0030] FIG. 8 is a diagram illustrating a VNF update method according to the first embodiment. The first embodiment discloses a method of deploying VNFs to both the active and standby systems. The update is performed in the order of steps (1) to (7) in FIG. 8. In FIG. 8, "VNF 0 system" (hereinafter simply referred to as "0 system") indicates the VNF of the original (original) active system (Act), and "VNF 1 system" (hereinafter simply referred to as "1 system") indicates the VNF of the original (original) standby system (Sby). During the update process, the active system switches between system 0 and system 1. The following steps are implemented by API operations of the virtualization platform 20 by the generation unit 121, first switching unit 122, or second switching unit 123 of the update control unit 12.

[0031] In step (1), system 0 is the active system and system 1 is the standby system. In this state, an update is started.

[0032] In step (2), the generation unit 121 generates (deploys) an updated instance of system 1 (hereinafter also referred to as "new version of system 1") (2-1), and assigns to the new version of system 1 (VNF' system 1) a MAC address and an IP address that are different from those of the old version of system 1, among the MAC addresses and IP addresses that can be assigned in the virtualization platform 20 where system 1 before the update (hereinafter referred to as "old version of system 1") is deployed (2-2). Therefore, a new version having a MAC address and IP address different from those of the old version is generated for system 1.

[0033] The new version means a VNF after a software update. The MAC addresses and IP addresses that can be assigned in the virtualization platform 20 where the first system is deployed and the MAC addresses and IP addresses of the old version of the first system can be acquired from the resource management unit 21 of the VNF where the old version of the first system is deployed.

[0034] In step (3), the first switching unit 122 stops the old version 1 system (3-1), switches the standby system from the old version to the new version 1 system (VNF' 1 system) (3-2), and then assigns the same MAC address and IP address as the old version 1 system to the new version 1 system (VNF' 1 system) (3-3).

[0035] In step (4), the first switching unit 122 switches the active system from the old system 0 to the new system 1 (VNF' system 1) (4-1). Next, the generation unit 121 generates (deploys) a new version "VNF' system 0" for system 0 (4-2) and assigns a MAC address and IP address different from those of the old system 0 to the new version (VNF' system 0) (4-3). Therefore, a new version having a MAC address and IP address different from those of the old version is generated for system 0.

[0036] In step (5), the second switching unit 123 stops the old system 0 (5-1) and assigns the same MAC address and IP address as the old system 0 to the new system 0 (VNF' system 0) (5-2).

[0037] In step (6), the second switching unit 123 switches the active system from the new version of system 1 to the new version of system 0. As a result, the pre-update MAC addresses and IP addresses are retained for both the active system and the standby system.

[0038] If no problem occurs for a certain period of time thereafter, the second switching unit 123 deletes the old version 0 system and the old version 1 system (7).

[0039] Next, a second embodiment will be described. In the second embodiment, differences from the first embodiment will be described. Points not specifically mentioned in the second embodiment may be the same as those in the first embodiment.

[0040] FIG. 9 is a diagram illustrating a VNF update method according to the second embodiment. The second embodiment discloses a method for simultaneously deploying both active and standby VNFs. The update is performed in the order of steps (1) to (6) in FIG. 9 . In FIG. 9 , "VNF 0" (hereinafter simply referred to as "0") indicates the VNF of the original (original) active system (Act), and "VNF 1" (hereinafter simply referred to as "1") indicates the VNF of the original (original) standby system (Sby). During the update process, the active system switches between system 0 and system 1. Each of the following steps is realized by API operations of the virtualization platform 20 by the generation unit 121, first switching unit 122, or second switching unit 123 of the update control unit 12.

[0041] In step (1), system 0 is the active system and system 1 is the standby system. In this state, an update is started.

[0042] In step (2), the generation unit 121 generates (deploys) updated instances (new versions) for both the 0 system and the 1 system (2-1), and assigns MAC addresses and IP addresses different from those of the old versions to the new versions of each system ("VNF' 0 system", "VNF' 1 system") (2-2). Therefore, in the second embodiment, new versions are generated for each of the 0 system and the 1 system before the first switching unit 122 executes switching.

[0043] In step (3), the first switching unit 122 stops the old version 1 system (3-1), switches the standby system from the old version to the new version 1 system (VNF' 1 system) (3-2), and then assigns the same MAC address and IP address as the old version 1 system to the new version 1 system (VNF' 1 system) (3-3).

[0044] In step (4), the first switching unit 122 switches the active system to the new version of system 1 (VNF' system 1) (4-1). Subsequently, the second switching unit 123 stops the old version of system 0 (4-2) and assigns the same MAC address and IP address as the old version of system 0 to the new version of system 0 (VNF' system 0) (4-3).

[0045] In step (5), the second switching unit 123 switches the active system from the new version of system 1 to the new version of system 0. As a result, the pre-update MAC addresses and IP addresses are retained for both the active system and the standby system.

[0046] If no problem occurs for a certain period of time thereafter, the second switching unit 123 deletes the old version 0 system and the old version 1 system (6).

[0047] As described above, in the first embodiment, up to step (6) of FIG. 8 , and in the second embodiment, up to step (5) of FIG. 9 , the old versions of both the 0-system and 1-system remain (the instances are stopped, but the data of the old version of the software remains), so even if a problem occurs with the update, switchback is possible. Furthermore, for both the 0-system and 1-system, instances with MAC addresses and IP addresses different from those of the old version are temporarily generated, but in the final state after the update, the new version operates using the MAC address and IP address used by the old version. As a result, it is possible to eliminate the need to switch settings on the communication node opposite the VNF, and it is also possible for the orchestrator to recognize the new version as the same instance as the old version. Therefore, according to each of the above embodiments, it is possible to perform efficient software updates while maximizing switchback.

[0048] It should be noted that the above embodiments are applicable not only to the case of 1+1 redundancy but also to the case of N+1 redundancy (when there are N active systems).

[0049] In the above embodiments, the 0 system is an example of the first system, and the 1 system is an example of the second system.

[0050] Although the embodiments of the present invention have been described in detail above, the present invention is not limited to such specific embodiments, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0051] REFERENCE SIGNS LIST 10 Software update control device 11 Resource status monitoring unit 12 Update control unit 13 Address information storage unit 20 Virtualization platform 21 Resource management unit 100 Drive device 101 Recording medium 102 Auxiliary storage device 103 Memory device 104 Processor 105 Interface device 121 Generation unit 122 First switching unit 123 Second switching unit B Bus

Claims

1. A software update control device comprising: a generation unit configured to generate a new version of the software with updated address information for each of a first active system and a second standby system of an old version virtual environment before the software update, the new version having different address information from the old version; a first switching unit configured to stop the second system of the old version, assign the second system of the new version the same address information as the old version, and switch the active system to the second system of the new version; and a second switching unit configured to stop the first system of the old version, assign the first system of the new version the same address information as the old version, and switch the active system to the first system of the new version.

2. The software update control device according to claim 1, characterized in that the generation unit is configured to generate a new version related to the first system after the first switching unit has switched.

3. The software update control device according to claim 1, characterized in that the generation unit is configured to generate new versions of the first system and the second system before the first switching unit switches.

4. A software update control method characterized by having the following computer procedures: a generation procedure for generating a new version of the software with updated address information different from that of the old version for each of a first active system and a second standby system of an old version virtual environment before the software update; a first switching procedure for stopping the second system of the old version, assigning the same address information as that of the old version to the second system of the new version, and switching the active system to the second system of the new version; and a second switching procedure for stopping the first system of the old version, assigning the same address information as that of the old version to the first system of the new version, and switching the active system to the first system of the new version.

Images