WO2021003677A1 - Service upgrade method and apparatus in distributed system, and distributed system - Google Patents

Abstract

A service upgrade method and apparatus in a distributed system, and the distributed system, wherein same relate to the technical field of computers, and can solve the problem of a low upgrade efficiency caused by services in only one node being able to be simultaneously upgraded in a distributed system. A management node in a distributed system acquires an upgrade constraint relationship between a plurality of nodes to be upgraded, determines, according to the upgrade constraint relationship and the minimum number of online nodes of each service to be upgraded from among the plurality of services to be upgraded, nodes to be upgraded, that are upgraded in parallel, from among the plurality of nodes to be upgraded, and upgrades, according to the determined nodes to be upgraded that are upgraded in parallel, the plurality of nodes to be upgraded. The duration for upgrading the plurality of nodes to be upgraded is effectively shortened, and the upgrade efficiency is improved. The upgrade constraint relationship is determined by means of the upgrade order of the plurality of services to be upgraded, and the minimum number of online nodes is the minimum number of nodes simultaneously supplying the same services to be upgraded.

Description

Method, device and distributed system for business upgrade in distributed system Technical field

The embodiments of the present invention relate to the field of computer technology, and in particular to a method, device and distributed system for service upgrade in a distributed system.

Background technique

The system software of the distributed system includes multiple services, which are deployed on multiple nodes of the distributed system. In practice, each service of the system software can be deployed on one or more nodes. As shown in Figure 1, the system software includes service 1, service 2, service 3, and service 4. Service 1 is deployed on node 0 to node 2, service 2 is deployed on node 1, node 2 and node 4, and service 3 is deployed on On node 3 to node 6, service 4 is deployed on node 7 to node 9. When new features of the system software are launched or the version is updated, each business in the system software needs to be upgraded.

At present, the method for upgrading the system software in a distributed system is: all nodes where the system software is deployed are arranged in order of memory quota (memory quota is used to limit the amount of data storage on the node) in descending order Sorting; migrate all data on the node with the largest memory quota in the sort to other nodes, and use the node with the largest memory quota in the sort as the current node to be upgraded; upgrade the business on the current node to be upgraded, and after the upgrade is completed, Migrate the data on the node whose ranking is next to the current node to be upgraded to the current node to be upgraded, and the node whose ranking is next to the current node to be upgraded as the current node to be upgraded, and so on, until the last node in the ranking The business on the company has been upgraded.

The above methods can smoothly realize business upgrades, and can also ensure data integrity without interrupting external services. However, it is necessary to upgrade the nodes on which the system software is deployed one by one, resulting in low upgrade efficiency.

Summary of the invention

This application provides a service upgrade method, device and distributed system in a distributed system, which solves the problem of low upgrade efficiency in a distributed system that can only upgrade the service in one node at the same time.

In the first aspect, this application provides a service upgrade method in a distributed system, which is applied to a management node used to upgrade multiple services to be upgraded deployed in multiple nodes to be upgraded in a distributed system. The upgrade method Including: the management node obtains the upgrade constraint relationship between multiple nodes to be upgraded, and determines the parallel upgrade among the multiple nodes to be upgraded based on the upgrade constraint relationship and the minimum number of online nodes for each of the multiple services to be upgraded And upgrade multiple nodes to be upgraded according to the determined nodes to be upgraded in parallel. The aforementioned upgrade constraint relationship is determined by the upgrade sequence of multiple services to be upgraded, and the minimum number of online nodes is the minimum number of nodes that provide the same service to be upgraded at the same time. The management node determines the nodes to be upgraded for parallel upgrade, and can upgrade the nodes to be upgraded in parallel in one batch, which effectively reduces the time for upgrading multiple nodes to be upgraded and improves the upgrade efficiency.

In a possible design, the above-mentioned "management node determines the node to be upgraded in parallel among the multiple nodes to be upgraded based on the upgrade constraint relationship and the minimum number of online nodes for each of the multiple services to be upgraded" Including: The management node determines the maximum number of parallel upgrade nodes allowed for each service to be upgraded according to the minimum number of online nodes for each service to be upgraded and the service to be upgraded deployed in each of the multiple nodes to be upgraded. Subsequently, the management node determines the node to be upgraded among the multiple nodes to be upgraded according to the maximum number of nodes to be upgraded in parallel and the upgrade constraint relationship allowed for each service to be upgraded. Here, the maximum number of nodes for parallel upgrade is the maximum number of nodes that are upgraded and deployed with the same service to be upgraded at the same time.

In order to ensure the continuity of the service to be upgraded deployed in each node to be upgraded, the management node needs to be based on the minimum number of online nodes for each service to be upgraded and the service to be upgraded deployed in each of the multiple nodes to be upgraded , Determine the maximum number of nodes to be upgraded in parallel for each service to be upgraded, so that when determining the nodes to be upgraded in parallel, for each service to be upgraded, the number of nodes to be upgraded in parallel will not exceed each The maximum number of parallel nodes allowed for each service to be upgraded.

In a possible design, the above-mentioned upgrade constraint relationship is represented by a directed graph, so that the “management node” determines the parallel among the multiple nodes to be upgraded according to the maximum number of nodes to be upgraded in parallel and the upgrade constraint relationship allowed by each service to be upgraded. The method of "upgrading nodes to be upgraded" includes: the management node obtains the in-degree of each node to be upgraded in the directed graph, and performs a first operation, which is: determining the in-degree to be upgraded in the directed graph is zero Nodes, and according to the maximum number of parallel upgrade nodes allowed for each service to be upgraded deployed in the nodes to be upgraded with zero indegree, determine the current batch of nodes to be upgraded from the nodes to be upgraded with zero indegree, and from Remove the current batch of nodes to be upgraded in the directed graph, and update the in-degree of the remaining nodes to be upgraded in the directed graph; after that, the management node determines whether there is a node to be upgraded with zero in-degree among the remaining nodes to be upgraded; if If it exists, return to perform the first operation; if it does not exist, get multiple batches of upgrading multiple nodes to be upgraded and the nodes to be upgraded included in each batch. In this way, the above method of "the management node upgrades the multiple nodes to be upgraded according to the determined nodes to be upgraded in parallel" includes: the management node determines the multiple batches according to the determined batches and the batches included in each batch The upgrade node upgrades multiple nodes to be upgraded.

In a possible design, when it is determined that the nodes to be upgraded in the current batch include at least two types of node combinations, the management node uses the nodes in each node combination as the nodes to be upgraded in the current batch to obtain At least two upgrade options. The upgrade scheme here is to upgrade multiple batches of nodes to be upgraded, and the nodes to be upgraded included in each batch. Each of the at least two types of node combinations includes at least one node to be upgraded. In this case, the management node selects one upgrade plan from at least two upgrade plans, and upgrades multiple nodes to be upgraded according to the selected upgrade plan.

In the process of determining the batch to upgrade multiple nodes to be upgraded, for a certain batch, the management node can determine to upgrade one or some nodes to be upgraded in the batch, or determine whether to upgrade in the batch Upgrade other nodes to be upgraded, so that different node combinations appear. For each node combination, the management node can determine the batch to upgrade all nodes to be upgraded, that is, generate an upgrade plan. In this way, the management node will eventually generate multiple upgrade solutions.

In a possible design, the above method of “the management node upgrades the multiple nodes to be upgraded according to multiple batches and the nodes to be upgraded included in each batch” includes: the management node performs a second operation, and the first The second operation includes: determining the target node corresponding to the node to be upgraded in the current upgrade batch, and sending an upgrade instruction to the node to be upgraded in the current upgrade batch. The upgrade instruction includes the identifier of the target node and is used to indicate that the current upgrade batch The business to be upgraded in the node to be upgraded is migrated to the target node, and the node to be upgraded in the current upgrade batch is upgraded; after that, the management node determines whether the current upgrade batch belongs to the last batch of multiple batches; if the current upgrade If the batch does not belong to the last batch to be upgraded among multiple batches, when it is determined that the nodes to be upgraded in the current upgrade batch have completed the upgrade, the next batch of the current upgrade batch will be regarded as the current upgrade batch and return to execution The second operation.

In order to ensure the integrity and reliability of the data of the service to be upgraded, when upgrading the currently upgraded node to be upgraded, the management node can determine the current upgrade batch according to the determined batch and the reliability of the data of the service to be upgraded The target node corresponding to the node to be upgraded.

In a possible design, the above method of "the management node determining the target node corresponding to the node to be upgraded in the current upgrade batch" includes: the management node determines whether the nodes to be upgraded included in the first batch can guarantee the current upgrade batch The reliability of the data of the business to be upgraded in the node to be upgraded. The first batch here is the batch that is the last to be upgraded among the batches other than the current upgrade batch; if it can be guaranteed , The node to be upgraded included in the first batch is determined to be the target node corresponding to the node to be upgraded in the current upgrade batch; if none of the guarantees are available, then other batches except the first batch and the current upgrade batch are determined In the second step, whether the nodes to be upgraded included in the last batch to be upgraded can guarantee the reliability of the data of the services to be upgraded in the nodes to be upgraded in the current batch of upgrades; this is repeated until the target node is determined.

In a possible design, the above upgrade constraint relationship is represented by a directed graph. The upgrade method provided in this application further includes: the management node determines whether there is a deadlock interconnection node to be upgraded in the upgrade constraint relationship, and the deadlock interconnection The node to be upgraded is a node to be upgraded that forms a ring in the directed graph. Due to the formation of a ring, the deadlocked interconnected nodes to be upgraded cannot be upgraded. Correspondingly, the above method of "the management node determines the nodes to be upgraded in parallel among the multiple nodes to be upgraded based on the upgrade constraint relationship and the minimum number of online nodes for each of the multiple services to be upgraded" includes: When there are no deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship between the nodes to be upgraded, the management node determines multiple nodes to be upgraded according to the upgrade constraint relationship and the minimum number of online nodes for each of the multiple services to be upgraded. The node to be upgraded that is upgraded in parallel among the upgraded nodes.

In a possible design, when there are deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship, the management node sends an alarm message to inform the administrator/operation and maintenance personnel that there are deadlocked interconnected nodes to be upgraded and cannot be performed upgrade.

The alarm information is used to inform the administrators/operations and maintenance personnel that there are deadlocked interconnected nodes to be upgraded and cannot be upgraded, so that the administrators/operations and maintenance personnel can adjust or reconfigure the upgrade constraints on the deadlocked interconnected nodes to be upgraded .

The deadlocked interconnected nodes to be upgraded are the nodes to be upgraded that form a ring in the directed graph. Due to the formation of a ring, the deadlocked interconnected nodes to be upgraded cannot be upgraded. In order to ensure the smooth upgrade of multiple nodes to be upgraded, the management node needs to ensure that there are no deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship.

In a possible design, the above method of "the management node judging whether there are deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship" includes: the management node obtains the in-degree of each node to be upgraded in the directed graph, and executes The third operation, the third operation is: determine the node to be upgraded with zero indegree in the directed graph, remove the node to be upgraded with zero indegree from the directed graph, and update the remaining nodes to be upgraded in the directed graph In degree; after that, the management node determines whether there is a node to be upgraded with zero in degree among the remaining nodes to be upgraded; if it exists, it returns to perform the third operation; if it does not exist, it determines that there is a deadlock interconnection in the upgrade constraint relationship The node to be upgraded.

The node to be upgraded whose entry degree is zero in the directed graph can be upgraded and is not restricted by other nodes during the upgrade. Therefore, if the in-degree of a certain/certain node to be upgraded is zero, it means that the node to be upgraded does not form a ring, and it is not a deadlocked interconnected node to be upgraded. If there is no node to be upgraded with a zero entry degree in the directed graph, and the number of nodes to be upgraded is not zero, it means that these nodes to be upgraded form a ring and cannot be upgraded, which means that these nodes to be upgraded are dead. Lock the interconnected nodes to be upgraded. Based on this, the management node determines whether there are deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship.

In the second aspect, this application provides a management node for executing each module of the first aspect or any one of the possible design methods in the first aspect.

In a third aspect, the present application provides an upgrade device. The upgrade device includes a memory and a processor. The memory is used to store computer execution instructions. When the upgrade device is running, the processor executes the computer execution instructions in the memory to use the The hardware resources in the upgrade device execute the operation steps of the first aspect or any one of the possible designs in the first aspect. The device may specifically be a management node or a chip.

In a fourth aspect, the present application also provides a computer-readable storage medium, including instructions, which when run on a computer, cause the computer to execute any of the above-mentioned first aspect or any of the possible designs of the first aspect The steps of a possible method.

In the fifth aspect, this application also provides a computer program product, including instructions, which when run on a computer, cause the computer to execute any of the above-mentioned first aspect or any of the possible designs of the first aspect Possible method steps.

It can be understood that any of the management nodes, upgrade devices, computer-readable storage media, or computer program products provided above are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to The beneficial effects of the corresponding method will not be repeated here.

Description of the drawings

Figure 1 is a schematic diagram of service deployment in a distributed system in an embodiment of the present invention;

Figure 2 is a structural schematic diagram 1 of a distributed system in an embodiment of the present invention;

3 is a schematic diagram of the hardware structure of a management node in an embodiment of the present invention;

4 is a schematic flowchart of a service upgrade method in a distributed system in an embodiment of the present invention;

FIG. 5 is a schematic diagram of a flow of generating a directed graph in an embodiment of the present invention;

6 is a schematic diagram of a directed graph of nodes to be upgraded with deadlock interconnection in an embodiment of the present invention;

FIG. 7 is a schematic diagram of a process of determining the maximum number of nodes that are allowed to be upgraded in parallel in an embodiment of the present invention;

FIG. 8 is a schematic diagram of generating a first scheme in an embodiment of the present invention;

FIG. 9 is a schematic diagram of generating a second solution in an embodiment of the present invention;

Fig. 10 is a schematic structural diagram of a management node in an embodiment of the present invention.

Detailed ways

The system software in a distributed system usually includes multiple services, which are distributed on multiple nodes of the distributed system. When upgrading the system software, each business of the system software needs to be upgraded. In actual applications, there is a sequence of upgrades for each service in the system software. For example, service A must be upgraded after service B is upgraded. This makes the nodes deployed with services in the system software have a sequence during upgrade. In the embodiment of the present invention, the sequence of nodes during upgrade is referred to as an upgrade constraint relationship.

The embodiment of the present invention provides a method for upgrading services in a distributed system. The method determines the nodes that can be upgraded in parallel among the multiple nodes on the premise that the upgrade constraint relationship between the multiple nodes is satisfied, so as to reduce the upgrade time and improve the upgrade efficiency.

The distributed systems provided by the embodiments of the present invention include, but are not limited to, distributed storage systems and distributed file systems.

Figure 2 shows a structure of a distributed system provided by an embodiment of the present invention. As shown in FIG. 2, the distributed system includes a management node 20 and multiple nodes 21 to be upgraded. In the embodiment of the present invention, the service included in the system software that needs to be upgraded is called the service to be upgraded, and the node where one or more services to be upgraded are deployed is called the node to be upgraded.

The node 21 to be upgraded may be a physical machine (such as a server), or a virtual machine (virtual machine, VM) deployed on the physical machine.

The management node 20 is used to manage each node 21 to be upgraded, for example: upgrade the service to be upgraded run by each node 21 to be upgraded. In this embodiment, the management node 20 is an independent physical machine or virtual machine. However, in other embodiments, the management node 20 may also be any node to be upgraded in the distributed system.

Fig. 3 shows a hardware structure of the management node 20 in the embodiment of the present invention. As shown in FIG. 3, the management node 20 includes a processor 31, a memory 32, a communication interface 33, and a bus 34. The processor 31, the memory 32, and the communication interface 33 may be connected by a bus 34.

The processor 31 is the control center of the management node 20, and may be a general-purpose central processing unit (central processing unit, CPU), or other general-purpose processors. Among them, the general-purpose processor may be a microprocessor or any conventional processor.

As an example, the processor 31 may include one or more CPUs, such as CPU 0 and CPU 1 shown in FIG. 3.

The memory 32 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM), or other types that can store information and instructions The dynamic storage device can also be electrically erasable programmable read-only memory (EEPROM), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store instructions or data structures The desired program code and any other medium that can be accessed by the computer, but not limited to this.

In a possible implementation manner, the memory 32 may exist independently of the processor 31. The memory 32 may be connected to the processor 31 through a bus 34, and is used to store instructions or program codes. When the processor 31 calls and executes the instructions or program codes stored in the memory 32, it can implement the service upgrade method in the distributed system provided by the embodiment of the present invention.

In another possible implementation manner, the memory 32 may also be integrated with the processor 31.

The communication interface 33 is used to connect the management node 20 with other devices (such as the node 21 to be upgraded) through a communication network. The communication network may be Ethernet, radio access network (RAN), or wireless local area network (RAN). area networks, WLAN), etc. The communication interface 33 may include a receiving unit for receiving data, and a sending unit for sending data.

The bus 34 may be an Industry Standard Architecture (ISA) bus, Peripheral Component Interconnect (PCI) bus, or Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in FIG. 3 to represent, but it does not mean that there is only one bus or one type of bus.

It should be pointed out that the structure shown in FIG. 3 does not constitute a limitation on the management node. In addition to the components shown in FIG. 3, the management node 20 may include more or less components than those shown in the figure, or a combination Certain components, or different component arrangements.

Similar to the hardware structure of the management node 20, the node 21 to be upgraded also includes components such as a processor, a memory, a communication interface, and a bus. Different from the management node 20, the processor in the node 21 to be upgraded is used to complete the functions of the node 21 to be upgraded when calling and executing instructions or program codes stored in the memory, such as executing the service to be upgraded, or according to management Node commands, upgrades to be upgraded, etc. When the processor in the management node 20 calls and executes instructions or program codes stored in the memory, it is used to complete the functions of the management node 20, for example: determining the nodes to be upgraded for parallel upgrades.

The service upgrade method in the distributed system provided by the embodiment of the present invention will be described below with reference to the accompanying drawings.

FIG. 4 is a schematic flowchart of a service upgrade method in a distributed system provided by an embodiment of the present invention. As shown in Figure 4, the service upgrade method includes:

S401: The management node 20 obtains the upgrade constraint relationship among multiple nodes 21 to be upgraded.

The upgrade constraint relationship in the embodiment of the present invention is used to indicate the sequence of multiple nodes 21 to be upgraded during the upgrade.

A service to be upgraded deployed in a node 21 to be upgraded can only be upgraded after the service to be upgraded deployed in other nodes to be upgraded 21 is upgraded. In other words, a certain node 21 to be upgraded can only be upgraded after the upgrade of other nodes 21 to be upgraded is completed.

For example, node 1 is deployed with service 1 and node 2 is deployed with service 1 and service 2, and service 1 must be upgraded after service 2 is upgraded. In this way, node 1 must be upgraded after node 2 is upgraded. This forms the upgrade constraint relationship between node 1 and node 2.

The management node 20 uses a directed graph to represent the upgrade constraint relationship among the multiple nodes 21 to be upgraded. In the directed graph of the embodiment of the present invention, the nodes 21 to be upgraded are connected by directed edges, and the node 21 to be upgraded at the arrow end must be upgraded after the node 21 to be upgraded at the non-arrow end is upgraded.

Exemplarily, if multiple nodes to be upgraded include node 1, node 2, node 3, node 4, node 5, and node 6, the upgrade constraint relationship between these 6 nodes to be upgraded is: node 1 needs to be between node 2 and node 2. Node 6 can be upgraded after the upgrade is completed (constraint relationship 1), node 2 can be upgraded after node 5 is upgraded (constraint relationship 2), and node 3 can be upgraded after node 4 and node 5 are upgraded (constraint relationship 3); The node 4 needs to be upgraded after the node 5 is upgraded (constraint relationship 4); then the management node 20 uses the process shown in FIG. 5 to generate a directed graph according to the upgrade constraint relationship. The directed graph can reflect constraint relationship 1 to constraint relationship 4.

S402: The management node 20 judges whether there are deadlocked interconnected nodes 21 to be upgraded in the upgrade constraint relationship between the multiple nodes 21 to be upgraded.

The deadlocked interconnected nodes to be upgraded means that the constraint relationship between multiple nodes to be upgraded 21 forms a ring. Each node 21 to be upgraded that forms a deadlock interconnection cannot be upgraded.

Exemplarily, in the directed graph shown in Figure 6, node 3, node 4, and node 5 form a ring. Node 5 can be upgraded after node 3 is upgraded, and node 4 can be upgraded after node 5 is upgraded. , Node 3 needs to be upgraded after node 4 is upgraded. That is, node 3, node 4, and node 5 form a deadlock interconnection, and node 3, node 4, and node 5 are all deadlock interconnected nodes.

In the directed graph shown in Figure 5, there are no nodes forming a ring, so there are no deadlocked interconnected nodes.

Specifically, the way for the management node 20 to determine whether there are deadlocked interconnected nodes 21 to be upgraded in the upgrade constraint relationship among the multiple nodes 21 to be upgraded is to obtain the in-degree of each node 21 to be upgraded in the directed graph (with The number of arrows pointing to the node 21 to be upgraded in the figure), and the node 21 to be upgraded whose current in-degree is zero is determined. The node 21 to be upgraded with an entry degree of zero indicates that the node 21 to be upgraded is not restricted by other nodes when it is upgraded. The node 21 to be upgraded whose current in-degree is zero is removed from the directed graph. When removing the node 21 to be upgraded with a current indegree of zero, the directed edges related to the node to be upgraded 21 with a current indegree of zero are also removed at the same time. The management node 20 updates the in degrees of the remaining nodes to be upgraded in the directed graph, determines the nodes to be upgraded 21 whose current in degrees in the remaining nodes to be upgraded is zero, and removes the current in degrees of the remaining nodes to be upgraded from the directed graph as Zero node 21 to be upgraded, so, repeat execution. If the number of remaining nodes to be upgraded is zero, the management node 20 determines that there are no deadlocked interconnected nodes 21 to be upgraded in the directed graph; if the number of remaining nodes to be upgraded in the directed graph is not zero, but does not exist If the node 21 to be upgraded has an in-degree of zero, the management node 20 determines that there are deadlocked interconnected nodes in the directed graph.

Exemplarily, in the directed graph shown in FIG. 5, the in-degrees of node 5 and node 6 are both 0, the in-degrees of node 2 and node 4 are both 1, and the in-degrees of node 1 and node 3 are 2. It can be seen that the nodes whose current in-degree is 0 are node 5 and node 6. The management node 20 removes nodes 5 and 6 from the directed graph shown in Figure 5, and updates the in-degrees of the remaining nodes (node 1, node 2, node 3, and node 4). The updated in-degrees of the remaining nodes are : The in-degree of node 2 and node 4 are both 0, and the in-degree of node 1 and node 3 is 1. At this time, the nodes with a current indegree of 0 are node 2 and node 4, and the management node 20 removes the nodes with a current indegree of 0 from the remaining nodes (node 1, node 2, node 3, and node 4) from the directed graph, That is, node 2 and node 4 are removed from node 1, node 2, node 3, and node 4. After that, the management node 20 updates the in degrees of the remaining nodes (node 1 and node 3). The updated in degrees of the remaining nodes are: The in-degree of node 1 and node 3 is 0. Correspondingly, at this time, the nodes whose current in-degree is 0 are node 1 and node 3, and the management node 20 removes node 1 and node 3. At this time, the number of remaining nodes is 0. Therefore, the management node 20 determines that There are no deadlocked interconnected nodes in the directed graph.

In the directed graph shown in FIG. 6, only the in-degree of node 6 is 0, and the management node 20 first removes node 6 from the directed graph and updates the in-degree of the remaining nodes (node 1 to node 5). At this time, the updated in-degrees of the remaining nodes are all 1, and the number of remaining nodes is not zero. Therefore, the management node 20 determines that there are deadlocked interconnected nodes in the directed graph shown in FIG. 6.

If the management node 20 determines that there are deadlocked interconnected nodes 21 to be upgraded in the upgrade constraint relationship between the multiple nodes to be upgraded 21, S403 is executed. If the management node 20 determines that there is no deadlocked interconnected node 21 to be upgraded in the upgrade constraint relationship between the plurality of nodes to be upgraded 21, S404 is executed.

S403. The management node 20 sends an alarm message to inform the administrator/operation and maintenance personnel that there are deadlocked interconnected nodes to be upgraded, and the upgrade cannot be performed.

The alarm information can be text, audio, etc. For example: the alarm message is "There are deadlocked interconnected nodes to be upgraded and cannot be upgraded". If the alarm information is text, the management node 20 can display the alarm information. If the alarm information is audio, the management node 20 broadcasts the alarm information.

Optionally, the alarm information includes the identification of the deadlocked interconnected node to be upgraded. For example: the alarm message is "Node 3, Node 4, and Node 5 are deadlocked interconnected nodes to be upgraded and cannot be upgraded".

The management node 20 sends out an alarm message to inform the administrator/operation and maintenance personnel that there are deadlocked interconnected nodes to be upgraded and cannot be upgraded, so that the administrator/operations and maintenance personnel can adjust or reconfigure the deadlocked interconnected nodes to be upgraded. Upgrade the constraint relationship. If there are no deadlocked interconnected nodes to be upgraded in the adjusted upgrade constraint relationship or the reconfigured upgrade constraint relationship, S404 is executed.

S404. The management node 20 obtains the service to be upgraded deployed in each node 21 to be upgraded and the maximum number of nodes that are allowed to be upgraded in parallel for each service to be upgraded.

In order to ensure the continuity of the service to be upgraded, when the service to be upgraded is upgraded, one or more nodes on which the service to be upgraded is deployed need to be reserved, and these nodes are not upgraded temporarily. The number of nodes that will not be upgraded temporarily is called the minimum number of online nodes required by the service to be upgraded. The minimum number of online nodes required by the service to be upgraded is pre-configured.

After determining the minimum number of online nodes required by the service to be upgraded, the management node 20 determines the maximum number of parallel upgrade nodes allowed for the service to be upgraded according to the number of nodes on which the service to be upgraded is deployed in the distributed system. That is, under the condition that the minimum number of online nodes required by the service to be upgraded is met, the maximum number of nodes on which the service to be upgraded is deployed that can be upgraded in parallel is determined.

The management node 20 obtains the minimum number of online nodes required by each service to be upgraded and the distribution information of each service to be upgraded in the distributed system from the configuration file of the service to be upgraded (for example, service 1 to be upgraded is distributed in the node to be upgraded) 1), and according to the minimum number of online nodes required by each service to be upgraded and the distribution information of each service to be upgraded in the distributed system, determine the service to be upgraded deployed in each node 21 to be upgraded and each service to be upgraded The maximum number of concurrent upgrade nodes allowed for the upgrade business.

Exemplarily, as shown in FIG. 7(A), the management node 20 obtains the minimum number of online nodes required by each service to be upgraded and the distribution information of each service to be upgraded in the distributed system: Service 1 is deployed in node 5 and node 6. The minimum number of online nodes required for the service to be upgraded is 1; service 2 is deployed in node 1 and node 2, and the minimum number of online nodes required for the service to be upgraded is 1; Service 3 to be upgraded is deployed in node 3 and node 4, and the minimum number of online nodes required by the service to be upgraded is 1. Based on this information, the management node 20 determines the service to be upgraded deployed in each of the nodes 1 to 6 (refer to (B) in Figure 7): the service to be upgraded is deployed in node 1, and the service to be upgraded is deployed in node 2 to be upgraded. Service 2, Node 3 is deployed with service 3 to be upgraded, node 4 is deployed with service 3 to be upgraded, node 5 is deployed with service 1 to be upgraded, and node 6 is deployed with service 1 to be upgraded. Since the minimum number of online nodes required for service 1 to be upgraded is 1, and there are two nodes deployed with service 1 to be upgraded in a distributed system: node 5 and node 6, therefore, when upgrading service 1 to be upgraded, at most Upgrade one node, that is, the maximum number of concurrent upgrade nodes allowed for service 1 to be upgraded is 1. Similarly, since the minimum number of online nodes required for service 2 to be upgraded is 1, and there are two nodes deployed with service 2 to be upgraded in the distributed system: node 1 and node 2, therefore, when upgrading service 2 to be upgraded, Only one node can be upgraded at most, that is, the maximum number of concurrent upgrade nodes allowed for service 2 to be upgraded is 1. Since the minimum number of online nodes required for service 3 to be upgraded is 1, and there are two nodes deployed with service 3 to be upgraded in a distributed system: node 3 and node 4, when upgrading service 3 to be upgraded, at most Upgrade one node, that is, the maximum number of concurrent upgrade nodes allowed for service 3 to be upgraded is 1. (C) in FIG. 7 shows the maximum number of nodes that are allowed to be upgraded in parallel for each of the business 1 to business 3 to be upgraded in this example.

S405. The management node 20 determines the batch to upgrade the multiple nodes 21 to be upgraded according to the constraint relationship between the multiple nodes 21 to be upgraded and the maximum number of nodes that are allowed to be upgraded in parallel for the services to be upgraded deployed in each node 21 to be upgraded. .

From the foregoing description, it can be seen that the node 21 to be upgraded whose in-degree is zero in the directed graph is not restricted by other nodes 21 to be upgraded during the upgrade. Therefore, the management node 20 may choose to first upgrade the node 21 to be upgraded whose in-degree is zero. In order to ensure the continuity of the service to be upgraded deployed in the node 21 to be upgraded with an in-degree of zero, the management node 20 also needs to be based on "the service to be upgraded deployed in the node to be upgraded 21 with an in-degree of zero" and "the in-degree is zero. The maximum number of parallel upgrade nodes allowed for each service to be upgraded deployed in the nodes 21 to be upgraded", the nodes to be upgraded 21 for the first batch of upgrades are determined from the nodes to be upgraded 21 whose in-degree is zero. For example, the nodes to be upgraded whose in-degree is zero in Fig. 5 are node 5 and node 6. From (B) in Figure 7, it can be found that the services deployed in node 5 and node 6 are all service 1. In addition, it can be found from (C) in Fig. 7 that the maximum number of concurrent upgrade nodes allowed for service 1 is 1, and it can be determined that the first batch of upgraded nodes is node 5 or node 6. In this way, the node to be upgraded for the first batch of upgrade is node 5 as an upgrade plan (this plan is called the first plan), and the node to be upgraded for the first batch of upgrade is node 6 as another upgrade plan (the This program is called the second program).

If there are multiple upgrade plans when determining the nodes 21 to be upgraded to be upgraded in the first batch, the management node 20 respectively determines the batches required for each upgrade plan to upgrade all the nodes 21 to be upgraded.

The method for the management node 20 to determine the batches required to upgrade all the nodes 21 to be upgraded for each upgrade scheme is: the management node 20 removes the nodes 21 to be upgraded in the first batch of upgrades from the directed graph, for example, as shown in FIG. 8 As shown, when the first scheme is adopted, node 5 is first removed from the directed graph. After removing the nodes 21 to be upgraded in the first batch of upgrades, the management node 20 updates the in-degree of the remaining nodes to be upgraded in the directed graph, and determines the node to-be-upgraded 21 whose in-degree is zero among the remaining nodes to be upgraded. As shown in FIG. 8, after node 5 is removed, the nodes with zero in-degree of node 1, node 2, node 3, node 4, and node 6 include node 2, node 4, and node 6. Then, the management node 20 according to "the service to be upgraded deployed in the node 21 to be upgraded with zero in-degree of the remaining nodes to be upgraded" and "the service to be upgraded deployed in the node to be upgraded 21 with zero in-degree is allowed Maximum number of nodes to be upgraded in parallel", the nodes to be upgraded 21 for the second batch of upgrades are determined from the nodes to be upgraded 21 whose in-degree is zero among the remaining nodes to be upgraded. For example, in Figure 8, the node 2 deploys service 2 to be upgraded, the node 4 deploys the service 3 to be upgraded, the node 6 deploys the service 1 to be upgraded, and the maximum number of concurrent upgrade nodes allowed by the service 1 to be upgraded, the service 2 to be upgraded The maximum number of parallel upgrade nodes allowed and the maximum number of parallel upgrade nodes allowed for service 3 to be upgraded are both 1. Therefore, parallel upgrade of node 2, node 4, and node 6 will not upgrade service 1, service 2 and service to be upgraded. The continuity of the upgrade service 3 is affected. In this way, the management node 20 determines that the nodes to be upgraded in the second batch of upgrades are node 2, node 4, and node 6.

If there are multiple upgrade schemes when determining the nodes 21 to be upgraded to be upgraded in the second batch, the management node 20 also needs to separately determine the batches required for each upgrade scheme to upgrade the remaining nodes 21 to be upgraded.

After determining the nodes to be upgraded 21 for the second batch of upgrades, the management node 20 continues to remove the nodes to be upgraded for the second batch of upgrades from the directed graph, and determines the nodes to be upgraded 21 and the first batch of upgrades. The method of upgrading the nodes 21 to be upgraded in the second batch determines the batches of the remaining nodes 21 to be upgraded until there is no node 21 to be upgraded in the directed graph. As shown in Figure 8, after removing node 2, node 4, and node 6, the in-degrees of node 1 and node 3 are both 0, and the management node 20 determines that node 1 and node 3 can be upgraded in parallel, taking node 1 and node 3 as The node to be upgraded for the third batch of upgrades. After deleting node 1 and node 3, there are no nodes in the directed graph, then the management node 20 determines that the first solution needs to be upgraded in 3 batches to complete the upgrade of all nodes to be upgraded, specifically: the first batch: node 5 →The second batch: node 2, node 4, node 6 → the third batch: node 1, node 3.

In combination with the above description, the method for the management node 20 to determine the batches required to upgrade all the nodes 21 to be upgraded using the second solution is described. This method is the same as that of the management node 20 using the first solution to upgrade all the nodes 21 to be upgraded. The method for the required batch is the same. FIG. 9 shows a process in which the management node 20 determines the batches required to upgrade all the nodes 21 to be upgraded using the second scheme. First, the management node 20 removes the node to be upgraded in the first batch of upgrades: node 6, and updates the in-degree of the remaining nodes (node 1 to node 5). The updated in-degree of the remaining nodes are: the in-degree of node 5 is 0, the in-degree of node 1, node 2, and node 4 are all 1, and the in-degree of node 3 is 2. Since the node 5 with an entry degree of 0 is deployed with service 1 to be upgraded, and the maximum number of concurrent upgrade nodes allowed for service 1 to be upgraded is 1, the management node 20 determines that the node to be upgraded for the second batch of upgrades is node 5. After determining that the node to be upgraded for the second batch of upgrade is node 5, the management node 20 removes node 5 and updates the in-degrees of the remaining nodes (node 1 to node 4). The updated in-degrees of the remaining nodes are: node 2 And the in-degree of node 4 is 0, and the in-degree of node 1 and node 3 is 1. Since service 2 to be upgraded is deployed in node 2 and service 3 to be upgraded is deployed in node 4, the maximum number of concurrent upgrade nodes allowed for service 2 to be upgraded and the maximum number of concurrent upgrade nodes allowed for service 3 to be upgraded are both 1, so The parallel upgrade of node 2 and node 4 will not affect the continuity of the service to be upgraded 2 and the service to be upgraded 3. In this way, the management node 20 determines that the nodes to be upgraded in the third batch of upgrades are node 2 and node 4. After determining that the nodes to be upgraded for the third batch of upgrades are node 2 and node 4, management node 20 removes node 2 and node 4, and the in-degrees of node 1 and node 3 in the remaining nodes are both 0, and management node 20 determines node 1 And node 3 can be upgraded in parallel, and node 1 and node 3 are used as the nodes to be upgraded in the fourth batch of upgrades. After deleting node 1 and node 3, there are no nodes in the directed graph, and the management node 20 determines that the second solution needs to be upgraded in 4 batches to complete the upgrade of all nodes to be upgraded, specifically: the first batch: node 6 → The second batch: node 5 → the third batch: node 2, node 4 → the fourth batch: node 1, node 3.

In summary, the management node 20 can determine a variety of upgrade schemes according to the maximum number of concurrent upgrade nodes allowed by the service to be upgraded and the constraint relationship between the nodes 21 to be upgraded. After determining multiple upgrade solutions, the management node 20 can select one upgrade solution from the multiple upgrade solutions according to actual needs, and perform the upgrade according to the selected upgrade solution.

Generally, an upgrade solution with fewer batches takes less time to upgrade. Therefore, the management node 20 can select an upgrade solution with the fewest batches from a variety of upgrade solutions.

Exemplarily, the first solution shown in FIG. 8 includes 3 batches (the first batch to the third batch), and the second solution shown in FIG. 9 includes 4 upgrade batches (the first batch to the third batch). Four batches), the batches included in the first solution are smaller than the batches included in the second solution. Therefore, the management node 20 can choose to use the first solution to upgrade the node to be upgraded.

It should be noted that the management node 20 selecting the upgrade solution with the fewest batches from the multiple upgrade solutions is only a possible example, and is not intended as a limitation to the embodiment of the present invention. In addition to considering the time consumed for the upgrade, the management node can also consider factors such as system reliability, system load, idle resources, etc., to more specifically select an upgrade plan that adapts to current needs. This is no longer in the embodiment of the present invention. Go into details one by one.

S406: The management node 20 sequentially instructs the nodes 21 to be upgraded in each batch to upgrade according to the determined batches.

In a scenario of multiple batches, the management node 20 sends an upgrade instruction to the nodes 21 to be upgraded in the first batch to instruct the nodes 21 to be upgraded in the first batch to upgrade. After the upgrade of the nodes 21 to be upgraded in the first batch is completed, the management node 20 sends an upgrade instruction to the nodes 21 to be upgraded in the second batch to instruct the nodes 21 to be upgraded in the second batch to upgrade. In this way, the execution is repeated until all the nodes 21 to be upgraded are upgraded.

Generally, in order to ensure the smooth execution of the service and the integrity of the data, when a certain service in the node is upgraded, the data of the service in the node needs to be migrated to another node. When the service upgrade is completed, the data of the service in other nodes needs to be migrated back to the node.

Exemplarily, when the service 1 in node 5 needs to be upgraded, node 5 migrates the data of service 1 in node 5 to node 1; after the upgrade of node 5 is completed, the data of service 1 is migrated back from node 1 Go to node 5.

In the embodiment of the present invention, the management node 20 sends an upgrade instruction to the node 21 to be upgraded in the second batch after the upgrade of the node 21 to be upgraded in the first batch is completed, so as to realize "the node to be upgraded in the second batch Synchronization of "21 upgrade" and "data migration of node 21 to be upgraded in the first batch".

In other words, the solution provided by the embodiment of the present invention realizes the synchronization of "the upgrade of the node 21 to be upgraded in the i-th batch" and the "data back migration of the node 21 to be upgraded in the i-1th batch", which effectively improves Upgrade efficiency.

For each node 21 to be upgraded, the management node 20 may determine a data migration destination node for the node 21 to be upgraded according to the determined batch and the reliability of the data of the service to be upgraded. In this way, the management node 20 can send an upgrade instruction including the identifier of the destination node to the node 21 to be upgraded to instruct to complete the upgrade of the service to be upgraded after migrating the data of the service to be upgraded to the destination node.

In a distributed system, in order to improve the reliability of the data, the data of a certain service is often stored on different nodes in a strip or multiple copies. When the management node 20 determines the destination node, it needs to consider that the reliability of the service data can be guaranteed after the service data is migrated.

For example, if the data of service 1 is stored in node 1 and node 2 in multiple copies, the management node 20 cannot determine node 2 as the destination node for node 1 to perform data migration. If the data of business 1 in node 1 is migrated to node 2, only node 2 in the distributed system stores the data of business 1. Once node 2 fails, or the data of business 1 in node 2 is destroyed, then business 1 Will not be able to run in this distributed system.

For each node to be upgraded in a certain batch (take batch b as an example), the management node 20 can first determine the batch to be upgraded in the batches other than batch b (take batch b as an example). Step a is an example) When the included node 21 to be upgraded serves as the destination node, can the reliability of the data be guaranteed. If the data reliability can be guaranteed when the node 21 to be upgraded in batch a serves as the destination node, the management node 20 determines the node 21 to be upgraded in batch a as the destination node. If each node 21 to be upgraded in batch a cannot guarantee the reliability of the data as a destination node, the management node 20 determines the final batch to be upgraded among other batches except batch b and batch a When the included node 21 to be upgraded serves as the destination node, can the reliability of the data be guaranteed. In this way, repeat the execution until the destination node is determined.

Exemplarily, in combination with the foregoing example, if the management node 20 selects the first solution from the first solution shown in FIG. 8 and the second solution shown in FIG. 9, and upgrades the node to be upgraded according to the first solution. When it is necessary to upgrade the node 5 in the first batch, the management node 20 first judges the nodes 1 and 3 in the third batch (except for the first batch, the last batch to be upgraded) as the destination nodes, Whether it can meet the reliability of the data of service 1 to be upgraded in node 5. If neither node 1 nor node 3 as the destination node can meet the reliability of the data of service 1 to be upgraded, the management node 20 judges the second batch (except for the first batch and the third batch, the final upgrade When node 2, node 4, and node 6 in the batch) are used as destination nodes, can they satisfy the reliability of the data of the service 1 to be upgraded? If one or more of node 2, node 4, and node 6 as the destination node can meet the reliability of the data of the service 1 to be upgraded, the management node 20 will take it as the destination node of node 5 and send the destination node including the destination node to node 5. Upgrade instructions for the node's identity.

In summary, on the premise that the management node 20 satisfies the upgrade constraint relationship among the multiple nodes 21 to be upgraded, it is determined to upgrade the multiple nodes 21 to be upgraded in batches, that is, it is determined that the multiple nodes 21 to be upgraded can be upgraded in parallel. The number of nodes to be upgraded effectively reduces the time for upgrading multiple nodes 21 to be upgraded, and improves the upgrade efficiency.

The foregoing mainly introduces the solutions provided by the embodiments of the present invention from the perspective of methods. In order to realize the above-mentioned functions, it includes hardware structures and/or software modules corresponding to each function. Those skilled in the art should easily realize that in combination with the units and algorithm steps of the examples described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed by hardware or computer software-driven hardware depends on the specific application and design constraint conditions of the technical solution. Professionals and technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of this application.

In the embodiment of the present invention, the management node may be divided into functional modules according to the foregoing method examples. For example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The above-mentioned integrated modules can be implemented in the form of hardware or software functional modules. It should be noted that the division of modules in the embodiment of the present invention is illustrative, and is only a logical function division, and there may be other division methods in actual implementation.

As shown in FIG. 10, it is a schematic structural diagram of a management node 100 provided by an embodiment of the present invention. The management node 100 is used to manage the upgrade of multiple nodes to be upgraded in the distributed system, for example, to execute the service upgrade method in the distributed system shown in FIG. 4. The management node 100 may include an acquisition unit 1001, a determination unit 1002, and an upgrade management unit 1003.

The obtaining unit 1001 is configured to obtain the upgrade constraint relationship between multiple nodes to be upgraded, and the upgrade constraint relationship is determined by the upgrade sequence of the multiple services to be upgraded. For example, in conjunction with FIG. 4, the acquiring unit 1001 may be used to execute S401. The determining unit 1002 is configured to determine the nodes to be upgraded that are upgraded in parallel among the multiple nodes to be upgraded according to the upgrade constraint relationship obtained by the obtaining unit 1001 and the minimum number of online nodes for each of the multiple services to be upgraded. The number of online nodes is the minimum number of nodes that provide the same service to be upgraded at the same time. The upgrade management unit 1003 is configured to upgrade multiple nodes to be upgraded according to the nodes to be upgraded that are determined in parallel by the determining unit 1002.

Optionally, the determining unit 1002 is specifically configured to: determine the allowable service for each service to be upgraded according to the minimum number of online nodes for each service to be upgraded and the service to be upgraded deployed in each of the multiple nodes to be upgraded The maximum number of parallel upgrade nodes is the maximum number of nodes that are upgraded and deployed at the same time with the same service to be upgraded; according to the maximum number of concurrent upgrade nodes allowed for each service to be upgraded and the upgrade constraint relationship, determine multiple The node to be upgraded that is upgraded in parallel among the upgraded nodes. For example, with reference to FIG. 4, the determining unit 1002 may be used to execute S404 and S405.

Optionally, the aforementioned upgrade constraint relationship is represented by a directed graph; the determining unit 1002 is specifically configured to: obtain the in-degree of each node to be upgraded in the directed graph; perform the first operation: determine that the in-degree in the directed graph is zero Nodes to be upgraded, and according to the maximum number of parallel upgrade nodes allowed for each service to be upgraded deployed in the nodes to be upgraded with zero in-degree, determine the current batch of nodes to be upgraded from the nodes to be upgraded with zero in-degree, And remove the current batch of nodes to be upgraded from the directed graph, and update the in-degree of the remaining nodes to be upgraded in the directed graph; determine whether there are still nodes to be upgraded with zero in-degree in the remaining nodes to be upgraded; if it exists, Return to perform the first operation; if it does not exist, obtain multiple batches for upgrading multiple nodes to be upgraded and the nodes to be upgraded included in each batch. The upgrade management unit 1003 is specifically configured to: upgrade multiple nodes to be upgraded according to the multiple batches determined by the determining unit 1002 and the nodes to be upgraded included in each batch.

Optionally, the determining unit 1002 is specifically configured to: when it is determined that the nodes to be upgraded in the current batch include at least two kinds of node combinations, each node in each node combination is used as the nodes to be upgraded in the current batch to obtain at least There are two upgrade schemes. The upgrade scheme is to upgrade multiple batches of nodes to be upgraded, and the nodes to be upgraded included in each batch, and each of the at least two node combinations includes at least one node to be upgraded. The determining unit 1002 is also used to select one upgrade solution from at least two upgrade solutions.

Optionally, the upgrade management unit 1003 is specifically configured to: perform a second operation: determine the target node corresponding to the node to be upgraded in the current upgrade batch, and send an upgrade instruction to the node to be upgraded in the current upgrade batch, the upgrade instruction including the target The identification of the node, the upgrade instruction is used to instruct to migrate the business to be upgraded in the node to be upgraded in the current upgrade batch to the target node, and to upgrade the node to be upgraded in the current upgrade batch; determine whether the current upgrade batch belongs to multiple batches If the current upgrade batch does not belong to the last upgrade batch among multiple batches, when it is determined that the nodes to be upgraded in the current upgrade batch have completed the upgrade, the next upgrade batch The batch is used as the current upgrade batch and returns to perform the second operation.

Optionally, the aforementioned upgrade constraint relationship is represented by a directed graph, and the management node 100 further includes a judgment unit 1004. The determining unit 1004 is used to determine whether there are deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship, and the deadlocked interconnected nodes to be upgraded are nodes to be upgraded that form a ring in the directed graph. The determining unit 1002 is specifically configured to: when the determining unit 1004 determines that there are no deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship between the multiple nodes to be upgraded, according to the upgrade constraint relationship and each of the multiple services to be upgraded The minimum number of online nodes for the business determines the node to be upgraded among multiple nodes to be upgraded in parallel. For example, in conjunction with FIG. 4, the judging unit 1004 may be used to execute S402.

Of course, the management node 100 provided in the embodiment of the present invention includes but is not limited to the above-mentioned modules. For example, the management node 100 may also include a storage unit 1005. The storage unit 1005 can be used to store the program code of the management node 100, and can also be used to store data generated during the operation of the management node 100, such as upgrading multiple batches of nodes to be upgraded.

Another embodiment of the present invention also provides a computer-readable storage medium that stores instructions in the computer-readable storage medium. When the instructions run on a computer, the computer executes the management node in the method flow shown in the foregoing method embodiment. The various steps performed.

In another embodiment of the present invention, there is also provided a computer program product. The computer program product includes computer instructions. When the instructions run on a computer, the computer executes the operations performed by the management node in the method flow shown in the foregoing method embodiments. Various steps.

Another embodiment of the present invention also provides a distributed system. The distributed system may include a management node 100 and multiple nodes to be upgraded.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using a software program, it may be implemented in the form of a computer program product in whole or in part. The computer program product includes one or more computer instructions. When the computer execution instructions are loaded and executed on the computer, the process or function according to the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a dedicated computer, a computer network, or other programmable devices. Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from a website, computer, server, or data center through a cable (such as Coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL) or wireless (such as infrared, wireless, microwave, etc.) transmission to another website site, computer, server, or data center. The computer-readable storage medium may be any available medium that can be accessed by a computer or may include one or more data storage devices such as a server or a data center that can be integrated with the medium. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)).

The above are only specific implementations of the application. Those skilled in the art can think of changes or substitutions according to the specific implementation manners provided by this application, and they should all be covered by the protection scope of this application.

Claims (13)

1. A service upgrade method in a distributed system is characterized in that it is applied to a management node in a distributed system, and the management node is used to upgrade multiple services to be upgraded deployed among multiple nodes to be upgraded. Upgrade methods include:

   Acquiring an upgrade constraint relationship between the multiple nodes to be upgraded, where the upgrade constraint relationship is determined by an upgrade sequence of the multiple services to be upgraded;

   According to the upgrade constraint relationship and the minimum number of online nodes for each service to be upgraded in the multiple services to be upgraded, determine the nodes to be upgraded in parallel among the multiple nodes to be upgraded, and the minimum number of online nodes is the same time The minimum number of nodes that provide the same service to be upgraded;

   Upgrade the multiple nodes to be upgraded according to the determined nodes to be upgraded in parallel.
2. The service upgrade method according to claim 1, wherein the plurality of services to be upgraded are determined according to the upgrade constraint relationship and the minimum number of online nodes of each service to be upgraded in the multiple services to be upgraded The nodes to be upgraded that are upgraded in parallel, including:

   According to the minimum number of online nodes for each service to be upgraded and the service to be upgraded deployed in each of the multiple nodes to be upgraded, the maximum concurrent upgrade node allowed for each service to be upgraded is determined The maximum number of nodes for parallel upgrade is the maximum number of nodes that are simultaneously upgraded and deployed with the same service to be upgraded;

   According to the maximum number of parallel upgrade nodes allowed for each service to be upgraded and the upgrade constraint relationship, determine the nodes to be upgraded that are to be upgraded in parallel among the multiple nodes to be upgraded.
3. The service upgrade method according to claim 2, wherein the upgrade constraint relationship is represented by a directed graph, and the maximum number of concurrent upgrade nodes allowed for each service to be upgraded is based on the upgrade constraint relationship , Determining the node to be upgraded that is upgraded in parallel among the plurality of nodes to be upgraded includes:

   Acquiring the in-degree of each node to be upgraded in the directed graph;

   Perform the first operation: determine the node to be upgraded with zero in-degree in the directed graph; according to the maximum number of concurrent upgrade nodes allowed for each service to be upgraded deployed in the node to be upgraded with zero in-degree, from The nodes to be upgraded in the current batch are determined among the nodes to be upgraded whose entry is zero; the nodes to be upgraded in the current batch are removed from the directed graph, and the remaining nodes to be upgraded in the directed graph are updated In degree

   Judging whether there is a node to be upgraded with an indegree of zero among the remaining nodes to be upgraded;

   If it exists, return to perform the first operation;

   If it does not exist, obtain multiple batches of the multiple nodes to be upgraded and the nodes to be upgraded included in each batch;

   The upgrading the plurality of nodes to be upgraded according to the determined nodes to be upgraded for parallel upgrade includes:

   Upgrade the multiple nodes to be upgraded according to the multiple batches and the nodes to be upgraded included in each batch.
4. The service upgrade method according to claim 3, wherein the maximum number of concurrent upgrade nodes allowed for each service to be upgraded deployed in the nodes to be upgraded according to the in-degree is zero, from the in-degree Among the zero nodes to be upgraded, the nodes to be upgraded in the current batch are determined, including:

   When it is determined that the nodes to be upgraded in the current batch include at least two kinds of node combinations, each node in each node combination is used as the nodes to be upgraded in the current batch, and each of the at least two node combinations The node combination includes at least one node to be upgraded;

   The determining the node to be upgraded in the multiple nodes to be upgraded in parallel according to the maximum number of nodes to be upgraded in parallel allowed for each service to be upgraded and the upgrade constraint relationship further includes:

   When there are at least two upgrade solutions, one upgrade solution is selected from the at least two upgrade solutions, and the upgrade solution is the batches for upgrading the multiple nodes to be upgraded, and the batches to be upgraded included in each batch node.
5. The service upgrade method according to claim 3, wherein the upgrading the plurality of nodes to be upgraded according to the plurality of batches and the nodes to be upgraded included in each batch comprises:

   Perform a second operation: determine the target node corresponding to the node to be upgraded in the current upgrade batch; send an upgrade instruction to the node to be upgraded in the current upgrade batch, the upgrade instruction includes the identifier of the target node, and the upgrade instruction For instructing to migrate the services to be upgraded in the nodes to be upgraded in the current upgrade batch to the target node, and to upgrade the nodes to be upgraded in the current upgrade batch;

   Determining whether the current upgrade batch belongs to the last batch to be upgraded among the multiple batches;

   If the current upgrade batch does not belong to the last batch to be upgraded among the multiple batches, when it is determined that the nodes to be upgraded in the current upgrade batch have completed the upgrade, the next upgrade batch of the current upgrade batch The batch is regarded as the current upgrade batch, and the second operation is executed back.
6. The service upgrade method according to any one of claims 1-5, wherein the upgrade constraint relationship is represented by a directed graph, and the service upgrade method further comprises:

   Judging whether there are deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship, and the deadlocked interconnected nodes to be upgraded are nodes to be upgraded that form a ring in a directed graph;

   According to the upgrade constraint relationship and the minimum number of online nodes for each service to be upgraded in the plurality of services to be upgraded, determining the node to be upgraded in the multiple nodes to be upgraded in parallel includes:

   When there are no deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship between the plurality of nodes to be upgraded, according to the upgrade constraint relationship and the minimum online value of each of the plurality of services to be upgraded The number of nodes determines the nodes to be upgraded that are upgraded in parallel among the multiple nodes to be upgraded.
7. A management node, characterized in that the management node is used to upgrade multiple services to be upgraded deployed among multiple nodes to be upgraded in a distributed system, and the management node includes:

   An obtaining unit, configured to obtain an upgrade constraint relationship between the multiple nodes to be upgraded, where the upgrade constraint relationship is determined by the upgrade sequence of the multiple services to be upgraded;

   The determining unit is configured to determine, based on the upgrade constraint relationship obtained by the obtaining unit and the minimum number of online nodes of each service to be upgraded in the plurality of services to be upgraded, the to-be-upgraded ones of the multiple nodes to be upgraded in parallel Nodes, the minimum number of online nodes is the minimum number of nodes that simultaneously provide the same service to be upgraded;

   The upgrade management unit is configured to upgrade the multiple nodes to be upgraded according to the nodes to be upgraded that are determined in parallel by the determining unit.
8. The management node according to claim 7, wherein the determining unit is specifically configured to:

   According to the minimum number of online nodes for each service to be upgraded and the service to be upgraded deployed in each of the multiple nodes to be upgraded, the maximum concurrent upgrade node allowed for each service to be upgraded is determined The maximum number of nodes for parallel upgrade is the maximum number of nodes that are simultaneously upgraded and deployed with the same service to be upgraded;

   According to the maximum number of parallel upgrade nodes allowed for each service to be upgraded and the upgrade constraint relationship, determine the nodes to be upgraded that are to be upgraded in parallel among the multiple nodes to be upgraded.
9. The management node according to claim 8, wherein the upgrade constraint relationship is represented by a directed graph;

   The determining unit is specifically used for:

   Acquiring the in-degree of each node to be upgraded in the directed graph;

   Perform the first operation: determine the node to be upgraded with zero in-degree in the directed graph; according to the maximum number of parallel upgrade nodes allowed for each service to be upgraded deployed in the node to be upgraded with zero in-degree, from The nodes to be upgraded in the current batch are determined among the nodes to be upgraded whose entry is zero; the nodes to be upgraded in the current batch are removed from the directed graph, and the remaining nodes to be upgraded in the directed graph are updated的入度;

   Judging whether there is a node to be upgraded with an indegree of zero among the remaining nodes to be upgraded;

   If it exists, return to perform the first operation;

   If it does not exist, obtain multiple batches of the multiple nodes to be upgraded and the nodes to be upgraded included in each batch;

   The upgrade management unit is specifically configured to: upgrade the multiple nodes to be upgraded according to the multiple batches determined by the determining unit and the nodes to be upgraded included in each batch.
10. The management node according to claim 9, wherein:

    The determining unit is specifically configured to: when it is determined that the nodes to be upgraded in the current batch include at least two types of node combinations, each node in each node combination is used as the nodes to be upgraded in the current batch, and the at least Each of the two node combinations includes at least one node to be upgraded;

    The determining unit is further configured to, when there are at least two upgrade plans, select one upgrade plan from the at least two upgrade plans, where the upgrade plan is a batch for upgrading the plurality of nodes to be upgraded, and each The nodes to be upgraded included in each batch.
11. The management node according to claim 9, wherein the upgrade management unit is specifically configured to:

    Perform a second operation: determine the target node corresponding to the node to be upgraded in the current upgrade batch; send an upgrade instruction to the node to be upgraded in the current upgrade batch, the upgrade instruction includes the identifier of the target node, and the upgrade instruction For instructing to migrate the services to be upgraded in the nodes to be upgraded in the current upgrade batch to the target node, and to upgrade the nodes to be upgraded in the current upgrade batch;

    Determining whether the current upgrade batch belongs to the last batch to be upgraded among the multiple batches;

    If the current upgrade batch does not belong to the last batch to be upgraded among the multiple batches, when it is determined that the nodes to be upgraded in the current upgrade batch have completed the upgrade, the next upgrade batch of the current upgrade batch The batch is regarded as the current upgrade batch, and the second operation is executed back.
12. The management node according to any one of claims 7-11, wherein the upgrade constraint relationship is represented by a directed graph, and the management node further comprises a judgment unit;

    The judgment unit is configured to judge whether there are deadlocked interconnected nodes to be upgraded in the upgrade constraint relationship, and the deadlocked interconnected nodes to be upgraded are nodes to be upgraded that form a ring in a directed graph;

    The determining unit is specifically configured to: when the determining unit determines that there is no deadlocked interconnected node to be upgraded in the upgrade constraint relationship between the multiple nodes to be upgraded, according to the upgrade constraint relationship and the multiple The minimum number of online nodes for each service to be upgraded in each service to be upgraded is determined to be upgraded in parallel among the multiple nodes to be upgraded.
13. An upgrade device, characterized by comprising a memory and a processor, the memory is used to store computer execution instructions, and the processor is used to call the computer execution instructions so that when the upgrade device is running, execute the computer execution Instructions to implement the service upgrade method according to any one of claims 1-6.

Images