Load balancing method and device, electronic equipment and storage medium

Abstract

The invention provides a load balancing method and device, electronic equipment and a storage medium, and relates to the technical field of servers, load monitoring is carried out on resource nodes in a server, load monitoring data is acquired, virtual machines are deployed in the resource nodes, and computing services of the virtual machines are bound to the resource nodes of corresponding classifications according to service types; performing load prediction on the resource nodes to obtain load prediction data; determining whether to migrate the virtual machine to other resource nodes according to the load monitoring data and the load prediction data; and in response to the determination of migrating the virtual machine to the other resource nodes, migrating the virtual machine to the target resource node, and binding the virtual machine with the target resource node. According to the invention, the load monitoring is combined with the service type binding mechanism, so that accurate matching between the resource node and the virtual machine demand can be ensured, and waste caused by resource mismatching is avoided. The virtual machine is actively migrated to the low-load node through load prediction, and the node load balance degree can be improved.

Description

Technical Field

[0001] The present disclosure relates to the field of server technology, and in particular to a load balancing method and device, an electronic device, and a storage medium. Background Art

[0002] With the development of multi-core servers, NUMA technology has become a key performance enabler. Its architecture divides the CPU and memory into multiple logical nodes, with intra-node communication via the IMC bus and inter-node interconnection relying on QPI, resulting in significantly higher latency. Current virtualization platforms (such as VMware) are inadequately adapted to NUMA, resulting in a lack of topology-aware memory allocation, frequent cross-node accesses, and limited resource utilization. Existing technologies employ static binding or purely dynamic scheduling. The former struggles to adapt to load fluctuations, while the latter destroys initial locality, creating a fundamental conflict between resource locality and load balancing. Existing virtual machine NUMA scheduling schemes fail to fully consider the synergy between memory bandwidth, latency, and service characteristics, leading to core binding failures, excessive cross-node access rates, and irrational resource allocation. Dynamic migration can also cause performance jitter, impacting business continuity. In high-concurrency, memory-sensitive scenarios, traditional approaches struggle to balance resource isolation and flexible scheduling, resulting in load imbalances on hotspot nodes, reduced throughput, and increased response latency. Summary of the Invention

[0003] The present disclosure provides a load balancing method and apparatus, an electronic device, and a storage medium, the main purpose of which is to solve the problem of inflexible scheduling when running a large number of services.

[0004] According to a first aspect of the present disclosure, a load balancing method is provided, comprising: Monitor the load of resource nodes in the server and obtain load monitoring data. Virtual machines are deployed on the resource nodes, and the computing services of the virtual machines are bound to resource nodes of corresponding categories according to the service types. Perform load prediction on resource nodes to obtain load prediction data; Determine whether to migrate the virtual machine to other resource nodes based on load monitoring data and load forecast data; In response to determining to migrate the virtual machine to another resource node, the virtual machine is migrated to the target resource node, and the virtual machine is bound to the target resource node.

[0005] Optionally, perform load prediction on the resource node to obtain load prediction data, including: Get the current load data of each resource node; The current load data is input into the load prediction model for load prediction, the load changes of each resource node within a preset time period are predicted, and the load prediction data of each resource node is generated.

[0006] Optionally, determining whether to migrate the virtual machine to another resource node based on load monitoring data and load forecast data includes: If the load monitoring data exceeds the preset load threshold, the virtual machine is determined to be migrated to another resource node; If the load prediction data exceeds the predicted load threshold, it is determined to migrate the virtual machine to another resource node.

[0007] Optionally, the load balancing method also includes: Obtain the node classification of each resource node and allocate computing services to resource nodes of corresponding classification based on service types.

[0008] Optionally, computing services are assigned to resource nodes of corresponding categories based on service types, including: Classify each resource node using the node evaluation parameters to obtain the node classification of each resource node; According to the node classification corresponding to the business type, the computing business is allocated to the resource nodes of the corresponding classification.

[0009] Optionally, node evaluation parameters include: resource topology data and operating status data; The node evaluation parameters of each resource node are used for classification to obtain the node classification of each resource node, including: Obtain resource topology data and operation status data of each resource node; Evaluate each resource node based on the resource topology data to obtain performance evaluation data, and evaluate each resource node based on the operation status data to obtain operation evaluation data; Each resource node is classified according to the performance evaluation data and the operation evaluation data to obtain a node classification of each resource node.

[0010] Optional business types include: memory-sensitive and general computing; node classifications include: performance and load. Based on the node classification corresponding to the business type, the computing business is allocated to the resource nodes under the corresponding node classification, including: If the computing business is memory-sensitive, the computing business will be allocated to the resource node corresponding to the performance classification; If the computing business is a general computing business, the computing business will be allocated to the resource node corresponding to the load classification.

[0011] Optionally, the load balancing method also includes: Configure and bind computing services to the resource nodes to which they are allocated.

[0012] Optionally, bind the computing service to the allocated resource node, including: Allocate memory resources to computing services and resource nodes according to service types; Based on the allocated memory resources, the computing business is bound to the allocated resource nodes.

[0013] Optionally, the load balancing method also includes: Preprocess the historical load data of each resource node to generate load data for training; The load prediction model to be trained is iteratively trained using the training load data to generate a trained load prediction model.

[0014] Optionally, the load balancing method also includes: Monitor the memory of each resource node and obtain cross-node access data of each resource node; Adjust the binding relationship between virtual machines and resource nodes based on cross-node access data.

[0015] According to a second aspect of the present disclosure, a load balancing device is provided, comprising: A monitoring unit is used to monitor the load of resource nodes in the server and obtain load monitoring data. The resource nodes are deployed with virtual machines, and the computing services of the virtual machines are bound to resource nodes of corresponding categories according to the service types. A prediction unit, configured to perform load prediction on resource nodes and obtain load prediction data; A determination unit, configured to determine whether to migrate the virtual machine to another resource node based on the load monitoring data and the load prediction data; The migration unit is configured to, in response to determining to migrate the virtual machine to another resource node, migrate the virtual machine to a target resource node and bind the virtual machine to the target resource node.

[0016] Optionally, the prediction unit includes: The acquisition module is used to obtain the current load data of each resource node; The prediction module is used to input the current load data into the load prediction model to perform load prediction, predict the load changes of each resource node within a preset time period, and generate load prediction data for each resource node.

[0017] Optionally, the determining unit includes: A first determining module is configured to determine to migrate the virtual machine to another resource node if the load monitoring data exceeds a preset load threshold; The second determining module is configured to determine to migrate the virtual machine to another resource node if the load prediction data exceeds a predicted load threshold.

[0018] Optionally, the load balancing device further includes: The allocation unit is used to obtain the node classification of each resource node and allocate the computing business to the resource node of the corresponding classification based on the business type.

[0019] Optionally, the allocation unit includes: A classification module is used to classify each resource node using the node evaluation parameters of each resource node to obtain a node classification of each resource node; The first allocation module is used to allocate computing services to resource nodes of corresponding classifications according to the node classifications corresponding to the service types.

[0020] Optionally, node evaluation parameters include: resource topology data and operating status data; The classification module is also used to: Obtain resource topology data and operation status data of each resource node; Evaluate each resource node based on the resource topology data to obtain performance evaluation data, and evaluate each resource node based on the operation status data to obtain operation evaluation data; Each resource node is classified according to the performance evaluation data and the operation evaluation data to obtain a node classification of each resource node.

[0021] Optional business types include: memory-sensitive and general computing; node classifications include: performance and load. The first allocation module is further configured to: If the computing business is memory-sensitive, the computing business will be allocated to the resource node corresponding to the performance classification; If the computing business is a general computing business, the computing business will be allocated to the resource node corresponding to the load classification.

[0022] Optionally, the load balancing device further includes: The binding unit is used to configure and bind the computing business with the resource nodes to which it is allocated.

[0023] Optionally, the binding unit includes: A second allocation module is used to allocate memory resources to computing services and resource nodes allocated thereto according to service types; The binding module is used to bind computing services to the allocated resource nodes based on the allocated memory resources.

[0024] Optionally, the load balancing device further includes: A generation unit, used to pre-process the historical load data of each resource node to generate load data for training; The training unit is used to iteratively train the load prediction model to be trained using the training load data to generate a trained load prediction model.

[0025] Optionally, the load balancing device further includes: The acquisition unit is used to monitor the memory of each resource node and obtain the cross-node access data of each resource node; The adjustment unit is used to adjust the binding relationship between the virtual machine and the resource node based on cross-node access data.

[0026] According to a third aspect of the present disclosure, there is provided an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the load balancing method described in the first aspect.

[0027] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable the computer to execute the load balancing method described in the first aspect.

[0028] According to a fifth aspect of the present disclosure, a computer program product is provided, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the load balancing method as described in the first aspect.

[0029] The present disclosure provides a method and device for load balancing, an electronic device and a storage medium, which relate to the field of server technology. By combining load monitoring with a business type binding mechanism, it can ensure that resource nodes are accurately matched with virtual machine requirements, avoiding waste caused by resource mismatch. By identifying potential overloaded nodes in advance through load prediction and actively migrating virtual machines to low-load nodes, the node load balance can be improved, the proportion of hot nodes can be significantly reduced, and the overall computing power of the server can be released. After the virtual machine is migrated, it is forcibly bound to the target node, which can greatly reduce cross-node memory access. Preventive migration based on load prediction can reduce the risk of business interruption caused by sudden loads.

[0030] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The accompanying drawings are provided to facilitate a better understanding of the present invention and do not constitute a limitation of the present disclosure. Figure 1 A flow chart of a load balancing method provided by an embodiment of the present disclosure; Figure 2A schematic diagram of the structure of a load balancing device provided in an embodiment of the present disclosure; Figure 3 A schematic structural diagram of another load balancing device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0032] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding. These details should be considered as merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0033] The following describes the load balancing method and apparatus, electronic device, and storage medium according to the embodiments of the present disclosure with reference to the accompanying drawings.

[0034] Figure 1 A flow chart of a load balancing method provided in an embodiment of the present disclosure.

[0035] like Figure 1 As shown, the method comprises the following steps: Step 101: load monitoring is performed on resource nodes in the server to obtain load monitoring data. Virtual machines are deployed on the resource nodes, and computing services of the virtual machines are bound to resource nodes of corresponding categories according to service types.

[0036] In the embodiments of the present disclosure, in the NUMA architecture of the server, a resource node refers to a logical node with an independent CPU core, memory resources and an integrated memory controller. Each node realizes internal communication through the IMC bus, and the nodes rely on QPI for data exchange. For the load monitoring of these resource nodes, it is necessary to use system tools to collect multi-dimensional indicators in real time to form load monitoring data, including but not limited to key parameters such as the CPU utilization rate of each node, memory bandwidth occupancy rate, cross-node access rate, memory capacity usage and inter-node communication delay. The acquisition of these data provides a real-time basis for subsequent resource scheduling decisions, and can accurately reflect the current load status of each resource node. At the same time, considering that the resource requirements of different computing services are significantly different, the computing services of the virtual machine need to be bound to the resource nodes of the corresponding classification according to the service type. Memory-sensitive businesses (such as database services), highly sensitive to memory access latency, must be bound to high-performance nodes with high memory bandwidth and low local access latency. Exclusive node allocation and strict memory isolation policies are implemented to completely avoid performance losses caused by cross-node access. General computing businesses can be bound to high-bandwidth nodes with low current loads, ensuring basic performance while also balancing resource utilization. This categorized binding mechanism, based on business type, ensures the performance stability of critical businesses while laying the foundation for efficient resource utilization, allowing load monitoring data to more specifically reflect the load characteristics of nodes hosting different types of businesses.

[0037] Step 102: Perform load prediction on the resource node to obtain load prediction data.

[0038] In the embodiments of the present disclosure, load forecasting for resource nodes to obtain load forecast data is a process that uses specific forecasting models to predict the resource node's load status for a period of time in the future, based on real-time load monitoring data and historical load information. The forecasting models used here include sliding window forecasting models and LSTM (Long Short-Term Memory) forecasting models. The sliding window forecasting model uses a fixed 5-minute time window, calculates the historical load mean within that window, and analyzes its changing trends, using this as a basis to infer the resource node's load trends in subsequent time periods. The LSTM forecasting model, by learning from a large amount of historical load data, captures the long-term dependencies of load changes, thereby more accurately predicting resource demand for the next 5 minutes. During the forecasting process, a corresponding dynamic threshold is set, typically 1.2 times the base load value. When the load forecast data derived from the forecasting model exceeds this threshold, it indicates that the resource node may be overloaded in the future. These load forecast data can provide early warning of potential load pressure and provide a forward-looking basis for judging whether virtual machine migration is needed later. This helps avoid the performance degradation of resource nodes caused by sudden load growth and ensures that the server system can maintain stable and efficient operation in scenarios with high concurrency and large business volume fluctuations.

[0039] Step 103: Determine whether to migrate the virtual machine to another resource node based on the load monitoring data and the load prediction data.

[0040] In the embodiments of the present disclosure, determining whether to migrate a virtual machine to another resource node based on load monitoring data and load forecast data is a process of comprehensive judgment based on real-time load status and future load trends. Among them, load monitoring data can reflect the current operating status of the resource node in real time, including key indicators such as the node's CPU utilization, memory bandwidth occupancy, and cross-node access rate. When the monitoring data shows that the CPU utilization of a resource node exceeds 80%, the memory bandwidth occupancy reaches 70%, or the cross-node access rate increases abnormally, it means that the node is currently in a high-load state. Continuing to carry virtual machines may cause performance degradation. At this time, a preliminary determination is required to determine whether migration is necessary. The load forecast data is obtained by predicting the load of the resource node for the next 5 minutes based on historical load data using a sliding window forecast model or an LSTM forecast model. When the forecast data shows that the node's future load will exceed a dynamic threshold (usually 120% of the base load value), it means that the node is about to face the risk of overload. In order to avoid the impact of sudden load on the business, it is necessary to determine that preventive migration is required. By combining real-time load monitoring data with forward-looking load forecasting data, we can comprehensively and accurately grasp the load change trends of resource nodes, and thus make accurate decisions on whether to initiate virtual machine migration. This not only ensures that timely measures are taken when the node is currently overloaded, but also ensures that preparations can be made in advance when future overloads are predicted, effectively balancing the system's load balancing and business stability.

[0041] Step 104 : In response to determining to migrate the virtual machine to another resource node, migrate the virtual machine to the target resource node, and bind the virtual machine to the target resource node.

[0042] In an embodiment of the present disclosure, when it is determined that a virtual machine needs to be migrated to another resource node, the target resource node that is suitable for the business type of the virtual machine to be migrated is first selected from idle or low-load nodes based on the resource node's real-time load monitoring data, load prediction data, and a node performance scoring model (this model calculates the node performance score based on a calculation formula of memory bandwidth ratio × 70% and 1 / latency × 30%). For example, for memory-sensitive businesses, nodes with high memory bandwidth and low local access latency are preferentially selected as target nodes. Subsequently, the live migration of the virtual machine is performed using tools such as virsh migrate. During the migration process, the hardware MMU / SMMU isolation mechanism is enabled to ensure the security of memory data during the migration process and avoid data leakage or access conflicts. After the migration is complete, the VM must be immediately bound to the target resource node. The binding method is dynamically selected based on business needs and system configuration. If the static mode with the ENABLE_CPU_PINNING parameter is enabled, the --cpunodebind policy of the numactl tool is used to forcibly bind the VM's vCPU to a specific CPU core on the target node. The --membind policy is used to bind the VM's memory to the local memory area of ​​the node. The 1GB huge page memory pre-allocated for the target node (mounted using --hugetlbfs) is also bound to the VM to reduce page table management overhead. If the migration is in dynamic mode, dynamic vCPU binding at the process level is supported using the taskset tool, allowing for flexible adaptation to load changes. Furthermore, within three seconds of the migration, the system enforces a memory rebinding protocol using the numactl --membind command to ensure that the VM's memory data resides in the local memory of the target node as much as possible, keeping the cross-node access rate below 5%. This ensures optimal performance of the VM on the target resource node, maintaining business continuity and stability.

[0043] The present disclosure provides a load balancing method that ensures accurate matching of resource nodes with virtual machine requirements through load monitoring combined with a business type binding mechanism, thus avoiding waste caused by resource mismatch. By identifying potential overloaded nodes in advance through load prediction and proactively migrating virtual machines to low-load nodes, the node load balance can be improved, the proportion of hot nodes can be significantly reduced, and the overall computing power of the server can be released. After the virtual machine is migrated, it is forcibly bound to the target node, which can significantly reduce cross-node memory access. Preventive migration based on load prediction can reduce the risk of business interruption caused by sudden loads.

[0044] Furthermore, in some embodiments of the present disclosure, the specific implementation methods for the operation of "performing load prediction on resource nodes and obtaining load prediction data" are diverse. For the purpose of clear explanation, the following includes but is not limited to some implementation methods: obtaining current load data of each resource node; inputting the current load data into the load prediction model to perform load prediction, predicting the load changes of each resource node within a preset time period, and generating load prediction data for each resource node.

[0045] Specifically, when performing load forecasting on resource nodes to obtain load prediction data, the current load data for each resource node must first be obtained. This data is derived from real-time load monitoring of the resource nodes and includes, but is not limited to, key metrics such as CPU utilization, memory bandwidth usage, cross-node access rate, memory capacity usage, and inter-node communication latency. This data provides a real-time and comprehensive reflection of the current operational load status of the resource nodes. This data is then fed into a load forecasting model, which employs models such as sliding window and LSTM (Long Short-Term Memory) models. The sliding window model uses a fixed 5-minute window and calculates the historical load average within that window to analyze load trends, thereby inferring the future load trends of the resource nodes over a predetermined period of time. The LSTM model, by learning and training from a large amount of historical load data, can capture long-term dependencies in load fluctuations, enabling more accurate load forecasting of resource nodes. The preset duration is typically set to five minutes into the future, taking into account the periodicity of business load changes and the timeliness of system responses. This ensures sufficient lead time for subsequent scheduling decisions while ensuring the accuracy of the forecast results. These forecasting models process and analyze current load data to generate load forecasts for each resource node within the preset duration. This data clearly demonstrates future load fluctuations at the resource node, such as whether the load will exceed a preset dynamic threshold (typically 1.2 times the base load value), providing important evidence for determining the need for preventative VM migration.

[0046] Furthermore, in some embodiments of the present disclosure, the specific implementation methods for the operation of "determining whether to migrate the virtual machine to other resource nodes based on load monitoring data and load prediction data" are diverse. For the sake of clarity, the following includes but is not limited to some implementation methods: if the load monitoring data exceeds the preset load threshold, it is determined to migrate the virtual machine to other resource nodes; if the load prediction data exceeds the predicted load threshold, it is determined to migrate the virtual machine to other resource nodes.

[0047] Specifically, when determining whether to migrate a virtual machine to another resource node based on load monitoring data and load forecast data, the preset load threshold and the predicted load threshold can be used as a basis for judgment. Among them, the preset load threshold is a real-time load upper limit set based on the performance carrying capacity and business stability requirements of the resource node, including indicators such as CPU utilization exceeding 80% and memory bandwidth occupancy exceeding 70%. The setting of these thresholds refers to the hardware performance parameters of the node (such as CPU core processing power, memory controller bandwidth) and historical load stress test results to ensure that the node can operate stably within the threshold range without a significant performance drop. When any indicator in the load monitoring data exceeds the corresponding preset load threshold, it indicates that the current resource node is already in a high-load state. Continuing to carry the virtual machine will lead to problems such as increased business response delay and increased cross-node access rate. At this time, it is determined that the virtual machine needs to be migrated to another resource node.

[0048] The predicted load threshold is a warning value set for future load fluctuations. It is typically 120% of the resource node's base load value. This threshold is determined by analyzing historical load fluctuations and business growth trends, aiming to proactively identify potential overload risks. When load forecast data obtained by a sliding window prediction model (calculated based on the historical 5-minute load average trend) or an LSTM prediction model exceeds this predicted load threshold, it indicates that the resource node is highly likely to experience overload within a preset timeframe (e.g., 5 minutes). Failure to intervene can cause business performance jitter, necessitating migration of the VM to another resource node.

[0049] By combining these two judgment methods, we can not only respond to the real-time overload of resource nodes in a timely manner, but also avoid possible load pressure in the future in advance, forming a dual judgment mechanism covering real-time and forward-looking, ensuring the timeliness and accuracy of migration decisions. At the same time, it is adapted to the mechanism of binding virtual machines to corresponding resource nodes according to business types, ensuring that the business can still run stably in the adapted node environment after migration.

[0050] Furthermore, in some embodiments of the present disclosure, the load balancing method includes other specific implementation steps in addition to the aforementioned contents. In order to clearly present these components, the relevant specific implementation methods are described in detail below: obtaining the node classification of each resource node, and allocating the computing business to the resource node of the corresponding classification based on the business type.

[0051] Specifically, obtaining the node classification of each resource node requires analyzing the physical node's CPU core distribution, memory capacity, interconnect bandwidth, and latency data using system tools (such as numactl) based on the resource node's hardware performance characteristics and topological properties. This is then quantitatively evaluated using a node scoring model (calculated as: bandwidth share × 70% + 1 / latency × 30%) to categorize resource nodes into different types. Specifically, node classifications can include high-performance nodes (high memory bandwidth and low local access latency), high-bandwidth nodes (outstanding memory throughput), and standard nodes (balanced overall performance). High-performance nodes typically correspond to physical nodes with high memory controller efficiency and low IMC bus communication latency, making them suitable for carrying performance-sensitive businesses. High-bandwidth nodes, on the other hand, prioritize memory data transfer rates and are suitable for business scenarios with high data throughput.

[0052] When assigning computing services to resource nodes of corresponding classifications based on service type, differentiated strategies must be implemented to address the resource requirements of different services. Memory-intensive computing services (such as database services), due to their high sensitivity to memory access latency, should be prioritized for allocation to high-performance nodes, with exclusive node allocation and strict memory isolation. Binding should be enforced using the --cpunodebind / --membind policy in the numactl tool to completely prevent cross-node access. General computing services (such as web application services) should be assigned to high-bandwidth nodes or regular nodes with low current loads, using elastic vCPU binding (dynamically switching between static and dynamic modes using the ENABLE_CPU_PINNING parameter) to improve resource utilization while ensuring basic performance. Furthermore, for large-scale monolithic services (such as in-memory databases), adjacent physical nodes can be combined into logical resource clusters using Sub-NUMA Clustering (SNC) technology. These clusters serve as dedicated, classified nodes, expanding local access to meet their high CPU resource requirements. This precise allocation approach, tailored to service type and node classification, achieves targeted and efficient resource utilization, laying the foundation for load balancing.

[0053] Furthermore, in some embodiments of the present disclosure, the specific implementation methods for the operation of "allocating computing services to resource nodes of corresponding classifications based on service types" are diverse. For the purpose of clear explanation, the following includes but is not limited to some implementation methods: utilizing the node evaluation parameters of each resource node to perform classification to obtain the node classification of each resource node; according to the node classification corresponding to the service type, allocating computing services to resource nodes of corresponding classifications.

[0054] Specifically, when classifying resource nodes using node evaluation parameters, these parameters primarily include key metrics such as memory bandwidth, access latency, CPU core performance, and node interconnect bandwidth. Specifically, the numactl tool is used to analyze the physical node topology to obtain each node's memory bandwidth data (such as memory read and write rates for different nodes), CPU core distribution, and communication latency within and between nodes (such as IMC Bus latency and QPI latency). A node scoring model is constructed based on these parameters. The calculation formula for this model is "bandwidth share × 70% + 1 / latency × 30%." Bandwidth share is the ratio of the node's memory bandwidth to the average memory bandwidth of all nodes, and 1 / latency reflects the weight of access speed on node performance. Resource nodes are divided into different categories based on the scoring results and actual performance differences (such as memory bandwidth differences >20%). For example, nodes with high scores, high memory bandwidth, and low access latency are classified as "high-performance nodes" and are suitable for carrying performance-sensitive businesses; nodes with outstanding memory bandwidth but slightly lower overall scores are classified as "high-bandwidth nodes" and are suitable for businesses with high data throughput; and nodes with balanced performance but no significant advantages are classified as "general-purpose nodes" and are used to carry ordinary computing businesses.

[0055] When allocating computing services based on the node classification corresponding to each service type, it is necessary to first clarify the resource requirements of each service type. Memory-intensive services (such as database services) are classified as "high-performance nodes." Because they are highly sensitive to memory access latency, they should be allocated to these nodes and receive exclusive node allocation and strict memory isolation. Forced binding is implemented using the --cpunodebind / --membind policies to ensure memory locality. General-purpose computing services (such as web application services) are classified as "high-bandwidth nodes" or "general-purpose nodes." High-bandwidth nodes with low current loads are prioritized during allocation, and elastic vCPU binding is implemented (with the ENABLE_CPU_PINNING parameter controlling the mode switching) to improve resource utilization while ensuring basic performance. For large-scale, single-server services (such as in-memory databases), the corresponding node classification can be set to a logical resource cluster (such as Node0+1) formed using Sub-NUMA Cluster (SNC) technology. This node classification meets their high CPU resource requirements by extending local access range. Performance can be further optimized when combined with 1GB huge page memory configuration. Through this allocation method based on the precise matching of node evaluation parameter classification and business type, efficient adaptation of computing business and resource nodes is achieved, laying the foundation for subsequent load balancing.

[0056] Furthermore, in some embodiments of the present disclosure, the specific implementation methods for "classifying each resource node using the node evaluation parameters of each resource node to obtain a node classification for each resource node" vary. For clarity, the following examples include, but are not limited to, some implementation methods: obtaining resource topology data and operational status data for each resource node; evaluating each resource node based on the resource topology data to obtain performance evaluation data, and evaluating each resource node based on the operational status data to obtain operational evaluation data; and classifying each resource node based on the performance evaluation data and operational evaluation data to obtain a node classification for each resource node. Node evaluation parameters include resource topology data and operational status data.

[0057] Specifically, when obtaining resource topology and operational status data for each resource node, resource topology data is primarily obtained by parsing the hardware architecture of the physical node using system tools such as numactl. This data includes hardware-specific attributes such as the CPU core distribution of each resource node (such as the number of cores, their numbers, and their affiliations), memory capacity (the total and allocated capacity of each node's local memory), interconnection bandwidth between the integrated memory controller (IMC) and Quick Path Interconnect (QPI), intra-node communication latency (IMC Bus latency), and inter-node communication latency (QPI latency). This data reflects the physical topology and basic performance potential of the resource node. Operational status data is collected through a real-time monitoring mechanism, covering dynamic operational indicators such as the node's CPU utilization, memory bandwidth utilization (the ratio of the current memory data transfer rate to the node's maximum memory bandwidth), cross-node access rate (the ratio of remote memory accesses to total accesses), and memory page table management overhead, providing real-time information on the node's current load pressure and operational stability.

[0058] When evaluating performance data based on resource topology data, a node performance scoring model is constructed using memory bandwidth and latency from the resource topology data as core metrics. The calculation formula for this model is "bandwidth share × 70% + 1 / latency × 30%." Bandwidth share is the ratio of the node's memory bandwidth to the average memory bandwidth of all nodes, and 1 / latency is the inverse of the latency metric, reflecting the positive impact of access speed on performance. The quantitative score calculated by this model is the performance evaluation data. A higher score indicates better basic node performance. For example, nodes with high memory bandwidth and low access latency receive higher scores and are preliminarily judged to have the potential to support high-performance services. When evaluating operational data based on operational status data, the key focus is on analyzing the degree to which each dynamic metric in the operational status data matches preset thresholds. For example, whether CPU utilization is below 80%, memory bandwidth utilization is below 70%, and cross-node access rate is below 5%. If all metrics are within a reasonable range, the operational evaluation data is considered "low-load stable." Otherwise, it is considered "high-load stress." This evaluation result reflects the node's current actual operational carrying capacity.

[0059] When classifying resource nodes based on performance evaluation data and operational evaluation data, the node classification is determined by combining the results of both. Nodes with high performance evaluation scores (e.g., in the top 20%) and operational evaluation data indicating a "low load stable state" are classified as "high-performance nodes" due to their high basic performance and low load pressure, specifically for memory-sensitive critical services (such as databases). Nodes with outstanding memory bandwidth metrics in the performance evaluation data (e.g., bandwidth utilization exceeding 30% of the average) and low memory bandwidth utilization according to the operational evaluation data are classified as "high-bandwidth nodes" for services with high data throughput (such as web application services). Nodes with moderate performance evaluation data and operational evaluation data indicating a balanced load are classified as "general-purpose nodes" for general computing services. Nodes with low performance evaluation data or operational evaluation data indicating a "high load pressure state" are temporarily classified as "pending scheduling nodes" and require re-evaluation after load balancing adjustments. This classification method, which combines static hardware performance with dynamic operational status, ensures that resource node classification results both match service performance requirements and adapt to real-time load fluctuations, providing a reliable basis for the precise allocation of computing services.

[0060] Furthermore, in some embodiments of the present disclosure, the specific implementation methods for "allocating computing services to resource nodes within the corresponding node classification based on the service type" vary. For clarity, the following examples include, but are not limited to, some implementation methods: If the computing service is memory-sensitive, the computing service is allocated to resource nodes within the corresponding performance classification; if the computing service is general computing, the computing service is allocated to resource nodes within the corresponding load classification. Service types include memory-sensitive and general computing, and node classifications include performance and load.

[0061] Specifically, if the computing business is memory-sensitive, it has extremely high requirements for memory access latency and bandwidth stability. A typical example is database services, which have frequent data read and write operations and are sensitive to response time, and therefore need to be allocated to resource nodes corresponding to the performance category. Performance-classified resource nodes are evaluated based on core parameters such as memory bandwidth and access latency from resource topology data, using a node performance scoring model (calculated as: bandwidth share × 70% + 1 / latency × 30%). These nodes feature hardware characteristics such as high memory bandwidth (typically more than 20% higher than the average level) and low local access latency (IMC Bus latency is significantly lower than QPI latency). Analysis using the numactl tool indicates that their CPU cores and memory controllers are better matched. During allocation, an exclusive node allocation strategy is implemented for memory-sensitive businesses. The --cpunodebind / --membind parameters are used to forcibly bind their vCPUs and memory to this type of node. At the same time, 1GB of huge page memory (--hugetlbfs) is configured to reduce page table management overhead, and memory isolation is strictly enforced to completely avoid cross-node access. This ensures that memory access during business runtime is almost all local access, and the cross-node access rate is controlled below 5%, meeting their high requirements for performance stability.

[0062] For general computing services, such as web application services, which have relatively low real-time resource requirements but require balanced resource utilization and load balancing, they must be allocated to resource nodes corresponding to the load classification. Load-classified resource nodes are those with the lowest current load, as determined by operational data. This evaluation is based on dynamic metrics such as CPU utilization (typically below 60%), memory bandwidth utilization (below 50%), and cross-node access rate (below 10%), ensuring that nodes have sufficient resource headroom to accommodate new services. During allocation, elastic vCPU binding is implemented. The ENABLE_CPU_PINNING parameter dynamically switches the binding mode, allowing for process-level dynamic binding (taskset) or configuration-level static mapping. Huge page memory is also pre-allocated to nodes to optimize basic performance. While ensuring normal business operations, nodes with the lowest current load are prioritized to achieve balanced resource utilization, avoid overloading any single node, and maintain overall system stability.

[0063] Furthermore, in some embodiments of the present disclosure, the load balancing method includes other specific implementation steps in addition to the aforementioned contents. In order to clearly present these components, the relevant specific implementation methods are described in detail below: configuring and binding the computing business with the allocated resource nodes.

[0064] Specifically, computing services are configured to bind to assigned resource nodes. Differentiated binding strategies are implemented based on service type and node characteristics, with either hard or flexible binding implemented through system tools and parameter configuration. For memory-sensitive services (such as databases), the binding operation focuses on strict localization and isolation: The --cpunodebind parameter of the numactl tool is used to bind the vCPU to a specific CPU core on the target resource node. The --membind parameter is used to bind memory to the node's local memory area, ensuring that both the vCPU and memory resources belong to the same node and completely preventing cross-node access. To further optimize performance, 1GB of huge page memory is pre-allocated to the target node (mounted using --hugetlbfs) and bound to the service. This has been shown to reduce page table management overhead by over 50%. NUMA automatic balancing is also disabled through the global kernel parameter (sysctl kernel.numa_balancing=0), eliminating interference from system-level scheduling on binding relationships and achieving strict isolation at the exclusive node level. For general computing services, the binding strategy emphasizes flexibility and load adaptability. The ENABLE_CPU_PINNING parameter dynamically switches binding modes. In static mode, configuration-level mapping is used to bind vCPUs and memory to target nodes. In dynamic mode, the taskset tool supports process-level dynamic vCPU binding, allowing real-time adjustment of binding relationships based on node load changes. Huge pages of memory are pre-allocated to nodes bound to these services, ensuring basic performance while using cgroups to implement fine-grained resource usage caps to avoid interference with other services.

[0065] Regardless of the service type, after binding is completed, the eBPF-driven SD-NUMA framework monitors the binding status in real time. If the cross-node access rate exceeds 10%, a rebinding mechanism is immediately triggered to ensure the validity of the binding relationship. In VM migration scenarios, within 3 seconds of the migration, the memory rebinding protocol is enforced using the numactl --membind command to re-anchor the service memory data to the target node's local memory. Hardware MMU / SMMU isolation mechanisms (such as the Kunpeng 920 platform register configuration) are enabled to ensure memory security during the binding process. Ultimately, this achieves stable binding between computing services and resource nodes, meeting both performance requirements and scheduling flexibility.

[0066] Furthermore, in some embodiments of the present disclosure, the specific implementation methods for the operation of "binding the computing business with the allocated resource nodes" are diverse. For the purpose of clear explanation, the following includes but is not limited to some implementation methods: allocating memory resources to the computing business and the allocated resource nodes according to the business type; binding the computing business with the allocated resource nodes based on the allocated memory resources.

[0067] Specifically, when allocating memory resources to computing services and their assigned resource nodes based on business type, differentiated strategies should be implemented based on the varying memory performance requirements of each business. For memory-intensive computing services (such as databases), given their high requirements for memory access latency and bandwidth stability, an exclusive node allocation strategy is adopted when allocating memory resources. This strategy allocates all local memory on the resource node where it resides, while strictly restricting other services from accessing the node's memory to completely prevent cross-node memory access. Furthermore, 1GB of huge page memory (mounted using --hugetlbfs) is allocated exclusively to these services. Huge page memory reduces page table management overhead (measured reductions of over 50%), further optimizing memory access efficiency. Huge page memory is bound only to the resource node corresponding to that service, ensuring exclusive use of memory resources. For general computing services, memory resources are prioritized for low-load, high-bandwidth resource nodes, with an appropriate amount of local memory allocated within those nodes. Memory capacity is dynamically adjusted based on business scale. Huge page memory can also be configured to improve basic performance, but exclusive ownership is not employed, allowing for flexible memory resource allocation as node load fluctuates. When binding compute services to resource nodes based on allocated memory resources, the --membind policy of the numactl tool is used to forcibly bind the compute service's memory address space to the allocated local memory area, ensuring that all memory accessed during service execution is local to the resource node. For memory-sensitive services, the --cpunodebind policy is also used to bind their vCPUs to the CPU cores of the node, achieving hard same-node binding of vCPUs and memory. The NUMA automatic balancing mechanism is disabled via the global kernel parameter (sysctlkernel.numa_balancing=0) to prevent automatic scheduling from disrupting the binding relationship. For general-purpose compute services, the ENABLE_CPU_PINNING parameter switches the binding mode. In static mode, binding is achieved through configuration-level mapping, while in dynamic mode, process-level vCPU binding is performed through the taskset tool, maintaining flexibility. Furthermore, the eBPF-driven SD-NUMA framework monitors memory binding status in real time. When the cross-node access rate exceeds 10%, a rebinding operation is triggered promptly to ensure the validity of the binding between compute services and resource nodes and ensure stable service performance.

[0068] Furthermore, in some embodiments of the present disclosure, the load balancing method includes other specific implementation steps in addition to the aforementioned contents. To clearly present these components, the relevant specific implementation methods are described in detail below: pre-processing the historical load data of each resource node to generate training load data; using the training load data to iteratively train the load prediction model to be trained to generate a trained load prediction model.

[0069] Specifically, when preprocessing the historical load data of each resource node, it is necessary to first collect historical load data generated by the resource node during long-term operation. This data covers multiple dimensions such as CPU utilization, memory bandwidth usage, cross-node access rate, and inter-node communication latency, and is recorded in a time series (e.g., once per minute). The preprocessing process begins with data cleansing to remove outliers caused by hardware failures and collection anomalies (e.g., abnormal data where CPU utilization instantly jumps to 100% and then immediately returns to zero). Missing values ​​that occur during data collection intervals are filled using a sliding average method to ensure data continuity. Next, data normalization is performed to uniformly map metrics of different magnitudes (e.g., CPU utilization as a percentage, memory bandwidth in GB / s) to the 0-1 range, eliminating the impact of dimensional differences on model training. Finally, the data is partitioned by time window, using a fixed 5-minute window to segment the continuous data into sample segments. Each segment contains all metric data within the window, serving as the basic input unit for model training and generating training load data. When iteratively training a load prediction model (such as an LSTM model) using training load data, the data is first split into a training set and a validation set in a 7:3 ratio. The training set is used to learn model parameters, and the validation set is used to evaluate model generalization. During training, the load data for each time window serves as input features, and the actual load data for the next 5 minutes after the window serves as labels. The model's predictions are calculated through forward propagation, and the mean squared error (MSE) loss function is used to measure the difference between the predictions and the labels. The model weights are then updated using the Adam optimizer with backpropagation. The iteration termination condition is set: training is terminated when the validation set loss stops decreasing for 10 consecutive epochs to prevent overfitting. Finally, a trained load prediction model is generated. Based on historical load trends, this model accurately predicts load changes on resource nodes over the next 5 minutes, providing a reliable basis for preventive migration. In conjunction with real-time load monitoring data, it forms a complete closed loop of "historical data-prediction model-real-time adjustment."

[0070] Furthermore, in some embodiments of the present disclosure, the load balancing method includes other specific implementation steps in addition to the aforementioned contents. In order to clearly present these components, the relevant specific implementation methods are described in detail below: memory monitoring of each resource node and obtaining cross-node access data of each resource node; based on the cross-node access data, adjusting the binding relationship between the virtual machine and the resource node.

[0071] Specifically, memory monitoring for each resource node primarily relies on the perf tool to monitor memory access events (such as numa_miss events). Simultaneously, by deploying the eBPF-driven Software-Defined NUMA (SD-NUMA) framework, cross-node access data for each resource node is collected in real time. This data includes indicators such as the number of cross-node accesses, the cross-node access rate (the ratio of remote memory accesses to total memory accesses), cross-node data transfer volume, and corresponding latency changes. The cross-node access rate is a core monitoring metric, directly reflecting the effectiveness of the binding relationship between the virtual machine and the current resource node. According to measured data, when this metric exceeds 10%, it significantly impacts service performance.

[0072] Adjusting the binding relationship between VMs and resource nodes based on cross-node access data follows a "real-time monitoring - threshold triggering - dynamic adjustment" logic. When the cross-node access rate of a resource node exceeds 10% (twice the industry standard sensitivity), the SD-NUMA framework immediately triggers a rebinding mechanism. Using a mounted eBPF probe, it calls kernel interfaces and, in conjunction with the --membind policy of the numactl tool, rebinds the VM's memory resources to a resource node with a higher local access ratio. If the cross-node access rate remains above 5%, Sub-NUMA Cluster (SNC) technology is further enabled to group adjacent physical nodes into a logical resource cluster (such as Node0+1), expanding the local access range and reducing the probability of cross-cluster access. For memory-sensitive services (such as databases), an abnormally high cross-node access rate triggers exclusive node reallocation. The virsh migrate tool is used to migrate the VM to a node with better performance, and then hard binding is re-executed. Simultaneously, 1GB huge pages (--hugetlbfs) are reallocated to reduce the interference of page table management overhead on memory access. In addition, within 3 seconds after the adjustment, the system will perform feedback control through the PID calibration algorithm, using the cross-node access rate as the input parameter, and enforce the memory rebinding protocol (numactl --membind) to ensure that the adjusted binding relationship can stably control the cross-node access rate within 5%, thereby maintaining the high performance state of the binding between virtual machines and resource nodes while ensuring business continuity.

[0073] It should be noted that the embodiments of the present disclosure may include multiple steps. For the convenience of description, these steps are numbered, but these numbers do not limit the execution time slots or execution order between the steps; these steps can be implemented in any order, and the embodiments of the present disclosure do not limit this.

[0074] Corresponding to the above-mentioned load balancing method, the present disclosure also provides a load balancing device. Since the device embodiment of the present disclosure corresponds to the above-mentioned method embodiment, details not disclosed in the device embodiment can be referred to the above-mentioned method embodiment and will not be repeated in this disclosure.

[0075] Figure 2 A schematic diagram of a load balancing device according to an embodiment of the present disclosure is shown in FIG. Figure 2 As shown, including: The monitoring unit 21 is used to monitor the load of resource nodes in the server and obtain load monitoring data. The resource nodes are deployed with virtual machines, and the computing services of the virtual machines are bound to resource nodes of corresponding categories according to service types; The prediction unit 22 is used to perform load prediction on the resource node and obtain load prediction data; A determination unit 23 is configured to determine whether to migrate the virtual machine to another resource node based on the load monitoring data and the load prediction data; The migration unit 24 is configured to migrate the virtual machine to a target resource node in response to determining to migrate the virtual machine to another resource node, and bind the virtual machine to the target resource node.

[0076] The present disclosure provides a load balancing device that ensures accurate matching of resource nodes with virtual machine requirements through load monitoring combined with a business type binding mechanism, thus avoiding waste caused by resource mismatch. By identifying potential overloaded nodes in advance through load prediction and actively migrating virtual machines to low-load nodes, the node load balance can be improved, the proportion of hot nodes can be significantly reduced, and the overall computing power of the server can be released. After the virtual machine is migrated, it is forcibly bound to the target node, which can significantly reduce cross-node memory access. Preventive migration based on load prediction can reduce the risk of business interruption caused by sudden load.

[0077] Furthermore, in a possible implementation of this embodiment, as Figure 3 As shown, the prediction unit 22 includes: The acquisition module 221 is used to obtain the current load data of each resource node; The prediction module 222 is used to input the current load data into the load prediction model to perform load prediction, predict the load change of each resource node within a preset time period, and generate load prediction data for each resource node.

[0078] Furthermore, in a possible implementation of this embodiment, as Figure 3 As shown, the determining unit 23 includes: A first determining module 231 is configured to determine whether to migrate the virtual machine to another resource node if the load monitoring data exceeds a preset load threshold; The second determining module 232 is configured to determine to migrate the virtual machine to another resource node if the load prediction data exceeds a predicted load threshold.

[0079] Furthermore, in a possible implementation of this embodiment, as Figure 3 As shown, the load balancing device also includes: The allocation unit 25 is configured to obtain the node classification of each resource node and allocate computing services to resource nodes of corresponding classification based on service types.

[0080] Furthermore, in a possible implementation of this embodiment, as Figure 3 As shown, the allocation unit 25 includes: A classification module 251 is configured to classify each resource node using the node evaluation parameters of each resource node to obtain a node classification of each resource node; The first allocation module 252 is configured to allocate computing services to resource nodes of corresponding categories according to the node categories corresponding to the service types.

[0081] Furthermore, in a possible implementation of this embodiment, the node evaluation parameters include: resource topology data and operation status data; The classification module 251 is also used to: Obtain resource topology data and operation status data of each resource node; Evaluate each resource node based on the resource topology data to obtain performance evaluation data, and evaluate each resource node based on the operation status data to obtain operation evaluation data; Each resource node is classified according to the performance evaluation data and the operation evaluation data to obtain a node classification of each resource node.

[0082] Furthermore, in a possible implementation of this embodiment, the business types include: memory-sensitive and general computing types, and the node classifications include: performance and load types. The first allocation module 252 is further configured to: If the computing business is memory-sensitive, the computing business will be allocated to the resource node corresponding to the performance classification; If the computing business is a general computing business, the computing business will be allocated to the resource node corresponding to the load classification.

[0083] Furthermore, in a possible implementation of this embodiment, as Figure 3As shown, the load balancing device also includes: The binding unit 26 is configured to configure and bind the computing service with the resource node to which it is allocated.

[0084] Furthermore, in a possible implementation of this embodiment, as Figure 3 As shown, the binding unit 26 includes: The second allocation module 261 is used to allocate memory resources to computing services and resource nodes allocated thereto according to service types; The binding module 262 is configured to bind the computing service to the allocated resource node based on the allocated memory resources.

[0085] Furthermore, in a possible implementation of this embodiment, as Figure 3 As shown, the load balancing device also includes: A generating unit 27 is used to pre-process the historical load data of each resource node to generate load data for training; The training unit 28 is used to iteratively train the load prediction model to be trained using the training load data to generate a trained load prediction model.

[0086] Furthermore, in a possible implementation of this embodiment, as Figure 3 As shown, the load balancing device also includes: An acquisition unit 29 is used to monitor the memory of each resource node and obtain cross-node access data of each resource node; The adjusting unit 210 is configured to adjust the binding relationship between the virtual machine and the resource node based on the cross-node access data.

[0087] It should be noted that the above explanation of the method embodiment is also applicable to the device of this embodiment, and the principles are the same, which is not limited in this embodiment.

[0088] For the description of the features in the embodiment corresponding to the load balancing device, please refer to the relevant description of the embodiment corresponding to the load balancing method, and no further details will be given here.

[0089] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned load balancing method embodiments.

[0090] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned load balancing method embodiments when running.

[0091] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0092] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned load balancing method embodiments are implemented.

[0093] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned load balancing method embodiments are implemented.

[0094] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0095] The above is a detailed introduction to a load balancing method and device, electronic device, and storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A load balancing method, characterized in that: include: Performing load monitoring on resource nodes in the server to obtain load monitoring data, wherein the resource nodes are deployed with virtual machines, and computing services of the virtual machines are bound to resource nodes of corresponding categories according to service types; Performing load prediction on the resource node to obtain load prediction data; Determining whether to migrate the virtual machine to another resource node based on the load monitoring data and the load prediction data; In response to determining to migrate the virtual machine to another resource node, the virtual machine is migrated to a target resource node, and the virtual machine is bound to the target resource node.

2. The load balancing method according to claim 1, wherein: The performing load prediction on the resource node to obtain load prediction data includes: Get the current load data of each resource node; The current load data is input into a load prediction model to perform load prediction, predict the load change of each resource node within a preset time period, and generate load prediction data for each resource node.

3. The load balancing method according to claim 1, wherein: The determining, based on the load monitoring data and the load prediction data, whether to migrate the virtual machine to another resource node includes: If the load monitoring data exceeds a preset load threshold, determining to migrate the virtual machine to another resource node; If the load prediction data exceeds the predicted load threshold, it is determined to migrate the virtual machine to another resource node.

4. The load balancing method according to claim 1, wherein: The method further comprises: The node classification of each resource node is obtained, and the computing service is allocated to the resource node of the corresponding classification based on the service type.

5. The load balancing method according to claim 4, wherein: Allocating the computing service to resource nodes of corresponding categories based on the service type includes: Classify each resource node using the node evaluation parameters to obtain the node classification of each resource node; According to the node classification corresponding to the business type, the computing business is allocated to the resource nodes of the corresponding classification.

6. The load balancing method according to claim 5, characterized in that: The node evaluation parameters include: resource topology data and operation status data; The node classification of each resource node is obtained by using the node evaluation parameters of each resource node, including: Obtaining the resource topology data and the operating status data of each resource node; Evaluate each resource node based on the resource topology data to obtain performance evaluation data, and evaluate each resource node based on the operation status data to obtain operation evaluation data; The resource nodes are classified according to the performance evaluation data and the operation evaluation data to obtain a node classification of each resource node.

7. The load balancing method according to claim 6, characterized in that: The business types include: memory-sensitive and general computing types; the node classifications include: performance classification and load classification; The allocating the computing service to the resource nodes under the corresponding node classification according to the node classification corresponding to the service type includes: If the computing service is memory-sensitive, allocating the computing service to a resource node corresponding to the performance classification; If the computing service is a general computing service, the computing service is allocated to a resource node corresponding to the load classification.

8. The load balancing method according to claim 7, wherein: The method further comprises: The computing service is configured and bound to the resource node to which it is allocated.

9. The load balancing method according to claim 8, characterized in that: Binding the computing service to the allocated resource node includes: Allocating memory resources to the computing service and the resource node to which it is allocated according to the service type; Based on the allocated memory resources, the computing service is bound to the allocated resource node.

10. The load balancing method according to claim 2, wherein: The method further comprises: Preprocess the historical load data of each resource node to generate load data for training; The load prediction model to be trained is iteratively trained using the training load data to generate a trained load prediction model.

11. The load balancing method according to claim 1, wherein: The method further comprises: Monitor the memory of each resource node and obtain cross-node access data of each resource node; Based on the cross-node access data, the binding relationship between the virtual machine and the resource node is adjusted.

12. A load balancing device, characterized in that: include: A monitoring unit is configured to monitor the load of resource nodes in the server and obtain load monitoring data, wherein the resource nodes are deployed with virtual machines, and the computing services of the virtual machines are bound to resource nodes of corresponding categories according to service types; A prediction unit, configured to perform load prediction on the resource node to obtain load prediction data; a determining unit, configured to determine whether to migrate the virtual machine to another resource node based on the load monitoring data and the load prediction data; The migration unit is configured to migrate the virtual machine to a target resource node in response to determining to migrate the virtual machine to another resource node, and bind the virtual machine to the target resource node.

13. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the load balancing method according to any one of claims 1 to 11.

14. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable the computer to execute the load balancing method according to any one of claims 1 to 11.

15. A computer program product, characterized in that The invention comprises a computer program, which implements the load balancing method according to any one of claims 1 to 11 when executed by a processor.

Images