Traffic distribution and computing resource scheduling method and system

Abstract

The invention relates to a traffic distribution and computing resource scheduling method and system, and the method comprises the steps: obtaining the traffic requested by a user in edge computing; the flow requested by a user is processed through a double-layer load balancing mechanism, and the double-layer load balancing mechanism comprises an upper-layer load balancing mechanism (used for carrying out flow distribution on edge nodes) and a lower-layer load balancing mechanism (used for scheduling computing resources according to a flow distribution result). According to the upper-layer load balancing mechanism, a request path is dynamically optimized by monitoring the CPU, the memory utilization rate and the network delay of each node, so that a request is preferentially processed at a local node and is forwarded to an optimal remote node when resources are limited, and therefore, the cross-node transmission delay is reduced, and the load is balanced; a lower-layer load balancing mechanism dynamically adjusts deployment of Pod through global flow monitoring, so that a high-flow area can obtain more computing resources, and the overall system throughput and the resource utilization rate are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of edge computing, and in particular to a traffic distribution and computing resource scheduling method and system. Background Art

[0002] Containerization technology is a promising solution for building edge computing infrastructure for smart cities, buildings, and power grids, as it has many inherent advantages such as fault isolation, high security, portability, and lightweight. However, in order to effectively deploy containers and manage application resources in an edge computing environment, container orchestration tools with resource allocation and utilization, scalability, high availability, and load balancing capabilities are also essential.

[0003] Among various container orchestration tools on the market, Kubernetes (abbreviated as K8s) is the most popular. K8s provides many of the important functions listed above and is suitable for container-based edge computing infrastructure. Its various functions help to quickly deploy applications (services) without complex configuration and installation steps. For example, each container of an application can be deployed as multiple replicas (pods) on worker nodes in a K8s cluster, providing high availability for the application. At the same time, the auto-scaling function in K8s can dynamically increase and decrease the number of replicas according to the current workload of the application. Although the number of pods often changes in a K8s cluster, all requests for a specific application are forwarded to the corresponding backend pod through the K8s component kube-proxy installed in each node. Therefore, the operation of kube-proxy can directly affect the performance of the application (e.g., throughput and latency).

[0004] Kube-proxy acts as a network load balancer in the Kubernetes cluster and plays an important role in containerized applications by evenly distributing client requests. However, its default policy faces significant limitations in an edge computing environment. First, since the pods of an application are usually geographically distributed among different nodes, and there may be high network latency between these nodes, forwarding requests across nodes often results in significant latency, seriously affecting the system's response time. Second, the request distribution policy of kube-proxy does not consider the resource status of the target node (e.g., CPU and memory utilization), which may cause requests to be assigned to nodes that are already overloaded or have high network latency, further reducing the performance of the application and increasing the processing latency. These problems make it difficult for traditional load balancing strategies to meet the requirements of high performance and high availability in edge computing scenarios with dynamic load environments.

[0005] Traditional Kubernetes load balancing strategies (such as the round-robin or random selection strategies of kube-proxy, and the Pod scheduling of kube-scheduler based only on static resource utilization) often ignore the dynamic changes in node resource status and the impact of network latency, which may lead to problems such as increased response latency and uneven resource utilization, affecting the overall system performance. Summary of the Invention

[0006] To this end, the technical problem to be solved by the present invention is to overcome the problems in the prior art that traditional Kubernetes load balancing strategies ignore the dynamic changes in node resource status and the impact of network latency, resulting in increased response latency and uneven resource utilization, affecting the overall system performance.

[0007] To solve the above technical problems, the present invention provides a traffic distribution and computing resource scheduling method, including:

[0008] In edge computing, obtain the traffic of user requests;

[0009] Process the traffic of user requests through a two-layer load balancing mechanism, where the two-layer load balancing mechanism includes an upper-layer load balancing mechanism and a lower-layer load balancing mechanism. The upper-layer load balancing mechanism is used for traffic distribution among edge nodes, and the lower-layer load balancing mechanism is used to schedule computing resources according to the traffic distribution result.

[0010] In an embodiment of the present invention, the method for the upper-layer load balancing mechanism to perform traffic distribution among edge nodes includes:

[0011] Obtain the local node and each remote node, and determine whether the CPU utilization rate or memory utilization rate of the local node exceeds the threshold. If so, calculate the comprehensive score of each remote node, and use the remote node with the highest comprehensive score as the target node and process the traffic; if not, use the local node as the target node and process the traffic, where the local node is the edge node that initially receives the traffic of user requests, and the remote node is other edge nodes that are not the local node.

[0012] In an embodiment of the present invention, the comprehensive score includes the CPU remaining rate, the memory remaining rate, and the network latency, and the formula is:

[0013]

[0014] where S i represents the comprehensive score of node i, and the range is [0,1]; w cpu , w mem , w lat are the weights of the CPU remaining rate, the memory remaining rate, and the network latency of the node respectively, and satisfy wcpu +w mem +w lat = 1; respectively represent the CPU remaining rate and memory remaining rate of node i, represents the network delay normalization value of node i.

[0015] In an embodiment of the present invention, the CPU remaining rate of the node i and the memory remaining rate formulas are respectively:

[0016]

[0017] wherein, and are respectively the used CPU and memory resources of node i, and are respectively the total CPU and memory resources of node i.

[0018] In an embodiment of the present invention, the network delay normalization value of the node i formula is:

[0019]

[0020] wherein, RTT i represents the network round-trip time of node i, RTT max represents the maximum network delay among all candidate nodes.

[0021] In an embodiment of the present invention, the method for the lower-layer load balancing mechanism to schedule computing resources according to the edge node traffic distribution result includes:

[0022] According to the edge region traffic weight W location and the total number of global Pods P total , calculate the expected number of Pods in the edge region, the formula is:

[0023]

[0024] Obtain the current number of Pods in the edge region Calculate ΔP location , the formula is:

[0025]

[0026] According to the value of ΔP location dynamically adjust the deployment of Pods in the edge region: when ΔP location > 0, add Pods in the edge region; when ΔP locationWhen < 0, release the redundant Pods in the edge area and ensure that at least one Pod in the edge area provides services. The edge area includes several edge nodes; a Pod is a computing resource deployed on an edge node to enable the edge node to process traffic data.

[0027] In an embodiment of the present invention, the calculation method of the traffic weight W of the edge area location includes:

[0028] After obtaining traffic data at the edge node, according to the node traffic data T node aggregate and calculate the total traffic volume T of each edge area location and then calculate the total global traffic volume T total The formula is:

[0029]

[0030] Calculate the traffic weight W of each edge area location The formula is:

[0031]

[0032] To solve the above technical problems, the present invention provides a traffic distribution and computing resource scheduling system, including:

[0033] An acquisition module: used to acquire the traffic of user requests in edge computing;

[0034] A distribution and scheduling module: used to process the traffic of user requests through a double-layer load balancing mechanism. The double-layer load balancing mechanism includes an upper-layer load balancing mechanism and a lower-layer load balancing mechanism. The upper-layer load balancing mechanism is used to distribute traffic to edge nodes, and the lower-layer load balancing mechanism is used to schedule computing resources according to the traffic distribution result.

[0035] To solve the above technical problems, the present invention provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of the above traffic distribution and computing resource scheduling method are implemented.

[0036] To solve the above technical problems, the present invention provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above traffic distribution and computing resource scheduling method are implemented.

[0037] The above technical solutions of the present invention have the following advantages compared with the prior art:

[0038] The present invention designs a two - layer load - balancing mechanism, which combines resource - aware traffic distribution and traffic - aware dynamic Pod scheduling. The upper - layer load - balancing mechanism optimizes the request - handling strategy of local nodes by sensing the resource status and network latency of nodes, and dynamically adjusts the remote forwarding path according to the scoring model when necessary to reduce system latency. The lower - layer load - balancing mechanism dynamically adjusts Pod deployment based on the global traffic distribution, enabling high - load areas to obtain more computing resources, thereby further optimizing system performance.

[0039] The present invention can effectively adapt to dynamic traffic changes, improve the throughput of the system and reduce request - handling latency, providing an optimized solution for efficient request handling in a Pod - based edge - computing environment. Brief Description of the Drawings

[0040] In order to make the content of the present invention easier to be clearly understood, the following further details the present invention according to specific embodiments of the present invention in conjunction with the drawings.

[0041] Figure 1 is the flowchart of the method of the present invention;

[0042] Figure 2 is the architecture diagram of the two - layer load - balancing mechanism of the present invention;

[0043] Figure 3 is the schematic diagram of the throughput change under different thresholds in the experiment;

[0044] Figure 4 is the schematic diagram of the response - speed change under different thresholds in the experiment;

[0045] Figure 5 is the schematic diagram of the throughput change under different network latencies in the experiment;

[0046] Figure 6 is the schematic diagram of the response - speed change under different network latencies in the experiment;

[0047] Figure 7 is the schematic diagram of the throughput change under different request distributions in the experiment. Detailed Embodiments

[0048] The following further illustrates the present invention in conjunction with the drawings and specific embodiments, so that those skilled in the art can better understand the present invention and be able to implement it, but the examples given are not intended to limit the present invention.

[0049] Embodiment 1

[0050] Traditional Kubernetes (abbreviated as K8s) load balancing strategies (such as the round-robin or random selection strategies of kube-proxy, and the Pod scheduling of kube-scheduler based only on static resource utilization) often ignore the dynamics of traffic and the impact of network latency, which may lead to problems such as increased response latency and uneven resource utilization. The two-layer load balancing mechanism proposed in this embodiment effectively improves the deficiencies of traditional methods by combining resource-aware traffic distribution and traffic-aware dynamic scheduling, enabling Kubernetes to better adapt to the complex load changes in the edge computing environment.

[0051] Referring to Figure 1 As shown, the present invention relates to a traffic distribution and computing resource scheduling method, including:

[0052] In edge computing, obtaining the traffic of user requests;

[0053] Processing the traffic of user requests through a two-layer load balancing mechanism, where the two-layer load balancing mechanism includes an upper-layer load balancing mechanism and a lower-layer load balancing mechanism. The upper-layer load balancing mechanism is used for traffic distribution to edge nodes, and the lower-layer load balancing mechanism is used for scheduling computing resources (in this embodiment, Pods are defined as computing resources) according to the traffic distribution result.

[0054] The following is a detailed introduction to this embodiment:

[0055] The two-layer load balancing mechanism proposed in this embodiment aims to optimize the performance of Kubernetes (abbreviated as K8s) in the edge computing environment. This two-layer load balancing mechanism combines the resource status and network performance of edge nodes (the essence of edge nodes is physical / virtual computing devices), and realizes short-term latency optimization and long-term resource balance through the traffic distribution of the upper-layer load balancing mechanism and the resource scheduling of the lower-layer load balancing mechanism.

[0056] Specifically, the upper-layer load balancing mechanism focuses on real-time performance. By monitoring the remaining CPU rate, remaining memory rate, and network latency of each edge node, it dynamically optimizes the request path, enables requests to be processed locally first, and forwards them to the optimal remote node when resources are limited, thereby reducing cross-node transmission latency and balancing the load. The lower-layer load balancing mechanism mainly focuses on long-term optimization. By globally monitoring traffic, it dynamically adjusts Pod deployment, enabling high-traffic areas to obtain more computing resources, thereby improving the overall system throughput and resource utilization.

[0057] Please refer to Figure 2 , Figure 2 shows the overall architecture of the two-layer load balancing mechanism, and the upper and lower layer mechanisms cooperate with each other to improve the overall system performance. Figure 2It shows the flow of user requests, the upper-layer load balancing mechanism, the lower-layer load balancing mechanism, and the interaction between the two, clearly presenting the load balancing optimization process.

[0058] Upper-layer load balancing mechanism: It monitors the resource status (such as CPU / memory utilization) and network latency of nodes in real time, calculates the optimal target node based on a comprehensive scoring model, and thus dynamically determines the request distribution strategy. The goal of this mechanism is to achieve traffic balance in the short term and reduce request processing latency.

[0059] Lower-layer load balancing mechanism: Based on the traffic data recorded in the Redis database, it calculates the traffic weights of each edge region and dynamically adjusts the Pod deployment accordingly to optimize the long-term utilization rate of computing resources, so as to more effectively handle load changes and improve system throughput.

[0060] Collaborative optimization of the upper-layer load balancing mechanism and the lower-layer load balancing mechanism: By comprehensively considering the node resource status and traffic dynamic changes, the goal of low latency, high throughput, and resource balance is finally achieved.

[0061] (1) Upper-layer load balancing mechanism

[0062] The core idea of the upper-layer load balancing is to dynamically adjust the request distribution strategy by real-time sensing the resource status (such as CPU and memory usage) and network latency of each node. The specific goals include:

[0063] (1) Reduce cross-node transmission latency: Prioritize distributing requests to local nodes, thereby reducing network latency and transmission time. Especially in the edge computing environment, data transmission latency directly affects the user experience, so reducing cross-node transmission is crucial.

[0064] (2) Dynamic traffic allocation: Dynamically adjust the request allocation according to the resource usage and network latency of nodes to avoid node overload, ensure cluster load balancing, and achieve efficient utilization of resources.

[0065] (3) Improve system throughput: Through reasonable traffic scheduling, ensure efficient distribution of traffic, enable the system to handle more requests, and avoid performance bottlenecks caused by insufficient node resources.

[0066] In this embodiment, the core of the resource-aware traffic distribution mechanism is to calculate the comprehensive score through a comprehensive scoring model. This comprehensive scoring model calculates the comprehensive score S of the edge node through the remaining CPU rate, remaining memory rate, and network latency of the node i , providing a basis for request distribution. Specifically, the comprehensive score S of node i i is defined as follows:

[0067]

[0068] Among them, S i represents the comprehensive score of node i, with a range of [0, 1]. The higher the value of S i , the more suitable the node is for processing requests, which is jointly determined by the resource status and network latency; w cpu , w mem , w lat are the weights of the remaining CPU rate, remaining memory rate, and network latency of the node respectively, and satisfy w cpu + w mem + w lat = 1, respectively represent the remaining CPU rate and remaining memory rate of node i, represents the network latency normalization value of node i.

[0069] Furthermore, the remaining CPU rate and remaining memory rate of node i are calculated by the following formulas respectively:

[0070]

[0071] Among them, and are the used CPU and memory resources of node i respectively, and are the total CPU and memory resources of node i respectively.

[0072] Furthermore, the network latency normalization value of node i represents the relative value of the network latency of node i, and the formula is:

[0073]

[0074] Among them, RTT i represents the network round-trip time of node i, and RTT max represents the maximum network latency among all candidate nodes.

[0075] Through the above comprehensive scoring model, the processing capabilities and adaptabilities of each edge node can be dynamically evaluated. By comprehensively considering the sufficiency of computing resources and network performance, it provides a scientific decision-making basis for request distribution.

[0076] The upper-layer load balancing mechanism based on resource awareness is based on the comprehensive scoring model. By real-time monitoring the resource status (CPU, memory) and network performance (RTT) of each edge node, it dynamically selects target nodes to optimize the request allocation path. While reducing the cross-node transmission latency, this mechanism ensures balanced resource allocation, thereby improving the overall throughput and response efficiency of the system. The specific implementation steps are as follows:

[0077] Step 1: Initialize the node set: Define a set that includes the current node LocalNode (local node) and the set of remote nodes Endpoints, and collect the resource status information (such as CPU and memory utilization) and network latency (RTT) of each node; among them, the local node is the edge node that initially receives the traffic of the user request, and the remote node is other edge nodes that are not local nodes;

[0078] Step 2: Determine whether the local node is overloaded: If the CPU or memory utilization of the current node LocalNode exceeds the threshold Threshold, go to Step 3; otherwise, directly return LocalNode as the TargetNode (target node), and process the traffic through the target node;

[0079] Step 3: Calculate the comprehensive score of the remote nodes: Traverse the set of remote nodes Endpoints, and calculate the comprehensive score S for each node i i ;

[0080] Step 4: Select the optimal remote node: Select the node BestNode with the highest comprehensive score S i as the TargetNode (target node), and process the traffic through the target node;

[0081] Step 5: Return and output the TargetNode (target node) to complete the scheduling.

[0082] (2) Lower-layer load balancing mechanism

[0083] In the default Pod scheduling mechanism of Kubernetes, Pods are mainly scheduled according to the static resource status of nodes (such as CPU and memory utilization), without considering the dynamic changes of traffic. However, in the edge computing environment, client requests are often affected by geographical location, network topology, and user behavior, resulting in uneven distribution of load among different nodes, which may cause the following problems: (1) Insufficient resources in high-traffic edge regions (Edge Region), resulting in request backlogs and increased response latency; (2) Waste of resources in low-traffic edge regions, resulting in a decrease in the overall throughput of the cluster; (3) Fixed scheduling strategies cannot adapt to dynamic traffic changes, affecting the quality of service (QoS) of the system.

[0084] This embodiment designs a lightweight traffic monitoring mechanism, which can efficiently record and store the traffic data of each node, thereby providing an accurate basis for scheduling decisions. The acquisition of traffic data is completed by the Proxy service deployed on each node. This service is responsible for recording all access requests of the node and storing the data in the Redis database in the form of key-value pairs. The format of the key is: Key = aslp:http_request_count:node_name, and the Key value is the cumulative number of access requests of the current node. This method not only solves the problem of inaccurate traffic statistics in the traditional solution but also avoids the impact of historical data backlog on system performance by cleaning up the processed data.

[0085] After obtaining the traffic data, first, according to the node traffic data T recorded in the Redis database node summarize and calculate the total traffic volume T of each edge area (the edge area includes several edge nodes) location , and then further calculate the global total traffic volume T total :

[0086]

[0087] Based on this, calculate the traffic weight W of each edge area location :

[0088]

[0089] The traffic weight W location reflects the relative demand for traffic in the edge area and will be used as the basis for Pod scheduling and allocation in the future.

[0090] Based on the calculation result of the traffic weight, this embodiment further designs a dynamic scheduling strategy. By combining the traffic demand of the edge area and the node resource status, the deployment location of the Pod is dynamically adjusted. A Pod (container) is equivalent to an application program. In this embodiment, a Pod is defined as a generalized computing resource (its essence is a task unit that uses computing resources in Kubernetes, and it must be deployed on an edge node for the edge node to execute computing tasks). The Pod scheduling strategy specifically includes the following steps:

[0091] Step 1: Calculate the expected number of Pods. According to the traffic weight W of the edge area location and the total number of global Pods P total , calculate the expected number of Pods in the edge area. The formula is:

[0092]

[0093] At the same time, obtain the current number of Pods in the edge area and calculate ΔP location(The difference between the expected Pod and the actual Pod), the formula is:

[0094]

[0095] Step 2: Deploy the adjustment strategy. According to ΔP location value, dynamically adjust the deployment of Pods in the edge area. When ΔP location > 0, add Pods in the edge area, and preferentially schedule Pods on nodes with sufficient resources in the edge area. At the same time, follow the anti-affinity rules of Kubernetes to ensure the balanced distribution of Pods on nodes in the edge area; when ΔP location < 0, release redundant Pods in the edge area, select nodes with higher resource loads to release Pods first, and at the same time ensure that at least one Pod in the edge area provides services to avoid service interruption.

[0096] Step 3: Update the scheduling rules and clean up the data. After the scheduling is completed, the Operator updates the node scheduling rules of the Deployment and makes the scheduling strategy effective through the Kubernetes API. At the same time, clear the processed traffic data in the Redis database to prepare for the next round of scheduling.

[0097] The experimental analysis is as follows:

[0098] To verify the effectiveness of the proposed two-layer load balancing mechanism in this embodiment, this embodiment compares the performance of the default Kubernetes load balancing strategy and this embodiment in the edge computing environment through multiple aspects such as experimental environment setup, key performance indicator analysis, and experimental result evaluation. The main goal of the experiment is to evaluate the optimization effect of this method in terms of request response time, system throughput, and resource utilization, and further analyze the respective contributions of the upper-layer load balancing mechanism (resource-aware traffic distribution) and the lower-layer load balancing mechanism (traffic-aware dynamic Pod scheduling) through ablation experiments.

[0099] Experimental environment

[0100] To verify the performance improvement effect of the proposed two-layer load balancing mechanism in the Kubernetes edge computing environment, a Kubernetes cluster was built for the experiment, and strict testing and data collection were carried out. The experimental environment consists of 1 master node and 4 worker nodes, each node is configured with 4-core CPU and 8GB of memory, and runs the Ubuntu 20.04 operating system. The cluster is managed by Kubernetes v1.23, and all applications are deployed in a containerized manner and use Docker20.10 as the container runtime environment.

[0101] The experimental application is managed in the Deployment mode, and the number of Pod replicas is set to a fixed value to eliminate the interference factors of scaling. The load generation tool uses the Apache HTTP Server Benchmarking (AB) tool, which can simulate client requests with different traffic distributions and measure the throughput and request latency of the system. In addition, the traffic monitoring and scheduling mechanism in the experiment is completely based on Redis for data collection to ensure that the traffic status of each node can be recorded in real time during the experiment and provide support for the dynamic scheduling of the underlying load balancing.

[0102] To study the impact of network latency between worker nodes on the overall performance of the cluster, different network latency configurations are introduced in the experimental environment, and the Linux tc tool is used to artificially set the network latency between worker nodes to ensure the controllability of the experimental environment.

[0103] This experiment compares the following four load balancing strategies to evaluate the performance of different solutions in the Kubernetes cluster:

[0104] 1) Default load balancing (Kubernetes default policy): The kube-proxy component is used to distribute requests based on the round-robin method without considering resource status and network latency;

[0105] 2) Only optimize the upper-layer load balancing mechanism (resource-aware traffic distribution): Dynamically adjust the request distribution path based on CPU, memory, and network latency to optimize the overall response time of the system;

[0106] 3) Only optimize the lower-layer load balancing mechanism (traffic-aware dynamic Pod scheduling): Dynamically adjust the Pod deployment location under uneven request loads to optimize resource utilization and system throughput;

[0107] 4) Combine upper and lower-layer optimizations (global load balancing): Simultaneously adopt the upper-layer load balancing mechanism and the lower-layer load balancing mechanism to achieve the optimal overall load balancing of the system.

[0108] 3.1.3 Evaluation Metrics

[0109] In this experiment, this embodiment uses throughput and response time as the core evaluation metrics to measure the performance of different load balancing strategies under different request patterns and network environments.

[0110] (1) Throughput is used to measure the number of requests processed by the system per unit time and is a key indicator to measure the overall processing ability of the system. Its definition is as follows:

[0111]

[0112] Among them, T represents the throughput, with the unit of requests per second (reqs / s); N represents the total number of requests successfully processed during the experimental period; t represents the total running time of the experiment, with the unit of seconds. A higher throughput indicates that the system can process more requests per unit time, meaning higher load processing capacity.

[0113] (2) The response time represents the time from when the system receives a request to when it returns a response, reflecting the service efficiency and user experience of the system. Its calculation formula is as follows:

[0114]

[0115] Among them: R represents the average response time, with the unit of milliseconds (ms); t start,i represents the time when the i-th request arrives at the system; t end,i represents the time when the i-th request is processed and the result is returned; N represents the total number of requests. A lower response time indicates that the system can process requests faster, improving the user experience.

[0116] Experimental design

[0117] (1) Threshold experiment of the upper-layer traffic distribution algorithm

[0118] Before the formal experiment, it is necessary to determine the optimal threshold (Threshold) of the upper-layer traffic distribution algorithm to ensure that request distribution can achieve an optimal balance between resource availability and network latency. Therefore, in this paper, the throughput and request response time of the system under different thresholds (60% to 100%) were tested in the experimental environment, and the impact of the threshold on the load balancing effect was analyzed.

[0119] The experiment first set the initial threshold threshold to 60%, and then increased it in steps of 5% up to 100%. Under each threshold setting, 10 rounds of experiments were conducted, and each round of experiment lasted for 300 seconds to ensure the stability of the experimental data. The throughput and average request response time of the system were recorded, and their means were taken. The experimental data are as Figure 3 and Figure 4 shown.

[0120] It can be observed from the experimental results that the throughput gradually increases with the increase of the threshold and tends to be stable near 90% ( Figure 3 ), which indicates that a higher threshold enables more requests to be preferentially processed on local nodes, thereby reducing the cross-node communication overhead, lowering the network latency, and helping to improve the overall system throughput. However, when the threshold further increases (higher than 95%), the load of local nodes approaches saturation, the processing capacity decreases, resulting in a backlog in the request processing queue, and the response time slightly increases (Figure 4 ) Based on experimental analysis, 90% was finally selected as the default threshold for the upper-layer traffic distribution algorithm to balance throughput improvement and response time optimization.

[0121] (2) Experiment on the impact of network latency between worker nodes on cluster performance

[0122] In this subsection, the impact of network latency between worker nodes on different load balancing strategies is analyzed. In the experiment, the client was set to send 100 concurrent requests to each worker node simultaneously, and network latencies of 3ms, 6ms, 9ms, 12ms, and 15ms were artificially set through the Linux tc tool. The throughput and response time were measured under different strategies, and the experimental data are as Figure 5 and Figure 6 shown ( Figure 5 and Figure 6 the upper-layer optimization strategy in

[0123] The experimental results show that as the network latency increases, the throughput of the default load balancing strategy decreases significantly, and the response time increases substantially. For example, when the inter-node latency is 3ms, the system throughput is approximately 1700reqs / s, while it drops to 800reqs / s at 15ms, with an overall decrease of 52.94%. This phenomenon is mainly because the default load balancing strategy uses round-robin scheduling, resulting in an increase in cross-node traffic, introducing additional network overhead, and thus affecting the throughput capacity and service quality.

[0124] In contrast, the upper-layer load balancing mechanism reduces cross-node communication through local priority scheduling, keeping the throughput at 2300reqs / s under all network latency conditions, with a 35.29% - 187.5% increase compared to the default strategy and an average increase of 96.41%. In addition, the request processing latency of the optimization strategy always remains stable at 10ms, while the default strategy increases from 22ms to 85ms as the network latency increases, with the response time reduction reaching up to 88.24% and an average reduction of 76.79%. This indicates that the optimization strategy can effectively reduce the request processing latency and improve the system throughput in a high network latency environment.

[0125] In a high network latency environment, the increase in cross-node communication will lead to a decline in QoS and affect the overall stability of the system. Especially in edge computing scenarios, this optimization strategy provides better QoS guarantee for latency-sensitive applications by intelligent scheduling, reducing cross-node traffic, and optimizing resource utilization. Therefore, considering the network latency between worker nodes and adopting an optimized load balancing strategy is the key to improving system performance and service quality.

[0126] (3) Experiment on the impact of client request distribution on load balancing strategies

[0127] This experiment aims to study the impact of different client request distribution patterns on load balancing strategies. To this end, this embodiment designs three request distribution patterns: centralized request distribution, evenly distributed distributed requests, and unevenly distributed distributed requests. Under these patterns, this embodiment evaluates the performance of the default load balancing strategy, the upper-layer load balancing mechanism, the lower-layer load balancing mechanism, and the upper and lower layer load balancing mechanisms respectively. The focus of the experiment is to examine the impact of these strategies on throughput and response time under different request distribution patterns.

[0128] In the experiment, this embodiment uses the Apache HTTP Server Benchmarking (AB) tool to generate the load. The experimental environment consists of 4 worker nodes, and the same number of Pods are deployed on each node. The total number of requests is fixed at 10,000, and the number of concurrent requests sent per second is set to 1,000 to simulate different load conditions. The request distribution patterns are as follows:

[0129] (1) Centralized request distribution (1000:0:0:0)

[0130] Under this pattern, all concurrent requests (1,000 requests per second) are sent to a single worker node, and the remaining nodes have no load. This pattern is used to examine the scenario of highly uneven load and test the adaptability of the load balancing strategy in this case.

[0131] (2) Evenly distributed distributed requests (250:250:250:250)

[0132] Under this pattern, 1,000 concurrent requests per second from the client are evenly distributed to four worker nodes, that is, each node receives 250 concurrent requests. This pattern simulates the ideal scenario of balanced load and is used to verify the performance of different load balancing strategies under balanced load conditions.

[0133] (3) Unevenly distributed distributed requests (100:200:300:400)

[0134] Under this pattern, 1,000 concurrent requests per second from the client are proportionally distributed to four worker nodes, receiving 100, 200, 300, and 400 concurrent requests respectively. This pattern is used to test the performance of the load balancing strategy and the impact of lower-layer Pod resource scheduling under unbalanced load conditions.

[0135] The experimental results are as Figure 7 shown, Figure 7 showing the throughput comparison under different request distribution patterns.

[0136] In the centralized request mode, all requests are concentrated on a single node. The default load balancing policy evenly distributes the requests to each node, resulting in increased latency for cross-node forwarding, decreased throughput, and increased response time. In contrast, the upper-layer load balancing mechanism reduces the network latency of remote forwarding by preferentially allocating requests to local nodes, increasing the throughput by 55.56% and significantly reducing the response time. The lower-layer load balancing mechanism further optimizes the load distribution by dynamically adjusting the Pod deployment to provide more computing resource support for high-load nodes, increasing the throughput by 66.67%. Overall, after combining the upper and lower-layer load balancing mechanisms, the intelligent traffic scheduling and dynamic resource adjustment are fully utilized, increasing the throughput by 94.44%, achieving the best performance, the highest throughput, and the shortest response time in this mode.

[0137] In the evenly distributed request mode, since the request load is already evenly distributed, the default load balancing policy can better distribute the traffic, so the role of the optimization policy is relatively limited. Nevertheless, the upper-layer load balancing mechanism can still reduce some forwarding latency, increasing the throughput by 84.00% to reach 4600 reqs / s and further reducing the response time. The impact of the upper-layer load balancing mechanism is relatively small because the load is more balanced at this time and large-scale adjustment of Pod resource scheduling is no longer required. After combining the upper and lower-layer load balancing mechanisms, the throughput is slightly higher than that of the upper-layer optimization alone, but the overall improvement is small, still showing an optimization advantage, and finally increasing by 88.00%.

[0138] In the unevenly distributed request mode, some nodes carry more load while other nodes are relatively idle. The default load balancing policy cannot effectively identify the load hotspots, resulting in low resource utilization of some nodes while high-load nodes become bottlenecks. The upper-layer load balancing mechanism optimizes the traffic distribution path and guides the requests to the nodes with lower load, increasing the throughput by 45.45%. The lower-layer load balancing mechanism enhances the resource support of high-load nodes by dynamically adjusting the Pod deployment, increasing the throughput by 13.64%. When the upper and lower-layer load balancing mechanisms are combined, their advantages complement each other, finally increasing the throughput by 81.82% and achieving the best performance in terms of throughput and response time.

[0139] Overall, the upper and lower-layer load balancing mechanisms increase the throughput by an average of 88.75% in different request distribution modes, significantly outperforming the upper-layer optimization alone (61.67%) or the lower-layer optimization (28.77%). This shows that the combined strategy of the upper and lower-layer load balancing mechanisms can maximize the throughput capacity and effectively reduce the impact of load imbalance on system performance, enabling it to maintain excellent performance in different load scenarios.

[0140] Example 2

[0141] This embodiment provides a traffic distribution and computing resource scheduling system, including:

[0142] An acquisition module: used to acquire the traffic of user requests in edge computing;

[0143] A distribution and scheduling module: used to process the traffic of user requests through a two-layer load balancing mechanism, where the two-layer load balancing mechanism includes an upper-layer load balancing mechanism and a lower-layer load balancing mechanism. The upper-layer load balancing mechanism is used to distribute traffic to edge nodes, and the lower-layer load balancing mechanism is used to schedule computing resources according to the traffic distribution results of edge nodes.

[0144] Embodiment Three

[0145] This embodiment provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of the traffic distribution and computing resource scheduling method described in Embodiment One are implemented.

[0146] Embodiment Four

[0147] This embodiment provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the traffic distribution and computing resource scheduling method described in Embodiment One are implemented.

[0148] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of the present application can be implemented in various computer languages, for example, object-oriented programming languages such as Java and interpreted scripting languages such as JavaScript.

[0149] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable data processing devices to generate a machine, so that the instructions executed by the processors of the computer or other programmable data processing devices generate for implementation in the process Figure 1 [[ID=Figure 1 means for the functions specified in one or more boxes.

[0150] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to work in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction means that implements the functions specified in one Figure 1 process or more processes and / or boxes Figure 1 or more boxes.

[0151] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus, such that a series of operational steps are performed on the computer or other programmable apparatus to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions specified in one Figure 1 process or more processes and / or boxes Figure 1 or more boxes.

[0152] Although the preferred embodiments of the present application have been described, those skilled in the art can make additional changes and modifications once they learn the basic creative concepts. Therefore, the appended claims are intended to be construed to include the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0153] Obviously, the above embodiments are merely examples for clear illustration and not limitations on the implementation manners. For those of ordinary skill in the art, other different forms of changes or variations can be made based on the above description. It is not necessary and impossible to enumerate all implementation manners here. And the obvious changes or variations derived therefrom are still within the protection scope of the present invention.

Claims

1. A traffic distribution and computing resource scheduling method, characterized in that: Including: In edge computing, obtaining the traffic of user requests; Processing the traffic of user requests through a two-layer load balancing mechanism, where the two-layer load balancing mechanism includes an upper-layer load balancing mechanism and a lower-layer load balancing mechanism. The upper-layer load balancing mechanism is used to distribute traffic to edge nodes, and the lower-layer load balancing mechanism is used to schedule computing resources according to the traffic distribution result.

2. The traffic distribution and computing resource scheduling method according to claim 1, characterized in that: The method by which the upper-layer load balancing mechanism is used to distribute traffic to edge nodes includes: Obtaining the local node and each remote node, determining whether the CPU utilization rate or memory utilization rate of the local node exceeds the threshold. If so, calculating the comprehensive score of each remote node, and taking the remote node with the highest comprehensive score as the target node and processing the traffic; if not, taking the local node as the target node and processing the traffic, where the local node is the edge node that initially receives the traffic of user requests, and the remote node is other edge nodes that are not local nodes.

3. The traffic distribution and computing resource scheduling method according to claim 2, wherein: The comprehensive score includes the CPU remaining rate, the memory remaining rate, and the network latency. The formula is: Among them, S i represents the comprehensive score of node i, with a range of [0, 1]; w cpu , w mem , w lat are the weights of the CPU remaining rate, memory remaining rate, and network latency of the node respectively, and satisfy w cpu + w mem + w lat = 1; respectively represent the CPU remaining rate and memory remaining rate of node i, represents the network latency normalization value of node i.

4. The traffic distribution and computing resource scheduling method according to claim 3, wherein: CPU remaining rate of node i and memory remaining rate The formulas are respectively as follows: Among them, and are the used CPU and memory resources of node i respectively, and are the total CPU and memory resources of node i respectively.

5. The traffic distribution and computing resource scheduling method according to claim 3, wherein: The network delay normalization value of node i The formula is as follows: Among them, RTT i represents the network round-trip time of node i, and RTT max represents the maximum network latency among all candidate nodes.

6. The traffic distribution and computing resource scheduling method according to claim 1, wherein: The method by which the lower-layer load balancing mechanism is used to schedule computing resources according to the traffic distribution result includes: According to the edge region traffic weight W location and the total number of global Pods P total , calculate the expected number of Pods in the edge region. The formula is: Get the current number of Pods in the edge area Calculate ΔP location , the formula is: Dynamically adjust the deployment of Pods in the edge area according to the value of ΔP location : When ΔP location > 0, add Pods in the edge area; when ΔP location < 0, release redundant Pods in the edge area and ensure that at least one Pod provides services in the edge area, where the edge area includes a number of edge nodes; Pods are computing resources deployed on edge nodes to enable edge nodes to process traffic data.

7. The traffic distribution and computing resource scheduling method according to claim 6, wherein: The calculation method of the edge area traffic weight W location includes: After obtaining traffic data at the edge node, according to the node traffic data T node Aggregate and calculate the total traffic volume T of each edge area location , and then calculate the global total traffic volume T total , the formula is: Calculate the flow weight W of each edge region location , and the formula is as follows:

8. A traffic distribution and computing resource scheduling system, characterized in that: Including: An obtaining module: used to obtain the traffic of user requests in edge computing; A distribution and scheduling module: used to process the traffic of user requests through a two-layer load balancing mechanism, where the two-layer load balancing mechanism includes an upper-layer load balancing mechanism and a lower-layer load balancing mechanism. The upper-layer load balancing mechanism is used to distribute traffic to edge nodes, and the lower-layer load balancing mechanism is used to schedule computing resources according to the traffic distribution result.

9. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that: When the processor executes the computer program, it implements the steps of the traffic distribution and computing resource scheduling method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the traffic distribution and computing resource scheduling method according to any one of claims 1 to 7.

Images