Fault tolerance of transaction mirroring

Abstract

This paper describes systems and methods for promoting fault tolerance in transaction mirroring. The methods described herein include: receiving a commit command for a data transaction from an initiating node of the system, wherein the data transaction is associated with a first fault domain, and wherein the commit command is directed to a primary participant node and a secondary participant node of the system; in response to the receipt, determining whether a response to the commit command has been received at the primary participant node from the secondary participant node; and in response to determining that no response to the commit command has been received at the primary participant node, indicating that the secondary participant node is invalid in a data store associated with a second fault domain different from the first fault domain.

Description

[0001] Cross-referencing related applications

[0002] This application claims priority to U.S. nonprovisional application filed on October 29, 2020, serial number 17 / 083,991 entitled “FAULTTOLERANCE FOR TRANSACTION MIRRORING”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to data storage, and more specifically, to technologies for data protection in data storage systems. Background Technology

[0004] Various measures can be taken to protect data written to computing systems, such as data written across one or more nodes in a network-attached storage (NAS) system and / or other distributed computing systems, from power outages, device failures, and / or other events. As an example, a data storage system can leverage file system logging to provide crash consistency by recording write operations that result in updates to one or more data or metadata blocks of a drive associated with that system in the log. Once the relevant file system updates become persistent and permanent on the log medium, the recorded writes can then be transferred to the drive in the background.

[0005] Additionally or alternatively, mirroring can be used to provide further protection for updates to one or more files, key-value stores, etc. For example, a transaction updating a (primary) participant node of a system can be structured to also include secondary (partner) participant nodes, such that the primary participant's transaction updates are mirrored to the secondary participants. In such transactions, it is desirable to implement techniques that provide improved fault tolerance for the devices and / or nodes involved in the transaction. Summary of the Invention

[0006] The following summary is a general overview of the various embodiments disclosed herein and is not intended to be exhaustive or limiting. The embodiments will be better understood by considering the following detailed description taken in conjunction with the accompanying drawings and claims.

[0007] In one aspect, this document describes a data storage system. The data storage system may include: a memory storing executable components; and a processor executing the executable components stored in the memory. The executable components may include: a transaction management component that receives, at the primary participant node of the data storage system, a transaction commit command corresponding to a data transaction associated with a first fault domain from the initiating node of the data storage system. The transaction commit command is directed to both the primary and secondary participant nodes of the data storage system. The executable components may further include: a status monitoring component that, in response to receiving the transaction commit command, determines whether a response message to the transaction commit command has been received at the primary participant node from the secondary participant node. The executable components may further include: a status updating component that, in response to determining that the primary participant node has not received a response message from the secondary participant node within a threshold time period, indicates the secondary participant node as invalid in a data structure stored in a second fault domain different from the first fault domain.

[0008] In another aspect, this document describes a method. This method may include: a system operatively coupled to a processor receiving a commit command for a data transaction from an initiating node of the system, wherein the data transaction is associated with a first fault domain, and the commit command is directed to a primary participant node and a secondary participant node of the system. The method may further include: in response to the receipt, the system determining whether a response to the commit command has been received at the primary participant node from the secondary participant node. The method may further include: in response to determining that no response to the commit command has been received at the primary participant node, the system instructing the secondary participant node that it is invalid in a data repository associated with a second fault domain different from the first fault domain.

[0009] In another aspect, this document describes a non-transient machine-readable medium comprising computer-executable instructions. When executed by a processor of a data storage system, the instructions facilitate the execution of operations including: receiving from an initiating node of the data storage system a first command to submit a transaction associated with a first fault domain, the first command being directed to a primary participant node and a partner participant node of the data storage system; in response to the receipt, determining whether a response to the first command has been received from the partner participant node at the primary participant node; and in response to determining that no response to the first command has been received at the primary participant node within a threshold time period, marking the partner participant node as inactive in a data structure associated with a second fault domain different from the first fault domain. Attached Figure Description

[0010] Various non-limiting embodiments of the subject matter are described with reference to the following figures, wherein, unless otherwise stated, the same reference numerals refer to the same parts throughout.

[0011] Figure 1 This is a block diagram of a fault-tolerant system that promotes transaction mirroring, based on the various aspects described in this article.

[0012] Figure 2 This is a block diagram of a system that facilitates data transaction submission based on the various aspects described in this article.

[0013] Figures 3 to 4 Based on the various aspects described in this document, it facilitates the submission of corresponding operational states for secondary participant nodes, such as... Figure 2 The diagram shows a block diagram of the corresponding system for the data transaction technology.

[0014] Figures 5 to 6 This is a diagram illustrating an example message flow for performing data transactions via a two-phase commit protocol, based on the various aspects described herein.

[0015] Figures 7 to 8 This is a block diagram of the corresponding system that facilitates the execution of participant-driven data transactions in response to the unavailability of the initiating node, based on the various aspects described in this article.

[0016] Figure 9 This is a block diagram of a fault-tolerant system that facilitates transaction mirroring via shared and non-shared participant nodes, based on the various aspects described in this article.

[0017] Figure 10 This is a flowchart illustrating methods for promoting fault tolerance in transaction mirroring, based on the various aspects described in this article.

[0018] Figure 11 This is an illustration of an example computing environment in which the various embodiments described herein may run. Detailed Implementation

[0019] Various specific details of the disclosed embodiments are provided in the following description. However, those skilled in the art will recognize that in some cases the techniques described herein may be implemented without one or more of these specific details, or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring certain aspects.

[0020] Furthermore, while some specific details of the disclosed embodiments provided in the following description relate to file system log mirroring, it should be understood that the techniques provided below can be extended to other contexts where transactional data updates (e.g., file system updates, etc.) are desired. Unless otherwise expressly stated, the various aspects set forth in the following description and the claimed subject matter are intended to cover all such contexts and are not intended to be limited to any particular context or use case.

[0021] On one hand, transaction mirroring schemes can be used to provide redundancy for file system updates in data storage systems. For example, in an initiator-driven mirroring scheme, a transaction used to update a primary participant node may include one or more additional participant nodes referred to as secondary or partner participants, such that each transaction update of the primary participant can be mirrored to its (or more) secondary participants(s). The roles of the initiator, primary participant, and secondary (partner) participants in a data transaction will be described in more detail below.

[0022] On the other hand, initiator-driven mirroring can utilize two-phase commit (2PC) protocols, such as 2PC version 2 (or 2PCv2), which leverages single-fault non-blocking semantics. In this context, blocking refers to the halting of a transaction's forward progress due to inconsistencies in the transaction's state among its nodes, such as due to node failure. Transactions blocked in this way are also called indeterminate transactions, for example, because the transaction's state is uncertain across its associated nodes. In this respect, by utilizing protocols with single-fault non-blocking semantics, the transaction can continue even if one of the nodes in the transaction fails.

[0023] However, transactions executed using single-failure non-blocking semantics can still be blocked in the event of multiple node failures. For example, any failure of a partner participant or initiator in a 2PCv2 transaction can render the transaction uncertain, halting its forward progress until the failure is recovered. This can, in turn, adversely affect the availability of the associated system cluster. To address this, the aspects presented in this paper implement techniques for tolerating failures of any number of partner participants in a 2PCv2 transaction.

[0024] By implementing the fault-tolerant techniques for transaction mirroring described herein, various advantages can be achieved that can improve the functionality of computing systems. These advantages include, but are not limited to, the following: The computational resources associated with recovery from driver and / or node failures (e.g., processor cycles, memory usage, power consumption, network bandwidth utilization, etc.) can be reduced. For example, by reducing downtime due to node failures, the availability and / or uptime of the cluster file system can be increased. Other advantages are also possible.

[0025] Now refer to the attached diagram, Figure 1 A block diagram of a fault-tolerant system 100 that facilitates transaction mirroring, based on the various aspects described herein, is shown. Figure 1As shown, system 100 includes a transaction management component 110, a status monitoring component 120, and a status update component 130, which can operate as described in more detail below. In one aspect, components 110, 120, and 130 of system 100 can be implemented in hardware, software, or a combination of hardware and software. As an example, components 110, 120, and 130 can be implemented as computer-executable components, such as components stored in memory and executed by a processor. Examples of computer architectures including processors and memory that can be used to implement components 110, 120, 130, and other components described herein are referenced below. Figure 11 To show and describe in more detail.

[0026] On one hand, components 110, 120, and 130 may be associated with computing nodes and / or other computing devices associated with file storage systems and / or other data storage systems. For example, components 110, 120, and 130 as shown in system 100 may each be associated with participant node 10 in system 100, which may be the primary participant in the corresponding data transaction as described above. Additionally or alternatively, components 110, 120, 130, and / or other components, which will be described in more detail below, may be implemented in other computing nodes or devices, such as initiator node 20, secondary (partner) participant nodes such as participant node 12, and / or other suitable devices. Furthermore, it should be understood that components 110, 120, and 130 of system 100, as well as other additional components, which will be described in further detail below, may be implemented at the same computing device (node) and / or distributed across multiple computing devices (nodes).

[0027] Although participant nodes 10, 12, and initiator node 20 shown in system 100 are logically distinct and are represented as different entities, it should be understood that participant nodes 10, 12, and initiator node 20 do not need to be physically distinct. For example, participant nodes 10, 12, and initiator node 20 may be housed in a shared physical chassis and / or other device, even though they are logically separate system nodes. In one aspect, a participant node associated with the same device as the initiator node may be referred to as a shared participant. (See below for reference.) Figure 9 A more detailed description of the specific technologies that can be employed in the presence of sharing participants is provided. Alternatively, the respective nodes in nodes 10, 12, and 20 may be located in different physical devices and configured to communicate with each other via any suitable wired or wireless communication protocol.

[0028] return Figure 1 ,like Figure 1As further shown, the transaction management component 110 of system 100 can, for example, receive a transaction commit command for a data transaction from the initiating node 20 of system 100. In one aspect, the transaction commit command can be a message sent by the initiating node 20 to initiate a transaction commit according to a transaction commit protocol such as 2PC, 2PCv2, etc. Figure 1 As further shown, in addition to the (primary) participant node 10, the transaction commit command provided by the initiating node can also be directed to the secondary participant node 12 (e.g., a secondary or partner participant). Although in Figure 1 Only two participant nodes, 10 and 12, are shown in this document; however, it should be understood that the data transactions described herein may include any appropriate number of participants, including any number of primary and / or secondary participants.

[0029] like Figure 1 As further shown, the status monitoring component 120 of system 100 can determine whether a response message to the transaction commit command from the secondary participant node 12 has been received at the primary participant node 10. For example, the secondary participant node 12 can respond to the commit command received from the initiating node 20 by committing the associated transaction and subsequently transmitting a response to the commit command to the primary participant node 10.

[0030] If the status monitoring component 120 of the primary participant node 10 and / or other appropriate components determine, for example, that no response message has been received from the secondary participant node 12 within a time period defined by a configurable threshold, the status update component 130 of the system 100 may mark and / or otherwise indicate the secondary participant node 12 as invalid in the associated data structure 30. In one aspect, the data structure 30 may be stored in and / or otherwise associated with a node state block (NSB), which is a per-node disk block that may be mirrored across the corresponding drive in a given node, and may be used to store file system log information and / or other boot information in addition to node status information. Additionally or alternatively, the data structure 30 may be associated with any suitable permanent data store, which may be stored in any suitable data or metadata block(s) across nodes 10, 12, 20 and their respective drive mirrors.

[0031] On one hand, data structure 30 can be stored in and / or otherwise associated with a fault (error) domain, which is different from the fault domain associated with the data transaction. For example, a commit command provided by the initiating node 20 can be associated with a first fault domain, and data structure 30 can be stored in or associated with a second, different fault domain. Therefore, the failure of one or more nodes or drivers associated with a given data transaction will not affect the integrity or availability of data structure 30.

[0032] As will be described in further detail below (for example, see references) Figures 4 to 6 The primary participant node 10 can be configured to respond to a commit command from the initiator node 20 only after confirming the commit of the secondary participant node 12, or by marking the secondary participant node 12 as invalid via the state update component 130. As will be described in further detail below, the secondary participant node 12 can be configured to respond only to the initiator node 20 and its primary participant node 10. These node behaviors and / or other node behaviors can facilitate participant-driven semantics in the commit phase of a transaction (e.g., a 2PCv2 transaction), thereby increasing tolerance to secondary participant failures.

[0033] Similar to data structure 30, secondary participant node 12 can also be associated with a fault domain different from that of primary participant node 10, which may be the same as or different from the fault domain of data structure 30. As a non-limiting example involving log mirroring, an initiator-driven log mirroring scheme can be utilized, where initiator node 20 sends a mirrored copy of the file system update for a given participant (e.g., participant node 10) to an additional set of different participants (e.g., the set of participants including participant node 12), such that for each expected participant in the transaction, there is an additional participant on a separate log fault domain. Thus, in the event of a log fault in the expected (primary) participant, a mirrored copy of the log can be obtained at the additional (secondary) participant. In one aspect, participant nodes 10 and 12 can be logically separate 2PCv2 participants. Therefore, participant nodes 10 and 12 can be associated with the corresponding other participants involved in the transaction ( Figure 1 (Not shown in the image) Isolate and operate in parallel.

[0034] In a 2PCv2 transaction, the transaction may be indeterminate if both the participant and the initiator fail after the preparation phase. In other words, because the state of the other failing participant is unknown (e.g., whether it was committed or aborted), the remaining participants in the transaction may become unable to make forward progress on the transaction. Therefore, a secondary participant failure can lead to an indeterminate transaction in an initiator-driven 2PCv2 transaction.

[0035] On one hand, system 100 can reduce the occurrence of uncertain transactions due to secondary participant failures by using a participant-driven transaction model in the transaction commit phase. More specifically, the aspects described herein can modify initiator-driven transactions in one or more of the following ways to facilitate participant-driven commit phases in order to improve fault tolerance to secondary participant failures:

[0036] 1) The initiator (e.g., initiator node 20) can send prepare and commit messages to both the primary participant (e.g., participant node 10) and the secondary participant (e.g., participant node 12).

[0037] 2) The initiator can anticipate and handle prepared responses from both the primary and secondary participants.

[0038] 3) The initiator can be configured to expect submission responses only from the main participant.

[0039] 4) The primary participant can only respond to a commit after (a) the secondary participant commits, or (b) the primary participant (e.g., via state update component 130) marks the secondary participant as invalid in a reliable, persistent storage (e.g., NSB) outside the primary participant's fault domain. See below for details. Figure 4 and Figure 5 Describe these situations in more detail.

[0040] 5) In the absence of an initiator, the primary participant may confirm with secondary participants before responding to other participants. See below for reference. Figures 7 to 8 To describe this in more detail.

[0041] Other measures may also be adopted. On the one hand, using one or more of the measures mentioned above can establish fault tolerance for secondary participant failures with minimal additional delay overhead (e.g., an additional delay cost of approximately half the round-trip time (RTT)).

[0042] Now go to Figure 2 This diagram illustrates a block diagram of a system 200 that facilitates data transaction submissions (e.g., at participant nodes 10, 12 of a data storage system) according to various aspects described herein. For brevity, repeated descriptions of similar elements used in other embodiments described herein are omitted. Figure 2 As shown, system 200 includes a transaction commit component 210, which can commit data transactions at, for example, primary participant node 10 or secondary participant node 12 in response to receiving a corresponding transaction commit command.

[0043] On the one hand, participating node 10 can utilize, for example... Figure 2 The transaction commit component 210 shown provides a baseline commit function for transactions, and this baseline function can be extended by components 110, 120, 130 of system 100 as described above to complete data transactions, such as 2PCv2 transactions, based on the operational status of secondary (partner) participant nodes 12 (e.g., determined by status monitoring component 120).

[0044] As a first example Figure 3System 300 illustrates operations that can be performed by the initiating node 20 and the primary participant node 10 to confirm a transaction, where the secondary participant node 12 has failed or otherwise failed to respond to the transaction commit command from the initiating node 20. In the scenario shown in System 300, if the secondary participant node 12 of the transaction disconnects or otherwise fails to respond within a configurable time period, the primary participant node 10 can mark the secondary participant node 12 as invalid, for example, via the state update component 130 as described above in the NSB or other data structure 30. Subsequently, the primary participant node 10 can commit the transaction via the transaction commit component 210 and respond to the initiating node 20 with its own response message (e.g., via the transaction management component 110).

[0045] By utilizing the above process, and by discarding the secondary participant node 12 from the transaction in response to marking it as invalid in data structure 30, the primary participant node 10 can continue the transaction until completion even if the secondary participant node 12 has timed out and / or otherwise failed. In one aspect of the transaction involving log mirroring shown in system 300, since any log recovery after log loss can query data structure 30 (e.g., via NSB), the validity information in data structure 30 can avoid the use of outdated information corresponding to the secondary participant node 12 in future transactions.

[0046] on the contrary, Figure 4 System 400 illustrates a scenario where secondary participant node 12 remains responsive throughout the transaction. In the scenario shown in system 400, primary participant node 10 can communicate with the above reference... Figure 3 In a similar manner, the primary participant node 10 commits the transaction in response to the commit command provided by the initiating node 20. However, in response to the state monitoring component 120 determining that the secondary participant node 12 is active, for example, because it has received a response to the commit command from the initiating node 20 at the primary participant node 10, the primary participant node 10 can be configured to respond to the initiating node 20 only after receiving a response from the secondary participant node 12. Simultaneously, the primary participant node 10 can, for example, log in an associated log that it has received the commit command from the initiating node 20 for later use. Once the primary participant node 10 receives a response from the secondary participant node 12, the primary participant node 10 can (e.g., via the transaction management component 110) generate a response to the primary participant node 10's commit command and send that response back to the initiating node 20 along with the response received from the secondary participant node 12.

[0047] As shown in system 400, the primary participant node 10 can facilitate participant-driven transaction commits by acting as an intermediary between the secondary participant node 12 and the initiator node 20 during the commit phase of a transaction. For example, although the initiator node 20, as shown in system 400, can directly submit a commit command to the secondary participant node 12, once committed, the secondary participant node 12 can be configured to respond to the primary participant node 10 only with a response to the commit command, i.e., not directly responding to the initiator node 20. Furthermore, during the preparation phase of a transaction, the secondary participant node 12 can be configured to receive transaction messages only from the initiator node 20 and the primary participant node 10, and respond only to said nodes.

[0048] Now go to Figure 5 Illustration 500 illustrates an example message flow depicting a 2PCv2 transaction (e.g., a transaction associated with file system writes and / or similar operations). The message flow shown in Illustration 500 can be executed between an initiator 502 initiating an update to one or more data or metadata blocks (e.g., one or more blocks corresponding to a file, etc.), a primary participant 504 associated with the corresponding block to be updated and the primary log corresponding to the transaction, and a partner (secondary) participant associated with a partner (secondary) log corresponding to the primary log of the primary participant 504. While only one initiator 502, primary participant 504, and partner participant 506 are shown in Illustration 500 for simplicity, it should be understood that message flows similar to those shown in Illustration 500 can also be used for transactions involving multiple initiators 502, primary participants 504, and / or partner participants 506. For example, without departing from the scope of this specification, message flows similar to those shown in Illustration 500 can be used for transactions involving multiple primary participants 504, each potentially associated with one or more partner participants 506.

[0049] On one hand, one or more partner participants 506 may be assigned to a given primary participant 504 prior to the message flow shown in Figure 500 via a static partner nomination scheme and / or by other means. For example, for each storage node in a system identified by device identifier X, the storage node in the system with the next highest device identifier (e.g., folded back) may be nominated as a partner for that storage node. Other schemes may also be used. On the other hand, initiator 502 may obtain the generation indicator and / or other information for each primary participant 504 prior to the message flow shown in Figure 500 from Group Management Protocol (GMP) group information and / or other suitable information.

[0050] As indicated at time 510, initiator 502 may send transaction start (txn_start) messages to both primary participant(s) 504 and partner participant(s) 506. On one hand, initiator 502 may send the txn_start message in parallel to both primary participant(s) 504 and partner participant(s) 506, for example, as a shared message to both sets of participants 504 and 506 and / or in separate messages. On the other hand, the txn_start message sent by initiator 502 at time 510 may include verification information, such as the generation number and / or generation indicator of the master log obtained by initiator 502 prior to time 510.

[0051] At time 520, initiator 502 may send write and / or increment messages to primary participant 504, which collectively include a copy of the block to be updated at primary participant 504. For each write or increment message (e.g., write_block, write_delta, write_elide, write_inode, lin_super_write, etc.) sent by initiator 502 at time 520, initiator 502 may also send similar messages with the same payload to partner participant 506.

[0052] After transmitting write and / or incremental messages at time 520, subsequent transaction resolution can be performed according to the 2PCv2 protocol. For example, initiator 502 may send a transaction prepare (txn_prepare) message to (multiple) primary participants 504 and (multiple) partner participants 506 at time 230, which may then respond with transaction prepared (txn_prepared) messages at times 240 and 242, respectively. In response to receiving the txn_prepared message, initiator 502 may then send a transaction commit (txn_commit) message to (multiple) primary participants 504 and (multiple) partner participants 506 at time 550, which may then respond with transaction committed (txn_committed) messages at times 260 and 262, respectively. The message flow may then end at time 570, during which time initiator 502 sends a txn_committed message back to (multiple) primary participants 504 and (multiple) partner participants 506 to confirm the transaction.

[0053] On one hand, the message flow shown in Figure 500 has two phases, for example, a preparation phase and a commit phase. In the preparation phase, initiator 502 sends a `txn_prepare` message to primary participant 504 and partner participant 506, for example, at time 530. Then, primary participant 504 and partner participant 506 respond with `txn_prepared` messages at times 540 and 542, respectively. Any failure of initiator 502, primary participant 504, or partner participant 506 during this phase could cause the transaction to be aborted.

[0054] During the commit phase, if the initiator 502 receives a `txn_prepared` message from each of the primary participants 504 and partner participants 506 in the transaction, it sends a `txn_commit` message to each of them at, for example, time 550. Then, the primary participants 504 and partner participants 506 respond to the initiator 502 with `txn_committed` messages at times 560 and 562, respectively. Here, the initiator 502 can then wait for the first `txn_committed` response from either the primary participant 504 or the partner participant 506 before making the transaction's resolution available to its caller. On the other hand, in the case of transactions utilizing shared and non-shared participants, the above-described process for the commit phase of a transaction can be modified, as will be referred to below. Figure 9 Further discussion is needed.

[0055] Figure 6 Figure 600 illustrates another example message flow that can be executed between initiator 502, primary participant 504, and partner participant 506 to facilitate improved fault tolerance. In one aspect, the message flow shown in Figure 600 can operate similarly to the message flow shown in Figure 500 for the preparation phase of a transaction, for example, from time 510 to time 542, via an initiator-driven transaction mirroring.

[0056] In contrast to the message flow shown in Figure 500, the message flow shown in Figure 600 can be transformed into a participant-driven transaction model for the commit phase of a transaction. Therefore, in response to the txn_commit message sent by initiator 502 to primary participant 504 and secondary participant 506 at time 550, primary participant 504 can wait until partner participant 506 commits the transaction before proceeding. Thus, the message flow shown in Figure 600 progresses from time 550 to time 660, where partner participant 506 sends a txn_committed message to primary participant 504, for example, instead of initiator 502. In response to receiving this message, primary participant 504 can then send a txn_committed message to initiator 502 at time 662, indicating that the transaction has been committed at both primary participant 504 and partner participant 506. Initiator 502 can respond to the txn_committed message provided in 662 by sending, for example, the txn_committed message to the main participant 504 and the partner participant 506 at time 570 as described above.

[0057] On one hand, as shown in Figure 600, using a participant-driven model for the transaction commit phase can establish fault tolerance for the failure of partner participant 506, because partner participant 506 only responds to the primary participant 504 during the commit phase. Therefore, regardless of the operational state of partner participant 506 at time 662, the primary participant 504 can confirm the transaction commit to the initiator 502, thereby enabling the transaction to complete successfully.

[0058] Next, turn to Figure 7 This diagram illustrates a block diagram of a system that facilitates the execution of participant-driven data transactions in response to the unavailability of initiating node 20, according to various aspects described herein. For brevity, repeated descriptions of similar elements used in other embodiments described herein have been omitted. Figure 7 As shown and as described above, the transaction initiator node 20 can submit transaction preparation commands to the primary participant node 10 and / or the secondary participant node 12, for example, as part of the transaction preparation phase. Figure 7 As further shown, the primary participant node 10 of system 700 includes a transaction driver component 710, which, in response to determining that the initiator node 20 has been disconnected and / or otherwise unavailable, can send a response to a preparation command to the associated secondary participant node 12, for example, in place of the initiator node 20.

[0059] As described above, a transaction can be executed by the primary participant node 10 via an initiator-driven prepare phase and a participant-driven commit phase. If the primary participant node 10, which was ready before the end of the prepare phase, disconnects from the initiator node 20, the primary participant node 10 can, for example via the transaction driver component 710, only respond to the transaction from other primary participants after confirming the transaction status with its secondary participant node 12. Figure 7 Prepared messages (e.g., not shown in the image) Figures 5 to 6 (The txn_prepared message shown).

[0060] After disconnecting from the initiating node 20, the primary participant node 10 can first send a txn_prepared message to the secondary participant node 12. If the secondary participant node 12 has prepared the transaction, it can record the txn_prepared message from the primary participant node 10 and respond back to the primary participant node 10 in response to receiving a txn_commit or txn_abort message from the initiating node 20. Therefore, if the secondary participant node 12 remains connected to the initiating node 20, it can be configured to not respond until the transaction is aborted or committed by the initiating node 20.

[0061] Conversely, if secondary participant node 12 also disconnects from initiating node 20, secondary participant node 12 can be configured to respond only to its primary participant node 10. For example, in response to determining that initiating node 20 has disconnected, secondary participant node 12 can send a txn_prepared message to its primary participant node 10. Subsequently, secondary participant node 12 can be configured to receive txn_aborted and / or txn_committed messages from other primary participants, and upon receipt, log the messages and forward them to primary participant node 10. In doing so, secondary participant node 12 can be prevented from committing the transaction, while primary participant node 10 and any other primary participant can abort the transaction.

[0062] like Figure 8As further illustrated in system 800, the transaction driver component 710 of the primary participant node can, for example, commit a transaction previously received with a prepare command from the initiating node in a manner similar to that of the transaction commit component 210 described above. This can be accomplished, for example, in response to receiving a response message from the secondary participant node 12 indicating that the transaction has been committed at the secondary participant node 12. The primary participant node 10 of system 800 also includes a transaction confirmation component 810, which can send a commit confirmation message to the secondary participant node 12 and / or one or more other nodes in response to the commit of the transaction at the primary participant node 10. In other words, in addition to the participant-driven transaction commit operation described above, the transaction confirmation component 810 can also broadcast a txn_committed message to the corresponding other participants in the transaction, including the secondary participant node 12 and any other primary or secondary participant in the transaction ( Figure 8 (Not shown in the image).

[0063] On the one hand, Figures 7 to 8 If the secondary participant node 12 shown disconnects from the initiating node 20 during a transaction, the secondary participant node 12 can be configured to respond only to the primary participant node 10 to which it was assigned. Therefore, for example, the secondary participant node 12 in this example can be configured not to respond to other primary or secondary participants.

[0064] Now for reference Figure 9 This diagram illustrates a fault-tolerant system 900 that facilitates transaction mirroring via shared and non-shared participant nodes, according to various aspects described herein. For brevity, repeated descriptions of similar elements used in other embodiments described herein are omitted. Figure 9 As shown, system 900 includes computing device 902, which is a physical machine, or a cluster or arrangement of physical machines, on which both initiator node 20 and main participant node 10 reside. Since the main participant node 10 is implemented on the same computing device 902 as the initiator node 20 (e.g., as a separate logical entity, etc.), the main participant node 10 in system 900 is referred to as a shared participant.

[0065] On the one hand, shared participants can operate differently from non-shared (or "normal") participants as described above in order to preserve single-fault, non-blocking semantics. For example, in 2PCv2, the difference between a shared participant and a normal participant is that the initiating node 20 does not send commit messages to the shared participant. Further in contrast to normal participants, shared participants can be non-logged pseudo-participants in a transaction.

[0066] exist Figure 9In the example shown, the initiating node 20 can send a commit command 910, such as the txn_commit message as described above, to the corresponding normal participants in the transaction (here, the secondary participant node 12 and the normal primary participant node 14). In response, the shared primary participant node 10 can be configured to wait for a response message 920 to the commit command 910, such as the txn_committed message as described above, before committing the transaction. On one hand, the shared primary participant node 10 can handle the disconnection and / or lack of response of the associated secondary participant node 12 by marking it as invalid, for example, as referenced above. Figure 1 The NSB or other data structure described in 30.

[0067] Apart from Figure 9 In addition to the case of the primary shared participant shown, similar modifications can be made in the case of the secondary shared participant. For example, with Figure 9 Similar to the shared primary participant node 10, the shared secondary participant does not receive commit commands, such as txn_commit messages, from the initiating participant node 20. Furthermore, the shared secondary participant can be configured to commit the transaction only after receiving a txn_committed message and / or another suitable commit response from any other normal primary participant in the transaction.

[0068] Next reference Figure 10 The diagram illustrates a flowchart of a fault-tolerant method 1000 for facilitating transaction mirroring, based on various aspects described herein. At 1002, a system operatively coupled to the processor can receive and / or otherwise obtain (e.g., via transaction management component 110) a commit command (e.g., a txn_commit message) for a data transaction from the system's initiating node (e.g., initiating node 20). Here, the data transaction may be associated with a first fault domain, and the commit command may be directed to the system's primary participant node (e.g., primary participant node 10) and secondary (partner) participant nodes (e.g., secondary participant node 12).

[0069] At 1004, the system can determine (e.g., via status monitoring component 120) whether a response (e.g., a txn_committed message) has been received from the secondary participant node at the primary participant node in response to the commit command received at 1002.

[0070] At 1006, in response to determining at 1004 that the primary participant node has not received a response, the system may indicate (e.g., via state update component 130) that the secondary participant node is invalid in the data repository (e.g., NSB or other data structure 30) associated with the second fault domain, which is different from the fault domain associated with the transaction at 1002.

[0071] As described above Figure 10 Methods according to certain aspects of this disclosure are illustrated. Although for purposes of simplicity of explanation, the methods have been shown and described as a series of actions, it should be understood and appreciated that this disclosure is not limited to the order of actions, as some actions may occur in a different order than those shown and described herein and / or simultaneously with other actions. For example, those skilled in the art will understand and appreciate that the methods may alternatively be represented as a series of interrelated states or events, such as in a state diagram. Furthermore, according to certain aspects of this disclosure, not all illustrated actions may be required to implement these methods.

[0072] To provide additional context for the various embodiments described herein, Figure 11 The following discussion is intended to provide a brief, general description of a suitable computing environment 1100 in which various embodiments of the embodiments described herein may be implemented. Although the embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the embodiments may also be implemented in combination with other program modules and / or as a combination of hardware and software.

[0073] Generally, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will recognize that various methods can be implemented using other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframes, Internet of Things (IoT) devices, distributed computing systems, and personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, etc., where each computer system configuration can be operatively coupled to one or more associated devices.

[0074] The embodiments illustrated herein can also be implemented in a distributed computing environment, where certain tasks are performed by remote processing devices linked via a communication network. In a distributed computing environment, program modules can reside on both local and remote memory storage devices.

[0075] Computing devices typically include various media, which may include computer-readable storage media, machine-readable storage media, and / or communication media. These two terms are used herein as distinct from each other, as described below. A computer-readable storage medium or a machine-readable storage medium can be any available storage medium accessible by a computer and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, a computer-readable storage medium or a machine-readable storage medium can be implemented using any method or technique for storing information such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0076] Computer-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transient media that can be used to store desired information. In this regard, the terms “tangible” or “non-transient” used herein to describe storage, memory, or computer-readable media should be understood to exclude only the propagation of transient signals themselves as a modifier, and do not waive the rights to all standard storage devices, memory, or computer-readable media that do not only propagate transient signals themselves.

[0077] A computer-readable storage medium can be accessed by one or more local or remote computing devices, for example, via access requests, queries or other data retrieval protocols, for various operations concerning the information stored on the medium.

[0078] Communication media typically implement computer-readable instructions, data structures, program modules, or other structured or unstructured data in data signals such as modulated data signals, carrier waves, or other transmission mechanisms, and include any information delivery or transmission medium. The term "modulated data signal" or signal refers to a signal whose characteristics are set or altered in a manner that encodes information in one or more signals. By way of example and not limitation, communication media include wired media, such as wired networks or direct wired connections, and wireless media, such as acoustic, RF, infrared, and other wireless media.

[0079] Refer again Figure 11 Example environment 1100 for implementing various embodiments of the aspects described herein includes a computer 1102, which includes a processing unit 1104, system memory 1106, and a system bus 1108. The system bus 1108 couples system components, including but not limited to system memory 1106, to the processing unit 1104. The processing unit 1104 can be any commercially available processor. Dual-microprocessor and other multiprocessor architectures can also be employed as the processing unit 1104.

[0080] System bus 1108 can be any type of bus architecture, which can be further interconnected to memory buses (with or without memory controllers), peripheral buses, and local buses using any of the various commercially available bus architectures. System memory 1106 includes ROM 1110 and RAM 1112. The Basic Input / Output System (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, containing basic routines such as those that help transfer information between elements within computer 1102 during startup. RAM 1112 may also include high-speed RAM, such as static RAM, for caching data.

[0081] Computer 1102 also includes an internal hard disk drive (HDD) 1114 (e.g., EIDE, SATA), one or more external storage devices 1116 (e.g., floppy disk drive (FDD), memory stick or flash drive reader, memory card reader, etc.), and an optical disc drive 1120 (e.g., capable of reading from or writing to CD-ROMs, DVDs, BDs, etc.). While the internal HDD 1114 is shown as residing within computer 1102, it can also be configured for external use in a suitable chassis (not shown). Furthermore, although not shown in environment 1100, solid-state drives (SSDs) may be used in addition to or in place of HDD 1114. HDD 1114, external storage devices(s) 1116, and optical disc drive 1120 can be connected to system bus 1108 via HDD interface 1124, external storage interface 1126, and optical disc drive interface 1128, respectively. The interface 1124 for external driver implementation may include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies. Other external driver connectivity technologies are contemplated in the embodiments described herein.

[0082] The drive and its associated computer-readable storage medium provide non-volatile storage of data, data structures, computer-executable instructions, etc. For computer 1102, the drive and storage medium are adapted to store any data in a suitable digital format. Although the above description of computer-readable storage media refers to a corresponding type of storage device, those skilled in the art will understand that other types of computer-readable storage media, whether currently existing or developed in the future, may also be used in this example operating environment, and further, any such storage medium may contain computer-executable instructions for performing the methods described herein.

[0083] Multiple program modules can be stored in the drive and RAM 1112, including an operating system 1130, one or more application programs 1132, other program modules 1134, and program data 1136. All or part of the operating system, applications, modules, and / or data can also be cached in RAM 1112. The systems and methods described herein can be implemented using a variety of commercially available operating systems or combinations of operating systems.

[0084] Computer 1102 may optionally include emulation technology. For example, a hypervisor (not shown) or other intermediary may emulate the hardware environment of operating system 1130, and the emulated hardware may optionally be different from that of the operating system 1130. Figure 11 The hardware is shown. In such an embodiment, the operating system 1130 may include one of a plurality of virtual machines (VMs) hosted at the computer 1102. Furthermore, the operating system 1130 may provide the application 1132 with a runtime environment such as a Java runtime environment or the .NET Framework. A runtime environment is a consistent execution environment that allows the application 1132 to run on any operating system that includes a runtime environment. Similarly, the operating system 1130 may support containers, and the application 1132 may be in the form of a container, which is a lightweight, stand-alone, executable software package that includes, for example, the application's code, runtime, system tools, system libraries, and setup.

[0085] Furthermore, computer 1102 may have a security module, such as a Trusted Processing Module (TPM). For example, using a TPM, the boot component hashes the next boot component in time and waits for the result to match a security value before loading the next boot component. This process can occur at any level of the computer 1102's code execution stack, for example, at the application execution level or at the operating system (OS) kernel level, thereby achieving security at any level of code execution.

[0086] Users can input commands and information into computer 1102 through one or more wired / wireless input devices, such as keyboard 1138, touchscreen 1140, and pointing devices such as mouse 1142. Other input devices (not shown) may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls or other remote controls, joysticks, virtual reality controllers and / or virtual reality headsets, gamepads, pens, image input devices such as cameras(s), gesture sensor input devices, visual motion sensor input devices, emotion or face detection devices, biometric input devices such as fingerprint or iris scanners, etc. These and other input devices are typically connected to processing unit 1104 via input device interface 1144, which may be coupled to system bus 1108, but may be connected via other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, etc. Interfaces, etc.

[0087] Monitor 1146 or other types of display devices can also be connected to system bus 1108 via an interface such as video adapter 1148. In addition to monitor 1146, the computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0088] Computer 1102 can operate in a networked environment using logical connections to one or more remote computers, such as (multiple) remote computers 1150, via wired and / or wireless communications. The (multiple) remote computers 1150 can be workstations, server computers, routers, personal computers, laptops, microprocessor-based entertainment devices, peer-to-peer devices, or other shared network nodes, and typically include many or all of the elements described relative to computer 1102, although for brevity only memory / storage device 1152 is shown. The described logical connections include wired / wireless connections to a local area network (LAN) 1154 and / or a larger network (e.g., a wide area network (WAN) 1156). Such LAN and WAN network environments are common in offices and corporations and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to global communication networks, such as the Internet.

[0089] When used in a LAN networking environment, computer 1102 can connect to local network 1154 via a wired and / or wireless communication network interface or adapter 1158. Adapter 1158 can facilitate wired or wireless communication to LAN 1154, and may also include a wireless access point (AP) configured thereon for communicating with adapter 1158 in wireless mode.

[0090] When used in a WAN networking environment, computer 1102 may include modem 1160, or may be connected to a communication server on WAN 1156 via other means for establishing communication on WAN 1156 (e.g., via the Internet). Modem 1160 may be built-in or external, wired or wireless, and may be connected to system bus 1108 via input device interface 1144. In a networking environment, program modules described relative to computer 1102 or parts thereof may be stored in remote memory / storage device 1152. It should be understood that the network connection shown is an example, and other means of establishing communication links between computers may be used.

[0091] When used in a LAN or WAN networking environment, computer 1102 can access cloud storage systems or other network-based storage systems as a supplement to or replacement of the aforementioned external storage device 1116. Generally, the connection between computer 1102 and the cloud storage system can be established on LAN 1154 or WAN 1156 via, for example, adapter 1158 or modem 1160. When computer 1102 is connected to the associated cloud storage system, external storage interface 1126 can manage the storage provided by the cloud storage system with the aid of adapter 1158 and / or modem 1160, just as it manages other types of external storage. For example, external storage interface 1126 can be configured to provide access to cloud storage sources as if these sources were physically connected to computer 1102.

[0092] Computer 1102 is operable to communicate with any wireless device or entity operably arranged in wireless communication, such as printers, scanners, desktop and / or portable computers, portable data assistants, communication satellites, any device or location associated with a wirelessly detectable tag (e.g., a kiosk, newsstand, store shelf, etc.), and telephones. This may include Wi-Fi and Wireless technology. Therefore, the communication can be a predefined structure like a traditional network, or simply self-organizing communication between at least two devices.

[0093] The foregoing description includes non-limiting examples of various embodiments. It is certainly not possible to describe every conceivable combination of components or methods in order to describe the disclosed subject matter, and those skilled in the art will recognize that further combinations and arrangements of the various embodiments are possible. The disclosed subject matter is intended to encompass all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

[0094] Regarding the various functions performed by the aforementioned components, devices, circuits, systems, etc., unless otherwise stated, the terminology used to describe these components (including references to "apparatus") is also intended to include any (e.g., functionally equivalent) structures(s) that perform the specified functions of the described components, even if they are not structurally equivalent to the disclosed structures. Furthermore, while a particular feature of the disclosed subject matter may be disclosed only for one of several implementations, such feature may be combined with one or more other features of other implementations, which may be desirable and advantageous for any given or particular application.

[0095] The terms “exemplary” and / or “illustrative” as used herein are intended to mean as an example, instance, or illustration. To avoid ambiguity, the subject matter disclosed herein is not limited to these examples. Furthermore, any aspect or design described herein as “exemplary” and / or “illustrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor does it imply the exclusion of equivalent structures and techniques known to those skilled in the art. Moreover, with regard to the use of the terms “comprising,” “having,” “including,” and other similar words in the specification or claims, these terms are intended to indicate inclusion—in a manner similar to the term “comprising” as an open conversion term—without excluding any additional or other elements.

[0096] The term “or” as used herein is intended to mean inclusive “or” rather than exclusive “or”. For example, the phrase “A or B” is intended to include instances of A, B, and both A and B. Furthermore, the article “a” as used in this application and the appended claims should generally be interpreted as meaning “one or more” unless otherwise stated or clearly indicated from the context to be in the singular form.

[0097] The term "set" as used herein does not include the empty set, i.e., a set containing no elements. Therefore, "set" in this subject disclosure includes one or more elements or entities. Similarly, the term "group" as used herein refers to a collection of one or more entities.

[0098] The terms “first,” “second,” “third,” etc., used in the claims are for clarity only and do not indicate or imply any order of time. For example, “first determination,” “second determination,” and “third determination” do not indicate or imply that the first determination was made before the second determination, or vice versa, etc.

[0099] The description of the illustrated embodiments disclosed herein, including those described in the abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples have been described herein for illustrative purposes, those skilled in the art will recognize that various modifications are possible within the scope of these embodiments and examples. In this regard, although the subject matter has been described herein in conjunction with various embodiments and corresponding drawings, it will be understood where applicable that other similar embodiments may be used, or modifications and additions may be made to the described embodiments to perform the same, similar, alternative, or substitute functions of the disclosed subject matter without departing from them. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but should be interpreted broadly and broadly in accordance with the appended claims.

Claims

1. A data storage system, comprising: Memory, which stores executable components; as well as The processor executes the executable component stored in the memory, wherein the executable component includes: A transaction management component receives a transaction commit command from the initiator node of the data storage system at the primary participant node of the data storage system. The transaction commit command corresponds to a data transaction associated with a first fault domain. The transaction commit command is directed by the initiator node to the primary participant node and the secondary participant node of the data storage system. A status monitoring component, in response to receiving the transaction commit command, determines whether a response message to the transaction commit command has been received at the primary participant node from the secondary participant node, wherein the secondary participant node only transmits the response message to the primary participant node; and The state update component, in response to determining that the response message was not received by the primary participant node from the secondary participant node within a threshold time period, indicates the secondary participant node as invalid in a data structure stored in a second fault domain different from the first fault domain.

2. The data storage system according to claim 1, wherein the executable component further comprises: A transaction commit component, which, in response to receiving the transaction commit command at the primary participant node, commits the data transaction at the primary participant node.

3. The data storage system according to claim 2, wherein the response message is a first response message, wherein the transaction commit component generates a second response message to the transaction commit command in response to committing the data transaction at the primary participant node, and wherein the transaction management component transmits the second response message to the initiating node.

4. The data storage system of claim 3, wherein the transaction commit component commits the data transaction, and in response to the state update component indicating the secondary participant node as invalid in the data structure, transmits the second response message to the initiating node.

5. The data storage system of claim 3, wherein in response to the first response message being received from the secondary participant node, the transaction commit component transmits the first response message and the second response message to the initiating node.

6. The data storage system of claim 2, wherein the primary participant node is a first primary participant node located on the same device as the initiator node, wherein the response message is a first response message, wherein the transaction commit command is further directed to a second primary participant node different from the first primary participant node, and wherein the transaction commit component further commits the data transaction at the first primary participant node in response to receiving a second response message for the transaction commit command from the second primary participant node.

7. The data storage system according to claim 1, wherein the transaction commit command is a first transaction commit command, wherein the data transaction is a first data transaction, wherein the transaction management component further receives a transaction preparation command for a second data transaction from the initiating node, and wherein the executable component further comprises: A transaction driver component, in response to determining that the initiating node has become unavailable, transmits a transaction preparation response message for the second data transaction to the secondary participating node.

8. The data storage system of claim 7, wherein the response message is a first response message, and wherein the transaction driver component, in response to receiving a second response message for the second data transaction from the secondary participant node, commits the second data transaction at the primary participant node.

9. The system of claim 1, wherein in response to determining that the response message was not received by the primary participant node from the secondary participant node within a threshold time period, the transaction management component discards the secondary participant node from the transaction.

10. A method comprising: The system, which is operatively coupled to the processor, receives a commit command for a data transaction from the initiating node of the system, wherein the data transaction is associated with a first fault domain, and wherein the commit command is directed by the initiating node to the primary and secondary participating nodes of the system. In response to the receipt, the system determines whether a response to the submit command has been received at the primary participant node from the secondary participant node, wherein the secondary participant node only transmits the response to the primary participant node. as well as In response to determining that the response to the submit command was not received at the primary participant node, the system instructs the secondary participant node to be invalid in the data repository associated with a second fault domain different from the first fault domain.

11. The method of claim 10, further comprising: The system responds to receiving the commit command at the primary participant node and commits the data transaction at the primary participant node.

12. The method of claim 11, wherein the response is a first response, and wherein the method further comprises: The system generates a second response to the commit command in response to the data transaction being committed at the primary participant node. as well as The system transmits the second response to the initiating node.

13. The method of claim 12, wherein submitting the data transaction at the primary participant node comprises: In response to indicating that the secondary participant node is invalid in the data repository, the second response is transmitted to the initiating node.

14. The method of claim 12, wherein submitting the data transaction at the primary participant node comprises: In response to receiving the first response from the secondary participant node, the first response and the second response are transmitted to the initiating node.

15. The method of claim 10, wherein the response is a first response, the commit command is a first commit command, the data transaction is a first data transaction, and the method further comprises: The system receives a preparation command for the second data transaction from the initiating node; In response to determining that the initiating node has become unavailable, the system transmits a preparation response message for the second data transaction to the secondary participating node; as well as The system, in response to receiving a second response for the second data transaction from the secondary participant node, submits the second data transaction at the primary participant node.

16. A non-transient machine-readable medium comprising computer-executable instructions that, when executed by a processor of a data storage system, facilitate the execution of operations, the operations comprising: The system receives a first command from the initiator node of the data storage system to submit a transaction associated with a first fault domain. The first command is directed by the initiator node to the main participant node and partner participant node of the data storage system. In response to the receipt, it is determined whether a response to the first command has been received at the primary participant node from the partner participant node, wherein the partner participant node transmits the response to the first command only to the primary participant node. as well as In response to determining that the response to the first command was not received at the primary participant node within a threshold time period, the partner participant node is marked as inactive in a data structure associated with a second fault domain different from the first fault domain.

17. The non-transient machine-readable medium of claim 16, wherein the operation further comprises: In response to receiving the first command at the primary participant node, the transaction is committed at the primary participant node.

18. The non-transient machine-readable medium of claim 17, wherein the response is a first response, and wherein the operation further comprises: In response to the submission of the transaction at the primary participant node, a second response to the first command is generated; as well as The second response is transmitted from the main participant node to the initiator node.

19. The non-transient machine-readable medium of claim 18, wherein the operation further comprises: In response to identifying the partner participant node as inactive in the data structure, the second response is transmitted from the main participant node to the initiator node.

20. The non-transient machine-readable medium of claim 18, wherein the operation further comprises: In response to receiving the first response from the partner participant node, the first response and the second response are transmitted from the main participant node to the initiator node.

Images