AI-based system batch installation method, system, equipment and readable medium

Abstract

The invention relates to the technical field of computer system deployment, in particular to an AI-based system batch installation method, system and equipment and a readable medium. According to the AI-based system batch installation method, deep matching between hardware and a configuration package is achieved by collecting hardware information, a to-be-installed server and a target configuration package corresponding to the to-be-installed server are dynamically matched through a configuration server, one-machine-one-configuration is achieved, and individuation of large-batch scripts is achieved through a variable replacement mechanism of a layered template engine. By using a distributed task scheduling engine of a master-slave architecture Master-Agent and analysis and decision of an AI model, script installation tasks are intelligently distributed to each server in a cluster, and the efficiency of deployment of an operating system in the server cluster is improved. Therefore, the technical problems that when an existing deployment method is used for carrying out system deployment of the server cluster, the efficiency is low, and the adaptation degree of equipment and installation scripts is low are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer system deployment, and particularly relates to an AI-based system batch installation method, a server deployment system, electronic equipment and a computer readable medium. BACKGROUND

[0002] Traditional enterprise computer system installation mostly needs human intervention, which has the following pain points: 1. The traditional scheme relies on fixed device types or models, and cannot distinguish between devices of the same model but with different hardware configurations. Most installation methods only support general hardware (such as standard x86 motherboards and integrated graphics cards), and lack deep adaptation to complex hardware specific to servers (such as RAID cards, HBA cards, GPU acceleration cards, and TPM 2.0 security chips), making it difficult to install or resulting in missing hardware functions or abnormal performance after installation. 2. The traditional scheme requires pre-storing independent images for each hardware (occupying a large amount of storage), and traditional scripts need to be written separately for each hardware. Most script installation schemes are designed only for a single device, lacking support for batch deployment of "hundred / thousand server clusters". After a traditional installation fails, it needs to be reinstalled manually, which is time-consuming and labor-intensive. Enterprise users need to operate or copy scripts manually, which is inefficient and prone to errors. 3. Predefined hardware lacks flexibility: based on predefined machine functions, source files with parameters required for installation are generated, and those parameters are stored in a centralized configuration database. Response files required for installation are generated in turn. It allows tracking installation, process, and reporting its success or failure to the central database. However, the hardware of the end user is predefined, lacking flexibility, and is not suitable for operating system installation jobs for computer clusters composed of a large number of enterprise server devices with different hardware structures. 4. Automated deployment lacks network division configuration, affecting network and related server access speed, and has high human dependency. In current information technology automated operating system deployment, the automation platform directly issues the operating system image file to the relevant server, writes the initialization configuration into the configuration file, installs according to the process of reading the configuration file, and controls the server start and stop through the IPMI protocol to complete the operating system deployment work. However, without precise control of the mac address and proper network vlan division, it may cause network load to be too large, affecting network speed and access speed of servers in the same network. The deployed server is set to PXE startup, and there is a risk of mistakenly reinstalling the operating system during reboot, which cannot be adjusted in time with the change of business, and the maintenance workload is large. 5. The degree of file integrity verification and installation testing is low. The current common method is to install the operating system to be tested on the device to be tested, which mainly uses the pre-boot execution environment to perform network boot, and then installs the operating system to be tested on the device to be tested. After the operating system to be tested is installed, the boot data stored in the hard disk boot area is cleared to skip the hard disk boot program and perform network boot at the next boot, and then install the next operating system to be tested on the device to be tested using network automation. However, this method is only limited to installing multiple Linux-based operating systems in succession, and cannot automatically and continuously install and test Microsoft operating systems. It cannot be applied to multiple operating systems to be tested. SUMMARY

[0003] In order to solve the technical problems of low efficiency and low adaptation of equipment and installation scripts in the existing deployment method when deploying a server cluster system, the application provides an AI-based system batch installation method, system, device and readable medium.

[0004] The first aspect of the application provides an AI-based system batch installation method, which adopts a closed-loop installation mechanism of "device perception-dynamic configuration loading-installation environment construction-intelligent decision-making-learning optimization" to deploy a server cluster system: Device perception: reading the hardware information of a plurality of servers to be installed to generate a plurality of device fingerprints; Dynamic configuration loading: the AI model marks the target configuration package with the highest installation success rate according to the device fingerprint and stores it in the configuration server; when a plurality of servers to be installed execute the script installation, the configuration server dynamically issues a plurality of target configuration packages corresponding to the plurality of servers to be installed; Installation environment construction: initializing the disk according to the target configuration package parameters and loading the driver, and injecting the parameters of a plurality of target configuration packages into the general template to generate scripts; Intelligent decision-making: introducing a distributed task scheduling engine with master-slave architecture Master-Agent, deploying the AI model in the Master node, and generating installation tasks based on the mapping relationship knowledge base; the Master node issues a plurality of script installation tasks to a plurality of Agent nodes to be installed to obtain target servers; Learning optimization: the device fingerprint is used to train the AI model and update the mapping relationship knowledge base of "device fingerprint-configuration package version-installation result".

[0005] Further, the device fingerprint generation method comprises: generating a device fingerprint by splicing the hardware information including the motherboard serial number, CPU serial number, hard disk serial number, physical network port MAC address and RAID card model through the SHA-256 hash algorithm; And / or, read the hardware information of a plurality of servers to be installed through a PXE boot terminal device to generate a plurality of device fingerprints; And / or, a plurality of target configuration package parameters are injected into the general template through the "variable substitution mechanism" of the hierarchical template engine to automatically generate a plurality of scripts corresponding to a plurality of servers to be installed; And / or, observe the state of the server cluster to be installed to determine whether to perform task migration between Agent nodes; And / or, distribute installation tasks according to Agent node load; when a certain Agent node fails, the Master node migrates the installation task to an idle Agent node for continuous execution; and the basic installation of the operating system is completed through a plurality of scripts to obtain a target server; And / or, in intelligent decision-making, continuously train the AI model with "the shortest overall deployment time" as the reward function; the final installation result and the corresponding device fingerprint are used for continuous training of the AI model.

[0006] Further, the XGBoost model is introduced, and the hardware health indicators are associated with the installation results based on the mapping relationship knowledge base; "hardware health state detection" is performed before intelligent decision-making, and the decision prediction of the XGBoost model is used to determine whether the installation failure rate exceeds the threshold value, if it exceeds, an alarm is given and the corresponding node is marked as "to be repaired".

[0007] Further, the installation mechanism adds the steps of post-installation verification, abnormal handling rollback to form a closed-loop installation mechanism of "device perception-dynamic configuration loading-installation environment construction-intelligent decision-making-learning optimization-post-installation verification-exception handling rollback": after the target server is generated by executing the script installation, the target server is verified by the verification rule base to output a verification report and an installation result; if the installation result fails, the steps of abnormal handling rollback are enabled.

[0008] Further, the abnormal handling rollback includes: When the exception is hardware missing, the processing is to record error logs, terminate the installation, and roll back the operating system to the initial state; When the exception is driver installation failure, the processing is to try to download the driver package again, if it still fails, skip the driver and continue to the next step; When the exception is network timeout, the processing is to switch to the backup network source, if it still fails after three retries, terminate and alarm; When the exception is partition table conflict, the processing is to forcibly uninstall the partition, if it fails, restart the device and re-execute the installation.

[0009] Further, the generation method of the target configuration package includes: matching the corresponding configuration package containing the partition scheme, the driver list, and the software component mapping relationship from the cloud database according to the device fingerprint.

[0010] Further, the cloud database supports dynamic updating.

[0011] The second aspect of the present application provides a server deployment system, which adopts the AI-based system batch installation method described above, comprising: a terminal device, a configuration server, an AI model, and an engine module. The terminal device is used to read hardware information of a plurality of servers to be installed. PXE is used to start the terminal device to read the hardware information of the plurality of servers to be installed to generate a plurality of device fingerprints. The configuration server is used to store a plurality of target configuration packages, and is further used to dynamically send the plurality of target configuration packages to the plurality of servers to be installed. The AI model is used to mark the corresponding target configuration package according to the device fingerprint, and to generate an installation task or to judge whether to perform task migration between Agent nodes based on the state of the server cluster to be installed and the mapping relationship knowledge base. The engine module is used to carry the layered template engine and the distributed task scheduling engine as described above.

[0012] The third aspect of the present application provides an electronic device, comprising: at least one processing module; at least one storage module for storing at least one program; When the at least one program is executed by the at least one processing module, the at least one processing module implements the AI-based system batch installation method described above.

[0013] The fourth aspect of the present application provides a computer readable medium having a computer program stored thereon, wherein the computer program is executed to implement the AI-based system batch installation method described above.

[0014] Compared with the prior art, the present application has the following beneficial effects: 1. The present application realizes the deep matching between hardware and configuration package by collecting the hardware information of the server to be installed instead of the server identification, avoids the matching error caused by multiple server identifications being the same, and after collecting the device fingerprint, introduces an AI model, establishes a mapping relationship knowledge base based on the learning ability of the AI model, through the mapping relationship knowledge base, the AI model can determine the target configuration package corresponding to the device fingerprint with the highest success rate to make a decision on the selection of the configuration package, stores the target configuration package through the configuration server, and when the server to be installed needs to be installed, dynamically matches the server to be installed and its corresponding target configuration package through the configuration server to achieve "one machine one configuration", effectively improving the adaptation of the device and the installation script. When generating the script of the target configuration package, the "variable replacement mechanism" of the hierarchical template engine is used to realize the individualization of a large number of scripts, avoiding the customization of each script, avoiding script errors in the customization process, thereby improving the overall accuracy and generation efficiency. When installing the operating system of the server cluster, a distributed task scheduling engine with master-slave architecture Master-Agent is used, based on the detection of the state of each server by the AI model, intelligently allocates the script installation task to each server in the cluster, timely handles the failed nodes, and allocates the installation task to the idle Agent node for continuous execution, thereby improving the resource allocation efficiency and the efficiency of the operating system deployment of the server cluster. Thus, the technical problems of low efficiency and low adaptation of the device and the installation script in the existing deployment method when deploying the system of the server cluster are solved.

[0015] 2. The traditional scheme needs to pre-store independent images for each hardware (occupying a large amount of storage), and the present method replaces "image pre-storage" with "configuration package dynamic distribution", reducing storage costs.

[0016] 3. The traditional scheme relies on fixed device types or models, and cannot distinguish devices with different hardware configurations but the same model (such as servers with different RAID cards), and the present method realizes precise adaptation through "hardware feature level" recognition (device fingerprint).

[0017] 4. The traditional scheme needs to manually configure RAID or LVM, which is prone to installation failure due to parameter errors, and the present method realizes "zero manual intervention" disk initialization through an automated tool chain.

[0018] 5. The traditional script needs to be written separately for each hardware, with high maintenance cost, and the present method realizes "write once, adapt multiple places" through templates, improving script maintenance efficiency, and can automatically generate target configuration packages and their corresponding scripts, also known as customized scripts.

[0019] 6. The traditional installation needs to be reinstalled manually after failure, which is time-consuming and labor-intensive, and the present method improves the installation success rate through a "verification-rollback" closed loop. 7. By introducing an artificial intelligence layer, a "perception-decision-learning" closed loop is constructed, and the automated process is upgraded to an intelligent closed loop system, and an AI model is used to empower it. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 A flowchart of the operating system batch installation method of the embodiment of the present application; Figure 2 An interaction logic diagram of the operating system batch installation method of the present application. DETAILED DESCRIPTION

[0021] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0022] The embodiments of the present application provide an AI-based system batch installation method, a server deployment system, an electronic device and a computer readable medium. The core technical problem of the present application is to solve the problem that the automatic deployment of the existing enterprise operating system cannot adapt to multiple models of enterprise server devices and is highly dependent on manual work; the present application can be widely applied to enterprise-level IT infrastructure deployment, cloud computing resource initialization, edge computing node construction, intelligent terminal batch operation and maintenance and the like. The present application is aimed at the deployment requirements of enterprise-level servers, and the installation method of the present application is significantly different from that of general devices (such as personal PCs and edge terminals) in technical design. The core innovation points are reflected in two aspects of hardware deep adaptation and large-scale deployment support. Through the whole process automation of "device feature recognition (device perception) - dynamic configuration loading - installation environment construction - script execution - verification feedback (post-installation verification, abnormal processing rollback) - learning optimization", the problems of high dependence on manual work, difficulty in hardware adaptation and weak fault tolerance in traditional enterprise operating system installation are solved. The technical solution can be directly applied to enterprise-level batch device deployment (such as data center servers and intelligent terminals), cloud computing infrastructure initialization and the like, significantly reducing the IT operation and maintenance cost and improving the deployment efficiency.

[0023] As shown in Figure 1 The present application provides an AI-based system batch installation method, which adopts a closed-loop installation mechanism of "device feature recognition (device perception) - dynamic configuration loading - installation environment construction - script installation - post-installation verification - abnormal processing rollback - learning optimization" for system deployment of server clusters: First, manually initiate a batch installation task.

[0024] Into the script one, device feature recognition (device perception): through the PXE terminal equipment to read a number of hardware information of the server to be installed to generate a number of device fingerprints (i.e. unique identification), and input a number of device fingerprints into the AI model for learning; in this mechanism, the hardware feature collection dimension is more comprehensive: in addition to the basic information such as motherboard / CPU / MAC, additional collection of server-specific hardware identification (such as LSI RAID card firmware version, NVIDIA GPU PCIe topology, TPM chip serial number), collection of physical hardware identification (motherboard serial number, CPU serial number, hard disk serial number) and other hardware identification (physical network port mac address, RAID card model); the unique identification is generated by splicing the hardware information through SHA-256 hash algorithm. The focus of this hardware information collection is not the identification code of the server itself, but the information of the internal hardware of the server, so that all the hardware installed in the server can be accurately identified. Thus, in the case of two servers with the same identification code but different internal hardware, the same target configuration package is sent, so as to achieve accurate pairing between the server to be installed and the target configuration package. In addition, in this stage, the state of the hardware will also be analyzed, including the identification of the hardware health status of the RAID card battery state, GPU temperature threshold, memory ECC error count, to ensure the availability of the hardware.

[0025] Enter script two, dynamic configuration loading: the AI model marks the target configuration package with the highest installation success rate according to the device fingerprint and stores it in the configuration server for dynamic distribution by the configuration server to the corresponding target configuration package of the several to-be-installed servers when executing the script installation; in this mechanism, the drive injection strategy is more precise: based on the "multi-firmware version compatibility" requirement of enterprise-level hardware, dynamic drive version matching is supported (such as selecting the corresponding drive according to the RAID card firmware version), avoiding startup failure due to incompatibility between the drive and the firmware. The main purpose is to match the device fingerprint with the matching database (cloud database) to form a configuration scheme. The matching database (cloud database supports dynamic updating) in the matching server includes multiple sets of device fingerprints, partition schemes, drive lists, and mapping relationships of software components. The matching server integrates and packages the device fingerprint and its corresponding configuration parameters according to the matching database to form a target configuration package, and stores the target configuration package. When the to-be-installed server requests, the corresponding target configuration package is dynamically selected and sent according to the device fingerprint of the to-be-installed server, thereby realizing "one machine one configuration" and providing matching accuracy. And through the AI model, it is empowered to further upgrade from automation to intelligence, thereby avoiding the traditional technical pain points: "the drive matching rule, hardware health threshold, installation process, etc. are all pre-defined statically by engineers. In the face of new hardware models or unforeseen hardware failure modes, the system cannot adjust the strategy independently and still needs manual intervention to update the rule library. The data behind each installation process is not systematically collected, analyzed, and transformed into knowledge, and cannot be used to optimize subsequent deployment tasks. For large-scale clusters, parameters such as installation task scheduling order and network bandwidth allocation usually use fixed strategies, which cannot be dynamically and intelligently adjusted according to the real-time cluster state to achieve global efficiency optimization." And the present application adopts intelligent hardware adaptation and drive decision engine: a deep knowledge base (mapping relationship knowledge base) of hardware features-drive version-installation results is constructed. Using an AI model, the collected hardware features (PCIe device ID, firmware version, subsystem ID, etc.) are embedded and analyzed. The model learns the mapping relationship between hardware configuration, drive version, and installation success probability through data training. When a new server is encountered, the system inputs its hardware features into the model. The model can intelligently select the drive with the highest success rate and give a confidence level. For options with low confidence, manual review or safe mode installation can be triggered. This greatly improves the first-time installation success rate, especially for new models or heterogeneous hardware combinations.

[0026] In addition, the traditional scheme needs to pre-store independent images for each hardware (occupying a large amount of storage), and the present method replaces "image pre-storage" with "configuration package dynamic distribution" to reduce storage costs.

[0027] In the third script, the installation environment is built: the parameters of several target configuration packages are injected into the general template through the "variable replacement mechanism" of the hierarchical template engine to automatically generate several customized scripts corresponding to several servers to be installed; in this mechanism, based on the pre-start environment tool chain (partition tool, raid tool, dynamic kernel module), the disk is initialized according to the parameters of the target configuration package (RAID / LVM disk array is automatically created, the integrity of the configuration file is verified through the verification algorithm (such as SHA-256), and the driver is loaded; in the traditional scheme, RAID or LVM needs to be manually configured, which is easy to cause installation failure due to parameter error, and the present method realizes "zero manual intervention" of disk initialization through the automatic tool chain. The generated initialized disk environment (partition result, raid / lvm array, driver loading state), installation script (convert the configuration package parameters into executable instructions through the hierarchical template engine). The most important part in this step is batch rendering of the configuration template: support for the hierarchical template engine based on Jinja2, generate differentiated configuration packages for different role servers (such as compute nodes, storage nodes, management nodes) in the cluster (such as compute nodes focusing on GPU drivers, storage nodes focusing on RAID array configuration), avoid resource waste caused by "one-size-fits-all" configuration. Use "variable replacement mechanism" to avoid writing scripts for each hardware separately, which reduces the errors that may occur when writing scripts separately, improves the adaptability of the device and the installation script, and thus improves the overall precision and deployment efficiency.

[0028] In the fourth script, intelligent decision making (including scripted installation; AI model intelligently selects installation strategy and schedules cluster nodes based on training results): generate installation scripts containing device-specific parameters (such as GRUB customization, hardware driver loading order), and execute through pre-boot environment (PXE). A distributed task scheduling engine with master-slave architecture Master-Agent is introduced, and the AI model is deployed in the Master node. The AI model observes the state of the server cluster to be installed and generates installation tasks or determines whether to migrate tasks between Agent nodes based on the mapping relationship knowledge base; the Master node distributes a number of customized script installation tasks to a number of Agent nodes to be installed on the server for execution, and allocates installation tasks according to Agent node load; when a certain Agent node fails, the Master node migrates the installation task to an idle Agent node for continuous execution; and the basic installation of the operating system is completed through the execution of a number of customized scripts to obtain the target server. In this mechanism, the server to be installed is installed with the operating system based on the customized scripts obtained in script three and the operating system installation source (HTTP image, NFS sharing), and the preliminary installed operating system and the target server carrying the system are obtained. In this step, the most critical is the collective installation of the operating system of the server cluster, which is different from the traditional single-server automatic installation method. The application adopts a distributed task scheduling engine with master-slave architecture Master-Agent, and the Master node distributes installation scripts (individual scripts) to Agent nodes (servers to be installed), supports dynamic load balancing (allocates installation tasks according to node load) and breakpoint resume (when a node fails, the Master automatically migrates the task to an idle node for continuous execution). The batch deployment time is shortened from the traditional "30 minutes for a single server to 10 hours for 200 servers" to "1.5 hours for 200 servers". This greatly improves the installation efficiency. In addition, an intelligent scheduling and fault-tolerant engine based on reinforcement learning is used: the deployment process of a large-scale cluster is modeled as a sequential decision-making problem. The deployment master node acts as an intelligent agent, observing the cluster state (node load, network bandwidth, installation task queue, historical failure rate), and deciding which node to assign tasks to or whether to migrate tasks. Using a reinforcement learning algorithm, the reward function is set to "shortest overall deployment time", and the intelligent agent (AI model) learns the optimal scheduling strategy through continuous attempts to make dynamic decisions and achieve global optimization of cluster-level deployment efficiency.

[0029] Thus, the technical problems of traditional technologies are solved: most script installation solutions are designed for a single device only, lack of support for batch deployment of "hundred / thousand server clusters", and enterprise users need to manually operate or simply copy scripts, which is inefficient and prone to errors. Traditional scripts need to be written separately for each hardware, and the maintenance cost is high. The present method realizes "one writing, multiple adaptation" through a template engine, improving script maintenance efficiency.

[0030] Before installation, a health detection mechanism is also added: intelligent prediction and active protection of installation success rate. In the "hardware health state detection" stage before installation begins, a machine learning classification model (such as random forest, XGBoost) is introduced. Based on historical data, the model learns which hardware health indicators (such as: memory ECC error count abnormally high, RAID card battery aging, hard disk SMART parameter warning) have a strong correlation with the final installation failure. At the beginning of installation, the system analyzes the hardware health data (to-be-installed server) in real time, and the model predicts the failure rate of this installation. If it exceeds the threshold, the system triggers an alarm, notifies the operation and maintenance personnel to replace the faulty components, or marks this node as "to be repaired", thereby avoiding unnecessary installation attempts and resource waste, changing passive rollback to active prevention, and further improving overall success rate and operation and maintenance efficiency.

[0031] In script five, post-installation verification: based on the verification rule library (file integrity check benchmark value, service state list, driver loading requirement), the preliminary installed operating system is verified, and the verification report (file integrity, service state, driver loading, network connectivity) and installation result (success or failure) are output. Through heartbeat detection and function test (such as network connectivity, driver loading state), the effectiveness of the installation is confirmed, and the rollback mechanism is triggered when it fails.

[0032] In script six, abnormal processing rollback: if the installation result shows failure, according to the backup image before installation and the verification report, the disk is restored to the initial state, and an abnormal log is generated (when a device installation process is interrupted, the system automatically records logs and rolls back to the initial state, supporting continuous installation from the breakpoint), thereby improving the fault tolerance of the installation mechanism; after traditional installation failure, manual reinstallation is required, which is time-consuming and labor-intensive. The present method improves the installation success rate through the "verification-rollback" closed loop.

[0033] Learning optimization: in device perception, a number of device fingerprints are used to train AI models to update the mapping relationship knowledge base of "device fingerprint-configuration package version-installation result"; in intelligent decision-making, the "shortest overall deployment time" is used as the reward function to continuously train the AI model; the final installation result and the corresponding device fingerprint are used to continuously train the AI model.

[0034] To sum up, the application adopts dynamic verification technology: adopting double verification (file integrity + installation result verification) to improve reliability. Rollback fault tolerance design: automatically restore to the initial state when installation fails, supporting breakpoint resume. Multi-dimensional adaptation mechanism: combining device hardware characteristics and cloud configuration library to realize "one machine one configuration". The application realizes deep matching between hardware and configuration package by collecting hardware information of the server to be installed instead of server identifier, avoiding matching errors caused by multiple server identifiers being the same, and after collecting the device fingerprint, the target configuration package is stored in the configuration server through the labeling of the AI model. When the server to be installed needs to be installed, the configuration server dynamically matches the server to be installed and its corresponding target configuration package, achieving "one machine one configuration" and effectively improving the adaptation of the device and the installation script. When generating the target configuration package script, the "variable replacement mechanism" of the hierarchical template engine is used to realize the individualization of a large number of scripts, avoiding customizing each script individually and avoiding script errors in the customization process, thereby improving overall accuracy and generation efficiency. When installing the operating system of the server cluster, the distributed task scheduling engine and AI model decision of the master-slave architecture Master-Agent are used to intelligently allocate script installation tasks to each server in the cluster, handle failed nodes in time, and allocate installation tasks to idle Agent nodes for continuous execution, thereby improving resource allocation efficiency and the efficiency of operating system deployment of the server cluster. Thus, the technical problems of low efficiency and low adaptation of devices and installation scripts in the existing deployment method when deploying the system of the server cluster are solved.

[0035] In comparison, the traditional deployment method has the following problems: 1. Static deployment strategy, lack of self-learning and evolution ability; the traditional scheme cannot learn experience from historical deployment data, cannot automatically optimize the driving matching accuracy, predict hardware failure risk, or adaptively adjust the installation process to cope with unknown scenarios, the system intelligence level is low, and the maintenance and upgrade cost is high.

[0036] 2. Lack of intelligent resource scheduling in large-scale deployment; the load balancing strategy of the traditional master-slave architecture is relatively fixed, and cannot dynamically and accurately predict and schedule based on real-time network topology, bandwidth occupation, node hardware performance and other multi-indexes, making it difficult to maximize the overall deployment efficiency of the cluster.

[0037] 3. Insufficient prediction and active protection capability of installation success rate; the traditional method only triggers rollback after installation failure, which is a passive response. Lack of ability to predict the success probability of this installation based on hardware feature data before installation starts, and actively inject preventive measures.

[0038] And the application effectively solves the above problems, thereby achieving outstanding progress.

[0039] As Figure 2 shown, Figure 2 is an interactive logic diagram of the operating system batch installation method of the present application, which shows the interaction logic of the client, the configuration server, the PXE server, and the AI model server (with an AI model). Among them, the configuration server sends a network request to the TFTP server and the AI model, the configuration server allocates an address (the TFTP server address starts the name of the file) to the to-be-deployed server (the to-be-installed server), the to-be-deployed server sends a request to the configuration server to download the corresponding startup file, the AI model marks the target configuration package, the configuration server sends the corresponding startup file, kernel and image file to the to-be-deployed server, and the to-be-deployed server generates a target server according to the script installation of the startup file, kernel and image file.

[0040] When implementing enterprise-level batch deployment, the hardware parameters and corresponding configuration packages of 1000 different models of devices are entered into the configuration server, and the AI intelligent decision engine (belongs to the AI model) is started.

[0041] 1. Boot the terminal device through PXE, and automatically perform device fingerprint collection.

[0042] 2. The collected fingerprint data is uploaded to the AI hardware adaptation engine (belongs to the AI model) on the server side. The engine returns not only the pre-matched configuration package, but also the best driver version list and installation parameter suggestion (for example: “Node-2034 is recommended megaraid_sas v07.12.xx.xx driver, confidence 99.5%”) through real-time model reasoning and query knowledge base.

[0043] 3. The installation script automatically completes partitioning, driver loading, and system component installation according to the AI decision result. The installation result (success / failure and log) is automatically recycled for updating and training the AI model, realizing model iteration optimization. The average time consumption is <15 minutes per device, and the first installation success rate is improved to 99.9%.

[0044] When an installation error occurs (intelligent fault tolerance and predictive maintenance scenario): 1. After the device starts, the AI health prediction model (such as random forest, XGBoost) first analyzes its hardware state (such as memory ECC error, hard disk reallocation sector number).

[0045] 2. The model predicts that the node hard disk has a high risk of failure (probability 85%), and the installation success probability is less than 40%. The system automatically suspends the standard installation process and sends a warning to the management platform: “Node B-47 hard disk suspected to be faulty, suggest replacing it before deployment”.

[0046] 3. After the operator replaces the hard disk, the system automatically retries the installation and successfully completes it. This process avoids a certain failed installation attempt, saves time and computing resources, and accumulates new prediction samples.

[0047] The principle of the installation script is as follows: 1. The underlying logic generated by the installation script: configuration package → instruction mapping.

[0048] The core function of the installation script is to convert the "installation requirements" in the configuration package into specific operation instructions that the operating system can recognize. Its generation process strictly follows the closed loop of "configuration package parameters → template engine rendering → instruction verification", ensuring that each instruction accurately corresponds to the device requirements.

[0049] 2. Configuration package structure and instruction mapping relationship: The configuration package (target configuration package) defines the basic parameters and extension rules required for installation, and the script needs to parse it into specific command line instructions or system calls when generating. The following is an example of the mapping between the key fields of the configuration package and the script instructions, as shown in Table 1: Table 1: Mapping between configuration package key fields and script instructions Configuration Package Fields Meaning Corresponding Script Instruction Example partition_scheme Disk partition scheme (partition device, size, type) parted / dev / sdamklabel gptparted / dev / sdamkpart primary ext4 0% 50GB drivers List of drivers to install (e.g.,.deb package names) apt-get install -y nvidia-driver-535 raid-card-ctrl-2023 software List of pre-installed software (e.g., application package names) dnf install -y nginx-1.24 docker-ce-24.06 kernel_params Kernel parameters (e.g., iommu=on) echo "kernel_params=iommu=on">> / mnt / etc / default / grub boot_loader Boot loader configuration (e.g., GRUB installation path) grub-install / dev / sda network_config Network configuration (e.g., IP, gateway, DNS) cat <eof> / mnt / etc / netplan / 00-installer-config.yaml... EOF < / eof> 3. Application of template engine: dynamically generate personalized scripts.

[0050] To avoid writing scripts for each hardware separately, this module uses a template engine to inject configuration package parameters into a general template through a "variable substitution" mechanism to generate customized scripts.

[0051] Example: Conversion of general template to personalized script.

[0052] General template (Jinja2 format): # Partition phase; parted {{ disk_device}} mklabel gpt; {% for partition in partitions %} parted {{ disk_device}} mkpart{{ partition.type}} {{partition.start}};{{ partition.end}}; {% endfor %} # Driver installation phase; apt-get update; apt-get install -y {% for driver in drivers %}{{ driver}} {% endfor%}; # Boot configuration; mount {{ boot_device}} / mnt / boot; grub-install --boot-directory= / mnt / boot / {{ disk_device}} / dev / sda; The script generated after injecting configuration package parameters (assuming disk_device= / dev / sda, partitions contain two partitions, and drivers are nvidia-driver-535): # Partitioning phase; parted / dev / sdamklabelgpt; parted / dev / sdamkpart primary ext4 0% 50GB; parted / dev / sdamkpart primary xfs 50GB 150GB; # Driver installation phase; apt-get update; apt-get install -y nvidia-driver-535; # Boot configuration; mount / dev / sdb1 / mnt / boot; grub-install --boot-directory= / mnt / boot / / dev / sda / dev / sda; 4. Script execution flow: from PXE boot to system initialization.

[0053] The script needs to be executed in a pre-boot environment (PXE / iPXE), which is independent of the target operating system and depends only on the device firmware (BIOS / UEFI) and network services (HTTP / NFS). The following is the complete script execution flow: Phase 1: PXE booting and script download.

[0054] When the device boots via PXE, the BIOS / UEFI reads the network boot program (such as pxelinux.0) and obtains the boot menu (menu.lst) from the configuration server. The boot menu calls the corresponding installation script (such as install_x86_64.sh) based on the device fingerprint. The script is downloaded to the device memory via TFTP or HTTP (to avoid local storage dependency).

[0055] Phase 2: Environment initialization and dependency checking.

[0056] Before executing the script, basic environment preparation must be completed to ensure that subsequent operations are feasible: Disk check: Use the lsblk command to confirm the existence of physical disks (such as / dev / sda, / dev / nvme0n1) to avoid failure due to missing hardware; Network connectivity: Test the configured server IP (e.g., 192.168.1.100) via ping. If the timeout occurs, retry 3 times and then terminate and trigger a rollback. Toolchain verification: Check if the required tools (such as parted, apt-get, grub-install) exist in the pre-boot environment (using the which command), and download them from the local cache or network if they are missing.

[0057] Phase 3: Execution of core installation instructions.

[0058] The script executes key instructions in the order of partition → driver → system → configuration, logging each step (e.g., / var / log / install.log) for traceability: Partitioning and RAID creation: Call parted / fdisk to partition, and mdadm to create a RAID array (example: mdadm --create / dev / md0 --level=10 --raid-devices=4 / dev / sd[be]). File system formatting: Execute mkfs.ext4 (ext4 file system) or mkfs.xfs (XFS file system) on the partition. Operating system installation: Pull the basic system package from the software source using debootstrap (Debian-based) or dnf (RHEL-based) and extract it to the target partition; Driver and software injection: Install the drivers (such as GPU firmware) and applications (such as Nginx) specified in the configuration package, and update the dynamic link library cache via ldconfig; Boot configuration: Install GRUB2 to the disk MBR or EFI partition, and configure grub.cfg to load the kernel and initialize the RAM disk (initrd).

[0059] Phase 4: Post-installation self-check and log upload.

[0060] After the script finishes executing, post-installation verification will be automatically triggered (linked with the verification module / verification feedback in the technical solution): Check / etc / os-release to confirm the operating system version; Verify that critical services (such as sshd and systemd) are running (systemctl is-active sshd); Collect installation logs (including the output and error codes of all commands) and upload them to the cloud server via scp or HTTP POST.

[0061] 5. Exception handling: Fault tolerance mechanism when script execution fails.

[0062] Script execution may fail due to hardware malfunctions, configuration errors, or network problems. This module mitigates the impact through a layered exception handling and precise recovery mechanism. The following is an example of the mapping between exception types and their corresponding handling logic, as shown in Table 2: Table 2. Examples of mapping between exception types and corresponding handling logic Exception Type Triggering Scenario Handling Logic Hardware Missing Detected that the disk / dev / sdb in the configuration package does not exist Record error log (ERROR: Disk / dev / sdb not found), terminate installation and rollback. Driver Installation Failure apt-get install returns a non-zero exit code Try to download the driver package again (from the backup source), if it still fails, skip this driver (marked as "optional") and continue. Network Timeout Ping the configuration server timeout when downloading system images Switch to the backup network source (e.g., from HTTP to NFS), if it still fails after 3 retries, terminate and alert. Partition Table Conflict Attempt to format the mounted partition / dev / sda1 Force unmount the partition (umount -f), if it fails, restart the device and re-execute the installation. In summary, this technical solution, through end-to-end automated design and multi-dimensional technological innovation, achieves significant technical improvements in installation efficiency, hardware compatibility, installation reliability, and maintenance costs for enterprise-level server equipment. Traditional operating system installation requires manual steps such as partitioning, driver installation, and system configuration, typically taking 30-60 minutes per device (including manual waiting time). This solution, through automated script execution and parallel task scheduling (using a distributed task scheduling engine), compresses the installation process to 10-15 minutes per device. Traditional solutions rely on "one-size-fits-all" images or fixed configuration templates, only adapting to standard hardware configurations of the same model of equipment (e.g., requiring 5-10 pre-stored images for different RAID card / hard drive combinations for the same server model). This solution, through hardware fingerprinting and a dynamic configuration library, achieves precise "one machine, one configuration" adaptation. Traditional installations typically have a success rate of only around 75% due to human error (such as partitioning errors or driver version conflicts) or hardware compatibility issues. This solution improves the installation success rate through dual verification and intelligent rollback mechanisms. Traditional batch deployments require dedicated maintenance personnel to debug each machine individually, resulting in high labor costs (3-5 people / day per deployment in an enterprise data center). This technical solution automates the entire process, reducing manpower to 1 person / day (only log monitoring is needed). Installation efficiency is improved by over 80% (compared to traditional manual installation). It supports automatic adaptation to 20+ hardware configuration combinations. The installation success rate is increased from 75% with manual operation to 99.6%.

[0063] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0064] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. An AI-based system batch installation method, characterized by, The system deployment of the server cluster is performed by using a closed-loop installation mechanism of "device awareness-dynamic configuration loading-installation environment construction-intelligent decision-making-learning optimization"; Device awareness: reading the hardware information of a plurality of to-be-installed servers to generate a plurality of device fingerprints; Dynamic configuration loading: an AI model marks a target configuration package with the highest installation success rate according to the device fingerprints and stores the target configuration package in a configuration server; when a plurality of to-be-installed servers execute a script installation, the configuration server dynamically issues a plurality of target configuration packages corresponding to the plurality of to-be-installed servers; Installation environment construction: initializing a disk and loading a driver according to the parameters of the target configuration package, and injecting the parameters of the plurality of target configuration packages into a general template to generate a script; Intelligent decision-making: introducing a distributed task scheduling engine of master-slave architecture Master-Agent, deploying the AI model in the Master node, and generating an installation task based on a mapping relationship knowledge base; Learning optimization: the device fingerprints are used to train the AI model and update the mapping relationship knowledge base of "device fingerprint-configuration package version-installation result"; 2.The AI-based system batch installation method of claim 1, wherein, The generation method of the device fingerprint includes: generating the device fingerprint by splicing the hardware information including the motherboard serial number, the CPU serial number, the hard disk serial number, the physical network port MAC address and the RAID card model through the SHA-256 hash algorithm; And / or, reading the hardware information of a plurality of to-be-installed servers through a PXE boot terminal device to generate a plurality of device fingerprints; And / or, automatically generating a plurality of scripts corresponding to a plurality of to-be-installed servers by injecting the parameters of a plurality of target configuration packages into a general template through the "variable substitution mechanism" of a hierarchical template engine; And / or, observing the state of the to-be-installed server cluster to determine whether to perform task migration between Agent nodes; And / or, distributing installation tasks according to the load of the Agent nodes; when a certain Agent node fails, the Master node migrates the installation task to an idle Agent node for continuous execution; and the basic installation of the operating system is completed by executing a plurality of scripts to obtain a target server; And / or, in intelligent decision-making, continuously training the AI model with "the shortest overall deployment time" as the reward function; and the final installation result and the corresponding device fingerprint are used to continuously train the AI model. 3.The AI-based system batch installation method of claim 1, wherein, An XGBoost model is introduced to associate hardware health indicators with installation results based on the mapping relationship knowledge base; before intelligent decision-making, "hardware health state detection" is performed and the decision prediction of the XGBoost model is used to determine whether the installation failure rate exceeds a threshold value; if it exceeds, an alarm is given and the corresponding node is marked as "to be repaired". 4.The AI-based system batch installation method of claim 1, wherein, The installation mechanism adds the steps of post-installation verification, abnormal handling rollback to form a closed-loop installation mechanism of "device awareness-dynamic configuration loading-installation environment construction-intelligent decision-making-learning optimization-post-installation verification- abnormal handling rollback": after executing the script installation to generate a target server, the target server is functionally verified by a verification rule library to output a verification report and an installation result; If the installation result fails, an exception handling rollback step is enabled. 5.The AI-based system batch installation method of claim 4, wherein, The exception handling rollback includes: When the exception is a hardware missing, the processing is to record an error log, terminate the installation, and rollback the operating system to the initial state; When the exception is a driver installation failure, the processing is to attempt to download the driver package again, and if it still fails, skip the driver and continue with the next step; When the exception is a network timeout, the processing is to switch to a backup network source, and if it still fails after three retries, terminate and issue an alarm; When the exception is a partition table conflict, the processing is to forcibly uninstall the partition, and if it fails, restart the device and re-execute the installation. 6.The AI-based system batch installation method of claim 1, wherein, The method for generating a target configuration package includes: matching a corresponding configuration package containing a partition scheme, a driver list, and a software component mapping relationship from a cloud database according to a device fingerprint. 7.The AI-based system batch installation method of claim 6, wherein, The cloud database supports dynamic updates. 8.A server deployment system employing the AI-based system bulk installation method according to any one of claims 1 to 7, characterized in that, It includes: A terminal device for reading hardware information of a plurality of servers to be installed; PXE for starting the terminal device to read the hardware information of the plurality of servers to be installed to generate a plurality of device fingerprints; A configuration server for storing a plurality of target configuration packages, and for dynamically sending the plurality of target configuration packages to the plurality of servers to be installed; An AI model for marking a corresponding target configuration package according to a device fingerprint, and for generating an installation task or determining whether to perform task migration between Agent nodes based on the state of a cluster of servers to be installed and a mapping relationship knowledge base; An engine module for carrying the layered template engine and the distributed task scheduling engine of any one of claims 1 to 7.

9. An electronic device, comprising: It includes: At least one processing module; At least one storage module for storing at least one program; When the at least one program is executed by the at least one processing module, the at least one processing module implements the AI-based system batch installation method of any one of claims 1 to 7.

10. A computer readable medium having stored thereon a computer program, characterized in that, The computer program is executed to implement the AI-based system batch installation method of any one of claims 1 to 7.

Images