Method and system for remote batch upgrade of solid state disk firmware

Abstract

The application discloses a solid state disk firmware remote batch upgrade method and system, relates to the technical field of data storage, and discloses the solid state disk firmware remote batch upgrade method and system, which can effectively process the dependency constraints among solid state disks, perceive the system resource state in real time, thereby avoiding the service interruption and the risk of data integrity damage, and improving the solid state disk firmware remote batch upgrade efficiency and operation and maintenance reliability by acquiring storage topology data and system resource state data, constructing a storage topology dependency graph, and generating a scheduling scheme based on the storage topology dependency graph to execute an upgrade operation.

Description

Technical Field

[0001] This application relates to the field of data storage technology, and in particular to a method and system for remote batch firmware upgrade of solid-state drives. Background Technology

[0002] In server cluster environments, SSD firmware upgrades are a critical operational procedure for ensuring the security and performance of storage systems. Currently, the industry commonly employs manual intervention on a per-disk basis or basic batch script execution for upgrade tasks. These methods are only suitable for small-scale deployments. When scaled to distributed systems with a large number of nodes, their inherent shortcomings become apparent: First, complex logical dependencies exist between SSDs, such as RAID groups composed of multiple disks, cross-server storage pool configurations, or virtualization layer relationships. Existing technologies fail to effectively identify and handle these dependencies, often executing upgrades in simple parallel or linear order, leading to storage volume state splits, abnormal service interruptions, and potential data integrity breaches. Second, the upgrade process lacks awareness of the dynamic resource status of the server cluster, failing to assess key indicators such as CPU load, memory usage, and network bandwidth in real time. This can easily cause upgrade operations to excessively preempt business resources, leading to delays in normal service response or even service outages. Especially in high-reliability sectors such as finance and telecommunications, these issues directly threaten data security and service continuity. Existing solutions fail to establish a collaborative scheduling mechanism between storage topology dependencies and system resource status, making it difficult to balance upgrade efficiency and business impact, severely restricting the operational reliability of large-scale storage infrastructure.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method and system for remote batch firmware upgrade of solid-state drives (SSDs), which aims to improve the efficiency and reliability of remote batch firmware upgrades of SSDs.

[0005] To achieve the above objectives, this application proposes a method for remote batch firmware upgrade of solid-state drives, the method comprising: Obtain the storage topology data of the target server cluster and obtain system resource status data; Based on the storage topology data, a storage topology dependency graph is constructed; Based on the storage topology dependency graph and system resource status data, a solid-state drive upgrade scheduling scheme is generated using a scheduling algorithm. Based on the aforementioned solid-state drive upgrade scheduling scheme, a concurrent control upgrade operation is performed to obtain the upgrade result; An upgrade report is generated based on the upgrade results.

[0006] In one embodiment, obtaining the storage topology data of the target server cluster includes: Obtain the physical information of the solid-state drives of each server through the system management interface; Obtain the logical relationships of solid-state drives through storage management software; The storage topology data is obtained by merging the physical information and logical relationships of the solid-state drives (SSDs).

[0007] In one embodiment, the step of constructing a storage topology dependency graph based on the storage topology data includes: Based on the storage topology data, each solid-state drive is treated as a node, and the dependencies between solid-state drives are treated as edges, thus obtaining nodes and edges; Based on the logical dependencies in the stored topology data and the edges, determine the weight value of the edges; Based on the nodes, edges, and weight values, a directed acyclic graph structure is constructed. Based on the directed acyclic graph structure, the storage topology dependency graph is constructed.

[0008] In one embodiment, based on the storage topology dependency graph and system resource status data, generating a solid-state drive upgrade scheduling scheme through a scheduling algorithm includes: Based on the system resource status data, calculate the minimum resource quota required for each solid-state drive upgrade; Based on the storage topology dependency graph, the order constraints for upgrading solid-state drives are determined; Based on the minimum resource quota and priority constraints, an optimization objective function is established; Based on the aforementioned optimization objective function, an initial scheduling scheme is generated using a scheduling algorithm. The feasibility of the initial scheduling scheme was verified, and the verification results were obtained. Based on the verification results, when the verification is successful, the initial scheduling scheme will be used as the SSD upgrade scheduling scheme.

[0009] In one embodiment, the step of generating an initial scheduling scheme based on the optimization objective function using a scheduling algorithm includes: Based on the aforementioned sequence constraints, an initial scheduling sequence is generated; Based on the initial scheduling sequence and the optimization objective function, optimization is performed using a genetic algorithm, including: The initial scheduling sequence is encoded to obtain chromosome codes; Based on the chromosome encoding and the optimization objective function, the chromosome fitness is calculated; Based on the chromosome fitness, a selection operation is performed to select chromosomes from chromosome codes, resulting in the selected chromosomes. The selected chromosomes are subjected to a crossover operation to obtain the crossover chromosomes; The crossed-over chromosomes are subjected to mutation operations to obtain mutated chromosomes; Return to the step of calculating chromosome fitness based on the chromosome encoding and optimization objective function, until a preset termination condition is met, and the optimized chromosome is obtained; The optimized chromosome is decoded to obtain the initial scheduling scheme.

[0010] In one embodiment, the steps of performing concurrent control upgrade operations and obtaining upgrade results based on the solid-state drive upgrade scheduling scheme include: Based on the aforementioned solid-state drive upgrade scheduling scheme, a concurrent execution token is allocated to each upgrade task; Based on the concurrent execution token, the number of upgrade tasks executed simultaneously is controlled to obtain the upgrade task queue; Based on the upgrade task queue, a two-phase commit protocol upgrade operation is performed, including: During the preparation phase, based on the upgrade task queue, an upgrade preparation command is sent to the target solid-state drive, a readiness response is received, and the readiness response is stored. During the submission phase, based on the stored ready response, a formal upgrade command is sent, and upgrade completion confirmation information is received and stored. The upgrade result is generated based on the stored upgrade completion confirmation information.

[0011] In one embodiment, performing a two-phase commit protocol upgrade operation based on the upgrade task queue further includes: During the transaction log recording phase, transaction log records are created based on the upgrade task queue; During the rollback mechanism configuration phase, rollback operation instructions are configured based on the transaction log records. During the anomaly detection phase, based on the upgrade task queue and the stored readiness response information, anomalies in the upgrade process are detected, and anomaly detection results are obtained. During the exception handling phase, based on the exception detection results and rollback operation instructions, a rollback operation is executed when an exception is detected.

[0012] In one embodiment, the method further includes: Real-time monitoring of system load changes yields system load change data; Based on the system load change data, the priority of the ongoing upgrade tasks is dynamically adjusted to obtain the adjusted priority; Based on the system load change data and preset threshold data, when the system load exceeds the preset threshold, non-critical upgrade tasks are paused and a task pause status is generated. Based on the task pause status and system load change data, the paused upgrade task is resumed when the system load returns to the preset normal range.

[0013] In one embodiment, the method further includes: Based on the aforementioned solid-state drive upgrade scheduling scheme, CPU time slice quotas, memory usage quotas, and network bandwidth quotas are allocated to each upgrade task to obtain resource quotas; Based on the resource quota, the network traffic for the upgrade task is controlled using the token bucket algorithm, including: Based on preset configuration parameters, configure the token generation rate and token bucket capacity for each upgrade task; Based on the token generation rate, tokens are periodically added to the token bucket; Before sending upgrade data, the upgrade task obtains a token from the token bucket and controls the sending of upgrade data based on the obtained token; Monitor the resource usage of each upgrade task and obtain resource usage data; Based on the resource usage data and resource quota, when resource usage exceeds the quota, rate limiting will be implemented.

[0014] Furthermore, to achieve the above objectives, this application also proposes a remote batch upgrade system for solid-state drive firmware. The system includes a memory, a processor, and a remote batch upgrade program for solid-state drive firmware stored on the memory and executable on the processor. The program is configured to implement the steps of the remote batch upgrade method for solid-state drive firmware.

[0015] The method and system for remote batch upgrade of solid-state drive firmware proposed in this application acquire storage topology data and system resource status data, construct a storage topology dependency graph, and generate a scheduling scheme based on this graph to execute the upgrade operation. This method can effectively handle the dependency constraints between solid-state drives, perceive the system resource status in real time, thereby avoiding the risks of service interruption and data integrity damage, and improving the efficiency and reliability of remote batch upgrade of solid-state drive firmware. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the method for remote batch firmware upgrade of solid-state drives according to this application. Figure 2 This is a schematic diagram of a structure provided for an embodiment of the solid-state drive firmware remote batch upgrade system of this application.

[0019] Explanation of icon numbers: 10. Memory; 20. Processor.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of this application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] It should be understood that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] In existing technologies, firmware upgrade methods for server cluster solid-state drives (SSDs) typically rely on manual operation or simple scripts. In large-scale distributed environments, when faced with complex logical dependencies between SSDs, these methods easily overlook dependency constraints, leading to inconsistent system states, upgrade interruptions, or data corruption. Furthermore, the lack of dynamic awareness and scheduling of system resources may result in excessive resource consumption, impacting business operations.

[0024] Based on this, the embodiments of this application provide a method for remote batch firmware upgrade of solid-state drives, referring to... Figure 1 The method for remote batch upgrade of solid-state drive firmware includes steps S100 to S500, wherein: Step S100: Obtain the storage topology data of the target server cluster and obtain the system resource status data; Step S200: Based on the storage topology data, construct a storage topology dependency graph; Step S300: Based on the storage topology dependency graph and system resource status data, a solid-state drive upgrade scheduling scheme is generated using a scheduling algorithm; Step S400: Based on the solid-state drive upgrade scheduling scheme, perform concurrent control upgrade operations to obtain upgrade results; Step S500: Based on the upgrade results, generate an upgrade report.

[0025] In this embodiment, storage topology data refers to a set of data describing the solid-state drives (SSDs) in the server cluster and their logical and physical connections. This data may include physical information such as the SSD model, capacity, and serial number, as well as their logical organization at the RAID group, storage pool, and file system levels. System resource status data refers to real-time or periodic monitoring data of various computing resources in the server cluster. This data may include information such as CPU utilization, memory usage, network bandwidth consumption, and disk I / O load, used to assess the current workload and available resources of the system. The storage topology dependency graph is a graphical representation where each node represents an SSD, and edges represent dependencies between SSDs. These dependencies can be physical connections, logical groupings, or business associations, used to identify the order or concurrency limits that must be followed during upgrades.

[0026] In this embodiment, the scheduling algorithm refers to a computational method used to optimize task execution order and resource allocation under given constraints. In this embodiment, the algorithm aims to generate an efficient and secure upgrade sequence based on the dependencies of the solid-state drives (SSDs) and the system resource status. The SSD upgrade scheduling scheme refers to a series of instructions and parameters generated by the scheduling algorithm, specifying in detail the upgrade time, order, concurrency, and required resource allocation for each SSD. This scheme aims to ensure a smooth upgrade process and minimize the impact on business operations. Concurrency control upgrade operations refer to limiting the number of SSDs or tasks being upgraded simultaneously during the upgrade process. This operation aims to avoid system resource exhaustion or instability caused by upgrading too many devices simultaneously. The upgrade result refers to the status information of each upgrade task recorded by the system after the SSD firmware upgrade operation is completed. This information may include statuses such as upgrade success, failure, partial success, or rollback, as well as related error codes or logs. The upgrade report is a summary document of the entire remote batch upgrade process of the SSD firmware. This report may include information such as the upgrade scheme, execution details, upgrade result statistics, anomaly records, and system status changes, for auditing and subsequent analysis.

[0027] In this embodiment, the method for remote batch firmware upgrade of solid-state drives (SSDs) first obtains the storage topology data and system resource status data of the target server cluster. The storage topology data can be obtained manually, for example, by the administrator manually collecting the physical and logical information of each SSD and organizing it into structured data. The system resource status data can be obtained by periodically querying the server's operating system logs or using simple monitoring scripts, for example, by executing commands at fixed time intervals to obtain and record CPU utilization and memory usage.

[0028] In this embodiment, a storage topology dependency graph is constructed based on the storage topology data. This process can be easily achieved by analyzing manually entered storage topology data to identify direct logical relationships between solid-state drives (SSDs). For example, if two SSDs belong to the same RAID group, an edge is created in the graph to represent their dependency. The graph can be constructed using data structures such as adjacency matrices or adjacency lists.

[0029] In this embodiment, a solid-state drive (SSD) upgrade scheduling scheme is generated based on the storage topology dependency graph and system resource status data using a scheduling algorithm. This scheduling algorithm can be a simple greedy algorithm, for example, prioritizing the upgrade of SSDs with no dependencies, or selecting the SSD on the server with the lowest current system resource load for upgrade. When generating the scheduling scheme, a simple priority ranking can be performed based on the type or importance of the SSDs, and then scheduling can be carried out according to this priority order.

[0030] In this embodiment, based on the solid-state drive (SSD) upgrade scheduling scheme, a concurrent control upgrade operation is performed to obtain the upgrade result. Concurrency control can be achieved by setting a fixed maximum concurrency; for example, the system always allows only N SSDs to be upgraded simultaneously. Once one SSD has been upgraded, the next SSD is retrieved from the upgrade queue for upgrade, and this process continues until all SSDs have been upgraded. The upgrade result can be determined by monitoring the upgrade status code of each SSD; for example, a return value of "0" indicates success, and a return value of "1" indicates failure.

[0031] In this embodiment, an upgrade report is generated based on the upgrade results. The upgrade report can be generated by simply summarizing the upgrade status of all solid-state drives (SSDs) into a text file, for example, listing the serial number of each SSD and its corresponding success or failure status. This report can be provided to the administrator to understand the overall situation of this batch upgrade.

[0032] In this embodiment, the remote batch firmware upgrade method for solid-state drives (SSDs) effectively solves the dependency neglect and resource consumption problems of traditional SSD firmware upgrade methods in large-scale distributed environments. By acquiring storage topology data and system resource status data, a storage topology dependency graph is constructed, and an upgrade scheduling scheme is generated based on this graph, thereby executing concurrent control upgrades. This effectively avoids the risk of system state inconsistencies and data corruption caused by blind upgrades. Simultaneously, through scheduling and concurrency control, the impact of the upgrade process on normal server operations is reduced, improving the reliability and efficiency of large-scale SSD firmware batch upgrades.

[0033] In one feasible implementation, obtaining the storage topology data of the target server cluster includes: obtaining the physical information of the solid-state drives (SSDs) of each server through the system management interface; obtaining the logical relationships of the SSDs through storage management software; and merging the physical information and logical relationships of the SSDs to obtain the storage topology data.

[0034] In this embodiment, the physical information of the solid-state drives (SSDs) of each server is obtained through the system management interface. This step aims to obtain the underlying hardware attributes of the SSDs. The system management interface may include, but is not limited to, the Intelligent Platform Management Interface (IPMI), the Redfish interface, proprietary management APIs provided by the manufacturer, and operating system-level command-line tools (such as `lsscsi`, `smartctl`, `nvme list`, etc. in Linux systems). Through these interfaces, detailed information such as the unique identifier (e.g., serial number), model, firmware version, capacity, physical connection type (e.g., SATA, SAS, NVMe), connected controller information, and physical location within the server chassis of each SSD can be obtained. This physical information is the basis for identifying and locating the SSDs.

[0035] In this embodiment, the logical relationships of solid-state drives (SSDs) are obtained through storage management software. This step is used to reveal how SSDs are organized and used at the logical level. Storage management software can encompass various types, such as Logical Volume Managers (LVM), hardware or software RAID controller management tools, management interfaces for distributed storage systems (such as Ceph and GlusterFS), and storage management modules for virtualization platforms (such as VMware vSAN and OpenStack Cinder). Through this software, information such as how SSDs are combined into logical volumes, RAID arrays, storage pools, file systems, or virtual disks can be obtained, as well as the dependencies between these logical entities. For example, a logical volume may consist of multiple physical SSDs, and a file system may be mounted on a logical volume.

[0036] Based on this, the physical information and logical relationships of the solid-state drives (SSDs) are merged to obtain the storage topology data. This step integrates and correlates the previously acquired physical and logical layer data. The merging process typically involves data cleaning, format standardization, and correlation matching. For example, the unique identifier of the SSD (such as a serial number or device path) can be used as a correlation key to match physical information with logical relationships. The merged data forms a unified and complete storage topology model that clearly shows the detailed attributes of each physical SSD, its logical role in the entire storage system, and its dependencies on other storage components. This merging process ensures the comprehensiveness and consistency of the storage topology data, providing an accurate global view for subsequent upgrade scheduling.

[0037] In this embodiment, the above-described technical solution refines the acquisition of storage topology data for the target server cluster into obtaining the physical information and logical relationships of the solid-state drives (SSDs) separately, and then merges these information. This solves the problem of obtaining comprehensive and accurate storage topology data in complex storage environments. Specifically, obtaining physical information through the system management interface ensures a clear understanding of the hardware attributes of each SSD, providing precise hardware targets for subsequent firmware upgrades. Simultaneously, obtaining logical relationships through storage management software reveals the logical organizational structure and dependencies of the SSDs, such as which SSDs form a RAID array or which SSDs carry critical business data. Merging these two types of information constructs a complete storage topology that includes both physical details and logical connections, avoiding upgrade risks caused by missing or inconsistent information. This comprehensive storage topology data makes the subsequent construction of the storage topology dependency graph more accurate, and the generated SSD upgrade scheduling scheme can fully consider all dependencies at the physical and logical levels, thereby improving the reliability, security, and efficiency of batch firmware upgrades and effectively reducing the risk of data loss or business interruption during the upgrade process.

[0038] In one feasible implementation, the step of constructing a storage topology dependency graph based on the storage topology data includes: taking each solid-state drive (SSD) as a node and the dependencies between SSDs as edges based on the storage topology data, to obtain nodes and edges; determining the weight values ​​of the edges based on the logical dependencies in the storage topology data and the edges; constructing a directed acyclic graph (DAG) structure based on the nodes, edges, and weight values; and constructing the storage topology dependency graph based on the DAG structure.

[0039] In this embodiment, when constructing the storage topology dependency graph, the system first abstracts each solid-state drive (SSD) in the storage system. The system treats each SSD in the target server cluster as an independent entity and abstracts it as a "node" in the graph structure. Simultaneously, the system analyzes the various logical or physical relationships between these SSDs. For example, the data on one SSD may depend on the normal operation of another SSD, or the upgrade of one SSD can only be performed after the upgrade of another SSD is completed. These relationships are abstracted as "edges" connecting different nodes to represent the dependencies between SSDs. For instance, by parsing information about RAID configuration, Logical Volume Management (LVM), or file system mount points in the storage topology data, it can identify which SSDs are members of a RAID group, which are its hot spares, or which SSDs carry the operating system while others carry application data, thus clarifying the direction and relationship of their dependencies.

[0040] In this embodiment, simply identifying the dependencies (edges) between solid-state drives (SSDs) is insufficient. To perform more refined upgrade scheduling, it is also necessary to quantify the importance or priority of these dependencies. Therefore, the system assigns a weight value to each edge based on the logical dependencies reflected in the storage topology data and the identified edges. This weight value can reflect the strength of the dependency, the priority of the upgrade, the degree of impact on system stability, or the time and resources required for the upgrade. For example, dependencies between SSDs carrying core business data or critical system components can be assigned higher weight values ​​to ensure their upgrade priority and security; while dependencies on non-critical data or log disks can be assigned lower weight values. The weight values ​​can be set based on preset policies, administrator configurations, or dynamically calculated according to the importance of the SSDs in the storage hierarchy.

[0041] In this embodiment, after acquiring all solid-state drive nodes, their directed dependencies, and the weights of these edges, the system further organizes these elements into a Directed Acyclic Graph (DAG) structure. A DAG is a special type of graph where all edges have a clear direction and there are no cycles. This structure effectively represents the sequence and dependencies between tasks, ensuring that the execution path of the upgrade task is clear and loop-free. During the construction process, the system performs cycle detection. If any circular dependencies are found, appropriate actions are taken (e.g., alerts, breaking cycles according to preset rules) to ensure the graph's validity and avoid deadlocks or infinite loops during upgrade scheduling.

[0042] In this embodiment, the final step, through the above steps, integrates all solid-state drive nodes, weighted directed dependency edges, and the structural characteristics of the directed acyclic graph to form a complete storage topology dependency graph. This graph is a comprehensive, accurate, and structured model that clearly depicts the interdependencies of all solid-state drives in the target server cluster, the order of upgrades, and the importance of each dependency. This storage topology dependency graph will serve as the core input for subsequent scheduling algorithms to generate solid-state drive upgrade scheduling schemes, providing a solid foundation for achieving efficient, secure, and reliable batch firmware upgrades.

[0043] In this embodiment, by employing the aforementioned technical solution, this application overcomes the potential blindness and inaccuracy of traditional methods in constructing storage topology dependency graphs. By abstracting each solid-state drive (SSD) as a node and the dependencies between SSDs as directed edges with weighted values, ultimately constructing a directed acyclic graph (DAG), this application ensures that the generated storage topology dependency graph comprehensively, accurately, and logically reflects the true dependencies and priorities between SSDs. This not only avoids upgrade conflicts or system failures caused by improper dependency identification but also provides precise input for subsequent scheduling algorithms, making the generated SSD upgrade scheduling scheme more reasonable and efficient. This improves the success rate of firmware batch upgrades and system stability, while reducing risks during the upgrade process.

[0044] In one feasible implementation, generating a solid-state drive (SSD) upgrade scheduling scheme based on the storage topology dependency graph and system resource status data using a scheduling algorithm includes: calculating the minimum resource quota required for each SSD upgrade based on the system resource status data; determining the order constraints for SSD upgrades based on the storage topology dependency graph; establishing an optimization objective function based on the minimum resource quota and the order constraints; generating an initial scheduling scheme using a scheduling algorithm based on the optimization objective function; verifying the feasibility of the initial scheduling scheme to obtain verification results; and using the initial scheduling scheme as the SSD upgrade scheduling scheme when the verification is successful.

[0045] In this embodiment, when calculating the minimum resource quota required for each SSD upgrade, system resource status data may include information such as CPU utilization, memory usage, network bandwidth, and I / O throughput. The minimum resource quota can be estimated based on factors such as the size of the firmware upgrade package, the I / O mode during the upgrade process, the SSD model and performance parameters, combined with historical upgrade data or preset empirical values. For example, different SSD models may require different amounts of memory or CPU processing power for firmware upgrades. This calculation process aims to determine a baseline resource requirement for each SSD upgrade task to avoid upgrade failures or performance bottlenecks due to insufficient resources.

[0046] In this embodiment, when determining the order constraints for SSD upgrades, the storage topology dependency graph clearly depicts the hierarchical relationships and data flow between SSDs. For example, one SSD may act as a cache for another, or multiple SSDs may form a RAID array. Determining the order constraints requires analyzing these dependencies. For instance, SSDs dependent on by upper-layer applications should be upgraded before application-layer SSD upgrades; upgrades of member disks in a RAID group may require following a specific order or synchronization mechanism. These constraints can be represented as directed edges, indicating that the upgrade of one SSD must occur after the upgrade of another.

[0047] In this embodiment, the objective function is a mathematical expression that quantifies various performance metrics of the scheduling scheme. For example, the objective can be to minimize the total time required to complete all SSD upgrades, while considering resource quota limitations and sequential constraints. This function can be a multi-objective function, such as simultaneously minimizing the total upgrade time and maximizing system availability. During construction, resource quotas can be treated as hard constraints (must be satisfied), sequential constraints as preconditions, and upgrade time, resource utilization, etc., as target variables to be optimized.

[0048] In this embodiment, when generating the initial scheduling scheme using the scheduling algorithm, the scheduling algorithm can be a variety of mature optimization algorithms, such as greedy algorithms, heuristic algorithms, linear programming, integer programming, or genetic algorithms as mentioned in subsequent embodiments. Guided by the optimization objective function, the algorithm combines minimum resource quotas and priority constraints to attempt to generate a feasible solid-state drive upgrade sequence and time allocation scheme. For example, the algorithm can prioritize scheduling solid-state drives with lower resource requirements or fewer dependencies, or it can use dynamic programming to gradually construct the scheduling scheme.

[0049] In this embodiment, the feasibility verification of the initial scheduling scheme includes simulated execution or logical checks. For example, it checks whether the total resources required by all concurrent upgrade tasks exceed the actual available resources of the system at any given time; whether the sequential constraints of all solid-state drives are met; and whether the upgrade process will lead to critical service interruptions or data unavailability. The verification process can be based on a preset system model and rules, outputting a boolean value (pass / fail) or a detailed verification report.

[0050] In this embodiment, based on the verification results, when the verification passes, the initial scheduling scheme is adopted as the SSD upgrade scheduling scheme. If the initial scheduling scheme passes all feasibility verifications, it indicates that the scheme is safe and executable, and can be adopted as the final SSD upgrade scheduling scheme. If the verification fails, it may be necessary to adjust the parameters of the scheduling algorithm, rebuild the optimization objective function, or make local modifications to the initial scheduling scheme, and then perform verification again until a scheme that passes verification is found.

[0051] In this embodiment, through the above technical solution, when generating a solid-state drive (SSD) upgrade scheduling scheme, this application can fully consider the minimum resource quota required for each SSD upgrade, avoiding upgrade failures or system overload due to insufficient resources. Simultaneously, by determining the upgrade order constraints based on the storage topology dependency graph, it effectively avoids data consistency issues or service interruption risks caused by improper handling of dependencies. By establishing a comprehensive optimization objective function and generating an initial scheduling scheme based on it, the scheduling result not only meets basic technical requirements but also achieves better performance in terms of upgrade time and resource utilization. Furthermore, rigorous feasibility verification of the initial scheduling scheme ensures that the final generated SSD upgrade scheduling scheme is safe, reliable, and practically executable, improving the success rate and efficiency of firmware batch upgrades, reducing potential risks during the upgrade process, and thus ensuring the stable operation of the server cluster.

[0052] In one feasible implementation, the step of generating an initial scheduling scheme based on the optimization objective function using a scheduling algorithm includes: generating an initial scheduling sequence based on the order constraints; optimizing the initial scheduling sequence and the optimization objective function using a genetic algorithm, including: encoding the initial scheduling sequence to obtain chromosome codes; calculating chromosome fitness based on the chromosome codes and the optimization objective function; selecting chromosomes from the chromosome codes through a selection operation based on the chromosome fitness to obtain selected chromosomes; performing a crossover operation on the selected chromosomes to obtain crossover chromosomes; performing a mutation operation on the crossover chromosomes to obtain mutated chromosomes; returning to the step of calculating chromosome fitness based on the chromosome codes and the optimization objective function until a preset termination condition is met to obtain optimized chromosomes; and decoding the optimized chromosomes to obtain the initial scheduling scheme.

[0053] In this embodiment, when generating the initial scheduling sequence, a topological sorting algorithm can be used to process the storage topology dependency graph to ensure that the generated sequence satisfies the sequential constraints of all solid-state drive upgrades. For example, methods such as the Kahn algorithm or depth-first search (DFS) can be used to gradually construct a linear sequence that satisfies the dependencies, starting from the node with an in-degree of zero in the graph. This initial scheduling sequence will serve as one or more individuals in the initial population of the genetic algorithm.

[0054] In this embodiment, when encoding the initial scheduling sequence to obtain chromosome codes, integer encoding or permutation encoding is typically used. For example, if the scheduling sequence contains N solid-state drive (SSD) upgrade tasks, each task can be assigned a unique integer identifier. Then, a chromosome can be represented as a permutation of these N integer identifiers, such as [3, 1, 4, 2] representing the upgrade order of SSDs 3, 1, 4, and 2. This encoding method can intuitively represent the execution order of the upgrade tasks.

[0055] In this embodiment, when calculating chromosome fitness based on chromosome encoding and an optimization objective function, the fitness function is crucial for evaluating the performance of the scheduling scheme. The optimization objective function may aim to minimize total upgrade time, minimize resource consumption, or maximize concurrency. For a given upgrade sequence represented by a chromosome encoding, the system simulates the execution of that sequence, calculates its corresponding total upgrade time, resource consumption, and other performance metrics, and substitutes these metrics into the optimization objective function to obtain a target value. The fitness function transforms this target value; for example, if the goal is to minimize the total upgrade time, the fitness can be set as the reciprocal of the total upgrade time to ensure that a higher fitness value indicates a better scheme.

[0056] In this embodiment, when selecting chromosomes from chromosome codes based on chromosome fitness through a selection operation, the selection operation aims to select individuals with higher fitness from the current population, giving them a greater chance of being passed on to the next generation. Common selection methods include roulette wheel selection and tournament selection. Roulette wheel selection allocates selection probabilities according to the fitness ratio of chromosomes, with chromosomes with higher fitness being more likely to be selected. Tournament selection randomly selects K chromosomes, and then selects the one with the highest fitness from these K chromosomes as the parent.

[0057] In this embodiment, when performing a crossover operation on the selected chromosomes to obtain the crossover chromosome, the crossover operation simulates gene recombination in biological reproduction. It generates new offspring chromosomes by exchanging partial genes from two parent chromosomes, thereby exploring new solution spaces. For permutation encoding, commonly used crossover operations include order crossover (OX) and partially mapped crossover (PMX). Order crossover typically involves randomly selecting two crossover points, copying the fragments from the first parent chromosome between the crossover points to the offspring, and then filling the unfilled positions in the offspring according to the order of the remaining elements in the second parent chromosome.

[0058] In this embodiment, when performing mutation operations on the crossed-out chromosomes to obtain the mutated chromosomes, the mutation operation simulates gene mutation, randomly changing certain genes on the chromosomes with a small probability, increasing population diversity and preventing the algorithm from getting trapped in local optima. For permutation encoding, common mutation operations include exchange mutation, insertion mutation, and inversion mutation. Exchange mutation randomly selects two positions on the chromosome and swaps the genes on them.

[0059] In this embodiment, the genetic algorithm is an iterative process that returns to the step of calculating chromosome fitness based on chromosome encoding and an optimized objective function, until a preset termination condition is met, resulting in an optimized chromosome. The termination condition may include reaching the maximum number of iterations, the best fitness value in the population not significantly improving over multiple generations, the found solution meeting preset performance requirements, or reaching a preset computation time limit.

[0060] In this embodiment, the optimized chromosome is finally decoded to obtain the initial scheduling scheme. If integer encoding or permutation encoding is used, the decoding process is usually direct. For example, an optimized chromosome [1, 3, 2, 4] is directly decoded into the upgrade order of solid-state drives 1, 3, 2, 4, and combined with their resource requirements and time constraints, a specific upgrade scheduling scheme is formed, including the upgrade start time, end time, and required resources for each solid-state drive.

[0061] In this embodiment, a genetic algorithm is introduced to optimize the initial scheduling scheme. This method can effectively cope with the complex resource quotas and strict sequence constraints in the batch upgrade process of solid-state drives. By simulating the process of natural selection and gene evolution, the genetic algorithm performs efficient search in a vast solution space, thereby finding the globally optimal or near-globally optimal scheduling sequence. This improves the quality of the initial scheduling scheme, enabling the solid-state drive upgrade task to allocate resources more rationally and execute more efficiently. This shortens the overall upgrade time, improves the utilization rate of system resources, and effectively reduces the risks caused by improper scheduling during the upgrade process, ensuring the stability and reliability of the upgrade process.

[0062] In one feasible implementation, the steps of performing concurrent control upgrade operations and obtaining upgrade results based on the solid-state drive upgrade scheduling scheme include: allocating a concurrent execution token to each upgrade task based on the solid-state drive upgrade scheduling scheme; controlling the number of upgrade tasks executed simultaneously based on the concurrent execution token to obtain an upgrade task queue; and performing a two-phase commit protocol upgrade operation based on the upgrade task queue, including: in the preparation phase, sending an upgrade preparation command to the target solid-state drive based on the upgrade task queue, receiving a readiness response, and storing the readiness response; in the commit phase, sending a formal upgrade command based on the stored readiness response, receiving and storing upgrade completion confirmation information; and generating the upgrade result based on the stored upgrade completion confirmation information.

[0063] In this embodiment, during the remote batch upgrade of solid-state drive firmware, to effectively manage concurrent tasks, the system allocates a concurrent execution token to each upgrade task to be executed. This token can be regarded as a credential for the task to obtain execution permission. For example, the system can maintain a token pool. When an upgrade task is ready to execute, it needs to obtain a token from the token pool. If there are no available tokens in the token pool, the task must wait. This mechanism can macroscopically limit the total number of upgrade tasks running simultaneously, avoiding resource contention and system overload caused by too many tasks. Through the above-mentioned concurrent execution token allocation and recycling mechanism, the system can accurately control the number of upgrade tasks executed simultaneously at any given time. For example, a maximum concurrency can be preset, and the number of tokens in the token pool is this maximum concurrency. When a task completes or fails and releases a token, the task in the waiting queue can obtain a token and start execution. This ensures that system resources (such as CPU, memory, and network bandwidth) are utilized within a controllable range, maintaining system stability and upgrade efficiency. When upgrade tasks cannot be executed immediately due to insufficient concurrent execution tokens, they will be placed in an upgrade task queue. This queue typically employs a first-in, first-out (FIFO) strategy, ensuring that tasks wait for execution in the order of submission or according to a preset priority. By introducing a task queue, the system can smoothly handle sudden surges in upgrade requests, avoiding task loss or repeated retries due to insufficient resources, thereby improving the robustness of the upgrade process.

[0064] In this embodiment, to ensure the atomicity and consistency of batch firmware upgrades for solid-state drives (SSDs), a two-phase commit protocol is employed. This protocol is a distributed transaction protocol designed to guarantee that in a distributed system, all participants (i.e., the target SSDs) either complete all operations or all roll back to their initial state. This is crucial to avoiding an inconsistent system state due to upgrade failures of some SSDs. During the preparation phase of the two-phase commit protocol, the upgrade coordinator (typically an upgrade server) sends upgrade preparation instructions to all target SSDs involved in the upgrade. These instructions may include requiring SSDs to check their current state, reserve necessary storage space, lock firmware regions, and verify the compatibility of the new firmware. After completing these checks, each SSD returns a ready response to the coordinator, indicating whether it is ready to write the firmware. The coordinator collects and stores all ready responses from all SSDs as a basis for deciding whether to proceed to the next phase. If the coordinator receives "ready" responses from all target SSDs during the preparation phase, it enters the commit phase. At this point, the coordinator sends formal upgrade instructions to all SSDs, instructing them to begin writing the new firmware.

[0065] In this embodiment, after successfully writing the firmware, the solid-state drives (SSDs) send an upgrade completion confirmation message to the coordinator. The coordinator collects and stores this confirmation message to record the final upgrade status of each SSD. If any SSD fails to prepare during the preparation phase, the coordinator sends a rollback command, instructing all prepared SSDs to abandon the upgrade operation. After the submission phase, the system generates the final upgrade result based on the collected upgrade completion confirmation messages from all SSDs. This result details the upgrade status of each SSD (success, failure, rollback, etc.) and summarizes the overall success rate and failure rate of the entire batch upgrade operation. This upgrade result serves as an important basis for generating subsequent upgrade reports and provides system administrators with a clear upgrade overview.

[0066] In this embodiment, the above-described technical solution effectively addresses the challenges of concurrency control and consistency assurance in remote batch firmware upgrades. Specifically, by allocating a concurrent execution token to each upgrade task and controlling the number of simultaneously executed upgrade tasks, the system avoids resource exhaustion and system instability caused by excessive instantaneous concurrency, thus ensuring a smooth upgrade process. Furthermore, the introduction of a two-phase commit protocol ensures that during batch upgrades in a distributed solid-state drive cluster, all solid-state drives either successfully upgrade or remain unchanged, preventing data inconsistencies or system malfunctions caused by partial upgrade successes and failures. This mechanism improves the reliability, stability, and atomicity of batch firmware upgrades, reduces upgrade risks, simplifies post-upgrade state management, and provides technical support for the maintenance of large-scale solid-state drive clusters.

[0067] In one feasible implementation, the two-phase commit protocol upgrade operation based on the upgrade task queue further includes: in the transaction log recording phase, creating transaction log records based on the upgrade task queue; in the rollback mechanism configuration phase, configuring rollback operation instructions based on the transaction log records; in the anomaly detection phase, detecting anomalies during the upgrade process based on the upgrade task queue and stored ready response information, and obtaining anomaly detection results; and in the anomaly handling phase, executing a rollback operation when an anomaly is detected based on the anomaly detection results and the rollback operation instructions.

[0068] In this embodiment, during the transaction log recording phase, the system generates a unique transaction identifier for each upgrade task or the entire batch upgrade process. Then, all key operations related to that transaction, such as the initiation of the upgrade task, responses during the preparation phase, command sending during the commit phase, upgrade results, and any intermediate state changes, are recorded in a structured manner in persistent storage. These log records typically include detailed information such as timestamps, operation types, involved solid-state drive identifiers, operation parameters, and operation status, aiming to ensure the traceability of upgrade operations and provide a reliable basis for subsequent fault analysis, state recovery, or rollback operations.

[0069] In this embodiment, during the rollback mechanism configuration phase, the system automatically generates or configures corresponding rollback operation instructions based on the pre-upgrade state of each solid-state drive and the type of upgrade operation, either while creating transaction log records or after the upgrade scheduling scheme is generated. For example, if the upgrade operation is a firmware update, the rollback operation instructions may include instructions to restore to the old firmware version, clear temporary files generated during the upgrade process, or mark the solid-state drive as pending. These instructions are associated with transaction log records so that reverse operations can be accurately executed when needed, and the system predefines how to restore to the pre-upgrade state when the upgrade fails, ensuring system consistency.

[0070] In this embodiment, during the anomaly detection phase, the system continuously monitors the entire upgrade lifecycle. During the preparation phase, the system checks if the SSD returns the expected "ready" response; if a timeout occurs or an error code is returned, it is considered an anomaly. During the submission phase, the system continuously monitors the SSD's upgrade status, firmware version, performance metrics, and system logs. Anomaly types include, but are not limited to: firmware upgrade failure (e.g., firmware checksum error, write failure), SSD offline, sharp performance degradation, system resource exhaustion, network communication interruption, etc. Detection mechanisms may include heartbeat detection, status polling, log analysis, performance threshold monitoring, etc., aiming to promptly detect various faults or unexpected behaviors during the upgrade process and generate anomaly detection results containing detailed information such as the anomaly type, occurrence time, and involved SSD identifiers.

[0071] In this embodiment, during the anomaly handling phase, after the anomaly detection phase identifies an anomaly and generates an anomaly detection result, the system will search for rollback operation instructions related to the affected solid-state drives (SSDs) or upgrade tasks based on the result. Then, the system will initiate the rollback process, executing the corresponding recovery operations according to the preset rollback operation instructions. For example, if the firmware upgrade of a particular SSD fails, the system will attempt to restore its firmware to the version before the upgrade; if a serious problem occurs in the entire batch upgrade, the system may trigger rollback operations for all prepared or partially upgraded SSDs. The execution of the rollback operation should also be recorded in the transaction log to ensure its traceability, so that after an anomaly is detected, the pre-configured rollback mechanism can be used to restore the affected SSDs or the entire system to a consistent and usable state.

[0072] In this embodiment, by introducing transaction log recording, rollback mechanism configuration, anomaly detection, and anomaly handling through the above technical solutions, the problem of inconsistent system states caused by anomalies that may occur during the batch upgrade of solid-state drives (SSDs) is effectively solved. Transaction log recording ensures the traceability of the upgrade operation, providing a basis for subsequent fault analysis and recovery. The pre-configured rollback mechanism enables rapid and accurate recovery operations when anomalies are detected, restoring the affected SSDs or system to their stable state before the upgrade, avoiding system downtime or data corruption due to upgrade failure. The anomaly detection mechanism can monitor the upgrade process in real time, promptly identifying various potential problems, thus providing triggering conditions for anomaly handling. Overall, these measures collectively construct a robust upgrade fault-tolerant mechanism, improving the reliability, stability, and security of batch SSD upgrades, ensuring that the server cluster can maintain data consistency and business continuity even in the face of unforeseen upgrade anomalies.

[0073] In one feasible implementation, the method further includes: monitoring system load changes in real time to obtain system load change data; dynamically adjusting the priority of ongoing upgrade tasks based on the system load change data to obtain the adjusted priority; pausing non-critical upgrade tasks and generating a task pause state when the system load exceeds the preset threshold based on the system load change data and preset threshold data; and resuming the paused upgrade tasks when the system load returns to a preset normal range based on the task pause state and system load change data.

[0074] In this embodiment, real-time monitoring of system load changes and obtaining system load change data refers to the system continuously collecting and analyzing the resource usage of the server cluster or a single server, such as CPU utilization, memory usage, disk I / O throughput, and network bandwidth usage. This data can be collected periodically through operating system-provided performance monitoring tools (such as the ` / proc` filesystem, `top`, `vmstat` commands in Linux systems, or the Performance Monitor API in Windows systems), virtualization platform management interfaces (such as VMware vSphere API, OpenStack Nova API), or monitoring agents deployed on the server (such as Prometheus Node Exporter, Zabbix Agent). The collection frequency can be configured according to actual needs to ensure timely reflection of dynamic changes in system load.

[0075] In this embodiment, the priority of ongoing upgrade tasks is dynamically adjusted based on the system load change data. The adjusted priority refers to the real-time adjustment of the execution order or weight in resource contention of currently executing solid-state drive upgrade tasks based on the real-time monitored system load. For example, when system load increases, the priority of upgrade tasks not directly related to core business can be reduced, while the priority of upgrade tasks related to critical business can be increased to ensure the resource requirements of critical business are met. This adjustment can be achieved by modifying the priority queue in the task scheduler, adjusting task scheduling parameters (such as the nice value in Linux systems), or through resource management frameworks (such as QoS levels in Kubernetes).

[0076] In this embodiment, based on the system load change data and preset threshold data, when the system load exceeds the preset threshold, non-critical upgrade tasks are paused, generating a task pause state. This means that the system determines whether the current system is under high load based on pre-set resource usage limits (i.e., preset thresholds, such as CPU utilization exceeding 80% or memory utilization exceeding 90%). Once the system load data exceeds these preset thresholds, the system identifies which currently executing upgrade tasks are marked as "non-critical tasks" (e.g., classified according to the importance of the business carried by the solid-state drive, data sensitivity, etc.) and sends pause commands to these non-critical tasks. After receiving the pause command, the upgrade task stops the current firmware writing or data transmission operation, records the current upgrade progress, updates its status to "paused," and waits for the system load to return to normal.

[0077] In this embodiment, based on the task pause status and system load change data, when the system load recovers to a preset normal range, the paused upgrade task is resumed. This means that after pausing some upgrade tasks, the system continuously monitors the system load data. When the system load data remains below a preset normal range threshold (e.g., CPU utilization below 70%) for a period of time (e.g., several minutes), the system determines that the resource pressure has eased. At this time, the system retrieves all non-critical upgrade tasks in the "paused" state and sends a resume command to them. After receiving the resume command, the upgrade agent will continue the firmware upgrade operation from the previously recorded progress point and update the task status from "paused" to "in progress".

[0078] In this embodiment, through the above technical solution, the method can perceive the system's operating status in real time and flexibly adjust the execution strategy of the solid-state drive firmware upgrade task according to the dynamic changes in system load. When the system load increases, by dynamically adjusting the priority of upgrade tasks and suspending non-critical tasks, the impact of upgrade operations on core businesses is effectively avoided, ensuring the reasonable allocation of system resources and the stability of critical services. When the system load returns to normal, the suspended tasks can automatically resume execution, thereby improving the success rate and efficiency of batch firmware upgrades while ensuring system performance, reducing system risks caused by upgrade operations, and realizing intelligent and flexible management of the upgrade process.

[0079] In one feasible implementation, the method further includes: allocating CPU time slice quotas, memory usage quotas, and network bandwidth quotas to each upgrade task based on the solid-state drive upgrade scheduling scheme to obtain resource quotas; controlling the network traffic of upgrade tasks through a token bucket algorithm based on the resource quotas, including: configuring a token generation rate and token bucket capacity for each upgrade task based on preset configuration parameters; periodically adding tokens to the token bucket based on the token generation rate; obtaining tokens from the token bucket before sending upgrade data, and controlling the sending of upgrade data based on the obtained tokens; monitoring the resource usage of each upgrade task to obtain resource usage data; and performing rate limiting when resource usage exceeds the quota based on the resource usage data and resource quotas.

[0080] In this embodiment, a resource quota is obtained by allocating CPU time slice quotas, memory usage quotas, and network bandwidth quotas to each upgrade task. This resource quota refers to the pre-set upper limit on the CPU time, memory space, and network bandwidth that each SSD upgrade task can occupy during the upgrade process. The allocation of these quotas can be based on a comprehensive consideration of various factors, such as the type of SSD, the importance of the services it carries, the size of the upgrade package, the current load of the target server, and the expected upgrade completion time. For example, for SSDs carrying core services, a relatively high resource quota can be allocated to ensure the priority and efficiency of their upgrade process; while for SSDs carrying non-critical services, a lower quota can be allocated to avoid unnecessary resource contention for core services. These quotas can be statically set by the system administrator through the configuration interface, or dynamically calculated and adjusted by the system based on real-time operating status and preset strategies.

[0081] Based on this, a token bucket algorithm is used to control network traffic for upgrade tasks, aiming to smooth the network data transmission rate of upgrade tasks and prevent sudden traffic surges from impacting the network. This control process includes: First, based on preset configuration parameters, a token generation rate and token bucket capacity are configured for each upgrade task. The token generation rate determines the average network transmission rate allowed for the upgrade task, such as how many tokens are generated per second, with each token representing a certain amount of data bytes. The token bucket capacity defines the maximum number of tokens that the bucket can accumulate, which determines the maximum allowed burst traffic for the task. These parameters must comprehensively consider available network bandwidth, the priority of the upgrade task, and the system's tolerance for network latency. Second, the system periodically adds tokens to the token bucket corresponding to each upgrade task at the preset token generation rate. For example, a certain number of tokens are added to the bucket at fixed time intervals. Finally, when an upgrade task needs to send upgrade data, it first attempts to obtain tokens corresponding to the amount of data to be sent from its corresponding token bucket. If there are enough tokens in the bucket, the data can be sent immediately, and the corresponding number of tokens are removed from the bucket. If there are not enough tokens, the task will have to wait until enough tokens are available, or its data transmission will be delayed, thus ensuring that the network traffic of the upgrade task does not exceed its allocated bandwidth quota and effectively avoiding network congestion.

[0082] In this embodiment, the system continuously monitors the resource usage of each upgrade task to obtain resource usage data. This includes real-time collection and recording of actual resource consumption data for each upgrade task, such as CPU utilization, memory usage, and network sent / received bytes. This data can be periodically collected through performance monitoring interfaces provided by the operating system (such as `cgroups`, ` / proc` filesystem, or `perf` tool in Linux systems, and performance counters in Windows systems), monitoring APIs of the virtualization platform, or dedicated resource management agents deployed on the server. The collected data is aggregated, stored, and compiled into detailed resource usage data, providing a basis for subsequent resource management.

[0083] In this embodiment, based on the resource usage data and resource quotas, the system will implement rate limiting when resource usage exceeds the quota. This means that once the actual resource consumption (such as CPU, memory, or network bandwidth) of an upgrade task is detected to exceed its preset quota, the system will immediately take measures to limit its resource usage. For example, for CPU resources, rate limiting can be implemented by lowering the task's scheduling priority, limiting the number of available CPU cores, or directly limiting its CPU time slices through container technology (such as cgroups). For memory resources, when a task's memory usage exceeds the quota, the system can trigger a memory reclamation mechanism or limit the task's subsequent memory allocation requests. For network resources, in addition to the control of the token bucket algorithm itself, when the actual network bandwidth usage is monitored to exceed the quota, the token bucket parameters can be further dynamically adjusted (such as reducing the token generation rate), or the data packets of the task can be dropped or delayed at the network level. These rate limiting measures aim to force tasks to comply with their resource quotas, maintain the overall stability of the system, and prevent the abnormal behavior of a single task from affecting the normal operation of the entire system.

[0084] In this embodiment, by allocating specific CPU time slice quotas, memory usage quotas, and network bandwidth quotas to each upgrade task, and combining this with the token bucket algorithm for fine-grained control of network traffic, this application can effectively prevent individual or partial upgrade tasks from excessively consuming system resources. This ensures that system resources are rationally allocated and efficiently utilized during batch firmware upgrades of solid-state drives. Real-time monitoring of resource usage and over-quota throttling further guarantee the stability and controllability of the upgrade process, preventing upgrade tasks from impacting the performance of other critical services or causing network congestion. This not only improves the success rate and efficiency of firmware upgrades but also enhances the operational reliability of the entire server cluster, enabling batch upgrade operations to proceed smoothly without affecting the stability of the production environment.

[0085] In this embodiment, the method for remote batch upgrade of solid-state drive firmware constructs a storage topology dependency graph by acquiring storage topology data and system resource status data, and generates a scheduling scheme based on this graph to execute the upgrade operation. This method can effectively handle the dependency constraints between solid-state drives, perceive the system resource status in real time, thereby avoiding the risk of service interruption and data integrity damage, and improving the efficiency and reliability of remote batch upgrade of solid-state drive firmware.

[0086] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the remote batch upgrade method for solid-state drive firmware of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0087] This application also provides a system for remote batch firmware upgrade of solid-state drives, see reference. Figure 2 The solid-state drive firmware remote batch upgrade system includes: a memory 10, a processor 20, and a solid-state drive firmware remote batch upgrade program stored on the memory 10 and capable of running on the processor 20. The solid-state drive firmware remote batch upgrade program is configured to implement the steps of the solid-state drive firmware remote batch upgrade method.

[0088] The solid-state drive (SSD) firmware remote batch upgrade system provided in this application adopts the SSD firmware remote batch upgrade method in the above embodiments, which can improve the efficiency and reliability of remote batch upgrades of SSD firmware. Compared with the prior art, the beneficial effects of the SSD firmware remote batch upgrade system provided in this application are the same as those of the SSD firmware remote batch upgrade method provided in the above embodiments, and other technical features of the SSD firmware remote batch upgrade system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0089] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. All equivalent structural transformations made under the technical concept of this application using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the scope of patent protection of this application.

Claims

1. A method for remote batch firmware upgrade of solid-state drives, characterized in that, The method includes: Obtain the storage topology data of the target server cluster and obtain system resource status data; Based on the storage topology data, a storage topology dependency graph is constructed; Based on the storage topology dependency graph and system resource status data, a solid-state drive upgrade scheduling scheme is generated using a scheduling algorithm. Based on the aforementioned solid-state drive upgrade scheduling scheme, a concurrent control upgrade operation is performed to obtain the upgrade result; Based on the upgrade results, an upgrade report is generated; Based on the storage topology dependency graph and system resource status data, a solid-state drive upgrade scheduling scheme is generated through a scheduling algorithm, including: Based on the system resource status data, calculate the minimum resource quota required for each solid-state drive upgrade; Based on the storage topology dependency graph, the order constraints for upgrading solid-state drives are determined; Based on the minimum resource quota and priority constraints, an optimization objective function is established; Based on the aforementioned optimization objective function, an initial scheduling scheme is generated using a scheduling algorithm. The feasibility of the initial scheduling scheme was verified, and the verification results were obtained. Based on the verification results, when the verification is successful, the initial scheduling scheme will be used as the SSD upgrade scheduling scheme. Based on the aforementioned optimization objective function, the steps for generating an initial scheduling scheme using a scheduling algorithm include: Based on the aforementioned sequence constraints, an initial scheduling sequence is generated; Based on the initial scheduling sequence and the optimization objective function, optimization is performed using a genetic algorithm, including: The initial scheduling sequence is encoded to obtain chromosome codes; Based on the chromosome encoding and the optimization objective function, the chromosome fitness is calculated; Based on the chromosome fitness, a selection operation is performed to select chromosomes from chromosome codes, resulting in the selected chromosomes. The selected chromosomes are subjected to a crossover operation to obtain the crossover chromosomes; The crossed-over chromosomes are subjected to mutation operations to obtain mutated chromosomes; Return to the step of calculating chromosome fitness based on the chromosome encoding and optimization objective function, until a preset termination condition is met, and the optimized chromosome is obtained; The optimized chromosome is decoded to obtain the initial scheduling scheme; Based on the aforementioned solid-state drive upgrade scheduling scheme, the steps for performing concurrent control upgrade operations and obtaining upgrade results include: Based on the aforementioned solid-state drive upgrade scheduling scheme, a concurrent execution token is allocated to each upgrade task; Based on the concurrent execution token, the number of upgrade tasks executed simultaneously is controlled to obtain the upgrade task queue; Based on the upgrade task queue, a two-phase commit protocol upgrade operation is performed, including: During the preparation phase, based on the upgrade task queue, an upgrade preparation command is sent to the target solid-state drive, a readiness response is received, and the readiness response is stored. During the submission phase, based on the stored ready response, a formal upgrade command is sent, and upgrade completion confirmation information is received and stored. The upgrade result is generated based on the stored upgrade completion confirmation information.

2. The method for remote batch firmware upgrade of solid-state drives as described in claim 1, characterized in that, Obtaining the storage topology data of the target server cluster includes: Obtain the physical information of the solid-state drives of each server through the system management interface; Obtain the logical relationships of solid-state drives through storage management software; The storage topology data is obtained by merging the physical information and logical relationships of the solid-state drives (SSDs).

3. The method for remote batch firmware upgrade of solid-state drives as described in claim 1, characterized in that, Based on the storage topology data, the steps for constructing a storage topology dependency graph include: Based on the storage topology data, each solid-state drive is treated as a node, and the dependencies between solid-state drives are treated as edges, thus obtaining nodes and edges; Based on the logical dependencies in the stored topology data and the edges, determine the weight value of the edges; Based on the nodes, edges, and weight values, a directed acyclic graph structure is constructed. Based on the directed acyclic graph structure, the storage topology dependency graph is constructed.

4. The method for remote batch firmware upgrade of solid-state drives as described in claim 1, characterized in that, Based on the upgrade task queue, the two-phase commit protocol upgrade operation also includes: During the transaction log recording phase, transaction log records are created based on the upgrade task queue; During the rollback mechanism configuration phase, rollback operation instructions are configured based on the transaction log records. During the anomaly detection phase, based on the upgrade task queue and the stored readiness response information, anomalies in the upgrade process are detected, and anomaly detection results are obtained. During the exception handling phase, based on the exception detection results and rollback operation instructions, a rollback operation is executed when an exception is detected.

5. The method for remote batch firmware upgrade of solid-state drives as described in claim 1, characterized in that, The method further includes: Real-time monitoring of system load changes yields system load change data; Based on the system load change data, the priority of the ongoing upgrade tasks is dynamically adjusted to obtain the adjusted priority; Based on the system load change data and preset threshold data, when the system load exceeds the preset threshold, non-critical upgrade tasks are paused and a task pause status is generated. Based on the task pause status and system load change data, the paused upgrade task is resumed when the system load returns to the preset normal range.

6. The method for remote batch firmware upgrade of solid-state drives as described in claim 1, characterized in that, The method further includes: Based on the aforementioned solid-state drive upgrade scheduling scheme, CPU time slice quotas, memory usage quotas, and network bandwidth quotas are allocated to each upgrade task to obtain resource quotas; Based on the resource quota, the network traffic for the upgrade task is controlled using the token bucket algorithm, including: Based on preset configuration parameters, configure the token generation rate and token bucket capacity for each upgrade task; Based on the token generation rate, tokens are periodically added to the token bucket; Before sending upgrade data, the upgrade task obtains a token from the token bucket and controls the sending of upgrade data based on the obtained token; Monitor the resource usage of each upgrade task and obtain resource usage data; Based on the resource usage data and resource quota, when resource usage exceeds the quota, rate limiting will be implemented.

7. A system for remote batch firmware upgrade of solid-state drives, characterized in that, The solid-state drive firmware remote batch upgrade system includes: a memory, a processor, and a solid-state drive firmware remote batch upgrade program stored on the memory and executable on the processor, wherein the solid-state drive firmware remote batch upgrade program is configured to implement the steps of the solid-state drive firmware remote batch upgrade method as described in any one of claims 1 to 6.

Images