Efficient repair method for erasure code storage system in ubiquitous scenario

Abstract

The application discloses a kind of efficient repair methods of erasure code storage system in ubiquitous scene, belong to distributed storage and data fault-tolerant field.The repair plan of failure block is decomposed into upload task and download task, and the download task is optimally distributed based on the available download bandwidth of each node, to obtain the task distribution scheme of minimizing download bottleneck time;According to the scheme, upload task and download task are paired, and a directed acyclic repair path with a heap-like structure is constructed;In the repair process, monitor the available network bandwidth change of each node, when the available download bandwidth of the laggard node is monitored to drop sharply, the laggard node and the node with the maximum available download bandwidth in its child node are repeatedly exchanged positions using the heap-like structure until the laggard no longer undertakes download task, to realize the low-overhead dynamic adjustment of repair path.The application can formulate efficient repair path, and adaptively adjust when bandwidth changes, reduce repair bottleneck time, improve repair throughput and system reliability.

Description

Technical Field

[0001] This invention belongs to the field of distributed storage and data fault tolerance technology, specifically relating to an efficient repair method for erasure coding storage systems in ubiquitous scenarios. Background Technology

[0002] With the rapid development of cloud computing and edge computing technologies, cloud-edge-device storage systems have been widely applied in fields such as the Internet of Things (IoT), smart manufacturing, and smart cities. In these scenarios, storage systems face the challenge of managing massive amounts of data, and providing efficient and reliable data storage services under limited resource conditions has become an urgent problem to solve. Erasure coding, due to its excellent storage utilization and fault tolerance capabilities, has become the mainstream solution for data redundancy protection in cloud-edge-device storage systems. However, the erasure coding repair process often incurs high network transmission overhead, especially in cloud-edge-device environments where network resources are limited.

[0003] The repair overhead of erasure coding primarily stems from the need to retrieve multiple live data blocks when repairing a single data block, leading to amplified repair traffic. In traditional data center environments, servers typically use high-speed wired networks for data transmission, effectively reducing network bandwidth pressure during the repair process. However, in cloud-edge-device environments, edge devices often rely on wireless networks or low-speed wired network connections, with bandwidth typically only in the Mb / s range, far below the network transmission capacity of data centers. Therefore, traditional erasure coding repair algorithms may face severe repair bottlenecks in cloud-edge-device architectures, resulting in prolonged repair times and consequently impacting system reliability.

[0004] Furthermore, network connectivity in a cloud-edge-device architecture is more unstable than in a data center, and communication between devices may be affected by network jitter or temporary disconnections. In such cases, the system needs to rely on degraded reads to retrieve temporarily unavailable data. However, due to network fluctuations, a "lagging device" problem may occur during the recovery process, where some devices slow down the entire recovery process due to poor network conditions. This not only prolongs data recovery time but may also make the storage system more vulnerable to subsequent failures, thereby increasing the risk of data loss and reducing the storage quality of the cloud-edge-device storage system.

[0005] Therefore, designing an efficient repair algorithm suitable for cloud-edge-device architecture (especially between edge nodes and end nodes) to increase repair throughput and reduce repair time is an important issue for improving the feasibility of erasure coding in this scenario. Summary of the Invention

[0006] This invention provides an efficient repair method for erasure coding storage systems in ubiquitous scenarios, aiming to solve the problems of long repair time, low repair efficiency, and difficulty in adaptive adjustment caused by the dynamic fluctuation of bandwidth and significant differences in node capabilities in existing erasure coding repair algorithms in heterogeneous network environments such as cloud, edge, and terminal.

[0007] This invention provides an efficient repair method for a ubiquitous erasure coding storage system, comprising: Select k source nodes and one destination node in the stripe containing the failed block to be repaired, and obtain the available upload bandwidth and available download bandwidth of each source node, as well as the available download bandwidth of the destination node; where k is the number of source nodes required to repair the failed block; The repair plan for the failed block is decomposed into k upload tasks and k download tasks. Each source node is assigned an upload task, and each upload task is used to upload a data block. Based on the available download bandwidth of each node, the k download tasks are allocated to obtain a task allocation scheme that minimizes the download bottleneck time, where the download bottleneck time is the maximum value of the expected completion time of the download tasks among all nodes participating in the repair. According to the task allocation scheme, upload tasks and download tasks are paired to construct a repair path. The repair path is a directed acyclic graph and satisfies the following conditions: except for the destination node, each source node is arranged in descending order of available download bandwidth, and the available download bandwidth of each node is greater than the available download bandwidth of all its child nodes, forming a heap-like structure. Perform data repair according to the repair path, and monitor the changes in available network bandwidth of each node in real time during the repair process; When a lagging node with a sudden drop in available download bandwidth is detected, the repair path is dynamically adjusted using the heap-like structure. This is achieved by swapping the lagging node with the node among its child nodes that has the largest available download bandwidth, and repeating this operation until the lagging node no longer undertakes download tasks, thereby mitigating the impact of lagging nodes on repair performance.

[0008] As can be seen, the technical solution provided by this invention minimizes download bottleneck time by decomposing the repair plan into upload and download tasks and optimizing the allocation based on available download bandwidth. It constructs a directed acyclic repair path with a heap-like structure, laying the structural foundation for low-overhead dynamic adjustment. Simultaneously, it monitors bandwidth changes in real time during the repair process. When a lagging node with a sudden drop in available download bandwidth is detected, the heap-like structure is used to repeatedly swap positions with the node's child node with the maximum download bandwidth until the lagging node no longer undertakes download tasks. This significantly reduces repair bottleneck time and enables rapid adaptive adjustment of the repair path. Compared to existing technologies that only focus on node selection or strategy switching before reconstruction, this invention can maintain efficient repair in heterogeneous and dynamically fluctuating network environments at the cloud, edge, and endpoint, effectively preventing lagging nodes from dragging down the overall progress, significantly improving repair throughput and system reliability, and providing strong support for the widespread application of erasure coding in cloud-edge-end storage architectures. Attached Figure Description

[0009] Figure 1 A flowchart illustrating an efficient repair method for a ubiquitous erasure coding storage system provided in this embodiment of the invention; Figure 2 This is a schematic diagram of a repair plan breakdown provided in an embodiment of the present invention; Figure 3 A schematic diagram of download task allocation provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the construction of a feasible repair path provided in an embodiment of the present invention; Figure 5 A schematic diagram of a node selection strategy based on replacement provided in an embodiment of the present invention; Figure 6 An example diagram of a dynamic adjustment strategy based on heap properties provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of an ECHeap system architecture provided in an embodiment of the present invention. Detailed Implementation

[0010] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0011] To address the technical problems in the background, this invention focuses on optimizing erasure coding repair algorithms in a cloud-edge-device architecture to improve data reliability and service quality, providing a more efficient and robust fault-tolerance mechanism for cloud-edge-device storage systems, and facilitating the widespread application of erasure coding in this architecture. This invention designs a high-speed erasure coding monolithic repair mechanism suitable for cloud-edge-device architectures, possessing the following two characteristics: First, this mechanism can formulate feasible and efficient repair paths at low cost based on different heterogeneous network environments, achieving efficient repair in various network conditions. Second, this mechanism should have low-overhead repair path adjustment capabilities, enabling it to quickly adapt to dynamic changes in available network bandwidth and continuously maintain high repair efficiency, thereby improving data reliability and service quality in cloud-edge-device environments.

[0012] like Figure 1 As shown in the figure, an efficient repair method for a ubiquitous erasure coding storage system provided by an embodiment of the present invention may specifically include the following steps: S110: Select k source nodes and one destination node in the stripe containing the failed block to be repaired, and obtain the available upload bandwidth and available download bandwidth of each source node, as well as the available download bandwidth of the destination node. Here, k is the number of source nodes required to repair the failed block.

[0013] Specifically, given a failed block C′ to be repaired, select a set of candidate destination nodes D, such that these nodes do not store any blocks of the stripe containing C′ before repair. Selecting a node from D as the destination node to repair the failed block C′ ensures that the repaired stripe still spans n nodes, tolerating failures of any nk nodes. For each node N... i ∈D, obtain its available download bandwidth. The node with the largest available download bandwidth in the candidate destination node set D is selected as the destination node, denoted as N. d Simultaneously, a set S of candidate source nodes with n-1 nodes is obtained, which stores surviving blocks in the stripe containing the failed block C′. k source nodes are selected from this set to participate in the repair, and the available upload and download bandwidth of each source node is obtained.

[0014] S120 decomposes the repair plan for the failed block into k upload tasks and k download tasks. Each source node is assigned one upload task, and each upload task is used to upload one data block.

[0015] Specifically, repairing a failed block requires establishing a repair plan on k+1 nodes. K source nodes provide surviving blocks, and one destination node stores the repaired block. To fully utilize available bandwidth, the repair plan is decomposed into k upload tasks and k download tasks. The k upload tasks can be denoted as {U1, U2, ..., Uk}, and the k download tasks can be denoted as {D1, D2, ..., Dk}. Each upload task (or download task) is responsible for uploading (or downloading) one block for repair. Each source node is assigned one upload task, and each upload task is used to upload one data block.

[0016] like Figure 2 As shown, taking the repair of a failed block involving four source nodes as an example (i.e., k=4), the repair process can be decomposed into eight repair tasks, including four upload tasks ({U1, U2, ..., U4} and four download tasks ({D1, D2, ..., D4}). Figure 2 In this context, C1, C2, C3, and C4 represent the surviving data blocks (i.e., surviving blocks) stored on the four source nodes participating in the repair, which are used to repair the failed block C′. Then, in this embodiment, ECHeap (i.e., the efficient erasure coding repair scheme for cloud-edge-device architecture proposed in this invention) will find k+1 nodes (k source nodes and 1 destination node) and distribute these 2k tasks to the nodes, thereby making full use of available network bandwidth for repair.

[0017] S130: Based on the available download bandwidth of each node, allocate k download tasks to obtain a task allocation scheme that minimizes the download bottleneck time, where the download bottleneck time is the maximum value of the expected completion time of download tasks among all nodes participating in the repair.

[0018] For any node N among the k selected source nodes i The number of download tasks allocated to it and the available download bandwidth are respectively recorded as follows: and For destination node N d Since it only undertakes download tasks, only the number of download tasks allocated to it and its available download bandwidth need to be considered. Therefore, this invention denotes the number of download tasks allocated to the destination node and its available download bandwidth as follows: and The concept of repair bottleneck time is introduced in erasure coding: the download bottleneck time is the maximum estimated completion time of download tasks across all participating nodes. By allocating download tasks, the download bottleneck time is minimized among all possible allocation schemes, resulting in a task allocation scheme that minimizes the download bottleneck time.

[0019] S140. According to the task allocation scheme, upload tasks and download tasks are paired to construct a repair path. The repair path is a directed acyclic graph and satisfies the following conditions: except for the destination node, each source node is arranged in descending order of available download bandwidth, and the available download bandwidth of each node is greater than the available download bandwidth of all its child nodes, forming a heap-like structure.

[0020] Specifically, after allocating 2k repair tasks across the selected k+1 nodes, repair paths are defined by pairing upload and download tasks. The destination node and the k source nodes are arranged in descending order of available download bandwidth. Upload and download tasks are matched to establish data transmission paths between nodes. The constructed repair path is a directed acyclic graph. Since the source nodes are arranged in descending order of available download bandwidth, the available download bandwidth of each node, except the destination node, is greater than the available download bandwidth of all its child nodes. This property is similar to a heap, forming a heap-like repair path.

[0021] S150 performs data repair according to the repair path and monitors the changes in available network bandwidth of each node in real time during the repair process.

[0022] Specifically, following the pre-defined repair path, each node collaboratively performs data block transmission and linear computation to recover the failed blocks. During the repair process, changes in the available network bandwidth of each node are monitored in real time. Nodes calculate their available network bandwidth (the difference between the maximum network bandwidth and the used bandwidth) by monitoring the usage of their own network interface cards (NICs), and report this information to the coordinator periodically. The coordinator uses the available bandwidth information reported by each node to understand the global bandwidth dynamics.

[0023] S160: When a lagging node with a sudden drop in available download bandwidth is detected, the repair path is dynamically adjusted using a heap-like structure. This is achieved by swapping the lagging node with the node with the largest available download bandwidth among its child nodes, and repeating this operation until the lagging node no longer undertakes download tasks, thereby mitigating the impact of the lagging node on repair performance.

[0024] Specifically, during the repair process, if the available download bandwidth of a node suddenly drops (e.g., from 6Mb / s to 1Mb / s), that node will become a bottleneck in the repair process because it cannot handle the originally allocated download tasks; this is referred to as a laggard node. When a laggard node with a sudden drop in available download bandwidth is detected, a heap-like structure is used to dynamically adjust the repair path: the laggard node is swapped with the node among its child nodes that has the largest available download bandwidth, and this operation is repeated until the laggard node no longer undertakes any download tasks, thereby mitigating the impact of the laggard node on repair performance.

[0025] Through the above steps, the present invention can formulate efficient repair paths at low cost based on the heterogeneous network bandwidth in the cloud-edge-device environment, and adjust the repair paths with low overhead when the bandwidth changes dynamically, thereby maintaining high repair efficiency and improving the data reliability and service quality of the cloud-edge-device storage system.

[0026] The technical solution provided by this invention decomposes the repair plan into upload and download tasks and optimizes the allocation based on available download bandwidth to minimize download bottleneck time. It constructs a directed acyclic repair path with a heap-like structure, laying the structural foundation for low-overhead dynamic adjustment. Simultaneously, it monitors bandwidth changes in real time during the repair process. When a lagging node with a sudden drop in available download bandwidth is detected, the heap-like structure is used to repeatedly swap positions with the node's child node with the highest download bandwidth until the lagging node no longer undertakes download tasks. This significantly reduces repair bottleneck time and enables rapid adaptive adjustment of the repair path. Compared to existing technologies that only focus on node selection or strategy switching before reconstruction, this invention can maintain efficient repair in heterogeneous and dynamically fluctuating network environments at the cloud, edge, and endpoint, effectively preventing lagging nodes from dragging down the overall progress, significantly improving repair throughput and system reliability, and providing strong support for the widespread application of erasure coding in cloud-edge-end storage architectures.

[0027] exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, S130, obtaining a task allocation scheme that minimizes download bottleneck time, may specifically include the following steps: Step a1: Sort the k source nodes in descending order of available download bandwidth to obtain the source node sequence.

[0028] First, obtain the available download bandwidth of each of the selected k source nodes. Arrange these k source nodes in descending order of available download bandwidth to obtain an ordered sequence of source nodes. For ease of subsequent description, denote this sequence as N = {N1, N2, …, N}. k}, where N1 has the largest available download bandwidth, N k The node with the minimum available download bandwidth. In addition to the available download bandwidth, each node in the sequence also has known available upload bandwidth (used for uploading tasks) and the number of download tasks currently assigned to it (initially both are 0).

[0029] Step a2: Assign one download task to the destination node and one to the first k-1 nodes in the source node sequence to ensure that all download tasks are assigned to the repair node.

[0030] There are currently k download tasks to be assigned. First, assign the task to the destination node N. d Assign one download task. Then, select the first k-1 nodes (i.e., N1, N2, …, N) from the source node sequence. k-1Each of the k-1 source nodes is assigned one download task. Thus, the destination node and each of the k-1 source nodes each undertakes one download task, and all k download tasks are distributed. The k nodes assigned download tasks (including the destination node and the k-1 source nodes) are called repair nodes. At this point, the last node N in the source node sequence... k It has not been assigned any download tasks yet, and its download task count is 0; while the download task counts of other source nodes are all 1, and the download task count of the destination node is also 1.

[0031] Step a3: Set the input pointer and output pointer, where the input pointer initially points to the first node in the source node sequence; the output pointer initially points to the (k-1)th node in the source node sequence.

[0032] Specifically, two pointers are defined: an incoming pointer and an outgoing pointer. The incoming pointer indicates the source node (or destination node) that may receive additional download tasks, and it initially points to the first node in the source node sequence, i.e., N1. The outgoing pointer indicates the source node that may outgoing download tasks, and it initially points to the (k-1)th node in the source node sequence, i.e., N. k-1 Subsequent iterations will be performed based on these two pointers.

[0033] Iteratively execute the following download task transfer operation steps a4 to a6: Step a4: Move from the current inbound pointer position toward the head of the source node sequence. If the estimated completion time of the download task of the first node encountered is less than that of the node currently pointed to by the pointer, then take that node as the new node pointed to by the inbound pointer; otherwise, the pointer remains unchanged.

[0034] At the beginning of each iteration, the input pointer is corrected. Let the current input pointer point to a node (denoted as N) in the source node sequence. cur From N cur Starting from the position, check each node sequentially towards the head of the source node sequence (i.e., the direction of decreasing index). For each checked node, calculate its current estimated download task completion time (i.e., the number of download tasks allocated to that node multiplied by the data block size and divided by its available download bandwidth). When the first node is encountered, its estimated download task completion time is strictly less than that of the current node N. cur When the download task is scheduled to complete at its estimated time, the pointer will move to that node and stop further checks. If from N... curIf no node meeting the criteria is found up to the head of the sequence (the first node), the pointer remains in its original position. Specifically, when the pointer initially points to the first node of the sequence, since there is no node further ahead, the check is skipped, and the pointer remains stationary. This correction ensures that the pointer always points to a candidate node whose expected completion time is likely to be shorter after accepting an additional download task, preparing for subsequent node selection.

[0035] Step a5: Compare the estimated completion time of the download task after the destination node and the node pointed to by the current inbound pointer take on an additional download task, and select the smaller one as the inbound node.

[0036] Specifically, after the correction of a4, the current inbound pointer may point to a source node (denoted as N). i Now, consider two candidate nodes: the destination node N. d and the source node N pointed to by the current jump pointer i Calculate the estimated completion time of the download task for each of the two nodes after adding one more download task (i.e., increasing the number of download tasks by 1) to their current allocated download task count. Compare these two time values ​​and select the node corresponding to the smaller time value as the actual "incoming node". In other words, if the time after the destination node takes over is less than that of the source node N... i If the time after acceptance is specified, the receiving node becomes the destination node; otherwise, the receiving node becomes N. i .

[0037] Step a6: Compare the estimated completion time of the download task after the receiving node takes on the additional download task with the estimated completion time of the current download task of the sending node. If the former is less than the latter, transfer one download task from the sending node to the receiving node and move the sending pointer one node to the head of the source node sequence. If the receiving node is not the destination node, move the receiving pointer one node to the tail of the source node sequence. Otherwise, terminate the iteration.

[0038] Specifically, let N_target be the node determined in step a5, and let T_target_new be the estimated completion time of its download task after taking on the additional download task. Let T_out_current be the estimated completion time of the current download task of the node currently pointed to by the outgoing pointer (denoted as N_out). Compare T_target_new and T_out_current: If T_target_new < T_out_current, it indicates that after transferring a download task of the outgoing node to the incoming node, the new download bottleneck time (i.e., the maximum value of the expected completion times of download tasks among all nodes) will decrease. Therefore, perform the transfer operation: transfer a download task of the outgoing node N_out to the incoming node N_target, that is, decrement the number of download tasks of N_out by 1 and increment the number of download tasks of N_target by 1. Then, update the pointers: move the outgoing pointer one node towards the head of the source node sequence (i.e., point to the previous node in the sequence, index minus 1); simultaneously, if the incoming node N_target is not the destination node (i.e., it is a source node), move the incoming pointer one node towards the tail of the source node sequence (i.e., point to the next node in the sequence, index plus 1). If the incoming node is the destination node, the incoming pointer remains unchanged. After completing the above operations, enter the next iteration (i.e., return to step a4).

[0039] If T_target_new ≥ T_out_current, it indicates that this transfer cannot reduce the download bottleneck time and may even increase the bottleneck. Therefore, cancel the transfer and terminate the entire iterative process (i.e., break out of the loop).

[0040] Step a7, repeat steps a4 to a6 until the termination condition is met: until the expected completion time of the download task of the incoming node is greater than or equal to the expected completion time of the download task of the outgoing node, or when the incoming pointer coincides with the outgoing pointer, obtain the task allocation scheme that minimizes the download bottleneck time.

[0041] During the iterative process, when T_target_new ≥ T_out_current is encountered in step a6, the iteration terminates. Additionally, if before the start of a certain iteration or after a transfer, the incoming pointer and the outgoing pointer point to the same node (i.e., they coincide), it also means that there are no more download tasks to transfer, and at this time the iteration automatically terminates. When the iteration terminates, the current task allocation scheme on each node obtained is the task allocation scheme with the minimum download bottleneck time.

[0042] Through the above steps a1 to a7, the embodiments of the present invention can, for the selected k source nodes and destination nodes, considering the differences in available download bandwidths of each node, obtain a task allocation scheme that minimizes the download bottleneck time with low computational overhead, laying a foundation for subsequent construction of an efficient repair path.

[0043] The following combines Figure 3 the specific example shown to give an exemplary illustration of the above steps a1 to a7. As Figure 3The diagram illustrates an instance of allocating download tasks among a defined destination and four source nodes. N6 is the failed node, N4 is the destination node, and the remaining nodes are source nodes participating in the repair process. First, ECHeap obtains the available download bandwidth of nodes N1, N2, ..., N5 and sorts the nodes according to their available download bandwidth from largest to smallest. ECHeap then allocates one upload task to each of the four source nodes and one download task to each of the destination node and the three nodes with the largest available download bandwidth. At this point, all four upload and download tasks have been allocated, as shown in the first round of the diagram. The first round of download task transfer then begins. The transfer-in pointer points to source node N2, and the transfer-out pointer points to source node N3. Next, the estimated completion time of the download task after a download task is transferred from the destination node N4 to the node N2 (where the transfer-in pointer points) is compared. and At this point, both the destination node N4 and the source node N2 have been assigned one download task. Therefore, if a download task needs to be transferred, it should be transferred to the destination node N4 (i.e., the receiving node is the destination node N4). Then, compare the estimated completion time of the download task after it has been transferred to the receiving node N4. And the estimated completion time of the download task at the originating node at this time. At this point, both the destination node N4 and the node N3 pointed to by the incoming pointer have been assigned one download task. Transferring the download task from node N3 to the destination node N4 can reduce download bottleneck time. Therefore, the download task D4, which was initially pointed to by the outgoing pointer at node N3, is transferred to the destination node N4, and the incoming pointer is moved one node towards the head of the queue. For the second round of download task transfer, the incoming pointer still points to the source node N2, and the outgoing pointer points to the source node N3, similar to the first round. ECHeap compares the estimated completion time of the download task after transferring a download task to the destination node N4 with the estimated completion time of the download task after transferring a download task to node N2 (which was initially pointed to by the incoming pointer). and At this point, the destination node N4 has been assigned 2 download tasks, while the node N2 pointed to by the incoming pointer has been assigned 1 download task. If the source node N2 becomes the receiving node, then the estimated completion time of the download task after receiving node N2 receives a download task is compared. The estimated completion time of the download task at the outgoing node N5 at this time. At this point, both the incoming node N2 and the outgoing node N5 are assigned one download task. Therefore, the download task of the source node N5 is transferred to node N2, and the transfer pointer is moved one node to the end of the queue. At this time, the transfer pointer and the transfer pointer coincide, and the download task transfer ends. The task allocation scheme at this time has the minimum download bottleneck time.

[0044] exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, S140, constructing the repair path may specifically include the following steps: Step b1: Record the destination node as the first node of the sequence, sort the k source nodes in descending order of available download bandwidth, and then arrange them sequentially after the destination node to form a node sequence.

[0045] Specifically, let the selected k source nodes be N1, N2, …, N k The destination node is N d First, rearrange the k source nodes in descending order of their available download bandwidth to obtain an ordered sequence of source nodes (e.g., the node with the largest available download bandwidth is placed first). Then, construct a node sequence N′ of length k+1, and then... d As the first node of the sequence, the k sorted source nodes are then arranged sequentially in N. d Then, that is, N′ = {N d , N1, N2,…, N k}. Where N1, N2, …, N k The available download bandwidth decreases sequentially.

[0046] Step b2: Initialize the input pointer to point to the position after the destination node in the node sequence.

[0047] Define an input pointer (denoted as Inputpoint) to indicate the node where the currently available upload tasks reside. Initially, set Inputpoint to point to the destination node N in the node sequence N′. d The next position points to the first source node N1. During subsequent matching, the Inputpoint gradually moves towards the end of the sequence.

[0048] Step b3: Starting from the destination node, traverse the node sequence. For the currently traversed node, if the number of download tasks to be matched is greater than 0, repeat the following operation.

[0049] Specifically, begin traversing the node sequence N′. The traversal order starts from the first node in the sequence (i.e., the destination node N). d Starting from the end of the sequence (i.e., N1, N2, …, N), proceed sequentially towards the end of the sequence (i.e., N1, N2, …, N). kThe process proceeds as follows: For the currently traversed node (denoted as node i), check the number of remaining unmatched download tasks (i.e., the number of download tasks assigned to this node in the task allocation scheme of step S130 but not yet matched). If the number is greater than 0, execute steps b4 and b5; if it is equal to 0, skip directly and continue traversing the next node.

[0050] Step b4: Establish a data transmission path from the node currently pointed to by the input pointer to the currently traversed node.

[0051] When node i has a download task to be matched, it retrieves the node currently pointed to by the input pointer (denoted as node p). A data transmission path is established from node p to node i, meaning that node p sends a data block stored locally (or obtained after linear computation) to node i for download. This pairing relationship binds an upload task of node p to a download task of node i.

[0052] Step b5: Decrement the number of download tasks to be matched for the currently traversed node by 1, and point the input pointer to the next node in the node sequence.

[0053] Specifically, after establishing a data transmission path, the number of download tasks to be matched for the currently traversed node i decreases by 1 (because a download task has already been matched). Simultaneously, the input pointer Inputpoint moves one position towards the end of the node sequence, pointing to the next node (i.e., Inputpoint = Inputpoint + 1). Thus, the next time an upload task needs to be matched, the node pointed to by the new Inputpoint will be used.

[0054] Step b6: Continue traversing the next node in the node sequence until the number of download tasks to be matched for all nodes is 0, thus obtaining a directed acyclic repair path.

[0055] After completing the matching of the current download task for node i, if the number of download tasks to be matched for node i is still greater than 0, continue repeating steps b4 and b5 until all download tasks for node i are matched. Then, the traversal process moves to the next node in the node sequence (i.e., i+1) and repeats steps b3 to b5. When all nodes (from N) d To N kWhen the number of pending download tasks becomes 0, all upload and download tasks have been successfully paired. The several data transmission paths established at this point constitute a complete repair path. Since the input pointer is always after the currently traversed node, all transmission directions are from the later node to the earlier node in the sequence, making it impossible to form a loop. Therefore, this repair path is a directed acyclic graph. Furthermore, since the source nodes are arranged in descending order of available download bandwidth, and the available download bandwidth of each node is greater than that of its child nodes (i.e., its downstream nodes), this repair path has a heap-like structure.

[0056] Through the above steps b1 to b6, the embodiments of the present invention can quickly construct a feasible, directed acyclic, heap-like repair path with linear time complexity O(k) according to the task allocation scheme, providing a clear transmission topology for subsequent data repair execution and dynamic adjustment.

[0057] like Figure 4 As shown, assume that the nodes involved in the repair include the destination node N. d There are four source nodes N1, N2, N3, and N4, whose available download bandwidth is sorted from largest to smallest as N1, N2, N3, and N4. According to the task allocation scheme in step S130, the number of upload tasks and download tasks for each node are allocated as follows: Destination node N d The number of download tasks is 2 (the number of upload tasks is 0). Source node N1 has 2 download tasks and 1 upload task. Source nodes N2, N3, and N4 all have 0 download tasks and 1 upload task each. Following step b1, the destination node N... d As the first node of the sequence, the sorted source nodes are arranged sequentially after it to form the node sequence {N}. d , N1, N2, N3, N4}. Following step b2, initialize the input pointer (represented by a hollow arrow in the diagram) to point to the destination node N. d The next position points to the source node N1. Then, from the destination node N... d Begin traversing the node sequence (step b3). Since N... d The number of download tasks to be matched is 2 (greater than 0), proceed to step b4: move from the node currently pointed to by the input pointer (i.e., N1) to N d Establish a data transmission path (steps shown in the diagram) This indicates that N1 uploads its data block to N. d Subsequently, step b5 will N d The number of download tasks to be matched is decremented by 1 (becoming 1), and the input pointer is moved to the next node in the sequence (i.e., N2). At this point, N d The number of download tasks is still greater than 0, so repeat step b4: from the node currently pointed to by the input pointer (i.e., N2) to N dEstablish a data transmission path (steps) ), and then N d The number of download tasks to be matched is decremented by 1 (becoming 0), and the input pointer is moved to the next node (i.e., N3). At this point, N... d After all download tasks have been matched, the traversal process continues to the next node N1. The current traversed node is N1, and its number of download tasks to be matched is 2 (greater than 0). At this time, the input pointer points to N3, and step b4 is executed: establish a data transmission path from N3 to N1 (step b4). Then, decrement the number of download tasks to be matched in N1 (making it 1), and point the input pointer to N4. Since the number of download tasks in N1 is still greater than 0, execute step b4 again: establish a data transmission path from N4 to N1 (step b4). Then, decrement the number of download tasks to be matched in N1 by 1 (making it 0), and move the input pointer to the end of the sequence (no more nodes). At this point, the number of download tasks to be matched for all nodes is 0, and the traversal ends. The final result is as follows: Figure 4 The repair path shown is a directed acyclic graph and satisfies a heap-like structure: except for the root node N d In addition, the available download bandwidth of each node is greater than that of its child nodes (for example, the available download bandwidth of N1 is greater than that of its child nodes N3 and N4). This example visually illustrates the process of building from a task allocation scheme to the actual repair path.

[0058] exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, before obtaining the k source nodes in the stripe containing the failed block to be repaired, a replacement-based node selection strategy is further included to select the set of source nodes with the shortest repair bottleneck time. This strategy achieves a balance between upload bottleneck time and download bottleneck time by dynamically adjusting the set of source nodes participating in the repair, ultimately selecting the set of nodes with the shortest repair bottleneck time. Specifically, the steps include the following: Step c1: Sort the candidate source nodes in descending order of their available upload bandwidth to obtain the candidate source node set S = {N1, N2, …, N}. n-1}, where n is the total number of nodes in the strip where the failed block is located.

[0059] Suppose there are n nodes in the stripe containing the failed block to be repaired, where the node containing the failed block is faulty, and the remaining n-1 nodes all store surviving blocks. These nodes constitute a set of candidate source nodes. These candidate source nodes are sorted in descending order of their available upload bandwidth, resulting in an ordered set S. That is, N1 has the largest available upload bandwidth, and N... n-1 The available upload bandwidth is the lowest.

[0060] Step c2, initialize the source node set R as the first k nodes sorted in S, i.e., R = {N1, N2, …, N k}, and calculate the upload bottleneck time Bottle_up corresponding to R = 1 / (the minimum value of the available upload bandwidths of all nodes in R), as well as the download bottleneck time Bottle_down, and the repair bottleneck time Bottle_all = max(Bottle_up, Bottle_down).

[0061] First, select the first k nodes in S as the initial source node set R. Since each source node participating in the repair needs to upload a data block, the upload bottleneck time depends on the node with the minimum available upload bandwidth in R, i.e., Bottle_up = 1 / min{B_up(N) | N ∈ R} (the data block size is a fixed value, and normalization is performed here). The download bottleneck time is calculated by calling the method in the aforementioned step S130, denoted as Bottle_down. The repair bottleneck time is the larger value between the upload bottleneck time and the download bottleneck time.

[0062] Step c3, if Bottle_up ≥ Bottle_down, then output R as the finally selected source node set.

[0063] If the upload bottleneck time is already greater than or equal to the download bottleneck time, it means that the repair bottleneck of the current set is determined by the upload side. At this time, further replacing the source node will only reduce the minimum upload bandwidth and make the upload bottleneck time larger. Therefore, there is no need to continue replacing, and directly output the current R as the optimal set.

[0064] Step c4, if Bottle_up < Bottle_down, then perform the following iterative replacement operation.

[0065] If the download bottleneck time is greater than the upload bottleneck time, it means that the current repair bottleneck is determined by the download side. It can be considered to reduce the download bottleneck time by replacing the source node. Even if it may slightly increase the upload bottleneck time, it may also reduce the overall repair bottleneck time.

[0066] Step c5, set the pointer End = k.

[0067] End is used to indicate the serial number of the candidate source node currently being examined in S. Initially, End points to the k-th node in S (i.e., the node with the largest serial number in the current R).

[0068] Step c6, loop and execute the following steps: increment End by 1; if End > n - 1, then jump out of the loop; obtain the candidate source node N End , and replace the node with the minimum available download bandwidth in R with NEnd ;; Calculate the upload bottleneck time Bottle_up' of the replaced R = 1 / (the minimum value of the available upload bandwidths of all nodes in R), and the download bottleneck time Bottle_down', and the repair bottleneck time Bottle_all' = max(Bottle_up', Bottle_down'); if Bottle_all' < Bottle_all, then retain the current R and update Bottle_all = Bottle_all'; otherwise, roll back the replacement; if Bottle_up' ≥ Bottle_down', then break out of the loop; otherwise, continue to the next iteration.

[0069] Specifically, (1) Increase End by 1 (i.e., End = End + 1). If End > n - 1 at this time, there are no more candidate nodes, and break out of the loop. (2) Obtain the candidate source node N End (i.e., the next unused node in S). (3) Replace the node with the minimum available download bandwidth in the current set R with N End , to obtain a temporary set R' (in actual implementation, it can be directly replaced on R and recorded, and if the effect is not good, roll back). (4) Calculate the upload bottleneck time Bottle_up' of the replaced R = 1 / (the minimum value of the available upload bandwidths of all nodes in R), and the download bottleneck time Bottle_down' (also call the method in step S130), and the repair bottleneck time Bottle_all' = max(Bottle_up', Bottle_down'). (5) If Bottle_all' < Bottle_all, it means that this replacement has reduced the repair bottleneck time, so retain this replacement (i.e., the updated R as the current optimal set), and set Bottle_all = Bottle_all'; otherwise, roll back the replacement and restore R to the set before replacement. (6) If Bottle_up' ≥ Bottle_down', it means that the upload bottleneck time has become the new main bottleneck, and continuing the replacement cannot improve the repair bottleneck time, so break out of the loop; otherwise, continue to the next iteration, that is, return to step (1).

[0070] Step c7, output the finally obtained R as the selected source node set.

[0071] After the loop ends, the current R is the source node set with the minimum repair bottleneck time obtained after dynamic replacement optimization. Use this set for subsequent repair task allocation and path construction.

[0072] Through steps c1 to c7 above, this embodiment of the invention can automatically find the optimal balance point between upload and download bottlenecks based on the available upload and download bandwidth of candidate source nodes, thereby selecting the set of source nodes that minimizes the overall bottleneck repair time and further improving repair efficiency. This strategy is particularly suitable for scenarios with strong node bandwidth heterogeneity in cloud-edge-device environments, and can effectively avoid the problem of the upload side becoming a new bottleneck due to the pursuit of high download bandwidth.

[0073] like Figure 5 The diagram illustrates a node selection strategy based on replacement. It is a... RS (9 , 6) An example of an erasure coding-based replacement-based node selection strategy. The table shows the available network bandwidth (including available upload bandwidth) of the selected destination node and the set of candidate source nodes. Available download bandwidth The candidate source node set S = {N1, N2, ..., N8} is sorted according to available upload bandwidth. First, nodes N1, N2, ..., N6 are selected as set R, and compared with the destination node N. d Together, we construct a repair path with the minimum download bottleneck time (Bottle_down), at which point the upload bottleneck time (Bottle_up) is... The download bottleneck time is Bottle_down. The time to fix the bottleneck is Bottle_all. Since the upload bottleneck time is less than the download bottleneck time, we consider using a set. S The next candidate source node N7 replaces the node with the minimum idle download bandwidth (i.e., node N1) in set R, and the new set is named R′. Similarly, the upload bottleneck time Bottle_now_up is obtained as follows: The download bottleneck time, Bottle_now_down, is... The bottleneck repair time is Bottle_now_all. Due to the set R′ To achieve a shorter bottleneck repair time, set R' is used to replace set R. Since the upload bottleneck time is now equal to the download bottleneck time (i.e., Bottle_now_up = Bottle_now_down), the node replacement ends. The set at this point... R This refers to the set of candidate source nodes that can achieve the minimum bottleneck repair time.

[0074] exist Figure 1Based on the illustrated embodiment, as one implementation of this invention, the real-time monitoring of changes in available network bandwidth of each node may specifically include the following steps: Step d1: Deploy an agent on each node and periodically collect the uplink and downlink bandwidth usage of that node through the network interface provided by the operating system.

[0075] Deploy an ECHeap agent on each participating node (including the source and destination nodes). The agent periodically collects the upstream and downstream bandwidth usage of each node through the network interface provided by the operating system (such as the nethogs tool or the / proc / net / dev file in Linux). The collection interval can be configured according to system load and network fluctuations; for example, the default setting is 1 second.

[0076] Step d2: The difference between the node's maximum network bandwidth and the used upload bandwidth is taken as the node's available upload bandwidth, and the difference between the maximum network bandwidth and the used download bandwidth is taken as the node's available download bandwidth.

[0077] Let the network bandwidth limit of a node be B_max (i.e., the maximum transmission capacity of the node's network interface), the currently used upload bandwidth be B_used_up, and the used download bandwidth be B_used_down. Then the available upload bandwidth of this node is B_avail_up = B_max - B_used_up, and the available download bandwidth is B_avail_down = B_max - B_used_down. The agent calculates the current available upload and download bandwidth based on the real-time collected used bandwidth data.

[0078] In step d3, each node reports its available upload bandwidth and available download bandwidth to the coordinator at preset time intervals, which are dynamically adjusted according to the degree of network fluctuation.

[0079] At preset time intervals (e.g., 1 second), the agents on each node report the calculated available upload and download bandwidth to the coordinator. To strike a balance between monitoring sensitivity and false alarm overhead, this time interval can be dynamically adjusted based on network fluctuations: when network fluctuations are severe, the reporting interval is shortened to improve sensitivity; when the network is relatively stable, the reporting interval is appropriately increased to reduce communication overhead. Furthermore, nodes can also choose the average available bandwidth over the reporting time interval to smooth out instantaneous fluctuations.

[0080] Step d4: The coordinator receives and records the available bandwidth information reported by each node.

[0081] The coordinator, acting as the central management entity, receives available bandwidth data reported by each node agent and records this data by node and timestamp to form a global bandwidth information view. Based on this real-time data, the coordinator can determine the current network load status of each node, providing a basis for constructing and dynamically adjusting repair paths.

[0082] Step d5: Based on the real-time available bandwidth values ​​reported by each node, the coordinator uses a recursive-based available network bandwidth prediction scheme to predict the available upload and download bandwidth of each node at the current moment. The prediction formula is as follows:

[0083] in, Bt The predicted available bandwidth at the current moment. Bt- 1 represents the predicted available bandwidth at the previous time step. Bnow This refers to the real-time available bandwidth reported by the node at the current moment. α This is the influence coefficient of the network bandwidth at the previous time step, with a value range of [0,1]. α The smaller the value, the higher the prediction sensitivity.

[0084] To further improve the smoothness and jitter resistance of monitoring, the coordinator can employ a recursive prediction model to estimate the available bandwidth of each node. Specifically, for each node, the coordinator maintains the predicted available bandwidth from the previous time step. Bt- 1. When the real-time available bandwidth reported by the node at the current moment is received... Bnow Then, the predicted available bandwidth at the current moment is calculated according to the above recursive formula. Bt .when α When the value is large, the prediction results rely more on historical values ​​and respond more slowly to instantaneous fluctuations, exhibiting lower sensitivity; when... α When the values ​​are small, the prediction results rely more on real-time reported values, resulting in higher sensitivity. The coordinator can be dynamically adjusted according to the actual needs of the scenario. α The value of , for example, in cloud-edge-device scenarios where the network environment changes frequently, should be chosen to be smaller. α (e.g., 0.2~0.4) to achieve rapid response. Through this prediction scheme, the coordinator can obtain a smoother and more timely estimate of the available bandwidth of nodes, thereby avoiding unnecessary repair path adjustments triggered by brief bandwidth fluctuations.

[0085] Through steps d1 to d5 above, this embodiment of the invention achieves real-time and accurate monitoring of the available network bandwidth of each node at the cloud edge, providing a reliable data foundation for dynamic adjustment of the subsequent repair path. It should be noted that the recursive prediction scheme described in step d5 is an optional refined monitoring method. In actual implementation, only the direct reporting method of steps d1 to d4 can be used, depending on the system's requirements for monitoring sensitivity and overhead.

[0086] Based on the above embodiments, as one implementation of the present invention, the repair path is dynamically adjusted using a heap-like structure, specifically including: Step e1: When a sudden drop in available download bandwidth is detected in any node, that node is marked as a lagging node.

[0087] During the repair process, the coordinator uses the aforementioned monitoring mechanism to obtain the available download bandwidth of each node in real time. When it detects a sudden drop in the available download bandwidth of a node (e.g., node N4) (e.g., from 6Mb / s to 1Mb / s), causing a significant increase in the estimated completion time of its download tasks and potentially becoming a bottleneck in the repair process, that node is marked as a "lagging" node. This marking is used to trigger the subsequent repair path adjustment process.

[0088] Step e2: Obtain all child nodes of the lagging node in the current repair path.

[0089] Because the repair path has a heap-like structure (each node's available download bandwidth is greater than that of all its child nodes), each node (except leaf nodes) may have one or more child nodes. The coordinator, based on the current repair path topology, identifies all direct child nodes of the lagging node within the current repair path—those nodes that need to receive data blocks from the lagging node.

[0090] In step e3, if the lagging node has no child nodes, the adjustment ends. Otherwise, select the child node with the largest available download bandwidth from all child nodes.

[0091] If a lagging node has no child nodes (i.e., it has become a leaf node), it means it no longer undertakes any download tasks and will not affect the repair efficiency, so no adjustment is needed and the process ends directly. If child nodes exist, these child nodes are traversed, their current available download bandwidth is compared, and the child node with the largest available download bandwidth is selected.

[0092] Step e4: Swap the positions of the lagging node and the child node with the largest available download bandwidth in the repair path, so that the lagging node becomes the child node and the child node with the largest available download bandwidth becomes the parent node.

[0093] Specifically, the swap operation involves exchanging the roles of the lagging node and its selected maximum bandwidth child node in the repair path. That is, the original lagging node becomes a child node, and the original maximum bandwidth child node becomes a parent node. Simultaneously, the parent-child relationships are adjusted accordingly—the other child nodes of the original lagging node become children of the new parent node, and the atomic nodes of the original maximum bandwidth child node (excluding the lagging node) become children of the lagging node. This operation is similar to the "sinking" or "filtering" process in a heap data structure.

[0094] Step e5: Re-determine all child nodes of the lagging node in the current repair path, and repeat the operation of selecting the child node with the largest available download bandwidth and swapping positions until the lagging node has no child nodes.

[0095] After a swap, the lagging node may still have child nodes (e.g., after the swap, N4 may still have child nodes N5 and N3). Therefore, it is necessary to reacquire all the child nodes of the lagging node in the new repair path and repeat steps e3 and e4: again select the child node with the largest available download bandwidth and swap their positions again. This process is repeated until the lagging node no longer has any child nodes (i.e., it becomes a leaf node). Ultimately, the lagging node sinks to the bottom of the repair path and no longer undertakes any download tasks, thus eliminating its impact on the overall repair efficiency.

[0096] Through the above steps e1 to e5, the embodiments of the present invention can respond quickly to sudden drops in node bandwidth with low overhead (each adjustment only affects the path chain from the laggard to the leaf node, with a complexity of O(log k)), dynamically adjust the repair path, effectively alleviate the problem of decreased repair performance caused by the laggard, and continuously maintain a high repair throughput.

[0097] like Figure 6 The image shows a complete example of this dynamic adjustment process. Figure 6 The image shows the destination node Nd and source nodes N1, N2, N3, N4, N5, and N6. The initial available download bandwidth for each node is as follows: N1 = 1 Mb / s, N2 = 5 Mb / s, N3 = 1 Mb / s, N4 = 6 Mb / s, N5 = 2 Mb / s, and N6 = 4 Mb / s. In the initial repair path, node N4 undertakes a large number of download tasks, and its child nodes include N2 and N6.

[0098] During the repair process, the coordinator detected a sharp drop in the available download bandwidth of node N4 from 6 Mb / s to 1 Mb / s. At this point, N4 became a lagging node, and the estimated completion time for its download tasks increased significantly, causing the repair bottleneck time to increase from 1 / 3 to 2. To eliminate this impact, a dynamic adjustment process was triggered.

[0099] First, obtain all child nodes of the lagging node N4, namely N2 (available download bandwidth 5Mb / s) and N6 (available download bandwidth 4Mb / s). Select the child node with the largest available download bandwidth, namely N2. Swap the positions of N4 and N2 in the repair path: after the swap, N2 becomes the parent node, N4 becomes a child node of N2, and N2's original child nodes N5 and N3 become children nodes of N4. After the first swap, N4 still has child nodes (N5 and N3) and has not yet become a leaf node.

[0100] Continue adjusting: Reacquire the current child nodes of N4, namely N5 (available download bandwidth 2Mb / s) and N3 (available download bandwidth 1Mb / s). Select the child node with the largest available download bandwidth, namely N5. Swap the positions of N4 and N5 again: After the swap, N5 becomes the parent node, and N4 becomes a child node of N5. At this point, N4 no longer has any child nodes, becomes a leaf node, and no longer undertakes download tasks.

[0101] After the two swaps described above, the repair path adjustment is complete. The adjusted repair path is as follows: Figure 6 As shown, the bottleneck repair time is reduced from 2 to 1 (i.e., 1 / 1), and the repair efficiency is doubled. The entire adjustment process only involves nodes (N4, N2, N5) on the path from the lagging node N4 to its leaf node. The repair paths of other nodes (such as N1, N3, N6) remain unchanged. The algorithm complexity of the adjustment is O(log k), with extremely low overhead.

[0102] This example visually demonstrates the dynamic adjustment process by which a node's repair efficiency is quickly restored when its bandwidth suddenly drops. This is achieved by repeatedly swapping positions with the child node with the highest bandwidth using a heap-like structure, thus pushing the lagging node down to a leaf node.

[0103] exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, data repair is performed according to the repair path, which may specifically include the following steps: In step f1, the coordinator sends the constructed repair path to each participating node agent in the form of a message.

[0104] After constructing the repair path, the coordinator encapsulates the repair path information, which includes the data transmission relationships between nodes (e.g., which target nodes each node needs to send data to and which source nodes it needs to receive data from), into a message and sends it to the agents running on all participating nodes (including source and destination nodes). Upon receiving the message, each agent can then know its role and responsibilities in this repair task.

[0105] In step f2, each source node determines the number of upload tasks, the number of download tasks, and the target node for data block transmission based on the repair path.

[0106] The agent on each source node parses the received repair path message and extracts the upload tasks (i.e., which downstream nodes need to be sent local data blocks) and download tasks (i.e., which upstream nodes need to be received data blocks) that it needs to perform. Simultaneously, the agent also specifies the target node address for each data block transmission and whether it needs to receive data from other nodes for local linear combination.

[0107] In step f3, each source node reads the surviving data blocks from its local storage and sends the data blocks to the corresponding nodes via a pipeline according to the target node address indicated by the repair path.

[0108] Each source node reads its surviving data blocks (or generated intermediate data blocks) from local storage according to the upload tasks specified in the repair path. To improve transmission efficiency, nodes use a pipelined approach to send data blocks in fragments: a data block is divided into multiple equal-sized data slices, and multi-threading technology is used to overlap the reading, transmission, and writing processes of the slices, thereby hiding the latency of disk I / O and network transmission. Data blocks are then sent sequentially to the corresponding downstream nodes according to the target node addresses indicated by the repair path.

[0109] Step f4: When a source node undertakes download tasks simultaneously, the node receives data blocks from other nodes, performs linear combination calculations with the local surviving data blocks to generate intermediate data blocks, and then uploads the intermediate data blocks to the next node according to the repair path.

[0110] In the repair path, some source nodes not only need to upload their own local data blocks but also receive data blocks from other nodes. Upon receiving a data block from an upstream node, these nodes utilize the linear additivity of erasure coding to linearly combine the received data block with locally stored surviving data blocks (e.g., XOR operation or addition over a finite field), generating an intermediate data block of the same size as the original data block. This intermediate data block contains aggregated information from multiple data blocks, and its upload task only needs to transmit this single block to satisfy the needs of downstream nodes. Then, the node uploads it to the designated next node according to the repair path.

[0111] In step f5, the destination node receives data blocks from each source node, performs the final linear combination operation, recovers the failed data blocks, and writes the recovered data blocks to local storage.

[0112] The destination node, acting as the root node of the repair path, is responsible for collecting all data blocks uploaded by the source nodes (or after processing by intermediate nodes). Once it receives a sufficient number of data blocks (typically k), the destination node performs the final linear combination operation (i.e., erasure coding decoding) to recover the original failed data block. After recovery, the destination node writes the repaired data block to its local storage and reports the repair completion to the coordinator. This concludes the data repair process for the failed block.

[0113] Through the above steps f1 to f5, the embodiments of the present invention achieve efficient execution of the repair path. By utilizing pipeline technology and linear combination calculation, the amount of data transmission and computational overhead are minimized, thereby improving the overall repair efficiency.

[0114] exist Figure 1 Based on the illustrated embodiment, as one implementation of the present invention, before constructing the repair path, a step of selecting the destination node is further included, which may specifically include the following steps: Step g1: Obtain a set of candidate destination nodes. Each node in the candidate destination node set does not store any blocks in the stripe containing the failed block to be repaired before the repair.

[0115] Given a failed block C′ to be repaired, the first step is to determine a suitable destination node to store the repaired data block. To ensure that the repaired stripe can still tolerate failures of any nk nodes, the selected destination node must satisfy the following condition: before repair, the node did not store any data block or parity block of the stripe containing C′. Therefore, the system selects nodes that meet this condition from all surviving nodes, forming a candidate destination node set D.

[0116] Step g2: Obtain the available download bandwidth for each node in the candidate destination node set.

[0117] For each node N in the candidate destination node set D i This allows you to obtain the node's current available download bandwidth. This bandwidth information can be obtained through periodic reporting by the node or through system presets, such as by monitoring network card usage through an agent on the node and calculating the difference between the network bandwidth limit and the used download bandwidth.

[0118] Step g3: Select the node with the largest available download bandwidth from the set of candidate destination nodes as the destination node.

[0119] In the repair task of a single failed block C′, the destination node only needs to undertake the download task (i.e., receive data blocks from each source node) and does not need to perform any upload operation. Therefore, the available download bandwidth of the destination node directly determines its data reception rate and is a key factor affecting repair efficiency. To maximize repair throughput, this embodiment selects the node with the largest available download bandwidth in the candidate destination node set D as the destination node. If multiple nodes have the same maximum available download bandwidth, one can be selected at will or further optimized based on other auxiliary conditions (such as node load, geographical location, etc.).

[0120] Through the above steps g1 to g3, this embodiment of the invention can select a destination node with sufficient download bandwidth and meeting fault tolerance requirements for the failed block, laying the foundation for subsequent repair task allocation and path construction.

[0121] exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, the method further includes the step of integrating the method into the Hadoop Distributed File System (HDFS), which may specifically include the following steps: Step h1: Deploy the coordinator on the HDFS NameNode and the agent on the HDFS DataNode.

[0122] In the HDFS architecture, the NameNode is responsible for managing the file system's metadata, while the DataNodes are responsible for actually storing the data blocks. This embodiment deploys the ECHeap coordinator component on the NameNode to leverage its global metadata management capabilities; simultaneously, the ECHeap proxy component is deployed on each DataNode to perform tasks such as reading, transferring, linearly combining, and monitoring bandwidth of data blocks.

[0123] Step h2: When any DataNode fails to send a heartbeat for an extended period of time, the NameNode identifies the DataNode as a faulty node, and the coordinator takes over the repair work, generating a repair plan for the failed blocks on the faulty DataNode.

[0124] HDFS's original heartbeat mechanism is used to detect the liveness status of DataNodes. When a DataNode fails to send a heartbeat to the NameNode for more than a preset time (e.g., the default 10 minutes), the NameNode marks it as a "dead" node, i.e., determines it as a failed node. At this time, the ECHeap coordinator deployed on the NameNode takes over the repair work. Based on the data block information stored on the failed node, it queries the metadata of its stripe (including the location of surviving blocks in the stripe) and generates a repair plan for each failed block on the failed node according to the node selection strategy, task allocation scheme, and repair path construction method described above in this invention.

[0125] In step h3, the coordinator distributes the generated repair plan to each DataNode participating in the repair.

[0126] The coordinator sends the generated repair plan (including the upload and download tasks to be undertaken by each DataNode, the data transmission target node, etc.) to each DataNode participating in the repair in the form of a message. After receiving the repair plan, the ECHeap agent on each DataNode can understand its role and operation in this repair.

[0127] In step h4, each DataNode executes a repair task to complete the data block transmission and reconstruction.

[0128] According to the received repair plan, the ECHeap agent on each DataNode performs data repair according to the repair path described above in this invention: read the surviving data blocks from local storage and send them to the target node in a pipeline manner; at the same time, the node that needs to undertake the download task receives the data blocks sent by other nodes, performs linear combination to generate intermediate data blocks and continues to upload; finally, the destination DataNode (i.e. the node that stores the repaired data blocks) completes the final linear combination operation, recovers the failed data blocks, and writes them to local storage.

[0129] Step h5: After the reconstruction is completed, the DataNode storing the repaired data block reports the new data block location to the NameNode via heartbeat, and the NameNode updates the metadata.

[0130] After the failed block is repaired, the DataNode storing the repaired data block reports the location information of its newly stored data block to the NameNode in its next heartbeat. Upon receiving this information, the NameNode updates its metadata, replacing the original location of the failed block with the new location, thus completing the entire repair process. Afterward, the system can access the data block normally, and the striping's fault tolerance capability is restored.

[0131] Through the above steps h1 to h5, this embodiment of the invention achieves seamless integration of the ECHeap solution into Hadoop HDFS, which can fully utilize HDFS’s heartbeat mechanism and metadata management capabilities to improve erasure coding repair efficiency in a low-intrusive manner, and provide a more efficient and robust data fault tolerance mechanism for HDFS clusters in cloud-edge-device environments.

[0132] The following is combined Figure 7 The system architecture and workflow of ECHeap are explained.

[0133] like Figure 7 As shown, the ECHeap system includes a coordinator running on a metadata server and multiple agents deployed across nodes. The coordinator is responsible for managing erasure coding metadata (such as the mapping from blocks to stripes, and the node distribution of data blocks and checksum blocks in storage stripes) and quickly generating repair paths based on reported available network bandwidth. Agents are responsible for accessing the underlying storage, delivering the data blocks required for repair, monitoring network bandwidth, and reporting it.

[0134] The specific workflow is as follows: 1. When a read or repair request for a failed block is received, the coordinator locates the stripe where the failed block is located, obtains the placement of surviving blocks in the stripe and the available network bandwidth of each node, establishes a repair plan and sends it to the relevant agent (step 1).

[0135] 2. After receiving the repair plan, each agent understands its assigned repair task, reads the requested data block from the underlying storage, and sends it to other agents in collaboration with the repair path (step 2).

[0136] 3. During the repair process, each agent uses tools (such as nethogs) to periodically monitor bandwidth usage and report the available bandwidth for repair to the coordinator. When the coordinator detects a lagging agent in the repair path, it sends a repair path adjustment request to the relevant agent (step 3).

[0137] 4. After the repair is completed, the agent of the destination node confirms to the coordinator that the failed block has been repaired (step 4).

[0138] This architecture is compatible with the aforementioned HDFS integration scheme (steps h1 to h5): In HDFS, the coordinator is deployed on the NameNode, the agent is deployed on the DataNode, the heartbeat mechanism is used to detect node failures and report data block locations, while bandwidth monitoring and path adjustment are performed according to... Figure 7 The process is carried out accordingly.

[0139] exist Figure 1Based on the illustrated embodiment, as an implementation of this invention, in the process of sinking the lagging node to the position of the leaf node that no longer undertakes the download task, the algorithm complexity of the repair path adjustment is O(logk), where k is the number of source nodes participating in the repair; and the repair path adjustment only affects the nodes on the path chain from the lagging node to the leaf node of its own child tree, while the repair paths of other nodes remain unchanged.

[0140] Specifically, since the repair path has a heap-like structure (the available download bandwidth of each node except the root node is greater than that of its child nodes), the adjustment operation when a lagging node appears is similar to the sinking (down-filtering) process of nodes in a heap. Let the number of source nodes participating in the repair be k, then the depth of the repair path is O(log k).

[0141] Each adjustment operation involves at most nodes on the path chain from the lagging node to the leaf node of its own child tree, with one comparison and swap per level, resulting in an algorithm complexity of O(log k). Furthermore, the adjustment only affects nodes on that path chain (e.g., the lagging node and its ancestor or descendant chains), while the repair paths for other nodes outside that chain remain unchanged. This means that dynamic adjustment has minimal overhead, enabling rapid response to changes in network bandwidth and avoiding excessive consumption of system resources due to the adjustment process itself.

[0142] Furthermore, this invention also designed and implemented a series of versatility and sensitivity experiments to comprehensively evaluate the repair performance of ECHeap under different load types, erasure coding parameters, network environments, and configurations. Experimental results show that ECHeap can maintain higher repair throughput under various complex conditions, demonstrating good versatility and adaptability, providing strong support for verifying its practical value in cloud-edge-device scenarios.

Claims

1. An efficient repair method for erasure coding storage systems in ubiquitous scenarios, characterized in that, include: Select k source nodes and one destination node in the stripe containing the failed block to be repaired, and obtain the available upload bandwidth and available download bandwidth of each source node, as well as the available download bandwidth of the destination node; where k is the number of source nodes required to repair the failed block; The repair plan for the failed block is decomposed into k upload tasks and k download tasks. Each source node is assigned an upload task, and each upload task is used to upload a data block. Based on the available download bandwidth of each node, the k download tasks are allocated to obtain a task allocation scheme that minimizes the download bottleneck time, where the download bottleneck time is the maximum value of the expected completion time of the download tasks among all nodes participating in the repair. According to the task allocation scheme, upload tasks and download tasks are paired to construct a repair path. The repair path is a directed acyclic graph and satisfies the following conditions: except for the destination node, each source node is arranged in descending order of available download bandwidth, and the available download bandwidth of each node is greater than the available download bandwidth of all its child nodes, forming a heap-like structure. Perform data repair according to the repair path, and monitor the changes in available network bandwidth of each node in real time during the repair process; When a lagging node with a sudden drop in available download bandwidth is detected, the repair path is dynamically adjusted using the heap-like structure. This is achieved by swapping the lagging node with the node among its child nodes that has the largest available download bandwidth, and repeating this operation until the lagging node no longer undertakes download tasks, thereby mitigating the impact of lagging nodes on repair performance.

2. The method according to claim 1, characterized in that, The task allocation scheme for minimizing download bottleneck time specifically includes: Sort the k source nodes in descending order of available download bandwidth to obtain the source node sequence; Assign one download task to the destination node and the first k-1 nodes in the source node sequence to ensure that all download tasks are assigned to the repair node; Set an in pointer and an out pointer, wherein the in pointer initially points to the first node in the source node sequence; and the out pointer initially points to the (k-1)th node in the source node sequence. Iteratively execute the following download task transfer operations: Move from the current inbound pointer position toward the head of the source node sequence. If the estimated completion time of the download task of the first node encountered is less than that of the node currently pointed to by the pointer, then use that node as the new inbound pointer; otherwise, the pointer remains unchanged. Compare the estimated completion time of the download task after the destination node and the node pointed to by the current inbound pointer have taken on an additional download task, and select the smaller one as the inbound node; Compare the estimated completion time of the download task after the receiving node takes on the additional download task with the estimated completion time of the current download task of the sending node. If the former is less than the latter, then transfer one download task of the sending node to the receiving node and move the sending pointer one node towards the head of the source node sequence. At the same time, if the receiving node is not the destination node, then move the receiving pointer one node towards the tail of the source node sequence; otherwise, terminate the iteration. Obtain a task allocation scheme that minimizes the download bottleneck time until the estimated completion time of the download task at the transfer-in node is greater than or equal to the estimated completion time of the download task at the transfer-out node, or the transfer-in pointer coincides with the transfer-out pointer.

3. The method according to claim 1, characterized in that, The construction of the repair path specifically includes: Denote the destination node as the first node in the sequence, and arrange the k source nodes in descending order of available download bandwidth and then arrange them after the destination node in sequence to form a node sequence; Initialize the input pointer to point to the position after the destination node in the node sequence; Traverse the node sequence starting from the destination node. For the currently traversed node, when the number of download tasks to be matched is greater than 0, repeatedly perform the following operations: Establish a data transfer path from the node currently pointed to by the input pointer to the currently traversed node; Decrease the number of download tasks to be matched for the currently traversed node by 1, and point the input pointer to the next node in the node sequence; Continue to traverse the next node in the node sequence until the number of download tasks to be matched for all nodes is 0, and obtain a directed acyclic repair path.

4. The method according to claim 1, characterized in that, Before selecting the k source nodes in the stripe where the failed block to be repaired is located, it also includes a node selection strategy based on replacement to select a set of source nodes with the minimum repair bottleneck time, specifically including: Sort the candidate source nodes in descending order of their available upload bandwidth to obtain the candidate source node set S = {N1, N2, …, N}. n-1 }, where n is the total number of nodes in the strip where the failed block is located; Initialize the source node set R to the k most recently sorted nodes in S, i.e., R = {N1, N2, …, N}. k }, and calculate the upload bottleneck time Bottle_up = 1 / (minimum available upload bandwidth of all nodes in R) and the download bottleneck time Bottle_down, and fix the bottleneck time Bottle_all = max(Bottle_up, Bottle_down); If Bottle_up ≥ Bottle_down, then output R as the finally selected set of source nodes; If Bottle_up < Bottle_down, then perform the following iterative replacement operation: Set the pointer End = k; Execute the following steps in a loop: increment End by 1; if End > n - 1, then break out of the loop; obtain the candidate source node N End , and replace the node with the minimum available download bandwidth in R with N End ;; Calculate the updated upload bottleneck time of R after replacement, Bottle_up' = 1 / (the minimum of the available upload bandwidths of all nodes in R), and the download bottleneck time Bottle_down', and repair the bottleneck time Bottle_all' = max(Bottle_up', Bottle_down'); if Bottle_all' < Bottle_all, then retain the current R and update Bottle_all = Bottle_all'; otherwise, roll back the replacement; if Bottle_up' ≥ Bottle_down', then break out of the loop; otherwise, continue to the next iteration; Output the finally obtained R as the selected set of source nodes.

5. The method according to claim 1, characterized in that, The real-time monitoring of the change in the available network bandwidth of each node specifically includes: Deploy an agent on each node, and regularly collect the uplink and downlink bandwidth usage of the node through the network interface provided by the operating system; Take the difference between the network bandwidth upper limit of the node and the used upload bandwidth as the available upload bandwidth of the node, and take the difference between the network bandwidth upper limit and the used download bandwidth as the available download bandwidth of the node; Each node reports its available upload bandwidth and available download bandwidth to the coordinator at a preset time interval, and the time interval is dynamically adjusted according to the degree of network fluctuation; The coordinator receives and records the available bandwidth information reported by each node; Based on the real-time available bandwidth values reported by each node, the coordinator adopts a prediction scheme for available network bandwidth based on recursion to predict the available upload bandwidth and available download bandwidth of each node at the current moment. The prediction formula is: in, Bt The predicted available bandwidth at the current moment. Bt- 1 represents the predicted available bandwidth at the previous time step. Bnow This refers to the real-time available bandwidth reported by the node at the current moment. α This is the influence coefficient of the network bandwidth at the previous time step, with a value range of [0,1]. α The smaller the value, the higher the prediction sensitivity.

6. The method according to claim 1, characterized in that, The dynamic adjustment of the repair path using a heap-like structure specifically includes: When it is monitored that the available download bandwidth of any node drops sharply, mark the node as a laggard node; Obtain all the child nodes of the laggard node in the current repair path; If the laggard node has no child nodes, end the adjustment; otherwise, select the child node with the largest available download bandwidth from all the child nodes; The positions of the lagging node and the child node with the largest available download bandwidth are swapped in the repair path, so that the lagging node becomes the child node and the child node with the largest available download bandwidth becomes the parent node. Re-determine all child nodes of the lagging node in the current repair path, and repeat the operation of selecting the child node with the largest available download bandwidth and swapping positions until the lagging node has no child nodes.

7. The method according to claim 1, characterized in that, The data repair performed according to the repair path specifically includes: The coordinator will send the constructed repair path to each participating node agent in the form of a message; Each source node determines the number of upload tasks, download tasks, and target nodes for data block transmission based on the repair path. Each source node reads the surviving data blocks from its local storage and sends the data blocks to the corresponding nodes in a pipeline manner according to the target node address indicated by the repair path. When a source node undertakes download tasks simultaneously, the node receives data blocks from other nodes, performs linear combination calculations with the local surviving data blocks to generate intermediate data blocks, and then uploads the intermediate data blocks to the next node according to the repair path. The destination node receives data blocks from each source node, performs a final linear combination operation to recover the failed data blocks, and writes the recovered data blocks to local storage.

8. The method according to claim 1, characterized in that, Selecting the destination node specifically includes: Obtain a set of candidate destination nodes, wherein each node in the set of candidate destination nodes has not stored any block in the stripe where the failed block to be repaired is located before repair; Obtain the available download bandwidth for each node in the candidate destination node set; The node with the largest available download bandwidth is selected from the set of candidate destination nodes as the destination node.

9. The method according to claim 1, characterized in that, It also includes the step of integrating the method into the Hadoop Distributed File System (HDFS), specifically including: Deploy the coordinator on the NameNode of HDFS and deploy the agent on the DataNode of HDFS; When any DataNode fails to send a heartbeat for an extended period of time, the NameNode identifies that DataNode as a faulty node, and the coordinator takes over the repair work, generating a repair plan for the failed blocks on the faulty DataNode. The coordinator will distribute the generated repair plan to each DataNode participating in the repair. Each DataNode executes a repair task to complete data block transmission and reconstruction; After the reconstruction is completed, the DataNode storing the repaired data blocks reports the new data block location to the NameNode via heartbeat, and the NameNode updates the metadata.

10. The method according to claim 1, characterized in that, In the process of sinking the lagging node to the position of the leaf node that no longer undertakes the download task, the algorithm complexity of the repair path adjustment is O(log k), where k is the number of source nodes participating in the repair; and the repair path adjustment only affects the nodes on the path chain from the lagging node to the leaf node of its own child tree, while the repair paths of other nodes remain unchanged.

Images