A bare metal server-based deployment method, device and system

Abstract

The application discloses a deployment method, device and equipment based on a bare metal server. The method is applied to a virtualization management platform and includes the following steps: receiving a first request message sent by a bare metal server, wherein the first request message comprises configuration parameters of the bare metal server; calling an adaptive algorithm according to the configuration parameters to determine a block size coefficient of a disk; and sending the block size coefficient to the bare metal server through a preset command, wherein the block size coefficient is used for assisting the bare metal server to complete an image file burning task. The method is realized by bottom-layer code and does not depend on an Ironic module of OpenStack, so that the use of the OpenStack platform and the installation of multiple modules can be effectively avoided. The method has high reliability, can download an image file in a multi-task mode on the side of the bare metal server, and thus realizes the image file burning and the deployment task of the bare metal server, and avoids the bloating of the platform.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a deployment method, apparatus and system based on bare metal servers. Background Technology

[0002] With the rapid development of cloud computing technology, dedicated, performance-loss-free bare-metal servers are increasingly favored by manufacturers and users. Bare-metal servers inherit the characteristics of physical servers, with no virtualization overhead or performance loss, 100% release of computing resources, high bandwidth, low latency cloud storage, and excellent cloud network access performance. The emergence of bare-metal technology meets the deployment density and performance requirements of enterprises' critical businesses such as databases, big data, containers, and AI. Furthermore, bare-metal servers have rapidly gained market recognition in the cloud computing market due to their high performance, elastic scalability, and secure isolation. Bare-metal servers combine the advantages and characteristics of traditional physical machines and cloud servers, providing users with completely physically isolated servers. This allows users to obtain excellent computing performance guarantees while fully enjoying the elasticity, scalability, and flexibility of cloud servers.

[0003] Generally, bare metal server deployment is implemented using the OpenStack Ironic system. During deployment, the core modules include Ironic, Nova, Neutron, Glance, and Cinder, and these modules work collaboratively. For example, Ironic is used for bare metal management, including bare metal information entry and automatic hardware discovery; Nova is responsible for bare metal scheduling and providing bare metal services; Neutron is used for bare metal network management and configuration; and Glance provides image services for bare metal servers, saving them as OS installation media.

[0004] Currently, during bare metal server deployment, Ironic needs to work in conjunction with other OpenStack functional modules. If OpenStack's bare metal functionality is required, not only the Ironic module but also other modules such as Glance and Nova must be installed. Because Ironic interacts with these modules, this necessitates installing numerous modules, resulting in a bloated platform and excessive dependence on OpenStack. Summary of the Invention

[0005] Therefore, the purpose of this invention is to address the problem of excessive reliance on the OpenStack system during bare metal deployment, leading to an bloated deployment platform. To solve this problem, embodiments of this invention provide a deployment method, apparatus, and device based on bare metal servers. Specifically, the technical solution is as follows:

[0006] In a first aspect, embodiments of this application disclose a deployment method based on a bare metal server, which is applied to a virtualization management platform, the method comprising:

[0007] Receive a first request message sent by a bare metal server, wherein the first request message includes the configuration parameters of the bare metal server;

[0008] The adaptive algorithm is invoked based on the configuration parameters to determine the disk block size coefficient;

[0009] The block size coefficient is sent to the bare metal server via a preset command. The block size coefficient is used to assist the bare metal server in completing the image file burning task.

[0010] Secondly, embodiments of this application also disclose a deployment apparatus based on a bare metal server, the method being applied to a bare metal server, the method comprising:

[0011] Obtain the image file and perform an integrity check on the image file;

[0012] Once the integrity verification passes, a first request message is sent to the virtualization management platform. The first request message includes the configuration parameters of the bare metal server.

[0013] Receive a preset command from the virtualization management platform based on the first request message, wherein the preset command includes the block size coefficient of the disk;

[0014] Using the block size coefficient, the image file is burned through multiple channels and then booted from the local hard drive.

[0015] Thirdly, according to an embodiment of this application, a deployment apparatus based on a bare metal server is provided, the apparatus comprising:

[0016] A receiving unit is configured to receive a first request message sent by a bare metal server, wherein the first request message includes configuration parameters of the bare metal server;

[0017] The processing unit is used to call an adaptive algorithm based on the configuration parameters to determine the block size coefficient of the disk.

[0018] The sending unit is used to send the block size coefficient to the bare metal server through a preset command. The block size coefficient is used to assist the bare metal server in completing the image file burning task.

[0019] Fourthly, embodiments of this application also provide a deployment apparatus based on a bare metal server, the apparatus comprising:

[0020] The acquisition unit is used to acquire image files;

[0021] The verification unit is used to perform integrity verification on the image file.

[0022] The sending unit is configured to send a first request message to the virtualization management platform after the verification unit passes the integrity verification of the image file. The first request message includes the configuration parameters of the bare metal server.

[0023] The receiving unit is configured to receive a preset command fed back by the virtualization management platform according to the first request message, wherein the preset command includes a disk block size coefficient;

[0024] The processing unit is used to perform the burning task of the image file in multiple channels using the block size coefficient, and to boot from the local hard disk.

[0025] Fifthly, embodiments of this application also provide a bare metal server deployment system, the system comprising: a virtualization management platform and a bare metal server, wherein the virtualization management platform and the bare metal server are connected via at least one switch;

[0026] The bare metal server is used to obtain an image file, perform an integrity check on the image file, and, after the integrity check passes, send a first request message to the virtualization management platform, the first request message including the configuration parameters of the bare metal server.

[0027] The virtualization management platform is used to receive the first request message, call an adaptive algorithm according to the configuration parameters to determine the block size coefficient of the disk, and send the block size coefficient to the bare metal server through a preset command;

[0028] The bare metal server is also used to receive the preset command, use the block size coefficient carried in the preset command to perform the burning task of the image file in multiple channels, and boot from the local hard disk.

[0029] In a sixth aspect, embodiments of this application also provide an electronic device, including a processor and a memory, wherein the memory is coupled to the processor; the memory stores computer-readable program instructions, which, when executed by the processor, implement the deployment method based on a bare metal server as described in the first or second aspect above.

[0030] In addition, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the deployment method based on a bare metal server as described in the first or second aspect above.

[0031] The methods, apparatus, and devices provided in this application automatically monitor the integrity of the image file during the deployment of a bare metal server, adaptively generate a block size coefficient based on the hardware configuration parameters of the bare metal server, and send the block size coefficient to the bare metal server through a preset command. The bare metal server performs image file writing work in multiple tasks according to the block size coefficient, thereby reducing manual intervention and improving deployment efficiency.

[0032] In addition, this method is implemented from the underlying code and does not depend on the OpenStack Ironic module, thus effectively avoiding the use of the OpenStack platform and the installation of multiple modules. This method has high reliability and deploys multiple tasks on the bare metal server side to download image files, thereby realizing the image file burning and bare metal server deployment tasks, avoiding bloat to the platform. Attached Figure Description

[0033] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram illustrating a bare metal server application scenario provided in an embodiment of the present invention;

[0035] Figure 2 This is a signaling flowchart of a deployment method provided in an embodiment of the present invention;

[0036] Figure 3 This is a flowchart of generating a preset command provided in an embodiment of the present invention;

[0037] Figure 4 This is a signaling flowchart of another deployment method provided in an embodiment of the present invention;

[0038] Figure 5 This is a structural block diagram of a deployment device based on a bare metal server provided in an embodiment of the present invention;

[0039] Figure 6 This is a structural block diagram of another deployment device based on a bare metal server provided in an embodiment of the present invention;

[0040] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0041] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] First, the nouns and technical terms involved in the embodiments of this application will be introduced.

[0043] 1. OpenStack and Ironic

[0044] OpenStack is an open-source cloud computing management platform project. It comprises several main components and provides software for building and managing public, private, and hybrid clouds. The primary goal of the OpenStack project is to simplify the cloud deployment process and deliver excellent scalability. OpenStack systems or their evolutions are currently widely used across various industries, including self-built private clouds, public clouds, leased private clouds, and hybrid clouds. OpenStack also supports virtual machine software such as KVM, Xen, Lvc, and Docker, as well as containers.

[0045] Ironic is an OpenStack project primarily used to manage bare metal, including power control, system deployment, and network configuration. Ironic enables functions such as recording bare metal information and automatic hardware discovery for one or more specified bare metal machines, thereby facilitating the rapid delivery of hardware infrastructure resources.

[0046] 2. Bare metal server

[0047] A bare metal server (BMS) is a type of physical facility in a cloud computing system. It can also be called a bare metal node or a physical machine with a bare operating system. It generally refers to a server without an operating system or virtualization software installed.

[0048] Additionally, a bare-metal server can also refer to a physical machine with an operating system installed but without virtualization software. Bare-metal servers are a hybrid between physical servers and virtual machines, combining the advantages of both. They meet the high performance and stability requirements of core application scenarios while also offering the elasticity and flexibility of cloud computing and the secure physical isolation of traditional physical machines.

[0049] 3. Bare metal agency service

[0050] The bare metal proxy service, also known as the bare metal proxy module, is a proxy service responsible for the actual control of the bare metal server. It runs on the bare metal server and interacts with the bare metal computing service.

[0051] It's a service that runs within the Initrid after the bare metal server boots over the network. It starts automatically with the Initrid instance. This service handles a series of actions for bare metal nodes in Ironic, such as checking, configuring, cleaning, and deploying images. Bare metal compute nodes can interact remotely with physical machine nodes through this agent. This bare metal agent module allows for a range of operations on the bare metal server, including disk formatting, disk partitioning, OS (bootloader) installation, firmware upgrades, and RAID configuration.

[0052] 4. Bare Metal Calculation Service

[0053] The bare metal computing service, also known as the bare metal computing module, is the component responsible for bare metal lifecycle management and serves as the control center for the entire bare metal functionality. It handles most of the control work for the bare metal deployment service, exposes its functionality through an API, interacts with a RESTful API, and is responsible for interacting with other components.

[0054] A RESTful API is an interface used by two computer systems to securely exchange information over the internet. RESTful APIs support this type of information exchange because they adhere to secure, reliable, and efficient software communication standards.

[0055] A RESTful API Gateway is a network gateway or channel for unified management of APIs. It serves as the sole entry point for all requests across the entire service platform. All clients and consumers access the platform through this unified gateway, which routes requests to the specific services that handle the responses. User API requests related to bare metal will be routed to the bare metal computing service through this gateway.

[0056] Furthermore, Representational State Transport (REST) ​​is a software architecture that determines the operating conditions of an API. REST was originally established as a guide for managing communication on complex networks such as the Internet. It enables high-performance and reliable large-scale communication through the use of a REST-based architecture. This architecture can also be modified to bring visibility and cross-platform possibilities to any API system.

[0057] 5. Adaptive

[0058] Self-adaptive refers to the process of automatically adjusting the processing methods, processing order, processing parameters, boundary conditions or constraints according to the data characteristics of the data being processed during the processing and analysis process, so as to adapt them to the statistical distribution characteristics and structural characteristics of the data being processed, in order to achieve the best processing results.

[0059] 6. Mirror service and image files

[0060] The image service, also known as the image management module / image service module, includes functions such as finding, registering, and retrieving virtual machine images. The image service module provides a RESTful API to query the metadata of virtual machine images and retrieve the images themselves. Furthermore, the image service can save images to various backend storage units, such as simple file storage or object storage.

[0061] An image is a template for a bare metal server's operating environment. This template includes a specific operating system and runtime environment, and sometimes also includes pre-installed application software. An image file is essentially a copy file, containing all the data from the system disk.

[0062] The technical solutions provided in this application are used to solve the following technical problems.

[0063] First, the deployment reliability is not high.

[0064] Typically, in the Ironic system of the OpenStack platform, the disks of the bare metal server are mounted to the host via the iSCSI small computer system interface. Then, the host deploys an image of the bare metal disk. Deploying the image is a time-consuming operation. If network jitter occurs during the deployment process, it can easily cause the deployment of the bare metal server to fail.

[0065] Second, the platform is bloated and overly reliant on other OpenStack modules.

[0066] Because the Ironic system needs to work in conjunction with other functional modules on the OpenStack platform. When using OpenStack's bare metal server functionality, not only the Ironic module needs to be installed, but also other modules such as Glance and Nova. This is because Ironic needs to interact with these modules to complete deployment, resulting in a bloated platform with numerous installed modules and excessive dependence on OpenStack.

[0067] To address the aforementioned issues, this embodiment provides a deployment method based on bare metal servers. This method can be applied to a bare metal service scenario, such as... Figure 1As shown, the scenario includes: a Portal server 100 and a bare metal resource pool 200, as well as at least one switch and a service network connected to each switch.

[0068] In this embodiment, at least one switch connects the Portal server 100 and the bare metal resource pool 200. This at least one switch includes a management network switch, such as an in-band management network switch 31 and an out-of-band management network switch 32. It also includes a storage network switch 33 and a service network switch 34, etc. The storage network switch 33 is used to connect storage, and the service network switch 34 is used to connect the service network. It should be understood that the number of the aforementioned in-band and out-of-band management network switches or various service network switches can be one or more, and this embodiment does not limit this.

[0069] exist Figure 1 In the system architecture shown, the Portal server 100 includes a virtualization management platform, optionally a Portal. Further, this virtualization management platform (e.g., Portal) includes a bare metal computing module 11 and a bare metal network boot module 12. The bare metal computing module 11 manages information related to the bare metal server and boots the bare metal server from the network via the bare metal network boot module 12.

[0070] In addition, the Portal may also include a mirror management module 13, as well as other modules; this embodiment does not impose any restrictions on this.

[0071] The bare metal resource pool 200 includes at least one bare metal server, such as bare metal server 21. The bare metal server 21 also includes a bare metal proxy module 22 for starting and running the image file.

[0072] It should be noted that the above-mentioned bare metal service scenario may also include other components or devices, and this embodiment does not impose any restrictions on this.

[0073] The method provided in this embodiment will be described in detail below.

[0074] This invention provides an adaptive and multi-tasking bare metal server deployment scheme. The method reliably and multi-taskingly uploads the bare metal production image file to the simulated disk drive (RAMDisk) of the bare metal server 21 via the bare metal computing module 11. The bare metal proxy module 22 performs hash operations on the bare metal image file uploaded by the bare metal computing module 11 to check the data integrity. If an error is detected, the bare metal proxy module 22 notifies the bare metal computing module 11 to re-execute the upload sub-task, thereby ensuring that the bare metal image file is reliably uploaded to the RAMDisk of the bare metal server.

[0075] Furthermore, the bare metal computing module 11 adaptively calculates the disk block size (bs) factor required for the burning process based on the hardware configuration parameters of the bare metal server 21. The bare metal agent module 22 executes the image file burning task based on the blistsize factor calculated by the bare metal computing module 11, and writes multiple tasks to the bare metal image file.

[0076] Specifically, such as Figure 2 As shown, this embodiment provides a deployment method including the following steps:

[0077] Step 101: The bare metal computing module of the virtualization management platform receives a first request message sent by the bare metal server, the first request message including the configuration parameters of the bare metal server.

[0078] The first request message requests the disk block size factor, or blocksize factor, for the bare metal server. The bare metal server's configuration parameters include: number of CPU cores, disk performance metrics (IOPS), disk response time, disk throughput, and memory resource size. Furthermore, the IOPS includes: disk read / write performance, disk rotation speed, and average access time.

[0079] In step 101, after obtaining the complete image file, the bare metal server sends the configuration parameters of the bare metal server to the bare metal computing module through the first request message.

[0080] Step 102: Invoke the adaptive algorithm according to the configuration parameters to determine the block size coefficient of the disk.

[0081] Specifically, such as Figure 3 As shown, one embodiment of step 102 includes:

[0082] Step 102-1: Obtain the weight values ​​corresponding to the number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size, respectively.

[0083] Step 102-2: Calculate the block size coefficient by weighting the weight values ​​corresponding to each parameter in the configuration parameters of the bare metal server and each parameter.

[0084] Furthermore, the block size system is added to a preset command, which is the dd command. Specifically, the dd command is:

[0085] dd if= / root / xxx.img of= / dev / sda bs=δ(x1,x2,x3,x4,x5)

[0086] Where x1, x2, x3, x4, and x5 are configuration parameters of the bare metal server, corresponding to the number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory size, respectively. And δ(x1, x2, x3, x4, x5) is constrained by the following formula:

[0087]

[0088] Where x1 represents the number of CPU cores, x2 represents the disk performance metric IOPS, x3 represents the disk response time, x4 represents the disk throughput, and x5 represents the memory size. It should be understood that other parameters, whether more or fewer, may also be included; this embodiment does not impose any limitations on this. T1, T2, T3, and T4 are thresholds, which can be defined by the system. f(x1,x2,x3,x4,x5) is a weighted average algorithm, which can be expressed by the following formula:

[0089] f(x1,x2,x3,x4,x5)=ω1*x1+ω2*x2+ω3*x3+ω4*x4+ω5*x5

[0090] Wherein, ω1, ω2, ω3, ω4, ω5 are the weight values ​​corresponding to x1, x2, x3, x4, x5, and these weight values ​​can be determined based on empirical data obtained from a large number of laboratory tests.

[0091] In step 102-2 above, the block size coefficient can be calculated based on the weight values ​​ω1, ω2, ω3, ω4, ω5 and the formula δ(x1, x2, x3, x4, x5), such as 256, 512, 1024, 2048 or 4096.

[0092] Step 103: The block size coefficient is sent to the bare metal server via a preset command. The block size coefficient is used to assist the bare metal server in completing the image file burning task.

[0093] The preset command is a dd command (DiskDump command). The dd command is mainly used for block copying of a file of a specified size, and performing specified conversions during the copying process. Specifically, the dd command can be used to complete the following tasks: copying files, formatting files, backing up data, burning images, testing hard drives, etc. The dd command has many parameters; in this embodiment, the parameter used is the block size factor, which represents the block size read and written to the disk in one operation.

[0094] The bare metal computing module instructs the bare metal server to perform the image file burning task by issuing the dd command to the bare metal server. During the issuance of the dd command, the block size in the input and output streams can be changed, i.e., changed by the block size coefficient.

[0095] Correspondingly, the bare metal server receives the dd command sent by the bare metal computing module.

[0096] Step 104: The bare metal server uses the block size to perform the image file burning task in multiple channels and boots from the local hard drive.

[0097] Specifically, the bare metal server includes a bare metal proxy module, and there are multiple transmission channels between the bare metal server and the bare metal proxy module; in step 104 above, the multi-channel image file burning task includes: using the multiple transmission channels to transmit the image file from the bare metal proxy module, and synchronously burning the image file.

[0098] Furthermore, before the bare metal server boots from the local hard drive, the process includes: the bare metal server sending the image burning result to the bare metal computing module; the bare metal server receiving the call command fed back by the bare metal computing module based on the image burning result, and booting from the local hard drive according to the call command.

[0099] The method provided in this embodiment automatically monitors the integrity of the image file during the deployment of a bare metal server, adaptively generates a block size coefficient based on the hardware configuration parameters of the bare metal server, and sends the block size coefficient to the bare metal server through a preset command. The bare metal server performs image file writing work in multiple tasks according to the block size coefficient, thereby reducing manual intervention and improving deployment efficiency.

[0100] In addition, this method is implemented from the underlying code and does not depend on the OpenStack Ironic module, thus effectively avoiding the use of the OpenStack platform and the installation of multiple modules. This method has high reliability and deploys multiple tasks on the bare metal server side to download image files, thereby realizing the image file burning and bare metal server deployment tasks, avoiding bloat to the platform.

[0101] In one specific embodiment, such as Figure 4 The diagram shown illustrates the signaling flowchart of another deployment method based on a bare metal server provided in this embodiment. The method includes the following steps:

[0102] S1: Users begin deployment through the RESTful API Gateway. A deployment request is sent to the virtualization management platform to initiate the deployment task and deploy the application to nodes in the network.

[0103] S2: After receiving the deployment request from the API gateway, the bare metal computing module in the virtualization management platform calls the IPMI shutdown command, which is used to instruct the bare metal server to shut down.

[0104] IPMI (Intelligent Platform Management Interface) is an industry standard used in peripheral devices for enterprise systems based on Intel architecture. Its function is to intelligently monitor, control, and automatically report the operational status of a large number of servers across different operating systems, firmware, and hardware platforms, thereby reducing server system costs.

[0105] After receiving the shutdown command from the bare metal computing module, the bare metal server performs the shutdown operation.

[0106] S3: The bare metal computing module generates network startup-related parameters.

[0107] One implementation involves the bare metal computing module obtaining network boot-related parameters via the acquired bare metal server identifier. These parameters include PXE configuration parameters, boot kernel-related parameters, and DHCP (Dynamic Host Configuration Protocol) parameters, etc., and these parameters can be pre-obtained from the bare metal server.

[0108] S4: The bare metal computing module sends the relevant parameters for network startup to the bare metal network startup module.

[0109] S5: The bare metal network boot module receives and generates a network boot file based on relevant parameters.

[0110] The network boot file includes a pre-boot execution environment (PXE) configuration file. Further, it includes: generating the PXE configuration file using PXE configuration parameters; setting the bm PXE boot kernel; and configuring DHCP parameters, etc. The PXE configuration file includes information such as the operating system the user wishes to install.

[0111] After generating the network startup file, the bare metal network startup module sends the feedback result to the bare metal computing module.

[0112] S6: The bare metal computing module sets the bare metal server to start from the network according to the relevant parameters of the network startup.

[0113] Specifically, the bare metal computing module calls IPMI to configure the bare metal server to start from the network.

[0114] Optionally, in another embodiment, the method further includes: the bare metal computing module obtaining bare metal custom configuration information, the bare metal custom configuration information including the system type information to be deployed on the bare metal server; then, the bare metal computing module sets the bare metal server to start from the network according to the network startup parameters and the PXE configuration file.

[0115] The system types mentioned include, but are not limited to, Windows, Linux, Unix, and Mac OS systems.

[0116] S7: The bare metal server boots from the network, loads the vmlinuz kernel, and mounts the RAMDisk. Simultaneously, the bare metal proxy module within the bare metal server starts along with the network kernel.

[0117] S8: The bare metal proxy module sends a second request message to the image management module. The second request message is used to request the image file of the bare metal.

[0118] S9: The image management unit receives the second request message and sends the image file to the bare metal proxy module via multiple tasks.

[0119] Correspondingly, the bare metal proxy module receives the image file in a multi-tasking manner. Specifically, one possible implementation is that the bare metal proxy module acquires multiple Transmission Control Protocol (TCP) links established with the image management module; using the multiple TCP links, it simultaneously receives multiple image sub-files, which together form the complete image file.

[0120] Each image sub-file transmission corresponds to a task, such as Task1 and Task2. Specifically, the number of tasks can be determined based on the number of TCP links. If there are 3 links, the image file is split into 3 image sub-files and transmitted simultaneously through the 3 links, thereby improving the transmission efficiency of the image file.

[0121] S10: After receiving multiple image sub-files through multiple TCP links, the bare metal proxy module processes all received image sub-files, integrates them into a single image file, and performs integrity verification on the image file. For example, it uses Cyclic Redundancy Check (CRC) to verify the integrity of the image file; the specific verification process is not detailed in this embodiment.

[0122] If the integrity verification fails, the bare metal proxy module requests the image file from the image management module again; if the integrity verification succeeds, step S11 is executed.

[0123] S11: After the integrity verification passes, the bare metal proxy module sends the image file download result to the bare metal calculation module. For example, the download result may indicate that the image file was downloaded successfully.

[0124] S12: The bare metal proxy module sends a first request message to the bare metal computing module. The first request message includes relevant configuration parameters of the bare metal server. This step is the same as step 101 in the above embodiment. For details, please refer to the description of the above embodiment. This embodiment will not be described in detail here.

[0125] S13: The bare metal computing module receives the first request message, and according to the relevant configuration parameters carried in the first request message, such as disk performance (read / write performance, disk speed, average access time, etc.) and CPU performance, calls the adaptive algorithm to calculate the block size coefficient and generates the dd command.

[0126] S14: The bare metal calculation module sends the dd command to the bare metal agent module. The dd command includes the block size coefficient calculated in step S13.

[0127] Steps S13 and S14 are the same as steps 102 and 103 in the previous embodiment. For details, please refer to the description of the previous embodiment. This embodiment will not repeat them here.

[0128] S15: After receiving the dd command, the bare metal proxy module quickly and in multiple tasks writes the disk image file of the bare metal server according to the block size coefficient contained therein.

[0129] Specifically, the bare metal server and the bare metal agent module include multiple transmission channels; the fast, multi-tasking task of burning the image file includes: the bare metal server using the multiple transmission channels to transmit the image file from the bare metal agent module and simultaneously burn the image file. Using multi-channel transmission / burning of the image file can improve the burning efficiency.

[0130] After the bare metal server has completed burning the bare metal image file, the written image file is verified. After the verification is completed, step S16 is executed.

[0131] S16: The bare metal server replies to the bare metal computing module with the image file writing result (or image file burning result).

[0132] S17: The bare metal computing module calls IPMI to configure the bare metal server to boot from the local hard drive. Correspondingly, the bare metal server boots from the local hard drive according to the call from the bare metal computing module.

[0133] The method provided in this embodiment reliably and multitaskingly uploads the bare metal production image file to the simulated disk drive (RAM Disk) of the bare metal server through the bare metal computing module. The bare metal agent module performs hash operation on the bare metal image file uploaded by the bare metal computing module to check the integrity of the data, thereby ensuring that the bare metal image file is reliably uploaded to the RAM Disk of the bare metal server.

[0134] Furthermore, the bare metal computing module adaptively calculates the disk block size coefficient required for burning based on the hardware configuration parameters of the bare metal server. The bare metal agent module executes the image file burning task based on the block size coefficient calculated by the bare metal computing module and writes the bare metal image file in multiple tasks. The method is implemented by the underlying code and does not depend on the OpenStack Ironic module, thus effectively avoiding the use of the OpenStack platform and the installation of multiple modules. The image file is downloaded in multiple tasks on the bare metal server side, thereby realizing the image file burning and bare metal server deployment tasks and avoiding platform bloat.

[0135] This invention also discloses a deployment apparatus based on a bare metal server, used to implement the method executed by the aforementioned virtualization management platform, such as... Figure 5 As shown, the device includes a receiving unit 510, a processing unit 520, and a transmitting unit 530. In addition, the device may include other units or modules, such as a storage unit.

[0136] The receiving unit 510 is used to receive a first request message sent by the bare metal server, wherein the first request message includes the configuration parameters of the bare metal server.

[0137] The processing unit 520 is used to call an adaptive algorithm based on the configuration parameters to determine the block size coefficient of the disk.

[0138] The sending unit 530 is used to send the block size coefficient to the bare metal server through a preset command. The block size coefficient is used to assist the bare metal server in completing the image file burning task.

[0139] Optionally, in one specific implementation of this embodiment, the processing unit 520 is further configured to invoke a shutdown command and send the shutdown command to the bare metal server through the sending unit 530, wherein the shutdown command is used to instruct the bare metal server to shut down.

[0140] It also includes an acquisition unit, which is used to acquire relevant parameters for network startup of the bare metal server; the processing unit 520 is also used to set the bare metal server to start from the network according to the relevant parameters for network startup.

[0141] Optionally, in another specific embodiment of this example, the acquisition unit is specifically used to acquire the identifier of the bare metal server; and generate relevant parameters for network startup based on the identifier of the bare metal server, the relevant parameters for network startup including: the bare metal server IP address and the system location information of the operating system.

[0142] Optionally, in another specific embodiment of this example, the acquisition unit is further configured to acquire bare metal custom configuration information, the bare metal custom configuration information including a PXE configuration file; the processing unit 520 is further configured to configure the bare metal server to start from the network according to the relevant parameters of network startup and the PXE configuration file.

[0143] Optionally, in another specific embodiment of this example, the configuration parameters of the bare metal server include: number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size;

[0144] The processing unit 520 is also used to obtain the weight values ​​corresponding to the number of CPU cores, disk performance indicators IOPS, disk response time, disk throughput and memory resource size respectively; and to calculate the block size coefficient by weighted averaging the weight values ​​corresponding to each parameter in the configuration parameters of the bare metal server and each parameter.

[0145] Additionally, in another embodiment, such as Figure 6 As shown, this application also provides another deployment device, such as Figure 6 As shown, the device includes: an acquisition unit 610, a verification unit 620, a transmission unit 630, a receiving unit 640, and a processing unit 650. Furthermore, the device may include other units or modules, such as a storage unit.

[0146] The acquisition unit 610 is used to acquire the image file.

[0147] The verification unit 620 is used to perform integrity verification on the image file.

[0148] The sending unit 630 is used to send a first request message to the bare metal computing module after the verification unit 620 passes the integrity verification of the image file. The first request message includes the configuration parameters of the bare metal server.

[0149] The receiving unit 640 is used to receive a preset command fed back by the bare metal calculation module according to the first request message, wherein the preset command includes a block size coefficient.

[0150] The processing unit 650 is used to perform the burning task of the image file in multiple channels using the block size coefficient, and to boot from the local hard disk.

[0151] Optionally, the preset command is the dd command.

[0152] Optionally, in one specific embodiment of this example, the sending unit 630 is further configured to send a second request message to the image management module, the second request message being used to request the image file; the obtaining unit 610 is further configured to receive the image file fed back by the image management module according to the second request message.

[0153] Optionally, in another specific embodiment of this example, the acquisition unit 610 is further configured to acquire multiple TCP links established with the image management module; the receiving unit 640 is further configured to utilize the multiple TCP links to simultaneously receive multiple image sub-files, the multiple image sub-files forming the complete image file.

[0154] Optionally, in another specific embodiment of this example, the bare metal server includes a bare metal proxy module, and the bare metal server and the bare metal proxy module include multiple transmission channels.

[0155] The processing unit 650 is also used to transmit the image file from the bare metal proxy module using the multiple transmission channels and to simultaneously burn the image file.

[0156] Optionally, in another specific embodiment of this example, the sending unit 630 is further configured to send the image burning result to the bare metal computing module before booting from the local hard disk.

[0157] The receiving unit 640 is also used to receive the calling command fed back by the bare metal computing module based on the image burning result.

[0158] In addition, the device also includes a boot unit for booting from a local hard disk according to the invocation command.

[0159] This invention also provides an electronic device, such as... Figure 7 As shown, the electronic device can be as described above. Figure 1 The Portal server 100 shown could also be a bare metal server 21 in a bare metal resource pool, or any switch. Furthermore, this electronic device could also be a bare metal computing module or a mirror management module.

[0160] The electronic device includes a processor 110 and a memory 120, which can be connected via a bus or other means. Figure 7 For example, the connection is via a bus. Furthermore, the electronic device also includes at least one interface 130, which can be a communication interface or other interface; this embodiment does not impose any limitations on this.

[0161] The processor 110 can be a central processing unit (CPU). The processor 110 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0162] The memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the video synthesis method in this embodiment of the invention. The processor 110 executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory 120, thereby implementing the bare-metal server-based deployment method in the above method embodiments.

[0163] The memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor 110, etc. Furthermore, the memory 120 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 120 may optionally include memory remotely located relative to the processor 110, and these remote memories may be connected to the processor 110 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0164] Additionally, at least one interface 130 is used for communication between the electronic device and external devices, such as communication with a switch, bare-metal server, or client. Optionally, at least one interface 130 can also be used to connect peripheral input / output devices, such as a keyboard or display screen.

[0165] The one or more modules are stored in the memory 120, and when executed by the processor 110, they perform actions such as... Figures 2 to 4The bare metal server-based deployment method shown in the embodiment.

[0166] In addition, embodiments of this application also provide a bare metal server deployment system, the system including as follows Figure 1 The device shown includes a portal server, a bare metal server, and at least one switch, and the structure of each device can be as described above. Figure 7 The electronic device shown includes a Portal server comprising a virtualization management platform.

[0167] The bare metal server is used to obtain an image file, perform an integrity check on the image file, and, after the integrity check passes, send a first request message to the virtualization management platform, the first request message including the configuration parameters of the bare metal server.

[0168] The virtualization management platform is used to receive the first request message, call an adaptive algorithm according to the configuration parameters to determine the block size coefficient of the disk, and send the block size coefficient to the bare metal server through a preset command;

[0169] The bare metal server is also used to receive the preset command, use the block size coefficient carried in the preset command to perform the burning task of the image file in multiple channels, and boot from the local hard disk.

[0170] In addition, the virtualization management platform and bare metal server are also used to execute the method steps of the foregoing embodiments, as described in the preceding method embodiments. This embodiment will not be described in detail here.

[0171] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0172] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A deployment method based on bare metal servers, characterized in that, Applied to a virtualization management platform, the method includes: The system receives a first request message from a bare metal server, the first request message including the configuration parameters of the bare metal server; the configuration parameters of the bare metal server include: number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size; The adaptive algorithm is invoked based on the configuration parameters to determine the disk block size coefficient; The block size coefficient is sent to the bare metal server via a preset command. The block size coefficient is used to assist the bare metal server in changing the size of blocks in the input and output streams according to the block size coefficient in order to complete the image file burning task. The step of calling the adaptive algorithm based on the configuration parameters to determine the disk block size coefficient includes: Obtain the weight values ​​corresponding to the number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size, respectively; The block size coefficient is calculated by weighting the weight values ​​of each parameter in the configuration parameters of the bare metal server and each parameter individually.

2. The method according to claim 1, characterized in that, Before receiving the first request message sent by the bare metal server, the method further includes: A shutdown command is invoked and sent to the bare metal server, the shutdown command being used to instruct the bare metal server to shut down; Obtain the relevant parameters for network booting of the bare metal server; Based on the relevant parameters for network startup, configure the bare metal server to start from the network.

3. The method according to claim 2, characterized in that, The parameters for obtaining network boot-up information for the bare metal server include: Obtain the identifier of the bare metal server; Based on the identifier of the bare metal server, the relevant parameters for network startup are generated. The relevant parameters for network startup include: the bare metal server IP address and the system location information of the operating system.

4. The method according to claim 2, characterized in that, Before receiving the first request message sent by the bare metal server, the method further includes: Obtain bare metal custom configuration information, which includes the system type information to be deployed on the bare metal server; The step of setting the bare metal server to boot from the network according to the relevant parameters for network boot includes: Based on the relevant parameters for network startup and the system type information, configure the bare metal server to start from the network.

5. A deployment method based on bare metal servers, characterized in that, Applied to a bare metal server, the method includes: Obtain the image file and perform an integrity check on the image file; Once the integrity verification passes, a first request message is sent to the virtualization management platform. The first request message includes the configuration parameters of the bare metal server. Receive a preset command from the virtualization management platform based on the first request message, wherein the preset command includes a block size coefficient for the disk; The block size coefficient is used to change the block size in the input and output streams, and the image file burning task is performed in multiple channels, and the system boots from the local hard drive. The configuration parameters of the bare metal server include: number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size; The block size factor of the disk is determined based on the following methods: Obtain the weight values ​​corresponding to the number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size, respectively; The block size coefficient is calculated by weighting the weight values ​​of each parameter in the configuration parameters of the bare metal server and each parameter individually.

6. The method according to claim 5, characterized in that, The process of obtaining the image file includes: Send a second request message to the image management module, the second request message being used to request the image file; Receive the image file from the image management module based on the second request message.

7. The method according to claim 6, characterized in that, Receiving the image file returned by the image management module according to the second request message includes: Obtain multiple TCP links established with the image management module; The multiple TCP links are used to simultaneously receive multiple image sub-files, which together form the complete image file.

8. The method according to any one of claims 5-7, characterized in that, The bare metal server includes a bare metal proxy module, and there are multiple transmission channels between the bare metal server and the bare metal proxy module; The multi-channel burning task of the image file includes: The image file is transmitted from the bare metal proxy module using the multiple transmission channels, and the image file is burned synchronously.

9. The method according to any one of claims 5-7, characterized in that, Before booting from the local hard drive, the following is also included: Send the image burning result to the virtualization management platform; The booting from the local hard drive includes: The system receives a call command from the virtualization management platform based on the image burning result, and boots from the local hard drive according to the call command.

10. A deployment device based on a bare metal server, characterized in that, The device includes: The receiving unit is configured to receive a first request message sent by the bare metal server, wherein the first request message includes the configuration parameters of the bare metal server; the configuration parameters of the bare metal server include: number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size; The processing unit is used to call an adaptive algorithm based on the configuration parameters to determine the block size coefficient of the disk. The sending unit is used to send the block size coefficient to the bare metal server through a preset command. The block size coefficient is used to assist the bare metal server in changing the size of the blocks in the input and output streams according to the block size coefficient in order to complete the image file burning task. The step of calling the adaptive algorithm based on the configuration parameters to determine the disk block size coefficient includes: Obtain the weight values ​​corresponding to the number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size, respectively; The block size coefficient is calculated by weighting the weight values ​​of each parameter in the configuration parameters of the bare metal server and each parameter individually.

11. A deployment device based on a bare metal server, characterized in that, The device includes: The acquisition unit is used to acquire image files; The verification unit is used to perform integrity verification on the image file. The sending unit is configured to send a first request message to the virtualization management platform after the verification unit passes the integrity verification of the image file. The first request message includes the configuration parameters of the bare metal server. The receiving unit is configured to receive a preset command fed back by the virtualization management platform according to the first request message, wherein the preset command includes a disk block size coefficient; The processing unit is used to change the size of blocks in the input and output streams using the block size coefficient, perform the burning task of the image file in multiple channels, and boot from the local hard disk; The configuration parameters of the bare metal server include: number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size; The block size factor of the disk is determined based on the following methods: Obtain the weight values ​​corresponding to the number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size, respectively; The block size coefficient is calculated by weighting the weight values ​​of each parameter in the configuration parameters of the bare metal server and each parameter individually.

12. A bare-metal server deployment system, characterized in that, The system includes a virtualization management platform and a bare metal server, wherein the virtualization management platform and the bare metal server are connected via at least one switch; The bare metal server is used to acquire an image file, perform integrity verification on the image file, and, after the integrity verification passes, send a first request message to the virtualization management platform. The first request message includes the configuration parameters of the bare metal server. The configuration parameters of the bare metal server include: number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size. The virtualization management platform is used to receive the first request message, call an adaptive algorithm according to the configuration parameters to determine the block size coefficient of the disk, and send the block size coefficient to the bare metal server through a preset command; The bare metal server is also used to receive the preset command, change the size of the blocks in the input and output streams using the block size coefficient carried in the preset command, perform the burning task of the image file in multiple channels, and boot from the local hard disk; The step of calling the adaptive algorithm based on the configuration parameters to determine the disk block size coefficient includes: Obtain the weight values ​​corresponding to the number of CPU cores, disk performance metrics IOPS, disk response time, disk throughput, and memory resource size, respectively; The block size coefficient is calculated by weighting the weight values ​​of each parameter in the configuration parameters of the bare metal server and each parameter individually.

13. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory is coupled to the processor; The memory stores computer-readable program instructions that, when executed by the processor, implement the deployment method based on a bare metal server as described in any one of claims 1 to 4, or 5 to 9.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the deployment method based on a bare metal server as described in any one of claims 1 to 4, or 5 to 9.

Images