CN117221320A

CN117221320A - Cloud entering method and device for bare metal server, processing equipment and readable storage medium

Info

Publication number: CN117221320A
Application number: CN202311255315.6A
Authority: CN
Inventors: 王宽
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Priority date: 2023-09-26
Filing date: 2023-09-26
Publication date: 2023-12-12

Abstract

The invention provides a cloud entering method and device of a bare metal server, processing equipment and a readable storage medium, and relates to the technical field of cloud resource deployment. The method comprises the following steps: acquiring first information corresponding to at least one first bare metal server, wherein the first information comprises: the first bare metal server is at least one bare metal server to be cloud successfully subjected to self-checking in the bare metal server to be cloud successfully; according to the first information corresponding to the at least one first bare metal server, each first bare metal server is verified to obtain a second bare metal server, and the second bare metal server is at least one first bare metal server which is verified successfully; and deploying and recycling each second bare metal server to realize cloud entering of the second bare metal server. The scheme of the invention solves the problem that the existing cloud entering method of the bare metal server is low in efficiency.

Description

Cloud entering method and device for bare metal server, processing equipment and readable storage medium

Technical Field

The invention relates to the technical field of cloud resource deployment, in particular to a bare metal server cloud entering method, a device, processing equipment and a readable storage medium.

Background

The bare metal server particularly refers to a physical server without an operating system deployed, has the advantages of strong computing capacity, exclusive resources, safe isolation and the like compared with a virtual machine, and is widely used in a private cloud environment. The bare metal server can be provided for the tenant to use after being checked and configured by hardware, software and network before entering the cloud.

The Ironic is intended to provide self-service bare metal management services to users, and can be used independently or integrated with OpenStack. The bare metal cloud entering method based on OpenStack at the present stage is mainly realized by calling a trivial interface of an Ironic component, and provides service for the management of full life cycles such as self-checking, deployment, recovery and the like after the bare metal server enters the cloud through the Ironic component.

However, in the self-checking operation, the Ironic entity cannot complete all the work, and still needs to be manually entered, and furthermore, the hardware integration work needs to be manually completed, and the bare metal server after self-checking also needs to be manually inserted to perform hardware integration quality check, so as to ensure that the hardware configuration is correct, the network connection is correct, and the like. Therefore, the work involved in cloud entry of the bare metal server is difficult to automatically complete by the Ironic at present, most of the work still needs to be completed through manual checking and comparison, and the cloud entry efficiency of the bare metal server is low.

Disclosure of Invention

The invention aims to provide a cloud entering method, device, processing equipment and readable storage medium of a bare metal server, which solve the problem of low efficiency of the existing cloud entering method of the bare metal server.

In order to achieve the above objective, an embodiment of the present invention provides a bare metal server cloud entry method, including:

acquiring first information corresponding to at least one first bare metal server, wherein the first information comprises: the first bare metal server is at least one bare metal server to be cloud successfully subjected to self-checking in the bare metal server to be cloud successfully;

according to the first information corresponding to the at least one first bare metal server, each first bare metal server is verified to obtain a second bare metal server, and the second bare metal server is at least one first bare metal server which is verified successfully;

and deploying and recycling each second bare metal server to realize cloud entering of the second bare metal server.

In order to achieve the above object, an embodiment of the present invention provides a bare metal server cloud entering device, including:

the processing module is used for acquiring first information corresponding to at least one first bare metal server, wherein the first information comprises: the first bare metal server is at least one bare metal server to be cloud successfully subjected to self-checking in the bare metal server to be cloud successfully;

The verification module is used for verifying each first bare metal server according to the first information corresponding to the at least one first bare metal server to obtain a second bare metal server, wherein the second bare metal server is at least one first bare metal server which is successfully verified;

the deployment module is used for deploying and recovering each second bare metal server to realize cloud entering of the second bare metal server.

To achieve the above object, an embodiment of the present invention provides a processing device including a processor and a transceiver, wherein the processor is configured to:

To achieve the above object, an embodiment of the present invention provides a processing apparatus including a transceiver, a processor, a memory, and a program or instructions stored on the memory and executable on the processor; and when executing a program or an instruction, the processor realizes the bare metal server cloud entering method.

To achieve the above object, an embodiment of the present invention provides a readable storage medium having stored thereon a program or instructions which, when executed by a processor, implement the steps in a bare metal server cloud entering method as described above.

The technical scheme of the invention has the following beneficial effects:

according to the method provided by the embodiment of the invention, through obtaining the first information corresponding to at least one first bare metal server (the bare metal server to be cloud successfully detected), each first bare metal server can be verified according to the first information corresponding to the first bare metal server to obtain a second bare metal server (at least one first bare metal server successfully verified), and then each second bare metal server is deployed and recovered to realize cloud entering of the second bare metal server. Therefore, batch cloud entering of at least one bare metal server to be cloud-entering can be automatically realized, and cloud entering efficiency of the bare metal server is effectively improved.

Drawings

FIG. 1 is a flow chart of a bare metal server cloud entering method according to an embodiment of the invention;

FIG. 2 is a schematic flow chart of a bare metal batch cloud entry system according to an embodiment of the present invention;

FIG. 3 is a schematic flow chart of self-checking according to an embodiment of the present invention;

FIG. 4 is a schematic diagram illustrating a verification process according to an embodiment of the present invention;

FIG. 5 is a schematic flow diagram of deployment reclamation of an embodiment of the present invention;

fig. 6 is a block diagram of a bare metal server cloud entry device according to an embodiment of the present invention;

FIG. 7 is a block diagram of a processing device according to an embodiment of the present invention;

fig. 8 is a block diagram of a processing apparatus according to another embodiment of the present invention.

Detailed Description

In order to make the technical problems, technical solutions and advantages to be solved more apparent, the following detailed description will be given with reference to the accompanying drawings and specific embodiments.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

In various embodiments of the present application, it should be understood that the sequence numbers of the following processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

In addition, the terms "system" and "network" are often used interchangeably herein.

In the embodiments provided herein, it should be understood that "B corresponding to a" means that B is associated with a from which B may be determined. It should also be understood that determining B from a does not mean determining B from a alone, but may also determine B from a and/or other information.

The related art will be first described below.

As cloud demand increases on various systems of an enterprise, the number of bare metal servers used in a cloud computing environment increases.

The bare metal server can be provided for the tenant to use after being checked and configured by hardware, software and network before entering the cloud. The inspection method before cloud entry of the bare metal server at the present stage mainly comprises the following steps: firstly, manually pre-installing an operating system and configuring a network for a full-quantity bare metal server, then checking information such as server hardware configuration, network connection information and the like, and carrying out detection after problematic feedback to a hardware integration side for processing, wherein the mode has poor convenience and low efficiency; secondly, a software integration engineer writes a script with fixed configuration parameters in advance according to hardware configuration and network configuration, and the script is utilized for checking, so that the method improves the checking efficiency of part of bare metal servers, but because the parameters are fixed, accurate checking is difficult to be carried out on the bare metal servers with different models; thirdly, grouping a plurality of bare metal servers according to hardware configuration, then selecting a part of bare metal servers in each grouping as a representative, and performing operating system installation to complete hardware configuration and network state detection.

In the cloud environment built by OpenStack, the cloud environment built by OpenStack provides service for management of full life cycles of self-checking, deployment, recovery and the like after a bare metal server enters the cloud through an ironic component. When the physical server finishes the work of hardware up-loading, network connection and the like, cloud self-checking operation needs to be finished on the bare metal server, and the process uses an Ironic aspect service function to realize the collection of hardware configuration information and upper-connection switch information of the bare metal server (Bare Metal Server, BMS), but based on the difference of specific drivers and agent implementation modes, the Ironic aspect can not finish all the work, and manual input is still needed. After the BMS finishes cloud self-checking, entering a deployment stage, wherein tenants use information such as an ironic provisioning service function designated mirror image, a network and the like to deploy BMS examples according to service requirements, then perform work such as resource scheduling, operating system installation, network configuration and the like, and finally finish delivery of service system resources. The BMS node configuration and data are cleaned at the stage after the tenant does not use the BMS system resource any more, and the bare metal node which is always pure is ensured to be provided for the subsequent tenant.

In the actual cloud computing environment integration process, the bare metal is often subjected to various problems such as large scale, tight delivery, hard collection and the like, thousands of physical servers are faced, the hardware integration quality is uneven, the problems such as hardware faults, optical fiber connection errors, server configuration anomalies and the like are often caused after self-inspection, at this time, the server of each nanotube needs to be manually involved, the nanotube failure is collected, or the hard collection is carried out after the hard collection is carried out, the hard collection is modified, the nanotube is again carried out, time and effort are wasted, the server with successful self-inspection and correct hard collection is also required to be subjected to example deployment and release test, and the release resource after the test is normal can be added into the current network environment for use by clients.

In addition, the bare metal server with the problem of hardware configuration or network connection needs to be subjected to re-self-inspection, and the state of the bare metal server needs to be manually switched and residual data needs to be manually cleaned before re-self-inspection, and after self-inspection, a self-inspection link before cloud entry is absent, and cloud can be directly accessed for tenants to use, so that the quality of large-scale bare metal cloud entry is difficult to ensure.

As shown in fig. 1, a bare metal server cloud entering method according to an embodiment of the present invention includes:

Step 101, obtaining first information corresponding to at least one first bare metal server, where the first information includes: the cloud bare metal server comprises first hardware configuration information and first network connection information, wherein the first bare metal server is at least one cloud bare metal server to be successfully self-checked in the cloud bare metal server.

It should be noted that, a unique node-id may be configured for each bare metal server to be cloud, so that the node identifiers correspond to the bare metal servers to be cloud one by one. The first information includes first hardware configuration information and first network connection information corresponding to each node identifier, and may obtain first information corresponding to the first bare metal server according to the node identifier corresponding to the first bare metal server.

In step 101, the first information corresponding to the first bare metal server (the cloud bare metal server to be successfully self-inspected) is obtained, so that the next verification can be performed on the cloud bare metal server to be successfully self-inspected, and the self-inspected bare metal server to be unsuccessfully self-inspected can be re-inspected, or relevant information (such as node identification, failure reason, etc.) of the cloud bare metal server to be unsuccessfully self-inspected is output, so that relevant personnel can modify the cloud bare metal server to be unsuccessfully self-inspected according to the information.

Step 102, verifying each first bare metal server according to the first information corresponding to the at least one first bare metal server to obtain a second bare metal server, wherein the second bare metal server is at least one first bare metal server with successful verification.

Through step 102, the bare metal server to be plugged into which the verification is successful can be screened, so that the bare metal server to be plugged into which the verification is unsuccessful can be rectified, and step 103 can be continued for the bare metal server to be plugged into which the verification is successful.

And step 103, deploying and recycling each second bare metal server to realize cloud entering of the second bare metal server.

In this embodiment, by acquiring first information corresponding to at least one first bare metal server (a cloud to be bare metal server with a successful self-inspection), each first bare metal server may be checked according to the first information corresponding to the first bare metal server to obtain a second bare metal server (at least one first bare metal server with a successful check), and then, each second bare metal server is deployed and recovered to implement cloud entry of the second bare metal server. Therefore, batch cloud entering of at least one bare metal server to be cloud-entering can be automatically realized, and cloud entering efficiency of the bare metal server is effectively improved.

In large-scale cloud computing resource pool project construction, there is a software integration requirement that a large-scale bare metal server enters the cloud. As shown in fig. 2, in an alternative embodiment of the present invention, a bare metal batch cloud entering system is constructed based on the bare metal server cloud entering method provided by the embodiment of the present invention, where the system mainly includes three decoupling modules: the automatic self-checking module, the automatic checking module and the automatic deployment module can be specifically constructed by using the technologies of python/openstack/mysql and the like. After the total bare metal servers are processed through the system, a successful bare metal list (success_list) and a failed bare metal list (failed_list) of the cloud can be automatically output, wherein the bare metal servers with successful cloud entry can be provided for tenants at any time, and the bare metal servers with failed cloud entry can be purposefully modified according to the output result of the automatic verification module, and then self-detection is carried out again until the cloud entry is successful. Therefore, batch deployment cloud entering work of the bare metal server to be cloud entering can be completed through the three modules, and cloud entering efficiency of the bare metal server is improved.

In some embodiments, in step 101, the obtaining first information corresponding to the at least one first bare metal server may specifically include the following steps:

And step 1011, judging whether the node state of each to-be-accessed cloud bare metal server is manageable or not according to each to-be-accessed cloud bare metal server.

In this step, a full-scale cloud-to-be-added BMS list (i.e., node_list, including at least one cloud-to-be-added bare metal node-id) may be received, and node identification (node-id) of the cloud-to-be-added bare metal server is included in the cloud-to-be-added BMS list. According to the to-be-cloud BMS list, an aspect operation may be performed on the to-be-cloud bare metal server, and for each node identifier in the to-be-cloud BMS list, it is checked whether a node state (node state) of the to-be-cloud bare metal server corresponding to the node identifier is manageable.

Step 1012, if the node status of the to-be-included bare metal server is manageable, performing inclusion management on the to-be-included bare metal server.

Here, the inclusion management, i.e., the nanotube, may perform a nanotube job on the to-be-included cloud bare metal server using an ironic aspect function call related interface, for example.

It should be noted that, if the node state is abnormal (i.e., the node state is not manageable), an ironic related API interface may be called to perform state switching on the cloud bare metal server to be in the abnormal node state, so as to set the node state as manageable.

Optionally, in step 1012, before performing inclusion management on the to-be-included cloud bare metal server, the method further includes: judging whether target data exist on the bare metal server to be cloud-loaded, wherein the target data comprise data related to inclusion management; and deleting the target data under the condition that the target data exist on the to-be-cloud bare metal server.

That is, after the node status checking is completed, it may be detected whether there is residual data (i.e., target data) in the bare metal server to be cloud. Here, the residual data may specifically be information such as a port (port), a port group (port group), etc. that has been remained in the previous nanotube. If the residual data on the bare metal server to be cloud-to-be-accessed is detected, the residual data can be deleted through related software codes.

And step 1013, judging whether the node state of the to-be-cloud bare metal server after the management is included is manageable.

Since the node status of the to-be-included cloud bare metal server after the management may change, it is required to confirm again in step 1013 whether the node status of the to-be-included cloud bare metal server is manageable.

Step 1014, if the node status of the managed to-be-included bare metal server is manageable, determining the managed to-be-included bare metal server as a to-be-included bare metal server with successful self-inspection, and obtaining first information corresponding to the to-be-included bare metal server with successful self-inspection.

Thus, through the steps 1011 to 1014, at least one bare metal server to be cloud-embedded, i.e., at least one first bare metal server, which is successfully self-checked, can be obtained.

It will be appreciated that after step 1014, the first list of cloud bare metal servers to be included for which the self-test was successful (i.e., the list of first bare metal servers) may also be automatically output, and the second list of cloud bare metal servers to be included for which the self-test was failed may also be output. The list can comprise node identifiers, and the second list can also comprise information such as reasons for self-checking failure of the cloud bare metal server to be in corresponding to the node identifiers.

The specific steps in this embodiment may be performed specifically by the automated self-test module described above.

As shown in fig. 3, in a specific embodiment, performing self-checking on a bare metal server to be entered, and the main steps of obtaining the bare metal server to be entered with the self-checking success include:

S301: the method comprises the steps of obtaining a node_list of a to-be-cloud bare metal server, wherein the node_list comprises at least one node identification (node-id) of the to-be-cloud bare metal server.

S302: judging whether the node state (node state) of the corresponding cloud bare metal server to be input is a manageable or not according to each node-id in the node_list; if yes, then execution S303; if not, S304 is performed.

S303: and deleting the node (namely the cloud bare metal server to be entered) residual data.

S304: and setting the node state to be in the cloud bare metal server as a manageable state.

S305: and calling an aspect-api interface to treat the cloud bare metal server nanotube.

S306: judging whether the cloud bare metal server to be accessed after the nanotubes is a manageable or not; if yes, then execution S307; if not, S308 is performed.

S307: and outputting success_list (including node-id of the cloud bare metal server to be successfully self-checked).

S308: outputting a failed_list (including node-id of the to-be-cloud bare metal server which fails self-checking).

Through the steps, the cloud bare metal server to be built on a large scale can be subjected to repeated self-checking operation for multiple rounds, so that the cloud bare metal server to be built fails in self-checking and is subjected to self-checking again after being rectified, and the cloud bare metal server to be built fails in self-checking can be successfully checked.

It should be noted that, the automatic self-checking module may collect hardware configuration information and network connection status of the full-scale bare metal server, that is, collect first information corresponding to the bare metal server to be cloud. Based on the uniqueness of node-id corresponding to the cloud bare metal server, performing self-checking input and automatic update on each item of hardware configuration information and network connection information so as to be used for subsequent bare metal server verification.

For example, a ramdisk small mirror image is installed for the bare metal server to be cloud-loaded, and ironic python agent service runs in the ramdisk small mirror image of the memory of the bare metal server to be cloud-loaded in the automatic self-checking process, can be used for collecting hardware configuration information and network connection information of the bare metal server to be cloud-loaded, and then interacts with a driver which can be compiled under the ironic-aspect service to collect, process and store the hardware configuration information and the network connection information of the bare metal server to be cloud-loaded. The specific process is as follows:

ironic Python agent is a Python agent for revoking and configuring bare metal services, and drivers inputs the Serial Number (SN) of the bare metal server to be cloud collected by ironic Python agent, a central processing unit (Central Processing Unit, CPU), a random access memory (Random Access Memory, RAM), an os_disk (system DISK), a DISK, a network card (network interface card, NIC) and other information into a database table corresponding to each node identifier (node-id), as shown in table 1, which is a format of hardware configuration information of the bare metal server to be cloud in an alternative example. The information of node-id, node-name, IPMI, TYPE and the like is automatically specified when the bare metal server is ready to enter the cloud, namely, the information is specified when the basic information of the node (to-be-cloud bare metal server) is created.

Table 1 hardware configuration information

Node-id	Node-name	IPMI	TYPE	SN	CPU	RAM	OS_DISK	DISK	NIC
										id1	name1	ip1	C3	sn1	64	384	445	153600	6
id2	name2	ip2	B1	sn2	32	192	445	96000	6
										id3	name3	ip3	B2	sn3	128	384	445	102400	6
...	...	...	...	...	...	...	...	...	...
										idn	namen	ipn	C3	snn	64	384	445	153600	6

Thus, the hardware configuration information of the cloud bare metal server to be input corresponding to the node-id can be obtained through the node-id.

In a cloud entering scene of a certain bare metal server, each bare metal server to be cloud-entering is provided with 3 network cards and 6 network ports, the network ports respectively correspond to 6 network card names (eth_name) and media access control addresses (MediaAccessControlAddress, MAC) (i.e. eth_mac), and the 6 network ports are respectively connected to designated port local network connections (Local Link Connection, LLC) of 3 pairs of switches (i.e. 3 network planes) in an Mgmt/Business/storage mode, so that cloud entering of network traffic of the bare metal server to be cloud-entering is realized. In order to better enter the network information and the condition of the uplink switch after the self-inspection of the cloud bare metal server, the network connection information can adopt the record specifications shown in table 2.

Table 2 network connection information

Node-id	Eth-name	Eth-mac	LLC	extra
					id1	enp34s0f0	b8:ce:f6:be:6d:ba	Ten-GigabitEthernet1/0/1	Business1
id1	enp34s0f1	b8:ce:f6:be:6d:bb	Ten-GigabitEthernet1/0/2	Storge1
					id1	enp97s0f0	b8:ce:f6:be:fb:8e	Ten-GigabitEthernet1/0/1	Business2
id1	enp97s0f1	b8:ce:f6:be:fb:8f	Ten-GigabitEthernet1/0/2	Storge2
					id1	eno1	f0:2f:74:96:c8:49	gigabitethernet0/1	Mgmt1
id1	eno2	f0:2f:74:96:c8:4a	gigabitethernet0/1	Mgmt2

Thus, the network connection information (specifically including network card information, uplink switch condition and the like) of the cloud bare metal server corresponding to the node-id can be obtained through the node-id.

Therefore, hardware configuration information, network connection information and the like corresponding to the bare metal server to be cloud-loaded can be automatically obtained in batches based on the node-id corresponding to the bare metal server to be cloud-loaded, and compared with the method for manually pre-installing an operating system, configuring a network and checking the hardware configuration, network connection information and other information of the server, the method omits complicated manual operation links, improves the cloud loading convenience of the bare metal server, improves the checking efficiency and checking quality of the bare metal server before cloud loading, and can also provide data support for the follow-up automatic checking of the bare metal server to be cloud-loaded more quickly and accurately.

Through the self-checking process, the hardware configuration information and the network connection information corresponding to the bare metal server to be cloud are automatically input (form first information) according to the standard format, and then the bare metal server can be checked accordingly. The specific process is as follows:

in an embodiment, in step 102, verifying each first bare metal server according to the first information corresponding to the at least one first bare metal server to obtain a second bare metal server, including:

(1) Obtaining second information corresponding to each target bare metal server in the at least one first bare metal server, wherein the second information comprises: the second hardware configuration information and the second network connection information are determined based on planning information corresponding to the first bare metal server, and the target first bare metal server is any one of the at least one first bare metal server.

It should be noted that, in the resource pool construction project, a detailed Design document (LLD) of a hardware integrated Design scheme generally plans information such as a machine room, a rack, a U number, a server type, an IP address, etc. of a full-volume server, where the server type is distinguished by attribute configuration differences such as a CPU, a memory, a disk, a network card, etc. Thus, the hard-set LLD (i.e., standardized hardware integration scheme) may be converted in accordance with a display format (e.g., the canonical form shown in table 1) of the self-test entry result (i.e., the first hardware configuration information). Similarly, the port connection table in the hardware integration stage is converted according to the display format (for example, the standard form shown in table 2) of the self-checking input result (namely, the first network connection information).

That is, the above-mentioned planning information may specifically be: the standardized hardware integration scheme and the port netlist of the at least one bare metal server to be input into the cloud can be processed to form a table which is the same as the format specification of the first information input by self-checking, namely the second information (which can be used as a standard specification). In this way, the actual value (i.e. the value in the first information) and the standard value (i.e. the value in the second information) of each parameter corresponding to the node identification (node-id) can be obtained through the double tables (i.e. the first information and the second information), so that the server configuration difference is confirmed through quick comparison, the hardware integration quality is checked, and the checking result of the bare metal server to be in the cloud is obtained.

(2) And comparing the first information corresponding to the target bare metal server with the second information.

For example, for a target bare metal server, a parameter value of RAM in first information and a parameter value of RAM in second information corresponding to the target bare metal server are compared.

(3) And determining the target bare metal server as the second bare metal server under the condition that the first information is consistent with the second information.

For example, taking the Node-id as id2 to be put into the bare metal cloud server as an example, acquiring a parameter value (i.e. an actual value) of the RAM corresponding to id2 in the first information and a parameter value (i.e. a standard value) of the RAM corresponding to id2 in the second information, and judging whether the two values are consistent. If the two are inconsistent, it can be determined that the id2 check fails, and further presume that the abnormal reasons of the check failure of the cloud bare metal server to be input corresponding to the id2 may be: lack of memory bank or memory bank failure.

The specific steps in this embodiment may be performed specifically by the automated verification module described above.

Because hardware configuration and switch connection are usually manually completed by engineers in a hardware integration stage, in a large-scale bare metal cloud entering process, the situation that actual and original hardware integration schemes are inconsistent is unavoidable.

As shown in fig. 4, in a specific example, the verification process is as follows:

s401: the method comprises the steps of obtaining a node_list of a to-be-cloud bare metal server, wherein the node_list comprises at least one node identification (node-id) of the to-be-cloud bare metal server.

S402: and checking the hardware configuration of the bare metal server.

For each node-id in the node_list, acquiring corresponding first hardware configuration information such as CPU, RAM, NIC, comparing the first hardware configuration information with corresponding second hardware configuration information (which can be a hardware configuration template table), and judging whether the first hardware configuration information is consistent with the second hardware configuration information; if yes, i.e., if the check is normal here, S403 is executed; if not, S405 is performed.

S403: and checking the network connection condition of the bare metal server.

For each node-id in the node_list, acquiring corresponding first network connection information such as eth_name and eth_ mac, LLC, extra, and then comparing the first network connection information with corresponding second network connection information (which can be a network connection condition template table) to judge whether the first network connection information and the second network connection information are consistent; if yes, then execute S404; if not, S405 is performed.

It is understood that the execution order of S402 and S403 is not limited to the order shown in fig. 4.

S404: outputting success_list (including node-id of the cloud bare metal server to be checked successfully), and then performing deployment recovery function test before cloud entry on the cloud bare metal server to be checked in the success_list.

S405: the failed_list (including the node-id of the cloud bare metal server to be checked failed) is output, and the abnormal configuration parameters and the speculation result (abnormal reason) may be marked in the failed_list, and may be recorded in logs. Therefore, related personnel can carry out rectification and re-self-inspection and verification on the abnormal bare metal server according to the fault_list, so that the quality and efficiency of bare metal cloud entering are improved.

In this embodiment, in order to avoid situations of inaccurate information and legacy problems caused by hardware configuration and network connection conditions of a part of bare metal servers in sampling inspection, automatic verification can be performed on the bare metal servers to be cloud according to first hardware configuration information and first network connection information recorded in self-inspection, it is determined that the bare metal servers to be cloud have abnormal hardware configuration and network connection, and accuracy of bare metal cloud detection is improved.

In some embodiments, after the comparing the first information corresponding to the target bare metal server with the second information, the method further comprises: and determining the target bare metal server as an abnormal bare metal server when the first information is inconsistent with the second information. Outputting abnormal information corresponding to the abnormal bare metal server, wherein the abnormal information comprises: the first information and/or the reason for the abnormality.

In this embodiment, the output of the configuration abnormality cause such as CPU, RAM, OS _ DISK, DISK, NIC or the output of the abnormality cause of the network connection condition such as 1:1 port check, rate failure, and the cross-talk of each network plane may be completed by comparison. Thus, the list of the abnormal bare metal server with the problem in the hardware integration can be determined through automatic verification, corresponding abnormal information such as specific error configuration and other abnormal reasons can be output, and the abnormal information can be fed back to the hardware integrator so that the hardware integrator can carry out corresponding correction on the abnormal bare metal server.

In an alternative example, the common configuration exception results are shown in table 3 after being processed by the automated verification module.

TABLE 3 anomaly information

Taking the Node-id as the id4 to-be-input cloud bare metal server as an example, the exception parameter is NIC, that is, the value (i.e. the actual value) of NIC corresponding to id4 in the first information is inconsistent with the value (i.e. the standard value) of NIC corresponding to id4 in the second information, it can be presumed that the exception cause of the check failure of the to-be-input cloud bare metal server corresponding to id4 is network card failure, link failure or speed exception.

It should be noted that, after the automation verification is successful, the bare metal server to be cloud-in basically has the cloud-in condition. In order to provide better use experience for tenants, in the embodiment of the invention, the automatic deployment module can issue a test service system for the cloud bare metal server to be checked (namely, the second bare metal server) after successful verification, and perform basic provisioning deployment and clean recovery function verification on the second bare metal server. The specific process is as follows:

in some optional embodiments, the step 103, performing deployment recovery on each of the second bare metal servers may specifically include the following steps:

Step 1031, obtaining a deployment template and target parameters corresponding to the second bare metal server.

It should be noted that, in order to test the adaptation capability of the bare metal server to be cloud to different types of systems, networks and configurations, the diversity of deployment verification is realized, and the deployment template and the specified parameters can be introduced with node granularity for differentiated deployment. That is, different deployment templates and target parameters may be specified for each node-id. For example, in order to verify that the C3 type bare metal server to be cloud-ready can adapt to the linux system and the windows system, different image images can be transmitted to the same type bare metal server to be cloud-ready in the process of the automatic deployment module, and the connectivity of the network can be verified by using the same network net.

Step 1032, deploying the second bare metal server according to the deployment template and the target parameter corresponding to the second bare metal server;

step 1033, performing network test on the service system deployed on the second bare metal server;

and step 1034, recovering and cleaning the service system on the second bare metal server under the condition that the network test of the service system on the second bare metal server passes.

The specific steps in this embodiment may be performed specifically by the automated deployment module described above.

In order to realize the full life cycle function test of the large-scale cloud bare metal server before cloud entry, the cloud bare metal server can be subjected to deployment and issuing (service system installation) and recovery cleaning test besides self-checking and verification.

In this embodiment, different templates (deployment templates) and parameter configurations can be specified for each node-id to verify the adaptation effect of each type of bare metal server to be cloud-in on different systems, networks and templates, and the bare metal server adaptation verification supporting multi-parameter multi-configuration can improve the software integration quality of bare metal cloud-in, improve the sufficiency of testing before the bare metal server to be cloud-in is cloud-in, thereby ensuring that tenants can normally use bare metal resources and providing better ordering and use experience for clients.

For example, the parameter assignment format specified at the time of deployment is shown in table 4.

Table 4 parameter assignment format

Node-id	image	net	flavor	userdata
					id1	centos	net1	C3	Userdata1
id2	bclinux	net1	B1	Userdata2
					...	...	...	...	...
idn	windows	netn	C3	userdataN

The target parameters of the cloud bare metal server to be input corresponding to the id1 comprise: image (parameter value is centos), net (parameter value is net 1), flag (parameter value is C3), userdata (parameter value is Userdata 1).

In a specific embodiment, in the provisioning phase, a deployment template (userdata) may be introduced into the automation deployment module, and parameter configurations such as image, net, flavor are specified, so as to start deploying the bare metal business system. The small ramdisk mirror image running in the memory of the cloud bare metal server (referred to as a second bare metal server herein) interacts with drivers of the ironic, performs resource scheduling, pulls a service system mirror image, takes over the bare metal server to guide the installation and network configuration of an operating system, so that the bare metal instance is successfully created, and a tenant can run services on the second bare metal server.

In order to further confirm that the provided second bare metal server is available, a service system basic environment self-checking script can be added into drivers, and after the system installation and network configuration process on the second bare metal server is completed, the script is automatically operated to check the connectivity of the network, the three network plane rates and the like. If the service system is successfully deployed and checked to be correct (the network test passes), the clean recovery operation is executed (i.e. recovery cleaning is performed), the service system is released, and the second bare metal server formally completes the cloud entering process, at this time, the second bare metal server can be provided for the tenant to subscribe. It can be understood that information such as failure results, logs, reasons of abnormality, etc. of the abnormal bare metal server may also be returned.

As shown in FIG. 5, in one embodiment, the specific process of deploying reclamation is as follows:

s501: the method comprises the steps of obtaining a node_list of a to-be-cloud bare metal server, wherein the node_list comprises at least one node identification (node-id) of the to-be-cloud bare metal server.

S502: judging whether the node state (node state) of the corresponding cloud bare metal server to be input is available or not according to each node-id in the node_list; if yes, then execution S503; if not, S504 is performed.

S503: target parameters (e.g., image, net, flavor, userdata) are obtained.

S504: setting a node state of a node (to-be-cloud bare metal server) to be an available state.

S505: the business system deploys the installation configuration.

S506: judging whether the service system is successful in issuing (namely whether the node state is active); if yes, then executing S507; if not, S510 is performed.

S507: testing whether the network connectivity, the network card speed and the like are normal; if yes, then execute S508; if not, S510 is performed.

S508: and recycling and cleaning the service system.

S509: outputting success_list (including node-id of the to-be-cloud bare metal server successfully deployed and recycled).

S510: outputting a failed_list (including node-ids of to-be-cloud bare metal servers which fail deployment reclamation).

In the embodiment, the OpenStack ir round trivial interface is integrated and optimized through the automatic self-checking module, so that cloud self-checking tasks to be input into the cloud bare metal server can be processed in batches, and the soft set efficiency is improved; for hard set quality check work which cannot be completed by the ironic insactor, various problems in hardware integration can be processed through an automatic check module, and the convenience of cloud entrance nano-tubes is improved; the automatic deployment module can complete deployment and recovery test work of batch cloud entering of the bare metal server to be cloud entering, and the use experience of tenants is improved.

According to the cloud entering method of the bare metal server, the first bare metal server (the bare metal server to be cloud which is successfully subjected to self-checking) can be obtained by carrying out self-checking on the bare metal server to be cloud entering, and each first bare metal server can be checked according to the first information corresponding to the first bare metal server by obtaining the first information corresponding to at least one first bare metal server, so that the second bare metal server (the at least one first bare metal server which is successfully checked) is obtained, and then deployment recovery is carried out on each second bare metal server, so that cloud entering of the second bare metal server is realized. Therefore, cloud entering self-checking verification and full life cycle management can be automatically carried out, large-scale cloud entering of bare metal servers to be cloud entering is achieved, errors caused by manual calling of trivial instructions are reduced, software integration efficiency and quality are improved, cloud entering efficiency of the bare metal servers is effectively improved, and delivery period of the bare metal servers is shortened.

As shown in fig. 6, a bare metal server cloud entering device according to an embodiment of the present invention includes:

the processing module 610 is configured to obtain first information corresponding to at least one first bare metal server, where the first information includes: the first bare metal server is at least one bare metal server to be cloud successfully subjected to self-checking in the bare metal server to be cloud successfully;

the verification module 620 is configured to verify each first bare metal server according to first information corresponding to the at least one first bare metal server, to obtain a second bare metal server, where the second bare metal server is at least one first bare metal server that is successfully verified;

the deployment module 630 is configured to deploy and recycle each of the second bare metal servers, so as to implement cloud entry of the second bare metal servers.

Optionally, the processing module 610 includes:

the first processing unit is used for judging whether the node state of each to-be-input cloud bare metal server is manageable or not according to each to-be-input cloud bare metal server;

the second processing unit is used for carrying out inclusion management on the bare metal server to be subjected to cloud entry if the node state of the bare metal server to be subjected to cloud entry is manageable;

the third processing unit is used for judging whether the node state of the cloud bare metal server to be accessed after the access management is manageable or not;

and the fourth processing unit is used for determining the managed cloud bare metal server to be the cloud bare metal server which is successful in self-checking if the node state of the managed cloud bare metal server is manageable, and acquiring first information corresponding to the cloud bare metal server which is successful in self-checking.

Optionally, before the taking-in management of the to-be-taken-in bare metal server, the processing module 610 further includes:

a fifth processing unit, configured to determine whether target data exists on the bare metal server to be cloud, where the target data includes data related to intake management;

And the sixth processing unit is used for deleting the target data under the condition that the target data exists on the to-be-accessed cloud bare metal server.

Optionally, the verification module 620 includes:

an information obtaining unit, configured to obtain second information corresponding to each target bare metal server in the at least one first bare metal server, where the second information includes: the second hardware configuration information and second network connection information are determined based on planning information corresponding to the first bare metal server, and the target first bare metal server is any one of the at least one first bare metal server;

the information comparison unit is used for comparing the first information corresponding to the target bare metal server with the second information;

and a seventh processing unit, configured to determine the target bare metal server as the second bare metal server when the first information is consistent with the second information.

Optionally, the deployment module 630 includes:

the data acquisition unit is used for acquiring a deployment template and target parameters corresponding to the second bare metal server;

The first deployment unit is used for deploying the second bare metal server according to the deployment template and the target parameters corresponding to the second bare metal server;

the system test unit is used for carrying out network test on the service system deployed on the second bare metal server;

and the recovery cleaning unit is used for recovering and cleaning the service system on the second bare metal server under the condition that the network test of the service system on the second bare metal server passes.

It should be noted that, the cloud entering device for the bare metal server provided by the embodiment of the present invention can implement all the method steps implemented by the cloud entering method embodiment for the bare metal server, and can achieve the same technical effects, and the same parts and beneficial effects as those of the method embodiment in the embodiment are not described in detail herein.

As shown in fig. 7, a processing device 700 according to an embodiment of the present invention includes a processor 710 and a transceiver 720, where the processor 710 is configured to:

Optionally, when acquiring the first information corresponding to the at least one first bare metal server, the processor 710 is specifically configured to:

Judging whether the node state of each to-be-cloud bare metal server is manageable or not according to each to-be-cloud bare metal server;

if the node state of the to-be-accessed cloud bare metal server is manageable, performing inclusion management on the to-be-accessed cloud bare metal server;

judging whether the node state of the cloud bare metal server to be managed is manageable or not;

if the node state of the cloud bare metal server to be imported after the hosting is manageable, determining the cloud bare metal server to be imported after the hosting as a cloud bare metal server to be imported after the hosting is successful in self-checking, and acquiring first information corresponding to the cloud bare metal server to be imported after the self-checking is successful.

Optionally, before the taking-in management of the to-be-in bare metal server, the processor 710 is further configured to:

judging whether target data exist on the bare metal server to be cloud-loaded, wherein the target data comprise data related to inclusion management;

and deleting the target data under the condition that the target data exist on the to-be-cloud bare metal server.

Optionally, the processor 710 is specifically configured to, when verifying each of the first bare metal servers according to the first information corresponding to the at least one first bare metal server to obtain a second bare metal server:

Obtaining second information corresponding to each target bare metal server in the at least one first bare metal server, wherein the second information comprises: the second hardware configuration information and second network connection information are determined based on planning information corresponding to the first bare metal server, and the target first bare metal server is any one of the at least one first bare metal server;

comparing the first information corresponding to the target bare metal server with the second information;

and determining the target bare metal server as the second bare metal server under the condition that the first information is consistent with the second information.

Optionally, the processor 710 is specifically configured to, when performing deployment recovery on each of the second bare metal servers:

acquiring a deployment template and target parameters corresponding to the second bare metal server;

deploying the second bare metal server according to the deployment template and the target parameters corresponding to the second bare metal server;

network testing is carried out on a service system deployed on the second bare metal server;

And under the condition that the network test of the service system on the second bare metal server passes, recycling and cleaning the service system on the second bare metal server.

It should be noted that, the processing device provided in the embodiment of the present invention can implement all the method steps implemented in the cloud entering method embodiment of the bare metal server, and can achieve the same technical effects, and detailed descriptions of the same parts and beneficial effects as those in the method embodiment in the embodiment are omitted.

A processing device according to another embodiment of the present invention, as shown in fig. 8, includes a transceiver 810, a processor 800, a memory 820, and a program or instructions stored on the memory 820 and executable on the processor 800; the processor 800 implements the bare metal server cloud approach described above when executing the program or instructions.

The transceiver 810 is configured to receive and transmit data under the control of the processor 800.

Wherein in fig. 8, a bus architecture may comprise any number of interconnected buses and bridges, and in particular, one or more processors represented by processor 800 and various circuits of memory represented by memory 820, linked together. The bus architecture may also link together various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., which are well known in the art and, therefore, will not be described further herein. The bus interface provides an interface. The transceiver 810 may be a number of elements, i.e., including a transmitter and a receiver, providing a means for communicating with various other apparatus over a transmission medium. The processor 800 is responsible for managing the bus architecture and general processing, and the memory 820 may store data used by the processor 800 in performing operations.

The readable storage medium of the embodiment of the present invention stores a program or an instruction, where the program or the instruction realizes the steps in the cloud entering method of the bare metal server as described above when being executed by a processor, and the same technical effects can be achieved, and for avoiding repetition, a detailed description is omitted herein. Wherein the computer readable storage medium is selected from Read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk or optical disk.

It is further noted that the terminals described in this specification include, but are not limited to, smartphones, tablets, etc., and that many of the functional components described are referred to as modules in order to more particularly emphasize their implementation independence.

In an embodiment of the invention, the modules may be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different bits which, when joined logically together, comprise the module and achieve the stated purpose for the module.

Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Likewise, operational data may be identified within modules and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices.

Where a module may be implemented in software, taking into account the level of existing hardware technology, a module may be implemented in software, and one skilled in the art may, without regard to cost, build corresponding hardware circuitry, including conventional Very Large Scale Integration (VLSI) circuits or gate arrays, and existing semiconductors such as logic chips, transistors, or other discrete components, to achieve the corresponding functions. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

The exemplary embodiments described above are described with reference to the drawings, many different forms and embodiments are possible without departing from the spirit and teachings of the present invention, and therefore, the present invention should not be construed as limited to the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete, and will convey the scope of the invention to those skilled in the art. In the drawings, the size of the elements and relative sizes may be exaggerated for clarity. The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Unless otherwise indicated, a range of values includes the upper and lower limits of the range and any subranges therebetween.

While the foregoing is directed to the preferred embodiments of the present invention, it will be appreciated by those skilled in the art that various modifications and adaptations can be made without departing from the principles of the present invention, and such modifications and adaptations are intended to be comprehended within the scope of the present invention.

Claims

1. The cloud entering method of the bare metal server is characterized by comprising the following steps of:

2. The method of claim 1, wherein the obtaining first information corresponding to the at least one first bare metal server comprises:

3. The method of claim 2, wherein prior to said hosting the to-be-hosted bare metal server, the method further comprises:

4. The method of claim 1, wherein the verifying each first bare metal server according to the first information corresponding to the at least one first bare metal server to obtain a second bare metal server comprises:

5. The method of claim 1, wherein the deploying and reclaiming each of the second bare metal servers comprises:

6. A bare metal server cloud entering device, comprising:

7. A processing apparatus, comprising: a transceiver and a processor; the processor is configured to:

8. A processing apparatus, comprising: a transceiver, a processor, a memory, and a program or instructions stored on the memory and executable on the processor; the bare metal server cloud entering method according to any one of claims 1-5 is realized when the processor executes the program or instructions.

9. A readable storage medium having stored thereon a program or instructions, which when executed by a processor, implements the steps of the bare metal server cloud entering method according to any of claims 1-5.