CN112470119B - Service upgrading method and device in distributed system and distributed system - Google Patents

Service upgrading method and device in distributed system and distributed system Download PDF

Info

Publication number
CN112470119B
CN112470119B CN201980030054.3A CN201980030054A CN112470119B CN 112470119 B CN112470119 B CN 112470119B CN 201980030054 A CN201980030054 A CN 201980030054A CN 112470119 B CN112470119 B CN 112470119B
Authority
CN
China
Prior art keywords
upgraded
nodes
node
upgrade
batch
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201980030054.3A
Other languages
Chinese (zh)
Other versions
CN112470119A (en
Inventor
杨阳
董如良
余思
张进毅
龚骏辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN112470119A publication Critical patent/CN112470119A/en
Application granted granted Critical
Publication of CN112470119B publication Critical patent/CN112470119B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • G06F8/658Incremental updates; Differential updates

Abstract

A service upgrading method, a device and a distributed system in the distributed system relate to the technical field of computers, and can solve the problem of low upgrading efficiency caused by that only the service in one node can be upgraded in the distributed system at the same time. The method comprises the steps that a management node in a distributed system obtains an upgrading constraint relation among a plurality of nodes to be upgraded, determines the nodes to be upgraded in the plurality of nodes to be upgraded according to the upgrading constraint relation and the minimum online node number of each service to be upgraded in the plurality of services to be upgraded, and upgrades the plurality of nodes to be upgraded according to the determined nodes to be upgraded in parallel, so that the time for upgrading the plurality of nodes to be upgraded is effectively shortened, and the upgrading efficiency is improved. The upgrade constraint relation is determined by the upgrade sequence of a plurality of services to be upgraded, and the minimum number of online nodes is the minimum number of nodes which simultaneously provide the same services to be upgraded.

Description

Service upgrading method and device in distributed system and distributed system
Technical Field
The embodiment of the invention relates to the technical field of computers, in particular to a method and a device for upgrading services in a distributed system and the distributed system.
Background
The system software of the distributed system includes a plurality of services deployed on a plurality of nodes of the distributed system. In practice, each service of the system software may be deployed on one or more nodes. As shown in fig. 1, the system software includes a service 1, a service 2, a service 3, and a service 4, where the service 1 is deployed on nodes 0 to 2, the service 2 is deployed on the nodes 1, 2, and 4, the service 3 is deployed on nodes 3 to 6, and the service 4 is deployed on nodes 7 to 9. When the system software has a new feature online or a version update, each service in the system software needs to be upgraded.
At present, a method for upgrading system software in a distributed system includes: sequencing all nodes of the service with the system software in sequence from large to small according to a memory quota (the memory quota is used for limiting the data storage capacity on the nodes); migrating all data on the node with the largest memory quota in the sequence to other nodes, and taking the node with the largest memory quota in the sequence as a current node to be upgraded; upgrading the service on the current node to be upgraded, after the upgrade is completed, migrating the data on the node which is ranked next to the current node to be upgraded, taking the node which is ranked next to the current node to be upgraded as the current node to be upgraded, and so on until the service on the last node in the ranking is upgraded.
The method can realize the service upgrade stably, and can ensure the integrity of the data without interrupting the external service. However, the nodes of the service in which the system software is deployed need to be upgraded one by one, which results in low upgrading efficiency.
Disclosure of Invention
The application provides a service upgrading method and device in a distributed system and the distributed system, which solve the problem of low upgrading efficiency caused by that only the service in one node can be upgraded in the distributed system.
In a first aspect, the present application provides a service upgrade method in a distributed system, which is applied to a management node in the distributed system for upgrading a plurality of services to be upgraded deployed in a plurality of nodes to be upgraded, and the upgrade method includes: the management node acquires an upgrade constraint relation among a plurality of nodes to be upgraded, determines the nodes to be upgraded in the plurality of nodes to be upgraded according to the upgrade constraint relation and the minimum online node number of each service to be upgraded in the plurality of services to be upgraded, and upgrades the plurality of nodes to be upgraded according to the determined nodes to be upgraded which are upgraded in parallel. The upgrade constraint relation is determined by the upgrade sequence of a plurality of services to be upgraded, and the minimum number of online nodes is the minimum number of nodes which simultaneously provide the same services to be upgraded. The management node determines the nodes to be upgraded which are upgraded in parallel, namely the nodes to be upgraded which are upgraded in parallel can be upgraded in one batch, so that the time for upgrading a plurality of nodes to be upgraded is effectively reduced, and the upgrading efficiency is improved.
In a possible design, the method for determining, by the management node, a node to be upgraded in parallel among a plurality of nodes to be upgraded according to the upgrade constraint relationship and the minimum online node number of each service to be upgraded among the plurality of services to be upgraded includes: the management node determines the maximum parallel upgrade node number allowed by each service to be upgraded according to the minimum online node number of each service to be upgraded and the service to be upgraded deployed in each node to be upgraded in the plurality of nodes to be upgraded, and subsequently, the management node determines the nodes to be upgraded in the plurality of nodes to be upgraded in parallel according to the maximum parallel upgrade node number allowed by each service to be upgraded and the upgrade constraint relationship. Here, the maximum number of parallel upgrade nodes is the maximum number of nodes 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 determine the maximum parallel upgrade node number allowed by each service to be upgraded according to the minimum online node number of each service to be upgraded and the service to be upgraded deployed in each node to be upgraded in the plurality of nodes to be upgraded, so that when the nodes to be upgraded are determined in parallel subsequently, for each service to be upgraded, the number of the nodes to be upgraded which are upgraded in parallel does not exceed the maximum parallel node number allowed by each service to be upgraded.
In a possible design, the upgrade constraint relationship is represented by a directed graph, so that the method for determining the nodes to be upgraded in parallel in a plurality of nodes to be upgraded by the management node according to the maximum number of parallel upgrades allowed by each service to be upgraded and the upgrade constraint relationship comprises the following steps: the management node acquires the degree of entry of each node to be upgraded in the directed graph and executes a first operation, wherein the first operation is as follows: determining nodes to be upgraded with zero in-degree in the directed graph, determining nodes to be upgraded in the current batch from the nodes to be upgraded with zero in-degree according to the maximum number of parallel upgrade allowed by each service to be upgraded deployed in the nodes to be upgraded with zero in-degree, removing the nodes to be upgraded in the current batch from the directed graph, and updating the in-degree of the remaining nodes to be upgraded in the directed graph; then, the management node judges whether the nodes to be upgraded with the zero in-degree still exist in the rest nodes to be upgraded; if yes, returning to execute the first operation; and if the node to be upgraded does not exist, obtaining a plurality of batches for upgrading the nodes to be upgraded and the nodes to be upgraded included in each batch. Thus, the method for the management node to upgrade the plurality of nodes to be upgraded according to the determined nodes to be upgraded which are upgraded in parallel comprises the following steps: and the management node upgrades the nodes to be upgraded according to the determined batches and the nodes to be upgraded included in each batch.
In a possible design, when it is determined that the nodes to be upgraded of the current batch include at least two node combinations, the management node takes the node in each node combination as the node to be upgraded of the current batch respectively to obtain at least two upgrading schemes. The upgrading scheme is to upgrade a plurality of batches of nodes to be upgraded and the nodes to be upgraded in each batch. Each node combination of the at least two node combinations comprises at least one node to be upgraded. In this case, the management node selects one upgrade scheme from the at least two upgrade schemes, and upgrades the plurality of nodes to be upgraded according to the selected upgrade scheme.
In the process of determining to upgrade a batch of a plurality of nodes to be upgraded, for a certain batch, the management node may determine to upgrade a certain node/certain nodes to be upgraded in the batch, or may determine to upgrade other nodes to be upgraded in the batch, so that different node combinations occur. For each node combination, the management node can determine to upgrade all the batches of the nodes to be upgraded, i.e. generate an upgrade scheme. Thus, the management node eventually generates a plurality of upgrade scenarios.
In a possible design, the method for the management node to upgrade the multiple nodes to be upgraded according to the multiple batches and the nodes to be upgraded included in each batch includes: the management node performs a second operation comprising: determining a target node corresponding to a node to be upgraded of a current upgrading batch, and sending an upgrading instruction to the node to be upgraded of the current upgrading batch, wherein the upgrading instruction comprises an identifier of the target node and is used for instructing to migrate a service to be upgraded in the node to be upgraded of the current upgrading batch to the target node and upgrading the node to be upgraded of the current upgrading batch; then, the management node judges whether the current upgrading batch belongs to the last batch to be upgraded in the multiple batches; and if the current upgrading batch does not belong to the last upgrading batch in the plurality of batches, taking the next batch of the current upgrading batch as the current upgrading batch and returning to execute the second operation when the node to be upgraded of the current upgrading batch is determined to finish upgrading.
In order to ensure the integrity and reliability of the data of the service to be upgraded, when the node to be upgraded of the current upgrade is upgraded, the management node can determine a target node corresponding to the node to be upgraded of the current upgrade batch according to the determined batch and the reliability of the data of the service to be upgraded.
In a possible design, the method for determining, by the management node, a target node corresponding to a node to be upgraded of a current upgrade batch includes: the management node judges whether the nodes to be upgraded included in a first batch can ensure the reliability of the data of the service to be upgraded in the nodes to be upgraded in the current upgrading batch, wherein the first batch is a batch which is finally upgraded in other batches except the current upgrading batch in a plurality of batches; if the upgrade can be guaranteed, determining the nodes to be upgraded included in the first batch as target nodes corresponding to the nodes to be upgraded of the current upgrade batch; if the reliability of the data of the service to be upgraded in the node to be upgraded in the current upgrading batch can not be ensured, judging whether the nodes to be upgraded in other batches except the first batch and the current upgrading batch can ensure the reliability of the data of the service to be upgraded in the nodes to be upgraded in the current upgrading batch; and repeating the steps until the target node is determined.
In a possible design, the upgrade constraint relationship is represented by a directed graph, and the upgrade method provided by the present application further includes: the management node judges whether a node to be upgraded which is in deadlock interconnection exists in the upgrading constraint relation or not, wherein the node to be upgraded which is in deadlock interconnection is the node to be upgraded which forms a ring in the directed graph. Because of the ring, the nodes to be upgraded which are deadlock interconnected cannot be upgraded. Correspondingly, the method for the management node to determine the node to be upgraded which is upgraded in parallel in the plurality of nodes to be upgraded according to the upgrade constraint relation and the minimum online node number of each service to be upgraded in the plurality of services to be upgraded comprises the following steps: when the upgrade constraint relation among the nodes to be upgraded does not have the nodes to be upgraded which are connected in a deadlock manner, the management node determines the nodes to be upgraded in parallel according to the upgrade constraint relation and the minimum online node number of each service to be upgraded in the services to be upgraded.
In a possible design, when the upgrade constraint relationship has the nodes to be upgraded which are deadlock-interconnected, the management node sends alarm information to inform an administrator/operation and maintenance personnel that the nodes to be upgraded which are deadlock-interconnected, and the upgrade cannot be performed.
The alarm information is used for informing an administrator/operation and maintenance personnel that the nodes to be upgraded which are in deadlock interconnection exist cannot be upgraded, so that the administrator/operation and maintenance personnel can adjust or reconfigure the upgrade constraint relation of the nodes to be upgraded which are in deadlock interconnection.
And deadlock the interconnected nodes to be upgraded is the nodes to be upgraded which form a ring in the directed graph. Because of the ring, the nodes to be upgraded which are deadlock interconnected cannot be upgraded. In order to ensure the smooth upgrade of a plurality of nodes to be upgraded, the management node needs to ensure that the nodes to be upgraded which are not deadlock-connected in the upgrade constraint relationship do not exist.
In a possible design, the method for the management node to determine whether there is a node to be upgraded in the upgrade constraint relationship, where the node to be upgraded is deadlock-interconnected, includes: the management node acquires the degree of entry of each node to be upgraded in the directed graph and executes a third operation, wherein the third operation is as follows: determining nodes to be upgraded with the in-degree of zero in the directed graph, removing the nodes to be upgraded with the in-degree of zero from the directed graph, and updating the in-degrees of the rest nodes to be upgraded in the directed graph; then, the management node judges whether the nodes to be upgraded with the zero in-degree still exist in the rest nodes to be upgraded; if yes, returning to execute the third operation; and if not, determining that the nodes to be upgraded with deadlock interconnection exist in the upgrade constraint relation.
The node to be upgraded with zero in-degree in the directed graph can be upgraded and is not restricted by other nodes during upgrading. Therefore, if the in-degree of a certain node/nodes to be upgraded is/are zero, it indicates that the node/nodes to be upgraded does not form a ring, and the node/nodes to be upgraded are not deadlock-connected nodes to be upgraded. If the nodes to be upgraded do not have the nodes to be upgraded with the zero in-degree in the digraph and the number of the nodes to be upgraded is not zero, the nodes to be upgraded form a ring shape, and the nodes to be upgraded cannot be upgraded, namely the nodes to be upgraded are the nodes to be upgraded which are deadlock-interconnected. Based on the method, the management node determines whether the upgrade constraint relation has the nodes to be upgraded which are connected in a deadlock mode.
In a second aspect, the present application provides a management node for performing the modules of the method of the first aspect or any one of the possible designs of the first aspect.
In a third aspect, the present application provides an upgrade apparatus, the upgrade apparatus comprising a memory and a processor, the memory being configured to store computer executable instructions, and the processor being configured to execute the computer executable instructions in the memory to perform the operation steps of the method in the first aspect or any one of the possible designs of the first aspect using hardware resources in the upgrade apparatus when the upgrade apparatus is running. The apparatus may specifically be a management node or a chip.
In a fourth aspect, the present application also provides a computer-readable storage medium comprising instructions which, when executed on a computer, cause the computer to perform the operational steps of any one of the possible methods of the first aspect or any one of the possible designs of the first aspect.
In a fifth aspect, the present application further provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the operational steps of any one of the possible methods of the first aspect or any one of the possible designs of the first aspect described above.
It is understood that any of the management node, the upgrade apparatus, the computer readable storage medium, or the computer program product provided above is used to execute the corresponding method provided above, and therefore, the beneficial effects achieved by the management node, the upgrade apparatus, the computer readable storage medium, or the computer program product may refer to the beneficial effects in the corresponding method, and are not described herein again.
Drawings
FIG. 1 is a schematic diagram illustrating a service deployment in a distributed system according to an embodiment of the present invention;
FIG. 2 is a schematic structural diagram of a distributed system according to an embodiment of the present invention;
FIG. 3 is a diagram illustrating a hardware structure of a management node according to an embodiment of the present invention;
fig. 4 is a schematic flowchart of a service upgrade method in a distributed system according to an embodiment of the present invention;
FIG. 5 is a flow chart illustrating the generation of a directed graph according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of a directed graph of nodes to be upgraded with deadlock interconnections in an embodiment of the present invention;
fig. 7 is a schematic flow chart illustrating the process of determining the maximum number of parallel upgrade nodes allowed by the service to be upgraded in the embodiment of the present invention;
FIG. 8 is a schematic illustration of a first scenario generated in an embodiment of the present invention;
FIG. 9 is a schematic illustration of a second scenario generated in an embodiment of the present invention;
fig. 10 is a schematic structural diagram of a management node in the embodiment of the present invention.
Detailed Description
The system software in a distributed system typically includes a plurality of services that are distributed across a plurality of nodes of the distributed system. When upgrading system software, it is necessary to upgrade each service of the system software. In practical application, each service in the system software has a precedence order during upgrading, and if the service a needs to be upgraded after the service B is upgraded, nodes deploying services in the system software also have the precedence order during upgrading. The embodiment of the invention refers to the sequence of the nodes in upgrading as an upgrading constraint relation.
The embodiment of the invention provides a method for upgrading services in a distributed system. The method determines the nodes capable of being upgraded in parallel in the plurality of nodes on the premise of meeting the upgrading constraint relation among the plurality of nodes, so that the upgrading time is shortened, and the upgrading efficiency is improved.
The distributed system provided by the embodiment of the invention comprises but is not limited to a distributed storage system and a distributed file system.
Fig. 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 a plurality of nodes to be upgraded 21. In the embodiment of the invention, the service included in the system software needing to be upgraded is called the service to be upgraded, and the node with one or more services to be upgraded is called the node to be upgraded.
The node to be upgraded 21 may be a physical machine (e.g., a server), or may be a Virtual Machine (VM) deployed on the physical machine.
The management node 20 is configured to manage each node to be upgraded 21, for example: and upgrading the service to be upgraded operated by each node 21 to be upgraded. In this embodiment, the management node 20 is an independent physical machine or virtual machine. In other embodiments, however, the management node 20 may be any node to be upgraded in a distributed system.
Fig. 3 shows a hardware configuration 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 a control center of the management node 20, and may be a Central Processing Unit (CPU), another general-purpose processor, or the like. Wherein a general purpose processor may be a microprocessor or any conventional processor or the like.
As one example, processor 31 may include one or more CPUs, such as CPU 0 and CPU 1 shown in fig. 3.
The memory 32 may be, but is not limited to, a read-only memory (ROM) or other type of static storage device that may store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that may store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
In one possible implementation, the memory 32 may exist independently of the processor 31. A memory 32 may be coupled to the processor 31 via a bus 34 for storing instructions or program code. When the processor 31 calls and executes the instructions or program codes stored in the memory 32, the service upgrading method in the distributed system provided by the embodiment of the present invention can be implemented.
In another possible implementation, the memory 32 may also be integrated with the processor 31.
A communication interface 33, configured to connect the management node 20 and another device (e.g., the node 21 to be upgraded) through a communication network, where the communication network may be an ethernet, a Radio Access Network (RAN), a Wireless Local Area Network (WLAN), or the like. The communication interface 33 may include a receiving unit for receiving data, and a transmitting unit for transmitting data.
The bus 34 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 3, but this does not mean only one bus or one type of bus.
It is noted that the structure shown in fig. 3 does not constitute a limitation of the management node, and that the management node 20 may comprise more or less components than those shown in fig. 3, or some components may be combined, or a different arrangement of components than those shown in fig. 3.
Similar to the hardware structure of the management node 20, the node to be upgraded 21 also includes components such as a processor, a memory, a communication interface, and a bus. Unlike the management node 20, the processor in the node to be upgraded 21, when calling and executing instructions or program code stored in the memory, is used to complete the functions of the node to be upgraded 21, such as: and executing the service to be upgraded, or upgrading the service to be upgraded according to the command of the management node. The processor in the management node 20 is used to perform the functions of the management node 20 when calling and executing the instructions or program codes stored in the memory, for example: and determining nodes to be upgraded for parallel upgrading and the like.
The service upgrade method in the distributed system provided in the embodiment of the present invention is described below with reference to the accompanying drawings.
Fig. 4 is a schematic flowchart of a service upgrading method in a distributed system according to an embodiment of the present invention. As shown in fig. 4, the service upgrade method includes:
s401, the management node 20 obtains the upgrading constraint relation among the nodes 21 to be upgraded.
The upgrade constraint relationship in the embodiment of the present invention is used to indicate the sequence of the nodes 21 to be upgraded during upgrading.
The service to be upgraded deployed in a certain node 21 to be upgraded must be upgraded after the service to be upgraded deployed in other nodes 21 to be upgraded is upgraded. That is, a certain node 21 to be upgraded must be upgraded after the other nodes 21 to be upgraded are upgraded.
For example, a service 1 is deployed in a node 1, and a service 1 and a service 2 are deployed in a node 2, and the service 1 must be upgraded after the service 2 is upgraded, so that the node 1 must be upgraded after the node 2 is upgraded. This forms an upgrade constraint relationship between node 1 and node 2.
The management node 20 represents the upgrade constraint relationship between the plurality of nodes to be upgraded 21 by using a directed graph. 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.
For example, if the plurality of nodes to be upgraded include node 1, node 2, node 3, node 4, node 5, and node 6, the upgrade constraint relationship among the 6 nodes to be upgraded is: the node 1 needs to be upgraded after the node 2 and the node 6 are upgraded (constraint relation 1), the node 2 needs to be upgraded after the node 5 finishes upgrading (constraint relation 2), and the node 3 needs to be upgraded after the node 4 and the node 5 finish upgrading (constraint relation 3); the node 4 needs to be upgraded after the node 5 finishes upgrading (constraint relation 4); the management node 20 generates a directed graph according to the upgrade constraint relationship by using the flow shown in fig. 5. The directed graph can reflect constraint relations 1 to 4.
S402, the management node 20 judges whether the upgrade constraint relation among the nodes 21 to be upgraded has the nodes 21 to be upgraded which are connected with each other in a deadlock way.
Deadlock the interconnected nodes to be upgraded means that the constraint relationship among the nodes 21 to be upgraded forms a ring. Each node to be upgraded 21 forming a deadlock interconnect cannot be upgraded.
For example, in the directed graph shown in fig. 6, the node 3, the node 4, and the node 5 form a ring, the node 5 needs to be upgraded after the node 3 is upgraded, the node 4 needs to be upgraded after the node 5 is upgraded, and the node 3 needs to be upgraded after the node 4 is upgraded. That is, node 3, node 4, and node 5 form a deadlock interconnect, and node 3, node 4, and node 5 are all deadlock interconnect nodes.
In the directed graph shown in fig. 5, there are no nodes that make up the ring, so there are no nodes that deadlock the interconnect.
Specifically, the mode for the management node 20 to determine whether the upgrade constraint relationship among the multiple nodes to be upgraded 21 has the deadlock-interconnected node to be upgraded 21 is as follows: the in-degree (the number of arrows pointing to the nodes 21 to be upgraded in the directed graph) of each node 21 to be upgraded in the directed graph is obtained, and the nodes 21 to be upgraded with the current in-degree of zero are determined. The node 21 to be upgraded with an in-degree of zero indicates that the node 21 to be upgraded is not constrained by other nodes when being upgraded. And removing the node 21 to be upgraded with the current in-degree of zero from the directed graph. When the node 21 to be upgraded with the current degree of income being zero is removed, the directed edge related to the node 21 to be upgraded with the current degree of income being zero is also removed at the same time. And the management node 20 updates the degree of the nodes to be upgraded in the directed graph, determines the nodes 21 to be upgraded with the current degree of zero in the nodes to be upgraded, removes the nodes 21 to be upgraded with the current degree of zero in the nodes to be upgraded from the directed graph, and thus, the steps are repeatedly executed. If the number of the remaining nodes to be upgraded is zero, the management node 20 determines that the directed graph has no nodes to be upgraded 21 which are connected with each other in a deadlock manner; if the number of the nodes to be upgraded remaining in the directed graph is not zero, but there is no node to be upgraded 21 with zero in-degree, the management node 20 determines that there is a node with deadlock interconnection in the directed graph.
Illustratively, in the directed graph shown in fig. 5, the degrees of entry of the nodes 5 and 6 are both 0, the degrees of entry of the nodes 2 and 4 are both 1, and the degrees of entry of the nodes 1 and 3 are 2. It can be seen that the nodes with the current in-degree of 0 are node 5 and node 6. The management node 20 removes the node 5 and the node 6 from the directed graph shown in fig. 5, and updates the degree of entry of the remaining nodes (node 1, node 2, node 3, and node 4), where the degree of entry after updating of the remaining nodes is: the incomes of node 2 and node 4 are both 0, and the incomes of node 1 and node 3 are 1. At this time, the nodes with the current degree of entry of 0 are node 2 and node 4, the management node 20 removes the nodes with the current degree of entry of 0 from the remaining nodes (node 1, node 2, node 3, and node 4), that is, removes node 2 and node 4 from node 1, node 2, node 3, and node 4, and then the management node 20 updates the degree of entry of the remaining nodes (node 1 and node 3), and the degrees of entry after the updating of the remaining nodes are: the in-degree of node 1 and node 3 is 0. Accordingly, at this time, the nodes with the current degree of income 0 are the node 1 and the node 3, and the management node 20 removes the node 1 and the node 3, and at this time, the number of the remaining nodes is 0, so that the management node 20 determines that there is no deadlock-interconnection node in the directed graph shown in fig. 5.
In the directed graph shown in fig. 6, only if the degree of entry of the node 6 is 0, the management node 20 first removes the node 6 from the directed graph and updates the degrees of entry 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 the remaining nodes is not zero, so the management node 20 determines the node in the directed graph shown in fig. 6 where the deadlock interconnection exists.
If the management node 20 determines that there is a deadlock-interconnected node to be upgraded 21 in the upgrade constraint relationship among the plurality of nodes to be upgraded 21, S403 is executed. If the management node 20 determines that there is no deadlock-interconnected node to be upgraded 21 in the upgrade constraint relationship among the plurality of nodes to be upgraded 21, S404 is executed.
And S403, the management node 20 sends alarm information to inform an administrator/operation and maintenance personnel that the nodes to be upgraded which are deadlock-connected exist and cannot be upgraded.
The alarm information can be characters, audio frequency and the like. For example: the alarm information is 'the nodes to be upgraded which are interconnected with deadlock and cannot be upgraded'. If the alarm information is text, the management node 20 may display the alarm information. If the alarm information is audio, the management node 20 broadcasts the alarm information.
Optionally, the alarm information includes an identifier of a node to be upgraded which is deadlock-interconnected. For example: the alarm information is that the node 3, the node 4 and the node 5 are deadlock interconnected nodes to be upgraded and cannot be upgraded.
The management node 20 sends an alarm message to inform an administrator/operation and maintenance personnel that the node to be upgraded which is deadlock-interconnected cannot be upgraded, so that the administrator/operation and maintenance personnel can adjust or reconfigure the upgrade constraint relationship of the node to be upgraded which is deadlock-interconnected. If the nodes to be upgraded do not exist 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 for parallel upgrade allowed by 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 with the service to be upgraded are required to be reserved, and the nodes are not upgraded temporarily. The number of nodes that are not upgraded temporarily is referred to as the minimum number of online nodes required for 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 online node number required by the service to be upgraded, the management node 20 determines the maximum parallel upgrade node number allowed by the service to be upgraded according to the number of nodes in the distributed system where the service to be upgraded is deployed. Namely, under the condition of meeting the minimum on-line node number required by the service to be upgraded, the maximum number of the nodes which can be upgraded in parallel and are provided with the service to be upgraded is determined.
The management node 20 obtains the minimum online node number required by each service to be upgraded and the distribution information of each service to be upgraded in the distributed system (for example, the service 1 to be upgraded is distributed in the node 1 to be upgraded), and determines the service to be upgraded deployed in each node 21 to be upgraded and the maximum parallel upgrade node number allowed by each service to be upgraded according to the minimum online node number required by each service to be upgraded and the distribution information of each service to be upgraded in the distributed system.
For example, as shown in (a) in fig. 7, the minimum number of online nodes required by the management node 20 to acquire each service to be upgraded and the distribution information of each service to be upgraded in the distributed system are: the service 1 to be upgraded is deployed in the node 5 and the node 6, and the minimum online node number required by the service to be upgraded is 1; the service 2 to be upgraded is deployed in the node 1 and the node 2, and the minimum online node number required by the service to be upgraded is 1; the service 3 to be upgraded is deployed in the node 3 and the node 4, and the minimum number of online nodes required by the service to be upgraded is 1. Based on these pieces of information, the management node 20 determines the service to be upgraded, which is deployed in each of the nodes 1 to 6 (see (B) in fig. 7): a service 2 to be upgraded is deployed in the node 1, a service 2 to be upgraded is deployed in the node 2, a service 3 to be upgraded is deployed in the node 3, a service 3 to be upgraded is deployed in the node 4, a service 1 to be upgraded is deployed in the node 5, and a service 1 to be upgraded is deployed in the node 6. Since the minimum number of online nodes required for the service 1 to be upgraded is 1, there are two nodes in the distributed system where the service 1 to be upgraded is deployed: the node 5 and the node 6, therefore, when the service 1 to be upgraded is upgraded, only one node can be upgraded at most, that is, the maximum number of nodes allowed for parallel upgrade of the service 1 to be upgraded is 1. Similarly, since the minimum number of online nodes required for the service 2 to be upgraded is 1, there are two nodes deploying the service 2 to be upgraded in the distributed system: the node 1 and the node 2, therefore, when upgrading the service 2 to be upgraded, only one node can be upgraded at most, that is, the maximum number of nodes allowed by the service 2 to be upgraded for parallel upgrade is 1. Because the minimum number of online nodes required by the service 3 to be upgraded is 1, there are two nodes deploying the service 3 to be upgraded in the distributed system: the node 3 and the node 4, therefore, when the service 3 to be upgraded is upgraded, only one node can be upgraded at most, that is, the maximum number of nodes allowed by the service 3 to be upgraded for parallel upgrade is 1. Fig. 7 (C) shows the maximum number of nodes that are allowed to be upgraded in parallel for each of the service 1 to be upgraded to the service 3 to be upgraded in this example.
S405, the management node 20 determines the batch of upgrading the multiple nodes 21 to be upgraded according to the constraint relationship among the multiple nodes 21 to be upgraded and the maximum number of parallel upgrading nodes allowed by the service to be upgraded deployed in each node 21 to be upgraded.
As can be seen from the foregoing description, the node 21 to be upgraded, whose in-degree is zero, in the directed graph is completely free from the constraints of other nodes 21 to be upgraded. Therefore, the management node 20 may choose to upgrade the node to be upgraded 21 with an incoming degree of zero. In order to ensure the continuity of the service to be upgraded deployed in the node 21 to be upgraded with the zero in-degree, the management node 20 further needs to determine the node 21 to be upgraded for the first batch of upgrades from the nodes 21 to be upgraded with the zero in-degree according to the "service to be upgraded deployed in the node 21 to be upgraded with the zero in-degree" and the "maximum node number of parallel upgrades allowed by each service to be upgraded deployed in the node 21 to be upgraded with the zero in-degree". For example, the nodes to be upgraded with an in-degree of zero in fig. 5 are node 5 and node 6. It can be seen from (B) in fig. 7 that the services deployed in the node 5 and the node 6 are both the service 1. In addition, it can be found from (C) in fig. 7 that the maximum number of parallel upgrade nodes allowed by the service 1 is 1, it can be determined that the node of the first batch of upgrade is the node 5 or the node 6. In this way, the node 5 to be upgraded for the first upgrade is an upgrade scheme (this scheme is referred to as a first scheme), and the node 6 to be upgraded for the first upgrade is another upgrade scheme (this scheme is referred to as a second scheme).
If multiple upgrade schemes exist when the nodes to be upgraded 21 upgraded in the first batch of upgrades are determined, the management node 20 determines that all the batches required by the nodes to be upgraded 21 are upgraded in each upgrade scheme respectively.
The method for the management node 20 to determine the batches required by all the nodes 21 to be upgraded after upgrading all the upgrade schemes includes: the management node 20 removes the node to be upgraded 21 of the first batch of upgrades from the directed graph, for example, as shown in fig. 8, when the first scheme is adopted, the node 5 is first removed from the directed graph. After removing the nodes to be upgraded 21 upgraded in the first batch, the management node 20 updates the degree of income of the remaining nodes to be upgraded in the directed graph, and determines the nodes to be upgraded 21 with zero degree of income in the remaining nodes to be upgraded. As shown in fig. 8, after removing the node 5, the nodes with an in-degree of zero among the nodes 1, 2, 3, 4, and 6 include the nodes 2, 4, and 6. Then, the management node 20 determines the nodes to be upgraded 21 for the second batch of upgrades from the nodes to be upgraded 21 with zero in-degree in the remaining nodes to be upgraded according to the "services to be upgraded deployed in the nodes to be upgraded 21 with zero in-degree" and the "maximum number of nodes to be upgraded in parallel allowed by each service to be upgraded deployed in the nodes to be upgraded 21 with zero in-degree". For example, in fig. 8, a service to be upgraded 2 is deployed in a node 2, a service to be upgraded 3 is deployed in a node 4, a service to be upgraded 1 is deployed in a node 6, and the number of parallel upgrade maximum nodes allowed by the service to be upgraded 1, the number of parallel upgrade maximum nodes allowed by the service to be upgraded 2, and the number of parallel upgrade maximum nodes allowed by the service to be upgraded 3 are all 1, so that the parallel upgrade nodes 2, 4, and 6 do not affect the continuity of the service to be upgraded 1, the service to be upgraded 2, and the service to be upgraded 3, and thus the management node 20 determines the nodes to be upgraded in the second batch of upgrades to be the nodes 2, 4, and 6.
If there are multiple upgrade schemes when determining the nodes to be upgraded 21 upgraded in the second batch, the management node 20 also needs to determine that each upgrade scheme has upgraded the batches required by the remaining nodes to be upgraded 21.
After determining the nodes to be upgraded 21 upgraded in the second batch, the management node 20 continues to remove the nodes to be upgraded in the second batch from the directed graph, and determines the batches of the remaining nodes to be upgraded 21 in a manner of determining the nodes to be upgraded 21 upgraded in the first batch and the nodes to be upgraded 21 upgraded in the second batch until the nodes to be upgraded 21 do not exist in the directed graph. As shown in fig. 8, after removing node 2, node 4, and node 6, the entries 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, and takes node 1 and node 3 as the to-be-upgraded nodes for the third batch of upgrade. After deleting the node 1 and the node 3, if there is no node in the directed graph, the management node 20 determines that the upgrade of all the nodes to be upgraded needs to be completed in 3 batches by adopting the first scheme, specifically: first batch: node 5 → second batch: node 2, node 4, node 6 → third batch: node 1, node 3.
With reference to the above description, a method for determining, by the management node 20, the batches required for completing the upgrade of all the nodes 21 to be upgraded by using the second scheme is described, which is the same as the method for completing the upgrade of all the batches required for completing the upgrade of all the nodes 21 to be upgraded by using the first scheme by using the management node 20. Fig. 9 shows a process in which the management node 20 determines that all the batches required for upgrading all the nodes 21 to be upgraded by using the second scheme are completed. Firstly, the management node 20 removes the node to be upgraded for the first batch of upgrades: and the node 6 updates the degree of income of the rest nodes (the node 1 to the node 5), wherein the degree of income after the rest nodes are updated is respectively as follows: the degree of entry of node 5 is 0, the degrees of entry of node 1, node 2 and node 4 are all 1, and the degree of entry of node 3 is 2. Since the node 5 with the in-degree of 0 is deployed with the service 1 to be upgraded, and the maximum number of nodes for parallel upgrade allowed by the service 1 to be upgraded is 1, the management node 20 determines that the node to be upgraded for the second batch of upgrade is the node 5. After determining that the node to be upgraded of the second batch of upgrades is the node 5, the management node 20 removes the node 5, and updates the degree of income of the remaining nodes (node 1 to node 4), where the degree of income of the remaining nodes after updating is respectively: the in-degree of nodes 2 and 4 is 0 and the in-degree of nodes 1 and 3 is 1. Because the service 2 to be upgraded is deployed in the node 2, the service 3 to be upgraded is deployed in the node 4, and the maximum number of parallel upgrade nodes allowed by the service 2 to be upgraded and the maximum number of parallel upgrade nodes allowed by the service 3 to be upgraded are both 1, the parallel upgrade nodes 2 and 4 do not affect the continuity of the service 2 to be upgraded and the service 3 to be upgraded, and thus the management node 20 determines that the nodes to be upgraded of the third batch of upgrades are the node 2 and the node 4. After determining that the nodes to be upgraded of the third batch of upgrade are the node 2 and the node 4, the management node 20 removes the node 2 and the node 4, the degree of income of the node 1 and the node 3 in the remaining nodes is 0, the management node 20 determines that the node 1 and the node 3 can be upgraded in parallel, and the node 1 and the node 3 are used as the nodes to be upgraded of the fourth batch of upgrade. After deleting the node 1 and the node 3, if there is no node in the directed graph, the management node 20 determines that the upgrade of all the nodes to be upgraded needs to be completed in 4 batches by using the second scheme, specifically: in the first batch: node 6 → second batch: node 5 → third batch: node 2, node 4 → fourth batch: node 1, node 3.
In summary, the management node 20 may determine multiple upgrade schemes according to the maximum number of parallel upgrade nodes allowed by the service to be upgraded and the constraint relationship between the nodes 21 to be upgraded. After determining the plurality of upgrading schemes, the management node 20 may select one upgrading scheme from the plurality of upgrading schemes according to actual requirements, and upgrade according to the selected upgrading scheme.
Generally, the upgrade using the upgrade scheme with fewer batches takes less time, and therefore, the management node 20 may select the upgrade scheme with the least batch from the plurality of upgrade schemes.
Illustratively, the first scheme shown in fig. 8 includes 3 batches (first batch to third batch), the second scheme shown in fig. 9 includes 4 upgrade batches (first batch to fourth batch), and the batches included in the first scheme are smaller than the batches included in the second scheme, so the management node 20 may choose to upgrade the node to be upgraded using the first scheme.
It should be noted that, the selection of the upgrade scheme with the least number of batches from the plurality of upgrade schemes by the management node 20 is only one possible example and is not meant to limit the embodiment of the present invention. Besides the time consumed by upgrading, the management node can also consider the factors of system reliability, system load, idle resources and the like, and more specifically select an upgrading scheme suitable for the current requirement.
S406, the management node 20 sequentially indicates the nodes to be upgraded 21 in each batch to be upgraded according to the determined batches.
In a scenario of multiple batches, the management node 20 sends an upgrade instruction to the node to be upgraded 21 in the first batch to instruct the node to be upgraded 21 in the first batch to upgrade. After the upgrade of the node 21 to be upgraded in the first batch is finished, the management node 20 sends an upgrade instruction to the node 21 to be upgraded in the second batch to instruct the node 21 to be upgraded in the second batch to be upgraded. In this way, the execution is repeated until all the nodes to be upgraded 21 are upgraded.
Generally, in order to ensure smooth execution of services and integrity of data, when a certain service in a node is upgraded, data of the service in the node needs to be migrated to another node. After the service is upgraded, the data of the service in another node needs to be migrated back to the node.
Illustratively, when the service 1 in the node 5 needs to be upgraded, the node 5 migrates the data of the service 1 in the node 5 to the node 1; and after the node 5 is upgraded, migrating the data of the service 1 from the node 1 back to the node 5.
After the upgrade of the node 21 to be upgraded in the first batch is finished, the management node 20 in the embodiment of the present invention sends an upgrade instruction to the node 21 to be upgraded in the second batch, so that synchronization between "upgrade of the node 21 to be upgraded in the second batch" and "data migration of the node 21 to be upgraded in the first batch" is achieved.
That is to say, the scheme provided by the embodiment of the present invention realizes synchronization between "upgrade of the node 21 to be upgraded in the ith batch" and "data migration of the node 21 to be upgraded in the (i-1) th batch", thereby effectively improving the upgrade efficiency.
For each node 21 to be upgraded, the management node 20 may determine, according to the determined batch and the reliability of the data of the service to be upgraded, a destination node of data migration for the node 21 to be upgraded. In this way, the management node 20 may send an upgrade instruction including an identifier of the destination node to the node to be upgraded 21, so as to complete the upgrade of the service to be upgraded after the data of the service to be upgraded is migrated to the destination node.
In a distributed system, in order to improve the reliability of data, data of a certain service is often stored on different nodes in a stripe (strip) or multi-copy manner. When the management node 20 determines the destination node, it needs to consider that the reliability of the service data can be ensured after the service data is migrated.
For example, if the data of the service 1 is stored in the node 1 and the node 2 in a multi-copy manner, the management node 20 cannot determine the node 2 as a destination node of the node 1 for performing data migration. If the data of the service 1 in the node 1 is migrated into the node 2, only the node 2 in the distributed system stores the data of the service 1, and once the node 2 fails or the data of the service 1 in the node 2 is damaged, the service 1 cannot run in the distributed system.
For each node to be upgraded in a certain batch (for example, batch b), the management node 20 may first determine whether the reliability of data can be guaranteed when the node to be upgraded 21 included in the batch (for example, batch a) to be upgraded in the other batches except for batch b is used as the destination node. If the reliability of the data can be ensured when the node 21 to be upgraded in the batch a is used as the destination node, the management node 20 determines the node 21 to be upgraded in the batch a as the destination node. If each node 21 to be upgraded in the batch a cannot guarantee the reliability of the data as the destination node, the management node 20 determines whether the reliability of the data can be guaranteed when the node 21 to be upgraded included in the batch to be upgraded in the other batches except the batch b and the batch a is used as the destination node. Thus, the execution is repeated until the destination node is determined.
Illustratively, in combination with the above example, if the management node 20 selects the first scheme from the first scheme shown in fig. 8 and the second scheme shown in fig. 9, the node to be upgraded is upgraded according to the first scheme. When the node 5 in the first batch needs to be upgraded, the management node 20 first determines whether the nodes 1 and 3 in the third batch (the batch in which the upgrade is performed last except the first batch) are used as destination nodes and can satisfy the reliability of the data of the service 1 to be upgraded in the node 5. If the node 1 and the node 3 as the destination nodes cannot satisfy the reliability of the data of the service 1 to be upgraded, the management node 20 determines whether the reliability of the data of the service 1 to be upgraded can be satisfied when the node 2, the node 4, and the node 6 in the second batch (the last batch to be upgraded, except the first batch and the third batch) as the destination nodes. If one or more of the node 2, the node 4 and the node 6 can satisfy the reliability of the data of the service 1 to be upgraded as the destination node, the management node 20 takes the node as the destination node of the node 5 and sends an upgrade instruction including the identification of the destination node to the node 5.
In summary, on the premise that the upgrade constraint relationship among the nodes 21 to be upgraded is satisfied, the management node 20 determines to upgrade the nodes 21 to be upgraded in batches, that is, determines the nodes to be upgraded among the nodes 21 to be upgraded, which can be upgraded in parallel, thereby effectively reducing the time for upgrading the nodes 21 to be upgraded, and improving the upgrade efficiency.
The scheme provided by the embodiment of the invention is mainly introduced from the perspective of a method. In order to implement the above functions, it includes a hardware structure and/or a software module for performing each function. Those of skill in the art would readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiment of the present invention, the management node may be divided into functional modules according to the above method example, 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 integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that, the division of the modules in the embodiment of the present invention is schematic, and is only a logic function division, and there may be another division manner in actual implementation.
Fig. 10 is a schematic structural diagram of a management node 100 according to an embodiment of the present invention. The management node 100 is configured to manage upgrade of a plurality of nodes to be upgraded in a distributed system, for example, to perform a 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 an upgrade constraint relationship between multiple nodes to be upgraded, where the upgrade constraint relationship is determined by an upgrade order of multiple services to be upgraded. For example, in conjunction with fig. 4, the acquisition unit 1001 may be configured to perform S401. The determining unit 1002 is configured to determine a node to be 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 online node number of each service to be upgraded among the multiple services to be upgraded, where the minimum online node number 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 a plurality of nodes to be upgraded according to the nodes to be upgraded, which are determined by the determination unit 1002 and are upgraded in parallel.
Optionally, the determining unit 1002 is specifically configured to: determining the maximum parallel upgrading node number allowed by each service to be upgraded according to the minimum online node number of each service to be upgraded and the service to be upgraded deployed in each node to be upgraded in the plurality of nodes to be upgraded, wherein the maximum parallel upgrading node number is the maximum number of nodes which are simultaneously upgraded and deployed with the same service to be upgraded; and determining the nodes to be upgraded in parallel in the plurality of nodes to be upgraded according to the maximum number of parallel upgrading nodes allowed by each service to be upgraded and the upgrade constraint relation. For example, in connection with fig. 4, the determining unit 1002 may be configured to perform S404, S405.
Optionally, the upgrade constraint relationship is represented by a directed graph; the determining unit 1002 is specifically configured to: the method comprises the steps of obtaining the degree of entry of each node to be upgraded in a directed graph; executing a first operation: determining nodes to be upgraded with zero in-degree in the directed graph, determining nodes to be upgraded in the current batch from the nodes to be upgraded with zero in-degree according to the maximum number of parallel upgrade allowed by each service to be upgraded deployed in the nodes to be upgraded with zero in-degree, removing the nodes to be upgraded in the current batch from the directed graph, and updating the in-degree of the remaining nodes to be upgraded in the directed graph; judging whether nodes to be upgraded with zero in-degree exist in the rest nodes to be upgraded or not; if yes, returning to execute the first operation; and if the node to be upgraded does not exist, obtaining a plurality of batches for upgrading the nodes to be upgraded and the nodes to be upgraded included in each batch. The upgrade management unit 1003 is specifically configured to: the plurality of nodes to be upgraded are upgraded according to the plurality of 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 comprise at least two node combinations, the nodes in each node combination are respectively used as the nodes to be upgraded in the current batch to obtain at least two upgrading schemes, the upgrading schemes are batches for upgrading a plurality of nodes to be upgraded and the nodes to be upgraded in each batch, and each node combination in the at least two node combinations comprises at least one node to be upgraded. The determining unit 1002 is further configured to select an upgrade scheme from at least two upgrade schemes.
Optionally, the upgrade management unit 1003 is specifically configured to: and executing a second operation: determining a target node corresponding to a node to be upgraded of a current upgrading batch, and sending an upgrading instruction to the node to be upgraded of the current upgrading batch, wherein the upgrading instruction comprises an identifier of the target node, and the upgrading instruction is used for instructing to migrate services to be upgraded in the node to be upgraded of the current upgrading batch to the target node and upgrading the node to be upgraded of the current upgrading batch; judging whether the current upgrading batch belongs to the last batch to be upgraded in the plurality of batches; and if the current upgrading batch does not belong to the last upgrading batch in the plurality of batches, taking the next batch of the current upgrading batch as the current upgrading batch and returning to execute the second operation when the node to be upgraded of the current upgrading batch is determined to finish upgrading.
Optionally, the upgrade constraint relationship is represented by a directed graph, and the management node 100 further includes a determining unit 1004. The determining unit 1004 is configured to determine whether there is a node to be upgraded in the upgrade constraint relationship, where the node to be upgraded in deadlock interconnection is a node to be upgraded that forms a ring in the directed graph. The determining unit 1002 is specifically configured to determine a node to be upgraded, which is to be upgraded in parallel, among the multiple nodes to be upgraded according to the upgrade constraint relationship and the minimum online node number of each service to be upgraded among the multiple services to be upgraded when the determining unit 1004 determines that there is no node to be upgraded which is deadlock-interconnected in the upgrade constraint relationship among the multiple nodes to be upgraded. For example, in conjunction with fig. 4, the determining unit 1004 may be configured to execute S402.
Of course, the management node 100 provided by the embodiment of the present invention includes, but is not limited to, the above modules, for example, the management node 100 may further include a storage unit 1005. The storage unit 1005 may be configured to store program codes of the management node 100, and may also be configured to store data generated by the management node 100 during an operation process, for example, a batch of a plurality of nodes to be upgraded is upgraded.
Another embodiment of the present invention further provides a computer-readable storage medium, which stores instructions that, when executed on a computer, cause the computer to perform the steps performed by the management node in the method flow shown in the above method embodiment.
In another embodiment of the present invention, a computer program product is also provided, which includes computer instructions that, when executed on a computer, cause the computer to perform the steps performed by the management node in the method flow shown in the above method embodiment.
Another embodiment of the present invention further provides a distributed system, which may include a management node 100 and a plurality of nodes to be upgraded.
In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented using a software program, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The processes or functions according to embodiments of the present invention occur, in whole or in part, when computer-executable instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wire (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). Computer-readable storage media can be any available media that can be accessed by a computer or can comprise one or more data storage devices, such as servers, data centers, and the like, that can be integrated with the media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.
The foregoing is only illustrative of the present application. Those skilled in the art can conceive of changes or substitutions based on the specific embodiments provided in the present application, and all such changes or substitutions are intended to be included within the scope of the present application.

Claims (11)

1. A service upgrading method in a distributed system is characterized in that the method is applied to a management node in the distributed system, the management node is used for upgrading a plurality of services to be upgraded deployed in a plurality of nodes to be upgraded, and the upgrading method comprises the following steps:
obtaining an upgrade constraint relation among the nodes to be upgraded, wherein the upgrade constraint relation is determined by the upgrade sequence of the services to be upgraded, and the upgrade constraint relation is represented by a directed graph;
judging whether a deadlock-interconnected node to be upgraded exists in the upgrading constraint relation, wherein the deadlock-interconnected node to be upgraded is a node to be upgraded which forms a ring in the directed graph;
when the upgrade constraint relation among the nodes to be upgraded does not have the nodes to be upgraded which are connected in a deadlock manner, determining the nodes to be upgraded in parallel according to the upgrade constraint relation and the minimum online node number of each service to be upgraded in the services to be upgraded, wherein the minimum online node number is the minimum number of the nodes which simultaneously provide the same service to be upgraded;
and upgrading the plurality of nodes to be upgraded according to the determined nodes to be upgraded in parallel.
2. The service upgrading method according to claim 1, wherein the determining the node to be upgraded, which is upgraded in parallel, in the plurality of nodes to be upgraded according to the upgrade constraint relationship and the minimum online node number of each service to be upgraded in the plurality of services to be upgraded includes:
determining the maximum parallel upgrade node number allowed by each service to be upgraded according to the minimum online node number of each service to be upgraded and the service to be upgraded deployed in each node to be upgraded in the plurality of nodes to be upgraded, wherein the maximum parallel upgrade node number is the maximum number of nodes which are simultaneously upgraded and deployed with the same service to be upgraded;
and determining the nodes to be upgraded in parallel in the plurality of nodes to be upgraded according to the maximum number of parallel upgrading nodes allowed by each service to be upgraded and the upgrading constraint relation.
3. The service upgrade method according to claim 2, wherein the upgrade constraint relationship is represented by a directed graph, and determining the nodes to be upgraded in parallel among the plurality of nodes to be upgraded according to the maximum number of nodes to be upgraded in parallel allowed by each service to be upgraded and the upgrade constraint relationship comprises:
acquiring the degree of entry of each node to be upgraded in the directed graph;
executing a first operation: determining a node to be upgraded with zero in-degree in the directed graph; determining nodes to be upgraded in the current batch from the nodes to be upgraded with the zero in-degree according to the maximum number of parallel upgraded nodes allowed by each service to be upgraded deployed in the nodes to be upgraded with the zero in-degree; removing the nodes to be upgraded of the current batch from the directed graph, and updating the in-degree of the rest nodes to be upgraded in the directed graph;
judging whether nodes to be upgraded with zero in-degree exist in the remaining nodes to be upgraded or not;
if yes, returning to execute the first operation;
if the node to be upgraded does not exist, obtaining a plurality of batches of the 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 in parallel comprises the following steps:
and upgrading the nodes to be upgraded according to the batches and the nodes to be upgraded in each batch.
4. The service upgrade method according to claim 3, wherein the determining, according to a maximum number of nodes to be upgraded allowed by each service to be upgraded deployed in the nodes to be upgraded with the zero in-degree, the nodes to be upgraded in the current batch from the nodes to be upgraded with the zero in-degree comprises:
when the nodes to be upgraded of the current batch comprise at least two node combinations, respectively taking the nodes in each node combination as the nodes to be upgraded of the current batch, wherein each node combination of the at least two node combinations comprises at least one node to be upgraded;
the determining the nodes to be upgraded in parallel in the plurality of nodes to be upgraded according to the maximum number of parallel upgrade nodes allowed by each service to be upgraded and the upgrade constraint relationship further comprises:
when at least two upgrading schemes exist, selecting one upgrading scheme from the at least two upgrading schemes, wherein the upgrading scheme is a batch for upgrading the nodes to be upgraded and the nodes to be upgraded in each batch.
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:
and executing a second operation: determining a target node corresponding to a node to be upgraded of a current upgrading batch; sending an upgrade instruction to the node to be upgraded of the current upgrade batch, wherein the upgrade instruction comprises an identifier of the target node, and the upgrade instruction is used for instructing to migrate the service to be upgraded in the node to be upgraded of the current upgrade batch to the target node and upgrade the node to be upgraded of the current upgrade batch;
judging whether the current upgrading batch belongs to the last upgrading batch in the plurality of batches;
and if the current upgrading batch does not belong to the batch which is upgraded at last in the plurality of batches, taking the next batch of the current upgrading batch as the current upgrading batch and returning to execute the second operation when the node to be upgraded of the current upgrading batch is determined to finish upgrading.
6. A management node, configured to upgrade a plurality of services to be upgraded deployed in a plurality of nodes to be upgraded in a distributed system, where the management node includes:
the obtaining unit is used for obtaining an upgrading constraint relation among the nodes to be upgraded, the upgrading constraint relation is determined by the upgrading sequence of the businesses to be upgraded, and the upgrading constraint relation is represented by a directed graph;
the judging unit is used for judging whether a deadlock-interconnected node to be upgraded exists in the upgrading constraint relation, wherein the deadlock-interconnected node to be upgraded is a node to be upgraded which forms a ring in the directed graph;
a determining unit, configured to determine, when the determining unit determines that there is no deadlock-interconnected node to be upgraded in the upgrade constraint relationship among the multiple nodes to be upgraded, a node to be upgraded, which is to be upgraded in parallel among the multiple nodes to be upgraded, according to the upgrade constraint relationship obtained by the obtaining unit and a minimum online node number of each service to be upgraded in the multiple services to be upgraded, where the minimum online node number is a minimum number of nodes that provide the same service to be upgraded at the same time;
and the upgrading management unit is used for upgrading the plurality of nodes to be upgraded according to the nodes to be upgraded which are determined by the determination unit and are upgraded in parallel.
7. The management node according to claim 6, wherein the determining unit is specifically configured to:
determining the maximum parallel upgrade node number allowed by each service to be upgraded according to the minimum online node number of each service to be upgraded and the service to be upgraded deployed in each node to be upgraded in the plurality of nodes to be upgraded, wherein the maximum parallel upgrade node number is the maximum number of nodes which are simultaneously upgraded and deployed with the same service to be upgraded;
and determining the nodes to be upgraded in parallel in the plurality of nodes to be upgraded according to the maximum number of parallel upgrading nodes allowed by each service to be upgraded and the upgrading constraint relation.
8. The management node of claim 7, wherein the upgrade constraint relationship is represented by a directed graph;
the determining unit is specifically configured to:
acquiring the degree of entry of each node to be upgraded in the directed graph;
executing a first operation: determining a node to be upgraded with zero in-degree in the directed graph; determining the nodes to be upgraded in the current batch from the nodes to be upgraded with the zero in-degree according to the maximum number of parallel upgrade nodes allowed by each service to be upgraded deployed in the nodes to be upgraded with the zero in-degree; removing the nodes to be upgraded of the current batch from the directed graph, and updating the degree of entry of the remaining nodes to be upgraded in the directed graph;
judging whether nodes to be upgraded with zero in-degree exist in the remaining nodes to be upgraded or not;
if yes, returning to execute the first operation;
if the node to be upgraded does not exist, obtaining a plurality of batches of the nodes to be upgraded and the nodes to be upgraded included in each batch;
the upgrade management unit is specifically configured to: and upgrading the nodes to be upgraded according to the batches determined by the determining unit and the nodes to be upgraded included in each batch.
9. The management node of claim 8,
the determining unit is specifically configured to: when the nodes to be upgraded of the current batch comprise at least two node combinations, respectively taking the nodes in each node combination as the nodes to be upgraded of the current batch, wherein each node combination of the at least two node combinations comprises at least one node to be upgraded;
the determining unit is further configured to select one upgrade scheme from the at least two upgrade schemes when at least two upgrade schemes exist, where the upgrade scheme is a batch for upgrading the plurality of nodes to be upgraded and a node to be upgraded included in each batch.
10. The management node according to claim 8, wherein the upgrade management unit is specifically configured to:
and executing a second operation: determining a target node corresponding to a node to be upgraded of a current upgrading batch; sending an upgrade instruction to the nodes to be upgraded of the current upgrade batch, wherein the upgrade instruction comprises the identification of the target node, and the upgrade instruction is used for instructing to migrate the services to be upgraded in the nodes to be upgraded of the current upgrade batch to the target node and upgrade the nodes to be upgraded of the current upgrade batch;
judging whether the current upgrading batch belongs to the last upgrading batch in the plurality of batches;
and if the current upgrading batch does not belong to the batch which is upgraded at last in the plurality of batches, taking the next batch of the current upgrading batch as the current upgrading batch when the nodes to be upgraded of the current upgrading batch are determined to be upgraded, and returning to execute the second operation.
11. An upgrade apparatus, comprising a memory for storing computer executable instructions and a processor for invoking the computer executable instructions so that the upgrade apparatus executes the computer executable instructions to implement the service upgrade method according to any one of claims 1 to 5 when running.
CN201980030054.3A 2019-07-09 2019-07-09 Service upgrading method and device in distributed system and distributed system Active CN112470119B (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/095312 WO2021003677A1 (en) 2019-07-09 2019-07-09 Service upgrade method and apparatus in distributed system, and distributed system

Publications (2)

Publication Number Publication Date
CN112470119A CN112470119A (en) 2021-03-09
CN112470119B true CN112470119B (en) 2022-09-16

Family

ID=74114924

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980030054.3A Active CN112470119B (en) 2019-07-09 2019-07-09 Service upgrading method and device in distributed system and distributed system

Country Status (2)

Country Link
CN (1) CN112470119B (en)
WO (1) WO2021003677A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116166300B (en) * 2023-04-19 2023-07-18 北京路浩知识产权集团有限公司 Upgrade management method and device for intellectual property system
CN116319712B (en) * 2023-05-23 2023-08-18 北京智芯半导体科技有限公司 Wireless upgrading method and device for slave nodes of power equipment body area network

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109753300A (en) * 2017-11-03 2019-05-14 阿里巴巴集团控股有限公司 A kind of algorithm upgrade method, calculating task sending method and Related product

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101741894B (en) * 2008-11-26 2012-09-19 中国移动通信集团公司 Upgrade method for distributed system and upgrade scheduling node and system
US8516474B2 (en) * 2009-07-31 2013-08-20 Alcatel Lucent Method and system for distributing an upgrade among nodes in a network
CN103327038B (en) * 2012-03-20 2016-06-22 中兴通讯股份有限公司 The method of the batch upgrade network equipment and device
US9578091B2 (en) * 2013-12-30 2017-02-21 Microsoft Technology Licensing, Llc Seamless cluster servicing
US10282187B2 (en) * 2014-07-03 2019-05-07 Oracle International Corporation Efficient application patching in heterogeneous computing environments
CN105005487B (en) * 2015-06-29 2018-06-22 清华大学 A kind of High-Performance Computing Cluster operating system online upgrading method of continuous service
EP3417371A1 (en) * 2016-02-17 2018-12-26 Telefonaktiebolaget LM Ericsson (publ) Model based upgrade campaign generation
CN106354531B (en) * 2016-08-25 2020-03-27 杭州华为数字技术有限公司 Physical node upgrading method and device
CN108268271A (en) * 2016-12-29 2018-07-10 华为技术服务有限公司 The upgrade method and update device of micro services
CN106886410B (en) * 2017-01-06 2018-06-19 深圳云天励飞技术有限公司 A kind of software version management system
CN108345462B (en) * 2018-01-11 2020-12-22 华为技术有限公司 Method and device for upgrading components
CN108958772A (en) * 2018-07-03 2018-12-07 武汉精测电子集团股份有限公司 A kind of batch upgrading method and system of more board equipment
CN109101260B (en) * 2018-08-30 2023-01-24 郑州云海信息技术有限公司 Node software upgrading method and device and computer readable storage medium

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109753300A (en) * 2017-11-03 2019-05-14 阿里巴巴集团控股有限公司 A kind of algorithm upgrade method, calculating task sending method and Related product

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"SaaS软件服务基于大规模定制的业务逻辑框架研究";罗小利 等;《电信科学》;20110915;第27卷(第09期);第26-31页 *

Also Published As

Publication number Publication date
WO2021003677A1 (en) 2021-01-14
CN112470119A (en) 2021-03-09

Similar Documents

Publication Publication Date Title
CN107769949B (en) Application component deployment method and deployment node
US20140376362A1 (en) Dynamic client fail-over during a rolling patch installation based on temporal server conditions
CN113296792B (en) Storage method, device, equipment, storage medium and system
US8185624B2 (en) Efficient on-demand provisioning of servers for specific software sets
CN112506617B (en) Mirror image updating method and device for side car containers in Kubernetes cluster
CN108628660B (en) Virtual machine capacity expansion and reduction method and virtual management equipment
EP3879875A1 (en) Resource change method and device, apparatus, and storage medium
CN112470119B (en) Service upgrading method and device in distributed system and distributed system
CN107479937A (en) A kind of multi-node cluster intersects the method for upgrading
CN109753300B (en) Algorithm upgrading method, calculation task sending method and related device
CN110262893B (en) Method and device for configuring mirror image memory and computer storage medium
CN108319492B (en) Method, device and system for resetting physical machine
CN111049682B (en) Method, system and central network equipment for realizing uninterrupted service upgrade
CN110795205B (en) System and method for providing cloud service based on software container
JP7439928B2 (en) Management device, management method, management program, and management system
CN108536541B (en) Process engine object processing method and device
CN114546493A (en) Core sharing method and device, processing core, electronic device and medium
CN111767126A (en) System and method for distributed batch processing
CN111416888A (en) Addressing method and device based on service gateway
CN114070889B (en) Configuration method, traffic forwarding device, storage medium, and program product
CN109032674B (en) Multi-process management method, system and network equipment
CN110308914B (en) Upgrade processing method, device, equipment, system and computer readable storage medium
CN116450165A (en) Method, system, terminal and storage medium for quickly building environment and deploying program
CN111769966B (en) Clone upgrading method, system and application
US20200356355A1 (en) Distributed autonomous patching system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant