Cloud platform deployment method, system, equipment and medium

Abstract

The invention discloses a cloud platform deployment method, system and device and a medium, and generally relates to the technical field of computers. The method comprises the following steps: detecting a candidate server, wherein the candidate server is a server with a cloud platform building condition; based on the configuration parameters of the candidate servers, a server cluster topology file of the cloud platform is generated, and the server cluster topology file comprises a service role of each server in the candidate servers in the cloud platform and deployment parameters corresponding to the servers; according to the cluster topology file, the cloud platform is deployed to the candidate servers, and the candidate servers comprise servers of at least two system architectures. The deployment efficiency and accuracy can be improved.

Description

Technical Field

[0001] The present disclosure generally relates to the field of computer technology, and more particularly to a cloud platform deployment method, system, device and medium. Background Art

[0002] With the continuous development of information technology, cloud platform technology is also developing in different aspects.

[0003] Cloud platforms often need to be installed on several servers. Reusing old servers can help users save costs and improve the overall computing resources of the cloud platform. Specifically, the reused servers may be servers of several different architectures, that is, they belong to a heterogeneous cloud platform environment. For example, a cloud platform includes servers with X86 architecture and servers with ARM architecture. In related technologies, for heterogeneous cloud platform environments, engineers need to manually split the installed resource packages of different servers, and then deploy the installed resource packages corresponding to their architectures and server functions for different servers to complete the construction of the cloud platform.

[0004] However, the above process requires manual intervention, which is very prone to errors, and the manual deployment preparation time is long, and the deployment process efficiency is low. Summary of the invention

[0005] In view of the above-mentioned defects or deficiencies in the related art, it is desired to provide a cloud platform deployment method, system, device and medium that can solve the problem that in the heterogeneous server deployment process of the cloud platform, manual intervention is required, which is very easy to make mistakes, the manual deployment preparation time is long, and the deployment process is inefficient, so as to simplify the heterogeneous deployment process of the cloud platform and improve the deployment efficiency and accuracy.

[0006] In a first aspect, a cloud platform deployment method is provided, the method comprising: Detect candidate servers, where the candidate servers are servers that meet the conditions for building a cloud platform; Based on the configuration parameters of the candidate servers, a server cluster topology file of the cloud platform is generated, wherein the server cluster topology file includes: the business role of each server in the candidate servers in the cloud platform and the deployment parameters corresponding to the server; According to the cluster topology file, the cloud platform is deployed to the candidate servers, wherein the candidate servers include servers of at least two system architectures.

[0007] In this application, in the process of building a cloud platform, servers that meet the conditions for building a cloud platform are first detected as candidate servers, and then, based on the configuration parameters of the candidate servers, the server cluster topology file of the cloud platform is generated, so that the business role of each server in the candidate server in the cloud platform and the deployment parameters of the server can be detailed; finally, according to the server cluster topology file of the above cloud platform, the cloud platform is deployed to the candidate servers, wherein the candidate servers include servers of at least two system architectures. In this way, by detecting the candidate servers that can build a cloud platform, and generating a server cluster topology file of the cloud platform that is compatible with the candidate servers for the candidate servers, the cloud platform can be deployed to servers including at least two system architectures. That is, by setting up a standardized process for building a cloud platform with heterogeneous servers, the construction process of the cloud platform is generalized and automated, which greatly improves the deployment efficiency of the heterogeneous cloud platform, and also greatly reduces the manual parameter steps in the construction process of the heterogeneous cloud platform.

[0008] In a second aspect, a cloud platform deployment system is provided, the system comprising: A node discovery module is used to detect candidate servers, where the candidate servers are servers that meet the conditions for building a cloud platform; A cluster topology module, used to generate a server cluster topology file of the cloud platform based on the configuration parameters of the candidate servers, wherein the server cluster topology file includes: the business role of each server in the candidate servers in the cloud platform and the deployment parameters corresponding to the server; A cluster deployment module is used to deploy the cloud platform to the candidate servers according to the cluster topology file, and the candidate servers include servers of at least two system architectures.

[0009] In a third aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method described in the first aspect is implemented.

[0010] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored, characterized in that when the program is executed by a processor, the method described in the first aspect is implemented.

[0011] In a fifth aspect, a computer program product is provided. The computer program product includes instructions, and the instructions are executed by a processor to implement the method described in the first aspect.

[0012] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings: Figure 1 A schematic diagram of a cloud platform deployment method provided in an embodiment of the present application; Figure 2 A schematic diagram of the execution flow of the node discovery module in the cloud platform deployment method provided in an embodiment of the present application; Figure 3 A schematic diagram of the execution flow of the cluster topology module in the cloud platform deployment method provided in an embodiment of the present application; Figure 4 A schematic diagram of the execution flow of a topology management module in a cloud platform deployment system provided in an embodiment of the present application; Figure 5 A schematic diagram of the execution flow of the role definition module in the cloud platform deployment method provided in an embodiment of the present application; Figure 6 A schematic diagram of the execution flow of the parameter processing module in the cloud platform deployment method provided in an embodiment of the present application; Figure 7 A schematic diagram of the execution flow of the cluster deployment module in the cloud platform deployment method provided in an embodiment of the present application; Figure 8 A schematic diagram of module logic in a visual sub-interface in a cloud platform deployment method provided in an embodiment of the present application; Fig. 9 A schematic diagram of the visual sub-interface in the cloud platform deployment method provided in an embodiment of the present application; Fig.10 A schematic diagram of the structure of the cloud platform deployment system provided in the embodiment of the present application; Fig.11 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0014] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It is also necessary to explain that, for ease of description, only the parts related to the invention are shown in the accompanying drawings.

[0015] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The following is an explanation of the factual scenario of the present application.

[0016] In the context of information technology application innovation, the proportion of domestic communication and computer-related software and hardware is increasing. Specifically, the market share of domestic operating systems, domestic core processors, and domestic image processors is increasing. Correspondingly, there are more and more cloud platform systems.

[0017] For enterprises, in the process of development, they may purchase or rent servers with different systems and algorithms (for example, Intel's servers). On the basis of having servers with multiple different systems and algorithms, if they need to build a new cloud platform, they often need to build the cloud platform in the server of the same target system or target algorithm. As a result, there may be 20 servers that need to be deployed on the cloud platform, but the enterprise has only 10 servers of the target system or target algorithm, and the remaining servers may be non-target systems or target algorithms. In this way, the enterprise will need to purchase or rent 10 new servers with the target system or target algorithm, which obviously causes a waste of existing server resources and also increases a lot of costs for the construction of the enterprise cloud platform. In this way, heterogeneous platforms, that is, building cloud platforms in servers with different system architectures or different algorithms, that is, by reusing old servers, can reduce the cost of enterprises and save and improve the overall computing resources of the cloud platform.

[0018] In related technologies, if heterogeneous servers need to be deployed, engineers need to perform different deployment configurations based on different software and hardware resources such as the server operating system, CPU, GPU, etc. Manual intervention is often required during the deployment process, which is prone to errors. At the same time, manual deployment preparation time is long and the parallel efficiency of the deployment process is low.

[0019] Therefore, a universal and automated deployment system that supports heterogeneous cloud platforms is needed to simplify the heterogeneous deployment process of cloud platforms and improve deployment efficiency and accuracy.

[0020] Based on this, the present application proposes a cloud platform deployment method, system, device and medium, which can solve the problem that in the heterogeneous server deployment process of the cloud platform, manual intervention is required, which is very easy to make mistakes, the manual deployment preparation time is long, and the deployment process is inefficient, so as to simplify the heterogeneous deployment process of the cloud platform and improve deployment efficiency and accuracy.

[0021] Figure 1 FIG. 1 is a flow chart of a cloud platform deployment method provided by an embodiment of the present application, and the execution subject of the method may be a server. Figure 1 As shown, the method includes the following steps 11 to 13: Step 11: Probe candidate servers.

[0022] In the embodiment of the present application, the above-mentioned candidate server is a server that meets the conditions for building a cloud platform.

[0023] It is understandable that when the cloud platform needs to be automatically built on several servers, it is necessary to first confirm the servers that currently have the conditions for building the cloud platform. Furthermore, assuming that the current cloud platform requires 20 servers to complete the work of building it, and there are 30 servers in the current building environment, it is necessary to determine which of the 30 servers can be used for building the cloud platform, and the servers that can be used to build the cloud platform are used as candidate servers.

[0024] In the embodiment of the present application, the server used to detect the candidate server can be one of the servers used to build the cloud platform, that is, one of the candidate servers, or other servers. It is understandable that when the server used to detect the candidate server is one of the servers for building the cloud platform, the server is a predetermined server that can be used to build the cloud platform.

[0025] In the embodiment of the present application, the above cloud platform building conditions may be pre-set. The cloud platform building conditions correspond to the configuration parameters of the cloud platform.

[0026] Optionally, in an embodiment of the present application, in the above-mentioned detection candidate server, in the cloud platform deployment method provided in the present application, it includes: sending detection information to the server cluster; receiving response information sent by the above-mentioned server cluster; and generating a server registration information list based on the above-mentioned response information.

[0027] Exemplarily, the server cluster includes candidate servers, and the detection information includes cloud platform configuration requirement parameters.

[0028] It is understandable that the number of servers in the server cluster is greater than or equal to the number of servers in the candidate servers.

[0029] Exemplarily, the cloud platform configuration requirement parameters may be indicated by server node range feature information.

[0030] It is understandable that in the process of sending detection information to the server cluster, the detection information can be information that can be received by the server in the server cluster and can also require the server receiving the information to perform the cloud platform parameter matching process. When the node parameters of the server match the cloud platform parameters, the server replies to the server deploying the cloud platform according to the detection information, and the reply information includes the node information of the server. That is, the server node range feature information is the information of the server that meets the cloud platform construction conditions through the network detection, which can also help obtain the node information of the server that meets the cloud platform construction conditions.

[0031] Exemplarily, the response information includes configuration parameters of the servers in the server cluster.

[0032] In an example, the configuration parameters of the server may include node information of the server.

[0033] Exemplarily, the above server registration information list includes server type parameters, and the server type parameters include at least two type parameters.

[0034] It can be understood that after the server cluster receives the above-mentioned detection information, as described above, the detection information is used to detect the server information that currently meets the construction requirements. The server in the server cluster that meets the node range characteristic information in the current detection information will respond to the detection information and send a response information. The response information includes the configuration parameters of the server that meets the construction conditions.

[0035] Exemplarily, the server registration information list includes configuration information of the candidate server.

[0036] It is understandable that in the process of detecting and determining candidate servers that can build a cloud platform, it is necessary to count the server's configuration parameters, such as node information, in the form of a list. The format of the list corresponds to the list format of the final cloud platform configuration server. By reading and updating the list, a cluster topology file that can be used to configure the cloud platform is eventually formed.

[0037] Exemplarily, the configuration information of the candidate server may include node information of the candidate server.

[0038] Optionally, in an embodiment of the present application, generating a server registration information list based on the response information includes: reading node information corresponding to the server node of the candidate server from the response information based on the response information; parsing the node information, and performing node registration based on the node information to generate a server node information list of the cloud platform.

[0039] Exemplarily, the above node information is as described above.

[0040] It is understandable that after obtaining the response information, the node information can be parsed and a server node information list can be generated based on the node information.

[0041] Furthermore, after determining that several servers in the construction environment can be used for building the cloud platform, whether to determine them as candidate servers for building the cloud platform can be determined during the detection of candidate servers, that is, the above-mentioned step 11, or after detecting the servers, the cloud platform servers used to build the cloud platform can be screened. The embodiments of the present application are not limited to this.

[0042] The following is a description of an embodiment of the present application based on the two different methods of determining the candidate server mentioned above, namely, during the process of detecting the candidate server and after detecting the server.

[0043] The first method: the detected server is the candidate server.

[0044] Optionally, in an embodiment of the present application, the above-mentioned detection of candidate servers, in the cloud platform deployment method provided in an embodiment of the present application, includes: sending first detection information to the server cluster.

[0045] Exemplarily, the above-mentioned receiving response information sent by the candidate server in the server cluster, in the cloud platform deployment method provided in the embodiment of the present application, includes: receiving first response information sent by the candidate server.

[0046] Exemplarily, the first response information is information sent by the candidate server after determining that the candidate server meets the conditions for building a cloud platform by performing capability matching based on the cloud platform configuration requirement parameters and the configuration parameters of the candidate server.

[0047] Exemplarily, the first detection information is used to instruct a server that receives the first detection information to perform capability matching based on the first detection information.

[0048] It is understandable that, in the process of detecting servers for deploying the cloud platform, the information content of the detection information can be set to be used to screen out information of servers that can actually be used to deploy the cloud platform, that is, the first detection information mentioned above. The first detection information can directly instruct the servers in the server cluster to perform cloud platform deployment capability matching on their own after receiving the first detection information, and send the first response information if the capabilities match.

[0049] Furthermore, the above-mentioned first detection information may also include the number of deployed servers of the cloud platform. The above-mentioned capability-matching candidate servers may be ranked according to the degree of capability matching in the local area network formed by themselves. Then, among all the servers that can send response information, the servers with the top N capability matching degrees are screened out and the first response information is sent, where N is the same as the number in the number of deployed servers of the cloud platform.

[0050] For example, there are 30 servers in the current server cluster, and the number of servers deployed by the cloud platform is 20. Then, the 30 servers in the server cluster, through the first detection information, instruct the servers among the 30 servers to perform cloud platform deployment capability matching based on the first detection information. After capability matching, the capability matching servers send a first response message. Among them, assuming that the number of capability matching servers is greater than 20, the capability matching degree of the capability matching servers is ranked, and the servers ranked in the top 20 send the first response message.

[0051] Furthermore, assuming that the number of servers with matching capabilities is greater than 20, the method of ranking the matching capabilities of the servers with matching capabilities can be introduced by introducing a self-ranking function of the matching capabilities. Specifically, assuming that 30 servers are servers that match the cloud platform deployment capabilities after receiving the first detection information sent by the server for deploying the cloud platform, the 30 servers will form a network by themselves, and perform capability ranking, and select the top 20 servers in the capability ranking as candidate servers by themselves, and send a first response information, which includes the server information of the 20 candidate servers.

[0052] The second method is to screen the servers that can deploy the cloud platform after detecting them to obtain the final candidate servers.

[0053] Optionally, in the embodiment of the present application, the sending of detection information to the server cluster, in the cloud platform deployment method provided in the embodiment of the present application, includes: sending second detection information.

[0054] Exemplarily, the second detection information is used to instruct the target server receiving the second detection information to report the current working status and server configuration parameters.

[0055] It is understandable that the second detection information may only require the servers in the server cluster to only feed back their own configuration parameter information and working status after receiving the second detection information.

[0056] Exemplarily, the current working status is used to indicate the application program and algorithm currently running on the server, whether the server is currently online, and the like.

[0057] Exemplarily, the above-mentioned receiving a response message sent by a candidate server in the server cluster includes: receiving a second response message sent by a target server; if the current working status in the second response message indicates that the target server is in an online deployable state, and the configuration parameters match the cloud platform configuration requirement parameters, then determining that the target server is a candidate server that meets the conditions for building a cloud platform.

[0058] Exemplarily, the second response information includes the current working status of the target server and server configuration parameters.

[0059] Exemplarily, the target servers include candidate servers. It is understandable that the number of target servers is greater than or equal to the number of candidate servers.

[0060] It is understandable that after receiving the second response information sent by the target server, the current working state and server configuration parameters of the target server that sent the second response information can be read according to the second response information.

[0061] When the target server is in a deployable state and matches the configuration requirement parameters of the cloud platform, the target server can be determined as a candidate server.

[0062] Furthermore, when the current working state is an online deployable state and the number of target servers whose configuration parameters meet the cloud platform configuration requirement parameters is greater than the number of candidate servers, the degree of match between the target server's configuration parameters and the cloud platform configuration requirement parameters can be ranked, and the target servers with the highest degree of match can be selected as the final candidate servers.

[0063] The process of detecting candidate servers is described below by way of Example 1.

[0064] Example 1: The above cloud platform deployment method is applied to a cloud platform deployment system, and the cloud platform deployment system is applied to a server, which can be a server that can be used as cloud platform deployment hardware, or a server other than a deployment server, that is, the server is specifically used to perform cloud platform deployment work. Furthermore, the cloud platform deployment system includes multiple functional modules, and different modules are used to perform different tasks, such as Figure 2 As shown, the module for performing the task of detecting candidate servers is the node discovery module. It can be understood that the node discovery module is used to detect and discover candidate servers that can be used to deploy the cloud platform.

[0065] S101: The node discovery module in the cloud platform deployment system sets server node range feature information and sends detection information.

[0066] Among them, the server node range feature information includes the IP address segment, the minimum number of CPU cores and the minimum memory capacity parameter threshold. The SNMP protocol detects online nodes within the IP address segment. It can be understood that the snmpd service of the detected server node that meets the candidate server requirements needs to be in a running state (that is, the above-mentioned working state is the current online state). Further, the CPU load information defined by HOST-RESOURCE-MIB::hrProcessorEntry is obtained through OID: .1.3.6.1.2.1.25.3.3.1.2. N cores have N load information. The CPU core number information is further obtained, and the memory size defined by HOST-RESOURCE-MIB::hrMemorySize is further obtained through OID: .1.3.6.1.2.1.25.2.2.0. The above three feature information is used to filter out servers that do not meet the basic requirements in the local area network; S102: The node discovery module in the cloud platform deployment system creates a server node registration list. The server node registration list is used to record candidate server node information of candidate servers that meet the requirements according to response information sent by the server after detecting the candidate servers.

[0067] In the embodiment of the present application, the above server node registration list is persistently stored through a yaml configuration file. Among them, the server node registration list contains the node name, IP address, node ID, node parameters, SSH remote connection information, etc. of each server in the candidate server. At the same time, the server node goes a step further, and the registered node list supports adding, editing, and deleting operations, and supports manual entry of nodes.

[0068] The server registration node list is shown below: node1: os: distribution: LinxOS architecture: aarch64 connect: …… cpu: …… mem: …… net: …… disk: …… pci: …… node2: …… In the above content, node1 represents the serial number ID of the candidate server. All information under the candidate server node ID is the detailed parameter information of the node. The os parameter segment is the operating system information of the candidate server, the connect parameter segment is the remote connection information of the candidate server, the cpu parameter segment is the CPU information of the candidate server, the mem parameter segment is the memory information of the candidate server, the net parameter segment is the server storage information, the disk parameter segment is the storage information of the candidate server, and the pci parameter segment is the PCI device information of the candidate server.

[0069] S103, the node discovery module in the cloud platform deployment system updates the remote connection parameters defined in the connect parameter section in the server registration node list. Further improve the node detailed information through the SSH remote connection, and update the collected node detailed parameters to the corresponding parameter section in the server registration node list.

[0070] Step 12: Based on the configuration parameters of the candidate servers, generate a server cluster topology file of the cloud platform.

[0071] In an embodiment of the present application, the server cluster topology file includes: the business role of each server in the candidate servers in the cloud platform and the deployment parameters corresponding to the server.

[0072] Exemplarily, the above server cluster topology file is used to characterize the connection relationship between servers and their business roles in the cloud platform.

[0073] It is understandable that for a cloud platform, it often needs to be deployed in multiple servers, that is, the above-mentioned candidate servers in this application. The servers have a logical connection relationship with each other. At the same time, a cloud platform is actually completed by the cooperation of multiple roles. Therefore, it is necessary to set corresponding roles for each server deployed on the cloud platform. Each server performs tasks according to the role and transmits information to each other according to the connection logic.

[0074] Step 13: According to the cluster topology file, deploy the cloud platform to the candidate servers.

[0075] In an embodiment of the present application, the candidate servers include servers of at least two system architectures.

[0076] It is understandable that, when the above-mentioned candidate servers and the cluster topology files of the cloud platform are determined, the cloud platform can be deployed in the candidate servers according to the file settings of the cluster topology files.

[0077] In the method provided in the embodiment of the present application, during the process of building a cloud platform, a server that meets the conditions for building a cloud platform is first detected as a candidate server, and then, based on the configuration parameters of the candidate server, a server cluster topology file of the cloud platform is generated, so that the business role of each server in the candidate server in the cloud platform and the deployment parameters of the server can be detailed; finally, according to the server cluster topology file of the above cloud platform, the cloud platform is deployed to the candidate server, wherein the candidate server includes servers of at least two system architectures. In this way, by detecting the candidate server that can build a cloud platform, and generating a server cluster topology file of the cloud platform that is compatible with the candidate server for the candidate server, the cloud platform can be deployed to the server including at least two system architectures. That is, by setting up a standardized process for building a cloud platform with heterogeneous servers, the process of building a cloud platform is generalized and automated, which greatly improves the deployment efficiency of the heterogeneous cloud platform, and also greatly reduces the manual parameter steps in the process of building a heterogeneous cloud platform.

[0078] In another embodiment of the present application, a specific implementation method for generating a cluster topology file is also provided. Exemplarily, the "generating a server cluster topology file of the cloud platform based on the configuration parameters of the candidate server" mentioned above includes: generating a first server cluster topology file of the cloud platform according to the node information in the configuration parameters of the candidate server; updating the first server cluster topology file according to the preset cluster topology template and the preset cluster deployment configuration file to generate a server cluster topology file of the cloud platform.

[0079] Exemplarily, the first server cluster topology file includes network topology information corresponding to each server in the candidate servers.

[0080] It is understandable that the above network topology information is the connection relationship between each candidate server in the candidate server. For example, if the candidate server includes 20 servers, the network topology information is used to indicate the location parameter information of each server in the 20 servers and the adjacent servers of each server. It is understandable that for any server in the candidate server, it can be connected to one or more servers, and the embodiment of the present application does not limit this.

[0081] Furthermore, it can be seen from the foregoing content that in an embodiment of the present application, the above-mentioned server cluster topology file includes the business role of each server in the cloud platform and the deployment parameters corresponding to the server. Therefore, the server cluster topology file is not generated once, but is formed by continuously assigning role information and deployment parameter information of the cloud platform to each server in the candidate servers. Specifically, it is formed by assigning role information and deployment parameter information of the cloud platform to each server according to the node information of each server.

[0082] In an example, the node information may be set in a server registration node list, that is, in the process of generating the first server cluster topology file and the server cluster topology file, operations may be performed on the server registration node list.

[0083] It should be noted that, for the embodiments of the present application, the above-mentioned server cluster topology file can update the first server cluster topology file through a pre-set preset cluster topology template and a preset cluster deployment configuration file; correspondingly, the first cluster topology file can also be directly updated and modified manually. The above-mentioned technical solution of the present application discusses the process of directly and automatically updating the first server cluster topology file.

[0084] Exemplarily, the above-mentioned preset cluster topology template is a pre-set template corresponding to the cloud platform, and can be used to indicate the configuration information of each server in the candidate servers.

[0085] Exemplarily, the above-mentioned preset cluster deployment configuration file is used to deploy the role sequence in the second server cluster topology file, to deploy the role tasks, and to deploy the role parameters.

[0086] Optionally, in an embodiment of the present application, the first server cluster topology file of the cloud platform is generated based on the node information in the configuration parameters of the candidate server. The cloud platform deployment method provided in the present application includes: according to the preset network relationship of the above-mentioned cloud platform, parsing the relationship between the node information of the above-mentioned candidate servers, and obtaining the network structure relationship of the above-mentioned candidate servers in the network; based on the network structure relationship, generating the first server cluster topology file of the cloud platform.

[0087] Exemplarily, the above-mentioned preset network relationship may be preset in the configuration file of the cloud platform, that is, in the process of deploying the cloud platform to the candidate server, it is necessary to pre-set the network relationship between multiple servers required by the cloud platform. Therefore, after determining the candidate server, the preset network relationship can be used to parse the relationship between the servers in the candidate server, and determine the network structure information of each server in the candidate server in the cloud platform, and finally generate a first server cluster topology file that matches the cloud platform.

[0088] It can be understood that in the process of generating the above-mentioned first server cluster topology file, it is necessary not only to set up each server in the candidate servers, but also to set up other network devices used to ensure that the candidate servers support the cloud platform deployment process, such as switches. Therefore, the first server cluster topology file actually describes the main body including candidate servers and related network devices of the candidate servers, which are collectively referred to as network devices in the subsequent specific descriptions.

[0089] In one example, the relationship between the node information of the candidate servers may be parsed by parsing the registered node list information of the candidate servers.

[0090] Exemplarily, the first server cluster topology file may be further read and updated subsequently.

[0091] The contents of the first cluster topology file include: 1) network device element; 2) network device parameter element; 3) role element; 4) role parameter element.

[0092] Each item is introduced below: 1) Network device element: The network device element is used to represent each network device node in the first server cluster topology file, that is, each node where a candidate server is located. Specifically, the candidate server can be described by device attributes. The details are as follows: a. ID attribute, used internally, marks the network device ID, determines the uniqueness of the device, and is used to organize network topology connections; b. TYPE attribute, used to describe the type of network equipment, such as server, switch, network connection, etc.; c. VALUE attribute, used to describe the name of the network device and displayed in the topology diagram; d. SOURCE attribute, used to indicate the network connection device, indicating the starting device of the network device connection, and its value is the server device ID; e. TARGET attribute, used to indicate the network connection device, indicating the end device of the network device connection, and its value is the switch device ID.

[0093] 2) Network device parameter element: The network device parameter element may include the associated parameter information of each candidate server and the associated parameter information of other network devices. A network device may have >= 0 parameters, so the number of network device parameter elements is >= 0.

[0094] 3) Role element: The role element is used to describe the business role of each candidate server and the business roles of other network devices. A network device can have >= 0 roles, so the number of role elements is >= 0.

[0095] 4) Role parameter element: The role parameter element further describes the parameter information associated with the business role. A business role can have >= 0 parameters, so the number of role parameter elements is >= 0.

[0096] Below is an example 2 and Figure 3 The process of generating the first server cluster topology file is described as follows.

[0097] Example 2: Example 2 is combined with Example 1 above. After generating the server registration node list in Example 1, the process of generating the first server cluster topology file in Example 2 is that the cluster topology module in the cloud platform deployment system processes the server registration node list to realize the first server cluster topology file.

[0098] S201: Generate a cluster network topology diagram. The cluster topology module in the cloud platform deployment system generates a host-type network device element based on the server registration node list, parses the network information of each server node in the server registration node list, and adds switch and line-type network device elements. Among them, the server nodes include: network card devices in the same network segment. These host-type network device elements can be connected to the same switch-type network device element through line-type network device elements, thereby constructing a cluster network topology diagram (that is, the first server cluster topology file mentioned above).

[0099] In Example 2, the network topology structure content in the cluster topology file can be: <cell id="1" type="host" value="服务器1" / > <cell id="2" type="switch" value="交换机1" / > <cell id="3" type="line" value="" source="1" target="2" / > Optionally, in an embodiment of the present application, the first server cluster topology file is updated according to the preset cluster topology template and the preset cluster deployment configuration file to generate a server cluster topology file of the cloud platform. The cloud platform deployment method provided in the embodiment of the present application includes: converting the first server cluster topology file into a second server cluster topology file according to the preset cluster topology template; configuring deployment parameters for the second server cluster topology file according to the preset cluster deployment configuration file to generate the server cluster topology file of the cloud platform.

[0100] Exemplarily, the above deployment parameters include: interface parameters of different services in the above cloud platform and sequence parameters of different services.

[0101] Exemplarily, the second server cluster topology file includes a correspondence between each server in the candidate servers and each role in the plurality of roles of the cloud platform.

[0102] It is understandable that, as described above, for a cloud platform, it requires multiple different servers, so the candidate servers not only have a network topology relationship and respective hardware configuration parameters, but also require the business role of each candidate server in the cloud platform.

[0103] It should be noted that, as mentioned above, in the process of cloud platform deployment, not only candidate servers are included, but also other network devices used to support the operation of candidate servers. Therefore, the server cluster topology file of the cloud platform finally generated includes candidate servers and network device parameter information related to the candidate servers.

[0104] Exemplarily, the above-mentioned preset cluster topology template is a pre-set template corresponding to the cloud platform, and can be used to indicate the role information of each server in the candidate servers.

[0105] In an example, the preset cluster topology template can be used to perform operations such as adding, deleting, modifying, and querying the first server cluster topology file. The preset cluster topology template includes network device elements and role elements, which are used to define the binding relationship between candidate servers and business roles.

[0106] Based on the above content, the first server cluster topology file can be converted into a second server cluster topology file and saved by using a preset cluster topology template.

[0107] In an example, during the conversion process of converting the first server cluster topology file into the second server cluster topology file by using the preset cluster topology template, the following operations may be performed on the first server cluster topology file: First, perform the deletion operation: 1) Delete network device elements except candidate server types; 2) Delete all network device parameter elements; 3) Delete all role parameter elements.

[0108] Secondly, the preset cluster topology template is applied to the server registration node list containing the node information of the candidate server, and a second server cluster topology file is generated according to the node parameters of the registration node list and the preset cluster topology template.

[0109] It can be understood that the second server cluster topology file includes the following application contents in the actual application process: 1) Parsing the server registration node list, binding the node information of the candidate server with the network device element of the server type in the preset cluster topology template; 2) Parsing the network information of each node in the server registration node list, adding network device elements of switch type and network connection type, and establishing a network topology mapping relationship; 3) Parsing the parameter information of each node in the server registration node list, and adding network device parameter elements according to the parameter domain; 4) According to the interface provided by the role definition module, parsing the role control parameters from the server node registration list information, and adding role parameter elements under the role elements.

[0110] Below is an example 3 and Figure 3The process of generating the second server cluster topology file and the server cluster topology file of the cloud platform is described as follows. The steps in Example 3 may be performed by a role definition module in the cloud platform deployment system.

[0111] Example 3: Example 3 is combined with Example 2 above. After the cluster network topology diagram (that is, the first server cluster topology file mentioned above) is generated in Example 2, the process of generating the second server cluster topology file in Example 3 is that the cluster topology module in the cloud platform deployment system processes the first server cluster topology file to generate the second server cluster topology file.

[0112] S202: 1) The cluster topology module in the cloud platform deployment system automatically processes the first server cluster topology file through the cluster topology module; or, 2) receiving manual role binding processing performed by the user by operating the role definition module through the visual operation interface. The method of manual role binding processing is detailed in the subsequent Example 6.

[0113] It is understandable that the cluster network topology diagram in the above example 2 (that is, the above first server cluster topology file) only reflects the network configuration of each candidate server node in the cluster formed by the candidate server. The cloud platform deployment also needs to determine the services to be deployed on the server nodes to define the cluster service topology. The nodes and service roles can be bound in the following ways: Automatic binding process: define the cluster business topology. The cluster topology module automatically applies the cluster topology template (that is, the preset cluster topology template mentioned above) to the server registration node list, thereby quickly assigning business roles to each node in the server registration node list. It should be noted that if there are server nodes with candidate servers that do not meet the configuration requirements of the roles to be bound, the cluster topology module template cannot be applied. At the same time, before applying the cluster topology module, it is necessary to ensure that the number of server nodes in the server registration node list is consistent with the number of nodes required by the template server.

[0114] In this embodiment, the service topology relationship structure is shown as follows: <cell id="0" type="host" value="服务器1"> <role value="业务角色1" priority="1" dependencies="" / > < / cell> Exemplarily, by using the above-mentioned preset cluster deployment configuration file, the second server cluster topology file is configured with sequence parameters and the like, so that after the cloud platform is subsequently deployed, tasks can be executed according to the sequence parameters.

[0115] Exemplarily, the above-mentioned preset cluster deployment configuration file can be configured according to different contents and parameters in the second server cluster topology file.

[0116] In one example, the second preset cluster topology file can be configured through the following three aspects: 1) Deploy the task segment of the second preset cluster topology file. Through the deployment of the task segment, the business deployment order and business deployment tasks can be defined, wherein the business deployment order is determined according to the role priority and dependency relationship, and the business deployment task directly references the task configuration file defined by the role definition module, and the referenced configuration file is determined according to the system release version and architecture information; 2) Deploy the role control parameter segment of the second preset cluster topology file, and the role control parameter segment information can be obtained after parsing the candidate servers of different roles; 3) Deploy the node parameter segment of the second preset cluster topology file, and the node parameter segment information can be obtained after parsing the candidate servers and the related network devices (such as switches) corresponding to the candidate servers.

[0117] Example 4: Example 4 combines the above Example 3 with reference to Figure 5 After the business topology relationship structure (that is, the above-mentioned second server cluster topology file) is generated in Example 3, the process of generating the server cluster topology file in Example 4 is that the parameter processing module in the cloud platform deployment system processes the second server cluster topology file through a preset cluster deployment configuration file to generate the server cluster topology file, specifically, deploying the role order in the second server cluster topology file, deploying the role tasks, and deploying the role parameters.

[0118] Figure 6 Schematic diagram of the steps for generating a server cluster topology file for the parameter processing module in the cloud platform deployment system. It is understandable that the second cluster topology file constructed in the aforementioned steps contains the cluster topology structure and related parameter information, but does not contain specific deployment tasks. The parameter processing module generates a cluster deployment configuration file containing the role deployment order, role deployment tasks, and role deployment parameters based on the cluster topology file. It should be noted that in Example 4, the cluster deployment configuration file is defined using yaml.

[0119] S501, service topology processing, used to determine the service deployment order and service associated nodes. Specifically, it includes: processing the host type network device element in the second server cluster topology file, reversing the mapping relationship from node to role to obtain the mapping relationship from role to node; further, sorting the roles according to the priority defined by the role and the role dependency, defining the service deployment order, the smaller the priority value, the higher the priority.

[0120] S502, business deployment task processing, is responsible for defining the role behavior of the business on a specific node, specifically including: defining the tasks segment in the second server cluster topology file, under which three role behavior segments are defined, namely preCheck, syncRepo, and deploy, and binding the business deployment order defined in the above steps to these three role behavior segments; processing the role behavior segments in sequence, and referencing the associated role behavior configuration files according to the node architecture information to which the roles are bound.

[0121] S503, parameter information processing, is responsible for converting the parameter information in the second server cluster topology file from XML attributes to YAML format, specifically as follows: processing the role parameter roleArgs attribute under the server type network device element, parsing the defined key=value, key1.key11=value and other attributes into YAML format; processing the role parameter hostArgs attribute under the server type network device element, converting it into YAML format; finally, appending the generated YAML result set to the cluster deployment configuration file.

[0122] In Example 4, the content of the finally generated cluster topology file can be: tasks: preCheck: role1: node1: tasks / LinxOS / 99 / aarch64 / preCheck.yaml node2: tasks / LinxOS / 99 / amd64 / preCheck.yaml … roleArgs: role1: node1: …… hostArgs: node1: …… Optionally, in an embodiment of the present application, the above-mentioned preset cluster topology template is pre-stored in the deployment system of the cloud platform in advance, and will be continuously updated after each application. After generating the server cluster topology file of the cloud platform, the cloud platform deployment method provided in the embodiment of the present application also includes: updating the above-mentioned preset cluster topology template through the above-mentioned server cluster topology file; storing the above-mentioned updated preset cluster topology template.

[0123] Exemplarily, the deployment system of the cloud platform includes a topology module management module, which can be used to persistently store cluster service topology templates and support management such as template creation, modification, deletion, conversion, and application.

[0124] Exemplarily, the above-mentioned preset cluster topology template is retrieved from the topology module management module.

[0125] In an example, the preset cluster topology template may be edited by operating a topology module management module, including a topology module management module.

[0126] Figure 4 A schematic diagram of the management, application, and conversion process of the preset cluster topology template by the topology management module in the cloud platform deployment system.

[0127] S301. Management of preset cluster topology files: A collection of cluster topology templates can be persistently stored and managed, providing interfaces such as query, addition, deletion, and editing. The cluster topology template is described using XML and stored as a local file in the deployment system. The visual interaction module supports parsing XML files, visually displays the binding relationship between servers and business roles, and supports direct editing on the page.

[0128] S302. Application of preset cluster topology file: The cluster business topology can be defined by applying the preset cluster topology template. It can be understood that the business set to be deployed has configuration requirements for the node. If the node does not meet the configuration requirements of the bound business, the template cannot be applied; after meeting the basic requirements, the node business role parameters are processed and bound to the corresponding node business role roleArgs element, and the node parameters are further processed and bound to the corresponding node hostArgs element.

[0129] S303, conversion of preset cluster topology file: the cluster topology file can be updated and converted into a cluster topology template for persistent storage.

[0130] It is understandable that the cluster topology template only contains the business topology relationship between nodes and business roles. The steps to save the cluster topology template are as follows: A1: Create a new topology template name and description; A2: Read the cluster topology file, remove the cluster network topology, node parameter information, and role control parameter information, and only retain the node role binding information and role dependency relationship; A3: Save the template content as an XML file and store it in the cluster topology template collection.

[0131] Optionally, in an embodiment of the present application, the above-mentioned preset cluster topology template sometimes does not have a way to fully deploy all the business roles that the users actually currently need. It is understandable that the preset cluster topology template is the needs of other users before the current cloud platform is deployed or the needs of users in the previous cloud platform deployment process, and cannot represent all the current needs of users. Therefore, the second server cluster topology file can be improved to set the server interface of the role that needs to be added, thereby setting the server role step, thereby more flexibly helping users to achieve the deployment requirements of any cloud platform they need. In the conversion of the first server cluster topology file into the second server cluster topology file, the cloud platform deployment method provided by the present application also includes: in the server corresponding to the server cluster topology file, setting other role information other than the role corresponding to the second server cluster topology file by setting the server role interface.

[0132] It is understandable that although the above preset cluster topology template has defined the role information of the candidate servers and related network devices, a flexible role change interface can be set or reserved to set the role information for the server, thereby improving the flexibility of the cloud platform deployment process.

[0133] Furthermore, the process of assigning a business role to each of the candidate servers substantially includes operations such as role creation, modification, allocation, and query. The definition of the business role is achieved by creating files such as resources, scripts, and configurations corresponding to the role.

[0134] The specific contents include the following: 1) Define the basic information of a role, including role name, role priority, role dependencies, role configuration requirements, role architecture support information, role control parameter list, and role parameter processing script. The relevant definitions are stored in the working directory of the deployment system in the form of configuration files and scripts.

[0135] Furthermore, the role priority and roles depend on the deployment order of the business roles in the subsequent preset cluster deployment configuration file.

[0136] 2) Define resource files such as software installation packages and configuration files. The relevant resource files are stored in the working directory of the deployment system, and the directory structure is organized to adapt to various architectures.

[0137] 3) The relevant role behaviors that need to be executed remotely during the role deployment process, and the relevant resource files are stored in the working directory of the deployment system, and the directory structure is organized to adapt to various architectures.

[0138] Furthermore, the role behavior is a combination of a series of deployment steps, which can be a deployment script, an executable program, etc.

[0139] Optionally, in an embodiment of the present application, in the server corresponding to the server cluster topology file, other role information other than the role corresponding to the second server cluster topology file is set by setting the server role interface. The above-mentioned cloud platform deployment method may include: according to the preset role information, parsing the second server cluster topology file and the node information of the candidate server, determining the role control parameters of the server in the candidate server corresponding to the preset role information; updating the second server cluster topology file according to the role control parameters; and setting the role of the preset role information for the candidate server according to the updated second server cluster topology file.

[0140] It can be understood that in the process of setting other role information other than the preset cluster topology template, it is necessary to update the second server cluster topology file, add the corresponding relationship between roles and server nodes for other role information other than the preset cluster topology template, and then set the preset role information for the candidate server according to the updated second server cluster topology file, and the preset role information is the newly added role.

[0141] Furthermore, in the process of setting the role corresponding to the preset role information for the candidate server, it is necessary to parse the role control parameters so that roles can be added to the preset roles of the candidate server more reasonably, so as to facilitate personalized cloud platform deployment by users.

[0142] Specifically, the role control parameters may include business role basic parameter information and role dependency parameter information. Both the role basic parameter information and the role dependency parameter information may be used to resolve the preset role corresponding to the candidate server.

[0143] Furthermore, the basic parameter information of the role is obtained by processing the node information of the candidate server; and the role-dependent parameter information is obtained by processing the basic parameter information of other roles.

[0144] Optionally, in an embodiment of the present application, after setting the server role interface in the server corresponding to the server cluster topology file, the cloud platform deployment method provided by the present application also includes: determining the role information of the cloud platform deployment process according to the cluster topology file; splitting the deployment task of the cloud platform into multiple subtasks according to the cluster topology file, the role information and the number of role information; executing the multiple subtasks in parallel to deploy the cloud platform to the candidate server.

[0145] Exemplarily, the number of the subtasks matches the number of the role information.

[0146] It should be noted that in the subsequent process of configuring role information according to the reserved role interface, the configuration process of each role should actually be completed by multiple steps. The configuration process of each role can be regarded as a subtask, and multiple subtasks can be executed in parallel to improve deployment efficiency.

[0147] Specifically, each subtask attribute defines the task type, task parameters, task execution type, and task synchronization type through related attributes.

[0148] In one example, the task type is used to define specific behaviors, including but not limited to shell command execution, Python script execution, remote file copying, etc. In one example, the task parameters obtain parameters according to a specific task type.

[0149] In one example, the task execution type deployment tasks are divided into local execution tasks and remote execution tasks, which are distinguished by this attribute.

[0150] In one example, the task synchronization type is to determine whether the task needs to be executed on the corresponding node based on a conditional expression.

[0151] The following example 5 and Figure 5 The process of setting other business roles besides the existing roles in the template corresponding to the preset cluster topology module is described. The process is provided by the role definition module, and the binding operation of the server and other roles is completed in the cluster topology module. The process of setting other business roles besides the preset cluster topology module is performed by the role definition module in the cloud platform deployment system.

[0152] Example 5: The following example 5 and Figure 5 The execution process of the role definition module in the deployment system of the above cloud platform is described as follows: The role definition module is mainly used to deploy the cloud platform deployment system. There is a roles directory under the working directory, which is used to store role definition related files. Among them, a role definition needs to fully implement related configuration, scripts and other files. The role definition module includes 3 sub-modules, namely the role basic information definition module, the role file definition module and the role behavior definition module. Among them, the role basic information definition module is responsible for defining the basic information of a role; the role file definition module is used to define the software installation package, configuration file and other resource files that the role deployment depends on; the role behavior definition module is responsible for defining the related role behaviors that need to be executed remotely during the role deployment process. The role behavior definition module defines a combination of a series of deployment steps, which complete the specified functions by executing related scripts and commands.

[0153] S401, role basic information definition module. The role basic information definition module creates a role1 directory under the roles directory, indicating that a role resource directory named role1 is created; further, a commons directory is created under the directory to define the basic information of the role.

[0154] The role name, priority, dependency and other information are defined in info.yaml. In this embodiment, the content may be: name: role2 priority: 10 dependencies: [role1] Name defines the role name, priority defines the role priority. The lower the value, the higher the priority. Dependencies defines the role dependencies. In the example, role2 depends on role1, which means that role1 needs to be deployed first to provide services for role2. Role definitions do not allow circular dependencies or conflicts between dependencies and priorities.

[0155] The role configuration requirements are defined in requirements.yaml. In this embodiment, the content may be: CPU: 2 mem: 2048MB architecture: [amd64, aarch64] cpu means that the role requires 2 cores of cpu resource allocation, mem means that the role requires 2048MB of memory, and architecture means that the role supports amd64 and aarch64 architectures.

[0156] The role parameter configuration is defined in args.yaml. In this embodiment, the content may be: serverIp: string serverPort: int role1.serverIp: string role1.serverPort: int In the example, serverIp represents the service access IP address provided by the current role role2 deployment, and its parameter type is a string. role1.serverIp represents the dependency parameter information of the role1 role that role2 depends on (that is, obtained through the role dependency parameter processing in the above role basic information definition module), and the access IP address of the service that depends on role1.

[0157] The role parameter script is defined as paramProcess.py. In this embodiment, the script can provide baseParamsProcess(hostArgs) method and depParamsProcess(roleName, roleArgs) method to process role basic parameter information and role dependent parameter information respectively. Among them, baseParamsProcess takes registration node parameter information as input, and depParamsProcess takes role name and role parameters as input.

[0158] S402, role file definition module. The role file definition module creates a files directory under the role1 directory to store deployment-related resource files; creates a packages directory to store deployment software packages; and creates a configs directory to store configuration files.

[0159] It is understandable that under the files directory, specific directories are created according to the architecture identifier to distinguish the architecture information, such as files / distribution / version / architecture / packages, so as to provide support for multiple architecture software packages and further support the deployment of heterogeneous cloud platforms.

[0160] S403, role behavior definition module. The role behavior definition module creates a tasks directory under the role1 directory, defines the task configuration files of the relevant role behaviors, and supports three types of behavior definitions: environment check, software source update, and business deployment. The environment check is defined in the preCheck.yaml file, the software source update is defined in the syncRepo.yaml file, and the business deployment is defined in the deploy.yaml file. The software source update behavior requires copying the software package from the corresponding architecture of the role file definition module, making it a local source file and updating it to the remote node.

[0161] It is understandable that under the tasks directory, specific directories are created according to the architecture identifier to distinguish the architecture information, such as files / distribution / version / architecture / deploy.yaml, to support the deployment behavior of servers with different architectures and further support the deployment of heterogeneous cloud platforms.

[0162] In the embodiment of the present application, the definition of subtask attributes is shown as follows: name: *** type: shell cmd: tar -xf / *** / ***.tar.gz remote: true condition: *** Among them, name defines the task name, type defines the task type, remote defines whether the task is executed on the remote node or the control node, and condition defines the condition for task execution. When the condition expression result is true, it means that the task needs to be executed. The above task example is a task to execute a shell command on a remote node, and cmd is the specific command to be executed.

[0163] The following example 6 and Figure 3 The process of manually binding roles is defined as follows: Example 6: The role definition module in the deployment system of the cloud platform provides a set of business roles that the deployment system supports deployment, and edits the business roles bound to the nodes in the cluster topology diagram; the role configuration requirements are defined in the role basic information. It is understandable that if the target node cannot meet the configuration requirements of the role, the binding of the role cannot be added.

[0164] In the process of manually binding roles, you need to define the node parameters of the business role.

[0165] S203, define cluster service parameters. Node parameters can be defined in the following ways: The role definition module defines a role basic parameter initialization script (that is, the role basic parameter information in the above role control parameters). The script inputs the node parameter information in the registered node list, obtains the role parameter configuration defined in yaml, provides a method for converting yaml parameters to xml parameters, and further converts them into attribute definitions under the roleArgs element of the role; parameters are parsed into roleArgs in the key=value mode. For multi-layer nested structure parameters, nested keys are defined by ".", bridge.name="bridge1"; The role definition module defines a role dependency parameter initialization script (that is, the role dependency parameter information in the above role control parameters). After all role parameters are processed, the parameter configuration information initialized for each role is used as input. After processing, the parameter information of other business roles that the role depends on is obtained, and then further converted into the attribute definition dependency parameters under the roleArgs element of the role.

[0166] The role parameter structure is as follows: <role value="业务角色1" priority="1" dependencies=""> <roleargs hostname="node1" bridge.name="bridge1" …… / > < / role> S204, define cluster node parameters. Add node parameter information to the first cluster topology file, and convert the node parameters defined in yaml in the registered node list into attribute definitions under the hostArgs sub-element under the corresponding host type network device element.

[0167] The parameter domain of the registered node list is in YAML format. A method for converting YAML parameters to XML parameters is provided. The parameters are parsed into hostArgs in key=value format. For multi-layer nested structure parameters, nested keys are defined by ".", such as cpu.nums="64".

[0168] The node parameter structure is as follows: <cell id="0" type="host" value="服务器1"> <hostargs type="os" hostname="node1" cpu.nums="64" …… / > < / cell> It is understandable that the node parameters and service role relationships newly added to the first cluster topology file in the above manual binding process can be exported to the topology template management module as an updated cluster service topology template.

[0169] S205: Save the cluster service topology. Save the updated cluster service topology template.

[0170] Optionally, in an embodiment of the present application, the cloud platform is deployed to the candidate server according to the cluster topology file. The cloud platform deployment method provided by the present application includes: detecting the deployment environment in the candidate server according to the environmental constraints in the cluster topology file; and deploying the cloud platform to the candidate server when the deployment environment meets the environmental constraints.

[0171] It is understandable that in order to ensure that new roles required for configuring the cloud platform can be flexibly adjusted at any time during the deployment of the cloud platform, the current deployment environment needs to be tested and confirmed during the configuration of the cloud platform.

[0172] It should be noted that the above-mentioned detection of the deployment environment of the candidate servers is mainly to ensure the environmental security during the process of setting the role for each server in the candidate servers and that the environment meets the deployment requirements of the current cloud platform to ensure executable.

[0173] Exemplarily, the above-mentioned environmental constraints may include at least one of the following: network environment conditions, software and hardware architecture support conditions of the candidate server, and storage conditions corresponding to the candidate server.

[0174] The following is an explanation of the process of testing the specific environment and configuring the cloud platform: 1) Perform lightweight environment check tasks to quickly locate environmental problems in the early stage of deployment. The scope of the check includes but is not limited to: whether the software and hardware architecture is supported, whether the network environment is normal, and whether the storage device is normal; 2) Perform software source synchronization tasks to provide a software package installation environment for business deployment nodes; 3) Finally, perform software installation, configuration and other tasks on the server.

[0175] Let's take a look at Example 7 and Figure 7The process of configuring the cloud platform based on the cluster topology file is defined as follows: Example 7: The cluster deployment module in the cloud platform deployment system is used to support the provision of deployment cloud platforms. The cluster deployment module can be used to remotely configure the cloud platform according to the cluster topology file, remotely perform tasks such as environment checking, software source update, and business deployment. In this embodiment, the cluster deployment module is remotely connected via SSH.

[0176] S601, remote connection, responsible for establishing a network connection with the node to be deployed, obtaining connect parameter information from the hostArgs segment, obtaining the IP address, port, user name and password in this embodiment, and performing remote connection through SSH; S602, environment check, is responsible for executing environment check tasks, which corresponds to the preCheck segment in the tasks segment in the cluster topology file. It can be understood that multiple task steps in the environment check configuration file are independent tasks and support concurrent execution; lightweight environment check tasks are executed first to quickly locate environmental problems in the early stage of deployment. The scope of the check includes but is not limited to: whether the software and hardware architecture is supported, whether the network environment is normal, and whether the storage device is normal.

[0177] S603, update the software source, responsible for packaging the software package of the corresponding architecture of the role, synchronizing it to the target server node and updating the software source, which corresponds to the syncRepo segment in the tasks segment in the cluster topology file; it can be understood that the tasks of software package packaging and remote copying of local sources need to be executed on the control node, the task execution type remote is defined as false, and the task execution type remote of updating the software source information on the target node is defined as true.

[0178] S604, business deployment, is responsible for executing tasks such as software package installation, business configuration, service startup, and business inspection on the target server node, which corresponds to the deploy segment in the tasks segment in the cluster topology file.

[0179] It can be understood that the above step 603 synchronizes the software source, and the business deployment can install the business software package through yum, dnf or apt tools; further, the business configuration-related subtasks also include subtasks of copying the configuration file from the control node to the remote node, and obtaining relevant parameters from the corresponding roleArgs segment for business configuration.

[0180] Optionally, in an embodiment of the present application, during the execution of the above method, the above cloud platform deployment process can be executed through a visual interface, that is, the deployment process of the entire cloud platform is visualized, and the rhythm of the automated deployment process can also be manually controlled. Exemplarily, the above method is applied to a cloud platform configuration interface, and the above cloud platform configuration interface includes multiple sub-interfaces. The above cloud platform deployment method includes: receiving a first input through the cloud platform configuration interface; in response to the first input, the target sub-interface in the configuration interface executes a target operation.

[0181] Exemplarily, the first input is used to perform a target operation on any sub-interface among multiple sub-interfaces in the configuration interface.

[0182] Exemplarily, the above-mentioned multiple sub-interfaces include: a server node discovery management sub-interface, a cluster topology management sub-interface, a server template management sub-interface, a server role management sub-interface, a parameter processing management interface and a cluster deployment management sub-interface.

[0183] In one example, the specific functions of the above sub-interfaces are introduced as follows: Figure 8 Shown is a module logic diagram of the visual sub-interface of this application: 1) The server node discovery management sub-interface is used to: input the node range feature information required by the node discovery module in a visual manner and communicate with the node discovery module to complete node discovery, and support the addition, deletion, editing, and display of the registered node list.

[0184] 2) The cluster topology management sub-interface is used to: support the display and editing of cluster topology, and provide cluster topology template conversion and application function operation. It is understandable that the generated network topology diagram is displayed by the cluster topology management sub-interface, and the editing function is provided for the network topology diagram.

[0185] 3) The above server template management sub-interface is used to: support cluster template addition, deletion, editing, display, etc. 4) The above server role management sub-interface is used to: support the addition, deletion, editing, and display of roles, support visual editing of role configuration, scripts, and other files, and support import and export management of configuration files, scripts, software packages, etc. It is understandable that the parameter values ​​of the role control parameter list can be manually filled in and modified on the visual page.

[0186] 5) The parameter processing management sub-interface is used to: support viewing cluster deployment file details.

[0187] 6) The cluster deployment management sub-interface is used to: support real-time viewing of deployment task execution status, such as deployment logs and deployment progress.

[0188] The following is an analysis of the overall process of the above cloud platform deployment method through Example 8: Example 8: Furthermore, the cloud platform deployment system includes multiple functional modules, and different modules are used to perform different tasks, such as Figure 8 shown.

[0189] They include: 1) Node discovery module: The node discovery module is used to detect and discover candidate servers that can be used to deploy the cloud platform.

[0190] S1: Set node range feature information through the node discovery module in the cloud platform deployment system, and set a server node registration list based on the detected candidate servers to record the remotely discovered server node information.

[0191] S2: Process the server node registration list through the cluster topology module in the cloud platform deployment system.

[0192] S3: Manage the preset cluster topology template through the topology template management module in the cloud platform deployment system.

[0193] S4: Create, modify, and define role behaviors for each server node in the cloud platform deployment process through the role definition module in the cloud platform deployment system.

[0194] S5: Edit the parameter information, topology structure, etc. of the cluster topology file in progress through the parameter processing module in the cloud platform deployment system.

[0195] S6: Deploy the cloud platform to the candidate servers according to the cluster topology file through the cluster deployment module in the cloud platform deployment system.

[0196] S7: The above S1-S6 processes are displayed through the visual interaction module in the cloud platform deployment system, and are also used to display the sub-modules in each cloud platform deployment system.

[0197] Specifically, Fig. 9 As shown, the visualization interaction module communicates and collaborates with other modules to complete the visualization interaction function, provide good human-computer interaction, and reduce the difficulty of deployment and implementation.

[0198] In the visual interaction module, area 701 can query and edit all information of registered nodes, and supports manual addition of nodes; area 702 is a collection list of cluster topology templates (preset cluster topology templates), which supports rapid application of cluster business topology templates; area 703 is a list of all business roles of the currently deployed system, and supports adding new business roles; area 704 is an applied cluster topology information display area, including but not limited to the applied topology template, cluster node information, cluster business role information, whether it is a heterogeneous cluster, etc.; area 705 is a cluster network topology diagram (that is, the first server cluster topology file), in which all nodes can be viewed. Area 706 is the node in the network topology diagram (that is, the server node), where you can query basic information such as the node network card configuration and node architecture; Area 707 is the node-business role mapping relationship, where you can view the parameter information of all related business roles of the selected node; Area 708 is the business role-node mapping relationship, where you can view the business parameters of all bound nodes under the specified business role; Area 709 is the topology management function area, which supports applying the selected cluster topology template (that is, the preset cluster topology template) to the current registered node list, or supports saving the cluster topology file as a cluster topology template.

[0199] The present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the training rule determination method described in the present application is implemented. For example, the following can be executed: Figure 1 The individual steps of the method are shown.

[0200] The present invention provides a computer program product, which includes instructions that are executed by a processor when the processor executes the instructions. Figure 1 The individual steps of the method are shown.

[0201] It should be noted that although the operations of the method of the present invention are described in a particular order in the drawings, this does not require or imply that the operations must be performed in this particular order or that all illustrated operations must be performed to achieve desired results.

[0202] Fig.10 This is a block diagram of a cloud platform deployment system according to an embodiment of the present application. The cloud platform deployment system can be deployed on a server. Fig.10 The device includes a node discovery module 1101, a cluster topology module 1102, and a cluster deployment module 1103.

[0203] The node discovery module 1101 is used to detect candidate servers, where the candidate servers are servers that meet the conditions for building a cloud platform; The cluster topology module 1102 is used to generate a server cluster topology file of the cloud platform based on the configuration parameters of the candidate servers, wherein the server cluster topology file includes: the business role of each server in the candidate servers in the cloud platform and the deployment parameters corresponding to the server; The cluster deployment module 1103 is used to deploy the cloud platform to the candidate servers according to the cluster topology file, and the candidate servers include servers of at least two system architectures.

[0204] In one embodiment, the node discovery module 1101 is specifically used to: Receiving response information sent by the server cluster, the response information including configuration parameters of the servers in the server cluster; A server registration information list is generated according to the response information, wherein the server registration information list includes configuration information of the candidate server.

[0205] In one embodiment, the node discovery module 1101 is specifically used to: Sending first detection information to the server cluster, where the first detection information is used to instruct the server receiving the first detection information to perform capability matching based on the first detection information; The receiving response information sent by the candidate server in the server cluster includes: Receive a first response message sent by the candidate server, where the first response message is information sent by the candidate server after the candidate server determines that the candidate server has the conditions for building a cloud platform through capability matching based on the cloud platform configuration requirement parameters and the configuration parameters of the candidate server.

[0206] In one embodiment, the node discovery module 1101 is specifically used to: Sending second detection information, where the second detection information is used to instruct a target server receiving the second detection information to report a current working state and server configuration parameters; The receiving response information sent by the candidate server in the server cluster includes: Receiving second response information sent by the target server, where the second response information includes a current working state and server configuration parameters of the target server; If the current working status in the second response information indicates that the target server is in an online deployable state, and the configuration parameters match the cloud platform configuration requirement parameters, the target server is determined to be a candidate server that meets the cloud platform construction conditions.

[0207] In one embodiment, the node discovery module 1101 is specifically used to: According to the response information, reading node information corresponding to the server node of the candidate server from the response information; The node information is parsed, and node registration is performed according to the node information to generate a server node information list of the cloud platform.

[0208] In one embodiment, the above-mentioned cloud platform deployment system includes a cluster topology module, and the cluster topology module is used to generate a first server cluster topology file of the cloud platform based on the node information in the configuration parameters of the candidate server, and the first server cluster topology file includes the network topology information corresponding to each server in the candidate server; according to a preset cluster topology template and a preset cluster deployment configuration file, the first server cluster topology file is updated to generate a server cluster topology file of the cloud platform.

[0209] In one embodiment, the cluster topology module is used to: parse the relationship between the node information of the candidate servers according to the preset network relationship of the cloud platform, and obtain the network structure relationship of the candidate servers in the network; A first server cluster topology file of the cloud platform is generated according to the network structure relationship.

[0210] In one embodiment, the cloud platform deployment system includes a topology template management module, the topology template management module is used to convert the first server cluster topology file into a second server cluster topology file according to the preset cluster topology template, the second server cluster topology file includes a correspondence between each server in the candidate server and each role in the multiple roles of the cloud platform; According to the preset cluster deployment configuration file, deployment parameters are configured for the second server cluster topology file to generate a server cluster topology file of the cloud platform, wherein the deployment parameters include: interface parameters of different services in the cloud platform and sequence parameters of different services.

[0211] In one embodiment, the cloud platform deployment system includes a topology template management module, and the topology template management module is used to update the preset cluster topology template through the server cluster topology file; and store the updated preset cluster topology template.

[0212] In one embodiment, the cloud platform deployment system includes a role definition module, and the role definition module is used to set other role information other than the role corresponding to the second server cluster topology file through a server role setting interface.

[0213] In one embodiment, the role definition module is specifically used to parse the second server cluster topology file and the node information of the candidate server according to preset role information, determine the role control parameters of the servers in the candidate server corresponding to the preset role information; update the second server cluster topology file according to the role control parameters; and set the role of the preset role information for the candidate server according to the updated second server cluster topology file.

[0214] In one embodiment, the role definition module is specifically used to determine the role information of the cloud platform deployment process based on the cluster topology file; split the deployment task of the cloud platform into multiple subtasks based on the cluster topology file, the role information and the number of the role information, and the number of the subtasks matches the number of the role information; execute the multiple subtasks in parallel to deploy the cloud platform to the candidate server.

[0215] In one embodiment, the above-mentioned cloud platform deployment system includes a cluster deployment module, which is used to detect the deployment environment in the candidate server according to the environmental constraints in the cluster topology file; when the deployment environment meets the environmental constraints, the cloud platform is deployed to the candidate server.

[0216] In one embodiment, the above-mentioned cloud platform deployment system includes a visualization interaction module, the visualization interaction module includes a configuration interface, the cloud platform configuration interface includes multiple sub-interfaces, and the visualization interaction module is used to receive a first input through the cloud platform configuration interface, and the first input is used to perform a target operation on any sub-interface of the multiple sub-interfaces in the configuration interface; in response to the first input, the target sub-interface in the configuration interface performs the target operation, and the multiple sub-interfaces include: server node discovery management sub-interface, cluster topology management sub-interface, server role management sub-interface, parameter processing management interface, cluster deployment management sub-interface, and server template management sub-interface.

[0217] It should be understood that the units recorded in the cloud platform deployment system correspond to the steps in the method described in the accompanying drawings. Therefore, the operations and features described above for the method are also applicable to the cloud platform deployment system and the units contained therein, and will not be repeated here. The cloud platform deployment system can be pre-implemented in a browser or other security application of a computer device, or loaded into a browser or its security application of a computer device by downloading or other means. The corresponding units in the cloud platform deployment system can cooperate with the units in the computer device to implement the solution of the embodiment of the present application.

[0218] For the several modules or units mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be embodied.

[0219] It should be noted that for details not disclosed in the cloud platform deployment system of the embodiment of the present application, please refer to the details disclosed in the above embodiments of the present application, which will not be repeated here.

[0220] Reference below Fig.11 , Fig.11 A schematic diagram of the structure of a computer device suitable for implementing the embodiments of the present application is shown. Fig.11 As shown, the computer system 1700 includes a central processing unit (CPU) 1701, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1702 or the program loaded from the storage part 1708 to the random access memory (RAM) 1703. In the RAM 1703, various programs and data required for the operation instructions of the system are also stored. The CPU 1701, the ROM 1702, and the RAM 1703 are connected to each other through a bus 1704. An input / output (I / O) interface 1705 is also connected to the bus 1704.

[0221] The following components are connected to the I / O interface 1705: an input section 1706 including a keyboard, a mouse, etc.; an output section 1707 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1708 including a hard disk, etc.; and a communication section 1709 including a network interface card such as a LAN card, a modem, etc. The communication section 1709 performs communication processing via a network such as the Internet. A drive 1710 is also connected to the I / O interface 1705 as needed. A removable medium 1711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1710 as needed, so that a computer program read therefrom is installed into the storage section 1708 as needed.

[0222] In particular, according to an embodiment of the present application, the above reference flow chart Figure 1The described process can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 1709, and / or installed from a removable medium 1711. When the computer program is executed by the central processing unit (CPU) 1701, the above-mentioned functions defined in the system of the present application are executed.

[0223] It should be noted that the computer-readable medium shown in the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium such as a computer-readable storage medium that can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, device or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0224] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operating instructions of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the aforementioned module, program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, the boxes represented by two connections can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operating instruction, or can be implemented with a combination of dedicated hardware and computer instructions.

[0225] The units or modules involved in the embodiments described in the present application may be implemented by software or hardware. The units or modules described may also be set in a processor. For example, it may be described as: a processor includes a first receiving module, a second receiving module, and a sending module. The names of these units or modules do not, in some cases, constitute limitations on the units or modules themselves.

[0226] As another aspect, the present application further provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device. The above computer-readable storage medium stores one or more programs, and when the above programs are used by one or more processors to execute the cloud platform deployment method described in the present application.

[0227] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the aforementioned disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present application (but not limited to) by each other to form a technical solution.

Claims

1. A cloud platform deployment method, characterized in that: The method comprises: Detect candidate servers, where the candidate servers are servers that meet the conditions for building a cloud platform; Based on the configuration parameters of the candidate servers, a server cluster topology file of the cloud platform is generated, wherein the server cluster topology file includes: the business role of each server in the candidate servers in the cloud platform and the deployment parameters corresponding to the server; According to the cluster topology file, the cloud platform is deployed to the candidate servers, wherein the candidate servers include servers of at least two system architectures.

2. The method according to claim 1, characterized in that The detecting candidate server comprises: Sending detection information to a server cluster, the server cluster including candidate servers, the detection information including cloud platform configuration requirement parameters; Receiving response information sent by the server cluster, the response information including configuration parameters of the servers in the server cluster; A server registration information list is generated according to the response information, wherein the server registration information list includes configuration information of the candidate server.

3. The method according to claim 2, characterized in that The sending of detection information to the server cluster includes: Sending first detection information to the server cluster, where the first detection information is used to instruct the server receiving the first detection information to perform capability matching based on the first detection information; The receiving response information sent by the candidate server in the server cluster includes: Receive a first response message sent by the candidate server, where the first response message is information sent by the candidate server after the candidate server determines that the candidate server has the conditions for building a cloud platform through capability matching based on the cloud platform configuration requirement parameters and the configuration parameters of the candidate server.

4. The method according to claim 2, characterized in that: The sending of detection information to the server cluster includes: Sending second detection information, where the second detection information is used to instruct a target server receiving the second detection information to report a current working state and server configuration parameters; The receiving response information sent by the candidate server in the server cluster includes: Receiving second response information sent by the target server, where the second response information includes a current working state and server configuration parameters of the target server; If the current working status in the second response information indicates that the target server is in an online deployable state, and the configuration parameters match the cloud platform configuration requirement parameters, the target server is determined to be a candidate server that meets the cloud platform construction conditions.

5. The method according to claim 2, characterized in that: The generating a server registration information list according to the response information includes: According to the response information, reading node information corresponding to the server node of the candidate server from the response information; The node information is parsed, and node registration is performed according to the node information to generate a server node information list of the cloud platform.

6. The method according to claim 1, characterized in that The generating of the server cluster topology file of the cloud platform based on the configuration parameters of the candidate server includes: Generate a first server cluster topology file of the cloud platform according to the node information in the configuration parameters of the candidate server, wherein the first server cluster topology file includes network topology information corresponding to each server in the candidate server; According to a preset cluster topology template and a preset cluster deployment configuration file, the first server cluster topology file is updated to generate a server cluster topology file of the cloud platform.

7. The method according to claim 6, characterized in that The step of generating a first server cluster topology file of the cloud platform according to the node information in the configuration parameters of the candidate server includes: According to the preset network relationship of the cloud platform, the relationship between the node information of the candidate server is analyzed to obtain the network structure relationship of the candidate server in the network; A first server cluster topology file of the cloud platform is generated according to the network structure relationship.

8. The method according to claim 6, characterized in that The updating of the first server cluster topology file according to the preset cluster topology template and the preset cluster deployment configuration file to generate a server cluster topology file of the cloud platform includes: According to the preset cluster topology template, converting the first server cluster topology file into a second server cluster topology file, wherein the second server cluster topology file includes a corresponding relationship between each server in the candidate servers and each role in the plurality of roles of the cloud platform; According to the preset cluster deployment configuration file, deployment parameters are configured for the second server cluster topology file to generate a server cluster topology file of the cloud platform, wherein the deployment parameters include: interface parameters of different services in the cloud platform and sequence parameters of different services.

9. The method according to claim 8, characterized in that After generating the server cluster topology file of the cloud platform, the method further includes: Updating the preset cluster topology template through the server cluster topology file; The updated preset cluster topology template is stored.

10. The method according to claim 8, characterized in that The converting the first server cluster topology file into a second server cluster topology file, the method further comprises: In the server corresponding to the server cluster topology file, other role information other than the role corresponding to the second server cluster topology file is set through a server role setting interface.

11. The method according to claim 10, characterized in that The step of setting, in the server corresponding to the server cluster topology file, other role information other than the role corresponding to the second server cluster topology file through a server role setting interface includes: According to the preset role information, parsing the second server cluster topology file and the node information of the candidate server, and determining the role control parameters of the server in the candidate server corresponding to the preset role information; Updating the second server cluster topology file according to the role control parameter; According to the updated second server cluster topology file, a role of the preset role information is set for the candidate server.

12. The method according to claim 10, characterized in that After setting other role information other than the role corresponding to the second server cluster topology file in the server corresponding to the server cluster topology file through the server role setting interface, the method further includes: Determine the role information of the cloud platform deployment process according to the cluster topology file; Splitting the deployment task of the cloud platform into a plurality of subtasks according to the cluster topology file, the role information and the number of the role information, wherein the number of the subtasks matches the number of the role information; The multiple subtasks are executed in parallel to deploy the cloud platform to the candidate server.

13. The method according to claim 1, characterized in that The step of deploying the cloud platform to the candidate server according to the cluster topology file includes: Detecting the deployment environment in the candidate server according to the environmental constraints in the cluster topology file; When the deployment environment meets the environmental constraints, the cloud platform is deployed to the candidate server.

14. The method according to claim 1, characterized in that The method is applied to a cloud platform configuration interface, the cloud platform configuration interface includes a plurality of sub-interfaces, and the method further includes: Receiving a first input through the cloud platform configuration interface, the first input being used to perform a target operation on any sub-interface of a plurality of sub-interfaces in the configuration interface; In response to the first input, the target sub-interface in the configuration interface executes the target operation, and the multiple sub-interfaces include: server node discovery management sub-interface, cluster topology management sub-interface, server role management sub-interface, parameter processing management interface, cluster deployment management sub-interface, and server template management sub-interface.

15. A cloud platform deployment system, applied to a server, characterized in that: include: A node discovery module is used to detect candidate servers, where the candidate servers are servers that meet the conditions for building a cloud platform; A cluster topology module, used to generate a server cluster topology file of the cloud platform based on the configuration parameters of the candidate servers, wherein the server cluster topology file includes: the business role of each server in the candidate servers in the cloud platform and the deployment parameters corresponding to the server; A cluster deployment module is used to deploy the cloud platform to the candidate servers according to the cluster topology file, and the candidate servers include servers of at least two system architectures.

16. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 14 is implemented.

17. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 14 is implemented.

18. A computer program product, comprising instructions, characterized in that: When the instructions are executed by a processor, the method according to any one of claims 1 to 14 is implemented.

Images