Firmware upgrade method and computing device

Abstract

Embodiments of the present application provide a firmware upgrading method and a computing device. The method is applied to a master server, which is in communication connection with a plurality of servers to be upgraded. The method comprises: obtaining a firmware package to be upgraded and performance index information of the plurality of servers to be upgraded; determining a block control strategy for each server to be upgraded according to the performance index information of the plurality of servers to be upgraded; wherein the block control strategy comprises a block weight and a push list, and the push list comprises at least one other server to be upgraded among the plurality of servers to be upgraded except the server to be upgraded itself; performing block processing on the firmware package to be upgraded according to the block weight to obtain a plurality of firmware blocks; and sending the firmware blocks and the push list to the corresponding server to be upgraded, so that the server to be upgraded pushes the firmware blocks to the servers to be upgraded in the push list, and generates the firmware package to be upgraded according to all the firmware blocks after receiving all the firmware blocks, thereby completing the firmware upgrading.

Description

Technical Field

[0001] This application relates to the field of computing device technology, and in particular to a firmware upgrade method and a computing device. Background Technology

[0002] As data centers evolve towards hyperscale operations, server cluster firmware upgrades have become a core challenge for operations and maintenance management. Firmware, as the underlying control program for hardware devices, is crucial for patching security vulnerabilities, improving hardware performance, and ensuring compatibility with new features. Traditional single-node, one-by-one upgrade methods are unsuitable for the firmware upgrade needs of large-scale cluster scenarios.

[0003] In related technologies, a common approach is to use a master server to distribute firmware packages to multiple target nodes in parallel, or to use a method where the firmware package is pre-defined into static blocks and then each server node pushes the block data to each other to achieve batch upgrades.

[0004] However, the firmware upgrade methods in related technologies have low resource utilization and long transmission time for firmware packages, resulting in low efficiency of firmware upgrades. Summary of the Invention

[0005] This application provides a firmware upgrade method and computing device that can improve the efficiency of firmware upgrades.

[0006] In a first aspect, embodiments of this application provide a firmware upgrade method applied to a main server, the method comprising:

[0007] Obtain the firmware package to be upgraded and performance metrics information of multiple servers to be upgraded;

[0008] Based on the performance metrics of the plurality of servers to be upgraded, a block control strategy is determined for each of the servers to be upgraded; wherein, the block control strategy includes block weights and a push list, and the push list includes at least one other server to be upgraded among the plurality of servers to be upgraded, excluding itself.

[0009] According to the block weight, the firmware package to be upgraded is divided into blocks to obtain multiple firmware blocks;

[0010] The firmware block and the push list are sent to the corresponding server to be upgraded, so that the server to be upgraded pushes the firmware block to the server to be upgraded in the corresponding push list. After receiving all the firmware blocks, the firmware package to be upgraded is generated according to all the firmware blocks to complete the firmware upgrade.

[0011] Here, this application embodiment provides a flexible firmware upgrade method. Before distributing the firmware package to be upgraded, the master server pre-obtains the performance index information of the servers to be upgraded. Based on the performance index information of each server to be upgraded, the master server dynamically determines the block control strategy, including the block weight corresponding to each server to be upgraded for block division and the push list for sharing firmware blocks. This achieves a flexible block division method that fits the server's business capabilities and a push scheme with high resource utilization. This method can implement differentiated block division strategies based on the network capabilities of different servers, shorten the overall upgrade time, and achieve rapid sharing of firmware blocks by combining targeted mutual push between servers to be upgraded. This enables efficient firmware package distribution, improves resource utilization during firmware package transmission, reduces transmission time, and thus effectively improves firmware upgrade efficiency.

[0012] In one possible implementation, the performance metric information includes uplink bandwidth and / or downlink bandwidth; wherein the block weight is positively correlated with the uplink bandwidth, and / or the block weight is negatively correlated with the downlink bandwidth.

[0013] This application introduces two performance metrics: uplink bandwidth and downlink bandwidth. These two metrics are the core basis for quantifying the server's data push and data reception capabilities. By combining uplink and downlink bandwidth, the differences in node bandwidth can be fully considered, allowing the block division and push strategies to match the server's actual network capabilities. This provides a quantitative basis for the network capability dimension of subsequent block weighting and push list formulation, thereby improving the accuracy of the strategy.

[0014] In one possible implementation, determining the block control strategy for each of the plurality of servers to be upgraded based on their performance metrics includes:

[0015] Calculate the upload capability factor of the server to be upgraded based on the uplink bandwidth and / or the downlink bandwidth;

[0016] Calculate the block weight of each of the servers to be upgraded based on the upload capability factors of the multiple servers to be upgraded;

[0017] For each of the servers to be upgraded, other servers with upload capability factors lower than the server to be upgraded are added to the corresponding push list.

[0018] In this embodiment, the upload capability factor of the server to be upgraded is calculated using uplink and / or downlink bandwidth. This upload capability factor reflects the server's ability to push data and its efficiency in receiving data. This embodiment first calculates the upload capability factor using uplink and downlink bandwidth, then calculates the block weight based on the upload capability factors of all nodes to determine the firmware block proportion of a single node. Finally, a push list is created based on the principle of pushing from nodes with high upload capability to nodes with low upload capability. Using upload capability as the core basis for block allocation and push, nodes with strong upload capability undertake more distribution tasks and are allocated larger blocks, fully leveraging the resource advantages of high-bandwidth nodes, while allowing low-bandwidth nodes to only receive pushes, reducing their transmission pressure. The upload capability factor quantifies and ranks the upload capabilities of nodes, providing a clear basis for targeted pushes, making peer-to-peer (P2P) pushes more targeted, maximizing bandwidth resource utilization, improving distribution efficiency, increasing global resource utilization, and thus improving firmware upgrade efficiency.

[0019] In one possible implementation, the performance metrics information also includes the average access traffic within a preset upgrade time window;

[0020] Accordingly, the step of calculating the block weight of each of the servers to be upgraded based on the upload capability factors of the multiple servers to be upgraded includes:

[0021] The upload capability factors of the plurality of servers to be upgraded are normalized to obtain the normalized bandwidth factor of each of the servers to be upgraded.

[0022] The average access traffic of the plurality of servers to be upgraded is normalized to obtain a normalized traffic factor for each of the servers to be upgraded.

[0023] The block weight of each server to be upgraded is determined based on the normalized bandwidth factor and the normalized traffic factor.

[0024] This application's embodiments, based on network capability indicators, supplement the average access traffic within a preset upgrade time window with a service load indicator. This overcomes the limitations of traditional technologies that do not consider service factors, upgrading the calculation of block weights from a single upload capability dimension to a dual dimension of network capability and service load. This allows the block allocation strategy to adapt to differences in both network capability and service load, assigning higher block weights to nodes with higher traffic, thus combining service priority with upgrade efficiency and reducing the impact time of upgrades on critical services. Normalization processing eliminates differences in indicator dimensions, achieving dual optimization of resource utilization and service security in cluster upgrades, further improving resource utilization during firmware packet transmission and increasing firmware upgrade efficiency.

[0025] In one possible implementation, the step of dividing the firmware package to be upgraded into multiple firmware blocks according to the block weight includes:

[0026] Obtain the data size of the firmware package to be upgraded;

[0027] Based on the data size and the block weight, calculate the allocated data size for each server to be upgraded; wherein, the sum of the allocated data sizes of the servers to be upgraded is the data size;

[0028] Based on the allocated data size, the firmware package to be upgraded is divided into blocks to obtain multiple firmware blocks.

[0029] In this embodiment, firmware package segmentation is performed by accurately segmenting the data size of the firmware package to be upgraded. The integrity of the firmware blocks is ensured by a normalization constraint that the sum of the segment sizes equals the total size, providing a foundation for subsequent node reassembly of the complete firmware package. Segment size is precisely linked to segment weight, allowing high-weight nodes with high upload performance and high service load to be allocated larger firmware blocks, fully leveraging their resource advantages. Simultaneously, lower-weight nodes are allocated smaller blocks, reducing their receiving pressure. This flexible combination of the performance characteristics of each server to be upgraded achieves accurate segmentation, effectively solving the bottleneck problem of low-bandwidth nodes, maximizing global bandwidth utilization, and significantly shortening the overall upgrade time.

[0030] In one possible implementation, after sending the firmware block and the push list to the corresponding upgrade server, the method further includes:

[0031] Monitor the upgrade status of the server to be upgraded within a preset time period;

[0032] If the upgrade status is "upgrade unsuccessful", then a firmware block sending status detection is triggered to determine whether there are any firmware blocks that have not been successfully sent.

[0033] If it exists, then resend the firmware block that was not successfully sent.

[0034] Here, in this embodiment, the master server monitors the upgrade status of each server to be upgraded. For nodes that have not successfully upgraded, it triggers firmware block transmission status detection and retransmits the unsuccessfully sent firmware blocks. By monitoring the upgrade status in real time, the master server can promptly detect upgrade failures, preventing faulty nodes from remaining in an unupgraded state for extended periods and shortening the overall upgrade time. Targeted detection of firmware block transmission status accurately pinpoints the cause of the failure, avoiding blind retransmissions and improving fault repair efficiency. The firmware block retransmission mechanism provides a fallback mechanism, improving the overall success rate of cluster upgrades and preventing upgrade tasks from being reworked due to individual node failures, further improving firmware upgrade efficiency and reliability.

[0035] Secondly, embodiments of this application provide a firmware upgrade method applied to a server to be upgraded, the method comprising:

[0036] The system receives a firmware block and a push list sent by the master server. The firmware block is generated by the master server after obtaining the firmware package to be upgraded and performance metrics information of multiple servers to be upgraded. Based on the performance metrics information of the multiple servers to be upgraded, the master server determines a block control strategy for each server to be upgraded, and then blocks the firmware package to be upgraded according to the block weights before sending it according to the push list. The block control strategy includes block weights and a push list, and the push list includes at least one other server to be upgraded among the multiple servers to be upgraded, excluding itself.

[0037] The firmware block is pushed to the corresponding server in the push list to be upgraded;

[0038] After receiving all firmware blocks, the firmware package to be upgraded is generated based on all the firmware blocks to complete the firmware upgrade.

[0039] This application provides a firmware upgrade scheme for a server to be upgraded. After receiving firmware blocks from the master server, the server to be upgraded pushes the firmware package to other servers to be upgraded according to a push list. Finally, all firmware blocks are collected and reassembled into a complete firmware package to complete the upgrade. The server to be upgraded participates in data distribution, realizing full-cluster P2P collaboration, distributing the transmission pressure of the master server to all nodes, making full use of the uplink bandwidth resources of all nodes in the cluster, and executing according to the strategy set by the master server to ensure the orderliness and accuracy of the push, maximizing the utilization of global network resources and solving the problem of low resource utilization. Combined with targeted push according to the push list, network congestion caused by irregular P2P push is avoided, improving data transmission efficiency, shortening firmware block distribution time, and distributing the reassembly of firmware packages so that each node only needs to collect its own missing firmware blocks, reducing the download pressure of individual nodes and preventing low-bandwidth nodes from becoming bottlenecks. Through the above methods, the firmware upgrade efficiency is effectively improved.

[0040] In one possible implementation, the step of generating the firmware package to be upgraded based on all the firmware blocks after receiving all the firmware blocks to complete the firmware upgrade includes:

[0041] Receive firmware blocks sent by other servers to be upgraded;

[0042] The firmware blocks are subjected to integrity verification to determine whether all firmware blocks have been received;

[0043] If it is determined that all firmware blocks have been received, then the firmware package to be upgraded is generated based on all the firmware blocks.

[0044] This application uses integrity verification as a prerequisite for firmware package reassembly, which can detect missing or damaged firmware blocks in advance, avoid upgrade failure due to invalid firmware packages, reduce upgrade rework, and shorten the overall upgrade time.

[0045] Thirdly, embodiments of this application provide a firmware upgrade device applied to a main server. The device includes: an acquisition module, a determination module, a block segmentation module, and a sending module, wherein...

[0046] The acquisition module is used to acquire the firmware package to be upgraded and the performance metrics information of multiple servers to be upgraded.

[0047] The determining module is used to determine the block control strategy for each of the plurality of servers to be upgraded based on the performance index information of the plurality of servers to be upgraded; wherein, the block control strategy includes block weight and push list, and the push list includes at least one other server to be upgraded among the plurality of servers to be upgraded, excluding itself.

[0048] The segmentation module is used to segment the firmware package to be upgraded into multiple firmware blocks according to the segmentation weight.

[0049] The sending module is used to send the firmware block and the push list to the corresponding server to be upgraded, so that the server to be upgraded pushes the firmware block to the server to be upgraded in the corresponding push list, and after receiving all firmware blocks, generates the firmware package to be upgraded based on all firmware blocks to complete the firmware upgrade.

[0050] In one possible implementation, the performance metric information includes uplink bandwidth and / or downlink bandwidth; wherein the block weight is positively correlated with the uplink bandwidth, and / or the block weight is negatively correlated with the downlink bandwidth.

[0051] In one possible implementation, the determining module is specifically used for:

[0052] Calculate the upload capability factor of the server to be upgraded based on the uplink bandwidth and / or the downlink bandwidth;

[0053] Calculate the block weight of each of the servers to be upgraded based on the upload capability factors of the multiple servers to be upgraded;

[0054] For each of the servers to be upgraded, other servers with upload capability factors lower than the server to be upgraded are added to the corresponding push list.

[0055] In one possible implementation, the performance metrics information also includes the average access traffic within a preset upgrade time window;

[0056] Accordingly, the determining module is also specifically used for:

[0057] The upload capability factors of the plurality of servers to be upgraded are normalized to obtain the normalized bandwidth factor of each of the servers to be upgraded.

[0058] The average access traffic of the plurality of servers to be upgraded is normalized to obtain a normalized traffic factor for each of the servers to be upgraded.

[0059] The block weight of each server to be upgraded is determined based on the normalized bandwidth factor and the normalized traffic factor.

[0060] In one possible implementation, the segmentation module is specifically used for:

[0061] Obtain the data size of the firmware package to be upgraded;

[0062] Based on the data size and the block weight, calculate the allocated data size for each server to be upgraded; wherein, the sum of the allocated data sizes of the servers to be upgraded is the data size;

[0063] Based on the allocated data size, the firmware package to be upgraded is divided into blocks to obtain multiple firmware blocks.

[0064] In one possible implementation, after the sending module sends the firmware block and the push list to the corresponding server to be upgraded, the above apparatus further includes a first detection module, used for:

[0065] Monitor the upgrade status of the server to be upgraded within a preset time period;

[0066] If the upgrade status is "upgrade unsuccessful", then a firmware block sending status detection is triggered to determine whether there are any firmware blocks that have not been successfully sent.

[0067] If it exists, then resend the firmware block that was not successfully sent.

[0068] Fourthly, embodiments of this application provide a firmware upgrade device applied to a server to be upgraded. The device includes: a receiving module, a pushing module, and a generating module, wherein...

[0069] A receiving module is used to receive a firmware block and the push list sent by the master server; wherein, the firmware block is generated by the master server after obtaining the firmware package to be upgraded and the performance index information of multiple servers to be upgraded, determining the block control strategy for each server to be upgraded based on the performance index information of the multiple servers to be upgraded, and dividing the firmware package to be upgraded into blocks according to the block weights before sending it according to the push list; wherein, the block control strategy includes block weights and a push list, and the push list includes at least one other server to be upgraded among the multiple servers to be upgraded, excluding itself.

[0070] The push module is used to push the firmware block to the server to be upgraded in the corresponding push list;

[0071] The generation module is used to generate the firmware package to be upgraded based on all the firmware blocks after receiving them, so as to complete the firmware upgrade.

[0072] In one possible implementation, the generation module is specifically used for:

[0073] Receive firmware blocks sent by other servers to be upgraded;

[0074] The firmware blocks are subjected to integrity verification to determine whether all firmware blocks have been received;

[0075] If it is determined that all firmware blocks have been received, then the firmware package to be upgraded is generated based on all the firmware blocks.

[0076] Fifthly, embodiments of this application provide a computing device, which includes a memory and a processor;

[0077] Memory and processor are coupled;

[0078] Memory is used to store program instructions;

[0079] The processor is used to invoke program instructions to cause the computing device to perform the firmware upgrade method as described in the first aspect and any possible implementation.

[0080] Sixthly, embodiments of this application provide a computing device, which includes a memory and a processor;

[0081] Memory and processor are coupled;

[0082] Memory is used to store program instructions;

[0083] The processor is used to invoke program instructions to cause the computing device to perform firmware upgrade methods as described in the second aspect and any possible implementation.

[0084] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by an electronic device, are used to implement the firmware upgrade method as described in the first aspect and any possible implementation.

[0085] Eighthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a first computing device, are used to implement the firmware upgrade method as described in the second aspect and any possible implementation.

[0086] Ninthly, embodiments of this application provide a computer program product, including a computer program that, when executed by an electronic device, implements the firmware upgrade method involved in the first aspect and any possible implementation.

[0087] In a tenth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a first computing device, implements the firmware upgrade method involved in the second aspect and any possible implementation.

[0088] The firmware upgrade method and computing device provided in this application embodiment, before distributing the firmware package to be upgraded, the main server pre-obtains the performance index information of the servers to be upgraded, and dynamically determines the block control strategy based on the performance index information of each server to be upgraded, including the block weight corresponding to each server to be upgraded for block division and the push list for sharing firmware blocks, thereby realizing a flexible block division method that fits the server's business capabilities and a push scheme with high resource utilization. This method can implement differentiated block division strategies according to the network capabilities of different servers, shorten the overall upgrade time, and achieve rapid sharing of firmware blocks by combining targeted mutual push between servers to be upgraded, thereby achieving efficient firmware package distribution, improving resource utilization during firmware package transmission, reducing transmission time, and thus effectively improving firmware upgrade efficiency. Attached Figure Description

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

[0090] Figure 1 This is a schematic diagram of a firmware upgrade system architecture provided in an embodiment of this application;

[0091] Figure 2A flowchart illustrating the firmware upgrade method provided in this application embodiment. Figure 1 ;

[0092] Figure 3 A schematic diagram illustrating a firmware package distribution process provided in an embodiment of this application;

[0093] Figure 4 A schematic diagram illustrating the firmware block push process provided in this application embodiment;

[0094] Figure 5 A schematic diagram illustrating the reception results of all firmware blocks provided in an embodiment of this application;

[0095] Figure 6 A flowchart illustrating the firmware upgrade method provided in this application embodiment. Figure 2 ;

[0096] Figure 7 This is a schematic diagram of the structure of a firmware upgrade device provided in an embodiment of this application;

[0097] Figure 8 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0098] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0099] Traditional firmware upgrade methods suffer from low resource utilization and long transmission times, leading to low upgrade efficiency. To address these issues, the firmware upgrade method and computing device provided in this application pre-obtain performance metrics information of the servers to be upgraded before distributing the firmware package. Based on this information, the main server dynamically determines a block control strategy, including the block weights for each server and a push list for sharing firmware blocks. This achieves a flexible block allocation method tailored to server capabilities and a high-resource-utilization push scheme.

[0100] The following is combined with Figure 1 The application scenarios involved in the embodiments of this application will be described.

[0101] Figure 1 This is a schematic diagram illustrating the structure of a firmware upgrade system architecture provided in an embodiment of this application. Figure 1 As shown, the firmware upgrade system may include multiple computing devices, which may also be referred to as servers. For example, the multiple computing devices may include a master server 11 as a control node, and multiple servers to be upgraded as execution nodes, such as servers to be upgraded 12, 13, 14, 15, and 16 as shown in the figure.

[0102] Multiple computing devices can be interconnected via a network (such as a local area network or wide area network in a data center) to enable data communication.

[0103] Specifically, the main server 11 can communicate with any one of the servers to be upgraded, namely 12, 13, 14, 15, and 16, via the network.

[0104] The network can be a network that transmits data using remote direct memory access (RDMA) technology. For example, the network can be a high-speed network (Infiniband, IB) or an RDMA over converged Ethernet (ROCE) network.

[0105] In some embodiments, the communication method between the master server 11 and any server to be upgraded is centered on the master server, with each server to be upgraded directly connected to it.

[0106] Optionally, the main server 11 is primarily used to issue firmware blocks and push lists, as well as possible control commands and status feedback.

[0107] Specifically, any two of the servers to be upgraded (13, 14, and 15) can communicate with each other via P2P. Any two servers can communicate directly without a central node.

[0108] Optionally, any two servers to be upgraded are primarily used to push firmware blocks to each other to achieve rapid, parallel data dissemination.

[0109] Optionally, the data transmitted in the communication can be the firmware to be upgraded, including the firmware blocks after being processed into blocks.

[0110] In some embodiments, the firmware package to be upgraded may be a software package containing all or part of the data of the target firmware program. Firmware typically refers to the low-level control program written to the non-volatile memory of a server hardware device (e.g., a baseboard management controller, hard disk drive, or network adapter). Therefore, the firmware upgrade method of this application aims to update, fix vulnerabilities, or enhance the functionality of the firmware of such hardware devices on multiple servers to be upgraded. The firmware package to be upgraded may be a complete firmware image file released by the device manufacturer, and its format may be, but is not limited to, a binary image, a packaged file containing signatures and metadata, etc.

[0111] Understandable Figure 1 This is merely illustrative; in actual implementation, the number of the master server and the servers to be upgraded can be determined according to the actual situation, and this application embodiment does not impose specific limitations on this. Furthermore, the master server can also be elected from the servers to be upgraded, or an independent control node can be deployed in the system; all of these fall within the protection scope of this application embodiment.

[0112] Understandable. Figure 1 The architecture shown is one example. In other embodiments, the functionality of the master server 11 can be shared by a server cluster to improve reliability.

[0113] Optionally, the P2P network between servers to be upgraded may be restricted by network policies in actual communication, and not all nodes can connect directly. This embodiment of the application can achieve shared push of firmware blocks through servers to be upgraded that can connect directly.

[0114] Optionally, a hierarchical architecture can be introduced in ultra-large-scale clusters. For example, the master server 11 first distributes the firmware package to several regional master nodes, and then each of these regional master nodes plays a role similar to a master server, calculating the block distribution strategy and initializing P2P diffusion for the child nodes within its jurisdiction.

[0115] This application does not limit the functionality of the firmware upgrade system. For example, the firmware upgrade system can be an artificial intelligence (AI) training cluster, or it can be other functional clusters.

[0116] Optionally, the aforementioned main server and the server to be upgraded may be, for example, a graphics processing unit (GPU) server or an AI server.

[0117] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the optimized system architecture of the model. In other feasible embodiments of this application, the above architecture may include more or fewer components than illustrated, or combine some components, or split some components, or arrange different components, which can be determined according to the actual application scenario and is not limited here. Figure 1 The components shown can be implemented in hardware, software, or a combination of both.

[0118] In specific implementation, the main server provided in this application embodiment may include data acquisition equipment and processing equipment.

[0119] Optionally, the data acquisition device may include an input / output interface or a communication interface, and the data acquisition device may be connected to the processing device through the input / output interface or the communication interface.

[0120] Before the firmware package to be upgraded is distributed, the main server can obtain the performance index information of the servers to be upgraded in advance. Based on the performance index information of each server to be upgraded, the processing device can dynamically determine the block control strategy, including the block weight corresponding to each server to be upgraded and the push list for sharing firmware blocks. This enables a flexible block method that fits the server's business capabilities and a push scheme with high resource utilization.

[0121] It should be understood that the aforementioned processing device can be implemented by a processor reading instructions from memory and executing those instructions, or it can be implemented by a chip circuit.

[0122] Furthermore, the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0123] Figure 2 A flowchart illustrating the firmware upgrade method provided in this application embodiment. Figure 1 ,like Figure 2 As shown, embodiments of this application provide a method for optimizing a model, which is described in detail below:

[0124] S201: Obtain the firmware package to be upgraded and the performance metrics information of multiple servers to be upgraded.

[0125] Optionally, the system can retrieve the firmware package to be upgraded from a specified storage location pre-uploaded to the main server by the system administrator, such as a local disk, network attached storage, or object storage service. Alternatively, the main server can automatically pull the firmware package to be upgraded from an external software vendor repository or mirror site according to the upgrade task configuration.

[0126] Optionally, after obtaining the firmware package, the master server can perform preliminary verification, such as verifying its message digest value or hash value to ensure file integrity, and verifying the digital signature to ensure the source is trustworthy. Through verification, it is ensured that the data basis for subsequent distribution is correct and secure, thereby improving the reliability and security of firmware upgrades.

[0127] Optionally, the performance metrics information can be a multidimensional dataset designed to assess the server's network throughput capacity and current load. Specifically, it may include, but is not limited to, at least one of the following:

[0128] Network bandwidth metrics: Uplink bandwidth is the maximum available rate at which a server can send data. This is the most critical metric determining its ability to function as a P2P distribution source. Downlink bandwidth is the maximum available rate at which a server can receive data. This affects the speed at which it receives firmware blocks from multiple sources.

[0129] Optionally, network bandwidth metrics may also include network latency and jitter, representing round-trip time with the master server or other peer nodes, used to assess network quality.

[0130] Optionally, it may also include the average access traffic within a preset upgrade time window, for example, the average access traffic for one month within the current upgrade time window.

[0131] Optionally, system load metrics may also be included: Central Processing Unit (CPU) utilization, the current percentage of CPU usage; high load may affect its ability to process network protocols and verify data. Memory utilization, available memory resources; this may affect its ability to cache firmware blocks. Disk input / output (I / O) status: read / write speed or queue depth, affecting the speed at which it writes received firmware blocks to temporary storage.

[0132] Optionally, contextual metrics may also be included: historical / real-time traffic, which is the average or real-time data traffic processed by the server's network interface within the current upgrade time window, used to determine whether the network is nearing saturation; and geographic location / network topology, which, in cross-region deployments, includes information about the server's data center and availability zone, and can be used to optimize the push list to reduce cross-region traffic.

[0133] In some possible implementations, the master server can collect performance metrics information from multiple servers to be upgraded through various active or passive mechanisms.

[0134] Optionally, when an upgrade task is triggered, the master server sends lightweight probe requests to all nodes in the list of servers to be upgraded. Upon receiving the request, each server to be upgraded collects local system information and returns it to the master server. This ensures real-time data transmission.

[0135] Optionally, monitoring agents on each server to be upgraded periodically report performance metrics to a centralized monitoring system. The master server, when needed, retrieves the latest performance snapshots of each server by querying the monitoring system's Application Programming Interface (API).

[0136] Optionally, the main server first obtains basic load information from the monitoring system, and then conducts a round of proactive probing on key indicators to obtain more accurate decision-making basis.

[0137] S202: Determine the block control strategy for each server to be upgraded based on the performance metrics information of multiple servers to be upgraded.

[0138] The block control strategy includes block weights and a push list, which includes at least one other server to be upgraded from among multiple servers to be upgraded.

[0139] Optionally, embodiments of this application establish a bandwidth-block allocation model to determine the block control strategy for each server to be upgraded. This improves resource utilization and solves the bottleneck problem of low-bandwidth nodes.

[0140] Specifically, this application embodiment optimizes network bandwidth differences to avoid low-bandwidth nodes becoming performance bottlenecks. It adopts dynamic firmware segmentation and dynamically adjusts the upgrade strategy according to the actual network conditions and node capabilities.

[0141] Optionally, the master server determines a corresponding block control strategy for each server to be upgraded based on the performance metrics information of each server to be upgraded, mainly the uplink bandwidth and downlink bandwidth.

[0142] Optionally, the block control strategy includes two key components: block weight and push list.

[0143] The block weight is used to determine the proportion of firmware packages that the server should receive in the initial distribution phase, and the push list is used to determine which other servers the server needs to push its firmware blocks to in the subsequent P2P exchange phase.

[0144] The core strategy of this application's embodiments is to assign more distribution tasks to servers with strong network capabilities and fewer distribution tasks to servers with weak network capabilities. Specifically, this is reflected in:

[0145] Regarding block weights, these weights determine the size of the firmware block a server receives during the initial distribution phase. The principle is that the greater the uplink bandwidth, the greater the block weight. Specifically, servers with higher uplink bandwidth have a stronger ability to push data outwards, so they are allocated a larger firmware block during the initial distribution phase. This allows them to share more data with other servers during subsequent P2P exchange phases, fully leveraging their uplink bandwidth advantage and acting as the primary data source node. Conversely, the greater the downlink bandwidth, the smaller the block weight. Servers with higher downlink bandwidth are allocated smaller firmware blocks because even if they initially receive only a small block of data, they can quickly download larger missing blocks from other servers during subsequent P2P exchange phases. This way, their strong downlink bandwidth is used to fetch data, rather than passively waiting for initial distribution. Allocating larger firmware blocks to servers with lower downlink bandwidth reduces the amount of data they need to download during the P2P phase, thus preventing low-bandwidth nodes from hindering the overall progress.

[0146] The push list determines which servers should push their firmware blocks to during the P2P exchange phase. The configuration strategy in this embodiment is to have servers with strong upload capabilities push data to servers with weak upload capabilities. Specifically, if all servers push data indiscriminately to all other servers during P2P exchange, it will cause a large amount of redundant transmission and network congestion. This embodiment achieves targeted push through a push list. Servers with strong upload capabilities (typically high uplink bandwidth and low downlink bandwidth) act as the primary data source, pushing their firmware blocks to servers with weak upload capabilities; servers with weak upload capabilities (typically low uplink bandwidth and high downlink bandwidth) primarily act as receivers, undertaking little or no push tasks. This targeted push mode ensures efficient data flow along capability gradients, avoiding the bottleneck problem of low-bandwidth nodes both sending and receiving data.

[0147] S203: Based on the block weight, the firmware package to be upgraded is divided into blocks to obtain multiple firmware blocks.

[0148] In one possible implementation, the firmware package to be upgraded is divided into blocks according to the block weights to obtain multiple firmware blocks, including: obtaining the data size of the firmware package to be upgraded; calculating the allocated data size for each server to be upgraded according to the data size and the block weights; and dividing the firmware package to be upgraded into blocks according to the allocated data size to obtain multiple firmware blocks.

[0149] The sum of the allocated data sizes for the servers to be upgraded is the total data size.

[0150] Specifically, this application embodiment configures normalization constraints, and the block size is determined as follows:

[0151]

[0152] in, Let S be the block size of the firmware block for the i-th server, and S be the data size of the firmware package to be upgraded. For block weights, The normalization correction coefficient's core function is to adjust the block weights of server nodes. Perform normalization calibration to ensure that the sum of the weights of all nodes satisfies the normalization constraint. This represents the total number of servers that need to be upgraded.

[0153] When segmenting the firmware package, this embodiment accurately segments the package based on its data size and ensures its integrity through a normalization constraint that the sum of the segment sizes equals the total size. This provides a foundation for subsequent node reassembly of the complete firmware package. The segment size is precisely linked to the segment weight, allocating larger firmware blocks to high-weight nodes with high upload performance and high service load, fully leveraging their resource advantages. Simultaneously, smaller blocks are allocated to low-weight nodes, reducing their receiving pressure. This flexible combination of performance characteristics of each server to be upgraded achieves accurate segmentation, effectively solving the bottleneck problem of low-bandwidth nodes, maximizing global bandwidth utilization, and significantly shortening the overall upgrade time.

[0154] In some scenarios, the block weight of the server to be upgraded may be determined to be 0. This means that during the initial distribution phase, the server to be upgraded will not be allocated any firmware block data.

[0155] Specifically, in case of node failure or anomaly: If a server to be upgraded is currently offline, experiencing network interruption, or suffering severe performance degradation (such as downlink bandwidth approaching 0), to prevent it from hindering the distribution process, the master server can set its block weight to 0 and temporarily withhold initial firmware blocks from it. Once it recovers, all firmware blocks can be obtained from other nodes through subsequent P2P exchanges.

[0156] Business scheduling strategy: In some scenarios, based on the above performance indicators, the server to be upgraded can be identified as the receiver. Alternatively, the operations and maintenance personnel may want certain nodes to act only as receivers and not as the initial data source. In this case, the block weight can be set to 0 according to user needs.

[0157] Dynamic adjustment: If a node malfunctions during the upgrade process, the master server can dynamically adjust its weight to 0 and trigger a retransmission mechanism.

[0158] When the block weight is 0, it means that the master server will not send any initial firmware blocks to this node, and the node will receive all firmware blocks from other nodes in subsequent P2P exchange phases. This further enhances the system's flexibility and fault tolerance.

[0159] Optionally, the chunk weight can be any positive number, and its value directly reflects the share of data that the server should handle in the initial distribution phase. The specific value of the weight depends on the calculation results of the performance metric information:

[0160] In some possible implementations, high-weight nodes—servers with high uplink bandwidth and high access traffic—have larger block weights and are allocated larger firmware blocks accordingly. These nodes will become the primary data source during the P2P exchange phase, making full use of their upload capabilities.

[0161] In some possible implementations, low-weight nodes—servers with low downlink bandwidth or light load—have smaller block weights and are allocated smaller firmware blocks. These nodes experience less pressure during the initial distribution phase and only need to receive a small amount of data to complete assembly during the P2P exchange phase.

[0162] S204: Send the firmware block and push list to the corresponding server to be upgraded, so that the server to be upgraded will push the firmware block to the server to be upgraded in the corresponding push list, and after receiving all firmware blocks, generate the firmware package to be upgraded based on all firmware blocks to complete the firmware upgrade.

[0163] Figure 3 This is a schematic diagram illustrating a firmware package distribution process provided in an embodiment of this application, as shown below. Figure 3 As shown, the master server 11 distributes different firmware blocks to the servers to be upgraded according to the block control strategy of each server. Figure 3 The example assumes that all servers to be upgraded participate in pushing firmware blocks. However, in the actual implementation, there may be servers that only receive firmware blocks pushed by other servers to be upgraded without undertaking the distribution task.

[0164] Specifically, in Figure 3 In this process, the original firmware package to be upgraded can be 1G in size, and firmware blocks of 250MB, 300MB, 250MB, 100MB and 100MB are distributed to the servers to be upgraded 12, 13, 14, 15 and 16 respectively.

[0165] In some embodiments, the scheme is described in detail based on the uplink and downlink bandwidth of the servers to be upgraded. If the uplink bandwidth of server 12 to be upgraded is 1000Mbps and the downlink bandwidth is 1000Mbps, the uplink bandwidth of server 13 to be upgraded is 1500Mbps and the downlink bandwidth is 500Mbps, the uplink bandwidth of server 14 to be upgraded is 1000Mbps and the downlink bandwidth is 1000Mbps, the uplink bandwidth of server 15 to be upgraded is 250Mbps and the downlink bandwidth is 1750Mbps, and the uplink bandwidth of server 16 to be upgraded is 250Mbps and the downlink bandwidth is 1750Mbps, the master server 11 can calculate the upload capability factor of each server to be upgraded to determine the block weight of each server, thereby realizing the distribution of firmware blocks.

[0166] In some embodiments, the master server 11 can determine the block weight of each server by calculating the upload capability factor of each server to be upgraded (the sum of the uplink bandwidth and the downlink bandwidth is determined as the total bandwidth; the quotient of the uplink bandwidth and the total bandwidth is calculated to obtain the upload capability factor of the server to be upgraded).

[0167] Among them, servers with higher upload capability factors are allocated larger firmware blocks: Server 13, with an upload capability factor of 1500 / (1500+500)=0.75, has the highest upload capability factor among all servers, and is therefore allocated the largest 300MB firmware block, serving as the core distribution node within the cluster; Servers 15 and 14, with upload capability factors of 250 / (250+1750)=0.125, have the lowest upload capability factors among all servers, and are therefore allocated the smallest 100MB firmware block, primarily serving as receiving nodes and not undertaking the main distribution task; Servers 12 and 14, with upload capability factors of 1000 / (1000+1000)=0.5, are at a medium level, and are therefore allocated a medium-sized 250MB firmware block, balancing distribution and receiving functions.

[0168] This application embodiment dynamically allocates firmware blocks based on the server's uplink and downlink bandwidth, allowing servers with high upload capabilities to handle more distribution tasks and preventing servers with low upload capabilities from becoming bottlenecks. For example, server 13, which has an upload bandwidth ratio as high as 75%, possesses stronger data push capabilities and is therefore allocated the largest firmware block, enabling it to quickly distribute data to other nodes in subsequent P2P pushes. In contrast, servers 15 and 16, with upload bandwidth ratios of only 12.5% ​​and weaker push capabilities, are allocated the smallest firmware blocks to reduce their distribution pressure and lower the overall transmission bottleneck. Through this differentiated block allocation method based on uplink and downlink bandwidth, servers with high upload capabilities can fully utilize their bandwidth advantages to handle more firmware block distribution tasks, while reducing the distribution pressure on servers with high upload capabilities, preventing them from becoming transmission bottlenecks, maximizing the overall network resource utilization of the cluster, and shortening the overall firmware upgrade time.

[0169] Figure 4 This is a schematic diagram of the firmware block push process provided in the embodiments of this application, as shown below. Figure 4 As shown, the server to be upgraded 12 pushes the 250MB firmware block 1 to the servers to be upgraded 13, 14, 15 and 16 respectively via P2P transmission.

[0170] Correspondingly, the firmware block push process is the same for other servers to be upgraded.

[0171] After receiving all firmware blocks sent by servers 13, 14, 15, and 16, server 12 integrates the firmware blocks to obtain all the firmware blocks, such as... Figure 5 As shown, Figure 5 This diagram illustrates the reception result of all firmware blocks as provided in an embodiment of this application. After receiving all firmware blocks, any server to be upgraded can integrate them to obtain the original firmware package to be upgraded, and then perform a firmware upgrade.

[0172] Here, this application embodiment provides a flexible firmware upgrade method. Before distributing the firmware package to be upgraded, the master server pre-obtains the performance index information of the servers to be upgraded. Based on the performance index information of each server to be upgraded, the master server dynamically determines the block control strategy, including the block weight corresponding to each server to be upgraded for block division and the push list for sharing firmware blocks. This achieves a flexible block division method that fits the server's business capabilities and a push scheme with high resource utilization. This method can implement differentiated block division strategies based on the network capabilities of different servers, shorten the overall upgrade time, and achieve rapid sharing of firmware blocks by combining targeted mutual push between servers to be upgraded. This enables efficient firmware package distribution, improves resource utilization during firmware package transmission, reduces transmission time, and thus effectively improves firmware upgrade efficiency.

[0173] In one possible implementation, after sending the firmware block and push list to the corresponding server to be upgraded, the method further includes:

[0174] Monitor the upgrade status of the server to be upgraded within a preset time period; if the upgrade status is unsuccessful, trigger firmware block sending status detection to determine if there are any unsuccessfully sent firmware blocks; if so, resend the unsuccessfully sent firmware blocks.

[0175] Optionally, the master server starts a scheduled monitoring task to track the upgrade status of each server to be upgraded. The upgrade status includes, but is not limited to, any of the following stages: the server has not yet received the firmware block or has not started the upgrade process; the server is receiving the firmware block; performing P2P exchange or assembling the firmware package; the server has successfully completed the firmware upgrade; and the server has not completed the upgrade within a preset time period or has reported an error status.

[0176] It is understood that the length of the preset time period can be dynamically configured according to the firmware package size, cluster size and network conditions. For example, it can be set to 30 minutes after the initial distribution is completed, or it can be estimated based on historical upgrade data using an adaptive algorithm. This application embodiment does not impose specific limitations on this.

[0177] Optionally, if a server awaiting upgrade fails to upgrade successfully within a preset time period, the master server immediately triggers a firmware block transmission status check for that node. The check includes at least one of the following:

[0178] Check the master server's transmission log to confirm whether the corresponding firmware block and push list have been successfully sent to the server to be upgraded. If the transmission fails, record it as a failure to send to the master server.

[0179] Server to be upgraded receives confirmation: A query request is sent to the server to be upgraded to confirm whether it has received the expected firmware block. If the server to be upgraded reports that it has not received the data or that the received data is incomplete, it is recorded as a node reception failure.

[0180] P2P Exchange Status: If the server X to be upgraded has received the initial firmware block but other firmware blocks are missing in subsequent P2P exchanges, its missing block list can be further queried.

[0181] Optionally, based on the detection results, the main server may take at least one of the following measures:

[0182] If the master server fails to send the firmware block data, it will reread the firmware block data and resend the complete firmware block and push list to the server to be upgraded. A maximum number of retries can be set to avoid infinite retries.

[0183] If a node receives a missing firmware block: the master server resends the missing firmware block to the server to be upgraded. If there are multiple missing blocks, they can be packaged and resent or resent in sequence.

[0184] If P2P exchanges are missing: The master server can choose to resend the missing blocks or instruct other nodes to assist in retransmission, depending on the situation. In a preferred embodiment, if the number of missing blocks is small and other nodes already have complete data, the master server can notify other nodes to resend the blocks to the server to be upgraded, thereby reducing the load on the master server.

[0185] Here, in this embodiment, the master server monitors the upgrade status of each server to be upgraded. For nodes that have not successfully upgraded, it triggers firmware block transmission status detection and retransmits the unsuccessfully sent firmware blocks. By monitoring the upgrade status in real time, the master server can promptly detect upgrade failures, preventing faulty nodes from remaining in an unupgraded state for extended periods and shortening the overall upgrade time. Targeted detection of firmware block transmission status accurately pinpoints the cause of the failure, avoiding blind retransmissions and improving fault repair efficiency. The firmware block retransmission mechanism provides a fallback mechanism, improving the overall success rate of cluster upgrades and preventing upgrade tasks from being reworked due to individual node failures, further improving firmware upgrade efficiency and reliability.

[0186] The following detailed explanation of step S202 is provided with reference to specific embodiments:

[0187] In one possible implementation, performance metrics information includes uplink bandwidth and / or downlink bandwidth.

[0188] Among them, the block weight is positively correlated with the uplink bandwidth, and / or the block weight is negatively correlated with the downlink bandwidth.

[0189] This application introduces two performance metrics: uplink bandwidth and downlink bandwidth. These two metrics are the core basis for quantifying the server's data push and data reception capabilities. By combining uplink and downlink bandwidth, the differences in node bandwidth can be fully considered, allowing the block division and push strategies to match the server's actual network capabilities. This provides a quantitative basis for the network capability dimension of subsequent block weighting and push list formulation, thereby improving the accuracy of the strategy.

[0190] In one possible implementation, a block control strategy for each server to be upgraded is determined based on performance metrics information of multiple servers to be upgraded, including: calculating the upload capability factor of the server to be upgraded based on uplink bandwidth and / or downlink bandwidth; calculating the block weight of each server to be upgraded based on the upload capability factors of multiple servers to be upgraded; and adding other servers to be upgraded with upload capability factors lower than the server to be upgraded to the corresponding push list for each server to be upgraded.

[0191] Optionally, this implementation generates the push list based on the principle of nodes with high upload capabilities pushing to nodes with low upload capabilities. Specifically, for any node, its push list includes all other nodes whose upload capability factor is less than its own. This means that the node with the strongest upload capability appears in the push lists of all other nodes and pushes to everyone as a data source; nodes with medium upload capabilities push to nodes with weaker upload capabilities while receiving pushes from stronger nodes; the push list of the node with the weakest upload capability may be empty.

[0192] To minimize the average upgrade time for all servers to be upgraded, it's necessary to consider the uplink and downlink bandwidth of each server, as well as the overall efficiency of P2P distribution between servers. This configuration fully satisfies the goal of optimal chunk size allocation.

[0193] Servers with strong upload capabilities: allocate larger chunks to enable faster data distribution.

[0194] Servers with high download capacity: allocate smaller chunks so that they can download missing data faster.

[0195] Global bandwidth utilization: Avoid a single server becoming a bottleneck and maximize the efficiency of parallel transmission.

[0196] In this embodiment, the upload capability factor of the server to be upgraded is calculated using uplink and / or downlink bandwidth. This upload capability factor reflects the server's ability to push data and its efficiency in receiving data. This embodiment first calculates the upload capability factor using uplink and downlink bandwidth, then calculates the block weight based on the upload capability factors of all nodes to determine the firmware block proportion of a single node. Finally, a push list is created based on the principle of pushing from nodes with high upload capability to nodes with low upload capability. Using upload capability as the core basis for block allocation and push, nodes with strong upload capability undertake more distribution tasks and are allocated larger blocks, fully leveraging the resource advantages of high-bandwidth nodes, while allowing low-bandwidth nodes to only receive pushes, reducing their transmission pressure. The upload capability factor quantifies and ranks the upload capabilities of nodes, providing a clear basis for targeted pushes, making peer-to-peer (P2P) pushes more targeted, maximizing bandwidth resource utilization, improving distribution efficiency, increasing global resource utilization, and thus improving firmware upgrade efficiency.

[0197] In one possible implementation, the performance metric information also includes the average access traffic within a preset upgrade time window; correspondingly, based on the upload capability factors of multiple servers to be upgraded, the block weight of each server to be upgraded is calculated, including: normalizing the upload capability factors of multiple servers to be upgraded to obtain a normalized bandwidth factor for each server to be upgraded; normalizing the average access traffic of multiple servers to be upgraded to obtain a normalized traffic factor for each server to be upgraded; and determining the block weight of each server to be upgraded based on the normalized bandwidth factor and the normalized traffic factor.

[0198] Here, the embodiments of this application take into account the traffic characteristics of the server to be upgraded and satisfy the following block partitioning strategy: the node with greater traffic is allocated a larger block, so that it can complete the upgrade with complete blocks more quickly.

[0199] This application's embodiments, based on network capability indicators, supplement the average access traffic within a preset upgrade time window with a service load indicator. This overcomes the limitations of traditional technologies that do not consider service factors, upgrading the calculation of block weights from a single upload capability dimension to a dual dimension of network capability and service load. This allows the block allocation strategy to adapt to differences in both network capability and service load, assigning higher block weights to nodes with higher traffic, thus combining service priority with upgrade efficiency and reducing the impact time of upgrades on critical services. Normalization processing eliminates differences in indicator dimensions, achieving dual optimization of resource utilization and service security in cluster upgrades, further improving resource utilization during firmware packet transmission and increasing firmware upgrade efficiency.

[0200] In one possible implementation, the upload capability factor of the server to be upgraded is calculated based on the uplink bandwidth and / or downlink bandwidth, including: determining the sum of the uplink bandwidth and downlink bandwidth as the total bandwidth; and calculating the quotient of the uplink bandwidth and the total bandwidth to obtain the upload capability factor of the server to be upgraded.

[0201] Here, this embodiment of the application allocates larger blocks to servers with strong upload capabilities through a specific upload capability factor calculation method, enabling them to distribute data faster, and allocates smaller blocks to servers with strong download capabilities, enabling them to download missing data faster. By quantifying the upload capability proportion of a single node using a relative value rather than an absolute value, the upload capability factor can be compared horizontally among nodes with different bandwidth configurations, providing a unified quantitative standard for subsequent block weighting and push list formulation. This avoids nodes with high absolute values ​​but low proportions being misjudged as high upload capability nodes, improving the accuracy of block allocation and push strategies, and further improving firmware upgrade efficiency.

[0202] In some possible implementations, block weighting is used in some embodiments. In this application embodiment, the bandwidth-block matching model is used to improve resource utilization and solve the bottleneck problem of low bandwidth nodes.

[0203] The firmware package will be adjusted based on the uplink bandwidth of the server to be upgraded. Downlink bandwidth Average access traffic over the current upgrade window (one month) The firmware is divided into blocks using a block size calculation formula. Each firmware block is transmitted to the server to be upgraded. The servers then push their own firmware blocks to other servers to be upgraded. Finally, the servers integrate these firmware blocks into a complete firmware package for upgrade.

[0204] The formula for calculating block weights is as follows:

[0205] Block weight Balanced any server to be upgraded The value of uploading If the upload speed is high, then a larger chunk will be allocated to utilize upload capacity and reduce download load. If the download speed is high, smaller chunks are allocated to increase the download size. Combined It explicitly optimizes the local latency of each server while implicitly satisfying global bandwidth constraints.

[0206] Block size Combined with the data size of the firmware upgrade package, it can meet the complete data transfer requirements.

[0207] This application provides an intelligent firmware upgrade method based on a bandwidth-block matching model. By comprehensively analyzing key performance indicators such as the server's uplink bandwidth, downlink bandwidth, and access traffic, the optimal firmware block size and allocation strategy are dynamically calculated. A P2P collaborative distribution mechanism is adopted to achieve rapid distribution and reorganization of firmware packages for upgrades. Differentiated block strategies can be implemented according to the network capabilities and load conditions of different servers, effectively solving the bottleneck problem of low-bandwidth nodes, maximizing global bandwidth utilization, and significantly shortening the overall upgrade time.

[0208] Figure 6 A flowchart illustrating the firmware upgrade method provided in this application embodiment. Figure 2 The execution entity for this method can be any of the aforementioned servers to be upgraded. Please refer to [link / reference]. Figure 6 The method may include:

[0209] S601: Receives firmware blocks and push lists sent by the master server.

[0210] The firmware block process involves the master server obtaining the firmware package to be upgraded and the performance metrics information of multiple servers to be upgraded. Based on the performance metrics information of multiple servers to be upgraded, the master server determines the block control strategy for each server to be upgraded. Then, based on the block weight, the firmware package to be upgraded is processed into blocks and sent according to the push list.

[0211] The block control strategy includes block weights and a push list, which includes at least one other server to be upgraded from among multiple servers to be upgraded.

[0212] The firmware block is one of several firmware blocks obtained by the master server dynamically dividing the complete firmware package to be upgraded into blocks based on the block weights of the servers to be upgraded. Each server to be upgraded receives only one dedicated firmware block during the initial distribution phase. The size of this firmware block is determined by the server's block weight; the higher the weight, the larger the allocated firmware block.

[0213] The push list is a list of push targets corresponding to each server to be upgraded, generated by the master server based on the performance metrics information of each server. The push list contains the identifier of at least one other server to be upgraded, indicating which nodes that server needs to push its firmware block to during the subsequent P2P exchange phase.

[0214] It should be noted that the firmware blocks and push lists received by the servers to be upgraded are customized; different servers receive different firmware block contents and push lists. This ensures the orderly and efficient operation of subsequent P2P exchanges.

[0215] After receiving the firmware block, the server to be upgraded can perform a preliminary integrity check on the local firmware block, such as checking whether the size matches and calculating the hash value, and temporarily store the firmware block in local memory or disk, waiting for subsequent P2P exchange.

[0216] S602: Push the firmware block to the server to be upgraded in the corresponding push list.

[0217] Alternatively, push operations can be implemented in various ways, such as:

[0218] Direct P2P transmission: The server to be upgraded establishes a direct TCP / UDP connection with the target server in the push list and sends the firmware block data in fragments.

[0219] P2P-based transmission: Data distribution is carried out using the existing P2P protocol, with the server to be upgraded acting as a seed node to provide data to other nodes.

[0220] Segmented Push: If the firmware block is large, it can be further divided into smaller sub-blocks and pushed in sequence, supporting resume from interrupted download.

[0221] Optionally, the server to be upgraded can determine the push priority based on the block weight or upload capability factor of each target server in the push list. For example, nodes with high block weights usually carry more critical services, so pushing data to them first can enable them to collect the complete firmware package faster, complete the upgrade first, and reduce the impact on services. For example, nodes with low upload capability factors have limited receiving capabilities, so pushing data to them as early as possible can allow them sufficient receiving time and prevent them from becoming a bottleneck in the overall progress.

[0222] S603: After receiving all firmware blocks, it generates a firmware package to be upgraded based on all firmware blocks to complete the firmware upgrade.

[0223] Optionally, after receiving all firmware blocks, this embodiment of the application can generate a firmware package to be upgraded based on information such as block number or data offset order. Then, the firmware upgrade is performed based on the firmware package to be upgraded.

[0224] In one possible implementation, after receiving all firmware blocks, an upgrade firmware package is generated based on all firmware blocks to complete the firmware upgrade, including: receiving firmware blocks sent by other upgrade servers; performing integrity verification on the firmware blocks to determine whether all firmware blocks have been received; and if it is determined that all firmware blocks have been received, generating an upgrade firmware package based on all firmware blocks.

[0225] Optionally, integrity verification may include quantity verification, representation verification, or data integrity verification.

[0226] The quantity check is used to verify whether the number of received firmware blocks is equal to the total number N of servers to be upgraded.

[0227] The identifier verification is used to check whether each block has been received, avoiding the repeated receipt of the same block while missing another block.

[0228] Among them, data integrity verification is used to calculate the hash value of each firmware block and compare it with the original hash value calculated by the master server when dividing the block to confirm that the data has not been damaged during transmission.

[0229] This application uses integrity verification as a prerequisite for firmware package reassembly, which can detect missing or damaged firmware blocks in advance, avoid upgrade failure due to invalid firmware packages, reduce upgrade rework, and shorten the overall upgrade time.

[0230] This application provides a firmware upgrade scheme for a server to be upgraded. After receiving firmware blocks from the master server, the server to be upgraded pushes the firmware package to other servers to be upgraded according to a push list. Finally, all firmware blocks are collected and reassembled into a complete firmware package to complete the upgrade. The server to be upgraded participates in data distribution, realizing full-cluster P2P collaboration, distributing the transmission pressure of the master server to all nodes, making full use of the uplink bandwidth resources of all nodes in the cluster, and executing according to the strategy set by the master server to ensure the orderliness and accuracy of the push, maximizing the utilization of global network resources and solving the problem of low resource utilization. Combined with targeted push according to the push list, network congestion caused by irregular P2P push is avoided, improving data transmission efficiency, shortening firmware block distribution time, and distributing the reassembly of firmware packages so that each node only needs to collect its own missing firmware blocks, reducing the download pressure of individual nodes and preventing low-bandwidth nodes from becoming bottlenecks. Through the above methods, the firmware upgrade efficiency is effectively improved.

[0231] In one possible implementation, after performing integrity checks on the firmware blocks to determine whether all firmware blocks have been received, the method further includes: if it is detected that not all firmware blocks have been received, identifying the missing firmware blocks; and requesting the master server and / or other servers to be upgraded to resend the missing firmware blocks.

[0232] This application embodiment enables the server to be upgraded to proactively discover faults and request repairs, actively detect missing firmware blocks, accurately locate problems, avoid blind waiting, shorten the upgrade time of faulty nodes, and, after discovering a fault, request retransmission from the master server and / or other nodes, providing dual retransmission channels. This achieves distributed self-healing of faults, further improving the efficiency and success rate of firmware upgrades.

[0233] Based on the core concept of the above-mentioned intelligent firmware upgrade method, the embodiments of this application can be further extended to scenarios such as data center operation and maintenance automation, edge computing node management, and large-scale cluster configuration synchronization. By introducing AI prediction algorithms to optimize the block strategy and combining blockchain technology to ensure the security and trustworthiness of the upgrade process, an intelligent distributed system operation and maintenance platform is built, realizing the evolution from single firmware upgrade to a comprehensive intelligent operation and maintenance ecosystem. This provides efficient software deployment and maintenance solutions for large-scale distributed systems such as cloud computing, the Internet of Things, and 5G base stations.

[0234] Figure 7 This is a schematic diagram of a firmware upgrade device provided in an embodiment of this application. The firmware upgrade device is applied to a main server. The firmware upgrade device 70 includes: an acquisition module 701, a determination module 702, a block segmentation module 703, and a sending module 704, wherein...

[0235] The acquisition module is used to acquire the firmware package to be upgraded and the performance metrics information of multiple servers to be upgraded.

[0236] The determination module is used to determine the block control strategy for each server to be upgraded based on the performance index information of multiple servers to be upgraded. The block control strategy includes block weights and a push list, which includes at least one other server to be upgraded among the multiple servers to be upgraded, excluding itself.

[0237] The segmentation module is used to segment the firmware package to be upgraded into multiple firmware blocks according to the segmentation weight.

[0238] The sending module is used to send firmware blocks and push lists to the corresponding servers to be upgraded, so that the servers to be upgraded can push firmware blocks to the servers to be upgraded in the corresponding push lists. After receiving all firmware blocks, the module generates a firmware package to be upgraded based on all firmware blocks to complete the firmware upgrade.

[0239] In one possible implementation, performance metrics information includes uplink bandwidth and / or downlink bandwidth.

[0240] In one possible implementation, the determining module is specifically used for:

[0241] Calculate the upload capability factor of the server to be upgraded based on the uplink bandwidth and / or downlink bandwidth;

[0242] Calculate the block weight of each server to be upgraded based on the upload capability factors of multiple servers to be upgraded.

[0243] For each server to be upgraded, other servers with upload capability factors lower than the server to be upgraded will be added to the corresponding push list.

[0244] In one possible implementation, the performance metrics information also includes the average access traffic within a preset upgrade time window;

[0245] Accordingly, the determination module is also specifically used for:

[0246] The upload capability factors of multiple servers to be upgraded are normalized to obtain the normalized bandwidth factor of each server to be upgraded.

[0247] The average access traffic of multiple servers to be upgraded is normalized to obtain the normalized traffic factor for each server to be upgraded.

[0248] The block weight of each server to be upgraded is determined based on the normalized bandwidth factor and the normalized traffic factor.

[0249] In one possible implementation, the determining module is further specifically used for:

[0250] The sum of the uplink bandwidth and the downlink bandwidth is determined as the total bandwidth;

[0251] Calculate the quotient of uplink bandwidth and total bandwidth to obtain the upload capacity factor of the server to be upgraded.

[0252] In one possible implementation, the block module is specifically used for:

[0253] Get the data size of the firmware package to be upgraded;

[0254] Based on the data size and block weight, calculate the allocated data size for each server to be upgraded; where the sum of the allocated data sizes of the servers to be upgraded is the data size.

[0255] Based on the size of the allocated data, the firmware package to be upgraded is divided into blocks to obtain multiple firmware blocks.

[0256] In one possible implementation, after the sending module sends the firmware block and push list to the corresponding server to be upgraded, the apparatus further includes a first detection module for:

[0257] Monitor the upgrade status of the server to be upgraded within a preset time period;

[0258] If the upgrade status is "upgrade unsuccessful", then a firmware block sending status check is triggered to determine if there are any firmware blocks that have not been sent successfully.

[0259] If it exists, resend the firmware block that was not successfully sent.

[0260] This application embodiment also provides a firmware upgrade device, which is applied to a server to be upgraded, and the firmware upgrade device includes:

[0261] The module consists of a receiving module, a pushing module, and a generating module.

[0262] The receiving module is used to receive firmware blocks and push lists sent by the master server. The firmware block is sent by the master server after obtaining the firmware package to be upgraded and the performance index information of multiple servers to be upgraded. Based on the performance index information of multiple servers to be upgraded, the master server determines the block control strategy for each server to be upgraded and, according to the block weight, blocks the firmware package to be upgraded and sends it according to the push list. The block control strategy includes block weights and a push list, and the push list includes at least one other server to be upgraded among the multiple servers to be upgraded, excluding itself.

[0263] The push module is used to push firmware blocks to the servers to be upgraded in the corresponding push list;

[0264] The generation module is used to generate a firmware package to be upgraded based on all firmware blocks after receiving them, so as to complete the firmware upgrade.

[0265] In one possible implementation, the generation module is specifically used for:

[0266] Receive firmware blocks sent by other servers to be upgraded;

[0267] Perform integrity checks on firmware blocks to determine if all firmware blocks have been received;

[0268] If it is determined that all firmware blocks have been received, then generate the firmware package to be upgraded based on all firmware blocks.

[0269] In one possible implementation, after the generation module performs integrity verification on the firmware blocks to determine whether all firmware blocks have been received, the above apparatus further includes a second detection module for:

[0270] If not all firmware blocks are received, the missing firmware blocks are identified.

[0271] Request the master server and / or other servers to be upgraded to resend the missing firmware blocks.

[0272] Figure 8 This is a schematic diagram of a computing device provided in an embodiment of this application. The computing device can be a main server or a server to be upgraded.

[0273] like Figure 8As shown, the computing device 50 may include a processor 51 and a memory 52, wherein the processor 51 and the memory 52 are coupled and can communicate with each other; for example, the processor 51 and the memory 52 communicate through a communication bus 53, the memory 52 is used to store computer execution instructions, and the processor 51 is used to call the computer execution instructions in the memory to execute the firmware upgrade method shown in the above method embodiment.

[0274] Optionally, the computing device 50 may also include a communication interface, which may include a transmitter and / or a receiver.

[0275] Optionally, the aforementioned processor can be a central processing unit (CPU), a graphics processing unit (GPU), other general-purpose processors, a digital signal processor (DSP), or an application-specific integrated circuit (ASIC), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0276] This application provides a computer-readable storage medium storing computer program instructions; when the program instructions are executed by an electronic device or a computing device, the computing electronic device or computing device performs the above-described firmware upgrade method.

[0277] This application provides a computer program product, which includes computer program instructions. When the computer program instructions are executed, they cause a computing electronic device or computing device to perform the firmware upgrade method described above.

[0278] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0279] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable terminal device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0280] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable terminal device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0281] These computer program instructions can also be loaded onto a computer or other programmable terminal device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0282] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, the embodiments of this application are also intended to include these modifications and variations.

[0283] In the embodiments 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. The term "or" and its variations can mean "and / or." In the embodiments of this application, the terms "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In the embodiments of this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0284] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the invention disclosed in the specification and in practice. The embodiments of this application are intended to cover any variations, uses, or adaptations of the embodiments of this application that follow the general principles of the embodiments of this application and include common knowledge or customary technical means in the art not disclosed in the embodiments of this application.

Claims

1. A firmware upgrade method, characterized in that, Applied to a master server, which communicates with multiple servers to be upgraded, the method includes: Obtain the firmware package to be upgraded and performance metrics information of multiple servers to be upgraded; Based on the performance metrics of the plurality of servers to be upgraded, a block control strategy is determined for each of the servers to be upgraded; wherein, the block control strategy includes block weights and a push list, and the push list includes at least one other server to be upgraded among the plurality of servers to be upgraded, excluding itself. According to the block weight, the firmware package to be upgraded is divided into blocks to obtain the firmware block corresponding to each server to be upgraded. The firmware block and the push list are sent to the corresponding server to be upgraded, so that the server to be upgraded pushes the firmware block to the server to be upgraded in the corresponding push list. After receiving all the firmware blocks, the firmware package to be upgraded is generated according to all the firmware blocks to complete the firmware upgrade.

2. The method according to claim 1, characterized in that, The performance metrics include uplink bandwidth and / or downlink bandwidth; Wherein, the block weight is positively correlated with the uplink bandwidth, and / or the block weight is negatively correlated with the downlink bandwidth.

3. The method according to claim 2, characterized in that, The step of determining the block control strategy for each of the multiple servers to be upgraded based on their performance metrics includes: Calculate the upload capability factor of the server to be upgraded based on the uplink bandwidth and / or the downlink bandwidth; Calculate the block weight of each of the servers to be upgraded based on the upload capability factors of the multiple servers to be upgraded; For each of the servers to be upgraded, other servers with upload capability factors lower than the server to be upgraded are added to the corresponding push list.

4. The method according to claim 3, characterized in that, The performance metrics information also includes the average access traffic within the preset upgrade time window. Accordingly, the step of calculating the block weight of each of the servers to be upgraded based on the upload capability factors of the multiple servers to be upgraded includes: The upload capability factors of the plurality of servers to be upgraded are normalized to obtain the normalized bandwidth factor of each of the servers to be upgraded. The average access traffic of the plurality of servers to be upgraded is normalized to obtain a normalized traffic factor for each of the servers to be upgraded. The block weight of each server to be upgraded is determined based on the normalized bandwidth factor and the normalized traffic factor.

5. The method according to any one of claims 1 to 4, characterized in that, The step of dividing the firmware package to be upgraded into multiple firmware blocks according to the block weight includes: Obtain the data size of the firmware package to be upgraded; Based on the data size and the block weight, calculate the allocated data size for each server to be upgraded; wherein, the sum of the allocated data sizes of the servers to be upgraded is the data size; Based on the allocated data size, the firmware package to be upgraded is divided into blocks to obtain multiple firmware blocks.

6. The method according to any one of claims 1 to 4, characterized in that, After sending the firmware block and the push list to the corresponding upgrade server, the process further includes: Monitor the upgrade status of the server to be upgraded within a preset time period; If the upgrade status is "upgrade unsuccessful", then a firmware block sending status detection is triggered to determine whether there are any firmware blocks that have not been successfully sent. If it exists, then resend the firmware block that was not successfully sent.

7. A firmware upgrade method, characterized in that, Applied to servers to be upgraded, the method includes: The system receives firmware blocks and push lists sent by the master server. The firmware blocks are generated by the master server after obtaining the firmware package to be upgraded and performance metrics information of multiple servers to be upgraded. Based on the performance metrics information of the multiple servers to be upgraded, the master server determines a block control strategy for each server to be upgraded, and then blocks the firmware package to be upgraded according to the block weights before sending it according to the push list. The block control strategy includes block weights and a push list, and the push list includes at least one other server to be upgraded among the multiple servers to be upgraded, excluding itself. The firmware block is pushed to the corresponding server in the push list to be upgraded; After receiving all firmware blocks, the firmware package to be upgraded is generated based on all the firmware blocks to complete the firmware upgrade.

8. The firmware upgrade method according to claim 7, characterized in that, The step of generating the firmware package to be upgraded based on all firmware blocks after receiving them, in order to complete the firmware upgrade, includes: Receive firmware blocks sent by other servers to be upgraded; The firmware blocks are subjected to integrity verification to determine whether all firmware blocks have been received; If it is determined that all firmware blocks have been received, then the firmware package to be upgraded is generated based on all the firmware blocks.

9. A computing device, characterized in that, The computing device includes a memory and a processor; The memory and the processor are coupled; The memory is used to store program instructions; The processor is used to invoke the program instructions to cause the computing device to perform the method as described in any one of claims 1-6.

10. A computing device, characterized in that, The computing device includes a memory and a processor; The memory and the processor are coupled; The memory is used to store program instructions; The processor is used to invoke the program instructions to cause the computing device to perform the method as described in claim 7 or 8.

Images