Multi-cloud resource dynamic scheduling method and device and storage medium

Abstract

The invention relates to a multi-cloud resource dynamic scheduling method and device and a storage medium, and the method comprises the steps: carrying out the matching calculation of a resource type based on a to-be-executed task type, and confirming a task priority; predicting a task resource demand based on the resource type, the historical task traffic duration data and the real-time service load; according to the instance resource information and the estimated task duration in the resource demand, and the resource supply state and the instance price information of each cloud manufacturer, calculating the initial resource overhead of each instance type of each cloud manufacturer; obtaining correction overhead based on the initial overhead and the task priority regulation factor; then, screening the cloud manufacturer with the lowest correction overhead and the corresponding instance type as an optimal strategy; and finally, creating a temporary node and deploying an instance in a corresponding cloud manufacturer server. Through application of the method and the device, the problem that the requirements of refinement and low cost of business on dynamic resource management are difficult to meet in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a method, apparatus and storage medium for dynamic scheduling of multi-cloud resources. Background Technology

[0002] As businesses continue to expand, multi-cloud environments and containerized deployments are gradually becoming the mainstream architecture supporting business operations due to their resource integration capabilities and flexible deployment advantages. However, methods using fixed configurations to match resource types suffer from insufficient multi-cloud coordination and a disconnect between resource supply and actual demand, making it difficult to meet the business's needs for refined and low-cost dynamic resource management.

[0003] Currently, no effective solution has been proposed to address the issue that related technologies cannot meet the business's needs for refined and low-cost dynamic resource management. Summary of the Invention

[0004] This application provides a method, apparatus, and storage medium for dynamic scheduling of multi-cloud resources, which at least solves the problem in related technologies that it is difficult to meet the business's demand for refined and low-cost dynamic resource management.

[0005] In a first aspect, embodiments of this application provide a method for dynamic scheduling of multi-cloud resources, the method comprising:

[0006] The resource type is matched based on the task type of the task to be executed, and the task priority corresponding to the task type is confirmed.

[0007] Based on the resource type, the obtained historical task traffic duration data, and the obtained real-time business load, the resource requirements corresponding to the task type are predicted; the historical task traffic duration data includes historical task traffic data and historical task runtime data.

[0008] Based on the instance resource information and estimated task duration in the resource requirements, as well as the resource supply status and instance price information of each cloud vendor obtained from the preset federated cluster management module, the initial instance resource cost of each instance type of each cloud vendor is calculated.

[0009] Based on the initial instance resource overhead and the priority adjustment factor corresponding to the task priority, the corrected instance resource overhead of each instance type of each cloud vendor is obtained.

[0010] Among the corrected instance resource costs of each cloud vendor and each instance type, the cloud vendor with the lowest corrected instance resource cost and the corresponding instance type are selected as the optimal strategy.

[0011] Create a temporary node on the cloud vendor server corresponding to the optimal strategy, and deploy an instance of the instance type corresponding to the optimal strategy on the temporary node.

[0012] In some embodiments, obtaining the corrected instance resource cost for each instance type from each cloud vendor based on the initial instance resource cost and the priority adjustment factor corresponding to the task priority includes:

[0013] Obtain network overhead data; the network overhead data includes IP allocation, data transmission, and load balancing overhead data that match the cloud vendor and instance type;

[0014] Based on the product of the initial instance resource overhead and the priority adjustment factor corresponding to the task priority, and then superimposed with the network overhead data, the corrected instance resource overhead for each instance type of each cloud vendor is obtained.

[0015] In some embodiments, the step of creating a temporary node on the cloud vendor server corresponding to the optimal policy and deploying an instance of the instance type corresponding to the optimal policy on the temporary node includes:

[0016] Create a temporary node on the cloud vendor server corresponding to the optimal strategy and assign an IP address to the temporary node; register the IP address with a preset load balancer;

[0017] Deploy an instance of the instance type corresponding to the optimal strategy on the temporary node.

[0018] In some embodiments, after deploying an instance of the instance type corresponding to the optimal strategy on the temporary node, the following steps are included:

[0019] By using a pre-defined network plugin, the traffic of the temporary node is isolated from the traffic of the pre-defined production environment.

[0020] In some embodiments, assigning an IP address to the ephemeral node includes:

[0021] From the pre-requested global IP resource pool, IP addresses are randomly assigned to the temporary nodes according to the obtained user geographical location; wherein, the global IP resource pool is formed by pre-requesting IP segments in the availability zones of multiple cloud vendors.

[0022] In some embodiments, after deploying an instance of the instance type corresponding to the optimal strategy on the temporary node, the method further includes:

[0023] If the temporary node remains idle for more than a preset time, the IP address will be removed from the load balancer.

[0024] Destroy the temporary node and reclaim the corresponding IP address;

[0025] When it is detected that the recycled IP address has been blocked, the recycled IP address will be removed from the global IP resource pool.

[0026] In some embodiments, the instance types include auction instances and on-demand instances.

[0027] In some embodiments, the task types include compute-intensive and I / O-intensive tasks.

[0028] Secondly, embodiments of this application provide a multi-cloud resource dynamic scheduling device, the device comprising:

[0029] The matching module is used to match computing resource types based on the task type of the task to be executed, and to confirm the task priority corresponding to the task type.

[0030] The prediction module is used to predict the resource requirements corresponding to the task type based on the resource type, the historical task traffic duration data obtained, and the real-time business load obtained; the historical task traffic duration data includes historical task traffic data and historical task runtime data.

[0031] The initial cost calculation module is used to calculate the initial instance resource cost of each instance type of each cloud vendor based on the instance resource information and estimated task duration in the resource requirements, as well as the resource supply status and instance price information of each cloud vendor obtained from the preset federated cluster management module.

[0032] The correction overhead calculation module is used to obtain the correction instance resource overhead of each instance type of each cloud vendor based on the initial instance resource overhead and the priority adjustment factor corresponding to the task priority.

[0033] The optimal strategy confirmation module is used to select the cloud vendor and corresponding instance type with the lowest corrected instance resource cost among the corrected instance resource costs of each instance type of each cloud vendor as the optimal strategy.

[0034] The deployment module is used to create a temporary node on the cloud vendor server corresponding to the optimal strategy, and deploy an instance of the instance type corresponding to the optimal strategy on the temporary node.

[0035] Thirdly, embodiments of this application provide a storage medium storing a computer program that, when executed by a processor, implements the multi-cloud resource dynamic scheduling method described in the first aspect above.

[0036] Compared to related technologies, the multi-cloud resource dynamic scheduling method, apparatus, and storage medium provided in this application solve the problem in related technologies of difficulty in meeting the refined and low-cost requirements of business dynamic resource management. This is achieved by matching and calculating resource types based on the task type of the task to be executed, and confirming the task priority corresponding to the task type. Based on the resource type, historical task traffic duration data, and real-time business load, the resource requirements corresponding to the task type are predicted. Historical task traffic duration data includes historical task traffic data and historical task runtime data. Based on instance resource information and estimated task duration in the resource requirements, as well as resource supply status and instance price information of each cloud vendor obtained from a preset federated cluster management module, the initial instance resource cost for each instance type of each cloud vendor is calculated. Based on the initial instance resource cost and the priority adjustment factor corresponding to the task priority, the corrected instance resource cost for each instance type of each cloud vendor is obtained. Among the corrected instance resource costs for each instance type of each cloud vendor, the cloud vendor with the lowest corrected instance resource cost and its corresponding instance type are selected as the optimal strategy. A temporary node is created on the cloud vendor server corresponding to the optimal strategy, and an instance of the instance type corresponding to the optimal strategy is deployed on the temporary node. This solves the problem in related technologies of difficulty in meeting the refined and low-cost requirements of business dynamic resource management.

[0037] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0038] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0039] Figure 1 This is a hardware structure block diagram of a terminal for a multi-cloud resource dynamic scheduling method according to an embodiment of this application;

[0040] Figure 2 This is a flowchart of a multi-cloud resource dynamic scheduling method according to an embodiment of this application;

[0041] Figure 3 This is a schematic diagram of the overall process of the multi-cloud resource dynamic scheduling method according to the embodiments of this application;

[0042] Figure 4 This is a structural block diagram of a multi-cloud resource dynamic scheduling device according to an embodiment of this application. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application. Furthermore, it is understood that although the efforts made in such a development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, modifications to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0044] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0045] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application means two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The terms “first,” “second,” “third,” etc., used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0046] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. Taking running on a terminal as an example, Figure 1 This is a hardware structure block diagram of a terminal for a multi-cloud resource dynamic scheduling method according to an embodiment of this application. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. Optionally, the terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0047] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the multi-cloud resource dynamic scheduling method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0048] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0049] As business scales up, multi-cloud environments and containerized deployments are gradually becoming mainstream. However, based on business development needs, there is currently a demand for many temporary resource nodes and temporary IPs. Existing technologies cannot provide flexible, elastic IPs, and the following issues still exist:

[0050] Static resource allocation: Traditional Kubernetes clusters rely on fixed resource configurations and cannot dynamically adjust the size of Pods or nodes according to task load, resulting in resource waste or performance bottlenecks.

[0051] Insufficient multi-cloud collaboration: Cross-cloud Kubernetes cluster management is complex, lacks a unified elastic scaling strategy and cost optimization mechanism, and makes it difficult to achieve optimal resource allocation.

[0052] Rigid IP management: Manually assigning IPs can easily lead to reuse, increasing the risk of being blocked, and there is a lack of automated recycling mechanisms.

[0053] Temporary nodes are costly: the use of on-demand instances for temporary tasks leads to a surge in costs, and the cost is not optimized by combining them with spot instances.

[0054] Therefore, there is an urgent need for an intelligent management system that combines multi-cloud resource management, task demand assessment, dynamic pricing, and elastic scaling to optimize cloud resource utilization, reduce costs, and improve system response speed and stability.

[0055] This embodiment provides a method for dynamic scheduling of multi-cloud resources. Figure 2 This is a flowchart of a multi-cloud resource dynamic scheduling method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0056] Step S201: Match the computational resource type based on the task type of the task to be executed, and confirm the task priority corresponding to the task type;

[0057] Specifically, in the initial stage of multi-cloud resource dynamic scheduling, the "tasks to be executed" must first undergo attribute identification and association matching: First, based on the business characteristics and computing requirements of the task itself, determine its task type (e.g., computationally intensive tasks such as real-time order processing and big data modeling, or IO-intensive tasks such as user data storage and log reading / writing); then, according to the preset "task type - resource type" mapping rules, match the appropriate computing resource type for the task, such as matching high-CPU instances for computationally intensive tasks and high-IOPS (input / output operations per second) storage and network resources for IO-intensive tasks; at the same time, combined with the task's business requirements for "stability and response timeliness" (e.g., core transaction tasks must be prioritized for execution, while non-urgent back-end data analysis tasks can be scheduled at low cost), confirm the task priority corresponding to the task type (e.g., mark core tasks such as order processing and payment calculation as high priority, and mark non-urgent tasks such as log statistics and report generation as low priority), providing core business attribute basis for subsequent resource demand prediction, cost optimization calculation, and scheduling strategy selection.

[0058] Step S202: Based on the resource type, the obtained historical task traffic duration data, and the obtained real-time business load, predict the resource requirements corresponding to the task type; the historical task traffic duration data includes historical task traffic data and historical task runtime data.

[0059] Specifically, after matching task types with computing resource types and confirming task priorities, the process moves to the resource demand prediction stage. This stage requires combining multi-dimensional data to achieve accurate calculations: Based on the matched computing resource types (such as high-CPU instances, high-IOPS storage resources, etc.), on the one hand, historical task traffic duration data is introduced. This historical task traffic data covers key indicators such as request volume fluctuations and concurrent user changes for similar tasks at different times (such as promotional peaks and daily operation periods). Historical task runtime data records the average execution time, peak execution time, and time differences under different resource configurations for similar tasks in the past. Task resource demand templates can also be generated by combining historical data to improve scheduling efficiency. On the other hand, real-time business load data is simultaneously accessed, including the number of tasks pending in the current task queue, real-time CPU / memory utilization, request response latency, and other dynamic indicators. By integrating the "trend patterns of historical data" and the "current state of real-time data," a resource demand prediction model is constructed. For example, if historical data shows that a certain type of IO-intensive task requires 5 high-IO instances to support an average daily traffic of 100,000 requests, with an average runtime of 30 minutes, while real-time business load shows that the number of pending requests for this type of task has reached 150,000 and is still increasing, the model can predict that it needs to be expanded to 8 instances of the same type to meet the demand. The model then outputs the specific resource requirements (such as the number of instances, CPU / memory / storage capacity, estimated runtime, etc.) required for this task type in the current scenario, providing accurate resource quantification for subsequent cloud computing vendor resource consumption and selection of optimal scheduling strategies. The resource requirement prediction is generated by a preset HPA (Horizontal Pod Autoscaler) and a preset VPA (Vertical Pod Autoscaler). HPA is used to dynamically adjust the number of Pod replicas based on custom metrics (such as task queue length, request latency, CPU / memory utilization), supports task priority weighting, and prioritizes resource allocation for high-priority tasks. VPA is used to dynamically adjust the CPU / memory requests and limits of Pods to avoid resource fragmentation and improve resource utilization.

[0060] Step S203: Based on the instance resource information and estimated task duration in the resource requirements, as well as the resource supply status and instance price information of each cloud vendor obtained from the preset federated cluster management module, calculate the initial instance resource cost of each instance type of each cloud vendor.

[0061] Specifically, after predicting the resource requirements corresponding to the task type, the initial instance resource cost calculation phase begins. This phase requires integrating "resource requirement parameters" and "multi-cloud vendor data" to achieve multi-dimensional calculations. First, the Cluster Autoscaler (CA) uses the instance resource information explicitly stated in the resource requirements (such as the number of instances needed to support the task, the number of CPU cores per instance, memory capacity, storage specifications, and other hardware configuration parameters) as a basis, combined with the estimated task duration before execution (such as a standard 2-hour execution cycle determined based on historical similar task execution patterns, or a peak 3-hour execution duration dynamically estimated based on task complexity). Simultaneously, it combines the core data (resource supply status and instance price information) from various cloud vendors obtained in real-time by the dynamic pricing optimizer through the federated cluster management module. The federated cluster management module enables unified collection and aggregation of cross-cloud vendor resource information, providing a unified API entry point across cloud clusters through Kubernetes Federation or Karmada, supporting seamless task migration and load balancing. It provides a global view of multi-cloud resource pools and monitors the resource supply status of each cloud vendor in real time. The resource supply status includes dynamic information such as instance inventory, resource preemption risk, and network bandwidth availability in different availability zones of each cloud vendor. The instance pricing information includes the unit price of different instance types of each cloud vendor and the discount of spot instances. Finally, based on the core calculation logic of "Σ (cloud vendor instance unit price × estimated task duration)", the initial instance resource cost of each instance type under each cloud vendor (such as Alibaba Cloud's spot instances and Huawei Cloud's on-demand instances) is calculated. Among them, Σ is the sum of the results of "unit price × duration" if the task requires multiple instances (the number of instances is confirmed based on the instance resource information).

[0062] Step S204: Based on the initial instance resource overhead and the priority adjustment factor corresponding to the task priority, obtain the corrected instance resource overhead for each instance type of each cloud vendor;

[0063] Specifically, after calculating the initial instance resource costs for each instance type from various cloud vendors, these costs need to be adjusted based on task priorities to obtain a comprehensive cost assessment that better meets business needs. First, the priority adjustment factor corresponding to the task priority bound to the current task type is retrieved (e.g., a factor of 10.0 for high-priority tasks and 1.0 for low-priority tasks). Then, the initial instance resource costs for each instance type from various cloud vendors are multiplied by this adjustment factor to achieve a weighted adjustment of the basic cost. High-priority tasks amplify costs to avoid low-priced but unstable resources (such as spot instances) to ensure business continuity, while low-priority tasks prioritize high-performance resources to control expenses. Finally, the adjusted instance resource costs for each instance type from various cloud vendors are obtained. This cost reflects both the basic usage cost of the resources and incorporates the weighting of task priorities on resource stability and timeliness, providing a core decision-making basis for selecting the optimal scheduling strategy that balances cost and business priority.

[0064] Step S205: Among the corrected instance resource costs of each cloud vendor and each instance type, select the cloud vendor with the lowest corrected instance resource cost and the corresponding instance type as the optimal strategy.

[0065] Specifically, after calculating the corrected instance resource costs for each instance type from various cloud vendors, the optimal scheduling strategy selection process begins. First, cost data from all candidate instances is integrated to form a list of corrected costs covering major cloud vendors such as Alibaba Cloud and Huawei Cloud, including different types of instances such as spot instances and on-demand instances. Then, using the lowest corrected instance resource cost as the core selection criterion, the cost values ​​for each instance type from each cloud vendor are compared one by one, for example, comparing the final corrected costs of Alibaba Cloud spot instances and Huawei Cloud on-demand instances. Finally, the cloud vendor with the lowest cost value and its corresponding instance type are selected and determined as the optimal scheduling strategy for the current task. This strategy can ensure that the task is executed stably according to priority requirements and achieve precise control over the cost of using multi-cloud resources.

[0066] Step S206: Create a temporary node on the cloud vendor server corresponding to the optimal strategy, and deploy an instance of the instance type corresponding to the optimal strategy on the temporary node.

[0067] Specifically, when the load prediction module detects that the future load exceeds the threshold, it triggers the creation of temporary nodes. In the target cloud vendor's server cluster determined by the optimal strategy, temporary nodes marked "ephemeral:true" are automatically created according to the task resource requirements. High-priority tasks are forcibly assigned to dedicated temporary node groups. After the nodes are ready, Pod instances matching the task requirements are deployed according to the instance type to ensure that the tasks run independently without manual intervention, achieving rapid resource deployment and secure scheduling.

[0068] You can think of HPA (Horizontal Pod Autoscaler) and VPA (Vertical Pod Autoscaler) as the "demand side." They determine the number (determined by HPA) and size (determined by VPA) of Pod instances needed based on the business load. CA (ClusterAutoscaler) is the "supply side." It responds to the Pod demands created by HPA and VPA (manifested as "Pending" Pods) and then invokes the "dynamic pricing optimizer" as the decision-making brain to actually procure and create new nodes (servers) to meet these demands.

[0069] Through steps S201 to S206 above, a three-dimensional collaborative optimization of "business needs-cost-stability" in resource scheduling under a multi-cloud environment is achieved: On the one hand, resource types are accurately matched based on task types, and resource demand is predicted by combining historical data and real-time load to avoid resource mismatch and waste. At the same time, business priorities are integrated into cost calculations through priority adjustment factors to ensure that high-priority tasks receive stable resources first and low-priority tasks minimize costs. On the other hand, multi-cloud resource supply and price information is integrated according to the federated cluster module to select the optimal cloud vendor and instance type and automatically complete the creation of temporary nodes and instance deployment. Ultimately, this achieves improved resource utilization efficiency, reduced operating costs, guaranteed task execution stability, and automated full-process management, effectively solving the problem that related technologies are difficult to meet the business's refined and low-cost requirements for dynamic resource management.

[0070] In some embodiments, obtaining the corrected instance resource cost for each instance type from each cloud vendor based on the initial instance resource cost and the priority adjustment factor corresponding to the task priority includes:

[0071] Obtain network overhead data; the network overhead data includes IP allocation, data transmission, and load balancing overhead data that match the cloud vendor and instance type;

[0072] Based on the product of the initial instance resource overhead and the priority adjustment factor corresponding to the task priority, and then superimposed with the network overhead data, the corrected instance resource overhead for each instance type of each cloud vendor is obtained.

[0073] Specifically, firstly, the system proactively acquires network overhead data adapted to the current scheduling scenario. This data is not a uniform fixed value, but rather dynamic data strongly correlated with cloud vendor characteristics and instance types. It covers core network cost items such as IP management fees incurred when allocating IPs to ephemeral nodes, data transmission traffic fees across regions or nodes during task execution, and load balancing service fees incurred after registering instance IPs with the load balancer. Then, using the initial instance resource overhead as a base, a multiplication operation is performed with the priority adjustment factor corresponding to the task priority to complete the weighted adaptation of "basic cost - business priority" (e.g., high-priority tasks amplify basic costs through a high adjustment factor to avoid low-stability resources, while low-priority tasks retain their low-cost advantage through a low adjustment factor). Finally, the weighted calculation result is superimposed with the previously acquired network overhead data to obtain the corrected instance resource overhead for each instance type from each cloud vendor, taking into account basic resource costs, business priority requirements, and additional network costs. The cost calculation formula is as follows:

[0074] ;

[0075] Wherein, Cost is the final corrected instance resource cost (i.e., the total cost after comprehensively considering the instance's basic cost, business priority, and network cost); Σ is the summation symbol, indicating that all instances or resource items involved in the calculation are summed; InstancePrice (instance unit price): the price of an instance provided by the cloud provider per unit time (e.g., hour / second), including computing resources (CPU, memory), storage (SSD / HDD), GPU, etc.; Duration is the predicted resource usage duration. When a new task (e.g., "order processing") is submitted, the system will query the average "task runtime" of similar tasks in the historical database and use this "task runtime" (e.g., "order processing" takes an average of 3 minutes) as the Duration variable in the cost calculation formula; (InstancePrice × Duration) is the basic resource cost of a single instance within the specified duration; This refers to the initial instance resource overhead; PriorityMultiplier is a task priority adjustment factor (high-priority tasks take a larger value to ensure resource stability; low-priority tasks take a smaller value to prioritize cost reduction). The priority adjustment factor is the core mechanism for achieving automatic balance between "business value" and "financial cost." It is not a fixed value, but a translator that translates business requirements into mathematical weights that the dynamic pricing optimizer can understand. For high-priority tasks (such as "order processing" and "payment calculation"), the system will assign them a very high PriorityMultiplier coefficient. The sole purpose of this high coefficient is to penalize and amplify the risk of "spot instances" in cost calculation. As a result, when the optimizer evaluates "spot instances," although their InstancePrice is low, multiplying it by a very high PriorityMultiplier makes their Cost very expensive. This forces the optimizer to abandon this "high-risk" option and instead choose "on-demand instances" that "ensure stability." For low-priority tasks (such as "recommendation algorithms" or "non-urgent tasks"), the system assigns a very low PriorityMultiplier coefficient (e.g., close to 1.0). The aim is to restore cost calculation to its "true nature," that is, to consider only financial costs. The resulting Cost is primarily determined by InstancePrice. Therefore, the optimizer will "prioritize the use of spot instances to reduce costs." In short, this coefficient automatically executes a "high priority for stability, low priority for cost saving" strategy by amplifying or reducing the expected cost of unstable resources (spot instances); Σ(InstancePrice×Duration)×PriorityMultiplier is a business priority weighting of basic resource overhead, reflecting "the impact of business importance on cost decisions"; NetworkCost is the network overhead (including network-related additional costs such as IP allocation, data transmission, and load balancing).

[0076] Through the above steps, the calculation of multi-cloud resource overhead is made more accurate and adapted to different scenarios. On the one hand, by acquiring network overhead data such as IP allocation, data transmission, and load balancing that are bound to cloud vendors and instance types, the gap of traditional calculation of only the basic cost of instances is filled, ensuring that the corrected overhead covers the entire link cost of the task and avoiding cost estimation deviations caused by hidden costs. On the other hand, the initial instance resource overhead is first weighted with a priority adjustment factor, and the business priority (such as high-priority tasks requiring stability and low-priority tasks requiring low cost) is converted into quantifiable cost weights. Then, network overhead is added, and the final corrected overhead reflects both the impact of business needs on costs and the full cost in actual scheduling. This provides an accurate decision-making basis for subsequent selection of cloud vendors and instance types with the best costs and that match business priorities, avoiding the problem of simply pursuing low prices while ignoring business adaptability or hidden costs.

[0077] In some embodiments, the step of creating a temporary node on the cloud vendor server corresponding to the optimal policy and deploying an instance of the instance type corresponding to the optimal policy on the temporary node includes:

[0078] Create a temporary node on the cloud vendor server corresponding to the optimal strategy and assign an IP address to the temporary node; register the IP address with a preset load balancer;

[0079] Deploy an instance of the instance type corresponding to the optimal strategy on the temporary node.

[0080] Specifically, firstly, the system locks the server resources of the target cloud vendor (such as Alibaba Cloud, Tencent Cloud, etc.) and its designated availability zone according to the optimal strategy, calls the cloud vendor's API to create a temporary node marked "ephemeral: true", and triggers the dynamic IP resource pool allocation mechanism to assign a unique IP address to the newly created temporary node. Next, the system automatically registers the IP address to the preset cloud vendor load balancer, such as Tencent Cloud CLB (Cloud Load Balancer), and completes the linkage configuration between the node and the load balancer network to ensure that subsequent task traffic can be accurately routed to the node. After the IP registration and network configuration are confirmed to be correct, the system deploys Pod instances that match the task resource requirements on the temporary node according to the instance type specified by the optimal strategy (such as spot instances or on-demand instances). During the deployment process, the resource configuration templates corresponding to the task (such as CPU / memory limits, storage specifications, etc.) are loaded synchronously to ensure that the instance parameters are highly adapted to the task requirements. No manual intervention is required throughout the process, realizing an automated closed loop from the creation of the temporary node, network configuration to instance deployment.

[0081] The above steps, through an automated closed loop of "node creation - IP configuration - load balancing - instance deployment," achieve a unified balance between high efficiency in multi-cloud resource scheduling, network availability, and business adaptability. On one hand, temporary nodes are created on the target cloud vendor's servers according to the optimal strategy. Dynamic IP allocation ensures compliant node network configuration and avoids IP blocking risks. Simultaneously, the IPs are registered with a preset load balancer, enabling temporary nodes to quickly connect to the business traffic distribution system. This ensures tasks can receive and process requests promptly, preventing resource idleness due to network configuration discrepancies. On the other hand, instances are deployed based on clearly defined instance types (such as low-cost spot instances and highly stable on-demand instances) according to the optimal strategy. This ensures that instance specifications precisely match task requirements, and the entire process requires no manual intervention. This improves the response speed of temporary resources from scheduling to availability and ensures the continuity of business access through load balancing, effectively supporting the stable execution of tasks in a dynamic resource environment.

[0082] In some embodiments, after deploying an instance of the instance type corresponding to the optimal strategy on the temporary node, the following steps are included:

[0083] By using a pre-defined network plugin, the traffic of the temporary node is isolated from the traffic of the pre-defined production environment.

[0084] Specifically, after deploying instances of the optimal policy corresponding to the instance type on the ephemeral node, the system will immediately start the preset network plugin (such as the Calico plugin adapted to multi-cloud environments) to perform traffic isolation operations: the network plugin will divide the ephemeral node and the deployed instance into independent network namespaces or logical isolation domains based on the pre-configured network policy rules, and explicitly restrict the interaction range of ephemeral node traffic by defining access control lists, allowing only ephemeral nodes to communicate with components necessary for task execution (such as load balancers and data storage nodes), and strictly blocking unnecessary traffic interactions between them and the preset production environment (such as core business systems, user data storage areas, and resident node clusters).

[0085] The above steps prevent the security risks (such as vulnerabilities and abnormal traffic) that may be introduced by temporary nodes due to their task characteristics (such as temporary computing and external data processing) from spreading to the production environment. They also prevent the sudden traffic of temporary nodes from occupying the network bandwidth resources of the production environment, ensuring the stable operation of production services. At the same time, they lay a network-level security foundation for the subsequent independent destruction and resource recycling of temporary nodes.

[0086] In some embodiments, assigning an IP address to the ephemeral node includes:

[0087] From the pre-requested global IP resource pool, IP addresses are randomly assigned to the temporary nodes according to the obtained user geographical location; wherein, the global IP resource pool is formed by pre-requesting IP segments in the availability zones of multiple cloud vendors.

[0088] The global IP resource pool is not created temporarily. Instead, the system pre-applies for IP segments in batches in different availability zones of multiple mainstream cloud providers such as Alibaba Cloud and Tencent Cloud (e.g., Alibaba Cloud East China Zone 1 and Tencent Cloud South China Zone 2), forming a cross-cloud provider and cross-regional IP resource reserve. The system also uses distributed storage components such as Etcd to synchronize the occupancy and idle status of each IP in real time to avoid allocation conflicts. When an IP needs to be allocated to a temporary node, the system first obtains the geographical location of the user corresponding to the current task (e.g., European users or users in East China). It then selects a subset of availability zone IPs that are close to the user's geographical location from the global IP resource pool to reduce cross-regional network transmission latency. Then, from the selected regionally compatible IP subset, an unoccupied IP is randomly selected and allocated to the temporary node using a random algorithm. This avoids the concentrated exposure of IP addresses caused by fixed IP allocation and further reduces the risk of being blocked by external services. The entire allocation process is fully automated and requires no manual intervention.

[0089] The aforementioned IP allocation method, on the one hand, shortens the network link between user requests and ephemeral nodes through adaptive allocation based on "user geographic location - IP region," effectively reducing network latency and improving task response speed, especially suitable for scenarios sensitive to network latency such as e-commerce promotions and real-time data processing; on the other hand, the random allocation mechanism avoids the problem of repeated use of a single IP or concentrated exposure of IP ranges, significantly reducing the probability of IPs being blocked by external platforms due to high-frequency access, and ensuring the stability of ephemeral node network connectivity; at the same time, the global IP resource pool pre-requested across cloud vendors breaks the limitations of IP resources from a single cloud vendor, ensuring that even if the availability zone IPs of a certain cloud vendor are insufficient, available IPs can still be obtained from other cloud vendors, improving the flexibility and reliability of IP allocation, and providing network infrastructure support for the stable operation of ephemeral nodes.

[0090] In some embodiments, after deploying an instance of the instance type corresponding to the optimal strategy on the temporary node, the method further includes:

[0091] If the temporary node remains idle for more than a preset time, the IP address will be removed from the load balancer.

[0092] Destroy the temporary node and reclaim the corresponding IP address;

[0093] When it is detected that the recycled IP address has been blocked, the recycled IP address will be removed from the global IP resource pool.

[0094] Specifically, after deploying instances of the optimal strategy corresponding to the instance type on the ephemeral node and completing task processing, the system will initiate an automated resource reclamation process: First, the load status of the ephemeral node is monitored in real time through the node monitoring module. When it is found that the idle time of the node exceeds a preset threshold (such as 5 minutes by default), and it is confirmed that there are no unfinished tasks or residual data on the node (the data is persisted through the Finalizer mechanism), the system will first send an instruction to the preset load balancer to delete the IP address corresponding to the node from the load balancer's node list, preventing subsequent traffic from continuing to be routed to the idle node; then, the cloud vendor's API is called to trigger the ephemeral node destruction operation, releasing... The system releases the computing and storage hardware resources occupied by the node, and at the same time reclaims the IP address corresponding to the node to the global IP resource pool, updates the status information of the IP resource pool in Etcd, and ensures that the IP can be reused by newly created temporary nodes. In addition, the system continuously monitors the reclaimed IP address through IP connectivity detection tools (such as periodic Ping tests and port probes). If a reclaimed IP is detected to be blocked (such as being unable to access external services normally or having its requests rejected), the IP address is immediately and permanently removed from the global IP resource pool, and the blocking log is recorded for subsequent investigation to prevent the blocked IP from being reassigned to new nodes and causing business anomalies.

[0095] The aforementioned resource recycling and IP management process, on the one hand, avoids the waste caused by long-term occupation of idle resources through automatic destruction of idle nodes and IP recycling, enabling cloud resources to be quickly reused. Especially in scenarios with large fluctuations in business load (such as after e-commerce promotional peaks), it can release redundant resources in a timely manner and reduce unnecessary cost expenditures. On the other hand, deleting IPs from the load balancer before destroying nodes prevents business interruptions caused by traffic routing to invalid nodes. The blocking detection and removal mechanism for recycled IPs completely avoids network connectivity problems caused by the reuse of blocked IPs, ensuring the stable execution of subsequent tasks. At the same time, the entire process is automated and requires no manual intervention, which reduces operation and maintenance costs and avoids omissions that may occur during manual operation (such as forgetting to delete load balancer nodes or not cleaning up blocked IPs), further improving the stability and efficiency of multi-cloud resource management.

[0096] Figure 3 This is a schematic diagram of the overall process of the multi-cloud resource dynamic scheduling method according to an embodiment of this application.

[0097] Step S301: The process begins, entering the task processing initialization phase.

[0098] Step S302: The system receives a task request initiated from an external source. The request contains key information such as task type and resource requirements.

[0099] Step S303: First, determine whether the task requires a temporary node. If so, create a temporary node, randomly assign an IP address to the temporary node from the pre-reserved global IP resource pool according to the user's geographical location, and register the IP address with the preset load balancer; if not, use a permanent node directly. Afterwards, the task will be executed regardless of whether it is a temporary or permanent node.

[0100] Step S304: During task execution, continuously check whether the task is completed. If not completed, continue executing the task; if completed, for tasks executed by ephemeral nodes, destroy the ephemeral node and reclaim its IP address.

[0101] Step S305: The process ends, completing the entire task processing and resource recycling loop.

[0102] In some embodiments, the instance types include auction instances and on-demand instances.

[0103] Among them, spot instances are low-cost instance types offered by cloud providers based on idle computing resources. Their prices fluctuate dynamically with market supply and demand (such as Alibaba Cloud's preemptive instances), and are typically 30%-70% lower than on-demand instances. However, they carry the risk of interruption due to cloud provider resource reclamation, making them more suitable for fault-tolerant, non-real-time tasks. On-demand instances, on the other hand, are standard instance types provided by cloud providers. They have fixed prices and exclusive resource usage, and cloud providers guarantee continuous operation (unless the user actively destroys the instance). They offer higher stability and are suitable for core tasks with strict requirements for continuity and real-time performance. In actual scheduling, the system combines task priority, cost budget, and business stability requirements to select the appropriate instance type from these two types. For example, low-priority backend data statistics tasks prioritize spot instances to reduce costs, while high-priority order processing and payment calculation tasks use on-demand instances to ensure uninterrupted business operations. The selection of both types of instances is made through a dynamic pricing optimizer linked with the task demand assessment module, ensuring a precise match between instance type and task characteristics.

[0104] In some embodiments, the task types include compute-intensive and I / O-intensive tasks.

[0105] The core requirements for computationally intensive tasks lie in the computing power of CPUs or GPUs. Typical scenarios include real-time recommendation algorithms on e-commerce platforms, risk model calculations in financial systems, and data analysis and modeling in big data scenarios. These tasks continuously consume a large amount of computing resources during execution, requiring high CPU / GPU core counts and processing speeds, while being relatively less sensitive to data read / write speeds. I / O intensive tasks, on the other hand, rely more on data input / output efficiency and are commonly found in scenarios such as user access request processing, order data storage and retrieval, and log file reading and writing. During execution, they frequently interact with storage devices or networks, requiring higher stability in storage IOPS (input / output operations per second) and network bandwidth, while CPU resource usage is relatively moderate. During the task requirement assessment phase, the system analyzes the task's business logic (such as whether it involves a large amount of data reading and writing, or whether complex calculations are required) and historical running data (such as CPU utilization and I / O wait time percentages of past tasks) to accurately determine the task type and match the appropriate resource type accordingly. For example, allocate instances with high CPU / GPU specifications for compute-intensive tasks, and select instances with high IOPS storage and high-bandwidth network configurations for IO-intensive tasks to ensure that resource supply is highly matched with task requirements.

[0106] The following example, using an e-commerce platform promotion scenario, illustrates this embodiment.

[0107] Suppose a large e-commerce platform needs to process a large number of user requests, order generation, and data calculations within a short period during a specific promotional season (such as "Double Eleven"). Due to fluctuations in user traffic, traditional fixed resource deployment methods may lead to excessive resource strain during peak traffic periods and resource waste during off-peak periods. To improve resource utilization efficiency and reduce costs, the e-commerce platform decides to adopt a multi-cloud resource elastic scaling and pricing optimization management solution based on task requirements.

[0108] Application scenario description:

[0109] (1) Task Description: During e-commerce platform promotions, the core tasks of the platform include user access, order processing, inventory management, payment calculation, and recommendation algorithms. The computational and storage requirements of these tasks vary at different times, and traffic peaks and troughs will alternate as the promotion proceeds.

[0110] (2) Resource demand assessment:

[0111] User access: During peak promotional periods, the bandwidth demand for user access is extremely high, especially when a flash sale begins, the system needs to respond quickly to a large number of concurrent requests.

[0112] Order processing and recommendation algorithms: These tasks require significant computing resources, especially CPU and memory, to support rapid order generation and real-time recommendation calculations.

[0113] Storage requirements: As user data volume increases, temporary storage requirements fluctuate constantly, and excess storage resources need to be released immediately after the promotion ends.

[0114] (3) System dynamic scheduling and pricing optimization:

[0115] Task estimation: The system predicts the resource requirements of tasks based on historical traffic data and task runtime. For example, during peak traffic periods, the system estimates that user access tasks will require more bandwidth, while order processing and recommendation algorithms will require more computing resources.

[0116] Cross-cloud resource scheduling: Based on the resource supply and demand of cloud vendors, the system selects the cloud vendor with the most abundant resources and the best price. For example, when Alibaba Cloud resources are scarce, the system may prioritize Tencent Cloud or Huawei Cloud for resource requests to ensure optimal resource pricing and task execution efficiency.

[0117] Dynamic pricing calculation: The system calculates the price for each task and adjusts it according to priority. Urgent order processing tasks are prioritized, while low-priority recommendation algorithm tasks can be processed using cheaper resources.

[0118] (4) Resource elastic scaling: When the promotional activity enters the peak period, the system will automatically expand resources and release temporary resources that are no longer needed after the activity ends to avoid waste.

[0119] Experimental comparison: Traditional solution vs. pricing optimization solution based on task requirements;

[0120] To verify the effectiveness of our task-demand-based multi-cloud resource elastic scaling and pricing optimization management solution, we conducted the following comparative experiments:

[0121] Experimental setup:

[0122] (1) Traditional solution: In the traditional solution, e-commerce platforms use fixed resource configuration and resource supply from a single cloud vendor, reserve resources during peak periods, and do not have dynamic pricing optimization.

[0123] (2) Task-based solution: In the new solution, the e-commerce platform uses a resource pricing optimization method based on task requirements, combined with multi-cloud resource scheduling, to dynamically adjust resource allocation and pricing.

[0124] Evaluation indicators:

[0125] (1) Resource utilization efficiency: measures the utilization rate of resources during task execution.

[0126] (2) Total cost: including the total cost of computing resources, storage resources, bandwidth resources, etc.

[0127] (3) Task completion time: The completion time of each task, especially the response speed during peak promotional periods.

[0128] (4) The degree to which task priorities are met: whether high-priority tasks can be completed on time.

[0129]

[0130] Experimental Analysis:

[0131] (1) Resource utilization efficiency: In the traditional solution, fixed resource allocation fails to make full use of idle resources during off-peak periods. However, the solution based on task requirements can automatically adjust resources during peak and off-peak periods through dynamic resource scheduling and elastic scaling, which greatly improves resource utilization.

[0132] (2) Total cost: The pricing optimization scheme based on task requirements saves a lot of unnecessary resource costs by dynamically adjusting resource supply, selecting the best cloud vendor and monitoring supply and demand in real time, and the overall cost is reduced by 30%.

[0133] (3) Task completion time: The solution based on task requirements performs better in high-priority tasks (such as order processing) by prioritizing the allocation of computing resources, thereby reducing response time.

[0134] (4) The degree of satisfaction of task priority: The new solution can more accurately meet the needs of high priority tasks, prioritize resource allocation in emergency tasks, and ensure the timely completion of tasks.

[0135] Application effects and commercial value:

[0136] (1) Reduce costs: Through dynamic pricing of tasks and cross-cloud resource scheduling, e-commerce platforms can adjust resource allocation according to real-time demand, avoiding excessive reservation and unnecessary resource waste, thereby saving about 30% of operating costs.

[0137] (2) Improve user experience: High-priority tasks (such as order processing and payment) are given priority resource guarantees, ensuring user experience during promotional activities and avoiding system crashes or delays due to insufficient resources.

[0138] (3) Enhanced flexibility and scalability: As the needs of the event change, the system can quickly respond and expand resources, and can automatically release resources after the event ends, which greatly improves the flexibility of the platform's resource management.

[0139] Beneficial effects:

[0140] (1) Improve resource utilization efficiency: Through accurate task demand assessment and intelligent resource scheduling, the utilization efficiency of resources is significantly improved, avoiding excessive idleness or waste of resources.

[0141] (2) Reduce operating costs: The dynamic pricing optimization scheme effectively reduces the cost of task execution. By selecting the best resource supplier and reasonable resource pricing, the company can complete the task at a lower cost.

[0142] (3) Improve system response speed and stability: Through priority scheduling and automated resource allocation, high-priority tasks can be completed on time, while improving the system response speed and stability.

[0143] (4) Enhance system flexibility: The system can automatically expand and shrink resources according to changes in task load, which greatly improves the system's flexibility and scalability, and can flexibly cope with various scenarios such as load fluctuations and sudden traffic.

[0144] (5) Enhance enterprise competitiveness: By reducing cloud computing costs and optimizing resource management, enterprises can invest more resources in business innovation and market expansion, thereby enhancing their market competitiveness.

[0145] This embodiment also provides a multi-cloud resource dynamic scheduling device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as described above. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0146] Figure 4 This is a structural block diagram of a multi-cloud resource dynamic scheduling device according to an embodiment of this application, such as... Figure 4 As shown, the device includes:

[0147] The matching module 41 is used to match the computing resource type based on the task type of the task to be executed, and to confirm the task priority corresponding to the task type.

[0148] The prediction module 42 is used to predict the resource requirements corresponding to the task type based on the resource type, the historical task traffic duration data obtained, and the real-time business load obtained; the historical task traffic duration data includes historical task traffic data and historical task runtime data.

[0149] The initial cost calculation module 43 is used to calculate the initial instance resource cost of each instance type of each cloud vendor based on the instance resource information and estimated task duration in the resource requirements, as well as the resource supply status and instance price information of each cloud vendor obtained from the preset federated cluster management module.

[0150] The calibration overhead calculation module 44 is used to obtain the calibration instance resource overhead of each instance type of each cloud vendor based on the priority adjustment factor corresponding to the initial instance resource overhead and the task priority.

[0151] The optimal strategy confirmation module 45 is used to select the cloud vendor and corresponding instance type with the lowest corrected instance resource cost among the corrected instance resource costs of each cloud vendor and each instance type as the optimal strategy.

[0152] Deployment module 46 is used to create temporary nodes on the cloud vendor server corresponding to the optimal policy, and deploy instances of the instance type corresponding to the optimal policy on the temporary nodes.

[0153] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination. Specific examples in this embodiment can be found in the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0154] Furthermore, in conjunction with the multi-cloud resource dynamic scheduling method in the above embodiments, this application embodiment can provide a storage medium for implementation. The storage medium stores a computer program; when executed by a processor, the computer program implements any of the multi-cloud resource dynamic scheduling methods in the above embodiments.

[0155] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0156] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0157] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0158] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for dynamic scheduling of multi-cloud resources, characterized in that, include: The resource type is matched based on the task type of the task to be executed, and the task priority corresponding to the task type is confirmed. Based on the resource type, the obtained historical task traffic duration data, and the obtained real-time business load, the resource requirements corresponding to the task type are predicted; the historical task traffic duration data includes historical task traffic data and historical task runtime data. Based on the instance resource information and estimated task duration in the resource requirements, as well as the resource supply status and instance price information of each cloud vendor obtained from the preset federated cluster management module, the initial instance resource cost of each instance type of each cloud vendor is calculated. Based on the initial instance resource overhead and the priority adjustment factor corresponding to the task priority, the corrected instance resource overhead of each instance type of each cloud vendor is obtained. Among the corrected instance resource overhead of each cloud vendor and each instance type, the cloud vendor with the lowest corrected instance resource overhead and the corresponding instance type are selected as the optimal strategy. Create a temporary node on the cloud vendor server corresponding to the optimal strategy, and deploy an instance of the instance type corresponding to the optimal strategy on the temporary node.

2. The multi-cloud resource dynamic scheduling method according to claim 1, characterized in that, The process of obtaining the corrected instance resource costs for each instance type from each cloud vendor based on the initial instance resource costs and the priority adjustment factor corresponding to the task priority includes: Obtain network overhead data; the network overhead data includes IP allocation, data transmission, and load balancing overhead data that match the cloud vendor and instance type; Based on the product of the initial instance resource overhead and the priority adjustment factor corresponding to the task priority, and then superimposed with the network overhead data, the corrected instance resource overhead for each instance type of each cloud vendor is obtained.

3. The multi-cloud resource dynamic scheduling method according to claim 1, characterized in that, The step of creating a temporary node on the cloud vendor server corresponding to the optimal strategy and deploying an instance of the instance type corresponding to the optimal strategy on the temporary node includes: Create a temporary node on the cloud vendor server corresponding to the optimal strategy and assign an IP address to the temporary node; register the IP address with a preset load balancer; Deploy an instance of the instance type corresponding to the optimal strategy on the temporary node.

4. The multi-cloud resource dynamic scheduling method according to claim 3, characterized in that, After deploying an instance of the instance type corresponding to the optimal strategy on the temporary node, the following steps are included: By using a pre-defined network plugin, the traffic of the temporary node is isolated from the traffic of the pre-defined production environment.

5. The multi-cloud resource dynamic scheduling method according to claim 3, characterized in that, Assigning an IP address to the temporary node includes: From the pre-requested global IP resource pool, IP addresses are randomly assigned to the temporary nodes according to the obtained user geographical location; wherein, the global IP resource pool is formed by pre-requesting IP segments in the availability zones of multiple cloud vendors.

6. The multi-cloud resource dynamic scheduling method according to claim 5, characterized in that, After deploying an instance of the instance type corresponding to the optimal strategy on the temporary node, the process further includes: If the temporary node remains idle for more than a preset time, the IP address will be removed from the load balancer. Destroy the temporary node and reclaim the corresponding IP address; When it is detected that the recycled IP address has been blocked, the recycled IP address will be removed from the global IP resource pool.

7. The multi-cloud resource dynamic scheduling method according to any one of claims 1 to 6, characterized in that, The instance types include auction instances and on-demand instances.

8. The multi-cloud resource dynamic scheduling method according to any one of claims 1 to 6, characterized in that, The task types include compute-intensive and I / O-intensive tasks.

9. A multi-cloud resource dynamic scheduling device, characterized in that, The device includes: The matching module is used to match computing resource types based on the task type of the task to be executed, and to confirm the task priority corresponding to the task type. The prediction module is used to predict the resource requirements corresponding to the task type based on the resource type, the historical task traffic duration data obtained, and the real-time business load obtained; the historical task traffic duration data includes historical task traffic data and historical task runtime data. The initial cost calculation module is used to calculate the initial instance resource cost of each instance type of each cloud vendor based on the instance resource information and estimated task duration in the resource requirements, as well as the resource supply status and instance price information of each cloud vendor obtained from the preset federated cluster management module. The correction overhead calculation module is used to obtain the correction instance resource overhead of each instance type of each cloud vendor based on the initial instance resource overhead and the priority adjustment factor corresponding to the task priority. The optimal strategy confirmation module is used to select the cloud vendor and corresponding instance type with the lowest corrected instance resource cost among the corrected instance resource costs of each instance type of each cloud vendor as the optimal strategy. The deployment module is used to create a temporary node on the cloud vendor server corresponding to the optimal strategy, and deploy an instance of the instance type corresponding to the optimal strategy on the temporary node.

10. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the multi-cloud resource dynamic scheduling method according to any one of claims 1 to 8 at runtime.

Images