Multi-node high-performance computing cluster network traffic load balancing scheduling method and device

Abstract

This invention discloses a method and apparatus for network traffic load balancing scheduling in a multi-node high-performance computing cluster, comprising three parts: network load detection, load estimation, and balancing decision. ArCa implements all parts on the host machine, requiring no modifications to the multi-node high-performance computing cluster network. Hosts send probe packets to each other to obtain the mapping relationship between paths and 5-tuples, as well as the path load. This information forms a network load table, on which ArCa estimates the short-term network load. Through estimation, the host makes a traffic plan decision and selects a path to send messages with the help of a skip flow algorithm. Each module is a separately running process that exchanges information through inter-process communication (such as MMAP), thereby improving the overall concurrency of the mechanism and enhancing its reaction speed and decision-making efficiency.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method and apparatus for network traffic load balancing scheduling of a multi-node high-performance computing cluster. Background Technology

[0002] With the rapid development of the internet, data has reached an astonishing scale, and the pressure on data processing is increasing day by day. According to a white paper by International Data Corporation (IDC), the total amount of data will increase to 163 ZB by 2025. Enterprises are developing various multi-node high-performance computing (HPC) clusters to handle big data processing tasks, such as data storage, genome sequencing, and distributed machine learning (DML), and are developing high-speed communication technologies to improve cluster performance, such as All-Reduce and Remote Direct Memory Access (RDMA).

[0003] Multi-node HPC clusters are primarily developed for distributed high-performance applications such as distributed storage and DML (Data Management). Each compute node in the cluster is a host, and the network uses switches to connect hosts to Clos, Fat-Tree, or Leaf-Spine. As host performance improves, network performance also increases. Compared to traditional networks, multi-node high-performance computing cluster networks have the following four characteristics:

[0004] (1) Scalability. Multi-node HPC clusters require high scalability to control deployment overhead. Therefore, in network approaches, Clos is widely deployed because it is simple and easy to scale. In recent years, Leaf-Spine has also become popular, as it can be scaled to build large multi-node high-performance computing cluster networks, such as EFLOPS (floating-point operations per second). General-purpose network hardware is common in high-performance computing cluster networks because it ensures broad compatibility, while dedicated hardware is rarely used.

[0005] (2) Kernel Bypass. To cope with the high computing performance of the host, multi-node high-performance computing cluster networks have introduced RDMA (Remote Memory Access) technology to improve throughput. RDMA allows network interface cards (NICs) to copy memory from user space without system interrupts and CPU copying. In this process, RDMA completely bypasses the system kernel, including TCP. To some extent, RDMA replaces TCP as a transport protocol. Therefore, mechanisms built on top of TCP are no longer effective.

[0006] (3) Asymmetry. Although vendors attempt to maintain network resource symmetry, asymmetry still exists due to various reasons, such as network failures and the implementation of heterogeneous resources. One such case is Clos unbalanced striping, which is almost unavoidable in practice. Asymmetry arises when the number of switches in one layer cannot be perfectly divided with the number of switches in adjacent layers. When asymmetry is high, algorithms that balance load based only on local load information will lead to a decrease in the average network utilization globally.

[0007] (4) Concurrency. Multi-node high-performance computing cluster networks are full of concurrent traffic. Taking DML as an example, it initiates communication from many hosts simultaneously, many of which share the same subnet resources. When several hosts simultaneously send traffic to their shared switch and choose the same switch output port, this traffic competes for bandwidth. The main reason for this is that the load balancing method selects the "best" path without considering the choices of other hosts.

[0008] Communication performance directly determines cluster performance, and load balancing is one of the most important technologies for improving network performance. In most high-performance computing cluster networks, multipath load balancing (ECMP) is a default load balancing algorithm deployed in commercial network switches. Generally, the switch collects 5 tuples from each packet as a hash key and hashes it to a random output port. ECMP has basic load balancing capabilities and is widely used due to its simplicity. However, hash collisions and poor resilience to asymmetry prevent ECMP from achieving the expected performance in many cases. Previous load balancing work has focused on improving the load balancing performance of data center networks (DCNs) and other cloud-scale networks. On one hand, some designs primarily focus on upgrading hardware, such as Ananta's upgrade of its multiplexer (Mux) and SilkRoad's use of application-specific integrated circuits (ASICs) for balancing. The aim of this type of work is to research and develop dedicated load balancing hardware that outperforms commercial switches. On the other hand, designs primarily focused on software development are more common. These designs discuss how to program switches and backend servers to achieve balancing based on existing hardware.

[0009] While these works perform well on traditional tasks, they are difficult to replicate on high-performance computing (HPC) cluster networks due to some unique characteristics. This is reflected in:

[0010] (1) Scalability. Designs intended to develop dedicated hardware load balancers are difficult to deploy and scale due to their high cost.

[0011] (2) High-performance computing cluster networks widely deploy RDMA, a kernel-bypass transport method to improve network throughput. With RDMA, clients directly access server memory and bypass kernel transport protocols, including TCP. Most existing load balancing jobs are designed based on Flowlets, which are based on TCP. Therefore, in an RDMA environment, the balancing performance of these jobs degrades to ECMP levels due to the inability to use Flowlets.

[0012] (3) Another factor is asymmetric network resources. To save costs, enterprises select and purchase different types and versions of hard drives for their HPC clusters, with hosts of varying computing performance processing the same DML task together. Hosts at different top-of-rack (ToR) levels may have different available bandwidths, resulting in unequal access to network resources. Link failures also contribute to asymmetry. In asymmetric networks, locally optimal load balancing can lead to a loss of global bandwidth utilization.

[0013] (4) Another characteristic is concurrent flow. Distributed applications (such as DML) initiate communication from many hosts, with large amounts of data flowing into the network simultaneously. What happens if the load balancing mechanism always selects the least loaded path for each host? Most traffic will be routed to a few paths! We call this concurrent path contention. This contention can lead to more severe imbalances and congestion. Introducing serialization and a centralized scheduler might help, but this is far from providing a fast response. Summary of the Invention

[0014] To address the challenges mentioned above and design comprehensive load balancing capabilities for high-performance computing cluster networks, this invention proposes a multi-node high-performance computing cluster network traffic load balancing scheduling method (ArCa) and apparatus. This method is entirely software-based, making routing decisions on the server side rather than at the switch or router side. The method is a simple application-layer communication module that can be implemented in any high-performance computing cluster network. ArCa's only dependency is ECMP, which is widely deployed as the default mechanism in networks. Therefore, ArCa achieves high scalability and tolerates kernel bypass communication. ArCa probes global network load through in-band network telemetry (INT) packets and maintains a global view even in asymmetric conditions. Furthermore, we introduce a novel distributed load balancing algorithm, "Jump Pipeline," to avoid path contention. As the name suggests, the Jump Pipeline algorithm arranges traffic like water flow, randomly jumping between streams; this simple introduction of randomness effectively avoids path contention.

[0015] To achieve the above objectives, the present invention provides the following technical solution:

[0016] On the one hand, this invention provides a method for network traffic load balancing scheduling in a multi-node high-performance computing cluster, comprising the following steps:

[0017] S1. Load Probe: Hosts send probe packets with different 5-tuples to each other, and obtain the mapping relationship between the paths and 5-tuples of other hosts and the load of the paths on each host to form a network load table.

[0018] S2. Load Estimation: Estimate the current path load of the network based on historical load data;

[0019] S3. Balancing Decision: The jump flow algorithm is adopted to distribute traffic from the host to each path, thereby completing the load balancing traffic scheduling.

[0020] Further, step S1 includes:

[0021] S101. In an end-to-end manner, the sending host i sends a probe data packet A with different 5-tuples. The 5-tuple consists of source IP, destination IP, source port number, destination port number, and protocol. The switch uses ECMP to uniquely map each 5-tuple to a specific port before sending it out. The 5-tuple representation of probe data packet A is as follows: <IP i IP j ,p i ,p j ,UDP>;

[0022] S102. When probe data packet A arrives at each switch along a fixed path, the switch will add relevant information about itself to the end of the probe packet according to the INT protocol. The relevant information includes: the ingress port through which the packet enters the switch, the egress port through which the packet is sent from the switch, the queuing delay on the switch, and the fixed bandwidth of the switch.

[0023] S103. After receiving probe data packet A, the receiving host j immediately copies an identical probe data packet B and sends it. The 5-tuple representation of probe data packet B is as follows: <IP j IP i ,p j ,p i ,UDP>, probe packet B returns to the sending host i along the original path;

[0024] S104. The receiving host j parses the probe data packet A and establishes a mapping relationship: 5-tuple → path → load. Wherein, the path is the ordered arrangement of the ingress and egress ports of the switch through which the probe data packet passes; the load is represented by the bandwidth-delay product.

[0025] S105. When the sending host i receives the probe data packet B, it parses it into a five-tuple → path → load mapping relationship in the same way as the receiving host j, and stores it in the program.

[0026] Furthermore, in step S104, it is assumed that the probe packet travels along a path from the sending host i to the receiving host j. The bandwidth is The total delay from the sender to the receiver is The bandwidth-delay product is then calculated using the following formula:

[0027]

[0028] Further, step S2 includes:

[0029] S201. Based on EWMA, the predicted load is obtained;

[0030] S202. Adjust the EWMA parameters based on load feedback.

[0031] Further, in step S201, the EWMA formula is:

[0032]

[0033] in At decision time t, the path The estimated load; △t is the interval between the latest received probe packet load data update time and the time of this decision.

[0034] Furthermore, in step S202, each time a probe packet brings back network load, the parameters of EWMA are adjusted based on the actual data of the probe packet using the following formula:

[0035]

[0036] Where △t' is the time interval between the current received probe packet and the previous received probe packet.

[0037] Further, step S3 includes:

[0038] S301, Path Arrangement: Assign numbers to each path sequentially. Paths with adjacent numbers are neighboring paths. Paths with numbers less than the current path are left neighbors, and paths with numbers greater than the current path are right neighbors.

[0039] S302, Traffic Scheduling: Assume that there are m paths from the sending host i to the receiving host j and a series of traffic demands F waiting to be sent to the receiving host j. A skip-flow algorithm is used.

[0040] Furthermore, the jump flow algorithm in step S3 includes:

[0041] S3021. Obtain the estimated value of the path load at the current moment and store it in the current process in the form of a path-load mapping. The traffic waiting to be scheduled will be allocated to the path of the replica one by one.

[0042] S3022. Randomly select a path k, compare it with the paths to its left and right, and recursively compare it to find the path with the lowest load on the left and right sides within the range of path k. Distribute a portion of the traffic demand waiting to be transmitted to the path with the lowest load, so that the load on this path is close to or slightly higher than that on its adjacent paths.

[0043] S3023. If the traffic demand has not been fully allocated, return to step S3022 to randomly select a path again; otherwise, the traffic demand has been fully allocated.

[0044] S3024. For each traffic demand, modify the 5-tuple according to the mapping relationship between the 5-tuple and the path, and based on the ECMP mechanism, ensure that the traffic is transmitted through the pre-scheduled path.

[0045] S3025. The sending host i and the receiving host j establish a connection and perform traffic transmission.

[0046] S3026. For each host's traffic requirements, traffic is transmitted using steps S3021 to S3025.

[0047] On the other hand, the present invention also provides the above-mentioned multi-node high-performance computing cluster network traffic load balancing scheduling device, which includes the following modules to implement the above method:

[0048] The load probing module is used for hosts to send probe data packets with different 5-tuples to each other, and to obtain the mapping relationship between the paths and 5-tuples of other hosts and the load of the paths on each host, forming a network load table.

[0049] The load estimation module is used to estimate the current path load of the network based on historical load data.

[0050] The load balancing decision module is used to distribute traffic from the host to each path, and the jump flow algorithm module is used to complete the load balancing traffic scheduling.

[0051] Furthermore, the jump flow algorithm module includes:

[0052] S3021. Obtain the estimated value of the path load at the current moment and store it in the current process in the form of a path-load mapping. The traffic waiting to be scheduled will be allocated to the path of the replica one by one.

[0053] S3022. Randomly select a path k, compare it with the paths to its left and right, and recursively compare it to find the path with the lowest load on the left and right sides within the range of path k. Distribute a portion of the traffic demand waiting to be transmitted to the path with the lowest load, so that the load on this path is close to or slightly higher than that on its adjacent paths.

[0054] S3023. If the traffic demand has not been fully allocated, return to step S3022 to randomly select a path again; otherwise, the traffic demand has been fully allocated.

[0055] S3024. For each traffic demand, modify the 5-tuple according to the mapping relationship between the 5-tuple and the path, and based on the ECMP mechanism, ensure that the traffic is transmitted through the pre-scheduled path.

[0056] S3025. The sending host i and the receiving host j establish a connection and perform traffic transmission.

[0057] S3026. For each host's traffic requirements, traffic is transmitted using steps S3021 to S3025.

[0058] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0059] The proposed multi-node high-performance computing cluster network traffic load balancing scheduling method utilizes intra-network telemetry technology to detect network path load, establishing a global perspective and avoiding local blind spots caused by asymmetry. Based on EWMA and network path load detection results, it predicts path load, improving the accuracy and real-time performance of the load balancing mechanism. Based on the jump pipeline algorithm, it actively adjusts the five-tuple of transmitted traffic on the server, leveraging the stability of the switch's ECMP mechanism to complete load-balanced traffic scheduling, and incorporates the randomness of random routing to avoid concurrent path contention. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are only some embodiments recorded in this invention, and those skilled in the art can obtain other drawings based on these drawings.

[0061] Figure 1 This is a block diagram illustrating the principle of a multi-node high-performance computing cluster network traffic load balancing scheduling method provided in an embodiment of the present invention.

[0062] Figure 2 This is a schematic diagram of the skipping flow algorithm provided in an embodiment of the present invention.

[0063] Figure 3This is a performance comparison chart of ArCa and ECMP on the switch side provided for an embodiment of the present invention.

[0064] Figure 4 This is a performance comparison chart of ArCa and ECMP on the server side provided for an embodiment of the present invention. Detailed Implementation

[0065] To better understand this technical solution, the method of the present invention will be described in detail below with reference to the accompanying drawings.

[0066] The multi-node high-performance computing cluster network traffic load balancing scheduling method (ArCa) of the present invention, such as Figure 1 As shown, ArCa is a modular system consisting of three parts: network load probing, load estimation, and balancing decision-making. All parts are implemented on the host machine, requiring no changes to the multi-node high-performance computing cluster network. Hosts send probe packets to each other, obtaining the mapping between paths and 5-tuples, as well as the load on each path. This information forms a network load table, upon which ArCa estimates the short-term network load. Based on this estimation, the host makes decisions about traffic planning and selects paths to send messages with the help of a skip flow algorithm. Each module is a separately running process that exchanges information through inter-process communication (such as MMAP), thereby improving the overall concurrency of the mechanism and enhancing its responsiveness and decision-making efficiency.

[0067] Specifically, ArCa includes the following steps:

[0068] Step 1: (Module 1) Load Probe. Send an INT probe message to probe the path load.

[0069] Step 1.1: In an end-to-end manner, the sending end (host i) sends probe packets with different 5-tuples. Each 5-tuple consists of <source IP, destination IP, source port number, destination port number, protocol>. The switch uses ECMP to uniquely map each 5-tuple to a specific port before sending it. Therefore, when the 5-tuple is fixed, the switch ports through which the flow passes are also fixed, resulting in a fixed path. Here, we assume that the 5-tuple of a probe packet A is... <IP i IP j ,p i ,p j ,UDP>.

[0070] Step 1.2: When probe packet A arrives at each switch along a fixed path, the switch will append its own information to the end of the probe packet according to the INT protocol. This information includes: the ingress port through which the packet enters the switch, the egress port through which the packet is sent from the switch, the queuing delay within the switch, and the fixed bandwidth of the switch.

[0071] Step 1.3: After receiving probe packet A, the receiving end (host j) immediately copies an identical packet B, exchanging the source IP and destination IP, source port number and destination port number. The 5-tuple of packet B is... <IP j IP i ,p j ,p i ,UDP>. Sending B out will return to host i along the original path.

[0072] Step 1.4: The receiving end parses probe packet A and establishes a mapping relationship: 5-tuple → path → load. Here, the path is the ordered arrangement of the ingress and egress ports of the switch through which the probe packet passes; the load is represented using the bandwidth-delay product. Assume the probe packet travels along a path from host i to j. The bandwidth is The total delay from the sender to the receiver is The bandwidth-delay product can then be calculated using the following formula.

[0073]

[0074] Step 1.5: The sending end receives probe packet B and parses it into a 5-tuple → path → load mapping using the same method as the receiving end, storing it in the program. Through the above steps, we obtain the network load and path mapping relationship to other hosts on each host.

[0075] Step 2: (Module Two) Load Forecasting. Based on historical load data, predict the current path load. Since there is a time lag between the detection time and the load balancing decision-making time, the detected data cannot accurately reflect the current network load. Forecasting is needed to improve the accuracy of the decision-making.

[0076] Step 2.1: Obtain the predicted load based on EWMA. In this invention, the EWMA formula is:

[0077]

[0078] in At decision time t, the path The estimated load; △t is the interval between the latest received probe packet load data update time and the time of this decision.

[0079] Step 2.2: Adjust the weight parameter α of EWMA based on load feedback. Each time a probe packet brings back network load data, adjust the EWMA parameters based on the actual data from the probe packet using the following formula to improve prediction accuracy.

[0080]

[0081] Where △t' is the time interval between the current received probe packet and the previous received probe packet.

[0082] Step 3: (Module 3) Load Balancing. Using the jump-flow algorithm, traffic is distributed to each path to complete load balancing. Assume there are m paths from host i to host j and a series of traffic demands F waiting to be sent to host j. In reality, each path is a different arrangement of the ingress and egress ports of a switch. Although two paths pass through the same switch, if their ingress and egress ports are different, they do not affect each other; therefore, we consider them two different paths. The traffic scheduling steps are as follows:

[0083] Step 3.1: Path Arrangement. Assign sequential numbers to each path to create "neighbor" paths: paths with adjacent numbers are neighbor paths, paths with numbers less than the current path are left neighbors, and paths with numbers greater than the current path are right neighbors. For example, for path number k, its left i-th neighbor is (ki)%n, and its right i-th neighbor is (k+i)%n. Here, n is the total number of paths, and % represents the modulo operation.

[0084] Step 3.2: Traffic Scheduling

[0085] The specific workflow of the jump flow algorithm of this invention is as follows: Figure 2 As shown. Specifically includes:

[0086] Step 3.2.1 Communicate with Module 2 to obtain the estimated replica of the path load at the current moment, and store it in the current process in the form of a "path-load" mapping. Traffic waiting to be scheduled will be allocated to the paths of the replicas one by one.

[0087] Step 3.2.2 Randomly select a path k and compare its load with its adjacent paths k-1 and k+1. Then compare path k-1 with path k-2, and so on. After recursively comparing, obtain the path with the lowest load on the left and right sides within the range of path k (this path may also be path k itself). Distribute a portion of the traffic demand waiting to be transmitted to the path with the lowest load, so that the load on this path is close to or slightly higher than that on its adjacent paths.

[0088] If the traffic demand has not been fully allocated in step 3.2.2, return to step 3.2.1 to randomly select a path again; otherwise, the traffic demand has been fully allocated.

[0089] Step 3.2.3 For each traffic demand, modify its quintuple according to the mapping relationship between the quintuple and the path, and based on the ECMP mechanism, ensure that it will be transmitted through the pre-scheduled path.

[0090] Step 3.2.4 Host i establishes a connection with host j and performs traffic transmission.

[0091] Step 3.2.5 applies the above-mentioned load balancing mechanism to the traffic demand of each host, thereby achieving a balanced load across the network.

[0092] Let's illustrate this with a concrete example: There are 8 paths between sending host i and receiving host j. We number these paths from 0 to 7 in black, and each bar represents the capacity and load of a path. The red bars represent the path load, and the light yellow bars represent the bandwidth. At the bottom of the bars, the white numbers indicate the specific load values. Solid boxes with traffic demands represent randomly selected paths, while the two dashed boxes represent flowing paths and hopped paths, respectively. For simplicity, we assume each traffic demand is 1 unit and each path's bandwidth is 10 units. Initially, there are 6 units of traffic demand to schedule.

[0093] Step 1: Randomly select path 1. Compared to adjacent paths, path 1 has a lower load than path 0 but a higher load than path 2. Therefore, we allocate traffic to path 2 so that its load reaches the level of path 1. At this point, 1 unit of traffic demand is allocated. A random number of 61 is generated, and the path selected for the second round of allocation is (1+61)%8 = 6.

[0094] Step 2: Allocate the remaining 5 units of traffic demand. For path 6, the load on both paths 5 and 7 is less than that on adjacent paths, so traffic is allocated to paths 5 and 7. Allocate a traffic demand consuming 5 units. Generate a random number of 82, and select the path for the third round of allocation: (6+82)%8 = 0.

[0095] Step 3: At this point, there is no unit flow remaining, and the scheduling algorithm ends.

[0096] Performance comparison of the ArCa invention with the existing ECMP:

[0097] We conducted some experiments in a real production environment. Figure 3This demonstrates the load performance achieved by two load balancing schemes on the switch side. The red bar shows that ECMP forwarded at least 400Gbps of traffic to ports 10 and 9, resulting in an imbalance on ports 0-4, with port 0 sending almost no traffic. Traffic that should have been forwarded to ports 0-4 was actually forwarded to ports 7-10. It can be said that varying degrees of flow collisions occurred on ports 7-10. ArCa achieves a higher degree of balance. In the case of coarse-grained elephant traffic, the skip flow algorithm schedules traffic to each path approximately evenly. More precisely, the skip flow algorithm evenly distributes traffic through different output ports of the switch. If we evaluate the balancing performance using the standard deviation of throughput, ECMP's value is 148.06, while ArCa's value is 2.96, an improvement of almost 49 times.

[0098] Figure 4 The diagram illustrates server-side throughput, with each bar representing the communication throughput between a pair of hosts. To our knowledge, switch imbalance doesn't always lead to host server performance degradation, which is why load balancing improvements rarely contribute to improved network performance. The throughput performance differences on hosts are not as pronounced as on the S0 output ports. Traffic collisions and imbalances on ECMP ultimately cause host performance degradation, as shown by the red bars. Compared to ECMP throughput, ArCa maintains load balancing performance, with a throughput difference of 6Gbps (191Gbps–197Gbps) in ArCa load balancing, compared to 38Gbps (160Gbps–198Gbps) in ECMP—a nearly 6.3x improvement. Meanwhile, the standard deviation of throughput in ECMP is 13.61, while in ArCa it is only 1.78, a 7.08x improvement. This is significantly smaller compared to the gains in switches. Furthermore, ArCa's total throughput is also slightly higher than ECMP. The average throughput of server-side ArCa is 22.5% higher than that of ECMP.

[0099] In summary, this invention reveals the main challenges of implementing load balancing methods on multi-node HPC cluster networks and proposes our solution, ArCa, a software-based load balancing method with high scalability, kernel bypass tolerance, asymmetric recovery capabilities, and contention avoidance. ArCa is built on the widely deployed ECMP, and its application-layer implementation makes it easy to deploy, while also addressing the load balancing failure caused by RDMA transmissions bypassed by the kernel. ArCa establishes a global load perspective with the help of INT probe technology, thus providing resilience to asymmetric network topologies. Furthermore, ArCa incorporates a pipelining algorithm, adding randomness to the load balancing flow scheduling to avoid concurrent path contention. In addition, our evaluation demonstrates that ArCa achieves near-complete load balancing compared to native ECMP, with network throughput exceeding ECMP by 22.5%.

[0100] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. However, these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A network traffic load balancing scheduling method for a multi-node high-performance computing cluster, characterized in that, Includes the following steps: S1. Load Probe: Hosts send probe packets with different 5-tuples to each other, and obtain the mapping relationship between the paths and 5-tuples of other hosts and the load of the paths on each host to form a network load table. S2. Load Estimation: Estimate the current path load of the network based on historical load data; Step S2 includes: S201. Based on EWMA, the predicted load is obtained; S202. Adjust the EWMA parameters based on load feedback; In step S201, the EWMA formula is: ， in At decision time t, the path The estimated load; It is the interval between the update time of the latest received probe packet's payload data and the time of this decision; In step S202, each time a probe packet brings back network load, the parameters of EWMA are adjusted based on the actual data of the probe packet using the following formula: ， in, This is the time interval between the current received probe packet and the previous received probe packet; S3, Balancing Decision: Using a skip-flow algorithm, the host distributes traffic to each path to achieve load balancing traffic scheduling; Step S3 includes: S301, Path Arrangement: Assign numbers to each path sequentially. Paths with adjacent numbers are neighboring paths. Paths with numbers less than the current path are left neighbors, and paths with numbers greater than the current path are right neighbors. S302. Traffic Scheduling: Assume that there are m paths from the sending host i to the receiving host j and a series of traffic demands F waiting to be sent to the receiving host j. A skip-flow algorithm is used; the skip-flow algorithm includes: S3021. Obtain the estimated value of the path load at the current moment and store it in the current process in the form of a path-load mapping. The traffic waiting to be scheduled will be allocated to the path of the replica one by one. S3022. Randomly select a path k, compare it with the paths to its left and right, and recursively compare it to find the path with the lowest load on the left and right sides within the range of path k. Distribute a portion of the traffic demand waiting to be transmitted to the path with the lowest load, so that the load on this path is close to or slightly higher than that on its adjacent paths. S3023. If the traffic demand has not been fully allocated, return to step S3022 to randomly select a path again; otherwise, the traffic demand has been fully allocated. S3024. For each traffic demand, modify the 5-tuple according to the mapping relationship between the 5-tuple and the path, and based on the ECMP mechanism, ensure that the traffic is transmitted through the pre-scheduled path. S3025. The sending host i and the receiving host j establish a connection and perform traffic transmission. S3026. For each host's traffic requirements, traffic is transmitted using steps S3021 to S3025.

2. The multi-node high-performance computing cluster network traffic load balancing scheduling method according to claim 1, characterized in that, Step S1 includes: S101. In an end-to-end manner, the sending host i sends a probe data packet A with different 5-tuples. The 5-tuple consists of source IP, destination IP, source port number, destination port number, and protocol. The switch uses ECMP to uniquely map the 5-tuple to a specific port before sending it. The 5-tuple representation of probe data packet A is as follows: <IP i IP j , p i , p j , UDP>; S102. When probe data packet A arrives at each switch along a fixed path, the switch will add relevant information about itself to the end of the probe packet according to the INT protocol. The relevant information includes: the ingress port through which the packet enters the switch, the egress port through which the packet is sent from the switch, the queuing delay on the switch, and the fixed bandwidth of the switch. S103. After receiving probe data packet A, the receiving host j immediately copies an identical probe data packet B and sends it. The 5-tuple representation of probe data packet B is <IP>. j IP i , p j , p i , UDP>, probe packet B returns to the sending host i along the original path; S104. The receiving host j parses the probe data packet A and establishes a mapping relationship: 5-tuple → path → load. Here, the path is the ordered arrangement of the ingress and egress ports of the switch through which the probe data packet passes; the load is represented by the bandwidth-delay product. S105. When the sending host i receives the probe data packet B, it parses it into a five-tuple → path → load mapping relationship in the same way as the receiving host j, and stores it in the program.

3. The multi-node high-performance computing cluster network traffic load balancing scheduling method according to claim 2, characterized in that, In step S104, it is assumed that the probe packet travels along a path from the sending host i to the receiving host j. The bandwidth is The total delay from the sender to the receiver is The bandwidth-delay product is then calculated using the following formula: 。 4. A network traffic load balancing scheduling device for a multi-node high-performance computing cluster, characterized in that, The following modules are included to implement the method of any one of claims 1-3: The load probing module is used for hosts to send probe data packets with different 5-tuples to each other, and to obtain the mapping relationship between the paths and 5-tuples of other hosts and the load of the paths on each host, forming a network load table. The load estimation module is used to estimate the current path load of the network based on historical load data. The load balancing decision module is used to distribute traffic from the host to each path, and the jump flow algorithm module is used to complete the load balancing traffic scheduling.

5. The multi-node high-performance computing cluster network traffic load balancing scheduling device according to claim 4, characterized in that, The jump flow algorithm module includes: S3021. Obtain the estimated value of the path load at the current moment and store it in the current process in the form of a path-load mapping. The traffic waiting to be scheduled will be allocated to the path of the replica one by one. S3022. Randomly select a path k, compare it with the paths to its left and right, and recursively compare it to find the path with the lowest load on the left and right sides within the range of path k. Distribute a portion of the traffic demand waiting to be transmitted to the path with the lowest load, so that the load on this path is close to or slightly higher than that on its adjacent paths. S3023. If the traffic demand has not been fully allocated, return to step S3022 to randomly select a path again; otherwise, the traffic demand has been fully allocated. S3024. For each traffic demand, modify the 5-tuple according to the mapping relationship between the 5-tuple and the path, and based on the ECMP mechanism, ensure that the traffic is transmitted through the pre-scheduled path. S3025. The sending host i and the receiving host j establish a connection and perform traffic transmission. S3026. For each host's traffic requirements, traffic is transmitted using steps S3021 to S3025.

Images