Startup file transmission method and device, electronic equipment and storage medium

Abstract

The invention discloses a boot file transmission method and device, electronic equipment and a storage medium, and relates to the technical field of computers.The boot file transmission method comprises the steps that under the condition that a to-be-deployed node in a network cluster is in a basic system environment, the node states of other cluster nodes are obtained, and determining the number of the peer-to-peer service nodes based on the node states of the other cluster nodes, and when the number of the peer-to-peer service nodes meets the peer-to-peer service conditions, indicating that there are enough nodes in the network cluster to provide peer-to-peer uploading services. And sending each first file request to the corresponding peer-to-peer service node. In the embodiment of the invention, the to-be-deployed node can obtain the first file block fed back by the peer-to-peer service node by using the peer-to-peer service downloading mode, so that the uploading bandwidth of all the peer-to-peer service nodes in the network cluster is effectively utilized, the downloading speed of the startup file can be effectively improved, and the deployment efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device, and storage medium for transmitting a startup file. Background Art

[0002] In the construction and maintenance of data centers and large-scale computing environments, efficient deployment and updates of computer equipment are crucial for ensuring rapid response to business needs and reducing operating costs. Traditional computer equipment deployment methods, such as local installation via USB (Universal Serial Bus) drives or optical disks, are time-consuming and error-prone. This approach is clearly impractical for large-scale clusters requiring the deployment of hundreds or even thousands of devices.

[0003] To address this issue, network booting technology emerged. It allows a computer to automatically load a boot program over the network during startup, eliminating the need for physical media to install the operating system. This process primarily relies on several network services, including DHCP (Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol).

[0004] However, while network booting technology greatly simplifies the deployment process, it still faces significant bottlenecks and limitations in large-scale cluster deployment scenarios: all computers to be booted rely on the network boot server to download the boot files. As the cluster scales, the server's upload bandwidth becomes a limiting factor, resulting in slower transmission speeds and longer deployment times. Various improvements have been attempted, such as adding multiple servers and increasing server bandwidth, but none have fundamentally resolved the problem. Especially in large-scale concurrent deployments, server bandwidth and processing power remain the primary bottlenecks, ultimately leading to inefficient boot file transmission and hindering deployment efficiency. Summary of the Invention

[0005] The present application provides a method, device, electronic device and storage medium for transmitting a startup file, so as to at least solve the problem in the related art that the transmission efficiency of the startup file is low, which affects the deployment efficiency of the nodes to be deployed.

[0006] The present application provides a method for transmitting a startup file, comprising: when a node to be deployed in a network cluster is in a basic system environment, obtaining the node status of other cluster nodes in the network cluster; determining the number of peer service nodes in the other cluster nodes based on the node status of the other cluster nodes; when it is determined based on the number of nodes that a peer service condition is met, generating a first file request corresponding to each of the peer service nodes based on the to-be-deployed file information of the node to be deployed; sending each of the first file requests to the corresponding peer service node, and receiving the first file blocks respectively fed back by the corresponding peer service nodes, wherein the startup file of the node to be deployed includes: the first file blocks respectively fed back by each of the peer service nodes.

[0007] The present application also provides a startup file transmission device, including: an acquisition module, used to obtain the node status of other cluster nodes in the network cluster when the node to be deployed in the network cluster is in a basic system environment; a determination module, used to determine the node number of peer service nodes in the other cluster nodes based on the node status of the other cluster nodes; a generation module, used to generate a first file request corresponding to each peer service node based on the to-be-deployed file information of the node to be deployed when it is determined that the peer service condition is met based on the node number; a receiving module, used to send each first file request to the corresponding peer service node, and receive the first file block respectively fed back by the corresponding peer service node, wherein the startup file of the node to be deployed includes: the first file block respectively fed back by each peer service node.

[0008] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned startup file transmission methods 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 startup file transmission methods are implemented.

[0010] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned startup file transmission methods when executed by a processor.

[0011] According to the present application, when a node to be deployed in a network cluster is in a basic system environment, the node status of other cluster nodes is obtained, and the number of peer service nodes is determined based on the node status of other cluster nodes. Furthermore, when the peer service condition is determined to be met based on the number of nodes, a first file request for the peer service node can be generated based on the to-be-deployed node's to-be-deployed file information. In other words, when the number of peer service nodes meets the peer service condition, it indicates that there are sufficient nodes in the network cluster to provide peer upload services. Furthermore, each first file request can be sent to the corresponding peer service node, and the first file block respectively fed back by the corresponding peer service node is received. The startup file of the node to be deployed includes the first file block respectively fed back by each peer service node. At this point, the node to be deployed can obtain the first file block fed back by the peer service node using peer service download mode (i.e., using multiple peer service nodes to jointly transmit the file). In this way, the upload bandwidth of all peer service nodes in the network cluster is effectively utilized, thereby effectively improving the download speed of the startup file and enhancing deployment efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] 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.

[0013] Figure 1 A structural block diagram of a computer device for starting a file transmission method provided in an embodiment of the present application;

[0014] Figure 2 One of the flowcharts of a method for transmitting a startup file provided in an embodiment of the present application;

[0015] Figure 3 A structural block diagram of a network cluster provided in an embodiment of the present application;

[0016] Figure 4 Flowchart 2 of another method for transmitting a startup file provided in an embodiment of the present application;

[0017] Figure 5 This is a structural block diagram of a startup file transmission device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] 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.

[0019] 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.

[0020] 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.

[0021] The startup file transmission method embodiment provided in the embodiment of the present application can be executed in a computer device or a similar computing device. The computer device can be a node to be deployed in a network cluster. Taking running on a computer device as an example, Figure 1 This is a hardware structure diagram of a computer device that starts a file transmission method according to an embodiment of the present application. Figure 1 As shown, the computer device may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA and other processing devices) and a memory 104 for storing data. The above-mentioned computer device may also include a transmission device 106 for communication functions and an input and output device 108. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer device. For example, the computer device may also include Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0022] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for transmitting the startup file in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0023] Transmission device 106 is used to receive or transmit data via a network. A specific example of such a network may include a wireless network provided by a communications provider of the computer device. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0024] The embodiment of the present application provides a method for transmitting a startup file, which is applied to the above-mentioned computer device. The computer device can be a node to be deployed in a network cluster. The method for transmitting a startup file is described in detail in conjunction with the execution process of the method for transmitting a startup file. Figure 2 As shown, the method includes the following steps S202-S208:

[0025] S202 : When the node to be deployed in the network cluster is in a basic system environment, obtain the node status of other cluster nodes in the network cluster.

[0026] In a network cluster deployment scenario, the node status indicates the current deployment stage, network status, file transfer progress, etc. of each node in the cluster. By obtaining the node status of all cluster nodes, you can determine the number of nodes in the cluster available for P2P (peer-to-peer) uploads, and thus decide whether to use multi-threaded download mode or P2P download mode.

[0027] The base system environment refers to the minimal operating system environment that is loaded and run through the Pre-boot Execution Environment (PXE) boot loader. It contains enough components to support network communication, boot file download, and basic software execution, but does not include a complete operating system image and drivers.

[0028] A network cluster is a collection of computing nodes (i.e., cluster nodes) connected via a network. These cluster nodes can be centrally managed using technologies such as PXE, and can participate in file downloads, uploads, and large-scale cluster deployments. Based on the characteristics of network clusters, the present embodiment implements dynamic selection of P2P transmission and multi-threaded downloading between nodes to optimize the deployment efficiency of the entire network cluster.

[0029] It should be noted that the boot file transfer process can be performed by an automated installer within the node to be deployed. This automated installer is a software tool embedded in or running within the node's underlying system environment. It guides and executes the entire boot file transfer and subsequent operating system installation process, achieving automated and intelligent deployment. The automated installer can be included in the pre-boot file or the initial image (initrd).

[0030] In some embodiments, in addition to the cluster nodes used to execute the startup file transfer, the network cluster also includes a management node. The management node is a server node in the network cluster responsible for coordinating, monitoring, and controlling the entire cluster deployment process. The management node can specifically be used for cluster status monitoring (i.e., collecting and updating the node status of all cluster nodes in the network cluster, including but not limited to the cluster node's file transfer progress, deployment progress, network status, resource utilization, etc.).

[0031] Specifically, when the node to be deployed is in the basic system environment, the node's automated installation program runs within the basic system environment, detecting the node's hardware environment and communicating with the management node to obtain further deployment information and policies. Specifically, the node's automated installation program can send requests to the management node to report its own deployment status and obtain the node status of other cluster nodes.

[0032] S204: Determine the number of peer service nodes in other cluster nodes based on the node status of other cluster nodes.

[0033] It should be noted that peer service nodes are cluster nodes capable of transferring files via the P2P protocol. Peer service nodes not only receive files but also provide them, uploading the required operating system images, drivers, and other startup files to the nodes to be deployed.

[0034] Specifically, the automated installer of the node to be deployed can send a request to the management node to report its deployment status. The management node aggregates and analyzes the node status of all cluster nodes in the network cluster, identifies which cluster nodes have P2P upload capabilities, and feeds this cluster status data back to the automated installer of the node to be deployed. The automated installer can receive cluster status data from the management node and, based on the node status of other cluster nodes in the network cluster, determine the number of peer service nodes.

[0035] S206 : When it is determined based on the number of nodes that the peer service condition is met, a first file request corresponding to each peer service node is generated based on the to-be-deployed file information of the to-be-deployed node.

[0036] The first file request is an instruction generated by the automated installer to request the download of startup files from eligible peer service nodes. Based on the required file list of the node to be deployed, the first file request can precisely target the file fragments stored on each peer service node, enabling efficient and parallel file transfer.

[0037] The peer service condition refers to a condition that another cluster node meets to be used as a P2P file transfer source, including but not limited to: the cluster node has completed downloading the startup file, has sufficient upload bandwidth, or has started the P2P server.

[0038] The file information to be deployed refers to the detailed information of the startup file that the node to be deployed needs to download, including the file name, file size, file checksum, file storage path, and the file's P2P transmission metadata (such as torrent files). A torrent file is a seed file, a special small file that contains information about the large file to be shared, such as the startup file's block information, file size, file name, directory structure, etc.

[0039] Specifically, the automated installer checks whether the number of nodes in the current network cluster meets the peer-to-peer service requirement. If so, the automated installer for the node to be deployed determines the specific information about the file to be deployed, including file size, storage location, and P2P metadata required for transmission. For each cluster node that meets the peer-to-peer service requirement, the automated installer generates a first file request.

[0040] In some embodiments, the automated installation program sends a first file request to a peer service node via a P2P network mechanism, requesting that the peer service node provide upload services for the required file. After receiving the first file request, the peer service node can upload the file to the node to be deployed, thereby achieving efficient transmission of the startup file.

[0041] In some embodiments, when the automated installation program generates a first file request, it can generate a corresponding first file request for each peer service node. Of course, it can also select some of the peer service nodes to generate corresponding first file requests. The specific generation method can be adaptively adjusted according to the actual network status, application scenarios, etc.

[0042] S208 , sending each first file request to a corresponding peer service node, and receiving first file blocks respectively fed back by the corresponding peer service nodes, wherein the startup file of the node to be deployed includes: first file blocks respectively fed back by each peer service node.

[0043] The first file block is the data block of the startup file to be deployed (such as an operating system image or driver). These data blocks are uploaded by the peer service node to the node to be deployed. By splicing multiple data blocks, the complete startup file to be deployed is finally formed. In P2P mode, each peer service node can upload one or more data blocks, which distributes the pressure of file transfer and improves transmission efficiency.

[0044] Specifically, the automated installer generates a first file request for each peer service node, specifying the size and location of the required first file block, and sends the request via the P2P network. Upon receiving the first file request, the peer service node uploads the corresponding first file block to the node to be deployed. This transmission process may involve multiple peer service nodes simultaneously, enabling parallel downloads. The node to be deployed receives the first file blocks from each peer service node, integrates them, and reconstructs the original startup file, such as an operating system image or driver.

[0045] In steps S202-S208, when the node to be deployed in the network cluster is in the basic system environment, the node status of other cluster nodes is obtained, and the number of peer service nodes is determined based on the node status of other cluster nodes. Furthermore, if the peer service condition is determined to be met based on the number of nodes, a first file request for the peer service node can be generated based on the to-be-deployed node's file information. In other words, when the number of peer service nodes meets the peer service condition, it indicates that there are sufficient nodes in the network cluster to provide peer upload services. Furthermore, each first file request can be sent to the corresponding peer service node, and the first file block respectively fed back by the corresponding peer service node is received. The startup file of the node to be deployed includes the first file block respectively fed back by each peer service node. At this point, the node to be deployed can obtain the first file block fed back by the peer service node using peer service download mode (i.e., using multiple peer service nodes to jointly transmit the file). This effectively utilizes the upload bandwidth of all peer service nodes in the network cluster, thereby effectively increasing the download speed of the startup file and improving deployment efficiency.

[0046] In some exemplary embodiments, when it is determined that the peer service conditions are met based on the number of nodes, a first file request corresponding to each peer service node is generated based on the to-be-deployed file information of the to-be-deployed node, including: when the number of nodes reaches the target number of nodes, the to-be-deployed file information is split to obtain sub-file information for each peer service node; based on each sub-file information, a first file request corresponding to each peer service node is generated.

[0047] The target node number is the minimum number of nodes required to effectively initiate P2P file transfer mode. When the number of nodes in the network cluster that meet the peer-to-peer service requirements reaches or exceeds the target node number, P2P file transfer mode is considered acceptable. Sub-file information represents detailed information assigned to each peer-to-peer service node. The sub-file information may include, but is not limited to, the checksum, size, and location of the first file block, as well as the peer-to-peer service node identifier.

[0048] Specifically, the automated installer can detect whether the number of nodes in the current network cluster that meet the peer service conditions has reached the target number of nodes. Once it is confirmed that the number of nodes meets the peer service conditions, the automated installer can split the file information to be deployed into multiple sub-file information, each of which corresponds to a first file block, intended to be distributed to different peer service nodes. Based on the sub-file information, the automated installer generates a dedicated first file request for each peer service node, clearly specifying the download requirements for the first file block, and sends the first file request to each peer service node via the P2P network.

[0049] In some embodiments, the automated installer splits the to-be-deployed file information into sub-file information. This can be considered as the automated installer splitting the boot file (including the operating system image, driver, etc.) into a series of sub-files. Each sub-file has specific information, such as file name, size, hash value, and file block number. For example, if the total size of the boot file is 20GB, it can be split into 20 sub-files according to the calculated optimal segmentation unit (e.g., 1GB). Furthermore, the automated installer evaluates the real-time status of each peer service node, including its upload bandwidth, remaining storage space, and the number of tasks currently being processed, to ensure that the selected peer node can reliably provide file upload services. For example, node A's upload bandwidth is stable at 120Mbps, with ample remaining space. Furthermore, the automated installer generates a first file request for the peer service node based on the sub-file information of each sub-file and the peer service node's evaluation results. Each first file request includes, but is not limited to, the peer service node ID, a list of requested sub-files (including file name, size, hash value, etc.), a priority, and a deadline. For example, if there are 20 sub-files and 100 peer service nodes in a cluster, these 20 sub-files can be evenly distributed to some or all nodes based on the peer service node evaluation results, with each node responsible for uploading several specific file chunks. For example, node A's first file request might include detailed information about sub-files 1, 2, and 3. The automated installer prioritizes these sub-files based on their type and importance. For example, core operating system images may be prioritized over auxiliary drivers to ensure fast transfer of critical files. The request also includes a dynamic scheduling mechanism, rescheduling requests based on network congestion and the node's real-time status to ensure continuous and efficient file transfers. In the current network environment, 80 of the 100 peer service nodes are stable and capable of uploading. The remaining 20 nodes are temporarily unavailable as upload nodes due to busy workloads or unstable networks. The total size of the startup file to be deployed is 20GB, which is divided into 20 sub-files using 1GB segments. The automated installer sends the generated first file request to the corresponding peer service node. During the transfer process, the automated installer continuously monitors file transfer progress, network congestion, and node status. If it detects inefficiencies or node issues, it immediately adjusts the file request, such as reallocating file blocks to other nodes or reprioritizing the file transfer, to ensure efficient and stable file transfers.

[0050] In the above embodiment, by splitting the file information to be deployed into multiple sub-file information and distributing these sub-file information to each peer service node in the network cluster, forming the first file request of the P2P transmission mode, efficient parallel file download can be achieved, which significantly improves the efficiency of large-scale cluster deployment.

[0051] In some exemplary embodiments, the file information to be deployed includes the file size of the startup file; splitting the file information to be deployed to obtain sub-file information for each peer service node includes: determining a segment splitting unit for splitting the file information to be deployed based on the number of peer service nodes and the file size of the startup file; wherein the segment splitting unit is a splitting step for splitting the file information to be deployed; splitting the file information to be deployed according to the segment splitting unit to obtain sub-file information for each peer service node.

[0052] The segment splitting unit refers to the splitting step size used when splitting the deployment file information. It is determined by the number of peer service nodes and the size of the startup file. It aims to evenly distribute the deployment file information and ensure that the first file block uploaded by each peer service node is of similar size, thereby optimizing network transmission efficiency and bandwidth utilization.

[0053] Specifically, the automated installation program obtains the number of nodes in the current network cluster that meet the peer service conditions and the file size of the startup file to be deployed. Based on the number of nodes and the file size, the segmentation unit is calculated to ensure that the size of the file block uploaded by each node is appropriate, neither too large to cause a long transmission time, nor too small to cause too many transmission requests and management overhead. Furthermore, the file information to be deployed is divided according to the calculated segmentation unit to form a series of sub-file information, and each sub-file information corresponds to a first file block for subsequent inter-node transmission. Based on the sub-file information, the automated installation program generates a corresponding first file request for each peer service node, which contains the specific information of the file block to be transferred. The first file request is sent to each peer service node, and the latter uploads the corresponding file block to the node to be deployed according to the request. The entire process can be carried out in parallel, significantly improving transmission efficiency.

[0054] In some embodiments, the automated installer can first assess the number of available peer service nodes in the cluster. For example, assuming a network cluster consisting of 300 nodes, 150 of which have completed file downloads (file transfer progress has reached 100%) and whose network status is stable, meeting the network stability criteria, these 150 nodes can be considered peer service nodes. Furthermore, the automated installer can determine the size of the boot file to be deployed, which is a key parameter for calculating the split unit. For example, the operating system image to be deployed is 10GB in size, including a total size of 2GB of critical drivers. Based on the upload capacity of the peer service nodes, the maximum file block size that a single peer service node can provide is calculated. If the average upload bandwidth of each peer service node is 100Mbps, and considering network fluctuations and the potential bandwidth occupied by other applications, the upload bandwidth of each peer service node is set to 80Mbps. Assuming a 30-minute file transfer time target, each peer service node can provide approximately 3.6GB of upload capacity (80Mbps x 1800 seconds / 8 bits) within 30 minutes. The automated installer can dynamically determine the segment splitting unit based on the total size of the boot file (e.g., 12GB), the number of peer service nodes (e.g., 150), and the maximum upload capacity of each peer service node (e.g., 3.6GB). For example, if the goal is for all peer service nodes to complete the boot file transfer within 30 minutes, the size of each first file chunk can be set to 80MB. This allows each peer service node to simultaneously serve multiple nodes to be deployed without excessively consuming any one peer service node's upload bandwidth. After determining the segment splitting unit, the automated installer can optimize the splitting of the deployment file information—specifically, the allocation of first file chunks—to ensure that each peer service node can efficiently transmit first file chunks to multiple nodes to be deployed within the target transfer time. For example, if each peer service node is assigned to process 15 file chunks (15 x 80MB = 1.2GB), then within 30 minutes, 150 peer service nodes can simultaneously process 2,250 first file chunks, significantly accelerating file download speeds across the entire network cluster.

[0055] In some embodiments, the automated installer can adjust the file segmentation unit based on real-time network status and dynamic changes in peer service nodes. For example, if a sudden network fluctuation causes the upload speed of some peer service nodes to drop, the automated installer can automatically reduce the size of the first file chunk and increase the number of first file chunks, thereby allocating more peer service nodes to participate in the transmission and ensuring that the overall deployment progress is not affected.

[0056] In the above embodiment, the file information to be deployed is split according to the segment splitting units to generate sub-file information, so that the peer service node can expand the feedback of the first file block according to the sub-file information, and then effectively perform large-scale file transmission, which greatly improves the deployment efficiency and speed, and at the same time ensures the reasonable allocation and utilization of network resources.

[0057] In some exemplary embodiments, after determining the number of peer service nodes in other cluster nodes, the startup file transmission method also includes: when it is determined based on the number of nodes that the peer service condition is not met, generating a second file request for any one of the peer service nodes based on the to-be-deployed file information of the node to be deployed; sending the second file request to any one of the peer service nodes, and receiving the startup file of the node to be deployed fed back by any one of the peer service nodes.

[0058] It is understandable that when the automated installer determines that the number of peer service nodes in the network cluster is insufficient to meet the high bandwidth requirements of large-scale cluster deployment, that is, the number of currently available peer service nodes cannot effectively share the file download load of the nodes to be deployed, it can automatically adopt a multi-threaded file download mode to ensure the continuity and efficiency of file transfer.

[0059] Specifically, the automated installer generates a second file request based on the file information to be deployed (such as operating system images, drivers, etc.) of the node to be deployed. This request usually contains metadata about the startup file to be deployed, such as the file name, size, hash value, and specific file block information requested. Unlike the multi-node parallel transmission strategy determined by the number of nodes and file size in the first phase, the file request in the second phase can be sent to any peer service node in the network cluster. This usually occurs when the number of peer service nodes is small and cannot meet the needs of large-scale parallel downloads. The peer service node that receives the second file request can read the specified startup file from its local storage according to the request content, and after processing the startup file, transmit it in parallel to the node to be deployed through the network.

[0060] In some embodiments, since the startup file must be retrieved from any peer service node, the automated installer can dynamically select the optimal transfer source based on each peer service node's real-time upload capabilities. If a peer service node's upload speed suddenly drops, the file request can be adjusted to a peer service node with greater upload capabilities, ensuring stable and efficient startup file transfers.

[0061] In some embodiments, the automated installation program can dynamically adjust the priority of second file requests based on the real-time needs of the cluster deployment. For example, during certain critical stages of the installation process, it may be necessary to prioritize downloading certain specific drivers or configuration files. The automated installation program can automatically increase the priority of requests for these files to ensure they are processed and transferred first.

[0062] In the above embodiment, when it is assessed that the number of peer service nodes is insufficient, a parallel download mode can be adopted to generate and send a second file request to any peer service node to ensure efficient and stable transmission of the file to be deployed, thereby ensuring the smooth progress of the entire large-scale cluster deployment process.

[0063] In some exemplary embodiments, sending a second file request to any peer service node and receiving a startup file of the node to be deployed fed back by any peer service node includes: sending a second file request to any peer service node to receive multiple second file blocks fed back in parallel by any peer service node; wherein the multiple second files are obtained by any peer service node extracting the startup files to be transmitted that match the file information to be deployed from the storage unit of the peer service node based on the file information to be deployed carried in the second file request, and splitting the startup files to be transmitted; assembling the multiple received second file blocks, and determining the assembly result as the startup file of the node to be deployed fed back by any peer service node.

[0064] The second file request is generated by the automated installation program of the node to be deployed and is used to request one or more peer service nodes to provide instructions for starting the file download service. Unlike the first file request, the second file request may be issued to any peer service node in some cases.

[0065] The second file chunk is a database created by extracting the startup file to be transferred from the peer service node's local storage unit based on the received second file request, matching the information of the file to be deployed. These data segments are designed to improve file transfer efficiency through parallel transmission.

[0066] Boot file assembly refers to the process by which the automated installer for the node to be deployed stitches together multiple received second file blocks to reconstruct the complete boot file. Using multithreading or parallel processing techniques, the automated installer ensures that all second file blocks are correctly assembled, forming a usable boot image, enabling the network booting of the node to be deployed and subsequent system installation.

[0067] Specifically, the automated installer generates a second file request based on the information about the file to be deployed (such as the size and checksum of the startup file), requesting the download of the startup file from any peer service node. The second file request is sent to any peer service node in the network cluster. Upon receiving the second file request, any peer service node extracts the startup file from its local storage unit based on the information about the file to be deployed, splits the file into multiple second file chunks, and then uploads the multiple second file chunks to the node to be deployed.

[0068] In the above embodiment, the startup file is transmitted in a parallel download mode through any peer service node, which improves the efficiency of large-scale cluster deployment and optimizes the utilization of overall network resources.

[0069] In some exemplary embodiments, each first file request is sent to a corresponding peer service node, and first file blocks respectively fed back by the corresponding peer service node are received, including: each first file request determined based on each sub-file information is sent to a corresponding peer service node, and first file blocks respectively fed back by the corresponding peer service node are received; wherein the first file block is extracted from the storage unit of the peer service node by the peer service node based on the file block index in the corresponding sub-file information; wherein each sub-file information is obtained by splitting the file information to be deployed.

[0070] The file chunk index is part of the sub-file information and indicates the relative position and size of each chunk within the startup file. By managing the file chunk index, the automated installer ensures the orderly transmission and correct assembly of all first file chunks. Based on the size and structure of the file to be deployed, the automated installer splits it into multiple sub-files, each corresponding to a peer service node. It then sends the first file request generated based on these sub-files to the corresponding peer service node.

[0071] Based on the sub-file information in the received first file request, the peer service node uses the file block index to extract the first file blocks from its storage unit and transmits these file blocks to the node to be deployed. The node to be deployed can receive first file blocks from different peer service nodes. These first file blocks will eventually be integrated by the automated installation program into a complete startup file to be deployed.

[0072] Specifically, the automated installer strategically splits the file information to be deployed based on the number of nodes in the network cluster and the size of the startup file, generating multiple sub-file information. For each sub-file information, the automated installer generates a corresponding first file request, which may include a file block index to specify the size and location of the first file block. The first file request is sent to each peer service node in the network cluster. Based on the received file block index, these peer service nodes extract the first file block from their local storage unit. The peer service node transmits the extracted first file block to the node to be deployed.

[0073] In the above embodiment, by splitting file information, generating the first file request for each peer service node, and an efficient file block transmission and reception mechanism, fast and reliable file transmission is achieved during large-scale cluster deployment, greatly improving deployment efficiency and user satisfaction.

[0074] In some exemplary embodiments, after sending each first file request to the corresponding peer service node and receiving the first file blocks respectively fed back by the corresponding peer service nodes, the method further includes: extracting file data and file block indexes from the received first file blocks; and assembling the file data returned by each peer service node in sequence according to the extracted file block indexes to obtain the startup file of the node to be deployed.

[0075] It's understood that in the received first file chunk, the file data is the actual content of the boot file, while the file chunk index is metadata that indicates the location and order of the file data within the boot file. The file chunk index is key to ensuring that the file chunks are correctly assembled into the boot file. Boot file assembly refers to the process by which the automated installer integrates the first file chunks received from multiple peer service nodes to restore the complete boot file.

[0076] It should be noted that the automated installer determines specific requests for each peer service node based on the information about the files to be deployed (such as file size and type) and the network cluster layout, generating and sending each first file request. The node to be deployed receives the first file block from each peer service node in response to the first file request. The first file block contains the file data and its corresponding file block index. The automated installer extracts the file data and file block index from each received first file block. The file data is used for subsequent file assembly, while the file block index guides the correct ordering and assembly of the file blocks. Based on the extracted file block index, the automated installer sequentially assembles the file data returned by each peer service node. This means that the file data is rearranged according to the location information in the original file to restore its original structure. After assembly is complete, the automated installer performs integrity verification on the resulting startup file, including but not limited to verifying the file size and hash checksum to ensure there is no data corruption or transmission errors. Once verification passes, the startup file is used to guide the node to be deployed through the subsequent system installation process, completing the entire automated deployment process.

[0077] In the above embodiment, the automated installation program obtains file data from the peer service node, and then assembles the file blocks in an orderly manner through precise file block indexing, and finally generates a complete startup file, providing an innovative and efficient method for large-scale cluster deployment.

[0078] In some exemplary embodiments, the node status of other cluster nodes includes: file transfer progress and network status; based on the node status of other cluster nodes, the node number of peer service nodes in other cluster nodes is determined, including: performing preliminary screening based on the file transfer progress of other cluster nodes, and screening out candidate cluster nodes from other cluster nodes; wherein the candidate cluster nodes are other cluster nodes whose file transfer progress is characterized as completed transmission; among the candidate cluster nodes, the candidate cluster nodes whose network status meets the network stability condition are determined as peer service nodes, and the node number of peer service nodes is determined.

[0079] As you can understand, file transfer progress is a key parameter in the node status, used to describe whether the node has successfully received and stored the required deployment files. When a node's file transfer progress reaches 100%, it indicates that it is fully ready to provide peer upload services to other nodes.

[0080] Network status refers to the connection stability and upload bandwidth of the cluster nodes in the current network environment. Nodes with good network status can provide stable and fast file upload services and are a prerequisite for becoming peer service nodes.

[0081] Candidate cluster nodes are nodes whose file transfer progress has reached the transfer completion criteria under node status monitoring. Since these nodes have already downloaded the deployment files, they are potentially eligible to serve as peer service nodes for peer upload services. Network stability criteria refer to a set of network status thresholds or standards set by the automated installer to ensure file transfer efficiency and quality. A candidate cluster node is confirmed as a peer service node only when its network status meets these criteria.

[0082] Specifically, the automated installation program can collect the node status of other cluster nodes periodically or in real time, including file transfer progress and network status, and screen out candidate cluster nodes that have completed file downloads based on the collected file transfer progress information. For the screened candidate cluster nodes, further verify whether their network status meets the preset network stability conditions. This includes but is not limited to checking the network connection stability of the candidate cluster nodes, the availability of upload bandwidth, etc. The candidate cluster nodes that have passed the network stability condition verification are determined as peer service nodes, and the number of peer service nodes is calculated and determined to provide a basis for the next step of file transfer strategy adjustment. Based on the number of peer service nodes, the automated installation program dynamically adjusts the file transfer method. If the number of peer service nodes is sufficient, the P2P mode is used to download files first; if the number is insufficient, the multi-threaded download mode is used as a supplement.

[0083] In the above embodiment, we can see how the automated installation program dynamically builds a peer-to-peer service network within the cluster based on the status information of each node, achieving efficient and fast file transmission, thereby significantly improving the efficiency and speed of large-scale cluster deployment.

[0084] In some exemplary embodiments, when the node to be deployed in the network cluster is in a basic system environment, the node status of other cluster nodes in the network cluster is obtained, including: continuously sending broadcast messages to other cluster nodes; wherein the broadcast information is used to instruct other cluster nodes to respectively feedback their respective node heartbeat messages and upload progress information; the basic system environment is entered by the node to be deployed by loading the pre-startup file and the initial image file; the pre-startup file is obtained when the node to be deployed is in a network startup mode; according to a preset time interval, the number of heartbeat receptions of the received node heartbeat messages is counted to determine the network status of each of the other cluster nodes; and the upload progress information of other cluster nodes is analyzed to determine the file transfer progress of each of the other cluster nodes; wherein the node status of other cluster nodes includes: file transfer progress and network status.

[0085] Broadcast messages are a mechanism used in the infrastructure to allow the node being deployed to send signals or requests to other nodes in the network cluster, prompting them to provide feedback on their status. Broadcast messages help automated installers monitor the health of the network cluster and deployment progress in real time.

[0086] Node heartbeat messages are confirmation signals sent by other cluster nodes in response to broadcast messages, indicating that the node is online and able to respond to network requests. Heartbeat messages allow the automated installer to track the activity of each node and identify those with stable network connections and potential peers.

[0087] Understandably, upload progress information provides cluster node feedback on the completion of the current file transfer task. It indicates whether the cluster node has downloaded the required deployment files and how much upload bandwidth the cluster node can contribute. By analyzing upload progress information, the automated installer can determine which cluster nodes have completed file downloads and thus treat them as peer service nodes.

[0088] It should be noted that the basic system environment refers to a temporary operating system environment that the node to be deployed boots up after loading the pre-boot file and the initial image file. This environment allows the node to perform necessary network configuration, file transfers, and other operations, preparing for the subsequent operating system installation. The pre-boot file is the first file downloaded from the PXE server via the PXE protocol when the node to be deployed enters network boot mode. This file typically contains a boot program that boots the node to be deployed into the basic system environment. The initial image file is a minimal boot image used by the node to be deployed in the basic system environment. It contains the basic operating system components required for booting, allowing the node to perform specific tasks, such as network communication and file transfer, without installing a full operating system.

[0089] Specifically, after the node to be deployed enters the basic system environment, the automated installer begins periodically sending broadcast messages to other nodes in the network cluster. These broadcast messages carry a specific identifier, instructing other nodes to respond with node heartbeat messages and upload progress information. Upon receiving these broadcast messages, other nodes respond with node heartbeat messages, indicating their online status, and send upload progress information to update their file transfer status. After receiving these node heartbeat messages, the automated installer counts the number of heartbeats received at preset intervals to assess the network stability of each node. It also analyzes the upload progress information to determine which nodes have completed file downloads and are eligible to serve as peer service nodes, which nodes are still in the process of downloading files, and their network bandwidth usage. Based on both network status (heartbeat counts) and file transfer progress information, the automated installer can comprehensively evaluate the real-time node status of other nodes in the network cluster. This process helps dynamically adjust the selection of P2P peer service nodes to optimize file transfer efficiency.

[0090] It is understood that as node status changes, the automated installer can update the peer service node list in real time and dynamically adjust the transfer strategy based on the number of peer service nodes and upload capacity. If the number of peer service nodes is sufficient and the network status is good, P2P file transfer mode will be enabled first; otherwise, multi-threaded download mode will be used to ensure the stability and efficiency of the initiated file transfer.

[0091] In the above embodiment, by sending broadcast messages and analyzing the heartbeat messages and upload progress information of cluster nodes, the node status of the network cluster is monitored and evaluated in real time, so as to make the optimal file transfer strategy decision, which greatly improves the flexibility, efficiency and stability of large-scale cluster deployment.

[0092] The embodiments described above are only part of the embodiments of the present application, not all of the embodiments. In order to better understand the above method, the above process is described below in conjunction with the embodiments, but it is not intended to limit the technical solutions of the embodiments of the present application. Specifically:

[0093] This application relates to a method for transmitting boot files. This method utilizes an automated installer to monitor the node network environment in real time and determine the number of peer service nodes. Based on the number of peer service nodes, it dynamically selects either a multi-threaded file download mode or a P2P file download mode to improve bandwidth utilization and accelerate large-scale cluster operating system deployment. The P2P file download mode is a distributed data transmission method based on a peer-to-peer network. Unlike the traditional client-server model, each node (peer) in a P2P network is both a data requester (client) and a data provider (server). This means that data transmission and distribution in a P2P network does not rely on a centralized server, but rather is accomplished through direct interaction between multiple nodes. The multi-threaded file download mode involves dividing the target file into multiple data blocks during the file transfer process and simultaneously downloading these blocks from one or more source servers (or peer service nodes) by establishing multiple concurrent connections. This method can significantly improve the transmission efficiency of large files (such as operating system images and deployment packages) in a network environment. It is particularly suitable for scenarios requiring rapid deployment, such as PXE booting and P2P distribution, and offers excellent fault tolerance and bandwidth utilization.

[0094] In the field of server operations and maintenance, PXE is a key remote boot protocol that allows administrators to remotely boot servers and install and configure operating systems over the network. PXE improves deployment efficiency, reduces human error, saves time and costs, and greatly simplifies the server deployment and maintenance process, leading to its widespread use in modern data centers.

[0095] refer to Figure 3 Figure 2 shows the structure of a network cluster. A network cluster can include a PXE server, PXE clients, and a network switch. The PXE server can include DHCP, TFTP, and a large file transfer service. Compute nodes that require an operating system installation (i.e., Client 1, Client 2, ..., Client N) are all PXE clients. Figure 3 The services and compute nodes designed in this example can be cluster nodes in a network cluster. The PXE client can be a bare node with a network boot card (needing to install an operating system) or a node with an operating system already installed (needing to overwrite the existing operating system).

[0096] Conventional technology typically follows the following workflow when completing a system boot using the PXE protocol: 1. Client Boot and Network Request: When booting from a bare metal machine, the client automatically enters the network installation state. If not booting from a bare metal machine, it must be configured to prioritize network booting through the BIOS (Basic Input / Output System) or BMC (Baseboard Management Controller). At this point, the client's network card sends a DHCP request to the DHCP server on the local network to obtain the necessary network configuration information. 2. DHCP Response and Boot Information Transfer: After receiving the client's request, the DHCP server returns a DHCP response packet. This response packet contains not only the basic network configuration information required by the client, such as the IP address, subnet mask, and gateway, but also information about the PXE deployment server, such as the PXE server address and the boot file name (e.g., bootx64.efi). This information is crucial for the client to subsequently complete a network boot. 3. TFTP Request and Boot File Download: Based on the PXE server information provided in the DHCP response, the client sends a request to the PXE deployment server using the TFTP protocol to download the specified boot file. This boot file is typically a PXE boot program, a lightweight software program that helps the client complete the boot process in a network environment without a local operating system. 4. Boot File Loading and Execution: The PXE deployment server responds to the client's TFTP request and transfers the boot file to the client. After successfully receiving the boot file, the client loads it into memory and executes it. The boot program further instructs the client to download necessary system startup files from the PXE deployment server, such as the kernel (vmlinuz) and initialization image (Initrd). These files form the basis of a minimal system operating environment. 5. Minimized System Boot and Subsequent Installation: After completing the above steps, the client uses the downloaded kernel and initialization image to boot a minimal operating system environment. This minimal system environment completes all subsequent installations, including downloading the full installation image, software packages, and drivers from the PXE deployment server, and then performing the full operating system installation. The files downloaded in this step account for the majority of the file downloads during the entire deployment process.

[0097] During a minimal system boot, installation images, software packages, and drivers are all large files. These files are required by every client. Traditional PXE deployments rely on protocols such as HTTP to transfer large files. HTTP is an application-layer protocol for transmitting hypertext and files over a network, allowing clients to initiate requests from servers and receive responses. HTTP is widely used in scenarios such as web browsing, remote file downloads, and programmable API calls. Therefore, in traditional file transfers, the PXE server provides file upload bandwidth, which is then shared by all PXE clients for downloading. This single server bandwidth becomes a bottleneck, leading to significant speed degradation when large-scale concurrency is encountered. For example, if the PXE server upload bandwidth is 1000MB and there are 100 PXE clients, each client is allocated an average of 10MB of network bandwidth, resulting in very low file transfer efficiency. This results in high network load and low deployment efficiency when deploying a network cluster. The more nodes there are, the lower the efficiency. At the same time, in existing PXE deployment methods, the client, i.e., the node to be installed, usually uses the single-threaded download mode of wget (World Wide Web get, a command-line-based open source network download tool). Even if the server has sufficient bandwidth, the single-threaded download mode cannot fully utilize the bandwidth.

[0098] After the traditional PXE completes the minimal system startup, this application does not use the wget single-threaded HTTP protocol downloader, but instead uses a multi-threaded HTTP protocol downloader or a P2P protocol downloader, achieving the goal of fully utilizing bandwidth. It aims to solve the problem of low efficiency of large-scale concurrent downloads caused by server bandwidth limitations during traditional PXE deployment. By introducing P2P technology, network resources between clients can be effectively utilized for file transfer, thereby significantly improving the deployment efficiency and reliability of the entire system. Through multi-threaded download technology, when the upload nodes are insufficient in P2P mode, they can be supplemented. The combination of the two can fully utilize bandwidth resources.

[0099] refer to Figure 4 As shown, a flowchart of a startup file transmission method provided by this application is shown, with the PXE client as the node to be deployed:

[0100] S401, the client (i.e., the node to be deployed) starts and enters the network startup mode;

[0101] S402, sending a network request, such as a DHCP request, a DHCP response and boot information transmission; a TFTP request, a TFTP request for boot file download, etc.

[0102] S403, determine whether a reply is received, if so, proceed to S404;

[0103] S404, downloading the boot program, loading and executing the boot program.

[0104] In step S405, the bootloader further instructs the client to download necessary pre-boot files, such as the kernel (vmlinuz) and the initialization image (Initrd), from the PXE deployment server. The kernel (Kernel) and the initialization image (Initrd) are embedded in the client's automated installation program in this application.

[0105] In step S406, the client uses the downloaded kernel and initialization image to launch a minimal operating system environment. Within this minimal operating system environment, the automated installer starts. After detecting its own hardware environment, the automated installer communicates with the management node to determine the required startup files (i.e., the system image and required drivers) and obtain the current number of peer service nodes in the entire network cluster.

[0106] S407, determine whether the number of peer service nodes reaches the target number of nodes; if so, proceed to S408; if not, proceed to S409;

[0107] S408: If the number of nodes in the cluster that can provide P2P upload services exceeds a threshold, indicating that sufficient cluster nodes have P2P upload capabilities, the automated installer downloads the image and driver torrent files from the management node and uses the P2P transfer protocol to download the startup files (i.e., the image and driver).

[0108] If the number of nodes in the cluster that can provide P2P upload services falls below a certain threshold, indicating that most nodes have either already completed downloading the image and drivers or have not yet entered the download phase, the server's network pressure is relatively low. The automated installer then uses a multi-threaded download method to download the system image and drivers from cluster nodes that can provide HTTP downloads (PXE server nodes and other peer service nodes). The automated installer then starts its own P2P and HTTP services in the background to provide upload services to other nodes to be deployed. Meanwhile, the nodes enter the subsequent installation process, and upload services terminate at the end of the installation.

[0109] S410, after the download is completed, provide upload services to other nodes in the background;

[0110] S411, proceed with the subsequent installation process;

[0111] S412, installation completed.

[0112] From the above steps, we can see that during the entire cluster deployment phase, cluster nodes that enter the downloading state early will use the multi-threaded download mode, because at this time other cluster nodes have not yet downloaded the file and therefore have no upload capability. At this time, the multi-threaded download mode has high bandwidth utilization. Cluster nodes that enter the downloading state in the middle stage will use the P2P download mode. At this time, many cluster nodes have completed downloading and can provide P2P upload services for nodes to be deployed. The P2P transmission protocol can fully utilize the upload bandwidth of peer service nodes, thereby fully utilizing the download bandwidth. Nodes to be deployed that enter the downloading state later will use the multi-threaded download mode, because at this time most cluster nodes have completed installation and no longer provide P2P upload services. At this time, the multi-threaded download mode has high bandwidth utilization.

[0113] This application uses P2P transmission technology and multi-threaded download technology to replace the traditional large file transmission method in PXE, which brings the following effects: Distributed transmission: Utilize the idle bandwidth of cluster nodes to reduce server load. Parallel download: Multiple cluster nodes transmit data blocks at the same time to improve overall throughput. Elastic expansion: The more cluster nodes there are, the higher the transmission efficiency is, which is suitable for large-scale deployment scenarios. For example: in a cluster with 200 nodes, the management network is 1000M, and the operating system needs to be deployed through this network. The image plus driver required for each cluster node is about 10G, and the time for transmitting the startup file is about 4.5 hours, and the total installation time is about 5 hours. The use of the startup file transmission method provided by this application can reduce the subsequent total installation time to less than 20 minutes.

[0114] This application integrates the kernel and initialization image into the automated installation program of the PXE client. The program can detect its own network environment and hardware environment and determine the required system image and driver. By communicating with the cluster deployment program on the server, it can obtain real-time information about the network cluster in the deployment state, and independently decide how to download files such as images and drivers based on the real-time information. It can also set its own node as a peer service node providing upload services.

[0115] 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.

[0116] The embodiments of the present application also provide a parameter adjustment device for realizing the above-mentioned embodiments and preferred embodiments, which have been described and will not be repeated here. As used below, the term "module" can realize a combination of software and / or hardware of a predetermined function. Although the modules described in the following embodiments are preferably realized with software, the realization of hardware, or a combination of software and hardware is also possible and contemplated.

[0117] Figure 5 1 is a structural block diagram of a device for transmitting a startup file according to an embodiment of the present application, the device comprising:

[0118] An acquisition module 502 is configured to acquire the node status of other cluster nodes in the network cluster when the node to be deployed in the network cluster is in a basic system environment;

[0119] A determination module 504 is configured to determine the number of peer service nodes in the other cluster nodes based on the node status of the other cluster nodes;

[0120] A generating module 506 is configured to generate, when it is determined based on the number of nodes that the peer service condition is met, a first file request corresponding to each of the peer service nodes based on the to-be-deployed file information of the to-be-deployed nodes;

[0121] The receiving module 508 is configured to send each of the first file requests to a corresponding peer service node and receive first file blocks respectively fed back by the corresponding peer service nodes, wherein the startup file of the node to be deployed includes: first file blocks respectively fed back by each of the peer service nodes.

[0122] Through the above-described apparatus, when a node to be deployed in a network cluster is in a basic system environment, the node status of other cluster nodes is obtained, and the number of peer service nodes is determined based on the node status of other cluster nodes. Furthermore, when it is determined based on the number of nodes that peer service conditions are met, a first file request for the peer service node can be generated using the to-be-deployed file information of the node to be deployed. In other words, when the number of peer service nodes meets the peer service conditions, it indicates that there are sufficient nodes in the network cluster to provide peer upload services. Furthermore, each first file request can be sent to a corresponding peer service node, and first file blocks respectively fed back by the corresponding peer service nodes are received. The startup file of the node to be deployed includes the first file blocks respectively fed back by each of the peer service nodes. At this point, the node to be deployed can obtain the first file blocks fed back by the peer service nodes using peer service download mode (i.e., using multiple peer service nodes to jointly transmit the file). This effectively utilizes the upload bandwidth of all peer service nodes in the network cluster, thereby effectively increasing the download speed of the startup file and improving deployment efficiency.

[0123] In an exemplary embodiment, the generation module 506 is further used to split the file information to be deployed when the number of nodes reaches the target number of nodes, and obtain sub-file information for each of the peer service nodes; based on each of the sub-file information, generate a first file request corresponding to each of the peer service nodes.

[0124] In an exemplary embodiment, the file information to be deployed includes the file size of the startup file; the generation module 506 is further used to determine the segment splitting unit for splitting the file information to be deployed based on the number of nodes of the peer service node and the file size of the startup file; wherein the segment splitting unit is the splitting step for splitting the file information to be deployed; the file information to be deployed is split according to the segment splitting unit to obtain sub-file information for each of the peer service nodes.

[0125] In an exemplary embodiment, the receiving module 508 is further used to generate a second file request for any one of the peer service nodes based on the to-be-deployed file information of the node to be deployed, when it is determined that the peer service condition is not met based on the number of nodes; send the second file request to the any one peer service node, and receive the startup file of the node to be deployed fed back by the any one peer service node.

[0126] In an exemplary embodiment, the receiving module 508 is further configured to send the second file request to the any one peer service node to receive multiple second file blocks fed back in parallel by the any one peer service node; wherein the multiple second files are obtained by the any one peer service node extracting the startup file to be transmitted that matches the file information to be deployed carried in the second file request from the storage unit of the peer service node, and splitting the startup file to be transmitted; assembling the received multiple second file blocks, and determining the assembly result as the startup file of the node to be deployed fed back by the any one peer service node.

[0127] In an exemplary embodiment, the receiving module 508 is further used to send each first file request determined based on each sub-file information to a corresponding peer service node, and receive first file blocks respectively fed back by the corresponding peer service node; wherein, the first file blocks are extracted by the peer service node from the storage unit of the peer service node based on the file block index in the corresponding sub-file information; wherein, each sub-file information is obtained by splitting the file information to be deployed.

[0128] In an exemplary embodiment, the device also includes an assembly module; the assembly module is used to extract file data and file block indexes from the received first file block respectively; according to the extracted file block indexes, the file data returned by each peer service node are assembled in sequence to obtain the startup file of the node to be deployed.

[0129] In an exemplary embodiment, the node status of the other cluster nodes includes: file transfer progress and network status; the acquisition module 502 is also used to continuously send broadcast messages to the other cluster nodes; wherein, the broadcast information is used to instruct the other cluster nodes to respectively feedback their respective node heartbeat messages and upload progress information; the basic system environment is entered by the node to be deployed loading the pre-startup file and the initial image file; the pre-startup file is obtained when the node to be deployed is in network startup mode; according to the preset time interval, the number of heartbeat receptions of the received node heartbeat messages is counted to determine the network status of each of the other cluster nodes; and the upload progress information of the other cluster nodes is analyzed to determine the file transfer progress of each of the other cluster nodes; wherein, the node status of the other cluster nodes includes: file transfer progress and network status.

[0130] For the description of the features in the embodiment corresponding to the startup file transmission device, please refer to the relevant description of the embodiment corresponding to the startup file transmission method. For the description of the features in the embodiment corresponding to the device startup device, please refer to the relevant description of the embodiment corresponding to the device startup method. They will not be repeated here.

[0131] 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 in any of the above-mentioned embodiments of the method for transmitting a startup file.

[0132] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned startup file transmission method embodiments when running.

[0133] 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.

[0134] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned startup file transmission method embodiments are implemented.

[0135] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned startup file transmission method embodiments are implemented.

[0136] 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.

[0137] The above is a detailed introduction to a startup file transmission method provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for transmitting a startup file, characterized in that: include: When the node to be deployed in the network cluster is in the basic system environment, obtaining the node status of other cluster nodes in the network cluster; Determining the number of peer service nodes in the other cluster nodes based on the node status of the other cluster nodes; In a case where it is determined based on the number of nodes that a peer service condition is met, generating a first file request corresponding to each of the peer service nodes based on the to-be-deployed file information of the to-be-deployed nodes; Send each first file request to a corresponding peer service node, and receive first file blocks respectively fed back by the corresponding peer service nodes, wherein the startup file of the node to be deployed includes: first file blocks respectively fed back by the corresponding peer service nodes.

2. The method according to claim 1, characterized in that The step of generating, when it is determined based on the number of nodes that a peer service condition is satisfied, a first file request corresponding to each peer service node based on the to-be-deployed file information of the to-be-deployed node, includes: When the number of nodes reaches the target number of nodes, splitting the to-be-deployed file information to obtain sub-file information for each of the peer service nodes; Based on the sub-file information, a first file request corresponding to each peer service node is generated.

3. The method according to claim 2, characterized in that The to-be-deployed file information includes the file size of the startup file; The step of splitting the to-be-deployed file information to obtain sub-file information for each of the peer service nodes includes: Determining, based on the number of peer service nodes and the file size of the startup file, a segment splitting unit for splitting the to-be-deployed file information; wherein the segment splitting unit is a splitting step size for splitting the to-be-deployed file information; The to-be-deployed file information is split according to the segment splitting units to obtain sub-file information for each of the peer service nodes.

4. The method according to claim 1, wherein After determining the number of peer service nodes in the other cluster nodes, the method further includes: If it is determined based on the number of nodes that the peer service condition is not met, generating a second file request for any one of the peer service nodes based on the to-be-deployed file information of the to-be-deployed node; The second file request is sent to any one of the peer service nodes, and the startup file of the node to be deployed fed back by the any one of the peer service nodes is received.

5. The method according to claim 4, characterized in that The sending of the second file request to the any one of the peer service nodes and receiving the startup file of the node to be deployed fed back by the any one of the peer service nodes includes: Sending the second file request to the any one peer service node to receive multiple second file blocks fed back in parallel by the any one peer service node; wherein the multiple second files are obtained by the any one peer service node extracting, based on the to-be-deployed file information carried in the second file request, startup files to be transmitted that match the to-be-deployed file information from a storage unit of the peer service node, and splitting the startup files to be transmitted; The received multiple second file blocks are assembled, and an assembly result is determined as the startup file of the node to be deployed fed back by any one of the peer service nodes.

6. The method according to claim 1, characterized in that Sending each of the first file requests to a corresponding peer service node, and receiving first file blocks respectively fed back by the corresponding peer service node, includes: Each first file request determined based on each sub-file information is sent to a corresponding peer service node, and first file blocks respectively fed back by the corresponding peer service node are received; wherein the first file blocks are extracted by the peer service node from a storage unit of the peer service node based on a file block index in the corresponding sub-file information; wherein each sub-file information is obtained by splitting the file information to be deployed.

7. The method according to claim 1, characterized in that After sending each of the first file requests to the corresponding peer service node and receiving the first file blocks respectively fed back by the corresponding peer service node, the method further includes: Extracting file data and file block indexes from the received first file block respectively; According to the extracted file block index, the file data returned by each of the peer service nodes are assembled in sequence to obtain the startup file of the node to be deployed.

8. The method according to claim 1, characterized in that The node status of the other cluster nodes includes: file transfer progress and network status; and determining the number of peer service nodes in the other cluster nodes based on the node status of the other cluster nodes includes: Performing a preliminary screening based on the file transfer progress of the other cluster nodes, screening out candidate cluster nodes from the other cluster nodes; wherein the candidate cluster nodes are other cluster nodes for which the file transfer progress is characterized as completed; The candidate cluster nodes whose network status satisfies the network stability condition among the candidate cluster nodes are determined as peer service nodes, and the number of the peer service nodes is determined.

9. The method according to claim 1, characterized in that When the node to be deployed in the network cluster is in the basic system environment, obtaining the node status of other cluster nodes in the network cluster includes: Continuously sending broadcast messages to the other cluster nodes; wherein the broadcast information is used to instruct the other cluster nodes to respectively feedback their respective node heartbeat messages and upload progress information; the basic system environment is entered by the node to be deployed loading a pre-startup file and an initial image file; the pre-startup file is obtained when the node to be deployed is in network startup mode; According to the preset time interval, the number of heartbeat receptions of the received node heartbeat messages is counted to determine the network status of each of the other cluster nodes; and the upload progress information of the other cluster nodes is analyzed to determine the file transfer progress of each of the other cluster nodes; wherein the node status of the other cluster nodes includes: file transfer progress and network status.

10. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the method for transmitting a startup file as claimed in any one of claims 1 to 9 when executing the computer program.

Images