Snapshot generation method, system, device, and program product

Abstract

Embodiments of the present application disclose a snapshot generation method, system, device and program product, which are applied to a distributed system. The method comprises: in the case that a snapshot creation process of a target volume is triggered, a metadata node device and a data node device generate a target snapshot corresponding to the target volume and a target snapshot version number, set a state of the target snapshot version number as a preparation state, and send the target snapshot version number to a control node device; the control node device, after obtaining the target snapshot version number, respectively issues a snapshot submission instruction to the metadata node device and the data node device; and the metadata node device and the data node device, in response to the snapshot submission instruction, set the state of the target snapshot version number as an effective state, and complete the snapshot creation process of the target volume. The data writing can be more flexibly implemented, and the view consistency of each node in the distributed system is ensured.

Description

Technical Field

[0001] This application relates to distributed storage technology, and includes, but is not limited to, a snapshot generation method, system, device, and program product. Background Technology

[0002] Snapshot technology is a data protection technique used in distributed storage systems, and it is widely used in scenarios such as data backup, disaster recovery, and test environment construction.

[0003] In related technologies, distributed systems typically need to pause business writes during snapshot generation until the snapshot is ready. This mechanism causes the system to be unable to continuously provide complete write services during snapshot generation, affecting system availability and performance. Summary of the Invention

[0004] In view of this, the snapshot generation method, system, device, and program product provided in the embodiments of this application can more flexibly realize data writing and ensure the visibility of each node in the distributed system. Figure 1 Consistency. The snapshot generation method, system, device, and program product provided in the embodiments of this application are implemented as follows: One aspect of this application provides a snapshot generation method applied to a distributed system, the distributed system including: a control node device, a metadata node device, and a data node device; the method includes: When the snapshot creation process for the target volume is triggered, the metadata node device and the data node device generate the target snapshot and the target snapshot version number corresponding to the target volume, set the status of the target snapshot version number to the ready state, and send the target snapshot version number to the control node device. After obtaining the target snapshot version number, the control node device sends snapshot commit instructions to both the metadata node device and the data node device. In response to the snapshot commit command, the metadata node device and the data node device set the status of the target snapshot version number to the effective state, thus completing the snapshot creation process for the target volume.

[0005] Another aspect of this application embodiment provides a snapshot generation apparatus, applied to a distributed system, the distributed system including: a control node device, a metadata node device, and a data node device; the apparatus includes: a preparation module, a transmission module, and a submission module; The preparation module is used to generate a target snapshot and a target snapshot version number corresponding to the target volume through the metadata node device and the data node device when the snapshot creation process of the target volume is triggered, set the status of the target snapshot version number to the preparation state, and send the target snapshot version number to the control node device. The transmission module is used to send snapshot submission instructions to the metadata node device and the data node device respectively after the control node device obtains the target snapshot version number; The commit module is used to respond to the snapshot commit command through the metadata node device and the data node device, set the status of the target snapshot version number to the effective state, and complete the snapshot creation process for the target volume.

[0006] This application provides a distributed system, which includes a control node device, a metadata node device, and a data node device. The distributed system implements the above-described method when executed.

[0007] The computer device provided in this application includes a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the method of this application.

[0008] The computer-readable storage medium provided in this application embodiment stores a computer program thereon, which, when executed by a processor, implements the method provided in this application embodiment.

[0009] In the snapshot generation method, system, device, and program product provided in this application embodiment, the target snapshot and its corresponding version number are directly generated by the metadata node device and data node device after triggering the snapshot creation process, and the version number is set to a ready state. This allows each participating node to independently complete the preparation of local snapshot data during the snapshot preparation phase without waiting for real-time coordination from the control node, thus avoiding blocking of node write operations during the preparation phase. By issuing a commit command after obtaining the snapshot version number, the final effective operation of snapshot generation is asynchronous with data transmission. The commit phase does not require data copying or moving, eliminating the occupation of system storage bandwidth and computing resources during the snapshot generation process. By switching the state of the target snapshot version number from the ready state to the effective state in response to the commit command, the entire snapshot creation process uses the version number as the basis, thereby ensuring snapshot consistency while guaranteeing the ability of the distributed system to continuously provide write services during snapshot generation, improving system availability and snapshot creation efficiency. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the 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.

[0011] Figure 1This is a schematic diagram of the structure of the distributed system provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the snapshot generation method provided in the embodiments of this application; Figure 3 This is a logical diagram illustrating the snapshot generation provided in the embodiments of this application; Figure 4 This is a schematic diagram of the interaction written by the client node in the embodiments of this application; Figure 5 This is a schematic diagram illustrating the logic of client node updates provided in the embodiments of this application; Figure 6 This is another logical schematic diagram of snapshot generation provided in the embodiments of this application; Figure 7 This is a logical diagram illustrating multi-node consistency provided in the embodiments of this application; Figure 8 A schematic diagram illustrating the logic of version updates for each node of the server provided in this application embodiment; Figure 9 This is a schematic diagram of the snapshot generation device provided in the embodiments of this application; Figure 10 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of this application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0014] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0015] It should be noted that the terms "first, second, third" used in the embodiments of this application are used to distinguish similar or different objects and do not represent a specific order of objects. It can be understood that "first, second, third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] Snapshot technology is a data protection technique used in distributed storage systems, and it is widely used in scenarios such as data backup, disaster recovery, and test environment construction.

[0017] In related technologies, distributed systems typically need to pause business writes during snapshot generation until the snapshot is ready. This mechanism causes the system to be unable to continuously provide complete write services during snapshot generation, affecting system availability and performance.

[0018] To address the aforementioned problems in related technologies, this application provides a snapshot generation method, the application scenarios of which will be explained below.

[0019] Figure 1 This is a schematic diagram of the structure of the distributed system provided in the embodiments of this application. Please refer to... Figure 1 The snapshot generation method provided in this embodiment of the invention is applied to a distributed system, such as a distributed file system. This distributed file system is used to integrate the storage resources of multiple physical or virtual devices into a unified storage space, providing highly reliable, high-concurrency, and scalable data access services for upper-layer applications.

[0020] The aforementioned distributed system may include: client device 110, control node device 120, metadata node device 130, and data node device 140. These node devices communicate with each other via a network to collaboratively perform operations such as data reading and writing, metadata management, system status maintenance, and snapshot creation.

[0021] It should be noted that in a distributed system, any one of the above four types of node devices can be included in one or more.

[0022] The client device 110 serves as the entry point for users or applications to access the distributed system. The client device 110 can be a physical server, virtual machine, container instance, or terminal computing device. The client device 110 initiates data read and write requests to the distributed system. When writing data, the client device 110 divides the data to be written into one or more data blocks and sends these data blocks, carrying a snapshot version number, to the corresponding metadata node device or data node device. When reading data, the client device 110 queries the metadata node device for data location information and retrieves the data from the data node device based on the returned location information. Furthermore, the client device 110 maintains its local snapshot version number, version list, and version context of open data streams to achieve version coordination with other node devices in the distributed system.

[0023] The control node device 120 serves as the control center of the distributed system. The control node device 120 can be a physical server or a virtual machine. The control node device 120 generates and manages globally unique snapshot version numbers, which serve as logical snapshot boundaries and identify the data state of the distributed system at a specific logical point in time. The control node device 120 also issues preparation tasks and commit instructions to the metadata node devices and data node devices, coordinating the snapshot creation process among participating nodes. Furthermore, the control node device 120 maintains a volume-level version list, recording all snapshot version numbers and their states for the current volume. Finally, the control node device 120 monitors the operational status of each metadata node device 130 and data node device 140, and performs fault recovery operations in case of node failure.

[0024] Metadata node device 130 is a node that manages metadata in a distributed system. Metadata node device 130 can be a physical server or a virtual machine. Metadata node device 130 is used to store and manage metadata information such as the directory tree structure, filenames, file attributes, file sizes, access permissions, creation time, and modification time of the file system. Metadata node device 130 is also used to maintain the location mapping information of file data blocks on data node devices, such as disk extent information, which records the correspondence between file logical offsets and the physical storage addresses of data node devices. During snapshot creation, metadata node device 130 is used to generate a metadata snapshot based on the snapshot version number issued by the control node device. The metadata snapshot includes at least the directory tree structure, file attributes, and the frozen state of disk extent information at the time of the snapshot. Metadata node device 130 is also used to process metadata query requests initiated by client devices and return the location mapping information of file data blocks to the client devices.

[0025] Data node device 140 is the node in the distributed system that actually stores user data. Data node device 140 can be a physical server, storage server, or computing device equipped with high-capacity storage media. Data node device 140 is used to store the actual data blocks of file content; the data blocks are user data in binary format. Data node device 140 is also used to respond to data read / write requests initiated by client devices or metadata node devices, performing write, read, modify, or delete operations on data blocks. During snapshot creation, data node device 140 is used to generate a data snapshot based on the snapshot version number issued by the control node device. The data snapshot includes at least the frozen state of all data blocks stored on the data node device at the time of the snapshot. Data node device 140 is also used to maintain a local version list and version sequence number to support the storage and access of multiple versions of data.

[0026] It should be noted that in this distributed system, all node devices can exchange information. Figure 1The communication connections between nodes are not shown in the diagram.

[0027] The following explanation, based on the structure of the aforementioned distributed system, details one feasible implementation of the snapshot generation method provided in this application embodiment.

[0028] Figure 2 This is a flowchart illustrating the snapshot generation method provided in the embodiments of this application. Please refer to... Figure 2 The method includes: S210: When the snapshot creation process for the target volume is triggered, the metadata node device and the data node device generate a target snapshot and a target snapshot version number corresponding to the target volume, set the status of the target snapshot version number to the ready state, and send the target snapshot version number to the control node device.

[0029] It should be noted that triggering the snapshot creation process for the target volume refers to the timing of initiating a snapshot operation on the target volume. The snapshot creation process can be triggered in ways including but not limited to the following: users manually initiating a snapshot creation command through the management interface or command-line tools; the system automatically triggering the snapshot according to a preset time strategy, such as performing a snapshot at a set time every morning; or the system automatically triggering a snapshot when it detects that the amount of data changes has reached a preset threshold.

[0030] The snapshot creation process can be triggered by the client device sending a trigger message to the control node device, or it can be triggered automatically by the control node device according to a preset time policy. After triggering the snapshot creation process of the target volume, the control node device can issue a corresponding preparation task to the metadata node device and the data node device. This preparation task is used to instruct the metadata node device and the data node device to prepare to generate the snapshot.

[0031] Optionally, a target volume refers to a logical storage unit in a distributed system designated to perform a snapshot operation. A target volume can correspond to a file system, a logical partition, or a storage pool. The metadata information of the target volume is managed by the metadata node device, while its actual data content is stored by the data node device.

[0032] It should be noted that after receiving the preparation task sent by the control node device, the metadata node device and the data node device can generate the target snapshot and the target snapshot version number corresponding to the target volume.

[0033] The snapshot generated by the metadata node device is a metadata snapshot, which may include the directory tree structure, file name, file attributes, file size, access permissions, creation time, modification time, and location mapping information of file data blocks on the data node device.

[0034] The snapshot generated by the data node device is a data snapshot, which may include the contents of all data blocks belonging to the target volume stored on the data node device.

[0035] It should be noted that metadata snapshots and data snapshots together constitute the aforementioned target snapshot.

[0036] Example: When a directory volume containing multiple files needs to be snapshotted, the metadata node device records the name, size, permissions of all files in the directory volume, and which data node devices each file's data blocks are distributed on. The data node device records the specific binary content of each data block at the snapshot time.

[0037] It should be noted that the target snapshot version number is a logical identifier used to identify the target snapshot. This target snapshot version number is generated by the metadata node device or data node device according to preset rules. As a logical snapshot boundary, the target snapshot version number is used to distinguish the data state of the target volume at the time of the snapshot from the data state after subsequent changes.

[0038] The target snapshot version number can be implemented in several ways. For example, it can use a monotonically increasing sequence number, incrementing by one with each snapshot generation; or it can use a combination of timestamp and node identifier to generate a globally unique number; or it can use a universally unique identifier. For example, assuming the target volume already has a snapshot with version number 100, the version number of the snapshot generated this time could be 101.

[0039] It should be noted that setting the target snapshot version number to the ready state means that when the metadata node device and the data node device generate the target snapshot, they mark the target snapshot version number as not yet effective in their respective version lists.

[0040] In other words, the ready state indicates that the data content of the target snapshot has been generated and stored in the storage media of each node, but the snapshot is not yet available for external reading or access. The version list is a data structure maintained locally on each node device to record the version numbers and status of all snapshots in which that node has participated.

[0041] For example, the version list of the metadata node device records snapshot version numbers 100, 101, and 102. Snapshot version number 102 is marked as ready, indicating that the metadata corresponding to this snapshot has been generated but has not yet taken effect. Snapshot versions 100 and 101 are in the effective state, indicating that the corresponding snapshots are available for reading.

[0042] Correspondingly, sending the target snapshot version number to the control node device means that after the metadata node device and data node device complete the local snapshot generation, they report the generated target snapshot version number to the control node device through a distributed system.

[0043] The sending operation can be performed independently by the metadata node device and the data node device after they have each completed snapshot generation, or it can be coordinated and sent by multiple nodes in a consolidated manner. Once the control node device receives the target snapshot version number, it knows that all participating nodes have completed the preparation of snapshot data.

[0044] S220: After obtaining the target snapshot version number, the control node device sends snapshot submission instructions to the metadata node device and the data node device respectively.

[0045] It should be noted that after receiving the target snapshot version number, the control node device can record and verify the snapshot version number.

[0046] For example, after obtaining the target snapshot version number, the control node device can record the target snapshot version number in the volume-level version list maintained by the control node device, and mark the status of the target snapshot version number as pending commit. The volume-level version list is a data structure table maintained by the control node device to record all snapshot version numbers of the target volume and their global status.

[0047] A snapshot commit command is a control message used by the control node device to notify all participating nodes to perform a snapshot activation operation. This command can carry the target snapshot version number so that each node knows which version number it needs to commit to. The control node device does not need to wait for each node to perform data copying or transfer operations before issuing the commit command; it only needs to confirm that each node has completed the preparation of the snapshot data before issuing the command.

[0048] S230: In response to the snapshot commit command, the metadata node device and the data node device set the status of the target snapshot version number to the effective status, thus completing the snapshot creation process for the target volume.

[0049] It should be noted that after receiving the snapshot commit instruction sent by the control node device, the metadata node device and the data node device can respond to the snapshot commit instruction by setting the snapshot version number status.

[0050] Optionally, setting the target snapshot version number to an active state means that the metadata node device and the data node device change the target snapshot version number in the ready state in their respective version lists to an active state according to the received commit instruction.

[0051] The "effective" status indicates that the snapshot has been officially confirmed and is available for reading and access by other node devices. Switching the target snapshot version number from the "ready" status to the "effective" status is a lightweight metadata operation that only involves updating the status field in the version list, without performing any data copying, data transfer, or data rewriting operations.

[0052] For example, after the status of version number 102 in the version list of the metadata node device is updated from the ready state to the effective state, the client device can read the metadata information at that snapshot time by specifying version number 102; after the status of version number 102 in the version list of the data node device is updated from the ready state to the effective state, the client device can read the data block content at that snapshot time by specifying version number 102.

[0053] After completing the above steps, the snapshot creation process for the target volume can be finished.

[0054] In one embodiment, after the snapshot creation process is completed, the metadata snapshot and the data snapshot are associated together by the same target snapshot version number, forming a consistent and complete view of the target volume at the snapshot time. When the client device reads the snapshot, it queries the metadata node device for metadata information by carrying the target snapshot version number. The metadata node device returns the directory tree structure and data block location mapping at the snapshot time based on the version number. The client device then reads the actual data blocks from the data node device based on the returned location mapping and carrying the same version number, thereby obtaining the complete snapshot data.

[0055] It should be noted that the snapshot creation process described above can be divided into the preparation phase (S210) and the commit phase (S230). The preparation and commit phases are independent of each other in time. The control node device can issue a commit command at any time after confirming that all metadata node devices and all data node devices have completed snapshot generation. A time interval is allowed between the preparation and commit phases. This time interval can be dynamically determined by the system based on the business load, for example, performing the commit operation when the system load is low.

[0056] In one embodiment, if the control node device fails to obtain the target snapshot version numbers of all participating nodes, or if any participating node fails during the preparation phase, the control node device sends a rollback command to the participating nodes that have already provided feedback. The participating nodes that have provided feedback delete the target snapshot version numbers in the preparation state from their respective version lists according to the rollback command and restore their version sequence numbers to the values ​​before the current snapshot creation. This rollback mechanism ensures that the snapshot creation process does not produce inconsistent intermediate states when any node fails, thus improving the system's fault tolerance.

[0057] In the snapshot generation method provided in this application embodiment, the metadata node device and the data node device directly generate the target snapshot and the corresponding target snapshot version number after triggering the snapshot creation process, and set the version number to a ready state. This allows each participating node to independently complete the preparation of local snapshot data during the snapshot preparation phase without waiting for real-time coordination from the control node, thus avoiding blocking of node write operations during the preparation phase. By issuing a commit command after obtaining the snapshot version number, the final effective operation of snapshot generation is asynchronous with data transmission. The commit phase does not require data copying or moving, eliminating the occupation of system storage bandwidth and computing resources during the snapshot generation process. By switching the state of the target snapshot version number from the ready state to the effective state in response to the commit command, the metadata node device and the data node device use the version number as the basis for the entire snapshot creation process. This ensures snapshot consistency while guaranteeing the ability of the distributed system to continuously provide write services during snapshot generation, improving system availability and snapshot creation efficiency.

[0058] The following explains the logical process of snapshot generation provided in the embodiments of this application.

[0059] Figure 3 For a schematic diagram of the snapshot generation provided in the embodiments of this application, please refer to... Figure 3 The logical steps are as follows: First, a snapshot request can be created. This snapshot request can be sent by the client device to the control node device or generated by the control node device itself; no specific restrictions are imposed here.

[0060] Secondly, after creating a snapshot request, the control node device can send a preparation task to the metadata node device and the data node device. The metadata node device and the data node device generate a target snapshot and a target snapshot version number corresponding to the target volume, set the status of the target snapshot version number to the preparation state, and send the target snapshot version number to the control node device.

[0061] Finally, after obtaining the target snapshot version number, the control node device sends snapshot commit commands to both the metadata node device and the data node device. In response to the snapshot commit commands, the metadata node device and the data node device set the target snapshot version number to an active state, completing the snapshot creation process for the target volume.

[0062] Figure 3 The logical steps shown represent the complete interaction between multiple node devices during the snapshot creation process.

[0063] It should be noted that in the snapshot creation process used in related technologies, data writing cannot be performed during the snapshot creation period. However, the snapshot creation process provided in this application embodiment does not affect the data writing process. The following explains one feasible implementation process of data writing provided in this application embodiment.

[0064] Figure 4 This is a schematic diagram of the interaction written by the client node in the embodiments of this application. Please refer to... Figure 4 The method also includes: S410: The client device sends a write request to the metadata node device or data node device, and the write request carries the first snapshot version number of the client device.

[0065] It should be noted that before initiating a write request, the client device maintains the currently used snapshot version number locally, which is recorded in the client device's local version manager. This version number represents the snapshot view currently perceived by the client device, that is, the data space corresponding to which snapshot version the client device expects to write data to.

[0066] Optionally, a write request is a request initiated by a client device to the distributed system for writing data. This request includes at least the data to be written, the target location information, and the snapshot version number currently maintained by the client device. The data to be written can be newly created file data or modified data of an existing file. The target location information indicates the specific file or directory path to which the data needs to be written. The snapshot version number maintained by the client device is the aforementioned first snapshot version number, which can be carried as a specific field in the write request so that the receiving device can identify the snapshot view to which the write request belongs.

[0067] It should be noted that the specific path the client device sends a write request to the metadata node device or data node device depends on the type of write operation. If the write operation involves metadata changes, such as creating a new file, modifying file attributes, or renaming a file, the client device sends the write request to the metadata node device. If the write operation only involves changes to the content of a data block, such as appending data to an existing file or modifying file content, the client device can directly send the write request to the data node device responsible for storing that data block.

[0068] Optionally, the client device obtains the location information of the data block in advance by querying the metadata node device, and thus can determine which data node device to send the write request to.

[0069] For example, a client device needs to append data to an existing file. The client device maintains a first snapshot version number of 100 locally. The client device constructs a write request, which includes the data to be appended, the path to the target file, and the first snapshot version number 100. Then, based on pre-acquired location information, the client device sends the write request to the data node device storing the data block of that file.

[0070] S420: The metadata node device or data node device receives a write request and compares the first snapshot version number with the target snapshot version number.

[0071] It should be noted that the metadata node device or data node device, as the recipient of write requests, can receive write requests from client devices through the network communication protocol of the distributed system.

[0072] After receiving the write request, the receiving device parses the first snapshot version number field from the request message and obtains the first snapshot version number of the client device.

[0073] After obtaining the first snapshot version number, it can be compared with the target snapshot version number. This target snapshot version number is uniformly managed by the control node device and has been applied to each metadata node device and data node device through the aforementioned snapshot generation method.

[0074] It should be noted that each node device maintains its current snapshot version number locally, which records the snapshot view that the node is currently in. Under normal circumstances, the target snapshot version numbers maintained by the metadata node device and the data node device are consistent, jointly identifying the latest snapshot boundary of the target volume.

[0075] Optionally, the receiving device compares the parsed first snapshot version number with the target snapshot version number maintained locally to determine whether the snapshot view perceived by the client device is consistent with the actual snapshot view of the distributed system.

[0076] The comparison operation is performed by the processing unit of the receiving device, and the comparison result includes the following two cases: the first snapshot version number is equal to the target snapshot version number, or the first snapshot version number is less than the target snapshot version number.

[0077] It should be noted that since the target snapshot version number is maintained by the control node device, and the version number of the control node device is the first snapshot version number updated in the entire distributed system, there is usually no situation where the first snapshot version number is greater than the target snapshot version number.

[0078] S430: If the first snapshot version number is equal to the target snapshot version number, the metadata node device or data node device performs the data write operation corresponding to the write request.

[0079] It should be noted that when the comparison result shows that the first snapshot version number is equal to the target snapshot version number, it means that the snapshot view currently perceived by the client device is consistent with the actual snapshot view of the distributed system. Figure 1 The client device's write request belongs to a currently valid snapshot view. In this case, the receiving device confirms the write request is valid and can continue the write operation.

[0080] The specific content of the data write operation corresponding to the write request depends on the type of write request. If the write request is sent to the metadata node device, the data write operation includes updating the metadata information of the target file in the storage medium of the metadata node device, such as updating the file size, modification time, data block location mapping, etc. If the write request is sent to the data node device, the data write operation includes writing the data to be written to the specified storage location in the storage medium of the data node device, such as modifying data in existing data blocks or appending new data blocks.

[0081] In one embodiment, when performing a write operation, the receiving device stores the data to be written in association with the current target snapshot version number. For the data node device, the written data block is marked with the target snapshot version number to distinguish that the data belongs to the current snapshot view. For the metadata node device, the updated metadata information is also marked with the target snapshot version number.

[0082] In the snapshot generation method provided in this application, when a client device initiates a write operation, it only needs to include the locally maintained snapshot version number in the request. The server device can determine the validity of the write request by comparing the version numbers once. If the snapshot version numbers match, the write operation is executed directly without additional version negotiation or status query overhead. This mechanism ensures the efficiency of the write operation, allowing the preparation and commit phases of the snapshot creation process to run completely in parallel with the write operation. The snapshot generation operation does not block the client's write request, thereby realizing the service capability of a distributed system during the snapshot creation process without interruption.

[0083] In one embodiment, after the metadata node device or data node device receives a write request and compares the first snapshot version number with the target snapshot version number, the method further includes: S440: If the first snapshot version number is less than the target snapshot version number, the metadata node device or data node device returns a version update response to the client device.

[0084] The version update response includes the target snapshot version number and a list of versions maintained by the metadata node device or data node device.

[0085] It should be noted that when the comparison result shows that the first snapshot version number is less than the target snapshot version number, it means that the snapshot version number currently perceived by the client device is lower than the actual snapshot version number of the distributed system.

[0086] This situation typically occurs in the following scenario: the client device initiates a write request before the snapshot is created, but the distributed system completes the snapshot creation and updates the target snapshot version number during the transmission or processing of the request, resulting in the version number carried by the client device being lower than the current version number of the server device.

[0087] In this situation, the receiving device cannot directly execute the write request because the request points to an outdated snapshot view. The metadata node device or data node device can return a version update response to the client device.

[0088] The version update response must include at least the target snapshot version number and a list of versions maintained by the receiving device. The target snapshot version number informs the client device of the current actual snapshot version number of the distributed system. The version list provides the client device with all version information from the first snapshot version number to the target snapshot version number, enabling the client device to perform version alignment.

[0089] In one embodiment, the receiving device sends a version update response to the client device via the network communication channel of the distributed system. This version update response includes a specific status code or flag to indicate that the response is a version update response rather than a normal write response, thereby enabling the client device to recognize the response and trigger the version update process.

[0090] S450: The client device updates the first snapshot version number maintained by the client device to the target snapshot version number according to the version update response.

[0091] In one embodiment, after receiving a version update response, the client device can parse the response message to obtain the target snapshot version number and version list. The client device identifies the response as a version update response based on the status code or flag bits in the response, thereby initiating the local version update process.

[0092] The client device updates the locally maintained first snapshot version number to the target snapshot version number carried in the response. This update operation is performed by the client device's local version manager and involves modifying the locally stored snapshot version number field from its original value to the target snapshot version number. This update operation is a memory operation or a lightweight persistent storage operation, and its execution speed is relatively fast.

[0093] It should be noted that while updating the snapshot version number, the client device can also update its local version list information based on the version list carried in the response. The version list is used to record the version numbers of each historical snapshot in the distributed system and their corresponding states. The client device maintains this list to correctly carry the version numbers in subsequent read and write requests.

[0094] For example, the client device's original first snapshot version number is 100, and the target snapshot version number in the received version update response is 101. The client device updates its local first snapshot version number from 100 to 101 and saves the version list carried in the response locally, completing the version synchronization.

[0095] The snapshot generation method provided in this application allows a client device to synchronize its version with the metadata node device or data node device even when the client device's version number is lower than that of the metadata node device or data node device. The metadata node device or data node device returns the target snapshot version number and a list of versions in a version update response, avoiding the need for the client device to query multiple times to obtain complete version information. This mechanism ensures that the client device maintains version consistency with the metadata node device or data node device, allowing normal writing to resume immediately after version synchronization. This reduces write latency caused by version inconsistencies. Furthermore, the update method avoids pausing the write process, instead updating first and then writing, thus achieving a non-stop write service capability during snapshot creation in the distributed system.

[0096] In one embodiment, after updating the first snapshot version number maintained by the client device to the target snapshot version number, the method further includes: S460: The client device updates the locally cached data based on the target snapshot version number.

[0097] The data for updating the local cache includes at least one of the following: refreshing the disk area information in the local cache and marking the open data stream as a version to be updated.

[0098] It should be noted that after the client device updates the first snapshot version number to the target snapshot version number, the locally cached data related to the old version needs to be updated accordingly to keep it consistent with the new version number.

[0099] The extent information is cached locally on the client device and describes the physical storage location of file data blocks on the data node device. This information includes the mapping between file logical offsets and the physical addresses of the data node device. When the snapshot version number changes, the location mapping of file data blocks may have changed during the snapshot creation process. Therefore, the client device needs to refresh the locally cached extent information to make it consistent with the data distribution corresponding to the target snapshot version number. Refreshing the extent information can be done by either re-querying the extent information of the target file from the metadata node device or invalidating the locally cached extent information so that it can be retrieved again on the next access.

[0100] An open data stream refers to a data stream object that is currently in use by the client device and has not yet been closed. These data streams are associated with a specific snapshot version number when they are opened. When the client device's snapshot version number is updated, the version number associated with the open data stream no longer matches the new target snapshot version number. Therefore, these data streams need to be marked as pending update, indicating that they require version alignment before the next operation. Specific methods for marking an open data stream as pending update include setting a flag in the data stream's control structure or adding the data stream to a queue for updates.

[0101] S470: The client device resends the write request based on the updated snapshot version number.

[0102] It should be noted that after updating the local version number and local cached data, the client device reconstructs the write request using the updated snapshot version number. The reconstructed write request has the same format as the original write request, but the snapshot version number field is updated to the target snapshot version number. The client device then resends the reconstructed write request to the metadata node device or data node device through the network communication channel of the distributed system.

[0103] After the resent write request arrives at the server device, the server device performs the same version number comparison operation as in step S420 above. Since the client device's first snapshot version number has been updated to the target snapshot version number, the comparison result is that the first snapshot version number equals the target snapshot version number. The server device will then execute the data write operation corresponding to the write request, and the write operation will be completed successfully.

[0104] For example, the client device reconstructs the write request, setting the version number field to 101, and resends the request to the data node device. Upon receiving the request, the data node device compares the version numbers and finds that the version number 101 carried by the client matches the local target snapshot version number 101. Therefore, it performs the data write operation and successfully writes the data.

[0105] The snapshot generation method provided in this application allows the client device to re-execute write requests that failed due to version inconsistency after version number synchronization is complete, ensuring the eventual successful execution of the write operation. By refreshing the locally cached disk information, the client device avoids write location errors caused by expired disk information, improving write accuracy. By marking the status of open data streams, the client device can systematically identify and update all data streams affected by version changes, preventing data write anomalies due to missed updates. This retry mechanism enables write requests to automatically recover when encountering version inconsistencies without manual intervention, thereby achieving a non-stop write service capability for the distributed system during snapshot creation.

[0106] The following section will explain in detail the logical relationship of client node updates provided in the embodiments of this application.

[0107] Figure 5 This is a schematic diagram of the client node update logic provided in the embodiments of this application. Please refer to... Figure 5 , Figure 5 This includes client nodes and server nodes, where client nodes correspond to the aforementioned client devices, and server nodes correspond to the aforementioned metadata node devices or data node devices.

[0108] The method includes: S510: The client node sends a write request.

[0109] S520: The server node performs a version check. If the versions are equal, the write operation is completed; otherwise, a version update response is returned to the client.

[0110] S530: Client nodes perform snapshot version updates based on version update responses.

[0111] S540: Client node: The client device resends the write request based on the updated snapshot version number.

[0112] S550: The server node has completed the write operation.

[0113] It should be noted that the implementation process of the above steps has already been explained above, and will not be repeated here.

[0114] In one embodiment, during a write operation, the content corresponding to the write request can be written to the snapshot view of the target snapshot.

[0115] The snapshot view refers to the latest data view that is currently in effect in the distributed system after the snapshot is created, and the modified content can be stored in the next snapshot view.

[0116] The following explains the steps that can be performed by various devices in the distributed system during the snapshot generation process provided in the embodiments of this application: In one embodiment, before issuing snapshot submission instructions to the metadata node device and the data node device respectively, the method further includes: when the control node device confirms that all metadata node devices and all data node devices have completed snapshot generation, recording the target snapshot version number in the volume-level version list maintained by the control node device, and marking the status of the target snapshot version number as pending submission; the control node device stores the volume-level version list.

[0117] It should be noted that after generating the metadata snapshot, the metadata node device returns a "ready to succeed" response to the control node device. This response carries confirmation that the metadata node device has successfully generated the target snapshot. Similarly, after generating the data snapshot, the data node device returns a "ready to succeed" response to the control node device. The control node device counts the number of nodes that have returned a "ready to succeed" response. When this number equals the total number of nodes involved in this snapshot creation, the control node device confirms that all nodes have successfully generated their snapshots.

[0118] The volume-level version list is a data structure maintained by the control node device in the local storage medium to record all snapshot version numbers and their global status for the target volume. This volume-level version list is indexed by the target volume, with each target volume corresponding to an independent version list. Each record in the volume-level version list contains a snapshot version number field and a status field, the status field indicating the current status of that snapshot version number.

[0119] In one embodiment, after confirming that all nodes have completed snapshot generation, the control node device adds the target snapshot version number as a new record to the volume-level version list and sets the status field of this record to "pending commit". The "pending commit" status indicates that the target snapshot version number has been successfully prepared by all participating nodes, but has not yet taken effect; this status is an intermediate transitional state between the preparation state and the commit state.

[0120] The storage of volume-level version lists by the control node device refers to the control node device writing the updated volume-level version list to its local persistent storage medium. Specific implementation methods for this storage operation include writing the volume-level version list to a local disk file on the control node device, or writing it to a non-volatile storage device mounted on the control node device.

[0121] This storage operation is a synchronous write operation, meaning the control node device waits for confirmation that the data has been written to disk before proceeding with subsequent steps. This ensures that the pending status records in the volume-level version list are not lost in the event of a power outage or restart of the control node device. Through this storage operation, the control node device persistently stores the target snapshot version number and its pending status, serving as a basis for subsequent fault recovery.

[0122] Accordingly, snapshot submission instructions are issued to the metadata node device and the data node device respectively, including: when the preset conditions are met, the control node device marks the status of the target snapshot version number as a submission status; when the status of the target snapshot version number is marked as a submission status, the control node device generates a snapshot submission instruction and issues it to the metadata node device and the data node device respectively.

[0123] It should be noted that the preset conditions are the preliminary judgment criteria for the control node device to trigger the commit operation. These preset conditions determine when the snapshot will finally take effect. The preset conditions include at least one of the following: the control node device detects that the load of the distributed system is below a preset threshold, such as CPU utilization below 30% or network bandwidth usage below 50%; the control node device detects that the current time is within a preset low-peak period, such as between 00:00 and 06:00 daily; the control node device receives a commit command manually triggered by a user or administrator through the management interface; the control node device detects that all participating nodes are in a stable operating state, such as normal heartbeat responses and no fault alarms. The specific settings of the preset conditions can be configured and adjusted by the system administrator according to actual business needs, and no specific restrictions are imposed here.

[0124] After persistently storing the volume-level version list, the control node continuously checks whether preset conditions are met. When the control node detects that the preset conditions are met, it initiates a commit operation. The first step of the commit operation is to update the status of the target snapshot version number from "pending commit" to "committed." This status update operation is performed on the record corresponding to the target snapshot version number in the volume-level version list maintained locally by the control node, changing the value of the status field from "pending commit" to "committed." The commit status indicates that the target snapshot version number has taken effect, and various node devices can perform operations such as reading and viewing the snapshot.

[0125] In one embodiment, the control node device can generate a snapshot commit instruction when the target snapshot version number is marked as committed. The snapshot commit instruction is a control message sent by the control node device to the metadata node device and the data node device.

[0126] The snapshot commit command must include at least a target snapshot version number field so that each participating node knows which version number to commit to. The snapshot commit command uses the protocol message format defined in the distributed system, including a message type field, a version number field, and a timestamp field.

[0127] In the snapshot generation method provided in this application embodiment, the control node device persistently stores the pending status records in the volume-level version list, ensuring that the completion status of the preparation phase remains traceable even after the control node device fails and restarts. The system can resume the submission operation based on the persistent records, avoiding the problem of the snapshot creation process being interrupted due to a control node failure and unable to continue. At the same time, the control node device flexibly controls the submission timing according to preset conditions, allowing the final snapshot activation operation to be executed when the system load is low, avoiding the submission operation competing for system resources with high-frequency writes during peak business periods. Through the above design, the preparation phase and the submission phase can be processed asynchronously in time, realizing asynchronous scheduling of snapshot submission operations and further reducing the impact of the snapshot creation process on business performance.

[0128] Figure 6 For another logical diagram of snapshot generation provided in the embodiments of this application, please refer to... Figure 6 In the process of generating a snapshot, a data persistence step is added between the preparation phase and the commit phase. By persistently storing the pending status records in the volume-level version list, the preparation phase and the commit phase can be processed asynchronously in time.

[0129] The snapshot generation method provided in this application embodiment can also guarantee the view of multiple nodes. Figure 1 To the point of being responsive.

[0130] Figure 7 This is a logical diagram illustrating multi-node consistency provided in the embodiments of this application. Please refer to... Figure 7 During the implementation of this scheme, client devices, control node devices, metadata node devices, and data node devices all participate in the iteration of the snapshot version number. Therefore, there will be no inconsistency between the metadata and data snapshot versions.

[0131] The following explains the process of version updates between nodes of the server provided in this embodiment.

[0132] Figure 8 For a logical diagram illustrating the version update process of each node on the server provided in this embodiment, please refer to... Figure 8 Before the metadata node device and the data node device generate the target snapshot and the target snapshot version number corresponding to the target volume, the method further includes: S810: The metadata node device or data node device obtains the target snapshot version number in the target task issued by the control node device, and compares the target snapshot version number with the snapshot version number maintained by itself.

[0133] It should be noted that the target task can be the aforementioned preparation task, which may include a target snapshot version number field and a version list field. The target snapshot version number is a logical version identifier assigned by the control node device for this snapshot creation process, used to identify the snapshot to be created. The version list is a data structure maintained by the control node device that records the version numbers and status of all historical snapshots of the target volume, used for version synchronization by all participating node devices.

[0134] It should be noted that the metadata node device or data node device, as the recipient of the target task, receives the target task issued by the control node device through the network communication protocol of the distributed system. The receiving device parses the target snapshot version number field from the message structure of the target task to obtain the logical version identifier assigned by the control node device for this snapshot.

[0135] The self-maintained snapshot version number refers to the currently effective snapshot version number recorded by the metadata node device or data node device in the local storage medium. Each node device continuously maintains this version number during normal operation, and it is updated to the latest effective snapshot version number each time the distributed system completes a snapshot creation.

[0136] The receiving device can compare the target snapshot version number with its own maintained snapshot version number stored locally to determine whether the snapshot version expected by the control node device is consistent with the snapshot version currently recognized by the node device. This comparison operation is performed by the processing unit of the receiving device, and the comparison result includes the following two cases: the target snapshot version number is consistent with its own maintained snapshot version number, or the target snapshot version number is inconsistent with its own maintained snapshot version number.

[0137] S820: If the target snapshot version number is inconsistent with the snapshot version number maintained by itself, the metadata node device or data node device shall update the snapshot version number maintained by itself to the target snapshot version number according to the version list issued by the control node device.

[0138] It should be noted that when the comparison result shows that the target snapshot version number is inconsistent with the snapshot version number maintained by itself, it means that the snapshot version number currently recognized by the node device is different from the snapshot version number expected by the control node device, that is, the version information of the node device is lagging behind the expected value of the control node device.

[0139] This situation typically occurs in the following scenario: the node device failed to update the version number in time during the previous snapshot creation process due to network latency, failure restart, or excessive load, resulting in the local snapshot version number being out of sync with the global snapshot version number recorded by the control system.

[0140] In the above scenario, the receiving device obtains the version list issued by the control node device from the target task. This version list is a complete version record maintained by the control node device, containing the version numbers of all historical snapshots of the target volume and their corresponding status information. The receiving device then performs a local version number update operation based on this version list.

[0141] It should be noted that updating the snapshot version number maintained by the device itself to the target snapshot version number means that the receiving device modifies the value of the current snapshot version number field stored locally to the target snapshot version number, so that the snapshot version number maintained locally is consistent with the target snapshot version number issued by the control node device.

[0142] This update operation also involves the synchronous update of the local version list. Specifically, the receiving device updates its local version list data based on the version list sent by the control node device, ensuring that the version numbers and their statuses in the local version list are consistent with the global version list recorded by the control node device. After this update operation is completed, the snapshot version number maintained by the receiving device itself is consistent with the target snapshot version number, and the node device is now aligned with the desired version of the control node device.

[0143] For example, the target task issued by the control node device carries a target snapshot version number of 101, and the version list records version numbers 100 and 101. A data node device maintains its own snapshot version number as 100. A comparison reveals that the target snapshot version number 101 is inconsistent with its own maintained version number 100. This data node device retrieves the version list from the target task, updates its own maintained snapshot version number from 100 to 101 based on the version list, and simultaneously updates the version list to include records containing version numbers 100 and 101. After the update, the data node device's own maintained snapshot version number matches the target snapshot version number, and it can continue with subsequent snapshot generation operations.

[0144] Correspondingly, if the target snapshot version number is consistent with the snapshot version number maintained by itself, the node device does not need to perform a version update operation and can directly enter the snapshot generation process.

[0145] In the snapshot generation method provided in this application embodiment, by performing version verification operations on the metadata node device and the data node device before snapshot generation, it is ensured that the snapshot version number maintained by each participating node when it starts to generate a snapshot is consistent with the target snapshot version number expected by the control node device. This avoids the problem that the generated snapshot data cannot correspond to the global version record of the control node device due to the version lag of some nodes. It ensures that all participating nodes in the distributed system are at the same snapshot version before snapshot generation, which facilitates version uniformity during the data writing process.

[0146] In one embodiment, the target snapshot version number corresponding to the target volume is generated by the control node device in one of the following ways: Method 1: The control node device generates the target snapshot version number corresponding to the target volume based on the locally maintained monotonically increasing sequence.

[0147] It should be noted that the control node device can maintain a monotonically increasing integer counter, whose initial value can be set to 0 or 1. Whenever the control node device needs to generate a new snapshot version number, it reads the current counter value as the version number of this snapshot, then increments the counter and writes it back to the storage medium. This method ensures that the generated snapshot version numbers are strictly incremental, with later-generated snapshot version numbers always greater than earlier-generated ones, thus clearly distinguishing the order in which snapshots were created. The monotonically increasing sequence can be implemented using increment operations to ensure that multiple version number generation requests do not conflict in high-concurrency scenarios. Because the sequence is monotonically increasing, the snapshot version number itself carries time sequence information; by comparing the magnitudes of two version numbers, the order of the corresponding snapshots can be determined.

[0148] Method 2: The control node device generates the target snapshot version number corresponding to the target volume based on the current timestamp, and corrects the target snapshot version number corresponding to the target volume when a timestamp conflict is detected.

[0149] It should be noted that the control node device obtains the current system time and uses the timestamp as the base value for the snapshot version number. The timestamp can use microsecond or nanosecond precision to reduce the probability of duplication. While there may be discrepancies in the system time between different node devices, the control node device, as a single management node, maintains relative consistency in its own system clock. When two snapshot creation requests occur within the same timestamp precision, a situation may arise where the timestamps are identical, i.e., a timestamp conflict. After generating the version number, the control node device checks whether the version number already exists. If a conflict is detected, the version number is corrected. Correction methods include adding an offset to the timestamp or appending a sequence number to the timestamp to distinguish different versions under the same timestamp.

[0150] Method 3: The control node device generates the target snapshot version number corresponding to the target volume based on the log index or term number maintained by the consensus mechanism.

[0151] It should be noted that when control node devices are deployed in a cluster, multiple control node instances maintain a consistent state through a consensus mechanism. This consensus mechanism can be either the Raft protocol or the Paxos protocol. In the Raft protocol, the log index is used to uniquely identify the position of a log entry in the log sequence, and the term number is used to identify the leader's term. When initiating a snapshot creation request, the control node device can use the index value of the current consensus log or a combination of the term number and the index value as the snapshot version number. Since the log index is globally unique and monotonically increasing in the consensus mechanism, the snapshot version number generated based on the log index naturally possesses global uniqueness and incrementing properties.

[0152] Method 4: The control node device generates the target snapshot version number corresponding to the target volume by combining the logical clock value and the node identifier of the control node device.

[0153] It should be noted that the control node device maintains a logical clock, which is an integer value that increments each time a new version number is generated. The logical clock value can be updated based on the order in which events occur, for example, using a Lamport clock or a vector clock. The control node device combines the current logical clock value with its own node identifier to generate a snapshot version number. The node identifier is a unique identifier for the control node device in the distributed system and can be an IP address, device ID, or UUID. Combination methods include appending the node identifier as a prefix or suffix to the logical clock value, or performing bitwise operations on the logical clock value and the node identifier to merge them into a composite value.

[0154] In practice, the snapshot version number can be implemented using any of the methods mentioned above, without any specific restrictions.

[0155] In one embodiment, the control node device may also use any determination strategy to determine whether to enter the submission phase. For example, the control node device confirms that the preparation phase is complete after receiving a successful preparation response from more than half of the nodes participating in this snapshot creation process.

[0156] For example, the control node device can confirm preparation completion solely based on the successful preparation response returned by the primary node of each data partition, without waiting for responses from all replica nodes. For nodes that have not returned a response for an extended period or are in a faulty state, the control node device can enable a forced strategy, i.e., proceed with the commit while ignoring unavailable nodes; in addition, the control node device records the abnormal state of unavailable nodes, and once the node recovers, it is aligned with the current snapshot version through a version catch-up mechanism.

[0157] In one embodiment, the version status can be further refined into multiple states to adapt to different reliability requirements. Specifically, the version status can include the following states: Preparing state, indicating that the snapshot version number has been assigned but snapshot data preparation has not yet begun; Prepared state, indicating that all participating nodes have completed snapshot data preparation, corresponding to the aforementioned prepared state; Submitting state, indicating that the control node device has issued a submit command but some nodes have not yet completed the activation operation; Normal state, indicating that the snapshot has taken effect and can be accessed normally, corresponding to the aforementioned activated state; Deleting state, indicating that the snapshot is being deleted and the data has not been completely cleaned up; Abnormal state, indicating that an error occurred during snapshot creation and cannot be completed normally; Timeout state, indicating that the snapshot creation process has exceeded the preset time limit.

[0158] In one embodiment, the client device can also trigger version updates in multiple ways. Specifically, the server device proactively includes the current version list in its response to a normal write request, and the client device synchronously updates its local version information upon receiving the response; the metadata node device includes the current version list in its response message when responding to the client device's metadata query request, and the client device updates its local version accordingly; the client device sends pull requests to the control node device or metadata node device at preset time intervals to periodically obtain the latest version information of the target volume; the control node device proactively pushes version change notifications to all client devices after snapshot creation, and the client devices update their local version numbers according to the notifications; after receiving a version error code returned by the server device, the client device forcibly refreshes the local cached extent information and version number.

[0159] In one embodiment, the write request can employ several different write strategies, such as: Redirect write strategy: New data is written directly to the new storage location, while existing data remains unchanged; Copy-on-write strategy: Before writing new data, the existing data is copied to the snapshot storage area, and then the write operation is performed; Segment splitting strategy: When the write position crosses an existing contiguous storage segment, the original segment is split into multiple segments, and new data is inserted at the split positions; New version append write strategy: All newly written data is appended to the new storage space, and the existing data blocks are not modified; Object storage versioning write strategy: In the underlying object storage system, each write generates a new object version, and the old version is automatically retained.

[0160] In one embodiment, this method can be applied to various application scenarios, such as: volume-level snapshot creation in distributed file systems to provide consistent data protection for the file system; bucket-level snapshot creation in distributed object storage to provide version management and data recovery capabilities for object storage; volume-level snapshot creation in distributed block storage to provide snapshot backup and fast recovery functions for block devices; consistent backup in multi-tenant storage systems to achieve point-in-time data freezing and backup at the tenant level; switching between cross-node metadata and data views to achieve a smooth transition during system upgrades or data migrations; and multi-version management scenarios such as snapshot deletion, snapshot rollback, and snapshot cloning, using a version number mechanism to achieve data management and operations between different snapshot versions. The above application scenarios are merely examples of typical applicable scenarios of this invention and do not constitute a limitation on the scope of application of this invention.

[0161] It should be understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0162] Based on the foregoing embodiments, this application provides a snapshot generation device, which includes various modules and units included in each module, and can be implemented by a processor; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), microprocessor (MPU), digital signal processor (DSP) or field programmable gate array (FPGA), etc.

[0163] Figure 9 This is a schematic diagram of the snapshot generation device provided in the embodiments of this application. Please refer to... Figure 9 In another aspect of the embodiments of this application, a snapshot generation apparatus is also provided, which is applied to a distributed system, including a control node device, a metadata node device, and a data node device; the apparatus includes a preparation module 910, a transmission module 920, and a submission module 930. The preparation module 910 is used to generate a target snapshot and a target snapshot version number corresponding to the target volume through the metadata node device and the data node device when the snapshot creation process of the target volume is triggered, set the status of the target snapshot version number to the preparation state, and send the target snapshot version number to the control node device. The transmission module 920 is used to send snapshot submission instructions to the metadata node device and the data node device respectively after the control node device obtains the target snapshot version number; The submission module 930 is used to respond to the snapshot submission command through the metadata node device and the data node device, set the status of the target snapshot version number to the effective status, and complete the snapshot creation process of the target volume.

[0164] In one embodiment, the distributed system further includes a client device; the device also includes a writing module, which is configured to send a write request to a metadata node device or a data node device through the client device, the write request carrying a first snapshot version number of the client device; receive the write request through the metadata node device or the data node device, and compare the first snapshot version number with a target snapshot version number; if the first snapshot version number is equal to the target snapshot version number, perform the data write operation corresponding to the write request through the metadata node device or the data node device.

[0165] In one embodiment, the apparatus further includes an update module, which is configured to return a version update response to the client device via a metadata node device or a data node device when the first snapshot version number is less than the target snapshot version number. The version update response carries the target snapshot version number and a version list maintained by the metadata node device or the data node device. The client device updates the first snapshot version number maintained by the client device to the target snapshot version number according to the version update response.

[0166] In one embodiment, the update module is further configured to update the locally cached data via the client device according to the target snapshot version number. The updated locally cached data includes at least one of the following: refreshing the local cache partition information and marking the opened data stream as the version to be updated; and resending the write request via the client device according to the updated snapshot version number.

[0167] In one embodiment, the submission module 930 is further configured to, upon confirming that all metadata node devices and all data node devices have completed snapshot generation, record the target snapshot version number in the volume-level version list maintained by the control node device and mark the status of the target snapshot version number as pending submission; store the volume-level version list through the control node device; mark the status of the target snapshot version number as submitted through the control node device when preset conditions are met; and when the status of the target snapshot version number is marked as submitted, generate a snapshot submission instruction and send it to the metadata node device and the data node device respectively.

[0168] In one embodiment, the preparation module 910 is further configured to obtain the target snapshot version number in the target task issued by the control node device through the metadata node device or the data node device, and compare the target snapshot version number with the snapshot version number maintained by itself; if the target snapshot version number is inconsistent with the snapshot version number maintained by itself, the metadata node device or the data node device updates the snapshot version number maintained by itself to the target snapshot version number according to the version list issued by the control node device.

[0169] In one embodiment, the target snapshot version number corresponding to the target volume is generated by the control node device in one of the following ways: The control node device generates the target snapshot version number corresponding to the target volume based on a locally maintained monotonically increasing sequence; or, The control node device generates the target snapshot version number corresponding to the target volume based on the current timestamp, and corrects the target snapshot version number corresponding to the target volume when a timestamp conflict is detected; or, The control node device generates the target snapshot version number corresponding to the target volume based on the log index or term number maintained by the consensus mechanism; or, The control node device generates the target snapshot version number corresponding to the target volume based on the combination of the logical clock value and the node identifier of the control node device.

[0170] In the snapshot generation apparatus provided in this application embodiment, the target snapshot and its corresponding version number are directly generated by the metadata node device and data node device after the snapshot creation process is triggered, and the version number is set to a ready state. This allows each participating node to independently complete the preparation of local snapshot data during the snapshot preparation phase without waiting for real-time coordination from the control node, thus avoiding blocking of node write operations during the preparation phase. By issuing a commit command after obtaining the snapshot version number, the final effective operation of snapshot generation is asynchronous with data transmission. The commit phase does not require data copying or moving, eliminating the occupation of system storage bandwidth and computing resources by the snapshot generation process. By switching the state of the target snapshot version number from the ready state to the effective state in response to the commit command, the entire snapshot creation process uses the version number as the basis, thereby ensuring snapshot consistency while guaranteeing the ability of the distributed system to continuously provide write services during snapshot generation, improving system availability and snapshot creation efficiency.

[0171] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0172] It should be noted that, in the embodiments of this application... Figure 9 The module division of the snapshot generation device shown is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or be integrated into one unit by two or more units. The integrated units can be implemented in hardware, as software functional units, or a combination of software and hardware.

[0173] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, 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 an electronic device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0174] Figure 10 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Please refer to... Figure 10 This application provides a computer device, which can be the control node device, the metadata node device, the data node device, or the client device described above. No specific limitations are imposed here; it can be a device corresponding to any node in a distributed system. Its internal structure diagram can be as follows: Figure 10 As shown.

[0175] The computer device includes a processor 1020, memory, and a network interface 1040 connected via a system bus 1010. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium 1031 and internal memory 1032. The non-volatile storage medium 1031 stores an operating system, computer programs, and a database. The internal memory 1032 provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium 1031. The database stores data. The network interface 1040 communicates with external terminals via a network connection. When the computer program is executed by the processor 1020, it implements the aforementioned methods.

[0176] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method provided in the above embodiments.

[0177] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the steps in the method provided in the above-described method embodiments.

[0178] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0179] In one embodiment, the snapshot generation apparatus provided in this application can be implemented as a computer program, and the computer program can be implemented in such a way as... Figure 10 The device operates on the computer device shown. The memory of the computer device can store the various program modules that make up the above-described apparatus. The computer program, composed of the various program modules, causes the processor to execute the steps of the methods in the various embodiments of this application described in this specification.

[0180] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium, storage medium, and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0181] It should be understood that the phrases "one embodiment," "an embodiment," or "some embodiments" mentioned throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment," "in one embodiment," or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be repeated here.

[0182] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three kinds of relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist simultaneously, and object B exists alone.

[0183] It should be noted that, in this document, 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. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0184] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or modules can be electrical, mechanical, or other forms.

[0185] The modules described above as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules. They may be located in one place or distributed across multiple network units. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0186] In addition, each functional module in the various embodiments of this application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the integrated modules can be implemented in hardware or in the form of hardware plus software functional units.

[0187] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0188] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, 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 an electronic device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0189] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0190] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0191] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0192] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A snapshot generation method, characterized in that, Applied to a distributed system, the distributed system including: a control node device, a metadata node device, and a data node device; the method includes: When the snapshot creation process for the target volume is triggered, the metadata node device and the data node device generate a target snapshot and a target snapshot version number corresponding to the target volume, set the status of the target snapshot version number to the ready state, and send the target snapshot version number to the control node device; After obtaining the target snapshot version number, the control node device sends snapshot submission instructions to the metadata node device and the data node device respectively. In response to the snapshot submission command, the metadata node device and the data node device set the status of the target snapshot version number to active status, thus completing the snapshot creation process for the target volume.

2. The method according to claim 1, characterized in that, The distributed system also includes client devices; the method further includes: The client device sends a write request to the metadata node device or the data node device, the write request carrying the first snapshot version number of the client device; The metadata node device or the data node device receives the write request and compares the first snapshot version number with the target snapshot version number; When the first snapshot version number is equal to the target snapshot version number, the metadata node device or the data node device performs the data write operation corresponding to the write request.

3. The method according to claim 2, characterized in that, After the metadata node device or the data node device receives the write request and compares the first snapshot version number with the target snapshot version number, the method further includes: If the first snapshot version number is less than the target snapshot version number, the metadata node device or the data node device returns a version update response to the client device. The version update response carries the target snapshot version number and the version list maintained by the metadata node device or the data node device. According to the version update response, the client device updates the first snapshot version number maintained by the client device to the target snapshot version number.

4. The method according to claim 3, characterized in that, After updating the first snapshot version number maintained by the client device to the target snapshot version number, the method further includes: The client device updates the data in the local cache according to the target snapshot version number. The updated data in the local cache includes at least one of the following: refreshing the disk area information in the local cache and marking the opened data stream as a version to be updated. The client device resends the write request based on the updated snapshot version number.

5. The method according to claim 1, characterized in that, Before issuing snapshot commit instructions to the metadata node device and the data node device respectively, the method further includes: When the control node device confirms that all metadata node devices and all data node devices have completed snapshot generation, it records the target snapshot version number in the volume-level version list maintained by the control node device and marks the status of the target snapshot version number as pending submission. The control node device stores the volume-level version list; The step of issuing snapshot commit instructions to the metadata node device and the data node device respectively includes: Under the condition that the preset conditions are met, the control node device marks the status of the target snapshot version number as a submission status. When the status of the target snapshot version number is marked as a submission status, the control node device generates the snapshot submission instruction and sends it to the metadata node device and the data node device respectively.

6. The method according to claim 1, characterized in that, Before the metadata node device and the data node device generate the target snapshot and target snapshot version number corresponding to the target volume, the method further includes: The metadata node device or the data node device obtains the target snapshot version number in the target task issued by the control node device, and compares the target snapshot version number with the snapshot version number maintained by itself; If the target snapshot version number is inconsistent with the snapshot version number maintained by itself, the metadata node device or the data node device shall update the snapshot version number maintained by itself to the target snapshot version number according to the version list issued by the control node device.

7. The method according to claim 1, characterized in that, The target snapshot version number corresponding to the target volume is generated by the control node device in one of the following ways: The control node device generates the target snapshot version number corresponding to the target volume based on a locally maintained monotonically increasing sequence; or, The control node device generates the target snapshot version number corresponding to the target volume based on the current timestamp, and corrects the target snapshot version number corresponding to the target volume when a timestamp conflict is detected; or, The control node device generates the target snapshot version number corresponding to the target volume based on the log index or term number maintained by the consensus mechanism; or, The control node device generates the target snapshot version number corresponding to the target volume by combining the logical clock value with the node identifier of the control node device.

8. A distributed system, characterized in that, The distributed system includes: a control node device, a metadata node device, and a data node device. When the distributed system is executed, it implements the steps of the method according to any one of claims 1-7.

9. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, The computer device is any node device in a distributed system, and the processor executes the program to implement the steps of the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images