Upgrade methods and electronic devices for distributed storage systems

Abstract

This application discloses an upgrade method and electronic device for a distributed storage system. The method includes: responding to an upgrade request from the distributed storage system to determine the target version after the upgrade; dividing the upgrade process of the distributed storage system into multiple upgrade stages; sequentially executing the multiple upgrade stages according to a preset execution order to upgrade the distributed storage system to the target version; and uniformly processing the original version and the target version of the distributed storage system before the upgrade through a preset compatibility strategy to ensure compatibility between the version differences between the original and target versions. Based on the upgrade method for the distributed storage system provided in this application, the compatibility of the distributed storage system before and after the upgrade can be improved.

Description

Technical Field

[0001] This application relates to the field of distributed data storage technology, and in particular to an upgrade method and electronic device for a distributed storage system. Background Technology

[0002] Distributed storage systems typically consist of a control plane and a data plane, both of which operate in the production environment long-term. Therefore, upgrades to distributed storage systems must be performed online. Currently, the common online upgrade method for distributed storage systems is a strategy of "manual rolling upgrades combined with simple version number verification." However, version numbers cannot adequately describe compatibility, resulting in poor compatibility between the distributed storage system before and after the upgrade. Summary of the Invention

[0003] This application provides an upgrade method and electronic device for a distributed storage system, which can improve the compatibility of the distributed storage system before and after the upgrade.

[0004] This application provides a method for upgrading a distributed storage system, including:

[0005] In response to an upgrade request from a distributed storage system, determine the target version for the upgrade;

[0006] The upgrade process for distributed storage systems is divided into multiple upgrade phases;

[0007] The multiple upgrade stages are executed sequentially according to a pre-defined execution order to upgrade the distributed storage system to the target version.

[0008] By using a pre-defined compatibility strategy, the original and target versions of the distributed storage system before the upgrade are processed in a unified manner to ensure compatibility between the version differences between the original and target versions.

[0009] This application also provides an upgrade device for a distributed storage system, including:

[0010] The determination module is used to determine the target version after the upgrade in response to an upgrade request from the distributed storage system.

[0011] The processing module is used to divide the upgrade process of the distributed storage system into multiple upgrade stages;

[0012] The processing module is also used to execute multiple upgrade stages sequentially according to a preset execution order between the multiple upgrade stages, so as to upgrade the distributed storage system to the target version;

[0013] The processing module is also used to uniformly process the original version and target version of the distributed storage system before the upgrade through a preset compatibility strategy, so as to be compatible with the version differences between the original version and the target version.

[0014] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the above-described distributed storage system upgrade method when executing the computer program.

[0015] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described upgrade method for a distributed storage system.

[0016] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described upgrade method for a distributed storage system.

[0017] The upgrade method and electronic device for the distributed storage system provided in this application divide the upgrade process into multiple upgrade stages and execute each stage sequentially according to a preset execution order. This transforms the upgrade process from a disordered batch switching to a controllable, phased evolution, thereby improving the orderliness of online upgrades. Furthermore, by employing a preset compatibility strategy to uniformly process the original and target versions before the upgrade, it is possible to be compatible with version differences between the original and target versions, thereby reducing state transition deviations during the upgrade process and improving system compatibility before and after the upgrade. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram of a scenario provided for an embodiment of this application;

[0020] Figure 2 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 1 ;

[0021] Figure 3 A diagram illustrating the structure of the control plane in an example distributed storage system;

[0022] Figure 4 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 2 ;

[0023] Figure 5 This example illustrates the execution flow between the various upgrade stages;

[0024] Figure 6 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 3 ;

[0025] Figure 7 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 4 ;

[0026] Figure 8 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 5 ;

[0027] Figure 9 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 6 ;

[0028] Figure 10 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 7 ;

[0029] Figure 11 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 8 ;

[0030] Figure 12 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 9 ;

[0031] Figure 13 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 10 ;

[0032] Figure 14 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 10 one;

[0033] Figure 15 An upgrade sequence diagram for an example distributed storage system;

[0034] Figure 16 This is a schematic diagram of the structure of an upgrade device for a distributed storage system provided in an embodiment of this application;

[0035] Figure 17 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

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

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

[0038] It should also be noted that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. The terms "installed," "connected," and "linked" should be interpreted broadly, for example, they can be fixed connections, detachable connections, or integral connections; they can be mechanical connections or electrical connections; they can be direct connections or indirect connections through an intermediate medium; they can be internal connections between two elements. The terms "parallel," "perpendicular," and "equal" include the described situation and situations similar to the described situation, the range of which is within an acceptable deviation range, wherein the acceptable deviation range is determined by those skilled in the art taking into account the measurement under discussion and the error associated with the measurement of a particular quantity (i.e., the limitations of the measurement system). For example, "parallel" includes absolute parallelism and approximate parallelism, where an acceptable deviation range for approximate parallelism can be, for example, within 5°; "perpendicular" includes absolute perpendicularity and approximate perpendicularity, where an acceptable deviation range for approximate perpendicularity can also be, for example, within 5°. "Equal" includes absolute equality and approximate equality, where an acceptable deviation range for approximate equality can be, for example, a difference between the two equal items being less than or equal to 5% of either one. Those skilled in the art will understand the specific meaning of the above terms in this application based on the specific circumstances.

[0039] Figure 1 This is a schematic diagram of a scenario provided for an embodiment of this application, such as... Figure 1 As shown, a distributed storage system typically includes a control plane and a data plane. The control plane is responsible for node management, topology convergence, event orchestration, object state maintenance, and resource allocation; the data plane is responsible for user input / output (IO) paths, replication and forwarding paths, and local caching. Both the control plane and data plane run in production environments for extended periods, so upgrades to the distributed storage system must be performed online. Currently, online upgrades for distributed storage systems typically employ a strategy of "manual rolling upgrades combined with simple version number verification." The system adds a global version number to determine whether clients or nodes meet the minimum version requirements at startup. However, version numbers cannot adequately describe compatibility, leading to poor compatibility between the distributed storage system before and after the upgrade.

[0040] The upgrade method and electronic device for a distributed storage system provided in this application divide the upgrade process of the distributed storage system into multiple upgrade stages and execute each upgrade stage sequentially according to a preset execution order. This transforms the upgrade process from disordered batch switching to a controllable phased evolution, thereby improving the orderliness of online upgrades. Furthermore, by employing a preset compatibility strategy to uniformly process the original version and the target version before the upgrade, it can be compatible with version differences between the original and target versions, thereby reducing state transition deviations during the upgrade transition and improving the system's compatibility before and after the upgrade.

[0041] The embodiments of this application provide an upgrade method for a distributed storage system, which is described in detail below: Figure 2 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 1 ,like Figure 2 As shown, it includes:

[0042] S201. In response to an upgrade request from the distributed storage system, determine the target version for the upgrade.

[0043] For example, in this embodiment, the execution entity is the control plane in a distributed storage system. Figure 3 Here is a diagram of the control plane structure in an example distributed storage system, such as... Figure 3As shown, the control plane includes: UpgradeManager, UpgradeController, Capability Registry, Feature Gate Center, Health Gateway, Rollback Controller, Compatibility Adapter Layer, and Upgrade Process. Specifically, the UpgradeManager is responsible for advancing the distributed storage system's upgrade state machine; the UpgradeController executes the upgrade operations; the Capability Registry includes a node capability set, which collects and stores the capability profiles of each node; the Feature Gate Center determines whether the semantics of the new version are truly enabled; the Health Gateway includes health gates for each upgrade stage, used to determine whether the upgrade process needs to continue; and the Rollback Controller restores the system to the most recent stable state point in case of upgrade failure. The compatibility and adaptation layer is responsible for ensuring compatibility with the main control node, non-main control nodes, and data plane nodes on the control plane. In other words, it is responsible for unifying different versions of event objects, business objects, and remote procedure calls (RPCs) into an internal standard semantic model (canonical model). The cluster database is used to store the audit and plan of the distributed storage system, upgrade progress, node capability sets in the capability registry, feature switches, health access control at each upgrade stage, and state stability points.

[0044] The upgrade request is received and parsed by the upgrade manager, which carries a version identifier indicating the target version that the upgrade needs to achieve. The target version is then written into the context of the upgrade controller, and this target version is used to constrain the final state of the entire upgrade process.

[0045] S202. The upgrade process of the distributed storage system is divided into multiple upgrade stages.

[0046] For example, this example discretizes the upgrade process into multiple upgrade stages so that they can be processed segment by segment in a pre-defined execution order.

[0047] Optionally, the distributed storage system includes: a control plane, a data plane, and a cluster database. The control plane includes: a master control node and multiple non-master control nodes. The multiple upgrade phases include: a preparation phase, a cluster database rolling upgrade phase, a control plane non-master control node rolling upgrade phase, a control plane master control node switching phase, a data plane gray-scale verification phase, a data plane rolling upgrade phase, a feature switching phase, and a cleanup phase.

[0048] For example, the execution order of each phase is as follows: preparation phase, cluster database rolling upgrade phase, control plane non-master control node rolling upgrade phase, control plane master control node switching phase, data plane canary verification phase, data plane rolling upgrade phase, feature switching phase, and closing phase. The preparation phase is used to write the upgrade plan, target version, upgrade scope, and rollback policy to the upgrade manager. It also obtains the node capability set to determine whether the upgrade is allowed. The cluster database rolling upgrade phase is used to check the health of the cluster database and proceed with subsequent upgrade phases only if the cluster database is healthy. The control plane non-master control node rolling upgrade phase refers to the upgrade phase of each non-master control node on the control plane. The control plane master control node switching phase refers to selecting a new master control node from the upgraded non-master control nodes to replace the original master control node. The data plane canary verification phase refers to performing canary verification on the data plane to observe IO latency, error rate, and whether the replication link exceeds limits. The data plane rolling upgrade phase refers to the upgrade process of the data plane. The feature switching phase refers to the new semantics of the target version taking effect. The cleanup phase refers to the process after all the aforementioned phases have been completed, which involves cleaning up the old write and read ends left over from the old version, as well as the rollback paths triggered during the upgrade process.

[0049] S203. Execute multiple upgrade stages sequentially according to the preset execution order between the multiple upgrade stages to upgrade the distributed storage system to the target version.

[0050] For example, the upgrade manager can set corresponding execution conditions for each upgrade stage, and submit the execution instructions for the next upgrade stage only after the execution conditions for the next upgrade stage are met. For instance, the next upgrade stage is only allowed after the completion of the previous upgrade stage is detected.

[0051] Optional, Figure 4 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 2 ,like Figure 4 As shown, S203 includes:

[0052] S401, Configure health access control mechanisms for each upgrade stage.

[0053] For example, a health access control mechanism should include at least the following metrics: cluster database quorum health, master control node stability, event backlog rate, RPC error rate, replication link health, IO latency rate, and timeout rate. Cluster database quorum health characterizes the percentage of available control nodes in the control plane. Each metric has a corresponding preset threshold to determine whether it meets the standard. For instance, the preset threshold for cluster database quorum health is 50%. When the percentage of available control nodes is greater than or equal to 50%, the cluster database is considered to be operating normally, and thus, cluster database quorum health is met. Conversely, when the percentage of available control nodes is less than 50%, cluster database quorum health is not met. Additionally, master control node stability and replication link health are considered acceptable when they are greater than or equal to their corresponding preset thresholds, while event backlog rate, RPC error rate, IO latency rate, and timeout rate are considered acceptable when they are less than their corresponding preset thresholds.

[0054] S402. Determine the current upgrade phase that is currently being executed.

[0055] For example, the current upgrade phase can be any one of the following phases: preparation phase, cluster database rolling upgrade phase, control plane non-master control node rolling upgrade phase, control plane master control node switching phase, data plane grayscale verification phase, data plane rolling upgrade phase, feature switching phase, and closing phase.

[0056] S403. After the current upgrade phase is completed, a phase verification will be conducted through the health access control mechanism.

[0057] Example, Figure 5 The execution flow between the various upgrade stages is shown in the example. Figure 5 As shown, based on the execution order of each upgrade phase, a health access control mechanism is used to verify the current upgrade phase after its completion. For example, if the current upgrade phase is a cluster database rolling upgrade phase, after the phase ends, the following metrics are checked: cluster database quorum health, master control node stability, event backlog rate, RPC error rate, replication link health, IO latency rate, and timeout rate. Based on preset thresholds for each metric, it is determined whether each metric meets the required standards. If all metrics meet the standards, the current upgrade phase satisfies the health access control mechanism, and the verification is successful. If any metric fails to meet the standards, the current upgrade phase does not meet the health access control mechanism, and the verification fails.

[0058] S404. If the stage verification passes, generate and save the state checkpoint corresponding to the current upgrade stage, and start executing the next upgrade stage.

[0059] For example, upon successful verification of the cluster database rolling upgrade phase, a state checkpoint corresponding to that phase is saved. This checkpoint represents a stable state point for the current phase. After saving the state checkpoint, the rolling upgrade phase for non-master control nodes in the control plane begins.

[0060] S405. If the phase verification fails, if the current upgrade phase is the first upgrade phase, control the distributed storage system to roll back to the state before the upgrade; if the current upgrade phase is not the first upgrade phase, control the distributed storage system to roll back to the state checkpoint of the previous upgrade phase.

[0061] For example, if the control plane can execute a cluster database rolling upgrade phase, it means that the previous preparation phase has been successfully completed and passed the health access control mechanism verification. Therefore, similarly, there are state checkpoints in the control plane regarding the preparation phase. When the cluster database rolling upgrade phase passes verification, a rollback mechanism is triggered to roll back to the state checkpoint of the preparation phase and re-execute the cluster database rolling upgrade phase.

[0062] Based on the method provided in this example, by using the health verification and state solidification prevention of the health access control mechanism, subsequent upgrades will only proceed after the health access control mechanism has passed the verification. If the verification fails, it can roll back to the state checkpoint of the previous upgrade stage, that is, roll back to the most recent stable state, which can improve the stability of the upgrade of the distributed storage system.

[0063] Optional, Figure 6 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 3 ,like Figure 6 As shown, the execution process of the preparation phase includes:

[0064] S601. Collect capability attribute information of the main control node and each non-main control node.

[0065] For example, the capability attribute information of the master control node and each non-master control node can be obtained from the node capability set. The capability attribute information is used to describe the node's software version, protocol information, feature bits, and version compatibility range, etc.

[0066] S602. Based on the target version and the capability attribute information of each node, determine whether the distributed storage system is allowed to be upgraded, and if the distributed storage system is allowed to be upgraded, enter the cluster database rolling upgrade phase.

[0067] For example, when it is detected that the capability attributes of each node are compatible with the target version, i.e., when the target version requirements are met, it is determined that the distributed storage system upgrade is allowed. At this time, information such as the upgrade plan, target version, upgrade scope, and rollback policy can be written to the upgrade controller, and the cluster database rolling upgrade phase begins. Before entering the cluster database rolling upgrade phase, the corresponding state checkpoints for the preparation phase are generated and saved. If the capability attributes of any node do not meet the target version requirements, the current state is maintained and the cluster database rolling upgrade phase is refused.

[0068] Optional, Figure 7 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 4 ,like Figure 7 As shown, the execution process of the cluster database rolling upgrade phase includes:

[0069] S701, detect the operating status of the main control node and each non-main control node.

[0070] For example, the cluster database rolling upgrade phase is mainly used to detect whether the cluster database is healthy, that is, to detect the health of the cluster database quorum. Therefore, it can detect the running status of each control node to detect whether the control node can run normally, such as reading and writing data normally.

[0071] S702. If the number of normally operating control nodes in the main control node and each non-main control node is greater than or equal to a preset threshold, then the non-main control node rolling upgrade phase of the control plane is entered.

[0072] For example, as mentioned above, the preset threshold for determining the health of the cluster database quorum can be 50%. When the number of normally operating control nodes is greater than or equal to 50%, the cluster database quorum health is considered to be up to standard. At this point, a status checkpoint corresponding to the cluster database rolling upgrade phase is generated and saved. When the number of normally operating control nodes is less than 50%, the cluster database quorum health is considered to be down to standard, and a rollback mechanism is triggered to roll back the upgrade process to the status checkpoint corresponding to the preparation phase.

[0073] Based on the method provided in this example, prioritizing the health of the cluster database quorum ensures that subsequent upgrade phases are built on a foundation of sufficient available control nodes, thereby reducing the probability of interruptions caused by insufficient available control nodes during the upgrade process.

[0074] Optional, Figure 8 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 5 The target version includes: the target software version, the target event object version, the target business object version, and the target interface version; such as Figure 8 As shown, the execution process of the rolling upgrade phase of the non-master control node in the control plane includes:

[0075] S801. During the upgrade process of each non-master control node, continuously monitor the software version, event object version, business object version and interface version of each non-master control node, as well as the update status of the characteristics of each non-master control node.

[0076] For example, the rolling upgrade phase of the control plane's non-master control nodes is used to upgrade each non-master control node one by one. The upgrade of non-master control nodes includes upgrades to software versions, event object versions, business object versions, and interface versions, as well as upgrades to the characteristic bits of the non-master control nodes. Characteristic bits are used to characterize the features that a non-master control node can support. A common implementation is a binary integer, where each bit represents a capability; for example, bit 0 represents supporting feature A, bit 1 represents supporting feature B. Based on the characteristics of a non-master control node, it can be determined whether the control node can continue to interpret old events, parse old event objects and old business objects, and use old interfaces, etc.

[0077] S802. After the software version, event object version, business object version and interface version of each non-master control node are updated to the target software version, target event object version, target business object version and target interface version, and the characteristics of each non-master control node are updated, the master control node switching phase of the control plane is entered.

[0078] For example, the capability registry continuously records the corresponding software version, event object version, business object version, interface version, and supported features of each non-master control node. When the software version of all non-master control nodes has been updated to the target software version, the event object version to the target event object version, the business object version to the target business object version, the interface version to the target interface version, and the features of the non-master control nodes have been updated to the features achievable by the target version, it can be determined that all non-master control nodes have been updated successfully. At this point, the status checkpoints corresponding to the rolling upgrade phase of the control plane non-master control nodes can be generated and saved, and the control plane master control node switching phase can be initiated. However, if the verification of the rolling upgrade phase of the control plane non-master control nodes based on the health access control mechanism fails, a rollback mechanism is triggered to roll back the upgrade process to the status checkpoint corresponding to the rolling upgrade phase of the cluster database.

[0079] Based on the method provided in this example, non-master control nodes can remain observable throughout the rolling upgrade process, and version and feature update results can be synchronously confirmed, allowing for timely observation of the upgrade progress of non-master control nodes. Furthermore, the switchover phase for the master control node in the control plane only begins after all non-master control nodes have completed target version alignment, thus forming clear phase boundaries and ensuring consistent state transitions in the control plane during the upgrade process.

[0080] Optional, Figure 9 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 6 ,like Figure 9 As shown, the execution process of the control plane master control node switching phase includes:

[0081] S901. Based on the updated characteristic information of each non-master control node, determine the candidate master control node.

[0082] For example, candidate master control nodes need to have the ability to continue interpreting old events, parsing old event objects and old business objects, and using old interfaces. Therefore, candidate master control nodes are determined from non-master control nodes that have these capabilities based on characteristic information.

[0083] S902. Control the current master control node to enter silent mode and write a switching boundary checkpoint through the current master control node. The switching boundary checkpoint includes: the sequence of event objects in the control plane and the tasks in progress.

[0084] For example, silent mode means no new processing tasks are accepted, but existing tasks continue to be processed. After entering silent mode, the current master control node serializes and writes the registered event objects in the control plane to the switch boundary checkpoint in a preset order, and also records ongoing tasks to the switch boundary checkpoint. In addition, the switch boundary checkpoint includes information such as the cluster database revision version and feature switch snapshots.

[0085] S903. After detecting the resignation of the current master control node, switch the candidate master control node to the new master control node, and read the switch boundary checkpoint through the new master control node to resume listening to each event object according to the event object sequence, and execute the processing of ongoing tasks.

[0086] For example, when the current master control node has resigned, the candidate master control node takes over the master control authority and restores the event object subscription table from the switch boundary checkpoint, re-establishes the listening relationship for each event object, and continues to process unfinished tasks according to the task identifier and execution progress, so that the dispatch of control commands, state maintenance and task takeover remain continuous.

[0087] After the control plane master control node switchover phase is completed and the health access control mechanism verifies the switchover phase, a status checkpoint corresponding to the master control node switchover phase is generated and saved, and the process proceeds to the data plane grayscale verification phase. Otherwise, a rollback mechanism is triggered to roll back the upgrade process to the status checkpoint corresponding to the non-master control node rolling upgrade phase of the control plane.

[0088] Based on the method provided in this example, the primary control node fully solidifies the boundary state before resigning, and the new primary control node resumes listening and task processing according to the same event object sequence. This ensures that the primary control responsibilities remain consistent before and after the switchover, reducing duplicate event consumption, task loss, and control state breaks. Because the switchover boundary checkpoint simultaneously saves the event object sequence and ongoing tasks, the primary control node can directly continue unfinished control semantics after the switchover, thereby ensuring the continuity of the control plane's state and the stability of business continuity during the upgrade phase.

[0089] Optional, Figure 10 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 7 ,like Figure 10 As shown, the execution process of the data plane grayscale verification stage includes:

[0090] S1001. Select a protection field of a preset size for grayscale verification to determine whether the delay time, error rate and number of replication links of input and output requests meet the security threshold.

[0091] For example, a small number of protection domains are first selected for canary testing to check whether the IO latency, error rate, and number of replication links meet the security thresholds. A protection domain refers to a pre-defined local business carrying area within a distributed storage cluster. Its internal nodes, replication relationships, and request traffic are limited to a controllable range. During the canary testing period, only input and output requests within this range are monitored and increased. The security threshold is used to characterize the allowable upper limit of latency, error rate, and the number of replication links.

[0092] S1002. When the safety threshold is met, enter the data plane rolling upgrade stage.

[0093] For example, if the IO latency, error rate, and number of replication links do not exceed the allowed limits, it indicates that the target version has the conditions to continue within the protection domain. In this case, a state checkpoint corresponding to the data plane gray-scale verification phase is generated and saved, and the data plane rolling upgrade phase begins. Conversely, if these conditions are not met, a rollback mechanism is triggered to roll back the upgrade process to the state checkpoint corresponding to the control plane master control node switching phase.

[0094] The execution process of the data plane rolling upgrade phase includes:

[0095] S1003. Perform an upgrade operation on the data plane according to the protection domain or the preset node group.

[0096] For example, after entering the data plane rolling upgrade phase, the upgrade scope can be expanded serially by protection domain, or a rolling upgrade can be performed on the data plane through a preset node group. Upon completion of the data plane rolling upgrade phase and successful verification of the phase via a health access control mechanism, a status checkpoint corresponding to the data plane rolling upgrade phase is generated and saved, and the feature switching phase begins. Conversely, if the upgrade fails, a rollback mechanism is triggered to revert the upgrade process to the status checkpoint corresponding to the data plane grayscale verification phase.

[0097] Based on the method provided in this example, grayscale verification can assess the impact of the new version on request latency, error rate, and replication relationships within the limited scope of the protection domain. Rolling upgrades, on the other hand, expand to the full data plane in batches after meeting the security threshold, thereby ensuring continuous upscaling of the upgrade process and maintaining the stability of the replication link.

[0098] Figure 11 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 8 ,like Figure 11 As shown, the execution process of the feature switching phase includes:

[0099] S1101. Determine the new control semantics corresponding to the target version.

[0100] For example, the new control semantics are used to characterize the event dispatch rules, write arbitration rules, and read response rules of the target version in the control plane.

[0101] S1102, The new control semantics take effect and the process enters the finalization phase.

[0102] For example, the new control semantics are formally implemented in the distributed storage system to make them effective. When the feature switching phase passes verification via a health access control mechanism, a state checkpoint corresponding to the feature switching phase is generated and saved, and the process proceeds to the final cleanup phase. Conversely, if the feature switching phase fails, a rollback mechanism is triggered to revert the upgrade process to the state checkpoint corresponding to the data plane rolling upgrade phase.

[0103] Figure 12 A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 9 ,like Figure 12 As shown, the new control semantics take effect, including:

[0104] S1201. Switch the event objects in the control plane to the event specification corresponding to the target event version, and switch the interface semantics of the distributed storage system to the semantics corresponding to the target interface version.

[0105] For example, the event object carries the event identifier, event type, event parameters, and event execution context received by the control plane; the event specification defines the parsing method, validation rules, dispatch conditions, and callback processing logic for event fields; the interface semantics defines the request format, return fields, and error code interpretation of the distributed storage system; and the read / write path represents the access channel and forwarding link used by the data plane when receiving read, write, and replication requests. Ongoing tasks can be incomplete data migration tasks, object write tasks, or replication synchronization tasks. Upon receiving a feature switching instruction, the control plane first determines the target event version and target interface version corresponding to the target version. Then, it loads the event specification file and interface semantics description file bound to the target version and registers them respectively in the event dispatch module and interface adaptation module to switch the event object to the event specification corresponding to the target event version and the interface semantics to the semantics corresponding to the target interface version. When a new control event is received, it completes the parsing according to the field mapping relationship corresponding to the target event version and generates control actions based on the processing rules of the target event version. When an external request is received, it is encoded and decoded according to the request header, parameter structure, and response template of the target interface version, so that the external interface takes effect according to the target interface version.

[0106] S1202. Create a new read / write path based on the target version.

[0107] For example, at the same time, the data plane creates new read / write path identifiers, new connection sessions, and new routing forwarding entries based on the target version, and writes the new paths to the path management table so that subsequent requests can switch to the access channel corresponding to the target version.

[0108] S1203. After completing the ongoing task, close the read / write paths corresponding to each original version in the distributed storage system.

[0109] For example, once the new read / write path is established, continue monitoring the tasks in progress in each task queue, and only perform cleanup processing on tasks that have entered the submission confirmation state or have completed the local disk write state. Then, deregister the read / write path corresponding to the original version from the path management table and close the read / write path corresponding to the original version.

[0110] Based on the method provided in this example, the event interpretation, interface request processing, and data read / write channels in the control plane can be switched within the same version boundary. The control semantics can take over the original processing logic without interrupting the task, thereby ensuring that the control instructions, interface calls, and data access remain consistent after the version migration.

[0111] Figure 13A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 10 ,like Figure 13 As shown, the execution process of the closing phase includes:

[0112] S1301. Clean up the rollback path, old write end and old read end created during rollback.

[0113] For example, during the rollback phase, temporary rollback paths created during the rollback are released, the bindings between the old writer and the write agent, and between the old reader and the read agent are released, and residual session identifiers, forwarding table entries, and compatibility caches are cleared.

[0114] S1302. Generate and save the final state checkpoint corresponding to the closing stage.

[0115] For example, after cleanup is complete, the current final state is solidified, and a final state checkpoint corresponding to the cleanup phase is generated and saved. The method provided in this example enables the target version's control semantics to stably take over the cluster's running state, while reducing routing ambiguity and state forks caused by old semantic remnants.

[0116] S204. Through a preset compatibility strategy, the original version and the target version of the distributed storage system before the upgrade are processed in a unified manner to ensure compatibility between the version differences between the original version and the target version.

[0117] For example, the original version and the target version may coexist on different nodes, different replicas, or different component instances during the upgrade. Version differences are typically reflected in event formats, object structures, interface protocols, and response semantics, thus requiring unified processing through compatibility strategies. In one possible embodiment, a compatibility strategy is used to convert, mask, or normalize the differences between the original and target versions. For example, mapping old version events to event formats recognizable by the target version, supplementing newly added fields in the target version with default values ​​acceptable to the old version, uniformly encapsulating interface requests from different versions into the same processing semantics, or rewriting version-sensitive fields in the receipt, enabling both sides to interact according to unified semantics during the mixed deployment. Based on the method provided in this example, by dividing the upgrade process of the distributed storage system into multiple upgrade stages and executing each stage sequentially according to a preset execution order, the upgrade process can be transformed from disordered batch switching to a controllable phased evolution, thereby improving the orderliness of online upgrades. Furthermore, by employing a preset compatibility strategy to uniformly process the original and target versions before the upgrade, it can be compatible with version differences between the original and target versions, thereby reducing state transition deviations during the upgrade process and improving system compatibility before and after the upgrade.

[0118] Figure 14A flowchart illustrating the upgrade method for the distributed storage system provided in this application embodiment. Figure 10 First, such as Figure 14 As shown, S204 includes:

[0119] S1401. Introduce a preset compatibility adaptation layer inside the control plane.

[0120] For example, the compatibility and adaptation layer is set in the control plane, which can maintain a version mapping table, a semantic conversion table, and a response version selection table. The version mapping table is used to record the object identification correspondence between the original version and the target version. The semantic conversion table is used to record the equivalence relationship between different event specifications and business fields. The response version selection table is used to record the matching relationship between the target node characteristic information and the response format.

[0121] S1402. By resolving the event specification information and specific event content of the event objects in the control plane through the compatibility adaptation layer, the original event objects in the original version and the target event objects in the target version are determined.

[0122] For example, during event object parsing, the compatibility adaptation layer first reads the event specification information, and then combines the object type, field set, and field values ​​in the specific event content to identify the original event object corresponding to the original version and the target event object corresponding to the target version.

[0123] S1403. Convert the original event object and the target event object into the same preset semantics.

[0124] For example, the original event object and the target event object are mapped to a unified intermediate semantic representation. When there are differences between the original event object and the target event object in terms of field naming, field order, or enumeration values, the compatibility adaptation layer completes the normalization transformation based on the semantic transformation table, so that the event semantics on which the control plane relies for subsequent listening, distribution, and persistence processing remain consistent.

[0125] S1404. For business objects in the control plane, when processing the original business objects in the original version, adjust the processing version of the original business objects through the compatibility adaptation layer.

[0126] For example, regarding business object processing, after receiving the original business object from the original version, the compatibility adaptation layer adjusts its processing version according to the processing requirements of the target version. This ensures that the business object uses the same processing context as the target version during validation, routing, transaction orchestration, or state updates. When the target version introduces new object attributes or deprecates old attributes, the compatibility adaptation layer can perform field completion, field pruning, or default value filling on the original business object to ensure that the original version's business logic can still output processing results that meet the requirements of the target version during the transition period.

[0127] S1405. For sending and receiving requests, the compatibility adaptation layer selects a response version based on the characteristic information of the target node corresponding to the request, and returns the processing result of the request based on the response version.

[0128] For example, during the request sending and receiving process, the compatibility adaptation layer reads the characteristic information of the target node corresponding to the request. The characteristic information includes at least the interface format supported by the node, the protocol frame version, the field compatibility range, and the response capability identifier, and selects the response version that matches the target node accordingly. When the target node only supports the old response structure, the compatibility adaptation layer returns the processing result of the old response version. When the target node supports the new response structure, it returns the processing result of the new response version, thus ensuring that the request and response between different version nodes maintain consistent interaction semantics.

[0129] By using the method provided in this example, through unified resolution, semantic normalization, processing version adjustment, and response version selection in the compatibility adaptation layer, the event processing, business processing, and request response of the original version and the target version in the control plane can maintain continuity and consistency during the upgrade, thereby improving the compatibility of the distributed storage system.

[0130] Figure 15 An upgrade sequence diagram for an example distributed storage system, such as... Figure 15 As shown, the upgrade event is first triggered by a management command, sending an upgrade request to the upgrade controller. The upgrade controller then writes the upgrade plan and stage status. The upgrade monitor observes the progress changes of the upgrade stages and determines whether to trigger the next upgrade stage through a health access control mechanism. If the verification passes, the next upgrade stage begins execution. This continues until all upgrade stages are completed. New control semantics are enabled via feature switches, new read / write paths are created, and finally, old paths are cleaned up and the final state checkpoint is saved. Simultaneously, the cluster controller records and updates the stage status. If the verification fails, a rollback mechanism is triggered, and the rollback controller rolls the upgrade process back to the most recent stable state point, which is the state checkpoint corresponding to the previous upgrade stage. The cluster controller also records the rollback record and the stage status after the rollback.

[0131] Figure 16 This is a schematic diagram of the structure of the upgrade device for the distributed storage system provided in the embodiments of this application, as shown below. Figure 16 As shown, it includes:

[0132] Module 161 is used to determine the target version after the upgrade in response to an upgrade request from the distributed storage system.

[0133] Processing module 162 is used to divide the upgrade process of the distributed storage system into multiple upgrade stages;

[0134] The processing module 162 is also used to execute multiple upgrade stages sequentially according to a preset execution order among the multiple upgrade stages, so as to upgrade the distributed storage system to the target version;

[0135] The processing module 162 is also used to uniformly process the original version and the target version of the distributed storage system before the upgrade through a preset compatibility strategy, so as to be compatible with the version differences between the original version and the target version.

[0136] The description of the features of the upgrade device for the distributed storage system provided in this embodiment can be found in the relevant description of the upgrade method for the distributed storage system, and will not be repeated here.

[0137] Figure 17 A schematic diagram of the structure of the electronic device provided in this application. Figure 17 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.

[0138] In the specific implementation process, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to execute the above-described embodiment of the upgrade method for the distributed storage system.

[0139] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0140] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0141] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0142] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0143] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the upgrade method for a distributed storage system.

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

[0145] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the upgrade method for a distributed storage system.

[0146] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the upgrade method for a distributed storage system.

[0147] It should be noted that the division of units is merely a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0148] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0149] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0150] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0151] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0152] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0153] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation.

[0154] The above provides a detailed description of the upgrade method and electronic device for a distributed storage system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for upgrading a distributed storage system, characterized in that, include: In response to an upgrade request from a distributed storage system, determine the target version for the upgrade; The upgrade process of the distributed storage system is divided into multiple upgrade stages; The multiple upgrade stages are executed sequentially according to a preset execution order to upgrade the distributed storage system to the target version. By using a preset compatibility strategy, the original version of the distributed storage system before the upgrade and the target version are processed in a unified manner to ensure compatibility between the version differences between the original version and the target version.

2. The method according to claim 1, characterized in that, The step of executing the multiple upgrade stages sequentially according to a preset execution order includes: Configure health access control mechanisms for each upgrade phase; Identify the current upgrade phase that is currently in progress; After the current upgrade phase is completed, a phase verification will be performed through the aforementioned health access control mechanism; If the stage verification passes, the state checkpoint corresponding to the current upgrade stage is generated and saved, and the next upgrade stage is started. If the stage verification fails, the distributed storage system is rolled back to its pre-upgrade state when the current upgrade stage is the first upgrade stage; and the distributed storage system is rolled back to the state checkpoint of the previous upgrade stage when the current upgrade stage is not the first upgrade stage.

3. The method according to claim 2, characterized in that, The distributed storage system includes a control plane, a data plane, and a cluster database. The control plane includes a master control node and multiple non-master control nodes. The multiple upgrade phases include a preparation phase, a cluster database rolling upgrade phase, a control plane non-master control node rolling upgrade phase, a control plane master control node switching phase, a data plane gray-scale verification phase, a data plane rolling upgrade phase, a feature switching phase, and a wrap-up phase.

4. The method according to claim 3, characterized in that, The execution process of the preparation phase includes: Collect capability attribute information of the main control node and each non-main control node; Based on the target version and the capability attribute information of each node, it is determined whether the distributed storage system is allowed to be upgraded, and when the distributed storage system is allowed to be upgraded, the cluster database enters the rolling upgrade phase. The execution process of the cluster database rolling upgrade phase includes: Detect the operating status of the main control node and each non-main control node; If the number of normally operating control nodes among the main control node and each non-main control node is greater than or equal to a preset threshold, then the non-main control node rolling upgrade phase of the control plane is entered.

5. The method according to claim 3, characterized in that, The target version includes: target software version, target event object version, target business object version, and target interface version; the execution process of the rolling upgrade phase of the control plane non-master control node includes: During the upgrade process of each of the non-master control nodes, the software version, event object version, business object version and interface version corresponding to each of the non-master control nodes, as well as the update status of the characteristics of each of the non-master control nodes are continuously monitored. Once the software version, event object version, business object version, and interface version corresponding to each of the non-master control nodes have been updated to the target software version, target event object version, target business object version, and target interface version, and the characteristics of each of the non-master control nodes have been updated, the master control node switching phase of the control plane is entered.

6. The method according to claim 5, characterized in that, The execution process of the control plane master control node switching phase includes: Based on the updated characteristic information of each non-master control node, candidate master control nodes are determined; The current master control node is controlled to enter silent mode, and a switching boundary checkpoint is written through the current master control node. The switching boundary checkpoint includes: the sequence of event objects in the control plane and the ongoing tasks. After detecting the resignation of the current master control node, the candidate master control node is switched to a new master control node, and the switch boundary checkpoint is read through the new master control node to resume listening to each event object according to the event object sequence and to process the ongoing task.

7. The method according to claim 3, characterized in that, The execution process of the data plane grayscale verification stage includes: Select a protection field of a preset size for grayscale verification to determine whether the latency, error rate, and number of replication links of input and output requests meet the security thresholds. When the security threshold is met, the data plane rolling upgrade phase begins. The execution process of the data plane rolling upgrade phase includes: The data plane is upgraded according to the protection domain or the preset node group.

8. The method according to claim 5, characterized in that, The execution process of the feature switching phase includes: Determine the new control semantics corresponding to the target version; The new control semantics are activated, and the process proceeds to the closing phase. The execution process of the closing phase includes: Clean up the rollback paths, old write ends, and old read ends created during the rollback; Generate and save the final state checkpoint corresponding to the closing stage.

9. The method according to claim 1, characterized in that, The step of using a preset compatibility strategy to uniformly process the original version and the target version of the distributed storage system before the upgrade, in order to be compatible with the version differences between the original version and the target version, includes: A preset compatibility adaptation layer is introduced inside the control plane; The compatibility adaptation layer parses the event specification information and event details of the event objects in the control plane to determine the original event objects in the original version and the target event objects in the target version. Convert the original event object and the target event object into the same preset semantics; For business objects in the control plane, when processing the original business objects in the original version, the processing version of the original business objects is adjusted through the compatibility adaptation layer; For sending and receiving requests, the compatibility and adaptation layer selects a response version based on the characteristic information of the target node corresponding to the request, and returns the processing result of the request based on the response version.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the upgrade method for a distributed storage system as described in any one of claims 1 to 9 when executing the computer program.

Images