Method and device for starting file transmission, electronic equipment and storage medium

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for transmitting startup files, relating to the field of computer technology. The method includes: when the node to be deployed in a network cluster is in the basic system environment, obtaining the node status of other cluster nodes, and then determining the number of peer service nodes based on the node status of the other cluster nodes. When the number of peer service nodes meets the peer service conditions, it indicates that there are enough nodes in the network cluster to provide peer upload services. Each first file request is sent to the corresponding peer service node. The node to be deployed can obtain the first file block returned by the peer service node using the peer service download mode. 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 startup files and enhancing deployment efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for transmitting startup files. Background Technology

[0002] In the construction and maintenance of data centers and large-scale computing environments, the efficient deployment and upgrading of computer equipment is crucial to ensuring rapid response to business needs and saving operating costs. Traditional methods of deploying computer equipment, such as local installation via USB (Universal Serial Bus) drives or optical discs, are not only time-consuming and prone to errors, but are also impractical for large-scale clusters that require the deployment of hundreds or even thousands of devices.

[0003] To address this issue, network boot technology was developed. Network boot technology allows computer devices to automatically load a bootloader over a network during startup, thus enabling operating system installation without physical media. This process primarily relies on several network services, such as DHCP (Dynamic Host Configuration Protocol) and TFTP (Trivial File Transfer Protocol).

[0004] However, while network booting technology greatly simplifies the deployment process, it still has significant bottlenecks and limitations in large-scale cluster deployment scenarios: all computers to be booted rely on the network booting server to download boot files. As the cluster size increases, the server's upload bandwidth becomes a limiting factor, leading to decreased transmission speed and extended deployment time. Various improvement methods have been tried, such as using multiple servers and increasing server bandwidth, but these have not fundamentally solved the problem. Especially in large-scale concurrent deployments, server bandwidth and processing power remain the main bottlenecks, ultimately resulting in low boot file transmission efficiency and impacting deployment efficiency. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for transmitting startup files, in order to at least solve the problem in the related art where the low efficiency of startup file transmission affects the deployment efficiency of the nodes to be deployed.

[0006] This application provides a method for transmitting a startup file, comprising: when the 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 among the other cluster nodes based on the node status of the other cluster nodes; if the peer service conditions are met based on the number of nodes, generating a first file request corresponding to each of the peer service nodes based on the file information to be deployed of the node to be deployed; sending each of the first file requests to the corresponding peer service nodes, 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] This application also provides a startup file transmission device, comprising: an acquisition module, 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 the basic system environment; a determination module, configured to determine the number of peer service nodes among the other cluster nodes based on the node status of the other cluster nodes; a generation module, configured to generate a first file request corresponding to each of the peer service nodes based on the file information to be deployed of the node to be deployed, provided that the peer service conditions are met based on the number of nodes; and a receiving module, configured to send each of the first file requests to the corresponding peer service nodes and receive 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 fed back by each of the peer service nodes.

[0008] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described startup file transfer methods when executing the computer program.

[0009] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described methods for transferring a startup file.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described startup file transfer methods.

[0011] This application describes a method for obtaining the node status of other cluster nodes within a network cluster, assuming the node to be deployed is in the basic system environment. Based on this status, the number of peer service nodes can be determined. Furthermore, if the number of nodes satisfies the peer service condition, a first file request can be generated for the peer service node using the file information to be deployed from the node to be deployed. In other words, if the number of peer service nodes meets the peer service condition, it indicates that there are enough nodes in the network cluster to provide peer upload services. Further, each first file request can be sent to the corresponding peer service node, and the first file block returned by the corresponding peer service node can be received. The startup file of the node to be deployed includes the first file block returned by each of the peer service nodes. At this point, the node to be deployed can obtain the first file block returned by the peer service node using the peer service download mode (i.e., using multiple peer service nodes to jointly transfer files). Thus, 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. Attached Figure Description

[0012] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A structural block diagram of a computer device for a method of transferring a startup file provided in an embodiment of this application;

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

[0015] Figure 3 This is a structural block diagram of a network cluster provided in an embodiment of this application;

[0016] Figure 4 A second flowchart illustrating another method for transferring a startup file provided in this application embodiment;

[0017] Figure 5 This is a structural block diagram of a startup file transmission device provided in an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

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

[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] The startup file transfer method provided in this application can be executed on a computer device or similar computing device, specifically 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 block diagram of a computer device for a method of transferring a startup file according to an embodiment of this application. Figure 1 As shown, a computer device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The computer device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer device described above. For example, the computer device may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0022] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the startup file transfer method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and 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 memory remotely located relative to the processor 102, and these remote memories can be connected to computer devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0023] The transmission device 106 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer equipment. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0024] This application provides a method for transferring a startup file, applied to the aforementioned computer device. Specifically, the computer device can be a node to be deployed in a network cluster. The method for transferring a startup file is described in detail below, along with its execution flow. 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 the basic system environment, obtain the node status of other cluster nodes in the network cluster.

[0026] In a network cluster deployment scenario, node status indicates the current deployment stage, network status, and file transfer progress of other cluster nodes. By obtaining the node status of the entire cluster, the number of nodes available for P2P (Peer-to-Peer) uploads can be determined, thus deciding whether to use a multi-threaded download mode or a P2P download mode.

[0027] The basic system environment refers to the minimal operating system environment loaded and run by the PXE (Pre-boot Execution Environment) bootloader. 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 managed uniformly using technologies such as PXE and participate in file downloading, uploading, and large-scale cluster deployment processes. Based on the characteristics of network clusters, this application's embodiments implement 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 transfer process of the boot files can be executed by an automated installer within the node to be deployed. This automated installer is a software tool embedded in or running within the underlying system environment of the node. It is responsible for guiding and executing the entire transfer of the boot files and the subsequent installation of the operating system, 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 perform the transfer of startup files, the network cluster also includes management nodes. Management nodes are server nodes in the network cluster responsible for coordinating, monitoring, and controlling the entire cluster deployment process. Specifically, management nodes can 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 file transfer progress, deployment progress, network status, resource utilization, etc.).

[0031] Specifically, when the node to be deployed is within the basic system environment, the automated installer for that node runs within that environment. It can detect the node's hardware environment and communicate with the management node to obtain further deployment information and strategies. Specifically, the automated installer for the node to be deployed can send requests to the management node to report its own deployment status and obtain the node status of other cluster nodes.

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

[0033] It should be noted that peer service nodes refer to cluster nodes capable of transferring files via P2P protocols. Peer service nodes not only act as file receivers but also as file providers, uploading necessary operating system images, drivers, and other boot files to the nodes to be deployed.

[0034] Specifically, the automated installer on 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 back the cluster status data to the automated installer on the node to be deployed. The automated installer can receive the cluster status data from the management node and then determine the number of peer service nodes based on the node status of other cluster nodes in the network cluster.

[0035] S206, if the conditions for peering services are met based on the number of nodes, generate a first file request for each peering service node based on the file information to be deployed of the node to be deployed.

[0036] The first file request refers to the instruction generated by the automated installer to request the download of startup files from eligible peer service nodes. The first file request can be based on the file requirement list of the nodes to be deployed, precisely targeting file fragments stored on each peer service node to achieve efficient and parallel file transfer.

[0037] Peer service conditions refer to the conditions that another cluster node meets to be used as a P2P file transfer source, including but not limited to: the cluster node has completed the download of the startup file, has sufficient upload bandwidth, or has started the P2P server, etc.

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

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

[0040] In some embodiments, through a P2P network mechanism, the automated installer sends a first file request to peer service nodes, requesting them to provide upload services for the required files. Upon receiving the first file request, the peer service nodes can upload the files to the node to be deployed, achieving efficient transfer of the startup files.

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

[0042] S208, each first file request is sent to the corresponding peer service node, and the first file blocks fed back by the corresponding peer service nodes are received respectively. The startup file of the node to be deployed includes: the first file blocks fed back by each peer service node.

[0043] The first file block consists of data blocks representing the segmented startup file to be deployed (such as an operating system image or driver). These data blocks are uploaded by peer service nodes to the node to be deployed. By concatenating multiple data blocks, a complete startup file to be deployed is finally formed. In P2P mode, each peer service node can upload one or more data blocks, thereby distributing the file transfer load and improving transmission efficiency.

[0044] Specifically, the automated installer can generate a first file request for each peer service node, specifying the size and location of the required first file block, and send the request via a P2P network. Upon receiving the first file request, each 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 downloading. The node to be deployed receives the first file blocks from each peer service node, integrates these blocks, and reconstructs the original boot file, such as an operating system image or driver.

[0045] In steps S202-S208 above, 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 then the number of peer service nodes is determined from the node status of other cluster nodes. Further, if the number of nodes determines that the peer service conditions are met, a first file request for the peer service node can be generated using the file information to be deployed from the node to be deployed. That is, when the number of peer service nodes meets the peer service conditions, it indicates that there are enough nodes in the network cluster to provide peer upload services. Further, each first file request can be sent to the corresponding peer service node, and the first file blocks returned by the corresponding peer service nodes can be received. The startup file of the node to be deployed includes the first file blocks returned by each peer service node. At this time, the node to be deployed can obtain the first file blocks returned by the peer service nodes using the peer service download mode (i.e., using multiple peer service nodes to jointly transfer files). 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.

[0046] In some exemplary embodiments, when the number of nodes determines that the conditions for peering services are met, a first file request is generated for each peering service node based on the file information to be deployed of the node to be deployed. This includes: when the number of nodes reaches the target number of nodes, splitting the file information to be deployed to obtain sub-file information for each peering service node; and generating a first file request for each peering service node based on the sub-file information.

[0047] The target number of nodes 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 conditions reaches or exceeds the target number of nodes, it is determined that P2P file transfer mode can be used. Sub-file information is used to represent the detailed information allocated to each peer service node. The information content of the sub-file information may include, but is not limited to: the checksum, size, and location of the first file block, and the identifier of the peer service node.

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

[0049] In some embodiments, the automated installer splits the information of the files to be deployed into sub-files. This can be considered as the automated installer splitting the startup file (including operating system images, drivers, etc.) into a series of sub-files, each with specific information such as filename, size, hash value, and file block number. For example, if the total size of the startup file is 20GB, it can be split into 20 sub-files using the calculated optimal segmentation unit (e.g., 1GB). Further, the automated installer evaluates the real-time status of each peer service node, including its upload bandwidth, remaining storage space, and the amount 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. Further, based on the sub-file information of each sub-file and the evaluation results of the peer service nodes, the automated installer generates a first file request for each peer service node. Each first file request includes, but is not limited to, the peer service node's ID, the requested list of sub-files (including filename, size, hash value, etc.), priority, and deadline. For example, if there are 20 sub-files and 100 peer service nodes in the cluster, these 20 sub-files can be evenly distributed among some or all nodes based on the evaluation results of the peer service nodes. Each node is responsible for uploading several specific file blocks. For example, node A's first file request could include detailed information about sub-files 1, 2, and 3. The automated installer assigns different priorities based on the type and importance of the sub-files. For example, the core operating system image has higher priority than auxiliary drivers, ensuring the rapid transfer of critical files. The request also includes a dynamic scheduling mechanism, rearranging requests based on network congestion and the real-time status of nodes to ensure the continuity and efficiency of file transfer. In the current network environment, 80 of the 100 peer service nodes are stable and capable of uploading, while the remaining 20 nodes are not currently acting as upload nodes due to busy tasks or network instability. The total size of the startup file to be deployed is 20GB, which is divided into 20 sub-files in 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 the file transfer progress, network congestion, and node status. If inefficiency or node problems are detected, the file request is immediately adjusted, such as by reallocating file blocks to other nodes or changing the file transfer priority, to ensure efficient and stable file transfer.

[0050] In the above embodiments, 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 to form the first file request in P2P transmission mode, efficient parallel file download can be achieved, significantly improving 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 the segmentation 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 segmentation unit is the splitting step size for splitting the file information to be deployed; splitting the file information to be deployed according to the segmentation unit to obtain sub-file information for each peer service node.

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

[0053] Specifically, the automated installer obtains the number of nodes in the current network cluster that meet the peering service conditions and the file size of the startup file to be deployed. Based on the number of nodes and the file size, it calculates the segmentation unit to ensure that the file block size uploaded by each node is appropriate—neither too large, leading to long transmission times, nor too small, leading to excessive transmission requests and management overhead. Further, the file information to be deployed is divided into a series of sub-files according to the calculated segmentation unit, each sub-file corresponding to a first file block for subsequent inter-node transmission. Based on the sub-file information, the automated installer generates a corresponding first file request for each peer service node, containing specific information about the file block to be transmitted. The first file request is sent to each peer service node, which then uploads the corresponding file block to the node to be deployed based on the request. This entire process can be performed 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 with 300 nodes, where 150 nodes have completed file downloads (file transfer progress reaches 100%), and the network status of these nodes is stable, meeting the network stability condition, these 150 nodes can be considered as peer service nodes. Further, the automated installer can determine the size of the boot file to be deployed, which is an important parameter for calculating the split unit. For example, the operating system image to be deployed is 10GB, and the total size of the included critical drivers is 2GB. Based on the upload capabilities 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, considering network fluctuations and bandwidth consumption by other applications, the bandwidth used for upload services by each peer service node is set to 80Mbps. Assuming a file transfer time target of 30 minutes, each peer service node can provide approximately 3.6GB (80Mbps × 1800 seconds ÷ 8 bits) of upload capacity within 30 minutes. Based on the total size of the startup 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), the automated installer can dynamically determine the segmentation unit. For example, if the goal is for all peer service nodes to complete the transfer of the startup file within 30 minutes, the size of each first file block can be set to 80MB. This allows each peer service node to serve multiple nodes simultaneously without excessively consuming the upload bandwidth of any single peer service node. After determining the segmentation unit, the automated installer can optimize the splitting of the deployment file information, i.e., optimize the allocation of the first file blocks, ensuring that each peer service node can efficiently transfer the first file blocks to multiple nodes within the target transfer time. For example, allocating each peer service node to handle 15 file blocks (15 × 80MB = 1.2GB) allows 150 peer service nodes to handle 2250 first file blocks simultaneously within 30 minutes, significantly accelerating the file download speed of the entire network cluster.

[0055] In some embodiments, the automated installer can adjust the file segmentation units based on real-time network conditions and dynamic changes in peer service nodes. For example, if a sudden network fluctuation causes a decrease in the upload speed of some peer service nodes, the automated installer can automatically reduce the size of the first file block and increase the number of the first file blocks, 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 embodiments, the file information to be deployed is split into sub-file information according to the segmented splitting unit, so that the peer service nodes can expand the feedback of the first file block according to the sub-file information, thereby effectively carrying out large-scale file transmission, greatly improving deployment efficiency and speed, while ensuring 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 method for transmitting the startup file further includes: if it is determined based on the number of nodes that the peer service conditions are not met, generating a second file request for any one of the peer service nodes based on the file information to be deployed 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 from any one of the peer service nodes.

[0058] Understandably, 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, a multi-threaded file download mode can be automatically adopted to ensure the continuity and efficiency of file transfer.

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

[0060] In some embodiments, since the startup file needs to be obtained from any peer service node, the automated installer can dynamically select the best transmission source based on the real-time upload capabilities of each peer service node. If the upload speed of a certain peer service node suddenly drops, the file request can be adjusted and redirected to a peer service node with stronger upload capabilities, ensuring the stability and efficiency of startup file transmission.

[0061] In some embodiments, based on the real-time needs of a cluster deployment, the automated installer can dynamically adjust the priority of second file requests. For example, at certain critical stages of the installation process, it may be necessary to prioritize the download of certain specific drivers or configuration files. The automated installer can automatically elevate the request priority of these files, ensuring that they are processed and transmitted preferentially.

[0062] In the above embodiments, when it is determined 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 the 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 the startup file of the node to be deployed from any peer service node includes: sending the 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 startup files matching the deployment file information carried in the second file request from the storage unit of the peer service node, and splitting the startup files 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 any peer service node.

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

[0065] The second file block refers to the database obtained by a peer service node after retrieving the startup file to be transferred from its local storage unit based on the received second file request, matching the information of the file to be deployed, and splitting it. 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 on the node to be deployed splices together multiple received second file blocks to reconstruct a complete boot file. Through multi-threading or parallel processing techniques, the automated installer ensures that all second file blocks are correctly assembled to form a usable boot image, thereby enabling network booting and subsequent system installation on the node to be deployed.

[0067] Specifically, the automated installer generates a second file request based on the information of the file to be deployed (such as the size of the startup file, checksum, etc.), requesting to download the startup file from any peer service node. This second file request is sent to any peer service node in the network cluster. Upon receiving the second file request, each peer service node retrieves the startup file from its local storage unit according to the information of the file to be deployed, splits it into multiple second file blocks, and uploads these multiple second file blocks to the node to be deployed.

[0068] In the above embodiments, 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, 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 node includes: sending each first file request determined based on the sub-file information to the corresponding peer service node and receiving the first file blocks respectively fed back by the corresponding peer service node; wherein, the first file block is 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, the sub-file information is obtained by splitting the file information to be deployed.

[0070] The file chunk index, a part of the sub-file information, indicates the relative position and size of each block within the startup file when the file is split into several chunks. 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 this sub-file information to the corresponding peer service node.

[0071] Based on the sub-file information in the received first file request, the peer service node extracts the first file blocks from its storage unit using the file block index 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, and these first file blocks will eventually be integrated by the automated installer into a complete startup file to be deployed.

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

[0073] In the above embodiments, by splitting file information to generate first file requests for each peer service node, and by implementing 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 returned by the corresponding peer service nodes, the method further includes: extracting file data and file block index from the received first file blocks respectively; and assembling the file data returned by each peer service node in sequence according to the extracted file block index to obtain the startup file of the node to be deployed.

[0075] Understandably, in the first file block received, the file data is the actual content of the startup file, while the file block index is metadata used to indicate the position and order of the file data within the startup file. The file block index is crucial to ensuring that the file blocks can be correctly assembled into the startup file. Startup file assembly refers to the process by which the automated installer integrates the first file blocks received from multiple peer service nodes to reconstruct the complete startup file.

[0076] It's important to note that the automated installer determines the specific requests to each peer service node based on the information of 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 blocks from each peer service node based on the first file requests. Each first file block contains file data and its corresponding file block index. From the received first file blocks, the automated installer extracts both the file data and the file block index. The file data is used for subsequent file assembly, while the file block index guides the correct sorting and combination of file blocks. The automated installer assembles the file data returned by each peer service node in sequence according to the extracted file block index. This means that the file data is rearranged according to its position information in the original file to restore its original structure. After assembly, the automated installer performs integrity verification on the resulting startup file, including but not limited to verifying file size and hash checksums, to ensure no data corruption or transmission errors. Once verification is successful, the startup file is used to guide the node to be deployed through the subsequent system installation process, thus completing the entire automated deployment process.

[0077] In the above embodiments, the automated installer obtains file data from peer service nodes, then assembles file blocks in an orderly manner using a precise file block index, 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, determining the number of peer service nodes among other cluster nodes includes: performing initial screening based on the file transfer progress of other cluster nodes to select candidate cluster nodes from other cluster nodes; wherein, candidate cluster nodes are other cluster nodes whose file transfer progress indicates that the transfer is complete; 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 number of peer service nodes is determined.

[0079] Understandably, file transfer progress is a key parameter in node status, used to describe whether a 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-to-peer upload services to other nodes.

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

[0081] Candidate cluster nodes refer to other cluster nodes whose file transfer progress has reached the completion standard under node status monitoring. These nodes, having already downloaded the deployment files, may be used as peer service nodes to provide peer-to-peer upload services. Network stability conditions refer to a series of network status thresholds or standards set by the automated installation program to ensure file transfer efficiency and quality. Only when the network status of a candidate cluster node meets the network stability conditions will it be confirmed as a peer service node.

[0082] Specifically, the automated installer can periodically or in real-time collect the node status of other cluster nodes, including file transfer progress and network status. Based on the collected file transfer progress information, it filters out candidate cluster nodes that have completed file downloads. For the filtered candidate cluster nodes, its network status is further verified to ensure it meets preset network stability conditions. This includes, but is not limited to, checking the network connection stability and upload bandwidth availability of the candidate cluster nodes. Candidate cluster nodes that pass the network stability verification are identified as peer service nodes. Simultaneously, the number of peer service nodes is calculated and determined, providing a basis for adjusting the file transfer strategy in the next step. Based on the number of peer service nodes, the automated installer dynamically adjusts the file transfer method. If there are enough peer service nodes, P2P mode is prioritized for file download; if the number is insufficient, a multi-threaded download mode is used as a supplement.

[0083] In the above embodiments, it can be seen how the automated installation program dynamically builds a peer-to-peer service network within the cluster based on the status information of each node, thereby achieving efficient and fast file transfer and 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 the basic system environment, obtaining the node status of other cluster nodes in the network cluster includes: continuously sending broadcast messages to other cluster nodes; wherein, the broadcast information is used to instruct other cluster nodes to respectively report their 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 network startup mode; according to a preset time interval, the number of heartbeats received from 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 a basic system environment to allow nodes to be deployed to send signals or requests to other nodes in the network cluster, prompting them to provide feedback on their respective status information. Broadcast messages help automated installers monitor the health of the network cluster and the deployment progress in real time.

[0086] A node heartbeat message is an acknowledgment signal sent by other cluster nodes in response to a broadcast message. It indicates that the node is currently online and capable of responding to network requests. Through heartbeat messages, automated installation programs can track the activity status of each node, identify which nodes have stable network connections and can be considered potential peer service nodes.

[0087] Understandably, upload progress information serves as feedback from cluster nodes regarding the completion status of the current file transfer task. It provides information on whether cluster nodes have finished downloading the required deployment files and how much upload bandwidth each node can contribute. By analyzing upload progress information, the automated installer can determine which cluster nodes have completed file downloads and thus identify them as peer service nodes.

[0088] It's important to note that the basic system environment refers to a temporary operating system environment that the node to be deployed starts after loading the pre-boot file and the initial image file. This environment allows the node to perform necessary network configurations, file transfers, and other operations, preparing it for subsequent operating system installation. The pre-boot file is the first file downloaded from the PXE server via the PXE protocol when the node enters network boot mode. This file typically contains a bootloader used to guide the node into the basic system environment. The initial image file is the minimized boot image used by the node in the basic system environment. It contains the basic operating system components required for startup, allowing the node to perform specific tasks, such as network communication and file transfer, without a full operating system installed.

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

[0090] Understandably, as the node status changes, the automated installer can update the list of peer service nodes in real time and dynamically adjust the transmission strategy based on the number of peer service nodes and their upload capabilities. If there are enough peer service nodes and the network is in good condition, the P2P file transfer mode is prioritized; otherwise, a multi-threaded download mode is used to ensure the stability and efficiency of the initiated file transfer.

[0091] In the above embodiments, 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, thereby making optimal file transfer strategy decisions, which greatly improves the flexibility, efficiency and stability of large-scale cluster deployment.

[0092] The embodiments described above are merely some embodiments of this application, and not all embodiments. To better understand the above methods, the following description, in conjunction with embodiments, illustrates the process, but is not intended to limit the technical solutions of the embodiments of this application. Specifically:

[0093] This application relates to a method for transferring boot files. It utilizes an automated installer to detect 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 accelerate the deployment of large-scale cluster operating systems by utilizing bandwidth. 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 in a P2P network, data transmission and distribution do not rely on a centralized server but are completed through direct interaction between multiple nodes. The multi-threaded file download mode refers to the technique of dividing the target file into multiple data blocks during file transfer and simultaneously downloading these data blocks from one or more source servers (or peer service nodes) by creating multiple concurrent connections. This method can significantly improve the transmission efficiency of large files (such as operating system images, deployment packages, etc.) in a network environment, and is particularly suitable for scenarios requiring rapid deployment, such as PXE booting and P2P distribution, exhibiting good fault tolerance and bandwidth utilization.

[0094] In the field of server operations and maintenance, PXE is an important remote boot protocol that allows administrators to remotely boot servers and perform operating system installation and configuration over a network. PXE can improve deployment efficiency, reduce human error, save time and costs, and greatly simplify the server deployment and maintenance process, thus it has been widely used in modern data centers.

[0095] refer to Figure 3 The diagram shown is a structural block diagram of a network cluster. A network cluster can include PXE servers, PXE clients, and network switches. The PXE server can include DHCP service, TFTP service, and a large file transfer service. The compute nodes that require an operating system to be installed (i.e., client 1, client 2… client N) are all PXE clients. Figure 3 The service and compute nodes designed in this system can all be cluster nodes in a network cluster. The PXE client is a bare node with a network card that supports network boot (requires an operating system to be installed), or a node with an operating system already installed (requires overwriting the existing operating system).

[0096] In conventional technology, the system boot process via the PXE protocol typically follows this workflow: 1. Client Boot and Network Request: When booting from bare metal, the client automatically enters network installation mode. If not booting from bare metal, it needs to be configured to prioritize network boot via BIOS (Basic Input / Output System), BMC (Baseboard Management Controller), etc. At this time, the client's network card sends a DHCP request to the DHCP server on the local network to obtain necessary network configuration information. 2. DHCP Response and Boot Information Transmission: After receiving the client's request, the DHCP server returns a DHCP response packet. This response packet not only contains basic network configuration information required by the client, such as the IP address, subnet mask, and gateway, but also provides information about the PXE deployment server, such as the PXE server address and boot file name (e.g., bootx64.efi). This information is crucial for the client to complete the subsequent 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 via the TFTP protocol to download the specified boot file. This boot file is typically the PXE bootloader, a lightweight software responsible for helping clients 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 bootloader further instructs the client to download necessary system startup files from the PXE deployment server, such as the kernel (vmlinuz) and the initialization image (Initrd). These files form the basis of the minimal system runtime environment. 5. Minimal System Booting 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 a complete operating system installation. The files downloaded in this step account for the majority of the file downloads in the entire deployment process.

[0097] In a minimal system startup, the installation image, software packages, and drivers are all large files. These files are needed by every client. Traditional PXE deployments rely on protocols like HTTP for transferring large files. HTTP is an application-layer protocol used for transferring hypertext and files over a network, allowing clients to send requests to servers and receive responses. HTTP is widely used in web browsing, remote file downloads, and programmable interface calls. Therefore, in traditional file transfer, the PXE server provides the upload bandwidth, which is shared by all PXE clients for downloading. The bandwidth of a single server becomes a bottleneck, and speed drops significantly under large-scale concurrency. For example, if the PXE server has a 1000M upload bandwidth and there are 100 PXE clients, each client is allocated an average of 10M of network bandwidth, resulting in very low file transfer efficiency. This leads to high network load and low deployment efficiency when deploying the entire network cluster. Moreover, the more nodes there are, the lower the efficiency becomes. Meanwhile, in existing PXE deployment methods, the client, i.e. the node to be installed, usually uses wget (World Wide Web get, an open-source command-line network download tool) in a single-threaded download mode. Even if the server has sufficient bandwidth, the single-threaded download mode cannot make full use of the bandwidth.

[0098] This application, after the traditional PXE system completes its minimal system startup, does not use the single-threaded HTTP protocol downloader (wget). Instead, it employs a multi-threaded HTTP protocol downloader or a P2P protocol downloader to fully utilize bandwidth. This aims to solve the problem of low efficiency during large-scale concurrent downloads caused by server bandwidth limitations in traditional PXE deployments. By introducing P2P technology, network resources between clients can be effectively utilized for file transfer, significantly improving the overall system deployment efficiency and reliability. Multi-threaded download technology supplements the P2P network when there are insufficient upload nodes, and the combination of both fully utilizes bandwidth resources.

[0099] refer to Figure 4 The diagram shown illustrates a flowchart of a file transfer initiation method provided in this application, with a PXE client as the node to be deployed.

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

[0101] S402, sends a network request. Examples include: DHCP request, DHCP response and boot information exchange; TFTP request, TFTP request for boot file download, etc.

[0102] S403, confirm whether a reply has been received; if so, proceed to S404.

[0103] S404, Download the bootloader, the bootloader loads and executes.

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

[0105] In S406, the client uses the downloaded kernel and initialization image to boot a minimal operating system environment. Within this minimal operating system environment, an automated installer begins. The automated installer detects its own hardware environment, communicates with the management node to determine the required boot files (i.e., the system image and necessary drivers), and obtains the number of peer service nodes in the entire network cluster.

[0106] S407, Determine whether the number of peer service nodes has reached the target number of nodes; if yes, proceed to S408; if no, proceed to S409.

[0107] S408 If the number of nodes in the cluster that can provide P2P upload service is greater than a threshold, it means that enough cluster nodes have P2P upload capability. At this time, the automated installer downloads the torrent files of the image and driver from the management node and uses the P2P transmission protocol to download the startup files (i.e., the image and driver).

[0108] S409: If the number of nodes in the cluster that can provide P2P upload service is less than a threshold, it means that most nodes have either finished downloading the image and drivers or have not yet entered the download stage. At this time, the network pressure on the server is relatively low. The automated installer uses a multi-threaded download method to download the system image and drivers from the cluster nodes that can provide HTTP download (PXE server nodes and other peer service nodes). Subsequently, the automated installer starts its own P2P and HTTP services in the background to provide upload services for other nodes to be deployed. At the same time, the nodes enter the subsequent installation process until the installation is completed, and the upload service also ends.

[0109] S410, after downloading, provides upload services for other nodes in the background;

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

[0111] S412, installation complete.

[0112] As shown in the above steps, during the entire cluster deployment phase, early cluster nodes entering the download state will use a multi-threaded download mode because other cluster nodes have not yet downloaded files and therefore have no upload capability. At this stage, multi-threaded downloading has high bandwidth utilization. Mid-stage cluster nodes entering the download state will adopt a P2P download mode. Many cluster nodes have completed their downloads and can provide P2P upload services to the nodes to be deployed. The P2P transmission protocol can fully utilize the upload bandwidth of peer service nodes, thus maximizing download bandwidth. Late-stage nodes entering the download state will use a multi-threaded download mode because most cluster nodes have completed installation and no longer provide P2P upload services. At this stage, multi-threaded downloading also has high bandwidth utilization.

[0113] This application employs P2P transmission technology and multi-threaded download technology to replace the traditional large file transfer method in PXE, resulting in the following advantages: Distributed transmission: Utilizing idle bandwidth of cluster nodes reduces server load. Parallel download: Multiple cluster nodes transmit data blocks simultaneously, improving overall throughput. Elastic scaling: The more cluster nodes, the higher the transmission efficiency, suitable for large-scale deployment scenarios. For example, in a cluster with 200 nodes and a 1000M management network, if an operating system needs to be deployed through this network, each cluster node requires approximately 10GB of image and driver data, and the time spent transferring boot files is approximately 4.5 hours, with a total installation time of approximately 5 hours. However, using the boot file transfer method provided in this application, the total installation time can be reduced to less than 20 minutes.

[0114] In the automated installation program of the PXE client, which integrates the kernel and initializes the image, the program can detect its own network and hardware environment, determine the required system image and drivers, obtain real-time information about the network cluster in the deployment state by communicating with the server-side cluster deployment program, and make autonomous decisions on the download method of files such as images and drivers based on the real-time information. It can also set its own node as a peer service node that provides upload services.

[0115] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0116] Embodiments of this application also provide a parameter adjustment device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the modules described in the following embodiments are preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0117] Figure 5 This is a structural block diagram of a startup file transfer device according to an embodiment of this application. The device includes:

[0118] The acquisition module 502 is used 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 the basic system environment.

[0119] The determination module 504 is used to determine the number of peer service nodes in the other cluster nodes based on the node status of the other cluster nodes.

[0120] The generation module 506 is used to generate a first file request corresponding to each of the peer service nodes based on the file information to be deployed of the nodes to be deployed, when it is determined that the peer service conditions are met based on the number of nodes.

[0121] The receiving module 508 is used to send each of the first file requests to the corresponding peer service nodes and receive 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.

[0122] Using the aforementioned device, 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. Further, if the number of nodes determines that the peer service conditions are met, a first file request for the peer service node can be generated using the file information to be deployed from the node to be deployed. That is, when the number of peer service nodes meets the peer service conditions, it indicates that there are enough nodes in the network cluster to provide peer upload services. Further, each first file request can be sent to the corresponding peer service node, and the first file blocks returned by the corresponding peer service nodes can be received. The startup file of the node to be deployed includes the first file blocks returned by each of the peer service nodes. At this time, the node to be deployed can obtain the first file blocks returned by the peer service nodes using the peer service download mode (i.e., using multiple peer service nodes to jointly transfer files). Thus, 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.

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

[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 configured to determine a segmentation 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 segmentation unit is a segmentation step size for splitting the file information to be deployed; and the file information to be deployed is split according to the segmentation unit to obtain sub-file information for each peer service node.

[0125] In an exemplary embodiment, the receiving module 508 is further configured to, when it is determined based on the number of nodes that the peer service conditions are not met, generate a second file request for any one of the peer service nodes based on the file information to be deployed of the node to be deployed; send the second file request to the any one peer service node; and receive the startup file of the node to be deployed from the feedback of 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 any one of the peer service nodes to receive multiple second file blocks fed back in parallel by the any one of the peer service nodes; wherein, the multiple second files are obtained by the any one of the peer service nodes extracting startup files that match the deployment file information carried in the second file request from the storage unit of the peer service node, and splitting the startup files 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 of the peer service nodes.

[0127] In an exemplary embodiment, the receiving module 508 is further configured to send each of the first file requests determined based on the sub-file information to the corresponding peer service node, and receive the first file blocks respectively fed back by the corresponding peer service nodes; wherein, the first file block is 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, the sub-file information is obtained by splitting the file information to be deployed.

[0128] In an exemplary embodiment, the apparatus further includes an assembly module; the assembly module is configured to extract file data and file block index from the received first file block respectively; and to assemble the file data returned by each of the peer service nodes in sequence according to the extracted file block index 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 further configured to continuously send broadcast messages to the other cluster nodes; wherein, the broadcast information is used to instruct the other cluster nodes to respectively report 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; the number of heartbeats received from the received node heartbeat messages is counted at preset time intervals 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 a description of the features in the embodiment corresponding to the boot file transmission device, please refer to the relevant description of the embodiment corresponding to the boot file transmission method. For a description of the features in the embodiment corresponding to the device boot device, please refer to the relevant description of the embodiment corresponding to the device boot method. They will not be repeated here.

[0131] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the boot file transfer method.

[0132] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the startup file transfer method when it is run.

[0133] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0134] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the startup file transmission method.

[0135] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described embodiments of the startup file transfer method.

[0136] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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 provides a detailed description of a method for transmitting startup files provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for transferring a startup file, characterized in that, include: When the node to be deployed in the network cluster is in the basic system environment, obtain the node status of other cluster nodes in the network cluster; The node status of the other cluster nodes includes: file transfer progress and network status; A preliminary screening is performed based on the file transfer progress of the other cluster nodes to select candidate cluster nodes; wherein, the candidate cluster nodes are other cluster nodes whose file transfer progress indicates that the transfer has been completed. Among the candidate cluster nodes, those whose network status meets the network stability condition are identified as peer service nodes, and the number of the peer service nodes is determined. If the number of nodes determines that the peering service conditions are met, a first file request is generated for each peering service node based on the file information to be deployed of the node to be deployed; wherein, the number of nodes meeting the peering service conditions means that the number of nodes reaches or exceeds the target number of nodes. Each of the first file requests is sent to the corresponding peer service node, and the first file block is received from the corresponding peer service node. The startup file of the node to be deployed includes the first file block from each of the peer service nodes. After determining the number of peer service nodes among the other cluster nodes, the method further includes: If it is determined that the peer service conditions are not met based on the number of nodes, a second file request is generated for any one of the peer service nodes based on the file information to be deployed of the node to be deployed. The second file request is sent to any one of the peer service nodes, and the startup file of the node to be deployed is received from any one of the peer service nodes.

2. The method according to claim 1, characterized in that, When the number of nodes determines that the conditions for peering services are met, the step of generating a first file request for each peering service node based on the file information to be deployed of the nodes to be deployed includes: When the number of nodes reaches the target number of nodes, the file information to be deployed is split to obtain sub-file information for each of the peer service nodes; Based on the information of each sub-file, a first file request is generated for each of the peer service nodes.

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

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

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

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

7. 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: Broadcast messages are continuously sent to the other cluster nodes; wherein, the broadcast messages are used to instruct the other cluster nodes to respectively report their own 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 a preset time interval, the number of heartbeats received from the nodes 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.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for transferring the startup file as described in any one of claims 1 to 7 when executing the computer program.

Images