A cross-domain resource unified arrangement and dynamic migration method in a hybrid cloud environment

Abstract

The application discloses a kind of mixed cloud environment cross-domain resource unified arrangement and dynamic migration method, belong to cloud computing resource scheduling and mixed cloud management technical field;Including:1, establish unified cross-domain resource pool;2, build directed acyclic graph, and calculate migration priority;3, build multi-objective arrangement optimization function, and obtain optimal resource deployment topological structure by solving;4, generate candidate migration scheme set;5, filter out optimal executable migration scheme;6, according to optimal executable migration scheme and the result of 2, execute migration operation;7, multidimensional check is carried out to migration result, and the judgment is carried out to check result;The application adopts the above method, can realize heterogeneous resource unified modeling, intelligent dynamic arrangement, migration cost quantization pre-evaluation and high reliable fine-grained migration, realizes the standardization of mixed cloud resource, intelligent, low cost, high reliable scheduling migration.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing resource scheduling and hybrid cloud management technology, and in particular relates to a method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment. Background Technology

[0002] As enterprises continue to deepen their digital transformation, a single public or private cloud architecture can no longer simultaneously meet the needs of business operation security, resource elasticity, and operating costs. Hybrid cloud architecture has become the mainstream deployment form for enterprise IT infrastructure. By integrating the data security and controllability advantages of private cloud with the elastic scalability advantages of public cloud, hybrid cloud can effectively adapt to the differentiated business scenarios of enterprises.

[0003] However, existing hybrid cloud resource management and cross-domain migration technologies have many core shortcomings, including strong heterogeneity of resource models, static and fixed orchestration strategies, lack of quantitative prediction in migration decisions, coarse migration granularity, and low reliability. The resource models are highly heterogeneous: the resource abstraction rules, API interfaces, and metering standards of different cloud platforms vary greatly, and there is a lack of a unified resource orchestration paradigm. Cross-cloud resource scheduling requires the development of specific adaptation programs, resulting in high system maintenance costs and poor universality. Static fixed orchestration strategy: Traditional cloud resource orchestration tools mostly adopt a static template deployment mode. After deployment, they cannot dynamically adjust the resource topology according to real-time load, business SLA, energy consumption and cost changes. This easily leads to the problem of insufficient resources during peak business periods and idle and wasted resources during off-peak periods. Migration decisions lack quantitative prediction: Existing migration technologies only trigger migration based on resource load and business performance, without quantitatively assessing the multi-dimensional costs such as data transmission costs, business interruption losses, computing power and bandwidth overhead, and migration failure risks. This often results in invalid migration actions where the migration costs exceed the migration benefits, causing economic losses and redundant resource consumption for enterprises. Coarse-grained migration and low reliability: Traditional cross-cloud migration often uses virtual machines as the smallest migration unit, without considering the dependencies of application components. The migration process is prone to business interruption and data inconsistency. At the same time, it lacks a full-process status verification and automatic rollback mechanism, making recovery difficult and time-consuming after migration failure. Summary of the Invention

[0004] The purpose of this invention is to provide a method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment. This method can realize unified modeling of heterogeneous resources, intelligent dynamic orchestration, quantitative pre-evaluation of migration costs, and high-reliability fine-grained migration, thereby achieving standardized, intelligent, low-cost, and highly reliable scheduling and migration of hybrid cloud resources.

[0005] To achieve the above objectives, this invention provides a method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment, comprising the following steps: S1. Map cross-domain resources to standardized resource objects and establish a unified cross-domain resource pool; S2. Perform topology analysis on the business applications to be deployed and migrated, construct a directed acyclic graph, and calculate the migration priority; S3. Construct a multi-objective orchestration optimization function, and use an improved genetic algorithm to solve for the optimal resource deployment topology based on cross-domain resource pools and migration priorities; S4. Based on the optimal resource deployment topology, monitor the actual operation and deployment status of each business component in the current hybrid cloud in real time, and generate a set of candidate migration solutions. S5. Calculate the overall migration cost and long-term benefits of each set of candidate migration schemes, calculate the net migration benefit, and select the optimal executable migration scheme. S6. Execute the migration operation based on the optimal executable migration plan and the results of S2; S7. Perform multi-dimensional verification on the migration results and make a judgment on the verification results.

[0006] Preferably, the process of S1 is as follows: S11. Build a unified resource description model covering the three core cloud resources of computing, storage, and network, and define a unified resource specification standard; S12. Map the heterogeneous resources of the cloud platform into standardized resource objects. Each standardized resource object includes six core fields: unique resource identifier, cloud domain, resource specification parameters, real-time status label, cost measurement attribute, and SLA capability label. S13. Construct a cloud adapter layer, configure multiple cloud platform adaptation plugins, and realize bidirectional parsing, data conversion and mapping between the native APIs of various cloud platforms and the unified resource description model; S14. Collect and organize resource data from various cloud domains through the cloud adapter layer to form a globally unified cross-domain resource pool.

[0007] Preferably, the process of S2 is as follows: S21. Collect all application components within the business to be deployed and migrated, and capture the call chain, data flow and network interaction logs between components to obtain the call frequency per unit time and the amount of data transmitted in a single interaction between each pair of components. S22. Using each independent business component as a node in the graph, the product of the call frequency and the amount of data transmitted in a single transaction between two nodes is used as the weighted result to obtain the weight of the edge connecting the two nodes, and a loop-free dependent directed acyclic graph is generated. S23. Set an affinity threshold. If the weight of the two nodes is greater than the affinity threshold, then the two nodes are determined to belong to a high affinity component group. All high affinity component groups are used to form a component affinity grouping list. S24. Based on the sum of the out-degree, in-degree, and edge weights of the nodes, calculate the importance score of each component, sort them from largest to smallest according to the importance score, and obtain the migration priority order.

[0008] Preferably, the process of S3 is as follows: S31. Construct a multi-objective orchestration optimization function with the optimization objectives of maximizing SLA satisfaction, minimizing resource costs, and maximizing energy efficiency. The process is as follows: ; in Indicates the degree of business SLA satisfaction. This represents the total cost of deploying and operating the business. Indicates resource energy consumption efficiency. , and These are the corresponding business weight coefficients, and their sum is 1; S32. Set the optimization constraints for the multi-objective orchestration optimization function; S33. Using integer encoding, each gene position on the chromosome corresponds to a business component, and the gene value is the cloud domain number of the target deployment. N initial deployment schemes that meet the constraints are randomly generated to form an initial population, and basic hyperparameters are set, including population size, maximum number of iterations, initial crossover probability, and initial mutation probability. S34. Substitute the chromosome into the optimization function. Calculate the fitness value corresponding to the chromosome; S35. Perform selection-crossover-mutation operations based on fitness values, as follows: Selection strategy: A hybrid strategy of elite retention and roulette wheel selection is adopted; the top 5% of individuals with the highest fitness in the population are directly retained as elite individuals and enter the next generation, while the remaining individuals are selected through roulette wheel selection. Adaptive crossover strategy: The crossover probability dynamically decreases as the population iterates; a high crossover probability is used in the early stage of iteration to speed up the global search; the crossover probability is reduced in the later stage of iteration to protect high-quality solutions that have converged; the crossover operation only swaps gene positions of non-affinity-bound components and prohibits splitting high-affinity component groups; Adaptive mutation strategy: The mutation probability is adaptively adjusted according to the fitness level; individuals with low fitness have a higher mutation probability; individuals with high fitness have a lower mutation probability; a new cloud domain number is generated during mutation, and it is verified whether the new scheme meets all constraints. S36. Iterate through S35 until any of the following conditions are met, then stop iterating and obtain the final population: (1) The algorithm has reached the preset maximum number of iterations; (2) If the change in the optimal fitness value of the population is less than the preset minimum threshold for M consecutive generations, the population tends to be stable; S37. Select the deployment scheme with the highest fitness from the final population as the global optimal resource deployment topology.

[0009] Preferably, the optimization constraints mentioned in S32 are as follows: Resource capacity constraint: Remaining resources in the target cloud domain ≥ Resources required by the components to be deployed; Network latency constraint: Cross-cloud latency between high-affinity components ≤ preset latency threshold; Data compliance constraints: Sensitive business components must not be deployed on the public cloud.

[0010] Preferably, the process of S4 is as follows: S41. Periodically collect real-time operational data from the cross-domain resource pool, and combine it with component affinity grouping information to check whether strongly coupled components have been split and deployed. Real-time operational data includes the current cloud domain location of each business component; the remaining resources of CPU, memory and bandwidth in each cloud domain; and the current business latency, load and operating cost. S42. Compare the current actual deployment location of each component with the global optimal resource deployment topology obtained in S3, and calculate the deployment deviation index. The deployment deviation index includes resource load deviation, cross-affinity component latency deviation, and operating cost deviation. S43. If any one of the migration initiation conditions is met, the migration process is triggered; otherwise, continuous loop monitoring is performed, and the migration process is not initiated. The migration initiation conditions are as follows: (1) High-affinity business components are deployed to different cloud domains, and the cross-cloud interaction latency exceeds the preset latency threshold; (2) The resource load of any cloud domain exceeds the upper limit threshold, resulting in a resource bottleneck; (3) The difference between the current scheme's multi-objective orchestration optimization function value and the optimal topology fitness is greater than the deviation threshold; (4) Significant fluctuations in business traffic have rendered the original deployment plan unsuitable for the current business load; S44. After triggering the migration process, a migration candidate set is generated based on the component affinity grouping constraint.

[0011] Preferably, the process of S44 is as follows: S441. Using groups as the smallest migration unit, high-affinity component groups are migrated as a whole without being split. S442. Traverse the available target cloud domains and verify whether the remaining resource capacity of the target cloud domain can accommodate the component group to be migrated. S443. Generate a candidate migration scheme by combining each legal component group to be migrated with the target cloud domain, resulting in several distinct candidate migration schemes that meet resource constraints and business affinity constraints.

[0012] Preferably, the process of S5 is as follows: S51. Extract the list of components to be migrated, source cloud domain, target cloud domain, estimated migration data volume, and estimated migration time for the candidate migration scheme; S52. Calculate independent cost metrics, including cross-cloud data transfer costs. Business interruption losses Additional CPU and memory overhead costs during the migration process The bandwidth squeeze cost caused by migrating traffic and occupying service bandwidth and the risks and costs of migration failure, rollback, and business anomalies. ; S53. Calculate the overall migration cost The process is as follows: ; in , , , ,and These are the corresponding cost weight parameters, and their sum is 1; S54. Calculate the sum of the operating cost savings, latency gains, and SLA improvement gains per unit period for the candidate migration scheme to obtain the long-term migration benefits. ; S55. Calculate the net migration benefit. The process is as follows: ; S56. The process of screening and determining candidate migration schemes is as follows: S561, Removal Candidate migration schemes; S562. If all candidate migration solutions are eliminated, it is considered that there is no effective solution, the migration action is abandoned, the migration process ends, and the process returns to S4 for continuous monitoring. S563. If there is at least one candidate migration plan with a net migration benefit greater than 0, then these candidate migration plans shall be sorted from high to low according to the net migration benefit. When the net benefits of multiple plans are close, the plan with the lowest overall migration cost, the lowest migration risk and the shortest migration time shall be selected as the final migration plan. S564. The optimal migration scheme is obtained through the above steps.

[0013] Preferably, the process of S6 is as follows: S61. Read the optimal migration scheme parameters, including the list of affinity component groups to be migrated, the source cloud domain, and the target cloud domain; S62. For stateless components, including gateways and microservice servers, parallel hot migration is adopted; first start in the target cloud domain, then gradually switch traffic after it is ready, and finally shut down the source cloud domain. For stateful components, including databases and caches, a three-stage migration approach of incremental synchronization, switching, and verification is adopted: The first step is to copy all historical data from the source cloud domain to the target cloud domain. The second step is to enable the incremental synchronization channel to continuously synchronize newly generated data during the migration process. The third step is to briefly freeze write traffic, complete the final incremental data synchronization, and switch the business access entry to the target cloud domain. S63. During the entire migration process, collect data synchronization progress, network bandwidth usage, and service latency indicators. If any abnormal signals are detected, immediately trigger an early warning and input the abnormal information into S7. S64. After the migration is complete, output the temporary deployment status data after the migration and input the temporary deployment status data into S7.

[0014] Preferably, the process of S7 is as follows: S71. Perform multi-dimensional consistency verification on temporary deployment status data, as follows: Data consistency verification involves comparing the data hash values ​​of stateful components in the source and target cloud domains to determine whether the data is complete and consistent before and after the migration. Business topology consistency verification: After the migration is completed, check whether the affinity component group is still deployed in the same cloud domain and whether the component deployment location matches the optimal migration plan; Runtime status verification checks whether the business response latency, resource load, and SLA metrics are within the normal threshold range after migration. S72. If all verifications pass the migration judgment, the corresponding old component instance and resources on the source cloud domain are released, the process ends, and the process returns to the S4 operation monitoring stage to enter the next round of dynamic monitoring cycle. If any check in S71 fails, the migration is deemed abnormal, and the S73 rollback process is immediately initiated. S73. Collect exception information and migration exceptions from S63, and perform a fault rollback operation. The process is as follows: S731, immediately switch business traffic back to the original components in the source cloud domain; S732. Shut down the newly created migration instance on the target cloud domain to release the resources occupied by the target cloud domain; S733. Record the migration failure log and mark the migration plan as an unavailable plan. This migration path will not be selected when generating candidate plans in the future. S734, return to the operation monitoring stage of S4, and enter the next round of dynamic monitoring cycle.

[0015] Therefore, the present invention employs the above-mentioned method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment, which has the following advantages: 1. It achieves unified management and control of heterogeneous resources. Through the URDM unified resource model and cloud adapter layer, it shields the resource differences of multiple cloud platforms. When adding a new cloud platform, only the corresponding plugin needs to be adapted. There is no need to reconstruct the orchestration logic, which greatly reduces the cost of hybrid cloud operation and maintenance adaptation. 2. Intelligent and dynamic resource orchestration: Based on multi-objective optimization algorithms, the resource topology is dynamically adjusted, taking into account business availability, cost and energy consumption. Compared with traditional static orchestration, it improves resource utilization and reduces overall operating costs. 3. A new migration cost quantification and prediction mechanism has been added, which for the first time realizes the quantitative calculation of migration costs and the screening of net benefits across all dimensions, completely eliminating the economic losses and resource waste caused by blind migration, and greatly improving the scientificity and rationality of migration decisions; 4. Fine-grained migration reduces business impact. Based on the component dependency graph, affinity grouping migration is implemented. Combined with stateless and stateful differentiated migration strategies, the business interruption time is controlled at the second level, ensuring the continuous and stable operation of the business. 5. High reliability throughout the entire process, with multi-checkpoint consistency verification and automatic rollback mechanism, effectively avoids problems such as inconsistent migration data and business anomalies, greatly improving the migration success rate and significantly enhancing the stability of hybrid cloud cross-domain migration.

[0016] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0017] Figure 1 This is an overall flowchart of a method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to the present invention; Figure 2 This is a flowchart illustrating the optimal resource deployment topology in a method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to the present invention. Figure 3 This is a flowchart illustrating the generation of a candidate migration scheme set in a method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to the present invention. Figure 4 This is a flowchart illustrating the selection of the optimal executable migration scheme in the method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Specific model specifications need to be selected and determined according to the actual specifications of the device, etc. The specific selection calculation method adopts existing technology in the art, and therefore will not be described in detail.

[0019] Example 1; like Figures 1-4 As shown, this invention provides a method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment, including the following steps: S1. Map cross-domain resources to standardized resource objects and establish a unified cross-domain resource pool; S11. Build a unified resource description model (URDM) covering the three core cloud resources of computing, storage, and network, and define a unified resource specification standard; S12. Map heterogeneous resource instances from various cloud platforms into standardized resource objects. Each standardized resource object includes six core fields: unique resource identifier, cloud domain, resource specification parameters, real-time status label, cost measurement attribute, and SLA capability label. S13. Construct a cloud adapter layer, configure multiple cloud platform adaptation plugins, and realize bidirectional parsing, data conversion and mapping between the native APIs of various cloud platforms and the unified resource description model; S14. Collect and organize resource data from various cloud domains through the cloud adapter layer to form a globally unified cross-domain resource pool, thereby achieving unified management and control of all heterogeneous cloud resources.

[0020] S2. Perform topology analysis on the business applications to be deployed and migrated, construct a directed acyclic graph, and calculate the migration priority; S21. Collect all application components within the business to be deployed and migrated. Components include microservices, middleware, databases, caches, gateways, etc., and capture the call chain, data flow and network interaction logs between components to obtain the call frequency per unit time and the amount of data transmitted in a single interaction between each pair of components. S22. Using each independent business component as a node in the graph, the product of the call frequency and the amount of data transmitted in a single transaction between two nodes is used as the weighted result to obtain the weight of the edge connecting the two nodes, and a loop-free dependent directed acyclic graph is generated. S23. Set an affinity threshold. If the weight of the two nodes is greater than the affinity threshold, they are determined to belong to a high affinity component group. All high affinity component groups are used to form a component affinity grouping list. High affinity components should be deployed and migrated to the same cloud domain first in subsequent orchestration and migration processes to reduce cross-cloud data interaction overhead.

[0021] S24. Based on the sum of the out-degree, in-degree, and edge weights of the nodes, calculate the importance score of each component and sort them from largest to smallest to obtain the migration priority order. The higher the importance score, the more important the component is as a core business component and the higher its migration priority. During migration, the SLA constraints of core components should be guaranteed first, and migration should be carried out with caution.

[0022] The output includes: a list of component affinity groups, migration priority for each component, and a "Do Not Split Deploy" constraint label (e.g., for database components with privacy data).

[0023] S3. Construct a multi-objective orchestration optimization function, and use an improved genetic algorithm to solve for the optimal resource deployment topology based on cross-domain resource pools and migration priorities; S31. Construct a multi-objective orchestration optimization function with the optimization objectives of maximizing SLA satisfaction, minimizing resource costs, and maximizing energy efficiency. The process is as follows: ; in Indicates the degree of business SLA satisfaction. This represents the total cost of deploying and operating the business. Indicates resource energy consumption efficiency. , and These are the corresponding business weight coefficients, and their sum is 1; Rules for dynamic adjustment of business weight coefficients: Peak business hours: Prioritize ensuring the quality of business services; Off-peak business hours: Prioritize controlling operating costs; Business off-peak periods: Prioritize improving energy efficiency.

[0024] S32. Set the optimization constraints for the multi-objective orchestration optimization function; The optimization constraints are as follows: Resource capacity constraint: Remaining resources in the target cloud domain ≥ Resources required by the components to be deployed; Network latency constraint: Cross-cloud latency between high-affinity components ≤ preset latency threshold; Data compliance constraints: Sensitive business components must not be deployed on the public cloud.

[0025] S33. Using integer encoding, each gene position on the chromosome corresponds to a business component, and the gene value is the cloud domain number of the target deployment. N initial deployment schemes that meet the constraints are randomly generated to form an initial population, and basic hyperparameters are set, including population size, maximum number of iterations, initial crossover probability, and initial mutation probability. S34. Substitute the chromosome (deployment plan) into the optimization function. Calculate the fitness value corresponding to the chromosome; S35. Perform selection-crossover-mutation operations based on fitness values, as follows: Selection strategy: A hybrid strategy of elite retention and roulette wheel selection is adopted; the top 5% of individuals with the highest fitness in the population are directly retained as elite individuals and enter the next generation, while the remaining individuals are selected through roulette wheel selection. Adaptive crossover strategy: The crossover probability dynamically decreases as the population iterates; a high crossover probability is used in the early stage of iteration to speed up the global search; the crossover probability is reduced in the later stage of iteration to protect high-quality solutions that have converged; the crossover operation only swaps gene positions of non-affinity-bound components and prohibits splitting high-affinity component groups; Adaptive mutation strategy: The mutation probability is adaptively adjusted according to the fitness level; individuals with low fitness have a higher mutation probability; individuals with high fitness have a lower mutation probability; a new cloud domain number is generated during mutation, and it is verified whether the new scheme meets all constraints. S36. Iterate through S35 until any of the following conditions are met, then stop iterating and obtain the final population: (1) The algorithm has reached the preset maximum number of iterations; (2) If the change in the optimal fitness value of the population is less than the preset minimum threshold for M consecutive generations, the population tends to be stable; S37. Select the deployment scheme with the highest fitness from the final population as the global optimal resource deployment topology.

[0026] S4. Based on the optimal resource deployment topology, monitor the actual operation and deployment status of each business component in the current hybrid cloud in real time, and generate a set of candidate migration solutions. S41. Periodically collect real-time operational data from the cross-domain resource pool, and combine it with component affinity grouping information to check whether strongly coupled components have been split and deployed. Real-time operational data includes the current cloud domain location of each business component; the remaining resources of CPU, memory and bandwidth in each cloud domain; and the current business latency, load and operating cost. S42. Compare the current actual deployment location of each component with the global optimal resource deployment topology obtained in S3, and calculate the deployment deviation index. The deployment deviation index includes resource load deviation, cross-affinity component latency deviation, and operating cost deviation. S43. If any one of the migration initiation conditions is met, the migration process is triggered; otherwise, continuous loop monitoring is performed, and the migration process is not initiated. The migration initiation conditions are as follows: (1) High-affinity business components are deployed to different cloud domains, and the cross-cloud interaction latency exceeds the preset latency threshold; (2) The resource load of any cloud domain exceeds the upper limit threshold, resulting in a resource bottleneck; (3) The difference between the current scheme's multi-objective orchestration optimization function value and the optimal topology fitness is greater than the deviation threshold; (4) Significant fluctuations in business traffic have rendered the original deployment plan unsuitable for the current business load; S44. After triggering the migration process, a migration candidate set is generated based on the component affinity grouping constraint.

[0027] S441. Using groups as the smallest migration unit, high-affinity component groups are migrated as a whole without being split. S442. Traverse the available target cloud domains and verify whether the remaining resource capacity of the target cloud domain can accommodate the component group to be migrated. S443. Generate a candidate migration scheme by combining each legal component group to be migrated with the target cloud domain, resulting in several distinct candidate migration schemes that meet resource constraints and business affinity constraints.

[0028] S5. Calculate the overall migration cost and long-term benefits of each set of candidate migration schemes, calculate the net migration benefit, and select the optimal executable migration scheme. S51. Extract the list of components to be migrated, source cloud domain, target cloud domain, estimated migration data volume, and estimated migration time for the candidate migration scheme; S52. Calculate independent cost metrics, including cross-cloud data transfer costs. Business interruption losses Additional CPU and memory overhead costs during the migration process The bandwidth squeeze cost caused by migrating traffic and occupying service bandwidth and the risks and costs of migration failure, rollback, and business anomalies. ; S53. Calculate the overall migration cost The process is as follows: ; in , , , ,and These are the corresponding cost weight parameters, and their sum is 1; Dynamic configuration strategy: Core high-availability services: Increase the weight of service interruption costs. Reduce transmission cost weight ; Large-volume cold data migration scenarios: Increase the weight of data transmission cost Reduce the weight of interruption cost ; High-risk and critical business operations: Increase the risk cost weighting. ; S54. Calculate the sum of the operating cost savings, latency gains, and SLA improvement gains per unit period for the candidate migration scheme to obtain the long-term migration benefits. ; S55. Calculate the net migration benefit. The process is as follows: ; S56. The process of screening and determining candidate migration schemes is as follows: S561, Removal Candidate migration schemes; S562. If all candidate migration solutions are eliminated, it is considered that there is no effective solution, the migration action is abandoned, the migration process ends, and the process returns to S4 for continuous monitoring. S563. If there is at least one candidate migration plan with a net migration benefit greater than 0, then these candidate migration plans shall be sorted from high to low according to the net migration benefit. When the net benefits of multiple plans are close, the plan with the lowest overall migration cost, the lowest migration risk and the shortest migration time shall be selected as the final migration plan. S564. The optimal migration scheme is obtained through the above steps.

[0029] S6. Execute the migration operation based on the optimal executable migration plan and the results of S2; S61. Read the optimal migration scheme parameters, including the list of affinity component groups to be migrated, the source cloud domain, and the target cloud domain; S62. For stateless components, including gateways and microservice servers, parallel hot migration is adopted; first start in the target cloud domain, then gradually switch traffic after it is ready, and finally shut down the source cloud domain. For stateful components, including databases and caches, a three-stage migration approach of incremental synchronization, switching, and verification is adopted: The first step is to copy all historical data from the source cloud domain to the target cloud domain. The second step is to enable the incremental synchronization channel to continuously synchronize newly generated data during the migration process. The third step is to briefly freeze write traffic, complete the final incremental data synchronization, and switch the business access entry to the target cloud domain. S63. During the entire migration process, collect data synchronization progress, network bandwidth usage, and service latency indicators. If any abnormal signals are detected, immediately trigger an early warning and input the abnormal information into S7. S64. After the migration is complete, output the temporary deployment status data after the migration and input the temporary deployment status data into S7.

[0030] S7. Perform multi-dimensional verification on the migration results and make a judgment on the verification results.

[0031] S71. Perform multi-dimensional consistency verification on temporary deployment status data, as follows: Data consistency verification involves comparing the data hash values ​​of stateful components in the source and target cloud domains to determine whether the data is complete and consistent before and after the migration. Business topology consistency verification: After the migration is completed, check whether the affinity component group is still deployed in the same cloud domain and whether the component deployment location matches the optimal migration plan; Runtime status verification checks whether the business response latency, resource load, and SLA metrics are within the normal threshold range after migration. S72. If all verifications pass the migration judgment, the corresponding old component instance and resources on the source cloud domain are released, the process ends, and the process returns to the S4 operation monitoring stage to enter the next round of dynamic monitoring cycle. If any check in S71 fails, the migration is deemed abnormal, and the S73 rollback process is immediately initiated. S73. Collect exception information and migration exceptions from S63, and perform a fault rollback operation. The process is as follows: S731, immediately switch business traffic back to the original components in the source cloud domain; S732. Shut down the newly created migration instance on the target cloud domain to release the resources occupied by the target cloud domain; S733. Record the migration failure log and mark the migration plan as an unavailable plan. This migration path will not be selected when generating candidate plans in the future. S734, return to the operation monitoring stage of S4, and enter the next round of dynamic monitoring cycle.

[0032] Example 2; This approach is applied to an enterprise's hybrid public-private cloud architecture. The private cloud adopts the OpenStack architecture to support the enterprise's core and sensitive business. The public cloud adopts the Alibaba Cloud elastic architecture to support elastic demand scenarios such as front-end gateways and marketing businesses. The overall business is a microservice architecture, including gateway services, product services, order services, user services, and corresponding database components.

[0033] Step 1: Unified resource modeling; By connecting to the private cloud OpenStack platform and Alibaba Cloud platform through cloud adapters, the computing, storage and network resources of the two cloud platforms are uniformly converted into URDM standardized resource objects, and the core parameters such as the cloud domain, specifications, cost and SLA capabilities of each resource are marked to build a unified cross-domain resource pool.

[0034] Step 2: Apply topology and dependency graph construction; Collect call chains and data transmission data from each microservice component to construct a dependent directed acyclic graph. Identify the order service and order database, and the product service and product database as high-affinity component groups. The user database is marked with a compliance constraint label prohibiting public cloud deployment due to the involvement of privacy data.

[0035] Step 3: Multi-objective orchestration optimization; With peak business time factor α=0.5, β=0.3, and γ=0.2, and SLA assurance as the core priority, the optimal deployment scheme is obtained by iteratively solving the problem using an improved genetic algorithm: core users and order databases are deployed in a private cloud to ensure security, while front-end elastic services are deployed in a public cloud to ensure scalability.

[0036] Step 4: Migration Triggering and Solution Generation; During peak sales periods, the system detected that the utilization rate of public cloud computing resources exceeded 90% for 5 consecutive minutes and the application response latency exceeded the SLA threshold. The system triggered a migration mechanism and generated two candidate solutions: "Migrate product services to private cloud" and "Expand and migrate gateway services".

[0037] Step 5: Pre-assessment and screening of migration costs; The two candidate solutions were evaluated using cost quantification: Solution 1, migrating goods and services, resulted in a small data volume, low transmission cost, and minimal business interruption loss, leading to a positive net benefit; Solution 2, expanding the gateway, incurred significant bandwidth overhead and low long-term benefits, resulting in a negative net benefit. The system automatically eliminated Solution 2, retaining Solution 1 as the final implementation solution.

[0038] Step 6: Incremental migration execution; The product service is a stateful, lightweight component that employs a three-stage incremental migration. A matching resource instance is created in the private cloud to complete full data pre-synchronization; incremental data changes are continuously captured, and once the data difference falls below the 10MB threshold, business traffic is seamlessly switched, ultimately releasing idle public cloud resources. The overall business interruption duration is 2 seconds.

[0039] Step 7: Consistency verification and cleanup; Resource configuration, data verification, and application status were fully verified at four checkpoints. All verification results were satisfactory, the migration process was completed normally, there were no business anomalies or data loss throughout the process, cloud domain resource utilization was balanced after the migration, business SLA was met, and operating costs were significantly reduced.

[0040] Therefore, the present invention employs a method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment, which has the following advantages: 1. It achieves unified management and control of heterogeneous resources. Through the URDM unified resource model and cloud adapter layer, it shields the resource differences of multiple cloud platforms. When adding a new cloud platform, only the corresponding plugin needs to be adapted. There is no need to reconstruct the orchestration logic, which greatly reduces the cost of hybrid cloud operation and maintenance adaptation. 2. Intelligent and dynamic resource orchestration: Based on multi-objective optimization algorithms, the resource topology is dynamically adjusted, taking into account business availability, cost and energy consumption. Compared with traditional static orchestration, it improves resource utilization and reduces overall operating costs. 3. A new migration cost quantification and prediction mechanism has been added, which for the first time realizes the quantitative calculation of migration costs and the screening of net benefits across all dimensions, completely eliminating the economic losses and resource waste caused by blind migration, and greatly improving the scientificity and rationality of migration decisions; 4. Fine-grained migration reduces business impact. Based on the component dependency graph, affinity grouping migration is implemented. Combined with stateless and stateful differentiated migration strategies, the business interruption time is controlled at the second level, ensuring the continuous and stable operation of the business. 5. High reliability throughout the entire process, with multi-checkpoint consistency verification and automatic rollback mechanism, effectively avoids problems such as inconsistent migration data and business anomalies, greatly improving the migration success rate and significantly enhancing the stability of hybrid cloud cross-domain migration.

[0041] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment, characterized in that, Includes the following steps: S1. Map cross-domain resources to standardized resource objects and establish a unified cross-domain resource pool; S2. Perform topology analysis on the business applications to be deployed and migrated, construct a directed acyclic graph, and calculate the migration priority; S3. Construct a multi-objective orchestration optimization function, and use an improved genetic algorithm to solve for the optimal resource deployment topology based on cross-domain resource pools and migration priorities; S4. Based on the optimal resource deployment topology, monitor the actual operation and deployment status of each business component in the current hybrid cloud in real time, and generate a set of candidate migration solutions. S5. Calculate the overall migration cost and long-term benefits of each set of candidate migration schemes, calculate the net migration benefit, and select the optimal executable migration scheme. S6. Execute the migration operation based on the optimal executable migration plan and the results of S2; S7. Perform multi-dimensional verification on the migration results and make a judgment on the verification results.

2. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 1, characterized in that, The process of S1 is as follows: S11. Build a unified resource description model covering the three core cloud resources of computing, storage, and network, and define a unified resource specification standard; S12. Map the heterogeneous resources of the cloud platform into standardized resource objects. Each standardized resource object includes six core fields: unique resource identifier, cloud domain, resource specification parameters, real-time status label, cost measurement attribute, and SLA capability label. S13. Construct a cloud adapter layer, configure multiple cloud platform adaptation plugins, and realize bidirectional parsing, data conversion and mapping between the native APIs of various cloud platforms and the unified resource description model; S14. Collect and organize resource data from various cloud domains through the cloud adapter layer to form a globally unified cross-domain resource pool.

3. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 2, characterized in that, The process of S2 is as follows: S21. Collect all application components within the business to be deployed and migrated, and capture the call chain, data flow and network interaction logs between components to obtain the call frequency per unit time and the amount of data transmitted in a single interaction between each pair of components. S22. Using each independent business component as a node in the graph, the product of the call frequency and the amount of data transmitted in a single transaction between two nodes is used as the weighted result to obtain the weight of the edge connecting the two nodes, and a loop-free dependent directed acyclic graph is generated. S23. Set an affinity threshold. If the weight of the two nodes is greater than the affinity threshold, then the two nodes are determined to belong to a high affinity component group. All high affinity component groups are used to form a component affinity grouping list. S24. Based on the sum of the out-degree, in-degree, and edge weights of the nodes, calculate the importance score of each component, sort them from largest to smallest according to the importance score, and obtain the migration priority order.

4. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 3, characterized in that, The process of S3 is as follows: S31. Construct a multi-objective orchestration optimization function with the optimization objectives of maximizing SLA satisfaction, minimizing resource costs, and maximizing energy efficiency. The process is as follows: ； in Indicates business SLA satisfaction. This represents the total cost of deploying and operating the business. Indicates resource energy consumption efficiency. , and These are the corresponding business weight coefficients, and their sum is 1; S32. Set the optimization constraints for the multi-objective orchestration optimization function; S33. Using integer encoding, each gene position on the chromosome corresponds to a business component, and the gene value is the cloud domain number of the target deployment. N initial deployment schemes that meet the constraints are randomly generated to form an initial population, and basic hyperparameters are set, including population size, maximum number of iterations, initial crossover probability, and initial mutation probability. S34. Substitute the chromosome into the optimization function. Calculate the fitness value corresponding to the chromosome; S35. Perform selection-crossover-mutation operations based on fitness values, as follows: Selection strategy: A hybrid strategy of elite retention and roulette wheel selection is adopted; the top 5% of individuals with the highest fitness in the population are directly retained as elite individuals and enter the next generation, while the remaining individuals are selected through roulette wheel selection. Adaptive crossover strategy: The crossover probability dynamically decreases as the population iterates; a high crossover probability is used in the early stage of iteration to speed up the global search; the crossover probability is reduced in the later stage of iteration to protect high-quality solutions that have converged; the crossover operation only swaps gene positions of non-affinity-bound components and prohibits splitting high-affinity component groups; Adaptive mutation strategy: The mutation probability is adaptively adjusted according to the fitness level; individuals with low fitness have a higher mutation probability; individuals with high fitness have a lower mutation probability; a new cloud domain number is generated during mutation, and it is verified whether the new scheme meets all constraints. S36. Iterate through S35 until any of the following conditions are met, then stop iterating and obtain the final population: (1) The algorithm has reached the preset maximum number of iterations; (2) If the change in the optimal fitness value of the population is less than the preset minimum threshold for M consecutive generations, the population tends to be stable; S37. Select the deployment scheme with the highest fitness from the final population as the global optimal resource deployment topology.

5. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 4, characterized in that, The optimization constraints mentioned in S32 are as follows: Resource capacity constraint: Remaining resources in the target cloud domain ≥ Resources required by the components to be deployed; Network latency constraint: Cross-cloud latency between high-affinity components ≤ preset latency threshold; Data compliance constraints: Sensitive business components must not be deployed on the public cloud.

6. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 5, characterized in that, The process of S4 is as follows: S41. Periodically collect real-time running data from the cross-domain resource pool, and combine it with component affinity grouping information to check whether strongly coupled components have been split and deployed. The real-time running data includes the cloud domain location where each business component is currently deployed. Remaining CPU, memory, and bandwidth resources in each cloud domain; Current business latency, load, and operating costs; S42. Compare the current actual deployment location of each component with the global optimal resource deployment topology obtained in S3, and calculate the deployment deviation index. The deployment deviation index includes resource load deviation, cross-affinity component latency deviation, and operating cost deviation. S43. If any one of the migration initiation conditions is met, the migration process is triggered; otherwise, continuous loop monitoring is performed, and the migration process is not initiated. The migration initiation conditions are as follows: (1) High-affinity business components are deployed to different cloud domains, and the cross-cloud interaction latency exceeds the preset latency threshold; (2) The resource load of any cloud domain exceeds the upper limit threshold, resulting in a resource bottleneck; (3) The difference between the current scheme's multi-objective orchestration optimization function value and the optimal topology fitness is greater than the deviation threshold; (4) Significant fluctuations in business traffic have rendered the original deployment plan unsuitable for the current business load; S44. After triggering the migration process, a migration candidate set is generated based on the component affinity grouping constraint.

7. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 6, characterized in that, The process of S44 is as follows: S441. Using groups as the smallest migration unit, high-affinity component groups are migrated as a whole without being split. S442. Traverse the available target cloud domains and verify whether the remaining resource capacity of the target cloud domain can accommodate the component group to be migrated. S443. Generate a candidate migration scheme by combining each legal component group to be migrated with the target cloud domain, resulting in several distinct candidate migration schemes that meet resource constraints and business affinity constraints.

8. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 7, characterized in that, The process of S5 is as follows: S51. Extract the list of components to be migrated, source cloud domain, target cloud domain, estimated migration data volume, and estimated migration time for the candidate migration scheme; S52. Calculate independent cost metrics, including cross-cloud data transfer costs. Business interruption losses Additional CPU and memory overhead costs during the migration process The bandwidth squeeze cost caused by migrating traffic and occupying service bandwidth and the risks and costs of migration failure, rollback, and business anomalies. ; S53. Calculate the overall migration cost The process is as follows: ； in , , , ,and These are the corresponding cost weight parameters, and their sum is 1; S54. Calculate the sum of the operating cost savings, latency gains, and SLA improvement gains per unit period for the candidate migration scheme to obtain the long-term migration benefits. ; S55. Calculate net migration benefits The process is as follows: ； S56. The process of screening and determining candidate migration schemes is as follows: S561, Removal Candidate migration schemes; S562. If all candidate migration solutions are eliminated, it is considered that there is no effective solution, the migration action is abandoned, the migration process ends, and the process returns to S4 for continuous monitoring. S563. If there is at least one candidate migration plan with a net migration benefit greater than 0, then these candidate migration plans shall be sorted from high to low according to the net migration benefit. When the net benefits of multiple plans are close, the plan with the lowest overall migration cost, the lowest migration risk and the shortest migration time shall be selected as the final migration plan. S564. The optimal migration scheme is obtained through the above steps.

9. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 8, characterized in that, The process of S6 is as follows: S61. Read the optimal migration scheme parameters, including the list of affinity component groups to be migrated, the source cloud domain, and the target cloud domain; S62. For stateless components, including gateways and microservice servers, parallel hot migration is adopted; first start in the target cloud domain, then gradually switch traffic after it is ready, and finally shut down the source cloud domain. For stateful components, including databases and caches, a three-stage migration approach of incremental synchronization, switching, and verification is adopted: The first step is to copy all historical data from the source cloud domain to the target cloud domain. The second step is to enable the incremental synchronization channel to continuously synchronize newly generated data during the migration process. The third step is to briefly freeze write traffic, complete the final incremental data synchronization, and switch the business access entry to the target cloud domain. S63. During the entire migration process, collect data synchronization progress, network bandwidth usage, and service latency indicators. If any abnormal signals are detected, immediately trigger an early warning and input the abnormal information into S7. S64. After the migration is complete, output the temporary deployment status data after the migration and input the temporary deployment status data into S7.

10. The method for unified orchestration and dynamic migration of cross-domain resources in a hybrid cloud environment according to claim 9, characterized in that, The process for S7 is as follows: S71. Perform multi-dimensional consistency verification on temporary deployment status data, as follows: Data consistency verification involves comparing the data hash values ​​of stateful components in the source and target cloud domains to determine whether the data is complete and consistent before and after the migration. Business topology consistency verification: After the migration is completed, check whether the affinity component group is still deployed in the same cloud domain and whether the component deployment location matches the optimal migration plan; Runtime status verification checks whether the business response latency, resource load, and SLA metrics are within the normal threshold range after migration. S72. If all verifications pass the migration judgment, the corresponding old component instance and resources on the source cloud domain are released, the process ends, and the process returns to the S4 operation monitoring stage to enter the next round of dynamic monitoring cycle. If any check in S71 fails, the migration is deemed abnormal, and the S73 rollback process is immediately initiated. S73. Collect exception information and migration exceptions from S63, and perform a fault rollback operation. The process is as follows: S731, immediately switch business traffic back to the original components in the source cloud domain; S732. Shut down the newly created migration instance on the target cloud domain to release the resources occupied by the target cloud domain; S733. Record the migration failure log and mark the migration plan as an unavailable plan. This migration path will not be selected when generating candidate plans in the future. S734, return to the operation monitoring stage of S4, and enter the next round of dynamic monitoring cycle.

Images