PXE-based automated bulk deployment and integration kickstart configuration system and method

Abstract

The application relates to the field of artificial intelligence technology and discloses a PXE-based automatic batch deployment and integrated start-up configuration method, a PXE information acquisition module, which is used for extracting the MAC address and network configuration parameters of a client from PXE start request information; a deployment requirement monitoring module, which is used for determining the Linux kernel loading requirement and the drive installation requirement of a to-be-deployed client, determining the operating system installation parameters required by the to-be-deployed client, and monitoring the intranet server connection state of the to-be-deployed client; a disk partition planning module, which is used for formulating a disk partition scheme of the to-be-deployed client; a system image deployment module, which is used for analyzing the deployment progress state of the Linux kernel; and a post-configuration integration module, which is used for performing system integration operation on the to-be-deployed client according to post-configuration content to obtain a lightweight business-ready system of the to-be-deployed client. The application can improve the efficiency of PXE-based automatic batch deployment and integrated start-up configuration.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an automated batch deployment and integration initial configuration system and method based on PXE. Background Technology

[0002] In closed network environments such as data centers, corporate intranets, and secure laboratories, batch installation and initial configuration of operating systems are core foundational tasks. These environments are typically completely isolated from the Internet due to security requirements, making it impossible to rely on external image sources, driver libraries, and configuration services. Traditional deployment methods rely on manual operation of media such as CDs and USB drives, which is not only inefficient and difficult to adapt to the needs of large-scale node deployment, but also prone to poor consistency of the environment among nodes due to differences in human operation, posing potential risks to subsequent business operation and maintenance.

[0003] While existing PXE network boot technology can achieve initial batch installation of operating systems, it can only complete the boot loading of the system kernel and base image. For key aspects such as hardware driver adaptation, custom disk partitioning planning, personalized network parameter configuration, and internal dedicated software deployment, a large amount of manual intervention and debugging is still required. In addition, the lack of a unified offline resource management and automated configuration injection mechanism in closed environments leads to fragmented deployment processes and fails to form a complete automated closed loop from hardware identification to system readiness. This cannot meet the deployment requirements of high efficiency, standardization, and low manual intervention in closed network environments. Therefore, there is an urgent need for an integrated automated solution that integrates hardware adaptation, configuration generation, system installation, and software deployment. Summary of the Invention

[0004] This invention provides a PXE-based automated batch deployment and integrated initial configuration system and method, the main purpose of which is to improve the efficiency of PXE-based automated batch deployment and integrated initial configuration.

[0005] To achieve the above objectives, this invention provides an automated batch deployment and integration commissioning configuration system based on PXE, comprising:

[0006] The PXE information acquisition module is used to collect PXE startup request information and hardware characteristic information of the client to be deployed, and extract the client's MAC address and network configuration parameters from the PXE startup request information.

[0007] The deployment requirement monitoring module is used to combine the MAC address and the hardware feature information to determine the Linux kernel loading requirements and driver installation requirements of the client to be deployed, then determine the operating system installation parameters required by the client to be deployed, and monitor the intranet server connection status of the client to be deployed based on the network configuration parameters.

[0008] The disk partitioning planning module is used to obtain the client's system hardware information and, based on the system hardware information, formulate a disk partitioning scheme for the client to be deployed.

[0009] The system image deployment module is used to combine the operating system installation parameters, the intranet server connection status and the disk partitioning scheme, pull the operating system image of the client to be deployed from the intranet server, execute the automated deployment configuration of the client to be deployed using the preset response file, record the deployment stage information of the client to be deployed, and analyze the deployment progress status of the Linux kernel based on the deployment stage information.

[0010] The post-configuration integration module is used to analyze the business role identifier and hardware baseline performance of the client to be deployed when the deployment progress status is complete, determine the post-configuration content of the client to be deployed, and perform system integration operations on the client to be deployed according to the post-configuration content to obtain a lightweight business-ready system for the client to be deployed.

[0011] Optionally, after determining the Linux kernel loading requirements and driver installation requirements for the client to be deployed by combining the MAC address and the hardware characteristic information, the process includes:

[0012] Extract the hardware component identifier from the hardware feature information, associate the MAC address with the hardware component identifier, and obtain the hardware configuration profile;

[0013] Based on the hardware configuration file, the kernel loading configuration and driver module configuration of the client to be deployed are determined from the preset kernel driver support rule base;

[0014] Analyze the multidimensional dependencies between the kernel loading configuration and the driver module configuration, and detect compatibility conflicts between the kernel loading configuration and the driver module configuration;

[0015] Based on the multidimensional dependencies and compatibility conflicts, the Linux kernel loading requirements and driver installation requirements for the client to be deployed are determined from the kernel loading configuration and the driver module configuration.

[0016] Optionally, detecting compatibility conflicts between the kernel loading configuration and the driver module configuration includes:

[0017] Extract the resource allocation information set and version identifier set from the kernel loading configuration and the driver module configuration;

[0018] Based on the resource allocation information set, calculate the resource conflict rate between the kernel loading configuration and the driver module configuration;

[0019] Based on the set of version identifiers, calculate the version matching degree between the kernel loading configuration and the driver module configuration;

[0020] Combining the resource conflict rate and the version matching degree, the compatibility conflict coefficient between the kernel loading configuration and the driver module configuration is calculated using the following formula:

[0021]

[0022] Where C represents the compatibility conflict coefficient between the kernel loading configuration and the driver module configuration. V represents the resource conflict rate, and V represents the version compatibility. Indicates sensitivity to resource conflicts. Indicates version matching sensitivity;

[0023] Based on the compatibility conflict coefficient, the compatibility conflict between the kernel loading configuration and the driver module configuration is determined.

[0024] Optionally, calculating the resource conflict rate between the kernel loading configuration and the driver module configuration based on the resource allocation information set includes:

[0025] Extract the kernel resource allocation information and driver resource allocation information from the resource allocation information set;

[0026] Identify the allocation resource identifiers corresponding to the kernel allocation resource information and the driver resource allocation information, and based on the allocation resource identifiers, count the overlapping resource items in the kernel allocation resource information and the driver resource allocation information;

[0027] The number of overlapping resource items and the number of driving resource items are counted separately to obtain the number of overlapping resource items and the number of driving resource items, and the conflict severity score corresponding to the overlapping resource items is assigned.

[0028] Combining the number of overlapping resource items, the number of driver resource items, and the conflict severity score, the resource conflict rate between the kernel loading configuration and the driver module configuration is calculated using the following formula:

[0029]

[0030] Where R represents the resource conflict rate between the kernel loading configuration and the driver module configuration. This represents the conflict severity score corresponding to the i-th overlapping resource item. Indicates the number of overlapping resource items. This represents the number of driving resource items, where i represents the sequence number corresponding to the overlapping resource item.

[0031] Optionally, the step of formulating a disk partitioning scheme for the client to be deployed based on the system hardware information includes:

[0032] Identify the storage device capacity entries and recording time points in the system hardware information, and sort the storage device capacity entries according to the recording time points to obtain the recording time-series capacity;

[0033] Query the pre-defined client task types and extract the basic space allocation corresponding to the client task types;

[0034] Obtain the physical interface standard and health status of the storage device corresponding to the system hardware information, and determine the interface speed efficiency of the client's storage device based on the physical interface standard;

[0035] Calculate the health reliability value of the client's storage device;

[0036] Combining the recorded timing capacity, the interface speed efficiency, the health reliability value, the identifier health, and the basic space allocation, the available space equivalent of the storage device is calculated using the following formula:

[0037]

[0038] in, This represents the available space equivalent of the storage device. This represents the record timing capacity of the j-th storage device. Indicates the physical interface standard of the j-th storage device. Interface speed efficiency This represents the health status of the j-th storage device, where j represents the number of storage devices and m represents the total number of storage devices. The indicated allocation ratio;

[0039] Based on the available space equivalent, a disk partitioning scheme for the client to be deployed is formulated.

[0040] Optionally, calculating the health reliability value of the client's storage device includes:

[0041] Query the historical operation records of the storage device and extract the operation failure records from the historical operation records;

[0042] Based on the operational failure records, calculate the current expected stability of the storage device;

[0043] Extract the health monitoring indicators of the storage device, and calculate the state deviation of the storage device based on the health monitoring indicators;

[0044] Based on the current expected stability and the state deviation, calculate the health reliability value of the client's storage device.

[0045] Optionally, calculating the current expected stability of the storage device based on the operational failure records includes:

[0046] Count the cumulative number of occurrences of the recorded operational faults within a preset period;

[0047] Identify the fault type and faulty component in the operational fault record, and assign a fault impact coefficient corresponding to the fault type based on the faulty component;

[0048] Obtain the total effective operating time of the storage device corresponding to the operating fault record;

[0049] Combining the cumulative number of occurrences, the fault impact coefficient, and the total effective operating time, the current expected stability of the storage device is calculated using the following formula:

[0050]

[0051] in, This indicates that the storage device is currently expected to remain stable. Indicates the cumulative number of occurrences. Indicates the fault impact coefficient. This indicates the total effective running time.

[0052] Optionally, analyzing the deployment progress status of the Linux kernel based on the deployment phase information includes:

[0053] Extract the key event streams related to the anomalies from the deployment phase information;

[0054] Based on the aforementioned key event stream, a causal network graph of the Linux kernel is constructed.

[0055] Identify the key root cause nodes in the causal network graph, and analyze the node deployment progress of the key root cause nodes based on the key event flow;

[0056] Based on the deployment progress of the nodes, analyze the deployment progress status of the Linux kernel.

[0057] Optionally, constructing a causal network graph of the Linux kernel based on the key event stream includes:

[0058] Filter the critical events related to the Linux kernel in the critical event stream, and extract the causal event units from the critical events.

[0059] Identify the core events and their corresponding related events within the causal event unit;

[0060] Based on the associated events and the core events, the causal dependency chain and kernel context scenario of the causal event unit are analyzed.

[0061] Based on the causal dependency chain and the kernel context scenario, a causal network graph of the Linux kernel is constructed.

[0062] A method for automated batch deployment and integration initial configuration based on PXE, characterized in that the method includes:

[0063] Collect PXE boot request information and hardware characteristic information of the client to be deployed, and extract the client's MAC address and network configuration parameters from the PXE boot request information;

[0064] After determining the Linux kernel loading requirements and driver installation requirements for the client to be deployed by combining the MAC address and the hardware feature information, the operating system installation parameters required for the client to be deployed are determined, and the intranet server connection status of the client to be deployed is monitored based on the network configuration parameters.

[0065] Obtain the client's system hardware information, and based on the system hardware information, formulate a disk partitioning scheme for the client to be deployed;

[0066] Combining the operating system installation parameters, the intranet server connection status, and the disk partitioning scheme, after pulling the operating system image of the client to be deployed from the intranet server, the automated deployment configuration of the client to be deployed is executed using a preset response file, and the deployment stage information of the client to be deployed is recorded. Based on the deployment stage information, the deployment progress status of the Linux kernel is analyzed.

[0067] When the deployment progress status is complete, the business role identifier and hardware baseline performance of the client to be deployed are analyzed to determine the post-configuration content of the client to be deployed. Based on the post-configuration content, the system integration operation of the client to be deployed is performed to obtain the lightweight business-ready system of the client to be deployed.

[0068] This invention extracts the client's MAC address and network configuration parameters from the PXE boot request information, enabling the determination of the client's network identity and basic network connectivity information. This provides a foundation for subsequent PXE automatic boot deployment and hardware adaptation. By combining the MAC address and hardware characteristics, this invention determines the Linux kernel loading and driver installation requirements for the client, achieving system-to-physical hardware compatibility and laying a foundation for subsequent automated deployment. Based on the system hardware information, this invention plans the hard disk space allocation for the client, allowing for an understanding of the client's storage resource configuration and expected usage load, providing a basis for subsequent space allocation operations. Finally, by combining the operating system installation parameters, the intranet server connection status, and the disk partitioning scheme, this invention retrieves the operating system image of the client from the intranet server, ensuring the quality of the retrieved image. The version, architecture, and target hardware configuration are precisely matched. Then, using a pre-defined response file, automated deployment configuration of the client to be deployed is executed. This enables unattended and standardized processing of key steps during installation, such as user interaction, partition settings, and software package selection, minimizing the differences caused by manual operations. Finally, when the deployment progress status is complete, this invention analyzes the business role identifier and hardware baseline performance of the client to be deployed to determine the post-configuration content. This allows for an accurate understanding of business needs and full utilization of hardware capabilities. Based on the post-configuration content, system integration operations are performed on the client to be deployed, automatically adapting and integrating necessary functional components to obtain a lightweight, business-ready system for the client to be deployed. Therefore, this invention can improve the efficiency of automated batch deployment and integrated initial configuration based on PXE. Attached Figure Description

[0069] Figure 1 A functional block diagram of an automated batch deployment and integration commissioning configuration system based on PXE provided in an embodiment of the present invention;

[0070] Figure 2 A schematic diagram of PXE operation for an automated batch deployment and integrated initial configuration method based on PXE provided in an embodiment of the present invention;

[0071] Figure 3 This is a flowchart illustrating an automated batch deployment and integration initial configuration method based on PXE, provided in an embodiment of the present invention.

[0072] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0073] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0074] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0075] In practice, the server-side equipment deployed by the PXE-based automated batch deployment and integration commissioning configuration system may consist of one or more devices. The aforementioned PXE-based automated batch deployment and integration commissioning configuration system can be implemented as: a business instance, a virtual machine, or hardware devices. For example, this PXE-based automated batch deployment and integration commissioning configuration system can be implemented as a business instance deployed on one or more devices in a cloud node. Simply put, this PXE-based automated batch deployment and integration commissioning configuration system can be understood as software deployed on a cloud node, used to provide PXE-based automated batch deployment and integration commissioning configuration services to various user terminals. Alternatively, this PXE-based automated batch deployment and integration commissioning configuration system can also be implemented as a virtual machine deployed on one or more devices in a cloud node. This virtual machine contains application software for managing various user terminals. Alternatively, this PXE-based automated batch deployment and integration commissioning configuration system can also be implemented as a server composed of numerous identical or different types of hardware devices, with one or more hardware devices configured to provide PXE-based automated batch deployment and integration commissioning configuration services to various user terminals.

[0076] In terms of implementation, the PXE-based automated batch deployment and integration configuration system and the user client are mutually compatible. That is, if the PXE-based automated batch deployment and integration configuration system is implemented as an application installed on a cloud service platform, then the user client acts as a client that establishes a communication connection with that application; or if the PXE-based automated batch deployment and integration configuration system is implemented as a website, then the user client acts as a webpage; or if the PXE-based automated batch deployment and integration configuration system is implemented as a cloud service platform, then the user client acts as a mini-program within an instant messaging application.

[0077] Reference Figure 1 The diagram shown is a functional block diagram of an automated batch deployment and integration initial configuration system based on PXE provided in an embodiment of the present invention.

[0078] The PXE-based automated batch deployment and integration configuration system 100 described in this invention can be located on a cloud server. In terms of implementation, it can function as one or more service devices, or as an application installed on the cloud (e.g., a PXE-based automated batch deployment and integration configuration server, server cluster, etc.), or it can be developed as a website. Depending on the functions implemented, the PXE-based automated batch deployment and integration configuration system 100 includes a PXE information acquisition module 101, a deployment requirement monitoring module 102, a disk partitioning planning module 103, a system image deployment module 104, and a post-configuration integration module 105.

[0079] In this embodiment of the invention, during the tracking of PXE-based automated batch deployment and integrated initial configuration, each of the above modules can be implemented independently and can call other modules. This calling can be understood as a module connecting to multiple modules of another type and providing corresponding services to those connected modules. In the PXE-based automated batch deployment and integrated initial configuration system provided by this embodiment of the invention, the applicability of the PXE-based automated batch deployment and integrated initial configuration architecture can be adjusted by adding modules and directly calling them without modifying the program code, achieving cluster-based horizontal expansion to quickly and flexibly expand the PXE-based automated batch deployment and integrated initial configuration system. In practical applications, the above modules can be set in the same device or different devices, or they can be set in virtual devices, such as service instances in a cloud server.

[0080] The following describes, with reference to specific embodiments, each component and specific workflow of the PXE-based automated batch deployment and integration commissioning configuration system.

[0081] The PXE information acquisition module 101 is used to collect PXE startup request information and hardware characteristic information of the client to be deployed, and extract the client's MAC address and network configuration parameters from the PXE startup request information.

[0082] This invention extracts the client's MAC address and network configuration parameters from the PXE boot request information, thereby obtaining the network identity and basic network connectivity information of the client to be deployed, and thus providing a basis for the subsequent automatic PXE boot deployment and hardware adaptation of the client.

[0083] The PXE boot request information is a set of network interaction messages sent by the client to be deployed to the PXE server in the local area network through the network interface when the client has no local boot media at startup, requesting boot resources. The hardware characteristic information is the inherent attributes and specification details of the various hardware devices mounted on the client. The MAC address is the unique physical identifier corresponding to the client's network interface, used to accurately distinguish different network devices within the local area network. The network configuration details are the basic network settings required for the client to achieve network connectivity with the PXE server. Furthermore, the PXE boot request information sent by the client can be captured using network monitoring technology, and the hardware characteristic information of the client can be collected using hardware low-level reading technology. The client's MAC address and network configuration parameters can be extracted from the PXE boot request information using an extraction function, which can be compiled using the JAVA language.

[0084] Furthermore, to gain a more intuitive understanding of how PXE works, you can refer to the following... Figure 2 This diagram illustrates the PXE workflow provided in this embodiment of the invention, clearly demonstrating the interaction between the client and server during the PXE boot process. According to the diagram, the process mainly includes: the client obtaining the IP address and boot file information from the server, progressively requesting and receiving the bootloader, configuration files, kernel image, and initialization files, ultimately completing the network boot of the operating system. The entire process demonstrates the hierarchical and phased characteristics of PXE booting, highlighting its ability to achieve remote system deployment without relying on local storage.

[0085] The deployment requirement monitoring module 102 is used to determine the Linux kernel loading requirements and driver installation requirements corresponding to the client to be deployed by combining the MAC address and the hardware feature information, then determine the operating system installation parameters required by the client to be deployed, and monitor the intranet server connection status of the client to be deployed based on the network configuration parameters.

[0086] This invention, by combining the MAC address and the hardware characteristic information, determines the Linux kernel loading requirements and driver installation requirements corresponding to the client to be deployed, enabling system construction to adapt to physical hardware and laying a compatibility foundation for subsequent automated deployment. The Linux kernel loading requirements refer to the list of modules that need to be explicitly loaded or built-in during the kernel startup phase to match specific hardware; the driver installation requirements refer to the set of proprietary driver packages that need to be installed additionally after the operating system is installed.

[0087] As an embodiment of the present invention, after determining the Linux kernel loading requirements and driver installation requirements corresponding to the client to be deployed by combining the MAC address and the hardware feature information, the process includes:

[0088] Extract the hardware component identifier from the hardware feature information, associate the MAC address with the hardware component identifier, and obtain the hardware configuration profile;

[0089] Based on the hardware configuration file, the kernel loading configuration and driver module configuration of the client to be deployed are determined from the preset kernel driver support rule base;

[0090] Analyze the multidimensional dependencies between the kernel loading configuration and the driver module configuration, and detect compatibility conflicts between the kernel loading configuration and the driver module configuration;

[0091] Based on the multidimensional dependencies and compatibility conflicts, the Linux kernel loading requirements and driver installation requirements for the client to be deployed are determined from the kernel loading configuration and the driver module configuration.

[0092] The hardware configuration file refers to a data object generated by associating a network identity identifier with a structured storage hardware component identifier; the kernel driver support rule base is a pre-built, continuously updated knowledge system that stores the mapping relationship between hardware identifiers and feasible Linux kernel modules, driver packages and versions, as well as a repository of metadata rules such as dependencies and conflicts between various software components; the multidimensional dependency relationship includes, but is not limited to, loading order dependency, functional symbol dependency, resource exclusive dependency, and version chain dependency; the compatibility conflict specifically refers to the mutual exclusion state caused by kernel API version mismatch, driver and firmware interface version incompatibility, or two software components competing for the same system resources.

[0093] Furthermore, the extraction of hardware component identifiers from hardware feature information involves associating MAC addresses with these identifiers. Specifically, this can be achieved by calling a standardized system information interface to collect raw information in a pre-boot environment or dedicated probe program. Then, regular expressions or lookup tables are used to precisely extract key fields such as device ID and vendor ID from the output text. Finally, the MAC address is used as the metadata anchor point, and all identifiers are organized into key-value pairs or JSON documents to form the hardware configuration file. The standardized system information interface, such as through LSPCI... -nn, lsusb, dmidecode, cpuid commands and their parsing libraries; the configuration determined from a preset rule base based on the hardware configuration file can be found by using each hardware identifier in the file as a query key and performing concurrent retrieval in the rule base index to find all candidate kernel modules and driver packages, and aggregating them to form an initial configuration set, such as prioritizing matching device IDs and then matching chipset categories; an attribute graph model with software components as nodes and various relationships as directed or undirected edges can be constructed, and graph traversal algorithms such as depth-first search can be used to identify dependency chains, thereby analyzing the multidimensional dependency relationship between the kernel loading configuration and the driver module configuration; based on the multidimensional dependency relationship and the compatibility conflict, the Linux kernel loading requirements and driver installation requirements corresponding to the client to be deployed are determined from the kernel loading configuration and the driver module configuration, such as first verifying the version compatibility, symbol dependencies, and system call interface compatibility of the driver module and the target Linux kernel one by one, eliminating configuration items with loading conflicts or missing dependencies, and then combining the client hardware architecture and business deployment scenario to select configuration combinations with no compatibility risks and that meet the minimum kernel loading rules.

[0094] Optionally, detecting compatibility conflicts between the kernel loading configuration and the driver module configuration includes:

[0095] Extract the resource allocation information set and version identifier set from the kernel loading configuration and the driver module configuration;

[0096] Based on the resource allocation information set, calculate the resource conflict rate between the kernel loading configuration and the driver module configuration;

[0097] Based on the set of version identifiers, calculate the version matching degree between the kernel loading configuration and the driver module configuration;

[0098] Combining the resource conflict rate and the version matching degree, the compatibility conflict coefficient between the kernel loading configuration and the driver module configuration is calculated using the following formula:

[0099]

[0100] Where C represents the compatibility conflict coefficient between the kernel loading configuration and the driver module configuration. V represents the resource conflict rate, and V represents the version compatibility. Indicates sensitivity to resource conflicts. Indicates version matching sensitivity;

[0101] Based on the compatibility conflict coefficient, the compatibility conflict between the kernel loading configuration and the driver module configuration is determined.

[0102] The resource allocation information set and the version identifier set are respectively key metadata sets in the kernel loading configuration and the driver module configuration that specifically define the system hardware resource usage and software component version identifiers; the resource conflict rate is a quantitative value calculated based on the resource allocation information set regarding the degree of resource overlap and competition between the kernel loading configuration and the driver module configuration; the version matching degree is a quantitative value calculated based on the version identifier set regarding the version consistency and compatibility between the kernel loading configuration and the driver module configuration; the compatibility conflict coefficient represents the overall configuration compatibility risk between the kernel loading configuration and the driver module configuration. The comprehensive quantitative assessment value of risk; the resource conflict sensitivity represents the moderating weight of the resource conflict rate on the final conflict coefficient; the version matching sensitivity represents the moderating weight of the version matching degree on the final conflict coefficient. The resource conflict sensitivity and the version matching sensitivity can be optimized and calibrated through statistical analysis of historical compatibility conflict data. Specifically, by collecting historical compatibility conflict data, using version matching degree and resource conflict degree as input features, and conflict coefficient as output label, a logistic regression or neural network model can be constructed for training. Optimization algorithms such as gradient descent can be used to minimize the prediction error, thereby calibrating the optimal weights of version matching sensitivity and resource conflict sensitivity.

[0103] Furthermore, the system configuration parser can extract the resource allocation information set and version identifier set from the kernel loading configuration and the driver module configuration. The system configuration parser can be compiled using a programming language.

[0104] Furthermore, based on the set of version identifiers, the version matching degree between the kernel loading configuration and the driver module configuration is calculated by comparing them using semantic versioning rules. First, the major version number, minor version number, and revision number of the kernel and driver are compared sequentially according to the semantic versioning rules. Differentiated weights are assigned to different levels of version numbers, and the final version matching degree is obtained by accumulating and quantifying the level matching scores.

[0105] Furthermore, the compatibility conflict between the kernel loading configuration and the driver module configuration is determined by comparing the compatibility conflict coefficient with a preset threshold. Three gradient thresholds of 0, 0.3, and 0.7 are preset. The calculated compatibility conflict coefficient is compared with the threshold to classify the compatibility conflict results into four categories: no conflict, slight conflict, moderate conflict, and severe conflict.

[0106] Optionally, calculating the resource conflict rate between the kernel loading configuration and the driver module configuration based on the resource allocation information set includes:

[0107] Extract the kernel resource allocation information and driver resource allocation information from the resource allocation information set;

[0108] Identify the allocation resource identifiers corresponding to the kernel allocation resource information and the driver resource allocation information, and based on the allocation resource identifiers, count the overlapping resource items in the kernel allocation resource information and the driver resource allocation information;

[0109] The number of overlapping resource items and the number of driving resource items are counted separately to obtain the number of overlapping resource items and the number of driving resource items, and the conflict severity score corresponding to the overlapping resource items is assigned.

[0110] Combining the number of overlapping resource items, the number of driver resource items, and the conflict severity score, the resource conflict rate between the kernel loading configuration and the driver module configuration is calculated using the following formula:

[0111]

[0112] Where R represents the resource conflict rate between the kernel loading configuration and the driver module configuration. This represents the conflict severity score corresponding to the i-th overlapping resource item. Indicates the number of overlapping resource items. This represents the number of driving resource items, where i represents the sequence number corresponding to the overlapping resource item.

[0113] The kernel resource allocation information and the driver resource allocation information respectively represent the ownership and allocation details of the hardware resources occupied during the kernel loading phase and required for the operation of the driver module; the allocated resource identifier is a unique index that distinguishes resource types such as memory address, interrupt number, IO port, and DMA channel; the number of overlapping resource items represents the number of specific items in which the kernel and driver are contending for resources; the number of driver resource items represents the total scale of resource items required for the normal loading of the driver module; and the conflict severity score represents the impact level of each overlapping resource item on the stability of system operation.

[0114] Furthermore, the resource traversal and parsing module compiled in C language can be used to extract various resource details and allocation identifiers from the resource allocation information set. The module supports automatic identification, classification, and item statistics of multiple types of hardware resources. By combining the resource type, system resource scarcity, and running priority of overlapping resource items, a hierarchical assignment method can be used to allocate the conflict severity score corresponding to the overlapping resource items. For example, core scarce resources are assigned a value of 0.8-1.0, and ordinary resources are assigned a value of 0.2-0.5, which can accurately distinguish the degree of conflict impact of different overlapping resources.

[0115] This invention automates and standardizes deployment tasks by determining the operating system installation parameters required for the client to be deployed, avoiding configuration errors that may be introduced by manual intervention. Based on the network configuration parameters, it monitors the connection status of the client's intranet server, which can verify and ensure the connectivity and stability of the network infrastructure in the early stages of the deployment process. This provides a reliable network environment guarantee for subsequent key steps such as image transmission and software distribution, thereby reducing the risk of deployment failure due to network problems.

[0116] The operating system installation parameters are determined by combining the Linux kernel loading requirements and driver installation requirements to establish the core deployment configuration set required by the client to be deployed, including the kernel version, driver adaptation rules, disk partitioning, and boot entries. The intranet server connection status is based on real-time network operation indicators such as link connectivity, network latency, and packet loss rate obtained by detecting the client to be deployed using the network configuration parameters. Furthermore, combining the Linux kernel loading requirements and driver installation requirements, the operating system installation parameters required by the client to be deployed are determined through configuration adaptation verification and parameter normalization integration. For example, the compatibility of the Linux kernel loading requirements, driver installation requirements, and client hardware environment is verified item by item, and then the discrete deployment parameters are normalized into standardized installation configuration items to generate compatible and directly deployable operating system installation parameters. Based on the network configuration parameters, the intranet server connection status of the client to be deployed is monitored using heartbeat probe polling and bidirectional connectivity verification. For example, ICMP probe messages and TCP handshake requests are sent to the target intranet server at preset time intervals, while listening for server acknowledgment messages and calculating link latency and packet loss rate in real time to determine whether the intranet connection is stable and reachable.

[0117] The disk partitioning planning module 103 is used to obtain the system hardware information of the client and, based on the system hardware information, formulate a disk partitioning scheme for the client to be deployed.

[0118] By formulating a hard disk space partitioning plan for the client to be deployed based on the system hardware information, the storage resource configuration and expected usage load of the client can be understood, providing a basis for subsequent space allocation operations. The system hardware information includes detailed descriptions of the client's core components such as hard disk, memory, and processor, collected from the client. The disk partitioning scheme refers to the specific operational instructions for partitioning, formatting, and setting mount points on the client's hard disk, reflecting the planning and allocation of storage space. Furthermore, the system hardware information can be obtained through built-in operating system commands or information gathering tools.

[0119] As an example of this process, the step of formulating a disk partitioning scheme for the client to be deployed based on the system hardware information includes:

[0120] Identify the storage device capacity entries and recording time points in the system hardware information, and sort the storage device capacity entries according to the recording time points to obtain the recording time-series capacity;

[0121] Query the pre-defined client task types and extract the basic space allocation corresponding to the client task types;

[0122] Obtain the physical interface standard and health status of the storage device corresponding to the system hardware information, and determine the interface speed efficiency of the client's storage device based on the physical interface standard;

[0123] Calculate the health reliability value of the client's storage device;

[0124] After normalizing the record timing capacity, the interface speed efficiency, the identifier health, the health reliability value, and the basic space allocation, the available space equivalent of the storage device is calculated using the following formula:

[0125]

[0126] in, This represents the available space equivalent of the storage device. This represents the normalized time-series capacity of the j-th storage device. This represents the interface speed efficiency of the j-th storage device after physical interface standard normalization. This represents the normalized health status of the j-th storage device. Let represent the normalized health reliability value of the j-th storage device, B represent the basic space allocation, j and k both represent the serial number of the storage device, and m represent the total number of storage devices. , , , These represent the normalized record time-series capacity, interface speed efficiency, identifier health, and health reliability value of the k-th storage device, respectively.

[0127] Based on the available space equivalent, a disk partitioning scheme for the client to be deployed is formulated.

[0128] Wherein, the storage device capacity entry and the recording time point are the times when the disk space and its acquisition are described in the system hardware information; the recorded time-series capacity is a capacity data column arranged in order of recording time points; the client task type is a predefined type label based on the nature of the service or application to be deployed on the client, such as database service, virtualization platform, file repository; the basic space allocation is the initial space requirement for the system's main storage area mapped from the task type; the physical interface standard is the electrical and logical specification for the connection between the storage device and the system motherboard; the identification health is a quantitative value of the storage device's current operating status and reliability after evaluation; the interface speed efficiency is a ratio of the interface's theoretical data transfer capability to the standard reference interface, obtained by querying the interface performance benchmark table; the health reliability value is a coefficient used to reduce the device capacity availability in space calculations based on the identification health; and the allocation ratio is the ratio of the basic space allocation to the original total capacity of all storage devices, used to scale theoretical requirements to actual available resources.

[0129] Furthermore, the storage device capacity entries and recording timestamps in the system hardware information can be identified by a system information parser, which is compiled using a scripting language. Based on the recording timestamps, the storage device capacity entries can be sorted using a capacity time-series sorting algorithm to obtain the recorded time-series capacity. A pre-defined client task type and its corresponding basic space allocation can be queried through a task configuration database query interface. The task configuration database is a relational database storing various client tasks and their corresponding preset storage configuration values. Based on the physical interface standard, the interface speed efficiency of the client's storage device can be determined by querying a preset interface performance comparison table, which is a table constructed using a large amount of interface performance statistics.

[0130] Optionally, calculating the health reliability value of the client's storage device includes:

[0131] Query the historical operation records of the storage device and extract the operation failure records from the historical operation records;

[0132] Based on the operational failure records, calculate the current expected stability of the storage device;

[0133] Extract the health monitoring indicators of the storage device, and calculate the state deviation of the storage device based on the health monitoring indicators;

[0134] Based on the current expected stability and the state deviation, calculate the health reliability value of the client's storage device.

[0135] The historical operation record is a collection of performance data and event logs continuously recorded by the storage device during its past operation; the operation failure record is a selection of specific event entries that clearly record abnormalities, errors, or functional failures of the device; the current expected stability is an estimate of the probability that the device will maintain normal operation in the next statistical period, obtained through statistical analysis based on the operation failure record; the health monitoring index is a technical parameter that reflects the current working status of the device, obtained in real time from the device firmware or operating system level; and the status deviation is a quantitative value of the comprehensive deviation calculated by comparing the values ​​of the health monitoring index with the preset benchmark values ​​of the device model under standard health conditions.

[0136] Furthermore, the historical operation records can be obtained through the operation log query interface of the device operation and maintenance management platform; health monitoring indicators can be extracted by calling device health status query commands, such as the SMART command; based on the current expected stability and the state deviation, the health reliability value of the client's storage device can be calculated by the weighted geometric mean method, by multiplying the current expected stability and the state deviation by their corresponding weights and summing them, and then averaging the summed results to obtain the health reliability value.

[0137] Optionally, calculating the current expected stability of the storage device based on the operational failure records includes:

[0138] Count the cumulative number of occurrences of the recorded operational faults within a preset period;

[0139] Identify the fault type and faulty component in the operational fault record, and assign a fault impact coefficient corresponding to the fault type based on the faulty component;

[0140] Obtain the total effective operating time of the storage device corresponding to the operating fault record;

[0141] Combining the cumulative number of occurrences, the fault impact coefficient, and the total effective operating time, the current expected stability of the storage device is calculated using the following formula:

[0142]

[0143] in, This indicates that the storage device is currently expected to remain stable. Indicates the cumulative number of occurrences. Indicates the fault impact coefficient. This indicates the total effective running time.

[0144] The preset observation period is a continuous historical time range selected for stability assessment; the cumulative occurrence count is the total number of all recorded operational failure events within this period; the failure type is a category based on the failure phenomenon and its impact range, such as "read / write error", "response timeout", "logical bad block", etc.; the impact coefficient is a preset quantitative value for each type of failure, characterizing its degree of damage to the overall operational stability of the device, usually preset based on the average time spent on failure repair or the average impact on business; the total effective runtime is the total time that the storage device is in a normal service-providing state within the preset observation period, excluding downtime or degraded operation time caused by failure.

[0145] Furthermore, the cumulative number of occurrences can be counted by querying the timestamp and event type fields of the operational fault records using a custom query algorithm; each fault can be assigned a corresponding impact coefficient according to a predefined fault type-impact coefficient mapping table; and the total effective runtime can be obtained by querying the device operation status log, filtering out the time periods of "normal" or "ready" status, and accumulating them.

[0146] The system image deployment module 104 is used to combine the operating system installation parameters, the intranet server connection status and the disk partitioning scheme, pull the operating system image of the client to be deployed from the intranet server, execute the automated deployment configuration of the client to be deployed using a preset response file, record the deployment stage information of the client to be deployed, and analyze the deployment progress status of the Linux kernel based on the deployment stage information.

[0147] This invention combines the operating system installation parameters, the intranet server connection status, and the disk partitioning scheme to pull the operating system image of the client to be deployed from the intranet server. This ensures that the version and architecture of the obtained image are accurately matched with the target hardware configuration. Then, the automated deployment configuration of the client to be deployed is executed using a preset response file. This enables unattended and standardized processing of key steps such as user interaction, partition settings, and software package selection during the installation process, thereby minimizing the differences caused by manual operation.

[0148] The operating system image refers to a read-only template file containing a complete Linux kernel, basic operating environment, and pre-installed software; the response file is a pre-written text file containing all necessary configuration instructions for the installation process; the automated deployment configuration refers to the entire process where the deployment program autonomously completes a series of operations, from system decompression and installation, driver adaptation, network settings to service start-up and shutdown, until the client is usable, without real-time human intervention, based on the response file and predetermined steps; furthermore, combining the operating system installation parameters, the intranet server connection status, and the disk partitioning scheme, after pulling the operating system image of the client to be deployed from the intranet server, the automated deployment configuration of the client to be deployed is executed using the preset response file. Specifically: the deployment engine first selects the available server node with the best network quality to establish a transmission link based on the intranet server connection status, and then compares the system version and hardware architecture information in the operating system installation parameters with the index of the server image repository to accurately locate and pull the matching image file. During the installation phase, the deployment engine directly formats and partitions the target disk according to the disk partitioning scheme, and performs silent installation and initialization configuration according to the preset response file throughout the process, thereby realizing automated deployment configuration of the client to be deployed.

[0149] This invention analyzes the deployment progress status of the Linux kernel based on the deployment phase information, transforming discrete and asynchronous recorded information into a coherent description of the core installation process. The deployment phase information comprises key events and log output captured during automated configuration; the deployment progress status is a comprehensive representation of the Linux kernel's progress from image release and module loading to initialization completion and its health status; furthermore, the deployment phase information of the client to be deployed can be recorded through a deployment program, which is pre-compiled using a computer language.

[0150] As an embodiment of the present invention, the step of analyzing the deployment progress status of the Linux kernel based on the deployment phase information includes:

[0151] Extract the key event streams related to the anomalies from the deployment phase information;

[0152] Based on the aforementioned key event stream, a causal network graph of the Linux kernel is constructed.

[0153] Identify the key root cause nodes in the causal network graph, and analyze the node deployment progress of the key root cause nodes based on the key event flow;

[0154] Based on the deployment progress of the nodes, analyze the deployment progress status of the Linux kernel.

[0155] The critical event stream refers to the sequence of events selected from data sources such as system logs, performance monitoring, and configuration management tools during the Linux kernel deployment process, representing the success, failure, delay, or unexpected state of the deployment steps, such as "kernel module loading failure," "service systemd-unit startup timeout," and "hardware adapter driver incompatibility alarm." The causal network graph refers to a directed graph representing the causal relationships between the above critical events and system component states. Nodes represent specific events or component states, and edges represent causal logic such as "caused," "triggered," or "dependent on," thus connecting discrete events into a network model reflecting fault propagation or deployment dependency paths. The critical root cause node refers to a node in the causal network graph with an in-degree of zero or very low, i.e., no or very few preceding causes, but a high out-degree, i.e., capable of triggering a series of subsequent events. It is usually the earliest fundamental anomaly point in the deployment chain. The node deployment progress refers to the degree of deployment for each identified critical root cause node.

[0156] Furthermore, a monitoring agent can be deployed to collect kernel boot logs, process states, file system changes, and performance metrics. Based on predefined rules or anomaly detection models such as isolated forests, abnormal events can be filtered and marked in real time to form the critical event stream. A graph algorithm is used to calculate the in-degree and out-degree of all nodes in the network, and combined with prior knowledge, such as a library of necessary steps in the deployment process, nodes with low in-degree but high out-degree and located at the beginning of the deployment sequence are identified as the critical root cause nodes. For each critical root cause node, all downstream nodes affected by it are traced back, and the current status of the corresponding components of these nodes is checked, such as whether the service is active, whether the configuration file exists and is compliant, and whether the kernel parameters are effective. This allows the deployment progress of the fault chain or dependency chain represented by that node to be calculated. For example, completion rate = number of successfully deployed downstream components / downstream group. The total number of components; finally, a comprehensive analysis of the deployment progress of all critical root cause nodes is conducted. The shortest board principle is adopted, where the root cause node with the lowest progress determines the overall status, generating a quantitative Linux kernel deployment progress status report with a health label. For example, when deploying a new kernel version, monitoring detects an "NVMe driver module loading failure" event, which triggers subsequent event chains such as "root file system mount timeout" and "target service cannot start". The causal network graph shows that "NVMe driver module loading failure" is the critical root cause node. Analysis of the progress of this node reveals that the cause is the missing new driver in the initrd image. The three downstream critical services are not ready, and the node deployment progress is 0%. Combining the progress of other root cause nodes, the system determines the overall deployment progress status as "blocked, critical hardware driver abnormal" and highlights the root cause.

[0157] Optionally, constructing a causal network graph of the Linux kernel based on the key event stream includes:

[0158] Filter the critical events related to the Linux kernel in the critical event stream, and extract the causal event units from the critical events.

[0159] Identify the core events and their corresponding related events within the causal event unit;

[0160] Based on the associated events and the core events, the causal dependency chain and kernel context scenario of the causal event unit are analyzed.

[0161] Based on the causal dependency chain and the kernel context scenario, a causal network graph of the Linux kernel is constructed.

[0162] The term "critical event" refers to the core events in the critical event stream that directly affect the Linux kernel's running state, function execution, exception generation, and performance fluctuations, encompassing kernel exception events, core subsystem service call events, and critical system resource scheduling events. The term "causal event unit" refers to the smallest analytical unit composed of a group of events with direct or indirect causal relationships within the critical events, serving as the basic granularity for decomposing and analyzing kernel causal relationships. The term "core event" refers to the key node event within the causal event unit that serves as the triggering source, core node of the process, or endpoint of the result, and is the core of the entire causal event unit's analysis. The term "related event" refers to peripheral events within the causal event unit that have temporal triggering, resource dependency, execution coupling, or state linkage relationships with the core event. The term "causal dependency chain" refers to the ordered event chain formed by organizing the core events and related events within the causal event unit according to their actual causal triggering order, resource dependency relationships, and execution coupling logic. The term "kernel context scenario" refers to the Linux kernel running context corresponding to each event in the causal event unit, including key environmental information such as process PID / thread TID, kernel / user mode execution state, register state, resource handles, lock holding and releasing states, and the kernel subsystem running environment.

[0163] Furthermore, by using the event marking rules of the kernel full-link tracing tool and combining them with the classification of kernel core subsystems, filtering conditions can be automatically or manually set to filter out critical Linux kernel runtime events in the critical event stream. Then, using a time-series sliding window and event correlation algorithm, isolated events without causal correlation are eliminated, extracting causal event units with a basis for causal correlation. By calculating the kernel impact weight and trigger propagation range of events, core events within the causal event units are identified, and related events strongly correlated with core events are matched based on event time stamps and resource association IDs, forming a core-related event set. Finally, a causal tracing algorithm is used to analyze the time-series triggering relationship and kernel resource dependency logic of the core-related event set. A hierarchical causal dependency chain is identified. Simultaneously, by parsing raw data collected from kernel tracing, kernel context information at the time of each event is extracted and bound to causal event units. Corresponding kernel context scenarios are then defined based on kernel subsystem types and execution scenarios. Using a directed graph model based on graph theory, each event in the causal dependency chain is mapped to a node in the directed graph, and kernel context attribute labels are assigned to the nodes. Causal relationships between events are mapped to directed edges, and the dependency types of the edges are labeled. Cross-unit fusion and correlation analysis are performed on the causal dependency chains of multiple sets of causal event units to complete the indirect causal relationships between events. Finally, a global, hierarchical Linux kernel causal network graph is constructed. For example, for the Linux kernel O... Analyzing the key event stream of OM (Out of Memory) exceptions, we identified critical runtime events such as process memory allocation, page fault interruption, physical page allocation, memory reclamation, and OOMKiller triggering. We extracted the causal event unit centered on "OOM exception triggering." Within this unit, we identified "process mmap requesting anonymous memory" (a triggering core event) and "OOMKiller triggering process termination" (a result-oriented core event) as the core events. Corresponding related events include "page fault interruption triggering," "buddy system physical page allocation failure," "kswapd memory reclamation process timeout," and "kernel memory threshold detection triggering." The causal dependency chain was analyzed as follows: process mmap requesting anonymous memory... → Page fault interrupt triggered → buddy system physical page allocation failure → kswapd memory reclamation timeout → kernel memory threshold detection triggered → OOMKiller triggers process termination, and the kernel context scenario of this unit is "anonymous memory request scenario of user-mode process PID1234 under the memory management subsystem"; a directed graph is constructed based on this causal dependency chain, with each event as a node and labeled with attributes such as process PID and execution status, and the causal relationship between events as directed edges labeled with "triggering" dependency. At the same time, other related events of this process and the kernel memory management subsystem are integrated, and finally the causal dependency chain of this OOM exception is highlighted in the causal network graph, and the corresponding kernel context scenario information is labeled for the nodes.

[0164] The post-configuration integration module 105 is used to analyze the business role identifier and hardware baseline performance of the client to be deployed when the deployment progress status is complete, determine the post-configuration content of the client to be deployed, and perform system integration operations on the client to be deployed according to the post-configuration content to obtain a lightweight business-ready system for the client to be deployed.

[0165] This invention analyzes the business role identifier and hardware baseline performance of the client to be deployed when the deployment progress status is "complete" to determine the post-configuration content of the client. This allows for an accurate understanding of business requirements and full utilization of hardware capabilities. Based on the post-configuration content, system integration operations are performed on the client to be deployed, automatically adapting and integrating necessary functional components to obtain a lightweight, business-ready system for the client to be deployed. The business role identifier and hardware baseline performance are respectively the core business characteristics and basic physical performance of the client to be deployed; the post-configuration content is a list of software and hardware integration and functional configurations determined by the client to be deployed based on the analysis of the business role identifier and hardware baseline performance; and the lightweight, business-ready system is a final system that precisely matches the business role and hardware performance and can be directly put into use, obtained by performing system integration operations on the client to be deployed based on the post-configuration content.

[0166] Furthermore, when the deployment progress status is complete, the business role identifier and hardware baseline performance of the client to be deployed are analyzed by comparing the business role identifier with the preset role library and parsing the hardware baseline performance and minimum requirement list. Then, based on the matching result between the necessity of the business operation and the support of the hardware capability, the post-configuration content of the client to be deployed is determined.

[0167] Furthermore, based on the post-configuration content, the system integration operation of the client to be deployed is performed to obtain a lightweight business-ready system for the client to be deployed. By loading business components on demand and automatically injecting the runtime environment, the general basic system is transformed into a specific instance that only contains necessary services and is configured and topologically ready, thereby obtaining a lightweight business-ready system.

[0168] like Figure 3 The diagram shown is a flowchart illustrating an automated batch deployment and integration initial configuration method based on PXE provided in an embodiment of the present invention. In this embodiment, the automated batch deployment and integration initial configuration method based on PXE includes:

[0169] S1. Collect the PXE boot request information and hardware characteristic information of the client to be deployed, and extract the client's MAC address and network configuration parameters from the PXE boot request information;

[0170] S2. After determining the Linux kernel loading requirements and driver installation requirements corresponding to the client to be deployed by combining the MAC address and the hardware feature information, determine the operating system installation parameters required for the client to be deployed, and monitor the intranet server connection status of the client to be deployed based on the network configuration parameters.

[0171] S3. Obtain the system hardware information of the client, and formulate a disk partitioning scheme for the client to be deployed based on the system hardware information;

[0172] S4. Combining the operating system installation parameters, the intranet server connection status, and the disk partitioning scheme, after pulling the operating system image of the client to be deployed from the intranet server, the automated deployment configuration of the client to be deployed is executed using the preset response file, and the deployment stage information of the client to be deployed is recorded. Based on the deployment stage information, the deployment progress status of the Linux kernel is analyzed.

[0173] S5. When the deployment progress status is completed, analyze the business role identifier and hardware baseline performance of the client to be deployed, determine the post-configuration content of the client to be deployed, and perform system integration operations on the client to be deployed according to the post-configuration content to obtain a lightweight business-ready system for the client to be deployed.

[0174] In the several embodiments provided by this invention, it should be understood that the provided systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0175] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0176] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A PXE-based automated batch deployment and integration commissioning configuration system, characterized in that, The PXE-based automated batch deployment and integration commissioning configuration system includes: The PXE information acquisition module is used to collect PXE startup request information and hardware characteristic information of the client to be deployed, and extract the client's MAC address and network configuration parameters from the PXE startup request information. The deployment requirement monitoring module is used to combine the MAC address and the hardware feature information to determine the Linux kernel loading requirements and driver installation requirements of the client to be deployed, then determine the operating system installation parameters required by the client to be deployed, and monitor the intranet server connection status of the client to be deployed based on the network configuration parameters. The disk partitioning planning module is used to obtain the client's system hardware information and, based on the system hardware information, formulate a disk partitioning scheme for the client to be deployed. The system image deployment module is used to combine the operating system installation parameters, the intranet server connection status and the disk partitioning scheme, pull the operating system image of the client to be deployed from the intranet server, execute the automated deployment configuration of the client to be deployed using the preset response file, record the deployment stage information of the client to be deployed, and analyze the deployment progress status of the Linux kernel based on the deployment stage information. The post-configuration integration module is used to analyze the business role identifier and hardware baseline performance of the client to be deployed when the deployment progress status is complete, determine the post-configuration content of the client to be deployed, and perform system integration operations on the client to be deployed according to the post-configuration content to obtain a lightweight business-ready system for the client to be deployed.

2. The PXE-based automated batch deployment and integration commissioning configuration system as described in claim 1, characterized in that, After determining the Linux kernel loading requirements and driver installation requirements for the client to be deployed by combining the MAC address and the hardware characteristic information, the process includes: Extract the hardware component identifier from the hardware feature information, associate the MAC address with the hardware component identifier, and obtain the hardware configuration profile; Based on the hardware configuration file, the kernel loading configuration and driver module configuration of the client to be deployed are determined from the preset kernel driver support rule base; Analyze the multidimensional dependencies between the kernel loading configuration and the driver module configuration, and detect compatibility conflicts between the kernel loading configuration and the driver module configuration; Based on the multidimensional dependencies and compatibility conflicts, the Linux kernel loading requirements and driver installation requirements for the client to be deployed are determined from the kernel loading configuration and the driver module configuration.

3. The PXE-based automated batch deployment and integration commissioning configuration system as described in claim 2, characterized in that, The detection of compatibility conflicts between the kernel loading configuration and the driver module configuration includes: Extract the resource allocation information set and version identifier set from the kernel loading configuration and the driver module configuration; Based on the resource allocation information set, calculate the resource conflict rate between the kernel loading configuration and the driver module configuration; Based on the set of version identifiers, calculate the version matching degree between the kernel loading configuration and the driver module configuration; Combining the resource conflict rate and the version matching degree, the compatibility conflict coefficient between the kernel loading configuration and the driver module configuration is calculated using the following formula: Where C represents the compatibility conflict coefficient between the kernel loading configuration and the driver module configuration. V represents the resource conflict rate, and V represents the version compatibility. Indicates sensitivity to resource conflicts. Indicates version matching sensitivity; Based on the compatibility conflict coefficient, the compatibility conflict between the kernel loading configuration and the driver module configuration is determined.

4. The PXE-based automated batch deployment and integration commissioning configuration system as described in claim 3, characterized in that, The calculation of the resource conflict rate between the kernel loading configuration and the driver module configuration based on the resource allocation information set includes: Extract the kernel resource allocation information and driver resource allocation information from the resource allocation information set; Identify the allocation resource identifiers corresponding to the kernel allocation resource information and the driver resource allocation information, and based on the allocation resource identifiers, count the overlapping resource items in the kernel allocation resource information and the driver resource allocation information; The number of overlapping resource items and the number of driving resource items are counted separately to obtain the number of overlapping resource items and the number of driving resource items, and the conflict severity score corresponding to the overlapping resource items is assigned. Combining the number of overlapping resource items, the number of driver resource items, and the conflict severity score, the resource conflict rate between the kernel loading configuration and the driver module configuration is calculated using the following formula: Where R represents the resource conflict rate between the kernel loading configuration and the driver module configuration. This represents the conflict severity score corresponding to the i-th overlapping resource item. Indicates the number of overlapping resource items. This represents the number of driving resource items, where i represents the sequence number corresponding to the overlapping resource item.

5. The PXE-based automated batch deployment and integration commissioning configuration system as described in claim 1, characterized in that, The step of formulating a disk partitioning scheme for the client to be deployed based on the system hardware information includes: Identify the storage device capacity entries and recording time points in the system hardware information, and sort the storage device capacity entries according to the recording time points to obtain the recording time-series capacity; Query the pre-defined client task types and extract the basic space allocation corresponding to the client task types; Obtain the physical interface standard and health status of the storage device corresponding to the system hardware information, and determine the interface speed efficiency of the client's storage device based on the physical interface standard; Calculate the health reliability value of the client's storage device; Combining the recorded timing capacity, the interface speed efficiency, the health reliability value, the identifier health, and the basic space allocation, the available space equivalent of the storage device is calculated using the following formula: in, This represents the available space equivalent of the storage device. This represents the record timing capacity of the j-th storage device. Indicates the physical interface standard of the j-th storage device. Interface speed efficiency This represents the health status of the j-th storage device, where j represents the number of storage devices and m represents the total number of storage devices. The indicated allocation ratio; Based on the available space equivalent, a disk partitioning scheme for the client to be deployed is formulated.

6. The PXE-based automated batch deployment and integration commissioning configuration system as described in claim 5, characterized in that, The calculation of the health reliability value of the client's storage device includes: Query the historical operation records of the storage device and extract the operation failure records from the historical operation records; Based on the operational failure records, calculate the current expected stability of the storage device; Extract the health monitoring indicators of the storage device, and calculate the state deviation of the storage device based on the health monitoring indicators; Based on the current expected stability and the state deviation, calculate the health reliability value of the client's storage device.

7. The PXE-based automated batch deployment and integration commissioning configuration system as described in claim 6, characterized in that, The calculation of the current expected stability of the storage device based on the operational failure records includes: Count the cumulative number of occurrences of the recorded operational faults within a preset period; Identify the fault type and faulty component in the operational fault record, and assign a fault impact coefficient corresponding to the fault type based on the faulty component; Obtain the total effective operating time of the storage device corresponding to the operating fault record; Combining the cumulative number of occurrences, the fault impact coefficient, and the total effective operating time, the current expected stability of the storage device is calculated using the following formula: in, This indicates that the storage device is currently expected to remain stable. Indicates the cumulative number of occurrences. Indicates the fault impact coefficient. This indicates the total effective running time.

8. The PXE-based automated batch deployment and integration commissioning configuration system as described in claim 1, characterized in that, The analysis of the Linux kernel deployment progress status based on the deployment phase information includes: Extract the key event streams related to the anomalies from the deployment phase information; Based on the aforementioned key event stream, a causal network graph of the Linux kernel is constructed. Identify the key root cause nodes in the causal network graph, and analyze the node deployment progress of the key root cause nodes based on the key event flow; Based on the deployment progress of the nodes, analyze the deployment progress status of the Linux kernel.

9. The PXE-based automated batch deployment and integration commissioning configuration system as described in claim 8, characterized in that, The construction of the causal network graph of the Linux kernel based on the key event stream includes: Filter the critical events related to the Linux kernel in the critical event stream, and extract the causal event units from the critical events. Identify the core events and their corresponding related events within the causal event unit; Based on the associated events and the core events, the causal dependency chain and kernel context scenario of the causal event unit are analyzed. Based on the causal dependency chain and the kernel context scenario, a causal network graph of the Linux kernel is constructed.

10. A method for automated batch deployment and integrated initial configuration based on PXE, characterized in that, The method includes: Collect PXE boot request information and hardware characteristic information of the client to be deployed, and extract the client's MAC address and network configuration parameters from the PXE boot request information; After determining the Linux kernel loading requirements and driver installation requirements for the client to be deployed by combining the MAC address and the hardware feature information, the operating system installation parameters required for the client to be deployed are determined, and the intranet server connection status of the client to be deployed is monitored based on the network configuration parameters. Obtain the client's system hardware information, and based on the system hardware information, formulate a disk partitioning scheme for the client to be deployed; Combining the operating system installation parameters, the intranet server connection status, and the disk partitioning scheme, after pulling the operating system image of the client to be deployed from the intranet server, the automated deployment configuration of the client to be deployed is executed using a preset response file, and the deployment stage information of the client to be deployed is recorded. Based on the deployment stage information, the deployment progress status of the Linux kernel is analyzed. When the deployment progress status is complete, the business role identifier and hardware baseline performance of the client to be deployed are analyzed to determine the post-configuration content of the client to be deployed. Based on the post-configuration content, the system integration operation of the client to be deployed is performed to obtain the lightweight business-ready system of the client to be deployed.

Images