DISTRIBUTED STORAGE SYSTEM, DATA PROCESSING METHODS AND STORAGE NODES

Description

TECHNICAL FIELD

[0001] This application relates to the field of distributed technologies, and in particular, to a distributed storage system, a data processing method, and a storage node.BACKGROUND

[0002] A distributed storage system such as Ceph, Cloud object storage system is a storage system in which data is dispersedly stored in a plurality of independent computer storage devices (namely, storage nodes). The distributed storage system includes at least one storage node, and a client and one or more object storage device (OSD) modules are deployed on the at least one storage node. Each OSD module may be deployed on one storage node, and the client may be deployed on any storage node. FIG. 1 is a schematic architectural diagram of a distributed storage system. The distributed storage system shown in FIG. 1 includes storage nodes 0, 1, 2, and 3. The distributed storage system includes a client and OSD modules 1 to 4. The client is deployed on the storage node 0, the OSD module 1 is deployed on the storage node 1, the OSD module 2 is deployed on the storage node 2, and the OSD modules 3 and 4 are deployed on the storage node 3.

[0003] A basic idea of data management in a conventional distributed storage system is as follows: A fixed quantity of partitions are set in the distributed storage system. A client evenly allocates all pieces of received data of input / output (IO) operations to the partitions. There is a relatively fixed mapping relationship between each partition and one OSD module. In other words, there is a mapping relationship between each partition and one specific OSD module within a specific time. Data of IO operations that belong to a same partition is stored in a storage node in which an OSD module that has a mapping relationship with the partition is located.

[0004] In the conventional distributed storage system, a hard disk drive (HDD) is used as a main storage medium, and an amount of metadata generated in a data storage process is relatively small. Therefore, it is relatively easy to manage data and metadata. Generally, data and metadata of one IO operation are managed by one OSD module. With development of storage technologies, for example, with diversification of storage media and / or increasing of metadata generated in a data storage process, the current distributed storage system cannot meet an overall performance requirement of the distributed storage system.

[0005] US 2006 / 0129614 relates to a crash recovery system and method for distributed file server using object based storage.SUMMARY

[0006] Implementations of this application provide a distributed storage system and a data processing method, to help improve overall performance of the distributed storage system.

[0007] The invention has been defined in the independent claims. Further specific technical features have been defined in the dependent claims.BRIEF DESCRIPTION OF DRAWINGS

[0008] FIG. 1 is a schematic architectural diagram of a distributed storage system according to the prior art; FIG. 2 is a schematic architectural diagram 1 of a distributed storage system according to an implementation of this application; FIG. 3 is a schematic structural diagram of a storage node according to an implementation of this application; FIG. 4 is a schematic architectural diagram 2 of a distributed storage system according to an implementation of this application; FIG. 5 is a schematic diagram of a data processing module corresponding to a partition according to an implementation of this application; FIG. 6 is a schematic diagram of setting data protection for metadata according to an implementation of this application; FIG. 7 is a schematic architectural diagram 3 of a distributed storage system according to an implementation of this application; FIG. 8A and FIG. 8B are schematic flowcharts 1 of a data processing method according to an implementation of this application; FIG. 9A and FIG. 9B are schematic flowcharts 2 of a data processing method according to an implementation of this application; FIG. 10 is a schematic structural diagram 1 of a data processing apparatus according to an implementation of this application; FIG. 11 is a schematic structural diagram 2 of a data processing apparatus according to an implementation of this application; and FIG. 12 is a schematic structural diagram 3 of a data processing apparatus according to an implementation of this application. DESCRIPTION OF IMPLEMENTATIONS

[0009] To make the objectives, technical solutions, and advantages of this invention clearer, the following further describes various implementations in detail with reference to the accompanying drawings. The implementations described below are not all claimed, they are included to help understanding the context of the invention. While the description refers to various implementations, the embodiments of the invention are those which comprise at least all the features of an independent claim. Any implementation which does not fall within the scope of the claims does not form part of the invention, but rather included as an illustrative example that is useful for understanding the invention.

[0010] In descriptions of this application, " / " means "or" unless otherwise specified. For example, A / B may represent A or B. In this specification, "and / or" describes only an association relationship for describing associated objects and represents that three relationships may exist. For example, A and / or B may represent the following three cases: Only A exists, both A and B exist, and only B exists. In addition, in description of this application, the term "a plurality of" means two or more than two unless otherwise specified. In addition, to clearly describe the technical solutions in the implementations of this application, terms such as "first" and "second" are used in the implementations of this application to distinguish between same items or similar items that have basically the same functions or purposes. A person skilled in the art may understand that the terms, such as "first" and "second", are not intended to limit a quantity or an execution sequence; and the terms, such as "first" and "second", do not indicate a definite difference.

[0011] With development of storage technologies, for example, with diversification of storage media and development of data storage manners, a conventional distributed storage system cannot meet an overall system performance requirement. For example, in the distributed storage system, there may be a scenario in which some storage media are HDDs and some storage media are solid-state drives (SSD). In this scenario, data and metadata are managed based on the conventional distributed storage system. If both metadata that requires low delay access and large volume data that requires high bandwidth access are stored in the HDD, access performance of the metadata is affected. Alternatively, if the metadata and the large volume data are stored in the SSD, a storage cost of the large volume data increases. For another example, to ensure data reliability, data storage manners such as an erasure coding (EC) strip storage manner and a multi-copy storage manner are proposed in the industry, and therefore an amount of metadata generated in a data storage process is relatively large, and the metadata accounts for a very large proportion of a total amount of data. In this case, if the metadata is stored based on the conventional distributed storage system, system performance cannot be significantly improved.

[0012] Based on this, this application provides a distributed storage system, a data processing method, and a storage node. Basic principles thereof are as follows: Modules (such as a management module, a data processing module, and a metadata processing module) that have different functions are deployed on an OSD module, so that data and metadata of an IO operation can be separately deployed and managed. This helps improve overall system performance. The OSD module may be considered as an OSD process. The management module, the data processing module, and the metadata processing module may be all considered as threads that have different functions.

[0013] The following describes technical solutions provided in this application with reference to the accompanying drawings by using examples.

[0014] FIG. 2 is a schematic architectural diagram of a distributed storage system according to an implementation of this application. In FIG. 2, the distributed storage system may include a switch 21 and at least one storage node 22. Storage nodes 22 are connected to each other by using the switch 21. For example, the switch 21 may be but is not limited to an ethernet switch, an IB switch (infiniband switch), or a PCIe switch. It may be understood that the distributed storage system shown in FIG. 2 is merely an example. During actual implementation, a plurality of storage nodes may also directly communicate with each other, or may communicate with each other by using another device. This is not limited in this application.

[0015] The storage node 22 is a core component that is in the distributed storage system and that provides an IO processing capability and storage space.

[0016] Optionally, the storage node 22 may include a communications interface 220, an execution module 221, and one or more storage modules 222 connected to the execution module 221. The communications interface 220 may be connected to the execution module 221 by using a communication line, and the execution module 221 may also be connected to the storage module 222 by using a communication line. The communication line may include a channel for information transmission between the foregoing components. The communication line may also be referred to as an IO bus, and may be specifically, for example, but is not limited to a quick peripheral component interconnect express (PCIe).

[0017] The communications interface 220 may be any apparatus such as a transceiver, and is configured to communicate with another device or a communications network (such as Ethernet or a wireless local area network (WLAN)).

[0018] The execution module 221 is responsible for inputting and outputting an IO operation (including a read / write operation) and executing a related processing procedure. The execution module 221 may include at least one processor. The at least one processor may be further connected to a specific quantity of memories.

[0019] The processor may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to control execution of a program in the solutions of this application. The communications interface 220 may be connected to the processor by using a communication line. It should be noted that, during physical implementation, the processor, the communication line, and all or a part of the communications interface herein may be integrated together, or certainly may be disposed separately. This is not limited in this application. The memory may be configured to store a computer program for executing the solutions of this application, and execution of the computer program is controlled by the processor. The processor is configured to execute the computer program stored in the memory, to implement a method provided in the following implementations of this application. Optionally, the computer program in the implementations of this application may also be referred to as application program code, a computer executable instruction, or the like. This is not specifically limited in the implementations of this application.

[0020] The storage module 222 may include at least one storage controller, and a plurality of storage chips connected to each storage controller. The storage chip may be a NandFlash chip, or may be another non-volatile storage chip such as a phase change memory (PCM), a magnetic random access memory (MRAM), or a resistive random access memory (RRAM). The storage controller may be an application-specific integrated circuit (ASIC) chip, or may be an FPGA. A physical form of the storage module 222 herein may be an SSD, or may be an HDD. During actual implementation, all storage modules 222 in one storage node 22 may be SSDs, or may be HDDs. Alternatively, some of the storage modules 222 may be SSDs, and the other storage modules 222 may be HDDs. This is not limited in this application.

[0021] Optionally, the distributed storage system may further include a client (which may also be referred to as a client process) 10 and one or more OSD modules 20. Each of the one or more OSD modules 20 may include at least one of the following modules: one or more management modules (which may also be referred to as one or more management processing modules) 201, at least one data processing module 202 that has a mapping relationship with each management module 201, and at least one metadata processing module 203 that has a mapping relationship with the at least one data processing module 202. Each processing module (including the management module 201, the data processing module 202, and the metadata processing module 203) may be included in one OSD module 20. Different processing modules may be included in a same OSD module 20, or may be included in different OSD modules 20.

[0022] It should be noted that, in this application, that the OSD module 20 includes (or has) a specific processing module (for example, the management module 201, the data processing module 202, or the metadata processing module 203) is equivalent to that the processing module is deployed on the OSD module 20. A unified description is provided herein. Details are not described below.

[0023] Some or all of the client 10, the management module 201, the data processing module 202, and the metadata processing module 203 may be stored in a memory (for example, the memory in FIG. 2) in a form of a computer program. A processor (for example, the CPU in FIG. 2) may invoke the computer program to implement a function implemented by at least one of the client 10, the management module 201, the data processing module 202, and the metadata processing module 203. A schematic diagram thereof is shown in FIG. 3.

[0024] In a specific implementation process, each OSD module 20 may be deployed on one storage node 22, and different OSD modules 20 may be deployed on a same storage node 22, or may be deployed on different storage nodes 22. The client 10 and any OSD module 20 may be deployed on a same storage node 22, or may be separately deployed on a storage node 22. FIG. 4 is a schematic architectural diagram of another distributed storage system according to an implementation of this application. For brevity, FIG. 4 does not show a communications interface, a processor, a communication line, a storage module, and the like in a storage node 22. A double-headed arrow in FIG. 4 indicates that there is a mapping relationship between a data processing module 202 and a metadata processing module 203.

[0025] In some implementations of this application, there is a mapping relationship between each data processing module 202 and one metadata processing module 203. In other words, the data processing module 202 is in a one-to-one correspondence with the metadata processing module 203.

[0026] In some implementations of this application, at least two partitions may be set in the distributed storage system. The partition is a set including an IO operation. Each partition may have a mapping relationship with the following processing modules: a management module 201, at least one data processing module 202 that has a mapping relationship with the management module 201, and a metadata processing module 203 that has a mapping relationship with each data processing module 202, as shown in FIG. 4. A dashed-line box in FIG. 4 indicates modules (including the management module 201, the data processing module 202, and the metadata processing module 203) corresponding to one partition.

[0027] Based on FIG. 4, the client 10 may be configured to receive an IO operation and attribute the IO operation to one of the at least two partitions. Then, the IO operation is sent to a management module 201 that has a mapping relationship with the partition. The management module 201 may be configured to manage data protection information of the IO operation that belongs to the partition. The data protection information is related to a data storage manner. For example, if the data storage manner is an EC strip storage manner, the data protection information may be specifically EC strip information. In this case, the management module 201 may be specifically configured to manage EC strip information generated based on data of the IO operation that belongs to the partition. The EC strip information may include, for example, but is not limited to, a specific data block and a specific parity block that are used to establish an EC strip, and the like. For another example, if the data storage manner is a multi-copy storage manner, the data protection information may be specifically multi-copy information. In this case, the management module 201 may be specifically configured to manage multi-copy information generated based on data of the IO operation that belongs to the partition. The multi-copy information may include, for example, but is not limited to, a specific data block that is used as a duplicate data block of a data block, and the like. A data storage manner is not limited in this application.

[0028] Each data processing module 202 that has a mapping relationship with the management module 201 is configured to manage data of an IO operation that belongs to one partition and that is allocated to the data processing module 202. Optionally, the client 10 or the management module 201 may allocate one IO operation to a data processing module 202.

[0029] A metadata processing module 203 that has a mapping relationship with each data processing module 202 is configured to manage metadata of the IO operation that belongs to the partition and that is allocated to the data processing module 202. Optionally, the client 10, the management module 201, or the data processing module 202 may allocate one IO operation to a metadata processing module 203.

[0030] In this application, an IO operation may be a write operation or a read operation. The write operation may carry a to-be-written logical block address (LBA) and to-be-written data, which are used to write the to-be-written data into physical storage space corresponding to the to-be-written LBA. The read operation may carry the to-be-read LBA, which is used to read data (namely, to-be-read data) stored in physical storage space corresponding to the to-be-read LBA. If the IO operation is the write operation, data of the IO operation is to-be-written data carried in the IO operation. If the IO operation is the read operation, data of the IO operation is data to be read by the IO operation (namely, to-be-read data). The metadata of the IO operation is metadata generated in a process of writing the data of the IO operation. Metadata is data about data that describes the IO operation, which is mainly information that describes property of data, and may be used to support functions such as storage location indication, historical data, resource searching, and file recording.

[0031] It may be understood that the distributed storage system shown in FIG. 4 is merely an example, and does not constitute a limitation on the distributed storage system provided in this application. For example, the distributed storage system may include one or more clients 10, and each client 10 may communicate with any OSD module 20. For example, each partition may have a mapping relationship with one or more management modules 201.

[0032] In some implementations of this application, a quantity of data processing modules 202 that have a mapping relationship with one partition is related to a data storage manner of the distributed storage system. A manner of storing data of the IO operation may be the EC strip storage manner or the multi-copying storage manner, or the like. For example, if the data of the IO operation is stored in the EC strip storage manner, the quantity of data processing modules 202 that have the mapping relationship with one partition may be a quantity of data blocks and parity blocks included in an EC strip. For example, assuming that one EC strip includes three data blocks and two parity blocks, the quantity of data processing modules 202 that have the mapping relationship with one partition may be five. For example, if the data of the IO operation is stored in the multi-copy storage manner, the quantity of data processing modules 202 that have the mapping relationship with one partition may be a quantity of data blocks and copy data blocks that have a multi-copy relationship. For example, if a data block that has the multi-copy relationship has three duplicate data blocks, the quantity of data processing modules 202 that have the mapping relationship with one partition may be four.

[0033] It may be understood that, to ensure data reliability, in the EC strip storage manner or the multi-copy storage manner, the data processing modules 202 that have the mapping relationship with one partition are deployed on OSD modules 20 of different storage nodes. For example, in FIG. 4, a plurality of data processing modules 202 that have a mapping relationship with a same partition are deployed on OSD modules 20 of different storage nodes. In this way, when a storage node is faulty, data of an IO operation stored in the faulty storage node may be recovered by using data of an IO operation stored in another storage node, thereby helping improve the data reliability. In an example in which the data of the IO operation is stored in the EC strip storage manner, a data processing module 202 that has a mapping relationship with one partition may be specifically a data processing module configured to manage a data block or a data processing module configured to manage a parity block. The data block is a basic unit for storing data by the storage node. The parity block is parity data obtained after the management module 201 checks data blocks belonging to a same EC strip. If the quantity of data processing modules 202 that have the mapping relationship with one partition is a quantity of data blocks and parity blocks included in an EC strip, the EC strip may include: as shown in FIG. 5, one data block managed by each data processing module configured to manage a data block in the partition and one parity block managed by each data processing module configured to manage a parity block. In FIG. 5, an example in which data processing modules 202 that have a mapping relationship with one partition is marked as the data processing modules 1 to 5, the data processing modules 1 to 3 are data processing modules configured to manage a data block, and the data processing modules 4 to 5 are data processing modules configured to manage a parity block is used for description. Each data processing module 202 is configured to manage one column of an EC strip, and each column includes a plurality of data blocks / parity blocks. In FIG. 5, an example in which each column includes four data blocks / parity blocks is used for description. A small box in each data processing module represents a data block or a parity block belonging to the data processing module. In FIG. 5, a small box in each data processing module configured to manage a data block represents a data block, and a small box in each data processing module configured to manage a parity block represents a parity block. In FIG. 5, data blocks and parity blocks included in a dashed line box establish one EC strip. Similar to this, it may be obtained that in a case in which the data of the IO operation is stored in the multi-copy storage manner, a correspondence between a data block and a duplicate data block that have a multi-copy relationship and a data processing module may be obtained. Details are not described herein again.

[0034] In the foregoing technical solution, reliability protection of data of an IO operation is described. In some implementations of this application, reliability protection may be further performed on metadata of an IO operation. Specifically, one metadata processing module 203 may distribute, to a plurality of storage nodes for storage, metadata managed by the metadata processing module 203. A storage manner of the metadata of the IO operation may be, for example, but is not limited to, an EC strip storage manner or a multi-copying storage manner. FIG. 6 is an implementation of setting data protection for metadata. In FIG. 6, a metadata processing module 203 is deployed on the storage node 1, and manages metadata MD 1 to 4. The MD 1 is stored locally, that is, a storage node 1, the MD 2 is stored in a storage node 2, the MD 3 is stored in a storage node 3, and the MD 4 is stored in a storage node 4. A relationship between MD 1 to 4 may be that one EC strip is jointly established, or may be a multi-copy relationship. Similar to this, in some implementations of this application, a management module 201 may also perform reliability protection on data (for example, data protection information of an IO operation) managed by the management module 201. Details are not described herein again.

[0035] In some implementations of this application, as shown in FIG. 7, a distributed storage system may further include a control module 30. The control module 30 may be deployed on any storage node. In FIG. 6, an example in which the control module 30 is separately deployed on one storage node, in other words, the control module 30 and a client 10 and / or each OSD module 20 are not deployed on a same storage node is used for description. The control module 30 is configured to: manage heartbeats of the client 10 and each OSD module 20; and manage a partition and a processing module (including a management module 201, a data processing module 202, and a metadata processing module 203) in the distributed storage system, and the like. That the control module 30 manages the heartbeat of the client 10 or each OSD module 20 may be understood as: The control module 30 detects, by sending a heartbeat message to the client 10 or each OSD module, whether the client 10 or each OSD module is faulty. That the control module 30 manages the partition and the processing module in the distributed storage system may include, for example, but is not limited to the following: The control module 30 manages a total quantity of partitions, a quantity of management modules 201, a quantity of data processing modules 202, and a quantity of metadata processing modules 203 that have a mapping relationship with each partition, a mapping relationship between processing modules, a mapping relationship between a partition and each processing module, a mapping relationship between each processing module and an OSD module 20 in which each processing module is located, a mapping relationship between the OSD module 20 and a storage node in which the OSD module 20 is located, and the like. In addition, in an implementation of performing data protection on metadata, the control module 30 may be further configured to manage a mapping relationship between each column in an EC strip and a storage node. In addition, the control module 30 may be further configured to: synchronize updated information to the client 10 and the OSD module 20 after the foregoing information is updated; and synchronize the foregoing information to the client 10 and / or the OSD module 20 after the client 10 is started and / or the OSD module 20 is started, and the like.

[0036] Generally, before an IO operation is performed, a distributed storage system needs to be constructed first. Specifically, the client 10, the OSD module 20, and the control module 30 are deployed on a storage node of the distributed storage system based on the configuration file, and one or more processing modules of each management module 201, the data processing module 202, and the metadata processing module 203 are deployed on the OSD module 20. The configuration file may be used to record: a total quantity of partitions in the distributed storage system, a quantity of management modules 201, a quantity of data processing modules 202, and a quantity of metadata processing modules 203 that have a mapping relationship with each partition, an allocation algorithm, and the like. The allocation algorithm may be used by the control module 30 to establish at least one of the following mapping relationships: a mapping relationship between each processing module and an OSD module 20 in which the processing module is located, a mapping relationship between each OSD module 20 and a storage node in which the OSD module is located, and a mapping relationship between a metadata processing module 203 and a storage node in which metadata managed by the metadata processing module 203 is located, a mapping relationship between a management module 201 and a storage node in which data managed by the management module 201 is located, and the like. The allocation algorithm may be, for example, but is not limited to, an allocation algorithm determined based on factors such as a type of a storage medium, an available capacity of a storage node, and load balancing between storage nodes. For example, the control module 30 may deploy the data processing module 202 in an HDD based on the allocation algorithm, to reduce storage costs of large volume data, and deploy the metadata processing module 203 in an SSD, to reduce an access delay of metadata, and further help improve overall performance of a system. For example, the control module 30 may deploy a same quantity of OSD modules 20 / processing modules in each storage node as far as possible based on the allocation algorithm, to help improve the overall performance of the system, and the like.

[0037] Optionally, any process / thread in the foregoing processes / threads (for example, the client 10, the OSD module 20, the management module 201, the data processing module 202, the metadata processing module 203, and the control module 30) may be implemented by one device, or may be jointly implemented by a plurality of devices, or may be a function module in one device. This is not specifically limited in this implementation of this application. It may be understood that the foregoing functions may be network elements in a hardware device, or may be software functions run on dedicated hardware, or may be instantiated virtualization functions on a platform (for example, a cloud platform). In an example, a schematic structural diagram of a device for implementing any one of the foregoing processes / threads may be the storage node shown in FIG. 2.

[0038] The following describes the data processing method provided in this application with reference to FIG. 2 to FIG. 7.

[0039] FIG. 8A and FIG. 8B are schematic interaction diagrams of a data processing method according to an implementation of this application. Specifically, an example in which an IO operation is a write operation is used for description. The method shown in FIG. 8A and FIG. 8B may include the following steps.

[0040] S101. A client receives a write operation, deploys the write operation in one of at least two partitions, and determines a management module that has a mapping relationship with the partition and an identifier of a third OSD module in which the management module is located. The write operation carries to-be-written LBA, to-be-written data, and the like.

[0041] The client may be any client deployed in the distributed storage system. The write operation may be any write operation received by the client. A user may send a write operation to the client when having a data writing requirement. Certainly, this application is not limited thereto. After receiving the write operation, the client may convert the write operation into a key-value pair based on some attributes of data of the write operation, for example, LBA, an offset, a snapshot number, or an object name, deploys the write operation in a partition of the distributed storage system by using a hash algorithm or another key-value homing algorithm, and determine, based on a mapping relationship between each management module and an OSD module in which each management module is located, an identifier of an OSD module (namely, the third OSD module) in which a management module that has a mapping relationship with the write operation is located. The identifier of the OSD module may be, for example, but is not limited to a process number of the OSD module.

[0042] S102. The client sends the write operation to the management module based on the identifier of the third OSD module. Specifically, the client sends the write operation to the management module deployed on the third OSD module.

[0043] S103. The management module determines, based on the write operation, a target data processing module and an identifier of a second OSD module in which the target data processing module is located. The second OSD module and the third OSD module may be a same OSD module, or may be different OSD modules. The target data processing module is a data processing module allocated by the distributed storage system to the write operation, and may be specifically a data processing module allocated by the client or the management module in the distributed storage system to the write operation. It is assumed that the target data processing module is a data processing module allocated by the client to the write operation. Specifically, after the client deploys the write operation in one of the partitions in S101, the client may allocate a data processing module to the write operation based on a specific homing algorithm such as the hash algorithm or the another key-value homing algorithm, use the allocated data processing module as the target data processing module, and send, based on the identifier of the third OSD module, an identifier of the target data processing module to the management module deployed on the third OSD module. In this case, that the management module determines a target data processing module in S103 may include: The management module receives the identifier of the target data processing module that is sent by the client.

[0044] It is assumed that the target data processing module is a data processing module allocated by the management module to the write operation. Specifically, after the management module receives the write operation sent by the client, the management module may allocate a data processing module to the write operation based on a homing algorithm such as the hash algorithm or the another key-value homing algorithm, and use the allocated data processing module as the target data processing module. Regardless of whether the target data processing module is the data processing module allocated by the client or the management module to the write operation, in an implementation, that the management module determines an identifier of a second OSD module in which the target data processing module is located may include: The management module determines, based on a mapping relationship between a data processing module and an OSD module in which the data processing module is located, an identifier of an OSD module (namely, the second OSD module) in which the target data processing module is located. In addition, if the target data processing module is the data processing module allocated by the client to the write operation, in another implementation, after determining the target data processing module, the client may determine the identifier of the second OSD module in which the target data processing module is located, and send the identifier of the second OSD module to the management module deployed on the third OSD module. In this case, that the management module determines an identifier of a second OSD module in which the target data processing module is located may include: The management module receives the identifier of the second OSD module that is sent by the client.

[0045] In an example, if the data of the write operation is stored in an EC strip storage manner, after receiving the write operation, the management module may calculate parity data based on the data of the write operation and data of another write operation to establish an EC strip, determine a target data processing module for each data block and each parity block in the EC strip, and write each data block and each parity block into a storage node in S104 to S108. Alternatively, S104 to S108 may be first performed to write the data of the write operation into a storage node. Then, when another write operation is received, parity data is calculated based on the data of the write operation and data of the another write operation to establish the EC strip. Then, a data block corresponding to the another write operation and a parity block corresponding to the parity data are separately written into the storage node in S104 to S108. Certainly, this application is not limited thereto. A specific write operation whose data is used to establish an EC strip and how to calculate a parity block in the EC strip are described in detail in the prior art. Details are not described herein.

[0046] In an example, if the data of the write operation is stored in a multi-copy storage manner, after receiving a write operation, the management module may obtain a plurality of pieces of data by copying the data of the write operation, determine a target data processing module for each data block and each duplicate data block, and write each data block and each duplicate data block into a storage node in S104 to S108.

[0047] It should be noted that data of an IO operation (including a write operation or a read operation) may include at least one data block. Generally, if data of an IO operation includes a plurality of data blocks, the distributed storage system usually divides the IO operation into several sub-IO operations before performing the IO operation. Data of each sub-IO operation is one data block. For ease of description an example in which the data of the IO operation is one data block is used for description in this application, or an example in which the IO operation is the sub-IO operation is used for description in a specific example of this application, which can be applied to both determining of the target data processing module for the data block and determining of the target data processing module for the IO operation.

[0048] S104. The management module sends the write operation to the target data processing module based on the identifier of the second OSD module. Specifically, the management module sends the write operation to the target data processing module deployed on the second OSD module.

[0049] S105. The target data processing module writes to-be-written data into physical storage space corresponding to the to-be-written LBA. Metadata is generated in a data writing process.

[0050] S106. The target data processing module determines, based on the write operation, a target metadata processing module and an identifier of a first OSD module in which the target metadata processing module is located. The first OSD module and the third OSD module may be a same OSD module, or may be different OSD modules. The first OSD module and the second OSD module may be a same OSD module, or may be different OSD modules. The target metadata processing module is a metadata processing module allocated by the distributed storage system to the write operation, and may be specifically a metadata processing module allocated by the client, the management module, or the target data processing module in the distributed storage system to the write operation.

[0051] It is assumed that the target metadata processing module is a metadata processing module allocated by the client to the write operation. Specifically, after determining the target data processing module, the client may determine, based on a mapping relationship between the data processing module and the metadata processing module, a target metadata processing module that has a mapping relationship with the target data processing module, and send, based on the identifier of the second OSD module, an identifier of the target metadata processing module to the management module deployed on the third OSD module. The management module sends the identifier of the target metadata processing module to the target data processing module deployed on the second OSD module. In this case, that the target data processing module determines the target metadata processing module may include: The target data processing module receives the target metadata processing module sent by the client.

[0052] It is assumed that the target metadata processing module is a metadata processing module allocated by the management module to the write operation. Specifically, after determining the target data processing module in S103, the management module may determine, based on a mapping relationship between the data processing module and the metadata processing module, a target metadata processing module that has a mapping relationship with the target data processing module, and send, based on the identifier of the second OSD module, an identifier of the target metadata processing module to the target data processing module deployed on the second OSD module. In this case, that the target data processing module determines the target metadata processing module may include: The target data processing module receives the target metadata processing module sent by the management module.

[0053] It is assumed that the target metadata processing module is a metadata processing module allocated by the target data processing module to the write operation. Specifically, after receiving the write operation, the target data processing module may determine, based on a mapping relationship between the data processing module and the metadata processing module, a metadata processing module that has a mapping relationship with the target data processing module, and use the metadata processing module as the target metadata processing module.

[0054] Regardless of whether the target metadata processing module is the metadata processing module allocated by the client, the management module, or the target data processing module to the write operation, in an implementation, that the target data processing module determines an identifier of a first OSD module in which the target metadata processing module is located may include: The target data processing module determines, based on a mapping relationship between the metadata processing module and an OSD module, an identifier of an OSD module (namely, the first OSD module) in which the target metadata processing module is located. In addition, if the target metadata processing module is the metadata processing module allocated by the client to the write operation, in another implementation, that the target data processing module determines an identifier of a first OSD module in which the target metadata processing module is located may include: The target data processing module receives the identifier of the first OSD module that is sent by the client. Moreover, if the target metadata processing module is the metadata processing module allocated by the management module to the write operation, in still another implementation, that the target data processing module determines the identifier of the first OSD module in which the target metadata processing module is located may include: The target data processing module receives the identifier of the first OSD module that is sent by the management module.

[0055] A sequence of performing S105 and S106 is not limited in this application. For example, S105 may be performed before S106, or S106 may be performed before S105, or S106 and S105 may be performed at the same time.

[0056] S107. The target data processing module sends an access operation to the target metadata processing module based on the identifier of the first OSD module. Specifically, the management module sends the access operation to the target metadata processing module deployed on the first OSD module. The access operation is specifically a write access operation, and the write access operation carries metadata of the write operation and the to-be-written LBA of the write operation.

[0057] S108. The target metadata processing module writes the metadata of the write operation into the storage node based on the write access operation.

[0058] In an implementation, if data protection is not performed on metadata of the IO operation, the target metadata processing module may locally write the metadata of the write operation, in other words, write the metadata of the write operation into a storage node in which the target metadata processing module is located. Specifically, the metadata of the write operation may be locally written based on the to-be-written LBA. In another implementation, if data protection is performed on metadata of the IO operation, for example, the metadata of the write operation is stored in an EC storage manner or a multi-copy storage manner, the target metadata processing module may determine, based on the to-be-written LBA, a storage node in which the metadata of the write operation is located. For example, referring to FIG. 6, the metadata of the write operation may be considered as any metadata in the MD 1 to the MD 4 in FIG. 6.

[0059] The data processing method provided in this implementation may be applied to the distributed storage system shown in FIG. 2, FIG. 4, or FIG. 6. Specifically, a method for performing a write operation is provided based on the distributed storage system. In this implementation, the data and the metadata of the write operation are respectively managed by the corresponding data processing module and the corresponding metadata processing module. In this way, compared with a technical solution in the prior art in which data and metadata are managed together, the distributed storage system can separately manage the data and the metadata, so as to help improve management performance, and improve overall system performance. The method may be applied to a scenario in which amounts of data and metadata are relatively large. In addition, the data processing module and the metadata processing module are properly deployed, for example, the data processing module is deployed on an HDD and the metadata processing module is deployed on an SSD, so as to help improve the overall system performance.

[0060] FIG. 9A and FIG. 9B are schematic interaction diagrams of a data processing method according to an implementation of this application. Specifically, an example in which an IO operation is a read operation is used for description. The method shown in FIG. 9A and FIG. 9B may include the following steps.

[0061] S201. A client receives a read operation, deploys the read operation in one of at least two partitions, deploys the read operation in a target data processing module, and determines an identifier of a second OSD module in which the target data processing module is located. The read operation carries a to-be-read LBA and the like, which are used to read to-be-read data stored in physical storage space corresponding to the to-be-read LBA.

[0062] The client may be any client deployed in the distributed storage system. The read operation may be any read operation received by the client. A user may send a read operation to the client when having a data reading requirement. Certainly, this application is not limited thereto. It should be noted that, for explanations of related content in this implementation, refer to the foregoing descriptions. Details are not described herein again. For example, for a case in which the read operation is deployed in one of partitions, the read operation is deployed on the target data processing module, and the identifier of the second OSD module in which the target data processing module is located is determined, refer to related descriptions of the write operation in S101.

[0063] It can be understood that, when this implementation and the implementation shown in FIG. 8A and FIG. 8B are applied to a same distributed storage system, and if the to-be-read LBA carried in the read operation is the same as the to-be-written LBA carried in the write operation in the implementation shown in FIG. 8A and FIG. 8B, the to-be-read data described in this implementation and the to-be-written data described in the implementation shown in FIG. 8A and FIG. 8B are the same. One of the partitions and the second OSD module are determined in this implementation, and a target data processing module, a target metadata processing module, a management module, a first OSD module, a third OSD module, and the like below are all corresponding to the corresponding partitions or modules determined in the implementation shown in FIG. 8A and FIG. 8B.

[0064] S202. The client determines whether data managed by the target data processing module is available.

[0065] If the client determines that the data managed by the target data processing module is available, S203 is performed. If the client determines that the data managed by the target data processing module is not available, S210 is performed. It may be understood that when data in a data processing module is migrated, or a storage node in which the data processing module is located is faulty, or the like, data managed by the data processing module may be unavailable.

[0066] S203. The client sends the read operation to the target data processing module based on the identifier of the second OSD module. Specifically, the client sends the read operation to the target data processing module deployed on the second OSD module. S204. The target data processing module determines, based on the read operation, a target metadata processing module and an identifier of a first OSD module in which the target metadata processing module is located. The target metadata processing module is a metadata processing module allocated by the distributed storage system to the read operation, and may be specifically a metadata processing module allocated by a client or the target data processing module in the distributed storage system to the read operation. For a specific implementation process, refer to related description in S103. Details are not described herein again.

[0067] S205. The target data processing module sends an access operation to the target metadata processing module based on the identifier of the first OSD module. Specifically, the client sends the access operation to the target metadata processing module deployed on the first OSD module. The access operation is a read access operation. The read access operation may carry a to-be-read LBA, which is used to read metadata of the read operation.

[0068] S206. The target metadata processing module reads the metadata of the read operation based on the read access operation.

[0069] In an implementation, if data protection is not performed on metadata of the IO operation, the target metadata processing module may locally read the metadata of the read operation.

[0070] In another implementation, if data protection is performed on metadata of the IO operation, for example, the metadata of the read operation is stored in an EC storage manner or a multi-copy storage manner, the target metadata processing module may determine, based on the to-be-read LBA carried by the read operation, a storage node in which the metadata of the read operation is located. For example, with reference to FIG. 6, the metadata of the read operation may be considered as any metadata in the MD 1 to the MD 4 in FIG. 6.

[0071] S207. The target metadata processing module sends the metadata of the read operation to the target data processing module.

[0072] S208. The target data processing module reads, based on the metadata of the read operation, data of the read operation (namely, the to-be-read data) stored in physical storage space corresponding to the to-be-read LBA.

[0073] S209. The target data processing module returns the to-be-read data to the client. After S209 is performed, the process ends.

[0074] S210. The client determines a management module that has a mapping relationship with the partition and an identifier of a third OSD module in which the management module is located.

[0075] S211. The client sends the read operation to the management module based on the identifier of the third OSD module. Specifically, the client sends the read operation to the management module deployed on the third OSD module.

[0076] S212. After receiving the read operation, the management module obtains data protection information of the read operation, reads, based on the data protection information, data that has a protection relationship with the to-be-read data, and reconstructs the to-be-read data based on the data that has the protection relationship with the to-be-read data.

[0077] Specifically, after receiving the read operation, the management module obtains identifiers of OSD modules in which data processing modules that have a mapping relationship with the management module are located, and sends the read operation to a corresponding data processing module based on the identifiers of the OSD modules. The read operation is used to read the data that has the protection relationship with the to-be-read data. These data processing modules read, based on a read request and S204 to S208, the data that has the protection relationship with the to-be-read data, and feed back the read data to the management module. The management module reconstructs the to-be-read data based on the data that has the protection relationship with the to-be-read data, and performs step S213.

[0078] S213. The management module returns the to-be-read data to the client.

[0079] After S213 is performed, the process ends.

[0080] The data processing method provided in this implementation may be applied to the distributed storage system shown in FIG. 2, FIG. 4, or FIG. 6. Specifically, based on the distributed storage system, a method for performing the read operation is provided. Optionally, the method for performing the read operation provided in this implementation may be proposed based on the method for performing the write operation shown in FIG. 8A and FIG. 8B. Therefore, for beneficial effects that can be achieved in this implementation, refer to the foregoing description. Details are not described herein again.

[0081] The foregoing mainly describes the solutions provided in the implementations of this application from a perspective of the methods. To implement the foregoing functions, corresponding hardware structures and / or software modules for performing the functions are included. A person skilled in the art should easily be aware that, in combination with the examples described in the implementations disclosed in this specification, units and algorithm steps can be implemented by hardware or a combination of hardware and computer software in this application. Whether a function is performed by hardware or hardware driven by computer software depends on particular applications and design constraints of the technical solutions. A skilled person may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of this application.

[0082] In the implementations of this application, the foregoing data processing module, the metadata processing module, the management module, and the like may be divided into function modules based on the foregoing method examples. For example, each function module may be obtained through division based on each corresponding function, or two or more functions may be integrated into one processing module. The integrated module may be implemented in a form of hardware, or may be implemented in a form of a software function module. It should be noted that the module division in the implementations of this application is an example, and is merely logical function division. There may be another division manner in actual implementation.

[0083] FIG. 10 is a schematic structural diagram of a data processing apparatus according to an implementation of this application. A data processing apparatus 90 shown in FIG. 10 may be applied to any distributed storage system provided above. The distributed storage system may include: at least one OSD module, and at least one data processing module and at least one metadata processing module that has a mapping relationship with the at least one data processing module are deployed on the at least one OSD module. The apparatus 90 is a data processing module that is in the at least one data processing module and that is allocated by a distributed storage system to an IO operation, which may be configured to perform the steps performed by the corresponding target data processing module in any one of the data processing methods provided above. The apparatus 90 may include: a receiving unit 901, a processing unit 902, and a sending unit 903. The receiving unit 901 is configured to receive an IO operation. The processing unit 902 is configured to determine a target metadata processing module and an identifier of a first OSD module in which the target metadata processing module is located. There is a mapping relationship between the target metadata processing module and the apparatus 90. The sending unit 903 is configured to send an access operation to the target metadata processing module based on the identifier of the first OSD module. The access operation is used to instruct the target metadata processing module to access metadata of the IO operation. The processing unit 902 may be further configured to access data of the IO operation. For example, with reference to FIG. 8A and FIG. 8B, the apparatus 90 may be the target data processing module in FIG. 8A and FIG. 8B. The IO operation may be the write operation. The receiving unit 901 may be configured to perform the receiving step in S104. The processing unit 902 may be configured to perform S106. The sending unit 903 may be configured to perform the sending step in S107. For example, with reference to FIG. 9A and FIG. 9B, the apparatus 90 may be the target data processing module in FIG. 9A and FIG. 9B. The IO operation may be the read operation. The receiving unit 901 may be configured to perform the receiving step in S203. The processing unit 902 may be configured to perform S204. The sending unit 903 may be configured to perform the sending step in S205.

[0084] Optionally, the processing unit 902 may be specifically configured to: determine, based on the mapping relationship between the data processing module and the metadata processing module, a target metadata processing module that has a mapping relationship with the apparatus 90; and determine, based on a mapping relationship between the metadata processing module and the OSD module in which the metadata processing module is located, the identifier of the first OSD module in which the target metadata processing module is located.

[0085] Optionally, the IO operation is a write operation, and the access operation is a write access operation. The write access operation includes metadata of the write operation. In this case, the processing unit 902 may be specifically configured to: write, based on the write operation, data of the write operation into a storage node in which the apparatus 90 is located; and generate the metadata of the write operation. For example, with reference to FIG. 8A and FIG. 8B, the processing unit 902 may be configured to perform S105.

[0086] Optionally, the IO operation is a read operation, and the access operation is a read access operation. In this case, the receiving unit 901 may be further configured to receive metadata that is of the read operation and that is sent by the target metadata processing module. The processing unit 902 may be specifically configured to read data of the read operation based on the read operation and the metadata of the read operation. For example, with reference to FIG. 9A and FIG. 9B, the receiving unit 901 may be configured to perform the receiving step in S207. The processing unit 902 may be configured to perform S208.

[0087] In an example, with reference to FIG. 2, the data processing apparatus 90 may correspond to the storage node 22 in FIG. 2. The receiving unit 901 and the sending unit 903 may correspond to the communications interface in FIG. 2. The processing unit 902 may correspond to the processor in FIG. 2.

[0088] Reference may be made to the foregoing method implementations for explanations about related content in this implementation. Details are not described herein again.

[0089] FIG. 11 is a schematic structural diagram of a data processing apparatus according to an implementation of this application. A data processing apparatus 100 shown in FIG. 11 may be applied to any distributed storage system provided above. The distributed storage system may include: at least one OSD module, and at least one data processing module and at least one metadata processing module that has a mapping relationship with the at least one data processing module are deployed on the at least one OSD module. The apparatus 100 is a metadata processing module that has a mapping relationship with a target data processing module. The target data processing module is a data processing module that is in the at least one data processing module and that is allocated by the distributed storage system to an IO operation, which is configured to access data of the IO operation. The apparatus 100 may include: a receiving unit 1001, and a processing unit 1002. The receiving unit 1001 is configured to receive an access operation sent by the target data processing module. The processing unit 1002 is configured to access metadata of the IO operation based on the access operation. For example, with reference to FIG. 8A and FIG. 8B, the apparatus 100 may be the target metadata processing module in FIG. 8A and FIG. 8B. The IO operation is a write operation. The receiving unit 1001 may be configured to perform the receiving step in S107. The processing unit 1002 may be configured to perform S108. For example, with reference to FIG. 9A and FIG. 9B, the apparatus 100 may be the target metadata processing module in FIG. 9A and FIG. 9B. The IO operation is a read operation. The receiving unit 1001 may be configured to perform the receiving step in S205. The processing unit 1002 may be configured to perform S206.

[0090] Optionally, the IO operation is the write operation, and the access operation is a write access operation. The write access operation carries metadata of the write operation. In this case, the processing unit 1002 may be specifically configured to write the metadata of the write operation into the at least two storage nodes based on the write access operation. For example, with reference to FIG. 8A and FIG. 8B, the processing unit 1002 may be configured to perform S108.

[0091] Optionally, the IO operation is a read operation, and the access operation is a read access operation. In this case, the processing unit 1002 may be specifically configured to read metadata of the read operation based on the read access operation. The apparatus 100 may further include: a sending unit 1003, configured to send the metadata of the read operation to the target data processing module. The metadata of the read operation is used to instruct the target data processing module to read data of the read operation. For example, with reference to FIG. 9A and FIG. 9B, the processing unit 1002 may be configured to perform S206. The sending unit 1003 may be configured to perform the sending step in S207.

[0092] In an example, with reference to FIG. 2, the data processing apparatus 100 may correspond to the storage node 22 in FIG. 2. The receiving unit 1001 and the sending unit 1003 may correspond to the communications interface in FIG. 2. The processing unit 1002 may correspond to the processor in FIG. 2.

[0093] Reference may be made to the foregoing method implementations for explanations about related content in this implementation. Details are not described herein again.

[0094] FIG. 12 is a schematic structural diagram of a data processing apparatus according to an implementation of this application. A data processing apparatus 110 shown in FIG. 12 may be applied to any distributed storage system provided above. The distributed storage system may include: at least one OSD module, and the apparatus 110, at least one data processing module that has a mapping relationship with the apparatus 110, and at least one metadata processing module that has a mapping relationship with the at least one data processing module are deployed on the at least one OSD module. The apparatus 110 is configured to manage data protection information of the IO operation. The apparatus 110 may include: a receiving unit 1101, a processing unit 1102, and a sending unit 1103.

[0095] In some implementations, the receiving unit 1101 is configured to receive an IO operation, and the IO operation is a write operation. The processing unit 1102 is configured to determine a target data processing module and an identifier of a second OSD module in which the target data processing module is located. The target data processing module is a data processing module that is in the at least one data processing module and that is allocated by a distributed storage system to the IO operation. The sending unit 1103 is configured to send the write operation to the target data processing module based on the identifier of the second OSD module. The write operation is used to instruct the target data processing module to determine a target metadata processing module and an identifier of a first OSD module in which the target metadata processing module is located, and send a write access operation to the target metadata processing module. The write access operation is used to instruct the target metadata processing module to read metadata of the write operation. The target data processing module is further configured to read data of the write operation based on metadata of the IO operation. For example, with reference to FIG. 8A and FIG. 8B, the apparatus 110 may be the management module in FIG. 8A and FIG. 8B. The IO operation may be the write operation. The receiving unit 1101 may be configured to perform the receiving step in S102. The processing unit 1102 may be configured to perform S103. The sending unit 1103 may be configured to perform the sending step in S104.

[0096] Optionally, the processing unit 1102 may be further configured to calculate data protection information of the write operation.

[0097] Optionally, the distributed storage system further includes a client. In this case, the receiving unit 1101 may be specifically configured to receive the write operation sent by the client. For example, with reference to FIG. 8A and FIG. 8B, the receiving unit 1101 may be configured to perform the receiving step in S102.

[0098] In some implementations, the receiving unit 1101 is configured to receive an IO operation, and the IO operation is a write operation. The processing unit 1102 is configured to: obtain data protection information of a read operation; read data that has a protection relationship with the data of the read operation based on the data protection information; and reconstruct data of the read operation based on the data that has the protection relationship with the data of the read operation. For example, with reference to FIG. 9A and FIG. 9B, the apparatus 110 may be the management module in FIG. 9A and FIG. 9B. The IO operation may be the read operation. The receiving unit 1101 may be configured to perform the receiving step in S211. The processing unit 1102 may be configured to perform S212.

[0099] Optionally, the distributed storage system further includes a client. In this case, the receiving unit 1101 may be specifically configured to receive a write operation sent by the client. The sending unit 1103 is configured to send data of the read operation to the client. For example, with reference to FIG. 9A and FIG. 9B, the receiving unit 1101 may be configured to perform the receiving step in S211. The sending unit 1103 may be configured to perform the sending step in S213.

[0100] In an example, with reference to FIG. 2, the data processing apparatus 110 may correspond to the storage node 22 in FIG. 2. The receiving unit 1101 and the sending unit 1103 may correspond to the communications interface in FIG. 2. The processing unit 1102 may correspond to the processor in FIG. 2.

[0101] Reference may be made to the foregoing method implementations for explanations about related content in this implementation. Details are not described herein again.

[0102] All or some of the foregoing implementations may be implemented by using software, hardware, firmware, or any combination thereof. When a software program is used to implement the implementations, the implementations may be implemented completely or partially in a form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on the computer, the procedure or functions according to the implementations of this application are all or partially generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or other programmable apparatuses. The computer instructions may be stored in a computer-readable storage medium or may be transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line (DSL)) or wireless (for example, infrared, radio, and microwave, or the like) manner. The computer-readable storage medium may be any usable medium accessible by a computer, or a data storage device, such as a server or a data center, integrating one or more usable media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, a DVD), a semiconductor medium (for example, a solid-state drive (SSD)), or the like.

[0103] The scope of protection shall be defined by the appended claims.

Claims

1. A distributed storage system comprising multiple storage nodes, wherein multiple object storage device, OSD, modules (20) are deployed on the multiple storage nodes (22) such that each storage node comprises at least one OSD module, and multiple data processing modules (202) and multiple metadata processing modules (203) are deployed on the multiple OSD modules, wherein a mapping relationship exists between the data processing modules and the metadata processing modules; wherein a target data processing module is configured to: receive an input / output IO operation; determine a target metadata processing module and an identifier of a first OSD module in which the target metadata processing module is located; and send an access operation to the target metadata processing module based on the identifier of the first OSD module, wherein the target data processing module is a data processing module allocated by the distributed storage system to the IO operation, and the target metadata processing module has a mapping relationship with the target data processing module, wherein the target metadata processing module is configured to: access metadata of the IO operation based on the access operation; and the target data processing module is further configured to access data of the IO operation based on the IO operation; wherein when the IO operation is a write operation, the access operation is a write access operation, and the write access operation carries metadata of the write operation; the target data processing module is further configured to: write, based on the write operation, data of the write operation into a storage node in which the target data processing module is located; and generate the metadata of the write operation; and the target metadata processing module is configured to: write the metadata of the write operation into at least two storage nodes based on the write access operation; and wherein when the IO operation is a read operation, and the access operation is a read access operation; the target metadata processing module is configured to: read metadata of the read operation based on the read access operation; and send the metadata of the read operation to the target data processing module; and the target data processing module is further configured to: read data of the read operation based on the read operation and the metadata of the read operation.

2. The distributed storage system according to claim 1, wherein the target data processing module is configured to: determine, based on the mapping relationship between the data processing module and the metadata processing module, the target metadata processing module that has the mapping relationship with the target data processing module; and determine, based on a mapping relationship between the metadata processing module and the OSD module in which the metadata processing module is located, the identifier of the first OSD module in which the target metadata processing module is located.

3. The distributed storage system according to any one of claims 1 to 2, wherein, the target data processing module is located in a second OSD module, wherein the second OSD module is different from the first OSD module in which the target metadata processing module is located.

4. The distributed storage system according to any one of claims 1 to 3, wherein a management module (201) is further deployed on the at least one OSD module, and there is a mapping relationship between the management module and the multiple data processing modules; and the management module is configured to: receive the IO operation, wherein the IO operation is the write operation; and calculate data protection information of the write operation; or the management module is configured to: receive the IO operation, wherein the IO operation is the read operation; obtain data protection information of the read operation; read, based on the data protection information, data that has a protection relationship with the data of the read operation; and reconstruct the data of the read operation based on the data that has the protection relationship with the data of the read operation.

5. The distributed storage system according to claim 4, wherein the distributed storage system further comprises: a client (10), configured to: receive the IO operation; determine the management module and an identifier of a third OSD module in which the management module is located; and send the IO operation to the management module based on the identifier of the third OSD module.

6. The distributed storage system according to claim 4 or 5, wherein the management module is further configured to: receive the IO operation, wherein the IO operation is the write operation; determine the target data processing module and an identifier of the second OSD module in which the target data processing module is located; and send the write operation to the target data processing module based on the identifier of the second OSD module.

7. The distributed storage system according to any one of claims 1 to 3, wherein the distributed storage system further comprises: a client, configured to: receive the IO operation, wherein the IO operation is the read operation; determine the target data processing module and an identifier of the second OSD module in which the target data processing module is located; and send the read operation to the target data processing module based on the identifier of the second OSD module.

8. A data processing method, applied to a distributed storage system, the distributed storage system comprising multiple storage nodes, wherein multiple object storage device, OSD, modules are deployed on the multiple storage nodes such that each storage node comprises at least one OSD module, and multiple data processing modules and multiple metadata processing modules are deployed on the multiple OSD modules, wherein a mapping relationship exists between the data processing modules and the metadata processing modules; and the method comprises: receiving, by a target data processing module, an input / output IO operation, wherein the target data processing module is a data processing module allocated by the distributed storage system to the IO operation; determining, by the target data processing module, a target metadata processing module and an identifier of a first OSD module in which the target metadata processing module is located, wherein there is a mapping relationship between the target metadata processing module and the target data processing module; sending, by the target data processing module, an access operation to the target metadata processing module based on the identifier of the first OSD module, wherein the access operation is used to instruct the target metadata processing module to access metadata of the IO operation; and accessing, by the target data processing module, data of the IO operation; wherein when the IO operation is a write operation, the access operation is a write access operation, and the write access operation carries metadata of the write operation; the method further comprises: writing, by the target data processing module, based on the write operation, data of the write operation into a storage node in which the target data processing module is located; and generate the metadata of the write operation; and writing, by the target metadata processing module, the metadata of the write operation into at least two storage nodes based on the write access operation; and wherein when the IO operation is a read operation, and the access operation is a read access operation; the method further comprises: reading, by the target metadata processing module, metadata of the read operation based on the read access operation; and send the metadata of the read operation to the target data processing module; and reading, by the target data processing module, data of the read operation based on the read operation and the metadata of the read operation.

9. The data processing method according to claim 8 further comprising: receiving, by the target metadata processing module, the access operation sent by the target data processing module; and accessing, by the target metadata processing module, metadata of the IO operation based on the access operation.

10. The method according to claim 8 to 9, wherein a management module is further deployed on the at least one OSD module, and there is a mapping relationship between the management module and the multiple data processing modules; and the method further comprises: receiving, by the management module, the IO operation, wherein the IO operation is a write operation; determining, by the management module, the target data processing module and an identifier of a second OSD module in which the target data processing module is located, wherein the target data processing module is a data processing module allocated by the distributed storage system to the IO operation; and sending, by the management module, the write operation to the target data processing module based on the identifier of the second OSD module, wherein the write operation is used to instruct the target data processing module to determine a target metadata processing module and an identifier of a first OSD module in which the target metadata processing module is located, and send a write access operation to the target metadata processing module based on the identifier of the first OSD module, there is a mapping relationship between the target metadata processing module and the target data processing module, the write access operation is used to instruct the target metadata processing module to read metadata of the write operation, and the target data processing module is further configured to read data of the write operation based on metadata of the IO operation.

11. A storage node for use in a distributed storage system, wherein the distributed storage system comprises multiple storage nodes, wherein multiple object storage device, OSD, modules are deployed on the multiple storage nodes such that each storage node comprises at least one OSD module, and multiple data processing modules and multiple metadata processing modules are deployed on the multiple OSD modules, wherein a mapping relationship exists between the data processing modules and the metadata processing modules; and the storage node comprises: a memory, configured to store a computer program; and a processor, configured to invoke the computer program to implement a function of a target data processing module according to claim 8, a target metadata processing module according to claim 9 or a management module according to claim 10.