Disaster recovery resource scheduling method and device based on heterogeneous cloud environment

Abstract

The invention discloses a disaster recovery resource scheduling method and device based on a heterogeneous cloud environment, and the method comprises the steps: constructing a multi-dimensional resource portrait model and a cross-cloud network topological graph in the heterogeneous cloud environment, and generating a standardized resource vector set and a topological affinity scoring matrix; aggregating the local SLA default risk prediction model of each cloud node through federated learning, and performing fine tuning through transfer learning to obtain a global prediction model; calculating load fluctuation entropy based on the SLA constraint template and real-time load data, and inputting the load fluctuation entropy into a global model to predict and obtain an SLA default probability set; constructing and solving a dynamic weight multi-objective optimization function to obtain an optimal takeover cloud node list and a migration strategy identifier set; a target cloud node and a migration strategy are determined through SLA simulation verification, and an adaptive execution adapter is called to complete virtual machine incremental snapshot migration or cross-cloud arrangement deployment of containerized services. According to the invention, intelligent and automatic scheduling of disaster recovery resources is realized, and the fault takeover speed and the cross-cloud resource utilization rate are improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method and apparatus for disaster recovery resource scheduling based on heterogeneous cloud environments. Background Technology

[0002] As enterprises deepen their digital transformation, hybrid cloud and multi-cloud architectures have become the mainstream choice to support business flexibility and high availability. However, while this heterogeneous cloud environment brings elasticity advantages to businesses, it also presents unprecedented challenges to disaster recovery resource scheduling. Traditional disaster recovery solutions, such as primary / standby modes or dual-active data centers, have shown significant shortcomings when dealing with cross-cloud and heterogeneous environments.

[0003] Existing technologies suffer from the following limitations: First, resource allocation is severely uneven. Different cloud service providers have significantly different resource specifications, performance metrics, and pricing models, lacking a unified method for resource measurement and profiling. This leads to an unbalanced disaster recovery resource pool, making it difficult to achieve accurate matching and efficient utilization of cross-cloud loads. Second, fault response latency is high. Cross-cloud network topologies are complex, and migration path quality varies. Traditional methods often rely on static policies or single network metrics (such as latency) for decision-making, failing to dynamically assess end-to-end migration efficiency, resulting in long failover times and slow business recovery. Third, decision-making depends on human experience. Key parameters for disaster recovery scheduling, such as Service Level Agreement (SLA) default risk and resource demand forecasting, are often manually set by operations personnel based on historical experience. This lack of data-driven, accurate forecasting and automated decision-making mechanisms is not only inefficient but also inadequate for handling sudden traffic spikes or complex fault scenarios. Therefore, existing technologies struggle to achieve rapid, intelligent, and automated scheduling of disaster recovery resources while ensuring SLA compliance. Summary of the Invention

[0004] The main purpose of this application is to provide a disaster recovery resource scheduling method and apparatus based on heterogeneous cloud environment, which aims to solve the technical problems of uneven allocation of disaster recovery resources and high response latency in the existing technology in hybrid cloud and multi-cloud environments.

[0005] To achieve the above objectives, this application proposes a disaster recovery resource scheduling method based on a heterogeneous cloud environment. The disaster recovery resource scheduling method based on a heterogeneous cloud environment includes: Construct a multi-dimensional resource profile model and a cross-cloud network topology map in a heterogeneous cloud environment, and generate a standardized resource vector set and a topology affinity scoring matrix based on the multi-dimensional resource profile model and the cross-cloud network topology map; The local SLA default risk prediction models of each cloud node in the heterogeneous cloud environment are aggregated by federated learning, and the aggregated SLA default risk prediction models are fine-tuned by transfer learning to obtain a global SLA default risk prediction model. The load fluctuation entropy is calculated based on the SLA constraint template of the business system and the real-time load status data. The load fluctuation entropy and the standardized resource vector set are then input into the global SLA default risk prediction model for prediction, so as to obtain the future SLA default probability set of each cloud node. A dynamic weighted multi-objective optimization function is constructed based on the SLA constraint template, the load fluctuation entropy, the SLA default probability set, the topology affinity scoring matrix, and the standardized resource vector set. By solving the dynamic weighted multi-objective optimization function, the optimal takeover cloud node list and the corresponding migration strategy identifier set are obtained. Based on the optimal takeover cloud node list and the migration policy identifier set, SLA simulation verification is performed to obtain the target cloud node and the corresponding migration policy identifier. Then, based on the target cloud node and the corresponding migration policy identifier, the execution adapter adapted to the target cloud platform is called to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services.

[0006] Preferably, the step of constructing a multi-dimensional resource profile model and a cross-cloud network topology map in a heterogeneous cloud environment, and generating a standardized resource vector set and a topology affinity scoring matrix based on the multi-dimensional resource profile model and the cross-cloud network topology map, includes: Static configuration data and dynamic performance data of resource instances are collected from multiple heterogeneous cloud platforms in a heterogeneous cloud environment, and a list of network entities is obtained. Extract logical relationship data between resources from the cloud platform configuration management database; The collected static configuration data, dynamic performance data, and logical relationship data are aggregated according to the identifier of the resource instance to generate a corresponding multi-dimensional resource profile model for each resource instance. Using network entities and resource instances from the network entity list as nodes, a directed weighted cross-cloud network topology graph is constructed. The heterogeneous features in the multidimensional resource profiling model are normalized and embedded into a standardized resource vector set. Calculate the network affinity between any two resource instance nodes based on the cross-cloud network topology graph; The topological affinity score matrix is ​​obtained by calculating the network affinity and the cosine similarity of the vectors in the standardized resource vector set.

[0007] Preferably, the step of aggregating the local SLA default risk prediction models of each cloud node in the heterogeneous cloud environment through federated learning, and fine-tuning the aggregated SLA default risk prediction model through transfer learning to obtain a global SLA default risk prediction model includes: On each cloud node, the corresponding local SLA default risk prediction model is trained in parallel using local private historical load data and SLA status labels. Differential privacy technology is used to add noise to the local model parameters and then homomorphically encrypt them; The encrypted local model parameters are uploaded to the federated learning aggregation server for aggregation, generating aggregated global model parameters. The aggregated global model parameters are distributed to each cloud node for fine-tuning to obtain the teacher model for each cloud node; A distillation dataset is constructed based on the unlabeled data of each node, and the distillation dataset is predicted by each of the teacher models to generate a corresponding soft-label dataset. A lightweight student model was trained using the soft-labeled dataset through knowledge distillation, and the student model was used as a global SLA default risk prediction model.

[0008] Preferably, the load fluctuation entropy is calculated based on the SLA constraint template of the business system and real-time load status data, and the load fluctuation entropy and the standardized resource vector set are input into the global SLA default risk prediction model for prediction, to obtain the future SLA default probability set of each cloud node, including: Extract key performance indicators and corresponding constraint thresholds from the SLA constraint template of the business system; Obtain real-time load status data corresponding to the key performance indicators, and determine the relative load rate based on the real-time load status data and the corresponding constraint thresholds; Based on the relative load rate, the load fluctuation entropy is calculated using the information entropy theory. The load fluctuation entropy and the standardized resource vectors in the standardized resource vector set are concatenated to generate a composite feature vector; The composite feature vector is input into the global SLA default risk prediction model to perform multi-step forward prediction based on time series analysis, and the default probability at multiple future time points is output. The default probabilities at multiple future time points are aggregated according to their respective cloud nodes to obtain the future SLA default probability set for each cloud node.

[0009] Preferably, the step of constructing a dynamic weighted multi-objective optimization function based on the SLA constraint template, the load fluctuation entropy, the SLA default probability set, the topology affinity scoring matrix, and the standardized resource vector set, and obtaining the optimal takeover cloud node list and the corresponding migration strategy identifier set by solving the dynamic weighted multi-objective optimization function, includes: The default risk sub-objective is determined based on the SLA default probability set, the resource balance sub-objective is determined based on the load fluctuation entropy, and the migration cost sub-objective is determined based on the topology affinity scoring matrix. The weight coefficients of each optimization sub-objective are determined based on the load fluctuation entropy. Based on the default risk sub-objective, the resource balance sub-objective, the migration cost sub-objective, and the weight coefficients, a dynamic weighted multi-objective optimization function containing multiple optimization sub-objectives is constructed. The constraint thresholds corresponding to the key performance indicators in the SLA constraint template are used as hard constraints for the optimization problem, and the hard constraints are injected into the dynamic weight multi-objective optimization function. A non-dominated sorting genetic algorithm with an elite retention strategy is used to solve the dynamic weight multi-objective optimization function after the injection constraints, generating a Pareto optimal solution set; From the Pareto optimal solution set, solutions that satisfy the resource capacity limit of the standardized resource vector set are selected to obtain the optimal takeover cloud node list; Based on the migration path of each node in the optimal takeover cloud node list, the corresponding migration strategy identifier is extracted from the topology affinity scoring matrix to generate a migration strategy identifier set.

[0010] Preferably, the non-dominated sorting genetic algorithm with an elite retention strategy is used to solve the dynamic weight multi-objective optimization function after the injection constraints to generate a Pareto optimal solution set, including: An initial population of a randomly predetermined size; Calculate the fitness value of each individual in the initial population; The initial population is sorted into multiple non-dominated layers based on fitness values, and crowding distance is calculated for individuals within the same non-dominated layer. Parent individuals are selected from the initial population based on non-dominated sorting and crowding distance using a tournament selection mechanism. Perform simulated binary crossover and polynomial mutation operations on the parent individuals to generate the offspring population; The parent individuals and the offspring population are merged into a new generation population; Determine whether the new generation population meets the preset termination condition. If not, continue iterating. If it does, extract individuals from the top non-dominated layer of the non-dominated sorting from the new generation population to generate the Pareto optimal solution set.

[0011] Preferably, the step of performing SLA simulation verification based on the optimal takeover cloud node list and the migration policy identifier set to obtain the target cloud node and its corresponding migration policy identifier, and then calling the execution adapter adapted to the target cloud platform based on the target cloud node and its corresponding migration policy identifier to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services, includes: Based on the current multi-dimensional resource profiling model and cross-cloud network topology, a digital twin simulation environment for disaster recovery scheduling is constructed. Obtain the historical service traffic corresponding to the first node in the optimal takeover cloud node list; The historical service traffic is injected into the disaster recovery scheduling digital twin simulation environment for SLA simulation verification, and the simulation verification results are obtained. If the simulation verification result shows that the simulation verification meets the standards, the first node will be determined as the target cloud node; If the simulation verification result is that the simulation verification fails, then the next node is selected from the optimal takeover cloud node list to continue the verification until the simulation verification meets the standard. Extract the migration strategy identifier corresponding to the target cloud node from the migration strategy identifier set; Based on the target cloud node and the corresponding migration policy identifier, the execution adapter adapted to the target cloud platform is matched and called from the preset adapter library to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services.

[0012] Preferably, the step of matching and calling an execution adapter adapted to the target cloud platform from a preset adapter library based on the target cloud node and the corresponding migration policy identifier to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services includes: Parse the migration strategy identifier to determine the migration type and migration parameters; Based on the cloud platform type and migration type of the target cloud node, a suitable execution adapter is selected from a preset adapter library. Based on the migration parameters, the execution adapter is configured to generate a migration instruction set; Based on the migration instruction set and the migration type, perform resource migration operations to complete virtual machine incremental snapshot migration or cross-cloud orchestration deployment of containerized services.

[0013] Preferably, the step of performing resource migration operations based on the migration instruction set and the migration type to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services includes: In the case of virtual machine incremental snapshot migration, the source cloud platform is controlled to generate virtual machine incremental snapshots through the migration instruction set; The virtual machine incremental snapshot is transferred to the target cloud platform through the adapted execution adapter, and the virtual machine incremental snapshot is merged with the base image on the target cloud platform to complete the virtual machine incremental snapshot migration; When the migration type is containerized service cross-cloud orchestration deployment, the migration instruction set controls the source cloud platform to export container images and orchestration template files; The container image is uploaded to the image repository of the target cloud platform, and the containerized service is deployed and configured on the target cloud node according to the orchestration template file.

[0014] Furthermore, to achieve the above objectives, this application also proposes a disaster recovery resource scheduling device based on a heterogeneous cloud environment, which includes: The module is used to construct a multi-dimensional resource profile model and a cross-cloud network topology map in a heterogeneous cloud environment, and to generate a standardized resource vector set and a topology affinity scoring matrix based on the multi-dimensional resource profile model and the cross-cloud network topology map. The aggregation module is used to aggregate the local SLA default risk prediction models of each cloud node in the heterogeneous cloud environment through federated learning, and to fine-tune the aggregated SLA default risk prediction models through transfer learning to obtain a global SLA default risk prediction model. The prediction module is used to calculate the load fluctuation entropy based on the SLA constraint template of the business system and the real-time load status data, and input the load fluctuation entropy and the standardized resource vector set into the global SLA default risk prediction model for prediction, so as to obtain the future SLA default probability set of each cloud node. The construction module is further configured to construct a dynamic weighted multi-objective optimization function based on the SLA constraint template, the load fluctuation entropy, the SLA default probability set, the topology affinity scoring matrix, and the standardized resource vector set. By solving the dynamic weighted multi-objective optimization function, the optimal takeover cloud node list and the corresponding migration strategy identifier set are obtained. The verification module is used to perform SLA simulation verification based on the optimal takeover cloud node list and the migration policy identifier set to obtain the target cloud node and the corresponding migration policy identifier, and to call the execution adapter adapted to the target cloud platform based on the target cloud node and the corresponding migration policy identifier to complete the cross-cloud orchestration deployment of virtual machine incremental snapshot migration or containerized services.

[0015] The proposed technical solutions, including one or more, achieve unified measurement and standardized representation of heterogeneous cloud resources by constructing a multi-dimensional resource profile model and a standardized resource vector set, thereby improving the accuracy and comparability of resource description. By aggregating local models of each cloud node through federated learning and combining them with transfer learning for fine-tuning, accurate prediction of global SLA default risk is achieved under data privacy protection, improving the comprehensiveness and timeliness of risk identification. By introducing load fluctuation entropy and constructing a dynamic weighted multi-objective optimization function, adaptive optimization of disaster recovery strategies based on real-time system status is achieved, improving the intelligence level and scenario adaptability of resource scheduling. Through topology affinity scoring matrix and multi-objective optimization solution, comprehensive evaluation and optimal selection of cross-cloud migration paths are achieved, improving the efficiency and reliability of disaster recovery migration. Through digital twin simulation verification and execution adapter mechanism, pre-verification of migration strategies and seamless execution across cloud platforms are achieved, improving the success rate and automation of disaster recovery scheduling, thereby further improving fault takeover speed and resource utilization. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the disaster recovery resource scheduling method based on a heterogeneous cloud environment provided in this application. Figure 2 This is a schematic diagram of the module structure of a disaster recovery resource scheduling device based on a heterogeneous cloud environment, according to an embodiment of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, or a disaster recovery resource scheduling device based on a heterogeneous cloud environment. The following description uses a disaster recovery resource scheduling device based on a heterogeneous cloud environment as an example to illustrate this embodiment and the subsequent embodiments.

[0023] Based on this, embodiments of this application provide a disaster recovery resource scheduling method based on a heterogeneous cloud environment, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the disaster recovery resource scheduling method based on a heterogeneous cloud environment according to this application.

[0024] In this embodiment, the disaster recovery resource scheduling method based on a heterogeneous cloud environment includes steps S10~S50: Step S10: Construct a multi-dimensional resource profile model and a cross-cloud network topology map in a heterogeneous cloud environment, and generate a standardized resource vector set and a topology affinity scoring matrix based on the multi-dimensional resource profile model and the cross-cloud network topology map, wherein each element in the topology affinity scoring matrix represents the quality of the migration path from the source cloud region to the target cloud region.

[0025] It should be noted that a heterogeneous cloud environment refers to a complex cloud computing environment composed of cloud platforms of different types and configurations. Each cloud environment includes multiple cloud nodes, which differ in resource dimensions such as computing power, storage capacity, and network bandwidth.

[0026] A multidimensional resource profile model is a comprehensive abstract representation of resource instances in a cloud platform across multiple resource dimensions. It is formed by collecting multi-source data from various resource instances and aggregating them according to the unique identifier of each resource instance to create a structured data object, namely the multidimensional resource profile model, which is represented in formats such as JSON or Protocol Buffers.

[0027] Cross-cloud network topology graphs are used to describe the network connectivity, bandwidth, latency, and other network attributes between cloud nodes in a heterogeneous cloud environment. They are represented by nodes and edges in graph theory, where nodes represent network entities and resource instances, edges represent connectivity relationships, and edges have weights. The weight of an edge represents an indicator such as network bandwidth or latency.

[0028] The standardized resource vector set is based on the multi-dimensional resource profiling model. It abstracts the resource characteristics of each cloud node into a vector representation with a unified dimension. Through normalization, it eliminates the dimensional differences between different resource dimensions and forms a standardized resource vector set. Each vector element corresponds to a standardized value of a specific resource dimension. That is, the vectors in the standardized resource vector set represent the computing, storage, network and platform compatibility characteristics of the cloud node.

[0029] The topology affinity scoring matrix quantifies the ease or cost of migration between any two resource instances. It is calculated by combining the network affinity between resource instance nodes in the cross-cloud network topology map and the cosine similarity of vectors in the standardized resource vector set. Each element in the matrix reflects the quality of the migration path from the source cloud region to the target cloud region, including quantitative scores of multiple dimensions such as network bandwidth, latency, data transmission efficiency, and resource matching degree. This scoring mechanism helps to prioritize paths with low migration costs, high efficiency, and minimal impact on business during subsequent resource scheduling.

[0030] In practical implementation, open-source graph computing frameworks or custom algorithms can be used to traverse and analyze the cross-cloud network topology graph, extract network parameters such as connection relationships, bandwidth, and latency between nodes, and combine the resource feature vectors of each resource instance in the multi-dimensional resource profile model to calculate the topology affinity score between any two resource instances through a preset scoring algorithm, thereby constructing a topology affinity score matrix.

[0031] In one feasible implementation, step S10 may include: collecting static configuration data and dynamic performance data of resource instances from multiple heterogeneous cloud platforms in a heterogeneous cloud environment, and obtaining a network entity list; extracting logical relationship data between resources from the cloud platform configuration management database, wherein the logical relationship data includes at least load balancing backend service relationships, database master-slave replication relationships, and application and dependent middleware service relationships; aggregating the collected static configuration data, dynamic performance data, and logical relationship data according to the identifier of the resource instance, and generating a corresponding multi-dimensional resource profile model for each resource instance; and using the network entities and resources in the network entity list... Instances are nodes, and logical connections and physical connectivity paths between entities, as well as communication relationships between resource instances, are used as edges to construct a directed weighted cross-cloud network topology graph. The weights of the edges in this graph are assigned based on network latency, bandwidth, or hop count. The heterogeneous features in the multi-dimensional resource profiling model are normalized and embedded, mapping all resource instances to a unified vector space to generate a standardized resource vector set. Based on the edge weights in the cross-cloud network topology graph, the network affinity between any two resource instance nodes is calculated. Finally, a topology affinity scoring matrix is ​​obtained by calculating the cosine similarity between the network affinity and the vectors in the standardized resource vector set.

[0032] It should be noted that static configuration data is obtained from the basic configuration information of resource instances from various heterogeneous cloud platforms, including instance type, number of vCPUs, memory size, operating system, virtual private cloud (VPC) to which it belongs, security group rules, storage type and capacity, etc. Dynamic performance data is collected in real time through monitoring tools, such as CPU utilization, memory usage, network traffic, etc. The network entity list is obtained from various cloud platforms through APIs or SDKs. The network entities in the network entity list include network devices such as virtual machines, containers, and load balancers, as well as network components such as subnets and gateways. Logical relationship data is used to describe the dependency or association relationships between resource instances, including load balancing backend service relationships, database master-slave replication relationships, and application-dependent middleware service relationships. Load balancing backend service relationships are used to determine which instances are backend services of a certain load balancer. Database master-slave replication relationships are used to identify the master and slave nodes in the database cluster and their replication relationships. Application-dependent middleware service relationships are used to record the relationship between the application and the middleware it depends on (such as message queues, caching services, etc.). Static configuration data, dynamic performance data, and logical relationship data are aggregated according to the unique identifier of the resource instance, such as ID, to form a multi-dimensional resource profile model for each resource instance.

[0033] Constructing a cross-cloud network topology graph involves treating network entities and resource instances as nodes in the graph, with logical connections between entities (such as load balancing relationships), physical connectivity paths (such as network topology), and communication relationships between resource instances as edges. Each edge is assigned a weight value based on the actual network conditions, and the weight can be determined based on network latency, bandwidth, or hop count.

[0034] The heterogeneous features in the multidimensional resource profiling model include numerical features, such as vCPU count and memory GB; categorical features, such as disk type and operating system; and temporal features, such as CPU utilization sequence. These heterogeneous features are normalized to map them to a uniform numerical range, such as 0 to 1, eliminating dimensional differences between features. Then, through embedding encoding techniques, such as word embedding or graph embedding, the normalized features are further mapped to a unified vector space, forming a standardized resource vector set.

[0035] When calculating the topology affinity score matrix, a shortest path algorithm, such as Dijkstra's algorithm, is used on the constructed cross-cloud network topology graph. Delay is used as the edge weight to calculate the total delay of the shortest path from source instance i to target instance j. A negative exponential function or its reciprocal function is used to convert the network cost into an affinity score, ensuring the value is between 0 and 1, with lower costs resulting in higher scores. Then, the cosine similarity between two resource vectors in the standardized resource vector set is calculated as the resource similarity. The network affinity score and the resource similarity score are then weighted and summed according to preset weights to obtain the topology affinity score between any two resource instances. This leads to the construction of the topology affinity score matrix. The formula for calculating the topology affinity score is as follows: in, For the topological affinity score of migration from resource i to resource j, For the network latency between resources i and j, For the standardized resource vectors of resources i and j and cosine similarity, is a weighting coefficient used to balance the importance of network and resource similarity.

[0036] Step S20: Aggregate the local SLA default risk prediction models of each cloud node in the heterogeneous cloud environment through federated learning, and fine-tune the aggregated SLA default risk prediction models through transfer learning to obtain the global SLA default risk prediction model.

[0037] It's important to note that federated learning, as a distributed machine learning framework, enables model training by combining data from multiple participants without sharing the original data, thus effectively protecting data privacy. By aggregating local models from various cloud nodes through federated learning, the data resources of each cloud node can be fully utilized, improving the model's generalization ability and predictive accuracy. Transfer learning further fine-tunes the aggregated model, making it better adaptable to the characteristics of heterogeneous cloud environments, resulting in a global SLA default risk prediction model. This model can accurately predict the probability of SLA default for each cloud node within a future period.

[0038] In one feasible implementation, step S20 may include: training a corresponding local SLA default risk prediction model in parallel on each cloud node in the heterogeneous cloud environment using local private historical load data and SLA status labels, and obtaining the corresponding local model parameters; adding noise to the local model parameters using differential privacy technology and homomorphically encrypting the noisy local model parameters to obtain encrypted local model parameters; uploading the encrypted local model parameters to a federated learning aggregation server, so that the federated learning aggregation server uses a federated averaging algorithm to aggregate the encrypted local model parameters to generate aggregated global model parameters; distributing the aggregated global model parameters to each cloud node, and fine-tuning the aggregated global model parameters on each cloud node using few-shot learning technology based on newly generated local labeled data to obtain teacher models for each cloud node; constructing a distillation dataset based on the unlabeled data of each node, and predicting the distillation dataset using each teacher model to generate a corresponding soft-label dataset; training a lightweight student model using the soft-label dataset through knowledge distillation technology, and using the student model as the global SLA default risk prediction model.

[0039] It's important to note that a local dataset is acquired for each cloud node i. This dataset contains historical load data and corresponding SLA status labels. Historical load data represents various performance metrics of the cloud node over a past period, such as CPU utilization, memory usage, and network bandwidth utilization. The SLA status labels indicate whether an SLA default event occurred during that period. Using these local datasets, each cloud node trains its corresponding local SLA default risk prediction model in parallel. This model can be built based on machine learning algorithms, such as support vector machines, random forests, or neural networks. By training, it learns the mapping relationship between historical load data and SLA status labels, thereby predicting the probability of an SLA default occurring in the future. After training, each cloud node obtains its corresponding local model parameters, which contain the knowledge learned by the model.

[0040] To protect data privacy and prevent the leakage of original data during model aggregation, differential privacy technology is used to add noise to the local model parameters. Differential privacy introduces random noise into the original data, making it impossible for attackers to infer the original data of individual participants from the aggregation results, thus protecting data privacy. The noisy local model parameters are then homomorphically encrypted. Homomorphic encryption allows computation on encrypted data without decryption, further enhancing data security. The encrypted local model parameters are uploaded to a federated learning aggregation server, which uses a federated averaging algorithm to aggregate the encrypted parameters. The federated averaging algorithm generates the aggregated global model parameters by calculating a weighted average of the local model parameters. This process does not involve the exchange of original data, thus protecting data privacy.

[0041] The aggregated global model parameters are distributed to each cloud node, but at this point, the global model may not yet be fully adapted to the specific characteristics of each cloud node. Therefore, on each cloud node, the aggregated global model parameters are fine-tuned using locally generated labeled data through few-shot learning. Few-shot learning can quickly adjust model parameters with limited labeled data, allowing them to better adapt to the local environment, thus obtaining the teacher model for each cloud node.

[0042] However, teacher models can still be quite complex, and deploying and running them on resource-constrained cloud nodes may face challenges. To address this, a distillation dataset is constructed based on unlabeled data from each node. This unlabeled data can be widely collected from daily operational data on cloud nodes without additional labeling costs. Subsequently, each teacher model makes predictions on the distilled dataset, generating a corresponding soft-label dataset. Soft labels contain the probability distribution of the teacher model's predictions for the data. Compared to hard labels (i.e., single category labels), soft labels provide richer information, helping student models learn more nuanced feature representations. Using the soft-label dataset, a lightweight student model is trained through knowledge distillation. Knowledge distillation is a model compression technique that transfers knowledge from complex teacher models to simpler student models, enabling student models to maintain high performance while achieving lower computational complexity and smaller model size.

[0043] It's worth noting that knowledge distillation guides the student model to learn the decision boundary and feature representation of the teacher model by minimizing the prediction discrepancy between the student and teacher models on soft-label datasets. After training, the resulting student model is used as a global SLA default risk prediction model and deployed on various cloud nodes in a heterogeneous cloud environment for real-time prediction of SLA default risk on each cloud node. This model not only effectively protects data privacy but also fully utilizes the data resources of each cloud node, improving prediction accuracy and generalization ability, and providing reliable decision support for disaster recovery resource scheduling.

[0044] Step S30: Calculate the load fluctuation entropy based on the SLA constraint template of the business system and the real-time load status data, and input the load fluctuation entropy and the standardized resource vector set into the global SLA default risk prediction model for prediction to obtain the future SLA default probability set of each cloud node.

[0045] It's important to note that the SLA constraint template is a specific quantitative template for the performance metrics and service level requirements set for the business system. It details the threshold ranges for key metrics such as response time, throughput, and availability. Real-time load status data reflects the actual operating status of the business system at any given moment, including the real-time values ​​of various performance metrics. By comparing and analyzing the real-time load status data with the SLA constraint template, the load fluctuation entropy of the business system at that moment can be calculated. Load fluctuation entropy quantifies the degree of load fluctuation in the business system.

[0046] After obtaining the load fluctuation entropy, it is input along with the previously generated standardized resource vector set into the global SLA default risk prediction model. This model has been thoroughly trained and fine-tuned using federated learning and transfer learning techniques, possessing the ability to accurately predict the SLA default risk of each cloud node in a heterogeneous cloud environment. Upon receiving the load fluctuation entropy and standardized resource vector set, the model utilizes the extensive historical data patterns and feature relationships learned during federated learning and transfer learning to predict the future SLA default probability of each cloud node, thus obtaining a set of future SLA default probabilities for each cloud node.

[0047] In one feasible implementation, step S30 may include: extracting key performance indicators and corresponding constraint thresholds from the SLA constraint template of the business system; acquiring real-time load status data corresponding to the key performance indicators, and determining the relative load rate based on the real-time load status data and the corresponding constraint thresholds; calculating the load fluctuation entropy based on the relative load rate using information entropy theory; concatenating the load fluctuation entropy with the standardized resource vectors in the standardized resource vector set to generate a composite feature vector; inputting the composite feature vector into the global SLA default risk prediction model for multi-step forward prediction based on time series analysis, and outputting the default probability at multiple future time points; aggregating the default probabilities at multiple future time points according to their respective cloud nodes to obtain the future SLA default probability set for each cloud node.

[0048] It's important to note that the key performance indicators (KPIs) extracted from the SLA constraint template of the business system are crucial for measuring the system's operational status. These KPIs cover various aspects such as response time, throughput, and availability, while the corresponding constraint thresholds clearly define the standards the business system needs to meet for these KPIs. Real-time data aligned with the KPIs, i.e., real-time load status data, is pulled from the monitoring system. The ratio of this real-time load status data to the corresponding constraint thresholds is calculated to obtain the relative load rate for each KPI. The relative load rate directly reflects the degree to which the business system's load deviates from the normal range for that KPI. Information entropy theory can be used to measure system uncertainty. Based on the relative load rate, load fluctuation entropy is calculated using formulas for calculating information entropy, such as the Shannon entropy formula. The higher the load fluctuation entropy value, the more drastic the fluctuation in the business system's load.

[0049] For each key performance indicator dimension, its relative load rate sequence is treated as a discrete distribution and normalized to a probability distribution as follows: in, Indicates within the time window within, no. The normalized probability value of the relative load rate of the j-th key performance indicator at time point j. For the first The relative load rate of the j-th key performance indicator at time point j. It is a very small positive number, used to avoid the case where the denominator is zero.

[0050] Based on the probability distribution obtained above, the load fluctuation entropy for each key performance indicator dimension is calculated using the Shannon entropy formula, as follows: in, The load fluctuation entropy of the j-th key performance indicator dimension is obtained by taking the logarithm of the probability value at each time point, multiplying it by the probability value itself, summing it over all time points and taking the negative value.

[0051] The magnitude of the load fluctuation entropy reflects the degree of load fluctuation in the business system at that critical performance indicator dimension; the larger the value, the more severe the fluctuation. After calculating the load fluctuation entropy for each critical performance indicator dimension, the load fluctuation entropy of all dimensions is summarized to obtain the overall load fluctuation entropy of the business system.

[0052] The calculated load fluctuation entropy and the standardized resource vectors from the standardized resource vector set are concatenated. The concatenation method can combine the elements of both in a specific order to form a new vector, namely a composite feature vector. This composite feature vector integrates the load fluctuation information of the business system and the resource characteristic information of the cloud node, and can more comprehensively reflect the possibility of the cloud node defaulting on its SLA in the future.

[0053] The generated composite feature vector is input into a global SLA default risk prediction model, which employs a multi-step forward prediction method based on time series analysis. Time series analysis takes into account the correlation and trends of data over time, while multi-step forward prediction can predict the default probability at multiple future time points. The model analyzes and processes the input composite feature vector, utilizing the patterns and rules learned during training to output the default probabilities at multiple future time points. The default probabilities at multiple future time points are then aggregated according to their respective cloud nodes. That is, the default probabilities at various time points belonging to the same cloud node are organized and summarized to obtain the future SLA default probability set for each cloud node.

[0054] Step S40: Construct a dynamic weighted multi-objective optimization function based on the SLA constraint template, the load fluctuation entropy, the SLA default probability set, the topology affinity scoring matrix, and the standardized resource vector set. By solving the dynamic weighted multi-objective optimization function, obtain the optimal takeover cloud node list and the corresponding migration strategy identifier set.

[0055] It should be noted that the dynamic weighted multi-objective optimization function in this embodiment is constructed with default risk, resource balance, and migration cost as objectives. The default risk objective is set based on the SLA default probability set, aiming to minimize the possibility of SLA defaults at each cloud node and ensure the stable operation of the business system. The resource balance objective is set based on load fluctuation entropy, aiming to balance the resource usage of each cloud node, avoiding situations where some cloud nodes are overloaded while others are idle, thereby improving the resource utilization of the entire heterogeneous cloud environment. The migration cost objective is set based on the topology affinity scoring matrix, comprehensively considering the network topology relationships between cloud nodes and the ease of resource migration, striving to minimize costs during resource migration.

[0056] Understandably, after constructing the dynamic weighted multi-objective optimization function, a suitable optimization algorithm is used to solve it. Common optimization algorithms include genetic algorithms and particle swarm optimization algorithms, which can search for optimal solutions in a complex solution space. Through continuous iteration and optimization, an optimal takeover cloud node list is finally obtained. This list clarifies which cloud nodes can act as takeover nodes to ensure business continuity in the event of a potential SLA breach. Simultaneously, a corresponding migration strategy identifier set is obtained. This set details the specific migration strategies to be adopted for different situations, such as the amount of data to be migrated and the migration order, thus providing a precise and feasible solution for disaster recovery resource scheduling.

[0057] In one feasible implementation, step S40 may include: determining a default risk sub-objective based on the SLA default probability set, determining a resource balance sub-objective based on the load fluctuation entropy, and determining a migration cost sub-objective based on the topology affinity scoring matrix; determining the weight coefficients of each optimization sub-objective according to the load fluctuation entropy; constructing a dynamic weighted multi-objective optimization function containing multiple optimization sub-objectives based on the default risk sub-objective, the resource balance sub-objective, the migration cost sub-objective, and the weight coefficients; using the constraint thresholds corresponding to the key performance indicators in the SLA constraint template as hard constraints for the optimization problem, and injecting the hard constraints into the dynamic weighted multi-objective optimization function to obtain a constraint-injected dynamic weighted multi-objective optimization function; solving the constraint-injected dynamic weighted multi-objective optimization function using a non-dominated sorting genetic algorithm with an elite retention strategy to generate a Pareto optimal solution set; selecting solutions that satisfy the resource capacity limit of the standardized resource vector set from the Pareto optimal solution set to obtain an optimal takeover cloud node list; and extracting the corresponding migration strategy identifiers from the topology affinity scoring matrix according to the migration paths of each node in the optimal takeover cloud node list to generate a migration strategy identifier set.

[0058] It should be noted that the default risk sub-objective is used to minimize the future SLA default risk, as shown in the following formula: in, Let M represent the value of the sub-objective function for default risk, and T represent the total number of cloud nodes and the total number of predicted future time points. This represents the probability of SLA default for the j-th cloud node at time k. As a decision variable, when the j-th cloud node is selected as the takeover node The value is 1 if it is not 0 otherwise. By minimizing this function value, the likelihood of future SLA defaults can be reduced.

[0059] The resource leveling sub-objective aims to avoid concentrating the load on a few nodes and to make resource utilization as evenly distributed as possible among the nodes, as shown in the following formula: in, This represents the value of the resource balance sub-objective function, where M represents the total number of cloud nodes. This represents the resource utilization rate of the j-th cloud node. This represents the average utilization rate of all selected nodes. By minimizing this function value, the resource utilization of each cloud node can be made as balanced as possible, avoiding resource overload or idleness.

[0060] The migration cost sub-objective is used to minimize the performance overhead and time latency caused by the migration process, as shown in the following equation: in, This represents the migration cost sub-objective function value, where N represents the number of services that need to be migrated, and M represents the total number of cloud nodes. This represents the topology affinity score for migrating the i-th service from the original node to the j-th cloud node (a higher score indicates lower migration difficulty and cost). The function is a decision variable. It takes the value 1 when the i-th service is migrated to the j-th cloud node, and 0 otherwise. By minimizing the value of this function, the cost of resource migration can be reduced.

[0061] After determining the three sub-objective functions, the weight coefficients of each sub-objective need to be dynamically adjusted based on the load fluctuation entropy. When the load fluctuation entropy is large, it indicates that the load fluctuation of the business system is relatively drastic. In this case, more attention should be paid to resource balance, and the weight coefficient of the resource balance sub-objective should be appropriately increased to avoid performance bottlenecks in some cloud nodes due to excessive load. At the same time, the default risk will also increase due to load fluctuations, so the weight coefficient of the default risk sub-objective should also be kept at a high level. The weight coefficient of the migration cost sub-objective can be relatively reduced because ensuring business continuity and resource balance is more important in emergency situations. When the load fluctuation entropy is small, it indicates that the load of the business system is relatively stable. In this case, the weight coefficient of the resource balance sub-objective can be appropriately reduced, and the weight coefficient of the migration cost sub-objective can be increased. Under the premise of ensuring stable business operation, the resource migration cost should be reduced as much as possible, while the weight coefficient of the default risk sub-objective can be kept within a reasonable range.

[0062] Based on the defined sub-objectives of default risk, resource balance, and migration cost, along with dynamically adjusted weight coefficients, a dynamic weighted multi-objective optimization function is constructed, incorporating multiple optimization sub-objectives. The constraint thresholds corresponding to key performance indicators in the SLA constraint template are used as hard constraints for the optimization problem, such as response time not exceeding a specific value or throughput reaching a certain standard. These hard constraints are then injected into the dynamic weighted multi-objective optimization function, resulting in a constraint-injected dynamic weighted multi-objective optimization function. This ensures that the optimization results meet the basic performance requirements of the business system.

[0063] A non-dominated sorting genetic algorithm with an elite retention strategy is employed to solve a dynamic weighted multi-objective optimization function with injected constraints. This algorithm searches for optimal solutions in a complex solution space by simulating natural selection and genetic mechanisms. During iteration, elite individuals (solutions with high fitness) from each generation are retained to avoid losing excellent solutions. After multiple iterations and optimizations, a Pareto optimal solution set is generated. These solutions achieve a good balance among multiple objectives, making it impossible to further optimize any one objective without compromising other objectives.

[0064] Solutions that satisfy the resource capacity constraints of the standardized resource vector set are selected from the Pareto optimal solution set. The standardized resource vector set reflects the resource capacity of each cloud node. The selection process ensures that the takeover cloud node corresponding to the selected solution has sufficient resources to handle any potential service migration, thus obtaining an optimal takeover cloud node list. This list clarifies which cloud nodes can act as takeover nodes to ensure service continuity in the event of a potential SLA breach.

[0065] Based on the migration paths of each node in the optimal takeover cloud node list, the corresponding migration strategy identifiers are extracted from the topology affinity scoring matrix. The topology affinity scoring matrix contains information on the network topology relationships between cloud nodes and the ease or difficulty of resource migration. By extracting the corresponding migration strategy identifiers, the specific migration strategies to be adopted for different situations can be detailed, such as the amount of data to be migrated and the migration order. Finally, a set of migration strategy identifiers is generated, providing an accurate and feasible solution for disaster recovery resource scheduling.

[0066] In one feasible implementation, the non-dominated sorting genetic algorithm with an elite retention strategy solves the dynamic weighted multi-objective optimization function after the injection constraints to generate a Pareto optimal solution set, including: an initial population of a randomly preset size, wherein the chromosome of each individual in the initial population uses a hybrid encoding, with the first part of the chromosome being binary encoding representing the selection state of candidate nodes and the second part being real-number encoding representing the resource allocation ratio; calculating the fitness value of each individual in the initial population, wherein the fitness value is obtained by a weighted combination of the function values ​​of each sub-objective in the dynamic weighted multi-objective optimization function after the injection constraints; and performing non-dominated sorting on the initial population based on the fitness value. The process involves sorting individuals into multiple non-dominated layers and calculating crowding distances for individuals within the same non-dominated layer. Based on the non-dominated sorting and crowding distances, a tournament selection mechanism is used to select parent individuals from the initial population. Simulated binary crossover and polynomial mutation operations are performed on the parent individuals to generate offspring. The parent individuals and the offspring population are merged into a new generation population. It is determined whether the new generation population meets a preset termination condition. If not, the new generation population is used as the initial population, and the process returns to calculating the fitness value of each individual in the initial population. If the condition is met, individuals from the top-ranked non-dominated layer of the new generation population are extracted to generate a Pareto optimal solution set.

[0067] It should be noted that the initial population of a randomly pre-set size is intended to cast a wide net across the solution space, increasing the likelihood of finding a high-quality solution. The chromosome of each individual in the initial population uses a hybrid encoding method, which has unique advantages. The first part of the chromosome uses binary encoding to represent the selection status of candidate nodes, which is simple and intuitive, clearly showing which nodes have been selected to participate in subsequent operations. The second part of the chromosome uses real-number encoding to represent the resource allocation ratio. This encoding method can more accurately describe the resource allocation situation and avoid the precision loss caused by discrete encoding.

[0068] The fitness value is obtained by weighted combination of the function values ​​of each sub-objective in the dynamic weighted multi-objective optimization function after the constraints are injected. This calculation method comprehensively considers multiple objectives such as default risk, resource balance and migration cost, and can fully reflect the individual's performance in the optimization problem.

[0069] Ranking the initial population by fitness values ​​into multiple non-dominated layers allows superior individuals to stand out more clearly. Calculating crowding distance within the same non-dominated layer prevents excessive concentration of superior individuals in subsequent selection processes, ensuring solution diversity. The formula for calculating crowding distance is: in, Let represent the crowding distance of the i-th individual, and m represent the number of objective functions, which are three in this implementation: default risk, resource balance, and migration cost. and Let represent the function values ​​of the two individuals adjacent to the i-th individual on the m-th objective function. and Let represent the maximum and minimum values ​​of the m-th objective function, respectively.

[0070] By calculating the crowding distance, we can measure the sparseness of an individual's distribution in the solution space. The larger the distance, the sparser the individual's surroundings, and the more likely it is to be retained in the subsequent selection process.

[0071] A tournament selection mechanism is employed based on non-dominated sorting and crowding distance to select parent individuals from the initial population. This selection mechanism ensures the selection of excellent individuals while also considering solution diversity. Simulated binary crossover and polynomial mutation operations are performed on the parent individuals to generate the offspring population. Simulated binary crossover simulates the crossover process in binary encoding, while polynomial mutation performs effective mutation operations on real-number encoding, thereby generating new individuals and increasing population diversity.

[0072] Merging parent and offspring individuals into a new generation population aims to combine the strengths of both generations and further optimize the solution quality. The process checks if the new generation population meets a preset termination condition. If not, it becomes the initial population, and the process returns to calculating the fitness value of each individual in the initial population. Through iterative iteration, the optimal solution is gradually approximated. If the condition is met, individuals from the top-ranked non-dominated layer of the new generation population are extracted to generate a Pareto optimal solution set. These solutions achieve a good balance among multiple objectives, providing a foundation for subsequent selection of the optimal takeover cloud node list.

[0073] Step S50: Perform SLA simulation verification based on the optimal takeover cloud node list and the migration policy identifier set to obtain the target cloud node and the corresponding migration policy identifier. Then, based on the target cloud node and the corresponding migration policy identifier, call the execution adapter adapted to the target cloud platform to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services.

[0074] It should be noted that SLA simulation verification verifies the optimal takeover cloud node list and migration strategy identifier set obtained by simulating the actual business operation environment, so as to ensure that the selected takeover cloud node and migration strategy can truly guarantee business continuity and performance in the event of an actual SLA default.

[0075] In practical implementation, SLA simulation verification can be carried out by constructing a disaster recovery scheduling digital twin simulation environment. This environment can highly replicate actual business operation scenarios, including network topology, resource distribution, and business load characteristics. Within the simulation environment, historical business traffic from each node in the optimal takeover cloud node list is injected for simulation operation. Based on the verification results, the target cloud node that meets the business performance requirements and its corresponding migration strategy identifier are determined.

[0076] This embodiment provides a disaster recovery resource scheduling method based on heterogeneous cloud environments. By constructing a multi-dimensional resource profile model and a standardized resource vector set, it achieves unified measurement and standardized representation of heterogeneous cloud resources, improving the accuracy and comparability of resource description. By aggregating local models of each cloud node through federated learning and combining them with transfer learning for fine-tuning, it achieves accurate prediction of global SLA default risk under data privacy protection, improving the comprehensiveness and timeliness of risk identification. By introducing load fluctuation entropy and constructing a dynamic weighted multi-objective optimization function, it achieves adaptive optimization of disaster recovery strategies based on real-time system status, improving the intelligence level and scenario adaptability of resource scheduling. Through topology affinity scoring matrix and multi-objective optimization solution, it achieves comprehensive evaluation and optimal selection of cross-cloud migration paths, improving the efficiency and reliability of disaster recovery migration. Through digital twin simulation verification and execution adapter mechanism, it achieves pre-verification of migration strategies and seamless execution across cloud platforms, improving the success rate and automation of disaster recovery scheduling, thereby further improving fault takeover speed and resource utilization.

[0077] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, step S50 includes steps S501 to S507: Step S501: Based on the current multi-dimensional resource profile model and cross-cloud network topology, construct a disaster recovery scheduling digital twin simulation environment.

[0078] It should be noted that, based on a standardized resource vector set, virtual node objects are created in the simulation environment, and their computing / storage / network capabilities are configured. Communication links between nodes are configured according to edge weights in the cross-cloud network topology graph, such as latency and bandwidth. The service topology of the services to be migrated, such as microservice call chains and database master-slave relationships, is mapped to the simulation nodes. SLA metric collectors, such as response time, error rate, and resource utilization, are embedded in the simulation to collect real-time service operation status. Through these steps, a disaster recovery scheduling digital twin simulation environment that highly replicates the actual business operation scenario can be built, providing a solid foundation for subsequent SLA simulation verification.

[0079] Step S502: Obtain the historical service traffic corresponding to the first node in the optimal takeover cloud node list.

[0080] It should be noted that historical business traffic data can be obtained from the cloud node's log system or monitoring system. This data records the traffic carried by the node over a period of time, including key indicators such as the number of requests and data transfer volume. Obtaining this data is to simulate real business load in a simulation environment, thereby more accurately evaluating the performance of the optimal takeover cloud node in actual business operations.

[0081] Step S503: Inject the historical service traffic into the disaster recovery scheduling digital twin simulation environment for SLA simulation verification, and obtain the simulation verification results.

[0082] It should be noted that historical business traffic is injected into the corresponding virtual node in the disaster recovery scheduling digital twin simulation environment according to its original time sequence and intensity. After the simulation is started, the processing of business on the node is simulated. During the simulation, SLA indicators in the virtual environment, such as application response time, error rate, and system resource utilization, are continuously monitored.

[0083] Simulation verification results are categorized as either "simulation verification meets standards" or "simulation verification fails to meet standards." "Simulation verification meets standards" means that all key SLA metrics (derived from the SLA constraint template) are better than preset thresholds throughout the entire simulation cycle. For example, the 95th percentile response time is consistently <150ms, and CPU utilization is <80%. In this case, the loop terminates, and the currently selected node is designated as the target cloud node. "Simulation verification fails to meet standards" means that any SLA metric is violated. In this case, the next node is automatically selected from the list, and the process returns to retrieve the historical service traffic corresponding to that new node. This process repeats until a node that meets the standards is found.

[0084] Step S504: If the simulation verification result shows that the simulation verification meets the standards, the first node is determined as the target cloud node. It should be noted that when the simulation verification results meet the standards, the selected first node can meet the business performance requirements in the actual business operation scenario and is qualified to serve as the target cloud node to undertake the possible migration of services. At this time, determining the first node as the target cloud node provides a clear target object for subsequent virtual machine incremental snapshot migration or cross-cloud orchestration deployment of containerized services.

[0085] Step S505: If the simulation verification result is that the simulation verification fails, then select the next node from the optimal takeover cloud node list, return to the step of obtaining the historical service traffic corresponding to the first node in the optimal takeover cloud node list, until the simulation verification meets the standard, and take the determined compliant node as the target cloud node.

[0086] It's important to note that if the simulation verification result of the first node fails to meet the standards, it means that the node may not meet the performance requirements in actual business operations and cannot be used as a target cloud node to take over the migrated services. Therefore, it is necessary to select the next node from the optimal takeover cloud node list, re-acquire its corresponding historical business traffic, and inject it again into the disaster recovery scheduling digital twin simulation environment for SLA simulation verification. This process will be repeated until a node that meets the simulation verification standards is found. Once a node that meets the standards is found, it is designated as the target cloud node, providing a clear target object for subsequent virtual machine incremental snapshot migration or cross-cloud orchestration deployment of containerized services. This step-by-step selection method ensures that the selected target cloud node has sufficient performance and reliability in actual business operations, thereby guaranteeing the continuity and stability of services.

[0087] Step S506: Extract the migration strategy identifier corresponding to the target cloud node from the migration strategy identifier set.

[0088] It's important to note that the migration policy identifier set contains multiple migration policies for different cloud nodes, each with its own specific identifier. After identifying the target cloud node, the migration policy identifier corresponding to that target cloud node needs to be extracted from this set. This step ensures that the most suitable migration policy for the target cloud node is adopted during subsequent migrations, thereby achieving high efficiency and accuracy in virtual machine incremental snapshot migrations or cross-cloud orchestration deployments of containerized services.

[0089] Step S507: Based on the target cloud node and the corresponding migration policy identifier, match and call the execution adapter adapted to the target cloud platform from the preset adapter library to complete the cross-cloud orchestration deployment of virtual machine incremental snapshot migration or containerization services.

[0090] It's important to note that the pre-defined adapter library stores various execution adapters adapted to different cloud platforms. These adapters possess the ability to interact and operate with the target cloud platform. By matching and invoking the execution adapter adapted to the target cloud platform from the adapter library, the compatibility and smoothness of the migration process with the target cloud platform can be ensured. The execution adapter will perform the corresponding virtual machine incremental snapshot migration or cross-cloud orchestration deployment operation for containerized services based on the target cloud node and the corresponding migration policy identifier, thereby completing the entire disaster recovery resource scheduling process. This step further improves the automation and flexibility of disaster recovery scheduling, making resource migration and business deployment between different cloud platforms more efficient and reliable.

[0091] In one feasible implementation, step S507 may include: parsing the migration policy identifier to determine the migration type and migration parameters, wherein the migration type includes virtual machine incremental snapshot migration and containerized service cross-cloud orchestration deployment, and the migration parameters include at least resource allocation and network bandwidth requirements; selecting suitable execution adapters from a preset adapter library based on the cloud platform type of the target cloud node and the migration type; configuring the execution adapters based on the migration parameters to generate a migration instruction set; and performing resource migration operations based on the migration instruction set and the migration type to complete the virtual machine incremental snapshot migration or containerized service cross-cloud orchestration deployment.

[0092] It's important to note that parsing migration policy identifiers clarifies the specific migration type, such as whether it's an incremental snapshot migration of virtual machines or a cross-cloud orchestration deployment of containerized services. It also allows for precise acquisition of related migration parameters, such as resource allocation and network bandwidth requirements. Incremental snapshot migration of virtual machines focuses on the rapid capture and recovery of virtual machine states, while cross-cloud orchestration deployment of containerized services prioritizes the overall migration of container services and their orderly operation in the new environment. Determining migration parameters ensures that resource allocation guarantees sufficient resources on the target cloud node to support the migration, and network bandwidth requirements ensure smooth data transmission.

[0093] Understandably, based on the target cloud node's cloud platform type and the determined migration type, suitable execution adapters are selected from a pre-defined adapter library. Specifically, this involves: first, traversing and analyzing each execution adapter in the pre-defined adapter library to determine if it supports the target cloud node's cloud platform type. For execution adapters that support this cloud platform type, further checks are conducted to see if they have the capability to handle the determined migration type. For example, if the migration type is a virtual machine incremental snapshot migration, adapters capable of performing this type of migration are selected; if the migration type is containerized service cross-cloud orchestration deployment, adapters capable of implementing this deployment function are selected. Through this dual selection process, suitable execution adapters are accurately identified from the pre-defined adapter library, providing appropriate tool support for subsequent resource migration operations. This ensures the entire disaster recovery resource scheduling process can proceed smoothly and efficiently, improving the success rate and stability of resource migration, and guaranteeing a smooth transition and continuous operation of services across different cloud platforms.

[0094] When configuring the execution adapter based on migration parameters, it is essential to strictly adhere to the preset parameter mapping rules. This ensures that the resource allocation quantities in the migration parameters are accurately converted into resource scheduling instructions recognizable by the execution adapter. For example, parameters such as the number of CPU cores and memory capacity are mapped to the resource allocation interface parameters corresponding to the target cloud platform. Simultaneously, network bandwidth requirements are converted into network configuration instructions to ensure that the data transmission channel meets the real-time requirements of the business migration. When generating the migration instruction set, differentiated instruction templates must be constructed based on the migration type: for virtual machine incremental snapshot migration, the instruction set must include key operation instructions such as snapshot creation, state freezing, data transmission, and state recovery; for containerized service cross-cloud orchestration deployment, the instruction set must cover deployment process instructions such as container image pulling, service dependency resolution, network configuration synchronization, and load balancing adjustment.

[0095] During the resource migration operation phase, the migration engine first initiates a pre-check mechanism on the target cloud node to verify whether its remaining resources meet the migration parameter requirements. If resources are insufficient, a dynamic scaling process is triggered or the target node is reselected. After the pre-check passes, the migration engine executes each operation instruction sequentially according to the timing requirements of the migration instruction set and the migration type. For virtual machine incremental snapshot migration, a virtual machine snapshot is first created to freeze its current state and prevent data changes during the migration process. Then, the snapshot data is accurately transmitted to the target cloud node. Finally, the virtual machine state is restored on the target cloud node to restore it to the same running state as the original virtual machine. For containerized service cross-cloud orchestration deployment, the required container images are first pulled from the image repository. Then, the dependencies between services are resolved to ensure that the container service can be correctly associated and run in the new environment. At the same time, the network configuration is synchronized to ensure normal communication of the container service in the new network environment. Finally, the load balancing strategy is adjusted according to business needs so that the container service can reasonably allocate business traffic.

[0096] Throughout the entire resource migration process, the migration engine monitors the migration progress and status in real time. If any abnormalities occur, such as data transmission interruption or container startup failure, it will promptly perform error handling and recovery operations to ensure that the resource migration operation can be completed smoothly. Ultimately, it achieves the goal of virtual machine incremental snapshot migration or cross-cloud orchestration deployment of containerized services, realizes disaster recovery resource scheduling based on heterogeneous cloud environments, and ensures the continuity and stability of business.

[0097] In one feasible implementation, the step of performing resource migration operations based on the migration instruction set and the migration type to complete the virtual machine incremental snapshot migration or cross-cloud orchestration deployment of containerized services includes: when the migration type is virtual machine incremental snapshot migration, controlling the source cloud platform to generate virtual machine incremental snapshots through the migration instruction set; transmitting the virtual machine incremental snapshots to the target cloud platform through an adapted execution adapter, and merging the virtual machine incremental snapshots with the base image on the target cloud platform to complete the virtual machine incremental snapshot migration; when the migration type is cross-cloud orchestration deployment of containerized services, controlling the source cloud platform to export container images and orchestration template files through the migration instruction set; uploading the container images to the image repository of the target cloud platform, and completing the deployment and configuration of containerized services on the target cloud node according to the orchestration template files.

[0098] It's important to note that when the migration type is virtual machine incremental snapshot migration, the migration instruction set allows for precise control over the generation of virtual machine incremental snapshots on the source cloud platform. This snapshot captures the virtual machine's state information at a specific moment, including critical content such as disk data and memory data. Subsequently, the adapted execution adapter acts as a bridge, accurately transferring the generated virtual machine incremental snapshot to the target cloud platform. On the target cloud platform, this snapshot is merged with the pre-prepared base image. This merging process is like integrating new content into an existing framework, ultimately completing the virtual machine incremental snapshot migration. This allows the virtual machine to continue running on the target cloud platform in a state consistent with the original virtual machine.

[0099] When the migration type is cross-cloud orchestration deployment of containerized services, the migration instruction set controls the source cloud platform to export container images and orchestration template files. The container image acts as a blueprint for the container service, containing all the software environment and configuration information required for container operation; the orchestration template file defines key rules such as dependencies between container services, network configuration, and load balancing. Next, the exported container image is uploaded to the target cloud platform's image repository, which acts as a container image repository, providing a convenient way to obtain images for subsequent deployments. Finally, based on the orchestration template file, the containerized service is deployed and configured on the target cloud nodes, ensuring that the container service can run orderly according to preset rules in the new cloud environment, achieving cross-cloud orchestration deployment of containerized services.

[0100] In this embodiment, the migration strategy is verified in advance and executed seamlessly across cloud platforms through digital twin simulation verification and execution adapter mechanism. This enables safe and reliable cross-cloud disaster recovery switching and improves the success rate and automation of disaster recovery scheduling.

[0101] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the disaster recovery resource scheduling method based on heterogeneous cloud environment. Any simple modifications based on this technical concept are within the protection scope of this application.

[0102] This application also provides a disaster recovery resource scheduling device based on a heterogeneous cloud environment. Please refer to [reference needed]. Figure 2 The disaster recovery resource scheduling device based on heterogeneous cloud environment includes: The construction module 10 is used to construct a multi-dimensional resource profile model and a cross-cloud network topology map in a heterogeneous cloud environment, and generate a standardized resource vector set and a topology affinity scoring matrix based on the multi-dimensional resource profile model and the cross-cloud network topology map, wherein each element in the topology affinity scoring matrix represents the quality of the migration path from the source cloud region to the target cloud region.

[0103] The aggregation module 20 is used to aggregate the local SLA default risk prediction models of each cloud node in the heterogeneous cloud environment through federated learning, and to fine-tune the aggregated SLA default risk prediction models through transfer learning to obtain a global SLA default risk prediction model.

[0104] Prediction module 30 is used to calculate load fluctuation entropy based on the SLA constraint template of the business system and real-time load status data, and input the load fluctuation entropy and the standardized resource vector set into the global SLA default risk prediction model for prediction, so as to obtain the future SLA default probability set of each cloud node. The construction module 10 is further configured to construct a dynamic weighted multi-objective optimization function based on the SLA constraint template, the load fluctuation entropy, the SLA default probability set, the topology affinity scoring matrix, and the standardized resource vector set, and obtain the optimal takeover cloud node list and the corresponding migration strategy identifier set by solving the dynamic weighted multi-objective optimization function.

[0105] The verification module 40 is used to perform SLA simulation verification based on the optimal takeover cloud node list and the migration policy identifier set to obtain the target cloud node and the corresponding migration policy identifier, and to call the execution adapter adapted to the target cloud platform based on the target cloud node and the corresponding migration policy identifier to complete the cross-cloud orchestration deployment of virtual machine incremental snapshot migration or containerized services.

[0106] The disaster recovery resource scheduling device based on a heterogeneous cloud environment provided in this application adopts the disaster recovery resource scheduling method based on a heterogeneous cloud environment in the above embodiments, which can solve the technical problems of uneven distribution of disaster recovery resources and high response latency in hybrid cloud and multi-cloud environments in the prior art. Compared with the prior art, the beneficial effects of the disaster recovery resource scheduling device based on a heterogeneous cloud environment provided in this application are the same as the beneficial effects of the disaster recovery resource scheduling method based on a heterogeneous cloud environment provided in the above embodiments, and other technical features in the disaster recovery resource scheduling device based on a heterogeneous cloud environment are the same as the features disclosed in the methods of the above embodiments, and will not be repeated here.

[0107] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A disaster recovery resource scheduling method based on a heterogeneous cloud environment, characterized in that, The method includes: A multi-dimensional resource profile model and a cross-cloud network topology map are constructed in a heterogeneous cloud environment. Based on the multi-dimensional resource profile model and the cross-cloud network topology map, a standardized resource vector set and a topology affinity scoring matrix are generated. Each element in the topology affinity scoring matrix represents the quality of the migration path from the source cloud region to the target cloud region. The local SLA default risk prediction models of each cloud node in the heterogeneous cloud environment are aggregated by federated learning, and the aggregated SLA default risk prediction models are fine-tuned by transfer learning to obtain a global SLA default risk prediction model. The load fluctuation entropy is calculated based on the SLA constraint template of the business system and the real-time load status data. The load fluctuation entropy and the standardized resource vector set are then input into the global SLA default risk prediction model for prediction, so as to obtain the future SLA default probability set of each cloud node. A dynamic weighted multi-objective optimization function is constructed based on the SLA constraint template, the load fluctuation entropy, the SLA default probability set, the topology affinity scoring matrix, and the standardized resource vector set. By solving the dynamic weighted multi-objective optimization function, the optimal takeover cloud node list and the corresponding migration strategy identifier set are obtained. Based on the optimal takeover cloud node list and the migration policy identifier set, SLA simulation verification is performed to obtain the target cloud node and the corresponding migration policy identifier. Then, based on the target cloud node and the corresponding migration policy identifier, the execution adapter adapted to the target cloud platform is called to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services.

2. The method as described in claim 1, characterized in that, The process of constructing a multi-dimensional resource profiling model and a cross-cloud network topology map in a heterogeneous cloud environment, and generating a standardized resource vector set and a topology affinity scoring matrix based on the multi-dimensional resource profiling model and the cross-cloud network topology map, includes: Static configuration data and dynamic performance data of resource instances are collected from multiple heterogeneous cloud platforms in a heterogeneous cloud environment, and a list of network entities is obtained. Extract logical relationship data between resources from the cloud platform configuration management database. The logical relationship data includes at least the load balancing backend service relationship, the database master-slave replication relationship, and the application and dependent middleware service relationship. The collected static configuration data, dynamic performance data, and logical relationship data are aggregated according to the identifier of the resource instance to generate a corresponding multi-dimensional resource profile model for each resource instance. Using network entities and resource instances in the network entity list as nodes, and the logical connection relationships between entities and physical connection paths, and the communication relationships between resource instances as edges, a directed weighted cross-cloud network topology graph is constructed. The weights of the edges in the cross-cloud network topology graph are assigned based on network latency, bandwidth, or hop count. The heterogeneous features in the multidimensional resource profiling model are normalized and embedded, and all resource instances are mapped to a unified vector space to generate a standardized resource vector set. Based on the edge weights in the cross-cloud network topology graph, calculate the network affinity between any two resource instance nodes; The topological affinity score matrix is ​​obtained by calculating the network affinity and the cosine similarity of the vectors in the standardized resource vector set.

3. The method as described in claim 1, characterized in that, The process involves aggregating local SLA default risk prediction models from each cloud node in the heterogeneous cloud environment through federated learning, and then fine-tuning the aggregated SLA default risk prediction models through transfer learning to obtain a global SLA default risk prediction model, including: In each cloud node of the heterogeneous cloud environment, the corresponding local SLA default risk prediction model is trained in parallel using local private historical load data and SLA status labels, and the corresponding local model parameters are obtained. The local model parameters are noise-added using differential privacy technology and then homomorphically encrypted to obtain the encrypted local model parameters. The encrypted local model parameters are uploaded to the federated learning aggregation server, so that the federated learning aggregation server uses the federated averaging algorithm to aggregate the encrypted local model parameters and generate aggregated global model parameters. The aggregated global model parameters are distributed to each cloud node, and the aggregated global model parameters are fine-tuned on each cloud node based on the newly generated local labeled data using few-shot learning technology to obtain the teacher model for each cloud node. A distillation dataset is constructed based on the unlabeled data of each node, and the distillation dataset is predicted by each of the teacher models to generate a corresponding soft-label dataset. A lightweight student model was trained using the soft-labeled dataset through knowledge distillation, and the student model was used as a global SLA default risk prediction model.

4. The method as described in claim 1, characterized in that, The load fluctuation entropy is calculated based on the SLA constraint template of the business system and real-time load status data. This load fluctuation entropy and the standardized resource vector set are then input into the global SLA default risk prediction model for prediction, resulting in a future SLA default probability set for each cloud node, including: Extract key performance indicators and corresponding constraint thresholds from the SLA constraint template of the business system; Obtain real-time load status data corresponding to the key performance indicators, and determine the relative load rate based on the real-time load status data and the corresponding constraint thresholds; Based on the relative load rate, the load fluctuation entropy is calculated using the information entropy theory. The load fluctuation entropy and the standardized resource vectors in the standardized resource vector set are concatenated to generate a composite feature vector; The composite feature vector is input into the global SLA default risk prediction model to perform multi-step forward prediction based on time series analysis, and the default probability at multiple future time points is output. The default probabilities at multiple future time points are aggregated according to their respective cloud nodes to obtain the future SLA default probability set for each cloud node.

5. The method as described in claim 1, characterized in that, The process involves constructing a dynamic weighted multi-objective optimization function based on the SLA constraint template, the load fluctuation entropy, the SLA default probability set, the topology affinity scoring matrix, and the standardized resource vector set. Solving this dynamic weighted multi-objective optimization function yields the optimal takeover cloud node list and the corresponding migration strategy identifier set, including: The default risk sub-objective is determined based on the SLA default probability set, the resource balance sub-objective is determined based on the load fluctuation entropy, and the migration cost sub-objective is determined based on the topology affinity scoring matrix. The weight coefficients of each optimization sub-objective are determined based on the load fluctuation entropy. Based on the aforementioned default risk sub-objective, resource balance sub-objective, migration cost sub-objective, and weight coefficients, a dynamic weighted multi-objective optimization function containing multiple optimization sub-objectives is constructed. The constraint thresholds corresponding to the key performance indicators in the SLA constraint template are used as hard constraints for the optimization problem, and the hard constraints are injected into the dynamic weight multi-objective optimization function to obtain the dynamic weight multi-objective optimization function after the constraints are injected. A non-dominated sorting genetic algorithm with an elite retention strategy is used to solve the dynamic weight multi-objective optimization function after the injection constraints, generating a Pareto optimal solution set; From the Pareto optimal solution set, solutions that satisfy the resource capacity limit of the standardized resource vector set are selected to obtain the optimal takeover cloud node list; Based on the migration path of each node in the optimal takeover cloud node list, the corresponding migration strategy identifier is extracted from the topology affinity scoring matrix to generate a migration strategy identifier set.

6. The method as described in claim 5, characterized in that, The non-dominated sorting genetic algorithm with an elite retention strategy solves the dynamic weighted multi-objective optimization function after the injection constraints, generating a Pareto optimal solution set, including: An initial population of a random preset size is formed, wherein the chromosome of each individual in the initial population adopts a hybrid encoding, with the first part of the chromosome being binary encoding to represent the selection state of candidate nodes, and the second part of the chromosome being real number encoding to represent the resource allocation ratio; Calculate the fitness value of each individual in the initial population, wherein the fitness value is obtained by weighted combination of the function values ​​of each sub-objective in the dynamic weighted multi-objective optimization function after the injection of constraints; The initial population is sorted into multiple non-dominated layers based on fitness values, and crowding distance is calculated for individuals within the same non-dominated layer. Parent individuals are selected from the initial population based on non-dominated sorting and crowding distance using a tournament selection mechanism. Perform simulated binary crossover and polynomial mutation operations on the parent individuals to generate the offspring population; The parent individuals and the offspring population are merged into a new generation population; Determine whether the new generation population meets the preset termination condition. If not, use the new generation population as the initial population and return to the step of calculating the fitness value of each individual in the initial population. If the conditions are met, individuals from the top non-dominated layer of the new generation population are extracted to generate the Pareto optimal solution set.

7. The method as described in claim 1, characterized in that, The process involves performing SLA simulation verification based on the optimal takeover cloud node list and the migration policy identifier set to obtain the target cloud node and its corresponding migration policy identifier. Then, based on the target cloud node and its corresponding migration policy identifier, an execution adapter adapted to the target cloud platform is invoked to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services. This includes: Based on the current multi-dimensional resource profiling model and cross-cloud network topology, a digital twin simulation environment for disaster recovery scheduling is constructed. Obtain the historical service traffic corresponding to the first node in the optimal takeover cloud node list; The historical service traffic is injected into the disaster recovery scheduling digital twin simulation environment for SLA simulation verification, and the simulation verification results are obtained. If the simulation verification result shows that the simulation verification meets the standards, the first node will be determined as the target cloud node; If the simulation verification result is that the simulation verification fails, then select the next node from the optimal takeover cloud node list, return to the step of obtaining the historical service traffic corresponding to the first node in the optimal takeover cloud node list, until the simulation verification meets the standard, and take the determined compliant node as the target cloud node. Extract the migration strategy identifier corresponding to the target cloud node from the migration strategy identifier set; Based on the target cloud node and the corresponding migration policy identifier, the execution adapter adapted to the target cloud platform is matched and called from the preset adapter library to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services.

8. The method as described in claim 7, characterized in that, The step of matching and calling an execution adapter adapted to the target cloud platform from a preset adapter library based on the target cloud node and the corresponding migration policy identifier to complete the cross-cloud orchestration and deployment of virtual machine incremental snapshot migration or containerized services includes: Parse the migration strategy identifier to determine the migration type and migration parameters. The migration type includes virtual machine incremental snapshot migration and containerized service cross-cloud orchestration deployment. The migration parameters include at least resource allocation and network bandwidth requirements. Based on the cloud platform type and migration type of the target cloud node, a suitable execution adapter is selected from a preset adapter library. Based on the migration parameters, the execution adapter is configured to generate a migration instruction set; Based on the migration instruction set and the migration type, perform resource migration operations to complete virtual machine incremental snapshot migration or cross-cloud orchestration deployment of containerized services.

9. The method as described in claim 8, characterized in that, The process of performing resource migration operations based on the migration instruction set and the migration type to complete virtual machine incremental snapshot migration or cross-cloud orchestration deployment of containerized services includes: In the case of virtual machine incremental snapshot migration, the source cloud platform is controlled to generate virtual machine incremental snapshots through the migration instruction set; The virtual machine incremental snapshot is transferred to the target cloud platform through the adapted execution adapter, and the virtual machine incremental snapshot is merged with the base image on the target cloud platform to complete the virtual machine incremental snapshot migration; When the migration type is containerized service cross-cloud orchestration deployment, the migration instruction set controls the source cloud platform to export container images and orchestration template files; The container image is uploaded to the image repository of the target cloud platform, and the containerized service is deployed and configured on the target cloud node according to the orchestration template file.

10. A disaster recovery resource scheduling device based on a heterogeneous cloud environment, characterized in that, The device includes: The module is used to construct a multi-dimensional resource profile model and a cross-cloud network topology map in a heterogeneous cloud environment, and to generate a standardized resource vector set and a topology affinity scoring matrix based on the multi-dimensional resource profile model and the cross-cloud network topology map. Each element in the topology affinity scoring matrix represents the quality of the migration path from the source cloud region to the target cloud region. The aggregation module is used to aggregate the local SLA default risk prediction models of each cloud node in the heterogeneous cloud environment through federated learning, and to fine-tune the aggregated SLA default risk prediction models through transfer learning to obtain a global SLA default risk prediction model. The prediction module is used to calculate the load fluctuation entropy based on the SLA constraint template of the business system and the real-time load status data, and input the load fluctuation entropy and the standardized resource vector set into the global SLA default risk prediction model for prediction, so as to obtain the future SLA default probability set of each cloud node. The construction module is further configured to construct a dynamic weighted multi-objective optimization function based on the SLA constraint template, the load fluctuation entropy, the SLA default probability set, the topology affinity scoring matrix, and the standardized resource vector set. By solving the dynamic weighted multi-objective optimization function, the optimal takeover cloud node list and the corresponding migration strategy identifier set are obtained. The verification module is used to perform SLA simulation verification based on the optimal takeover cloud node list and the migration policy identifier set to obtain the target cloud node and the corresponding migration policy identifier, and to call the execution adapter adapted to the target cloud platform based on the target cloud node and the corresponding migration policy identifier to complete the cross-cloud orchestration deployment of virtual machine incremental snapshot migration or containerized services.

Images