User-demand-oriented cloud host batch rapid construction method and device

Abstract

The invention provides a user-demand-oriented cloud host batch rapid construction method and device, and relates to the technical field of cloud computing application, and the method comprises the steps: receiving a cloud host batch construction request submitted by a user; performing task splitting on the batch construction request according to the configuration information, splitting the batch construction request into N sub-tasks, and determining a cluster corresponding to each sub-task; scheduling the sub-tasks by adopting a preset scheduling strategy, and allocating the N sub-tasks to target computing nodes in corresponding clusters for execution; monitoring execution states of all the sub-tasks, and generating a batch construction result report after all the sub-tasks are completed; and if it is detected that execution of the subtasks fails, triggering a resource rollback process, and releasing the allocated invalid resources. According to the method, the problems of low batch deployment efficiency, inconsistent configuration and poor fault tolerance in the prior art can be solved, and efficient batch construction and intelligent scheduling of the cloud hosts are realized.

Description

Technical Field

[0001] This invention relates to the field of cloud computing application technology, and in particular to a method and apparatus for rapid batch construction of cloud servers to meet user needs. Background Technology

[0002] With the deep penetration of cloud computing technology into enterprise IT infrastructure, cloud platforms have become the core carrier supporting business operations. Users have an increasingly urgent need for the batch deployment of cloud server resources, requiring the rapid and stable creation of dozens or even hundreds of cloud servers with identical configurations to meet the dual requirements of business for resource delivery efficiency and cluster stability. However, traditional cloud server creation methods are difficult to adapt to such batch requirements, gradually exposing the technical pain point of balancing resource delivery efficiency and configuration consistency, which restricts the business response speed of enterprises in cloud computing scenarios.

[0003] To alleviate the aforementioned problems, existing technologies have developed two typical solutions. One is a batch deployment solution based on orchestration tools, such as Terraform and Ansible. This solution defines cloud host specifications, network configurations, and other parameters by writing resource templates, and then calls the cloud platform API to perform batch creation operations, attempting to ensure parameter consistency through templated configuration. The other is a solution based on native cloud platform resource templates, such as AWS CloudFormation and Azure ARM templates. This solution relies on standardized templates provided by cloud vendors to encapsulate the configurations and dependencies of multiple cloud hosts into template files. Users can trigger a batch creation process by submitting templates, aiming to simplify deployment operations through the platform's native capabilities.

[0004] However, all of the aforementioned existing technologies have key drawbacks: they cannot achieve dynamic adaptation and high fault tolerance in resource scheduling while ensuring batch deployment efficiency. Specifically, while orchestration-based solutions can achieve batch creation, users need to master specific template syntax, resulting in a high learning cost. Furthermore, the scheduling logic is fixed and cannot dynamically allocate tasks based on the real-time load of computing nodes, easily leading to some nodes being overloaded and others being idle, thus reducing resource utilization efficiency. While native resource template-based solutions lower the learning threshold, they lack a fine-grained scheduling mechanism for fault domains. When a single node fails, cloud hosts created with the same template are easily affected collectively, resulting in insufficient fault tolerance. If temporary errors occur during batch creation, manual intervention is required to re-execute, severely impacting deployment efficiency. This deficiency has become the core bottleneck restricting the rapid batch construction of cloud hosts. Summary of the Invention

[0005] This invention provides a method and apparatus for rapid batch construction of cloud servers to meet user needs. It can solve the problems of low batch deployment efficiency, inconsistent configuration, and poor fault tolerance in the prior art, and realize efficient batch construction and intelligent scheduling of cloud servers.

[0006] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: Firstly, a method for rapidly building cloud servers in batches to meet user needs is provided. The method includes: receiving a batch build request submitted by a user, the batch build request requesting the construction of N cloud servers, and the batch build request carrying configuration information; performing task splitting on the batch build request according to the configuration information, splitting the batch build request into N sub-tasks, and determining the cluster corresponding to each sub-task, with each sub-task being used to build one cloud server in its corresponding cluster; scheduling the sub-tasks using a preset scheduling strategy, allocating the N sub-tasks to target computing nodes in the corresponding clusters for execution, the scheduling strategy including a basic scheduling strategy based on minimum load priority and an advanced scheduling strategy based on anti-affinity; monitoring the execution status of all sub-tasks, and generating a batch build result report after all sub-tasks are completed, the report including success rate statistics, resource allocation details, and error diagnosis information; if a sub-task execution failure is detected, triggering a resource rollback process to release the allocated invalid resources.

[0007] The beneficial effects of this invention are as follows: First, the method provided by this invention firstly breaks down batch requests into N independent subtasks, and uses a scheduling strategy to achieve parallel processing, avoiding the accumulated time consumption of traditional serial operations and significantly improving the batch build speed. Secondly, through unified monitoring and reports including success rates and resource details, it ensures that the configuration of each cloud host meets user needs, eliminates configuration inconsistencies caused by manual intervention, and improves cluster stability. Finally, when a subtask fails, it triggers resource rollback, releasing allocated invalid resources, avoiding the problem of long-term resource idleness after traditional failures, and significantly improving the resource utilization of the cloud platform. In this way, the method provided by this invention can solve the problems of low batch deployment efficiency, inconsistent configurations, and poor fault tolerance in existing technologies, achieving efficient batch build and intelligent scheduling of cloud hosts.

[0008] In one possible implementation of the first aspect, the step of splitting the batch build request into N sub-tasks based on the configuration information and determining the cluster corresponding to each sub-task includes: extracting configuration parameters from the batch build request, the configuration parameters including the specification configuration, network parameters, storage configuration, and deployment strategy information of each of the N cloud hosts, the deployment strategy information being used to characterize whether the N cloud hosts specify a target cluster; if the N cloud hosts specify a target cluster, obtaining the real-time resource capacity of the target cluster, the real-time resource capacity including the number of remaining CPU cores, available memory, storage space, and available network bandwidth of the target cluster; verifying whether the real-time resource capacity of the target cluster meets the total resource requirements of the N cloud hosts; and verifying whether the number of remaining CPU cores of the target cluster is greater than or equal to the number of N cloud hosts. If the target cluster's available memory is greater than or equal to the memory requirements of the N cloud hosts, the target cluster's storage space is greater than or equal to the storage requirements of the N cloud hosts, and the target cluster's available network bandwidth is greater than or equal to the network bandwidth requirements of the N cloud hosts, the batch build request is split into N sub-tasks, and the cluster corresponding to each sub-task is determined as the target cluster. If the target cluster's remaining CPU cores are less than the CPU core requirements of the N cloud hosts, the target cluster's available memory is less than the memory requirements of the N cloud hosts, the target cluster's storage space is less than the storage requirements of the N cloud hosts, or the target cluster's available network bandwidth is less than the network bandwidth requirements of the N cloud hosts, a resource shortage warning message is generated to indicate insufficient resources to the target cluster. The warning message includes the type and quantity of the missing resources.

[0009] The method provided by this invention accurately extracts core parameters such as specification configuration, network parameters, storage configuration, and deployment strategies from batch build requests, ensuring comprehensive coverage of user needs and avoiding unexpected cloud host configurations due to parameter omissions. This lays an accurate foundation for subsequent task splitting and resource allocation. Furthermore, for a specified target cluster, it obtains real-time resource capacity across all dimensions, including the number of remaining CPU cores, available memory, storage space, and available network bandwidth, and verifies whether it meets the total resource requirements of N cloud hosts. This ensures that the target cluster can not only support the basic computing and storage needs of the cloud hosts but also guarantee critical operating conditions such as network communication. This completely avoids the problem of cloud hosts being created but not usable due to traditional methods that only verify some resource dimensions, reducing invalid builds and rework costs. Finally, when the target cluster resources are insufficient, it explicitly generates a prompt message containing the type and specific quantity of missing resources. Compared to traditional methods, operations and maintenance personnel do not need to check the remaining status of various resources in the cluster one by one. They can directly formulate expansion plans for missing resources, significantly shortening the response time for resource replenishment, ensuring the rapid continuation of batch build tasks, and significantly improving the efficiency and controllability of the overall build process.

[0010] In one possible implementation of the first aspect, the step of splitting the batch build request into N sub-tasks based on the configuration information and determining the cluster corresponding to each sub-task further includes: when no target cluster is specified for the N cloud hosts, obtaining the real-time resource capacity of multiple available clusters, wherein the real-time resource capacity includes the number of remaining CPU cores, available memory, storage space, and network bandwidth of the available clusters; determining a capacity score for each available cluster based on the real-time resource capacity of the multiple available clusters, wherein the capacity score is positively correlated with the resource capacity of the available clusters; and ranking the multiple available clusters from largest to smallest based on the capacity score. Sort the data to obtain a sorting result; split the batch build request into N subtasks; calculate the number of allocable subtasks for the first available cluster in the sorting result, allocate the corresponding number of subtasks to the first available cluster, update the remaining resources of the cluster and the number of subtasks to be allocated, until the termination condition is met. The termination condition includes: the number of subtasks to be allocated is 0, the available clusters have been traversed and the number of subtasks to be allocated is greater than 0, generating a resource shortage prompt message, the prompt message including the type and quantity of the missing resources, or, the number of operation iterations reaches a preset maximum iteration threshold, terminating the allocation and generating an iteration timeout prompt message; the formula for determining the capacity score S is: S = 0.4A + 0.3B + 0.2C + 0.1D; where A is the normalized value of the number of remaining CPU cores, B is the normalized value of available memory, C is the normalized value of storage space, and D is the normalized value of network bandwidth.

[0011] The method provided by this invention is based on capacity scoring, sorts available clusters in descending order of capacity, and prioritizes the allocation of subtasks to clusters with sufficient resources. This avoids the uneven load distribution problem of traditional random allocation, ensures balanced resource utilization in each cluster, and reduces build delays caused by single cluster overload. Furthermore, it specifies multiple termination conditions, which not only prevents infinite loops in the traditional allocation process, but also accurately indicates the gap type when resources are exhausted, helping operations and maintenance to quickly expand capacity. At the same time, it avoids system resource waste caused by excessive iterations, and improves the controllability and stability of batch allocation.

[0012] In one possible implementation of the first aspect, the configuration parameters further include the subtask group identifiers and fault domain isolation requirements to be distributed among the N cloud hosts; the step of scheduling the subtasks using a preset scheduling strategy and allocating the N subtasks to target computing nodes in the corresponding clusters for execution includes: for a target subtask, determining the topology information of all available computing nodes in the cluster corresponding to the target subtask, the topology information including the fault domain identifier of the computing node and the number of subtasks in the same group already carried; removing computing nodes that have already carried subtasks in the same group, and retaining the fault domain identifiers of the assigned subtasks in the same group. Multiple candidate computing nodes are obtained from different computing nodes in the domain; real-time load data of the multiple candidate computing nodes are determined, including CPU utilization, memory utilization, I / O utilization, network utilization, and GPU utilization of the computing nodes, and the target subtask is any one of N subtasks; the real-time load data is standardized to obtain normalized values ​​of CPU utilization, memory utilization, I / O utilization, network utilization, and GPU utilization; a weighted average is then calculated based on the normalized values ​​of CPU utilization, memory utilization, I / O utilization, network utilization, and GPU utilization. The load score of each candidate computing node is obtained. The load scores of each candidate computing node are sorted from smallest to largest, and the candidate computing node with the lowest load score is selected as the target computing node for the target subtask. The real-time resources of the target computing node are verified to meet the specifications and configuration requirements of the cloud host corresponding to the target subtask. If they do, the target subtask is assigned to the target computing node for execution. If not, the target computing node is removed, and the next computing node with the lowest load score is selected from the sorted computing nodes. This verification process is repeated until the target computing node suitable for the target subtask is determined. If the load score of all available computing nodes in the cluster corresponding to the target subtask exceeds a preset safety threshold, the number of concurrent subtasks processed by the cluster corresponding to the target subtask is reduced, and unassigned subtasks are temporarily stored in the task queue. When the load score of the available computing nodes in the cluster corresponding to the target subtask is less than the preset safety threshold, the remaining subtasks are re-executed. If all fault domains in the cluster corresponding to the target subtask are already carrying subtasks in the same group, a scheduling conflict prompt message is generated. The scheduling conflict prompt message includes a list of occupied fault domains and identifiers of subtasks in the same group that can be released.

[0013] The method provided by this invention distributes subtasks that need to be deployed in a distributed manner to different fault domains by filtering out nodes in the same group and retaining nodes in different fault domains. This avoids the risks of traditional deployment in the same fault domain. Even if a node fails, it only affects a small number of cloud hosts in the same group, significantly improving system fault tolerance and service continuity. Furthermore, it accurately matches the computing needs of cloud hosts by calculating load scores and selects the node with the lowest load to avoid build failures caused by node overload and improve the utilization rate of computing node resources. Finally, when the load exceeds the threshold, it reduces concurrency and temporarily stores tasks to prevent the cluster from being paralyzed due to too many tasks. When scheduling conflicts occur, it prompts that fault domains are occupied and that subtasks can be released, reducing scheduling blocking time and ensuring a smooth batch build process.

[0014] In one possible implementation of the first aspect, the step of triggering a resource rollback process and releasing allocated invalid resources if a subtask execution failure is detected includes: when a subtask execution failure is detected, obtaining the resource allocation record of the subtask, the resource allocation record including the number of locked CPU cores, memory size, storage space, virtual network interface identifier, and storage volume identifier; determining the subtask failure type, and if the failure type is resource allocation failure, directly executing resource release; if the failure type is execution timeout, first calling the target cluster status query interface to confirm whether there are any incomplete cloud host instances, and if so, deleting the instances through the cluster API.

[0015] The method provided by this invention directly releases resources in the event of allocation failure, avoiding invalid resource occupation; for execution timeouts, it first queries the cluster status to confirm the existence of incomplete instances before deletion, preventing instance residue caused by the traditional method of releasing resources upon timeout. Simultaneously, based on locked resource allocation records for CPU, memory, virtual network interfaces, etc., it ensures no resource omissions during rollback, avoiding resource fragmentation caused by incomplete rollbacks in traditional methods, and improving the cleanliness and reuse efficiency of cloud platform resources.

[0016] In one possible implementation of the first aspect, after splitting the batch build request into N sub-tasks based on the configuration information, the method further includes: assigning a unique identifier and injecting execution context information for each sub-task, the execution context information including cluster API credentials, image repository address, security group fingerprint, tenant ID, and timeout threshold; locking cluster resources using a distributed lock; starting N independent monitoring threads to receive the sub-task status via RabbitMQ, the sub-task status including initialization, resource locking, execution, success, or failure; and establishing a status cache table to store the status of each sub-task, the execution node IP, and the elapsed time, the status cache table being used to generate the batch build result report.

[0017] The method provided by this invention ensures the traceability of each subtask's configuration by assigning a unique identifier and injecting context, avoiding confusion caused by traditional manual configuration entry and improving configuration consistency. Furthermore, it prevents multiple subtasks from competing for the same cluster resources through distributed locks, avoiding resource allocation conflicts caused by traditional lock-free mechanisms and reducing task failure rates. Finally, it provides real-time and accurate data support for result reports by receiving status through RabbitMQ and storing details in a status cache table via N independent monitoring threads, avoiding the delays and errors of traditional manual progress statistics and improving the transparency and manageability of batch builds.

[0018] In one possible implementation of the first aspect, the method further includes: storing image files used for batch building of cloud hosts in the image repository of each cluster, and periodically verifying the integrity of the image files; if image files are found to be corrupted or updated, re-caching the image files, wherein the image files include system images and application images; pre-initializing the virtualization environment for the compute nodes in each cluster, wherein for KVM-driven compute nodes, the KVM kernel module is pre-loaded and a default virtual network is created; for VMware-driven compute nodes, a connection session with vCenter is pre-established and vSAN storage policies are loaded to avoid repeated initialization operations during subtask execution; real-time statistics of the cache hit rate of each image are performed, and images with a hit rate lower than a preset hit rate threshold are automatically cleaned up to release local storage resources; for compute nodes that have not carried subtasks for more than a preset time after initialization, the pre-initialized virtualization environment resources are released.

[0019] The method provided by this invention stores images in a local cluster repository and pre-initializes the virtualization environment, avoiding remote IO waits and repeated initialization operations during each creation. This effectively shortens the creation time of a single cloud host, and the efficiency improvement is even more significant in batch scenarios. On the other hand, it provides real-time statistics on image cache hit rate and releases pre-initialized environments that have timed out and are not being used for tasks, preventing traditional local storage from being occupied by low-frequency images and idle environments. This ensures that storage resources prioritize high-frequency needs, improves local storage utilization, and reduces the consumption of computing node performance by invalid environments.

[0020] Secondly, the present invention provides a cloud server batch rapid construction device oriented to user needs. The device includes: a request receiving module, used to receive a batch construction request for cloud servers submitted by a user, the batch construction request requesting the construction of N cloud servers, and the batch construction request carrying configuration information; a task splitting module, used to split the batch construction request into N sub-tasks according to the configuration information, and determine the cluster corresponding to each sub-task, each sub-task being used to build one cloud server in its corresponding cluster; a task scheduling module, used to schedule the sub-tasks using a preset scheduling strategy, and allocate the N sub-tasks to target computing nodes in the corresponding clusters for execution, the scheduling strategy including a basic scheduling strategy based on minimum load priority and an advanced scheduling strategy based on anti-affinity; a task monitoring module, used to monitor the execution status of all sub-tasks, and generate a batch construction result report after all sub-tasks are completed, the report including success rate statistics, resource allocation details and error diagnosis information; and a resource rollback module, used to trigger a resource rollback process and release allocated invalid resources if a sub-task execution failure is detected.

[0021] Thirdly, an electronic device is provided, the electronic device including a memory and one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform the method as described in any implementation of the first aspect.

[0022] Fourthly, a computer-readable storage medium is provided, including computer instructions that, when executed on an electronic device, cause the electronic device to perform a method as described in any implementation of the first aspect.

[0023] Fifthly, a computer program product is provided that, when run on a computer, causes the computer to perform the method in any implementation of the first aspect.

[0024] Understandably, the beneficial effects achieved by the system of the second aspect, the electronic device of the third aspect, the computer-readable storage medium of the fourth aspect, and the computer program product of the fifth aspect provided above can be referred to with reference to the beneficial effects of the first aspect and any of its possible design embodiments, which will not be repeated here. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a method for rapidly building cloud servers in batches to meet user needs, as provided in an embodiment of the present invention; Figure 3An interactive flowchart of a basic scheduling strategy provided in an embodiment of the present invention; Figure 4 A flowchart illustrating an advanced scheduling strategy provided in an embodiment of the present invention; Figure 5 A business process diagram for batch construction of cloud servers is provided in this embodiment of the invention; Figure 6 A flowchart of a task splitting strategy provided in an embodiment of the present invention; Figure 7 A task scheduling flowchart provided for an embodiment of the present invention; Figure 8 This is a schematic diagram of a construction device provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of another construction device provided in an embodiment of the present invention. Detailed Implementation

[0026] With the deep penetration of cloud computing technology into enterprise IT infrastructure, cloud platforms have become the core carrier supporting business operations. Users have an increasingly urgent need for the batch deployment of cloud server resources, requiring the rapid and stable creation of dozens or even hundreds of cloud servers with identical configurations to meet the dual requirements of business for resource delivery efficiency and cluster stability. However, traditional cloud server creation methods are difficult to adapt to such batch requirements, gradually exposing the technical pain point of balancing resource delivery efficiency and configuration consistency, which restricts the business response speed of enterprises in cloud computing scenarios.

[0027] To alleviate the aforementioned problems, existing technologies have developed two typical solutions. One is a batch deployment solution based on orchestration tools, such as Terraform and Ansible. This solution defines cloud host specifications, network configurations, and other parameters by writing resource templates, and then calls the cloud platform API to perform batch creation operations, attempting to ensure parameter consistency through templated configuration. The other is a solution based on native cloud platform resource templates, such as AWS CloudFormation and Azure ARM templates. This solution relies on standardized templates provided by cloud vendors to encapsulate the configurations and dependencies of multiple cloud hosts into template files. Users can trigger a batch creation process by submitting templates, aiming to simplify deployment operations through the platform's native capabilities.

[0028] However, all of the aforementioned existing technologies have key drawbacks: they cannot achieve dynamic adaptation and high fault tolerance in resource scheduling while ensuring batch deployment efficiency. Specifically, while orchestration-based solutions can achieve batch creation, users need to master specific template syntax, resulting in a high learning cost. Furthermore, the scheduling logic is fixed and cannot dynamically allocate tasks based on the real-time load of computing nodes, easily leading to some nodes being overloaded and others being idle, thus reducing resource utilization efficiency. While native resource template-based solutions lower the learning threshold, they lack a fine-grained scheduling mechanism for fault domains. When a single node fails, cloud hosts created with the same template are easily affected collectively, resulting in insufficient fault tolerance. If temporary errors occur during batch creation, manual intervention is required to re-execute, severely impacting deployment efficiency. This deficiency has become the core bottleneck restricting the rapid batch construction of cloud hosts.

[0029] In view of this, embodiments of the present invention provide a method and apparatus for rapid batch construction of cloud servers to meet user needs. The method includes: receiving a batch construction request for cloud servers submitted by a user, the batch construction request requesting the construction of N cloud servers, and the batch construction request carrying configuration information; performing task splitting on the batch construction request according to the configuration information, splitting the batch construction request into N sub-tasks, and determining the cluster corresponding to each sub-task, each sub-task being used to build one cloud server in its corresponding cluster; scheduling the sub-tasks using a preset scheduling strategy, allocating the N sub-tasks to target computing nodes in the corresponding clusters for execution, the scheduling strategy including a basic scheduling strategy based on minimum load priority and an advanced scheduling strategy based on anti-affinity; monitoring the execution status of all sub-tasks, and generating a batch construction result report after all sub-tasks are completed, the report including success rate statistics, resource allocation details, and error diagnosis information; if a sub-task execution failure is detected, triggering a resource rollback process to release the allocated invalid resources.

[0030] The method provided by this invention first breaks down batch requests into N independent subtasks, and uses a scheduling strategy to achieve parallel processing, avoiding the accumulated time consumption of traditional serial operations and significantly improving the batch build speed. Second, through unified monitoring and reports including success rates and resource details, it ensures that the configuration of each cloud host meets user needs, eliminating configuration inconsistencies caused by manual intervention and improving cluster stability. Finally, when a subtask fails, resource rollback is triggered, releasing allocated invalid resources and avoiding the problem of long-term resource idleness after traditional failures, significantly improving the resource utilization of the cloud platform. In this way, the method provided by this invention can solve the problems of low batch deployment efficiency, inconsistent configurations, and poor fault tolerance in existing technologies, achieving efficient batch build and intelligent scheduling of cloud hosts.

[0031] In some embodiments, the cloud server batch rapid construction method oriented to user needs provided by the present invention can be executed by a cloud server batch rapid construction device 100 (hereinafter referred to as construction device 100) oriented to user needs.

[0032] As an example, the construction device 100 can be any electronic device 200 with data processing capabilities, such as a general-purpose computer, personal computer, laptop computer, switch, or tablet computer, etc. The specific implementation of the construction device 100 is not limited here.

[0033] Figure 1 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention is shown. The electronic device 200 includes a processor 210, a memory 220, and a communication interface 230.

[0034] Processor 210 may include one or more processing cores. Processor 210 connects to various parts within electronic device 200 using various interfaces and lines, and performs various functions and processes data of electronic device 200 by running or executing instructions, programs, code sets, or instruction sets stored in memory 220, and by calling data stored in memory 220. Optionally, processor 210 may be implemented using at least one of the following hardware forms: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA).

[0035] The memory 220 may include random access memory (RAI) or read-only memory (ROI). Optionally, the memory 220 may include non-transitory computer-readable storage ledger. The memory 220 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 220 may include a program storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as video acquisition, feature extraction, and process detection), and instructions for implementing the various method embodiments described above.

[0036] Communication interface 230 is used to communicate with other devices, equipment or communication networks, such as data storage devices, image processing devices or Ethernet, wireless access network (RAN), wireless local area network (WLAN), etc.

[0037] In terms of physical implementation, the aforementioned devices (such as processor 210, memory 220, and communication interface 230) can each be devices within the same device (such as a laptop computer). Alternatively, at least two of these devices can be located within the same device, i.e., as different devices within the same device, similar to the deployment of devices or components in a distributed system.

[0038] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 200. In other embodiments of the present invention, the electronic device 200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0039] The following description, in conjunction with the accompanying drawings, illustrates a method for rapidly building cloud servers in batches to meet user needs, as provided by an embodiment of the present invention.

[0040] Figure 2 This is a flowchart illustrating a method for rapid batch construction of cloud servers tailored to user needs, provided by an embodiment of the present invention. Optionally, this method can be... Figure 1 The illustrated electronic device 200 performs this operation. The method may include the following steps: S1. Receive a batch build request for cloud hosts submitted by the user. The batch build request is used to request the build of N cloud hosts and carries configuration information. S2. Based on the configuration information, perform task splitting on the batch build request, split the batch build request into N sub-tasks, and determine the cluster corresponding to each sub-task.

[0041] Each of the subtasks is used to build a cloud host for the corresponding cluster; In one possible implementation, the above S2 specifically includes: Configuration parameters are extracted from the batch build request. These parameters include the specifications, network parameters, storage configuration, and deployment strategy information for each of the N cloud hosts. The deployment strategy information indicates whether the N cloud hosts specify a target cluster. If the N cloud hosts specify a target cluster, the real-time resource capacity of the target cluster is obtained. This real-time resource capacity includes the remaining CPU cores, available memory, storage space, and available network bandwidth of the target cluster. The real-time resource capacity of the target cluster is verified to meet the total resource requirements of the N cloud hosts. If the remaining CPU cores of the target cluster are greater than or equal to the CPU core requirements of the N cloud hosts, and the available memory of the target cluster is greater than or equal to the memory requirements of the N cloud hosts, then... If the storage space of the target cluster is greater than or equal to the storage requirements of the N cloud hosts, and the available network bandwidth of the target cluster is greater than or equal to the network bandwidth requirements of the N cloud hosts, the batch build request is split into N sub-tasks, and the cluster corresponding to each sub-task is determined as the target cluster; if the remaining CPU cores of the target cluster are less than the CPU core requirements of the N cloud hosts, the available memory of the target cluster is less than the memory requirements of the N cloud hosts, the storage space of the target cluster is less than the storage requirements of the N cloud hosts, or the available network bandwidth of the target cluster is less than the network bandwidth requirements of the N cloud hosts, a resource shortage prompt message is generated to prompt the target cluster, and the prompt message includes the type and quantity of the missing resources.

[0042] The method provided by this invention accurately extracts core parameters such as specification configuration, network parameters, storage configuration, and deployment strategies from batch build requests, ensuring comprehensive coverage of user needs and avoiding unexpected cloud host configurations due to parameter omissions. This lays an accurate foundation for subsequent task splitting and resource allocation. Furthermore, for a specified target cluster, it obtains real-time resource capacity across all dimensions, including the number of remaining CPU cores, available memory, storage space, and available network bandwidth, and verifies whether it meets the total resource requirements of N cloud hosts. This ensures that the target cluster can not only support the basic computing and storage needs of the cloud hosts but also guarantee critical operating conditions such as network communication. This completely avoids the problem of cloud hosts being created but not usable due to traditional methods that only verify some resource dimensions, reducing invalid builds and rework costs. Finally, when the target cluster resources are insufficient, it explicitly generates a prompt message containing the type and specific quantity of missing resources. Compared to traditional methods, operations and maintenance personnel do not need to check the remaining status of various resources in the cluster one by one. They can directly formulate expansion plans for missing resources, significantly shortening the response time for resource replenishment, ensuring the rapid continuation of batch build tasks, and significantly improving the efficiency and controllability of the overall build process.

[0043] In another possible implementation, the above S2 also includes: When no target cluster is specified for the N cloud hosts, the real-time resource capacity of multiple available clusters is obtained. The real-time resource capacity includes the number of remaining CPU cores, available memory, storage space, and network bandwidth of the available clusters. A capacity score is determined for each available cluster based on its real-time resource capacity, wherein the capacity score is positively correlated with the resource capacity of the available cluster. The multiple available clusters are sorted from largest to smallest according to their capacity scores to obtain a sorting result. The batch build request is split into N sub-tasks. The number of allocable sub-tasks for the first-ranked available cluster in the sorting result is calculated, and the corresponding number of sub-tasks are allocated to the first-ranked available cluster. The remaining resources of the cluster and the number of sub-tasks to be allocated are updated until a termination condition is met. The termination condition includes: the number of sub-tasks to be allocated is 0, the available clusters have been traversed and the number of sub-tasks to be allocated is greater than 0, generating a resource shortage prompt message, which includes the type and quantity of the missing resources; or, the number of operation iterations reaches a preset maximum iteration threshold, terminating the allocation and generating an iteration timeout prompt message. The formula for determining the capacity score S is: S = 0.4A + 0.3B + 0.2C + 0.1D; Where A is the normalized value of the number of remaining CPU cores, B is the normalized value of available memory, C is the normalized value of storage space, and D is the normalized value of network bandwidth.

[0044] The method provided by this invention is based on capacity scoring, sorts available clusters in descending order of capacity, and prioritizes the allocation of subtasks to clusters with sufficient resources. This avoids the uneven load distribution problem of traditional random allocation, ensures balanced resource utilization in each cluster, and reduces build delays caused by single cluster overload. Furthermore, it specifies multiple termination conditions, which not only prevents infinite loops in the traditional allocation process, but also accurately indicates the gap type when resources are exhausted, helping operations and maintenance to quickly expand capacity. At the same time, it avoids system resource waste caused by excessive iterations, and improves the controllability and stability of batch allocation.

[0045] In some embodiments, the method provided by the present invention further includes, after S2 above: Each subtask is assigned a unique identifier and injected with execution context information, including cluster API credentials, image repository address, security group fingerprint, tenant ID, and timeout threshold. Cluster resources are locked using a distributed lock. N independent monitoring threads are started to receive subtask status via RabbitMQ, including initialization, resource locking, execution, success, or failure. A status cache table is established to store the status of each subtask, the execution node IP, and the elapsed time. This status cache table is used to generate the batch build result report.

[0046] The method provided by this invention ensures the traceability of each subtask's configuration by assigning a unique identifier and injecting context, avoiding confusion caused by traditional manual configuration entry and improving configuration consistency. Furthermore, it prevents multiple subtasks from competing for the same cluster resources through distributed locks, avoiding resource allocation conflicts caused by traditional lock-free mechanisms and reducing task failure rates. Finally, it provides real-time and accurate data support for result reports by receiving status through RabbitMQ and storing details in a status cache table via N independent monitoring threads, avoiding the delays and errors of traditional manual progress statistics and improving the transparency and manageability of batch builds.

[0047] S3. The subtasks are scheduled using a preset scheduling strategy, and the N subtasks are assigned to the target computing nodes in the corresponding clusters for execution.

[0048] Specifically, the scheduling strategies include a basic scheduling strategy based on minimum load priority and an advanced scheduling strategy based on anti-affinity.

[0049] Among them, see Figure 3 Based on the minimum load priority scheduling strategy, the algorithm uses Least Loaded First (LLF) to distribute the load as evenly as possible across nodes by calculating the load score of each node in real time. New tasks are preferentially assigned to the node with the lowest current load, preventing some nodes from being overloaded while others are idle, thus maximizing the utilization of resources across the entire system. Real-time load calculation further reduces the overall system performance degradation caused by single-node resource contention and avoids system latency due to waiting for newly assigned tasks. In this device, node CPU utilization, memory utilization, I / O utilization, network utilization, and GPU utilization are used as the basic data collected in real time. Weight values ​​are designed on these five types of basic data to comprehensively calculate the load score of each node in real time. The load scoring formula is: LoadScore = (0.4×CPU) + (0.3×Mem) + (0.15×IO) + (0.1×Net) + (0.05×GPU).

[0050] The advanced scheduling strategy based on anti-affinity is based on the anti-affinity scheduling (AAS) algorithm, a resource allocation strategy that forces critical service instances to be distributed across different object nodes. A single node failure only affects a limited area, avoiding a single point of failure impacting multiple instances. This effectively prevents interference between services with high resource loads, thereby improving the overall fault tolerance and availability of the system. The workflow of the advanced scheduling strategy is described in [link to documentation]. Figure 4When initiating a batch API creation request, anti-affinity rules are explicitly specified (e.g., by tags or group identifiers), and physical node topology discovery is implemented. Simultaneously, the scheduler monitors and maintains node status in real time. When creating cloud hosts in batches via API, request parsing and rule extraction are performed first. The scheduler receives the API request, parses the anti-affinity rules, and determines which instances need to be distributed. The scheduler filters nodes that meet the criteria from the "available node pool." If a node is already included in the affinity configuration, no new instances in the same group are allocated. Nodes in different fault domains are prioritized to ensure that instances in the same group are distributed across multiple fault domains. After candidate node filtering is complete, each cloud host instance is assigned to a selected node, and the allocation result is verified. This primarily includes checking if "instances in the same rule group are on the same node" and whether node resources are sufficient (e.g., whether CPU and memory meet instance specification requirements). If verification passes, instance creation is executed; if not (e.g., no suitable node is available), an error is returned or a retry mechanism is triggered. After an instance is created, the status tracker continuously monitors the health status of the node. If a node fails, the scheduler will automatically migrate the instance on that node to another available node to ensure service continuity.

[0051] In some embodiments, the configuration parameters further include subtask group identifiers and fault domain isolation requirements that need to be distributed among the N cloud hosts; the step of scheduling the subtasks using a preset scheduling strategy and allocating the N subtasks to the target computing nodes in the corresponding clusters for execution includes: For the target subtask, determine the topology information of all available computing nodes within the cluster corresponding to the target subtask. The topology information includes the fault domain identifier of the computing node and the number of subtasks already carried in the same group. Eliminate computing nodes already carrying subtasks in the same group, and retain computing nodes whose fault domains are different from those of the assigned subtasks, resulting in multiple candidate computing nodes. Determine the real-time load data of the multiple candidate computing nodes, including CPU utilization, memory utilization, I / O utilization, network utilization, and GPU utilization. The target subtask is any one of N subtasks. Standardize the real-time load data to obtain normalized values ​​for CPU utilization, memory utilization, I / O utilization, network utilization, and GPU utilization. Perform a weighted sum based on the normalized values ​​of CPU utilization, memory utilization, I / O utilization, network utilization, and GPU utilization to obtain a load score for each candidate computing node. Sort the load scores of each candidate computing node from smallest to largest, and select the candidate with the smallest load score. The compute node serves as the target compute node for the target subtask. The real-time resources of the target compute node are verified to meet the configuration requirements of the cloud host corresponding to the target subtask. If they do, the target subtask is assigned to the target compute node for execution. If not, the target compute node is removed, and the next compute node with the lowest load score is selected from the sorted compute nodes. This verification is repeated until a suitable target compute node for the target subtask is determined. If the load scores of all available compute nodes in the cluster corresponding to the target subtask exceed a preset safety threshold, the number of concurrent subtasks processed in the cluster corresponding to the target subtask is reduced, and unassigned subtasks are temporarily stored in the task queue. The remaining subtasks are re-executed when the load scores of available compute nodes in the cluster corresponding to the target subtask are less than the preset safety threshold. If all fault domains in the cluster corresponding to the target subtask are already carrying subtasks in the same group, a scheduling conflict warning is generated. This warning includes a list of occupied fault domains and identifiers of subtasks in the same group that can be released.

[0052] The method provided by this invention distributes subtasks that need to be deployed in a distributed manner to different fault domains by filtering out nodes in the same group and retaining nodes in different fault domains. This avoids the risks of traditional deployment in the same fault domain. Even if a node fails, it only affects a small number of cloud hosts in the same group, significantly improving system fault tolerance and service continuity. Furthermore, it accurately matches the computing needs of cloud hosts by calculating load scores and selects the node with the lowest load to avoid build failures caused by node overload and improve the utilization rate of computing node resources. Finally, when the load exceeds the threshold, it reduces concurrency and temporarily stores tasks to prevent the cluster from being paralyzed due to too many tasks. When scheduling conflicts occur, it prompts that fault domains are occupied and that subtasks can be released, reducing scheduling blocking time and ensuring a smooth batch build process.

[0053] S4. Monitor the execution status of all subtasks. Once all subtasks are completed, generate a batch build result report. The report includes success rate statistics, resource allocation details, and error diagnosis information. S5. If a subtask execution failure is detected, a resource rollback process is triggered to release the allocated invalid resources.

[0054] In some embodiments, S5 includes: When a subtask execution failure is detected, the resource allocation record of the subtask is obtained. The resource allocation record includes the number of locked CPU cores, memory size, storage space, virtual network interface identifier, and storage volume identifier. The failure type of the subtask is determined. If the failure type is resource allocation failure, the resource is released directly. If the failure type is execution timeout, the target cluster status query interface is first called to confirm whether there are any incomplete cloud host instances. If so, the instance is deleted through the cluster API.

[0055] The method provided by this invention directly releases resources in the event of allocation failure, avoiding invalid resource occupation; for execution timeouts, it first queries the cluster status to confirm the existence of incomplete instances before deletion, preventing instance residue caused by the traditional method of releasing resources upon timeout. Simultaneously, based on locked resource allocation records for CPU, memory, virtual network interfaces, etc., it ensures no resource omissions during rollback, avoiding resource fragmentation caused by incomplete rollbacks in traditional methods, and improving the cleanliness and reuse efficiency of cloud platform resources.

[0056] As described in S1-S5 above, the method provided by this invention firstly breaks down batch requests into N independent subtasks, and uses a scheduling strategy to achieve parallel processing, avoiding the accumulated time consumption of traditional serial operations and significantly improving the batch build speed. Secondly, through unified monitoring and reports including success rates and resource details, it ensures that the configuration of each cloud host meets user needs, eliminates configuration inconsistencies caused by manual intervention, and improves cluster stability. Finally, when a subtask fails, it triggers resource rollback, releasing allocated invalid resources, avoiding the problem of long-term resource idleness after traditional failures, and significantly improving the resource utilization of the cloud platform. In this way, the method provided by this invention can solve the problems of low batch deployment efficiency, inconsistent configuration, and poor fault tolerance in the prior art, and achieve efficient batch build and intelligent scheduling of cloud hosts.

[0057] The following example illustrates the method provided by an embodiment of the present invention.

[0058] For details, see Figure 5The batch cloud server construction process is designed as follows: Upon receiving a request to build cloud servers in batches, the task decomposition and scheduling module is invoked based on the "number of cloud servers" parameter in the request parameters (including the number of cloud servers to be built, the name of the cloud servers, and technical specifications such as CPU, memory, disk, image, and network). Creating N cloud servers in batches will be divided into N independent subtasks. Each independent subtask calls the cloud platform's API for creating a single cloud server to complete the construction task for that single cloud server. The task decomposition and scheduling module starts N threads to poll and monitor the N independent cloud server construction subtasks. When all subtasks have been completed, the result of building N cloud servers in batches is output.

[0059] Further, see Figure 6 The process of splitting batch construction tasks specifically includes: request reception and parameter parsing, target cluster determination and resource evaluation, intelligent capacity allocation and subtask generation, cyclic resource allocation and resource exhaustion handling, and subtask encapsulation and return.

[0060] Request Reception and Parameter Parsing: When the system receives a request to create cloud hosts in batches, it first verifies the completeness and validity of the request. The core task is to parse the JSON-formatted request body and extract key operation parameters, including the total number of hosts to be created (N), virtual machine specifications (such as the number of CPU cores and memory size), network topology requirements (such as VPC and subnet), storage type (system disk and data disk configuration), and optional target cluster specifications. This stage involves strict parameter validity verification to ensure that the number of hosts is within the system's allowed range (e.g., no more than 1000), the specifications conform to the types supported by the platform, and the network configuration exists and is available. If any parameter is found to be invalid or exceeds the limit, the process is immediately terminated and detailed error information is returned.

[0061] Target Cluster Determination and Resource Assessment: The system employs different resource discovery paths depending on whether the user explicitly specifies a target cluster. If a target cluster is specified, it directly locks onto that cluster and obtains its real-time resource status. If not specified, it queries all available clusters (those in normal operation and not under maintenance) and sorts them in descending order based on their comprehensive capacity score. The capacity score is calculated based on multiple dimensions: remaining CPU cores (weight 40%), available memory (weight 30%), storage space (weight 20%), and network bandwidth (weight 10%). The system prioritizes clusters with the largest capacity but excludes high-pressure clusters whose load has exceeded safety thresholds (e.g., CPU utilization > 80%) to ensure that new tasks do not degrade existing services.

[0062] Intelligent capacity allocation and subtask generation: Based on the selected target cluster, the system calculates the currently allocatable host capacity for that cluster. Capacity calculation is not a simple division operation, but rather takes into account virtual machine specification constraints: for example, when creating a host with 4 vCPUs / 8GB, it needs to check whether the cluster has sufficient CPU fragmentation (to avoid the remaining cores being scattered across multiple physical machines) and contiguous memory space. The actual allocation is the minimum of the "remaining demand" and the "cluster allocatable capacity," generating corresponding subtasks. Each subtask contains key metadata: target cluster UUID, number of hosts, resource reservation credentials (such as locking the number of CPU cores and the number of GB of memory), timeout settings (default 300 seconds), and task priority tags. Resource reservation uses a distributed lock mechanism to prevent other tasks from competing for the same resources.

[0063] Circular Allocation and Resource Exhaustion Handling: After the initial allocation, the remaining demand is updated (total demand minus allocated capacity). If the remaining demand is still greater than zero, the system automatically enters a circular allocation process: obtaining the next available cluster (sorted by capacity), and repeatedly performing capacity calculation and subtask generation. This loop continues until one of three termination conditions is met: all demand is satisfied (remaining demand = 0), available clusters are exhausted but demand is not satisfied (triggering a resource shortage error), or the system reaches its maximum iteration count (protection against infinite loops). In resource shortage scenarios, the system accurately calculates the shortfall and identifies which resource types (CPU / memory / storage) are causing bottlenecks, providing maintenance personnel with a basis for capacity expansion.

[0064] Subtask Encapsulation and Return: After all requests are successfully allocated, the system performs final encapsulation of the subtask queue. Each subtask is assigned a unique ID (format: st-<date>-<cluster code>-<sequence number>) and injected with execution context information, including dependent image repository addresses, security group rule fingerprints, and the tenant of the project it belongs to. The entire subtask queue is grouped and sorted by cluster, with tasks from the same cluster arranged consecutively to optimize subsequent scheduling efficiency. The final returned structured data includes a global task ID, total number of hosts, a list of subtasks, and a resource reservation summary report, providing a baseline framework for task tracking for the client. Any abnormal situation (such as partial cluster communication timeout) will trigger a compensation operation at this stage, releasing locked resources.

[0065] The task splitting strategy is primarily based on resource availability. Cloud servers implement splitting based on the dependencies between image, network, and storage volume components, as well as the scale of batch creation. The design includes resource availability-based splitting, dependency-based splitting, and scale-based dynamic splitting. Resource availability-based splitting is designed from three aspects: compute node load balancing, resource pool partitioning, and quota-aware splitting. Compute node load balancing distributes batch creation tasks to less loaded compute nodes based on their current load. Resource pool partitioning groups batch tasks according to the availability of resource pools (CPU, memory, storage), ensuring that each group of tasks does not exceed the capacity of a single resource pool. Quota-aware splitting, combined with tenant quota limits, splits large tasks into smaller task groups that do not exceed quota limits. Dependency-based splitting is designed from three aspects: image dependencies, network topology, and storage volumes. Image dependency grouping groups instance creation requests using the same image, reducing duplicate image transmissions. Network topology grouping groups instance creation requests with the same network configuration, optimizing network resource allocation. Storage volume grouping is based on storage backend type and volume size, optimizing storage resource allocation. The main design of scale-based dynamic splitting is to split a large number of tasks into subtasks of a fixed size, such as 50 instances each time.

[0066] See another example. Figure 7 The scheduling process for batch build tasks specifically includes: subtask queue triggering scheduling; load detection and branch processing; computing resource (worker) type judgment and task scheduling; execution of API calls and status code processing; task status polling and result determination; retry / transfer decision and dead letter queue.

[0067] Specifically, when there are tasks pending in the subtask queue, the scheduler core is triggered to initiate the task scheduling process. During load detection and branch processing, the scheduler core first detects the system load and handles it in different ways based on the detection results: if the load is too high, it performs dynamic degradation of concurrency to reduce the number of tasks processed simultaneously, thereby alleviating the load pressure; if the load is normal, it continues execution and obtains available workers to process the tasks. For worker type determination and task scheduling, after obtaining an available worker, it determines the worker's type: if the worker is suitable for handling small tasks, it prioritizes scheduling small tasks and assigns lightweight tasks to that worker; if scheduling fails (e.g., insufficient workers, exceptions), it performs task re-acquisition, re-acquiring workers or adjusting the scheduling strategy to attempt task reassignment. After task allocation, API calls and status code processing are executed, a task creation request is sent to the target service, and corresponding operations are performed based on different return results: If the task has been accepted and processed by the service, the task location is recorded, including its storage location or tracking identifier, for later retrieval; if the service is overloaded or temporarily unavailable, a backoff and retry strategy is implemented, using an exponential waiting mechanism to retry scheduling after a period of time. The task status is tracked in real time, continuously polled by a status tracker to query the actual execution result, and corresponding operations are performed based on the result: When the result is "Success," resource locks are released, freeing up system resources (such as memory and threads) occupied by the task to avoid resource waste; when the result is "Failed," the task is marked as "requiring rollback," preparing for rollback operations (such as undoing completed steps). Finally, based on the result status and business rules, the following processing is performed: In retryable scenarios, if the task fails but is due to a temporary error (such as network fluctuations), a retry / transfer decision is made, and the task is rescheduled in conjunction with an exponential waiting mechanism; In unrecoverable scenarios: if the task fails and cannot be repaired (such as a permanent error, or failure after multiple retries), the task is added to the dead letter queue and will no longer be automatically retried, and will be handled manually or through offline processes.

[0068] In one possible implementation, the method provided by the embodiments of the present invention further includes: Image files used for batch building of cloud hosts are stored in the image repository of each cluster, and the integrity of the image files is checked regularly. If a corrupted image file or a version update is found, the image file is re-cached. The image files include system images and application images. The virtualization environment of the compute nodes in each cluster is pre-initialized. For compute nodes driven by KVM, the KVM kernel module is pre-loaded and a default virtual network is created. For compute nodes driven by VMware, a connection session with vCenter is pre-established and vSAN storage policy is loaded to avoid repeated initialization operations when subtasks are executed. The cache hit rate of each image is counted in real time. Images with a hit rate lower than a preset hit rate threshold are automatically cleaned up and local storage resources are released. For compute nodes that have not carried subtasks for more than a preset time after initialization, the pre-initialized virtualization environment resources are released.

[0069] In one example, resource pre-configuration optimization is achieved through pre-stocking and rapid reuse. Frequently used virtual machine templates, system images, network configurations, and other information are cached in a resource pool. When creating a cloud host, there's no need to pull images from remote storage or rebuild templates in real time; instead, they are quickly copied directly from the resource pool, reducing I / O wait time. For frequently used compute nodes, the virtualization environment (such as KVM or Xen hypervisors) is pre-initialized to avoid time-consuming operations like repeatedly loading the kernel and drivers during creation.

[0070] The method provided by this invention stores images in a local cluster repository and pre-initializes the virtualization environment, avoiding remote IO waits and repeated initialization operations during each creation. This effectively shortens the creation time of a single cloud host, and the efficiency improvement is even more significant in batch scenarios. On the other hand, it provides real-time statistics on image cache hit rate and releases pre-initialized environments that have timed out and are not being used for tasks, preventing traditional local storage from being occupied by low-frequency images and idle environments. This ensures that storage resources prioritize high-frequency needs, improves local storage utilization, and reduces the consumption of computing node performance by invalid environments.

[0071] The foregoing mainly describes the solutions of the embodiments of the present invention from a methodological perspective. It is understood that, in order to achieve the above-mentioned functions, the construction apparatus 100 includes at least one of the hardware structures and software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of the present invention.

[0072] In this embodiment of the invention, the building device 100 can be divided into functional units according to the above method example. For example, the building device 100 can be divided into functional units corresponding to various functions, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this embodiment of the invention is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0073] For example, Figure 8 This diagram illustrates a hardware structure of a construction device according to an embodiment of the present invention. The construction device 100 includes: a request receiving module 110, used to receive a batch construction request for cloud hosts submitted by a user, the batch construction request requesting the construction of N cloud hosts, and the batch construction request carrying configuration information; a task splitting module 120, used to split the batch construction request into N sub-tasks according to the configuration information, and determine the cluster corresponding to each sub-task, each sub-task being used to build one cloud host in its corresponding cluster; a task scheduling module 130, used to schedule the sub-tasks using a preset scheduling strategy, allocating the N sub-tasks to target computing nodes in the corresponding clusters for execution, the scheduling strategy including a basic scheduling strategy based on minimum load priority and an advanced scheduling strategy based on anti-affinity; a task monitoring module 140, used to monitor the execution status of all sub-tasks, and generate a batch construction result report after all sub-tasks are completed, the report including success rate statistics, resource allocation details, and error diagnosis information; and a resource rollback module 150, used to trigger a resource rollback process and release allocated invalid resources if a sub-task execution failure is detected.

[0074] In one possible implementation, see Figure 9 The present invention also provides a build apparatus, which includes a client layer, an API service layer, a resource management layer, an infrastructure layer and a build support layer.

[0075] Specifically, the client layer includes a batch creation controller, a report generator, and a concurrency manager. The batch creation controller is the central coordinator for batch task execution, responsible for initializing the creation process, parsing input parameters (including host specifications, quantity, and deployment strategy), and monitoring the entire lifecycle status of the tasks. It shapes request traffic by calling the concurrency manager and synchronizes the operation status to the report generator in real time. When some tasks fail, it automatically triggers a resource rollback process to maintain system consistency. The report generator aggregates and analyzes the operation results and outputs them in a structured manner. It continuously collects task execution data (including host deployment metadata, error codes, and resource allocation details) and generates a technical report (the aforementioned batch build result report) containing success rate statistics, time distribution, and fine-grained error diagnosis. In rollback scenarios, it accurately identifies the set of resources to be released, providing the resource reclaimer with operational basis. The concurrency manager implements system-level flow control strategies, limiting API request rates through a configurable thread pool model and token bucket algorithm. By integrating an exponential backoff retry mechanism and circuit breaker strategy, it effectively addresses server-side rate limiting (HTTP 429) and temporary service unavailability (HTTP 503) scenarios, ensuring the stability of backend services.

[0076] Furthermore, the API service layer is designed with an authentication gateway, a resource verification engine, a virtual machine scheduler, and an asynchronous task processor. The authentication gateway, acting as the API access control layer, performs identity authentication and RBAC permission verification based on the OAuth 2.0 protocol. It verifies the validity of session tokens and the scope of operation permissions, establishes a security context, and injects audit logs. Once verification is successful, the request is routed to the downstream processing pipeline. The resource verification engine performs pre-deployed resource availability verification. It verifies the legality of computing specifications, image templates, and network configurations by querying the database in real time, while simultaneously assessing the remaining capacity (CPU / Memory / Storage) of the target physical cluster. If resource quotas are insufficient or configuration conflicts occur, the operation is terminated early, returning a traceable error code. The virtual machine scheduler implements resource scheduling decisions. Based on preset load balancing algorithms (such as minimum load priority) and affinity rules, it selects the optimal deployment location, comprehensively evaluates the host machine's real-time performance indicators (CPU utilization / memory fragmentation rate) and storage I / O characteristics, and generates executable deployment instructions to be submitted to the asynchronous task queue. The asynchronous task processor manages the lifecycle of long-cycle tasks, transforms operation requests into persistent task items, tracks task progress (Pending / Running / Success / Failed) through a database state machine, exposes a task query interface (GET / api-jobs / {uuid}), and triggers compensation operations when a task times out (TTL mechanism) or fails.

[0077] The infrastructure layer includes the KVM driver and the VMware driver. The KVM driver encapsulates the Libvirt virtualization platform operations, converting standardized virtual machine configurations into libvirt XML definition files. It manages virtual machine lifecycle operations (create / start / delete), handles storage volume allocation (qcow2 format), and virtual network binding (Linux Bridge / OVS), and executes host commands via SSH tunnels. The VMware driver integrates the vSphere SDK, enabling virtual machine deployment and management for ESXi clusters. It converts common configuration parameters into VMware-specific objects (VirtualMachineConfigSpec), operates the vCenter API through Managed Object References, and handles asynchronous task polling and vSAN storage policy application.

[0078] The support layer comprises a message queue, a database, and a configuration center. The message queue implements asynchronous communication between services based on the message queue protocol, using RabbitMQ as the message broker. It provides persistent queues, publisher confirmations, and dead-letter exchange (DLX) mechanisms to ensure the reachability of task status updates and alarm events. The database uses a relational data storage engine (MySQL) and employs the InnoDB transaction engine to maintain resource topology and task metadata. It guarantees resource state consistency through ACID transactions, provides low-latency queries (index optimization) for the resource verification engine, and supports point-in-time recovery (PITR) to meet auditing requirements. The configuration center implements distributed configuration management based on ZooKeeper, storing global parameters (default deployment policies, timeout thresholds), supporting runtime dynamic configuration updates (Watcher mechanism), providing policy rule injection for the scheduler, and providing platform-specific parameters (such as QEMU tuning flags) for the driver layer.

[0079] The resource management layer includes a rollback controller and a resource reclaimer. The rollback controller implements the compensation transaction logic, formulates resource release strategies based on error type (insufficient resources / configuration errors), and generates a sequence of deletion instructions ordered by resource dependency topology by analyzing the impact of failed tasks, ensuring that operations meet atomicity requirements. The resource reclaimer executes resource release operations, deleting virtual machines and related storage volumes by calling the infrastructure API (DELETE / vm-instances). It handles resource dependency decoupling (such as virtual network adapter unmounting), state synchronization, and operation verification, maintaining the eventual consistency of the resource inventory.

[0080] Furthermore, based on the above methods and architecture, in order to further improve the speed of batch creation of cloud hosts, this embodiment of the invention also provides optimization methods such as parallel processing, resource pre-allocation optimization, asynchronous processing and status tracking, intelligent scheduling, caching and localization acceleration, error handling and retry, and protocol and data optimization.

[0081] Specifically, the core of batch creation is multi-task parallel processing and concurrent execution, rather than serial execution. When a request to create 10 cloud hosts is submitted, the scheduler will simultaneously start multiple task threads to handle the creation process of each host (such as resource allocation, network configuration, and image loading). Compared to serial processing, parallel execution can reduce the total time from 10 times the time per host to nearly the sum of the time per host and the concurrency overhead, significantly improving overall efficiency.

[0082] Real-time API response is achieved through non-blocking asynchronous processing and state tracking. After a user initiates a batch creation request, the API immediately returns the task ID, rather than waiting for all hosts to complete creation. The background processes the creation process in parallel using asynchronous task queues (such as RabbitMQ and Kafka), allowing users to continue performing other operations without being blocked. A state tracker (such as the "State Tracker" step in the flowchart) provides real-time status feedback, allowing users to check the creation progress at any time via task ID (e.g., nodes allocated, image loading, startup), eliminating the need for frequent API polling and reducing interaction latency.

[0083] Intelligent scheduling quickly matches optimal nodes. It enables load detection and prediction, with the scheduler monitoring the CPU, memory, and disk I / O resource usage of computing nodes in real time. Algorithms (such as LLF and AAS) rapidly filter out nodes with sufficient resources that meet constraints (such as anti-affinity and affinity requirements). Compared to manual node selection, intelligent scheduling can complete node matching in milliseconds, avoiding user waiting. If a node suddenly fails (e.g., hardware damage), the scheduler immediately selects a replacement node from the backup node pool without manual intervention, reducing task interruption time and achieving rapid fault domain switching.

[0084] Local acceleration is achieved through metadata caching and network configuration caching. Metadata (such as size, format, and checksum) of virtual machine templates and images is cached locally, and the cache is read directly during creation, avoiding repeated access to remote storage (such as Ceph or NFS). Commonly used network configurations (such as VLANs, security groups, and IP address pools) are pre-loaded into memory and applied directly when creating cloud hosts, reducing the time spent on network configuration.

[0085] Error handling and retries are implemented through rapid failure detection and fault recovery. If an irreversible error occurs during the creation of a host (such as image corruption or node resource exhaustion), the scheduler will immediately terminate the task and return an error message to the user, avoiding meaningless waiting. For temporary errors (such as network jitter or temporary node busy), the scheduler will automatically retry (such as the "exponential waiting" mechanism in the flowchart), with gradually increasing retry intervals (e.g., waiting 1 second the first time, 2 seconds the second time), which reduces the impact on the system while ensuring that the task is eventually completed.

[0086] Protocol and data optimizations are achieved through efficient serialization and connection reuse. Binary serialization formats such as Protocol Buffers are used instead of JSON to reduce the data size of API requests / responses and lower network transmission time. Connection reuse between clients and servers is implemented using protocols such as HTTP / 2 or gRPC, avoiding the overhead of establishing a new connection for each request.

[0087] It should be understood that specific descriptions of the above-mentioned optional methods can be found in the foregoing method embodiments, and will not be repeated here. Furthermore, explanations of any of the above-provided construction apparatus 100 and descriptions of its beneficial effects can be found in the corresponding method embodiments, and will not be repeated here.

[0088] This invention also provides a computer-readable storage medium storing at least one computer instruction, which is loaded and executed by a processor to implement the methods of the various embodiments described above. Explanations of the relevant content and descriptions of the beneficial effects of any of the computer-readable storage media provided above can be found in the corresponding embodiments described above, and will not be repeated here.

[0089] This invention also provides a chip. This chip integrates a control circuit for implementing the functions of the aforementioned construction apparatus 100 and one or more ports. Optionally, the functions supported by this chip are as described above and will not be repeated here.

[0090] Those skilled in the art will understand that the program for implementing all or part of the steps of the above embodiments, which can be executed by a program instructing related hardware, can be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a random access memory, etc. The processing unit or processor mentioned above can be a central processing unit, a general-purpose processor, an application-specific integrated circuit (ASIC), a microprocessor (DSP), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

[0091] It should be noted that the devices for storing computer instructions or computer programs provided in the embodiments of the present invention, such as, but not limited to, the aforementioned memory, computer-readable storage medium, and communication chip, are all non-transitory. Those skilled in the art should recognize that the functions described in the embodiments of the present invention in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable storage medium or transmitted as one or more instructions or code on a computer-readable storage medium. Computer-readable storage media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of computer programs from one place to another. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0092] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A cloud host batch rapid construction method oriented to user needs, characterized in that, The method comprises: receiving a user-submitted cloud host batch construction request, the batch construction request being used to request the construction of N cloud hosts, and the batch construction request carrying configuration information; performing task splitting on the batch construction request according to the configuration information, splitting the batch construction request into N subtasks, and determining the cluster corresponding to each subtask, each subtask being used to construct one cloud host in the corresponding cluster; scheduling the subtasks by using a preset scheduling strategy, and distributing the N subtasks to target computing nodes in the corresponding cluster for execution, the scheduling strategy comprising a basic scheduling strategy based on minimum load priority and an advanced scheduling strategy based on anti-affinity; monitoring the execution status of all subtasks, and generating a batch construction result report after all subtasks are completed, the report comprising success rate statistics, resource allocation details and error diagnosis information; if a subtask execution failure is detected, triggering a resource rollback process to release invalid allocated resources.

2. The method of claim 1, wherein, The task splitting on the batch construction request according to the configuration information, splitting the batch construction request into N subtasks, and determining the cluster corresponding to each subtask comprise: extracting configuration parameters from the batch construction request, the configuration parameters comprising the specification configuration, network parameters, storage configuration and deployment strategy information of each of the N cloud hosts, the deployment strategy information being used to represent whether the N cloud hosts are specified target clusters; in the case where the N cloud hosts are specified target clusters, obtaining the real-time resource capacity of the target cluster, the real-time resource capacity comprising the target cluster's CPU remaining core number, available memory, storage space and available network bandwidth; verifying whether the real-time resource capacity of the target cluster meets the total resource demand of the N cloud hosts; in the case where the target cluster's CPU remaining core number is greater than or equal to the CPU core number demand of the N cloud hosts, the target cluster's available memory is greater than or equal to the memory demand of the N cloud hosts, the target cluster's storage space is greater than or equal to the storage demand of the N cloud hosts, and the target cluster's available network bandwidth is greater than or equal to the network bandwidth demand of the N cloud hosts, splitting the batch construction request into N subtasks, and determining the cluster corresponding to each subtask as the target cluster; in the case where the target cluster's CPU remaining core number is less than the CPU core number demand of the N cloud hosts, the target cluster's available memory is less than the memory demand of the N cloud hosts, the target cluster's storage space is less than the storage demand of the N cloud hosts, or the target cluster's available network bandwidth is less than the network bandwidth demand of the N cloud hosts, generating resource shortage prompt information for prompting the target cluster, the prompt information comprising the type and quantity of the missing resources.

3. The method of claim 2, wherein, The task splitting on the batch construction request according to the configuration information, splitting the batch construction request into N subtasks, and determining the cluster corresponding to each subtask further comprise: In the case that the N cloud hosts do not specify a target cluster, real-time resource capacities of a plurality of available clusters are obtained, the real-time resource capacities including CPU remaining core numbers, available memories, storage spaces and network bandwidths of the available clusters; A capacity score of each of the available clusters is determined according to the real-time resource capacities of the plurality of available clusters, wherein the capacity score is positively correlated with the resource capacity of the available cluster; The plurality of available clusters are sorted in descending order according to the capacity scores to obtain a sorting result; The batch construction request is split into N subtasks; A number of allocable subtasks of an available cluster ranked first in the sorting result is calculated, and a corresponding number of subtasks are allocated to the available cluster ranked first, and the remaining resources of the cluster and the number of subtasks to be allocated are updated until a termination condition is met, the termination condition including that the number of subtasks to be allocated is 0, the available cluster has been completely traversed and the number of subtasks to be allocated is greater than 0, a resource shortage prompt information is generated, the prompt information including the type and number of the shortage resources, or the number of iterations of operations reaches a preset maximum iteration threshold, the allocation is terminated and an iteration timeout prompt information is generated; The determination formula of the capacity score S is: S=0.4A+0.3B+0.2C+0.1D; wherein A is a normalized value of the CPU remaining core number, B is a normalized value of the available memory, C is a normalized value of the storage space, and D is a normalized value of the network bandwidth.

4. The method of claim 3, wherein, The configuration parameters further include a subtask grouping identifier and a fault domain isolation requirement of the N cloud hosts to be distributedly deployed; The N subtasks are allocated to target computing nodes in the corresponding clusters for execution by using a preset scheduling strategy, including: For a target subtask, topology information of all available computing nodes in the cluster corresponding to the target subtask is determined, the topology information including a fault domain identifier to which the computing node belongs and a number of carried same-grouping subtasks; The computing nodes carrying the same-grouping subtasks are eliminated, and computing nodes different from the fault domain to which the allocated same-grouping subtasks belong are retained to obtain a plurality of candidate computing nodes; Real-time load data of the plurality of candidate computing nodes is determined, the real-time load data including CPU usage, memory usage, I / O usage, network usage and GPU usage of the computing nodes, and the target subtask is any one of the N subtasks; The real-time load data is standardized to obtain normalized values of the CPU usage, the memory usage, the I / O usage, the network usage and the GPU usage; A load score of each candidate computing node is obtained by weighted summation according to the normalized values of the CPU usage, the memory usage, the I / O usage, the network usage and the GPU usage; The load scores of the candidate computing nodes are sorted in ascending order, and a candidate computing node with the smallest load score is selected as a target computing node of the target subtask. checking whether real-time resources of the target computing node meet the specification configuration requirement of the cloud host corresponding to the target subtask; if yes, assigning the target subtask to the target computing node for execution; if no, eliminating the target computing node, reselecting the next computing node with the minimum load score from the sorted computing nodes, and repeating the checking until a target computing node suitable for the target subtask is determined; if the load scores of all available computing nodes in the cluster corresponding to the target subtask exceed the preset safety threshold, reducing the number of concurrent subtasks of the cluster corresponding to the target subtask, and temporarily storing the unassigned subtasks in a task queue; and when the load scores of the available computing nodes in the cluster corresponding to the target subtask are less than the preset safety threshold, re-executing the scheduling of the remaining subtasks; if all the failure domains in the cluster corresponding to the target subtask have already carried the same-group subtasks, generating a scheduling conflict prompt information, the scheduling conflict prompt information including an occupied failure domain list and an identifiable same-group subtask that can be released.

5. The method of claim 4, wherein, If the subtask execution fails, a resource rollback process is triggered to release the invalid resources that have been allocated, including: When the subtask execution fails, the resource allocation record of the subtask is obtained, the resource allocation record including the number of locked CPU cores, memory size, storage space, virtual network interface identifier and storage volume identifier; The subtask failure type is determined. If the failure type is resource allocation failure, the resource release is directly executed. If the failure type is execution timeout, the target cluster state query interface is called to determine whether there is an unfinished cloud host instance. If there is, the instance is deleted through the cluster API.

6. The method of claim 5, wherein, After the batch construction request is split into N subtasks according to the configuration information, the method further includes: allocating a unique identifier and injecting execution context information for each subtask, the execution context information including cluster API credentials, image repository address, security group fingerprint, tenant ID and timeout threshold; locking the cluster resources through a distributed lock; starting N independent monitoring threads to receive subtask states through RabbitMQ, the subtask states including initialization, resource locking, execution, success or failure; establishing a state cache table to store the state, execution node IP and elapsed time of each subtask, the state cache table being used to generate the batch construction result report.

7. The method of claim 6, wherein, The method further includes: storing the image files for cloud host batch construction into the image repository of each cluster, and periodically checking the integrity of the image files; in the case of finding that the image files are damaged or updated in version, the image files are rebuffered, the image files including system image and application image; The virtualization environment is pre-initialized for each computing node in the cluster, wherein for a KVM-driven computing node, a KVM kernel module is pre-loaded and a default virtual network is created; for a VMware-driven computing node, a connection session with a vCenter is pre-established and a vSAN storage strategy is pre-loaded, so as to avoid repeated initialization operations during execution of a subtask; The cache hit rate of each image is counted in real time, and the images with a hit rate lower than a preset hit rate threshold are automatically cleaned to release local storage resources; the pre-initialized virtualization environment resources of a computing node that has not carried a subtask for more than a preset time length are released.

8. A cloud host batch rapid construction device oriented to user requirements, characterized in that, The apparatus comprises: The request receiving module is configured to receive a batch construction request of a cloud host submitted by a user, wherein the batch construction request is used to request to construct N cloud hosts, and the batch construction request carries configuration information; The task splitting module is configured to perform task splitting on the batch construction request according to the configuration information, split the batch construction request into N subtasks, and determine a corresponding cluster for each subtask, wherein each subtask is used to construct one cloud host for the corresponding cluster; The task scheduling module is configured to schedule the subtasks by using a preset scheduling strategy, and distribute the N subtasks to target computing nodes in the corresponding clusters for execution, wherein the scheduling strategy comprises a basic scheduling strategy based on minimum load priority and an advanced scheduling strategy based on anti-affinity. The task monitoring module is configured to monitor the execution state of all subtasks, and generate a batch construction result report after all subtasks are completed, wherein the report comprises success rate statistics, resource allocation details, and error diagnosis information. The resource rollback module is configured to trigger a resource rollback process to release invalid resources that have been allocated if it is detected that a subtask fails to execute.

9. An electronic device comprising a processor; a memory for storing processor-executable instructions; wherein, The processor is configured to execute the instructions to implement the cloud host batch rapid construction method for user requirements according to any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, the computer-readable storage medium comprising: When the computer program is executed by the processor, the cloud host batch rapid construction method for user requirements according to any one of claims 1-7 is implemented.

Images