Software update control device
Patent Information
- Application Number
- JP2025541193
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Filing Date
- 2023-08-21
- Publication Date
- 2025-02-27
Abstract
Description
Software update control device
[0001] The present invention relates to a software update control device.
[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. For example, as shown in Figure 3, if multiple (N) VNFs, VNF-1 to VNF-N, are updated simultaneously (in parallel), twice the total resource usage of the N VNFs is required during the update period. In this case, if there are not enough free resources, the update will fail. On the other hand, if the update periods of the N VNFs are simply staggered (i.e., if the updates are performed serially), the time from the start of the update of VNF-1 to the completion of the update of VNF-N will be prolonged.
[0011] The present invention has been made in view of the above points, and an object of the present invention is to enable 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 schedule for the update by assigning to each of a plurality of virtual environments one of a plurality of types of update procedures, for which the required time for the software update and the amount of resource usage over time are known, and the start timing of that one update procedure; and a determination unit configured to determine, each time the schedule is generated, for each of one or more nodes to which the virtual environment is deployed, whether or not a period will occur in which the upper limit of the resource will be exceeded, based on the amount of resources over time that will be required to perform the update based on the schedule and the resource usage status of the node, and the generation unit is configured to generate a new schedule by changing at least one of the type and start timing of the update procedure for the virtual environment to which the virtual environment is deployed, which is the node in which the period will occur.
[0013] This makes it possible to perform efficient software updates while enabling switchback as much as possible.
[0014] 1 is a diagram for explaining a rolling update. FIG. 2 is a diagram for explaining blue-green deployment. FIG. 3 is a diagram for explaining a problem with blue-green deployment when updates to multiple VNFs are executed in parallel. FIG. 4 is a diagram for explaining a problem with blue-green deployment when updates to multiple VNFs are executed in series. FIG. 5 is a diagram for explaining an example of a configuration of a software update control system 1 in an embodiment of the present invention. FIG. 6 is a diagram for explaining pattern 1. FIG. 7 is a diagram for explaining pattern 2. FIG. 8 is a diagram for explaining pattern 3. FIG. 9 is a diagram for explaining an example of a hardware configuration of a software update control device 10 in an embodiment of the present invention. FIG. 10 is a diagram for explaining an example of a functional configuration of the software update control system 1 in an embodiment of the present invention. FIG. 11 is a diagram for explaining an example of a configuration of pattern information. FIG. 12 is a diagram for explaining an example of a configuration of deployment destination information. FIG. 13 is a diagram for explaining an example of a configuration of resource usage information. FIG. 14 is a flowchart for explaining an example of a processing procedure executed by the software update control device 10. FIG. 15 is a diagram for explaining an example of an update plan that is generated initially. FIG. 16 is a diagram for explaining an example of converting resource usage information into the number of VNFs. FIG. 17 is a diagram for explaining an example of application of change method 1 to an update plan. FIG. 18 is a diagram for explaining an example of application of a combination of change methods 1 and 2 to an update plan. FIG. 19 is a diagram for explaining an example of an application method for an update failure.
[0015] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Fig. 5 is a diagram showing an example of the configuration of a software update control system 1 according to an embodiment of the present invention. In Fig. 5, a software update control device 10 is capable of communicating with one or more NFV platforms 20 via a network.
[0016] The NFV platform 20 is a virtualization platform (NFV (Network Functions Virtualization)) on which one or more VNFs (Virtualized Network Functions) can be deployed. The NFV 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 NFV platform 20 may be a virtualization platform 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. This embodiment is particularly effective when there are multiple VNFs to be updated.
[0019] In this embodiment, the software update control device 10 can perform updates for each VNF using one of multiple types of update procedures (hereinafter referred to as "patterns"), each of which has a known update time and time-series resource consumption. When performing updates for multiple VNFs in parallel, different patterns may be assigned to each VNF. In this embodiment, a case where three patterns are used will be described, but two patterns may be used, or four or more patterns may be defined.
[0020] The first pattern (hereinafter referred to as "Pattern 1") is an update by blue-green deployment described with reference to Fig. 2. In this embodiment, Pattern 1 is understood as being divided into a plurality of steps in chronological order.
[0021] Fig. 6 is a diagram for explaining Pattern 1. As shown in Fig. 6, Pattern 1 is made up of three steps, STEP 1 to STEP 3, in chronological order.
[0022] Step 1 is a step in which a new version active system (Act) and a standby system (Sby) are constructed. Step 2 is a step in which a system switchover (switching of operation from the old version to the new version) is performed. Step 3 is a step in which the old version is deleted.
[0023] The second pattern (hereinafter referred to as "Pattern 2") is made up of the steps shown in Fig. 7. Fig. 7 is a diagram for explaining Pattern 2. As shown in Fig. 7, Pattern 2 is made up of six steps, STEP 1 to STEP 6, in chronological order.
[0024] STEP 1 is a step in which only the new version of the active system (hereinafter referred to as "new Act") is constructed. STEP 2 is a step in which operation is switched from the old version of the active system (hereinafter referred to as "old Act") to the new version of Act. STEP 3 is a step in which the old Act is deleted. STEP 4 is a step in which the new version of the standby system (hereinafter referred to as "new Sby") is further constructed. STEP 5 is a step in which operation is switched from the old version of the standby system (hereinafter referred to as "old Sby") to the new version of Sby. STEP 6 is a step in which the old Sby is deleted.
[0025] In pattern 2, the maximum number of temporary VNFs (resource usage) is 3. Therefore, resource usage can be suppressed more than in pattern 1.
[0026] The third pattern (hereinafter referred to as "Pattern 3") is made up of the steps shown in Fig. 8. Fig. 8 is a diagram for explaining Pattern 3. As shown in Fig. 8, Pattern 3 is made up of five steps, STEP 1 to STEP 5, in chronological order.
[0027] STEPs 1 and 2 of Pattern 3 are the same as STEPs 1 and 2 of Pattern 2. STEP 3 of Pattern 3 is a step in which a new Sby is further constructed. That is, in Pattern 3, STEP 4 of Pattern 2 is executed before STEP 3 of Pattern 2. STEP 4 of Pattern 3 is a step in which operation is switched from the old Sby to the new version Sby. STEP 5 of Pattern 3 is a step in which the old Act and new Sby are deleted.
[0028] In pattern 3, the number of temporary VNFs (resource usage) is 3 or 4, and the resource usage is inferior to pattern 2. However, while pattern 2 has a risk of not being able to switch back to the old version after STEP 3, pattern 3 does not have such a risk.
[0029] 6 to 8 show the required time and resource usage (number of VFNs (e.g., number of VMs)) for each step (i.e., in chronological order). In the notation of resource usage, "Act1 / Sby" indicates that there is one active system (Avtive system) and one standby system (Standby system). The required time and resource usage are parameters that will be used later. Information indicating the required time and resource usage for each step of each pattern will be referred to as "pattern information" hereinafter. The pattern information may be measured in advance by trial updates using each pattern, or may be estimated using any method.
[0030] The software update control device 10 generates an update schedule (a collection of update pipelines (hereinafter simply referred to as "pipelines") for each VNF) for multiple VNFs to be updated based on pattern information, information indicating the deployment destination nodes (NFV infrastructure 20) for the active and standby systems of multiple VNFs to be updated (hereinafter referred to as "deployment destination information"), and the resource usage or availability (free capacity) of each node. Hereinafter, the update schedule will be referred to as an "update plan." A pipeline for a certain VNF refers to information indicating the pattern to be applied to that VNF and the start timing of each step of that pattern. The start timing of each step of each pipeline is specified by a value relative to the start timing of each step of other pipelines.
[0031] 9 is a diagram showing an example of the hardware configuration of a software update control device 10 according to an embodiment of the present invention. The software update control device 10 in FIG. 9 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.
[0032] 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.
[0033] 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.
[0034] Fig. 10 is a diagram showing an example of the functional configuration of the software update control system 1 according to an embodiment of the present invention. Fig. 10 shows three NFV infrastructures 20, 20-1 to 20-3. Each NFV infrastructure 20 has one or more VNFs as well as a resource management unit 21. The resource management unit 21 monitors the usage status (in other words, availability) of resources (CPU, RAM, DISK, NW (communication resources)) of the nodes functioning as the NFV infrastructures 20.
[0035] 10 shows an example in which, for VNF-1, the active system (VNF-1 Act) is deployed in the NFV infrastructure 20-1 and the standby system (VNF-1 Sby) is deployed in the NFV infrastructure 20-2. Also, for VNF-2, an example in which the active system (VNF-2 Act) is deployed in the NFV infrastructure 20-2 and the standby system (VNF-2 Sby) is deployed in the NFV infrastructure 20-3 is shown. Also, for VNF-3, an example in which the active system (VNF-3 Act) is deployed in the NFV infrastructure 20-3 and the standby system (VNF-3 Sby) is deployed in the NFV infrastructure 20-1 is shown. Also, for VNF-4, an example is shown in which the active system (VNF-4 Act) is deployed in the NFV infrastructure 20-2 and the standby system (VNF-4 Sby) is deployed in the NFV infrastructure 20-1. In this way, in order to reduce the impact of a single physical failure, each VNF is deployed in a different NFV infrastructure 20 as the active system and the standby system.
[0036] On the other hand, the software update control device 10 has a monitoring unit 11, a generating unit 12, a determining unit 13, and a control unit 14. Each of these units is realized by a process in which one or more programs installed in the software update control device 10 are executed by a processor 104. The software update control device 10 also uses a pattern information storage unit 15 and a deployment destination information storage unit 16. Each of these storage units 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.
[0037] The pattern information storage unit 15 stores pattern information for each pattern. FIG. 11 is a diagram showing an example of the configuration of pattern information. In FIG. 11, (1) is pattern information corresponding to pattern 1 shown in FIG. 6. (2) is pattern information corresponding to pattern 2 shown in FIG. 7. (3) is pattern information corresponding to pattern 3 shown in FIG. 8. The pattern information is information including the required time for each step constituting the pattern (and thus the required time for the entire pattern) and the resource usage (in chronological order) for each step. As described above, the pattern information is measured in advance by an update trial or estimated by any method, and is registered in advance in the pattern information storage unit 15.
[0038] The deployment destination information storage unit 16 stores deployment destination information. FIG. 12 is a diagram showing an example of the configuration of deployment destination information. As shown in FIG. 12, the deployment destination information is information including an active system deployment destination and a standby system deployment destination for each VNF. The active system deployment destination is the NFV platform 20 where the active system is deployed. The standby system deployment destination is the NFV platform 20 where the standby system is deployed. Note that the notation "node N" (N is 1 to 4), which is the identification information of the active system deployment destination and the standby system deployment destination, is the node name of the node corresponding to the NFV platform 20-N. The deployment destination information in FIG. 12 corresponds to the deployment destination of each VNF in FIG. 10.
[0039] The monitoring unit 11 acquires information indicating the usage status (availability) of resources in each NFV infrastructure 20 (each node) (hereinafter referred to as “resource usage information”) from the resource management unit 21 of each NFV infrastructure 20 .
[0040] 13 is a diagram showing an example of the configuration of resource usage information, which shows information including the respective usage rates of the CPU and RAM for each NFV platform 20 as an example of resource usage information.
[0041] The generation unit 12 generates an update plan by assigning to each of a plurality of VNFs one of a plurality of patterns in which the required time for software update and the resource usage over time are known, and the start timing of that one pattern.
[0042] Each time an update plan is generated, the determination unit 13 determines whether or not a period in which the upper limit of the resource will be exceeded will occur, for each of one or more nodes (NFV infrastructure 20) that are deployment destinations of each VNF, based on the time-series resource amount required when performing an update based on the update plan and the resource usage status of the node. If there is a node in which the corresponding period occurs, the generation unit 12 generates a new update plan by changing at least one of the type and start timing of the pattern related to the VNF that has the node in which the period occurs as a deployment destination (deployment destination of either the active system or the standby system).
[0043] The control unit 14 controls the execution of updates for each VNF based on the update plan.
[0044] The following describes the processing procedure executed by the software update control device 10. Fig. 14 is a flowchart for explaining an example of the processing procedure executed by the software update control device 10.
[0045] In step S101, the generation unit 12 generates an update plan to be processed (hereinafter referred to as the "target plan") by assigning a pipeline of pattern 1, which has the shortest required time based on the pattern information (Figure 11), to all VNFs registered in the deployment destination information (Figure 12), and assigning simultaneous start timings to the pipelines 1 assigned to each VNF.
[0046] 15 is a diagram showing an example of an update plan that is generated initially. This update plan shows an update plan in which pipeline execution of pattern 1 is started simultaneously for VNF-1 to VNF-4. The reason why such an update plan is used as the first update plan (initial value of the update plan) is that pattern 1 is completed the fastest, and therefore updating all VNFs in parallel using pattern 1 as much as possible is preferable from the perspective of shortening the update time.
[0047] Note that a pipeline is generated for each VNF, and is not distinguished between active and standby systems. If there are N VNFs, N pipelines are generated, not N x 2. If the active and standby pipelines of a VNF are not common, each step of the update of the VNF will not be consistent between the active and standby systems, making it difficult to execute the update correctly.
[0048] Next, the determination unit 13 calculates information (hereinafter referred to as "required resource information") indicating, in chronological order, the amount of resources required by each node (NFV platform 20) when executing the target plan (S102). The amount of resources required by a certain node at a certain time point can be calculated by calculating the sum of the resource usage (resource usage of the active system or standby system) at that time point of each VNF pipeline that is deployed at that node among the pipelines that make up the target plan. The resource usage of a certain pipeline at a certain node and at a certain time point can be identified by referring to the value of the system (active system or standby system) deployed at that node among the resource usage of the NFV corresponding to the pipeline in the pattern information (Figure 11) corresponding to the pattern related to the pipeline.
[0049] Next, the determination unit 13 determines, for each node (NFV infrastructure 20), whether or not there is a node in which a period in which the node's resource upper limit is exceeded (hereinafter referred to as an "excess period") occurs, based on the node's required resource information and the node's resource usage information ( FIG. 13 ) (S103). The resource usage amount that forms the basis of the required resource information is the number of VNFs. On the other hand, the resource usage information is the CPU and RAM usage rates. Therefore, the determination unit 13 makes this determination by converting the number of VNFs into CPU and RAM usage rates. The CPU and RAM usage (usage rates) of each VNF may be acquired from the NFV infrastructure 20 where each VNF is deployed, or a conversion table may be generated in advance. Alternatively, as shown in FIG. 16 , the resource usage information may be converted into the number of VNFs (number of VNFs) based on a predetermined conversion formula or correspondence table, and then the required resource information and the resource usage information ( FIG. 13 ) may be compared.
[0050] If there is a node (hereinafter referred to as the "target node") in which an overage period occurs (No in S104), the generation unit 12 updates the target plan (generates a new target plan) by modifying the partial update plan (hereinafter referred to as the "change target update plan") for the VNF that is deployed to the target node so that the overage period is eliminated (so that an overage period does not occur) (S105).
[0051] The change to the update plan to be changed is executed, for example, by any one of the following change methods 1 to 3, or a combination of two or more of change methods 1 to 3. (Change method 1) Changing the start timing of any of the pipelines that make up the update plan to be changed. (Change method 2) Changing the pattern assigned to the VNF that has the target node as its deployment destination. (Change method 3) Delaying the start timing of any of the steps of any of the pipelines that make up the update plan to be changed, and including a period during which nothing is executed between steps of the pipeline (hereinafter referred to as an "interruption period").
[0052] 17 is a diagram showing an example of applying change method 1 to an update plan. FIG. 17 shows an example in which the start timing of the VNF-3 pipeline is shifted backward. As a result, the maximum amount of resources required by the target node in period T1 can be reduced. Note that a change may also be made to shift the start timing of the pipeline to be changed forward.
[0053] 18 is a diagram showing an example of applying a combination of change methods 1 and 2 to an update plan. Fig. 18 shows an example in which the pipelines of VNF-1 to VNF-4 are changed to pattern 3, and the start timing of the pipelines of VNF-3 and VNF-4 is shifted back. As a result, the maximum amount of resources required by the target node in periods T1 and T2 can be reduced.
[0054] 19 is a diagram showing an example of applying change methods 1 and 3 to an update plan. In FIG. 19, an example is shown in which the start timing of the VNF-3 pipeline is shifted backward, and interruption periods are inserted between STEPs 1 and 2 and between STEPs 2 and 3 of the pipeline.
[0055] As is clear from the above, there may be multiple ways to change the change target update plan. For example, the generation unit 12 may generate multiple or all change methods (combinations of patterns, start timings, etc.) for the change target update plan within the resource constraints (upper limit) of the target node, and select from among them the change method that minimizes the required time (period from start to finish) for the change target update plan. When generating all change methods, in order to limit the total number of methods, a constraint may be set that the start timing of the pipeline to be changed matches the boundary of a step of any of the other pipelines constituting the change target update plan, or a pipeline related to another node.
[0056] In this way, in this embodiment, an update plan is initially attempted using the simultaneous execution of pattern 1, but if the resource constraints cannot be satisfied, one or more of change methods 1 to 3 are applied to search for an update plan that can be executed in a short period of time while satisfying the resource constraints.
[0057] Pattern 2 reduces the amount of resources required for the update to 1.5 times that before the update, but makes it impossible to roll back to the old version after STEP 3. Furthermore, if an update in a pipeline of patterns 1 or 3 fails, it is considered that there is a relatively high possibility that other pipelines will similarly fail compared to cases where the update does not fail. Therefore, it is desirable to execute pattern 2, which has a relatively high risk of service interruption (e.g., an interruption exceeding the service interruption time allowed based on the SLA), after a successful update has been established. By doing so, if an update in a pipeline of patterns 1 or 3 fails, the pipeline of pattern 2, which may similarly fail, can also be stopped in advance, thereby avoiding the above-mentioned risks.
[0058] Therefore, when there is a change method that includes a change to Pattern 2 among a plurality of change methods for the update plan to be changed, the generation unit 12 may preferentially select, among the relevant change methods, a change method that has a relatively late start timing for Pattern 2. By doing so, it is possible to ensure that the pipeline of Pattern 2 is executed as late as possible in the update (so that Patterns 1 and 3 are executed before Pattern 2).
[0059] Furthermore, a numerical value indicating the degree of tolerance for the above-mentioned risks (hereinafter referred to as "risk tolerance") may be set for each VNF. An example of risk tolerance is the allowable service disruption time. Alternatively, an index representing the empirical difficulty of reverting (e.g., 100 for a VNF that frequently fails, 10 for a VNF that rarely fails) may be used as the risk tolerance. In this case, when the generation unit 12 wants to change one of multiple pipelines to Pattern 2, the generation unit 12 may preferentially assign Pattern 2 to a pipeline associated with a VNF with a relatively high (large) risk tolerance. In other words, a failed revert often requires manual intervention, resulting in a longer service disruption time. The idea is that a VNF that can tolerate this may be assigned Pattern 2.
[0060] In addition, when two or more of the conditions of shortening the required time for the change target update plan, delaying pattern 2 as much as possible, and prioritizing allocation of pattern 2 to pipelines related to VNFs with high risk tolerance are combined, the generation unit 12 may assign weights to these three conditions and calculate an evaluation value for each of the generated multiple change methods using a weighted sum based on the weights (a weighted sum of the weights and the degree to which each condition is satisfied). In this case, the generation unit 12 may select the change method to be adopted based on the evaluation value.
[0061] Following step S105, steps S102 and onward are repeated. Note that even if the overrun period of the target node is resolved in step S105, there is a possibility that a new overrun period will occur in a node to which the same pipeline as the target node is assigned (a node to which a standby system or an active system that is paired with the active system or standby system deployed in the target node is deployed).
[0062] In the process of repeating step S102 and subsequent steps, when there are no more nodes in which an overrun period occurs (Yes in S104), the control unit 14 controls the update of each VNF based on the target plan at that time (S106). Specifically, the control unit 14 transmits commands corresponding to each step of each pipeline constituting the target plan to the VNF corresponding to that pipeline at a timing according to the pipeline.
[0063] Note that the generation unit 12 may generate an update plan by using an optimization algorithm such as mathematical optimization (schedule optimization problem) instead of executing the processing procedure of Fig. 14. In this case, the generation unit 12 can generate an update plan by solving a problem of minimizing the required time for the entire update plan as an objective function, with the resource amount based on the resource usage information of each node as a constraint condition.
[0064] Furthermore, although the above describes an example in which a method that minimizes the total required time (the "time-priority method") is adopted, an update plan may be generated based on the "resource-priority method" when, for example, there is ample time but it is desired to suppress resource consumption (or the (economic) cost required for the update) as much as possible. Among patterns 1 to 3, pattern 2 is the one that can most effectively suppress the maximum resource usage (i.e., the maximum cost). Therefore, in the case of the resource-priority method, in step S101 of FIG. 14, the generation unit 12 generates an update plan in which, as a target plan, for all VNFs registered in the deployment destination information (FIG. 12), the pipeline of pattern 2 that has the smallest maximum resource usage based on the pattern information (FIG. 11) is assigned, and simultaneous start timings are assigned to the pipelines 2 assigned to each VNF.
[0065] In addition, in the case of the resource priority method, in step S105, the generation unit changes the change-target update plan so as to eliminate the overrun period (so that no overrun period occurs) by changing the start timing of any one or more pipelines that make up the change-target update plan. In other words, in the case of the resource priority method, no pattern change is performed in order to suppress resource consumption (an update plan using only pattern 2 is searched for).
[0066] Alternatively, when the objective is to minimize the risk of a rollback failure, the "risk-priority method" may be adopted instead of the time-priority method and the resource-priority method. In the risk-priority method, a restriction that pattern 2 should not be used is added to the time-priority method. Therefore, the pattern of each pipeline constituting the update plan generated by the risk-priority method is pattern 1 or pattern 3.
[0067] In any of the time-priority method, the resource-priority method, and the risk-priority method, there is a possibility that one of the pipelines may fail while the control unit 14 is controlling the update based on the update plan in step S106 of Fig. 14. How to deal with this case will be described below.
[0068] Fig. 20 is a diagram for explaining an example of how to deal with an update failure. Fig. 20 shows an example in which STEP 4 of the pipeline for VNF-1 has failed. The following are possible ways to deal with this case: (1) Executed pipeline: Do nothing. (2) Failed pipeline: Switch back (failback). (3) Executing pipeline: Determine whether to continue as is or switch back (failback). (4) Unexecuted pipeline: Determine whether to execute as scheduled or to abort execution.
[0069] The above (1) and (2) may be automatically executed by the control unit 14. The determinations in (3) and (4) may be made by the control unit 14 based on a policy set in advance, or an error may be output and left to the operator.
[0070] As described above, according to the present embodiment, it is possible to perform an efficient software update while enabling switchback as much as possible. For example, by generating an update plan that shortens (minimizes) the required time or reduces (minimizes) the consumed resources within the resource constraints, it is possible to perform an efficient software update.
[0071] In this embodiment, a VNF in which a network function (or network device) is virtualized (softwareized) has been described as a virtual environment, but this embodiment may also be applied to updates to a virtual environment in which a function (or device) other than a network function is virtualized.
[0072] 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.
[0073] REFERENCE SIGNS LIST 1 Software update control system 10 Software update control device 11 Monitoring unit 12 Generation unit 13 Determination unit 14 Control unit 15 Pattern information storage unit 16 Deployment location information storage unit 20 NFV platform 21 Resource management unit 100 Drive device 101 Recording medium 102 Auxiliary storage device 103 Memory device 104 Processor 105 Interface device B Bus
Claims
1. A software update control device comprising: a generation unit configured to generate an update schedule by assigning to each of a plurality of virtual environments one of a plurality of types of update procedures, the required time for software update and the amount of resource usage over time being known, and the start timing of the one of the procedures; and a determination unit configured to determine, each time the schedule is generated, for each one or more nodes to which the virtual environments are deployed, whether or not a period of time will occur in which the upper limit of the resource will be exceeded, based on the amount of resources over time required to perform the update based on the schedule and the resource usage status of the node; wherein the generation unit is configured to generate a new schedule by changing at least one of the type and start timing of the update procedure for the virtual environment deployed to the node in which the period of time occurs.
2. The software update control device as described in claim 1, characterized in that the generation unit is configured to select, from among multiple combinations of the update procedures and the start timings that can eliminate the occurrence of the period, a combination that minimizes the time required for the update at the node where the period occurs.
3. The software update control device as described in claim 1, characterized in that the generation unit is configured to select a combination that minimizes the maximum value of resource usage in the node where the period occurs from among multiple combinations of the update procedures and the start timings that can eliminate the occurrence of the period.
4. A software update control device as described in claim 2 or 3, characterized in that the generation unit is configured to select a combination of the update procedures and start timings that can eliminate the occurrence of the period, the combination having a relatively late start timing of the update procedures that makes it impossible to switch back.