Write request response method and electronic device

Abstract

This application discloses a write request response method and electronic device, relating to the field of storage technology. The method includes: after detecting a failure in a first node, a quiescent operation can be performed on a second node, allowing the second node to enter a quiescent state. During a first time period between the first moment the first node failure is detected and the second moment the second node enters a quiescent state, the write data in the pending write request can be written to a cache, and a write response can be sent to the service device. Additionally, during this first time period, a service write request may also be received from the service device; the write data in the service write request can also be written to the cache promptly, and a write response can be sent to the service device. In summary, this solution eliminates the need to wait until the second node enters single-node operation mode before writing the pending write request or the write data in the service write request to the cache, allowing for timely feedback of the write response to the service device.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to write request-response methods and electronic devices. Background Technology

[0002] In the field of storage technology, for multi-node storage systems, the write response process typically involves the application device sending a write request to a second node, which then synchronizes the write request to the first node. Upon receiving the write request from the second node, the first node writes the write data from the request to its cache and then replies with the corresponding write response to the second node. Similarly, upon receiving the write response from the first node, the second node writes the write data from the request to its cache and then sends the write response to the application device. If the first node fails, the second node first performs a quiescent operation to enter a silent state. Then, while switching from multi-node operation mode to single-node operation mode, it processes write requests that did not receive a response from the failed first node in single-node mode. Because it takes some time for the second node to enter a silent state, during which time it also receives write requests from application devices, both write requests that did not receive a response from the first node and newly received write requests cannot be processed in a timely manner, resulting in significant write request response delays. Summary of the Invention

[0003] This application provides a write request response method, apparatus, electronic device, storage medium, and program product to solve the problem of large write request response delays when nodes fail.

[0004] This application provides a method for writing request and response, including: After detecting a failure in the first node, a silencing operation is performed on the second node to put it into a silencing state. The silencing state is used to instruct the second node to stop processing write requests.

[0005] During the first time period between the first moment when the failure of the first node is detected and the second moment when the second node enters a silent state, write requests awaiting response are extracted from the pre-constructed waiting list. The write requests awaiting response are write requests that the second node has sent to the first node but has not received a corresponding write response from the first node.

[0006] After writing the write data in the pending write request to the cache of the second node, the write response corresponding to the pending write request is sent back to the business device.

[0007] And / or, during the first time period, receive a service write request sent by the service device.

[0008] After writing the write data in the business write request to the cache of the second node, the write response corresponding to the business write request is sent back to the business device.

[0009] This application also provides a write request-response apparatus, comprising: The silencing module is used to perform a silencing operation on the second node after a failure is detected in the first node, so that the second node enters a silencing state. The silencing state is used to instruct the second node to stop performing business processing operations on write requests.

[0010] The extraction module is used to extract pending write requests from a pre-built waiting list during a first time period between the first moment when the first node fails and the second moment when the second node enters a silent state. The pending write requests are write requests that the second node has sent to the first node but has not received a corresponding write response from the first node.

[0011] The response module is used to write the write data in the write request to be responded to into the cache of the second node, and then reply to the business device with the write response corresponding to the write request to be responded to.

[0012] And / or, the receiving module is used to receive a service write request sent by the service device in the first time period.

[0013] The response module is also used to write the write data in the business write request to the cache of the second node, and then reply to the business device with the write response corresponding to the business write request.

[0014] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described write request-response methods when executing the computer program.

[0015] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described write request response methods.

[0016] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described write request-response methods.

[0017] This application allows for a quiescent operation on the second node after a failure of the first node is detected, enabling the second node to enter a quiescent state. Since the quiescent operation on the second node involves a series of setup steps, it takes time for the second node to fully enter a quiescent state. Therefore, in the first time period between the detection of the first node's failure and the second node entering a quiescent state, this solution can first write the data from write requests that have not yet received a write response from the first node (i.e., pending write requests) to the cache, and then send a write response back to the business device. This ensures timely completion of the write response operation, allowing the business device to continue subsequent business processing after receiving the write response. Additionally, during this first time period, new write requests (i.e., business write requests) may be received from the business device. For these business write requests, the write data can also be written to the cache promptly, and a write response can be sent to the business device. In summary, this solution eliminates the need to wait until the second node enters single-node operation mode before writing the data from pending write requests or business write requests to the cache, allowing for timely feedback of write responses to the business device. Attached Figure Description

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

[0019] Figure 1 A schematic diagram of the architecture of a storage system provided in an embodiment of this application; Figure 2 A flowchart illustrating a write request response under normal node conditions, provided for an embodiment of this application; Figure 3 A flowchart illustrating a write request-response method provided in an embodiment of this application; Figure 4 A flowchart illustrating another write request-response method provided in an embodiment of this application; Figure 5 A flowchart illustrating another write request-response method provided in an embodiment of this application; Figure 6 This application provides a schematic diagram of a node offline to online process in an embodiment of the present application; Figure 7 A schematic diagram of a write request response device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0021] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0022] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] The write request-response method provided in this application can be implemented by a storage system, such as... Figure 1 As shown, the storage system may include service devices, multiple nodes, and storage devices.

[0024] In this context, the storage system can be a server, and correspondingly, the business equipment can be a central processing unit, also known as a host. The node can be a storage controller, and the storage device can be a storage disk, which can be divided into storage volumes.

[0025] User services such as databases and virtual machines can run on the business equipment. During the execution of these user services, they can generate write requests (Input / Output, IO) and send them to the nodes. The nodes can then perform business processing operations based on these write requests. These operations can include writing the write data from the write request to the cache and flushing the write data from the cache to the storage device. The storage device can be used for persistent data storage.

[0026] like Figure 2 As shown, for a two-node storage system, the processing flow for a single write request can be as follows: Figure 2 As shown.

[0027] Step 1: User services such as databases or virtual machines send write requests to node A.

[0028] Step 2: Node A sends a write request remote write command to Node B to synchronize the write requests sent by the user service to Node A to Node B.

[0029] Step 3: After receiving the remote write command request, node B writes the write data in the write request into node B's cache, and then sends the response remote write command (i.e., write response) to node A.

[0030] Step 4: After receiving the remote write command response, node A writes the data to its cache and then sends a write response to the database or virtual machine, indicating that the write request processing operation has been completed.

[0031] During the above process, node B may fail, causing node A to be unable to execute the write response to the business device in a timely manner. Therefore, in order to improve the timeliness of the write response operation, embodiments of this application provide a write request response method, which can be executed by any one of multiple nodes (the following description will take the second node as the execution subject as an example). Figure 3 As shown, the specific processing steps for writing a request-response method may include: Step S301: After detecting a fault in the first node, perform a silent operation on the second node.

[0032] The silent state is used to instruct the second node to stop processing write requests. The second node can correspond to node A mentioned above, and the first node can correspond to node B mentioned above.

[0033] Specifically, the first node can periodically send heartbeat signals to the second node so that the second node can detect that the first node is operating normally. If the first node fails to receive a heartbeat signal from the first node for a preset number of periods (e.g., 3), it can determine that the first node has failed. At this time, the second node can perform a quiescent operation to enter a quiescent state. After entering the quiescent state, the second node stops performing business processing operations on write requests. For example, the quiescent operation may include releasing resources, setting a state to stop business processing operations, or adding write requests that have not yet been processed to a quiescent queue.

[0034] Step S302: During the first time period between the first moment when the failure of the first node is detected and the second moment when the second node enters a silent state, write requests to be responded to are extracted from the pre-built waiting list.

[0035] Among them, the write request awaiting response can be a write request that the second node receives from the service device and sends to the first node, but does not receive the corresponding write response from the first node.

[0036] Specifically, since the second node cannot receive the write response from the first node after the first node fails, and therefore the second node cannot write to the service device, in order to avoid this problem, the second node can respond to the write request to be responded to during the period between detecting the failure of the first node and the second node entering a silent state.

[0037] First, the second node can determine whether there are any pending write requests in the waiting list. If not, steps S302 and S303 do not need to be executed. If so, one or more pending write requests can be extracted from the waiting list. Additionally, to ensure data consistency and avoid unnecessary resource consumption and state chaos, the second node can also delete pending write requests from the waiting list.

[0038] Step S303: After writing the write data in the write request to be responded to to the cache of the second node, reply to the business device with the write response corresponding to the write request to be responded to.

[0039] Specifically, before the first node detects a failure and the second node enters a silent state, the second node can parse the write request to be responded to, extract the write data and request identification information, and then write the write data into its own cache. Then, based on the request identification information, it generates the corresponding write response and sends it back to the business device. Since it takes some time for the second node to enter a silent state (e.g., several hundred milliseconds), meaning the silent operation takes time, the second node can use this time to promptly write write requests that were originally sent to the first node but for which the first node has not yet responded, thus responding to the business device in a timely manner.

[0040] And / or, in step S304, receive a service write request sent by the service device.

[0041] Specifically, before the first node detects a failure and the second node enters a silent state, the second node may receive one or more new write requests from the service device, i.e., service write requests. If the second node does not receive any service write requests from the service device during this period, steps S304 and S305 do not need to be executed.

[0042] Step S305: After writing the write data in the business write request to the cache of the second node, reply to the business device with the write response corresponding to the business write request.

[0043] Specifically, similar to the write request to be responded to, the second node can parse the business write request, extract the write data and request identification information, write the extracted write data into the second node's cache, and then generate a write response corresponding to the business write request based on the request identification information and send it back to the business device, so that the business device can receive the write response in a timely manner and proceed with the subsequent business process in a timely manner.

[0044] The write request response method of this application, after detecting a failure in the first node, can perform a silencing operation on the second node, allowing the second node to enter a silencing state. Since the silencing operation on the second node includes a series of setup operations, it takes a certain amount of time for the second node to fully enter the silencing state. Therefore, in the first time period between the first moment of detecting a failure in the first node and the second moment of the second node entering the silencing state, this solution can first write the write data in write requests that have not yet received a write response from the first node (i.e., write requests awaiting a response) into the cache, and then reply with a write response to the service device. This allows the write response operation to be completed in a timely manner, enabling the service device to continue subsequent business processing after receiving the write response. Additionally, during the first time period, new write requests (i.e., business write requests) may also be received from the service device. For business write requests, the write data in the business write request can also be written into the cache in a timely manner, and a write response can be sent to the service device. In summary, this solution does not need to wait until the second node enters single-node operation mode before writing the write data in the write requests awaiting a response or business write requests into the cache; it can promptly provide a write response to the service device.

[0045] In some optional implementations, before step S303 or S305 above, that is, before the write data in the target write request is written to the cache of the second node, in order to distinguish the above-mentioned write requests to be responded to and business write requests from other normal write requests, these write requests can be marked. Accordingly, the second node can set a first mark for the target write request. Here, the target write request is any one of the write requests to be responded to or business write requests, and the first mark is used to indicate the write request for which the second node performs business processing operations alone in the first time period.

[0046] In some optional implementations, the second node can also flush the write data in its cache to the storage device during the first time period. Furthermore, the second node will also flush the write data in its cache to the storage device while the first node is operating normally. Therefore, to ensure correct execution of business processing operations in both cases of first node failure and normal operation, the second node can also perform the following specific steps: Step 1: Flush the write data in the target write request from the cache of the second node to the storage device.

[0047] Step two: Receive the response information sent by the storage device.

[0048] Step 3: Based on the response information, determine the target write request corresponding to the response information.

[0049] Step four: If it is determined that the target write request has a first flag set, change the state of the write data in the target write request from dirty data state to non-dirty data state, and determine not to send target indication information to the first node.

[0050] The target indication information can be used to instruct the first node to change the state of the write data in the target write request from dirty data state to non-dirty data state. The dirty data state is used to indicate that the write data has been written to the cache but has not been flushed to the storage device, while the non-dirty data state is used to indicate that the write data has been flushed to the storage device.

[0051] Specifically, after receiving write data from the second node, the storage device can write it to its own storage space. After completing the write operation, it can send corresponding response information to the second node. Upon receiving the response information from the storage device, the second node can extract the request identifier information from the response information. Then, based on the request identifier information, it can determine in its cache the write request that matches the request identifier information. Finally, the storage device can determine whether the write request has a first flag set.

[0052] If so, it means that the write request is a write request that the second node performs business processing operations independently after the failure of the first node (e.g., the target write request). There is no need to synchronize information with the first node. Therefore, the second node can directly change the status of the write data in the write request stored in its own cache from the dirty data state to the non-dirty data state and determine not to send the target indication information to the second node.

[0053] If not, it means that the write request is a write request for the second node to perform business processing operations under normal circumstances. It needs to synchronize information with the first node. Therefore, the second node can send target indication information to the first node. After receiving the target indication information, the first node can change the status of the write data in the write request in its own cache from dirty data status to non-dirty data status.

[0054] In this way, by setting the first flag, the second node can accurately determine the type of write request (i.e., whether it is a write request that needs to synchronize the write request status) after receiving the response information sent by the storage device, and accurately execute the corresponding operation according to the type of write request, so as to ensure data consistency among multiple nodes in the storage system.

[0055] In some alternative implementations, after determining that the second node has entered a silent state, the second node may also perform the following specific steps: Step 1: Change the second node from multi-node operation mode to single-node operation mode.

[0056] Step two: Release the silent state of the second node.

[0057] Step 3: Obtain the pending write requests in the second node that have not yet undergone business processing.

[0058] Step 4: In single-node operation mode, write the write data in the pending write request to the cache of the second node, and reply to the business device with the write response corresponding to the pending write request.

[0059] The pending write requests may include pending write requests and / or business write requests.

[0060] Specifically, to enable the storage system to return to normal operation as quickly as possible, the second node can change its operating mode from multi-node mode (e.g., dual-node mode for a dual-controller system) to single-node mode, allowing the entire storage system to perform business processing operations in single-node mode. After completing the node operating mode setting, the second node can exit its silent state and continue performing business processing operations.

[0061] Due to the limited time frame in the first period, and the large number of write requests to be responded to, or the large number of write requests issued by the business devices in the first period, some write requests may not be written to the cache of the second node or respond to the business devices during the first period. Therefore, after the second node enters the single-node operation mode, this solution allows the second node to determine whether there are any write requests that have not been written to the cache and have not been flushed. If so, these write requests can be identified, which means identifying the write requests to be processed.

[0062] Finally, in single-node operation mode, the second node can parse the write request to be processed, extract the write data and request identification information, write the write data to the second node's cache, and then add the request identification information to the write response before sending it to the business device. The business device can receive the write response in a timely manner.

[0063] In this way, the solution utilizes the first time period to respond to a portion of the write requests, thereby reducing the number of write requests processed by the second node in single-node operation mode. This allows the write requests to be responded to more quickly compared to the processing methods in related technologies.

[0064] In some alternative implementations, the second node may handle requests for which no write response operation was performed during the first time period using the following specific steps: Step 1: Obtain candidate requests to be responded to.

[0065] Step 2: Remove the first tag of the candidate request to be responded to.

[0066] Step 3: Add the candidate requests to be responded to after removing the first tag to the pre-built silent queue.

[0067] And / or, in step 4, during the second time period between the second moment and the third moment after the silence state is lifted, a service write request sent by the service device is received.

[0068] Step 5: Add the business write requests received in the second time period to the silent queue.

[0069] The candidate pending response requests include pending write requests and / or business write requests that did not respond to the business device during the first time period. Write requests in the silent queue are the pending write requests.

[0070] Specifically, during the silent operation performed by the second node, after completing other silent operations, it can be determined whether there are any requests for which no write response operation has been performed. If so, these requests can be identified as candidate requests awaiting response. The second node can then remove the first flag from the candidate requests awaiting response and add them to the silent queue. If not, steps 1 to 3 are unnecessary. If a business write request is received from a business device after the second node enters the silent state but before it exits the silent state, the business write request can be directly added to the silent queue without adding the first flag. Accordingly, in step three above, the second node can identify the requests in the silent queue as write requests awaiting processing.

[0071] Since the requests in the silent queue are those that the second node needs to process in single-node operation mode, retaining the first flag would cause these requests to be handled differently, potentially leading to data errors. Therefore, this solution removes the first flag before adding candidate requests to the silent queue, ensuring that all requests in the silent queue can be processed uniformly. Furthermore, regarding the hot restart request recovery process, the first flag is lost after a node hot restart, meaning it cannot be saved. Therefore, this solution also ensures that all write requests can be processed uniformly after a hot restart.

[0072] In some alternative implementations, the second node may also perform the following specific steps before setting the first flag for the target write request: Step 1: Extract the operation address from the target write request.

[0073] Step 2: Based on the operation address, determine the storage space corresponding to the operation address in the storage device.

[0074] Step 3: Based on the storage space, determine the target thread corresponding to the storage space, so that after locking the storage space according to the target thread, the write data in the target write request is written to the cache of the second node, and after flushing the write data in the target write request to the storage space, the storage space is unlocked.

[0075] Specifically, during the parsing of the target write request by the second node, the second node can also extract the operation address. Then, it can determine the storage space to which the operation address belongs from a set of preset storage spaces. Based on this storage space, it identifies the thread corresponding to that storage space in the mapping table between storage spaces and threads, and designates that thread as the target thread. The second node can use the target thread to lock the storage space (which could be a Track lock), write the second write request to the second node's cache, flush the second write request from the cache to the storage device, and then unlock it.

[0076] In this way, during the business processing of any write request, the operations of writing to the cache and flushing to the storage device can be executed sequentially. In related technologies, the lock is usually released directly after writing to the cache, and the lock needs to be re-acquired during the flushing process, which is inefficient. This solution acquires the lock before writing to the cache and unlocks it after flushing to the storage device, which is more efficient.

[0077] In some optional implementations, after detecting that the first node has recovered, the second node can perform a synchronization operation on the pending data refresh request. During the synchronization operation, the second node can set its own second flag to the first indicator information and synchronize it to the first node to indicate that a synchronization operation is currently being performed. After the synchronization is completed, it sets its own second flag to the second indicator information and synchronizes it to the first node, so that the first node can know that the synchronization operation is complete. During the synchronization operation, the second node may also fail. If the second node fails, there will still be data inconsistency between the first and second nodes, making it unable to provide services. Accordingly, the first node can set its own status to offline. After detecting that the first node is offline, the service device will no longer access the first node. After the first node detects that the second node has recovered, it can continue to perform the unfinished synchronization operation. For the first node, after detecting that the second node has recovered, it can restore its own status to online and continue to receive access operations from the service device.

[0078] In some optional implementations, users can send target commands to the first node through the business device. After receiving the target command, the first node can restore its online status, allowing the business device to access the storage device through the first node.

[0079] In some alternative implementations, in the aforementioned operation process, the second node may perform the write response operation as the primary node. If the second node acts as a backup node, it may also perform the following specific steps: Step 1: If a failure is detected in the third node and the pre-acquired second flag indicates that the synchronization operation of the first type of pending write request has not been completed, the working status of the second node is set to offline to block access operations of the business device.

[0080] Step two: After detecting that the third node has returned to normal, set the working status of the second node to online status to accept access operations from business devices.

[0081] Among them, the first type of pending write request is the write request that belongs to the write data that was not flushed from the cache of the third node to the storage device during the period when the second node failed.

[0082] Specifically, the third node can be a node performing a synchronization operation on the second node. During the synchronization process, if the third node fails, it cannot promptly synchronize the first type of pending write requests to the second node, causing inconsistencies between the write data in the second node's cache and the write data in the third node's cache. Therefore, the second node can set its working state to offline. After detecting that the second node is offline, the service device will no longer access the second node to avoid further data inconsistency issues caused by access operations. The second node can resume its online state after detecting that the third node has recovered, in order to receive access operations from the service device.

[0083] In this way, in the event of a failure of the third node, keeping the second node offline can ensure cache consistency between the second and third nodes, avoiding data corruption caused by the second node directly providing services to business devices when the data is inconsistent.

[0084] In some optional implementations, since the second node may be in a faulty state for an extended period, causing business devices to be unable to access the node for a long time and resulting in business interruption, this solution also provides a method to force the second node to come online. Accordingly, the second node can perform the following specific steps: Step 1: Receive the target command sent by the service device.

[0085] Step 2: Based on the target command, directly set the working status of the second node to online.

[0086] Specifically, users can input target commands via command-line processing. The business device can then receive the target command and send it to the second node. The second node can then set its working status to online based on the target command. The third node can then continue to synchronize the first type of pending flash requests that have not yet completed the synchronization operation to the second node.

[0087] This allows the storage system to quickly return to normal and resume business operations. Furthermore, forcing the second node online via command line eliminates the need for volume reconfiguration, making it even more convenient.

[0088] In some alternative implementations, the second node may synchronize pending write requests using the following specific steps: Step 1: After detecting that the first node has returned to normal, determine whether there are any second type of write requests to be flushed to the storage device in the cache of the second node.

[0089] Step 2: If it is confirmed that there are second-type pending flush requests, count the number of second-type pending flush requests and obtain the business type and operation address corresponding to each second-type pending flush request.

[0090] Step 3: Obtain the network bandwidth of the second node.

[0091] Step 4: Determine the data synchronization type based on network bandwidth, the number of second-type pending write requests, and the corresponding service type and operation address of the second-type pending write requests.

[0092] Step 5: Generate a data synchronization strategy corresponding to the data synchronization type based on the data synchronization type and the second type of pending write request.

[0093] Step 6: Using a data synchronization strategy, the second type of pending write requests are synchronized to the first node.

[0094] Specifically, after the second node receives the heartbeat signal sent by the first node again, it can determine that the first node has returned to normal. Then, it can determine whether there is write data in the second node's cache in the state of dirty data. If so, the write request to which the write data in the state of dirty data belongs can be determined as the second type of write request to be flushed.

[0095] Then, the second node can count the number of second-type pending write requests. Since the number of second-type pending write requests indicates the amount of synchronized data, i.e., its impact on network bandwidth, and the service type of the second-type pending write requests indicates service priority, while the operation address indicates the continuity of write operations, by analyzing the number and service type of the second-type pending write requests in conjunction with network bandwidth, a data synchronization type matching the current actual situation can be selected from a variety of preset data synchronization types.

[0096] Furthermore, the second node can allocate the second type of pending write requests based on the data synchronization type (for example, placing the write requests with the highest priority business type in the first batch for synchronization), thus obtaining a data synchronization strategy. Finally, the second node can use the data synchronization strategy to synchronize the second type of pending write requests to the first node.

[0097] This approach, by comprehensively considering multiple dimensions of indicators, offers high flexibility. Including network bandwidth in the calculation ensures that data synchronization operations are adapted to the actual network bandwidth, reducing bandwidth consumption when insufficient and avoiding underutilization when sufficient bandwidth is available. Furthermore, considering the quantity and nature of the second type of pending write requests ensures that critical requests are synchronized promptly. Consequently, even if the second node fails, forcing it back online minimizes the impact of data inconsistencies caused by these pending write requests.

[0098] In some optional implementations, in step four above, the second node can determine the data synchronization type based on network bandwidth, the number of second-type pending write requests, and the service type and operation address corresponding to the second-type pending write requests: The second node can determine sufficient network bandwidth if it finds the network bandwidth is greater than a preset bandwidth threshold, or insufficient network bandwidth if it finds the network bandwidth is less than the preset bandwidth threshold. The second node can determine the continuity of operation addresses based on the operation addresses of each type of second-class pending write request. For example, if all operation addresses of the second-class pending write requests are not consecutive, the continuity level is set to the lowest; if all operation addresses of the second-class pending write requests are consecutive, the continuity level is set to the highest; otherwise, the continuity level can be set to other levels. The second node can determine whether there is a highest priority service type based on the service type of each type of second-class pending write request. The second node can determine the target quantity range to which the quantity of second-class pending write requests belongs from multiple preset quantity ranges.

[0099] Then, the second node can determine the data synchronization type that matches the analysis results from among the pre-built data synchronization types based on the analysis results of the above four dimensions. For example, the data synchronization type can be parallel full-speed, priority-first, sequential batch, and compressed streaming. Parallel full-speed corresponds to the above analysis results of sufficient network, contiguous addresses, no high priority, and small quantity. Priority-first corresponds to the above analysis results of sufficient network, contiguous addresses, high priority, and medium quantity. Sequential batch corresponds to the above analysis results of insufficient network, contiguous addresses, high priority, and large quantity. Compressed streaming corresponds to the above analysis results of severely insufficient network, random addresses, no high priority, and large quantity.

[0100] In this way, by simply comparing the information of each dimension and then matching the data synchronization type based on the analysis results, it is relatively simple and does not require a lot of resources to determine the data synchronization type.

[0101] The execution process of the write request-response method described above will be explained in detail below with a specific example. The nodes mentioned above can include a cluster module and a cache module. The cluster module can be used to detect node events. The cache module can be a module in the IO stack, used to reply to the application device with a write response after the write request is written to the cache.

[0102] like Figure 4 The diagram shows the response flow for the pending request, including: Step 1: User services such as databases or virtual machines send write requests to node A.

[0103] Step 2: Node A sends a write request remote write command to Node B.

[0104] Step 3: Node B fails and goes down.

[0105] Step 4: Node A's cache module receives a notification that Node B has crashed.

[0106] Specifically, this solution adds a notification to the cache module. After the driver layer of node A detects a failure in node B, it can notify its own cluster module and cache module respectively, so that the cache module can execute subsequent steps.

[0107] Step 5: Remove the write request waiting for a response from node B from the waiting list, mark the write request, and write it into the cache of node A.

[0108] Step 6: Directly flush the write request to the storage volume without releasing the lock.

[0109] Specifically, after receiving notification that node B has crashed, node A's caching module removes the pending write requests from the waiting list and assigns them to the corresponding threads for processing. Then, it marks these pending write requests with a mirror request single-control write-back flag (i.e., the first flag), writes the write data from these requests to the cache, and sends a write response back to the host. To expedite the flushing process, the track lock is not released after completing the write cache operation. This avoids acquiring the track lock again when flushing the pending write requests to the storage device, thus improving flushing efficiency.

[0110] After the storage device replies with a response message, if the write request to be responded to corresponding to the response message has already set the mirror request single-control write-back flag, then the request to change the dirty data state to non-dirty data state (i.e., the target indication information) will no longer be sent to node B. Instead, the state of the write data in the corresponding write request to be responded to on node A will be changed from dirty data state to non-dirty data state.

[0111] The above operation begins when node A receives the notification that node B has crashed and ends when node A enters a silent state. Once the silent state begins, no more pending requests will be processed.

[0112] like Figure 5 The diagram shows the response flow for a business write request, including: Step 1: User services such as databases or virtual machines send write requests to node A.

[0113] Step 2: Node A sends a write request remote write command to Node B.

[0114] Step 3: Node B fails and goes down.

[0115] Step 4: Node A's cache module receives a notification that Node B has crashed.

[0116] Step 5: Mark the business write requests issued by the host, write the write data in the business write requests to the cache, and reply with a write response to the user business.

[0117] Specifically, after receiving notification that node B has failed, node A's caching module sets a mirror request single-control write-back start flag. From the time this flag is set until node A becomes silent, for all new business write requests arriving at node A, node A no longer sends remote write commands to node B. Instead, node A's caching module sets the mirror request single-control write-back flag for the business write requests and sends a write response back to the host after writing to the cache. Similarly, after node A sends a write response back to the host, it can choose the immediate flush mode. To speed up processing, the track lock is not released after writing to the cache. Upon receiving the response from the storage device, if the business write request corresponding to the response has already set the mirror request single-control write-back flag, it no longer sends a request to node B to change the dirty data state to a non-dirty data state (i.e., target indication information). It only changes the dirty data state of the write data in node A's business write request to a non-dirty data state. If node A has already entered a silent state, the business write requests sent by the host can be added to the silent queue.

[0118] like Figure 6 The diagram shows the node offline to online process, which includes the following steps: Step 1: User services such as databases or virtual machines send write requests to node A.

[0119] Step 2: Node A sends a write request remote write command to Node B.

[0120] Step 3: Node B fails and goes down.

[0121] Step 4: Node A performs a mirror request for single-control writeback, which means that a write response operation is performed independently in the event of a failure of Node B.

[0122] Step 5: Node B returns to normal, and Node A synchronizes the write requests in its own cache that have not been flushed to the storage volume to Node B.

[0123] Step 6: During the synchronous write request process, node A fails and crashes.

[0124] Step 7: Node B remains offline for the business devices and waits for Node A to return to normal before going online again.

[0125] Specifically, after node B recovers, if the write data in node A's cache has not yet been flushed to the storage device, node A needs to synchronize this write data to node B. If node A fails before completing data synchronization, node B's cache module can remain offline to the host until node A recovers. After node A recovers, node B's cache module can then bring the upper-layer modules back online.

[0126] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0127] Embodiments of this application also provide a write request-response apparatus, such as... Figure 7 As shown, it includes: The silencing module 710 is used to perform a silencing operation on the second node after detecting a failure in the first node, so that the second node enters a silencing state. The silencing state is used to instruct the second node to stop performing business processing operations on write requests.

[0128] The extraction module 720 is used to extract pending write requests from a pre-built waiting list during a first time period between the first moment when the first node is detected to have failed and the second moment when the second node enters a silent state. The pending write requests are write requests that the second node has sent to the first node but has not received a corresponding write response from the first node.

[0129] The response module 730 is used to write the write data in the write request to be responded to into the cache of the second node, and then reply to the business device with the write response corresponding to the write request to be responded to.

[0130] And / or, receiving module 740 is used to receive a service write request sent by the service device in the first time period.

[0131] The response module 730 is also used to write the write data in the business write request to the cache of the second node, and then reply to the business device with the write response corresponding to the business write request.

[0132] In some alternative embodiments, the device further includes a marking module 750 for: A first flag is set for the target write request, wherein the target write request is either a write request to be responded to or a business write request. The first flag is used to indicate the write request for which the second node performs business processing operations alone in the first time period.

[0133] In some alternative implementations, the device further includes a brush module 760 for: The write data in the target write request is flushed from the cache of the second node to the storage device; Receive response information sent by the storage device; Based on the response information, determine the target write request corresponding to the response information; If the target write request is found to have a first flag, the state of the write data in the target write request is changed from dirty data state to non-dirty data state, and it is determined not to send target indication information to the first node. The target indication information is used to instruct the first node to change the state of the write data in the target write request from dirty data state to non-dirty data state. The dirty data state is used to indicate that the write data has been written to the cache but not flushed to the storage device, and the non-dirty data state is used to indicate that the write data has been flushed to the storage device.

[0134] In some alternative implementations, the response module 730 is further configured to: After confirming that the second node has entered a silent state, change the second node from multi-node operation mode to single-node operation mode. Release the silent state of the second node; Get the pending write requests in the second node that have not yet performed business processing operations, where pending write requests include pending response write requests and / or business write requests; In single-node operation mode, the write data in the pending write request is written to the cache of the second node, and the write response corresponding to the pending write request is sent back to the business device.

[0135] In some alternative embodiments, the device further includes an adding module 770 for: Obtain candidate pending response requests, which include pending write requests and / or business write requests that have not responded to the business device during the first time period; Remove the first tag from the candidate request to be responded to; Add the candidate requests to be responded to after removing the first tag to the pre-built silent queue; And / or, during the second time period between the second moment and the third moment when the silence state is lifted, receive a service write request sent by the service device; Add the business write requests received in the second time period to the silent queue; Among them, the write requests in the silent queue are write requests waiting to be processed.

[0136] In some alternative embodiments, the device further includes a determining module 780, for: Extract the operation address from the target write request; Based on the operation address, determine the storage space corresponding to the operation address in the storage device; Based on the storage space, determine the target thread corresponding to the storage space, so that after locking the storage space according to the target thread, write the write data in the target write request to the cache of the second node, and after flushing the write data in the target write request to the storage space, unlock the storage space.

[0137] In some alternative implementations, the device further includes a synchronization module 790 for: If a failure is detected in the third node and the pre-acquired second flag is used to indicate that the synchronization operation of the first type of pending write request has not been completed, the working state of the second node is set to offline state to block access operations of the business device. The first type of pending write request is the write request to which the write data that was not flushed from the cache of the third node to the storage device during the failure of the second node belongs. After the third node is detected to have returned to normal, the working status of the second node is then set to online to accept access operations from business devices.

[0138] In some alternative implementations, the synchronization module 790 is also used for: Receive the target command sent by the service device; Based on the target command, the working status of the second node is directly set to online.

[0139] In some alternative implementations, the synchronization module 790 is also used for: After detecting that the first node has returned to normal, determine whether there are any second type of write requests to be flushed to the storage device in the cache of the second node; If it is determined that there are second-type pending flush requests, count the number of second-type pending flush requests and obtain the business type and operation address corresponding to each second-type pending flush request; Obtain the network bandwidth of the second node; The data synchronization type is determined based on network bandwidth, the number of second-type pending write requests, the service type corresponding to the second-type pending write requests, and the operation address. Based on the data synchronization type and the second type of pending write request, generate a data synchronization strategy corresponding to the data synchronization type. A data synchronization strategy is adopted to synchronize the second type of pending write requests to the first node.

[0140] For a description of the features in the embodiment corresponding to the write request response device, please refer to the relevant description in the embodiment corresponding to the write request response method, which will not be repeated here.

[0141] Embodiments of this application also provide an electronic device, such as... Figure 8 As shown, it includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the above-described write request response method embodiments.

[0142] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described write request response method embodiments when running.

[0143] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0144] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described write request response method embodiments.

[0145] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described write request response method embodiments.

[0146] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] The foregoing has provided a detailed description of a write request response method, apparatus, electronic device, storage medium, and program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A write request response method, characterized by, include: After detecting a failure in the first node, a silencing operation is performed on the second node to put the second node into a silencing state, wherein the silencing state is used to instruct the second node to stop performing business processing operations on write requests; During the first time period between the first moment when the first node is detected to the second moment when the second node enters the silent state, write requests to be responded to are extracted from the pre-constructed waiting list. The write requests to be responded to are write requests that the second node has sent to the first node but has not received a corresponding write response from the first node. After writing the write data in the pending write request to the cache of the second node, the write response corresponding to the pending write request is sent back to the service device; And / or, during the first time period, receive a service write request sent by the service device; After writing the write data in the business write request to the cache of the second node, the write response corresponding to the business write request is sent back to the business device.

2. The write request response method of claim 1, wherein, Before writing the write data in the target write request to the cache of the second node, the method further includes: A first flag is set for the target write request, wherein the target write request is either the write request to be responded to or the business write request, and the first flag is used to indicate that the second node executes the business processing operation write request alone during the first time period.

3. The write request response method of claim 2, wherein, After writing the write data in the target write request to the cache of the second node, the method further includes: The write data in the target write request is flushed from the cache of the second node to the storage device; Receive response information sent by the storage device; Based on the response information, determine the target write request corresponding to the response information; If it is determined that the target write request has the first flag set, the state of the write data in the target write request is changed from dirty data state to non-dirty data state, and it is determined not to send target indication information to the first node. The target indication information is used to instruct the first node to change the state of the write data in the target write request from the dirty data state to the non-dirty data state. The dirty data state is used to indicate that the write data has been written to the cache but not flushed to the storage device, and the non-dirty data state is used to indicate that the write data has been flushed to the storage device.

4. The write request response method according to claim 2 or 3, characterized by, The method further includes: After determining that the second node has entered the silent state, the second node is switched from multi-node operation mode to single-node operation mode. Release the silent state of the second node; Obtain pending write requests in the second node that have not yet performed the business processing operation, wherein the pending write requests include the pending write requests and / or the business write requests; In the single-node operation mode, the write data in the pending write request is written to the cache of the second node, and a write response corresponding to the pending write request is sent back to the service device.

5. The write request-response method according to claim 4, characterized in that, The method further includes: Obtain candidate pending response requests, wherein the candidate pending response requests include pending write requests and / or the service write requests that did not respond to the service device during the first time period; Remove the first tag from the candidate requests to be responded to; Add the candidate requests to be responded to after removing the first tag to the pre-built silent queue; And / or, during the second time period between the second moment and the third moment when the silence state is lifted, receive a service write request sent by the service device; Add the business write requests received in the second time period to the silent queue; The write requests in the silent queue are the write requests to be processed.

6. The write request-response method according to claim 3, characterized in that, Before setting the first flag for the target write request, the method further includes: Extract the operation address from the target write request; Based on the operation address, determine the storage space corresponding to the operation address in the storage device; Based on the storage space, a target thread corresponding to the storage space is determined so that, after locking the storage space according to the target thread, the write data in the target write request is written to the cache of the second node, and after flushing the write data in the target write request to the storage space, the storage space is unlocked.

7. The write request response method according to any one of claims 1-3 and 5-6, characterized in that, The method further includes: If a failure is detected in the third node and the pre-acquired second flag is used to indicate that the synchronization operation of the first type of pending write request has not been completed, the working state of the second node is set to offline state to block the access operation of the service device. The first type of pending write request is the write request to which the write data that was not flushed from the cache of the third node to the storage device during the failure of the second node belongs. After the third node is detected to have returned to normal, the working status of the second node is set to online to accept access operations from the service device.

8. The write request response method according to claim 7, characterized in that, The method further includes: Receive the target command sent by the service device; According to the target command, the working status of the second node is directly set to online.

9. The write request response method according to any one of claims 1-3 and 5-6, characterized in that, The method further includes: After detecting that the first node has returned to normal, determine whether there are any second type of write requests to be flushed to the storage device in the cache of the second node; If it is confirmed that there are second type of pending write requests, count the number of second type of pending write requests, and obtain the business type and operation address corresponding to each of the second type of pending write requests; Obtain the network bandwidth of the second node; The data synchronization type is determined based on the network bandwidth, the number of second-type pending write requests, and the service type and operation address corresponding to the second-type pending write requests. Based on the data synchronization type and the second type of pending write request, generate a data synchronization strategy corresponding to the data synchronization type; Using the data synchronization strategy, the second type of pending write requests are synchronized to the first node.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the write request response method as described in any one of claims 1-9 when executing the computer program.

Images