A Server Cluster Scheduling Method Based on Dynamic Load Balancing

Abstract

This invention belongs to the field of server cluster scheduling technology, specifically involving a server cluster scheduling method based on dynamic load balancing. It involves real-time collection of load data from each server in the server cluster; quantitative evaluation of the collected load data using a preset load assessment model to obtain the real-time load value and load stability score of each server; receiving external tasks to be processed, parsing the task's resource requirement parameters and task type characteristics; determining the target server for the task based on server status level, load stability score, task resource requirement parameters, and task type characteristics; and updating the load assessment model and scheduling strategy in real time based on historical scheduling data, task execution feedback data, and industry scenario characteristic parameters. This invention effectively improves the resource utilization and task processing efficiency of server clusters through multi-dimensional load assessment, precise task-server matching, and dynamic strategy optimization, adapting to the needs of different industry scenarios.

Description

Technical Field

[0001] This invention belongs to the field of server cluster scheduling technology, and in particular relates to a server cluster scheduling method based on dynamic load balancing. Background Technology

[0002] Against the backdrop of rapid development in internet technology, server clusters have become the core infrastructure supporting large-scale concurrent task processing, widely used in various scenarios such as e-commerce platforms, financial transactions, and medical data processing. With the diversification of user needs and the increase in task complexity, the types of tasks to be processed in the cluster exhibit significant differences, such as computationally intensive data analysis tasks and I / O-intensive file storage tasks. Furthermore, the resource demands of these tasks fluctuate dynamically, such as high-concurrency order tasks during e-commerce promotional periods and peak transaction requests on financial trading days. This places extremely high demands on the load balancing and scheduling capabilities of server clusters.

[0003] Traditional server cluster scheduling methods have the following main technical drawbacks:

[0004] Load assessment relies on a single dimension, resulting in insufficient accuracy in status assessment.

[0005] Existing technologies mostly rely on dynamic load parameters such as real-time CPU utilization and memory usage of servers for load assessment. These parameters can only reflect the current load intensity of the server and cannot quantify load fluctuation characteristics. For example, drastic load fluctuations in a short period of time may cause task execution to be interrupted. Some servers may be judged to be in an idle state due to a momentary drop in load, but in reality, there are high-frequency load fluctuations. After tasks are assigned, they can easily enter an overload state quickly, resulting in a decrease in task processing efficiency.

[0006] Poor task scheduling adaptability, resulting in an imbalance between resource utilization and task efficiency:

[0007] Existing scheduling strategies often employ a simple rule of prioritizing idle servers, failing to consider the matching between task type and server performance characteristics. For example, they might assign computationally intensive tasks to servers with ample memory redundancy but weak CPU performance, or fail to differentiate between task priority and runtime requirements for server stability. For instance, assigning long tasks to servers with volatile loads can easily lead to task interruptions due to mid-task load migration. Furthermore, when faced with high-priority tasks, traditional methods often directly utilize the remaining resources of normally functioning servers without establishing a dynamic migration mechanism for overloaded servers. This can lead to rapid saturation of normal server loads, triggering a cascading overload risk.

[0008] Static strategies are difficult to adapt to scenario-based needs and dynamic changes.

[0009] The task characteristics of different industry scenarios vary significantly. For example, some scenarios are sensitive to task response latency, while e-commerce scenarios have high requirements for high concurrency carrying capacity. However, existing scheduling strategies mostly adopt general rules and cannot be dynamically adjusted according to scenario characteristics. For example, resources are not prioritized for short tasks during e-commerce promotions, or emergency resource pools are not reserved for financial transaction tasks.

[0010] The load migration and emergency dispatch mechanisms are inadequate.

[0011] Existing technologies for task migration under server overload often rely on the simple logic of "randomly selecting low-priority tasks," neglecting the dependencies between tasks. For example, splitting and migrating related tasks may lead to data consistency issues and high migration costs. Migrating large file transfer tasks can be time-consuming, affecting the timely allocation of high-priority tasks. Furthermore, in extreme scenarios, such as when the overall cluster load exceeds its capacity limit, the lack of a coordinated scheduling mechanism with edge nodes makes it difficult to alleviate the pressure on the core cluster by expanding the resource pool, easily leading to task backlog or service interruptions.

[0012] Therefore, how to construct a scheduling method that can accurately assess server load status, dynamically adapt to task types and scenario requirements, and has self-optimization capabilities has become a key technical issue in improving server cluster resource utilization and task processing efficiency. Summary of the Invention

[0013] The purpose of this invention is to provide a server cluster scheduling method based on dynamic load balancing, which can accurately assess the server load status, dynamically adapt to task types and scenario requirements, and achieve self-optimization scheduling, thereby improving the resource utilization and task processing efficiency of the server cluster.

[0014] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0015] A server cluster scheduling method based on dynamic load balancing includes the following steps:

[0016] S1: Real-time collection of load data from each server in the server cluster, including static load parameters, dynamic load parameters, and load fluctuation characteristic parameters.

[0017] S2: The preset load assessment model quantifies the load data, obtains the real-time load value and load stability score of each server, and divides the server into three state levels: idle, normal, and overload based on the real-time load value. The load stability score is used to characterize the degree of fluctuation of the server load within a preset time period.

[0018] S3: Receive external tasks to be processed, and parse the resource requirement parameters and task type characteristics of the tasks to be processed;

[0019] S4: Based on the server's status level, load stability score, task resource requirement parameters, and task type characteristics, determine the target server for the task through a preset scheduling strategy.

[0020] S5: Assign tasks to the corresponding target servers and monitor the load changes and task progress matching degree of the target servers in real time during task execution; if the load value of the target server exceeds the preset overload threshold or the task progress matching degree is lower than the preset threshold, perform load migration.

[0021] S6: Based on historical scheduling data, task operation feedback data, and industry scenario characteristic parameters, update the load assessment model and scheduling strategy in real time.

[0022] Preferably, the static load parameters are the specified hardware inherent attribute parameters of the server, the dynamic load parameters are the performance parameters that change in real time during server operation, and the load fluctuation characteristic parameters are the fluctuation amplitude, frequency and trend slope of the dynamic load within a preset time period.

[0023] The task progress matching degree is the deviation rate between the actual task progress and the preset progress.

[0024] The resource requirement parameters include the CPU utilization, memory usage, network bandwidth, and task priority required by the task; the task type characteristics include whether the task is compute-intensive, I / O-intensive, or a hybrid type, and the expected runtime of the task.

[0025] The industry scenario characteristic parameters include the distribution pattern of task types within the scenario, the distribution of peak periods, and the common characteristics of resource requirements.

[0026] Preferably, the scheduling strategy includes:

[0027] Prioritize assigning tasks to servers that are idle and have a load stability score ≥ the preset threshold;

[0028] For compute-intensive tasks, prioritize servers with high CPU performance redundancy; for I / O-intensive tasks, prioritize servers with high disk I / O throughput.

[0029] If a task is of high priority and the normal state server has insufficient resources, then the overloaded state server will be reloaded and the task will be assigned.

[0030] Preferably, the load fluctuation characteristic parameters are calculated using a sliding window algorithm: a sliding window is used in 5-minute units, the standard deviation of the dynamic load parameters within the window is used as the fluctuation amplitude, the number of peak occurrences is used as the fluctuation frequency, and the linear fitting slope is used as the fluctuation trend.

[0031] Among them, a positive slope indicates that the load is increasing, while a negative slope indicates that the load is decreasing.

[0032] Preferably, the specific process of using the preset load assessment model in step S2 to quantify and assess the load data, and to obtain the real-time load value and load stability score of each server, is as follows:

[0033] S21: Preprocess the load data of each server;

[0034] S22: Preset base weights based on server type:

[0035] Assign fixed base weights to static load parameters, including the number of CPU cores and total memory capacity;

[0036] Assign dynamic base weights to dynamic load parameters, including real-time CPU utilization and memory utilization.

[0037] The load fluctuation characteristic parameters, including fluctuation amplitude, frequency, and trend slope, are assigned specific basic weights to the load stability score.

[0038] S23: Perform real-time load calculation to quantify the current server load intensity.

[0039] Static load parameter quantification: Based on the maximum carrying capacity of the server hardware, static parameters are converted into quantified values ​​of hardware redundancy: Static parameter quantification value = (maximum hardware specification - currently allocated specification) / maximum hardware specification;

[0040] Dynamic load parameter quantification: Based on the server's real-time performance utilization, weights are dynamically adjusted in conjunction with load fluctuation characteristics.

[0041] Basic quantization: Dynamic parameter quantization value = 1 - real-time utilization rate;

[0042] Weight adjustment: If the load fluctuation amplitude is greater than the preset threshold, the weight of the dynamic parameter will be reduced, while the weight of the parameter with higher stability will be increased.

[0043] Calculate the real-time load value using a weighted summation:

[0044] Real-time load value = (static parameter quantization value × static weight) + (dynamic parameter quantization value × dynamically corrected weight);

[0045] S24: Perform load stability scoring to quantify the risk of server load fluctuations.

[0046] Quantification of load fluctuation characteristic parameters:

[0047] Fluctuation data calculated using a 5-minute sliding window is converted into quantified values:

[0048] Fluctuation range: based on the standard deviation of dynamic load parameters, standardized to 0-10 points;

[0049] Fluctuation frequency: Count the number of times the value exceeds the preset threshold within 5 minutes, and standardize it to 0-10 points;

[0050] Trend slope: Convert the slope of the load change trend into a 0-10 scale.

[0051] Stability score is calculated using preset weights:

[0052] Load stability score = (fluctuation amplitude score × 40%) + (fluctuation frequency score × 30%) + (trend slope score × 30%).

[0053] Preferably, the specific process of step S3 is as follows:

[0054] S31: Perform preliminary verification on the received tasks, filtering out invalid or abnormal tasks, including legality verification and integrity verification;

[0055] S32: Based on the resource description information carried by the task, i.e. the parameters specified when the task is submitted or the preset task template, extract the four core resource requirements, including CPU requirements, memory requirements, network bandwidth requirements and storage I / O requirements.

[0056] S33: Task Priority Analysis and Dynamic Adjustment:

[0057] Basic priority extraction: Read the preset priority levels P0-P3 from the task parameters;

[0058] Priority is dynamically adjusted based on task submission time and timeout requirements;

[0059] S34: Preliminary judgment based on task behavior type:

[0060] Preliminary classification based on initial task information: Computationally intensive tasks:

[0061] If a task involves a large number of mathematical operations, does not involve frequent disk read / write operations, and has little network interaction, it is initially determined to be a computationally intensive task and marked with a CPU-sensitive tag.

[0062] IO-intensive tasks: If a task involves a large amount of file reading and writing, database querying or network data transmission, and the CPU utilization is lower than the preset value, it is judged as IO-intensive and marked with a disk IO / network sensitive tag.

[0063] Hybrid tasks: If a task simultaneously meets the characteristics of both computationally intensive and computationally intensive tasks, it is marked with a dual CPU+IO sensitivity tag.

[0064] Secondary verification of features based on trial operation:

[0065] For unknown types of tasks that appear for the first time, a micro-sample trial run mechanism is initiated: minimal resources are allocated to run the first 10% of the task process, and the resource consumption curve of this stage is collected.

[0066] Task duration and correlation analysis:

[0067] Runtime: The estimated execution time of the task is analyzed or estimated based on historical data, and the duration is divided into short tasks, medium tasks, and long tasks;

[0068] Relevance: Check if the task is part of a task chain. If a dependency exists, record the associated task ID. During subsequent scheduling, ensure that associated tasks are assigned to servers in the same subnet with a network latency of ≤10ms.

[0069] Preferably, the specific process of matching tasks with target servers according to the preset scheduling strategy in step S4 using a hierarchical filtering method is as follows:

[0070] S41: Filter servers in idle state, servers with a load value ≤ 30%:

[0071] If at least one server exists after filtering, select the server ranked first in descending order of the combined score of resource matching degree and type suitability degree as the target server; if there is no idle server that meets the conditions, proceed to step S42.

[0072] S42: Filter servers in normal condition, servers with 30% < load value ≤ 70%:

[0073] If a server that meets the criteria is found after screening, the target server is determined in the order of priority suitability > resource buffer space > stability score; if the server resources are insufficient in normal state, such as no matching server for high priority tasks, then step S43 is executed.

[0074] S43: Overloaded state server scheduling, only for high-priority tasks:

[0075] If the overloaded server meets the task requirements after migration, it will be identified as the target server; if the migration fails, such as if there is no target server to migrate, or if the overloaded server load value is ≥85% and cannot be migrated, a cluster expansion warning will be triggered and emergency scheduling will be initiated.

[0076] Preferably, the specific process of step S41 is as follows:

[0077] S411: First, perform basic resource matching:

[0078] Select candidate servers from the idle servers that meet the task's resource requirement threshold:

[0079] Matching degree calculation: The matching degree of a single resource is calculated by "(Available server resources - Task requirements) / Task requirements";

[0080] Eliminate invalid candidates: If the matching degree of a certain type of resource on the server is less than 0, exclude it directly;

[0081] S412: Perform task type adaptation:

[0082] From the servers that passed the initial match, further filtering is performed based on task type characteristics:

[0083] For computationally intensive tasks: prioritize servers with the top 30% CPU redundancy and exclude servers with CPU fluctuations greater than 20% in the past hour;

[0084] For IO-intensive tasks: prioritize tasks with IOPS availability ≥ 60%;

[0085] Hybrid task: Calculate the comprehensive score of "CPU matching degree × 0.4 + IO matching degree × 0.4 + stability score × 0.2", and filter the top 50% of servers.

[0086] S413: Perform stability and task duration adaptation:

[0087] Combining load stability score and task duration optimization selection:

[0088] Long tasks exceeding 2 hours: Only selected from servers with a stability score of ≥7;

[0089] For short tasks lasting less than 10 minutes: select from servers with a stability score of ≥5, prioritizing servers with the highest resource matching, without waiting for high-stability servers to release resources.

[0090] Preferably, the specific process of step S42 is as follows:

[0091] S421: Strict verification of resource redundancy:

[0092] In normal operation, servers need to reserve more buffer resources to avoid overload after scheduling; therefore, resource matching standards are raised.

[0093] Core rule: Available server resources must be at least 1.2 times the task requirements;

[0094] Special verification: If the task is of high priority (P0 / P1), additionally check the server load trend slope. If the slope is greater than 0.3, it will be excluded even if the resources match.

[0095] S422: Task Priority and Server Load Balancing Adaptation:

[0096] High-priority tasks: Skip the overall score sorting and directly select the server with the lowest resource matching degree ≥ 0.8 and current load value; Normal-priority tasks: Calculate the server's current load value + the expected increase in load value of the task;

[0097] Type feature secondary adaptation:

[0098] S423: Differentiated use of load stability scores for servers in normal operating conditions:

[0099] If the task is I / O intensive and requires frequent disk reads and writes, select a server with a stability rating of ≥8 points for fluctuation frequency.

[0100] If the task is computationally intensive and requires continuous CPU usage, select a server with a trend slope score ≥ 7 in the stability rating. Preferably, the specific process of step S43 is as follows:

[0101] S431: Overloaded Server Screening and Load Migration Preparation

[0102] Filtering criteria: Select only servers that are overloaded but not at their limit, with a load value of 70%-85%, have not triggered the automatic protection mechanism, and have server hardware specifications that are ≥ 1.5 times the task requirements;

[0103] Migration target determination: Select nodes from idle / normal servers that can undertake the migration task. The nodes must meet the resource requirements of the migration task and the current load ≤ 70%. Servers on the same subnet as the overloaded servers should be given priority.

[0104] S432: Load Migration Execution and Task Allocation

[0105] Migration task selection: based on the principle of low priority and low migration cost;

[0106] Task assignment timing: After the migration is completed, immediately assign the current high-priority tasks to the server and mark it as a temporary protected state, and do not assign new tasks for a specified period of time.

[0107] The beneficial effects of this invention include:

[0108] This invention provides a server cluster scheduling method based on dynamic load balancing. It collects load data from each server in the server cluster in real time; quantifies and evaluates the collected load data using a pre-defined load assessment model to obtain the real-time load value and load stability score of each server; receives external tasks to be processed, and analyzes the resource requirement parameters and task type characteristics of the tasks; determines the target server for the tasks based on server status level, load stability score, task resource requirement parameters, and task type characteristics; and updates the load assessment model and scheduling strategy in real time based on historical scheduling data, task execution feedback data, and industry scenario characteristic parameters. This invention effectively improves the resource utilization and task processing efficiency of server clusters through multi-dimensional load assessment, precise task-server matching, and dynamic strategy optimization, adapting to the needs of different industry scenarios.

[0109] First, by simultaneously collecting static load parameters, dynamic load parameters, and load fluctuation characteristic parameters, and combining them with a load assessment model to calculate real-time load values ​​and load stability scores, this approach breaks through the traditional single assessment mode that relies solely on real-time load values. On the one hand, the introduction of static parameters can accurately reflect the server's hardware redundancy capabilities, avoiding the problem of mismatch between task requirements and hardware. On the other hand, the load stability score can identify servers with drastic load fluctuations, reducing the likelihood of misclassifying such servers as idle and assigning them tasks, thus mitigating the risk of server overload during task execution from the source.

[0110] Secondly, by analyzing the resource requirements and task type characteristics of each task, and combining this with scheduling strategies, targeted allocation is achieved: computationally intensive tasks are prioritized to servers with high CPU performance redundancy, I / O intensive tasks are prioritized to servers with efficient disk I / O, and long tasks are prioritized to servers with high stability. This targeted matching of task characteristics and server capabilities improves task processing efficiency; at the same time, a mechanism that triggers load migration of overloaded servers through high-priority tasks ensures that urgent tasks can still be executed quickly when resources are scarce.

[0111] Furthermore, during the task execution phase, by monitoring the target server load and task progress matching in real time, load migration can be triggered promptly, prioritizing the migration of low-priority, low-migration-cost tasks to minimize the impact of migration on normal tasks. Real-time updates to the load assessment model and scheduling strategy based on historical data, task feedback, and industry scenario parameters ensure the cluster maintains high efficiency under dynamic load and scenario changes, reducing task failure rates caused by load fluctuations.

[0112] Finally, through a closed-loop mechanism of data collection, model update, strategy iteration, and effect feedback, the parameters of the load assessment model and the rules of the scheduling strategy can automatically adapt to changes in cluster load characteristics and task distribution. Simultaneously, by incorporating industry-specific scenario parameters, the scheduling strategy can be customized for specific scenarios, improving the method's versatility and adaptability. Attached Figure Description

[0113] Figure 1 This is a flowchart illustrating the server cluster scheduling method based on dynamic load balancing of the present invention. Detailed Implementation

[0114] The following is in conjunction with the appendix Figure 1 The present invention will be further described in detail below:

[0115] Example 1

[0116] See appendix Figure 1 As shown, a server cluster scheduling method based on dynamic load balancing includes the following steps:

[0117] S1: Real-time collection of load data from each server in the server cluster, including static load parameters, dynamic load parameters, and load fluctuation characteristic parameters.

[0118] S2: The preset load assessment model quantifies the load data, obtains the real-time load value and load stability score of each server, and divides the server into three state levels: idle, normal, and overload based on the real-time load value. The load stability score is used to characterize the degree of fluctuation of the server load within a preset time period.

[0119] S3: Receive external tasks to be processed, and parse the resource requirement parameters and task type characteristics of the tasks to be processed;

[0120] S4: Based on the server's status level, load stability score, task resource requirement parameters, and task type characteristics, determine the target server for the task through a preset scheduling strategy.

[0121] S5: Assign tasks to the corresponding target servers and monitor the load changes and task progress matching degree of the target servers in real time during task execution; if the load value of the target server exceeds the preset overload threshold or the task progress matching degree is lower than the preset threshold, perform load migration.

[0122] S6: Based on historical scheduling data, task operation feedback data, and industry scenario characteristic parameters, update the load assessment model and scheduling strategy in real time.

[0123] The static load parameters are the specified hardware inherent attribute parameters of the server, the dynamic load parameters are the performance parameters that change in real time during server operation, and the load fluctuation characteristic parameters are the fluctuation amplitude, frequency and trend slope of the dynamic load within a preset time period.

[0124] The task progress matching degree is the deviation rate between the actual task progress and the preset progress.

[0125] The resource requirement parameters include the CPU utilization, memory usage, network bandwidth, and task priority required by the task; the task type characteristics include whether the task is compute-intensive, I / O-intensive, or a hybrid type, and the expected runtime of the task.

[0126] The industry scenario characteristic parameters include the distribution pattern of task types within the scenario, the distribution of peak periods, and the common characteristics of resource requirements.

[0127] The scheduling strategy includes:

[0128] Prioritize assigning tasks to servers that are idle and have a load stability score ≥ the preset threshold;

[0129] For compute-intensive tasks, prioritize servers with high CPU performance redundancy; for I / O-intensive tasks, prioritize servers with high disk I / O throughput.

[0130] If a task is of high priority and the normal state server has insufficient resources, then the overloaded state server will be reloaded and the task will be assigned.

[0131] The load fluctuation characteristic parameters are calculated using a sliding window algorithm: a sliding window is used in 5-minute units, the standard deviation of the dynamic load parameters within the window is used as the fluctuation amplitude, the number of peak occurrences is used as the fluctuation frequency, and the linear fitting slope is used as the fluctuation trend.

[0132] Among them, a positive slope indicates that the load is increasing, while a negative slope indicates that the load is decreasing.

[0133] Example 2

[0134] The specific process of using the preset load assessment model in step S2 to quantify and evaluate the load data and obtain the real-time load value and load stability score of each server is as follows:

[0135] S21: Preprocess the load data of each server, filter out the outliers in the dynamic load parameters through the 3σ principle, standardize the parameters of different units into dimensionless values ​​in the 0-1 range, and align the load fluctuation characteristic parameters with the timestamps of the real-time dynamic load parameters.

[0136] S22: Preset base weights based on server type:

[0137] Static load parameters, including the number of CPU cores and total memory capacity, are assigned fixed base weights, accounting for 30% of the total weight in the calculation of real-time load values. Among them, the number of CPU cores accounts for 15%, the total memory capacity accounts for 10%, and the disk storage limit accounts for 5%, because the disk has a relatively low impact on real-time load.

[0138] Dynamic load parameters, including real-time CPU utilization and memory utilization, are assigned dynamic base weights, accounting for 70% of the total weight in the calculation of real-time load values. In the initial state, real-time CPU utilization has a weight of 30%, real-time memory utilization has a weight of 20%, network bandwidth utilization has a weight of 15%, and task queue length has a weight of 5%.

[0139] Load fluctuation characteristic parameters, including fluctuation amplitude, frequency, and trend slope, correspond to the basic weights of 40%, 30%, and 30% for the load stability score, respectively.

[0140] S23: Perform real-time load calculation to quantify the current server load intensity.

[0141] Static load parameter quantification: Based on the maximum capacity of the server hardware, static parameters are converted into quantified values ​​of hardware redundancy.

[0142] Static parameter quantization value = (maximum hardware specification - currently allocated specification) / maximum hardware specification;

[0143] If the server CPU has 32 cores and 8 cores are currently allocated to resident processes, then the CPU static redundancy is (32-8) / 32=0.75, which is 75% redundancy.

[0144] Dynamic load parameter quantification: Based on the server's real-time performance utilization, weights are dynamically adjusted in conjunction with load fluctuation characteristics.

[0145] Basic quantization: Dynamic parameter quantization value = 1 - real-time utilization rate. When the CPU utilization rate is 30%, the quantization value = 0.7.

[0146] Weighting adjustment: If the load fluctuation is greater than the preset threshold, such as CPU utilization fluctuation greater than 20% within 5 minutes, the weight of the dynamic parameter will be reduced, such as the weight of CPU utilization will be reduced from 30% to 20%, while the weight of the more stable parameter (memory utilization) will be increased from 20% to 30%, so as to avoid the parameters with drastic fluctuations from having an excessive impact on the evaluation results.

[0147] Calculate the real-time load value using a weighted summation:

[0148] Real-time load value = (static parameter quantization value × static weight) + (dynamic parameter quantization value × dynamically corrected weight);

[0149] When a server has a static redundancy quantification value of 0.8 and a weight of 30%, a dynamic parameter quantification value of 0.6, and a corrected weight of 70%, then the real-time load value = 0.8 × 30% + 0.6 × 70% = 0.66, which is 66% load intensity, corresponding to a normal state.

[0150] S24: Perform load stability scoring to quantify the risk of server load fluctuations.

[0151] Quantification of load fluctuation characteristic parameters:

[0152] Fluctuation data calculated using a 5-minute sliding window is converted into quantified values:

[0153] Fluctuation range: Based on the standard deviation of dynamic load parameters, it is standardized to 0-10 points. The smaller the standard deviation, the higher the score; for example, a standard deviation of <5% gets 10 points, and a standard deviation of >20% gets less than 3 points.

[0154] Fluctuation frequency: Count the number of times the frequency exceeds the preset threshold within 5 minutes, and standardize it to 0-10 points. ≤1 time gets 10 points, ≥5 times gets 3 points or less;

[0155] Trend slope: Convert the load change trend slope into a score of 0-10. A slope absolute value <0.1 gets 10 points, and >0.5 gets less than 3 points. Avoid classifying servers that are continuously rising / falling as stable.

[0156] Stability score is calculated using preset weights:

[0157] Load stability score = (fluctuation amplitude score × 40%) + (fluctuation frequency score × 30%) + (trend slope score × 30%);

[0158] For example, if a server scores 8 points for fluctuation amplitude, 7 points for fluctuation frequency, and 9 points for trend slope, then its stability score = 8×40%+7×30%+9×30%= 8 points. Since it scores ≥7 points, it is considered a highly stable server.

[0159] Example 3

[0160] Based on Example 1 or Example 2, the specific process of step S3 is as follows:

[0161] S31: Perform preliminary verification on the received tasks, filtering out invalid or abnormal tasks:

[0162] Legality verification: Verify whether the identity identifier carried by the task, including the API key and signature, matches the preset whitelist, and reject unauthorized tasks;

[0163] Completeness check: Check whether the task contains the necessary fields. The necessary fields include task ID, submission time, and basic resource requirement description. If key fields are missing, return a response indicating incomplete parameters and record the missing fields for subsequent user feedback.

[0164] S32: Based on the resource description information carried by the task, i.e. the parameters specified when the task is submitted or the preset task template, extract the four core resource requirements, including CPU requirements: parse the number of CPU cores or the upper limit of CPU utilization expected to be used by the task, such as 2 CPU cores or CPU utilization ≤50%. If the task does not specify, it is estimated based on the average CPU consumption of similar tasks in history. For example, the image compression task is associated with the historical average requirement of 0.5 cores by default.

[0165] Memory Requirements: Extract the memory capacity required for the task, distinguishing between initial memory (used at task startup) and peak memory (maximum used during task execution). The latter serves as the core basis for resource matching. Network Bandwidth Requirements: Determine bandwidth requirements based on whether the task involves data transmission. For example, video transcoding tasks require uplink bandwidth ≥ 10Mbps, while local computing tasks can be set to low bandwidth requirements, ≤ 1Mbps. Storage I / O Requirements: For tasks involving disk read / write operations, including database queries and log analysis, analyze the number of I / O operations per second (IOPS) and read / write throughput.

[0166] S33: Task Priority Analysis and Dynamic Adjustment:

[0167] Basic Priority Extraction: Reads preset priorities from task parameters, such as four levels from P0 to P3, with P0 being the highest. If not specified, it defaults to P2, a normal priority. Dynamic Priority Correction: Adjusts priorities based on task submission time and timeout requirements. For example, a P2 task that has timed out by 10 minutes is automatically promoted to P1, while a P2 task that can be delayed for 24 hours is downgraded to P3, ensuring that urgent tasks receive resources first.

[0168] S34: Initial Classification Based on Task Behavior: Initial classification is performed using task information including task name, executed instructions, and historical execution records. Computationally Intensive Tasks: If a task involves a large number of mathematical operations, has infrequent disk read / write operations, and minimal network interaction, it is initially classified as computationally intensive and tagged with a CPU-sensitive label.

[0169] IO-intensive tasks: If a task involves a large amount of file reading and writing, database queries, or network data transmission, and the CPU utilization is low, it is judged as IO-intensive and marked with a disk IO / network sensitive label. Hybrid tasks: If a task meets both of the above characteristics, it is marked with a CPU+IO dual sensitive label. Secondary verification based on trial runs: For unknown types of tasks appearing for the first time without historical records, a micro-sample trial run mechanism is initiated: The task is allocated minimal resources (0.1 CPU cores and 1GB of memory) to run the first 10% of its process, and the resource consumption curve, CPU utilization, and IOPS changes during this stage are collected. If the CPU utilization remains ≥60% and IOPS ≤100 during the trial run, it is confirmed as computationally intensive; if IOPS ≥500 and CPU utilization ≤30%, it is confirmed as IO-intensive, avoiding misjudgments based solely on initial information.

[0170] Task duration and correlation analysis:

[0171] Runtime: Analyze the estimated execution time of tasks or estimate based on historical data, categorizing tasks into short tasks (<10 minutes), medium tasks (10 minutes - 2 hours), and long tasks (>2 hours). Long tasks should be matched with servers with higher stability to avoid mid-journey migration. Relevance: Check if a task is part of a task chain. If a dependency exists, record the associated task ID. During subsequent scheduling, ensure that associated tasks are assigned to servers in the same subnet with network latency ≤10ms.

[0172] Example 4

[0173] Based on Example 1, Example 2, or Example 3, the specific process of matching tasks with target servers according to the preset scheduling strategy in step S4 using a hierarchical filtering method is as follows:

[0174] S41: Filter idle servers with a load value ≤ 30%: If at least one server exists after filtering, select the server ranked first in descending order of comprehensive score (resource matching degree + type adaptability) as the target server; if there is no idle server that meets the conditions, proceed to step S42.

[0175] S42: Filter servers in normal state, servers with 30% < load value ≤ 70%: If there are servers that meet the criteria after filtering, determine the target server in the order of priority adaptability > resource buffer space > stability score; if the resources of the servers in normal state are insufficient, such as high priority tasks having no matching servers, then proceed to step S43.

[0176] S43: Overloaded server scheduling, only for high-priority tasks: If the overloaded server meets the task requirements after migration, it will be determined as the target server; if the migration fails, such as if there is no target server to migrate, or if the overloaded server load value is ≥85% and cannot be migrated, a cluster expansion warning will be triggered and emergency scheduling will be initiated.

[0177] The specific process of step S41 is as follows:

[0178] S411: First, perform basic resource matching:

[0179] From the idle servers, candidate servers that meet the task resource requirement threshold are selected. The matching degree is calculated as follows: (Available server resources - Task requirements) / Task requirements. For example, if a server has 3 available CPU cores and the task requires 2, then the CPU matching degree is (3-2) / 2 = 0.5. All servers with a resource matching degree ≥ 0 are selected, indicating no resource shortage. Invalid candidates are removed: If the matching degree of a certain type of server resource is < 0, such as 6GB of available memory < 8GB of task requirements, it is directly excluded to avoid task failure due to insufficient resources.

[0180] S412: Task Type Adaptation: From the servers that pass the basic matching, further filter according to task type characteristics. Computation-intensive tasks: Prioritize servers with the top 30% CPU redundancy (e.g., CPU available cores / total cores ≥ 50%), and exclude servers with CPU fluctuations > 20% in the past hour to avoid affecting computational stability. IO-intensive tasks: Prioritize servers with IOPS availability ≥ 60%, i.e., current IOPS usage ≤ 40% peak and SSD storage. If the task involves cross-node data interaction, additionally require server network bandwidth redundancy ≥ 1.2 times the task requirement, reserving buffer space. Mixed tasks: Calculate a comprehensive score of "CPU matching degree × 0.4 + IO matching degree × 0.4 + stability score × 0.2", and filter the top 50% of servers based on the score.

[0181] S413: Perform stability and task duration adaptation:

[0182] Optimize server selection by combining load stability score and task duration: Long tasks: Select only servers with a stability score ≥7 to avoid migration due to load fluctuations. If there are insufficient candidate servers, lower the score to ≥6, but trigger load fluctuation warnings simultaneously. Short tasks: Relax stability requirements (≥5 is sufficient), prioritize servers with the highest resource matching degree, and do not wait for high-stability servers to release resources.

[0183] The specific process of step S42 is as follows:

[0184] S421: Strict verification of resource redundancy:

[0185] In normal operation, servers need to reserve more buffer resources to avoid overload after scheduling; therefore, resource matching standards are raised. Core rule: Available server resources must be at least 1.2 times the task's requirements. For example, if a task requires 2 CPU cores, the server must have at least 2.4 available CPU cores. Special verification: If the task is high priority (P0 / P1), the server load trend slope (load fluctuation characteristic parameter) is additionally checked. If the slope > 0.3 (load continuously rising), the task is excluded even if resources match, to avoid server overload during task execution.

[0186] Task priority and server load balancing adaptation:

[0187] High-priority tasks: Skip the overall score sorting and directly select the server with the lowest resource matching degree (≥0.8) and current load value. If two servers meet the requirements, prioritize the server with a load value of 35% rather than 50%, reserving more load margin. Normal-priority tasks: Calculate the server's current load value plus the task's expected increase in load value. For example, if the server's current load is 40% and the task's expected increase in load is 20%, the total is 60%. Select the server with a total value ≤65%, reserving a 5% buffer.

[0188] Secondary adaptation based on type characteristics: Differentiated use of load stability scores for servers in normal state. If the task is I / O intensive and requires frequent disk read / write operations, select a server with a fluctuation frequency score ≥ 8 in the stability score to avoid sudden fluctuations in disk I / O affecting the task. If the task is compute-intensive and requires continuous CPU usage, select a server with a trend slope score ≥ 7 in the stability score to avoid continuous increases in CPU load causing mid-process slowdown.

[0189] The specific process of step S43 is as follows:

[0190] S431: Overloaded Server Screening and Load Migration Preparation

[0191] Screening criteria: Only select servers that are overloaded but not at their limit, with a load value of 70%-85%, have not triggered automatic protection mechanisms, and have server hardware specifications ≥ 1.5 times the task requirements to ensure sufficient resources after migration. Migration target determination: Select nodes from idle / normal servers that can undertake the migration task. These nodes must meet the migration task resource requirements + current load ≤ 70%, prioritizing servers on the same subnet as the overloaded server (network latency ≤ 5ms).

[0192] S432: Load Migration Execution and Task Allocation

[0193] Migration Task Selection: Based on the principle of low priority and low migration cost, such as tasks with priority P3 and migration time <30 seconds, calculate the total number of tasks to be migrated to ensure that the overloaded server load value drops to ≤60%. Task Allocation Timing: After the migration is completed (confirmed by heartbeat detection that the migration task is running normally), immediately allocate the current high-priority tasks to the server and mark it in a temporary protection state. Do not allocate new tasks within 3 minutes to avoid overload again.

[0194] Step S6 is as follows: First, updates are triggered based on events such as lightweight updates every 30 minutes, daily full updates, or high task failure rates. Next, relevant data is collected. For the load assessment model, the weights of static / dynamic load parameters are adjusted by analyzing the deviation between the model's predicted and actual values; for example, if the prediction deviation for IO-intensive tasks is large, the weight of IO parameters is increased. For the scheduling strategy, optimization rules are implemented based on task efficiency feedback, such as increasing the allocation weight of IO-intensive tasks on SSD servers. Finally, after the update, a canary rollout verification is performed. If no problems are found, a full deployment is carried out, and update logs are recorded to form a data feedback loop.

Claims

1. A server cluster scheduling method based on dynamic load balancing, characterized in that, Includes the following steps: S1: Real-time collection of load data from each server in the server cluster, including static load parameters, dynamic load parameters, and load fluctuation characteristic parameters. The static load parameters are the specified hardware inherent attribute parameters of the server, the dynamic load parameters are the performance parameters that change in real time during server operation, and the load fluctuation characteristic parameters are the fluctuation amplitude, frequency and trend slope of the dynamic load within a preset time period. S2: The preset load assessment model quantifies the load data, obtains the real-time load value and load stability score of each server, and divides the server into three state levels: idle, normal, and overload based on the real-time load value. The load stability score is used to characterize the degree of fluctuation of the server load within a preset time period. The specific process for calculating the load stability score is as follows: Quantification of load fluctuation characteristic parameters: Fluctuation data calculated using a 5-minute sliding window is converted into quantified values: Fluctuation range: based on the standard deviation of dynamic load parameters, standardized to 0-10 points; Fluctuation frequency: Count the number of times the value exceeds the preset threshold within 5 minutes, and standardize it to 0-10 points; Trend slope: Convert the slope of the load change trend into a 0-10 scale. Stability score is calculated using preset weights: Load stability score = (fluctuation amplitude score × 40%) + (fluctuation frequency score × 30%) + (trend slope score × 30%); S3: Receive external tasks to be processed, and parse the resource requirement parameters and task type characteristics of the tasks to be processed; S4: Based on the server's status level, load stability score, task resource requirement parameters, and task type characteristics, determine the target server for the task through a preset scheduling strategy. S5: Assign tasks to the corresponding target servers and monitor the load changes of the target servers and the matching degree of task progress in real time during task execution; If the target server load exceeds the preset overload threshold or the task progress matching degree is lower than the preset threshold, then load migration will be performed. The task progress matching degree is the deviation rate between the actual task progress and the preset progress. S6: Based on historical scheduling data, task operation feedback data, and industry scenario characteristic parameters, update the load assessment model and scheduling strategy in real time.

2. The server cluster scheduling method based on dynamic load balancing according to claim 1, characterized in that, The resource requirement parameters include the CPU utilization, memory usage, network bandwidth, and task priority required by the task; the task type characteristics include whether the task is compute-intensive, I / O-intensive, or a hybrid type, and the expected runtime of the task. The industry scenario characteristic parameters include the distribution pattern of task types within the scenario, the distribution of peak periods, and the common characteristics of resource requirements.

3. The server cluster scheduling method based on dynamic load balancing according to claim 1, characterized in that, The scheduling strategy includes: Prioritize assigning tasks to servers that are idle and have a load stability score ≥ the preset threshold; For compute-intensive tasks, prioritize servers with high CPU performance redundancy; for I / O-intensive tasks, prioritize servers with high disk I / O throughput. If a task is of high priority and the normal state server has insufficient resources, then the overloaded state server will be reloaded and the task will be assigned.

4. A server cluster scheduling method based on dynamic load balancing according to claim 2, characterized in that, The load fluctuation characteristic parameters are calculated using a sliding window algorithm: a sliding window is used in 5-minute units, the standard deviation of the dynamic load parameters within the window is used as the fluctuation amplitude, the number of peak occurrences is used as the fluctuation frequency, and the linear fitting slope is used as the fluctuation trend; where a positive slope indicates that the load is increasing, and a negative slope indicates that the load is decreasing.

5. A server cluster scheduling method based on dynamic load balancing according to claim 1, characterized in that, The specific process of using the preset load assessment model in step S2 to quantify and evaluate the load data and obtain the real-time load value and load stability score of each server is as follows: S21: Preprocess the load data of each server; S22: Preset base weights based on server type: Assign fixed base weights to static load parameters, including the number of CPU cores and total memory capacity; Assign dynamic base weights to dynamic load parameters, including real-time CPU utilization and memory utilization. The load fluctuation characteristic parameters, including fluctuation amplitude, frequency, and trend slope, are assigned specific basic weights to the load stability score. S23: Perform real-time load calculation to quantify the current server load intensity. Static load parameter quantification: Based on the maximum carrying capacity of the server hardware, static parameters are converted into quantified values ​​of hardware redundancy: Static parameter quantification value = (maximum hardware specification - currently allocated specification) / maximum hardware specification; Dynamic load parameter quantification: Based on the server's real-time performance utilization, weights are dynamically adjusted in conjunction with load fluctuation characteristics. Basic quantization: Dynamic parameter quantization value = 1 - real-time utilization rate; Weight adjustment: If the load fluctuation amplitude is greater than the preset threshold, the weight of the dynamic parameter will be reduced, while the weight of the parameter with higher stability will be increased. Calculate the real-time load value using a weighted summation: Real-time load value = (static parameter quantization value × static weight) + (dynamic parameter quantization value × dynamically corrected weight).

6. A server cluster scheduling method based on dynamic load balancing according to claim 1, characterized in that, The specific process of step S3 is as follows: S31: Perform preliminary verification on the received tasks, filtering out invalid or abnormal tasks, including legality verification and integrity verification; S32: Based on the resource description information carried by the task, i.e. the parameters specified when the task is submitted or the preset task template, extract the four core resource requirements, including CPU requirements, memory requirements, network bandwidth requirements and storage I / O requirements. S33: Task Priority Analysis and Dynamic Adjustment: Basic priority extraction: Read the preset priority levels P0-P3 from the task parameters; Priority is dynamically adjusted based on task submission time and timeout requirements; S34: Preliminary judgment based on task behavior type: Preliminary classification based on initial task information: Computationally intensive tasks: If a task involves a large number of mathematical operations, does not involve frequent disk read / write operations, and has little network interaction, it is initially determined to be a computationally intensive task and marked with a CPU-sensitive tag. IO-intensive tasks: If a task involves a large amount of file reading and writing, database querying or network data transmission, and the CPU utilization is lower than the preset value, it is judged as IO-intensive and marked with a disk IO / network sensitive tag. Hybrid tasks: If a task simultaneously meets the characteristics of both computationally intensive and computationally intensive tasks, it is marked with a dual CPU+IO sensitivity tag. Secondary verification of features based on trial operation: For unknown types of tasks that appear for the first time, a micro-sample trial run mechanism is initiated: minimal resources are allocated to run the first 10% of the task process, and the resource consumption curve during the micro-sample trial run is collected. Task duration and correlation analysis: Runtime: The estimated execution time of the task is analyzed or estimated based on historical data, and the duration is divided into short tasks, medium tasks, and long tasks; Relevance: Check if the task is part of a task chain. If a dependency exists, record the associated task ID. During subsequent scheduling, ensure that associated tasks are assigned to servers in the same subnet with a network latency of ≤10ms.

7. A server cluster scheduling method based on dynamic load balancing according to claim 1, characterized in that, The specific process of matching tasks with target servers using the preset scheduling strategy in step S4, which employs a hierarchical filtering approach, is as follows: S41: Filter servers in idle state, servers with a load value ≤ 30%: If at least one server exists after filtering, the server ranked first in descending order of the combined score of resource matching degree and type suitability will be selected as the target server. If no available server meets the criteria, proceed to step S42; S42: Filter servers in normal condition, servers with 30% < load value ≤ 70%: If a server that meets the criteria is found after screening, the target server is determined in the order of priority suitability > resource buffer space > stability score; if the server resources are insufficient in normal state, such as no matching server for high priority tasks, then step S43 is executed. S43: Overloaded state server scheduling, only for high-priority tasks: If the overloaded server meets the task requirements after migration, it will be identified as the target server; if the migration fails, such as if there is no target server to migrate, or if the overloaded server load value is ≥85% and cannot be migrated, a cluster expansion warning will be triggered and emergency scheduling will be initiated.

8. A server cluster scheduling method based on dynamic load balancing according to claim 7, characterized in that, The specific process of step S41 is as follows: S411: First, perform basic resource matching: Select candidate servers from the idle servers that meet the task's resource requirement threshold: Matching degree calculation: The matching degree of a single resource is calculated by "(Available server resources - Task requirements) / Task requirements"; Eliminate invalid candidates: If the matching degree of a certain type of resource on the server is less than 0, exclude it directly; S412: Perform task type adaptation: From the servers that passed the initial match, further filtering is performed based on task type characteristics: For computationally intensive tasks: prioritize servers with the top 30% CPU redundancy and exclude servers with CPU fluctuations greater than 20% in the past hour; For IO-intensive tasks: prioritize tasks with IOPS availability ≥ 60%; Hybrid task: Calculate the comprehensive score of "CPU matching degree × 0.4 + IO matching degree × 0.4 + stability score × 0.2", and filter the top 50% of servers by score; S413: Perform stability and task duration adaptation: Combining load stability score and task duration optimization selection: Long tasks exceeding 2 hours: Only selected from servers with a stability score of ≥7; For short tasks lasting less than 10 minutes: select from servers with a stability score of ≥5, prioritizing servers with the highest resource matching, without waiting for high-stability servers to release resources.

9. A server cluster scheduling method based on dynamic load balancing according to claim 7, characterized in that, The specific process of step S42 is as follows: S421: Strict verification of resource redundancy: In normal operation, servers need to reserve more buffer resources to avoid overload after scheduling; therefore, resource matching standards are raised. Core rule: Available server resources must be at least 1.2 times the task requirements; Special verification: If the task is of high priority (P0 / P1), additionally check the server load trend slope. If the slope is >0.3, it will be excluded even if the resources match. S422: Task Priority and Server Load Balancing Adaptation: High-priority tasks: Skip the overall score sorting and directly select the server with the lowest resource matching degree ≥ 0.8 and the lowest current load value; Normal priority task: Calculate the current server load plus the expected increase in load due to the task; Type feature secondary adaptation: S423: Differentiated use of load stability scores for servers in normal operating conditions: If the task is I / O intensive and requires frequent disk reads and writes, select a server with a stability rating of ≥8 points for fluctuation frequency. If the task is computationally intensive and requires continuous CPU usage, select a server with a trend slope score of ≥7 in the stability rating.

10. A server cluster scheduling method based on dynamic load balancing according to claim 7, characterized in that, The specific process of step S43 is as follows: S431: Overloaded Server Screening and Load Migration Preparation Filtering criteria: Select only servers that are overloaded but not at their limit, with a load value of 70%-85%, have not triggered the automatic protection mechanism, and have server hardware specifications that are ≥ 1.5 times the task requirements; Migration target determination: Select nodes from idle / normal servers that can undertake the migration task. The nodes must meet the resource requirements of the migration task and the current load ≤ 70%. Servers on the same subnet as the overloaded servers should be given priority. S432: Load Migration Execution and Task Allocation Migration task selection: based on the principle of low priority and low migration cost; Task assignment timing: After the migration is completed, immediately assign the current high-priority tasks to the server and mark it as a temporary protected state, and do not assign new tasks for a specified period of time.

Images