Mutli-Raft algorithm-based edge node management system

Abstract

The invention relates to an edge node management system based on a Mutli-Raft algorithm, and belongs to the technical field of cloud computing. According to the system, based on a Mutli-Raft algorithm, edge nodes are divided into a plurality of node partitions according to network interaction conditions and node positions, and each node partition is internally provided with an independent Raft group which is responsible for managing and maintaining the consistency of data in the edge node partitions. Partition management nodes are elected in the node partitions according to the network connection condition of the edge nodes and the cloud management center, and efficient and accurate transmission of cloud edge data is guaranteed. Any edge node in the partition can know the resource use conditions of other edge nodes, and can provide accurate and consistent data such as node health states and resource use conditions for the cloud management center, so that the situation that the cloud management center cannot perceive the health states of the edge nodes is avoided; the problems of task expelling and resource waste under the condition that nodes are not damaged in a complex network environment are solved. According to the invention, network overhead can be reduced, and rapid recovery of edge applications can be guaranteed.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud computing, and in particular relates to an edge node management system based on the Mutli-Raft algorithm. Background Art

[0002] In recent years, cloud native and edge computing technologies have developed rapidly. Under the condition of good network connection, cloud-edge collaboration technology can send tasks to edge nodes and make full use of edge node resources. However, in a complex network environment with weak connection and low bandwidth, traditional cloud-edge collaboration technology is difficult to accurately perceive the health status of edge nodes, resulting in the expulsion of tasks when edge nodes are not damaged, causing waste of resources; at the same time, it is difficult to flexibly use edge data. Edge node management technology replaces the cloud management center to manage and control widely distributed and dispersed edge nodes at the edge of the network. It can quickly perceive the node status and provide flexible application management capabilities.

[0003] There is an edge node management method. An edge node group is created based on the regional identification of the edge node. Each edge node group includes at least one edge node. The cloud management center obtains the node resource status of the edge node group and schedules the task to the edge node group so that the edge node executes the edge application load, thereby realizing unified management of edge nodes in different regions and improving the overall operating performance and reliability of edge nodes. This method groups edge nodes based on region, realizing regional management and regional scheduling of edge nodes. However, in the complex network environment of cloud-edge, this method cannot provide the cloud management center with fast and accurate node status information. When the cloud-edge network is disconnected, the cloud management center cannot identify the health status of the edge node, and will migrate the edge application to other nodes, causing the resources of the edge node to be idle without damage.

[0004] There is another edge node management method. The edge node receives data sent by the cloud management center. The data contains key information of each edge node. The edge node can draw an edge map of the current edge node based on the key information, characterize the degree of association between the current edge node and other edge nodes, determine the associated edge node based on the degree of association, and establish a synchronization relationship between the current edge node and the associated edge node. When the current edge node fails, the associated edge node takes over the task of the current edge node, realizing information interaction and associated scheduling between edge nodes, and improving the processing speed. In a complex network environment at the edge of the cloud, when an edge node fails, this method can quickly complete application migration without going through the cloud management center, providing users with stable services. However, in a complex network environment at the edge of the cloud, the edge node in this method cannot perceive the resource status of the associated node in real time, and cannot ensure that the resource margin of the associated node always meets the task carrying requirements, so there is a possibility of service interruption. Summary of the invention

[0005] 1. Technical issues to be resolved

[0006] The technical problem to be solved by the present invention is how to provide an edge node management system based on the Mutli-Raft algorithm to solve the problems of task expulsion and resource waste in the case of non-damaged nodes in a complex network environment.

[0007] (II) Technical solution

[0008] In order to solve the above technical problems, the present invention proposes an edge node management system based on the Mutli-Raft algorithm. Based on the network connection interaction of the edge nodes and the node location factors, the edge nodes are divided into multiple edge partitions. Each edge partition forms an independent Raft group with independent partition role management, partition data management and partition application management capabilities.

[0009] In each edge partition, a distributed consensus is reached on the resource usage, node health status, and application running status of edge nodes through the Raft consensus algorithm. Each edge node stores the consistent status information and synchronizes and updates it regularly.

[0010] At the same time, a partition management node is elected within the edge partition to upload and store partition metadata and send and receive scheduling instructions with the cloud management center. For the complex network environment with weak connection and low bandwidth at the cloud edge, the partition management node has the best communication capability with the cloud management center.

[0011] (III) Beneficial effects

[0012] The present invention proposes an edge node management system based on the Mutli-Raft algorithm. Compared with the prior art, the present invention proposes an edge node management system based on the Mutli-Raft algorithm. The system can partition edge nodes for management, reduce the communication overhead between a cloud management center and edge nodes, and adapt to complex network environments with weak cloud-edge connections and low bandwidth. Edge nodes within a partition form independent Raft groups that can sense each other, and provide the cloud management center with consistent and accurate node health status and resource usage, thereby solving the problem that the cloud management center misjudges edge nodes as node failures and expels tasks when the cloud-edge is disconnected, and fully utilizes edge node resources. The edge node management system based on the Mutli-Raft algorithm provides two methods of intra-partition migration and inter-partition migration after edge node damage, thereby reducing network overhead and ensuring rapid recovery of edge applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 This is an architecture diagram of the edge node management system based on the Mutli-Raft algorithm of the present invention;

[0014] Figure 2Manage node election and succession flow chart for edge partitions;

[0015] Figure 3 Apply migration flow chart for edge node failure. DETAILED DESCRIPTION

[0016] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0017] The present invention belongs to the technical field of cloud computing, and combines edge computing with a distributed consensus algorithm to solve the problem of edge node management distributed over a wide area, and specifically relates to an edge node management system based on the Mutli-Raft algorithm.

[0018] The purpose of the present invention is to propose an edge node management system based on the Mutli-Raft algorithm. Based on the Mutli-Raft algorithm, the system divides the edge nodes into multiple node partitions according to the network interaction and node location. Each node partition has an independent Raft group inside, which is responsible for managing and maintaining the consistency of the data inside the edge node partition. The node partition elects the partition management node according to the network connection between the edge node and the cloud management center to ensure the efficient and accurate transmission of cloud edge data. Any edge node in the partition can know the resource usage of other edge nodes, and can provide the cloud management center with accurate and consistent node health status, resource usage and other data, so as to avoid the cloud management center from being unable to perceive the health status of the edge nodes, and solve the problem of task expulsion and resource waste in the case of non-damaged nodes in complex network environments. The edge node management system based on the Mutli-Raft algorithm designs an edge partition management scheduler in the cloud management center, which is responsible for managing the metadata of each partition, monitoring the resource status of each partition, providing support for task scheduling between partitions, and ensuring the rapid recovery of edge applications.

[0019] Figure 1It is an edge node management system architecture diagram based on the Mutli-Raft algorithm. The system divides edge nodes into multiple edge partitions based on factors such as edge node network connection interaction and node location. Each edge partition forms an independent Raft group with independent partition role management, partition data management and partition application management capabilities. In each edge partition, a distributed consensus is reached on edge node resource usage, node health status and application running status through the Raft consensus algorithm. Each edge node stores consistency status information and updates it synchronously regularly. At the same time, a partition management node is elected within the edge partition to upload and store partition metadata and send and receive scheduling instructions with the cloud management center. For the complex network environment with weak connection and low bandwidth at the cloud edge, the partition management node has the best communication capability with the cloud management center, thereby ensuring stable and reliable transmission of cloud edge data.

[0020] The system is divided into two levels, namely the cloud management center side and the edge side. The cloud management center side includes: edge partition management scheduler and edge partition data storage; the edge partition includes: partition role management component, partition data management component and partition application management component. The specific functions of the components are as follows:

[0021] The edge partition management scheduler is the core of task scheduling management. It is used to schedule tasks to specific edge partitions based on task attributes, edge partition resource usage, and network connection conditions.

[0022] The edge partition data storage device is the core of edge data storage and is used to store edge partition metadata, including partition identification, partition node information, partition management node information, partition application load status, and edge application data, providing data support for the edge partition management scheduler to complete task scheduling and application migration between partitions;

[0023] Partition role management, responsible for the election and succession of partition management nodes within edge partitions;

[0024] Partition data management, responsible for the consensus management of data such as node resource information, node health status, and application load status within the edge partition, to ensure that each node reaches a consensus;

[0025] Partition application management is responsible for task scheduling and application migration within edge partitions.

[0026] In the traditional cloud-edge fusion architecture, task distribution is completely controlled by the cloud management center, which is easily limited by the complex network conditions of the cloud and edge, making it difficult to accurately perceive the health status of nodes, thereby causing resource waste. The cloud management center of the edge node management system based on the Mutli-Raft algorithm can always complete resource monitoring and task distribution with the node with the best communication connection in the edge partition, and the cloud management center is only responsible for scheduling tasks to the edge partition level. The specific edge node to which the task is scheduled is determined by the edge partition.

[0027] Edge partitions are divided according to node locations and network connectivity. Compared with the cloud management center, the partition management node has better network communication capabilities with other edge nodes in the partition, and can more accurately perceive the health status and resource usage of edge nodes. When the partition management node receives a task scheduling instruction, it schedules the task to the most suitable edge node by filtering and weight sorting according to the parsed task attributes. After the scheduling is completed, the partition management node informs the cloud management center of the task load status, and notifies other edge nodes in the partition of changes in partition resources and application execution through broadcasting to reach a consensus on the partition status.

[0028] Figure 2 This is a flow chart for the election and succession of partition management nodes within edge partitions. Edge nodes sometimes have dynamic changes in network status due to task requirements and node location maneuvers. In order to ensure that the cloud management center can always form the best communication link with the edge partition, it is necessary to dynamically elect and succeed partition management nodes. The specific steps are as follows:

[0029] Step S21, initialize the edge node to follower state and initialize the term number;

[0030] Step S22: The edge node determines the node timeout period according to the network connection status with the cloud management center;

[0031] The better the network connection status between the edge node and the cloud management center, the shorter the node timeout period.

[0032] Step S23: The edge node that times out first modifies its term number, recommends itself as a candidate node for partition management, and votes for itself. At the same time, it broadcasts to other nodes, requesting that it be elected as a partition management node.

[0033] Step S24: Determine whether other edge nodes have timed out before receiving the broadcast message. If so, the term number will be modified and the broadcast message of electing itself will be initiated. If not, the vote will be cast for the candidate node of the partition management node corresponding to the first received broadcast message.

[0034] The edge nodes in each partition have only one vote in one term election cycle. When the candidate node voting is completed within one term, it becomes the follower of the candidate node. Before the partition management node is determined, it will no longer vote even if it receives election broadcasts from other edge nodes.

[0035] Step S25: Summarize the voting results, and the edge node with the most votes becomes the partition management node and starts its term;

[0036] During its term of office, the partition management node reports the partition status to the cloud management center and receives partition task scheduling instructions; at the same time, it broadcasts heartbeat messages to other nodes in the partition to confirm its own survival status.

[0037] Step S26: When the partition management node is damaged or the network status is poor, other edge nodes in the partition do not receive the heartbeat message within the specified time, and other edge nodes re-determine the timeout time according to the network status;

[0038] If other edge nodes in the partition do not receive the heartbeat message within the specified time, the other edge nodes are considered to have reached the end of their terms and need to re-elect new partition management nodes. Each node re-determines the timeout period based on the network connection status with the cloud management center.

[0039] Step S27: broadcast voting, elect a new partition management node to take over, and modify the term number;

[0040] Step S28: Based on the consensus of the nodes in the partition, the new partition management node establishes a connection with the cloud management center to synchronize the partition status.

[0041] Figure 3 This is the flow chart of edge node failure application migration. After the cloud management center dispatches the task to the edge partition, the edge application is provided with lifecycle management capabilities by the edge partition. When an edge node failure occurs and the application needs to be migrated, the edge application migration is completed in collaboration with the cloud management center based on the usage of partition resources. The specific steps are as follows:

[0042] Step S31: When the partition management node senses that an edge node fails, an application migration program is started;

[0043] Step S32: The partition management node obtains the application attributes and resource requirements running on the faulty edge node, and initiates a current node resource reporting notification to other edge nodes in the partition;

[0044] Step S33, determine whether there are other edge nodes in the edge partition that meet the application requirements; if so, enable application migration within the edge partition and execute S34; if not, migrate the application to other edge partitions and execute S36.

[0045] Step S34: When other edge nodes in the edge partition meet the application running requirements, the partition management node migrates the application to the best edge node in the partition for hosting according to the filtering and weight sorting algorithm;

[0046] Step S35: The partition management node reports the latest application load status and node health status to the cloud management center. The cloud management center modifies the application load data and node status, completes the edge node failure application migration, and ends the process.

[0047] Step S36: When other edge nodes in the edge partition do not meet the application running requirements, the partition management node synchronizes the application attributes, resource requirements and application data to the cloud management center, and clears the application data in the partition;

[0048] Step S37: The cloud management center reads the edge partition data storage device to obtain resource usage of other edge partitions;

[0049] Step S38: The cloud management center uses the edge partition scheduler to perform secondary scheduling in combination with the acquired resource usage of other partitions;

[0050] Step S39: After receiving the scheduling instruction, other edge partitions complete the task scheduling within the partition, notify the cloud management center, modify the application bearer data, complete the edge node failure application migration, and end the process.

[0051] Compared with the prior art, the present invention proposes an edge node management system based on the Mutli-Raft algorithm. The system can manage edge nodes by partitioning, reduce the communication overhead between the cloud management center and the edge nodes, and adapt to the complex network environment with weak connection and low bandwidth of the cloud edge; the edge nodes in the partition form an independent Raft group that can perceive each other, and provide the cloud management center with consistent and accurate node health status and resource usage, so as to solve the problem that the cloud management center misjudges the edge nodes as node failures and expels tasks when the cloud edge is disconnected, and make full use of edge node resources; the edge node management system based on the Mutli-Raft algorithm provides two methods of intra-partition migration and inter-partition migration after the edge node is damaged, which reduces network overhead while ensuring the rapid recovery of edge applications.

[0052] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. An edge node management system based on the Mutli-Raft algorithm, characterized in that: Based on the network connection interaction of edge nodes and node location factors, edge nodes are divided into multiple edge partitions. Each edge partition forms an independent Raft group with independent partition role management, partition data management and partition application management capabilities. In each edge partition, a distributed consensus is reached on the resource usage, node health status, and application running status of edge nodes through the Raft consensus algorithm. Each edge node stores the consistent status information and synchronizes and updates it regularly. At the same time, a partition management node is elected within the edge partition to upload and store partition metadata and send and receive scheduling instructions with the cloud management center. For the complex network environment with weak connection and low bandwidth at the cloud edge, the partition management node has the best communication capability with the cloud management center.

2. The edge node management system based on the Mutli-Raft algorithm according to claim 1, characterized in that: The system is divided into two levels, namely the cloud management center side and the edge side. The cloud management center side includes: edge partition management scheduler and edge partition data storage; the edge partition includes: partition role management component, partition data management component and partition application management component.

3. The edge node management system based on the Mutli-Raft algorithm as claimed in claim 2, characterized in that: The edge partition management scheduler is the core of task scheduling management. It is used to schedule tasks to specific edge partitions based on task attributes, edge partition resource usage, and network connection conditions. The edge partition data storage device is the core of edge data storage and is used to store edge partition metadata, including partition identification, partition node information, partition management node information, partition application load status, and edge application data, providing data support for the edge partition management scheduler to complete task scheduling and application migration between partitions.

4. The edge node management system based on the Mutli-Raft algorithm as claimed in claim 3, characterized in that: Partition role management, responsible for the election and succession of partition management nodes within edge partitions; Partition data management, responsible for the consensus management of node resource information, node health status, and application load data within the edge partition to ensure that each node reaches a consensus; Partition application management is responsible for task scheduling and application migration within edge partitions.

5. The edge node management system based on the Mutli-Raft algorithm as claimed in claim 4, characterized in that: When a partition management node receives a task scheduling instruction, it schedules the task to the most suitable edge node by filtering and weight sorting according to the parsed task attributes. After the scheduling is completed, the partition management node informs the cloud management center of the task load status and notifies other edge nodes in the partition of changes in partition resources and application execution through broadcasting to reach a consensus on the partition status.

6. The edge node management system based on the Mutli-Raft algorithm according to claim 4, characterized in that: The election and succession of the partition management node includes the following steps: Step S21, initialize the edge node to follower state and initialize the term number; Step S22: The edge node determines the node timeout period according to the network connection status with the cloud management center; Step S23: The edge node that times out first modifies its term number, recommends itself as a candidate node for partition management, and votes for itself. At the same time, it broadcasts to other nodes, requesting that it be elected as a partition management node. Step S24: Determine whether other edge nodes have timed out before receiving the broadcast message. If so, they will modify their term numbers and also initiate their own broadcast information elections. If it does not time out, the vote will be cast for the partition management node candidate node corresponding to the first received broadcast message; Step S25: Summarize the voting results, and the edge node with the most votes becomes the partition management node and starts its term. During the term, the partition management node reports the partition status to the cloud management center and receives the partition task scheduling instructions. At the same time, it broadcasts heartbeat messages to other nodes in the partition to confirm its own survival status. Step S26: When the partition management node is damaged or the network status is poor, other edge nodes in the partition do not receive the heartbeat message within the specified time, and other edge nodes re-determine the timeout time according to the network status; Step S27: broadcast voting, elect a new partition management node to take over, and modify the term number; Step S28: Based on the consensus of the nodes in the partition, the new partition management node establishes a connection with the cloud management center to synchronize the partition status.

7. The edge node management system based on the Mutli-Raft algorithm according to claim 6, characterized in that: In S24, each edge node in each partition has only one vote in one term election cycle; when the candidate node voting is completed within one term, it becomes the follower of the candidate node, and will not vote again even if it receives election broadcasts from other edge nodes before the partition management node is determined.

8. The edge node management system based on the Mutli-Raft algorithm according to claim 6, characterized in that: In S26, if other edge nodes in the partition do not receive the heartbeat message within the specified time, the other edge nodes are deemed to be about to end their terms and need to re-elect new partition management nodes. Each node re-determines the timeout period based on the network connection status with the cloud management center.

9. The edge node management system based on the Mutli-Raft algorithm according to claim 4, characterized in that: After the cloud management center schedules the task to the edge partition, the edge application is provided with lifecycle management capabilities by the edge partition. When an edge node failure occurs and the application needs to be migrated, the edge application migration is completed in collaboration with the cloud management center based on the usage of partition resources.

10. The edge node management system based on the Mutli-Raft algorithm according to claim 9, characterized in that: The application migration within the edge partition includes the following steps: Step S31: When the partition management node senses that an edge node fails, an application migration program is started; Step S32: The partition management node obtains the application attributes and resource requirements running on the faulty edge node, and initiates a current node resource reporting notification to other edge nodes in the partition; Step S33, determine whether there are other edge nodes in the edge partition that meet the application requirements; if yes, enable application migration in the edge partition and execute S34; if no, migrate the application to other edge partitions and execute S36; Step S34: When other edge nodes in the edge partition meet the application running requirements, the partition management node migrates the application to the best edge node in the partition for hosting according to the filtering and weight sorting algorithm; Step S35: The partition management node reports the latest application load status and node health status to the cloud management center. The cloud management center modifies the application load data and node status, completes the edge node failure application migration, and ends the process. Step S36: When other edge nodes in the edge partition do not meet the application running requirements, the partition management node synchronizes the application attributes, resource requirements and application data to the cloud management center, and clears the application data in the partition; Step S37: The cloud management center reads the edge partition data storage device to obtain resource usage of other edge partitions; Step S38: The cloud management center uses the edge partition scheduler to perform secondary scheduling in combination with the acquired resource usage of other partitions; Step S39: After receiving the scheduling instruction, other edge partitions complete the task scheduling within the partition, notify the cloud management center, modify the application bearer data, complete the edge node failure application migration, and end the process.

Images