Out-of-band batch deployment system for servers in production environments

Abstract

This disclosure provides an out-of-band batch deployment system for servers in a production environment. One specific implementation of the system includes: a deployment device, various servers to be deployed, and a switch, wherein: the out-of-band management port of each server to be deployed is connected to the switch via an out-of-band network; the deployment device is connected to the switch and configured to: collect information from each out-of-band deployment server; create an operating system smart installation image corresponding to at least one of the servers to be deployed; execute multiple concurrent installation threads to mount the created at least one operating system smart installation image to at least one server to be deployed; and control the servers to be deployed to boot from their corresponding operating system smart installation images for unattended installation and configuration. This implementation improves the security of the servers to be deployed during the installation and configuration process.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of computer technology, and more specifically to out-of-band batch deployment systems for servers suitable for production environments. Background Technology

[0002] With the accelerated digital transformation of enterprise businesses, the number of servers is growing exponentially. Out-of-band batch deployment systems for servers in production environments provide operating system deployment services for various servers in production environments (e.g., government servers, servers in real IT environments that actually carry core business operations and provide services to end users). Currently, the common method for deploying operating systems on individual servers is to use the server's intranet port to boot the server via PXE or iPXE, and then install the operating system over the network. PXE (Preboot Execution Environment) and iPXE booting require a DHCP (Dynamic Host Configuration Protocol) server to assign IP addresses to the servers to be deployed, provide network configuration information, and specify the address of the boot server to achieve network booting and system deployment.

[0003] However, when deploying the operating system on each server using the above method, the following technical problems often arise:

[0004] First, attackers can set up a fake DHCP server on the network to provide incorrect network configurations to the servers to be deployed or to maliciously start the servers to be deployed, thereby achieving their attack. Furthermore, during the PXE boot process, much data is transmitted via unencrypted broadcasts (e.g., boot files and network configuration information), making this data susceptible to eavesdropping by anyone on the network, allowing them to obtain sensitive information. This results in low security for the various servers to be deployed in a production environment during the operating system deployment process.

[0005] Furthermore, in the process of adopting technical solutions to address the first technical problem mentioned above, the following technical issues often arise: Second, during the execution of multiple concurrent installation threads, all servers to be deployed share the same network bandwidth. If all servers attempt to download or mount the image simultaneously, network congestion may occur, resulting in lower operating system installation speed and success rate. (For example, servers to be deployed may compete for limited network bandwidth and I / O resources, causing some installation tasks to fail or complete slowly).

[0006] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not form prior art known to those skilled in the art. Summary of the Invention

[0007] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0008] Some embodiments of this disclosure provide out-of-band batch deployment operating systems and out-of-band batch deployment methods for servers in production environments, in order to address one or more of the technical intentions mentioned in the background section above.

[0009] In a first aspect, some embodiments of this disclosure provide an out-of-band batch deployment system for servers suitable for a production environment. The system includes: a deployment device, various servers to be deployed, and a switch. Each server to be deployed has an out-of-band management port connected to the switch via an out-of-band network, wherein the switch is not connected to a service network. The deployment device is connected to the switch and configured to perform the following steps: collecting out-of-band deployment server information for each server to be deployed through its respective out-of-band management port, wherein each out-of-band deployment server information includes verification information and server information to be deployed; verifying each server to be deployed based on the out-of-band deployment server information; and assigning at least one server information corresponding to at least one server to be deployed that has passed verification. The information is stored in a preset list to be deployed; based on the preset unattended installation requirements and the preset list to be deployed, an operating system smart installation image is created for each of the at least one server to be deployed, wherein the operating system smart installation image includes an operating system installation configuration file; multiple concurrent installation threads are executed to mount the at least one created operating system smart installation image to the at least one server to be deployed through at least one out-of-band management port of the at least one server to be deployed; for each of the at least one server to be deployed, the server is controlled to start from its corresponding operating system smart installation image, so that the server to be deployed can perform unattended installation and configuration according to the operating system installation configuration file in the operating system smart installation image, and then shut down after installation and configuration.

[0010] Secondly, some embodiments of this disclosure provide an out-of-band batch deployment method for servers suitable for production environments. The method includes: collecting out-of-band deployment server information for each server to be deployed through various out-of-band management ports, wherein each out-of-band deployment server information includes verification information and server information to be deployed; verifying each server to be deployed based on the out-of-band deployment server information, and storing at least one server information corresponding to at least one verified server to be deployed in a preset deployment list; creating an operating system smart installation image corresponding to each of the at least one server to be deployed according to preset unattended installation requirements and the preset deployment list, wherein the operating system smart installation image includes an operating system installation configuration file; executing multiple concurrent installation threads to mount the created at least one operating system smart installation image to the at least one server to be deployed through at least one out-of-band management port of the at least one server to be deployed; for each of the at least one server to be deployed, controlling the server to start from its corresponding operating system smart installation image, so that the server to be deployed can perform unattended installation and configuration according to the operating system installation configuration file in the operating system smart installation image, and shutting down after installation and configuration.

[0011] The above embodiments of this disclosure have the following beneficial effects: The out-of-band batch deployment system for servers in a production environment, as described in some embodiments of this disclosure, improves the security of the servers to be deployed during the deployment process. Specifically, the reason for the low security of the servers to be deployed during the operating system deployment process is that attackers can set up a fake DHCP server on the network, provide incorrect network configurations to the servers to be deployed, or maliciously start the servers to be deployed, thereby achieving an attack. Furthermore, during the PXE boot process, much data is transmitted via unencrypted broadcast (e.g., boot files and network configuration information), which allows anyone on the network to eavesdrop on this data and obtain sensitive information, resulting in low security for the servers to be deployed in the production environment during the operating system deployment process. Based on this, the out-of-band batch deployment system for servers in a production environment, as described in some embodiments of this disclosure, includes: a deployment device, various servers to be deployed, and a switch, wherein: the out-of-band management port of each of the servers to be deployed is connected to the switch via an out-of-band network, and the switch is not connected to the business network. Therefore, each server to be deployed is connected to the switch via an out-of-band management port, and the switch is not connected to the service network. The deployment activity takes place in an isolated network, avoiding direct interaction with the public network, thereby reducing the possibility of attacks during deployment by forging DHCP servers. The aforementioned deployment device is connected to the aforementioned switch and is configured to perform the following steps: collecting out-of-band deployment server information from each server to be deployed through each out-of-band management port, wherein each out-of-band deployment server information includes verification information and server information to be deployed. Then, based on each out-of-band deployment server information, the aforementioned servers to be deployed are verified, and at least one server information corresponding to at least one verified server is stored in a preset deployment list. Thus, by collecting and verifying the out-of-band deployment server information of the servers to be deployed, it can be ensured that only information corresponding to authenticated servers to be deployed can be added to the deployment list, further preventing interference from unauthorized devices. Next, according to preset unattended installation requirement information and the aforementioned preset deployment list, an operating system smart installation image corresponding to each of the at least one servers to be deployed is created, wherein the operating system smart installation image includes an operating system installation configuration file. Next, multiple concurrent installation threads are executed, mounting at least one created operating system smart installation image to at least one out-of-band management port of at least one server to be deployed. This allows the operating system smart installation image, including the operating system installation configuration file, to be transmitted via the out-of-band management port over an isolated out-of-band network, reducing the possibility of sensitive information leakage.Subsequently, for each of the at least one servers to be deployed, the server is controlled to boot from its corresponding smart installation image of the operating system. This allows the server to perform unattended installation and configuration based on the operating system installation configuration file within the smart installation image, and then shut down after installation and configuration. This unattended installation and configuration reduces manual intervention during the installation process. Furthermore, by controlling the server to boot from its corresponding smart installation image, the boot process is ensured to originate from a trusted source, preventing the loading of malware or misconfigurations and improving the security of the servers to be deployed in the production environment during installation and configuration. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is an architecture diagram of an exemplary system for out-of-band batch deployment of servers in a production environment, based on the present disclosure.

[0014] Figure 2 Flowcharts of some embodiments of the out-of-band bulk deployment method for servers applicable to a production environment according to this disclosure. Detailed Implementation

[0015] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0016] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0017] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0018] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0019] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0020] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] Figure 1 An exemplary system architecture 100 for an out-of-band batch deployment system for servers suitable for a production environment, to which some embodiments of the present disclosure may be applied, is shown.

[0022] like Figure 1 As shown, the system architecture 100 may include: a deployment device 101, various servers to be deployed 103, and a switch 102. Each of the servers to be deployed has an out-of-band management port connected to the switch via an out-of-band network. The switch is not connected to the business network. The deployment device connects to the switch via its out-of-band management port. The deployment device can be a dedicated server or service node for batch deployment of server operating systems. Each of the servers to be deployed 103 can be a server in a production environment that requires operating system deployment and configuration (e.g., a government server, a server in a real IT environment within an enterprise or organization that actually carries core business operations and provides services to end users). The business network can be a network used to carry core business data communication in the actual production environment of an organization or enterprise.

[0023] In some embodiments, the deployment device is connected to the switch, and the deployment device is configured to perform the following steps:

[0024] The first step involves collecting out-of-band deployment server information from each server to be deployed through various out-of-band management ports. Each out-of-band deployment server information entry includes verification information and server information. The server information includes server vendor information, server model, server serial number, and server hardware configuration information. The server hardware configuration information represents the server's hardware. The verification information verifies whether the server to be deployed is authorized. For example, the verification information may include at least one of the following: server out-of-band IP address, username, and password. The password may correspond to either the server out-of-band IP address or the username. Each out-of-band deployment server information entry corresponds to one of the servers to be deployed. Each out-of-band management port is an out-of-band management port on one of the servers to be deployed.

[0025] The second step involves verifying each out-of-band deployment server based on its information, and storing at least one out-of-band server information corresponding to the verified server in a preset deployment list. In practice, for each out-of-band deployment server, the deployment device can determine the verification information included in that information as the information to be verified. This verification information may include the server's out-of-band IP address and password. The deployment device can then determine the out-of-band IP address included in the verification information as the server's out-of-band IP address to be queried. Next, the deployment device can query a preset mapping table for the pre-registered or pre-assigned password corresponding to the queried server's out-of-band IP address. Then, the deployment device can compare the queried pre-registered or pre-assigned password with the password included in the verification information. If the pre-registered or pre-assigned password matches the password included in the verification information, the deployment device can determine the out-of-band deployment server corresponding to that information as a verified server. Similarly, the verification information may include the username and password. The aforementioned deployment device can identify the username included in the information to be verified as the username to be queried. Then, the deployment device can query a pre-registered or pre-assigned password corresponding to the username to be queried from a preset mapping table. Next, the deployment device can compare the queried pre-registered or pre-assigned password with the password included in the information to be verified. If it determines that the pre-registered or pre-assigned password matches the password included in the information to be verified, the deployment device can identify the server to be deployed corresponding to the out-of-band deployment server information as the verified server to be deployed.

[0026] The third step involves creating a smart installation image of the operating system corresponding to each of the at least one deployable server, based on the preset unattended installation requirements information and the aforementioned preset deployment list. This smart installation image includes an operating system installation configuration file. The preset unattended installation requirements information includes various sub-information items related to unattended installation requirements, with each of the at least one deployable server corresponding to one of these sub-information items. These sub-information items can be manually entered installation requirements corresponding to the deployable server, or they can be installation requirements filled in by the user through the deployment machine's device management page. The installation requirements information may include, but is not limited to, at least one of the following: operating system type (e.g., RHEL, Windows Server, Ubuntu), version (e.g., RHEL 8.5, Windows Server 2019), associated native image file path, system installation configuration (including but not limited to: user configuration, language support, system partition configuration, software package installation configuration, system installation source configuration, etc.), and preset configurations (e.g., hostname, network configuration, etc.).

[0027] In some optional implementations of certain embodiments, the deployment device is further configured to create an operating system smart installation image corresponding to each of at least one server to be deployed, based on preset unattended installation requirement information and the preset list to be deployed, through the following steps:

[0028] First, for each of at least one of the servers to be deployed, perform the following creation steps:

[0029] The first sub-step involves identifying the unattended installation requirement sub-information that corresponds to the server to be deployed from among the aforementioned unattended installation requirement sub-information as the matching unattended installation requirement sub-information.

[0030] The second sub-step involves parsing and validating the aforementioned unattended installation requirement sub-information to obtain requirement metadata. In practice, the deployment device can use NLP keyword extraction methods to parse the unattended installation requirement sub-information and extract key information (such as operating system type, version, associated image file, disk capacity, partition scheme, etc.). At least one extracted key piece of information is then validated, and those that pass the validation are identified as requirement metadata. This requirement metadata includes, but is not limited to, the following: operating system type, version, and disk capacity. As an example, the format of each key piece of information extracted can be checked, and those that pass the check are identified as requirement metadata. (For example, the operating system version can be matched using regular expressions, and the disk capacity format can be checked to see if it is a number plus a unit (e.g., 50G, 100GiB, etc.).

[0031] The third sub-step involves customizing the installation and configuration of the server to be deployed based on the aforementioned requirement metadata, resulting in an unattended installation configuration file, which serves as the operating system installation configuration file. In practice, requirement metadata (such as operating system type, version, image source, disk partitions, etc.) can be converted into automated configuration files in a specific format (such as Kickstart files, AutoUnattend.xml files, preseed.cfg files) as unattended installation configuration files. Specifically, a parser generation tool (e.g., ANTLR 3.0ea8 parser generator) can be used to convert the requirement metadata into structured data (such as JSON / YAML). The converted requirement metadata is then populated into a preset configuration file template, and this populated template is used as the unattended installation configuration file for the operating system installation configuration file. Optionally, a configuration file parsing library can be used to convert the requirement metadata into structured data. Optionally, based on the type of operating system to be deployed and the system installation configuration, a corresponding unattended installation configuration file for the operating system is generated: In response to determining that the operating system type included in the requirement metadata is a RHEL series operating system (RHEL, CentOS, RockyLinux, etc.): First, a kickstart file (.ks or .cfg format) is generated based on the system installation configuration.The kickstart file mentioned above includes, but is not limited to: System installation source configuration: specifying the operating system installation source location (e.g., cdrom, nfs, http, etc.); System language and time zone configuration: generating corresponding configuration items based on the system language support and system time zone configuration in the system installation configuration; System user configuration: generating configuration items such as root password and user creation based on the system user configuration in the system installation configuration; System partition configuration: generating partition configuration items such as autopart, part, logvol, etc. based on the system partition configuration generated by personalized configuration processing; Package installation configuration: generating the %packages configuration section based on the package installation configuration / system category in the system installation configuration, specifying the packages or package groups to be installed; System preset configuration integration: adding the copying of the operating system preset configuration file and the execution command of the preset configuration script in the %post configuration section of the kickstart file; Windows series operating systems (Windows Server, Windows, etc.): generating an AutoUnattend.xml file based on the system installation configuration; The AutoUnattend.xml file includes, but is not limited to: System installation source configuration: specifies the operating system installation source location; System language and time zone configuration: generates corresponding configuration items based on the language support and system time zone configuration in the system installation configuration; User configuration: generates user account configuration items based on the system user configuration in the system installation configuration; System partition configuration: generates disk partition configuration items based on the system partition configuration generated by the personalized configuration processing; Package installation configuration: generates package installation configuration items based on the package installation configuration in the system installation configuration; System preset configuration integration: adds the execution command of the operating system preset configuration script in the FirstLogonCommands configuration section of the AutoUnattend.xml file.

[0032] The fourth sub-step involves generating post-installation scripts and configuration files based on the aforementioned requirement metadata. In practice, the executing entity can determine the operating system type and version included in the requirement metadata. Next, the deployment device can obtain the operating system's default configuration file corresponding to the operating system type and version. This default configuration file includes a set of system default configuration parameters. This set of system default configuration parameters can be a set of parameters generated by default during operating system installation or initialization, covering parameters related to partitioning and storage, network, user permissions, and services. For example, the system default configuration parameters could be {partitioning and storage configuration information: hard disk: / dev / sda, partition table type: GPT; network configuration parameters: IP address: 192.168.1.10, subnet mask: 255.255.255.0, gateway: 192.168.1.1}. In practice, a pre-written script (which can be written using Bash, Python, etc.) is used to read the system default configuration parameters and parse it into variables or data structures. Then, using template engine technology, a post-installation script and a post-installation configuration file corresponding to the system's preset configuration parameter information set are automatically generated based on a preset JSON configuration file. The post-installation script can be a script used to automate operations (such as configuring the network or installing software packages) after system installation. The post-installation configuration file can overwrite or modify the system's configuration file.

[0033] The fifth sub-step involves integrating the aforementioned operating system installation configuration file, post-installation script, and post-installation configuration file into a preset native image to obtain the native image to be packaged. In practice, the operating system installation configuration file, post-installation script, and post-installation configuration file can be integrated into a preset native image. This preset native image can be a preset system image file.

[0034] The sixth sub-step involves packaging the aforementioned native image to be packaged, and then identifying the packaged native image as the smart installation image of the operating system corresponding to the server to be deployed. In practice, system packaging technology can be used to package the aforementioned native image to be packaged.

[0035] The fourth step involves executing multiple concurrent installation threads to mount at least one smart installation image of an operating system to at least one of the aforementioned servers through at least one out-of-band management port of at least one server to be deployed.

[0036] In addressing the technical challenges of the aforementioned background technologies, the application scenario—automatic deployment of large-scale server operating systems—often presents the following technical issues: During the execution of multiple concurrent installation threads, all servers to be deployed share the same network bandwidth. If all servers attempt to download or mount the image simultaneously, network congestion may occur, leading to lower operating system installation speed and success rate. (For example, servers may compete for limited network bandwidth and I / O resources, causing some installation tasks to fail or complete slowly). This application scenario requires the following characteristics: suitability for high-concurrency environments, and the ability to dynamically adjust task concurrency based on real-time system load to ensure the success rate and overall efficiency of batch deployment tasks. Faced with these technical challenges, we decided to adopt the following solution:

[0037] In some optional implementations of certain embodiments, the aforementioned deployment device is further configured to execute multiple concurrent installation threads by mounting at least one created operating system smart installation image to at least one server to be deployed via at least one out-of-band management port of at least one server to be deployed:

[0038] The first step is to determine the target number of servers to be deployed, which is the number of servers to be deployed that need to be identified at least one.

[0039] The second step is to mount at least one smart installation image of an operating system to at least one of the aforementioned servers in parallel through at least one out-of-band management port of at least one server to be deployed, in response to the target number being less than or equal to a preset threshold.

[0040] Third, in response to the determination that the target number is greater than the above preset threshold, the following dynamic concurrent installation process is performed:

[0041] The first sub-step involves collecting the user's own resource data, which includes CPU resource information, memory resource information, disk resource information, and network resource information. Specifically, the CPU resource information can be the CPU utilization rate. The memory resource information can be the current memory utilization rate. The disk resource information can be the current disk utilization rate. The network resource information can be the network bandwidth utilization rate.

[0042] The second sub-step involves collecting the switch's network resource information. This network resource information can represent the out-of-band network bandwidth utilization of the switch. In practice, SNMP tools (such as snmpwalk and snmpget) can be used to obtain the switch's network resource information.

[0043] The third sub-step involves determining the initial number of mounts based on the aforementioned CPU resource information. In response to the determination that the CPU utilization rate indicated by the CPU resource information is less than a preset utilization rate, the preset mount number (e.g., 3) is determined as the initial mount number.

[0044] The fourth sub-step generates resource utilization scoring information based on the CPU resource information, memory resource information, disk resource information, network resource information, and the aforementioned switch network resource information. In practice, the resource utilization score can be determined by the weighted sum of the utilization rates represented by the CPU resource information, memory resource information, disk resource information, network resource information, and the aforementioned switch network resource information, along with their corresponding preset weights. For example, if the CPU resource information indicates a CPU utilization rate of 80%, the memory resource information indicates a memory utilization rate of 70%, the disk resource information indicates a disk utilization rate of 60%, the network resource information indicates a network utilization rate of 50%, and the switch network resource information indicates a switch network utilization rate of 30%, and assuming the following weights: CPU weight: 0.4, memory weight: 0.3, disk weight: 0.2, network weight: 0.1, then the resource utilization score can be (0.8 × 0.4) + (0.7 × 0.3) + (0.6 × 0.2) + (0.5 × 0.1) = 0.7.

[0045] The fifth sub-step involves mounting at least one smart installation image of an operating system to at least one server to be deployed in batches and in parallel, based on the resource usage score information and the initial mounting quantity.

[0046] The above technical solution and its related content, as an inventive point of this disclosure, solve the second technical problem mentioned in the background: "low operating system installation speed and success rate." Factors leading to low operating system installation speed and success rate often include: during the execution of multiple concurrent installation threads, all servers to be deployed share the same network bandwidth. If all servers to be deployed attempt to download or mount the image simultaneously, network congestion may occur, resulting in low operating system installation speed and success rate. (For example, servers to be deployed may compete for limited network bandwidth and I / O resources, leading to some installation tasks failing or completing slowly). Solving these factors can improve the low operating system installation speed and success rate. To achieve this, firstly, the number of servers to be deployed (at least one to be deployed) is determined as the target number. Then, in response to the target number being less than or equal to a preset threshold, at least one created intelligent operating system installation image is mounted in parallel to the at least one to be deployed server through at least one out-of-band management port of the at least one to be deployed server. In response to the determination that the target number exceeds the aforementioned preset threshold, the following dynamic concurrent installation process is executed: First, the system collects its own resource data, including CPU resource information, memory resource information, disk resource information, and network resource information. This yields its own resource data representing the current resource occupancy. Next, the system collects the switch's network resource information. Then, based on the aforementioned CPU resource information, the initial number of mounts is determined. Following this, based on the CPU resource information, memory resource information, disk resource information, network resource information, and the aforementioned switch network resource information, resource occupancy score information is generated. This yields a score that quantitatively assesses the overall system load, i.e., the resource occupancy score information. Then, based on the aforementioned resource occupancy score information and the initial mount number, at least one created operating system smart installation image is mounted in batches and in parallel to at least one server to be deployed. This allows for dynamic control of concurrency based on real-time system load, avoiding excessive concurrency when resources are scarce. Because a dynamic batch concurrency mechanism based on real-time resource monitoring and scoring is adopted, instantaneous overload of network bandwidth and local resources during large-scale concurrent installations is avoided. This alleviates network congestion, reduces resource contention, and improves the overall speed and success rate of batch operating system installations.

[0047] In addressing the technical challenges mentioned above, and considering the application scenario of large-scale server operating system batch parallel deployment, the following technical issues often arise: When installing operating systems on a large number of servers via parallel image mounting, improperly set concurrent mounting limits (e.g., too high) can excessively consume the computing resources (CPU, memory) of deployment nodes and shared switch network bandwidth, leading to a surge in system load, network congestion, and consequently, image transmission timeouts, mounting failures, overall deployment delays, or decreased success rates. Conversely, overly conservative limits fail to fully utilize available resources, resulting in low deployment efficiency. This application scenario requires the following characteristics: suitable for large-scale server operating system batch parallel deployment in high-concurrency environments. Faced with these technical challenges, we have decided to adopt the following solution:

[0048] The first step, based on resource usage scoring information, is to perform the following batch parallel mounting process:

[0049] The first sub-step, in response to determining that the above resource usage score information is greater than or equal to a preset lower limit and less than or equal to a preset upper limit, executes the following concurrent hold mount steps:

[0050] Sub-step one: Determine the initial mount quantity as the mount quantity, and for at least one of the at least one servers to be deployed, mount the operating system smart installation image corresponding to the at least one operating system smart installation image of the at least one server to be deployed to the at least one server to be deployed.

[0051] Sub-step two: Determine the number of mounted devices as the number of mounted devices.

[0052] Sub-step three: Based on the at least one already mounted quantity generated, generate the total number of mounted quantities. In practice, the aforementioned executing entity can determine the total number of mounted quantities as the sum of at least one already mounted quantity.

[0053] In sub-step four, in response to the determination that the total number of mounted devices is less than the target number, the system collects its own resource data and switch network resource information again to generate resource occupancy score information again.

[0054] The second sub-step is to perform a first resource assessment test on the resource data itself in response to determining that the resource occupancy score information is greater than the preset upper limit. After the first resource assessment test is passed, the initial mounting quantity is determined as the first mounting quantity to be updated, and the preset decrement number is determined as the decrement number.

[0055] The third sub-step, based on the first number of mounts to be updated and the decrement count, executes the following successive decrement mount steps:

[0056] Sub-step one involves generating a decreasing update mount quantity based on the first number of mounts to be updated and a preset decreasing quantity, mounting at least one operating system smart installation image (the decreasing update mount quantity) to the decreasing update mount quantity of servers to be deployed, and determining the decreasing update mount quantity as the number of mounts already mounted. In practice, the difference between the first number of mounts to be updated and the preset decreasing quantity can be used to determine the decreasing update mount quantity.

[0057] Sub-step two involves updating the decrement count based on a preset value. In practice, the sum of the decrement count and a preset value (e.g., 1) can be used to determine the target decrement parameter. Then, the target decrement parameter is updated to the decrement count.

[0058] Sub-step three: Update the first number of mounts to be updated based on the decreasing update mount quantity. In practice, the aforementioned executing entity can determine the decreasing update mount quantity as the first number of mounts to be updated, and then update the first number of mounts to be updated.

[0059] Sub-step four: Based on the at least one generated mounted quantity, generate the total number of mounted quantities. In practice, the sum of the at least one generated mounted quantity can be used to determine the total number of mounted quantities.

[0060] Sub-step five: In response to determining that the total number of mounted devices is less than the target number and that the number of decrements after the update is less than or equal to the preset number, the successive decrementing step is executed again based on the first number of mounted devices to be updated after the update and the number of decrements.

[0061] Sub-step six: In response to determining that the total number of mounted devices is less than the target number and that the updated number of reductions is greater than the preset number, collect its own resource data and switch network resource information again to generate resource occupancy score information again.

[0062] The second step is to perform the batch parallel mounting process again based on the regenerated resource usage score information.

[0063] The above-described technical solution and its related content, as an inventive point of this disclosure, solve the technical problem that "when installing operating systems on a large number of servers to be deployed in batches via parallel image mounting, if the concurrent mounting quantity is set improperly (e.g., too high), it will simultaneously over-consume the computing resources (such as CPU and memory) of the deployment nodes and the shared switch network bandwidth, leading to a surge in system load, network congestion, and consequently causing image transmission timeouts, mounting failures, overall deployment delays, or a decrease in success rate; if the concurrent quantity is too conservative, it will not be able to fully utilize available resources, resulting in low deployment efficiency." Solving these factors can reduce mounting failures and improve deployment success rate and efficiency. To achieve this, in practice, traditional methods lack a flexible and effective dynamic adjustment mechanism when setting the concurrent mounting quantity, making it difficult to accurately control the mounting quantity based on actual resource usage. This results in either excessively high concurrent mounting causing a series of problems or excessively low concurrent mounting causing resource waste and inefficiency. This disclosure performs batch parallel mounting processing based on resource usage scoring information. When the resource usage scoring information is within an appropriate range, a concurrent mounting step is executed to reasonably determine the initial mounting quantity and complete the corresponding mounting. When the resource usage scoring information is too high, a successive decreasing mounting step is executed after a first resource assessment to gradually reduce the number of mountings to avoid excessive resource consumption. At the same time, based on the relationship between the total number of mounted units and the target number, as well as the number of decreasing steps, subsequent operations are flexibly determined, such as collecting resource data again to generate new resource usage scoring information or continuing to execute the successive decreasing steps. Therefore, the number of concurrent mountings can be dynamically adjusted according to the actual resource situation, which avoids problems such as system load surges, network congestion, image transmission timeouts, mounting failures, overall deployment delays, or decreased success rates caused by excessively high concurrent mountings. It also prevents resource waste and low deployment efficiency caused by overly conservative concurrent mounting, effectively improving the efficiency and success rate of batch operating system installation.

[0064] In addressing the technical problems mentioned above, and considering the application scenario of large-scale server operating system batch parallel deployment, the following technical issues often arise: When resources are sufficient (i.e., resource consumption is reduced), to improve the deployment speed of batch parallel deployment of the operating system, a sequential incremental mounting of the operating system intelligent installation image is typically used. However, the lack of a maximum limit on the number of concurrent startups in sequential mounting can easily lead to excessive concurrency and system crashes. This application scenario requires the following characteristics: suitable for sequential incremental mounting of server operating systems under conditions of sufficient resources. Faced with the above technical problems, we decided to adopt the following solution:

[0065] Optionally, the aforementioned deployment equipment is further configured to:

[0066] The first step is to determine that the resource occupancy score information is less than the preset lower limit value, and to perform a second resource assessment test on the above-mentioned resource data. After the second resource assessment test is passed, the initial mounting quantity is determined as the second mounting quantity to be updated, and the preset increment number is determined as the increment number.

[0067] The second step involves executing the following incremental mounting steps based on the second number of mounts to be updated and the increment count:

[0068] The first sub-step involves generating an incremental update mount quantity based on the second number of mounts to be updated, the increment count, and the preset increase quantity. In response to determining that the incremental update mount quantity is less than the preset mount limit, the following steps are executed:

[0069] Sub-step one involves mounting at least one operating system smart installation image to an incrementally updated number of servers to be deployed, and determining the incrementally updated number of mounted images as the number already mounted.

[0070] Sub-step two involves updating the increment count based on a preset value. In practice, the executing entity can determine the target increment count as the sum of the preset value and the increment count. Then, the target increment count can be updated to the increment count.

[0071] Sub-step three involves updating the second number of mounts to be updated based on the incrementally updated mount quantity. In practice, the aforementioned executing entity can determine the incrementally updated mount quantity as the second number of mounts to be updated, and then update the second number of mounts to be updated accordingly.

[0072] Sub-step four: Based on the generated at least one mounted quantity, generate the total number of mounted quantities.

[0073] Sub-step five: In response to determining that the total number of mounted devices is less than the target number and that the increment count after the update is less than or equal to the preset number, the incremental step is executed again based on the updated second number of mounted devices to be updated and the increment count.

[0074] Sub-step six: In response to determining that the total number of mounted devices is less than the target number and that the updated increment count is greater than the preset count, collect its own resource data and switch network resource information again to generate resource occupancy score information again.

[0075] The second sub-step, in response to determining that the above-mentioned incremental update mount quantity is greater than or equal to the above-mentioned preset mount limit quantity, mounts at least one operating system smart installation image of the second number of operating system smart installation images to be updated to the second number of servers to be deployed, and determines the second number of mounts to be updated as the number of mounted.

[0076] The above-described technical solution and its related content, as an inventive point of this disclosure, solve the technical problem that "when resources are sufficient, i.e., resource consumption is reduced, in order to improve the deployment speed of the operating system in batch parallel deployment, the intelligent installation image of the operating system is usually mounted incrementally. However, in the incremental mounting, no limit is set on the maximum number of concurrent startups, which can easily cause excessive concurrency and system crashes." If the above factors are solved, the effect of reducing system crashes caused by excessive concurrency can be achieved. To achieve this effect: First, in response to determining that the above resource consumption score information is less than the above-preset lower limit, a second resource evaluation test is performed on the above-described resource data. After the second resource evaluation test passes, the initial mounting quantity is determined as the second mounting quantity to be updated, and the preset increment number is determined as the increment number. Then, based on the second number of mounts to be updated and the increment count, the following incremental mounting steps are performed: Based on the second number of mounts to be updated, the increment count, and the preset increase count, an incremental update mount count is generated. In response to determining that the above incremental update mount count is less than the preset mount limit, the following steps are performed: Mount at least one operating system smart installation image containing an incremental update mount count of operating system smart installation images to an incremental update mount count of servers to be deployed, and determine the incremental update mount count as the mounted count. The increment count is updated based on a preset value. The second number of mounts to be updated is updated based on the incremental update mount count. The total mounted count is generated based on the generated at least one mounted count. In response to the determination that the total number of mounted devices is less than the target number and the updated increment count is less than or equal to the preset number, the incremental step is executed again based on the updated second number of devices to be updated and the increment count. In response to the determination that the total number of mounted devices is less than the target number and the updated increment count is greater than the preset number, the system collects its own resource data and switch network resource information again to generate resource occupancy score information again. In response to the determination that the above-mentioned incremental update mounted device number is greater than or equal to the above-mentioned preset mounted upper limit number, at least one second number of operating system smart installation images to be updated are mounted to the second number of servers to be deployed, and the second number of devices to be updated is determined as the number of mounted devices. Therefore, when generating the incremental update mount quantity, it can be compared with the preset mount limit quantity to ensure that the mount quantity after each increment does not exceed the safe range. At the same time, based on the relationship between the total number of mounts and the target quantity, as well as the relationship between the number of increments and the preset number of increments, when resources are sufficient, it can effectively improve the speed of batch parallel deployment of the operating system by incrementally increasing the mounts, and avoid system crashes caused by excessive concurrency by setting an implicit limit on the maximum number of concurrent startups (the preset mount limit quantity).

[0077] In some optional implementations of certain embodiments, the above-mentioned deployment device is further configured to:

[0078] The first step is to perform the following installation status verification process for each of at least one of the servers to be deployed:

[0079] The first sub-step involves obtaining the power-on / off status information of the server to be deployed through its out-of-band management port. This power-on / off status information indicates whether the server is currently powered off or powered on. This information includes a power-on / off identifier (e.g., a power-on identifier or a power-off identifier). It should be noted that when the power-on / off status information indicates power-off, it includes the initial power-off time.

[0080] The second sub-step, in response to determining the power-on / off status information, including the initial power-off time, involves polling the power-on / off status at preset time intervals within a first preset time period following the initial power-off time, to obtain polled power-on / off status information and generate a polled power-on / off status information sequence. This polled power-on / off status information can indicate whether the server to be deployed is currently in a power-off or power-on state. This polled power-on / off status information can be represented by Boolean values; for example, true indicates the server is in a power-on state, and false indicates the server is in a power-off state.

[0081] The third sub-step, in response to determining that all polling power-on / off status information in the obtained polling power-on / off status information sequence represents a power-off state, controls the server to be deployed to restart and uninstall the operating system smart installation image.

[0082] In some optional implementations of certain embodiments, the above-mentioned deployment device is further configured to:

[0083] The first step involves obtaining power-on / off status information from the obtained polling power-on / off status information sequence, where each polling power-on / off status information represents a power-on state. After a second preset time, the power-on / off status information is obtained again to verify the power-on / off status information.

[0084] The second step involves, in response to determining and verifying the power-on / off status information representing the power-on status, recording information indicating the installation failure of the server to be deployed to a preset installation fault log, and sending a warning message indicating the installation failure of the server to be deployed to a preset terminal. In practice, the identifier of the server to be deployed can be determined, and then the text information indicating the installation failure of the server corresponding to the identifier (e.g., server 103 installation failed) can be recorded in the preset installation fault log. The information indicating the installation failure of the server to be deployed can be text information. In practice, the text information indicating the installation failure of the server corresponding to the identifier can be sent as a warning message to the preset terminal. The preset terminal can be a computer or mobile phone used by maintenance personnel.

[0085] The above embodiments of this disclosure have the following beneficial effects: The out-of-band batch deployment system for servers in a production environment, as described in some embodiments of this disclosure, improves the security of the servers to be deployed during the deployment process. Specifically, the reason for the low security of the servers to be deployed during the operating system deployment process is that attackers can set up a fake DHCP server on the network, provide incorrect network configurations to the servers to be deployed, or maliciously start the servers to be deployed, thereby achieving an attack. Furthermore, during the PXE boot process, much data is transmitted via unencrypted broadcast (e.g., boot files and network configuration information), which allows anyone on the network to eavesdrop on this data and obtain sensitive information, resulting in low security for the servers to be deployed in the production environment during the operating system deployment process. Based on this, the out-of-band batch deployment system for servers in a production environment, as described in some embodiments of this disclosure, includes: a deployment device, various servers to be deployed, and a switch, wherein: the out-of-band management port of each of the servers to be deployed is connected to the switch via an out-of-band network, and the switch is not connected to the business network. Therefore, each server to be deployed is connected to the switch via an out-of-band management port, and the switch is not connected to the service network. The deployment activity takes place in an isolated network, avoiding direct interaction with the public network, thereby reducing the possibility of attacks during deployment by forging DHCP servers. The aforementioned deployment device is connected to the aforementioned switch and is configured to perform the following steps: collecting out-of-band deployment server information from each server to be deployed through each out-of-band management port, wherein each out-of-band deployment server information includes verification information and server information to be deployed. Then, based on each out-of-band deployment server information, the aforementioned servers to be deployed are verified, and at least one server information corresponding to at least one verified server is stored in a preset deployment list. Thus, by collecting and verifying the out-of-band deployment server information of the servers to be deployed, it can be ensured that only information corresponding to authenticated servers to be deployed can be added to the deployment list, further preventing interference from unauthorized devices. Next, according to preset unattended installation requirement information and the aforementioned preset deployment list, an operating system smart installation image corresponding to each of the at least one servers to be deployed is created, wherein the operating system smart installation image includes an operating system installation configuration file. Next, multiple concurrent installation threads are executed, mounting at least one created operating system smart installation image to at least one out-of-band management port of at least one server to be deployed. This allows the operating system smart installation image, including the operating system installation configuration file, to be transmitted via the out-of-band management port over an isolated out-of-band network, reducing the possibility of sensitive information leakage.Subsequently, for each of the at least one servers to be deployed, the server is controlled to boot from its corresponding smart installation image of the operating system. This allows the server to perform unattended installation and configuration based on the operating system installation configuration file within the smart installation image, and then shut down after installation and configuration. This unattended installation and configuration reduces manual intervention during the installation process. Furthermore, by controlling the server to boot from its corresponding smart installation image, the boot process is ensured to originate from a trusted source, preventing the loading of malware or misconfigurations and improving the security of the servers to be deployed in the production environment during installation and configuration.

[0086] Figure 2 The flowchart 200 illustrates some embodiments of an out-of-band batch deployment method for servers in a production environment, according to the present disclosure, which applies the deployment machine device included in the above-described out-of-band batch deployment operating system for servers in a production environment. This out-of-band batch deployment method for servers in a production environment includes the following steps:

[0087] Step 201: Collect information about each out-of-band deployment server of each server to be deployed through each out-of-band management port.

[0088] In some embodiments, the execution entity (e.g., a deployment machine) for out-of-band batch deployment of servers in a production environment can collect out-of-band deployment server information for each server to be deployed through each out-of-band management port, wherein each out-of-band deployment server information includes verification information and server information to be deployed.

[0089] Step 202: Based on the preset unattended installation requirement information and the preset list of servers to be deployed, create an operating system smart installation image corresponding to each of the at least one servers to be deployed.

[0090] In some embodiments, the aforementioned execution entity may create an operating system smart installation image corresponding to each of the at least one server to be deployed, based on preset unattended installation requirement information and the aforementioned preset list to be deployed. The aforementioned operating system smart installation image includes an operating system installation configuration file.

[0091] Step 203: Execute multiple concurrent installation threads to mount at least one smart installation image of an operating system to at least one server to be deployed through at least one out-of-band management port of at least one server to be deployed.

[0092] In some embodiments, the execution entity may execute multiple concurrent installation threads to mount at least one created operating system smart installation image to at least one server to be deployed via at least one out-of-band management port of at least one server to be deployed.

[0093] Step 204: Execute multiple concurrent installation threads to mount at least one smart installation image of an operating system to at least one server to be deployed through at least one out-of-band management port of at least one server to be deployed.

[0094] In some embodiments, the execution entity may execute multiple concurrent installation threads to mount at least one created operating system smart installation image to at least one server to be deployed via at least one out-of-band management port of at least one server to be deployed.

[0095] Step 205: For each of the at least one servers to be deployed, control the server to be deployed to start from its corresponding smart installation image of the operating system, so that the server to be deployed can perform unattended installation and configuration according to the operating system installation configuration file in the smart installation image of the operating system, and shut down after installation and configuration.

[0096] In some embodiments, the execution entity may control each of the at least one servers to be deployed to start from the corresponding smart installation image of the operating system, so that the servers to be deployed can perform unattended installation and configuration according to the operating system installation configuration file in the smart installation image of the operating system, and shut down after installation and configuration.

[0097] The above embodiments of this disclosure have the following beneficial effects: The out-of-band batch deployment system for servers in a production environment, as described in some embodiments of this disclosure, improves the security of the servers to be deployed during the deployment process. Specifically, the reason for the low security of the servers to be deployed during the operating system deployment process is that attackers can set up a fake DHCP server on the network, provide incorrect network configurations to the servers to be deployed, or maliciously start the servers to be deployed, thereby achieving an attack. Furthermore, during the PXE boot process, much data is transmitted via unencrypted broadcast (e.g., boot files and network configuration information), which allows anyone on the network to eavesdrop on this data and obtain sensitive information, resulting in low security for the servers to be deployed in the production environment during the operating system deployment process. Based on this, the out-of-band batch deployment system for servers in a production environment, as described in some embodiments of this disclosure, includes: a deployment device, various servers to be deployed, and a switch, wherein: the out-of-band management port of each of the servers to be deployed is connected to the switch via an out-of-band network, and the switch is not connected to the business network. Therefore, each server to be deployed is connected to the switch via an out-of-band management port, and the switch is not connected to the service network. The deployment activity takes place in an isolated network, avoiding direct interaction with the public network, thereby reducing the possibility of attacks during deployment by forging DHCP servers. The aforementioned deployment device is connected to the aforementioned switch and is configured to perform the following steps: collecting out-of-band deployment server information from each server to be deployed through each out-of-band management port, wherein each out-of-band deployment server information includes verification information and server information to be deployed. Then, based on each out-of-band deployment server information, the aforementioned servers to be deployed are verified, and at least one server information corresponding to at least one verified server is stored in a preset deployment list. Thus, by collecting and verifying the out-of-band deployment server information of the servers to be deployed, it can be ensured that only information corresponding to authenticated servers to be deployed can be added to the deployment list, further preventing interference from unauthorized devices. Next, according to preset unattended installation requirement information and the aforementioned preset deployment list, an operating system smart installation image corresponding to each of the at least one servers to be deployed is created, wherein the operating system smart installation image includes an operating system installation configuration file. Next, multiple concurrent installation threads are executed, mounting at least one created operating system smart installation image to at least one out-of-band management port of at least one server to be deployed. This allows the operating system smart installation image, including the operating system installation configuration file, to be transmitted via the out-of-band management port over an isolated out-of-band network, reducing the possibility of sensitive information leakage.Subsequently, for each of the at least one servers to be deployed, the server is controlled to boot from its corresponding smart installation image of the operating system. This allows the server to perform unattended installation and configuration based on the operating system installation configuration file within the smart installation image, and then shut down after installation and configuration. This unattended installation and configuration reduces manual intervention during the installation process. Furthermore, by controlling the server to boot from its corresponding smart installation image, the boot process is ensured to originate from a trusted source, preventing the loading of malware or misconfigurations and improving the security of the servers to be deployed in the production environment during installation and configuration.

[0098] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of technical features, but should also cover other technical solutions formed by arbitrary combinations of technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. An out-of-band batch deployment system for servers suitable for production environments, comprising: Deployment equipment, each server to be deployed, and switches, including: The out-of-band management port of each of the servers to be deployed is connected to the switch via an out-of-band network, wherein the switch is not connected to the service network; The deployment device is connected to the switch, and the deployment device is configured to perform the following steps: Information about each out-of-band deployment server is collected through each out-of-band management port. The information about each out-of-band deployment server includes verification information and information about the server to be deployed. Based on the information of each out-of-band deployed server, each server to be deployed is verified, and the information of at least one server to be deployed corresponding to at least one verified server is stored in a preset list to be deployed. Based on the preset unattended installation requirement information and the preset list to be deployed, create an operating system smart installation image corresponding to each of the at least one servers to be deployed, wherein the operating system smart installation image includes an operating system installation configuration file; Execute multiple concurrent installation threads to mount at least one smart installation image of an operating system to at least one server to be deployed through at least one out-of-band management port of at least one server to be deployed; For each of the at least one servers to be deployed, the server to be deployed is controlled to start from the corresponding smart installation image of the operating system, so that the server to be deployed can perform unattended installation and configuration according to the operating system installation configuration file in the smart installation image of the operating system, and shut down after installation and configuration; The deployment device is further configured to: The number of servers to be deployed, which includes at least one server to be deployed, is defined as the target number. In response to a target number being less than or equal to a preset threshold, at least one smart installation image of an operating system is mounted in parallel to the at least one server to be deployed via at least one out-of-band management port of at least one server to be deployed. In response to the determination that the target number is greater than the preset threshold, the following dynamic concurrent installation process is performed: Collect its own resource data, which includes central processing unit resource information, memory resource information, disk resource information and network resource information; Collect network resource information of the switch; Based on the central processing unit resource information, determine the initial number of mounts; Based on the central processing unit resource information, memory resource information, disk resource information, network resource information, and the switch network resource information, resource occupancy score information is generated; Based on the resource usage score information and the initial mounting quantity, at least one smart installation image of an operating system is created and mounted in batches and in parallel to the at least one server to be deployed.

2. The out-of-band batch deployment system for servers in a production environment according to claim 1, wherein, The deployment device is further configured to: For each of at least one of the servers to be deployed, perform the following installation status verification process: The power on / off status information of the server to be deployed is obtained through the out-of-band management port of the server to be deployed; In response to determining the power-on / off status information, including the first power-off time, the power-on / off status is polled once every preset time interval during a first preset time period after the first power-off time to obtain polled power-on / off status information, thereby generating a polled power-on / off status information sequence. In response to the determination that all polling power-on / off status information in the obtained polling power-on / off status information sequence represents a power-off state, the system controls the server to be deployed to restart and uninstall the operating system smart installation image.

3. The out-of-band batch deployment system for servers in a production environment according to claim 2, wherein, The deployment device is further configured to: Since the polled power-on / off status information in the obtained polled power-on / off status information sequence all represent the power-on status, the power-on / off status information is obtained again after a second preset time as a verification power-on / off status information. In response to determining and verifying the power-on / off status information to represent the power-on status, information indicating that the server to be deployed has failed to install is recorded in a preset installation fault log, and a warning message indicating that the server to be deployed has failed to install is sent to a preset terminal.

4. The out-of-band batch deployment system for servers in a production environment according to claim 1, wherein, The verification information includes hardware specification information and status information, and the deployment device is further configured to perform the following steps: For each of the servers to be deployed, perform the following steps: The out-of-band deployment server information corresponding to the server to be deployed in each out-of-band deployment server information is determined as the target out-of-band deployment server information; In response to determining that the status information included in the target out-of-band deployment server information meets preset conditions, the hardware specification information included in the target out-of-band deployment server information is verified to obtain verification information; In response to the determination that the verification information indicates that the verification has passed, the information of the server to be deployed corresponding to the server to be deployed is stored in a preset list to be deployed.

5. The out-of-band batch deployment system for servers in a production environment according to claim 1, wherein, The preset unattended installation requirement information includes various unattended installation requirement sub-information, each of the at least one server to be deployed corresponds to one of the unattended installation requirement sub-information, and the deployment device is further configured as follows: For each of at least one of the servers to be deployed, perform the following creation steps: The unattended installation requirement sub-information that corresponds to the server to be deployed in each of the unattended installation requirement sub-information is determined as the matching unattended installation requirement sub-information; The required sub-information for unattended installation is parsed and verified to obtain the required metadata. Based on the required metadata, the server to be deployed is customized for installation and configuration, resulting in an unattended installation configuration file, which serves as the operating system installation configuration file. Based on the aforementioned requirement metadata, generate the post-installation script and post-installation configuration file; The operating system installation configuration file, the post-installation script, and the post-installation configuration file are integrated into a preset native image to obtain the native image to be packaged. The native image to be packaged is then packaged, and the packaged native image is determined as the smart installation image of the operating system corresponding to the server to be deployed.

6. The out-of-band batch deployment system for servers in a production environment according to claim 5, wherein, The deployment device is further configured to: The server to be deployed is controlled to boot from its corresponding operating system smart installation image, so that the server to be deployed can perform the following steps: Read the operating system installation configuration file to execute the installation task, wherein the installation task is the task of partitioning and formatting the disk, and installing the operating system and software packages; Execute the post-installation script to perform system initialization configuration.

7. An out-of-band batch deployment method for servers in a production environment, applied to the deployment machine equipment included in the out-of-band batch deployment system for servers in a production environment as described in any one of claims 1-6, the method comprising: Information about each out-of-band deployment server is collected through each out-of-band management port. The information about each out-of-band deployment server includes verification information and information about the server to be deployed. Based on the information of each out-of-band deployed server, each server to be deployed is verified, and the information of at least one server to be deployed corresponding to at least one verified server is stored in a preset list to be deployed. Based on the preset unattended installation requirement information and the preset list to be deployed, create an operating system smart installation image corresponding to each of the at least one servers to be deployed, wherein the operating system smart installation image includes an operating system installation configuration file; Execute multiple concurrent installation threads to mount at least one smart installation image of an operating system to at least one server to be deployed through at least one out-of-band management port of at least one server to be deployed; For each of the at least one servers to be deployed, the server to be deployed is controlled to start from the corresponding smart installation image of the operating system, so that the server to be deployed can perform unattended installation and configuration according to the operating system installation configuration file in the smart installation image of the operating system, and then shut down after installation and configuration.

Images