Pre-boot execution environment boot time optimization method and program product

Abstract

The present application discloses a method and program product for optimizing the boot time of a pre-boot execution environment, comprising: receiving a broadcast message from a target client to allocate a temporary IP address and a lightweight boot file path; after receiving a request message, optimizing the initial lightweight boot file to obtain a lightweight boot file; after receiving a unicast message, allocating a final IP address, allocating system files to the target client according to a corresponding target block size, and determining the target client's feedback information according to a corresponding target window configuration to optimize the boot time of the pre-boot execution environment of the target client. This solves the problem in related technologies that traditional PXE relies on a single DHCP server and physical network connectivity, resulting in increased latency and low transmission efficiency. This method achieves the technical effect of upgrading DHCP interaction from traditional broadcast dependence to intelligent unicast negotiation, reducing data transmission latency, improving file transmission efficiency, and reducing the boot time of the pre-boot execution environment.

Description

Technical Field

[0001] The present application relates to the field of electronic manufacturing technology, and in particular to a method for optimizing the boot time of a pre-boot execution environment and a program product. Background Art

[0002] During the R&D process, operating system installation is often necessary. However, sometimes the machines being maintained aren't just one or two; instead, a large number of servers may need installation. Manually installing the operating system on these numerous machines one by one would likely consume the majority of the time. Therefore, a PXE (preboot execute environment) server is typically set up to deploy operating systems in batches over the network.

[0003] In related technologies, PXE technology is a network model that operates between a server and a client, enabling the client to download an image from the server over the network, thereby supporting the booting of an operating system from the network. The PXE server acts as the server, and the device requiring the operating system installation acts as the client. During the boot process, the client requests an IP address from the server. It then uses TFTP (trivial file transfer protocol) or MTFTP (multicast trivial file transfer protocol) to download a boot package to local memory and execute it. This boot package completes the client's basic software setup, booting the operating system pre-installed on the server.

[0004] However, in related technologies, traditional PXE relies on a single DHCP (Dynamic Host Configuration Protocol) server. In cross-subnet or relay scenarios, DHCP requests need to be relayed multiple times, which will increase latency. In addition, the global DHCP configuration cannot dynamically adapt to the needs of different clients, which can easily cause IP conflicts or configuration errors. On the other hand, it relies on physical network connectivity and requires complex DHCP relay and routing configuration in cross-VLAN (Virtual Local Area Network) or wide area network scenarios, making it difficult to achieve flexible deployment. At the same time, TFTP transmission efficiency is also low due to the use of a fixed byte block size, which needs to be urgently addressed. Summary of the Invention

[0005] The present application provides a method and program product for optimizing the boot time of a pre-boot execution environment, which aims to at least address the problems in the related art, namely, that traditional PXE relies on a single DHCP server and physical network connectivity, which increases latency in cross-subnet or relay scenarios, is unable to dynamically adapt to different client requirements, is prone to causing IP conflicts or configuration errors, is difficult to achieve flexible deployment in cross-VLAN or wide area network scenarios, and suffers from low TFTP transmission efficiency.

[0006] The present application provides a method for optimizing the boot time of a pre-boot execution environment, comprising the following steps: receiving a broadcast message carrying a pre-boot execution environment identifier sent by a target client, and allocating a temporary IP address and a lightweight boot file path of the target client based on the broadcast message; after receiving a request message sent by the target client, allocating an initial lightweight boot file in the lightweight boot file path to the target client based on the temporary IP address, and optimizing the initial lightweight boot file to obtain a lightweight boot file that meets the target file capacity after optimization; after receiving a unicast message sent by the target client, allocating a final IP address of the target client according to the unicast message, and allocating the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, and determining feedback information of the target client according to the target window configuration corresponding to the target block size, so as to optimize the pre-boot execution environment boot time of the target client until the pre-boot execution environment boot time is within a preset time interval.

[0007] The present application also provides a computer program product, comprising: an allocation module, configured to receive a broadcast message sent by a target client carrying a pre-boot execution environment identifier, and to allocate a temporary IP address and a lightweight boot file path of the target client based on the broadcast message; a first optimization module, configured to allocate an initial lightweight boot file in the lightweight boot file path to the target client based on the temporary IP address after receiving a request message sent by the target client, and to optimize the initial lightweight boot file to obtain a lightweight boot file that meets the target file capacity after optimization; a second optimization module, configured to allocate a final IP address of the target client according to the unicast message after receiving a unicast message sent by the target client, and to allocate the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, and to determine feedback information of the target client according to the target window configuration corresponding to the target block size, so as to optimize the pre-boot execution environment boot time of the target client until the pre-boot execution environment boot time is within a preset time interval.

[0008] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing any of the steps of the above-mentioned pre-boot execution environment boot time optimization method when executing the computer program.

[0009] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned pre-boot execution environment boot time optimization methods are implemented.

[0010] Through this application, after allocating a temporary IP address and a lightweight boot file path to the target client, the initial lightweight boot file can be optimized, and the target client is required to make a second unicast DHCP request. Then, the system file is allocated to the target client according to the target block size, thereby optimizing the pre-boot execution environment boot time. Therefore, it can solve the problem in the related art that traditional PXE relies on a single DHCP server and physical network connectivity, which increases latency in cross-subnet or relay scenarios, cannot dynamically adapt to different client requirements, easily causes IP conflicts or configuration errors, is difficult to achieve flexible deployment in cross-VLAN or wide area network scenarios, and has low TFTP transmission efficiency. The technical effect of upgrading DHCP interaction from traditional broadcast dependence to intelligent unicast negotiation through a secondary DHCP request mechanism and a dynamic IP pre-allocation strategy is achieved, reducing data transmission delays, optimizing the transmission method and transmission path of system files through strategies such as dynamic block adjustment and window mechanism, effectively improving file transmission efficiency, and reducing the pre-boot execution environment boot time. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 A flowchart of a method for optimizing boot time of a pre-boot execution environment provided according to an embodiment of the present application;

[0013] Figure 2 A block diagram of a computer program product provided according to an embodiment of the present application;

[0014] Reference numerals:

[0015] Among them, 10-computer program product; 100-allocation module, 200-first optimization module, 300-second optimization module. DETAILED DESCRIPTION

[0016] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0017] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0018] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0019] An embodiment of the present application provides a method for optimizing the boot time of a pre-boot execution environment. The method is described in detail in conjunction with the execution flow of the method for optimizing the boot time of a pre-boot execution environment.

[0020] Before explaining the method for optimizing the boot time of the pre-boot execution environment in the embodiment of the present application, in order to better understand the embodiment of the present application, the core process of the PXE boot process is first explained. The core process of the PXE boot process can be, but is not limited to, as follows:

[0021] 1. Hardware startup: After the client is turned on, the PXE firmware in the network card ROM is activated and the network device is initialized (such as obtaining the MAC address);

[0022] 2. Broadcast DHCP Discover message (discovery message): The client broadcasts a DHCP Discover message using UDP (User Datagram Protocol). This message carries the PXE identifier to request network configuration and boot information.

[0023] 3. DHCP server response: The DHCP server responds to the DHCP Offer message (provided message), provides a temporary IP address, and specifies the TFTP server address, boot file name, etc.

[0024] 4. Client confirms the lease: The client sends a DHCP Request message to confirm the lease, and the DHCP server replies with a DHCP Ack message to complete the IP allocation.

[0025] 5. Download and execute the boot program: The client downloads the boot file from the server through the TFTP protocol. If it fails, the client can retry (usually 3 times);

[0026] 6. Load boot configuration: The boot client program reads the configuration file on the TFTP server and guides the client to continue downloading the kernel file and initramfs (Initial RAM Filesystem, a temporary root file system) according to the configuration (such as initrd.img (Initial RAM Disk Image), a temporary root file system image used during the Linux system startup process) through TFTP or HTTP (Hypertext Transfer Protocol).

[0027] 7. Network mounted root file system: After the kernel starts, the remote root file system is mounted according to the configuration of initramfs;

[0028] 8. Operating system startup: Execute the init (Initialization Process) process, the kernel loads the temporary root file system in initramfs, starts the / init script, and completes hardware detection and driver loading.

[0029] Specifically, Figure 1 The present invention provides a flowchart of a method for optimizing boot time of a pre-boot execution environment according to an embodiment of the present application.

[0030] like Figure 1 As shown, the pre-boot execution environment boot time optimization method includes the following steps:

[0031] In step S101, a broadcast message carrying a pre-boot execution environment identifier sent by a target client is received, so as to allocate a temporary IP address and a lightweight boot file path of the target client based on the broadcast message.

[0032] It's understood that the target client here refers to the target device that needs to install an operating system. The broadcast message here can be understood as the standard DHCP Discover message broadcast by a client (such as a computer without a hard drive or a thin client) when requesting an IP address when it first connects to the network.

[0033] In some embodiments, when a target client wants to install an operating system using PXE technology, it will broadcast a standard DHCP Discover message to find a DHCP server so that the server can return special configurations (such as TFTP server address, boot program path, etc.).

[0034] Based on this, after receiving the broadcast message carrying the PXE identifier (Pre-boot Execution Environment identifier) ​​sent by the target client, the server in the embodiment of the present application will return a DHCP Offer message (offer message), and then assign a temporary IP address and basic network parameters (such as subnet mask, gateway) to the target client, and assign a specified lightweight boot file path.

[0035] The PXE identifier can be understood as an additional statement added by the target client when broadcasting a standard DHCP Discover message, indicating that the target client itself is a device that needs to be booted from the network, rather than an ordinary terminal.

[0036] The temporary IP address here refers to a temporary IP address obtained by the target client through DHCP to facilitate communication with the server when PXE is started but the operating system has not yet been loaded. Therefore, this IP is usually short-term and can be assigned by the DHCP server or the PXE server.

[0037] The lightweight boot file path here refers to the TFTP directory address on the server of the lightweight boot file (such as pxelinux.0, grubx64.efi, or bootmgfw.efi) that the client needs to download after obtaining a temporary IP address to initialize the operating system and load the operating system kernel. The client can download the lightweight boot file through this path.

[0038] The embodiment of the present application can receive a broadcast message carrying a PXE identifier sent by a target client, avoid communicating with the target client that does not have the requirement to install an operating system through PXE technology, and allocate a temporary IP address and a lightweight boot file path to it.

[0039] Step S102, after receiving the request message sent by the target client, the initial lightweight boot file in the lightweight boot file path is allocated to the target client based on the temporary IP address, and the initial lightweight boot file is optimized to obtain an optimized lightweight boot file that meets the target file capacity.

[0040] In some embodiments, after the target client broadcasts (sends) a standard DHCP Discover message, and the server responds with a DHCP Offer message, providing a temporary IP address, a lightweight boot file path for basic network parameters, and other content, the target client will then return a DHCP Request message after receiving the response, i.e., a request message in the embodiments of the present application, to confirm the lease between the two.

[0041] Then, after receiving the request message sent by the target client, the server will reply with a DHCP Ack message, completing the first interaction with the target client.

[0042] The target client can then download the initial lightweight boot file from the lightweight boot file path via TFTP based on the temporary IP address, thereby completing the distribution of the initial lightweight boot file from the lightweight boot file path to the target client for subsequent boot operations. The initial lightweight boot file includes, but is not limited to, a lightweight network driver and a speed measurement module.

[0043] Furthermore, in order to reduce the PXE boot time (pre-boot execution environment boot time) in subsequent processes and avoid unnecessary resource occupation, the embodiment of the present application can optimize the initial lightweight boot file to obtain a lightweight boot file that meets the target file capacity after optimization.

[0044] The target file size here refers to the expected size range of an optimized lightweight boot file. For example, the optimized lightweight boot file should be within 100KB. Because the target client has limited memory (usually only a few MB) during initial boot, loading large files should be avoided. Furthermore, the TFTP protocol is typically implemented over UDP, which is less efficient. Smaller files are more reliable.

[0045] It should be noted that the specific target file capacity can be set or adjusted by professional and technical personnel in this technical field according to actual conditions or actual needs. The embodiments of this application are only for illustrative purposes and are not specifically limited.

[0046] The embodiment of the present application can reply to the message after receiving the request message sent by the target client to allow the target client to download the initial lightweight boot file in the lightweight boot file path, and then optimize the initial lightweight boot file to obtain a lightweight boot file that meets the target file capacity, thereby reducing the capacity and resource occupation of the lightweight boot file, which helps to reduce the PXE boot time.

[0047] Optionally, in one embodiment of the present application, the initial lightweight boot file is optimized to obtain a lightweight boot file that meets the target file capacity after optimization, including: according to the necessity of the file driver of the initial lightweight boot file, removing unnecessary drivers of the initial lightweight boot file to optimize the initial lightweight boot file and obtain a lightweight boot file.

[0048] During the actual implementation process, when optimizing the initial lightweight boot file, this application can, but is not limited to, remove non-essential drivers in the initial lightweight boot file based on the necessity of the file driver of the initial lightweight boot file, retain only the basic network functions of the file, and control the size of the file within a certain file capacity (such as 100KB) to obtain a lightweight boot file that meets the target file capacity in this application.

[0049] Among them, when removing non-essential drivers in the initial lightweight boot file, it can be achieved, but not limited to, by the developer of the initial lightweight boot file or the system administrator through the server during the compilation stage or the configuration stage. For example, non-essential driver modules can be disabled through configuration parameters during server compilation, and the file size can be controlled through compiler optimization and binary trimming.

[0050] It should be noted that the specific optimization method of the initial lightweight boot file can be experimentally set by professional and technical personnel in this technical field according to actual conditions or actual needs or selected from existing technologies. The embodiments of this application are only for illustrative purposes and are not specifically limited.

[0051] The embodiments of the present application can optimize non-essential drivers in the initial lightweight boot file, reduce initialization time, and limit its file capacity, so that the optimized lightweight boot file meets the target file capacity requirements, can better adapt to the PXE environment restrictions, and thus improve startup efficiency and reliability.

[0052] In step S103, after receiving the unicast message sent by the target client, the final IP address of the target client is allocated according to the unicast message, and the system files of the target client are allocated to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, and the feedback information of the target client is determined according to the target window configuration corresponding to the target block size, so as to optimize the pre-boot execution environment boot time of the target client until the pre-boot execution environment boot time is within the preset time interval.

[0053] As a possible implementation method, after obtaining a lightweight boot file that meets the target file capacity, the embodiment of the present application can enable the target client to initiate a secondary unicast message to the server in the form of unicast to request the final IP address to download system files, etc.

[0054] For example, after obtaining a lightweight boot file that meets the target file capacity, the target client will directly send a secondary unicast request message (essentially still a DHCP Request message) to the PXE server (fixed IP: 10.0.0.200). The message includes but is not limited to information such as MAC address, hardware architecture (x86 / ARM), boot mode (UEFI / Legacy) and real-time network bandwidth (which can be obtained through the speed measurement module).

[0055] Based on the target client's information, the PXE server selects the optimal IP address from the pre-allocated IP pool and assigns it to the target client as the final IP address. The pre-allocated IP pool refers to the IP range (e.g., 10.0.0.150-10.0.0.200) that the PXE server has pre-leased from the primary DHCP server. The server maintains lease status with the primary DHCP server through an in-memory database, thus avoiding conflicts with the primary DHCP server.

[0056] Furthermore, after the server determines the final IP address, it can allocate the system files required by the target client to the final IP address.

[0057] For example, the target client can first download a configuration file from the final IP address. Then, the boot program in the lightweight boot file will read the configuration file to guide the target client to download kernel files (such as vmlinuz, Linux kernel image files), initramfs (such as initrd.img, initialized memory file system) and other system files through TFTP or HTTP, thereby completing the distribution of system files required by the target client to the target client.

[0058] The process of allocating system files is essentially data transmission. To effectively improve the transmission efficiency of system files, embodiments of the present application can transmit system files from the server to the client according to the corresponding target block size. The target block size can be understood as the size of a single data block (e.g., 512B, 8KB, 64KB, etc.) used when transmitting the same file or different files.

[0059] Furthermore, when downloading system files, users will feedback their data reception information to the server according to a certain declared window. To reduce the server's waiting time for this feedback information, embodiments of the present application may, but are not limited to, determine the target client's feedback information based on a target window configuration corresponding to the target block size. The target window configuration herein can be understood as a declared window size configuration that is dynamically adjusted based on the target block size.

[0060] That is, the embodiment of the present application can determine different declaration window sizes according to the target block size of the system file, and when a certain declaration window is reached, it interacts with the target client to determine the data transmission status and data reception information of the target client, avoiding continuously waiting for feedback from the target client.

[0061] Therefore, the embodiment of the present application can ensure address uniqueness through pre-allocated IP pool and ARP conflict detection, and transmit different system files through different target block sizes, reducing the time consumption caused by fixed block byte transmission when dividing large files and small files into data blocks, and interacting with the target client in a timely manner according to the target window configuration corresponding to the target block size, reducing data delay, thereby achieving the technical effect of optimizing the PXE boot time of the target client until the PXE boot time is within the preset time interval.

[0062] It should be noted that the preset time interval here does not specifically refer to a specific time interval, but refers to the time interval reached by the optimized pre-boot execution environment boot time.

[0063] The embodiments of the present application can upgrade DHCP interaction from traditional broadcast dependence to intelligent unicast negotiation through a secondary DHCP request mechanism and a dynamic IP pre-allocation strategy, effectively reducing data latency. Combined with TFTP optimization (dynamic adjustment and optimization of target block size and target window configuration) and multi-architecture adaptation, a complete PXE efficient boot system is formed.

[0064] Optionally, in one embodiment of the present application, before allocating the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, it also includes: collecting the real-time communication network bandwidth of the target client; determining the target block size and target window configuration corresponding to the system file based on the real-time communication network bandwidth.

[0065] During actual execution, when determining the target block size and target window configuration corresponding to the system file, the present application may be implemented by, but is not limited to, dynamically adjusting the block size according to the real-time communication network bandwidth of the target client.

[0066] For example, this application can negotiate the block size (blksize) with the server through TFTP Option Negotiation (a function for Trivial File Transfer Protocol (TFTP) defined in RFC 2347) when the target client initiates a request, and dynamically adjust the block size (e.g., 512B~64KB) according to the real-time network bandwidth.

[0067] For example, Table 1 is a recommended table of block size (target block size) and declared window size (target window configuration) corresponding to network bandwidth in one embodiment of the present application, which can be expressed as follows:

[0068] Table 1

[0069]

[0070] It should be noted that the network bandwidth and the corresponding block size and declaration window size in Table 1 are only obtained based on certain experiments in the embodiments of this application. In actual application, they can be set or adjusted by professional and technical personnel in this technical field according to actual conditions. They are only used for illustrative purposes in the embodiments of this application and are not specifically limited.

[0071] Thus, embodiments of the present application can configure the client's declared window size, allowing the server to continuously send multiple data blocks before waiting for cumulative ACKs. For example, if the server continuously sends DATA 1, DATA 2, DATA 3, and DATA 4, there is no need to wait for a client ACK. When the window size reaches 4, the client responds with ACK 4, acknowledging receipt of blocks 1-4. Thereafter, the server continuously sends DATA 5, DATA 6, DATA 7, and DATA 8.

[0072] The embodiment of the present application can dynamically adjust the block size and the declared window size through the real-time communication network bandwidth of the target client, so that the TFTP protocol can adapt to the characteristics of different network environments: large blocks are used to reduce interactions in high bandwidth, and small blocks are used to ensure reliability in low bandwidth, ultimately achieving on-demand optimized system file transfer and balancing transmission efficiency and reliability.

[0073] Optionally, in one embodiment of the present application, the final IP address of the target client is allocated according to the unicast message, so that the system files of the target client are allocated to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, including: obtaining the hardware characteristics and network status of the target client based on the unicast message; generating the final IP address and transmission parameters of the system files based on the hardware characteristics and network status of the target client; and allocating the system files to the target client according to the corresponding target block size in combination with the final IP address and the transmission parameters.

[0074] It's understood that hardware features here refer to the target client's hardware attributes, such as CPU model, memory size, storage interface type (e.g., SSD / HDD), and network card model. Network status here refers to the target client's network environment parameters, such as real-time bandwidth, latency, packet loss rate, and network type (e.g., LAN / wireless). Transfer parameters here refer to file transfer configuration items, such as block size (blksize), timeout retransmission period, and optimized parameters for transfer protocols (e.g., TFTP).

[0075] In certain embodiments, in the process of allocating the final IP address and system files, in addition to negotiating the block size and declaring the window size, the present application can also obtain the hardware characteristics and network status of the target client based on the unicast message, so as to generate the final IP address and the transmission parameters of the system files based on this information, so as to allocate the system files to the target client according to the corresponding target block size in combination with the final IP address and the transmission parameters.

[0076] Take the startup process of a diskless workstation (target client) as an example:

[0077] First, obtain the target server's information: the server detects that the workstation's hardware features are "quad-core CPU, 4GB memory, Gigabit network card", and the network status is "LAN environment, real-time bandwidth 100Mbps, delay 1ms, packet loss rate 0%".

[0078] Based on the target client's information, along with its hardware (a Gigabit network card supports high-speed transmission) and network status (high bandwidth and low latency), the server assigns the final IP address "192.168.1.100" and generates transfer parameters with a 4KB block size (to reduce round-trips) and a 500ms timeout (to minimize latency). Finally, the server splits system files (such as vmlinuz and initrd.img) into 4KB blocks and sends them to the workstation (target client) via the final IP address, completing the file transfer.

[0079] The embodiments of the present application can dynamically generate IP addresses and transmission parameters by combining client hardware characteristics and network status, so that the file transfer process can avoid hardware performance waste (such as using large blocks on a low-speed network card resulting in transmission failure) and maximize the use of network resources (such as using large blocks to improve efficiency under high bandwidth), ultimately improving the stability, speed and resource utilization of system file transfers, and reducing the boot time of the pre-boot execution environment.

[0080] Optionally, in one embodiment of the present application, the system files of the target client are allocated to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, including: obtaining the historical access frequency of each file in the system file; based on the historical access frequency of each file, transferring the files whose historical access frequency meets the target frequency range from the original disk to the target memory path; and allocating the system files from the target memory path to the target client according to the corresponding target block size.

[0081] In traditional TFTP servers, boot files are stored on the server's hard drive (or SSD). When clients are downloading files concurrently, the server needs to frequently read files from disk. However, disk I / O speeds are typically much slower than memory, easily becoming a bottleneck. For example, in a PXE boot process, pxelinux.0 (the bootloader) and grubx64.efi (the UEFI bootloader) are essential files that all clients download and are frequently accessed.

[0082] In certain embodiments, in order to avoid disk I / O bottlenecks, the present application can obtain the historical access frequency of each file in the system files when the service (operating system installation task) is started, thereby transferring the files whose historical access frequency meets the target frequency range from the original disk to the target memory path, that is, when the service is started, the high-frequency access files (such as pxelinux.0, grubx64.efi) are pre-loaded into the memory.

[0083] The target frequency range herein can be understood as a frequency range that can be set to define the historical access frequency of a file as a high frequency. For example, the target frequency range is 30% higher than the average access frequency of all files. The target memory path herein can be understood as the storage path of the high-frequency file in the memory after it is transferred from the disk to the memory. The specific target frequency range and target memory path can be determined by professionals in this technical field based on the actual situation of the file. This application is for illustrative purposes only and does not impose specific limitations.

[0084] Then, the embodiment of the present application can distribute the system files to the target client according to the corresponding target block size from the target memory path, that is, when the target client downloads the system files, it can directly read and write these high-frequency files from the memory.

[0085] For example, this application can mount the TFTP root directory as a memory file system (a special file system in the Linux system that does not occupy disk space but directly uses the server's memory as a storage medium. Data only exists in memory and has extremely fast read and write speeds, such as Linux tmpfs), that is, actively copying these high-frequency files to the memory file system (or directly loading them into the memory cache) to avoid reading from the disk when the client requests it for the first time (which may not have entered the memory at this time). As a result, all files transferred via TFTP (files downloaded by the target client) are read and written from memory rather than disk, thereby avoiding the input and output limitations of the disk during the file download process.

[0086] The embodiment of the present application can transfer files whose historical access frequency meets a certain frequency range from the original disk to the target memory path, so that all read and write operations of these high-frequency files are completed in the memory, greatly improving the speed, avoiding disk I / O bottlenecks, and reducing service delays.

[0087] Optionally, in one embodiment of the present application, the system files of the target client are allocated to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, including: allocating a transmission path corresponding to each file according to the size of each file; allocating each file to the target client according to the transmission path corresponding to each file, so as to complete the allocation of the system files to the target client according to the corresponding target block size.

[0088] As a possible implementation method, the embodiment of the present application can also match a corresponding transmission path for each file according to the size of each file, so as to distribute each file to the target client according to the corresponding transmission path.

[0089] For example, by using advanced boot programs such as iPXE, the present application can assign HTTP as the transmission path for large files such as kernel files in the system files, allowing the target client to download these large files via HTTP. For small files in the system files, the present application can assign TFTP as the transmission path, allowing the target client to download these small files via TFTP, thus achieving a hybrid transmission protocol using HTTP / TFTP hybrid acceleration.

[0090] This embodiment of the application can match the corresponding transmission path according to the size of each file item in the system file, assigning different transmission paths to file items of different sizes, thereby improving the file transfer rate and reducing the file transfer time. On this basis, combined with the dynamic adjustment of data block size and window configuration, the transmission efficiency of TFTP can be increased by 3-10 times, taking into account the compatibility of traditional equipment and the high-performance requirements of modern networks. It is suitable for various scenarios such as data centers and edge computing, effectively improving the applicable scenarios and practical application capabilities of this application.

[0091] Optionally, in one embodiment of the present application, it also includes: deploying multiple dynamic host configuration protocol relay agents on key network nodes of the transmission path; detecting the message type of the target client; and matching the corresponding dynamic host configuration protocol relay agent and transmission path according to the message type.

[0092] Understandably, in some large networks, the target client and DHCP server may not be on the same subnet (for example, networks on different floors or in different departments). In this case, the DHCP broadcast message sent by the target client cannot be transmitted across subnets. Therefore, a DHCP relay agent is required to receive the DHCP request from the client within the subnet (broadcast), forward it to the DHCP server across the subnet (unicast), and simultaneously receive the DHCP server's response and forward it to the target client.

[0093] In certain embodiments, the present application can deploy multiple DHCP (Dynamic Host Configuration Protocol) relay agents on key network nodes of the transmission path, and configure the VRRP protocol to achieve high availability (allowing multiple physical devices (such as multiple routers) to share a virtual IP address. The client only needs to send a request to this virtual IP, and VRRP will automatically determine which relay agent is active and let it handle the request), avoiding single point failure (once a device fails (such as power outage or hardware damage), all clients in the subnet it is responsible for will be unable to obtain IP addresses (including PXE-booted devices)).

[0094] Furthermore, after deploying multiple DHCP relay agents, the embodiment of the present application can also detect the message type of the target client, thereby matching the corresponding DHCP relay agent and transmission path according to the message type, so that different information flows can take different optimal transmission paths.

[0095] For example, the DHCP relay agent can forward PXE requests to a dedicated server based on the target client's MAC prefix or Option 60 identifier, and divert non-PXE traffic (various data transmission traffic generated in the network when starting or deploying an operating system using PXE technology) to the default path for transmission.

[0096] The embodiment of the present application deploys multiple DHCP relay agents on key network nodes on the transmission path to ensure that when one fails, another can immediately take over, avoiding single point failure. The embodiment of the present application matches the corresponding DHCP relay agent and transmission path according to the message type, allowing PXE requests and ordinary DHCP requests to go to different servers respectively, effectively improving transmission efficiency and stability.

[0097] Optionally, in one embodiment of the present application, it also includes: based on an independent controller, selecting an independent bandwidth pool for the pre-boot execution environment traffic, and encapsulating the pre-boot execution environment traffic into a corresponding virtual extended LAN data packet to determine the transmission path of the virtual extended LAN data packet based on the independent bandwidth pool; based on an independent network interface, encapsulating the pre-boot execution environment request of the target client to obtain a Hypertext Transfer Protocol Security data packet corresponding to the pre-boot execution environment request; based on an independent edge gateway, converting the Simple File Transfer Protocol request of the target client into a corresponding reverse proxy; combining the transmission path of the virtual extended LAN data packet, the Hypertext Transfer Protocol Security data packet and the reverse proxy, adjusting the transmission time of the system file to within the target transmission time range, so as to optimize the pre-boot execution environment boot time to within the target time range.

[0098] In other embodiments, the present application may further adjust the transmission path and mode of the message information and the system files, thereby optimizing the transmission time of the system files and further optimizing the PXE boot time.

[0099] Specifically, the embodiment of the present application can select an independent bandwidth pool for PXE (Pre-boot Execution Environment) traffic based on an independent controller, encapsulate the PXE traffic into corresponding VXLAN (Virtual Extended Local Area Network) data packets, and then determine the transmission path of the VXLAN data packets based on the independent bandwidth pool.

[0100] Selecting an independent bandwidth pool for PXE traffic can be understood as allocating a separate bandwidth resource pool for PXE protocol-related traffic. This ensures that this type of traffic is not squeezed out by other network traffic during transmission, ensuring the stability and efficiency of the PXE boot process.

[0101] For example, this application can leverage the real-time monitoring of the entire network status by an SDN controller (such as Open Daylight) to dynamically select the optimal path for PXE traffic, thus implementing SDN dynamic path management. Furthermore, in cross-data center scenarios, embodiments of this application can also encapsulate PXE traffic via VXLAN, using VXLAN tunnels to traverse physical isolation and overcome underlying network restrictions.

[0102] Furthermore, the embodiment of the present application can also encapsulate the PXE request of the target client based on the independent network interface to obtain the Hypertext Transfer Protocol Security data packet corresponding to the PXE request.

[0103] For example, this application can utilize the independent network interface of the server's out-of-band management card to forward PXE requests to the target server via the management network. For example, the Smart NIC communicates with the IPMI interface (Intelligent Platform Management Interface) via a PCIe (Peripheral Component Interconnect Express) channel, which can reduce the host CPU load. After receiving the PXE request, the IPMI interface encapsulates the PXE request into an HTTPS (Hypertext Transfer Protocol Secure) data packet, which is then sent to the PXE server via the management network. The PXE server responds and returns the response to the target client via the reverse path.

[0104] Furthermore, the embodiment of the present application can also deploy a gateway service at the edge node to convert the client's TFTP request into an HTTP reverse proxy, thereby improving the efficiency of large file transmission.

[0105] Therefore, after combining multiple processing methods such as determining the transmission path of VXLAN data packets based on the independent bandwidth pool of PXE traffic, encapsulating the PXE request of the target client into the corresponding HTTPS data packet, and converting the client's TFTP request into an HTTP reverse proxy, the present application can effectively improve the transmission efficiency of messages and various files, adjust the transmission time of system files to within the target transmission time range, and thereby realize the boot time of the pre-boot execution environment of the target client to within the target time range.

[0106] It should be noted that the target transmission time range here does not specifically refer to a specific time interval, but refers to the time interval reached by the optimized system file transmission time.

[0107] The embodiments of the present application can combine SDN dynamic routing, intelligent hardware penetration, edge cache distribution and other aspects to reduce the complexity of cross-network PXE deployment, and then combine network layer protocol optimization and application layer service enhancement to achieve seamless cross-VLAN, data center and hybrid cloud environments, optimize the transmission time of system files, and thus optimize the PXE boot time.

[0108] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0109] An embodiment of the present application also provides a computer program product.

[0110] Figure 2 A block diagram of a computer program product provided according to an embodiment of the present application.

[0111] like Figure 2 As shown, the computer program product 10 includes: an allocation module 100 , a first optimization module 200 and a second optimization module 300 .

[0112] The allocation module 100 is configured to receive a broadcast message carrying a pre-boot execution environment identifier sent by a target client, and allocate a temporary IP address and a lightweight boot file path of the target client based on the broadcast message.

[0113] The first optimization module 200 is used to allocate the initial lightweight boot file in the lightweight boot file path to the target client based on the temporary IP address after receiving the request message sent by the target client, and optimize the initial lightweight boot file to obtain a lightweight boot file that meets the target file capacity after optimization.

[0114] The second optimization module 300 is used to allocate the final IP address of the target client according to the unicast message after receiving the unicast message sent by the target client, allocate the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, and determine the feedback information of the target client according to the target window configuration corresponding to the target block size, so as to optimize the pre-boot execution environment boot time of the target client until the pre-boot execution environment boot time is within a preset time interval.

[0115] For descriptions of features in the embodiment corresponding to the computer program product 10, reference may be made to the relevant descriptions of the embodiment corresponding to the method for optimizing boot time of a pre-boot execution environment, which will not be described in detail here.

[0116] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps of any of the above-mentioned pre-boot execution environment boot time optimization method embodiments.

[0117] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned pre-boot execution environment boot time optimization method embodiments when running.

[0118] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0119] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of any of the above-mentioned pre-boot execution environment boot time optimization method embodiments.

[0120] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0121] The above describes in detail the method and program product for optimizing the boot time of a pre-boot execution environment provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only intended to help understand the method and core concept of this application. It should be noted that for those skilled in the art, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A method for optimizing boot time of a pre-boot execution environment, characterized in that: The following steps are involved: receiving a broadcast message carrying a pre-boot execution environment identifier sent by a target client, and allocating a temporary IP address and a lightweight boot file path of the target client based on the broadcast message; After receiving the request message sent by the target client, based on the temporary IP address, the initial lightweight boot file in the lightweight boot file path is allocated to the target client, and the initial lightweight boot file is optimized to obtain an optimized lightweight boot file that meets the target file capacity; After receiving the unicast message sent by the target client, allocating a final IP address of the target client according to the unicast message, allocating system files of the target client to the target client according to a corresponding target block size based on the lightweight boot file and the final IP address, and determining feedback information of the target client according to a target window configuration corresponding to the target block size, so as to optimize a pre-boot execution environment boot time of the target client until the pre-boot execution environment boot time falls within a preset time interval; Among them, before allocating the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, it also includes: collecting the real-time communication network bandwidth of the target client; determining the target block size corresponding to the system file and the target window configuration corresponding to the target block size based on the real-time communication network bandwidth.

2. The method according to claim 1, characterized in that The step of optimizing the initial lightweight boot file to obtain an optimized lightweight boot file that meets the target file capacity includes: According to the necessity of the file driver of the initial lightweight boot file, unnecessary drivers of the initial lightweight boot file are removed to optimize the initial lightweight boot file and obtain the lightweight boot file.

3. The method according to claim 1, characterized in that The allocating the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address includes: Obtaining a historical access frequency of each file in the system file; Based on the historical access frequency of each file, transferring the files whose historical access frequencies meet the target frequency range from the original disk to the target memory path; The system file is allocated to the target client from the target memory path according to the corresponding target block size.

4. The method according to claim 3, characterized in that The allocating the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address includes: Allocating a transmission path corresponding to each file according to the size of each file; Each file is allocated to the target client according to the transmission path corresponding to each file, so as to complete the allocation of the system file to the target client according to the corresponding target block size.

5. The method according to claim 4, characterized in that Also includes: deploying a plurality of dynamic host configuration protocol relay agents on key network nodes of the transmission path; Detecting the message type of the target client; The corresponding dynamic host configuration protocol relay agent and transmission path are matched according to the message type.

6. The method according to claim 1, wherein Also includes: Based on the independent controller, an independent bandwidth pool for pre-boot execution environment traffic is selected, and the pre-boot execution environment traffic is encapsulated into a corresponding virtual extended local area network data packet, so as to determine a transmission path for the virtual extended local area network data packet according to the independent bandwidth pool; Encapsulating the pre-boot execution environment request of the target client based on an independent network interface to obtain a Hypertext Transfer Protocol Security data packet corresponding to the pre-boot execution environment request; Based on an independent edge gateway, converting the simple file transfer protocol request of the target client into a corresponding reverse proxy; In combination with the transmission path of the virtual extended local area network data packet, the HTTP security protocol data packet and the reverse proxy, the transmission time of the system file is adjusted to within the target transmission time range to optimize the pre-boot execution environment boot time to within the target time range.

7. The method according to claim 1, characterized in that The allocating the final IP address of the target client according to the unicast message, and allocating the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, includes: Based on the unicast message, obtaining hardware characteristics and network status of the target client; Generating the final IP address and the transmission parameters of the system file based on the hardware characteristics and network status of the target client; The system file is allocated to the target client according to the corresponding target block size in combination with the final IP address and the transmission parameter.

8. A computer program product, wherein: The computer program product comprises: an allocation module, configured to receive a broadcast message carrying a pre-boot execution environment identifier sent by a target client, and allocate a temporary IP address and a lightweight boot file path of the target client based on the broadcast message; a first optimization module configured to, after receiving a request message sent by the target client, allocate the initial lightweight boot file in the lightweight boot file path to the target client based on the temporary IP address, and optimize the initial lightweight boot file to obtain an optimized lightweight boot file that meets the target file capacity; a second optimization module configured to, after receiving the unicast message sent by the target client, assign a final IP address of the target client according to the unicast message, allocate system files of the target client to the target client according to a corresponding target block size based on the lightweight boot file and the final IP address, and determine feedback information of the target client according to a target window configuration corresponding to the target block size, so as to optimize a pre-boot execution environment boot time of the target client until the pre-boot execution environment boot time falls within a preset time interval; Among them, before allocating the system files of the target client to the target client according to the corresponding target block size based on the lightweight boot file and the final IP address, it also includes: collecting the real-time communication network bandwidth of the target client; determining the target block size corresponding to the system file and the target window configuration corresponding to the target block size based on the real-time communication network bandwidth.

9. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the pre-boot execution environment boot time optimization method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the pre-boot execution environment boot time optimization method according to any one of claims 1 to 7.

Images