Data reconstruction method, distributed storage system and computer readable storage medium
By deploying a proxy repair service in a distributed storage cluster and using local loopback ports and erasure coding algorithms for data reconstruction, the network bottleneck problem in high-proportion erasure coding scenarios is solved, and the data reconstruction efficiency and availability of the cluster are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-14
AI Technical Summary
In scenarios involving high-proportion erasure coding, data reconstruction can lead to network bottlenecks, resulting in excessive cluster network bandwidth consumption and impacting cluster reliability and performance.
Deploy a proxy repair service in a distributed storage cluster, obtain data reconstruction tasks through a local loopback port, and use erasure coding algorithms to reconstruct data on the local node, reducing cross-node network transmission.
It significantly alleviated the network bottleneck in data reconstruction and improved the data reconstruction efficiency and overall availability of the cluster.
Smart Images

Figure CN121858352A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of distributed storage technology, and in particular to a data reconstruction method, a distributed storage system, and a computer-readable storage medium. Background Technology
[0002] With the development of big data and cloud computing, distributed storage systems are widely used for the storage and management of massive amounts of data. In order to balance high data reliability and efficient utilization of storage resources, distributed storage systems typically employ erasure coding technology to achieve data redundancy, especially high-proportion erasure coding (EC) schemes, which can significantly improve storage space utilization and data fault tolerance.
[0003] However, in high-proportion EC deployments, data reconstruction incurs significant network overhead. Taking EC 20+2 as an example, reconstructing 1MB of data requires reading 20MB of data, with approximately 10MB transferred across the network, making network bandwidth a bottleneck. After a disk failure, data reconstruction consumes a large amount of cluster network bandwidth, severely impacting the operation of critical cluster modules. Furthermore, reconstruction performance is limited by network interface capabilities, causing reconstruction tasks to take a long time to complete, thus affecting the reliability and overall performance of the storage cluster.
[0004] Therefore, how to solve the network bottleneck of data reconstruction in large-scale EC scenarios and improve cluster availability and efficiency has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0005] In view of the above problems, the present invention provides a data reconstruction method, a distributed storage system, and a computer-readable storage medium to overcome or at least partially solve the above problems. The technical solution is as follows:
[0006] A data reconstruction method is provided, wherein the method is applied to a proxy repair service, the proxy repair service being deployed on a persistence layer client of a distributed storage cluster, the distributed storage cluster comprising multiple nodes, each node being configured with a persistence layer client and an object storage service client, the method comprising:
[0007] The data reconstruction task is obtained from the object storage service client of the local node through the local loopback port. The data reconstruction task is used to indicate the data to be reconstructed corresponding to the faulty disk in the distributed storage cluster, the fragmentation information of the data to be reconstructed, and the target node for writing the repair data.
[0008] Based on the sharding information in the data reconstruction task, read the source sharding data corresponding to the data to be reconstructed;
[0009] Based on the erasure coding algorithm and the source fragment data, the repaired fragment data of the data to be reconstructed is obtained;
[0010] The repaired shard data is pushed to the object storage service of the target node to complete the writing process.
[0011] Optionally, before reading the source shard data corresponding to the data to be reconstructed based on the shard information in the data reconstruction task, the method further includes:
[0012] Based on the version number and storage identifier of the data reconstruction task, it is determined whether it is a duplicate task. If not, the context information of the data reconstruction task is prepared, wherein the context information is used for the asynchronous task scheduling of the persistence layer client.
[0013] Register a task completion callback function, wherein the task completion callback function is used to notify the object storage service client after the data reconstruction task is completed.
[0014] Optionally, before obtaining the repaired fragment data of the data to be reconstructed based on the erasure coding algorithm and the source fragment data, the method further includes:
[0015] Error checking and data validity verification are performed on the source fragment data, so that the verified source fragment data can be used to calculate the repair fragment data of the data to be reconstructed using erasure coding algorithm.
[0016] Optionally, the step of performing error checking and data validity verification on the source fragment data includes:
[0017] Check if there are any read errors in the source fragment data. If so, terminate the data reconstruction task. If not, verify the integrity of the source fragment data.
[0018] If the source fragment data passes integrity verification, the step of obtaining the repaired fragment data of the data to be reconstructed based on the erasure coding algorithm and the source fragment data is executed.
[0019] Optionally, reading the source shard data corresponding to the data to be reconstructed based on the shard information in the data reconstruction task includes:
[0020] Based on the sharding information in the data reconstruction task, request and obtain the logical block address information of the data to be reconstructed from the object storage service client of the local node;
[0021] Based on the logical block address information, read the source fragment data corresponding to the data to be reconstructed.
[0022] Optionally, reading the source fragment data corresponding to the data to be reconstructed based on the logical block address information includes:
[0023] A read request is generated based on the logical block address information;
[0024] The read request is sent to the corresponding disk using the local internal path;
[0025] Receive the source fragment data returned by the disk that corresponds to the data to be reconstructed.
[0026] Optionally, the method further includes:
[0027] When the cluster monitoring service of the distributed storage cluster detects that the logical pool has entered read-only mode, the object storage service intercepts the data reconstruction task sent to the proxy repair service, so as to complete the data reconstruction through the network path between the various object storage service clients in the distributed storage cluster.
[0028] A distributed storage system for implementing the data reconstruction method, the system comprising: a cluster monitoring module, an object storage service module, a data persistence module, a proxy repair module, and a mode switching module;
[0029] The cluster monitoring module is used to detect disk failures in the distributed storage cluster and maintain disk view information.
[0030] The object storage service module is used to manage the disk data of the distributed storage cluster and generate data reconstruction tasks that generate data to be reconstructed;
[0031] The data persistence module is used to access the disk and perform calculations on the data to be reconstructed via local loopback communication.
[0032] The proxy repair module is used to handle the reconstruction task of the data to be reconstructed;
[0033] The mode switching module is used to switch the reconstruction path of the data to be reconstructed.
[0034] Optionally, the proxy repair module includes: a server-side component and a client-side component, wherein the server-side component is integrated in the process of the persistence layer client, and the client-side component is integrated in the process of the object storage service client;
[0035] The server-side component is used to receive and process the reconstruction task of the data to be reconstructed;
[0036] The client component is used to send reconstruction tasks for the data to be reconstructed and to receive processing results.
[0037] A computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the data reconstruction method described above.
[0038] By employing the above technical solutions, this invention provides a data reconstruction method, a distributed storage system, and a computer-readable storage medium. This method is applied to a proxy repair service deployed on a persistent layer client of a distributed storage cluster. The distributed storage cluster includes multiple nodes, each configured with a persistent layer client and an object storage service client. The method includes: obtaining a data reconstruction task from the object storage service client of a local node via a local loopback port. The data reconstruction task indicates the data to be reconstructed corresponding to a faulty disk in the distributed storage cluster, the shard information of the data to be reconstructed, and a target node for writing the repair data; reading the source shard data corresponding to the data to be reconstructed based on the shard information in the data reconstruction task; obtaining the repair shard data of the data to be reconstructed based on the erasure coding algorithm and the source shard data; and pushing the repair shard data to the object storage service client of the target node to complete the write operation. This invention, by applying a proxy repair service in a distributed storage cluster, enables local loopback communication between the object storage service client and the persistent layer client. Combined with reading local source shard data and performing erasure coding reconstruction, it significantly reduces cross-node network data transmission, thereby effectively alleviating the network bottleneck of data reconstruction in high-proportion EC scenarios and improving the data reconstruction efficiency and overall availability of the cluster.
[0039] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description
[0040] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:
[0041] Figure 1 A schematic diagram of a traditional data reconstruction process is shown;
[0042] Figure 2 A flowchart illustrating one embodiment of the data reconstruction method provided by this invention is shown.
[0043] Figure 3 A schematic diagram of the structure of the distributed storage system provided in an embodiment of the present invention is shown;
[0044] Figure 4A schematic diagram of a system architecture for a distributed storage system provided in an embodiment of the present invention is shown;
[0045] Figure 5 A schematic diagram of the communication interaction process for the proxy repair task provided in an embodiment of the present invention is shown;
[0046] Figure 6 This diagram illustrates a process for repairing local reads provided in an embodiment of the present invention.
[0047] Figure 7 A schematic diagram of the reconfiguration and switching process provided in an embodiment of the present invention is shown. Detailed Implementation
[0048] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
[0049] Before providing a further detailed description of the embodiments of the present invention, the nouns and terms involved in the embodiments of the present invention will be explained, and the nouns and terms involved in the embodiments of the present invention are subject to the following interpretations.
[0050] 1. P (Persistence) layer: The data persistence layer in a distributed storage system, responsible for long-term data storage and protection.
[0051] 2. plog: A linear storage unit provided by the P layer for sequential writing and management of data.
[0052] 3. OSD (Object Storage Daemon): An object storage service client, serving as the server for the P layer. Each OSD process manages a physical disk, responsible for writing data in the form of objects, and performing functions such as data verification, replication, and recovery.
[0053] 4. PClient: Persistence layer client, the client component of the P layer, responsible for communicating with the OSD and completing data read and write requests.
[0054] 5. Placement Group (PG): A placement group is a logical grouping unit between OSDs and data objects. A PG divides a large number of data objects into groups for easier unified management. One PG is distributed across multiple OSDs, and one OSD can host multiple PGs. A PG is also the smallest unit for data refactoring.
[0055] 6. OSDMap: Disk view information, a view that stores the status and metadata information of all OSDs in the cluster, reflecting the cluster members and their status.
[0056] 7. EC (Erasure Coding): A data protection and fault tolerance technology. Traditional replication methods ensure reliability by using multiple complete copies of the data. Although recovery is fast, storage efficiency is low. Erasure coding, on the other hand, splits and encodes the data to generate redundant blocks, achieving the recovery of lost data with less storage overhead and some computational cost, thus significantly improving storage efficiency.
[0057] 8. NoF (NVMe over Fabric): A high-performance storage access method based on the NVMe protocol for network transmission. In this invention, it refers to a path that accesses the local hard drive via PClient without crossing a network.
[0058] 9. LBA (Logical Block Address): The logical block address refers to the disk logical address corresponding to the Plog in the linear storage unit.
[0059] 10. ProxyRecovery: Responsible for forwarding and scheduling reconstruction tasks and coordinating the data reconstruction process.
[0060] 11. Monitor (Cluster Monitoring Service): Maintains a global status view of the distributed storage cluster, including OSDMap, and is responsible for cluster health monitoring and management.
[0061] Before explaining the data reconstruction method provided in the embodiments of the present invention, the methods in related technologies are first described: In a distributed storage system, the P layer is responsible for persistent storage and redundancy protection of data. When a disk fails, the system needs to reconstruct the data on the failed disk to other normal disks to restore data redundancy and ensure the reliability of the system. Figure 1 The diagram illustrates a traditional data reconstruction process, which may include repair scheduling, the master object storage service (master OSD) acquiring plog metadata information of the shard to be repaired and the data source shard, the OSD of the shard to be repaired and the OSD of the data source shard to be repaired reading and replying with the corresponding plog data, the master OSD summarizing the information and using erasure coding algorithm to reconstruct the data, and then sending the repair task to the OSD of the shard to be repaired to complete the data writing and status feedback, and repeating the process until all plog data is repaired.
[0062] As can be seen, traditional data reconstruction processes are typically coordinated by the primary object storage service (OSD), involving reading large amounts of data from multiple data source nodes across the network for erasure coding computation. Especially in high-proportion erasure coding scenarios, the read amplification effect is significant, leading to network bandwidth bottlenecks and severely impacting cluster performance and availability.
[0063] Based on this, this embodiment of the invention provides a data reconstruction method. Leveraging the characteristic of P-layer data reconstruction in a dual-controller architecture where data flows only between disks within the same frame, the PClient accesses each disk within the frame via a NoF pass-through method, eliminating the need for cross-network transmission. Reconstruction tasks are forwarded to the local PClient, and repair reads are completed via the NoF path, effectively eliminating the network bandwidth consumption of repair reads. Simultaneously, to achieve efficient forwarding of reconstruction tasks, this embodiment of the invention employs a local loopback communication mechanism. Each controller's PClient only handles reconstruction tasks initiated by the local OSD, reducing cross-node message interaction. The proxy repair service is responsible for task forwarding and scheduling; the client is integrated into the OSD process, and the server is integrated into the PClient process. The OSD does not need to know the global PClient address, only the local PClient communication address. Furthermore, when multiple disk failures cause the storage pool to become read-only or the PClient process to fail to start, the cluster monitoring service can automatically identify the fault and switch the reconstruction mode, completing data reconstruction via the traditional OSD path, quickly restoring P-layer data redundancy, and ensuring data reliability.
[0064] The data reconstruction method provided in this embodiment of the invention is applied to a proxy repair service. The proxy repair service is deployed on a persistent layer client of a distributed storage cluster. The distributed storage cluster includes multiple nodes, each configured with a persistent layer client and an object storage service client. Figure 2 The diagram shows a flowchart of one embodiment of the data reconstruction method provided by this invention. The method may include:
[0065] S200: Obtain the data reconstruction task from the object storage service client of the local node through the local loopback port. The data reconstruction task is used to indicate the data to be reconstructed corresponding to the faulty disk in the distributed storage cluster, the fragment information of the data to be reconstructed, and the target node to be written to repair the data.
[0066] The data reconstruction task is generated by the local node's object storage service upon receiving a disk failure notification from the cluster monitoring service. The object storage service can generate specific data reconstruction tasks for each placement group requiring reconstruction. A data reconstruction task is an instruction structure containing necessary metadata, including: a unique storage identifier (plog ID) for the data to be reconstructed, a task version number to avoid duplicate processing, a list of object storage service providers offering data sources, and object storage service provider information specifying the target node for writing the repair data. The data reconstruction task encapsulates the critical shard location and routing information required to perform a data repair operation.
[0067] Specifically, the proxy repair service provided in this embodiment of the invention can receive data reconstruction tasks generated by the object storage service client on the local node through local loopback communication. The communication strategy of the local loopback communication can be pre-configured, including the local loopback port listened to by the server, and the client holding this address information for task transmission. For example, the object storage service client process integrates a client component of the proxy repair service; this client establishes a Socket connection with the proxy repair service component in the persistence layer client process running on the same node through the pre-configured local loopback port; after the connection is established, the object storage service client sends the encapsulated data reconstruction task as a message to the proxy repair service of the persistence layer client through this local loopback communication link.
[0068] Optionally, in the above Figure 2 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, before step S200, the method may further include:
[0069] When the cluster monitoring service detects a disk failure in the distributed storage cluster, it updates the disk view information and disseminates it to the object storage service on each node.
[0070] Specifically, when the cluster monitoring service detects a disk failure and the failure persists for more than a preset time, the cluster monitoring service updates the cluster global view information (including OSDMap), marking the failed disk as unavailable. The updated OSDMap is then pushed to all object storage service providers via a subscription mechanism, achieving consistent synchronization of views within the cluster.
[0071] As examples, the cluster monitoring service continuously monitors the disk status of each node. When a disk failure is detected and the duration exceeds a preset threshold of 5 minutes, the cluster monitoring service determines that the disk is permanently failed and then updates the global disk view information, marking the failed disk as "out". After the update is completed, the cluster monitoring service actively pushes or notifies all object storage service client processes in the cluster with the new disk view information through its maintained subscription mechanism, ensuring that all object storage service clients can promptly perceive the changes in disk topology.
[0072] Before generating a data reconstruction task through the object storage service client, this embodiment of the invention updates the disk view information of the distributed storage cluster and spreads it to the object storage service client, which can ensure that all nodes have a consistent and up-to-date understanding of the current disk status and fault conditions.
[0073] Optionally, upon receiving the updated disk view information, each object storage service client initiates a consistency negotiation at the placement group level to determine the data to be reconstructed.
[0074] Specifically, after receiving new disk view information, each object storage service client initiates a consistency negotiation process based on the operation logs at the placement group granularity. Through negotiation, it identifies placement groups where data loss is caused by failed disks, meaning these placement groups require data reconstruction.
[0075] As examples, after receiving new disk view information from the cluster monitoring service, each object storage service process traverses all the placement groups it manages. For each placement group, the object storage service checks whether its data distribution has become incomplete due to disk failure (i.e., missing replicas or shards). For the affected placement groups, the object storage service initiates a consistency negotiation process, compares the operation logs (plogs) of each replica in the placement group, determines which specific data objects (corresponding to specific plog IDs) need to be reconstructed because they are located on the failed disk, and clarifies which healthy target disk these data to be reconstructed should be migrated to.
[0076] The embodiments of the present invention initiate consistency negotiation at the placement group granularity on the object storage service side, which can accurately and quickly determine the data to be reconstructed, avoid data reconstruction errors or redundancy caused by inconsistent information, and improve the accuracy and efficiency of data reconstruction.
[0077] S210. Based on the sharding information in the data reconstruction task, read the source sharding data corresponding to the data to be reconstructed.
[0078] Specifically, in this embodiment of the invention, the logical location information of the data to be reconstructed can be obtained from the local node based on the sharding information in the data reconstruction task, and the corresponding source shard data can be read. Further, this embodiment of the invention can submit a query request to the object storage service client of the local node, requesting the sharding information as a query parameter to obtain the logical location information of the corresponding source shard data, and read the source shard data at the storage location indicated by the logical location information.
[0079] S220. Based on the erasure coding algorithm and the source fragment data, obtain the repair fragment data of the data to be reconstructed.
[0080] Specifically, embodiments of the present invention can use multiple source fragment data read to calculate the specific data content of the fragment to be repaired based on a configured erasure coding algorithm, thereby achieving data reconstruction. The volume of the repaired fragment data obtained after this calculation is smaller than the original read data volume, significantly reducing the cross-network transmission load.
[0081] As examples, embodiments of the present invention can verify the read source shard data to ensure that the data is valid. Then, the persistence layer client calls its built-in erasure coding calculation engine. Based on the preset erasure coding strategy, a sufficient number of healthy source shard data are used as input, and the missing repair shard data is calculated through erasure coding decoding or encoding operations.
[0082] S230. Push the repaired shard data to the object storage service client of the target node to complete the write.
[0083] Specifically, in this embodiment of the invention, the calculated repair shard data can be sent to the object storage service of the target node via a message. The object storage service of the target node then calls the local storage engine interface to write the repair shard data to the corresponding plog position, thus completing the actual data repair operation.
[0084] As examples, embodiments of the present invention can encapsulate the calculated repair shard data in an MProxyRecoverPush message and send it to the object storage service client of the target node. Upon receiving the push message, the target node's object storage service client calls its local storage engine interface to write the repair shard data to the specified healthy disk. After the write is complete, the target node's object storage service client replies with an MProxyRecoverPushReply message to the persistence layer client that sent the MProxyRecoverPush message to inform it of the write result. The persistence layer client verifies the result; if it fails, it retryes.
[0085] This invention enables local loopback communication between the object storage service client and the persistence layer client by applying a proxy repair service in a distributed storage cluster. Combined with reading local source shard data and performing erasure coding reconstruction, it significantly reduces cross-node network data transmission, thereby effectively alleviating the network bottleneck of data reconstruction in high-proportion EC scenarios and improving the data reconstruction efficiency and overall availability of the cluster.
[0086] Optionally, in this embodiment of the invention, after the target object storage service completes the writing of the repaired sharded data, the object storage service of the distributed storage cluster's master node is notified to update the status information of the placement group through the callback mechanism of the persistent layer client.
[0087] Specifically, after the write operation is complete, the target node's object storage service returns a confirmation message to the persistence layer client. The persistence layer client verifies the repair result. If all plog data has been repaired, the registered task callback is triggered, notifying the master node's object storage service to update the placement group metadata status, driving the placement group state machine to rotate, and finally restoring the placement group to a healthy state, completing the entire data reconstruction process.
[0088] As examples, when a data reconstruction task of a certain plog is completely completed, the persistence layer client executes the task completion callback function and sends an MCaphProxyRecoverPlogReply message to the object storage service of the master node to notify that the task is completed. After receiving the notification, the master object storage service updates the metadata of the relevant placement group (such as the repair progress) and drives the placement group state machine to perform state transition. When all the data to be reconstructed has been repaired, the placement group state is finally restored to the healthy state of "active+clean", which marks the completion of this data reconstruction process.
[0089] This invention ensures that each node in the cluster keeps pace with the data repair status by promptly notifying the latest progress of data reconstruction and the status of the relocation group. This effectively avoids misjudgment or repeated reconstruction caused by delayed status information and improves the overall data consistency of the distributed storage cluster.
[0090] Optionally, in the above Figure 2 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, before step S210, the method may further include:
[0091] Based on the version number and storage identifier of the data reconstruction task, determine whether it is a duplicate task. If not, prepare the context information of the data reconstruction task, which is used for asynchronous task scheduling of the persistence layer client; register a task completion callback function, which is used to notify the object storage service client after the data reconstruction task is completed.
[0092] Specifically, after receiving a new data reconstruction task, the proxy repair service first queries the currently executing or completed task records based on the version number and storage identifier (plog ID) in the task. If a task with a higher or identical version number corresponding to the same storage identifier is found, it indicates that the task is a duplicate or an old task, and the proxy repair service will proactively discard the request to avoid redundant calculations and wasted resources. If the task is new, subsequent processing continues.
[0093] Furthermore, for newly confirmed tasks, the proxy repair service constructs a task context based on task parameters (such as plog ID, repair version number, and object storage service client information for the source and target nodes). The context can include a unique identifier for the task, source data shard location information and target write location, task status tracking information, parameters required for asynchronous scheduling, and callback handles. This context information will be used by the persistence layer client to asynchronously call the data reconstruction interface, supporting concurrent processing of multiple tasks and state management.
[0094] The proxy repair service registers a task completion callback function for new tasks. This callback function is used to monitor the data reconstruction execution status. Once the data reconstruction is completed (whether successful or not), the callback is triggered to notify the object storage service (main object storage service) to update the placement group metadata and status, release related resources, and update the task execution record. Thus, through the callback mechanism, timely feedback of task execution results and dynamic synchronization of cluster status are achieved, ensuring data consistency and reliability.
[0095] In this embodiment of the invention, before calling the data reconstruction interface of the persistence layer client based on the proxy repair service, it first determines whether the data reconstruction task is a duplicate task based on the version number and storage identifier of the data reconstruction task. This effectively avoids repeatedly executing the same reconstruction operation, saves system resources, and improves reconstruction efficiency. At the same time, the proxy repair service realizes asynchronous task scheduling of the persistence layer client by preparing the context information of the data reconstruction task, supports multi-task concurrent processing, and improves the system's responsiveness and throughput. In addition, registering a task completion callback function ensures that the object storage service client is notified in a timely manner after the data reconstruction task is completed, promotes real-time updates of the placement group status and data consistency maintenance, thereby enhancing the data reliability and reconstruction management capabilities of the entire distributed storage cluster.
[0096] Optionally, in the above Figure 2 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, before step S220, the method may further include:
[0097] Error checking and data validity verification are performed on the source fragment data so that the verified source fragment data can be used to calculate the repair fragment data of the data to be reconstructed through erasure coding algorithm.
[0098] Specifically, in this embodiment of the invention, the reading status of the source fragment data can be checked first. If an error is found, the task is interrupted to ensure reliability. After the check passes, the integrity of the data content is further verified, thereby selecting the valid source fragment data as a reliable input for the erasure coding algorithm to accurately calculate the required repair fragment data.
[0099] Optionally, in this embodiment of the invention, it can check whether there is a read error in the source fragment data. If so, the data reconstruction task is terminated; if not, the integrity of the source fragment data is verified. If the source fragment data passes the integrity verification, step S220 is executed.
[0100] Specifically, in this embodiment of the invention, when reading source fragment data, error codes during the reading process are first detected. For example, the success of data reading is confirmed by the I / O return status code. If errors such as hardware failure, timeout, or data loss are found, the current data reconstruction task is immediately terminated, and the error information is fed back to the agent repair service for subsequent retry scheduling, avoiding data pollution caused by using erroneous data for repair. If no error occurs during reading, the validity of the source fragment data is further verified. This may include: comparing the data checksum (such as CRC, hash value) with the original checksum stored to confirm that the data has not been tampered with or damaged; verifying the logical consistency and integrity of the data by combining erasure coding redundancy information; if the verification fails, the fragment data is marked as invalid, and other redundant fragment data is reread to ensure that the source data used for repair is valid and reliable. Only after all the above verifications pass is the verified source fragment data used to perform calculations based on the pre-configured erasure coding algorithm to generate complete and accurate repair fragment data, ensuring the correctness and efficiency of data recovery.
[0101] Before obtaining the repaired fragment data of the data to be reconstructed based on the erasure coding algorithm and the source fragment data, this embodiment of the invention first performs error checking and validity verification on the source fragment data. This effectively ensures the accuracy and reliability of the data used for reconstruction, avoiding erroneous reconstructions caused by read errors or data corruption, thereby improving the success rate of data reconstruction and the stability of the system. Simultaneously, by promptly terminating reconstruction tasks with read errors, system resources can be saved and error propagation can be prevented, further improving the accuracy and efficiency of data reconstruction and enhancing the overall data security of the distributed storage cluster.
[0102] Optionally, in the above Figure 2 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, step S210 may specifically include:
[0103] Based on the sharding information in the data reconstruction task, request and obtain the logical block address information of the data to be reconstructed from the object storage service client on the local node. Based on the logical block address information, read the source shard data corresponding to the data to be reconstructed.
[0104] Specifically, in this embodiment of the invention, the data reconstruction interface of the persistence layer client can be called. The persistence layer client requests and obtains the metadata of the data to be reconstructed from the object storage service client of the local node based on the sharding information in the data reconstruction task. The metadata includes logical block address information.
[0105] Furthermore, embodiments of the present invention can preprocess the data reconstruction task, eliminate duplicate tasks, prepare context information, and then call the data reconstruction interface of the persistence layer client. The persistence layer client on the local node sends a message to the object storage service client, requesting the plog metadata of the target data and the corresponding logical block address, in order to locate the specific physical location to be read.
[0106] As examples, after receiving a data reconstruction task, the proxy repair service first performs preprocessing, and then calls the data reconstruction interface provided by the persistence layer client to submit the task to the core processing module of the persistence layer client. The persistence layer client first sends an MProxyRecoverGet request message to the object storage service of the local node according to the plog ID in the task to query the detailed metadata of the data to be reconstructed. After querying the local storage engine, the object storage service returns the metadata (including the logical block address - LBA information of the data on the disk) to the persistence layer client through an MProxyRecoverGetReply reply message. The persistence layer client updates the local cache with this information for use in subsequent steps.
[0107] Specifically, in this embodiment of the invention, based on the obtained logical block address information, a read request is asynchronously initiated to obtain the source data fragment by utilizing the corresponding disk within the NoF direct path local access frame.
[0108] As examples, embodiments of the present invention can utilize the acquired logical block address information to generate NVMe read commands. Through its internal NoF client component, it bypasses traditional OSD inter-network transmission and sends read requests to all healthy disks within the node that contain data source shards to be reconstructed via high-speed network paths such as RDMA. The disks then return the requested source shard data to the persistence layer client, achieving efficient "local reads".
[0109] Optionally, embodiments of the present invention may generate a read request based on logical block address information; send the read request to the corresponding disk using a local internal path; and receive the source fragment data returned by the disk that corresponds to the data to be reconstructed.
[0110] Specifically, in this embodiment of the invention, read requests for specific data fragments can be constructed based on the logical block address information in the metadata obtained from the object storage service. The read request includes detailed information such as the starting offset, length, and target physical storage unit of the data to be read, ensuring accurate location and access to the source fragment data stored on the disk. Utilizing a NoF path, the generated read request is sent to the corresponding physical disk or OSD-managed disk unit via a local internal communication channel, fully leveraging the advantages of the local network topology to achieve low-latency, high-bandwidth data access and avoid performance bottlenecks caused by cross-node network transmission. Upon receiving the read request, the disk schedules the local storage engine to read the specified physical block data and returns the source fragment data. This embodiment of the invention can perform caching and preliminary verification after receiving the data to ensure data integrity and availability, providing reliable foundational data for subsequent erasure coding calculations and data repair.
[0111] This invention generates precise read requests based on logical block address information and efficiently sends them to the corresponding disk using local internal paths, enabling fast and accurate access to the data source fragments to be reconstructed. Subsequently, it promptly receives the source fragment data returned by the disk, ensuring data integrity and consistency. This not only reduces the latency and bandwidth pressure caused by cross-network transmission but also improves the efficiency and reliability of data reading, providing high-quality input data for subsequent erasure coding calculations.
[0112] Optionally, in the above Figure 2 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, the method may further include:
[0113] When the cluster monitoring service of the distributed storage cluster detects that the logical pool has entered read-only mode, the object storage service intercepts the data reconstruction task sent to the proxy repair service, so as to complete the data reconstruction through the network path between the various object storage service clients in the distributed storage cluster.
[0114] Specifically, the cluster monitoring service of the distributed storage cluster can determine whether the logical pool has entered read-only mode by using the placement group status information of the object storage service and the process status of the persistence layer client. If so, it obtains the read-only information of the logical pool in read-only mode and persists the read-only information to the disk view information of the object storage service. The disk view information containing read-only information is then disseminated to the local cache of the persistence layer client on each node and to the process of the object storage service, so that the persistence layer client and the object storage service are aware that the logical pool has entered read-only mode. The data reconstruction task sent by the proxy repair service to the persistence layer client is intercepted by the object storage service and the data reconstruction is completed through the network path between the object storage services.
[0115] As examples, the cluster monitoring service can periodically collect the status information of placement groups and the running status of persistence layer clients. It uses preset judgment logic to detect whether there are disk or node failures exceeding safety thresholds. If all placement groups are unable to write data normally, the logical pool is determined to enter read-only mode, preventing further writes to ensure data security. When a logical pool is determined to be read-only, metadata information containing read-only markers (including read-only identifier, scope of impact, and version information) is generated. This read-only information is then written to the disk view information of the object storage service for persistent storage via a distributed consistency protocol, ensuring reliable preservation and recoverability of status information. The cluster monitoring service pushes the updated read-only status view to all object storage service clients and persistence layer clients through a subscription mechanism. Upon receiving the update, each node updates its local cache and memory status, enabling all service components to synchronously perceive the read-only status of the logical pool and adjust relevant business processes accordingly. In read-only mode, the object storage service actively intercepts the data reconstruction task that was originally executed by the proxy repair service of the persistence layer client, and reschedules the task to the internal network path of the object storage service. The data reconstruction operation is then completed between OSD nodes, avoiding the inability of the persistence layer client to coordinate due to read-only restrictions, and ensuring the rapid recovery of data redundancy and the stable operation of the storage pool.
[0116] This invention, based on the status information of the placement group and the process status of the persistence layer client, accurately determines whether the logical pool has entered read-only mode. It then persists this read-only information to the disk view information of the object storage service and distributes it efficiently. This enables all persistence layer clients and the object storage service in the cluster to synchronize the read-only status of the logical pool in a timely manner, preventing the proxy repair service from failing to perform data reconstruction tasks normally in read-only mode. By intercepting and autonomously completing data reconstruction through the object storage service, and fully utilizing the high-speed network path between nodes, it achieves seamless switching of reconstruction modes, effectively ensuring data integrity and system stability under abnormal or restricted states, and significantly improving the fault tolerance and business continuity of the distributed storage cluster.
[0117] This invention provides a distributed storage system for implementing the aforementioned data reconstruction method. The structure of this distributed storage system is as follows: Figure 3 As shown, it may include: cluster monitoring module 10, object storage service module 20, data persistence module 30, proxy repair module 40 and mode switching module 50.
[0118] The cluster monitoring module 10 is used to detect disk failures in the distributed storage cluster and maintain disk view information.
[0119] The cluster monitoring module 10 is specifically used to monitor the operating status of disks in the distributed storage cluster in real time, and promptly update and maintain the latest disk view information after detecting disk failures. By monitoring disk health status and cluster topology changes, the cluster monitoring module 10 ensures the accuracy and consistency of the global view, providing data support for subsequent data reconstruction.
[0120] The object storage service module 20 is used to manage disk data in the distributed storage cluster and generate data reconstruction tasks that generate data to be reconstructed.
[0121] The object storage service module 20 is specifically responsible for managing disk data in the distributed storage cluster. Based on the latest disk view information and placement group status, it initiates consistency negotiation to determine the data shards to be reconstructed. The object storage service module 20 generates specific data reconstruction tasks, including the shard information required for repair, and is responsible for distributing the reconstruction tasks to the persistence layer client or the proxy repair module 40 to achieve reliable data repair and redundant recovery.
[0122] The data persistence module 30 is used to access the disk and perform calculations on the data to be reconstructed via local loopback communication.
[0123] The data persistence module 30 is located within each node. It accesses the hard disk device via local loopback communication or a direct connection to the storage path to perform read and calculation operations on the data to be reconstructed. Specifically, the data persistence module 30 processes the source fragment data according to the erasure coding algorithm, calculates the fragment data that needs to be repaired, ensures the efficiency and accuracy of data repair, and reduces the data transmission load across the network.
[0124] The proxy repair module 40 is used to handle the reconstruction task of the data to be reconstructed.
[0125] The proxy repair module 40, as a component on the client side of the persistence layer, receives and manages the reconstruction tasks issued by the object storage service module 20, and performs scheduling and coordination of the data reconstruction process. Specifically, the proxy repair module 40 is used to communicate with the object storage service client to complete operations such as data metadata acquisition, source data reading, erasure coding calculation, and repair data distribution, thereby achieving efficient data reconstruction and collaborative work between nodes.
[0126] The mode switching module 50 is used to switch the reconstruction path of the data to be reconstructed.
[0127] The mode switching module 50 is specifically used to dynamically switch the execution path of data reconstruction when the storage pool is detected to have entered read-only mode or other abnormal states. Based on the overall cluster status and the operating status of the persistence layer clients, the mode switching module 50 determines whether the data reconstruction is performed by the proxy repair module 40 or completed by the object storage service client nodes via the intranet, thereby ensuring the continuity of data reconstruction and the stability of the system under different operating environments.
[0128] Optionally, the proxy repair module 40 includes a server-side component and a client-side component, wherein the server-side component is integrated into the process of the persistence layer client, and the client-side component is integrated into the process of the object storage service client.
[0129] The server-side component is used to receive and process the reconstruction tasks of the data to be reconstructed.
[0130] The server-side component is integrated into the persistence layer client process. It receives reconstruction tasks from the client component, parses and preprocesses the tasks (such as deduplication and context preparation), and schedules and calls the persistence layer client's data reconstruction interface to complete the actual data reading, error verification, erasure coding calculation, and generation and distribution of repaired data. A callback mechanism is used to provide feedback on the reconstruction results to the client component, ensuring the reliable completion and efficient execution of the data reconstruction task.
[0131] The client component is used to send reconstruction tasks for the data to be reconstructed and to receive the processing results.
[0132] The client component is integrated into the object storage service's process. It sends data tasks requiring repair to the corresponding server component according to a specified format and protocol, based on the data reconstruction scheduling strategy. The client component also receives processing results from the server component, including task execution status and data writing status, ensuring the object storage service can promptly grasp the data reconstruction progress and results, achieving end-to-end task collaboration and closed-loop control.
[0133] Optionally, the distributed storage system adopts a dual-controller architecture, with each node containing two controllers, and the data persistence module 30 can access all disks within the node simultaneously.
[0134] As some examples, such as Figure 4The diagram illustrates a system architecture of a distributed storage system provided in this embodiment of the invention. This distributed storage system is a multi-frame distributed storage cluster. Each frame serves as an independent storage node, internally configured with two controllers to enhance node high availability and fault tolerance. The two controllers can support active-active mode, where both controllers provide services simultaneously, and I / O traffic automatically switches to the other controller if either controller fails; or they can support master-slave mode, where the backup controller takes over all services if the master controller fails. With dual-port disk support, each controller can access all disks within its frame. The storage cluster employs a localized data persistence strategy, with data distributed and stored within nodes. Erasure coding redundancy mechanisms are also implemented within the nodes, improving data access efficiency and enhancing disaster recovery capabilities. PClient, as the persistence layer client, provides two data access paths: one is direct access to all disks via a NoF (Network over Fabric) path, achieving high-bandwidth, low-latency data read / write; the other is efficient direct read / write with the object storage service OSD within the node via the node's internal network.
[0135] Compared to traditional solutions that require the primary OSD to fetch data in batches from multiple other OSDs across the network, this architecture allows PClient to read the necessary disk data locally in parallel, perform partial recovery calculations on the sharded data, and push the final calculation results to the primary OSD. This significantly reduces the amount of data transmitted across the network from several times the traditional amount to only the final repair results, substantially reducing network load. Furthermore, to further enhance the system's data recovery capabilities, a proxy recovery service (ProxyRecovery) is integrated into the PClient side of the architecture. When a disk failure occurs within the cluster, the monitoring module immediately updates the cluster's OSDMap information and pushes it to each OSD. Upon receiving the view change, the OSD initiates a consensus negotiation and delegates the data reconstruction task to the proxy recovery service. The proxy recovery service obtains metadata and recovery task information through the OSDClient, utilizes NoFClient for local access to disk data, and performs recovery calculations on the source data based on erasure coding algorithms. After recovery is complete, the recovery results are automatically pushed to the target shard, ensuring efficient and reliable execution of the data security and redundant recovery process.
[0136] To facilitate understanding of the data reconstruction interaction process of the distributed storage system provided in the embodiments of the present invention, this document combines... Figure 5 , Figure 6 and Figure 7 Explanation: Figure 5The diagram illustrates the communication interaction process for the proxy repair task provided in this embodiment of the invention. During the PClient initialization phase, the repair proxy server (ProxyRecovery) starts and listens to the local loopback port, preparing to receive reconstruction task requests from OSDs. During the OSD initialization phase, the system configures the communication strategy for the repair proxy client, mainly including setting the IP address and port information of the repair proxy server to ensure that subsequent cross-process reconstruction tasks can be accurately sent to the repair proxy server on the PClient. When the Monitor detects a disk failure and the failure exceeds a set threshold time, it updates the disk's view information and pushes it to each OSD. After receiving the latest view, the OSD determines that data reconstruction is needed to restore data redundancy and then actively initiates a connection request with the PClient repair proxy server. Upon receiving the connection request, the repair proxy server on the PClient side completes a handshake process with the OSD client to establish a stable communication connection. After the connection is established, the proxy repair server and the proxy repair client begin message interaction, coordinating and executing specific data reconstruction tasks.
[0137] Figure 6 The diagram illustrates the process of repairing local reads according to an embodiment of the present invention. When the Monitor detects a disk failure and updates the disk view information, the OSD receives this information and initiates consistency negotiation on a PG-level data write operation log basis. This determines the data to be migrated and the target disk. Multiple PGs initiate data reconstruction tasks in parallel to migrate data from the failed disk to the target disk. Subsequently, the OSD sends a reconstruction task to ProxyRecovery. The task information includes key metadata such as the plog ID to be repaired, the task version number, the source OSD of the data to be repaired, and the target OSD. The proxy repair server determines whether the task is duplicated based on the task version number and plog ID, discards the old task, retains the latest task, prepares context information for asynchronous scheduling by the PClient, and registers a repair task callback function to notify the OSD when the task is completed.
[0138] The proxy repair server is primarily responsible for the preprocessing and management of repair tasks. It then hands the tasks over to PClient, which calls the data reconstruction interface and utilizes its thread pool resources for concurrent asynchronous processing. PClient first sends an MProxyRecoverGet message to the OSD requesting the corresponding plog metadata. The OSD retrieves the plog metadata and its LBA from its local storage engine, processes it, and returns an MProxyRecoverGetReply. Upon receiving the reply, PClient updates the cached plog metadata and LBA. Subsequently, PClient obtains the latest PG view information. The PG view, maintained by the Monitor and synchronized to the OSD and PClient via a state machine rotation, reflects the current OSD combination state within the PG and data write logs, ensuring the correct execution of data read / write and reconstruction tasks.
[0139] Based on plog metadata, PClient updates the memory information of the shard to be repaired and sends a data read request to the corresponding disk via NoFClient carrying LBA. During the read process, PClient performs error code checks and data validity verification. If the reading is incorrect, the task is terminated and retried; if silent data corruption is detected, it attempts to read from other redundant data shards. Using erasure coding algorithms, PClient calculates and recovers the lost or corrupted shard data to be repaired based on the read source shard data. PClient pushes the repaired data to the corresponding OSD shard via the message MProxyRecoverPush. The OSD calls the local engine interface to execute plog repair and replies with MProxyRecoverPushReply. PClient verifies the success of the repair process based on the reply. If the repair is not yet complete, it continues to execute subsequent steps; if the repair is complete, it triggers the previously registered task completion callback and sends an MCephProxyRecoverPlogReply message to the master OSD. Finally, the master OSD updates the relevant PG metadata, rotates the PG state machine, restores the PG state to healthy, and completes the entire data reconstruction and repair process.
[0140] When multiple disk failures occur in a storage system, causing the number of original data blocks and redundant blocks for certain data to fall below a safe threshold, the system switches the affected logical pool to read-only mode, prohibiting further writes to prevent further data corruption and loss. In read-only mode, the PClient service may fail to start normally because it cannot write necessary metadata or status information. At this point, the reconstruction task needs a path switch: repair tasks that originally passed through the PClient reconstruction agent are intercepted by the OSD side. The OSD retrieves the reconstruction task from its task queue and distributes and processes it among OSDs, bypassing the PClient agent, thus achieving faster data redundancy recovery.
[0141] Figure 7 The diagram illustrates the refactoring and failover process provided in this embodiment of the invention. The specific process is as follows: First, the logical pool is determined to be in read-only mode based on the PG status and PClient process status. After each PG view information update, the Monitor persists the relevant statistics and view information to disk to ensure the recoverability of the cluster state, and periodically checks and updates the read-only status of the logical pool. When all PGs in the logical pool are unwritable, the logical pool is marked as read-only. This read-only status is written to the OSDMap and persisted through the Paxos mechanism. The Monitor then pushes the latest OSDMap to the PClient and each OSD process, and both parties update the view information in their local cache and memory, respectively. The PG then synchronizes the read-only mark to its own pool information structure based on the latest OSDMap. During the reconstruction scheduling process, the reconstruction mode is automatically switched according to the read-only / write status of the storage pool: if the storage pool is read-only, the reconstruction scheduling task is handled by the OSD without going through the PClient agent, thus realizing data repair between OSDs; if the storage pool is still readable and writable, the reconstruction scheduling task continues to follow the PClient agent repair path, thereby ensuring the continuity of fault recovery and the timely recovery of data redundancy in read-only scenarios.
[0142] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.
[0143] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.
[0144] This invention provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the data reconstruction method.
[0145] This invention provides a processor for running a program, wherein the program executes the data reconstruction method during runtime.
[0146] The present invention also provides a computer program product that, when executed on an electronic device, is suitable for executing a program with initialization data reconstruction method steps.
[0147] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0148] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM, and memory includes at least one memory chip. Memory is an example of computer-readable media.
[0149] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0150] In the description of this invention, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.
[0151] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that 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 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 the element.
[0152] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0153] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the present invention.
Claims
1. A data reconstruction method, characterized in that, The method is applied to a proxy repair service, which is deployed on a persistence layer client of a distributed storage cluster. The distributed storage cluster includes multiple nodes, each configured with a persistence layer client and an object storage service client. The method includes: The data reconstruction task is obtained from the object storage service client of the local node through the local loopback port. The data reconstruction task is used to indicate the data to be reconstructed corresponding to the faulty disk in the distributed storage cluster, the fragmentation information of the data to be reconstructed, and the target node for writing the repair data. Based on the sharding information in the data reconstruction task, read the source sharding data corresponding to the data to be reconstructed; Based on the erasure coding algorithm and the source fragment data, the repaired fragment data of the data to be reconstructed is obtained; The repaired shard data is pushed to the object storage service of the target node to complete the writing process.
2. The method according to claim 1, characterized in that, Before reading the source shard data corresponding to the data to be reconstructed based on the shard information in the data reconstruction task, the method further includes: Based on the version number and storage identifier of the data reconstruction task, it is determined whether it is a duplicate task. If not, the context information of the data reconstruction task is prepared, wherein the context information is used for the asynchronous task scheduling of the persistence layer client. Register a task completion callback function, wherein the task completion callback function is used to notify the object storage service client after the data reconstruction task is completed.
3. The method according to claim 1, characterized in that, Before obtaining the repaired fragment data of the data to be reconstructed based on the erasure coding algorithm and the source fragment data, the method further includes: Error checking and data validity verification are performed on the source fragment data, so that the verified source fragment data can be used to calculate the repair fragment data of the data to be reconstructed using erasure coding algorithm.
4. The method according to claim 3, characterized in that, The error checking and data validity verification of the source fragment data includes: Check if there are any read errors in the source fragment data. If so, terminate the data reconstruction task. If not, verify the integrity of the source fragment data. If the source fragment data passes integrity verification, the step of obtaining the repaired fragment data of the data to be reconstructed based on the erasure coding algorithm and the source fragment data is executed.
5. The method according to claim 1, characterized in that, The step of reading the source fragment data corresponding to the data to be reconstructed based on the fragment information in the data reconstruction task includes: Based on the sharding information in the data reconstruction task, request and obtain the logical block address information of the data to be reconstructed from the object storage service client of the local node; Based on the logical block address information, read the source fragment data corresponding to the data to be reconstructed.
6. The method according to claim 5, characterized in that, The step of reading the source fragment data corresponding to the data to be reconstructed based on the logical block address information includes: A read request is generated based on the logical block address information; The read request is sent to the corresponding disk using the local internal path; Receive the source fragment data returned by the disk that corresponds to the data to be reconstructed.
7. The method according to claim 1, characterized in that, Also includes: When the cluster monitoring service of the distributed storage cluster detects that the logical pool has entered read-only mode, the object storage service intercepts the data reconstruction task sent to the proxy repair service, so as to complete the data reconstruction through the network path between the various object storage service clients in the distributed storage cluster.
8. A distributed storage system, characterized in that, The system for implementing the method of any one of claims 1 to 7 comprises: a cluster monitoring module, an object storage service module, a data persistence module, a proxy repair module, and a mode switching module; The cluster monitoring module is used to detect disk failures in the distributed storage cluster and maintain disk view information. The object storage service module is used to manage the disk data of the distributed storage cluster and generate data reconstruction tasks that generate data to be reconstructed; The data persistence module is used to access the disk and perform calculations on the data to be reconstructed via local loopback communication. The proxy repair module is used to handle the reconstruction task of the data to be reconstructed; The mode switching module is used to switch the reconstruction path of the data to be reconstructed.
9. The system according to claim 8, characterized in that, The proxy repair module includes a server-side component and a client-side component, wherein the server-side component is integrated in the process of the persistence layer client, and the client-side component is integrated in the process of the object storage service client. The server-side component is used to receive and process the reconstruction task of the data to be reconstructed; The client component is used to send reconstruction tasks for the data to be reconstructed and to receive processing results.
10. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the data reconstruction method as described in any one of claims 1 to 7.