Data processing method and system for erasure storage pool based on distributed storage system

Abstract

The application discloses a kind of based on distributed storage system's erasure storage pool data processing method and system, it is related to distributed storage data redundancy technical field.The method in main object storage device only bears the task of updating local data and synchronizing copy, and does not need to bear "read-modify-code-write" whole task, so, reduce the burden of main object storage device, so that the main object storage device in high concurrency scenario is no longer system bottleneck, relatively improve the performance of storage system.Moreover, parity object storage device locally holds complete data block copy, therefore, parity object storage device can obtain the original data block corresponding to target data block from local after receiving target data block sent by main object storage device, and then can independently code, without relying on main object storage device or the strip data of full placement group, avoid causing a large number of redundant read-write and the increase of delay.

Description

Technical Field

[0001] This invention relates to the field of distributed storage data redundancy technology, and in particular to a data processing method and system for erasure storage pools based on distributed storage systems. Background Technology

[0002] In distributed storage systems, erasure coding (EC) is widely used in large-scale data storage scenarios due to its higher storage efficiency compared to replication.

[0003] The EC storage pool employs a centralized encoding mode using a primary object storage device (OSD). In this mode, client write requests are received by the primary OSD, which is responsible for data fragmentation, encoding to generate parity blocks, and synchronizing them to the secondary OSDs. Overwrite operations require reading the entire Placement Group (PG) stripe data, executing a complete "read-modify-encode-write" process. Because the primary OSD bears the heavy responsibility of encoding and synchronization, it becomes a system bottleneck in high-concurrency scenarios. Furthermore, overwrite operations require accessing the entire Placement Group (PG) stripe data, resulting in a large amount of redundant reads and writes and a significant increase in latency.

[0004] Therefore, improving the performance of systems in high-concurrency distributed storage scenarios, as well as reducing input / output amplification and lowering latency, are technical problems that urgently need to be solved by those in this field. Summary of the Invention

[0005] The purpose of this invention is to provide a data processing method and system for erasure storage pools based on a distributed storage system, in order to solve the problems that the main OSD bears the heavy responsibility of encoding and synchronization, and becomes the system bottleneck in high-concurrency scenarios; and that the overwrite operation requires access to the striped data of the entire placement group, resulting in a large amount of redundant read and write operations and a significant increase in latency.

[0006] To address the aforementioned technical problems, this invention provides a data processing method for an erasure propagation storage pool based on a distributed storage system. The method is applied to parity object storage devices within the erasure propagation storage pool, wherein any data block in the erasure propagation storage pool is stored in both the primary object storage device and the parity object storage device. The method includes:

[0007] Receive a target data block sent by the primary object storage device; wherein, the target data block is obtained by the primary object storage device updating the preset data block stored locally according to the write request sent by the client to represent updating the preset data block;

[0008] Obtain the difference between the target data block and the original data block corresponding to the target data block stored locally;

[0009] Obtain the coding coefficients determined based on the fault domain configuration of the placement group, and determine the parity block increment based on the coding coefficients and the difference;

[0010] The parity blocks in the local storage are updated using the parity block increment.

[0011] On the one hand, before the primary object storage device updates the locally stored preset data block to the target data block, it also includes:

[0012] The main object storage device records logs and writes them to the persistent memory space in multiple parts using the preset byte atomic write feature of persistent memory; wherein, the log includes at least the unique code of the preset data block, the version number prefix, the old value hash and the new value pointer.

[0013] On the other hand, the primary object storage device synchronizes the target data block to the parity object storage device, including:

[0014] Based on the metadata of the placement group, locate multiple parity object storage devices of the placement group strip to which the target data block belongs;

[0015] Obtain the load values ​​of the plurality of parity object storage devices;

[0016] The target data blocks are synchronized to each parity object storage device in order of increasing load value.

[0017] On the other hand, object storage devices synchronize target data blocks to parity object storage devices, including:

[0018] Obtain the access frequency of the target data block;

[0019] If the target data block is determined to be a hot data block based on the access frequency, the target data block is synchronized to the parity object storage device, and confirmation information is awaited from the parity object storage device.

[0020] If the target data block is determined to be a cold data block based on the access frequency, multiple operations on the cold data block are accumulated, and the target data block obtained by merging the multiple operations is synchronized to the parity object storage device.

[0021] On the other hand, after the primary object storage device synchronizes the target data block to the parity object storage device, it also includes:

[0022] From the moment the target data block is synchronized to the parity object storage device, a first confirmation message is received from the parity object storage device within a first preset time period; wherein, the first confirmation message includes at least information indicating that the parity object storage device has successfully received the target data block and information indicating that the parity object storage device has stored the target data block in the cache;

[0023] The second confirmation information sent by the parity object storage device is received; wherein the second confirmation information includes at least one item indicating that the parity object storage device has written the log record of the target data block into the local persistent memory space;

[0024] The system returns information to the client indicating a successful update and marks the data status of the preset data block as pending encoding.

[0025] On the other hand, before the primary object storage device updates the locally stored preset data block to the target data block, it also includes:

[0026] Maintain a version vector for each placement group and record the latest version number of each data block;

[0027] Upon detecting concurrent write requests sent by the client to represent updates to preset data blocks, obtain the version number of the data blocks corresponding to all write requests; determine the highest version number based on all version numbers; and respond to the write request corresponding to the highest version number.

[0028] On the other hand, before obtaining the difference between the target data block and the original data block corresponding to the target data block stored locally, the method further includes:

[0029] Read local logs to extract the unique code, old value hash, target data block, old version number, and new version number of the target data block;

[0030] The original data block corresponding to the target data block is located using its unique code, and the location result is obtained.

[0031] If the value of the new version number is detected to be greater than the value of the old version number, and / or if the location result indicates that the original data block exists locally, proceed to the step of obtaining the difference between the target data block and the original data block corresponding to the target data block stored locally;

[0032] If the location result indicates that the original data block does not exist locally, a request for hash verification is sent to the primary object storage device. If the hash of the original data block sent by the primary object storage device matches the old value hash in the log, the original data block sent by the primary object storage device is obtained, and the process proceeds to the step of obtaining the difference between the target data block and the original data block corresponding to the target data block stored locally. If they do not match, a prompt message indicating rejection is output.

[0033] On the other hand, determining the coding coefficients based on the fault domain configuration of the placement group includes:

[0034] Obtain the relationship between itself and the fault domains of the data block object storage device; wherein, the fault domain is a rack or node;

[0035] If the relationship is detected to be within the same fault domain, then the coefficient for the same fault domain is set to 1;

[0036] If the relationship is detected to be across fault domains, then the cross-fault domain coefficient is set to a coprime coefficient.

[0037] Generate an encoding matrix based on the values ​​of the same fault domain coefficients and the cross-fault domain coefficients;

[0038] The coding coefficients are determined based on the elements in the coding matrix.

[0039] On the other hand, determining the coprime coefficients includes:

[0040] Obtain the fault domain distance value and a pre-created prime number library;

[0041] Prime numbers that are positively correlated with the fault domain distance value are selected from the prime number library to obtain coprime coefficients.

[0042] On the other hand, after generating the coding matrix based on the values ​​of the same fault domain coefficients and the cross-fault domain coefficients, the method further includes:

[0043] The fault domain distribution of object storage devices within the placement group is monitored in real time via a metadata server.

[0044] If a change in the fault domain topology is detected, return to the step of obtaining the relationship between itself and the fault domains of the data block object storage device.

[0045] On the other hand, before updating the locally stored parity blocks using the parity block increment, the method further includes:

[0046] The parity block increment, the original data block, and the target data block are XORed, and the XOR result is obtained.

[0047] If the XOR calculation result is detected to be equal to an element in the encoding matrix, proceed to the step of updating the locally stored parity block using the parity block increment;

[0048] If the XOR calculation result is not equal to an element in the encoding matrix, return to the step of receiving the target data block sent by the master object storage device.

[0049] On the other hand, updating the parity blocks in local storage using the parity block increment includes:

[0050] Write the updated parity block to the new storage address;

[0051] After a successful write is detected, the metadata pointer is updated to point to the new address through an atomic write operation in the persistent memory space.

[0052] On the other hand, after updating the locally stored parity blocks using the parity block increment, the method further includes:

[0053] The version number of the target data block is updated to obtain a new version number;

[0054] Generate an encoding completion log; wherein the encoding completion log includes at least the unique encoding of the target data block, the hash value of the new parity block obtained after the update, and the new version number.

[0055] On the other hand, the persistent memory space includes a region for storing logs that have not yet been updated and a region for storing logs that have been encoded.

[0056] Specifically, the incomplete logs stored in the area for storing logs that have not been updated are retained until the encoding is completed; the encoded logs stored in the area for storing encoded logs are retained for a second preset duration.

[0057] On the other hand, after updating the locally stored parity blocks using the parity block increment, the method further includes:

[0058] Once the encoding is complete, delete the original data block and log stored locally;

[0059] Release the storage space occupied by the original data blocks and logs locally.

[0060] On the other hand, after updating the locally stored parity blocks using the parity block increment, the method further includes:

[0061] Send information indicating the completion of encoding to the master object storage device; wherein the information indicating the completion of encoding includes the hash value of the new parity block; so that the master object storage device can change the data state from the pending encoding state to the completed state and synchronize the data state to the metadata server.

[0062] To address the aforementioned technical problems, this invention also provides a data processing method for an erasure propagation storage pool based on a distributed storage system, applied to the primary object storage device in the erasure propagation storage pool, wherein any data block in the erasure propagation storage pool is stored in both the primary object storage device and the parity object storage device; the method includes:

[0063] Get the write request sent by the client that represents the update of the preset data block;

[0064] The target data block is obtained by updating the preset data block stored locally according to the write request;

[0065] The target data block is synchronized to the parity object storage device so that the parity object storage device can obtain the difference between the target data block and the original data block corresponding to the target data block in local storage; the coding coefficients determined based on the fault domain configuration of the placement group are obtained, and the parity block increment is determined according to the coding coefficients and the difference; the parity block in local storage is updated using the parity block increment.

[0066] To address the aforementioned technical problems, the present invention also provides a distributed storage system, comprising a primary object storage device, a parity object storage device, and a metadata server; wherein, the primary object storage device is used to acquire a write request sent by a client to represent an update of a preset data block; update the preset data block stored locally according to the write request to obtain a target data block; and synchronize the target data block to the parity object storage device;

[0067] The metadata server is used to determine coding coefficients based on the fault domain configuration of the placement group;

[0068] The parity object storage device is used to receive a target data block sent by the main object storage device; obtain the difference between the target data block and the original data block corresponding to the target data block in local storage; obtain the coding coefficient determined based on the fault domain configuration of the placement group, and determine the parity block increment according to the coding coefficient and the difference; and update the parity block in local storage using the parity block increment.

[0069] To address the aforementioned technical problems, the present invention also provides a data processing apparatus, comprising:

[0070] Memory, used to store computer programs;

[0071] A processor is used to implement the steps of the erasure storage pool data processing method based on a distributed storage system when executing the computer program.

[0072] To address the aforementioned technical problems, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the erasure storage pool data processing method based on a distributed storage system described above.

[0073] The beneficial effect of this invention is that, in this method, the primary object storage device updates the preset data block stored locally according to the write request sent by the client to represent the update of the preset data block, and then sends the target data block to the parity object storage device. That is, in the method provided by this invention, the primary object storage device undertakes the tasks of updating local data and synchronizing copies. Since any data block in the erasure storage pool is stored in both the primary object storage device and the parity object storage device, meaning the parity object storage device locally holds a complete copy of the data block, after receiving the target data block sent by the primary object storage device, the parity object storage device can obtain the original data block corresponding to the target data block locally, and thus perform autonomous encoding. During autonomous encoding, the parity object storage device obtains the difference between the target data block and the original data block corresponding to the target data block stored locally; obtains the encoding coefficients determined based on the fault domain configuration of the placement group; determines the parity block increment based on the encoding coefficients and the difference; and finally updates the parity block stored locally using the parity block increment. Because this method uses incremental encoding to update the parity blocks in local storage during autonomous encoding of the parity object storage device, it does not rely on the striped data of the primary object storage device or the full placement group, thus avoiding a large amount of redundant read and write operations and increased latency. In this method, the parity object storage device undertakes the functions of autonomous encoding and updating parity blocks, achieving decoupling between encoding and updating. Moreover, the primary object storage device only undertakes the tasks of updating local data and synchronizing copies, instead of performing the entire "read-modify-encode-write" operation as before, reducing the burden on the primary object storage device. As a result, the primary object storage device no longer becomes a system bottleneck in high-concurrency scenarios, thereby relatively improving the performance of the storage system.

[0074] In addition, the primary object storage device logs data before updating its own stored preset data blocks to the target data blocks. An "old value hash" is introduced into the log to replace the complete storage of the old value, reducing persistent memory space usage (from the original full storage of the old value to 1 / 8 to 1 / 16). Simultaneously, hash verification ensures the consistency of the old value, resolving the space redundancy problem caused by traditional log storage of the complete old value.

[0075] When the primary object storage device synchronizes the target data block to the parity object storage device, it obtains the load value of the parity object storage device and dynamically selects the synchronization order based on the load balancing status (prioritizing sending to the low-load parity object storage device) to avoid a single parity object storage device becoming a bottleneck.

[0076] When synchronizing target data blocks to parity object storage devices, the primary object storage device uses a "synchronous + asynchronous confirmation" mode (send data first, then wait for confirmation) for hot data blocks (accessed frequently) and a "batch synchronization" mode (accumulate multiple updates and then send them together) for cold data blocks, which can reduce the number of network interactions.

[0077] After the primary object storage device synchronizes the target data block to the parity object storage device, it receives the first and second confirmation information sent by the parity object storage device. The "double confirmation" mechanism balances performance and reliability, avoiding the consistency risk caused by cache loss in the traditional single confirmation mode.

[0078] Before the primary object storage device updates its own preset data blocks to the target data blocks, it only allows the request with the highest version number to enter the data update and synchronization process when concurrent update requests are detected, while other requests are delayed and retried to ensure consistency.

[0079] Before performing autonomous encoding, the parity object storage device introduces hash verification instead of transmitting the complete old value, which reduces cross-node data interaction (only 32-byte hash values ​​are transmitted instead of complete data blocks), and prevents encoding errors caused by data inconsistency between the main object storage device and the parity object storage device.

[0080] The coding matrix is ​​dynamically generated based on the fault domains (such as cabinets and nodes) of the placement group. Setting the coefficient for the same fault domain to 1 simplifies the calculation; setting the coefficients for cross-fault domains to coprime numbers ensures linear independence and improves fault recovery efficiency. Furthermore, when selecting prime numbers, the greater the distance, the larger the prime number, which can improve the fault tolerance capability for cross-domain faults.

[0081] The metadata server monitors the distribution of fault domains of the object storage devices within the group in real time. When a change in the fault domain topology is detected (such as the addition of a new rack), the coefficients are automatically recalculated and synchronized to the relevant object storage devices to ensure that the matrix adapts to the current cluster status.

[0082] Before updating the parity blocks in local storage using the parity block increment, an XOR check is performed on the calculated parity block increment to ensure the accuracy of the increment calculation.

[0083] A copy-on-write mechanism is adopted to write the updated parity blocks to a new storage address. After a successful write is detected, the metadata pointer is updated to point to the new address through an atomic write operation in persistent memory space, thus avoiding the corruption of parity blocks caused by power failure during the update process.

[0084] In addition, the present invention also provides a data processing method for erasure storage pools based on a distributed storage system, a distributed storage system, a data processing device, and a computer-readable storage medium for primary object storage devices in erasure storage pools. These methods have the same or corresponding technical features as the aforementioned data processing method for erasure storage pools based on a distributed storage system for parity object storage devices in erasure storage pools, and have the same effects. Attached Figure Description

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

[0086] Figure 1 This invention provides an overall architecture diagram of a distributed storage system according to an embodiment of the invention.

[0087] Figure 2 A flowchart of a data processing method for an erasure storage pool based on a distributed storage system, applied to an even / odd object storage device in an erasure storage pool, is provided as an embodiment of the present invention.

[0088] Figure 3 This is a schematic diagram illustrating the entire process of an erasure storage pool data processing method based on a distributed storage system, as provided in an embodiment of the present invention.

[0089] Figure 4 This is a structural diagram of a data processing apparatus provided in an embodiment of the present invention. Detailed Implementation

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

[0091] The core of this invention is to provide a data processing method and system for erasure storage pools based on a distributed storage system, in order to solve the problems that the main OSD bears the heavy responsibility of encoding and synchronization, and becomes the system bottleneck in high-concurrency scenarios; and that the overwrite operation requires access to the striped data of the entire placement group, resulting in a large amount of redundant read and write operations and a significant increase in latency.

[0092] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 An overall architecture diagram of a distributed storage system provided in an embodiment of the present invention is shown below. Figure 1As shown, it includes a distributed storage client, a distributed storage system, and a unified, self-controlled, and scalable distributed storage consistency management system. In the distributed storage client, the client layer provides three interfaces: block, object, and file. Correspondingly, objects correspond to object network management services, blocks to block device services, and files to file system services. The object gateway service connects to the storage pool, and the storage pool connects to the file system service through a metadata server cluster and a monitoring service cluster. The storage pool includes storage pools... To storage pool A controllable, scalable, and distributed replica data placement algorithm is used to map the data to groups 1 through n, with each group mapped to a node. To node In this system, each node corresponds to multiple OSDs. Specifically, the distributed storage system adopts a decentralized, distributed architecture. Its core components include clients, a control plane (Monitor), a metadata server (MDS), and object storage devices (OSDs). These modules collaborate via high-speed networks (such as Ethernet and InfiniBand) to achieve data storage and management. The architecture layers are explained below:

[0093] 1. Client Layer: The client layer is the entry point for users to interact with distributed storage, providing three interfaces: block, object, and file. Core components include:

[0094] The librados library encapsulates the underlying Application Programming Interface (API) and is responsible for interacting with the cluster.

[0095] CRUSH client module: Local caches the CRUSH Map and calculates data storage locations. Input: Object name, storage pool rules (e.g., number of replicas, fault domain level). Processing steps: Hash the object name to generate a random number. Traverse the CRUSH bucket level (e.g., host → rack → data center) according to the storage pool rules, and select OSDs based on weights. Ensure balanced data distribution and meet redundancy policies (e.g., deploying replicas across racks).

[0096] 2. Control Plane (MoKitor / MDS):

[0097] MoKitor: Maintains cluster metadata (OSD Map, CRUSH Map, authentication information) and ensures consistency across multiple nodes through the Paxos algorithm.

[0098] Interaction with the client: When the client connects for the first time, it pulls the latest cluster map and updates it synchronously via heartbeat.

[0099] MDS (File Scenario): Manages file system metadata (directory tree, permissions), and caches hot metadata to accelerate access.

[0100] 3. Data Plane (OSD Cluster):

[0101] OSD Node: Hardware components include CPU, memory, disk (HDD / SSD), and network interface (Gigabit / 10 Gigabit network card). It is responsible for data storage, replication, erasure coding, consistency maintenance, and uses OSDMap to understand the cluster topology.

[0102] This invention provides a data processing method (i.e., a write optimization method) for erasure storage pools based on distributed storage systems, applied to parity OSDs (Parity OSDs) within the erasure storage pool. The parity OSD is the core node in the distributed storage system responsible for storing parity blocks and performing autonomous encoding, corresponding to the primary OSD (Primary OSD) which stores the original data blocks. The core function of the parity OSD is to ensure data reliability through redundant parity blocks. Traditional distributed storage systems only store parity blocks and do not have copies of the data blocks. In this invention, ensuring that the parity OSD locally holds complete copies of the data blocks is a prerequisite for enabling autonomous encoding. That is, in this invention, any data block in the erasure storage pool is stored in both the primary OSD and the parity OSD. Figure 2 A flowchart illustrating a data processing method for an erasure storage pool based on a distributed storage system, applied to an even / odd object storage device in an erasure storage pool, is provided as an embodiment of the present invention. Figure 2 As shown, the method includes:

[0103] S10: Receive the target data block sent by the primary object storage device; wherein, the target data block is obtained by the primary object storage device updating the preset data block stored locally according to the write request sent by the client to represent the update of the preset data block;

[0104] S11: Obtain the difference between the target data block and the original data block corresponding to the target data block stored locally;

[0105] S12: Obtain the coding coefficients determined based on the fault domain configuration of the placement group, and determine the parity block increment based on the coding coefficients and the difference;

[0106] S13: Update the parity blocks in the local storage using parity block increments.

[0107] It should be noted that the client sends a write request to the primary object storage device to represent an update of a preset data block. The preset data block is not limited and is determined based on the actual situation. The preset data block in the write request is the same as the original data block corresponding to the target data block in the parity object storage device.

[0108] In order to record the value before the update (i.e., the old value), the primary object storage device includes the following steps before updating the locally stored preset data block to the target data block:

[0109] The main object storage device records logs and writes them to the persistent memory space in multiple steps using the preset byte atomic write feature of persistent memory; the logs include at least the unique code of the preset data block, the version number prefix, the old value hash, and the new value pointer.

[0110] The default size is 8 bytes. Before updating the target data block with the default data block stored in its own storage, the main object storage device records a log. An "old value hash" is introduced into the log to replace the storage of the complete old value, reducing persistent memory space usage (from the original full storage of the old value to 1 / 8 to 1 / 16). At the same time, hash verification ensures the consistency of the old value, solving the space redundancy problem caused by traditional log storage of the complete old value.

[0111] After recording the old value information, the primary object storage device updates the preset data blocks in its local storage to obtain the target data block. The target data block is then synchronized to the parity object storage device. To avoid a single parity object storage device becoming a bottleneck, the synchronization of the target data block from the primary object storage device to the parity object storage device includes:

[0112] Based on the metadata of the placement group, locate multiple parity object storage devices in the placement group strip to which the target data block belongs;

[0113] Get the load values ​​of multiple parity object storage devices;

[0114] The target data blocks are synchronized to each parity object storage device in order of load value from low to high.

[0115] That is, when the primary object storage device synchronizes the target data block to the parity object storage device, it obtains the load value of the parity object storage device and dynamically selects the synchronization order based on the load balancing status (prioritizing sending to the low-load parity object storage device) to avoid a single parity object storage device becoming a bottleneck.

[0116] In practice, some data blocks are accessed less frequently, while others are accessed more frequently. To reduce the number of network interactions, in implementation, the primary object storage device synchronizes the target data blocks to the parity object storage device, including:

[0117] Obtain the access frequency of the target data block;

[0118] If the target data block is determined to be a hot data block based on the access frequency, the target data block is synchronized to the parity object storage device, and the device waits for confirmation information to be returned.

[0119] If the target data block is determined to be a cold data block based on the access frequency, multiple operations on the cold data block are accumulated, and the target data block obtained by merging the multiple operations is synchronized to the parity object storage device.

[0120] By using a "synchronous + asynchronous confirmation" mode (send data first, then wait for confirmation) for hot data blocks (accessed frequently) and a "batch synchronization" mode (accumulate multiple updates and then send them together), the number of network interactions is reduced.

[0121] After the primary object storage device synchronizes the target data block to the parity object storage device, to ensure reliable data transmission, the primary object storage device further includes the following steps:

[0122] From the start of synchronizing the target data block to the parity object storage device, a first confirmation message is received from the parity object storage device within a first preset time period; wherein, the first confirmation message includes at least information indicating that the parity object storage device has successfully received the target data block and information indicating that the parity object storage device has stored the target data block in the cache;

[0123] The parity object storage device receives a second confirmation message; wherein the second confirmation message includes at least one log record indicating that the parity object storage device has written the target data block into the local persistent memory space.

[0124] Return information to the client indicating a successful update and mark the data status of the preset data block as pending encoding.

[0125] In this method, after the master object storage device synchronizes the target data block to the parity object storage device, it receives the first confirmation information and the second confirmation information sent by the parity object storage device. The "double confirmation" mechanism balances performance and reliability and avoids the consistency risk caused by cache loss in the traditional single confirmation mode.

[0126] To maintain consistency, before the primary object storage device updates the locally stored preset data blocks to the target data blocks, it also includes:

[0127] Maintain a version vector for each placement group and record the latest version number of each data block;

[0128] Upon detecting concurrent write requests from clients that represent updates to preset data blocks, obtain the version number of the data blocks corresponding to all write requests; determine the highest version number based on all version numbers; and respond to the write request corresponding to the highest version number.

[0129] In this method, when the main object storage device detects concurrent update requests, it only allows the request with the highest version number to proceed with data update and synchronization, while the remaining requests are delayed and retried, thus ensuring consistency.

[0130] The above process describes the processing procedure of the primary object storage device in the erasure storage pool data processing method based on a distributed storage system, that is, the primary object storage device undertakes the functions of updating local data and synchronizing copies.

[0131] After receiving the target data block from the main object storage device, the parity object storage device, in order to ensure that both the original data block and the target data block exist locally simultaneously for autonomous encoding, includes the following steps before obtaining the difference between the target data block and the corresponding original data block stored locally:

[0132] Read the local log to extract the unique code, old value hash, target data block, old version number, and new version number of the target data block;

[0133] Locate the corresponding original data block using the unique code of the target data block and obtain the location result;

[0134] If the value of the new version number is detected to be greater than the value of the old version number, and / or if the location result indicates that the original data block exists locally, proceed to the step of obtaining the difference between the target data block and the original data block corresponding to the target data block stored locally;

[0135] If the location result indicates that the original data block does not exist locally, a request for hash verification is sent to the primary object storage device. If the hash of the original data block sent by the primary object storage device matches the old value hash in the log, the original data block sent by the primary object storage device is obtained, and the process proceeds to the step of obtaining the difference between the target data block and the original data block corresponding to the target data block stored locally. If they do not match, a prompt message indicating rejection is output.

[0136] In this method, before performing autonomous encoding, the parity object storage device introduces hash verification instead of transmitting the complete old value, which reduces cross-node data interaction (only 32-byte hash values ​​are transmitted instead of complete data blocks), and at the same time prevents encoding errors caused by data inconsistency between the main object storage device and the parity object storage device.

[0137] When performing autonomous encoding, the parity object storage device obtains the difference between the target data block and the original data block corresponding to the target data block in local storage; obtains the encoding coefficients determined based on the fault domain configuration of the placement group; and determines the parity block increment based on the encoding coefficients and the difference.

[0138] Specifically, determining the coding coefficients based on the fault domain configuration of the placement group includes:

[0139] Obtain the relationship between itself and the fault domains of the data block object storage device; where the fault domain is a rack or node;

[0140] If the relationship is detected to be in the same fault domain, then set the coefficient of the same fault domain to 1;

[0141] If a relationship is detected to be across fault domains, then the cross-fault domain coefficient is set to a coprime coefficient.

[0142] Generate an encoding matrix based on the values ​​of coefficients within the same fault domain and coefficients across fault domains;

[0143] The coding coefficients are determined based on the elements in the coding matrix.

[0144] To improve fault tolerance across domains, the coprime coefficients are determined to include:

[0145] Obtain the fault domain distance value and a pre-created prime number library;

[0146] Prime numbers that are positively correlated with the fault domain distance value are selected from the prime number library to obtain coprime coefficients.

[0147] In this method, an encoding matrix is ​​dynamically generated based on the fault domains (such as cabinets and nodes) of the placement group. Setting the coefficient for the same fault domain to 1 simplifies calculations. Setting the coefficients for cross-fault domains to coprime numbers ensures linear independence and improves fault recovery efficiency. Furthermore, when selecting prime numbers, the greater the distance, the larger the prime number, which improves the fault tolerance capability for cross-domain faults.

[0148] In practice, the fault domain topology may change (e.g., a new rack is added). To ensure the obtained coding coefficients are adapted to the current cluster state, the implementation includes, after generating the coding matrix based on the values ​​of coefficients within the same fault domain and those across fault domains, the following steps are also taken:

[0149] The fault domain distribution of object storage devices within the placement group is monitored in real time via a metadata server.

[0150] If a change in the fault domain topology is detected, return to the steps for obtaining the relationship between itself and the fault domains of the data block object storage device.

[0151] In this method, the metadata server monitors the distribution of fault domains of the object storage devices within the placement group in real time. When a change in the fault domain topology is detected (such as the addition of a new rack), the coefficients are automatically recalculated and synchronized to the relevant object storage devices to ensure that the matrix adapts to the current cluster status.

[0152] The odd / even block increment is determined based on the coding coefficients and differences. The expression is:

[0153] ;

[0154] in, Represents the original data block. This refers to the target data block (i.e., the data block obtained after being updated by the main object storage device). Indicates the first The odd / even block corresponds to the first Each data block encoding coefficient, Indicated by The remainder modulo 1.

[0155] After obtaining the parity increment, to ensure the accuracy of the increment calculation, in implementation, before updating the locally stored parity block using the parity block increment, the following steps are also included:

[0156] Obtain the parity block increment, the original data block, and the target data block, perform an XOR operation, and obtain the XOR result.

[0157] If the XOR calculation result is found to be equal to an element in the encoding matrix, proceed to the step of updating the locally stored parity block using parity block increment;

[0158] If the XOR calculation result is not equal to an element in the encoding matrix, return to the step of receiving the target data block sent by the master object storage device.

[0159] Before updating the parity blocks in local storage using the parity block increment, an XOR check is performed on the calculated parity block increment to ensure the accuracy of the increment calculation.

[0160] If the verification passes, the parity blocks in local storage are updated incrementally using parity blocks. To prevent parity block corruption due to power outages during the update process, the implementation includes the following steps for incrementally updating the parity blocks in local storage:

[0161] Write the updated parity block to the new storage address;

[0162] After a successful write is detected, the metadata pointer is updated to point to the new address through an atomic write operation in the persistent memory space.

[0163] This involves using a copy-on-write mechanism to write the updated parity blocks to a new storage address. After a successful write is detected, the metadata pointer is updated to point to the new address through an atomic write operation in persistent memory, thus avoiding parity block corruption caused by power outages during the update process.

[0164] To ensure timely log updates, after incrementally updating the parity blocks in local storage using parity blocks, the following steps are also included:

[0165] Update the version number of the target data block to obtain a new version number;

[0166] Generate an encoding completion log; the encoding completion log shall include at least the unique encoding of the target data block, the hash value of the new parity block obtained after the update, and the new version number.

[0167] The persistent memory space includes a region for storing logs that have not yet been updated and a region for storing logs that have been encoded. The incomplete logs stored in the region for storing logs that have not yet been updated are retained until encoding is complete. The encoded logs stored in the region for storing logs that have been encoded are retained for a second preset duration. The second preset duration is not limited and is determined based on actual circumstances.

[0168] To reduce the storage space occupied by data blocks and logs, after incrementally updating the parity blocks in local storage using parity blocks, the following is also included:

[0169] Once encoding is complete, delete the original data blocks and logs stored locally.

[0170] Release the storage space occupied by the original data blocks and logs locally.

[0171] In addition, to ensure that the correct data state is recorded in the primary object storage device, the implementation includes, after updating the parity blocks of the local storage using parity block increments:

[0172] Send information indicating the completion of encoding to the master object storage device; wherein the information indicating the completion of encoding includes the hash value of the new parity block; so that the master object storage device can change the data status from the pending encoding state to the completed state and synchronize the data status to the metadata server.

[0173] Based on the erasure storage pool data processing method of the distributed storage system described above, this invention adds an "erasure write optimization module" to the existing IO process of the distributed storage system. The optimization module is specifically embedded in the data IO of the distributed storage system at the following locations:

[0174] Main OSD side: Located between the data receiving module and the synchronization module, responsible for data update triggering and log management;

[0175] Parity OSD side: Located between the data receiving module and the storage module, it is responsible for data copy storage, incremental encoding, and parity block updates;

[0176] Metadata layer: Interacts with MDS (Metadata Service) to obtain PG stripe distribution information and fault domain configuration (reference).

[0177] Comparison of data I / O processes before and after optimization in a distributed storage system:

[0178] Traditional process: Client → Master OSD (sharding + encoding) → Slave OSD (storage);

[0179] Optimized process: Client → Master OSD (Optimized module: update data + synchronize replica) → Odd / Even OSD (Optimized module: custom encoding + update odd / even blocks).

[0180] Among them, the primary OSD refers to the core node in the erasure coding (EC) storage pool that is responsible for data block management and update coordination. In the distributed storage system architecture, it is directly associated with the PG (Placement Group): as the coordinator of data operations within the PG, it receives client write requests and manages the initial storage and replica synchronization of data blocks. In traditional EC storage pools, the primary OSD undertakes the heavy responsibility of data sharding, full PG striping coding (generating parity blocks), and cross-node synchronization, and is the main source of performance bottlenecks.

[0181] In this invention, the primary OSD's responsibilities are optimized to "data update triggering + replica synchronization". It no longer participates in the coding process, but is only responsible for synchronizing the updated data blocks to the odd and even OSDs, and recording the update status (block ID + version number) through the PMem log to ensure the traceability of the update process.

[0182] Parity OSD refers to a node that stores parity blocks and autonomously performs encoding operations, deeply bound to the fault domain design of the PG: it stores parity blocks and data block replicas within the corresponding PG (according to the "1 master M slave" placement strategy of this invention, each data block has one replica stored in each of the M parity OSDs); in traditional EC storage pools, parity OSDs only passively receive parity blocks generated by the master OSD and have no autonomous encoding capability; in this invention, parity OSDs are endowed with autonomous encoding capability: based on the locally stored data block replicas, the parity block increment is calculated through the incremental encoding algorithm proposed below in this invention, without relying on the master OSD or the full PG stripe data, thus achieving decoupling of encoding and updating.

[0183] To enable those skilled in the art to better understand the erasure storage pool data processing method based on a distributed storage system described above, the following description will continue with reference to the accompanying drawings and specific embodiments. Figure 3This is a schematic diagram illustrating the entire process of a data processing method for erasure storage pools based on a distributed storage system, as provided in an embodiment of the present invention. Figure 3 As shown, the client sends data write input / output requests to the primary object storage device. The primary object storage device records persistent memory hierarchical logs, updates local data blocks, and synchronizes data to the parity object storage device. The primary object storage device sends write requests to the parity object storage device, which performs log parsing, hash verification, data block synchronization, incremental encoding, and copy-on-write update operations. After the parity object storage device completes the parity block update, the primary object storage device receives an encoding completion notification from the parity object storage device.

[0184] Specifically, it includes the following steps:

[0185] The first step is the data placement strategy (for the (K,M)EC storage pool, i.e., the storage pool contains K data blocks and M parity OSDs):

[0186] 1. Data block distribution:

[0187] K data blocks The data is stored in a "1 master M slave" mode: each data block is stored in one copy on the master OSD and one copy on each of the M parity OSDs (forming K groups of M+1 copies), ensuring that the parity OSDs hold a complete copy of the data block locally.

[0188] 2. Odd / Even Block Distribution:

[0189] M odd and even blocks The blocks are stored in M ​​parity OSDs, with each parity OSD only storing the parity blocks it is responsible for. and corresponding data blocks (i.e., data block replicas) do not require the primary OSD to obtain full PG stripe data.

[0190] Step 2: Optimize the two-phase write method based on the erasure data pool of the distributed storage system:

[0191] Phase 1, Data Update (Synchronous Replica Mode, Layered Logging and Multi-Dimensional Confirmation Mechanism): The client sends a write request (update) to the master OSD. for The main OSD optimizes execution through the "Data Update Module":

[0192] 1. Record PMem (Persistent Memory) logs (including a 64-bit block ID, a 32-bit version number prefix, a 64-bit old value hash, and a 64-bit new value pointer), with a total length of 224 bits (28 bytes). Utilizing PMem's 8-byte atomic write feature, the logs are written atomically in three stages (the first two stages are 8 bytes each, and the final stage is 4 bytes to complete the write), ensuring log integrity. An "old value hash" is introduced to replace the storage of the complete old value, reducing PMem space usage (from storing the entire old value to 1 / 8 to 1 / 16). Simultaneously, hash verification ensures old value consistency (solving the space redundancy problem caused by storing the complete old value in traditional logs). Based on PMem's atomic write feature, the log only requires 16 bytes (block ID + version number), improving performance by over 80% compared to traditional logs, providing a lightweight log.

[0193] 2. Data Update and Intelligent Synchronization. Update local data blocks to... The data is then synchronized to the corresponding replicas of the M odd and even OSDs. Based on the PG metadata, the M odd and even OSDs of the PG stripe to which the data block belongs are located (ensuring cross-fault domain distribution). When synchronizing replicas, OSDs with loads below a threshold (e.g., 70%) are prioritized to avoid single-point overload. The primary OSD is updated locally (updating...). for The system then locates the M parity OSDs of the PG stripe to which the data block belongs based on the PG (Placement Group) metadata (by obtaining the OSD mapping table of the current PG through the MDS). Combined with the PG's load balancing status (obtained through the Monitor to get the OSD load value), the system dynamically selects the synchronization order (prioritizing sending to low-load parity OSDs) to avoid a single parity OSD becoming a bottleneck.

[0194] In addition, during synchronization, the synchronization strategy is as follows: for hot data blocks (accessed frequently), a "synchronous + asynchronous confirmation" mode is used (data is sent first, and then confirmation is waited for), and for cold data blocks, a "batch synchronization" mode is used (updates are accumulated N times and then sent together) to reduce the number of network interactions.

[0195] 3. Authentication and Response Mechanism. The master OSD needs to receive two types of authentication:

[0196] Basic confirmation: Odd / Even OSD successfully received. And write it to a temporary buffer (must return within 10ms, otherwise trigger a retransmission);

[0197] Log confirmation: Odd / Even OSD will Log records are written to the local PMem (ensuring no data loss in case of power failure, and returning within 20ms).

[0198] Only after all parity OSDs return two types of confirmations will the master OSD return "update successful" to the client (without waiting for encoding to complete) and mark the data block status as "pending encoding".

[0199] The "double confirmation" mechanism balances performance and reliability, avoiding the consistency risks caused by cache loss in the traditional single confirmation mode.

[0200] Phase 2: Autonomous Encoding (Asynchronous Execution by Odd / Even OSDs). After detecting an update to the local data block replica (based on version number increment or log triggering) through the "Autonomous Encoding Module," the Odd / Even OSDs asynchronously execute the following process:

[0201] 1. Log parsing and version verification: Reading local logs to obtain... , and version number .

[0202] Read the local PMem log and extract the block ID, old value hash, and new value. and version number Locate the corresponding original data block by block ID. (If not available locally) Then, a hash verification request is sent to the master OSD, and only if the master OSD returns a hash verification result... The hash is retrieved only when it matches the hash of the old value in the log. Otherwise, the encoding will be rejected and an exception will be flagged.

[0203] This method introduces hash verification to replace the transmission of the complete old value, reducing cross-node data interaction (only 32-byte hash values ​​are transmitted instead of complete data blocks), while preventing encoding errors caused by inconsistencies between the master OSD and parity OSD data.

[0204] 2. Incremental coding and dynamic matrix adaptation: Based on the coding matrix proposed in this invention Calculate the odd / even block increment (see the description below for a detailed implementation example);

[0205] Based on the encoding matrix ( Represents the real number field. The elements in are available It means that, among them, For the first The odd / even block corresponds to the first The coding coefficients of each data block are dynamically generated by MDS based on the fault domain configuration of the PG (e.g., increasing the coefficient weight when deployed across racks), and the parity block increment is calculated. ;

[0206] Perform an XOR check on the calculation result. This ensures that the incremental calculations are accurate.

[0207] In this method, the matrix It is bound to the PG fault domain (the corresponding coefficient of OSD in the same rack is 1, and the coefficient across racks is a prime number), which improves the recovery efficiency in fault scenarios, unlike the fixed matrix design in existing related technologies.

[0208] The erasure coding algorithm provided by this invention will be further described below. This invention's erasure coding algorithm is based on a dynamically generated matrix and an incremental calculation model, designed for (K,M)EC storage pools. It supports both initial full encoding and avoids full PG striping operations through local incremental updates. The core lies in the incremental calculation of the dynamic matrix coefficients for fault domain adaptation and hash verification, as detailed below:

[0209] First, the initial encoding formula (full encoding):

[0210] For the (K,M)EC system, let the data block be... The generating matrix is Initial parity block calculation:

[0211] ;

[0212] in, For the first Each odd and even block is generated by a linear combination of all data blocks.

[0213] 3. Parity Block Update and Atomic Commit: Incrementally update local parity blocks. for The version number is updated synchronously. And generate an "encoding completion log" (block ID + new parity block hash + version number).

[0214] Employing a "copy-on-write (COW)" mechanism: first, copy-on-write... Write to the new address, and after success, atomically switch the pointer (update metadata by writing 8 bytes of PMem atomically) to avoid parity block corruption caused by power failure during the update process.

[0215] By using "hash verification + COW" to ensure the atomicity of parity block updates, the partial write problem in the traditional in-place update mode is solved.

[0216] 4. Space reclamation and state synchronization: After coding is complete, delete the local space. Restore the copy and log (retain the "encoding completion log" for 10 minutes for primary OSD consistency verification), and free up storage space. Send an encoding completion notification (including the new parity block hash) to the primary OSD, which updates the block status from "pending encoding" to "complete" and synchronizes it to the MDS (for PG status monitoring).

[0217] The difference between this invention's method and related technologies lies in its layered log design: It replaces complete data storage with old value hashing and pointers, combining this with PMem's atomic write characteristics to achieve lightweight and high reliability of the log. Its dual-acknowledgment synchronization mechanism dynamically adjusts the synchronization strategy based on PG load, ensuring no data loss through basic acknowledgment and log acknowledgment, which is superior to the traditional single-acknowledgment mode. Fault domain adaptation matrix: an encoding matrix. Binding to PG fault domains (such as racks and nodes) improves fault recovery efficiency and overcomes the limitations of fixed matrices. Hash verification and COW: Hash verification is introduced throughout the process to prevent data tampering, and the COW mechanism ensures the atomicity of encoding, resolving consistency conflicts caused by concurrent updates.

[0218] Through the above optimizations, the two-phase write method maintains compatibility with the distributed storage erasure pool architecture, reduces write latency to less than 10% of the traditional method, increases the number of input / output operations per second (IOPS) by more than 3 times, and avoids the space redundancy problem caused by relying on a fixed number of replicas (such as a fixed number of replicas of M+1) in related technologies.

[0219] The following uses a (3,2) EC storage pool (K=3, M=2) as an example to illustrate the encoding matrix of this invention. By adopting a fault domain-aware dynamic coefficient allocation strategy and combining linear algebra and prime number properties, the following innovative design is implemented in the (3,2)EC scenario:

[0220] 1. Fault Domain Topology Analysis and Matrix Initialization: MDS first parses the topology of the PG: Data block distribution: Three OSDs located in rack A. Parity block distribution: Located in rack A, Located in rack B. MDS performs the following steps to generate the matrix. : Same fault domain coefficient allocation, for odd and even blocks within rack A The coefficients are set to an all-1 vector [1,1,1]. Mathematical basis: OSD faults within the same rack have high correlation; all-1 coefficients simplify incremental calculations. Furthermore, during fault recovery, decoding can be completed using only local data. Cross-fault domain coefficient allocation: parity blocks for rack B. The coefficients are chosen from a sequence of coprime prime numbers [3, 5, 7]. Mathematical basis: prime numbers have no common divisors, ensuring linear independence of matrix row vectors (to avoid issues caused by cabinet B malfunction). and Simultaneous failure recovery (failure when simultaneously failed). The modulo operation characteristics of prime numbers can reduce encoding conflicts (e.g., 3mod2=1, 5mod2=1, ensuring independence in the binary field).

[0221] 2. Therefore, in this embodiment of the invention, the MDS configuration encoding matrix is ​​as follows:

[0222] ;

[0223] If the data block value is ;

[0224] but .

[0225] Second, the incremental coding formula:

[0226] When data blocks Updated to At that time, the increment of parity blocks Only a single data block change is required; no need to read the entire PG stripe.

[0227] This avoids the traditional "read the entire PG stripe - re-encode" process, reducing I / O amplification. An XOR check is performed on the calculation results. This ensures that the incremental calculations are accurate.

[0228] Following the above (3,2) EC instance, if Updated from 20 to 25 (i.e.) The difference value is ), Incremental calculation: ;

[0229] Updated odd / even blocks:

[0230] ;

[0231] XOR check: The goal of simplified verification is to quickly eliminate obvious errors, rather than strict mathematical equivalence. In simplified verification, when When it is an odd number, The result should be 0 (as in the example). The parity of the coefficients is verified; in actual engineering, the total time is controlled within 5μs by combining CRC32 to verify the complete data.

[0232] This invention proposes the following erasure coding algorithm flow: The algorithm flow revolves around three core stages: "log parsing - incremental calculation - atomic update", and combines hash verification and copy-on-write (COW) mechanisms to ensure the consistency and reliability of the coding process. The specific steps are as follows:

[0233] Step 1: Log parsing and version verification (Odd / Even OSD side):

[0234] 1. Odd / Even OSD reads the local PMem log and extracts the field: Block ID=2 (corresponding to...) ), old value hash = hash(20) = 0xABC, new value =25, Version Number .

[0235] 2. Locate the original data block in local storage. If it does not exist, a "hash check request" is sent to the main OSD.

[0236] 3. Main OSD return The hash is 0xABC, which matches the old hash in the log, confirming data consistency and allowing encoding.

[0237] Step 2: Dynamic matrix acquisition and incremental calculation:

[0238] 1. Odd / Even OSD obtains the encoding matrix of the current PG through MDS. (As described above).

[0239] 2. Calculate data block differences: .

[0240] 3. Calculate the increment: .

[0241] 4. Perform XOR check: The verification was simplified, and CRC32 was actually used to confirm that the calculation was correct.

[0242] Step 3: Odd / Even Block Atom Update and COW Mechanism:

[0243] 1. Parity OSD uses Copy-on-Write (COW): for and Allocate a new address and write values ​​65 and 365. Update the metadata pointer via an 8-byte atomic write to PMem, switching from the old address to the new address.

[0244] 2. Generate "Encoding Completion Log": Block ID=2, New Odd / Even Block Hash=hash(65,365)=0xDEF, Version Number .

[0245] Step 4: Space reclamation and state synchronization:

[0246] 1. Delete local The old copy (value 20) and update log are retained, and the "coding completion log" is retained for 10 minutes.

[0247] 2. Send an "encoding complete notification" to the master OSD. The master OSD will... The status changes from "Pending Encoding" to "Completed" and is synchronized to MDS.

[0248] In addition, the present invention also provides the following reliable guarantee:

[0249] Version control: Each data block / parity block is associated with a global version number. The version number is incremented during updates to ensure that read and write operations are based on the latest version and to avoid concurrent update conflicts.

[0250] Log mechanism: PMem logs only record incomplete updates (8-byte block ID + 8-byte version number). When a node fails, data is synchronized through the logs to ensure strong consistency (reference).

[0251] Fault tolerance: Based on the (K,M)EC feature, it can tolerate up to M node failures. The old and new data block copies of the parity OSD can be recovered by encoding.

[0252] Furthermore, the erasure storage pool data processing method and the collaborative processing process of the distributed storage system based on the present invention are described below:

[0253] I. Integration with PG technology:

[0254] A PG is a logical unit used for data distribution and redundancy management in a distributed storage system. This invention achieves coordination between the master OSD, parity OSDs, and the PG in the following way:

[0255] 1. Role division within PG:

[0256] Each PG contains K primary OSDs corresponding to data blocks and M parity OSDs corresponding to parity blocks (corresponding to (K,M)EC configuration). For example, in a (3,2)EC PG, the 3 primary OSDs manage the data blocks respectively, and the 2 parity OSDs manage the parity blocks respectively.

[0257] The primary OSD is mapped to the PG via the CRUSH algorithm and is responsible for updating and synchronizing data blocks within that PG. The parity OSDs are also distributed across different fault domains (such as different hosts / racks) via the CRUSH algorithm to avoid the loss of multiple parity blocks due to a single point of failure.

[0258] 2. Concurrency control at the PG level:

[0259] The master OSD records the update status (block ID + version number) of data blocks within the PG through the PMem log, ensuring that concurrent updates within the same PG are executed in order according to the version number;

[0260] Odd-even OSDs only trigger encoding when there are no incomplete logs (i.e., no concurrent updates) within the PG, thus avoiding encoding conflicts.

[0261] 3. Adaptation of PG to fault domain:

[0262] The distribution of primary OSDs and parity OSDs within the PG follows the fault domain isolation principle (such as cross-host deployment) to ensure the fault tolerance capability of (K,M)EC (tolerating a maximum of M node failures).

[0263] The incremental encoding mechanism of this invention retains old and new versions of data blocks at the PG level. Even if some nodes within the PG fail, the data can still be recovered by decoding the remaining copies or odd / even blocks.

[0264] II. Integration with EC Pool technology:

[0265] The erasure pool is a storage pool that employs an EC redundancy strategy. The design of the primary OSD and parity OSD directly serves to optimize the performance and reliability of the erasure pool.

[0266] 1. Data Placement and Erasure Pool Architecture:

[0267] The erasure pool is divided into PG stripes according to the (K,M)EC configuration. Each PG stripe corresponds to one or more PGs. The main OSD stores the original data blocks in the PG stripe, and the parity OSD stores the corresponding parity blocks and data block replicas (the hybrid placement strategy of this invention).

[0268] Compared to traditional erasure pools (with centralized encoding on the main OSD), this invention separates the encoding operation from the main OSD and distributes it to multiple nodes through autonomous encoding of odd and even OSDs, thereby reducing the overall load of the erasure pool.

[0269] 2. Optimization of overwrite operations (solving the "read-modify-encode-write" bottleneck):

[0270] Traditional erasure pool overwrite operations require the main OSD to read the entire PG stripe data (involving OSDs of multiple PGs), re-encode it, and then write it, resulting in I / O amplification.

[0271] In this invention, the master OSD only synchronizes the updated data blocks to the parity OSD (stage 1), and the parity OSD updates the parity blocks based on the local copy through incremental encoding (stage 2). There is no need to read the entire PG stripe, which reduces the I / O overhead of the overwrite operation to 0.

[0272] 3. Collaboration with erasure pool metadata:

[0273] The master OSD obtains the stripe distribution information of the erasure pool's PGs (such as the OSD list corresponding to each PG) through the MDS to ensure the accuracy of data block synchronization;

[0274] The parity OSD identifies the location of the parity block it is responsible for and its encoding matrix through PG metadata. The coefficients are autonomously encoded and the metadata version of the erasure pool is updated, ensuring compatibility with the OSD Map synchronization mechanism of the distributed storage system.

[0275] In practice, specifically:

[0276] 1. System Configuration:

[0277] Based on the (3,2) RS code (3 data blocks + 2 parity blocks), a 6-node distributed storage system is deployed. Each node is configured with: 2 CPUs, 256GB DRAM memory, 2 256GB PMem (for storing logs) and 24 HDDs (for storing data).

[0278] 2. Optimize module deployment:

[0279] Primary OSDs (3): Deploy the "data update module", responsible for synchronizing data to the odd and even OSDs;

[0280] Parity OSDs (2): Deploy "autonomous encoding modules" to store data copies and parity blocks, and perform incremental encoding;

[0281] Metadata layer: Obtain PG stripe distribution information through MDS to ensure correct mapping of data blocks / parity blocks.

[0282] The test results of the example show that, under the (3,2)EC configuration, the 4KB random write IOPS reached 210k (52k natively in the distributed storage system), and the 64KB sequential write throughput was 1.5GB / s (360MB / s natively in the distributed storage system). After hot and cold tiering, the storage redundancy rate decreased to 40%. Table 1 shows some of the test results.

[0283] Table 1

[0284] .

[0285] This invention decouples data updates from encoding by embedding an optimization module into the erasure propagation storage pool of a distributed storage system. Combined with incremental encoding and a lightweight logging mechanism, it effectively solves the performance bottleneck of traditional EC storage pools. Its modular design is compatible with existing architectures and can be widely applied in high-concurrency distributed storage scenarios, demonstrating significant practical value.

[0286] Specifically, the beneficial effects of the technical solution of this invention are mainly reflected in four dimensions: performance, reliability, compatibility, and resource efficiency, as detailed below:

[0287] In terms of performance improvement, by decoupling the data update and encoding processes, the encoding task is transferred from the main OSD to the odd and even OSDs for autonomous execution, avoiding the I / O amplification of the traditional "read-modify-encode-write" process. Real-world test data shows that 4KB random write IOPS reaches 210k (4.04 times that of the native EC storage pool), and 64KB sequential write throughput reaches 1.5GB / s (4.17 times that of the native pool); overwrite operation latency is reduced by 75% to 90%, and 4KB random write latency is only 8.2μs (7.8% of the native pool), significantly improving response speed in high-concurrency scenarios.

[0288] In terms of reliability and consistency assurance, relying on PMem lightweight logs (block ID + version number) and a two-phase write "double confirmation" mechanism, the data update process is ensured to be traceable, and even if a node fails, it can be recovered through log synchronization. At the same time, it is compatible with the fault tolerance capability of (K,M)EC, which can tolerate up to M node failures. The new and old data block replicas of the parity OSD storage combined with the dynamic encoding matrix further reduce the risk of data loss, and there are no consistency conflicts during concurrent updates.

[0289] In terms of compatibility, the optimization module is implemented by embedding the OSD layer, without the need to refactor the underlying code. It supports existing PG management, fault domain configuration and CRUSH algorithm, adapts to the existing architecture of enterprise-level distributed storage, and reduces migration costs.

[0290] In terms of resource efficiency, incremental encoding only transmits data block differences, reducing cross-node data transmission volume by 90%; PMem logs use hash + pointer to replace full data storage, reducing metadata overhead by 60%; the hot and cold data tiering strategy (hot replica, cold data EC) reduces storage redundancy by 60% compared to the fixed replica scheme, and approaches the storage efficiency of traditional EC under (3,2) EC configuration, balancing performance and space usage.

[0291] In summary, this invention achieves synergistic optimization of performance, reliability, and resource efficiency in high-concurrency distributed storage scenarios, and has significant practical value.

[0292] Furthermore, it should be noted that compared to optimizations based on encoding algorithms (regenerated codes, local repair codes), data layout-based optimizations (strip merging and layering strategies), and system architecture-based optimizations, the write operation-focused optimization provided by this invention is based on "incremental encoding + dynamic matrix." It does not rely on complex encoding algorithms but achieves efficient updates through local calculation of parity OSD. The optimization goals of these two approaches differ: the former optimizes fault repair, while the method provided by this invention optimizes real-time write performance; these are different technical paths.

[0293] The preceding text describes a data processing method for an erasure storage pool based on a distributed storage system, applied to an odd-even object storage device within an erasure storage pool. This invention also provides a data processing method for an erasure storage pool based on a distributed storage system, applied to a master object storage device within an erasure storage pool. This method includes:

[0294] Get the write request sent by the client that represents the update of the preset data block;

[0295] The target data block is obtained by updating the preset data block stored locally according to the write request;

[0296] The target data block is synchronized to the parity object storage device so that the parity object storage device can obtain the difference between the target data block and the original data block corresponding to the target data block in the local storage; the coding coefficients determined based on the fault domain configuration of the placement group are obtained, and the parity block increment is determined based on the coding coefficients and the difference; the parity block in the local storage is updated using the parity block increment.

[0297] The erasure storage pool data processing method based on a distributed storage system for primary object storage devices in an erasure storage pool provided in this embodiment has the same or corresponding technical features as the erasure storage pool data processing method based on a distributed storage system for parity object storage devices in an erasure storage pool described above. The embodiments of the erasure storage pool data processing method based on a distributed storage system for parity object storage devices in an erasure storage pool have been described in detail above, and the embodiments of the erasure storage pool data processing method based on a distributed storage system for primary object storage devices in an erasure storage pool will not be repeated here, but the effects are the same as above.

[0298] In addition, embodiments of the present invention also provide a distributed storage system, including a master object storage device, a parity object storage device, and a metadata server; wherein, the master object storage device is used to obtain a write request sent by a client to represent updating a preset data block; update the preset data block stored locally according to the write request to obtain a target data block; and synchronize the target data block to the parity object storage device;

[0299] The metadata server is used to determine coding coefficients based on the fault domain configuration of the placement group;

[0300] The parity object storage device is used to receive target data blocks sent by the master object storage device; obtain the difference between the target data block and the original data block corresponding to the target data block in the local storage; obtain the coding coefficients determined based on the fault domain configuration of the placement group, and determine the parity block increment based on the coding coefficients and the difference; and update the parity block in the local storage using the parity block increment.

[0301] Specifically, the main object storage device deploys a data update module to perform write request processing, PMem log recording, and data synchronization as described in Phase 1 above;

[0302] Parity object storage device: Deploys an autonomous coding module to perform the log parsing, incremental coding, parity block update and space reclamation described in Phase 2 above;

[0303] Metadata server: Deploys a matrix generation module to dynamically generate encoding matrices based on fault domains. And maintain the stripe distribution and version information of PG;

[0304] Client: Initiates write requests to the main object storage device and receives responses, interacting with the cluster through the distributed storage interface.

[0305] The data update module of the primary object storage device and the autonomous encoding module of the parity object storage device interact through a network protocol to synchronize data blocks and confirmation information. The interaction data only includes block ID, version number and hash value, and does not transmit complete data blocks.

[0306] The metadata server's matrix generation module has a built-in prime number sequence library. Cross-fault domain coefficients are selected from this library as coprime prime numbers to ensure the encoding matrix... The linear independence of row vectors.

[0307] In addition, the distributed storage system also includes:

[0308] Storage unit: includes PMem (Storage Tiered Log) and persistent storage medium (storage data blocks, parity blocks);

[0309] Processing unit: Executes the data update logic of the main object storage device or the self-encoded logic of the odd / even object storage device;

[0310] Network unit: Enables communication with other object storage devices and MDS, transmitting data blocks, acknowledgment information, and matrix coefficients.

[0311] PMem's log storage area adopts a partitioned design, independently storing logs that have not been updated and logs that have been encoded. Logs that have not been updated are retained until the encoding is completed, while logs that have been encoded are retained for 10 minutes for consistency verification.

[0312] The processing unit integrates incremental encoding acceleration instructions, performs hardware-level optimizations for the incremental calculation process, and reduces encoding latency.

[0313] When generating the encoding matrix, MDS obtains the fault domain labels (such as rack ID and node ID) of all object storage devices within the PG.

[0314] For each parity object storage device, configure coefficients according to its fault domain relationship with the data block object storage device: the coefficient for the same fault domain is 1, and the coefficient for cross-fault domain is selected from the preset prime number library as coprime prime numbers;

[0315] Generate an encoding matrix of (M×K) dimensions. After verifying the linear independence of the matrix row vectors, the data is synchronized to the relevant OSD and the metadata version is updated.

[0316] The prime number library contains prime numbers up to 1000, and when selecting coefficients, prime numbers that are positively correlated with the distance to the fault domain are preferred (the farther the distance, the larger the prime number), thereby improving the fault tolerance capability for cross-domain faults.

[0317] Furthermore, version control is implemented: each data block and parity block is associated with a globally incrementing version number, and update operations are only allowed to be executed based on the latest version; log recovery: after a node failure and restart, incomplete update operations are reconstructed through PMem logs, and the hash values ​​of local data and log records are compared. If they are inconsistent, data synchronization is requested from the primary object storage device; conflict arbitration: the primary object storage device detects concurrent update conflicts through PG version vectors, only processes requests with the highest version number, and retryes other requests after a 1ms delay. This ensures the consistency of the erasure storage pool.

[0318] In summary, the data processing method for erasure coding (EC) storage pools based on distributed storage systems provided by this invention solves the performance bottleneck problem caused by the reliance on centralized encoding by the primary object storage device and the need for a full "read-modify-encode-write" process for overwrite operations in traditional distributed storage systems. It achieves data update and encoding decoupling by embedding optimization modules into the IO process, employing a "1 master, M slave" hybrid data placement strategy, a two-stage write method (synchronous data from the primary object storage device + autonomous incremental encoding by parity OSD), a fault domain-adaptive dynamic encoding matrix, and a lightweight PMem log mechanism. Simultaneously, it optimizes storage redundancy by combining hot and cold data tiering. This method is compatible with existing architectures, can increase write throughput by 2.5 to 4.2 times, and reduce overwrite operation latency to 10% to 25% of traditional methods. It is suitable for high-concurrency distributed storage scenarios, balancing performance and storage efficiency.

[0319] In the above embodiments, a data processing method for erasure storage pools based on a distributed storage system for parity object storage devices applied in erasure storage pools has been described in detail. The present invention also provides embodiments corresponding to the base data processing device.

[0320] Figure 4 This is a structural diagram of a data processing apparatus provided in an embodiment of the present invention. This embodiment is based on a hardware perspective, such as… Figure 4 As shown, the data processing device includes:

[0321] Memory 20 is used to store computer programs;

[0322] The processor 21 is used to execute computer programs to implement the steps of the erasure storage pool data processing method based on the distributed storage system mentioned in the above embodiments.

[0323] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array. The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0324] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the erasure storage pool data processing method based on a distributed storage system disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the aforementioned erasure storage pool data processing method based on a distributed storage system.

[0325] In some embodiments, the data processing device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0326] Those skilled in the art will understand that Figure 4 The structure shown does not constitute a limitation on the data processing device and may include more or fewer components than illustrated.

[0327] The data processing apparatus provided in this embodiment of the invention includes a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a data processing method for erasure storage pools based on a distributed storage system, with the same effect as above.

[0328] This invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the erasure storage pool data processing method based on a distributed storage system described above.

[0329] Finally, the present invention also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiments (which may be a method applied to the primary object storage device side in an erasure storage pool, a method applied to the parity object storage device side in an erasure storage pool, or a method corresponding to both the primary object storage device side and the parity object storage device side).

[0330] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0331] The computer-readable storage medium provided by this invention includes the erasure storage pool data processing method based on the distributed storage system mentioned above, and has the same effect.

[0332] The erasure propagation storage pool data processing method and system based on a distributed storage system provided by the present invention have been described in detail above. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to the present invention without departing from the principle of the invention, and these improvements and modifications also fall within the protection scope of the present invention.

[0333] It should also be noted that, in this specification, 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. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A data processing method for erasure storage pools based on a distributed storage system, characterized in that, A parity object storage device applied in an erasure storage pool, wherein any data block in the erasure storage pool is stored in both the main object storage device and the parity object storage device; the method includes: Receive a target data block sent by the primary object storage device; wherein, the target data block is obtained by the primary object storage device updating the preset data block stored locally according to the write request sent by the client to represent updating the preset data block; Obtain the difference between the target data block and the original data block corresponding to the target data block stored locally; Obtain the coding coefficients determined based on the fault domain configuration of the placement group, and determine the parity block increment based on the coding coefficients and the difference; Update the locally stored parity blocks using the parity block increment; The primary object storage device synchronizes the target data block to the parity object storage device, including: Based on the metadata of the placement group, locate multiple parity object storage devices of the placement group strip to which the target data block belongs; Obtain the load values ​​of the plurality of parity object storage devices; The target data blocks are synchronized to each parity object storage device in order of load value from low to high. After the primary object storage device synchronizes the target data block to the parity object storage device, it also includes: From the moment the target data block is synchronized to the parity object storage device, a first confirmation message is received from the parity object storage device within a first preset time period; wherein, the first confirmation message includes at least information indicating that the parity object storage device has successfully received the target data block and information indicating that the parity object storage device has stored the target data block in the cache; The second confirmation information sent by the parity object storage device is received; wherein the second confirmation information includes at least one item indicating that the parity object storage device has written the log record of the target data block into the local persistent memory space; The system returns information to the client indicating a successful update and marks the data status of the preset data block as pending encoding.

2. The erasure storage pool data processing method based on a distributed storage system according to claim 1, characterized in that, Before the primary object storage device updates the locally stored preset data block to the target data block, it further includes: The main object storage device records logs and writes them to the persistent memory space in multiple parts using the preset byte atomic write feature of persistent memory; wherein, the log includes at least the unique code of the preset data block, the version number prefix, the old value hash and the new value pointer.

3. The erasure storage pool data processing method based on a distributed storage system according to claim 2, characterized in that, The primary object storage device synchronizes the target data block to the parity object storage device, including: Obtain the access frequency of the target data block; If the target data block is determined to be a hot data block based on the access frequency, the target data block is synchronized to the parity object storage device, and confirmation information is awaited from the parity object storage device. If the target data block is determined to be a cold data block based on the access frequency, multiple operations on the cold data block are accumulated, and the target data block obtained by merging the multiple operations is synchronized to the parity object storage device.

4. The erasure storage pool data processing method based on a distributed storage system according to any one of claims 1 to 3, characterized in that, Before the primary object storage device updates the locally stored preset data block to the target data block, it further includes: Maintain a version vector for each placement group and record the latest version number of each data block; Upon detecting concurrent write requests sent by the client to represent updates to preset data blocks, obtain the version number of the data blocks corresponding to all write requests; determine the highest version number based on all version numbers; and respond to the write request corresponding to the highest version number.

5. The erasure storage pool data processing method based on a distributed storage system according to claim 2, characterized in that, Before obtaining the difference between the target data block and the original data block corresponding to the target data block stored locally, the method further includes: Read local logs to extract the unique code, old value hash, target data block, old version number, and new version number of the target data block; The original data block corresponding to the target data block is located using its unique code, and the location result is obtained. If the value of the new version number is detected to be greater than the value of the old version number, and / or if the location result indicates that the original data block exists locally, proceed to the step of obtaining the difference between the target data block and the original data block corresponding to the target data block stored locally; If the location result indicates that the original data block does not exist locally, a request for hash verification is sent to the primary object storage device. If the hash of the original data block sent by the primary object storage device matches the old value hash in the log, the original data block sent by the primary object storage device is obtained, and the process proceeds to the step of obtaining the difference between the target data block and the original data block corresponding to the target data block stored locally. If they do not match, a prompt message indicating rejection is output.

6. The erasure storage pool data processing method based on a distributed storage system according to claim 2, characterized in that, Determining coding coefficients based on the fault domain configuration of placement groups includes: Obtain the relationship between itself and the fault domains of the data block object storage device; wherein, the fault domain is a rack or node; If the relationship is detected to be within the same fault domain, then the coefficient for the same fault domain is set to 1; If the relationship is detected to be across fault domains, then the cross-fault domain coefficient is set to a coprime coefficient. Generate an encoding matrix based on the values ​​of the same fault domain coefficients and the cross-fault domain coefficients; The coding coefficients are determined based on the elements in the coding matrix.

7. The erasure storage pool data processing method based on a distributed storage system according to claim 6, characterized in that, Determining the coprime coefficients includes: Obtain the fault domain distance value and a pre-created prime number library; Prime numbers that are positively correlated with the fault domain distance value are selected from the prime number library to obtain coprime coefficients.

8. The erasure storage pool data processing method based on a distributed storage system according to claim 6, characterized in that, After generating the encoding matrix based on the values ​​of the same fault domain coefficients and the cross-fault domain coefficients, the method further includes: The fault domain distribution of object storage devices within the placement group is monitored in real time via a metadata server. If a change in the fault domain topology is detected, return to the step of obtaining the relationship between itself and the fault domains of the data block object storage device.

9. The erasure storage pool data processing method based on a distributed storage system according to claim 1, characterized in that, Before updating the locally stored parity blocks using the parity block increment, the following steps are also included: The parity block increment, the original data block, and the target data block are XORed, and the XOR result is obtained. If the XOR calculation result is detected to be equal to an element in the encoding matrix, proceed to the step of updating the locally stored parity block using the parity block increment; If the XOR calculation result is not equal to an element in the encoding matrix, return to the step of receiving the target data block sent by the master object storage device.

10. The erasure storage pool data processing method based on a distributed storage system according to claim 5, characterized in that, Updating the locally stored parity blocks using the parity block increment includes: Write the updated parity block to the new storage address; After a successful write is detected, the metadata pointer is updated to point to the new address through an atomic write operation in the persistent memory space.

11. The erasure storage pool data processing method based on a distributed storage system according to claim 10, characterized in that, After updating the parity blocks in the local storage using the parity block increment, the process also includes: The version number of the target data block is updated to obtain a new version number; Generate an encoding completion log; wherein the encoding completion log includes at least the unique encoding of the target data block, the hash value of the new parity block obtained after the update, and the new version number.

12. The erasure storage pool data processing method based on a distributed storage system according to claim 11, characterized in that, The persistent memory space includes a region for storing logs that have not yet been updated and a region for storing logs that have been encoded. Specifically, the incomplete logs stored in the area for storing logs that have not been updated are retained until the encoding is completed; the encoded logs stored in the area for storing encoded logs are retained for a second preset duration.

13. The erasure storage pool data processing method based on a distributed storage system according to claim 12, characterized in that, After updating the parity blocks in the local storage using the parity block increment, the process also includes: Once the encoding is complete, delete the original data block and log stored locally; Release the storage space occupied by the original data blocks and logs locally.

14. The erasure storage pool data processing method based on a distributed storage system according to claim 1, characterized in that, After updating the parity blocks in the local storage using the parity block increment, the process also includes: Send information indicating the completion of encoding to the master object storage device; wherein the information indicating the completion of encoding includes the hash value of the new parity block; so that the master object storage device can change the data state from the pending encoding state to the completed state and synchronize the data state to the metadata server.

15. A data processing method for erasure storage pools based on a distributed storage system, characterized in that, A primary object storage device is used in an erasure storage pool, wherein any data block in the erasure storage pool is stored in both the primary object storage device and the parity object storage device; the method includes: Get the write request sent by the client that represents the update of the preset data block; The target data block is obtained by updating the preset data block stored locally according to the write request; The target data block is synchronized to the parity object storage device so that the parity object storage device can obtain the difference between the target data block and the original data block corresponding to the target data block stored locally; the coding coefficients determined based on the fault domain configuration of the placement group are obtained, and the parity block increment is determined according to the coding coefficients and the difference; the parity block in the local storage is updated using the parity block increment; The primary object storage device synchronizes the target data block to the parity object storage device, including: Based on the metadata of the placement group, locate multiple parity object storage devices of the placement group strip to which the target data block belongs; Obtain the load values ​​of the plurality of parity object storage devices; The target data blocks are synchronized to each parity object storage device in order of load value from low to high. After the primary object storage device synchronizes the target data block to the parity object storage device, it also includes: From the moment the target data block is synchronized to the parity object storage device, a first confirmation message is received from the parity object storage device within a first preset time period; wherein, the first confirmation message includes at least information indicating that the parity object storage device has successfully received the target data block and information indicating that the parity object storage device has stored the target data block in the cache; The second confirmation information sent by the parity object storage device is received; wherein the second confirmation information includes at least one item indicating that the parity object storage device has written the log record of the target data block into the local persistent memory space; The system returns information to the client indicating a successful update and marks the data status of the preset data block as pending encoding.

16. A distributed storage system, characterized in that, It includes a primary object storage device, a parity object storage device, and a metadata server; wherein, the primary object storage device is used to obtain a write request sent by a client to represent updating a preset data block; update the preset data block stored locally according to the write request to obtain a target data block; and synchronize the target data block to the parity object storage device; The metadata server is used to determine coding coefficients based on the fault domain configuration of the placement group; The parity object storage device is used to receive a target data block sent by the main object storage device; obtain the difference between the target data block and the original data block corresponding to the target data block in local storage; obtain the coding coefficient determined based on the fault domain configuration of the placement group, and determine the parity block increment according to the coding coefficient and the difference; and update the parity block in local storage using the parity block increment. The primary object storage device synchronizes the target data block to the parity object storage device, including: Based on the metadata of the placement group, locate multiple parity object storage devices of the placement group strip to which the target data block belongs; Obtain the load values ​​of the plurality of parity object storage devices; The target data blocks are synchronized to each parity object storage device in order of load value from low to high. After the primary object storage device synchronizes the target data block to the parity object storage device, it also includes: From the moment the target data block is synchronized to the parity object storage device, a first confirmation message is received from the parity object storage device within a first preset time period; wherein, the first confirmation message includes at least information indicating that the parity object storage device has successfully received the target data block and information indicating that the parity object storage device has stored the target data block in the cache; The second confirmation information sent by the parity object storage device is received; wherein the second confirmation information includes at least one item indicating that the parity object storage device has written the log record of the target data block into the local persistent memory space; The system returns information to the client indicating a successful update and marks the data status of the preset data block as pending encoding.

17. A data processing apparatus, characterized in that, include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the steps of the erasure storage pool data processing method based on a distributed storage system as described in any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the erasure storage pool data processing method based on a distributed storage system as described in any one of claims 1 to 15.

Images