Application deployment method and device and storage medium

Abstract

The invention discloses an application deployment method and device and a storage medium. The method comprises the following steps: acquiring network cloud resource configuration related data, including interface communication information and configuration parameter information of each cloud management platform and each network management platform; communication connection is established based on interface communication information, an API interface is called to complete collaborative opening configuration of cloud resources and network resources, and collaborative intercommunication of equipment at two ends is realized through uniform parameter distribution in cross-domain boundary configuration; acquiring application deployment related data including application mirror image information, application classification and a resource scheduling strategy; based on the application classification matching resource demand recommendation value, in combination with a resource scheduling strategy and network cloud resource state data collected in real time, target resources matched with the application mirror image information are determined, and the target resources are used for application deployment. According to the invention, collaborative configuration and intelligent resource selection of cross-domain cloud network resources are realized, the application deployment process is simplified, and the resource utilization rate and the deployment success rate are improved.

Description

An application deployment method, device, and storage medium Technical Field

[0001] This application relates to the fields of cloud computing and network communication technology, specifically to an application deployment method, device, and storage medium. Background Technology

[0002] With the rapid development of cloud computing and network convergence technologies, the widespread adoption of hybrid cloud and edge computing architectures has made it a trend for enterprises to deploy businesses across data centers and cloud platforms. This has created an increasingly urgent need for the collaborative configuration, efficient scheduling, and elastic support of heterogeneous resources (including network resources and cloud resources, collectively referred to as network-cloud resources).

[0003] However, in actual enterprise applications, the configuration and management of network resources and cloud resources are often separated. Specifically, operations and maintenance personnel need to operate separately through network management platforms and cloud management platforms: first, apply for cloud resources such as computing and storage, and then configure network connections. In complex scenarios spanning data centers or backbone networks, network configuration often involves multiple management domains, requiring offline negotiation of network parameters and manual adaptation of devices from multiple vendors. The configuration process is cumbersome and prone to network conflicts or connectivity failures due to inconsistent parameters. After resources are activated, existing technologies typically require operations and maintenance personnel to manually configure the application deployment environment through remote login, failing to achieve automated integration of resource activation and application deployment. Furthermore, resource scheduling relies heavily on static policies, making it difficult to dynamically respond to fluctuations in business traffic, resulting in low resource utilization and high operation and maintenance costs.

[0004] Therefore, how to improve the efficiency, success rate, and intelligent level of resource adaptation in application deployment is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides an application deployment method, device, and storage medium to achieve efficient cross-domain collaborative configuration of cloud resources and intelligent application deployment.

[0006] To achieve the above-mentioned objectives, this application adopts the following technical solution:

[0007] Firstly, an application deployment method is provided, applied to a management server, wherein the management server is used to manage multiple cloud management platforms and multiple network management platforms in a data center and backbone network, the method comprising:

[0008] Obtain cloud resource configuration related data, which includes interface communication information of each cloud management platform and network management platform, as well as configuration parameter information generated according to user configuration requirements. The configuration parameter information includes data center internal configuration parameters, backbone network internal configuration parameters, and cross-domain boundary configuration parameters.

[0009] Based on the interface communication information, a communication connection is established between the management server and the multiple cloud management platforms and the multiple network management platforms. According to the configuration parameter information, the API interface of the corresponding platform is called to complete the collaborative activation configuration of cloud resources and network resources. The configuration includes data center internal configuration, backbone network internal configuration and cross-domain boundary configuration. The cross-domain boundary configuration realizes the collaborative interoperability of the two-end devices through the unified cross-domain boundary configuration parameter allocation.

[0010] Obtain application deployment-related data submitted by the user, including application image information, application classification, and resource scheduling strategy;

[0011] Based on the application classification and matching resource requirement recommendation value, and according to the resource requirement recommendation value, resource scheduling strategy and real-time collected cloud resource status data, a target resource matching the application image information is determined. The target resource is used to deploy the application to enable normal external service.

[0012] According to certain implementations of the first aspect, the step of determining the target resources for application deployment based on the application classification matching resource requirement recommendation value, the resource scheduling strategy, and real-time collected cloud resource status data specifically includes:

[0013] Based on the application classification, the recommended resource requirement values ​​for the application are matched from the preset demand measurement model table;

[0014] Candidate resource clusters are selected from all NetCloud resource clusters based on the resource requirement recommendation values;

[0015] For all candidate resource clusters, scores are assigned based on the configured resource scheduling policy, and the candidate resource cluster with the highest score is selected as the target resource for application deployment.

[0016] According to certain embodiments of the first aspect, the step of matching recommended resource requirement values ​​for an application from a preset demand measurement model table based on the application classification specifically includes:

[0017] The minimum requirements for CPU, memory, and storage resources for each application are determined by classifying the applications.

[0018] The refined resource requirements of an application are identified by the application tags under the application category, and the corresponding refined resource requirement suggestion values ​​are matched.

[0019] By combining the minimum requirement standard and the refined resource requirement recommendation value, a recommended value for the application's resource requirements is formed.

[0020] According to certain implementations of the first aspect, the resource scheduling strategy includes at least one of a load-aware scheduling strategy, an SLA-aware scheduling strategy, a cost-aware scheduling strategy, and an energy-aware scheduling strategy. The value of each resource scheduling strategy is calculated as follows:

[0021] The value of the load-aware scheduling strategy is obtained based on the ratio of the actual number of idle nodes in the candidate resource cluster to the preset idle node baseline value.

[0022] The value of the SLA-aware scheduling strategy is obtained based on the ratio of the actual network bandwidth within the candidate resource cluster to the preset bandwidth baseline value.

[0023] The value of the cost-aware scheduling strategy is determined based on the ratio of the actual resource price of the candidate resource cluster to the preset highest price benchmark value.

[0024] The value of the energy consumption sensing scheduling strategy is obtained based on the ratio of the actual energy consumption of the resource to the preset maximum energy consumption benchmark value.

[0025] According to certain implementations of the first aspect, after selecting the candidate resource cluster with the highest score as the target resource for application deployment, the method further includes: performing an adaptation verification on the selected target resource cluster to verify whether the cluster conforms to the specified deployment rules; if the verification passes, the cluster is determined to be the final target resource; if the verification fails, the cluster is removed, and the cluster with the second highest score among the candidate resource clusters is selected for re-verification until the verification passes.

[0026] According to certain embodiments of the first aspect, the configuration parameter information is obtained by dragging and dropping elements in a visual blueprint interface;

[0027] The application deployment-related data is selected or determined through the visual blueprint interface.

[0028] According to certain embodiments of the first aspect, the data center includes at least one cluster, each cluster includes at least one virtual machine, and each virtual machine has at least one business application container instance deployed on it; the method further includes:

[0029] Adjust the number of business application container instances deployed on virtual machines based on real-time monitored business traffic data and resource utilization data.

[0030] If the number of the business application container instances reaches the maximum configurable number of containers, a first virtual machine is created and added to the cluster. The first virtual machine has the same specifications, image, network, and subnet as the existing virtual machines in the cluster.

[0031] If the number of virtual machines in the cluster reaches the maximum configurable number of virtual machine nodes in the cluster, a second virtual machine is created and a new cluster is created using the second virtual machine as the master node. The second virtual machine has the same specifications, image, network, and subnet as the existing virtual machines in the existing cluster.

[0032] According to certain embodiments of the first aspect, the data center includes at least one cluster, each cluster includes at least one virtual machine, and each virtual machine has at least one business application container instance deployed on it; the method further includes:

[0033] Based on real-time monitored business traffic data and resource utilization data, once it is determined that the number of business application requests has decreased and the CPU or memory utilization of the business application container instance is lower than a set value, the business application container instance is deleted.

[0034] If the number of business application container instances deployed on a virtual machine drops to 0, delete the virtual machine.

[0035] If the number of virtual machines in the cluster drops to 0, delete the cluster.

[0036] Secondly, an application deployment device is provided, which serves as a management server. The management server is used to manage multiple cloud management platforms and multiple network management platforms. The application deployment device includes:

[0037] The resource data acquisition module is used to acquire cloud resource configuration related data. The cloud resource configuration related data includes interface communication information of each cloud management platform and network management platform, as well as configuration parameter information generated according to user configuration requirements. The configuration parameter information includes data center internal configuration parameters, backbone network internal configuration parameters, and cross-domain boundary configuration parameters.

[0038] The resource configuration module is used to establish a communication connection between the management server and the multiple cloud management platforms and the multiple network management platforms based on the interface communication information, and to call the API interface of the corresponding platform according to the configuration parameter information to complete the collaborative activation configuration of cloud resources and network resources. The configuration includes data center internal configuration, backbone network internal configuration and cross-domain boundary configuration. The cross-domain boundary configuration achieves collaborative interoperability between the two devices through unified cross-domain boundary configuration parameter allocation.

[0039] The application deployment data acquisition module is used to acquire application deployment-related data submitted by users, including application image information, application classification, and resource scheduling strategies.

[0040] The target resource determination module is used to match the recommended resource requirements based on the application classification, and determine the target resources that match the application image information according to the recommended resource requirements, resource scheduling strategy and real-time collected cloud resource status data. The target resources are used to deploy the application to enable normal external business services.

[0041] Thirdly, this application also provides an electronic device, including: one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the programs, when executed by the processors, implement the application deployment method as described in the first aspect.

[0042] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the application deployment method as described in the first aspect.

[0043] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the application deployment method as described in the first aspect.

[0044] Beneficial effects:

[0045] This application manages multiple cloud management platforms and network management platforms in the data center and backbone network through a unified management server. It automatically establishes connections and calls API interfaces based on interface communication information, enabling collaborative provisioning and configuration of cloud and network resources. Since cross-domain boundary configuration achieves interoperability between devices at both ends through unified cross-domain boundary configuration parameter allocation, it eliminates the need for manual offline negotiation and adaptation of devices from multiple vendors, effectively avoiding connectivity failures caused by parameter inconsistencies and significantly improving the efficiency and accuracy of cross-domain configuration. Building upon the collaborative configuration of cloud and network resources, it further matches recommended resource requirements based on application categories and automatically determines target resources matching the application image information by combining real-time collected cloud and network resource status data. Because this target resource can be directly used for application deployment, it achieves automated connection between resource provisioning and application deployment, eliminating the need for operations personnel to remotely log in and manually configure the deployment environment. Therefore, it effectively reduces operational complexity and labor costs during application deployment. Furthermore, this application incorporates real-time collected cloud resource status data when determining target resources, enabling the perception of dynamic information such as the load status of each node, network bandwidth usage, and latency. Each deployment selects the optimal target resource, effectively avoiding overloaded nodes and congested links, achieving dynamic response to business traffic, and improving overall resource utilization. Attached Figure Description

[0046] Figure 1 is a schematic diagram of the application scenario of the application deployment method provided in this application;

[0047] Figure 2 is a flowchart of the application deployment method provided in this application;

[0048] Figure 3 is a block diagram of the application deployment system provided in this application;

[0049] Figure 4 is a flowchart of the application deployment system provided in this application;

[0050] Figure 5 is a structural block diagram of the application deployment device provided in this application. Detailed Implementation

[0051] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0052] As enterprise business deployments across data centers and cloud platforms become increasingly common, the application deployment process faces numerous challenges. Traditionally, deploying a cross-domain application involves several fragmented steps: first, applying for cloud resources such as virtual machines on the cloud management platform; then, configuring network connections on the network management platform; and in cross-domain scenarios, negotiating network parameters offline and manually adapting to devices from multiple vendors; finally, manually configuring the application environment remotely after resource activation. This process is not only cumbersome and inefficient but also prone to deployment failures due to inconsistent configurations. Furthermore, resource scheduling relies heavily on static policies, making dynamic adjustments based on business traffic difficult, resulting in low resource utilization. Therefore, this application provides an application deployment method that uses a management server to uniformly manage multiple cloud management platforms and network management platforms within the data center and backbone network. This automatically completes the collaborative configuration of cloud and network resources before application deployment and intelligently matches target resources based on real-time status, thereby achieving application deployment and improving the automation level and resource utilization efficiency of application deployment.

[0053] Figure 1 shows a typical network topology for enterprise-level cross-data center network interconnection, including a management server, Data Center 1, backbone network, and Data Center 2. On the data center side, Data Center 1 adopts a Leaf-Spine Layer 2 / 3 network architecture (Leaf1, Spine, Border1), and Data Center 2 includes Border3 egress devices. Data Center 1 and Data Center 2 also include servers, cloud management platforms, and DCN network controllers (the network management platform for data centers). The backbone network includes PE1 / PE2 (Provider Edge, carrier edge routers), P1 / P2 (Provider, core routers), and the backbone network controller (the network management platform for the backbone network), which is a typical carrier backbone network interconnection topology and is responsible for carrying traffic forwarding between the two data centers. The backbone network and data center networks are connected to the Border devices through PE devices. The management server connects all devices through MGMT_Switch (management switch) with a dashed management link to achieve unified operation and maintenance management across data centers and backbone networks.

[0054] The application deployment method of this application is applied to a management server. In this application, the management server is used to manage multiple cloud management platforms and multiple network management platforms in the data center and backbone network. Referring to Figure 2, the method includes the following steps:

[0055] Step S101: Obtain cloud resource configuration related data. The cloud resource configuration related data includes interface communication information of each cloud management platform and network management platform, as well as configuration parameter information generated according to user configuration requirements. The configuration parameter information includes internal data center configuration parameters, internal backbone network configuration parameters, and cross-domain boundary configuration parameters.

[0056] Interface communication information refers to the information required for the management server to interact with various cloud management platforms and network management platforms, including but not limited to API access addresses, authentication credentials (such as API keys and tokens), supported protocol types (such as RESTful and gRPC), and data formats. This information is the foundation for establishing communication connections.

[0057] Configuration parameters are specific resource configuration parameters determined by the user based on their needs. These are further subdivided into data center internal configuration parameters, backbone network internal configuration parameters, and cross-domain boundary configuration parameters. Data center internal configuration parameters relate to the configuration of cloud resources within the data center, while backbone network internal configuration parameters relate to the configuration of backbone network resources, such as bandwidth and routing protocols. Cross-domain boundary configuration parameters are used to achieve interconnection and interoperability between different domains (such as between a data center and the backbone network, or between different data centers). These parameters are uniformly allocated to ensure that devices at both ends can work collaboratively.

[0058] Specifically, the configuration parameters within the data center include the hostname, availability domain, specifications, image, and associated network, subnet, and security group for virtual machines. The configuration parameters within the backbone network include the latency, bandwidth, and hop count of the link between the originating and ending physical exponents (PEs) of the backbone network. The cross-domain boundary configuration parameters between the data center and the backbone network include the interface name, sub-interface number, and sub-interface IP. The interface name corresponds to the physical port of the network device, and the sub-interface number is the logical interface assigned to the physical port. Each sub-interface can be configured with a separate IP. An interface with sub-interfaces is also called a main interface, and one main interface can correspond to multiple sub-interfaces.

[0059] For example, in the topology shown in Figure 1, the parameter configuration logic on the Border is as follows: Main Interface Name: The name of the Border-side interface used to connect to the PE, obtained based on the actual physical connection; Sub-interface Number: VLAN ID. If the external network is newly created, the value is 1~4096; if it is an existing network, the value is the VLAN ID of the existing external network; Sub-interface IP: The IP configured for the sub-interface. The parameter configuration logic on the PE is as follows: Main Interface Name and Sub-interface Number are consistent with the Border configuration; the Sub-interface IP is filled with an IP address in the same network segment as in the Border configuration. This application simplifies the collaborative configuration between the data center and the backbone network to three parameters: interface name, sub-interface number, and sub-interface IP, and automatically assigns consistent sub-interface numbers and IP addresses in the same network segment to both ends of the device, achieving extremely simplified management of cross-domain boundary configuration.

[0060] Step S102: Based on the interface communication information, establish communication connections between the management server and the multiple cloud management platforms and the multiple network management platforms. Call the corresponding platform's API interface according to the configuration parameter information to complete the collaborative activation configuration of cloud resources and network resources. The configuration includes data center internal configuration, backbone network internal configuration, and cross-domain boundary configuration. The cross-domain boundary configuration achieves collaborative interoperability between the two ends of the device through a unified cross-domain boundary configuration parameter allocation.

[0061] The management server establishes connections with each platform using secure protocols such as HTTPS based on the API address and authentication credentials in the interface communication information, ensuring the security and reliability of subsequent API calls.

[0062] The management server converts configuration parameter information into API requests recognizable by each platform, and calls the interfaces of the cloud management platform and network management platform respectively to complete resource creation, modification and other operations. For example, based on the virtual machine parameters obtained in step S101, it calls the API interface for creating virtual machines to create and start virtual machines. Based on the network parameters obtained in step S101, it calls the interfaces of the data center network controller and backbone network controller respectively to create the backbone network virtual network and tunnel. The data center network controller configures the Border device, and completes the IP binding and VRF OSPF configuration of the sub-interface through the main interface name, sub-interface number and sub-interface IP. After the sub-interface is configured with a valid IP, it can communicate directly with IP targets in the same network segment. The backbone network controller configures the PE device, and configures the PE access point for the virtual network service through the main interface name, sub-interface number and sub-interface IP, so that the PE access point can communicate with the sub-interface of the Border device using IPs in the same network segment. Referring to the topology example in Figure 1, the backbone network controller calls the interface to create network tunnels between different PE access points, thereby opening up the DCI network channel between the virtual machine in data center 1, Border1, PE1, PE4, Border3, and the virtual machine in data center 2. This eliminates the need for remotely logging into network devices to execute commands and shields the heterogeneity of devices from different manufacturers and models, as well as the complexity of user operations.

[0063] Collaborative provisioning configuration refers to the fact that the configuration of cloud resources and network resources are not isolated but coordinated. For example, when creating a virtual machine, it needs to be added to a specific network domain, and the network configuration (such as bandwidth and routing) needs to match the network attributes of that virtual machine. This application ensures the consistency of cloud-side and network-side configurations through unified scheduling by a management server.

[0064] For cross-domain configuration, the management server simultaneously sends the same set of cross-domain boundary parameters to both ends of the device (such as the data center gateway and the backbone network edge router), and configures them separately through API calls, thereby achieving automatic collaboration and interoperability between the two ends of the device, avoiding parameter inconsistencies caused by manual offline negotiation and manual adaptation.

[0065] Step S103: Obtain application deployment-related data submitted by the user. The application deployment-related data includes application image information, application classification, and resource scheduling strategy.

[0066] Application image information includes information about the image file into which the application is packaged, such as the name, version, and repository address of the Docker image, as well as the environment requirements for the image to run (such as operating system type, kernel version, dependent libraries, etc.).

[0067] Application categorization is used to identify the type of application. For example, application categorization includes, but is not limited to, AI applications, big data applications, and general applications. Applications in different categories typically have different resource requirements. For instance, AI applications indicate that the application is CPU-intensive, big data applications indicate that the application is I / O or storage-intensive, and general applications indicate that the application has no particular resource preferences. Application categories can be further subdivided into different application tags to differentiate the more refined resource requirements of each application. Application tags include scenario dimensions and technical dimensions. Scenario dimension tags include, but are not limited to, intelligent operation and maintenance, fault handling, facial recognition, image recognition, industrial quality inspection, and industrial production. Technical dimension tags include, but are not limited to, deep learning, neural networks, model inference, convolutional computation, Yolov5s, and VGG-16. For example, an image recognition application tag indicates that the application has GPU and bandwidth requirements.

[0068] Resource scheduling strategies include user-specified policies to guide the selection of target resources, such as prioritizing low-load nodes, ensuring low network latency, reducing costs, and considering energy consumption. These strategies will influence the final resource decision.

[0069] Step S104: Based on the application classification and matching resource requirement recommendation value, and according to the resource requirement recommendation value, resource scheduling strategy, and real-time collected cloud resource status data, determine the target resource that matches the application image information. The target resource is used to deploy the application to enable normal external service.

[0070] Recommended resource requirements are baseline values ​​pre-configured or dynamically calculated based on application categories. These requirements include CPU, GPU, memory, disk, and bandwidth. For example, AI applications are recommended to have a minimum of 8 CPU cores and 16GB of memory, while big data applications are recommended to have a minimum of 4 CPU cores, 32GB of memory, and 200GB of hard drive space. Applications tagged with "Intelligent O&M" are advised to use 32GB of GPU memory. These recommended values ​​can be set based on historical data or expert experience.

[0071] The real-time collected cloud resource status data includes current resource status information collected in real time through monitoring components, including but not limited to CPU utilization, memory utilization, disk I / O, network bandwidth utilization, latency, packet loss rate, etc. of each computing node. This data reflects the real-time load and availability of resources.

[0072] The management server, considering recommended resource requirements, resource scheduling strategies, and real-time status data, selects the most suitable resource from the available resource pool as the target resource. Specifically, it first filters candidate resources that meet basic specifications based on recommended resource requirements; then, it scores or ranks these candidate resources according to the resource scheduling strategy; finally, it determines the final target resource by combining real-time status data (e.g., avoiding high-load nodes and selecting low-latency paths). Simultaneously, it verifies whether the target resource's operating environment matches the application image information (e.g., operating system version, container runtime version, etc.). This ensures that the determined target resource is capable of hosting and running the application image, allowing subsequent application deployment operations (such as pulling images and creating container instances) to be performed directly on the resource, enabling external business services.

[0073] As demonstrated by the steps above, this application manages multiple platforms uniformly through a management server, automatically establishing connections and invoking APIs to achieve coordinated activation of cloud and network resources. In particular, through unified cross-domain boundary parameter allocation, it enables automatic interoperability between the two ends of the device, avoiding manual offline negotiation and adaptation. Furthermore, this application matches recommended resource requirements based on application categories and dynamically determines target resources matching the image information by combining real-time collected cloud and network resource status data. This achieves automated connection between resource activation and application deployment, and can dynamically respond to business traffic fluctuations, improving resource utilization and deployment success rate.

[0074] In some specific embodiments, step S104, based on the application classification matching resource requirement recommendation value, and according to the resource requirement recommendation value, resource scheduling strategy, and real-time collected cloud resource status data, determines the target resources for application deployment, specifically including:

[0075] Based on the application classification, the recommended resource requirement values ​​for the application are matched from the preset demand measurement model table;

[0076] Candidate resource clusters are selected from all NetCloud resource clusters based on the resource requirement recommendation values;

[0077] For all candidate resource clusters, scores are assigned based on the configured resource scheduling policy, and the candidate resource cluster with the highest score is selected as the target resource for application deployment.

[0078] This application uses a demand measurement model table to store recommended resource requirements such as CPU, GPU, memory, disk, and bandwidth for different application categories and tags. The demand measurement model table is essentially a large database table. An initial version is formed based on prior knowledge and research summaries. As the system runs, the actual resource parameter indicators used by each application can be observed, and the recommended values ​​for different application tags in the demand measurement model are updated with the actual indicator values. Therefore, the demand measurement model is self-evolving and self-optimizing. The system uses fuzzy matching keywords in the demand measurement model based on the application type and application tag of the business application to find recommended values ​​for resource requirements such as CPU, GPU, memory, disk, and bandwidth.

[0079] Table 1 shows an example of a demand metric model table. After a user deploys an application, based on the actual resource consumption of the application, the table calculates data such as CPU consumption per replica (i.e., application container instance), memory consumption per replica, disk read / write speed per replica, and network bandwidth per replica. The average value over a specified time period (e.g., 5 minutes) is then used to update the corresponding recommended resource demand values ​​in the demand metric model table.

[0080] Table 1. Examples of Demand Measurement Models

[0081]

[0082] In some specific embodiments, a more refined matching method can be used when matching recommended resource requirement values ​​from a preset demand measurement model table. In this method, matching recommended resource requirement values ​​for an application from the preset demand measurement model table according to the application category specifically includes:

[0083] The minimum requirements for CPU, memory, and storage resources for each application are determined by classifying the applications.

[0084] The refined resource requirements of an application are identified by the application tags under the application category, and the corresponding refined resource requirement suggestion values ​​are matched.

[0085] By combining the minimum requirement standard and the refined resource requirement recommendation value, a recommended value for the application's resource requirements is formed.

[0086] For example, suppose a user submits an application categorized as "AI application." The management server first matches the minimum requirements based on this category: 8 CPU cores, 16GB RAM, and 100GB storage. Simultaneously, the user selects "face recognition" as the application tag within this category. Based on this tag, the management server identifies more refined resource requirements: GPU acceleration is needed, with at least 16GB of GPU VRAM, and storage needs to be upgraded to an SSD to improve read and write performance. Finally, the minimum requirements are combined with the refined suggested values ​​to form the recommended resource requirements: 8 CPU cores, 16GB RAM, 16GB GPU VRAM, 200GB SSD storage, and 150Mbps bandwidth.

[0087] For example, a user submits an application categorized as "Big Data Application," with minimum requirements of 4 CPU cores, 16GB of RAM, and 200GB of storage. The user also selects "Real-time Stream Processing" as the application tag. Based on this tag, the management server provides refined recommendations: high IOPS storage is needed to support fast read and write operations, and RAM needs to be increased to 64GB to handle the large amounts of state data in streaming computing. The combined recommended resource requirements are: 8 CPU cores, 64GB of RAM, 500GB of high IOPS SSD storage, and 200Mbps bandwidth.

[0088] In this way, the basic operational requirements of the application are guaranteed, while refined resource matching is possible for specific business scenarios, making the recommendation values ​​more accurate and effective.

[0089] In some specific embodiments, the management server dynamically determines the target resources matching the image information based on recommended resource demand values ​​and real-time collected cloud resource status data. This dynamic determination method uses resource scheduling strategies. The resource scheduling strategies include at least one of the following: load-aware scheduling strategy, SLA (Service Level Agreement)-aware scheduling strategy, cost-aware scheduling strategy, and energy-aware scheduling strategy. The value calculation method for each resource scheduling strategy is as follows:

[0090] The value of the load-aware scheduling strategy is obtained based on the ratio of the actual number of idle nodes in the candidate resource cluster to the preset idle node baseline value.

[0091] The value of the SLA-aware scheduling strategy is obtained based on the ratio of the actual network bandwidth within the candidate resource cluster to the preset bandwidth baseline value.

[0092] The value of the cost-aware scheduling strategy is determined based on the ratio of the actual resource price of the candidate resource cluster to the preset highest price benchmark value.

[0093] The value of the energy consumption sensing scheduling strategy is obtained based on the ratio of the actual energy consumption of the resource to the preset maximum energy consumption benchmark value.

[0094] Specifically, the scoring logic of the load-aware scheduling strategy is as follows: using the number of idle nodes in the candidate cluster as the core indicator, the ratio of the actual number of idle nodes in the candidate cluster to the preset idle node baseline is calculated. This ratio is multiplied by the preset full score for this item to obtain the score, which shall not exceed the preset full score for this item. For example, the system defaults to a full score of 100 points when the number of idle virtual machines or physical machine nodes in the cluster is M. Using a linear function calculation algorithm, the score for N idle virtual machines in the cluster is (N / M)*100, and if the result is greater than 100, it is taken as 100.

[0095] The scoring logic for the SLA-aware scheduling strategy is as follows: using network bandwidth as the core indicator, calculate the ratio of the actual network bandwidth within the candidate cluster to the preset bandwidth baseline value, multiply this ratio by the preset maximum score for this item to obtain the score for this item, and the score shall not exceed the preset maximum score for this item. For example, if the maximum score is 100 points for bandwidth M (MB), the score for network bandwidth N (NB) is (N / M)*100.

[0096] The scoring logic for the cost-aware scheduling strategy is as follows: Using the usage price of candidate resources as the core indicator, calculate the ratio of the actual resource price to the preset maximum price benchmark. Multiply this ratio by the preset maximum score for this item. Subtract the product from the preset maximum score to obtain the score for this item. The score must not be lower than the preset minimum score for this item. For example, if the maximum virtual machine price is M yuan, and the virtual machine price is N yuan, the score is 100 - (N / M*100). The higher the price, the lower the score.

[0097] The scoring logic for the energy consumption-aware scheduling strategy is as follows: Using the energy consumption of candidate resources as the core indicator, calculate the ratio of the actual energy consumption of the resource to the preset maximum energy consumption benchmark. Multiply this ratio by the preset maximum score for this item, and subtract the product from the preset maximum score to obtain the score for this item. The score must not be lower than the preset minimum score for this item. For example, if the maximum energy consumption of a virtual machine is M watts, the score for a virtual machine with an energy consumption of N watts is 100 - (N / M*100). The higher the energy consumption, the lower the score.

[0098] If a single resource scheduling policy is configured, the calculated score of that policy is used as the final score for the candidate resource cluster. If multiple resource scheduling policies are configured, the calculated scores of each policy are weighted and summed, and the sum is used as the final score for the candidate resource cluster. This method is also known in this context as a multi-policy target selection algorithm. In this way, multi-dimensional policies can be integrated into resource selection, making the target resources for application deployment more aligned with business preferences.

[0099] In some specific embodiments, after selecting the candidate resource cluster with the highest score as the target resource for application deployment, the method further includes: performing an adaptation verification on the selected target resource cluster to verify whether the cluster conforms to the specified deployment rules; if the verification passes, the cluster is determined to be the final target resource; if the verification fails, the cluster is removed, and the cluster with the second highest score among the candidate resource clusters is selected for re-verification until the verification passes.

[0100] Deployment rules can include the security compliance requirements of the cluster's region, the compatibility of the application image with the cluster's operating system version, and whether the cluster has enabled necessary services (such as monitoring and logging). If the verification passes, the cluster is determined as the final target resource; if the verification fails, the cluster is removed, and the second-highest-scoring cluster among the candidate resource clusters is selected for re-verification until it passes. This mechanism ensures that the final selected target resource not only has a high performance score but also meets various constraints of actual deployment, avoiding operational anomalies caused by environment incompatibility after application deployment.

[0101] After determining the target resources for application deployment, the system automatically installs the container cluster and monitoring components required by the business application, starts the application instance, and completes the deployment with a single click. Specifically, the system generates an application deployment configuration file based on the application image information (such as image address and startup command) and target resource information. One-click deployment of the application can be completed by applying the configuration file. Business services are then provided externally through the API gateway.

[0102] In some specific embodiments, the configuration parameter information is obtained by dragging and dropping elements in the visualization blueprint interface; the application deployment related data is selected or determined through the visualization blueprint interface.

[0103] A blueprint is a topological structure describing a series of resource components and the relationships between them. This application uses a visual blueprint interface as a unified interactive entry point and employs MxGraph technology for front-end design. By condensing and abstracting network and cloud resource elements into different types of graph elements, such as virtual machines, containers, network devices, and bandwidth, users can drag and drop graph elements through the visual blueprint interface and connect these graph elements to represent connection relationships, thus completing the configuration preparation. For example, by connecting the data center boundary device (Border) and the backbone network boundary device (PE), double-clicking the connection allows for intuitive configuration of parameters that need to be coordinated and consistent. This mainly includes configuring Border and PE parameter data on the connections between the two cloud service provider (data center) graph elements and the backbone network graph elements. The system backend automatically converts the blueprint into configuration parameter information. The system centrally maintains the configurations within the data center, backbone network, and boundary in a unified interface, and automatically issues commands based on the encapsulated RESTful API, shielding the differences between underlying multi-vendor devices.

[0104] The specific mechanism for automatically converting blueprints into configuration parameter information is as follows: The system pre-builds a multi-form cloud resource element configuration information database, which establishes a mapping relationship between elements and resource parameters. Specifically, each element type corresponds to a set of predefined parameter templates: Data center Leaf switch element: bound to parameter templates such as the number of ports, bandwidth threshold, VLAN range, and uplink configuration; Backbone P router element: bound to parameter templates such as the device's unique identifier, manufacturer model, physical interface bandwidth, IGP routing protocol configuration, network convergence threshold, and out-of-band management address; Cross-domain boundary element: bound to parameter templates such as the names of the interconnecting interfaces at both ends, sub-interface numbers, and sub-interface IP addresses; Virtual machine element: bound to parameter templates such as hostname, availability domain, specifications, and image, as well as associated network, subnet, and security group elements.

[0105] After a user completes drag-and-drop and association operations on graphical elements in the visual blueprint interface, the system executes the following conversion logic: It identifies each graphical element placed by the user and its type, extracts the corresponding default parameter set from the parameter template library, and generates an instance object of that element. Then, it analyzes the connection relationships between graphical elements to determine the dependencies and connections between resources. For example, a connection between a virtual machine graphical element and a network graphical element indicates that the virtual machine needs to join a specific network; a connection between cross-domain boundary graphical elements indicates that the devices at both ends need to establish an interconnection. Next, based on the attribute configuration and topology relationships of the graphical elements, it automatically calculates and fills in specific parameter values. For example, the sub-interface numbers of the connections at both ends of a cross-domain boundary are automatically kept consistent, and IP addresses are automatically assigned to addresses within the same network segment. Finally, the above information is summarized and a complete set of network cloud resource configuration parameters is generated according to a standardized format (such as JSON or YAML), including configuration parameters within the data center, configuration parameters within the backbone network, and configuration parameters for cross-domain boundaries.

[0106] This automatic conversion mechanism based on primitive-parameter mapping makes complex cross-domain resource configuration intuitive and visual. Users can complete professional-grade cloud resource collaborative configuration without having to memorize or input a large number of underlying parameters.

[0107] Similarly, application deployment-related data can also be selected through the blueprint interface. The application image is a container image of the business application, which can be selected in the visual blueprint interface based on image resources in the image repository, which is communicatively connected to the management server. After the user selects an application image from the image repository associated with the interface, the management server synchronously obtains the corresponding identification information of the application image, ensuring that the image can be accurately pulled to the target resource using this identification. Application classification is confirmed by the user from the preset classification options on the interface, clarifying the application's type and providing a basis for recommending resource requirements. Optionally, the user can select the corresponding application tag under the application classification to clarify the application's refined resource requirements. The resource scheduling strategy is selected by the user on the interface, specifying one or more strategies. The management server performs format verification and integrity checks on all received application deployment-related data to ensure that the data meets the requirements for subsequent application deployment and resource scheduling, while also achieving unified data collection and storage.

[0108] This visualization method reduces the complexity of user operations, making complex cross-domain resource configuration and application deployment intuitive and easy to understand, and further improving the efficiency of application deployment.

[0109] A data center comprises at least one cluster, each cluster includes at least one virtual machine, and each virtual machine hosts at least one instance of a business application container. A cluster is a logical collection of physical servers (hosts) or virtualized hosts, united by cluster software to provide a unified pool of computing resources. A virtual machine is an independent virtual server allocated from the cluster's resource pool. A container is an application instance deployed on the virtual machine's operating system. In some specific embodiments, after one-click deployment, an automatic scaling mechanism is activated to dynamically adjust resource supply based on real-time monitored business traffic and resource utilization data. This automatic scaling mechanism is a three-tiered, interconnected mechanism, including container-based, virtual machine-based, and cluster-based scaling, with the scaling capabilities increasing sequentially across the three levels.

[0110] In some specific embodiments, the capacity expansion method includes:

[0111] Adjust the number of business application container instances deployed on virtual machines based on real-time monitored business traffic data and resource utilization data.

[0112] If the number of the business application container instances reaches the maximum configurable number of containers, a first virtual machine is created and added to the cluster. The first virtual machine has the same specifications, image, network, and subnet as the existing virtual machines in the cluster.

[0113] If the number of virtual machines in the cluster reaches the maximum configurable number of virtual machine nodes in the cluster, a second virtual machine is created and a new cluster is created using the second virtual machine as the master node. The second virtual machine has the same specifications, image, network, and subnet as the existing virtual machines in the existing cluster.

[0114] Volume reduction methods include:

[0115] Based on real-time monitored business traffic data and resource utilization data, once it is determined that the number of business application requests has decreased and the CPU or memory utilization of the business application container instance is lower than a set value, the business application container instance is deleted.

[0116] If the number of business application container instances deployed on a virtual machine drops to 0, delete the virtual machine.

[0117] If the number of virtual machines in the cluster drops to 0, delete the cluster.

[0118] Specifically, if container-based scaling is configured, the number of business application container instances deployed on virtual machines is adjusted based on real-time monitored business traffic and resource utilization data. If virtual machine-based scaling is configured, container-based scaling is executed first. When the number of containers deployed on a virtual machine reaches the configurable maximum number of containers, and no new containers can be added, virtual machine-based scaling is triggered. Under the cloud service provider where the cluster resides, a new virtual machine with the same specifications, image, network, and subnet as the existing virtual machines is created. The new virtual machine is seamlessly and automatically created via API calls and added to the cluster. If cluster-based scaling is configured, it automatically has the capabilities for both virtual machine-based and container-based scaling. When the number of virtual machines in the cluster reaches the configurable maximum number of virtual machine nodes in the cluster, and no more virtual machine nodes can be added, cluster-based scaling is triggered. A new cloud service provider is selected, and a new virtual machine with the same specifications, image, network, and subnet as the existing virtual machines is created. A new cluster is created using the new virtual machine as the master node, and the expanded application replicas are deployed through the new cluster. The maximum number of containers is configurable, typically not exceeding 110, and the maximum number of virtual machine nodes within the cluster is configurable, typically not exceeding 5000.

[0119] In addition, this application not only supports traditional Kubernetes HPA scaling, but also predicts peak and trough business traffic based on historical time-series data, and completes the scaling of business application container instances before the predicted peak and trough times arrive.

[0120] When application requests decrease, the first step is to scale down the container. If the container's CPU or memory usage falls below a set value, the container replica is deleted. When the number of containers on a virtual machine in the cluster reaches zero, the virtual machine is deleted. When all virtual machines in the cluster have been deleted, meaning the number of worker nodes in the cluster is zero, the entire cluster is deleted. All three scaling-up / scaling strategies follow this scaling-down rule.

[0121] Through an automatic scaling mechanism, the resource supply can be dynamically adjusted based on business traffic data and resource utilization data. This breaks free from the constraints of traditional static scheduling strategies, enabling rapid response to sudden business traffic fluctuations. While ensuring stable business operation, it avoids resource idleness and waste, effectively improves cloud resource utilization, and meets the core needs of enterprises for elastic business support.

[0122] This application also discloses an application deployment system, which is a software system. As shown in Figure 3, the system architecture mainly consists of modules such as cloud access, resource management, blueprint orchestration, and scheduling engine.

[0123] The cloud access module, composed of cloud platform management and network controller management, forms the foundation of the system solution. By importing API call authentication credentials from the cloud management and network management platforms, it enables access management of infrastructure such as cloud management and network management platforms. Cloud platform management is used to manage multiple cloud management platforms, including but not limited to public clouds, private clouds, and edge cloud platforms. Network controller management is used to manage multiple network management platforms, including but not limited to data center network controllers and backbone network controllers. The cloud access module supports various resource management operations at the top and interacts with different cloud management and network management platforms via API interfaces at the bottom.

[0124] The resource management module manages cloud and network resources throughout their entire lifecycle, including virtual machine management, virtual network management, cloud disk management, security group management, resource specifications, image management, unified network status, and network tunnel management. Virtual machine management provides CRUD operations for virtual machines and is the core of cloud resource usage. Creating a virtual machine depends on resource specifications, system images, networks, subnets, and security groups. Network management provides CRUD operations for networks and subnets. Cloud disk management provides CRUD operations for cloud disks, as well as mounting and unmounting operations. Security group management provides CRUD operations for security groups and editing security group rules. Resource specifications define key metrics such as the number of CPU cores and memory size for virtual machines created by users. Image management provides customized management of operating system images, allowing users to choose which operating system to use when creating a virtual machine. The unified network status can display the network topology and device status across multiple network management platforms in a single diagram, providing a global overview. Network tunnel management, through calls to the network management platform's API interface, uniformly displays network tunnel information and tunnel traffic data.

[0125] The blueprint orchestration module uses MxGraph technology for its front-end design. By condensing and abstracting cloud resource elements into different types of graph elements, users can drag and drop graph elements on a single graph to orchestrate and configure cloud resource requirements. It mainly consists of network orchestration, resource templates, one-click activation, and an orchestrated list. The network orchestration front-end is based on a visual blueprint, providing selection of cloud and network resource graph element types and configuration of graph element parameters. Graph elements are connected to visually demonstrate logical relationships, allowing for flexible configuration modification. The network orchestration back-end centrally manages the backbone network-side configuration and data center-side configuration required to connect networks between data centers. The system decomposes all configurations into internal data center configurations, internal backbone network configurations, and data center and backbone network boundary configurations, all managed through a single web page. Furthermore, it abstracts and simplifies the boundary configuration information requiring consistency between the two sides to a minimum of parameters: interface name, sub-interface number, and sub-interface IP. It automatically assigns the same sub-interface number and IP address to devices on both sides of the boundary. Based on the required configuration parameters, each network management platform encapsulates and exposes RESTful APIs. The API interface enables users to log in to switches or routers and execute relevant commands via interface code. This module is located at the top level of the system and interfaces with multiple cloud management platforms and network management platforms. It uses a token authentication method based on username and password to access the interfaces of each platform. By calling the interface, it shields the differences between underlying devices from different vendors, enabling efficient end-to-end cross-cloud and cross-network data center business interoperability. The resource template is used to save commonly used cloud resource configurations as templates for easy reuse. Opening a resource template allows users to directly configure and activate resources according to the blueprint of the resource template. One-click activation is used to call the resource management module to perform atomic operations for various resources based on the user's blueprint orchestration results, and to apply for and activate cloud resources. The orchestrated list is responsible for managing the resources that users have orchestrated and activated, tracking the resource application and activation status, logging in to view related virtual machine resources, and deleting and releasing applied cloud resources.

[0126] The scheduling engine module is responsible for the automated deployment of business applications, scheduling and utilizing the user's existing cloud resources on demand, including application management, scheduling policies, orchestration algorithms, and one-click deployment. Application management manages users' business applications, including uploading application images, application categorization, application tagging, and deployment resource pools. Application categorization and tagging represent the application's coarse-grained and fine-grained requirements, respectively. Scheduling policies configure resource scheduling and automated scaling strategies used during application deployment. Resource scheduling strategies include, but are not limited to, load-aware, cost-aware, SLA-aware, and energy-aware scheduling strategies. Automated scaling strategies include, but are not limited to, container-based, virtual machine-based, and cluster-based scaling. Orchestration algorithms are crucial for matching supply and demand between cloud resources and business applications. Based on the current status of cloud resources, the resource requirements of business applications, and the configured scheduling policies, a multi-strategy target selection algorithm is used to accurately match the optimal target resources for application deployment. One-click deployment, based on the output of the orchestration algorithm, deploys business applications to target resources, including automatically creating container clusters and monitoring components. Users do not need to intervene throughout the process; the business application is deployed with a single click and provides business services externally through the API gateway. To address potential surges in business traffic during application operation, the system implements automated scaling without user intervention, based on pre-configured scaling strategies. This employs a three-tiered automated scaling mechanism, including container-based, virtual machine-based, and cluster-based scaling. In this application, container-based scaling, built on cloud-native technology, utilizes historical data-driven scaling. Specifically, it pre-scales container instances based on historical time-series data of the number of business application container instances recorded by the system. Furthermore, it adds automated scaling based on virtual machines and clusters. When new containers cannot be added to virtual machines, new virtual machines are automatically added to expand the business. When all virtual machines in a cluster are fully utilized, new clusters are automatically added to accommodate new business requests. Because the system manages various cloud platforms, virtual machines can be seamlessly and automatically created via API calls, and new virtual machines are added to the cluster for business application expansion.

[0127] Figure 4 illustrates the workflow of the application deployment system in this embodiment of the application. The specific steps are as follows:

[0128] Step 1: Manage multiple cloud management platforms. Enter the API call authentication credentials of the cloud management platform, including but not limited to AK / SK, username and password, API access address and port, and user domain. After the API authentication is successful, you can use the corresponding functions of the cloud management platform through API interface calls.

[0129] Step 2: Manage multiple network management platforms. Enter the API call authentication credentials for the network controller, including but not limited to username, password, API access address and port. After the API authentication is successful, the corresponding functions of the network management platform can be used through API interface calls.

[0130] Step 3: Based on the visual blueprint canvas, drag and drop graphic elements. Select the graphic element type according to the user's needs for cloud resources, including but not limited to cloud service providers, virtual machines, networks, subnets, cloud disks, security groups, floating IPs, routes, backbone networks, PE devices, and P devices. Through the editing, configuration, and connection operations of graphic elements, realize the visual representation and one-map display of user needs.

[0131] Step 4: Construct the required cloud topology and obtain configuration parameters. Data center internal configuration includes configuring virtual machine elements such as hostname, availability zone, specifications, and image, as well as connecting associated networks, subnets, and security groups. Backbone internal configuration includes configuring the latency, bandwidth, and hop count of the link between the backbone network's starting and ending PEs, calculating and selecting the optimal path. Data center and backbone network boundary configuration is achieved by connecting data center boundary devices (Border) and backbone network boundary devices (PEs), and double-clicking the connection allows for intuitive configuration of parameters requiring consistency.

[0132] Step 5: Call the cloud management interface to enable and configure cloud platform resources. Based on the virtual machine parameters configured in the previous steps, call the API interface for creating virtual machines to create and start the virtual machines.

[0133] Step 6: Call the network management interface to enable and configure network resources. Based on the network parameters configured in the previous steps, call the interfaces of the data center network controller and the backbone network controller respectively to create the backbone virtual network and tunnel, and open up the DCI network channel between virtual machines across data centers. This eliminates the need to remotely log in to network devices to execute commands, and shields the heterogeneity of devices from different manufacturers and models and the complexity of user operations.

[0134] Step 7: Upload the container image of the business application, and set the application category, application tags, and deployment resource pool. The resource pool can be selected from the previously enabled resources. The application category is used to represent the overall resource requirements of the application, and the application tags include scenario dimensions and technical dimensions to represent the detailed requirements of the application.

[0135] Step 8: Configure application deployment strategies. Application deployment strategies mainly refer to resource scheduling strategies and automated scaling strategies. Resource scheduling strategies include, but are not limited to, load-aware scheduling strategies, cost-aware scheduling strategies, SLA-aware scheduling strategies, and energy-aware scheduling strategies. Resource scheduling strategies can be configured with combinations of multiple strategies and corresponding weights. Automated scaling strategies include, but are not limited to, container-based scaling, virtual machine-based scaling, and cluster-based scaling.

[0136] Step 9: Use a multi-strategy target selection algorithm to determine the target resources. Specifically: First, determine the application's resource requirements by matching the application's recommended resource requirements from the demand metric model table based on application classification. Second, obtain the CPU, memory, disk, and other metrics of virtual machines or physical machines, as well as the usage and performance metrics of container resources. Iterate through the resource status in the cluster to select all clusters that meet the recommended application resource requirements. Finally, for all clusters that meet the criteria, perform a weighted score based on the configured resource scheduling strategy. The cluster with the highest score is selected as the target resource for deploying the application, thus achieving the best match between resource demand and resource supply.

[0137] Step 10: One-click application deployment. After calculation by the scheduling engine algorithm, the target resources for application deployment are determined, the container cluster and monitoring components required by the business application are automatically installed, the application instance is started, and the deployment is completed with one click.

[0138] Step 11: Run the three-level linkage automatic scaling mechanism. The system completes the elastic scaling of business application throughput according to the configured three-level scaling strategies based on containers, virtual machines, and clusters. The levels of container-based, virtual machine-based, and cluster-based increase in that order.

[0139] Step 12: The scheduling engine monitors resource utilization in real time and determines whether scaling up or down is necessary. If not, it directly exposes the application service to the outside world through the API gateway.

[0140] Step 13: If scaling up or down is required, apply for or release resources based on business traffic and resource status. When resource utilization is high, apply for new resources according to the automated scaling up / down strategy; when resource utilization is low, release existing resources according to the automated scaling up / down strategy.

[0141] Step 14: Update application instances. Add or delete application instances on newly requested resources to effectively cope with sudden business traffic and server node failures, and ensure the continuity and reliability of external services.

[0142] Accordingly, this application also discloses an application deployment device used as a management server. The management server is used to manage multiple cloud management platforms and multiple network management platforms. Referring to FIG5, the device includes:

[0143] The resource data acquisition module is used to acquire cloud resource configuration related data. The cloud resource configuration related data includes interface communication information of each cloud management platform and network management platform, as well as configuration parameter information generated according to user configuration requirements. The configuration parameter information includes data center internal configuration parameters, backbone network internal configuration parameters, and cross-domain boundary configuration parameters.

[0144] The resource configuration module is used to establish a communication connection between the management server and the multiple cloud management platforms and the multiple network management platforms based on the interface communication information, and to call the API interface of the corresponding platform according to the configuration parameter information to complete the collaborative activation configuration of cloud resources and network resources. The configuration includes data center internal configuration, backbone network internal configuration and cross-domain boundary configuration. The cross-domain boundary configuration achieves collaborative interoperability between the two devices through unified cross-domain boundary configuration parameter allocation.

[0145] The application deployment data acquisition module is used to acquire application deployment-related data submitted by users, including application image information, application classification, and resource scheduling strategies.

[0146] The target resource determination module is used to match the recommended resource requirements based on the application classification, and determine the target resources that match the application image information according to the recommended resource requirements, resource scheduling strategy and real-time collected cloud resource status data. The target resources are used to deploy the application to enable normal external business services.

[0147] It should be understood that the application deployment device in this embodiment can implement all the technical solutions in the above application deployment method embodiments. The functions of each functional module can be specifically implemented according to the methods in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here.

[0148] This application also provides an electronic device, including: one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the programs, when executed by the processors, implement the steps of the application deployment method as described above.

[0149] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the application deployment method described above.

[0150] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus (systems), electronic devices, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0151] This application is described with reference to flowchart illustrations of methods according to embodiments of this application. It should be understood that each step in the flowchart and combinations of steps in the flowchart can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more steps of the flowchart.

[0152] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more processes of a flowchart.

[0153] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more processes in the flowchart.

Claims

1. An application deployment method, characterized in that, This method is applied to a management server, which manages multiple cloud management platforms and multiple network management platforms in a data center and backbone network. The method includes: acquiring cloud resource configuration-related data, which includes interface communication information of each cloud management platform and network management platform, as well as configuration parameter information generated according to user configuration requirements. The configuration parameter information includes data center internal configuration parameters, backbone network internal configuration parameters, and cross-domain boundary configuration parameters; establishing communication connections between the management server and the multiple cloud management platforms and the multiple network management platforms based on the interface communication information; and calling the corresponding platform's API interface according to the configuration parameter information to complete the process. The system coordinates the activation and configuration of cloud and network resources. This configuration includes internal data center configuration, internal backbone network configuration, and cross-domain boundary configuration. The cross-domain boundary configuration achieves interoperability between devices at both ends through unified cross-domain boundary configuration parameter allocation. It also acquires application deployment-related data submitted by the user, including application image information, application classification, and resource scheduling strategies. Based on the application classification, it matches recommended resource requirements. According to the recommended resource requirements, resource scheduling strategies, and real-time collected cloud and network resource status data, it determines target resources that match the application image information. These target resources are used to deploy applications to enable normal external business services.

2. The method according to claim 1, characterized in that, The step of matching resource requirement recommendations based on the application classification, and determining the target resource for application deployment based on the resource requirement recommendations, resource scheduling strategies, and real-time collected cloud resource status data, specifically includes: matching the application's resource requirement recommendations from a preset requirement measurement model table according to the application classification; filtering candidate resource clusters from all cloud resource clusters based on the resource requirement recommendations; scoring all candidate resource clusters according to the configured resource scheduling strategy, and selecting the candidate resource cluster with the highest score as the target resource for application deployment.

3. The method according to claim 2, characterized in that, The step of matching the recommended resource requirements of an application from a preset demand measurement model table based on the application classification specifically includes: determining the minimum requirement standards for CPU, memory, and storage resources corresponding to the application through the application classification; identifying the refined resource requirements of the application through the application tags under the application classification, and matching the corresponding refined resource requirement suggestion values; and combining the minimum requirement standards and the refined resource requirement suggestion values ​​to form the recommended resource requirements of the application.

4. The method according to claim 2, characterized in that, The resource scheduling strategy includes at least one of the following: load-aware scheduling strategy, SLA-aware scheduling strategy, cost-aware scheduling strategy, and energy-aware scheduling strategy. The values ​​of each resource scheduling strategy are calculated as follows: the value of the load-aware scheduling strategy is obtained based on the ratio of the actual number of idle nodes in the candidate resource cluster to a preset idle node baseline value; the value of the SLA-aware scheduling strategy is obtained based on the ratio of the actual network bandwidth in the candidate resource cluster to a preset bandwidth baseline value. The value of the cost-aware scheduling strategy is obtained based on the ratio of the actual resource price of the candidate resource cluster to the preset maximum price benchmark value; the value of the energy consumption-aware scheduling strategy is obtained based on the ratio of the actual energy consumption of the resource to the preset maximum energy consumption benchmark value.

5. The method according to claim 2, characterized in that, After selecting the candidate resource cluster with the highest score as the target resource for application deployment, the process further includes: performing an adaptation check on the selected target resource cluster to verify whether the cluster conforms to the specified deployment rules; if the check passes, the cluster is determined as the final target resource; if the check fails, the cluster is removed, and the second highest-scoring cluster among the candidate resource clusters is selected for re-checking until the check passes.

6. The method according to claim 1, characterized in that, The configuration parameter information is obtained by dragging and dropping elements in the visualization blueprint interface; the application deployment related data is selected or determined through the visualization blueprint interface.

7. The method according to claim 1, characterized in that, The data center includes at least one cluster, each cluster includes at least one virtual machine, and each virtual machine deploys at least one business application container instance. The method further includes: adjusting the number of business application container instances deployed on the virtual machine based on real-time monitored business traffic data and resource utilization data; if the number of business application container instances reaches the maximum configurable number of containers, creating a first virtual machine and adding the first virtual machine to the cluster, wherein the first virtual machine has the same specifications, image, network, and subnet as the existing virtual machines in the cluster; if the number of virtual machines in the cluster reaches the maximum configurable number of virtual machine nodes in the cluster, creating a second virtual machine and using the second virtual machine as the master node to create a new cluster, wherein the second virtual machine has the same specifications, image, network, and subnet as the existing virtual machines in the existing cluster.

8. The method according to claim 1, characterized in that, The data center includes at least one cluster, each cluster includes at least one virtual machine, and each virtual machine deploys at least one business application container instance. The method further includes: based on real-time monitored business traffic data and resource utilization data, determining that business application requests have decreased and the CPU or memory utilization of the business application container instance is lower than a set value, then deleting the business application container instance; if the number of business application container instances deployed on the virtual machine drops to 0, deleting the virtual machine; if the number of virtual machines in the cluster drops to 0, deleting the cluster.

9. An electronic device, characterized in that, include: One or more processors; Memory; And one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, wherein when the programs are executed by the processors, they implement the application deployment method as described in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the application deployment method as described in any one of claims 1-8.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the application deployment method as described in any one of claims 1-8.

Images