A cloud data center virtual machine load prediction and intelligent migration scheduling method

Abstract

The present application relates to the technical field of cloud computing, in particular to a cloud data center virtual machine load prediction and intelligent migration scheduling method, comprising the following steps: collecting CPU, memory, disk IO and network bandwidth indicators of physical machines and virtual machines, forming resource time series and predicting utilization, combining predicted peak value, fluctuation rate, load, virtual machine quantity and fragmentation rate to evaluate overload probability, determining migration virtual machines according to risk, matching target physical machines under multi-dimensional weight and constraint, and adjusting strategy parameters.In the present application, a closed loop is formed through prediction identification, probability evaluation, migration screening, target matching and strategy feedback, so that the scheduling decision is changed from passive response to advance dredging, taking into account business priority, migration cost, affinity constraint and fragmentation management, reducing the risk of physical machine overload, frequent migration, resource imbalance and service level violation, and improving the stability of cloud data center resource utilization.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method for predicting virtual machine load and intelligent migration scheduling in cloud data centers. Background Technology

[0002] The field of cloud computing technology involves software implementations for scheduling and managing computing resources, storage resources, and task execution status within a cloud-based integrated application runtime support platform. Among these, cloud data center virtual machine load prediction refers to the periodic collection of processor utilization, memory utilization, disk read / write volume, and network traffic data from physical hosts and virtual machines by a cloud management server, and the generation of virtual machine load status based on time-series records, threshold rules, or historical load statistics.

[0003] Existing cloud data center virtual machine scheduling relies heavily on real-time monitoring and fixed threshold triggering. Physical machine load assessment lags behind business fluctuations, and the correlation between resource indicators is not fully utilized. Sudden peaks can easily evolve into congestion. Virtual machine migration selection is biased towards single-item occupancy or manual experience. Business priority, affinity constraints, migration costs, and historical migration frequency lack coordinated balancing. Target host matching is mostly centered on remaining capacity, making it difficult to fully release fragmented resources. Long-term fixed scheduling parameters can easily lead to frequent migrations, resource imbalances, and service level breach risks. Summary of the Invention

[0004] The purpose of this invention is to provide a method for predicting virtual machine load and intelligent migration scheduling in cloud data centers. By performing time-series prediction of multi-dimensional resource indicators of physical machines and virtual machines, judging the probability of overload risk, selecting migrated virtual machines, matching target physical machines, and adjusting scheduling strategies, the virtual machine migration scheduling can make decisions based on predicted load changes, real-time operating status, resource fragmentation, and migration stability factors, thereby adapting the virtual machine migration process in the cloud data center to changes in resource load.

[0005] To achieve the above objectives, the present invention provides a method for cloud data center virtual machine load prediction and intelligent migration scheduling, comprising the following steps: Step S1: Obtain resource indicators of central processing unit, memory, disk I / O and network bandwidth of physical machines and virtual machines in the cloud data center, form resource time series in time order of resource indicators, and use stacked LSTM model to predict the resource time series to obtain the central processing unit utilization prediction series.

[0006] Furthermore, the process of generating the CPU utilization prediction sequence includes: acquiring the CPU utilization, memory usage, disk I / O throughput, and network bandwidth usage of physical machines and virtual machines in the cloud data center; aligning different resource indicators according to a unified time granularity; establishing the correlation between resource indicators based on physical machine identifiers, virtual machine identifiers, and collection time; generating resource time series corresponding to each physical machine and virtual machine; inputting the resource time series into a stacked LSTM model; extracting resource change features at different time scales using multiple recurrent layers; and outputting the CPU utilization prediction value within the corresponding time range based on historical resource change relationships to obtain the CPU utilization prediction sequence.

[0007] Step S2: Determine the predicted peak value and load volatility based on the CPU utilization prediction sequence, and input the predicted peak value, load volatility, real-time load, number of virtual machines and resource fragmentation rate into the Bayesian network to obtain the physical machine overload probability, and determine the overload risk level based on the physical machine overload probability.

[0008] Furthermore, the process of determining the physical machine overload probability includes: acquiring the CPU utilization prediction sequence, real-time load, number of virtual machines, and resource fragmentation rate; determining the prediction peak value based on the maximum predicted value in the CPU utilization prediction sequence; determining the load volatility based on the change relationship between consecutive prediction values; establishing a risk input relationship between the prediction peak value, load volatility, real-time load, number of virtual machines, and resource fragmentation rate and the physical machine state; inputting the risk input relationship into a Bayesian network; determining the probability value of the physical machine experiencing an overload state based on the conditional correlation between each risk input parameter; and generating the physical machine overload probability.

[0009] Furthermore, the process of determining the overload risk level includes: obtaining the overload probability of the physical machine and the preset risk level range; comparing the overload probability of the physical machine with each risk level range; when the overload probability of the physical machine reaches the emergency overload range, the corresponding physical machine is determined to be in an emergency overload state; when the overload probability of the physical machine reaches the warning range, the corresponding physical machine is determined to be in a warning state; when the overload probability of the physical machine does not reach the warning range, the corresponding physical machine is determined to be in a normal state, thus obtaining the overload risk level.

[0010] Step S3: For physical machines with an overload risk level of emergency overload or warning status, determine the virtual machine migration score based on resource consumption, business priority, migration cost, specification matching, affinity, and historical migration count, and then select virtual machines to migrate according to the virtual machine migration score.

[0011] Furthermore, the process of selecting virtual machines for migration includes: obtaining a list of running virtual machines corresponding to physical machines with an overload risk level of emergency overload or warning status, and determining virtual machine resource usage parameters, business priority parameters, migration cost parameters, specification matching parameters, affinity constraint parameters, and historical migration count parameters, respectively; calculating a single virtual machine candidate score based on the correlation between each parameter and the overload release requirement; sorting the virtual machine running list in descending order according to the single virtual machine candidate score, and selecting at least one virtual machine under the condition of meeting the upper limit of migration quantity and the lower limit of resource release, thus generating a migrated virtual machine.

[0012] Furthermore, the process of generating a single virtual machine candidate score includes: obtaining a risk score weight table, which records the score weights corresponding to resource usage parameters, business priority parameters, migration cost parameters, specification matching parameters, affinity constraint parameters, and historical migration count parameters; when the overload risk level is emergency overload, increasing the weight ratio of resource usage parameters and migration cost parameters; when the overload risk level is warning state, increasing the weight ratio of business priority parameters and affinity constraint parameters, and performing a weighted calculation based on the adjusted score weights to obtain the single virtual machine candidate score.

[0013] Step S4: Based on the migrated virtual machine, determine the dimension weights according to the available resources of the central processing unit, memory, disk I / O and network bandwidth in the cluster, and determine the comprehensive resource score under hardware compatibility constraints, capacity constraints and anti-affinity constraints, and determine the target physical machine according to the comprehensive resource score.

[0014] Furthermore, the process of determining the target physical machine includes: obtaining the specification requirements of the virtual machine to be migrated and the available resources of the central processing unit, memory, disk I / O, and network bandwidth corresponding to each candidate physical machine in the cluster; determining the dimension weight based on the remaining proportion of each resource dimension and the proportion of the migration virtual machine's demand in the corresponding resource dimension; and, when hardware compatibility constraints, capacity constraints, and anti-affinity constraints are all satisfied, weighting the matching results of each resource dimension with the dimension weight to generate a comprehensive resource score; sorting the candidate physical machines according to the comprehensive resource score, and determining the candidate physical machines that meet the migration acceptance conditions in the sorting results as the target physical machines.

[0015] Additionally, the process of determining the target physical machine also includes: obtaining the current number of migration tasks, network link occupancy status, and historical migration failure records of the virtual machines to be migrated; determining the migration concurrency pressure based on the current number of migration tasks; determining the link receiving pressure based on the network link occupancy status; and determining the receiving stability status based on the historical migration failure records. When the migration concurrency pressure or link receiving pressure reaches a set pressure threshold, the comprehensive resource score of the corresponding candidate physical machine is reduced, and the target physical machine is determined based on the adjusted comprehensive resource score.

[0016] Step S5: Determine the migration plan based on the target physical machine, and adjust the scheduling strategy parameters through genetic algorithm and reinforcement learning based on changes in resource utilization, fragmentation degree, migration frequency, and service level default events.

[0017] Furthermore, the process of determining the migration plan includes: obtaining the target physical machine, the virtual machine to be migrated, the source physical machine, and the migration window configuration; determining the migration object order according to the correspondence between the virtual machine to be migrated and the target physical machine; generating a single migration task based on the remaining capacity of the target physical machine, the network link occupancy status, and the migration concurrency limit; setting the execution order relationship according to the association relationship between the source physical machine and the target physical machine in the single migration task, and writing the execution order relationship into the migration task queue to obtain the migration plan.

[0018] Furthermore, the process of adjusting the scheduling strategy parameters includes: obtaining changes in resource utilization, fragmentation level, migration count, and service level violation events after migration execution; determining the resource consolidation evaluation result based on changes in resource utilization and fragmentation level; and determining the migration stability evaluation result based on the migration count and service level violation events. The resource consolidation evaluation result and migration stability evaluation result are used as inputs for the fitness evaluation of the genetic algorithm to perform selection, crossover, and mutation processing on the combination of scheduling strategy parameters, and the scheduling strategy parameters are determined from the processed candidate combinations of scheduling strategy parameters.

[0019] Compared with the prior art, the advantages and positive effects of the present invention are as follows: A continuous closed loop is formed around resource time-series prediction, risk probability inference, migration target screening, target physical machine matching, and adaptive strategy adjustment. By correlating the indicators of CPU, memory, disk I / O, and network bandwidth over time, peak values ​​and fluctuation trends are predicted. Then, by combining real-time load, number of virtual machines, and fragmentation status, overload risk is characterized, so that migration actions shift from post-event preemption to pre-emptive mitigation. Candidate virtual machine screening simultaneously weighs resource consumption, business priority, migration cost, specification matching, affinity, and historical frequency. Target selection is based on multi-dimensional available resources and constraints to reduce fragmentation. Combined with genetic algorithms and reinforcement learning, strategy parameters are continuously corrected to reduce congestion, migration jitter, and service level default risks. Attached Figure Description

[0020] Figure 1 A schematic diagram of the closed-loop data for virtual machine load prediction and migration scheduling in cloud data centers; Figure 2 Schematic diagram for time alignment and forecasting of resource indicators; Figure 3 A schematic diagram illustrating the risk input and overload risk level output of a Bayesian network; Figure 4A diagram illustrating virtual machine migration scoring and target physical machine matching; Figure 5 This diagram illustrates the feedback of migration task queue and scheduling strategy parameters. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0022] Please see Figures 1 to 5 This embodiment provides a method for predicting virtual machine load and intelligent migration scheduling in cloud data centers.

[0023] Data is collected and recorded from resources and then processed in a time series model. The stacked LSTM model outputs a CPU utilization prediction sequence. This prediction sequence, along with real-time load, number of virtual machines, and resource fragmentation rate, enters a Bayesian network to output the physical machine overload probability. The physical machine overload probability is then compared to a risk level, resulting in an emergency overload status, a warning status, or a normal status. Emergency overload and warning statuses trigger virtual machine migration scoring. Migrating virtual machines then enters a candidate physical machine matching process, outputting the target physical machine. The target physical machine, the source physical machine, and the migration window configuration together generate a migration task queue. After migration execution, resource utilization changes, fragmentation levels, migration counts, and service level default events are generated. This feedback data is then processed by a genetic algorithm and reinforcement learning to output scheduling strategy parameters for subsequent scheduling cycles.

[0024] S1. Obtain resource indicators of central processing unit, memory, disk I / O and network bandwidth of physical machines and virtual machines in the cloud data center, form resource time series in time order of resource indicators, and use stacked LSTM model to predict the resource time series to obtain the central processing unit utilization prediction series.

[0025] S101. The resource acquisition side reads CPU utilization, memory usage, disk I / O throughput, and network bandwidth usage from physical machine monitoring records and virtual machine monitoring records. Each record is written with a physical machine identifier, a virtual machine identifier, and the acquisition time. If a record lacks a physical machine identifier, the bearer node to which the record belongs cannot be determined, and the record is not written into the physical machine resource time series; if a virtual machine identifier is lacking, it is not written into the virtual machine resource time series; if the acquisition time is lacking, the time series position cannot be determined, and the record does not participate in the current prediction period.

[0026] S102. The time alignment process uses a unified time granularity as the alignment benchmark. The resource acquisition side combines the CPU utilization, memory usage, disk I / O throughput, and network bandwidth usage of the same physical machine or virtual machine at the same time location into a single point-in-time resource status. If any one of these resource metrics is missing at a given time point, the record for that time point is marked as incomplete. Whether an incomplete record should be included in the model input can be determined by the data processing configuration supported by the original disclosure; if a completion rule or replacement rule cannot be determined, the incomplete record will not be included in the generation process of the current CPU utilization prediction sequence.

[0027] S103. Resource indicator relationships are established based on "physical machine identifier, virtual machine identifier, and collection time". Physical machine resource indicators under the same physical machine identifier are arranged in ascending order of collection time to form a physical machine resource time series; virtual machine resource indicators under the same virtual machine identifier are arranged in ascending order of collection time to form a virtual machine resource time series. If multiple collection records correspond to the same physical machine identifier, the same virtual machine identifier, and the same collection time, the resource management side retains the available records according to the record selection rules supported by the original disclosure; if an available record cannot be determined, that time position is not used as the current prediction input.

[0028] S104. The stacked LSTM model receives time-aligned resource time series. The fields in the input data maintain a consistent order and include at least CPU utilization, memory usage, disk I / O throughput, and network bandwidth usage. Multiple recurrent layers process the resource time series sequentially, with the resource change characteristics output from the previous recurrent layer entering the next. The output of the stacked LSTM model writes the predicted CPU utilization values ​​for the corresponding prediction time range. These predicted values ​​are arranged by prediction time to form a CPU utilization prediction sequence. This CPU utilization prediction sequence is written to the risk assessment side for S2 to read.

[0029] S105. If the stacked LSTM model does not return a CPU utilization prediction sequence, or if the returned prediction sequence is empty, the current physical machine will not proceed to overload risk calculation based on the prediction results. In this case, the scheduling process can wait for the next acquisition cycle to regenerate the resource time series. If the returned prediction value cannot be sequentially correlated with the corresponding prediction time, the prediction result will not be used as input for the predicted peak and load volatility to avoid using disordered data for subsequent risk level comparisons.

[0030] S2. Determine the predicted peak and load fluctuation rate based on the CPU utilization prediction sequence, and input the predicted peak, load fluctuation rate, real-time load, number of virtual machines and resource fragmentation rate into the Bayesian network to obtain the physical machine overload probability. Determine the overload risk level based on the physical machine overload probability.

[0031] S201. The risk assessment side reads the CPU utilization prediction sequence output by S1. The CPU utilization prediction value with the largest value in the prediction sequence is written as the prediction peak. The prediction peak retains the corresponding physical machine identifier and is subsequently combined only with the real-time load, number of virtual machines, and resource fragmentation rate of the same physical machine, without mixing it with data from other physical machines.

[0032] S202. The risk assessment side reads adjacent predicted values ​​from the CPU utilization prediction sequence in the order of prediction time, and obtains the load volatility based on the changing relationship between consecutive predicted values. The input for load volatility is adjacent predicted values ​​from the same CPU utilization prediction sequence; other resource indicators are not read as substitute inputs. If the prediction sequence has only one predicted value, a changing relationship between adjacent predicted values ​​cannot be formed, and the prediction sequence does not generate load volatility; the physical machine may not enter Bayesian network calculation for the current period, or it may execute according to the default processing state supported by the original disclosure.

[0033] S203. Real-time load is obtained from the physical machine's operating status in the current collection period. The number of virtual machines is obtained from the current virtual machine running list of the physical machine. The resource fragmentation rate is obtained from the resource remaining distribution record stored on the resource management side. If any of the real-time load, number of virtual machines, or resource fragmentation rate is missing, the risk input relationship is incomplete; incomplete risk input relationships are not written into the Bayesian network, and the current physical machine does not output a new physical machine overload probability in this period.

[0034] S204, predicted peak load, load volatility, real-time load, number of virtual machines, and resource fragmentation rate constitute the risk input relationship. Each input parameter is labeled with a physical machine identifier. The Bayesian network reads this risk input relationship and outputs the probability value of a physical machine becoming overloaded based on the conditional relationships between the various risk input parameters. This probability value is recorded as the physical machine overload probability. The physical machine overload probability is then incorporated into the risk level comparison process.

[0035] S205. The risk level comparison process reads the physical machine overload probability and the preset risk level range. The preset risk level range includes an emergency overload range and a warning range. When the physical machine overload probability reaches the emergency overload range, an emergency overload status is output; when the physical machine overload probability reaches the warning range, a warning status is output; when the physical machine overload probability does not reach the warning range, a normal status is output. The output result is written to the overload risk level field of the physical machine.

[0036] S206. If the physical machine's overload probability cannot be compared with the preset risk level range, for example, if the probability value is empty, the probability value format does not meet the input requirements of the risk level comparison process, or the preset risk level range cannot be read, then the physical machine will not output a new overload risk level for this cycle. The overload risk level of the previous cycle must not directly overwrite the calculation result of the current cycle; when it is necessary to use historical risk levels, they should be explicitly read as historical states and distinguished from the current cycle states.

[0037] After S207 and the overload risk level are output, only emergency overload and warning states proceed to S3. Physical machines in normal states do not enter the virtual machine migration screening process. This branch is used to prevent physical machines in normal states from generating migration tasks when there is no migration release requirement.

[0038] S3. For physical machines with an overload risk level of emergency overload or warning status, determine the virtual machine migration score based on resource consumption, business priority, migration cost, specification matching, affinity, and historical migration count, and select virtual machines for migration according to the virtual machine migration score.

[0039] S301. The migration scheduling side reads the physical machine identifiers of those with an overload risk level of emergency overload or warning status, and queries the virtual machine running list based on these physical machine identifiers. The virtual machine running list must at least record the virtual machine identifier and the physical machine where the virtual machine is currently located. If the virtual machine running list is empty, no migration virtual machine will be generated for that physical machine in this cycle; if a virtual machine in the virtual machine running list does not belong to that physical machine, then that virtual machine will not participate in the migration scoring of that physical machine.

[0040] S302. For each virtual machine in the virtual machine running list, read the virtual machine resource usage parameters, service priority parameters, migration cost parameters, specification matching parameters, affinity constraint parameters, and historical migration count parameters. The virtual machine resource usage parameter comes from resource acquisition records or resource management records and represents the resource pressure that can be released after migrating the virtual machine out. The service priority parameter comes from the service management configuration. The migration cost parameter comes from the migration management configuration or historical migration records. The specification matching parameter comes from the matching records between the virtual machine specification requirements and the candidate receiving resource specifications. The affinity constraint parameter comes from the deployment constraint configuration. The historical migration count parameter comes from the virtual machine migration history record.

[0041] S303. If any virtual machine lacks a necessary field from the above scoring input, that virtual machine will not be included in the single virtual machine candidate score calculation. If the business priority parameter or affinity constraint parameter is missing but the original disclosure supports the default configuration, it will be written into the scoring input according to the default configuration; if there is no default configuration, the migration scheduling side will not generate a single virtual machine candidate score for that virtual machine. Records of missing fields should be retained in the abnormal status of the current scheduling cycle for subsequent investigation by the resource management side.

[0042] S304. The migration scheduling side reads the risk scoring weight table. The risk scoring weight table records the scoring weights corresponding to virtual machine resource usage parameters, business priority parameters, migration cost parameters, specification matching parameters, affinity constraint parameters, and historical migration count parameters. Each scoring weight corresponds to a scoring input parameter, and the parameter name or correspondence must not be changed within the same scoring period.

[0043] S305. When the overload risk level is "emergency overload," the migration scheduling side increases the weighting of resource usage parameters and migration cost parameters. The increased weights are used to calculate the candidate scores for each virtual machine on the physical machine. In this processing path, resource usage parameters reflect the contribution of the migrated virtual machine to resource release, and migration cost parameters reflect the impact of the migration process on the current scheduling cycle.

[0044] S306. When the overload risk level is in a warning state, the migration scheduling side increases the weighting of service priority parameters and affinity constraint parameters. The increased weights are used to calculate the candidate scores for each virtual machine on the physical machine. Under this processing path, service priority parameters and affinity constraint parameters are included in the scoring process to avoid conflicts between migration candidates and service carrying relationships or deployment constraints.

[0045] S307. The migration scheduling side, according to the adjusted scoring weights, weights the virtual machine resource usage parameters, service priority parameters, migration cost parameters, specification matching parameters, affinity constraint parameters, and historical migration count parameters for the same virtual machine, and outputs a single virtual machine candidate score. The single virtual machine candidate score is written into the corresponding virtual machine entry in the virtual machine running list.

[0046] S308. The migration scheduling side sorts the virtual machine running list in descending order according to the single virtual machine candidate score. The sorted results enter the migration candidate queue from high to low. The migration candidate queue reads the upper limit of the number of migrations and the lower limit of the number of resources to be released. The migration scheduling side selects migration objects starting from the virtual machines at the top of the sort until the lower limit of the number of resources to be released or the upper limit of the number of migrations is reached. The selected virtual machines are written as migration virtual machines.

[0047] S309. If the sorted list of running virtual machines cannot meet the lower limit of resource release within the migration limit, the migration scheduler outputs the current set of available virtual machines for migration, while retaining the insufficient resource release status. In this status, target physical machines are not directly generated unless the original disclosure supports continuing subsequent matching when resources are insufficient. If all virtual machines are excluded due to incomplete scoring input, unmet affinity constraints, or unsuitable migration status based on historical migration counts, no virtual machines will be generated for migration in this cycle.

[0048] S4. Based on the migrated virtual machines, determine the dimension weights according to the available resources of the central processing unit, memory, disk I / O and network bandwidth in the cluster, and determine the comprehensive resource score under hardware compatibility constraints, capacity constraints and anti-affinity constraints, and determine the target physical machine according to the comprehensive resource score.

[0049] S401. The target matching side reads the migrated virtual machines output by S3. Each migrated virtual machine carries a virtual machine identifier, a source physical machine identifier, and specification requirements. Specification requirements include the migrated virtual machine's requirements for CPU, memory, disk I / O, and network bandwidth. The target matching side simultaneously reads the available CPU resources, available memory resources, available disk I / O resources, and available network bandwidth resources of the candidate physical machines in the cluster.

[0050] S402. The candidate physical machine list is obtained from the cluster resource management records. If a candidate physical machine lacks an available resource record for any resource dimension, it will not be included in the comprehensive resource score calculation for the currently migrated virtual machine. If the candidate physical machine is the same as the source physical machine, it will not be output as the target physical machine.

[0051] S403. The target matching side determines the dimension weights based on the remaining proportion of each resource dimension and the proportion of the migrated virtual machines' demand in the corresponding resource dimensions. The CPU, memory, disk I / O, and network bandwidth each correspond to a dimension weight. These dimension weights are written into the comprehensive resource score calculation process to control the impact of the matching results for each resource dimension on the final ranking.

[0052] S404. The target matching side first performs constraint checks, then scores the results. Constraint checks include hardware compatibility constraints, capacity constraints, and anti-affinity constraints. If the hardware compatibility constraint is not met, the candidate physical machine is directly excluded; if the capacity constraint is not met, the candidate physical machine is directly excluded; if the anti-affinity constraint is not met, the candidate physical machine is directly excluded. Excluded candidate physical machines do not generate a comprehensive resource score.

[0053] S405. For candidate physical machines that pass the constraint check, the target matching side weights the matching results of each dimension (CPU, memory, disk I / O, and network bandwidth) with their corresponding dimension weights, and outputs a comprehensive resource score. This comprehensive resource score is bound to the candidate physical machine identifier and the migrated virtual machine identifier, and written to the candidate physical machine ranking list.

[0054] S406. The target matching side reads the current number of migration tasks, network link occupancy status, and historical migration failure records. The current number of migration tasks is used to obtain the migration concurrency pressure. The network link occupancy status is used to obtain the link reception pressure. Historical migration failure records are used to obtain the reception stability status. All three statuses are bound to the candidate physical machine identifier and are used to adjust the comprehensive resource score of the candidate physical machine.

[0055] S407. When migration concurrency pressure or link reception pressure reaches a set pressure threshold, the target matching side reduces the overall resource score of the corresponding candidate physical machine. The reduced overall resource score is written back to the candidate physical machine ranking list. The reception stability status is used to participate in the candidate physical machine reception condition judgment or overall resource score adjustment. The set pressure threshold is read from the cluster migration configuration; if the set pressure threshold cannot be read, the score reduction process is not executed, but the threshold missing status is retained.

[0056] S408. The target matching side sorts the candidate physical machines according to the adjusted comprehensive resource score. The candidate physical machines that meet the migration acceptance conditions in the sorting results are written as the target physical machines. If no candidate physical machine simultaneously meets the hardware compatibility constraint, capacity constraint, and anti-affinity constraint, then no target physical machine is generated for the current migration virtual machine. If multiple candidate physical machines have the same comprehensive resource score, the target physical machine is determined according to the sorting rules supported by the original disclosure; if no sorting rules are given, the tied candidate status is retained, and a unique target physical machine is not output.

[0057] S5. Determine the migration plan based on the target physical machine, and adjust the scheduling strategy parameters through genetic algorithm and reinforcement learning based on changes in resource utilization, fragmentation degree, migration frequency, and service level default events.

[0058] S501. The migration execution side reads the target physical machine, the virtual machine to be migrated, the source physical machine, and the migration window configuration. The target physical machine comes from S4, the virtual machine to be migrated comes from S3, the source physical machine comes from the virtual machine run list, and the migration window configuration comes from the migration management configuration. If any virtual machine to be migrated lacks a target physical machine or a source physical machine, then that virtual machine will not enter the single migration task generation process.

[0059] S502. The migration execution side determines the migration object order according to the correspondence between the migrated virtual machines and the target physical machines. The migration object order is used to arrange the execution order of multiple migrated virtual machines. If multiple migrated virtual machines correspond to the same target physical machine, the migration execution side arranges the order in which they enter the queue based on the remaining capacity of the target physical machine and the migration concurrency limit. If multiple migrated virtual machines come from the same source physical machine, the migration execution side arranges the execution order based on the current state of the source physical machine.

[0060] S503. The migration execution side reads the remaining capacity of the target physical machine, the network link occupancy status, and the migration concurrency limit, and generates a single migration task. The single migration task includes the migration virtual machine identifier, the source physical machine identifier, the target physical machine identifier, the migration window configuration, and the execution order. If the target physical machine has insufficient remaining capacity, the single migration task is not generated; if the network link occupancy status does not meet the migration reception conditions, the single migration task is not temporarily added to the executable queue; if the current number of migration tasks reaches the migration concurrency limit, subsequent migration tasks enter a waiting state.

[0061] S504. The migration execution side sets the execution order based on the relationship between the source and target physical machines in a single migration task. Migration tasks with the same source physical machine, the same target physical machine, or the same network link occupancy are written into the migration task queue according to the migration concurrency limit and migration window configuration. The order of tasks in the migration task queue is the basis for the execution of the migration plan.

[0062] S505. After the migration is completed, the resource management side re-reads the resource utilization rate and fragmentation level, while the migration management side reads the number of migrations and service level violation events. Changes in resource utilization are obtained by comparing resource utilization records before and after the migration. Fragmentation level is derived from the remaining resource distribution records after the migration. The number of migrations is derived from the migration task execution records. Service level violation events are derived from the service level monitoring records.

[0063] S506. Changes in resource utilization and fragmentation levels are entered into the resource consolidation evaluation process, outputting the resource consolidation evaluation results. Migration frequency and service level default events are entered into the migration stability evaluation process, outputting the migration stability evaluation results. Both evaluation results are written to the scheduling strategy parameter adjustment input area. If migration execution feedback is missing, no new resource consolidation evaluation results or migration stability evaluation results will be generated in this cycle; the scheduling strategy parameters will retain the previous available output or be processed according to the scheduling configuration supported by the original disclosure.

[0064] S507. The genetic algorithm reads the resource management evaluation results and migration stability evaluation results, and uses them as input for fitness evaluation. It then performs selection, crossover, and mutation processing on candidate combinations of scheduling strategy parameters. After fitness evaluation, the processed candidate combinations output scheduling strategy parameters. These parameters are written into subsequent scheduling cycles for use in risk level judgment, virtual machine migration scoring, comprehensive resource scoring, or migration task queue generation.

[0065] S508: Reinforcement learning reads the feedback status generated after migration execution, including changes in resource utilization, fragmentation level, migration count, and service level default events, and reads the scheduling strategy parameters used in the current scheduling cycle. Reinforcement learning adjusts the selection direction of subsequent scheduling strategy parameters based on the feedback status. This adjustment does not change the queue of already executed migration tasks, nor does it write back to the target physical machine already determined in the current cycle.

[0066] S509. If the scheduling strategy parameters output by the genetic algorithm and reinforcement learning conflict, the scheduling execution side determines the scheduling strategy parameters to enter the next scheduling cycle according to the arbitration rules supported by the original disclosure. If no arbitration rules are given, the conflicting parameters are not merged, the previous available scheduling strategy parameters are retained, and the conflict status is recorded. After the scheduling strategy parameters are written into the subsequent scheduling cycle, the resource indicators are reread from S1 in the next cycle and a new processing procedure begins.

[0067] In the above implementation, the resource indicators are sourced from physical machine and virtual machine monitoring records; the CPU utilization prediction sequence is sourced from the output of a stacked LSTM model; the physical machine overload probability is sourced from the Bayesian network output; the overload risk level is sourced from the comparison result of the physical machine overload probability with a preset risk level range; the virtual machine migration is sourced from the virtual machine migration score ranking and the screening results of the upper limit of migration quantity and the lower limit of resource release; the target physical machine is sourced from the comprehensive resource score ranking and migration acceptance conditions; the migration scheme is sourced from the migration virtual machine, source physical machine, target physical machine, and migration window configuration; and the scheduling strategy parameters are sourced from the output of the migration execution feedback after processing by a genetic algorithm and reinforcement learning.

[0068] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for predicting virtual machine load and intelligent migration scheduling in cloud data centers, characterized in that, Includes the following steps: Step S1: Obtain resource indicators of central processing unit, memory, disk I / O and network bandwidth of physical machines and virtual machines in the cloud data center, form resource time series in time order of resource indicators, and use stacked LSTM model to predict the resource time series to obtain the central processing unit utilization prediction series. Step S2: Determine the predicted peak value and load fluctuation rate based on the CPU utilization prediction sequence, and input the predicted peak value, load fluctuation rate, real-time load, number of virtual machines and resource fragmentation rate into the Bayesian network to obtain the physical machine overload probability, and determine the overload risk level based on the physical machine overload probability; Step S3: For physical machines with an overload risk level of emergency overload or warning state, determine the virtual machine migration score based on resource consumption, service priority, migration cost, specification matching, affinity and historical migration count, and select virtual machines to migrate according to the virtual machine migration score. Step S4: Based on the migrated virtual machine, determine the dimension weights according to the available resources of the central processing unit, memory, disk I / O and network bandwidth in the cluster, and determine the comprehensive resource score under hardware compatibility constraints, capacity constraints and anti-affinity constraints, and determine the target physical machine according to the comprehensive resource score; Step S5: Determine the migration scheme based on the target physical machine, and adjust the scheduling strategy parameters through genetic algorithm and reinforcement learning based on resource utilization changes, fragmentation degree, migration times, and service level default events.

2. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 1, characterized in that, In step S1, the process of generating the central processing unit utilization prediction sequence specifically includes: The CPU utilization, memory usage, disk I / O throughput, and network bandwidth usage of physical machines and virtual machines in the cloud data center are obtained. The different resource indicators are time-aligned according to a unified time granularity. The resource indicator correlation is established based on the physical machine identifier, virtual machine identifier, and collection time to generate the resource time series corresponding to each physical machine and virtual machine. The resource time series is input into a stacked LSTM model, and multiple recurrent layers are used to extract resource change features at different time scales. Based on the historical resource change relationship, the CPU utilization prediction value within the corresponding time range is output to obtain the CPU utilization prediction sequence.

3. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 1, characterized in that, In step S2, the process of determining the overload probability of the physical machine specifically includes: The CPU utilization prediction sequence, real-time load, number of virtual machines, and resource fragmentation rate are obtained. The prediction peak value is determined based on the maximum prediction value in the CPU utilization prediction sequence, and the load volatility is determined based on the relationship between the changes in the consecutive prediction values. The prediction peak value, load volatility, real-time load, number of virtual machines, and resource fragmentation rate are used to establish a risk input relationship with the physical machine status. The risk input relationship is input into a Bayesian network, and the probability value of the physical machine being overloaded is determined based on the conditional correlation between each risk input parameter, thus generating the physical machine overload probability.

4. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 3, characterized in that, In step S2, the process of determining the overload risk level specifically includes: Obtain the physical machine overload probability and preset risk level range, and compare the physical machine overload probability with each risk level range; When the probability of physical machine overload reaches the emergency overload range, the corresponding physical machine will be identified as being in an emergency overload state. When the overload probability of a physical machine reaches the warning range, the corresponding physical machine will be identified as being in a warning state. When the overload probability of a physical machine does not reach the warning range, the corresponding physical machine is determined to be in normal condition, and the overload risk level is obtained.

5. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 1, characterized in that, Step S3, the selection process for migrating virtual machines specifically includes: Obtain the list of virtual machines running corresponding to physical machines with overload risk level of emergency overload or warning state, and determine the virtual machine resource consumption parameters, business priority parameters, migration cost parameters, specification matching parameters, affinity constraint parameters and historical migration number parameters respectively. Calculate the candidate score of a single virtual machine based on the correlation between each parameter and the overload release requirement. The virtual machine running list is sorted in descending order according to the single virtual machine candidate score, and at least one virtual machine is selected to generate the migrated virtual machine under the conditions of meeting the upper limit of migration quantity and the lower limit of resource release.

6. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 5, characterized in that, The process of generating the candidate score for a single virtual machine specifically includes: Obtain the risk scoring weight table, which records the scoring weights corresponding to resource consumption parameters, business priority parameters, migration cost parameters, specification matching parameters, affinity constraint parameters, and historical migration count parameters. When the overload risk level is emergency overload, increase the weighting of resource usage parameters and migration cost parameters; When the overload risk level is in a warning state, the weight ratio of the business priority parameter and affinity constraint parameter is increased, and a weighted calculation is performed based on the adjusted scoring weights to obtain the candidate score for the single virtual machine.

7. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 1, characterized in that, Step S4, the process of determining the target physical machine specifically includes: The specification requirements of the migrated virtual machine and the available resources of the central processing unit, memory, disk input / output and network bandwidth of each candidate physical machine in the cluster are obtained. The dimension weight is determined according to the remaining proportion of each resource dimension and the demand proportion of the migrated virtual machine in the corresponding resource dimension. When the hardware compatibility constraint, capacity constraint and anti-affinity constraint are all satisfied, the matching results of each resource dimension are weighted with the dimension weight to generate the comprehensive resource score. The migrated virtual machines are sorted according to the comprehensive resource score, and the migrated virtual machines that meet the migration acceptance conditions in the sorting results are determined as the target physical machines.

8. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 7, characterized in that, The process of determining the target physical machine also includes: The current number of migration tasks, network link occupancy status, and historical migration failure records of the virtual machines to be migrated are obtained. The migration concurrency pressure is determined based on the current number of migration tasks, the link receiving pressure is determined based on the network link occupancy status, and the receiving stability status is determined based on the historical migration failure records. When the migration concurrency pressure or the link reception pressure reaches a set pressure threshold, the comprehensive resource score of the corresponding virtual machine to be migrated is reduced, and the target physical machine is determined based on the adjusted comprehensive resource score.

9. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 1, characterized in that, Step S5, the process of determining the migration plan specifically includes: Obtain the target physical machine, the migration virtual machine, the source physical machine, and the migration window configuration; determine the migration object order according to the correspondence between the migration virtual machine and the target physical machine; and generate a single migration task based on the remaining capacity of the target physical machine, the network link occupancy status, and the migration concurrency limit. The execution order is set according to the association between the source physical machine and the target physical machine in the single migration task, and the execution order is written into the migration task queue to obtain the migration scheme.

10. The cloud data center virtual machine load prediction and intelligent migration scheduling method according to claim 1, characterized in that, In step S5, the process of adjusting the scheduling strategy parameters specifically includes: The system acquires data on changes in resource utilization, fragmentation levels, migration counts, and service level breach events after migration execution. Based on the changes in resource utilization and fragmentation levels, it determines resource consolidation evaluation results and based on the migration counts and service level breach events, it determines migration stability evaluation results. The resource organization evaluation results and the migration stability evaluation results are used as inputs for the fitness evaluation of the genetic algorithm. The scheduling strategy parameter combinations are selected, crossovered, and mutated, and the scheduling strategy parameters are determined from the processed candidate combinations of scheduling strategy parameters.

Images