CN117692315A

CN117692315A - Cluster deployment method, related device and storage medium

Info

Publication number: CN117692315A
Application number: CN202311696212.3A
Authority: CN
Inventors: 麦合木提·买买提; 季宗耀; 马海月
Original assignee: Uniontech Software Technology Co Ltd
Current assignee: Uniontech Software Technology Co Ltd
Priority date: 2023-12-11
Filing date: 2023-12-11
Publication date: 2024-03-12

Abstract

The present disclosure relates to a method for deploying a cluster, a related device and a storage medium, the method comprising: starting a target application program; receiving deployment information corresponding to a target node sent by a user terminal; based on the target application program and the deployment information, acquiring a target deployment file corresponding to the target node, and storing the target deployment file on the server; generating a PXE starting configuration file by utilizing an onstable script; sending the PXE starting configuration file to a target node; receiving a deployment file pulling request which is sent by a target node and is generated in response to a PXE starting configuration file; and responding to the deployment file pulling request, and sending the target deployment file to the target node so that the target node can install and deploy the operating system based on the target deployment file. In the method, the automatic deployment of the clusters is realized by combining the active script with the PXE, and a user does not need to use external storage devices such as a U disk to install a system at each node, so that the deployment efficiency and success rate of the clusters can be improved.

Description

Cluster deployment method, related device and storage medium

Technical Field

The present disclosure relates to the field of computer technology, and more particularly, to a method for deploying a cluster, related devices, and a storage medium.

Background

A cluster can comprise a plurality of nodes, for example, a plurality of physical machines, and under the condition that user requests are concentrated, the cluster can more uniformly distribute a large number of user requests received at a certain moment to different nodes in the cluster for processing, so that the load pressure of each node in the cluster can be ensured to be balanced, and the situation that the node collapses due to overlarge load pressure because a large number of requests are concentrated on the same node is avoided.

In the related art, when a cluster is deployed, a usb disk or an optical disc needs to be recorded, and the recorded usb disk or optical disc is inserted into a physical machine to install a new system for the physical machine, so that the deployment of the physical machine is completed. However, once the number of nodes included in the cluster is large, for example, may be as high as several hundred or even thousands, if the user still performs the deployment of the nodes by writing the usb disk or the optical disk, a lot of labor cost and time cost are consumed, and the deployment efficiency of the cluster is low.

Disclosure of Invention

The disclosure provides a cluster deployment method, related equipment and storage medium, so as to at least solve the problem that in the related art, the efficiency of cluster deployment by means of recording a usb disk or an optical disk is very low.

According to a first aspect of an embodiment of the present disclosure, there is provided a method for deploying a cluster, applied to a server, including: starting a target application program; receiving deployment information corresponding to a target node sent by a user terminal, wherein the target node is one of a plurality of service nodes included in the cluster; based on the target application program and the deployment information, acquiring a target deployment file corresponding to the target node, and storing the target deployment file on the server; generating a PXE starting configuration file by utilizing an onstable script, wherein the PXE starting configuration file comprises a target storage position of the target deployment file on the server; sending the PXE starting configuration file to the target node; receiving a deployment file pulling request which is sent by the target node and is generated in response to the PXE starting configuration file; and responding to the deployment file pulling request, and sending the target deployment file to the target node so that the target node can install and deploy an operating system based on the target deployment file.

Optionally, the target deployment file includes an IP address, an image file, and an registration file of the target node; the obtaining the target deployment file corresponding to the target node includes: acquiring the IP address of the target node from the deployment information; acquiring the mirror image file based on the deployment information; and generating the registration file based on the target application program.

Optionally, the deployment information includes indication information for online/offline deployment; the obtaining the image file based on the deployment information includes: pulling the image file from the target website based on the address of the target website stored in the target application program under the condition that the indication information indicates that online deployment is required; and under the condition that the indication information indicates that offline deployment is required, pulling the image file from an image file warehouse pre-created on the server.

Optionally, the image file is an ISO image, and the ISO image includes kernel, initramfs and rootfs.

Optionally, the storing the target deployment file on the server includes: storing the kernel and the initumfs to a tftpboot directory of the server; and storing the rootfs into a hypertext transfer protocol directory of the server.

Optionally, before sending the PXE boot configuration file to the target node, the deployment method further includes: adding a dynamic host configuration protocol subnet on a main network card of the server; distributing a target subnet IP to the target node; the sending the PXE start configuration file to the target node includes: and sending the PXE start configuration file to the target node which is allocated with the target subnet IP.

Optionally, before acquiring the target deployment file corresponding to the target node based on the target application program and the deployment information, and storing the target deployment file on the server, the deployment method further includes: and sending a popup prompt to the user terminal based on the deployment information corresponding to the target node, wherein the popup prompt comprises prompt information for modifying the starting configuration for the target node.

Optionally, after the target deployment file is sent to the target node in response to the deployment file pull request, the deployment method further comprises: detecting the running state of each service node in the cluster through the target application program; and under the condition that the running states of the service nodes are normal running states, removing the IP address of the transition node from a load balancing configuration file corresponding to the base node through the target application program, wherein the load balancing configuration file comprises the IP address of each service node in a plurality of service nodes contained in the cluster, and the transition node and the base node are two different service nodes in the cluster.

Optionally, the receiving the deployment information corresponding to the target node sent by the user terminal includes: receiving an acquisition request of a deployment information configuration interface sent by the user terminal; responding to the acquisition request, and sending the deployment information configuration interface generated by the target application program to the user terminal; and receiving deployment information corresponding to the target node, which is input in the deployment information configuration interface by a user and is sent by the user terminal.

According to a second aspect of the embodiments of the present disclosure, there is provided a deployment method of a cluster, applied to a target node, including: receiving a PXE starting configuration file sent by a server, wherein the PXE starting configuration file is generated by the server by utilizing an existing script, the PXE starting configuration file comprises a target storage position of a target deployment file on the server, the target deployment file is a target application program started by the server, after receiving deployment information corresponding to a target node sent by a user terminal, the PXE starting configuration file is a deployment file which corresponds to the target node and is stored on the server and is acquired based on the target application program and the deployment information, and the target node is one service node of a plurality of service nodes included in the cluster; generating and sending a deployment file pulling request to the server in response to the PXE starting configuration file; receiving the target deployment file sent by the server in response to the deployment file pulling request; and installing and deploying the operating system based on the target deployment file.

Optionally, before receiving the PXE start configuration file sent by the server, the deployment method further includes: receiving a target subnet IP distributed by the server, wherein the target subnet IP is a subnet IP distributed by the server for the target node after a dynamic host configuration protocol subnet is added on a main network card of the server; the receiving the PXE start configuration file sent by the server includes: and receiving the PXE starting configuration file sent by the server through the target node distributed with the target subnet IP.

Optionally, the target node is a base node, and after the operating system is installed and deployed based on the target deployment file, the deployment method further includes: receiving a plurality of user requests; distributing the plurality of user requests to other service nodes in the cluster except the transition node based on a load balancing configuration file with the IP address of the transition node removed; the load balancing configuration file with the IP address of the transition node removed is obtained by detecting the running state of each service node in the cluster through a target application program on the service end, and removing the IP address of the transition node from the load balancing configuration file corresponding to the base node under the condition that the running state of each service node is detected to be a normal running state, wherein the load balancing configuration file comprises the IP address of each service node in a plurality of service nodes contained in the cluster, and the transition node and the base node are two different service nodes in the cluster.

Optionally, before receiving the PXE start configuration file sent by the server, the deployment method further includes: receiving a modification start configuration operation input by a user, wherein the modification start configuration operation is an operation input by the user on the target node based on a popup prompt after the user terminal receives the popup prompt sent by the server, the popup prompt comprises prompt information for modifying start configuration for the target node, and the popup prompt is a popup prompt sent to the user terminal by the server terminal receiving deployment information corresponding to the target node sent by the user terminal; and in response to the modification start-up configuration operation, modifying the start-up configuration of the target node so that the target node with the modified start-up configuration is controlled by the onstate script on the server side.

According to a third aspect of embodiments of the present disclosure, there is provided a server, including: an application program starting module configured to start a target application program; the deployment information receiving module is configured to receive deployment information corresponding to a target node sent by a user terminal, wherein the target node is one of a plurality of service nodes included in the cluster; a deployment file acquisition module configured to acquire a target deployment file corresponding to the target node based on the target application program and the deployment information, and store the target deployment file on the server; the system comprises a PXE starting configuration file generation module, a storage management module and a storage management module, wherein the PXE starting configuration file generation module is configured to generate a PXE starting configuration file by utilizing an allowable script, and the PXE starting configuration file comprises a target storage position of the target deployment file on the server; the PXE starting configuration file sending module is configured to send the PXE starting configuration file to the target node; a deployment file pulling request receiving module configured to receive a deployment file pulling request generated in response to the PXE start configuration file sent by the target node; and the deployment file sending module is configured to respond to the deployment file pulling request and send the target deployment file to the target node so that the target node can install and deploy an operating system based on the target deployment file.

Optionally, the target deployment file includes an IP address, an image file, and an registration file of the target node; the deployment file acquisition module is configured to: acquiring the IP address of the target node from the deployment information; acquiring the mirror image file based on the deployment information; and generating the registration file based on the target application program.

Optionally, the deployment information includes indication information for online/offline deployment; the deployment file acquisition module is configured to: pulling the image file from the target website based on the address of the target website stored in the target application program under the condition that the indication information indicates that online deployment is required; and under the condition that the indication information indicates that offline deployment is required, pulling the image file from an image file warehouse pre-created on the server.

Optionally, the deployment file acquisition module is configured to: storing the kernel and the initumfs to a tftpboot directory of the server; and storing the rootfs into a hypertext transfer protocol directory of the server.

Optionally, the server further includes: the subnet adding module is configured to add a dynamic host configuration protocol subnet on the main network card of the server; a subnet IP allocation module configured to allocate a target subnet IP to the target node; the PXE start profile sending module is configured to: and sending the PXE start configuration file to the target node which is allocated with the target subnet IP.

Optionally, the server further includes: and the popup prompt sending module is configured to send a popup prompt to the user terminal based on the deployment information corresponding to the target node, wherein the popup prompt comprises prompt information for modifying the starting configuration for the target node.

Optionally, the server further includes: the running state detection module is configured to detect the running state of each service node in the cluster through the target application program; the removing module is configured to remove, by the target application program, an IP address of a transition node from a load balancing configuration file corresponding to a base node when detecting that the running states of the service nodes are normal running states, where the load balancing configuration file includes an IP address of each service node in a plurality of service nodes included in the cluster, and the transition node and the base node are two different service nodes in the cluster.

Optionally, the deployment information receiving module is configured to: receiving an acquisition request of a deployment information configuration interface sent by the user terminal; responding to the acquisition request, and sending the deployment information configuration interface generated by the target application program to the user terminal; and receiving deployment information corresponding to the target node, which is input in the deployment information configuration interface by a user and is sent by the user terminal.

According to a fourth aspect of embodiments of the present disclosure, there is provided a target node comprising: the system comprises a PXE starting configuration file receiving module, a target application program and a user terminal, wherein the PXE starting configuration file receiving module is configured to receive a PXE starting configuration file sent by a server, the PXE starting configuration file is generated by the server through an existing script, the PXE starting configuration file comprises a target storage position of a target deployment file on the server, the target deployment file is the server starting a target application program, and after receiving deployment information corresponding to a target node sent by the user terminal, the target deployment file is acquired based on the target application program and the deployment information, corresponds to the target node and is stored on the server, and the target node is one of a plurality of service nodes included in the cluster; the deployment file pulling request sending module is configured to respond to the PXE starting configuration file to generate and send a deployment file pulling request to the server; the deployment file receiving module is configured to receive the target deployment file sent by the server in response to the deployment file pulling request; and the installation and deployment module is configured to install and deploy the operating system based on the target deployment file.

Optionally, the target node further includes: a subnet IP receiving module configured to receive a target subnet IP allocated by the server, where the target subnet IP is a subnet IP allocated by the server for the target node after adding a dynamic host configuration protocol subnet on a host network card of the server; the PXE start profile receiving module is configured to: and receiving the PXE starting configuration file sent by the server through the target node distributed with the target subnet IP.

Optionally, the target node is a base node, and the target node further includes: a user request receiving module configured to receive a plurality of user requests; a request distribution module configured to distribute the plurality of user requests to other service nodes in the cluster than the transition node based on a load balancing profile from which the IP address of the transition node was removed; the load balancing configuration file with the IP address of the transition node removed is obtained by detecting the running state of each service node in the cluster through a target application program on the service end, and removing the IP address of the transition node from the load balancing configuration file corresponding to the base node under the condition that the running state of each service node is detected to be a normal running state, wherein the load balancing configuration file comprises the IP address of each service node in a plurality of service nodes contained in the cluster, and the transition node and the base node are two different service nodes in the cluster.

Optionally, the target node further includes: the modification starting configuration operation receiving module is configured to receive modification starting configuration operation input by a user, wherein the modification starting configuration operation is an operation input by the user on the target node based on a popup prompt after the user terminal receives the popup prompt sent by the server, the popup prompt comprises prompt information for modifying starting configuration for the target node, and the popup prompt is a popup prompt sent to the user terminal by the server terminal for receiving deployment information corresponding to the target node sent by the user terminal; and the startup configuration modification module is configured to respond to the startup configuration modification operation and modify the startup configuration of the target node so that the target node with the startup configuration modified is controlled by the advanced script on the server side.

According to a fifth aspect of embodiments of the present disclosure, there is provided an electronic device, comprising: a processor; a memory for storing the processor-executable instructions; wherein the processor is configured to execute the instructions to implement a method of deployment of a cluster according to the present disclosure.

According to a sixth aspect of embodiments of the present disclosure, there is provided a computer readable storage medium, which when executed by a processor of an electronic device, enables the electronic device to perform a method of deployment of a cluster according to the present disclosure.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects:

in the method, the automatic deployment of the clusters is realized by adopting a mode of combining the active script and the PXE, and a system is installed at each node without using external storage equipment such as a U disk by a user, namely, without logging in each node by the user to repeatedly execute a deployment command, so that the time cost and the labor cost can be reduced, and the deployment efficiency of the clusters can be improved. In addition, because an automatic deployment mode is adopted, human factor intervention is reduced, human misoperation can be reduced to a large extent, and then the success rate of cluster deployment can be improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure and do not constitute an undue limitation on the disclosure.

FIG. 1 is a flowchart of a method of deploying a cluster, according to an example embodiment of the present disclosure;

FIG. 2 is a schematic diagram of a plurality of nodes included in a cluster in accordance with an exemplary embodiment of the disclosure;

FIG. 3 is a flowchart of another cluster deployment method in accordance with an exemplary embodiment of the present disclosure;

FIG. 4A is a flowchart of a specific implementation of a method of deploying a cluster in accordance with an exemplary embodiment of the disclosure;

FIG. 4B is a flowchart of a particular implementation of installing a deployment base node, according to an example embodiment of the present disclosure;

FIG. 5 is a block diagram of a server according to an exemplary embodiment of the present disclosure;

FIG. 6 is a block diagram of a target node according to an exemplary embodiment of the present disclosure;

fig. 7 is a block diagram of an electronic device according to an exemplary embodiment of the present disclosure.

Detailed Description

In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the foregoing figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the disclosure described herein may be capable of operation in sequences other than those illustrated or described herein. The embodiments described in the examples below are not representative of all embodiments consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.

It should be noted that, in this disclosure, "at least one of the items" refers to a case where three types of juxtaposition including "any one of the items", "a combination of any of the items", "an entirety of the items" are included. For example, "including at least one of a and B" includes three cases side by side as follows: (1) comprises A; (2) comprising B; (3) includes A and B. For example, "at least one of the first and second steps is executed", that is, three cases are juxtaposed as follows: (1) performing step one; (2) executing the second step; (3) executing the first step and the second step.

The cloud native operating system is a lightweight operating system specially designed for cloud native applications and container work loads, has the characteristics of container optimization, automatic arrangement, safety, observability and the like, can support efficient, extensible and elastic application deployment and management, can promote a cloud computing platform to exert the advantages of the cloud computing platform, and achieves faster and reliable cloud native application delivery.

The container cloud platform is a representation form of the modern PaaS, is based on a container technology, and can realize the development, deployment and management of simplified application by constructing the cloud computing platform through container arrangement and a distributed technology. Containerization refers to packaging applications and their dependencies into containers, which in turn can ensure consistency in different environments. Such container cloud platforms use container orchestration engines, e.g., kubernetes, to automatically manage the deployment, expansion, and maintenance of containers, which may speed development, shorten online cycles, improve resource utilization, and improve research, development, and operational efficiency.

In the related art, clusters may be deployed manually on bare metal machines, i.e., purely physical machines, which may generally include the following steps:

1. creating an registration file of the base node;

2. the cloud primary operating system is recorded in the U disk;

3. installing a basic node system;

4. creating an installation configuration catalog;

5. generating an ssh secret key;

6. generating install config yaml file;

7. generating an registration file, and modifying the registration file;

8. importing an offline mirror image;

9. starting an http service and providing an identification downloading link;

10. creating coredns configuration and starting a mirror image;

11. creating a haproxy configuration and starting a mirror image;

12. installing a guide node system and monitoring an installation process;

13. installing a master node system and monitoring a bootstrap guiding process;

14. installing a worker node system and monitoring an install process;

15. removing the guide node in the base node haproxy after all cluster operators are started;

16. the oc program is configured.

The cluster deployment process has strict requirements on the accuracy of configuration, the fault tolerance rate is small, and all processes need to be manually executed, for example, users are required to repeatedly execute the same operation on each node. The cluster deployment process described above may have the following drawbacks: firstly, the deployment process is complicated, manual configuration environment is needed, a plurality of configuration files are needed to be modified, and human errors are easy to occur. Secondly, the large-scale node management needs to repeatedly execute the same operation, and the workload and the time cost are increased. The time spent for cluster deployment again is too long, affecting the ability of the system to be quickly brought on-line and iterated. The final deployment process requires expertise and experience, which is difficult for non-professionals to accomplish, limiting team expansion and flexibility.

As can be seen, the current cluster deployment process is complex to operate, involves a wide knowledge range, is complex and repeated in configuration, which results in a low success rate of cluster deployment, and generally requires multiple redeployment to succeed.

In order to solve the problems in the related art, the present disclosure uses an active program to write a series of scripts, so that functions of dynamically reading and updating deployment configuration, automatically starting and stopping each container and application, storing and displaying logs, displaying detailed failure logs, and the like can be realized. In addition, the remote batch installation of the operating system is performed by using the PXE, so that the multi-architecture system installation can be realized, and the problems of large repeated workload, complex operation, time cost and excessive labor cost caused by the traditional disk engraving installation can be avoided.

The english language of "PXE" is called "Preboot Execution Environment", which is a network boot protocol that allows a computer to boot an operating system from a remote server over a network. By using PXE, a computer can be started from a remote location on the network without a local storage medium, e.g., without a hard drive or optical drive.

The above "stable" is an automated operation tool for configuring, managing and deploying computer systems and applications. It may use SSH protocols to communicate with remote computers and may use YAML-based language to define tasks and workflows. The main features of Anstable include easy learning, easy use, agent-based architecture, scalability and efficiency. It can be used to manage various types of systems including, but not limited to, linux systems, unix systems, windows systems, and the like.

Next, a detailed implementation procedure of the cluster deployment method provided in the present disclosure will be described with reference to fig. 1 to 5.

Fig. 1 is a flowchart of a cluster deployment method, according to an exemplary embodiment of the present disclosure, applied to a server.

Referring to fig. 1, in step 101, a target application may be launched. The target application program may be a beego program, and the beego program may generate a deployment information configuration interface.

In step 102, deployment information corresponding to a target node sent by a user terminal may be received. Wherein the target node may be one of a plurality of service nodes comprised by the cluster. The "plurality of service nodes comprised by the cluster" may include, but is not limited to: base nodes, transition nodes, also known as bootstrap nodes, control nodes (masters) and worker nodes (workers). Fig. 2 is a schematic diagram of a plurality of nodes included in a cluster in accordance with an exemplary embodiment of the disclosure. Referring to fig. 2, 1 base node, 1 transition node (pilot node), 3 control nodes (master), and 2 work nodes (worker) are shown together.

According to an exemplary embodiment of the present disclosure, an acquisition request of a deployment information configuration interface sent by a user terminal may be received. Illustratively, the user may enter the address of the service within the web browser of the user terminal: http:// < server IP >:8080/, and the user terminal can send an acquisition request of the deployment information configuration interface to the server.

Next, in response to the received acquisition request, the deployment information configuration interface generated by the target application program may be sent to the user terminal, i.e., the deployment information configuration interface generated by the beego program may be sent to the user terminal.

Then, the deployment information corresponding to the target node, which is input in the deployment information configuration interface by the user and sent by the user terminal, can be received. For example, the user may input all the nodes included in the cluster, for example, the deployment information corresponding to 7 nodes, into the deployment information configuration interface at one time. And, the deployment information corresponding to each node may include, but is not limited to: the IP address of the node, CPU architecture information of the node, indication information of online/offline deployment corresponding to the node, personalized deployment information corresponding to the node, and the like.

In this way, the user can set the deployment information corresponding to each node according to the own needs, that is, the user can autonomously decide which nodes the cluster needs to contain from bottom to bottom, which deployment information each node corresponds to from bottom to bottom, and the like. Therefore, in the method and the device, corresponding deployment operation can be automatically executed according to the input of the user, namely, the input of the user can be conveniently converted into the available configuration file, further, the execution of automatic deployment tasks can be realized, and the autonomy and flexibility of the deployment cluster are good. Moreover, as the node deployment information input by the user can be collected only through the web interface, namely click-to-deploy is realized, non-professional persons can be ensured to easily deploy the clusters, and the threshold of cluster deployment is reduced.

Furthermore, the server may integrate the deployment information corresponding to the target node into a JSON configuration file, and transmit the JSON configuration file as a variable to the onstable scenario of the corresponding deployment mode, so that the onstable scenario may be used to execute the deployment task. The advantage of integrating the deployment information corresponding to the target node into the JSON format is that the method is friendly to processing of a computer programming language.

According to an exemplary embodiment of the present disclosure, the beego program on the server may also configure the necessary conditions required for deploying the cluster, such as generating a password (sshkey), configuring an installation directory, and so on, based on the deployment information corresponding to the target node. The catalog of configuration installation can be: the tftpboot directory and the http directory.

After the beego program on the server has configured the necessary conditions required by the deployment of the cluster, the pop-up prompt can also be sent to the user terminal based on the deployment information corresponding to the target node. The popup prompt may include prompt information to modify the startup configuration for the target node. It should be noted that, after the target node is modified to be in the startup configuration, the target node may be controlled by the onstate scenario on the server, that is, the onstate scenario on the server may take over the target node that is modified to be in the startup configuration.

In step 103, a target deployment file corresponding to the target node may be acquired based on the target application and the deployment information, and the target deployment file may be stored on the server.

According to an exemplary embodiment of the present disclosure, the above-described target deployment file may include an IP address of the target node, an image file, and an registration file. The IP address of the target node can be obtained from the deployment information corresponding to the target node; the mirror image file can be obtained based on the deployment information corresponding to the target node; the registration file may also be generated based on the target application, i.e., the beego program. The "registration file" is mainly used to install the operating system, i.e., it is mainly used to install the operating system in cooperation with PXE.

According to an exemplary embodiment of the present disclosure, the deployment information corresponding to the target node may include indication information for online/offline deployment. In the case where the indication information indicates that online deployment is required, the image file may be pulled from the target website based on the address of the target website stored in the target application. The mirror image file can be pulled from the target website based on the address of the target website stored in the beego program; in the case where the indication information indicates that offline deployment is required, the image file may be pulled from an image file repository created in advance on the server.

Furthermore, under the condition of determining to perform offline deployment, the server side can also generate a CA certificate, wherein the CA certificate is mainly used for ensuring that data is not tampered in the process of network communication, namely in the process of communication between the server side and nodes in the cluster.

Therefore, for each node, a user can configure the indication information of online deployment or offline deployment in the deployment information corresponding to the node according to the own needs, and further the server can decide to perform online deployment or offline deployment based on the indication information, so that the autonomy and flexibility of cluster deployment are good.

According to an exemplary embodiment of the present disclosure, the image file may be an ISO image, which may contain kernel, initramfs and rootfs. Wherein the ISO image is primarily responsible for installing the operating system. The ISO image includes "kernel" mainly for starting a basic boot environment, which can start a virtual small system on physical hardware without any operating system; the ISO image contains "initrefs" that are substantially similar to "kernel" and are loaded after "kernel" is started. The ISO image contains "rootfs" which is primarily responsible for writing the entire system to the target physical machine, i.e., on top of the target machine. It should be noted that, the "image file" may include, in addition to the ISO image, a "cluster image", which is mainly to install a deployment cluster on an operating system, and belongs to the concept of an application layer.

According to an exemplary embodiment of the present disclosure, the kernel and init fs described above may be stored to a tftpboot directory of the server; and, the rootfs may be stored to a hypertext transfer protocol directory, i.e., an http directory, of the server.

In this way, in the present disclosure, an installation directory may be configured on the server, so that a specific type of deployment file may be stored under a specified directory, allowing each node to pull the deployment file from a specified location of the server, so that a phenomenon that it is difficult to comb and place the deployment file due to random storage everywhere may be avoided. And if the deployment files are randomly stored in any position, when the cluster deployment is completed and the deployment files need to be deleted, the files need to be deleted at the storage positions of various randomly arranged seventies, and management and maintenance of the deployment files are not facilitated. In the method, the various deployment files are stored in the appointed catalogs in a classified mode, and when a user wants to delete the deployment files, the catalogs in which the deployment files are located are only needed to be deleted directly, so that convenience in managing the deployment files is improved.

Configuration such as utccp-instrument generation manifests, auth may also be used. The "alifies" belongs to customized configuration corresponding to each node, and is mainly generated based on personalized deployment information in deployment information input by a user, namely, the "alifies" may be different for different nodes. For example, when a user initially inputs deployment information in a web node, for a certain node in a cluster, a possibly customized setting needs to install and deploy an instant messaging application program on the node; for another node in the cluster, the settings that may be customized require that deployment office software be installed on that node, and so on.

For "auth," the "auth" information may be the only credentials that are needed to log in to this cluster, i.e., login credentials. In practice, the "auth" may be understood as a password, but it is actually a file, whose main purpose is to perform login authentication of the cluster. And, this "auth" is also generated by the beego program on the server side.

In step 104, a PXE start-up profile may be generated using an allowable script. The PXE boot configuration file may include a target storage location of the target deployment file on the server. For example, the PXE boot configuration file may contain the storage location of each of these deployment files, respectively, on the server side, kernel, initramfs, rootfs, ignition, the IP address of the node, etc.

According to an exemplary embodiment of the present disclosure, a dynamic host configuration protocol subnet, i.e., a DHCP subnet, may be added on the host network card of the server. Next, the target node may be assigned a target subnet IP. The PXE start-up profile may then be sent to the target node that has been assigned the target subnet IP.

It should be noted that, after the target node is modified to be started and restarted, it may send a DHCP request broadcast packet for requesting the server to allocate a subnet IP. And after the server adds a DHCP subnet on the main network card and receives the DHCP request broadcast packet, a subnet IP is allocated to the target node. The server may then send the PXE start configuration file to the target node to which the subnet IP has been allocated.

Furthermore, an httpd container can be started on the server side and used for containing the igtion file and the rootfs file, i.e. the httpd container can be used for providing the igtion service and the rootfs service. And, a PXE container may also be started on the server side to provide PXE services.

In step 105, the PXE boot configuration file may be sent to the target node as previously described.

In step 106, a deployment file pull request sent by the target node in response to the PXE start-up profile may be received.

In step 107, in response to the deployment file pull request, a target deployment file may be sent to the target node to cause the target node to perform an installation deployment of the operating system based on the target deployment file. For example, the deployment files kernel, initramfs, rootfs, ignition, the IP address of the node, etc. may be sent to the target node to cause the target node to perform an installation deployment of the operating system based on the deployment files.

According to an exemplary embodiment of the present disclosure, after a target deployment file is transmitted to a target node in response to a deployment file pull request, i.e., after all nodes join a cluster, the running states of the respective service nodes in the cluster may be detected by a target application, i.e., a beego program. Under the condition that the running states of all the service nodes are detected to be normal running states, the IP address of the transition node can be removed from the load balancing configuration file corresponding to the base node through the target application program, namely the beego program. The load balancing configuration file may include an IP address of each service node in the plurality of service nodes included in the cluster, and the transition node and the base node may be two different service nodes in the cluster.

It should be noted that, when cluster deployment is performed, deployment may be performed according to the order of the base node, the transition node, that is, the guide node, the control node, and the working node, and the process of deploying each node is similar. Furthermore, the transition node plays a role in transition in the process of deploying the cluster, and after the cluster operates normally, the transition node, namely the guide node, can be removed from the cluster. Therefore, after all the nodes join the cluster, the beego program on the server can automatically detect the running state of each service node in the cluster. Under the condition that all nodes in the cluster are determined to normally operate, transition nodes in the load balancing configuration file corresponding to the base nodes can be automatically cleaned.

In this way, after the IP address of the transition node is removed from the load balancing configuration file corresponding to the base node, when the base node receives a large number of requests at the same time, the large number of requests can be distributed to other service nodes except the transition node in the cluster, and the other service nodes digest and process the requests. Therefore, in the present disclosure, the transition node can be removed from the load balancing configuration file in time after the cluster deployment is successful, that is, the nodes which cannot function in a specific scene can be removed in time, and the abnormal operation, maintenance and use of the cluster caused by the redundant node reservation are avoided.

FIG. 3 is a flowchart of another cluster deployment method applied to a target node in accordance with an exemplary embodiment of the present disclosure

Referring to fig. 3, in step 301, a PXE start-up profile sent by a server may be received. The PXE start configuration file may be generated by the server using an active scenario, and the PXE start configuration file may include a target storage location of the target deployment file on the server. The target deployment file may be a deployment file which is acquired based on the target application program and the deployment information and corresponds to the target node and is stored on the server after the target application program is started for the server and the deployment information corresponding to the target node sent by the user terminal is received. The target node may be one of a plurality of service nodes included in the cluster.

According to an exemplary embodiment of the present disclosure, before receiving the PXE boot configuration file sent by the server, a modified boot configuration operation input by the user may also be received. The modification start configuration operation may be an operation input by the user on the target node based on the popup prompt after the user terminal receives the popup prompt sent by the server. The popup prompt may include prompt information to modify the startup configuration for the target node. The popup prompt may be a popup prompt that the server receives deployment information corresponding to the target node sent by the user terminal and sent to the user terminal. And then, in response to the received modification start configuration operation, the start configuration of the target node can be modified, so that the target node subjected to the modification start configuration is controlled by the onstate script on the server side, namely, the onstate script on the server side can take over the target node subjected to the modification start configuration.

According to an exemplary embodiment of the present disclosure, before receiving the PXE start configuration file sent by the server, the target subnet IP allocated by the server may also be received. The target subnet IP may be a subnet IP allocated by the server for the target node after adding a dynamic host configuration protocol subnet on the host network card of the server. Next, the PXE start-up profile sent by the server may be received by the target node assigned to the target subnet IP.

It should be noted that, after the target node is modified to be started and restarted, it may send a DHCP request broadcast packet for requesting the server to allocate a subnet IP. And after the server adds a DHCP subnet on the main network card and receives the DHCP request broadcast packet, a subnet IP is allocated to the target node. Then, the PXE start configuration file sent by the server may be received by the target node allocated to the target subnet IP.

In step 302, a deployment file pull request may be generated and sent to a server in response to a PXE boot configuration file.

In step 303, a target deployment file sent by the server in response to the deployment file pull request may be received. Illustratively, as in the previous embodiment, the target deployment file may comprise a kernel file, an initumfs file, a rootfs file, an registration file, an IP address, and so on.

In step 304, an installation deployment of the operating system may be performed based on the target deployment file.

As described in the previous embodiment, "kernel" is used primarily to launch a most basic boot environment that can launch a virtual small system on physical hardware without any operating system; "initumfs" is substantially similar to "kernel" and is loaded after "kernel" is started; "rootfs" is mainly responsible for writing the entire system to the target physical machine, i.e., on the target machine; the "registration" file is primarily used to install the operating system, i.e., it is primarily used in conjunction with PXE to install the operating system.

According to an exemplary embodiment of the present disclosure, the target node may be a base node, and may also receive a plurality of user requests after an installation deployment of the operating system based on the target deployment file. Next, the plurality of user requests may be distributed to other service nodes in the cluster than the transition node based on the load balancing profile with the IP address of the transition node removed.

The load balancing configuration file from which the IP address of the transition node is removed may be obtained by detecting, by the target application program on the server, an operation state of each service node in the cluster, and removing the IP address of the transition node from the load balancing configuration file corresponding to the base node when detecting that the operation states of the service nodes are all normal operation states. The load balancing configuration file may include an IP address of each service node in the plurality of service nodes included in the cluster, and the transition node and the base node may be two different service nodes in the cluster.

The disclosure also provides another cluster deployment method applied to the user terminal.

The user terminal can send the deployment information corresponding to the target node to the server, so that the server obtains a target deployment file corresponding to the target node based on the target application program and the deployment information which are started in advance, and stores the target deployment file on the server. And generating a PXE start configuration file by utilizing the prior script, and sending the PXE start configuration file to the target node. And after receiving a deployment file pulling request which is sent by the target node and is generated in response to the PXE starting configuration file, responding to the deployment file pulling request and sending the target deployment file to the target node so that the target node can install and deploy the operating system based on the target deployment file. The PXE start configuration file may include a target storage location of the target deployment file on the server, where the target node may be one of a plurality of service nodes included in the cluster.

According to an exemplary embodiment of the present disclosure, an acquisition request for deploying an information configuration interface may be sent to a server. Illustratively, the user may enter the address of the service within the web browser of the user terminal: http:// < server IP >:8080/, and the user terminal can send an acquisition request of the deployment information configuration interface to the server. Then, the deployment information configuration interface sent by the server can be received and displayed, namely, the deployment information configuration interface generated by the beego program and sent by the server can be received and displayed.

Then, the deployment information corresponding to the target node input by the user in the deployment information configuration interface can be obtained. Then, the deployment information corresponding to the target node input by the user in the deployment information configuration interface can be sent to the server. For example, the user may input all the nodes included in the cluster, for example, the deployment information corresponding to 7 nodes, into the deployment information configuration interface at one time. And, the deployment information corresponding to each node may include, but is not limited to: the IP address of the node, CPU architecture information of the node, indication information of online/offline deployment corresponding to the node, personalized deployment information corresponding to the node, and the like.

In this way, the user can set the deployment information corresponding to each node according to the own needs, namely, the user can autonomously decide which nodes the cluster needs to contain from the bottom, which deployment information corresponds to each node from the bottom, and the like, and the autonomy and flexibility of deploying the cluster are good. Moreover, as the node deployment information input by the user can be collected only through the web interface, namely click-to-deploy is realized, non-professional persons can be ensured to easily deploy the clusters, and the threshold of cluster deployment is reduced.

According to the exemplary embodiment of the disclosure, after the deployment information corresponding to the target node is sent to the server, a popup prompt sent by the server may also be received. The popup prompt may include prompt information for modifying the startup configuration for the target node, where after the startup configuration of the target node is modified, the target node may be controlled by an onsite scenario on the server, that is, the onsite scenario on the server may take over the modified startup configuration of the target node.

According to the exemplary embodiment of the present disclosure, after the deployment information corresponding to the target node is sent to the server, the cluster login address, the user name and the password sent by the server may also be received. Next, one of a plurality of service nodes included in the cluster may be logged in based on the cluster login address, the user name, and the password.

It should be noted that, the user terminal may send the trunking login request to the base node based on the trunking login address, that is, based on the login address of the base node. Then, a cluster login verification page sent by the base node may be received. Next, the user name and password entered by the user within the cluster login authentication page may be obtained to send the user name and password to the base node.

The authentication pass information sent by the base node may then be received. The authentication passing information may be generated by any node after the base node forwards the user name and the password to any node of the plurality of nodes, and the any node determines that the user name and the password pass login authentication based on the received user name and the password and the user name and the password stored in advance, and the authentication passing information is transmitted to the base node. The user name and the password stored in any node in advance can be generated by the server and sent to each node in the plurality of nodes. Next, the any one node may be logged in based on the authentication pass information.

Thus, after the cluster is deployed, the base node can forward the user request to any node in the cluster for processing each time the user request is received. Furthermore, under the condition that a large number of requests are received at the same moment, the base node can forward the large number of user requests to a plurality of nodes in the cluster to share, so that the condition that the large number of user requests at the same moment are concentrated on the same node to be processed and possibly cause the node to crash due to overlarge load is avoided.

Fig. 4A is a flowchart of a specific implementation of a method of deploying a cluster according to an example embodiment of the disclosure.

Referring to fig. 4A, in step 401, a user starts a beego program on a server.

In step 402, the user may enter an address of the server within a web browser of the user terminal: http:// < server IP >:8080/, and the user terminal may send an acquisition request for deploying the information configuration interface to the server.

In step 403, the user terminal may receive the deployment information configuration interface generated by the beego program and sent by the server.

In step 404, the user inputs deployment information corresponding to the target node in the deployment information configuration interface, and the user terminal may send the deployment information corresponding to the target node to the server.

In step 405, the beego program on the server may configure the necessary conditions for deploying the cluster based on the deployment information corresponding to the target node. For example, generate a password (ssh key), configure an installation directory, and so forth. The catalog of configuration installation can be: the tftpboot directory and the http directory.

In step 406, the ue may receive the pop-up prompt sent by the server. The popup prompt may include prompt information to modify the startup configuration for the target node. It should be noted that, after the target node is modified to be in the startup configuration, the target node may be controlled by the onstate scenario on the server, that is, the onstate scenario on the server may take over the target node that is modified to be in the startup configuration.

In step 407, the user may modify the start-up configuration of the target node based on the popup prompt received by the user terminal and restart the target node.

In step 408, a deployment base node is installed.

In step 409, a deployment guidance node is installed.

In step 4010, a deployment control node is installed.

In step 4011, a deployment worker node is installed.

In step 4012, the running status of each service node in the cluster is detected by a target application on the server, i.e., a beego program.

In step 4013, if it is detected that the running states of the service nodes are all normal running states, the IP address of the bootstrap node may be removed from the load balancing configuration file corresponding to the base node by the target application program on the service side, that is, the beego program.

In step 4014, the server prompts the user terminal that the cluster has been deployed, and prompts the cluster login address, the user name, and the password.

In step 4015, the user terminal may send a trunking login request to the base node based on the trunking login address, i.e. based on the login address of the base node.

In step 4016, the user terminal may receive a cluster login authentication page sent by the base node.

In step 4017, the user terminal may obtain a user name and password entered by the user within the cluster login authentication page to send the user name and password to the base node.

In step 4018, the user terminal may receive authentication passing information transmitted by the base node. The authentication passing information may be generated by any node after the base node forwards the user name and the password to any node of the plurality of nodes, and the any node determines that the user name and the password pass login authentication based on the received user name and the password and the user name and the password stored in advance, and the authentication passing information is transmitted to the base node. The user name and the password stored in any node in advance can be generated by the server and sent to each node in the plurality of nodes.

In step 4019, the user terminal may log in to the any one of the nodes based on the authentication passing information.

Further, fig. 4B is a flowchart of a specific implementation of installing a deployment base node, according to an example embodiment of the present disclosure.

Referring to fig. 4B, in step 4081, the server initiates an onstate script.

In step 4082, the server determines to perform online/offline deployment based on the indication information for online/offline deployment included in the deployment information corresponding to the target node.

In step 4083, if the indication information indicates that online deployment is required, the server may pull the image file from the target website based on the address of the target website stored in the target application. The image file can be pulled from the target website based on the address of the target website stored in the beego program.

In step 4084, in the case where the above indication information indicates that offline deployment is required, the image file may be pulled from an image file repository created in advance on the server side. Wherein the image file may be an ISO image, which may contain kernel, initramfs and rootfs.

In step 4085, the kernel and the init fs may be stored in a tftpboot directory of the server; and, the rootfs may be stored to a hypertext transfer protocol directory, i.e., an http directory, of the server.

In step 4086, the server may generate configurations such as a fields file, an registration file, an auth file, and the like using utccp-install.

In step 4087, the server may generate a PXE boot configuration file using the allowable script. The PXE boot configuration file may include a target storage location of the target deployment file on the server. For example, the PXE boot configuration file may contain the storage location of each of these deployment files, respectively, on the server side, kernel, initramfs, rootfs, ignition, the IP address of the node, etc.

In step 4088, an httpd container may be started on the server side to accommodate the registration file and the rootfs file, i.e., the httpd container may be used to provide the registration service and the rootfs service.

In step 4089, a dynamic host configuration protocol subnet, i.e., a DHCP subnet, may be added on the host network card of the server.

In step 40810, the server may assign a target subnet IP to the target node.

In step 40811, the server may send the PXE start configuration file to the target node assigned the target subnet IP.

In step 40812, a PXE container can be started on the server side for providing PXE services.

In step 40813, the server may receive a deployment file pull request sent by the target node in response to the PXE start-up profile.

In step 40814, the server may send the target deployment file to the target node in response to the deployment file pull request, so that the target node performs installation deployment of the operating system based on the target deployment file. For example, the server may send kernel, initramfs, rootfs, ignition, the IP address of the node, etc. these deployment files to the target node, so that the target node performs installation deployment of the operating system based on these deployment files.

Fig. 5 is a block diagram of a server according to an exemplary embodiment of the present disclosure. Referring to fig. 5, the server 500 may include an application start module 501, a deployment information receiving module 502, a deployment file obtaining module 503, a PXE start profile generating module 504, a PXE start profile sending module 505, a deployment file pull request receiving module 506, and a deployment file sending module 507.

The application launch module 501 may launch a target application. The target application program may be a beego program, and the beego program may generate a deployment information configuration interface.

The deployment information receiving module 502 may receive deployment information corresponding to a target node sent by a user terminal. Wherein the target node may be one of a plurality of service nodes comprised by the cluster. The "plurality of service nodes comprised by the cluster" may include, but is not limited to: base nodes, transition nodes, also known as bootstrap nodes, control nodes (masters) and worker nodes (workers).

According to an exemplary embodiment of the present disclosure, the deployment information receiving module 502 may receive an acquisition request of a deployment information configuration interface sent by a user terminal. Illustratively, the user may enter the address of the service within the web browser of the user terminal: http:// < server IP >:8080/, and the user terminal can send an acquisition request of the deployment information configuration interface to the server.

Next, in response to the received acquisition request, the deployment information reception module 502 may send the deployment information configuration interface generated by the target application program to the user terminal, that is, may send the deployment information configuration interface generated by the beego program to the user terminal.

Then, the deployment information receiving module 502 may receive deployment information corresponding to the target node, which is input in the deployment information configuration interface by the user and sent by the user terminal. For example, the user may input all the nodes included in the cluster, for example, the deployment information corresponding to 7 nodes, into the deployment information configuration interface at one time. And, the deployment information corresponding to each node may include, but is not limited to: the IP address of the node, CPU architecture information of the node, indication information of online/offline deployment corresponding to the node, personalized deployment information corresponding to the node, and the like.

The server 500 may further include a popup prompt sending module. After the beego program on the server has configured the necessary conditions required by the deployment of the cluster, the popup prompt sending module may also send the popup prompt to the user terminal based on the deployment information corresponding to the target node. The popup prompt may include prompt information to modify the startup configuration for the target node. It should be noted that, after the target node is modified to be in the startup configuration, the target node may be controlled by the onstate scenario on the server, that is, the onstate scenario on the server may take over the target node that is modified to be in the startup configuration.

The deployment file acquisition module 503 may acquire a target deployment file corresponding to the target node based on the target application and the deployment information, and may store the target deployment file on the server side.

According to an exemplary embodiment of the present disclosure, the above-described target deployment file may include an IP address of the target node, an image file, and an registration file. The deployment file obtaining module 503 may obtain the IP address of the target node from the deployment information corresponding to the target node; the deployment file obtaining module 503 may obtain an image file based on the deployment information corresponding to the target node; the deployment file acquisition module 503 may also generate an registration file based on the target application, i.e., the beego program. The "registration file" is mainly used for installing the operating system, i.e. is mainly used for installing the operating system in cooperation with the PXE.

According to an exemplary embodiment of the present disclosure, the deployment information corresponding to the target node may include indication information for online/offline deployment. In the case where the indication information indicates that online deployment is required, the deployment file acquisition module 503 may pull an image file from the target website based on the address of the target website stored in the target application. The mirror image file can be pulled from the target website based on the address of the target website stored in the beego program; in the case where the indication information indicates that offline deployment is required, the deployment file acquisition module 503 may pull the image file from an image file repository created in advance on the server side.

Therefore, for each node, a user can configure the indication information of online deployment or offline deployment in the deployment information corresponding to the node according to the self requirement, and the server can decide to perform online deployment or offline deployment based on the indication information, so that the autonomy and flexibility of cluster deployment are good.

According to an exemplary embodiment of the present disclosure, the deployment file acquisition module 503 may store the kernel and the init fs described above to the tftpboot directory of the server; furthermore, the deployment file acquisition module 503 may store rootfs to a hypertext transfer protocol directory, i.e., an http directory, of the server.

The PXE start profile generation module 504 may generate a PXE start profile using an allowable script. The PXE boot configuration file may include a target storage location of the target deployment file on the server. For example, the PXE boot configuration file may contain the storage location of each of these deployment files, respectively, on the server side, kernel, initramfs, rootfs, ignition, the IP address of the node, etc.

According to an exemplary embodiment of the present disclosure, the server 500 may further include a subnet adding module and a subnet IP assigning module.

The subnet adding module can add a dynamic host configuration protocol subnet, namely a DHCP subnet, on the main network card of the server side. Next, the subnet IP allocation module may allocate the target subnet IP to the target node. The PXE start-up profile may then be sent to the target node that has been assigned the target subnet IP.

The PXE start profile sending module 505 may send the PXE start profile to the target node.

The deployment file pull request receiving module 506 may receive a deployment file pull request generated in response to a PXE start-up profile sent by a target node.

In response to the deployment file pull request, the deployment file sending module 507 may send the target deployment file to the target node, so that the target node performs installation deployment of the operating system based on the target deployment file. For example, the deployment files kernel, initramfs, rootfs, ignition, the IP address of the node, etc. may be sent to the target node to cause the target node to perform an installation deployment of the operating system based on the deployment files.

According to an exemplary embodiment of the present disclosure, the server 500 may further include an operation state detection module and a removal module.

After the target deployment file is sent to the target node in response to the deployment file pulling request, that is, after all nodes join the cluster, the running state detection module may detect the running state of each service node in the cluster through the target application, that is, the beego program. Under the condition that the running states of the service nodes are detected to be normal running states, the removing module can remove the IP address of the transition node from the load balancing configuration file corresponding to the base node through the target application program, namely the beego program. The load balancing configuration file may include an IP address of each service node in the plurality of service nodes included in the cluster, and the transition node and the base node may be two different service nodes in the cluster.

Fig. 6 is a block diagram of a target node according to an exemplary embodiment of the present disclosure. Referring to FIG. 6, the target node 600 may include a PXE start configuration file receiving module 601, a deployment file pull request sending module 602, a deployment file receiving module 603, and an installation deployment module 604.

The PXE start configuration file receiving module 601 may receive a PXE start configuration file sent by the server. The PXE start configuration file may be generated by the server using an active scenario, and the PXE start configuration file may include a target storage location of the target deployment file on the server. The target deployment file may be a deployment file which is acquired based on the target application program and the deployment information and corresponds to the target node and is stored on the server after the target application program is started for the server and the deployment information corresponding to the target node sent by the user terminal is received. The target node may be one of a plurality of service nodes included in the cluster.

According to an exemplary embodiment of the present disclosure, the target node 600 may further include a modify launch configuration operation receiving module and a launch configuration modifying module.

Before receiving the PXE boot configuration file sent by the server, the modified boot configuration operation receiving module may also receive a modified boot configuration operation input by a user. The modification start configuration operation may be an operation input by the user on the target node based on the popup prompt after the user terminal receives the popup prompt sent by the server. The popup prompt may include prompt information to modify the startup configuration for the target node. The popup prompt may be a popup prompt that the server receives deployment information corresponding to the target node sent by the user terminal and sent to the user terminal. Next, in response to the received modification start-up configuration operation, the start-up configuration modification module may modify the start-up configuration of the target node, so that the target node after the modification start-up configuration is controlled by the active scenario on the server, that is, the active scenario on the server may take over the target node after the modification start-up configuration.

According to an exemplary embodiment of the present disclosure, the target node 600 may further comprise a subnet IP receiving module.

Before receiving the PXE start configuration file sent by the server, the subnet IP receiving module may also receive the target subnet IP allocated by the server. The target subnet IP may be a subnet IP allocated by the server for the target node after adding a dynamic host configuration protocol subnet on the host network card of the server. Next, the PXE start-up profile sent by the server may be received by the target node assigned to the target subnet IP.

The deployment file pull request sending module 602 may generate and send a deployment file pull request to a server in response to a PXE start-up profile.

The deployment file reception module 603 may receive a target deployment file sent by the server in response to the deployment file pull request. Illustratively, as in the previous embodiment, the target deployment file may comprise a kernel file, an initumfs file, a rootfs file, an registration file, an IP address, and so on.

The install deployment module 604 may perform an install deployment of the operating system based on the target deployment file.

According to an exemplary embodiment of the present disclosure, the target node 600 may further include a user request receiving module and a request allocating module.

The target node may be a base node, and the user request receiving module may further receive a plurality of user requests after performing installation deployment of the operating system based on the target deployment file. Next, the request distribution module may distribute the plurality of user requests to other service nodes in the cluster than the transition node based on the load balancing profile with the IP address of the transition node removed.

The present disclosure also provides a user terminal that may include a deployment information sending module.

The deployment information sending module can send the deployment information corresponding to the target node to the server, so that the server obtains a target deployment file corresponding to the target node based on the target application program and the deployment information which are started in advance, and stores the target deployment file on the server. And generating a PXE start configuration file by utilizing the prior script, and sending the PXE start configuration file to the target node. And after receiving a deployment file pulling request which is sent by the target node and is generated in response to the PXE starting configuration file, responding to the deployment file pulling request and sending the target deployment file to the target node so that the target node can install and deploy the operating system based on the target deployment file. The PXE start configuration file may include a target storage location of the target deployment file on the server, where the target node may be one of a plurality of service nodes included in the cluster.

According to an exemplary embodiment of the present disclosure, the deployment information sending module may send an acquisition request of the deployment information configuration interface to the server. Illustratively, the user may enter the address of the service within the web browser of the user terminal: http:// < server IP >:8080/, and the user terminal can send an acquisition request of the deployment information configuration interface to the server. Then, the deployment information sending module can receive and display the deployment information configuration interface sent by the server, namely, the deployment information configuration interface generated by the beego program and sent by the server can be received and displayed.

Then, the deployment information sending module can obtain the deployment information corresponding to the target node input by the user in the deployment information configuration interface. Then, the deployment information sending module may send deployment information corresponding to the target node input by the user in the deployment information configuration interface to the server. For example, the user may input all the nodes included in the cluster, for example, the deployment information corresponding to 7 nodes, into the deployment information configuration interface at one time. And, the deployment information corresponding to each node may include, but is not limited to: the IP address of the node, CPU architecture information of the node, indication information of online/offline deployment corresponding to the node, personalized deployment information corresponding to the node, and the like.

According to an exemplary embodiment of the present disclosure, the user terminal may further include a popup prompt receiving module.

After the deployment information corresponding to the target node is sent to the server, the popup prompt receiving module can also receive the popup prompt sent by the server. The popup prompt may include prompt information for modifying the startup configuration for the target node, where after the startup configuration of the target node is modified, the target node may be controlled by an onsite scenario on the server, that is, the onsite scenario on the server may take over the modified startup configuration of the target node.

According to an exemplary embodiment of the present disclosure, the user terminal may further include a login information receiving module and a login module.

After the deployment information corresponding to the target node is sent to the server, the login information receiving module can also receive the cluster login address, the user name and the password sent by the server. Next, the login module may login to one of the plurality of service nodes included in the cluster based on the cluster login address, the user name, and the password.

Fig. 7 is a block diagram of an electronic device 700 according to an exemplary embodiment of the present disclosure. Referring to fig. 7, an electronic device 700 includes at least one memory 701 and at least one processor 702, the at least one memory 701 having instructions stored therein that, when executed by the at least one processor 702, perform a method of deploying a cluster according to an exemplary embodiment of the disclosure.

By way of example, the electronic device 700 may be a PC computer, tablet device, personal digital assistant, smart phone, or other device capable of executing the instructions described above. Here, the electronic device 700 is not necessarily a single electronic device, but may be any apparatus or a collection of circuits capable of executing the above-described instructions (or instruction set) individually or in combination. The electronic device 700 may also be part of an integrated control system or system manager, or may be configured as a portable electronic device that interfaces with either locally or remotely (e.g., via wireless transmission).

In electronic device 700, processor 702 may include a Central Processing Unit (CPU), a Graphics Processor (GPU), a programmable logic device, a special purpose processor system, a microcontroller, or a microprocessor. By way of example, and not limitation, processors may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, and the like.

The processor 702 may execute instructions or code stored in the memory 701, wherein the memory 701 may also store data. The instructions and data may also be transmitted and received over a network via a network interface device, which may employ any known transmission protocol.

The memory 701 may be integrated with the processor 702, for example, RAM or flash memory disposed within an integrated circuit microprocessor or the like. In addition, the memory 701 may include a separate device, such as an external disk drive, a storage array, or any other storage device usable by a database system. The memory 701 and the processor 702 may be operatively coupled or may communicate with each other, for example, through an I/O port, a network connection, etc., such that the processor 702 is able to read files stored in the memory.

In addition, the electronic device 700 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device 700 may be connected to each other via a bus and/or a network.

According to an exemplary embodiment of the present disclosure, a computer-readable storage medium may also be provided, which when executed by a processor of an electronic device, enables the electronic device to perform the above-described cluster deployment method. Examples of the computer readable storage medium herein include: read-only memory (ROM), random-access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random-access memory (RAM), dynamic random-access memory (DRAM), static random-access memory (SRAM), flash memory, nonvolatile memory, CD-ROM, CD-R, CD + R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD + R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, blu-ray or optical disk storage, hard Disk Drives (HDD), solid State Disks (SSD), card memory (such as multimedia cards, secure Digital (SD) cards or ultra-fast digital (XD) cards), magnetic tape, floppy disks, magneto-optical data storage, hard disks, solid state disks, and any other means configured to store computer programs and any associated data, data files and data structures in a non-transitory manner and to provide the computer programs and any associated data, data files and data structures to a processor or computer to enable the processor or computer to execute the programs. The computer programs in the computer readable storage media described above can be run in an environment deployed in a computer device, such as a client, host, proxy device, server, etc., and further, in one example, the computer programs and any associated data, data files, and data structures are distributed across networked computer systems such that the computer programs and any associated data, data files, and data structures are stored, accessed, and executed in a distributed fashion by one or more processors or computers.

According to the method, the related equipment and the storage medium for deploying the clusters, the automatic deployment of the clusters is realized by adopting the mode of combining the active script and the PXE, and a user does not need to use external storage equipment such as a U disk and the like to install a system at each node, namely, the user does not need to log in each node to repeatedly execute a deployment command, so that the time cost and the labor cost can be reduced, and the deployment efficiency of the clusters can be further improved. In addition, because an automatic deployment mode is adopted, human factor intervention is reduced, human misoperation can be reduced to a large extent, and then the success rate of cluster deployment can be improved.

Further, the user can set deployment information corresponding to each node according to own needs, that is, the user can autonomously decide which nodes the cluster needs to contain from the bottom, which deployment information each node corresponds to from the bottom, and the like. Therefore, in the method and the device, corresponding deployment operation can be automatically executed according to the input of the user, namely, the input of the user can be conveniently converted into the available configuration file, further, the execution of automatic deployment tasks can be realized, and the autonomy and flexibility of the deployment cluster are good. Moreover, as the node deployment information input by the user can be collected only through the web interface, namely click-to-deploy is realized, non-professional persons can be ensured to easily deploy the clusters, and the threshold of cluster deployment is reduced.

Further, for each node, the user can configure the indication information of online deployment or offline deployment in the deployment information corresponding to the node according to the own needs, and then the server can decide to perform online deployment or offline deployment based on the indication information, so that the autonomy and flexibility of cluster deployment are good.

Furthermore, an installation catalog can be configured on the server, and then a specific type of deployment file can be stored under the designated catalog, so that each node is allowed to pull the deployment file from the designated position of the server, and the phenomenon that the deployment file is difficult to comb and place due to random storage everywhere can be avoided. And if the deployment files are randomly stored in any position, when the cluster deployment is completed and the deployment files need to be deleted, the files need to be deleted at the storage positions of various randomly arranged seventies, and management and maintenance of the deployment files are not facilitated. In the method, the various deployment files are stored in the appointed catalogs in a classified mode, and when a user wants to delete the deployment files, the catalogs in which the deployment files are located are only needed to be deleted directly, so that convenience in managing the deployment files is improved.

Furthermore, the transition nodes can be removed from the load balancing configuration file in time after the cluster deployment is successful, so that the nodes which cannot be used in a specific scene can be removed in time, and the abnormal operation and maintenance and use of the cluster caused by the reservation of redundant nodes are avoided.

Further, after the cluster is deployed, the base node may forward the user request to any node in the cluster for processing each time the user request is received. Furthermore, under the condition that a large number of requests are received at the same moment, the base node can forward the large number of user requests to a plurality of nodes in the cluster to share, so that the condition that the large number of user requests at the same moment are concentrated on the same node to be processed and possibly cause the node to crash due to overlarge load is avoided.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This disclosure is intended to cover any adaptations, uses, or adaptations of the disclosure following the general principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. The deployment method of the cluster is applied to a server and is characterized by comprising the following steps:

starting a target application program;

receiving deployment information corresponding to a target node sent by a user terminal, wherein the target node is one of a plurality of service nodes included in the cluster;

based on the target application program and the deployment information, acquiring a target deployment file corresponding to the target node, and storing the target deployment file on the server;

generating a PXE starting configuration file by utilizing an onstable script, wherein the PXE starting configuration file comprises a target storage position of the target deployment file on the server;

sending the PXE starting configuration file to the target node;

receiving a deployment file pulling request which is sent by the target node and is generated in response to the PXE starting configuration file;

and responding to the deployment file pulling request, and sending the target deployment file to the target node so that the target node can install and deploy an operating system based on the target deployment file.

2. The deployment method of claim 1 wherein the target deployment file comprises an IP address of the target node, an image file, and an registration file;

the obtaining the target deployment file corresponding to the target node includes:

acquiring the IP address of the target node from the deployment information;

acquiring the mirror image file based on the deployment information;

and generating the registration file based on the target application program.

3. The deployment method of claim 2, wherein the deployment information comprises indication information of online/offline deployment;

the obtaining the image file based on the deployment information includes:

pulling the image file from the target website based on the address of the target website stored in the target application program under the condition that the indication information indicates that online deployment is required;

and under the condition that the indication information indicates that offline deployment is required, pulling the image file from an image file warehouse pre-created on the server.

4. A method for deploying a cluster, applied to a target node, comprising:

Receiving a PXE starting configuration file sent by a server, wherein the PXE starting configuration file is generated by the server by utilizing an existing script, the PXE starting configuration file comprises a target storage position of a target deployment file on the server, the target deployment file is a target application program started by the server, after receiving deployment information corresponding to a target node sent by a user terminal, the PXE starting configuration file is a deployment file which corresponds to the target node and is stored on the server and is acquired based on the target application program and the deployment information, and the target node is one service node of a plurality of service nodes included in the cluster;

generating and sending a deployment file pulling request to the server in response to the PXE starting configuration file;

receiving the target deployment file sent by the server in response to the deployment file pulling request;

and installing and deploying the operating system based on the target deployment file.

5. The deployment method as recited in claim 4, wherein before receiving the PXE boot configuration file sent by the server, the deployment method further comprises:

Receiving a target subnet IP distributed by the server, wherein the target subnet IP is a subnet IP distributed by the server for the target node after a dynamic host configuration protocol subnet is added on a main network card of the server;

the receiving the PXE start configuration file sent by the server includes:

and receiving the PXE starting configuration file sent by the server through the target node distributed with the target subnet IP.

6. The deployment method of claim 4, wherein the target node is a base node, the deployment method further comprising, after the installation deployment of the operating system based on the target deployment file:

receiving a plurality of user requests;

distributing the plurality of user requests to other service nodes in the cluster except the transition node based on a load balancing configuration file with the IP address of the transition node removed;

the load balancing configuration file with the IP address of the transition node removed is obtained by detecting the running state of each service node in the cluster through a target application program on the service end, and removing the IP address of the transition node from the load balancing configuration file corresponding to the base node under the condition that the running state of each service node is detected to be a normal running state, wherein the load balancing configuration file comprises the IP address of each service node in a plurality of service nodes contained in the cluster, and the transition node and the base node are two different service nodes in the cluster.

7. A server, comprising:

an application program starting module configured to start a target application program;

the deployment information receiving module is configured to receive deployment information corresponding to a target node sent by a user terminal, wherein the target node is one of a plurality of service nodes included in the cluster;

a deployment file acquisition module configured to acquire a target deployment file corresponding to the target node based on the target application program and the deployment information, and store the target deployment file on the server;

the system comprises a PXE starting configuration file generation module, a storage management module and a storage management module, wherein the PXE starting configuration file generation module is configured to generate a PXE starting configuration file by utilizing an allowable script, and the PXE starting configuration file comprises a target storage position of the target deployment file on the server;

the PXE starting configuration file sending module is configured to send the PXE starting configuration file to the target node;

a deployment file pulling request receiving module configured to receive a deployment file pulling request generated in response to the PXE start configuration file sent by the target node;

and the deployment file sending module is configured to respond to the deployment file pulling request and send the target deployment file to the target node so that the target node can install and deploy an operating system based on the target deployment file.

8. A target node, comprising:

the system comprises a PXE starting configuration file receiving module, a target application program and a user terminal, wherein the PXE starting configuration file receiving module is configured to receive a PXE starting configuration file sent by a server, the PXE starting configuration file is generated by the server through an existing script, the PXE starting configuration file comprises a target storage position of a target deployment file on the server, the target deployment file is the server starting a target application program, and after receiving deployment information corresponding to a target node sent by the user terminal, the target deployment file is acquired based on the target application program and the deployment information, corresponds to the target node and is stored on the server, and the target node is one of a plurality of service nodes included in the cluster;

the deployment file pulling request sending module is configured to respond to the PXE starting configuration file to generate and send a deployment file pulling request to the server;

the deployment file receiving module is configured to receive the target deployment file sent by the server in response to the deployment file pulling request;

and the installation and deployment module is configured to install and deploy the operating system based on the target deployment file.

9. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the method of deploying a cluster according to any one of claims 1 to 3 and claims 4 to 6.

10. A computer readable storage medium, characterized in that instructions in the computer readable storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the method of deployment of a cluster according to any of claims 1 to 3, 4 to 6.