WO2025041237A1 - Software update control device - Google Patents

Abstract

A software update control device generates a schedule for a software update for each of a plurality of virtual environments by allocating one of a plurality of types of update procedures, in which the time required and the resource usage over time for the software update are known, and the start timing of the update procedure. Each time the schedule is generated, the software update control device determines whether a period in which the upper limit of the resource is exceeded occurs in each of one or more nodes that are deployment destinations of the virtual environment on the basis of the amount of resources required over time when performing the update on the basis of the schedule and the use state of the resources in the node, and generates a new schedule by changing at least one of the type or the start timing of the update procedure related to the virtual environment having the node in which the period occurs as a deployment destination, thus enabling efficient software updates while making it possible to undo the updates as much as possible.

Description

Software update control device

The present invention relates to a software update control device.

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

Therefore, there is a need to avoid communication interruptions as much as possible when updating software related to VNF, and to be able to roll back if a problem occurs after the update.

Traditional software update technologies with an Active/Standby configuration include rolling updates and blue-green deployments (also known as "blue-green updates").

As shown in Figure 1, rolling update is a technology that performs uninterrupted updates by switching between Active and Standby and updating each of them (Non-Patent Document 1).

As shown in Figure 2, blue-green deployment is a technology that creates (deploys) a new version while maintaining the currently running VNF, and then deletes (undeploys) the old version after the switchover (Non-Patent Document 2).

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

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> RedHat, "What is Blue-Green Deployment?", [online], Internet <URL: https://www.redhat.com/ja/topics/devops/what-is-blue-green-deployment>

While rolling updates have the advantage of allowing updates without increasing the amount of resources used, they have 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.

While blue-green deployment has the advantage that if a problem occurs after an update, it is possible to roll back because the old version remains, it has the disadvantage that the amount of temporary resource usage increases during the update. For example, as shown in Figure 3, when updating multiple (N) VNFs, VNF-1 to N, simultaneously (in parallel), twice the total amount of resources required during the update period will be required as compared to the total amount of resources used by the N VNFs. In this case, if there are not enough free resources, the update will fail. On the other hand, if the update periods for the N VNFs are simply staggered (i.e., when the updates are performed serially), there is a problem in that the period from when the update of VNF-1 starts to when the update of VNF-N finishes will be longer.

The present invention was made in consideration of the above points, and aims to make it possible to perform efficient software updates while making reversion as possible as possible.

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, the required time for the 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, whether or not a period of time will occur in which the upper limit of the resource will be exceeded, for each one or more nodes to which the virtual environment is deployed, 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, 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, the node in which the period of time occurs.

This makes it possible to perform efficient software updates while allowing as much rollback as possible.

FIG. 1 is a diagram for explaining a rolling update. FIG. 1 is a diagram to explain blue-green deployment. FIG. 1 is a diagram for explaining the problems of blue-green deployment when updating multiple VNFs in parallel. FIG. 1 is a diagram for explaining the problems of blue-green deployment when updating multiple VNFs in series. 1 is a diagram showing an example of a configuration of a software update control system 1 according to an embodiment of the present invention. FIG. 13 is a diagram for explaining pattern 1. FIG. 13 is a diagram for explaining pattern 2. FIG. 13 is a diagram for explaining pattern 3. 1 is a diagram illustrating an example of a hardware configuration of a software update control device 10 according to an embodiment of the present invention. 1 is a diagram illustrating an example of a functional configuration of a software update control system 1 according to an embodiment of the present invention. FIG. 11 is a diagram illustrating an example of the configuration of pattern information. FIG. 11 is a diagram illustrating an example of the configuration of deployment destination information. FIG. 11 is a diagram illustrating an example of the configuration of resource usage information. 4 is a flowchart illustrating an example of a processing procedure executed by the software update control device 10. FIG. 13 is a diagram illustrating an example of an update plan that is initially generated. FIG. 13 is a diagram illustrating an example of converting resource usage information into the number of VNFs. FIG. 13 is a diagram illustrating an example of application of change method 1 to an update plan. FIG. 13 is a diagram illustrating an example of application of a combination of change methods 1 and 2 to an update plan. FIG. 13 is a diagram illustrating an example of application of change methods 1 and 3 to an update plan. FIG. 11 is a diagram for explaining an example of a method for dealing with a failure in updating.

Below, 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 in 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.

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 make up 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 it may be a cloud platform such as AWS.

A VNF is a network function that can be virtualized (an example of a virtual environment that functions as a device that handles packets, such as a virtual router or UPF). A VNF may be realized by a virtual machine (VM (Virtual Machine)), or by a container or VRF (Virtual Routing and Forwarding) that virtually separates functions.

The software update control device 10 is one or more computers (e.g., 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.

In this embodiment, the software update control device 10 can update 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 on multiple VNFs in parallel, the pattern assigned to each VNF may be different. In this embodiment, a case in which three patterns are used is described, but two patterns may be used, or four or more patterns may be defined.

The first pattern (hereinafter referred to as "Pattern 1") is an update using blue-green deployment as described in FIG. 2. In this embodiment, Pattern 1 is understood as being divided into multiple steps in chronological order.

Figure 6 is a diagram for explaining Pattern 1. As shown in Figure 6, Pattern 1 is composed of three steps, STEP 1 to STEP 3, in chronological order.

STEP 1 is the step in which the new version's active system (Act) and standby system (Sby) are constructed. STEP 2 is the step in which the systems are switched (operations are switched from the old version to the new version). STEP 3 is the step in which the old version is deleted.

The second pattern (hereinafter referred to as "Pattern 2") is composed of the steps shown in Figure 7. Figure 7 is a diagram for explaining Pattern 2. As shown in Figure 7, Pattern 2 is composed of six steps, STEP 1 to STEP 6, in chronological order.

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.

In pattern 2, the maximum number of temporary VNFs (resource usage) is 3. Therefore, resource usage can be reduced more than in pattern 1.

The third pattern (hereinafter referred to as "Pattern 3") is composed of the steps shown in Figure 8. Figure 8 is a diagram for explaining Pattern 3. As shown in Figure 8, Pattern 3 is composed of five steps, STEP 1 to STEP 5, in chronological order.

STEP 1 and 2 of pattern 3 are the same as STEP 1 and 2 of pattern 2. STEP 3 of pattern 3 is the step where 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 the step where operation is switched from the old Sby to the new version Sby. STEP 5 of pattern 3 is the step where the old Act and new Sby are deleted.

In pattern 3, the number of temporary VNFs (resource usage) is 3 or 4, which is inferior to pattern 2 in terms of resource usage. However, while pattern 2 has the risk of not being able to switch back to the old version after STEP 3, pattern 3 does not have such a risk.

Note that Figures 6 to 8 show the time required 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 and one standby system. The time required and resource usage are parameters that will be used later. Information indicating the time required and resource usage for each step of each pattern will be referred to as "pattern information" below. The pattern information may be measured in advance by trial updates using each pattern, or may be estimated by any method.

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 platforms 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 is 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 as a relative value to the start timing of each step of other pipelines.

FIG. 9 is a diagram showing an example of the hardware configuration of a software update control device 10 in an embodiment of the present invention. The software update control device 10 in FIG. 9 has a drive device 100, an auxiliary storage device 102, a memory device 103, a processor 104, and an interface device 105, which are all interconnected by a bus B.

The 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 via the drive device 100 into the auxiliary storage device 102. 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.

When an instruction to start a program is received, the memory device 103 reads out 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.

FIG. 10 is a diagram showing an example of the functional configuration of the software update control system 1 in an embodiment of the present invention. Three NFV platforms 20, NFV platforms 20-1 to 20-3, are shown in FIG. 10. Each NFV platform 20 has a resource management unit 21 in addition to one or more VNFs. The resource management unit 21 monitors the usage status (in other words, availability) of the resources (CPU, RAM, DISK, NW (communication resources)) of the nodes functioning as the NFV platform 20.

In addition, in FIG. 10, for VNF-1, an example is shown in which the active system (VNF-1 Act) is deployed on the NFV platform 20-1, and the standby system (VNF-1 Sby) is deployed on the NFV platform 20-2. Also, for VNF-2, an example is shown in which the active system (VNF-2 Act) is deployed on the NFV platform 20-2, and the standby system (VNF-2 Sby) is deployed on the NFV platform 20-3. Also, for VNF-3, an example is shown in which the active system (VNF-3 Act) is deployed on the NFV platform 20-3, and the standby system (VNF-3 Sby) is deployed on the NFV platform 20-1. Also, for VNF-4, an example is shown in which the active system (VNF-4 Act) is deployed on NFV platform 20-2, and the standby system (VNF-4 Sby) is deployed on NFV platform 20-1. In this way, in order to reduce the impact of a single physical failure, each VNF is deployed on a different NFV platform 20 as an active system and a standby system.

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 the 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, for example, by using an auxiliary storage device 102, or a storage device that can be connected to the software update control device 10 via a network, etc.

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 time required for each step constituting the pattern (and thus the time required for the entire pattern) and the resource usage (in chronological order) for each step. As described above, the pattern information is registered in advance in the pattern information storage unit 15 by being measured in advance by an update trial or estimated by any method.

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 on which the active system is deployed. The standby system deployment destination is the NFV platform 20 on which 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 VFN in FIG. 10.

The monitoring unit 11 obtains information indicating the resource usage (availability) in each NFV platform 20 (each node) (hereinafter referred to as "resource usage information") from the resource management unit 21 of each NFV platform 20.

FIG. 13 is a diagram showing an example of the configuration of resource usage information. In FIG. 13, information including the respective usage rates of the CPU and RAM for each NFV platform 20 is shown as an example of resource usage information.

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 updates and the amount of resource usage over time are known, and the start timing of that one of the patterns.

Each time an update plan is generated, the determination unit 13 determines whether or not a period will occur in which the upper limit of the resource will be exceeded for each of the one or more nodes (NFV platforms 20) in which each VNF is deployed, based on the time-series resource amount required when performing an update based on the update plan and the resource usage status in the node. If there is a node in which the relevant 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 in which the node in which the period occurs is the deployment destination (deployment destination of either the active system or the standby system).

The control unit 14 controls the execution of updates for each VNF based on the update plan.

The following describes the processing procedure executed by the software update control device 10. Figure 14 is a flowchart for explaining an example of the processing procedure executed by the software update control device 10.

In step S101, the generation unit 12 generates an update plan to be processed (hereinafter referred to as the "target plan") by assigning the pipeline of pattern 1, which has the shortest required time based on the pattern information (Fig. 11), to all VNFs registered in the deployment destination information (Fig. 12) and assigning simultaneous start timings to the pipelines 1 assigned to each VNF.

FIG. 15 is a diagram showing an example of the first update plan to be generated. FIG. 15 shows an update plan in which pipeline execution of pattern 1 is started simultaneously for VNF-1 to 4. Such an update plan is set as the first update plan (initial value of the update plan) because pattern 1 is completed the fastest, and therefore it is preferable from the perspective of shortening the update time to update all VNFs in parallel as much as possible with pattern 1.

Note that pipelines are generated for each VNF, and are not differentiated 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 that VNF will not be consistent between the active and standby systems, making it difficult to execute the update correctly.

Then, the determination unit 13 calculates information (hereinafter referred to as "required resource information") indicating, in time series, 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 can be calculated by finding the sum of the resource usage (resource usage of the active system or standby system) at that time 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 can be identified by referring to the value of the system (active system or standby system) deployed at the 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.

Then, the determination unit 13 determines whether or not there is a node (NFV platform 20) in which a period in which the resource upper limit of the node is exceeded (hereinafter referred to as an "excess period") occurs, based on the required resource information of the node and the resource usage information of the node (FIG. 13) (S103). The resource usage amount that is the basis of the required resource information is the number of VNFs. On the other hand, the resource usage information is the usage rate of the CPU or RAM. Therefore, the determination unit 13 performs such a determination by converting the number of VNFs to the usage rate of the CPU or RAM. The usage rate (usage rate) of the CPU or RAM of each VNF may be obtained from the NFV platform 20 where each VNF is deployed, or a conversion table may be generated in advance. Alternatively, as shown in FIG. 16, the required resource information may be compared with the resource usage information (FIG. 13) by converting the resource usage information into the number of VNFs (number of units) based on a predetermined conversion formula or correspondence table, etc.

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 has the target node as its deployment destination so that the overage period is eliminated (so that an overage period does not occur) (S105).

The change of 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 the 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) Change the pattern to be assigned to the VNF that has the target node as its deployment destination.
(Change method 3) Delaying the start timing of any step of any of the pipelines that make up the update plan to be changed, and including a period during which nothing is executed between the steps of the pipeline (hereinafter referred to as an "interruption period").

FIG. 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.

FIG. 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 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.

FIG. 19 shows an example of applying change methods 1 and 3 to an update plan. In FIG. 19, the start timing of the VNF-3 pipeline is shifted back, and an example is shown in which interruption periods are inserted between STEPs 1 and 2 and between STEPs 2 and 3 of the pipeline.

As is clear from the above, there may be multiple ways to change the update plan to be changed. For example, the generation unit 12 may generate multiple or all ways (combinations of patterns and start timing, etc.) for the update plan to be changed within the resource constraints (upper limit) of the target node, and select from among them the change method that will provide the shortest time required for the update plan to be changed (the period from start to finish). When generating all ways of change 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 update plan to be changed, or of a pipeline related to another node, in order to make the total number of ways finite.

In this way, in this embodiment, an update plan with simultaneous execution of pattern 1 is initially attempted, but if the resource constraints cannot be met, one or more of change methods 1 to 3 are applied to search for an update plan that satisfies the resource constraints and can be executed in a short period of time.

In addition, while pattern 2 can reduce the amount of resources required for the update to 1.5 times that before the update, it becomes impossible to switch back to the old version after STEP 3. Also, if an update in a pipeline of pattern 1 or 3 fails, it is considered that there is a relatively high possibility that other pipelines will fail as well, compared to other cases where this is not the case. Therefore, it is desirable to execute pattern 2, which has a relatively high risk of causing a service interruption (for example, an interruption that exceeds the service interruption time allowed based on the SLA), after there is a proven track record of successful updates. By doing so, if an update in a pipeline of pattern 1 or 3 fails, the pipeline of pattern 2, which may also fail, can be stopped in advance, and the above risks can be avoided.

Then, 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 the change method in which the start timing of pattern 2 is relatively late among the relevant change methods. By doing so, it is possible to ensure that the pipeline of pattern 2 is executed as late as possible in the update (patterns 1 and 3 are executed before pattern 2).

Furthermore, a numerical value indicating the tolerable degree of the above-mentioned risks (hereinafter referred to as "risk tolerance") may be set for each VNF. One example of risk tolerance is the tolerable service outage time. Furthermore, an index indicating the empirical difficulty of reverting (e.g., 100 for a VNF that often fails, 10 for a VNF that rarely fails, etc.) may be set as the risk tolerance. In this case, when the generation unit 12 wishes to change any of a plurality of pipelines to pattern 2, the generation unit 12 may preferentially assign pattern 2 to pipelines related to VNFs with a relatively high (large) risk tolerance. In other words, if reverting fails, human intervention is often required, resulting in a long service outage time. The idea is that VNFs that can tolerate this may be pattern 2.

In addition, when two or more of the conditions of shortening the time required for the change target update plan, delaying pattern 2 as much as possible, and prioritizing the 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 multiple generated change methods based on the weights (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.

Following step S105, steps S102 and onwards are repeated. Note that even if the overage period of the target node is resolved in step S105, a new overage period may occur in a node to which the same pipeline as the target node is assigned (a node to which a standby system or working system that is paired with the working system or standby system deployed in the target node is deployed).

When there are no more nodes in which an overrun period occurs while steps S102 and after are repeated (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.

In addition, instead of executing the processing procedure of FIG. 14, the generation unit 12 may generate an update plan by using an optimization algorithm such as mathematical optimization (schedule optimization problem). 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.

In addition, in the above, an example of adopting a method that minimizes the total required time ("time priority method") has been described, but for example, if there is time to spare but it is desired to suppress resource consumption (or the (economic) cost required for the update) as much as possible, an update plan may be generated based on the "resource priority method". Among patterns 1 to 3, pattern 2 is the one that can suppress the maximum resource usage (i.e., the maximum cost) the most. Therefore, in the case of the resource priority method, in step S101 of FIG. 14, the generation unit 12 assigns the pipeline of pattern 2, which has the smallest maximum resource usage based on the pattern information (FIG. 11), to all VNFs registered in the deployment destination information (FIG. 12) as the target plan, and generates an update plan in which simultaneous start timing is assigned to the pipelines 2 assigned to each VNF.

In addition, in the case of the resource priority method, in step S105, the generation unit changes the update plan to be changed so that the overrun period is eliminated (so that the overrun period does not occur) by changing the start timing of one or more of the pipelines that make up the update plan to be changed. In other words, in the case of the resource priority method, the pattern is not changed to reduce resource consumption (an update plan using only pattern 2 is searched for).

Alternatively, if the objective is to minimize the risk of rollback failure, a "risk-priority method" may be adopted instead of the time-priority method and the resource-priority method. In the risk-priority method, a constraint 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 will be pattern 1 or pattern 3.

Note that in any of the cases of the time-priority method, the resource-priority method, and the risk-priority method, while the control unit 14 is controlling the update based on the update plan in step S106 of FIG. 14, there is a possibility that one of the pipelines may fail. A method for dealing with this case will be described below.

Fig. 20 is a diagram for explaining an example of a method for dealing with an update failure. Fig. 20 shows an example in which STEP 4 of the pipeline for VNF-1 has failed. The following methods can be considered as methods for dealing with this case.
(1) Executed pipeline: Do nothing.
(2) Failed Pipeline: Failback.
(3) A running pipeline: Determine whether to continue or to fail back.
(4) Unexecuted pipeline: Determine whether to execute the pipeline as scheduled or to abort the execution.

The above (1) and (2) may be automatically executed by the control unit 14. The judgments 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.

As described above, according to this embodiment, it is possible to perform efficient software updates while making reversion possible as much as possible. For example, by generating an update plan that requires less time (shortest possible time) or consumes fewer resources (minimum possible time) within the resource constraints, it is possible to perform efficient software updates.

In this embodiment, the VNF in which a network function (or network device) is virtualized (made into software) is described as a virtual environment, but this embodiment may also be applied to updates of a virtual environment in which a function (or device) other than a network function is virtualized.

The above describes in detail the embodiments of the present invention, but the present invention is not limited to such specific embodiments, and various modifications and variations are possible within the scope of the gist of the present invention as described in the claims.

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 destination 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 (4)

a generating unit configured to generate a schedule of the updates by assigning to each of a plurality of virtual environments one of a plurality of types of update procedures, each of which has a known required time for updating software and a known amount of resource usage over time, and a start timing of the one of the update procedures;
a determination unit configured to determine, each time the schedule is generated, for each 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 a time-series resource amount required when the update is performed based on the schedule and a resource usage status in the node;
having
the generation unit is configured to generate a new schedule by changing at least one of a type and a start timing of the update procedure related to the virtual environment in which the node in which the period occurs is a deployment destination.
A software update control device comprising: the generation unit is configured to select a combination that minimizes a required time for the update in a node in which the period occurs from among a plurality of combinations of the update procedures and the start timings that can eliminate the occurrence of the period.
2. The software update control device according to claim 1, the generation unit is configured to select a combination that minimizes a maximum value of a resource usage amount in a node in which the period occurs from among a plurality of combinations of the update procedure and the start timing that can eliminate the occurrence of the period.
2. The software update control device according to claim 1. The generation unit is configured to select a combination in which the start timing of the update procedure is relatively late, which makes it impossible to switch back, from among a plurality of combinations of the update procedure and the start timing that can eliminate the occurrence of the period.
4. The software update control device according to claim 2 or 3.

Images