Data reading method, storage node, system and computing equipment

Abstract

The embodiment of the invention provides a data reading method which comprises the steps that a first storage node receives a data reading request, and the data reading request comprises a target I P address, an MAC address of the first storage node and an identifier of to-be-read data; the first storage node determines a target storage node based on the identifier of the to-be-read data, the target storage node stores a data block in the to-be-read data, and the virtual IP of the target storage node is the same as the virtual IP of the first storage node; the first storage node generates a second request according to the data reading request, wherein the second request comprises a target I P address, an MAC address of a target storage node and an identifier of a data block stored by the target storage node; the second request indicates the target storage node to send the data block stored by the target storage node to the request initiating end. Therefore, by directly transmitting the data from the target storage node to the request initiating end, the additional flow for transferring the data through the first storage node is avoided, and the problems of flow bottleneck and delay in a data transmission path are reduced.

Description

Technical Field

[0001] The present application relates to the field of storage technology, and in particular to a data reading method, storage node, system and computing device. Background Art

[0002] In a multi-copy distributed storage system, data reading operations often face the problem of unbalanced network traffic. One prominent problem is that the ratio of requests sent by the client to the storage system is about 10%:90% relative to the large amount of data sent by the storage system to the client. This imbalance leads to a series of problems: First, the amount of data forwarding between storage nodes is huge, accounting for almost the vast majority of the total traffic. For example, in a 5-node system, the amount of forwarded data may be as high as 80%. For a 10Gbps network bandwidth, 8Gbps is required to handle the forwarding volume. Secondly, in order to cope with this high proportion of data forwarding, the system needs to be configured with more network cards, CPUs, and memory resources, which not only increases the complexity of the system, but also significantly increases the hardware cost. Finally, since data needs to be transmitted between multiple nodes, the latency of the client obtaining data also increases, affecting the user experience.

[0003] In order to solve the problems of large data forwarding volume between nodes, increased hardware costs and reduced customer experience in multi-copy distributed storage systems, it is crucial to optimize data reading operations. Summary of the invention

[0004] The embodiments of the present application provide a data reading method, storage node, system and computing device, which transmit data directly to the request initiator through each storage node, thereby reducing the traffic bottleneck and delay problems in the data transmission path.

[0005] In a first aspect, an embodiment of the present application provides a data reading method, the method comprising a first storage node receiving a data reading request sent by a request initiator, the data reading request comprising a target IP address, a MAC address of the first storage node and an identification of the data to be read, wherein the target IP address is a virtual IP of the first storage node; the first storage node determines a target storage node based on the identification of the data to be read, the target storage node stores a data block in the data to be read, and the virtual IP of the target storage node is the same as the virtual IP of the first storage node; the first storage node generates a second request according to the data reading request, the second request comprising the target IP address, the MAC address of the target storage node and an identification of the data block stored by the target storage node; the second request is used to instruct the target storage node to send the data block stored by itself to the request initiator. The first storage node sends the second request to the target storage node.

[0006] In the above example, by directly transmitting data from the target storage node to the request initiator, the additional traffic of transferring data through the centralized node (such as the first storage node) is avoided. The traffic bottleneck and delay problems in the data transmission path are significantly reduced, the transmission efficiency of the system is improved, and the use of network resources is optimized, especially in high-concurrency or large-scale data reading scenarios, the load of the centralized node is reduced, and the response speed of data reading is further improved.

[0007] In one possible implementation, the first storage node generates multiple second requests based on the data read request, each second request corresponds to a target storage node, and each second request includes the target IP address, the source IP address, the MAC address of the corresponding target storage node, and the identifier of the data block stored by the corresponding target storage node; the second request is used to instruct the corresponding target storage node to send the data block stored by itself to the request initiator.

[0008] In the above example, the first storage node decomposes the data request into multiple second requests, each of which points to a different target storage node, allowing multiple target storage nodes to process and transmit data blocks in parallel, thereby significantly improving the efficiency and throughput of data reading. By specifying the target storage node in the second request to directly send the data block to the request initiator, the data is avoided from being transferred through the first storage node, network latency is reduced, and the response speed of data transmission is improved.

[0009] In one possible implementation, the first storage node generates a second request based on a data read request, the second request includes a target IP address, a source IP address, a MAC address of the first target storage node, and an identifier of a data block stored by the first target storage node; the second request is used to instruct the first target storage node to return the data block stored by itself to the request initiator, and the first storage node sends the second request based on the data read request; the first target storage node generates a third request based on the second request, the third request includes the target IP address, the source IP address, the MAC address of the second target storage node, and the identifier of the data block stored by the second target storage node; the third request is used to instruct the second target storage node to send the data block stored by itself to the request initiator, and the first target storage node sends the third request based on the second read request.

[0010] In the above example, the first storage node only needs to generate the first request, and subsequent requests are passed to the next node by each target storage node step by step. In this way, the first storage node does not have to bear the task of forwarding all requests, which significantly reduces the load and avoids the generation of bottlenecks.

[0011] In a possible implementation, the first storage node obtains status information sent by the target storage node, where the status information is used to indicate whether the target storage node has successfully read a data block of the to-be-read data stored in itself.

[0012] In the above example, by obtaining the status information sent by the target storage node, the first storage node can better control the progress and reliability of data reading, and improve the response speed, fault tolerance and integrity of the system.

[0013] In one possible implementation, the first storage node determines the target storage node based on the identification of the data to be read, specifically including: according to the metadata list, the first storage node identifies the target storage node that stores the data block, and the metadata list is used to record the location of each data block and its corresponding storage node information.

[0014] In the above example, by querying the metadata list, the first storage node can efficiently and accurately determine the target storage node, effectively improving the data reading performance of the system.

[0015] In a possible implementation, if the first storage node stores a data block in the data to be read, the first storage node reads the data block from the local storage and sends the data block to the request initiator.

[0016] In the above example, when the first storage node stores the requested data block, it can directly read and transmit the data to the request initiator, avoiding the network delay of forwarding the request to other storage nodes, thereby significantly improving the response speed of data reading.

[0017] In a second aspect, an embodiment of the present application provides a data reading method, which is applied to a first target storage node, and the method includes: receiving a second request sent by the first storage node, the second request includes a target IP address, a MAC address of the first target storage node, and an identifier of a data block stored by the target storage node; the second request is used to instruct the first target storage node to send its own stored data block to the request initiator, and the target IP address is a virtual IP of the first storage node; sending its own stored data block to the request initiator; generating a third request according to the second request, the third request includes the target IP address, the source IP address, the MAC address of the second target storage node, and the identifier of the data block stored by the second target storage node; the third request is used to instruct the second target storage node to return its own stored data block to the request initiator. Send the third request to the second target storage node.

[0018] In a third aspect, an embodiment of the present application provides a storage node, including: a network request receiving module, used to receive a data read request sent by a request initiator, the data read request includes a target IP address, a MAC address of a first storage node and an identifier of the data to be read, wherein the target IP address is a virtual IP of the first storage node; a data request distribution module, used to determine a target storage node according to the identifier of the data to be read, the target storage node stores a data block in the data to be read, and the virtual IP of the target storage node is the same as the virtual IP of the first storage node; a data request forwarding module, used to generate a second request according to the data read request, the second request includes a target IP address, a MAC address of the target storage node and an identifier of the data block stored by the target storage node; the second request is used to instruct the target storage node to send a data block stored by itself back to the request initiator. Send the second request to the target storage node.

[0019] In a fourth aspect, an embodiment of the present application provides a distributed storage system, including a first storage node and a target storage node, characterized in that it includes: a first storage node, used to receive a data read request sent by a request initiator, the data read request includes a target IP address, a MAC address of the first storage node and an identification of the data to be read, wherein the target IP address is a virtual IP of the first storage node; and based on the identification of the data to be read, determining the target storage node, the target storage node stores a data block in the data to be read, and the virtual IP of the target storage node is the same as the virtual IP of the first storage node; finally, generating a second request according to the data read request, the second request includes the target IP address, the MAC address of the target storage node and an identification of the data block stored by the target storage node; the second request is used to instruct the target storage node to return the data block stored by itself to the request initiator; the target storage node, used to receive the second request sent by the first storage node, and send the data block stored by itself to the request initiator. Send a second request to the target storage node;

[0020] In a fifth aspect, an embodiment of the present application provides a computing device, which executes the method described in the first aspect.

[0021] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

[0022] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the first aspect.

[0023] In a seventh aspect, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 A schematic diagram of the architecture of a distributed storage system for implementing the method provided in an embodiment of the present application;

[0025] Figure 2 A schematic diagram of a data writing process provided in an embodiment of the present application;

[0026] Figure 3 A flowchart of a data reading method provided in an embodiment of the present application;

[0027] Figure 4 A flowchart of a reading scenario in which data to be read is located in a target storage node provided in an embodiment of the present application;

[0028] Figure 5 This is a schematic diagram of a data read request process provided by an embodiment of the present application;

[0029] Figure 6 A schematic diagram of a flow chart of another method for reading data provided in an embodiment of the present application;

[0030] Figure 7 A schematic diagram of another data reading process provided in an embodiment of the present application;

[0031] Figure 8 A flowchart of another data reading method provided in an embodiment of the present application;

[0032] Fig. 9 A schematic diagram of another data reading process provided in an embodiment of the present application;

[0033] Fig.10 A schematic diagram of a data reading exception processing process provided in an embodiment of the present application;

[0034] Fig.11 A schematic diagram of the structure of a storage node provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] The term "and / or" in this article is a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The symbol " / " in this article indicates that the associated objects are in an or relationship, for example, A / B means A or B.

[0036] The terms "first" and "second" in the specification and claims herein are used to distinguish different objects rather than to describe a specific order of the objects. For example, a first response message and a second response message are used to distinguish different response messages rather than to describe a specific order of the response messages.

[0037] In the description of this document, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", "circumferential" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation.

[0038] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0039] To facilitate understanding of the technical solutions of the embodiments of the present application, the terms involved in this document are explained below.

[0040] A distributed storage system is a storage system that stores data in multiple independent computer storage devices (i.e. storage nodes). Its essence is to evenly distribute a large number of files to multiple storage nodes.

[0041] Object Storage Daemon (OSD): It is the core component of the object storage system. It is mainly responsible for managing the data storage operations of storage devices (such as logical hard disks), responding to client requests and returning the corresponding storage data. Usually there is a one-to-one correspondence between physical disks. Each OSD process is usually responsible for managing the data on a physical disk. In the Ceph cluster, OSD is the basic storage unit, responsible for storing data blocks.

[0042] Block storage: It is an efficient data storage architecture that divides data into fixed-size blocks, allowing fast random access and modification, and is suitable for application scenarios that require high-performance reading and writing. By providing direct access to physical storage devices, it supports a wide range of file systems and operating systems and is suitable for mission-critical applications such as databases, virtualized environments, and high-performance computing.

[0043] Multi-copy storage technology: a technology that implements data protection by storing multiple copies of the same data on different storage nodes. The copy is the smallest unit of data backup. Each copy set contains multiple copies. The specific number of copies is pre-set by the user. The data content of each copy is exactly the same.

[0044] Ceph: A distributed storage system that provides high-performance, scalable, and reliable storage solutions on large-scale computing clusters.

[0045] In distributed storage systems, data reading operations often face the problem of unbalanced network traffic, especially the phenomenon that the upstream traffic (the amount of requested data) is small, while the downstream traffic (the amount of returned data) increases significantly. The main reason is that the query requests sent by the client usually have a small amount of data, while the amount of data returned by the storage node is large, resulting in a high demand for data transmission between nodes, especially an increase in the amount of data forwarding across nodes.

[0046] Specifically, data blocks are usually distributed on multiple storage nodes, resulting in a large amount of cross-node data transmission during the data reading process. For example, in a 5-node system, the data to be read is divided into 5 data blocks and distributed on different nodes. When the client initiates a read request, the initial node needs to request data blocks from the other 4 nodes and return them to the client after aggregation. Since the 4 data blocks all come from other storage nodes, the amount of cross-node data forwarding accounts for 80% of the total data volume. In a 10Gbps network environment, the initial node needs to occupy 8Gbps bandwidth to receive data from other nodes, resulting in huge system bandwidth and resource consumption. The initial node refers to the storage node that first receives the request after the client initiates a read request.

[0047] As the number of storage nodes increases, the amount of data transmitted across nodes will also increase accordingly, thus occupying more network bandwidth. In order to ensure overall performance, each storage node usually needs to be equipped with a high-speed network interface, such as a 10Gbps or higher interface, to meet the needs of cross-node data flow. Cross-node data forwarding not only takes up a large amount of network bandwidth, but also consumes considerable CPU and memory resources. The consumption of these resources may occupy computing resources on the storage node and affect the overall performance of the system. Storage nodes not only have to handle their own storage and computing tasks, but also have to undertake the task of receiving data from other storage nodes and forwarding it.

[0048] In order to solve the challenges brought by cross-node data transmission, distributed storage systems may need to make a lot of investment in hardware, such as adding network interface cards, upgrading CPU and memory configuration, etc. In addition, a large amount of forwarded data may also increase the complexity of the system and bring potential performance bottlenecks. Therefore, designing an efficient data reading strategy is crucial to improving the performance of distributed storage systems.

[0049] The present application embodiment provides a data reading method. In this method, data is directly transmitted from the target storage node to the request initiator, avoiding the need to pass through the initial node (such as Figure 1 This significantly reduces the traffic bottleneck and delay problems in the data transmission path, improves the transmission efficiency of the system, and optimizes the use of network resources. In particular, in high-concurrency or large-scale data reading scenarios, it reduces the load on the initial node and further improves the response speed of data reading.

[0050] Next, the data reading method provided in the embodiment of the present application is specifically introduced.

[0051] Figure 1 The following is a schematic diagram of the architecture of a distributed storage system for implementing the method provided in the embodiment of the present application. Figure 1 As shown, the distributed storage system 100 includes a storage cluster 20 and a client 30 connected to the storage cluster 20 via a network.

[0052] The storage cluster 20 includes a plurality of storage nodes 11 storing data, and at least one client 30 is connected to the storage cluster 20. The client 30 can write data to the storage cluster 20 or read data from the storage cluster 20. Each storage node 11 may serve as the first storage node, that is, at each request, a storage node 11 in the storage cluster 20 will be selected as the first storage node, and the selection may be based on load balancing distribution or user-specified policies. The selected first storage node (e.g., the storage node 11 shown in the figure) will receive the request from the client 30, and forward the request to other target storage nodes (e.g., Figure 1 The storage nodes 11-1, 11-2 ... 11-n) are shown, wherein the target storage node stores the data required by the request.

[0053] In the distributed storage system 100, a client 30 is provided as an example only and not as a limitation (the system can flexibly adjust the number of clients according to its actual needs). The client 30 can run on a variety of computing devices, such as physical servers, virtual machines, desktop computers, laptops, and mobile devices, and supports different operating systems, such as Windows, Linux, etc. By deploying clients on these devices, applications (APPs) can access data on storage nodes. Write operations carry data to be written, which is used to write the data to be written to the storage nodes in the distributed storage system. Read operations carry data requests to be read, which are used to read stored data from storage nodes.

[0054] The storage node can be a physical storage node or a plurality of logical storage nodes divided by a physical storage node, and converts the read and write operations into read and write request processing for the disk. The above-mentioned server is interconnected with the storage node through, for example but not limited to, a computing network, a conversion cable InfiniBand or Fibre Channel over Ethernet FCoE. The storage node is used to receive data requests sent from the client. Multiple storage nodes can also communicate directly or through other devices, which is not limited in this application. The storage Target deployed in the storage node can process the read and write operation requests sent by the client, and is a device or component used to provide storage resources, receive and respond to client storage requests.

[0055] In the storage cluster 20, each storage node (including the storage node 11, and the storage nodes 11-1 to 11-n) is configured with a virtual IP address, and these virtual IPs are bound via a local loopback interface (lo).

[0056] Exemplarily, each storage node is configured with the same virtual IP and the virtual IP is bound to the loopback interface (lo). All storage nodes use the same virtual IP as the source IP to send response data to the client. When the client sends a request to the virtual IP (e.g., VIP 1.1.1.1), the request is distributed to a specific storage node (i.e., the first storage node) through a load balancing mechanism, for example.

[0057] For example, the following configuration commands may be executed on the storage node 11-1: ifconfig lo:01.1.1.1 netmask 255.255.255.255 up, route add-host 1.1.1.1 dev lo, ifconfig lo:01.1.1.1: bind the virtual IP 1.1.1.1 to the local loopback interface lo of the storage node 11-1, where lo:0 is an alias interface for configuring multiple IPs. route add-host 1.1.1.1 dev lo: ensure that the data packets sent to 1.1.1.1 are processed through the local loopback interface (lo).

[0058] The first storage node (acting as an entry node) receives a data read request from a request initiator (eg, a client), which includes a target IP address (ie, a virtual IP address of the first storage node), a MAC address of the first storage node, and a unique identifier of the requested data.

[0059] After receiving the request, the first storage node determines the specific storage location (target storage node) of the data through the requested data identifier. These target storage nodes store the data blocks of the requested data, and they share the same virtual IP address with the first storage node, but have different MAC addresses.

[0060] Then, the first storage node generates a second request based on the data read request, which includes the MAC address of the target storage node, the identifier of the data block stored by the target storage node, and the target IP address. The second request instructs the target storage node to directly return the specified data block stored by it to the request initiator. Through this mechanism, the client can directly obtain each data block from different storage nodes, reducing the transit burden of the data transmission path and improving the response efficiency and throughput of the system.

[0061] It should be noted that the first storage node can also store part or all of the data to be read. In this case, when the client initiates a data read request, the first storage node parses the request and finds that the required data block is already stored on its local storage device (such as OSD). At this time, it is both the first storage node that receives the client request and the target storage node that is ultimately responsible for reading data from the storage and returning it directly to the client.

[0062] When the target storage node encounters an error while transmitting data (e.g., transmission failure, network anomaly, storage device failure, etc.), it will immediately feedback detailed error information through the connection established with the first storage node. This information may include: error type (e.g., network problem, storage hardware failure, etc.), data block transmission status (e.g., transmission interrupted or unable to complete)

[0063] For example, after receiving the error feedback, the first storage node will perform the following operations: Logging: The first storage node records the error details and current progress of this transmission for subsequent troubleshooting. Update status: The first storage node updates the list of target storage nodes and marks the status of the target storage node as abnormal to prevent further requests from being sent to the node. The first storage node will select the target storage node where the next available copy is located to read the data. The first storage node will generate a new request and send it to this new target storage node to continue reading and transmitting the data block. The newly selected target storage node will attempt to read the data block from its copy and transmit it to the client. The first storage node continuously monitors the transmission progress of the new target storage node to ensure that the data is successfully transmitted to the client.

[0064] If the target storage node has the data but an error occurs during the transmission, the first storage node will receive error feedback from the target storage node, indicating that a problem occurred during the transmission. The first storage node will make adjustments based on the feedback information, such as reselecting other available replicas to complete the data transmission. The client will only receive the final complete data, and the handling of transmission errors is coordinated and resolved internally by the first storage node. The client usually does not directly perceive these transmission errors, and the first storage node ensures the final data integrity through rescheduling.

[0065] It should be noted that the above illustrative discussion is not intended to be exhaustive or to limit the present invention to Figure 1 The system architecture shown is feasible in many modifications and variations of the distributed storage system 100 during the specific implementation process. It is only used as an example and not as a limitation. The storage nodes can be respectively integrated into the electronic devices where the client 30 is located.

[0066] Figure 2 A schematic diagram of a data writing process provided in an embodiment of the present application. Figure 2 The three-copy strategy is shown in Figure 1, that is, each data block has one primary copy and two secondary copies. The data writing process involves multiple storage nodes and OSDs.

[0067] When a client initiates a write request, the request is encapsulated, for example, by an iSCSI Initiator. The encapsulated request is sent to the storage target on the storage node Node 0 through the network along the optimal path. The storage target is responsible for receiving the write request and sending the data to OSD.0 (primary). OSD.0 (primary) is the storage unit responsible for storing the primary copy of the data block.

[0068] Next, OSD.0 (primary) sends the secondary copy of the data block to the OSD storage on other storage nodes. In this process, OSD.0 of Node 1 and OSD.0 of Node 2 receive the secondary copy of the data block and write it to their respective local OSDs as secondary copy storage.

[0069] When the OSD.0 of Node 1 and Node 2 completes writing the secondary replica of the data block, they return a confirmation message of the completion of the write to the OSD.0 (primary) of Node 0. At the same time, these storage nodes can also update the metadata related to the data block. The metadata update includes the write timestamp and completion status of the data, which is used to select the latest replica for reading in subsequent data read operations. If Node 0 (primary replica) fails, the metadata update of other secondary replica nodes will ensure that the secondary replica node is upgraded to the primary replica node and continues to provide data services.

[0070] When Node 0's OSD.0 (primary) collects all write confirmation messages from Node 1 and Node 2, it indicates that both the primary and secondary copies of the data block have been successfully written. Subsequently, OSD.0 (primary) reports the write completion status to the storage target. Finally, the storage target sends a write success message back to the client's iSCSI Initiator, indicating that the entire write process has been completed.

[0071] The data writing process in the embodiment of the present application is basically consistent with the relevant technology, and the data reading process provided by the embodiment of the present application is described below. In the traditional data reading process, the read request of the client is usually concentrated on one storage node, which is responsible for collecting copies of all relevant data blocks from other storage nodes and then returning them to the client in a unified manner. This method easily leads to a single point bottleneck and increases the traffic burden between nodes. The embodiment of the present application provides an improved data reading process. When the client issues a read request, the request will first arrive at the first storage node (e.g., Node0). The first storage node is responsible for parsing the request and determining the distribution of the data block, and then forwarding the request to the second storage node (e.g., Node 1) storing data block 1, and then the second storage node forwards the remaining data read request to the third storage node (e.g., Node 2) storing data block 2. After receiving the request forwarded by the previous storage node, each target storage node processes the request and returns the data block to the client without the need for centralized processing by the first storage node. This improvement greatly reduces data forwarding between storage nodes and improves overall performance.

[0072] Figure 3 A flow chart of a data reading method provided in an embodiment of the present application. Figure 3 As shown, this embodiment can be applied in a distributed storage system. The data reading method provided in the embodiment of the present application includes at least the following steps:

[0073] Step 301: A first storage node receives a data read request sent by a request initiator, wherein the data read request includes a target IP address, a MAC address of the first storage node, and an identifier of data to be read, wherein the target IP address is a virtual IP address of the first storage node.

[0074] The request initiator may refer to a client, which sends a read request to obtain data stored in the distributed storage system.

[0075] The first storage node is the initial node that receives the client request and is responsible for processing the request logic.

[0076] A virtual IP is a virtual IP address assigned to each storage node in a cluster, allowing clients to communicate with storage nodes in a distributed storage system through a unified address. The request sent by the client uses a virtual IP instead of a specific physical node address. In a distributed storage system, data is usually divided into multiple data blocks and distributed on different nodes. The system uses identifiers to query the specific locations of these data blocks.

[0077] In a possible implementation, in a block storage system, the identifier of the data to be read is a logical block address (Logical Block Addressing, LBA for short). In an object storage system, the object ID can be used to identify a specific object to be read. In a file storage system, data can be identified by a file path or a file name. The embodiment of the present application is described using block storage as an example. It should be noted that the embodiment of the present application is also applicable to object storage and file storage.

[0078] In one possible implementation, a self-loop interface is configured on each storage node, and a virtual IP is allocated to each storage node; the allocated virtual IP address is associated with the local network interface of each storage node through the self-loop interface; and each storage node provides storage services to the request initiator through its virtual IP address.

[0079] In one possible implementation, the communication connection established between the target storage node and the first storage node is also used for: the target storage node sends status information of data reading and data transmission to the first storage node, and the communication connection is established when the first storage node sends the second request to the target storage node; based on the status information, when it is detected that the target storage node data reading failure or data transmission failure fails, the first storage node selects other target storage nodes that store copies of the data to be read to read the data block.

[0080] In a possible implementation, there are multiple target storage nodes. After the target storage node returns the first data block to the request initiator, the target storage node generates a new request according to the target storage node list, the MAC address pointed to by the new request is the MAC address of the next target storage node, and the new request instructs the next target storage node to read and return the second data block stored by itself; the next target storage node is the second target storage node in the target storage node list; the next target storage node retrieves the second data block and returns the retrieved second data block to the request initiator.

[0081] In one possible implementation, when the next target storage node receives a request sent by the first target storage node, the next target storage node establishes a communication connection with the first storage node; the next target storage node sends the data reading status and the data transmission status to the first storage node through the connection; based on the status information, when it is detected that the next target storage node fails to read the data or the data transmission fails, the first storage node selects other target storage nodes to read the data block.

[0082] Combine the following Figure 1 To further illustrate, for example, a client sends a data read request to a distributed storage system, and the data to be read includes data blocks 1, 2, and 3, whose copies are distributed on different storage nodes.

[0083] After the client sends a TCP SYN request, the first storage node among the multiple storage nodes that receives the read / write request sent by the client is the first storage node, and the first storage node may be any storage node in the storage cluster.

[0084] Exemplarily, when the client initiates a data request, the first storage node can be determined based on the load balancing mechanism. The scheduling algorithm of the load balancing mechanism can be polling, minimum number of connections, optimal path, etc., which is not limited in this embodiment of the present application.

[0085] For example, taking the case where the server operating system where the client is located is Windows, the client initiates an access request to the storage resource through the iSCSI Initiator. The iSCSI Initiator is software deployed on the client, responsible for establishing and managing the connection with the storage Target deployed in the storage node. The storage Target is the component on each storage node responsible for processing storage requests, managing the allocation, read and write processing, and data transmission of data blocks. It can be an iSCSI Target or other forms of storage services. The storage Target receives data read and write requests and converts them into operations on storage resources. The client's iSCSI Initiator uses multi-path selection technology to select one from multiple available paths for sending data requests based on predefined strategies (such as polling, minimum number of connections, and other load balancing strategies).

[0086] The client sends a TCP SYN request. After determining the first storage node, try to establish a TCP connection from the source address [ip1, port1] to the target IP address [ip2, port2], where the target address is the virtual IP address of the first storage node. That is, after the connection is established, the Iscsi Initiator establishes a TCP session with the storage Target. The iSCSI Initiator encapsulates the I / O request (such as a read operation) into a SCSI command and sends these commands to the storage Target of the first storage node through the iSCSI protocol. Each SCSI command includes identification information (such as LBA) of the data to be read, the operation type (read operation), etc.

[0087] TCP SYN packet content:

[0088] Source IP: The client's IP address (for example, IP1)

[0089] Source Port: Random port of the client (for example, Port1)

[0090] Destination IP: Virtual IP address of the first storage node (VIP1)

[0091] Target Port: The port on which the first storage node provides services (for example, Port2. Services in a storage cluster usually listen for client requests on a fixed port. This target port is used to ensure that client requests are routed to the correct service. For example, the service port of a distributed storage system may be a specific port (such as 7000), which is the port that the storage service listens on each node in the cluster.)

[0092] Source MAC address: The client's MAC address (for example, MAC1)

[0093] Target MAC address: The MAC address of the target storage node (for example, MAC2). Each storage node includes multiple functional modules, a network request receiving module, a data request distribution module, a data request processing module, a data request forwarding module, and a logging module, which will be described in detail later.

[0094] In an embodiment of the present application, each storage node in the storage cluster includes multiple functional modules for receiving, storing, retrieving and other operations of data.

[0095] In one possible implementation, before parsing the client's request, the network request receiving module in the first storage node verifies the legitimacy of the request, ensures that its source is credible and the format is correct, and records the request receiving time, request content, and sender information.

[0096] The network request receiving module is the module in the storage node responsible for the initial processing of requests. It not only ensures that the request can be correctly parsed and distributed, but also has the functions of exception handling and information recording. Specifically, it includes:

[0097] a) Receive data requests from clients and other storage nodes, including read requests and write requests. It is the entry point for storage nodes to communicate with the outside world, ensuring that all data requests entering the storage node can be correctly received and identified. Perform basic legitimacy checks on received requests to ensure that the request format is correct and preliminarily verify the integrity of the request.

[0098] b) Parse the data content in the request, such as request type, target data, source address, etc. According to the parsing results, pass the message to the appropriate module for processing, including sending the read request to the data request distribution module.

[0099] c) During the parsing or receiving process, if the message format is wrong, the data is incomplete, or other abnormal situations are found, the module will immediately capture these abnormalities and handle the abnormal situations in a timely manner, such as recording abnormal logs, returning error information to the sender, or triggering system-level alarm mechanisms.

[0100] d) When processing each request, record relevant processing information, including the request receiving time, parsing results, distribution results, etc. This can provide a complete record for subsequent operations. If an exception occurs during the processing, record the type of exception, occurrence time, and processing steps in detail.

[0101] In one possible example, the storage target communicates with the client, receives the client's read and write requests and passes these requests to the network request receiving module of the storage node for processing. When a node without a storage target is requested to read data, the network request receiving module can directly return the data to the client through the node's network interface.

[0102] In one possible example, considering that storage nodes need to process hundreds of thousands or even millions of I / O operations per second, the network request receiving module can adopt a multi-threading mechanism. A thread pool is set up in this module, and a certain number of worker threads are created in advance. When a new request arrives, a thread in the thread pool is assigned to process the request. Each thread independently processes the request assigned to it, including parsing the request content, verifying the legitimacy of the request, performing data operations, etc.

[0103] The use of parallel thread processing can significantly improve the system's responsiveness to high-concurrency read requests. When multiple clients simultaneously issue read requests for different data blocks, the network request receiving module on the storage node assigns these requests to multiple parallel threads. Each thread independently processes its assigned requests and communicates directly with the storage node responsible for a specific data block. For example, thread T1 may process requests for data A, while thread T2 processes requests for data B. In this way, the system can fully utilize the advantages of multi-threaded parallel processing to improve overall I / O throughput and performance.

[0104] If multiple threads (such as T1 and T2) access the same data block at the same time, in order to avoid data conflicts or consistency issues, the system will use mutex locks or semaphores when accessing these shared resources. The granularity of the lock can be at the data block level, depending on the application scenario and performance requirements. After each thread independently completes the reading of the data block, it will summarize the results and send them back to the client, thereby improving the concurrent processing capabilities of the entire system. Through multi-threaded processing, the concurrent processing capabilities of the node are greatly improved and the waiting time of the request is reduced.

[0105] Step 302: The first storage node determines a target storage node based on the identifier of the data to be read. The target storage node stores a data block in the data to be read. The virtual IP of the target storage node is the same as the virtual IP of the first storage node.

[0106] The first storage node identifies and locates the target storage node storing the data block by analyzing the identification information of the data to be read contained in the data read request. In other words, the first storage node determines which target storage nodes store the requested data block.

[0107] In a possible implementation, when there is only one target storage node, the first storage node generates a second request and sends it to the target storage node, instructing it to start reading data. After the target storage node finishes reading the data, it directly returns the data to the client.

[0108] In a distributed storage system, data is usually divided into multiple blocks and distributed on different storage nodes. When a client initiates a data read request, after receiving the client's data request, the first storage node first parses and determines which target storage nodes the data blocks are stored on based on the data identification information in the request. The data identification information is, for example, a logical block address (LBA), which is used to identify the unique number of each data block.

[0109] In a possible implementation, when there are multiple target storage nodes, after receiving the first request, the first storage node parses the command content to determine the request type of the client and the location of the target data block (data block to be read). Exemplarily, the first request can be a SCSI command. According to the location of the target data block, the first storage node obtains the target storage node. The target storage node is the node where the required data block is actually stored.

[0110] After receiving the request, the first storage node parses the identifier of the data block to be read (e.g., logical block address LBA). The first storage node queries the metadata list, which records the correspondence between each data block and its storage node. By querying, the first storage node determines which storage nodes each data block is stored on. The metadata list can be located in the first storage node or in the metadata server of the distributed storage system.

[0111] Optionally, the first storage node constructs the storage location information of each data block queried into a data structure, which is usually stored in the form of a list or array, and includes the target storage node information of each data block. This data structure will include the location of each data block and its status (for example: unprocessed). In a possible implementation, the first storage node can send the constructed data structure to the storage node responsible for storing the first data block, that is, the first target storage node.

[0112] For example, in the form of a list [

[0113] ["Data Block 1","Node 1","192.168.1.1","MAC1","Unprocessed"],

[0114] ["Data Block 2","Node 2","192.168.1.2","MAC2","Unprocessed"],

[0115] ["Data block 3","Node 3","192.168.1.3","MAC3","Unprocessed"] ]

[0117] Among them, data block identifier: the identifier of each data block (such as data block 1, data block 2), target storage node: the name of the node storing the data block (such as Node 1), target node IP: the IP address of the target storage node, target node MAC: the MAC address of the target storage node, processing status: the current status of the data block (such as "unprocessed", "completed"). The first storage node generates this list and passes it to the first target storage node (Node 1). For example, the first storage node can obtain the MAC address of each storage node through a static ARP table (configure static ARP mapping in advance, and manually bind the VIP and MAC address of each storage node. The first storage node can look up the corresponding MAC address from the static ARP table.) or a dynamic ARP request (the first storage node obtains the MAC address of the storage node by sending an ARP request.).

[0118] For example Figure 1 As shown, data block 1 of the data to be read is stored in Node 1 (the first target storage node), data block 2 is stored in Node 2 (the second target storage node), and data block 3 is stored in Node 3 (the third target storage node).

[0119] In a possible implementation, the data request distribution module of the first storage node parses the LBA or data identifier in the request and queries the metadata for the corresponding data block storage location. After the parsing is completed, the distribution module generates a target storage node list, which includes the storage node information corresponding to each data block. During the parsing process, if the data identifier is invalid or the mapping relationship is abnormal, the module will record the detailed abnormality type, occurrence time, and processing steps.

[0120] The data request distribution module is responsible for judging and distributing data requests from clients or other devices. This module determines the data's home node by parsing the request and distributes the request to the appropriate processing module according to different situations.

[0121] a) This module can obtain the storage node information of the target data from the metadata information of the storage node. Metadata usually contains information such as the location of the data block and the replication strategy, which is an important basis for determining data ownership. Parse the metadata to determine whether the requested data block belongs to the storage node or whether it needs to be processed across nodes. This step determines the processing path of the data request.

[0122] b) If the requested data belongs to only one storage node (e.g. the primary copy of a data block is stored in this node), the request will be directly distributed to the data request processing module of this storage node for processing. If the data belongs to multiple storage nodes (e.g. the copies of the data block are stored in different storage nodes), the module needs to determine which storage nodes need to participate in the data reading or writing operation, and distribute the request to the data request forwarding module for processing.

[0123] c) During the processing of data requests, all key operation information is recorded, including request parsing results, determination of data ownership nodes, distribution paths of data requests, etc. These records are extremely important for system monitoring, performance analysis, and troubleshooting. If an abnormal situation occurs during the distribution of a request (such as failure to determine the data ownership node, metadata corruption, etc.), the module will record the abnormal information in detail and may trigger the abnormal handling mechanism.

[0124] d) If the data belongs to this storage node, the request is forwarded to the data request processing module of this node, which directly reads or writes the data from the local storage and returns the result. If the data does not belong to this storage node, the module forwards the request to the network request receiving module of the corresponding data belonging storage node.

[0125] In the example, when the client initiates a read request for data A, the request is sent to Node 0 to which it belongs. On Node 0, the data request distribution module parses the data identifier in the request to determine the location where data block A is stored. After confirming that data block A is stored in Node 0, the module forwards the request to the data request processing module of Node 0, which performs the data read or write operation.

[0126] For example, when a client initiates a request for data B, the request may first be received by the network request receiving module of any storage node, such as Node 1. After receiving the request, the data request distribution module of Node 1 will analyze the data identifier in the request and identify the list of storage nodes to which all data blocks of data object B belong (that is, the list of target storage nodes). The list indicates the storage node where each data block in data B is located, for example, the data blocks in data B are stored in Node 1, Node 2, and Node 3 in order. The data request distribution module on Node 1 first checks whether the first data block of data object B is stored locally. If so, the data request processing module of the node will be responsible for reading this data block and sending the data back to the client. At the same time, Node 1 identifies the storage location of other data blocks in data object B, and forwards the request to the next node that stores a copy of the data block according to the list of storage nodes to which it belongs, such as Node 2. After receiving the forwarded request, Node 2 checks and determines whether it has a copy of the next data block specified in the request, and performs the corresponding read operation to return to the client. Node 3 performs the same operation. After the client receives all the data blocks returned in sequence, it correctly assembles them into a complete data object B.

[0127] During the whole process, each storage node reads and returns data independently according to the order of the data blocks it stores until the client receives a copy of all the data blocks of data B. This distributed processing method improves the efficiency and reliability of the system and ensures that the client can receive all the copies of data B from multiple storage nodes in sequence. Each storage node will return its stored part of the data to the client before forwarding the request to the next storage node, thus ensuring the integrity of the data and efficient reading operations.

[0128] In a possible implementation, the data request processing module of the target storage node locates and reads the corresponding data block according to the data block identifier listed in the request, and transmits it to the client. After the reading is completed, the module marks the data block status as "completed".

[0129] The data request processing module is responsible for reading the required data and sending it to the client, including:

[0130] a) When a data request is assigned to this module by the data request distribution module, the data request processing module will read the required data from the storage device of this storage node according to the request content. After the data reading is completed, the module returns the data directly to the client. If it is a write request, the data is written to the storage device of this storage node and then the operation is confirmed to be completed.

[0131] b) After the data request processing of this storage node is completed, the data request processing module will determine whether to continue to pass the remaining requests to other storage nodes based on the progress of the request execution in the target storage node list. If the request involves multiple storage nodes, the module will distribute the remaining requests to the data request forwarding module, which will be responsible for forwarding the remaining requests to the next target storage node for further processing.

[0132] c) During the processing of data requests, the data request processing module will record the processing process in detail, including the start and end time of data reading / writing, the data blocks read / written, the returned results, etc. If an exception occurs during the data reading or writing process (such as storage device failure, data reading failure, etc.), the module will capture and record the exception information and may start the exception handling process to ensure the stability of the system.

[0133] The data request processing module will read the data block and return the data directly to the client. If the request involves multiple data blocks, some of which are not in the local storage node, the module will distribute the remaining requests to the data request forwarding module after completing the data reading of the local storage node, and the latter will continue to process the cross-node data reading operation.

[0134] The data request processing module is responsible for reading or writing data from the local storage device, returning the data to the client or continuing to distribute the remaining requests. This module not only ensures the efficient processing of data requests, but also maintains the stability and reliability of the system through detailed process records and exception handling mechanisms.

[0135] For example, Node 1 receives a data read request from a client, but the requested data is actually stored on Node 3. The forwarding data request module of Node 1 will forward the request to the storage node of Node 3, which will process the data and return it directly to the client. If Node 1 fails to successfully forward the request to Node 3 during the forwarding process (for example, due to network delay or node failure), the data request forwarding module will record the exception and may try to re-forward or feedback the exception to the system management module for further processing.

[0136] The data request forwarding module is a key module in the storage node to ensure that data requests can be correctly delivered to the target node. It ensures smooth data access across nodes in the distributed storage system through accurate request forwarding and exception handling. Whether it is a single data read request or a complex request involving multiple nodes, this module can effectively coordinate communication between nodes and maintain the overall operating efficiency of the system.

[0137] In a possible implementation, if the data block is in the local storage, the data request processing module of the first storage node reads the data block from the local storage, transmits the data block to the client after completing the data reading, and updates the status of the data block in the request list to "completed". If the data block is not in the local storage, the data request processing module will pass the request to the data request forwarding module, and the forwarding module will continue to send the request to the next possible storage node.

[0138] The data request forwarding module is responsible for forwarding data requests that cannot be processed by the current storage node to the target storage node. This module acts as a bridge connecting different storage nodes, ensuring that data requests can be smoothly transmitted to their own storage node, thereby completing the data read or write operation. The functions of this module include:

[0139] a) When the data request processing module or the data request distribution module determines that a data request cannot be processed on the storage node, the request will be forwarded to the data request forwarding module for processing. Based on the data ownership information, the module will forward the data processing request to the corresponding target storage node. For example, if the requested data block is stored on Node 2, the forwarding data request module of Node 1 will forward the request to Node 2. During the forwarding process, the module will ensure that all necessary data information and customer request information are accurately delivered to the target node, including request type, data identification, etc.

[0140] b) During the forwarding process, the data request forwarding module will record the forwarding process in detail, including the time the request was received, the target node for forwarding, the results of the forwarding, and other information. These records help track the flow and processing status of data requests. If an exception occurs during the forwarding process (such as a network failure, the target storage node is unreachable, etc.), the module will record the exception information and may trigger an alarm or retry mechanism to ensure that the data request can eventually reach the target storage node. Optionally, the logging module of the first storage node records the reading and forwarding status of each data block, including detailed information such as the time the processing was completed and the storage node used. The logging module provides a complete record of operations throughout the process.

[0141] The logging module collects and summarizes log information from the network request receiving module, data request distribution module, data request processing module, and data request forwarding module. This module collects log information generated by other modules, including detailed information of data requests, system behavior data, abnormal situations, etc. When an abnormal situation occurs in the system, the relevant module will generate an abnormal log, which will be collected and stored by the logging module for subsequent analysis. For example, when the client initiates a data write request, the data request processing module will record the detailed information and processing status of the request, which will then be summarized by the logging module. If an exception occurs during the processing, such as a network interruption, the data request forwarding module will record the exception, and the logging module will summarize it for troubleshooting.

[0142] It should be noted that the logging module may also have an independent logging function, which can directly capture and record system events and operations, such as recording performance monitoring data, detecting and recording system anomalies, etc.

[0143] Step 303: The first storage node generates a second request according to the data read request, wherein the second request includes a target IP address, a MAC address of the target storage node, and an identifier of a data block stored by the target storage node; the second request is used to instruct the target storage node to send the data block stored by itself to the request initiator. The first storage node sends the second request to the target storage node.

[0144] According to the target storage node list, the first storage node determines that the target storage node stores the first data block requested by the client. The first storage node generates a second request based on the information, and the second request includes the IP address of the target storage node, the MAC address of the target storage node, and the identifier of the first data block stored by the target storage node. In this process, the first storage node constructs the second request based on the information in the target storage node list, sets the target to the IP address and MAC address of the first target storage node, and includes the corresponding data block identifier.

[0145] In one possible implementation, the data request forwarding module in the first storage node generates and distributes the request to the target storage node according to the parsing result. The request distribution module records the request distribution time, distribution result and processing status. It is also responsible for marking the status of data block processing as "completed" or "uncompleted" and recording the current processing progress in the request information. In each request forwarding operation, the request distribution module records the response time and data block processing status of each target storage node for monitoring and tracking in subsequent operations.

[0146] The first storage node does not change the source IP and target IP of the request packet, selects the target storage node through direct routing, and forwards the request to the target storage node. Exemplarily, the first storage node modifies the target MAC address of the TCP SYN packet according to the link layer protocol, changing it from its own MAC address to the MAC address of the first target storage node in the target storage node list.

[0147] Contents of a data packet sent by the first storage node to the first target storage node;

[0148] Source IP: remains unchanged, the client's IP address (for example, IP1)

[0149] Destination IP: remains unchanged, the virtual IP address of the first storage node (VIP1)

[0150] Target port: remains unchanged, the port provided by the first storage node (for example, Port2.)

[0151] Source MAC address: MAC address of the first storage node (e.g., MAC2)

[0152] Destination MAC Address: The MAC address of the first destination storage node (for example, MAC3)

[0153] Data content: The TCP SYN packet forwarded by the first storage node contains a list of target storage nodes and pending requests. After receiving the request from the first storage node, the first target storage node parses the request content and extracts the data block identifier and operation type. This information instructs the target storage node to locate the specific data block that needs to be accessed in the storage device. The storage target maps the data block identifier to the actual physical storage address, reads the specified data block, and passes the data back to the iSCSI service at the application layer.

[0154] According to the content in the target storage node list, the first target storage node identifies the data block it needs to process. For example, the first target storage node needs to process data block 1. The target storage node maps the identifier of data block 1 to the actual physical storage address, completes the data block reading, and updates the reading status to "completed".

[0155] In a possible implementation, the first target storage node confirms whether the requested data block exists in the local storage. If the data block exists, the first target storage node generates a TCP SYN-ACK response packet. After the client receives the TCP SYN-ACK response from the first target storage node, it sends back a TCP ACK packet to confirm that the TCP connection between the client and the first target storage node is formally established.

[0156] The first target storage node establishes a connection with the client. The content of the TCP SYN-ACK packet is:

[0157] Source IP: Virtual IP address of the first storage node (VIP1)

[0158] Destination IP: The client's IP address (for example, IP1)

[0159] Source port: The port of the first target storage node. This port is the port that the storage service that communicates with the client listens on (same as the original target port)

[0160] Destination Port: The client's port (for example, Port1, which is the same as the source port in the TCP SYN request originally sent by the client.)

[0161] Source MAC address: The MAC address of the first target storage node (for example, MAC3)

[0162] Destination MAC Address: The client's MAC address (e.g., MAC1)

[0163] Data content: TCP SYN-ACK packet, used to confirm the connection with the client.

[0164] After receiving this packet, the client sends an ACK packet to complete the TCP three-way handshake and formally establish a connection with the first target storage node. The data transmission phase of the data packet of the first target storage node begins, and the first target storage node will directly return the read data to the client without passing through the first storage node.

[0165] Optionally, after transmitting the corresponding data block to the client, the first target storage node updates the request information and marks the processed data block as processed. For example, if the first target storage node processes LBA1000 to 1999 (that is, the range of data block 1), the remaining requests involve LBA2000 to 3999 (that is, the range of the remaining data blocks), where the data block range is identified by the logical block address (LBA), and this part will be forwarded to the next target storage node. The first target storage node updates the target storage node list, and the updated list contains the request part that has not been processed and the request part that has been processed.

[0166] Optionally, after transmitting the processed corresponding data blocks to the client, the first target storage node will update the request information and mark the processed data blocks as "completed". For example, if the first target storage node processes data block _1, the status of the data block will be updated to "completed" in the request information. The remaining data blocks to be processed in the request information will be processed by the next target storage node.

[0167] Optionally, the first target storage node updates the target storage node list, and the updated list includes the status of the data blocks that have not been processed and the data blocks that have been processed. Then, the first target storage node passes the updated list to the next target storage node to ensure that the request is completed step by step.

[0168] The embodiment of the present application provides a method of modifying the MAC address of the link layer to guide the traffic directly to the target storage node, avoiding unnecessary data forwarding between nodes, improving network efficiency, and reducing the load of the first storage node so that it only needs to handle the distribution of the initial request. The first storage node transfers the processing of the request to the target storage node (Node 1, Node2, Node3), and allows the target storage node to communicate directly with the client, because the subsequent data traffic no longer passes through the first storage node, reducing the load of the first storage node. The client reads data directly from the node responsible for storing data, and the system can handle tens of thousands of concurrent requests at the same time without causing bottlenecks due to excessive load on a single node.

[0169] By modifying the MAC address of the data packet, the traffic is routed from the first storage node to the target storage node, and from the target storage node to the client, ensuring efficient data transmission. In this process, most layers in the system's protocol stack, including the session layer, presentation layer, and application layer, the protocol and data format remain unchanged. The high-level protocol behaviors such as the TCP connection between the client and the storage node, HTTP requests and responses, etc. have not changed, and the upper-layer protocols are still executed according to their standards.

[0170] The link layer achieves traffic redirection by modifying the destination MAC address of the data packet. After receiving the request, the first storage node changes the destination MAC address from its own MAC address to the MAC address of the target storage node. This operation ensures that the data packet can be correctly forwarded to the target node without any changes through the high-level protocol.

[0171] The link layer also binds the VIP (virtual IP) to the MAC address of the storage node. Through this binding, the client's data packets can still be correctly routed to the actual storage node at the link layer even if the destination IP remains VIP. This binding ensures transparency in the network. The client still perceives the communication with the VIP, while the link layer handles the actual routing work.

[0172] Through the data reading method provided in the embodiment of the present application, only the MAC address of the link layer changes between different storage nodes, while the network layer, transport layer and higher-level protocol stacks are not affected, which effectively improves network performance, reduces unnecessary data traffic between storage nodes, and improves the throughput of the overall system.

[0173] After the reading is completed, the first target storage node packages the first data block read and returns it directly to the request initiator (i.e., the client) through the network without being transferred through the first storage node. This helps to reduce latency and optimize traffic. For example, after the first target storage node reads and returns the first data block it stores, the returned data packet includes: the virtual IP address of the target storage node, the data block identifier, the data content, the response status code, etc.

[0174] Figure 4 A flowchart of a reading scenario in which the data to be read is located in a target storage node is provided in an embodiment of the present application. Figure 4 As shown,

[0175] When a client issues a data read request, a multi-path selection algorithm is used to determine which storage node to send the request to. This can be based on a multi-path selection strategy to select the node with the smallest communication delay with the client and the best bandwidth under the current network conditions as the first storage node. A load balancing strategy may also be used to select the first storage node. By monitoring the current load of each storage node (such as CPU usage, I / O load, etc.), the request is assigned to the storage node with a lighter load to balance the working pressure of the overall system. Alternatively, a storage node that is physically close to the client or in the same network topology is selected to reduce network transmission delays. This application does not impose any restrictions on this.

[0176] For example, the client initiates a read request and sends the request to the storage Target 0 of Node 0 through the network. At this time, Node 0, as the initial receiving node, is responsible for processing and parsing the request.

[0177] After Node 0 storage node parses the request, it forwards the request to the target storage node Node 1 that actually stores the data.

[0178] For example, Node 0 uses metadata or a distribution strategy (such as the CRUSH algorithm) in the system to determine the actual storage locations of these data blocks or objects.

[0179] After Node 0's storage target 0 parses the request, it determines that the primary copy of the data block is stored on Node 1. Therefore, storage target 0 forwards the request to storage target 1 on Node 1.

[0180] In the embodiment of the present application, because the data requested to be read are all stored in Node 1, the target storage node only includes one storage node Node 1. After receiving the forwarded request, the storage Target 1 of Node 1 sends a data read request to the OSD.1 (master) of the storage node. OSD.1 is responsible for reading data from the local storage and returning the data to the storage Target 1.

[0181] After receiving the data from OSD.1, Target 1 of Node 1 directly returns the data to the client through the network. In this way, the client gets the requested data without the need for re-aggregation and forwarding by Node 0, thus avoiding the centralized processing of data traffic and improving the overall performance and response speed of the distributed storage system.

[0182] It should be noted that if Target 1 is not stored in Node 1, Node 0 forwards the read request to OSD 1 of Node 1 to read the data block. After receiving the request, Node 1 reads the stored data block and returns the data block to the client. Because the data stream will not be transmitted across nodes through Node 0, the efficiency of data transmission is guaranteed.

[0183] Figure 5 1 is a schematic diagram of a data read request process provided by an embodiment of the present application. It aims to optimize the data access efficiency and reliability in a distributed storage system. The process involves a series of interactions between the client and the storage node to ensure efficient processing and rapid response of data requests. Figure 5 As shown,

[0184] When a client initiates a data read request, the request is first sent to the first storage node. In the storage node, the network request receiving module is responsible for receiving and parsing the request from the client. After the parsing is completed, the request is forwarded to the data request distribution module, which determines whether the data required by the request is available on the current storage node.

[0185] If the data request distribution module determines that the required data is accessible in this storage node, it passes the request to the data request processing module. This module is responsible for reading the corresponding data and sending it back to the client. During the whole process, the network request receiving module records the message reception record in detail for subsequent monitoring and analysis.

[0186] If the requested data is not stored in the first storage node, the data request distribution module of the first storage node will trigger the data request forwarding module and further forward the request to the target storage node. In this process, the data request forwarding module can construct a forwarding structure and record message processing records to track the status and history of the request. The forwarding structure is constructed according to the target storage node list information described above.

[0187] After the first storage node forwards the remaining requests to the target storage node, the network request receiving module of the target storage node parses the request and passes the request to the data request distribution module. This module performs data availability judgment. If the data is available on the target storage node, the data request processing module is notified to read the data, construct the data structure, and then send the data directly back to the client. At the same time, the network request processing module records the cross-node message, the data request distribution module records the processing progress, and returns the request processing progress to the data request forwarding module of the first storage node for further monitoring and management.

[0188] The data read request flow diagram provided in the embodiment of the present application optimizes the data interaction mode between storage nodes by intelligently distributing and forwarding requests between storage nodes, effectively reduces the data transmission traffic between storage nodes, and significantly improves the performance and response speed of the distributed storage system. In addition, the detailed recording and monitoring mechanism provides strong support for the operation and management of the system.

[0189] In a distributed storage system, the complexity of data read operations often depends on the number of data blocks involved in the request and their distribution. Next, we will analyze several typical data read scenarios in detail. These scenarios not only cover scenarios where the request involves multiple data blocks, where these data blocks may be scattered on different storage nodes, but also include scenarios where the request is for a single data block.

[0190] Figure 6 A method flow chart of another data reading method provided in an embodiment of the present application. Figure 6 As shown, this embodiment can be applied in a distributed storage system. The data reading method provided in the embodiment of the present application includes at least the following steps:

[0191] Step 601: A first storage node receives a data read request sent by a request initiator, wherein the data read request includes a target IP address, a MAC address of the first storage node, and an identifier of data to be read, wherein the target IP address is a virtual IP address of the first storage node.

[0192] Please refer to the description of step 301 for details, which will not be repeated here.

[0193] Step 602: The first storage node determines a target storage node based on the identifier of the data to be read. The target storage node stores a data block in the data to be read. The virtual IP of the target storage node is the same as the virtual IP of the first storage node.

[0194] Please refer to the description of step 302 for details, which will not be repeated here.

[0195] Step 603: The first storage node generates a second request according to the data read request, the second request including the target IP address, the source IP address, the MAC address of the first target storage node and the identifier of the data block stored by the first target storage node; the second request is used to instruct the first target storage node to send the data block stored by itself to the request initiator. The first storage node sends the second request to the target storage node.

[0196] After receiving the data read request, the first storage node generates a second request based on the request.

[0197] Exemplarily, the second request may include:

[0198] Target IP address: the IP address of the target storage node.

[0199] Source IP address: the IP address of the first storage node,

[0200] MAC address of the target storage node: corresponds to the physical layer address of the target storage node, used for link layer communication to ensure that the request reaches the node accurately.

[0201] Data block identifier: indicates a specific data block stored on the target storage node, so as to indicate the specific data block to be processed by the target node.

[0202] In a possible implementation, the first storage node only queries the location of the first data block: after the read request initiated by the client reaches the first storage node, the first storage node only queries and locates the storage node of the first data block to be processed. For example, the query finds that data block 1 is located at Node 1.

[0203] The first storage node sends a request to Node 1, requesting it to process data block 1 and return the data. After Node 1 processes and transmits data block 1 to the client, it continues to query the location of the next data block listed in the request (for example, data block_2) to determine which target node the data block is stored in.

[0204] In one possible implementation, Node 1 marks data block 1 as "completed" and updates the request information. It then forwards the request to the storage node where data block 2 is located (e.g., Node 2) and includes the updated status information in the request. Each subsequent target storage node repeats the process, processes its own data block in turn, marks the status as "completed", and finds the location of the next data block, forwarding the request to the next storage node until all data blocks are processed and returned to the client.

[0205] Step 604: The first target storage node generates a third request according to the second request, the third request including the target IP address, the source IP address, the MAC address of the second target storage node, and the identifier of the data block stored by the second target storage node; the third request is used to instruct the second target storage node to send the data block stored by itself to the request initiator. The first target storage node sends the third request to the second target storage node.

[0206] In a possible implementation, when there are multiple target storage nodes, a first target storage node receives a data request from a first storage node, parses the request, and distributes the request to a second target storage node for processing.

[0207] After the first target storage node completes its own data block processing, it will create a new request and send it to the next target storage node in sequence. The request contains an updated list of target storage nodes, which indicates the processed data blocks and the data blocks that have not yet been processed. Similarly, after receiving this request, the next target storage node will check the data block identifiers in the target storage node list to determine the part of the data block it is responsible for. For example, Node3 will determine the content that needs to be processed based on the data block identifier in the list (such as data block 3), and then locate and read the data block in its physical storage, and update the status to "completed" after processing. The processed data block will be returned directly to the client, and the updated request information will continue to be passed to the next target storage node until all data blocks have been read.

[0208] After the first target storage node processes the data block stored in itself and returns it to the client, it generates a third request based on the received second request and sends the third request to the second target storage node. The third request may include the following information:

[0209] Target IP address: the IP address of the second target storage node, used to correctly route the request to the next target storage node.

[0210] Source IP address: The IP address of the first target storage node, which enables the second target storage node to identify the sender of the request.

[0211] MAC address of the second target storage node: used to accurately transmit the request to the second target storage node at the link layer.

[0212] Data block identifier: indicates the specific data block that the second target storage node needs to process, and specifies the data content to be read.

[0213] In this way, after completing its own reading task, each target storage node generates and transmits subsequent requests, and gradually passes the requests to the next storage node, ensuring that all data blocks are read on demand and returned directly to the client, reducing unnecessary transit traffic and achieving efficient distributed data transmission.

[0214] Figure 7 A flowchart of another data reading process provided by the embodiment of the present application is shown below. Figure 7 As shown, the initial storage node does not store any data blocks of the data to be read, so the read request is forwarded to the first target storage node among the target storage nodes.

[0215] The client initiates a read request to read Block 1, Block 2, and Block 3. Block 1 is stored in OSD 0 of Node 1, Block 2 is stored in OSD 1 of Node 2, and Block 3 is stored in OSD 2 of Node 3. The read request issued by the client first reaches Node 0. As the initial receiving node, Node 0 determines that the target data blocks to be read are Block 1, Block 2, and Block 3. Node 0 queries metadata or uses a data distribution strategy (such as the CRUSH algorithm) to determine where these data blocks are stored:

[0216] Block 1 is stored in OSD 0 of Node 1.

[0217] Block 2 is stored in OSD 1 of Node 2.

[0218] Block 3 is stored in OSD 2 of Node 3.

[0219] Based on the query results, Node 0 builds a target storage node list, which records the storage node of each data block and the progress information of the current read request.

[0220] Node 0 forwards the request to read Block 1 to Node 1 according to the target storage node list. Node 0 also passes the target storage node list and the remaining requests (i.e., the read requests for Block 2 and Block 3) to Node 1.

[0221] After receiving the request and the target storage node list, Node 1 resolves that it needs to process Block 1. Node 1's storage Target 1 reads Block 1's data from OSD 0. After the reading is complete, the data of Block 1 is directly returned to the client. At the same time, Node 1 updates the target storage node list, marks that Block 1 has been read, and forwards the remaining requests to Node 2 to continue processing Block 2.

[0222] Node 2 receives the request forwarded by Node 1 and the updated target storage node list. The target storage node list shows that Block 1 has been read and Node 2 needs to process Block 2. Node 2's storage Target 2 reads Block 2 from OSD 1. After Node 2 completes the reading, it also returns the data of Block 2 directly to the client.

[0223] Node 2 updates the target storage node list again, marks that Block 2 has completed reading, and forwards the remaining request (i.e., reading Block 3) and the updated target storage node list to Node 3.

[0224] Node 3 receives the request forwarded by Node 2 and the target storage node list. The list shows that Block 1 and Block 2 have been read, and the remaining request is to read Block 3. Node 3's storage Target 3 reads Block 3's data from OSD 2. Node 3 returns Block 3's data to the client, completing the task of reading all data.

[0225] Finally, Node 3 updates the target storage node list, marks Block 3 as completed, and notifies the end of the entire reading process.

[0226] The client receives data of Block 1, Block 2, and Block 3 from Node 1, Node 2, and Node 3 in sequence.

[0227] The client reassembles the data blocks into complete data according to the order of the data blocks and completes the read request.

[0228] In this case, since Node 0 does not store any data blocks requested by the client, Node 0 forwards the request to the correct target storage node after receiving it. Finally, each target storage node (Node 1, Node 2, Node 3) processes its own data block read request and returns the data block directly to the client. Through this mechanism, the system can effectively process data read requests in a distributed environment, reduce unnecessary data transmission and inter-node communication, and improve the efficiency of data access.

[0229] In a possible implementation, when all the data blocks to be read are stored in the same storage node, the client's request can be directly processed by the storage node. After receiving the request, the node reads all the data blocks and returns the data directly to the client through its network request receiving module.

[0230] Figure 8 A flowchart of another data reading method provided in an embodiment of the present application is shown below. Figure 8 As shown, this embodiment can be applied in a distributed storage system. The data reading method provided in the embodiment of the present application includes at least the following steps:

[0231] Step 801: A first storage node receives a data read request sent by a request initiator, wherein the data read request includes a target IP address, a MAC address of the first storage node, and an identifier of data to be read, wherein the target IP address is a virtual IP address of the first storage node.

[0232] Please refer to the description of step 301 for details, which will not be repeated here.

[0233] Step 802: The first storage node determines a target storage node based on the identifier of the data to be read. The target storage node stores a data block in the data to be read. The virtual IP of the target storage node is the same as the virtual IP of the first storage node.

[0234] Please refer to the description of step 302 for details, which will not be repeated here.

[0235] Step 803: The first storage node generates multiple second requests according to the data read request, each second request corresponds to a target storage node, and each second request includes a target IP address, a source IP address, a MAC address of the corresponding target storage node, and an identifier of a data block stored by the corresponding target storage node; the second request is used to instruct the corresponding target storage node to send the data block stored by itself to the request initiator. The first storage node first sends a second request to each target storage node.

[0236] For each target storage node, the first storage node generates a second request. Each second request includes the following content:

[0237] Target IP address: the IP address of the target storage node.

[0238] Source IP address: the IP address of the first storage node,

[0239] MAC address of the target storage node: used for link layer communication so that the data request can be correctly transmitted to the target node.

[0240] Data block ID: Indicates the specific data block ID stored on the target storage node so that the target node knows the data to be read.

[0241] The first storage node sends these second requests to each target storage node respectively. After receiving the second request, each target storage node parses the data block identifier and checks whether the data block is stored locally. If the data block is in the local storage, the data request processing module of the target storage node directly reads the data block from the local storage and sends the data to the client.

[0242] In this way, multiple target storage nodes can transmit their respective data blocks to the client in parallel, reducing the load of the first storage node and lowering the transmission delay.

[0243] The log recording module of the first storage node records the sending status of each second request and the response status of each target storage node to ensure that the read requests of all data blocks are successfully completed.

[0244] Fig. 9 A flowchart of another data reading process provided by the embodiment of the present application is shown below. Fig. 9 As shown in the figure, the client initiates a read request to read data blocks Block 1, Block 2, and Block 3. These data blocks are stored in different storage nodes: Block 1 is stored in OSD 0 of Node 1, Block 2 is stored in OSD 1 of Node 2, and Block 3 is stored in OSD 2 of Node 3.

[0245] The client's read request first arrives at Node 0 (the first storage node). Next, Node 0 determines the data storage location based on the target data block identifier (Block 1, Block 2, and Block 3) of the request, generates multiple second requests, and sends these requests to the corresponding target storage nodes in sequence.

[0246] Node 0 queries metadata or determines the location information of the target storage node through a data distribution strategy (such as the CRUSH algorithm). Node 0 generates a second request for each target storage node based on the storage location of the data block. Each request contains the necessary information to read the specified data block. Node 0 sends these requests to each target storage node in turn. The generated second request includes:

[0247] Request 1 (read Block 1): Target IP address: Node 1's IP address, Source IP address: Node 0's IP address, Target MAC address: Node 1's MAC address, Data block identifier: Block 1's identifier.

[0248] Request 2 (read Block 2): Target IP address: Node 2's IP address, Source IP address: Node 0's IP address, Target MAC address: Node 2's MAC address, Data block identifier: Block 2's identifier.

[0249] Request 3 (read Block 3): Target IP address: IP address of Node 3, Source IP address: IP address of Node 0, Target MAC address: MAC address of Node 3, Data block identifier: Block 3 identifier.

[0250] Node 1 receives the request to read Block 1, parses the request, reads the data of Block 1 from OSD 0, and returns the data directly to the client.

[0251] Node 2 receives the request to read Block 2, parses the request, reads the data of Block 2 from OSD 1, and returns the data directly to the client.

[0252] Node 3 receives the request to read Block 3, parses the request, reads the data of Block 3 from OSD 2, and returns the data directly to the client.

[0253] The client receives the data of Block 1, Block 2, and Block 3 from Node 1, Node 2, and Node 3 in sequence. The client reassembles the data blocks into complete data according to the order and completes the read request. By passing the requests in this order, Node 0, as the initial storage node, generates multiple second requests according to the storage location of the target data block and sends these requests to different target storage nodes in sequence. After receiving the request, each target storage node will independently process the corresponding data block reading task and return the result to the client. This method simplifies the interaction between storage nodes, avoids unnecessary data transmission, and improves the efficiency of data access.

[0254] Fig.10 A flow chart of data reading exception handling provided in an embodiment of the present application. In a distributed storage system, if an exception occurs during data reading, the system needs to execute a specific exception handling process. After the first forwarding fails to obtain data, other available storage nodes will no longer be tried, because this situation is usually a node or disk exception, and there is no way to recover in a short time.

[0255] Furthermore, in the embodiment of the present application, the first storage node and the target storage node can communicate in real time, the first storage node can grasp the status of data reading in real time, and can better perform abnormal management.

[0256] Specifically, after the first target storage node establishes a connection with the client, it will maintain the connection established with the first storage node or create a new communication connection. The first storage node can communicate with the target storage node in real time. The first storage node can grasp the status of data reading in real time and better manage exceptions.

[0257] For example, the first target storage node may establish a separate TCP connection with the first storage node, and the connection is used to transmit processing status, error reports, or other related information.

[0258] Packet Contents:

[0259] Source IP: IP address of the first target storage node

[0260] Source port: The port provided by the first target storage node (for example, Port2.)

[0261] Target IP: IP address of the first storage node

[0262] Target port: The port that the first storage node provides services on (for example, Port2.)

[0263] Source MAC address: The MAC address of the first target storage node (for example, MAC3)

[0264] Destination MAC address: MAC address of the first storage node (e.g., MAC2)

[0265] Data content: Feedback information, including data reading status, error information or other relevant status updates.

[0266] For example, the first target storage node may communicate with the first storage node using an established TCP connection.

[0267] It should be noted that other methods may also be used to establish a connection between the first storage node and the first target storage node, and the embodiments of the present application do not limit this.

[0268] like Fig.10 As shown, the client initiates a read request and sends the request to the storage Target 0 of Node 0 through the network. The storage Target 0 of Node 0 parses the request and confirms that the primary copy of the data block is stored on OSD 1 (primary) of Node 1.

[0269] Node 0 forwards the read request to Node 1's storage target 1. After receiving the request, Node 1's storage target 1 attempts to read data from OSD 1.

[0270] Since OSD 1 is unavailable (such as disk failure or node failure), storage target 1 refuses to receive and process the request and returns an error status to Node 0. After receiving the error status returned by Node 1, storage target 0 of Node 0 may no longer retry other available nodes, because the node cannot be restored in a short time due to node or disk abnormality. Or try to obtain data copies from other available nodes.

[0271] Node 0 checks whether there are other nodes in the system that store copies of the data block (such as Node 2, Node 3, etc.), and tries to resend the read request.

[0272] If another node (such as Node 2) is available, Node 0 forwards the read request to Node 2's storage Target2, reads the data from its OSD and returns it to the client. During the data reading process, Node 2 maintains real-time communication with Node 0 and promptly feeds back the reading progress to Node 0. This communication ensures that Node 0 can monitor the status of data reading at any time and can make adjustments and handle exceptions based on the feedback information. Through this mechanism, Node 0 can effectively grasp the operating status of each storage node, so as to initiate fault tolerance processing when necessary, especially when encountering unavailable nodes during the reading process, remedial measures can be taken quickly.

[0273] When Node 2 finishes reading the data, for example, updating the target storage node list, it upgrades the secondary copy of Block 1 (OSD 2 of Node 2) to the new primary copy, and marks OSD 1 of Node 1 as unavailable.

[0274] During the whole process, Node 2 reports its processing progress and the update of the replica status to Node 0 in real time. Through this feedback, Node 0 can continuously monitor the entire data reading process and perform global optimization and exception management based on the node status information. Through this real-time communication and status update mechanism, Node 0 ensures that the latest metadata information can be used at the next client request, ensuring the efficiency and fault tolerance of system operation.

[0275] If Node 0 fails to resend the request to other nodes (i.e., no other nodes are available, or all nodes are faulty), Node 0 returns an exception message to the client, indicating that the data is unavailable. After receiving the exception response, the client can perform subsequent processing according to the specific situation (such as retrying the request, recording a log, or notifying the user).

[0276] A strategy for handling data read anomalies in a distributed storage system. By trying to read replica data from other nodes, the system can improve fault tolerance and data availability. However, when all nodes or replicas are unavailable, the system will return exception information to the client to ensure that abnormal situations can be reported in a timely manner while ensuring data availability as much as possible.

[0277] It should also be noted that during the processing, if an exception occurs, the target storage node will immediately capture and handle these exceptions through the exception handling module, and record relevant information (such as exception type, occurrence time, processing steps, etc.) in the log system, and send the exception status back to the first storage node. At the same time, under normal circumstances, the target storage node will also send data reading and transmission status information to the first storage node, so that the first storage node can track the processing progress and transmission status of each data block in real time.

[0278] Specifically, the status information includes:

[0279] Request reception status: The target storage node confirms whether the request from the first storage node is successfully received. If the request is received normally, the "reception success" status is returned; if the request is not successfully received or a parsing error occurs, the "reception failure" or "request rejection" status is returned.

[0280] Data processing status: The status information returned by the target storage node includes the processing progress of the data block in the request. The processing status includes "reading", "read completed" or "read failed" to indicate the processing status of the data block.

[0281] Data transfer status: After the data block is transferred to the client, the target storage node returns the transfer status information. The transfer status includes "transfer started", "transferring", "transfer completed" or "transfer failed", etc., to indicate the progress of the data block transfer process.

[0282] Abnormal status: If the target storage node encounters an abnormal situation during data reading or transmission, the status information includes the abnormal status, such as "transmission interruption", "storage device unavailable" or "network error", etc., and is accompanied by the specific type of abnormality and the time of occurrence.

[0283] This state communication connection is established when the first storage node sends a second request to the target storage node. On this connection, for example, the target storage node notifies the first storage node that it has received the request and starts reading the specified data block; if there is segmentation or long delay in data transmission, the target storage node can send transmission progress updates regularly; when the target storage node successfully transmits the data block to the client), it will send a completion status so that the first storage node can confirm that the processing of the data block has been completed; if an exception occurs during the reading or transmission process, the target storage node will immediately send the exception status information, including the exception type, handling measures, etc., so that the first storage node can take corresponding measures in time.

[0284] See also Fig.11 The embodiment of the present application provides a storage node 1100, including a network request receiving module 1110, which is used to receive a data read request sent by a request initiator, the data read request includes a target IP address, a MAC address of a first storage node and an identifier of the data to be read, wherein the target IP address is a virtual IP of the first storage node. A data request distribution module 1120 is used to determine a target storage node according to the identifier of the data to be read, the target storage node stores a data block in the data to be read, and the virtual IP of the target storage node is the same as the virtual IP of the first storage node. A data request forwarding module 1130 generates a second request according to the data read request, the second request includes a target IP address, a MAC address of a target storage node and an identifier of a data block stored by the target storage node; the second request is used to instruct the target storage node to send back the data block stored by itself to the request initiator. The data request forwarding module 1130 is also used to send a second request to the target storage node.

[0285] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0286] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0287] It is understandable that the size of the sequence number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. In addition, in some possible implementations, each step in the above embodiment can be selectively executed according to actual conditions, and can be partially executed or fully executed, which is not limited here.

[0288] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0289] An embodiment of the present application also provides a computing device, which executes the method provided in any of the above embodiments.

[0290] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0291] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

[0292] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

Claims

1. A data reading method, characterized in that: The first storage node receives a data read request sent by a request initiator, wherein the data read request includes a target IP address, a MAC address of the first storage node, and an identifier of the data to be read, wherein the target IP address is a virtual IP address of the first storage node; The first storage node determines a target storage node based on the identifier of the data to be read, the target storage node stores a data block in the data to be read, and the virtual IP of the target storage node is the same as the virtual IP of the first storage node; The first storage node generates a second request according to the data read request, wherein the second request includes a target IP address, a MAC address of the target storage node, and an identifier of a data block stored by the target storage node; the second request is used to instruct the target storage node to send the data block stored by itself to the request initiator; The first storage node sends the second request to the target storage node.

2. The method according to claim 1, characterized in that When there are multiple target storage nodes determined by the first storage node, the first storage node generates a second request according to the data read request, including: The first storage node generates multiple second requests based on the data read request, each second request corresponds to a target storage node, and each second request includes a target IP address, a source IP address, a MAC address of the corresponding target storage node, and an identifier of a data block stored by the corresponding target storage node; the second request is used to instruct the corresponding target storage node to send the data block stored by itself to the request initiator.

3. The method according to claim 1, characterized in that: When there are multiple target storage nodes determined by the first storage node, the target storage nodes include a first target storage node and a second target storage node, and the first storage node generates a second request according to the data read request, including: The first storage node generates a second request according to the data read request, wherein the second request includes a target IP address, a source IP address, a MAC address of the first target storage node, and an identifier of a data block stored by the first target storage node; the second request is used to instruct the first target storage node to send the data block stored by itself to the request initiator; The first target storage node generates a third request based on the second request, and the third request includes the target IP address, the source IP address, the MAC address of the second target storage node and the identifier of the data block stored by the second target storage node; the third request is used to instruct the second target storage node to send the data block stored by itself to the request initiator.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The first storage node obtains the status information sent by the target storage node, where the status information is used to indicate whether the target storage node has successfully read a data block of the to-be-read data stored in itself.

5. The method according to any one of claims 1 to 4, characterized in that: The first storage node determines a target storage node based on the identifier of the data to be read, specifically including: The first storage node identifies a target storage node storing the data block according to the metadata list, wherein the metadata list is used to record the location of each data block and its corresponding storage node information.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: If the first storage node stores a data block in the data to be read, the first storage node reads the data block from local storage and sends the data block to the request initiator.

7. A data reading method, applied to a first target storage node, characterized in that: Receive a second request sent by the first storage node, where the second request includes a target IP address, a MAC address of the first target storage node, and an identifier of a data block stored by the target storage node; The second request is used to instruct the first target storage node to send the data block stored in itself to the request initiator, and the target IP address is the virtual IP address of the first storage node; Sending the data block stored in the request initiator to the request initiator; Generate a third request according to the second request, the third request including a target IP address, a source IP address, a MAC address of the second target storage node, and an identifier of a data block stored by the second target storage node; the third request is used to instruct the second target storage node to return the data block stored by itself to the request initiator; Send the third request to the second target storage node.

8. A storage node, characterized in that: include: A network request receiving module, used to receive a data reading request sent by a request initiator, wherein the data reading request includes a target IP address, a MAC address of the first storage node, and an identifier of the data to be read, wherein the target IP address is a virtual IP address of the first storage node; A data request distribution module, used for determining a target storage node according to the to-be-read data identifier, wherein the target storage node stores a data block in the to-be-read data, and the virtual IP of the target storage node is the same as the virtual IP of the first storage node; A data request forwarding module generates a second request according to the data read request, wherein the second request includes a target IP address, a MAC address of the target storage node and an identifier of a data block stored by the target storage node; the second request is used to instruct the target storage node to send back the data block stored by itself to the request initiator; and the second request is sent to the target storage node.

9. A distributed storage system, comprising a first storage node and a target storage node, characterized in that: include: The first storage node is used to receive a data read request sent by a request initiator, the data read request includes a target IP address, a MAC address of the first storage node and an identification of the data to be read, wherein the target IP address is a virtual IP of the first storage node; and based on the identification of the data to be read, determine a target storage node, the target storage node stores a data block in the data to be read, and the virtual IP of the target storage node is the same as the virtual IP of the first storage node; generate a second request according to the data read request, the second request includes a target IP address, a MAC address of the target storage node and an identification of the data block stored by the target storage node; the second request is used to instruct the target storage node to send the data block stored by itself to the request initiator; send the second request to the target storage node; The target storage node is used to receive the second request sent by the first storage node, and send the data blocks stored in the target storage node to the request initiator.

10. A computing device, characterized in that: The computing device executes the method according to any one of claims 1-6.

Images