Patent Application
20230004448
This application generally relates to data storage.
Systems may include different resources used by one or more host processors. The resources and the host processors in the system may be interconnected by one or more communication connections, such as network connections. These resources may include data storage devices such as those included in data storage systems. The data storage systems may be coupled to one or more host processors and provide storage services to each host processor. Multiple data storage systems from one or more different vendors may be connected and may provide common data storage for the one or more host processors.
A host may perform a variety of data processing tasks and operations using the data storage system. For example, a host may issue I/O operations, such as data read and write operations, received at a data storage system. The host systems may store and retrieve data by issuing the I/O operations to the data storage system containing a plurality of host interface units, disk drives (or more generally storage devices), and disk interface units. The host systems access the storage devices through a plurality of channels provided therewith. The host systems provide data and access control information through the channels to a storage device of the data storage system. Data stored on the storage device may also be provided from the data storage system to the host systems also through the channels. The host systems do not address the storage devices of the data storage system directly, but rather, access what appears to the host systems as a plurality of files, objects, logical units, logical devices or logical volumes. Thus, the I/O operations issued by the host may be directed to a particular storage entity, such as a file or logical device. The logical devices may or may not correspond to the actual physical drives. Allowing multiple host systems to access the single data storage system allows the host systems to share data stored therein.
Various embodiments of the techniques herein may include a method, a system and a computer readable medium for comprising: performing first processing in accordance with one or more policies to assign a winner role and a loser role between a first node and a second node, wherein current assignments of the winner role and the loser role among the first node and the second node are used in connection with deadlock resolution processing; detecting a deadlock or potential deadlock between a first node performing processing for a first transaction and a second node performing processing for a second transaction; in response to detecting the deadlock or potential deadlock by the first node, using a first current state of the first node to determine whether to perform said deadlock resolution processing to resolve the deadlock or potential deadlock, wherein the first current state indicates whether the first processing is in progress whereby role assignment of the winner role and the loser role between the first node and the second node is in progress and not synchronized among the first node and second node; and responsive to the first current state indicating that the first processing is not in progress whereby role assignment of the winner role and the loser role between the first node and the second node is not in progress and is synchronized among the first node and second node, using the first current state of the first node to perform said deadlock resolution processing to resolve the deadlock or potential deadlock detected by the first node.
In at least one embodiment, the first current state may be any one of three predetermined states. The three predetermined states may include a first predetermined state indicating that the first node is currently assigned the winner role and the second node is currently assigned the loser role. The three predetermined states may include a second predetermined state indicating that the second node is currently assigned the winner role and the first node is currently assigned the loser role. The three predetermined states may include a third predetermined state indicating that the first processing is in progress whereby role assignment of the winner role and the loser role between the first node and the second node is in progress and not synchronized among the first node and second node.
In at least one embodiment, the first current state may have a first value denoting either the first predetermined state or the second predetermined state whereby the first current state denotes that the first processing is not in progress, role assignment of the winner role and the loser role between the first node and the second node is not in progress, and role assignment of the winner role and loser role is synchronized among the first node and second node, and wherein the method may include performing said deadlock resolution processing to resolve the deadlock or potential deadlock detected by the first node.
In at least one embodiment, the first current state may have a second value denoting the third predetermined state indicating that the first processing is in progress, role assignment of the winner role and the loser role between the first node and the second node is in progress, and role assignment of the winner role and loser role is not synchronized among the first node and second node, and wherein the method may include waiting to perform said deadlock resolution processing to resolve the deadlock or potential deadlock detected by the first node. Waiting to perform the deadlock resolution processing may include placing a first conflicting lock request on a first queue. The first conflicting lock request may be between the first transaction and the second transaction. Responsive to the first current state transitioning from the second value denoting the third predetermined state to another value denoting either the first predetermined state or the second predetermined state, the first current state of the first node may be used to perform deadlock resolution processing to resolve the deadlock or potential deadlock detected by the first node.
In at least one embodiment, servicing each of the first transaction and the second transaction may include updating a set of one or more metadata (MD) pages. Servicing the first transaction may include acquiring exclusive access to a first MD page. Servicing the first transaction may include: acquiring a first local lock of the first node for a first MD page; and acquiring a second local lock of the second node for a first MD page. Servicing the second transaction may include acquiring exclusive access to the first MD page. Servicing the second transaction may include: acquiring the first local lock of the first node for a first MD page; and acquiring the second local lock of the second node for a first MD page. At a first point in time, the first local lock of the first node for the first MD page may be held by the first node, the second local lock of the second node for the first MD page may be held by the second node, the second node may have requested but not yet acquired the first local lock of the first node for the first MD page, and the first node may have requested but not yet acquired the second local lock of the second node for the first MD page. The first node may detect the deadlock or potential deadlock at the first point in time in response to the first node receiving a request from the second node for the first local lock of the first node for the first MD page while the first node holds the first local lock for the first MD page and while the first node also has an outstanding request for the second local lock of the second node for the first MD page.
In at least one embodiment, performing the first processing in accordance with one or more policies to assign a winner role and a loser role between a first node and a second node may be initiated by one of the first node and the second node currently assigned the loser role when the current one is also an initiator servicing a transaction. The first processing may include the one node sending, to the other of the first node and the second node, a new winner value indicating that the one node is transitioning from the loser role to the winner role, and indicating that the other of the first node and the second node is transitioning form the winner role to the loser role. The one or more policies may include a first policy indicating to periodically performing the first processing to assign a winner role and a loser role between a first node and a second node. The first policy may indicate to perform the first processing at any of: each occurrence of a defined time interval, and each time a specified number of transactions is processed collectively by the first node and the second node.
Features and advantages of the present invention will become more apparent from the following detailed description of exemplary embodiments thereof taken in conjunction with the accompanying drawings in which:
Referring to the
Each of the host systems 14a-14n and the data storage system 12 included in the system 10 may be connected to the communication medium 18 by any one of a variety of connections as may be provided and supported in accordance with the type of communication medium 18. The processors included in the host systems 14a-14n and data storage system 12 may be any one of a variety of proprietary or commercially available single or multi-processor system, such as an Intel-based processor, or other type of commercially available processor able to support traffic in accordance with each particular embodiment and application.
It should be noted that the particular examples of the hardware and software that may be included in the data storage system 12 are described herein in more detail, and may vary with each particular embodiment. Each of the hosts 14a-14n and the data storage system 12 may all be located at the same physical site, or, alternatively, may also be located in different physical locations. The communication medium 18 used for communication between the host systems 14a-14n and the data storage system 12 of the system 10 may use a variety of different communication protocols such as block-based protocols (e.g., SCSI, Fibre Channel, iSCSI), file system-based protocols (e.g., NFS or network file server), and the like. Some or all of the connections by which the hosts 14a-14n and the data storage system 12 may be connected to the communication medium 18 may pass through other communication devices, such as switching equipment, a phone line, a repeater, a multiplexer or even a satellite.
Each of the host systems 14a-14n may perform data operations. In the embodiment of the
It should be noted that although the element 12 is illustrated as a single data storage system, such as a single data storage array, the element 12 may also represent, for example, multiple data storage arrays alone, or in combination with, other data storage devices, systems, appliances, and/or components having suitable connectivity, such as in a SAN (storage area network) or LAN (local area network), in an embodiment using the techniques herein. It should also be noted that an embodiment may include data storage arrays or other components from one or more vendors. In subsequent examples illustrating the techniques herein, reference may be made to a single data storage array by a vendor. However, as will be appreciated by those skilled in the art, the techniques herein are applicable for use with other data storage arrays by other vendors and with other components than as described herein for purposes of example.
The data storage system 12 may be a data storage appliance or a data storage array including a plurality of data storage devices (PDs) 16a-16n. The data storage devices 16a-16n may include one or more types of data storage devices such as, for example, one or more rotating disk drives and/or one or more solid state drives (SSDs). An SSD is a data storage device that uses solid-state memory to store persistent data. SSDs may refer to solid state electronics devices as distinguished from electromechanical devices, such as hard drives, having moving parts. Flash devices or flash memory-based SSDs are one type of SSD that contains no moving mechanical parts. The flash devices may be constructed using nonvolatile semiconductor NAND flash memory. The flash devices may include, for example, one or more SLC (single level cell) devices and/or MLC (multi level cell) devices.
The data storage array may also include different types of controllers, adapters or directors, such as an HA 21 (host adapter), RA 40 (remote adapter), and/or device interface(s) 23. Each of the adapters (sometimes also known as controllers, directors or interface components) may be implemented using hardware including a processor with a local memory with code stored thereon for execution in connection with performing different operations. The HAs may be used to manage communications and data operations between one or more host systems and the global memory (GM). In an embodiment, the HA may be a Fibre Channel Adapter (FA) or other adapter which facilitates host communication. The HA 21 may be characterized as a front end component of the data storage system which receives a request from one of the hosts 14a-n. The data storage array may include one or more RAs that may be used, for example, to facilitate communications between data storage arrays. The data storage array may also include one or more device interfaces 23 for facilitating data transfers to/from the data storage devices 16a-16n. The data storage device interfaces 23 may include device interface modules, for example, one or more disk adapters (DAs) (e.g., disk controllers) for interfacing with the flash drives or other physical storage devices (e.g., PDS 16a-n). The DAs may also be characterized as back end components of the data storage system which interface with the physical data storage devices.
One or more internal logical communication paths may exist between the device interfaces 23, the RAs 40, the HAs 21, and the memory 26. An embodiment, for example, may use one or more internal busses and/or communication modules. For example, the global memory portion 25b may be used to facilitate data transfers and other communications between the device interfaces, the HAs and/or the RAs in a data storage array. In one embodiment, the device interfaces 23 may perform data operations using a system cache that may be included in the global memory 25b, for example, when communicating with other device interfaces and other components of the data storage array. The other portion 25a is that portion of the memory that may be used in connection with other designations that may vary in accordance with each embodiment.
The particular data storage system as described in this embodiment, or a particular device thereof, such as a disk or particular aspects of a flash device, should not be construed as a limitation. Other types of commercially available data storage systems, as well as processors and hardware controlling access to these particular devices, may also be included in an embodiment.
The host systems 14a-14n provide data and access control information through channels to the storage systems 12, and the storage systems 12 may also provide data to the host systems 14a-n also through the channels. The host systems 14a-n do not address the drives or devices 16a-16n of the storage systems directly, but rather access to data may be provided to one or more host systems from what the host systems view as a plurality of logical devices, logical volumes (LVs) which may also referred to herein as logical units (e.g., LUNs). A logical unit (LUN) may be characterized as a disk array or data storage system reference to an amount of storage space that has been formatted and allocated for use to one or more hosts. A logical unit may have a logical unit number that is an I/O address for the logical unit. As used herein, a LUN or LUNs may refer to the different logical units of storage which may be referenced by such logical unit numbers. The LUNs may or may not correspond to the actual or physical disk drives or more generally physical storage devices. For example, one or more LUNs may reside on a single physical disk drive, data of a single LUN may reside on multiple different physical devices, and the like. Data in a single data storage system, such as a single data storage array, may be accessed by multiple hosts allowing the hosts to share the data residing therein. The HAs may be used in connection with communications between a data storage array and a host system. The RAs may be used in facilitating communications between two data storage arrays. The DAs may include one or more type of device interface used in connection with facilitating data transfers to/from the associated disk drive(s) and LUN (s) residing thereon. For example, such device interfaces may include a device interface used in connection with facilitating data transfers to/from the associated flash devices and LUN(s) residing thereon. It should be noted that an embodiment may use the same or a different device interface for one or more different types of devices than as described herein.
In an embodiment in accordance with the techniques herein, the data storage system as described may be characterized as having one or more logical mapping layers in which a logical device of the data storage system is exposed to the host whereby the logical device is mapped by such mapping layers of the data storage system to one or more physical devices. Additionally, the host may also have one or more additional mapping layers so that, for example, a host side logical device or volume is mapped to one or more data storage system logical devices as presented to the host.
It should be noted that although examples of the techniques herein may be made with respect to a physical data storage system and its physical components (e.g., physical hardware for each HA, DA, HA port and the like), the techniques herein may be performed in a physical data storage system including one or more emulated or virtualized components (e.g., emulated or virtualized ports, emulated or virtualized DAs or HAs), and also a virtualized or emulated data storage system including virtualized or emulated components.
Also shown in the
Information regarding the data storage system configuration may be stored in any suitable data container, such as a database. The data storage system configuration information stored in the database may generally describe the various physical and logical entities in the current data storage system configuration. The data storage system configuration information may describe, for example, the LUNs configured in the system, properties and status information of the configured LUNs (e.g., LUN storage capacity, unused or available storage capacity of a LUN, consumed or used capacity of a LUN), configured RAID groups, properties and status information of the configured RAID groups (e.g., the RAID level of a RAID group, the particular PDs that are members of the configured RAID group), the PDs in the system, properties and status information about the PDs in the system, local replication configurations and details of existing local replicas (e.g., a schedule or other trigger conditions of when a snapshot is taken of one or more LUNs, identify information regarding existing snapshots for a particular LUN), remote replication configurations (e.g., for a particular LUN on the local data storage system, identify the LUN's corresponding remote counterpart LUN and the remote data storage system on which the remote LUN is located), data storage system performance information such as regarding various storage objects and other entities in the system, and the like.
Consistent with other discussion herein, management commands issued over the control or data path may include commands that query or read selected portions of the data storage system configuration, such as information regarding the properties or attributes of one or more LUNs. The management commands may also include commands that write, update, or modify the data storage system configuration, such as, for example, to create or provision a new LUN (e.g., which may result in modifying one or more database tables such as to add information for the new LUN), to modify an existing replication schedule or configuration (e.g., which may result in updating existing information in one or more database tables for the current replication schedule or configuration), to delete a LUN (e.g., which may include deleting the LUN from a table of defined LUNs and may also include modifying one or more other database tables to delete any existing snapshots of the LUN being deleted), and the like.
It should be noted that each of the different controllers or adapters, such as each HA, DA, RA, and the like, may be implemented as a hardware component including, for example, one or more processors, one or more forms of memory, and the like. Code may be stored in one or more of the memories of the component for performing processing.
The device interface, such as a DA, performs I/O operations on a physical device or drive 16a-16n. In the following description, data residing on a LUN may be accessed by the device interface following a data request in connection with I/O operations. For example, a host may issue an I/O operation which is received by the HA 21. The I/O operation may identify a target location from which data is read from, or written to, depending on whether the I/O operation is, respectively, a read or a write operation request. The target location of the received I/O operation may be expressed in terms of a LUN and logical address or offset location (e.g., LBA or logical block address) on the LUN. Processing may be performed on the data storage system to further map the target location of the received I/O operation, expressed in terms of a LUN and logical address or offset location on the LUN, to its corresponding physical storage device (PD) and location on the PD. The DA which services the particular PD may further perform processing to either read data from, or write data to, the corresponding physical device location for the I/O operation.
It should be noted that an embodiment of a data storage system may include components having different names from that described herein but which perform functions similar to components as described herein. Additionally, components within a single data storage system, and also between data storage systems, may communicate using any suitable technique that may differ from that as described herein for exemplary purposes. For example, element 12 of the
Generally, the techniques herein may be used in connection with any suitable storage system, appliance, device, and the like, in which data is stored. For example, an embodiment may implement the techniques herein using a midrange data storage system, such as a Dell EMC Unity® data storage system or a Dell EMC PowerStore® data storage system, as well as a high end or enterprise data storage system, such as a Dell EMC™ PowerMAX™ data storage system.
The data path or I/O path may be characterized as the path or flow of I/O data through a system. For example, the data or I/O path may be the logical flow through hardware and software components or layers in connection with a user, such as an application executing on a host (e.g., more generally, a data storage client) issuing I/O commands (e.g., SCSI-based commands, and/or file-based commands) that read and/or write user data to a data storage system, and also receive a response (possibly including requested data) in connection such I/O commands.
The control path, also sometimes referred to as the management path, may be characterized as the path or flow of data management or control commands through a system. For example, the control or management path may be the logical flow through hardware and software components or layers in connection with issuing data storage management command to and/or from a data storage system, and also receiving responses (possibly including requested data) to such control or management commands. For example, with reference to the
The data path and control path define two sets of different logical flow paths. In at least some of the data storage system configurations, at least part of the hardware and network connections used for each of the data path and control path may differ. For example, although both control path and data path may generally use a network for communications, some of the hardware and software used may differ. For example, with reference to the
With reference to the
In a manner similar to that as described for data path 104, the data path 106 for processing node B 102b has its own FE component 106a, system cache layer 106b, inline processing layer 105b, and BE component 106c that are respectively similar to the components 104a, 104b, 105a and 104c. The elements 110a, 110b denote the non-volatile BE physical storage provisioned from PDs for the LUNs, whereby an I/O may be directed to a location or logical address of a LUN and where data may be read from, or written to, the logical address. The LUNs 110a, 110b are examples of storage objects representing logical storage entities included in an existing data storage system configuration. Since, in this example, writes directed to the LUNs 110a, 110b may be received for processing by either of the nodes 102a and 102b, the example 100 illustrates what may also be referred to as an active-active configuration.
In connection with a write operation as may be received from a host and processed by the processing node A 102a, the write data may be written to the system cache 104b, marked as write pending (WP) denoting it needs to be written to the physical storage 110a, 110b and, at a later point in time, the write data may be destaged or flushed from the system cache to the physical storage 110a, 110b by the BE component 104c. The write request may be considered complete once the write data has been stored in the system cache whereby an acknowledgement regarding the completion may be returned to the host (e.g., by component the 104a). At various points in time, the WP data stored in the system cache is flushed or written out to the physical storage 110a, 110b.
In connection with the inline processing layer 105a, prior to storing the original data on the physical storage 110a, 110b, one or more data reduction operations may be performed. For example, the inline processing may include performing data compression processing, data deduplication processing, and the like, that may convert the original data (as stored in the system cache prior to inline processing) to a resulting representation or form which is then written to the physical storage 110a, 110b.
In connection with a read operation to read a block of data, a determination is made as to whether the requested read data block is stored in its original form (in system cache 104b or on physical storage 110a, 110b), or whether the requested read data block is stored in a different modified form or representation. If the requested read data block (which is stored in its original form) is in the system cache, the read data block is retrieved from the system cache 104b and returned to the host. Otherwise, if the requested read data block is not in the system cache 104b but is stored on the physical storage 110a, 110b in its original form, the requested data block is read by the BE component 104c from the backend storage 110a, 110b, stored in the system cache and then returned to the host.
If the requested read data block is not stored in its original form, the original form of the read data block is recreated and stored in the system cache in its original form so that it can be returned to the host. Thus, requested read data stored on physical storage 110a, 110b may be stored in a modified form where processing is performed by 105a to restore or convert the modified form of the data to its original data form prior to returning the requested read data to the host.
Also illustrated in
In connection with at least one embodiment in accordance with the techniques herein, each processor or CPU may include its own private dedicated CPU cache (also sometimes referred to as processor cache) that is not shared with other processors. In at least one embodiment, the CPU cache, as in general with cache memory, may be a form of fast memory (relatively faster than main memory which may be a form of RAM). In at least one embodiment, the CPU or processor cache is on the same die or chip as the processor and typically, like cache memory in general, is far more expensive to produce than normal RAM such as may be used as main memory. The processor cache may be substantially faster than the system RAM such as used as main memory and contains information that the processor will be immediately and repeatedly accessing. The faster memory of the CPU cache may, for example, run at a refresh rate that's closer to the CPU's clock speed, which minimizes wasted cycles. In at least one embodiment, there may be two or more levels (e.g., L1, L2 and L3) of cache. The CPU or processor cache may include at least an L1 level cache that is the local or private CPU cache dedicated for use only by that particular processor. The two or more levels of cache in a system may also include at least one other level of cache (LLC or lower level cache) that is shared among the different CPUs. The L1 level cache serving as the dedicated CPU cache of a processor may be the closest of all cache levels (e.g., L1-L3) to the processor which stores copies of the data from frequently used main memory locations. Thus, the system cache as described herein may include the CPU cache (e.g., the L1 level cache or dedicated private CPU/processor cache) as well as other cache levels (e.g., the LLC) as described herein. Portions of the LLC may be used, for example, to initially cache write data which is then flushed to the backend physical storage such as BE PDs providing non-volatile storage. For example, in at least one embodiment, a RAM based memory may be one of the caching layers used as to cache the write data that is then flushed to the backend physical storage. When the processor performs processing, such as in connection with the inline processing 105a, 105b as noted above, data may be loaded from the main memory and/or other lower cache levels into its CPU cache.
In at least one embodiment, the data storage system may be configured to include one or more pairs of nodes, where each pair of nodes may be generally as described and represented as the nodes 102a-b in the
In at least one embodiment, the data storage system may be configured to provide both block and file storage services with a system software stack that includes an operating system running directly on the processors of the nodes of the system.
In at least one embodiment, the data storage system may be configured to provide block-only storage services (e.g., no file storage services). A hypervisor may be installed on each of the nodes to provide a virtualized environment of virtual machines (VMs). The system software stack may execute in the virtualized environment deployed on the hypervisor. The system software stack (sometimes referred to as the software stack or stack) may include an operating system running in the context of a VM of the virtualized environment. Additional software components may be included in the system software stack and may also execute in the context of a VM of the virtualized environment.
In at least one embodiment, each pair of nodes may be configured in an active-active configuration as described elsewhere herein, such as in connection with
In at least one embodiment, each pair of nodes provides a dual node architecture where both nodes of the pair may be identical in terms of hardware and software for redundancy and high availability. Consistent with other discussion herein, each node of a pair may perform processing of the different components (e.g., FA, DA, and the like) in the data path or I/O path as well as the control or management path. Thus, in such an embodiment, different components, such as the FA, DA and the like of
Consistent with other discussion herein, a cache may be used for caching write I/O data and other cached information. The other cached information may include, for example, cached operations or commands such as create snapshot commands. In one system, the cache may be implemented using multiple caching devices or PDs, such as non-volatile (NV) SSDs such as NVRAM devices that are external with respect to both of the nodes or storage controllers. The caching devices or PDs used to implement the cache may be configured in a RAID group of any suitable RAID level for data protection. The caching PDs form a shared cache accessible to both nodes of the dual node architecture. It should be noted that in a system where the caching devices or PDs are external with respect to the two nodes, the caching devices or PDs are in addition to other non-volatile PDs accessible to both nodes. The additional PDs provide the BE non-volatile storage for the nodes where the cached data stored on the caching devices or PDs is eventually flushed to the BE PDs as discussed elsewhere herein.
In the following paragraphs, the one or more caching devices or PDs may be referred to as a data journal or log used in the data storage system. In such a system, the caching devices or PDs are non-volatile log devices or PDs upon which the log is persistently stored.
In a data storage system, minimizing the latency of I/O requests is a critical performance metric. In at least one data storage system using the dual node architecture such as described in connection with
Consistent with other discussion herein, the log file may be used to optimize write operation latency. Generally, a write operation writing data is received by the data storage system from a host or other client. The data storage system then performs processing to persistently record the write operation in the log. Once the write operation is persistently recorded in the log, the data storage system may send an acknowledgement to the client regarding successful completion of the write operation. At some point in time subsequent to logging the write operation the log, the write operation is flushed or destaged from the log to the BE PDs. In connection with flushing the recorded write operation from the log, the data written by the write operation is stored on non-volatile physical storage of a BE PD. The space of the log used to record the write operation that has been flushed may now be reclaimed for reuse.
It should be noted that the flushing of the log may be performed in response to an occurrence of any one or more defined conditions. For example, the log may be flushed in response to determining that the amount of reclaimed log space available for use and allocation is less than a specified threshold amount or size.
In at least one embodiment, a metadata (MD) structure of mapping information that may be used in accordance with the techniques herein.
The mapping information may be used, for example, to map a logical address, such as a LUN and an LBA or offset, to its corresponding storage location, such as a physical storage location on BE non-volatile PDs of the system. Consistent with discussion elsewhere herein, write requests or operations stored in the log may be flushed to the BE PDs (non-volatile) providing storage locations for the written data. For example, a logged write operation that writes first data to a logical address may be flushed whereby the logged first data is written out to a physical storage location on a BE PD. The mapping information may be used to map the logical address to the physical storage location containing the content or data stored at the logical address. In at least one embodiment, the mapping information may include a MD structure that is hierarchical structure of multiple layers.
In at least one embodiment, the mapping structure for a LUN, such as a LUN A, may be in the form of a tree having a plurality of levels of MD pages. More generally, the mapping structure may be in the form of any ordered list or hierarchical structure. In at least one embodiment, the mapping structure for the LUN A may include LUN MD in the form of a tree having 3 levels including a single top or root node (TOP node), a single mid-level (MID node) and a bottom level of leaf nodes (LEAF nodes), where each of the MD page leaf nodes may point to, or reference (directly or indirectly) one or more pages of stored data, such as user data stored on the LUN A. Each node in the tree may correspond to a MD page including MD for the LUN A. More generally, the tree or other hierarchical structure of various MD pages of the mapping structure for the LUN A may include any suitable number of levels, such as more than 3 levels where there are multiple mid-levels. In at least one embodiment the tree of MD pages for the LUN may be a B+ tree, also sometimes referred to as an “N-ary” tree, where “N” indicates that each node in the tree structure may have up to a maximum of N child nodes. For example, in at least one embodiment, the tree of MD pages for the LUN may specify N=512 whereby each node in the tree structure may have up to a maximum of N child nodes. For simplicity of illustration, the tree structure of MD pages, corresponding to the mapping structure in at least one embodiment, is represented in
Referring to
The links or connections between a parent node (at level M) and its one or more child nodes (at level M+1) in the tree 1300 generally represent mappings between the parent node and the one or more child nodes. In at least one embodiment, the parent node may include a reference used to access (directly or indirectly) each of its one or more child nodes. For example, the root node MD page top 1302 may include addresses or pointers used to access each of its child nodes 1304, 1306 and 1308. The mid-level node MD page mid1 1304 may include addresses or pointers used to access each of its child leaf nodes 1310, 1312. The mid-level node MD page mid1 1306 may include addresses or pointers used to access each of its child leaf nodes 1314, 1316. The mid-level node MD page mid1 1308 may include addresses or pointers used to access each of its child leaf nodes 1318, 1320.
In at least one embodiment, each of the addresses or pointers included in a MD page that references a location in another MD page or references a location in a UD page may be a physical storage location on the back-end PDs. Thus, the traversal between connected nodes of the structure 1300 may correspond to traversing physical address or storage locations included in pages or nodes that are parent nodes.
In connection with accessing a particular UD page in at least one embodiment, all MD pages in a path from the root or top level of the tree to the UD page may be required to be traversed in a consecutive serialized order in which such pages appear in the path traversal down the path from the top or root level to the UD page accessed using a particular one of the MD page leaf nodes. For example, assume UD page or block X is included in the set of UD pages 1312a. In order to access UD page X of 1312a, the following denotes the consecutive serialized order in which the MD pages forming a sequence are accessed: MD page top 1302, MD page mid1 1304, and MD page leaf2 1312. Generally, in at least one embodiment, each of the MD pages may include pointers or addresses to locations of one or more child pages or nodes. Thus, the foregoing traversal of MD pages denotes the sequence of MD pages that are processed in consecutive serialized order in order to access the particular UD page, such as UD page X. In order to access the UD page X as stored on PDs where UD page X includes first data needed to service a read I/O operation in connection with a cache miss of the first data, each of the MD pages in the foregoing sequence (e.g., MD page top 1302, MD page mid1 1304, and MD page leaf2 1312) needs to be accessed in consecutive serialized order. In at least one embodiment, the sequence of MD pages, and more generally, the path from the MD page top to the UD page X, forms a linked list of nodes of pages. In at least one embodiment, each parent node or MD page of the structure 1300 may generally include multiple pointers or references to locations of its child nodes or pages. For example, MD page top 1302 includes pointers to locations of its child nodes, MD pages 1304, 1306 and 1308. MD page mid2 1306 includes pointers to locations of its child nodes, MD pages 1314 and 1316.
The data pages 1310a, 1312a, 1314a, 1316a, 1318a and 1320a include UD stored on particular logical addresses of a LUN's address space, such as the LUN A's logical address space. In at least one embodiment each MD leaf may hold MD for a specified number of LBAs of a LUN. For example, in one embodiment each MD leaf may hold MD for 512 LBAs. For example, with reference to
In at least one embodiment, when the structure 1300 is traversed in a depth first manner (i.e., from the left-most path to the right most path as arranged in the tree), the MD page leaf nodes that occur in the depth first traversal correspond to consecutive sequential LBA subranges of a LUN. In at least one embodiment, when the overall tree including MD page top node 1302 and all its descendant nodes are traversed in this depth first manner, the MD page leaf nodes that occur in the depth first traversal correspond to consecutive sequential LBA subranges of a LUN.
In at least one embodiment as described herein, each of the MD pages and data blocks in the example 1300 may be of a predetermined size and each of the MD pages may hold a known number of entries containing pointer or address values. In such a case and in combination with the correspondence of sequential consecutive LBA ranges of each MD leaf page, an embodiment may perform a calculation to determine the MD page at a particular level that is accessed in the tree MD mapping structure 1300 to determine the data block for a particular LUN and LBA. Similarly, it is a straightforward mathematical calculation to determine the index, offset of entry in a particular page or node to be accessed in connection with obtaining data blocks stored at the particular LUN and LBAs of the LUN. Each MD page in 1300 may be known to include MD relevant for accessing data on a particular LUN and one or more LBAs of that LUN. For example, consistent with discussion above, element 310a denotes the data blocks for LBAs 0-511 of a LUN. In order to access the data block for an LBA of the LUN in the LBA subrange 0-511, MD pages 1302, 1304 and 1310 may be traversed in sequential order. In particular, the first entry or offset of the MD page top 1302 may contain the address of the MD page mid 1 1304; the first entry or offset of the MD page mid 1 1304 may contain the address of the MD page leaf 1 1310; and the first entry or offset of the MD page leaf 1 1310 may contain the address of the data blocks for 1310a.
In a similar manner, a mapping may be made regarding what MD pages of the structure 300 and entries thereof are used in connection with obtaining data blocks containing data for any particular LUN and LBA. In at least one embodiment, the particular MD pages used to access a data block including data for a particular LUN and LBA may be known based on such mappings and correspondence of LBA subranges to particular MD leaf pages.
For a write I/O operation received at a node of a dual node system or appliance such as in an active-active configuration, servicing the write operation may include updating one or more data blocks or storage locations as well as one or more MD pages such as, for example, of the MD or mapping structure of
With a log-structured system in at least one embodiment, as recorded writes of the log are processed and flushed to the BE PDs, the content written by the recorded writes of the log may be stored at physical storage locations on the BE PDs. Additionally, the MD or mapping information corresponding to the logged writes being flushed may also be accordingly updated to reference the physical storage locations on the BE PDs containing the content. In a dual node appliance or system with an active-active configuration as described herein, both nodes of the system may concurrently receive and service write I/Os, as well as other received requests and commands using shared resources such as, for example, the MD or mapping information described in connection with
In connection with an active-active appliance or system such as described herein, the nodes should be synchronized to guarantee consistent access and updates of the same data and MD objects or MD pages from both nodes. Schema providing MD consistency, integrity and coherency may use global transactional update semantics (e.g., providing for coherent synchronized updates on both nodes) and global locking semantics. A classical problem that may occur in connection with the active-active architecture of the dual node appliance is deadlock or a potential for deadlock in the case where, for example, both nodes of the appliance initiate an update for the same one or more objects or pages, such as the same one or more MD pages, concurrently. A deadlock is a situation in which two processes, threads, programs or other code entities sharing the same resource are effectively preventing each other from accessing the resource, resulting in blocking execution of both processes, threads, programs or other code entities. For example, process 1 needs both resources A and B to continue execution. Additionally, process 2 also needs both resources A and B to continue execution. Process 1 requests and receives resource A. Process 2 requests and receives resource B. Process 1, while holding resource A, now requests resource B but is blocked since resource B is currently held by process 2. In a similar manner, process 2, while holding resource B, now requests resource A but is blocked since resource A is currently held by process 1. In the foregoing, a deadlock may be detected between both process 1 and process 2. More generally, the potential for deadlock may occur in connection with any scenario where two consumers are both attempting to acquire the same one or more shared resources and each of the two consumers have a mutual dependency on each other and hold a shared resource the other needs to proceed.
One existing technique for resolving a detected deadlock or potential deadlock such as with two nodes of the dual node appliance that are in a deadlock scenario includes permanently assigning a fixed, dedicated winner node and permanently assigning a fixed dedicated loser node. In this solution, a first node of the two nodes may be permanently selected and assigned as the fixed predetermined winner and a second of the two nodes may be permanently selected and assigned as the fixed predetermined loser. In response to a detected deadlock or potential deadlock, the loser node always aborts or releases any resources held that are causing the deadlock. In response to a detected deadlock or potential deadlock, the winner node is always allowed to continue processing and subsequently acquires the resources released by the loser node.
However, the foregoing solution of fixed permanent dedicated assignments of the node roles of winner and loser to particular nodes has drawbacks. For example, always having one of the nodes be a winner and always having the other node be the loser provides for node asymmetry that may result in a load imbalance between the nodes. Additionally, there is a fairness issue in that the same winner node is always allowed to proceed for a detected deadlock and given priority over the other loser node. In some instances, this could result in the loser node potentially being indefinitely blocked by the winner node. For example, in some instances, the loser node may be not be able to make any progress with a particular task, operation or transaction. Each time the loser node attempts to acquire a shared resource for the particular task, operation or transaction and a deadlock or potential deadlock is detected, the loser node may be forced to abort the particular task or operation, and release any shared resource currently held or acquired. Subsequently, the loser node may continually retry and repeat processing for the transaction, task or operation aborted. In contrast, the winner node (that conflicted with the loser node causing the detected potential deadlock) is allowed to always proceed and acquire any needed resources released by the aborted loser node. The adverse impact of both of the foregoing factors may increase as the system load increases thereby resulting in system performance degradation.
Described in the following paragraphs are techniques that may be used in connection with resolving a deadlock or potential deadlock in a system. The techniques described in the following paragraphs provide a balanced and fair approach to break and resolve any detected deadlock. In accordance with the techniques herein in at least one embodiment, roles of winner and loser may be assigned to the nodes in a balanced manner that minimize the adverse results noted above that may be introduced by having fixed permanent dedicated assignments of the node roles of winner and loser.
It should be noted that balanced switching of the winner and loser roles between the nodes is not a trivial task. For example, the decision at a point in time of which node is the winner and which is the loser may not be done per object or page since a completing a transaction may require acquiring exclusive access to multiple resources such by acquiring and simultaneously holding multiple locks for the multiple resources. In this case, multiple resources required for a transaction to complete should be resolved at the transaction level uniformly whereby the same node is assigned the role of winner or loser with respect to all resources required for the transaction. Additionally, the same shared resource may be involved in two different transactions.
In the following paragraphs, reference may be made to a particular method or protocol used in connection with performing MD updates to one or more MD pages. The MD pages may be, for example, like the MD pages of the mapping information or structure of
The '252 application uses a technique to synchronize access to shared MD pages among the two nodes of an appliance by combining locking and transactional update logic using a single round or message exchange between the two nodes. However, as discussed in the '252 application and also in the following paragraphs, such a technique may also result in deadlock or potential deadlock. Also discussed in the following paragraphs is a technique that may be used to break or resolve the detected deadlock or potential deadlock between the two nodes with respect to both nodes attempting concurrently to acquire exclusive access to a same MD page.
What will now be described is processing that may be performed in connection with two nodes of the dual node appliance to synchronize access to one or more MD pages involved in a transaction. Thus, in this context and example described in the following paragraphs, all of the one or more MD pages may be required to perform the updates of the transaction initiated by an initiator. The processing described herein, such as in connection with
The flowchart of
The local lock for a MD page may be characterized as local with respect to a single node for the MD page and may be used to provide lock semantics and serialization of access in the scope of only the single node. Thus, in order for a node in a dual node appliance to acquire exclusive access to a MD page, the node needs to acquire a first local lock for the MD page from a first of the two nodes and also acquire a second local lock for the MD page from the remaining node (e.g., a second of the two nodes).
Referring to
At the step 202, the initiator node needs to update a set of one or more MD pages for a transaction. Each of the one or more MD pages may have a first corresponding local lock on the initiator node and a second corresponding local lock on the peer node. In the step 202, the initiator node acquires a first set of the one or more local locks for the set of one or more MD pages of the transaction on the initiator node. From the step 202, control proceeds to the step 204.
At the step 204, the initiator node sends a commit message to its peer node. The commit message is a request from the initiator node to the peer node to acquire a second set of the one or more local locks of the peer node for the set of MD pages of the transaction. The commit message in this protocol illustrated also includes, as a commit message payload, the MD updates for the one or more MD pages. From the step 204, control proceeds to the step 206.
At the step 206, the peer node receives the commit message. In response, processing may be performed to acquire, for the initiator node for the transaction, the second set of one or more local locks of the peer node for the set of one or more MD pages of the transaction. From the step 206, control proceeds to the step 208.
At the step 208, the peer node may persistently store and apply the MD updates to the one or more MD pages of the transaction. From the step 208, control proceeds to the step 210.
At the step 210, the peer node may store and apply the MD updates to its volatile memory copy of the one or more MD pages of the transaction. From the step 210, control proceeds to the step 212.
At the step 212, the second set of one or more local locks of the peer node that are associated with the one or more MD pages of the transaction may be released. From the step 212, control proceeds to the step 214.
At the step 214, a reply message may be sent from the peer node to the initiator node indicating completion of the commit processing by the peer node. From the step 214, control proceeds to the step 216.
At the step 216, the initiator node receives the reply from the peer node. From the step 216, control proceeds to the step 218.
At the step 218, the initiator node may store and apply the MD updates to its local volatile memory copy of the one or more MD pages of the transaction. From the step 218, control proceeds to the step 220.
At the step 220, the first set of one or more local locks of the initiator node associated with the one or more MD pages of the transaction may be released.
In connection with a local lock requested by an initiator node, such as in connection with the steps 202 and 206, if the requested local lock for a MD page is not available and is currently held by a node in connection with another transaction, processing for the request by the initiator may be blocked and wait in a queue associated with the local lock. In at least one embodiment, if there are multiple requests for multiple transactions blocked and waiting for the local lock, the multiple requests may be placed in the queue in a FIFO (first in first out) order in accordance with the time order in which the multiple requests attempted to acquire the local lock. In response to releasing the local lock of the FIFO queue, a next waiting request, if any, from the queue may proceed to attempt to acquire the local lock of the peer node for the transaction associated with the next waiting request. For example, such a queue as just described may be used in connection each local lock of an initiator node when attempting to acquire its own one or more local locks for one or more MD pages of the transaction in the step 202. Additionally, such a queue as just described may be used in connection each local lock of a peer node when attempting to acquire, on behalf of the commit request from the initiator node for a transaction, one or more local locks of the peer node for the one or more MD pages of the initiator's transaction in the step 206.
In connection with the processing of
What will now be described is processing that may be performed in response to detecting a deadlock or a potential deadlock. As described above, in at least one embodiment, a deadlock may occur if it is determined that both nodes are attempting to update the same MD page concurrently. As noted above in at least one embodiment, the deadlock condition may be detected in response to a first node holding a first local lock on a MD page X2 and being blocked or waiting to acquire a second lock on the same MD page X2, and where a second node holds the second lock on the same MD page X2 and the second node is blocked or waiting for the first lock on the same MD page X2.
The following paragraphs describe techniques that may be performed to resolve a deadlock or potential deadlock detected in an embodiment in accordance with the techniques herein. The following techniques may be characterized as defining one of the nodes to be a winner and the other node to be a loser. Once the winner and loser node roles are assigned, the concurrent update and deadlock may be resolved by having the winner or winning node proceed with processing even if the winner node waits on a queue for a local lock for a MD page. The loser or losing node aborts its current transaction that includes the conflicting one or more local locks for one or more MD pages. In particular, the loser node releases all acquired local locks for the conflicting transaction being aborted and then retries the update or transaction (e.g., may include rebuilding delta sets of MD changes and then repeating processing to attempt to acquire all necessary local locks of both nodes for all MD pages of the transaction). The winning node or winner is allowed to proceed and may, for example, wait on one or more queues for one or more locks held by the loser node. In response to the losing node releasing the conflicting one or more local locks, the winning node may proceed to acquire the one or more local locks just released by the losing node. The winning node then continues its processing while the loser node waits and subsequently attempts to retry the updating of the one or more MD pages for the transaction.
In at least one embodiment in accordance with the techniques, assigning or reassigning the roles of winner and loser between the two nodes may be performed periodically in an ongoing continuous manner. For example, switching or alternating the roles of winner and loser between the two nodes may be performed at each occurrence of a periodic time interval, and/or after each specified number of transactions. More generally, switching or alternating the roles of winner and loser between the two nodes may be performed in an ongoing manner in response to any one or more defined trigger events or conditions. The switching of the roles of winner and loser between the two nodes may be performed using the techniques herein to guarantee coherent and consistent views of the roles among the nodes.
In at least one embodiment, each node at any point in time may have a current state that is one of the following three (3) predetermined or predefined states used to characterize the current role assignment status where “A” and “B” refer to identifiers uniquely identifying each of the two nodes in the appliance:
1. A WINNER. In the case of deadlock or potential deadlock detection between the nodes A and B, resolution is made in favor of the node A. The node A is assigned the winner role and the peer node B is assigned the loser role. Specifically, node-A-initiated transaction continues processing despite counter commit lock request sent to the peer. The node-B-initiated transaction is aborted in case of detected deadlock or potential deadlock for one or more of the locks of the node B's initiated transaction.
2. B WINNER. In the case of deadlock or potential deadlock detection between the nodes A and B, resolution is made in favor of the node B. The node B is assigned the winner role and the node A is assigned the winner role. Specifically, the node-B-initiated transaction continues processing despite counter commit lock request sent to the peer. The node-A-initiated transaction is aborted in case of detected deadlock or potential deadlock for one or more of the locks of the node A's initiated transaction.
3. NO WINNER. This state mean that the system is in transition whereby switching or assigning the roles of winner and loser to the two nodes is in progress at the current time and the nodes have not yet completed role synchronization. If some deadlock or potential deadlock is detected and the state of the node is “NO WINNER”, then the conflicting local lock request causing the deadlock or potential deadlock may temporarily block or wait in a wait queue and does not progress until the state is changed to a new winner denoting either A WINNER or B WINNER. Subsequently, blocked conflicting local lock requests on the wait queue may be processed and resolved according to the new winner assignment. As an alternative to having the conflicting lock request of a detected deadlock/potential deadlock wait in the wait queue until the node's state transition from NO WINNER to either A WINNER or B WINNER, an embodiment may alternatively abort the transaction associated with the conflicting request for the local lock. Aborting the transaction may be characterized as a safe alternative guaranteed to prevent and resolve deadlocks. However, aborting all such transactions when a deadlock or potential deadlock is detected may cause an excessive number of transaction aborts depending on the particular implementation.
In at least one embodiment, each of the two nodes A and B may store in its local volatile memory a current state or value denoting one of the above-noted three (3) states used to characterize the current role assignment status as viewed locally by the particular node. In connection with the role switching processing or algorithm described herein, processing is performed to switch and update the current state denoting the current role assignment of winner and loser among the two nodes as stored locally on each of the two nodes. A node's current value for the current state may be set to one of the three above-noted states denoting the current assignments of the winner and loser roles (e.g., when the state of a node is either A WINNER or B WINNER), or denoting that the current role assignment switching is in progress (e.g., when the state of a node is NO WINNER). The current value for the current state of a node may be continuously changed or switched using the role switching processing or algorithm described herein. In at least one embodiment, a node's current value for the current state may be used by the node when performing resolution of detected deadlocks. In the event that the node's current value for the current state is NO WINNER and the node has detected a deadlock/potential deadlock requiring resolution, the conflicting request determined to cause the potential deadlock/deadlock may be placed on a wait queue where resolution of the potential deadlock/deadlock occurs once the node's current state has transitioned to either A WINNER or B WINNER.
An initial role assignment of the winner role and the loser role are made between the two nodes A and B. In at least one embodiment, the node that was activated in the appliance first in time may be assigned the winner role with the remaining node subsequently assigned the role of loser (as soon as the remaining node is booted and active). Once both nodes A and B are active and the initial role assignment performed, processing may be performed to enable the role switching processing or algorithm described below. The role switching processing or algorithm may be performed in a continuous manner in response to each occurrence of any one or more defined trigger events or conditions as discussed elsewhere herein. For example consistent with other discussion herein, the role switching processing or algorithm may be performed in accordance with one or more defined policies specifying the one or more defined trigger events or conditions. For example, the role switching processing or algorithm may be performed periodically based on a defined time interval (e.g. every 0.5 seconds), and/or after processing is completed for a specified number of transactions (e.g., every 512 transactions received and processed by both nodes of the appliance collectively). In at least one embodiment, once enabled, the role switching processing or algorithm may continue to operate and switch the roles of winner and loser between the two nodes in accordance with the one or more defined policies specifying the one or more defined trigger events or conditions.
In at least one embodiment, the existing messaging exchange between an initiator node and its peer node may be used for role switching and synchronization of the role between the nodes. Consistent with other discussion herein, the initiator node may be the node that needs to update a set of one or more MD pages for a transaction and where the initiator node is therefore attempting to acquire one or more local locks of the initiator node for the one or more MD pages and to acquire one or more local locks of the peer node for the one or more MD pages. In at least one embodiment, an additional field, referred to herein as “new winner” may be added to the payload of the commit message or request sent in the step 204 of
Referring to
In a step S1, the loser node is an initiator node and needs to update a set of one or more MD pages such as described elsewhere herein, for example, in connection with
It is noted that the step S1 may generally denote performing the processing of the step 202 of
At the step S2, the loser node (also the initiator node with respect to the current transaction for which the set of one or more MD pages is to be updated) updates its current state to NO WINNER. As discussed elsewhere herein, in at least one embodiment, once the loser node sets its current state to NO WINNER, all local lock requests (e.g., such as those received by the loser node from the other peer node as well as any requests initiated by the loser node) determined to have deadlock potential or causing deadlock may not be resolved and may wait in a queue until the loser node's state is changed from NO WINNER to either A WINNER or B WINNER. As also discussed herein as an alternative, an embodiment may have any such lock requests determined to have deadlock potential or causing deadlock to be aborted, whereby the transaction associated with each such lock request may be aborted and then subsequently retrying the update or transaction (e.g., may include rebuilding delta sets of MD changes and then repeating processing to attempt to acquire all necessary local locks of both nodes for all MD pages of the transaction). Put another way, in this latter alternative embodiment, the loser node may continue to operate as the loser role node that aborts or releases any resources held that are causing the deadlock or potential deadlock. From the step S2, control proceeds to the step S3.
In the step S3, the commit request or message with the new winner set to either A WINNER or B WINNER (e.g., in the step S1) is sent from the initiator loser node to the peer node (currently the winner node). The step S3 may include processing as described in the step 204 of
In the step S4, in response to receiving the commit request or message, the peer node sets its current state to the new winner field of the received commit request or message. From this point forward, the peer node uses its updated current state of loser role as determined from the new winner field to resolve deadlocks or potential deadlocks it detects. In the step S4, from the perspective of the peer node, the peer node transitions from the role of winner to the role of loser as a result of the peer node setting its current state to the new winner field of the received commit request or message. In the step S4, from the peer node's perspective, the initiator node transitions from the role of loser to the role of winner as a result of the peer node setting its current state to the new winner field of the received commit request or message. From the step S4, control proceeds to the step S5.
At the step S5, the peer node completes processing for the commit request or message such as described in connection with the
At the step S6, the initiator node (still having the loser node role) updates its current state according to the new winner field (e.g., either A WINNER or B WINNER) of the commit request or message it previously sent in the step S3. At this point from the initiator node's perspective, subsequent to updating the current state of the initiator node according to the new winner field, the initiator node's role is transitioned to the new winner role, where the initiator node may now resolve deadlocks or potential deadlocks according to the new winner role assigned to the initiator node and the new loser role assigned to the peer node. From the step S6, control proceeds to the step S7.
In the step S7, processing is performed in connection with all conflicting local lock requests of detected potential deadlock or deadlock that were placed on the wait queue in the step S2, where such conflicting local lock requests relate to detected deadlock conditions that occurred when the initiator node's state was NO WINNER. In the step S7, all such lock requests may now be processed and resolved according to the new updated node role of winner assigned to the initiator node and the new updated node role of loser assigned to the peer node. It should be noted that the probability of having any queued conflicting local lock requests that are awaiting deadlock resolution in the step S7 may be very small. Such conflicting local lock requests on the wait queue are associated with potential deadlock or deadlock conditions detected during a typically very small window of time when the winner and loser role assignment switch is in progress. In this manner, performing the techniques herein is efficient and has negligible impact on performance.
The foregoing role switching processing or algorithm guarantees coherent loser and winner role updates across the nodes of each appliance and cluster while avoiding race conditions. The foregoing role switching processing or algorithm therefore provides for balancing the winner assignments between the nodes of a dual node appliance. The foregoing role switching and assignment processing such as described in connection with
For illustration purposes, the foregoing role switching processing or algorithm is described above with reference to the particular protocol described in connection with
1) Acquire the local locks of the initiator node for the MD pages of a transaction.
2) The initiator node sends a first request to the peer node to acquire the local locks of the peer node for the MD pages of the transaction.
3) The peer node receives the first message. In response, processing is performed on the peer node to acquire the requested local locks of the peer node for the MD pages of the transaction and then return a reply or response to the initiator acknowledging successful completion of the first request.
4) The initiator node sends a second request to the peer node with the updates to be made to the MD pages for the transaction.
5) The peer node receives the second request. In response, the peer node persistently updates the MD pages in accordance with the received updates of the second request; and the peer node updates its volatile memory copy of the MD pages in accordance with the received updates of the second request.
6) The peer node returns a response or reply to the initiator acknowledging successful completion of the second request.
7) In response to receiving the response or reply for the second request, the initiator updates its volatile memory copy of the MD pages in accordance with the received updates for the MD pages and releases its local locks for the MD pages (e.g., release the local locks of the initiator acquired in 1).
8) The initiator node sends a third request to the peer node requesting that the peer node release the local locks of the peer node for the MD pages previously acquired in 3).
9) The peer node receives the request, releases the locks on the MD pages, and returns a response or reply to the initiator acknowledging successful completion of the third request.
It is straight forward to adapt the above-noted role switching processing or algorithm as described in connection with
In connection with the step 3) of the second protocol, the peer node may detect a potential deadlock if A) the initiator node is requesting a first local lock of the peer node for a first MD page that is already taken or held such as by the peer node itself for another transaction; and B) the peer node (when operating as an initiator for another transaction) has an outstanding request for a second local lock of the initiator node for the same first MD page. In other words, the peer node is waiting to acquire the second local lock of the initiator node for the first MD page and the initiator node currently holds second local lock in connection with another transaction; and the initiator node is waiting the acquire the first local lock of the peer node for the first MD page and the peer node currently holds the first local lock in connection with another transaction. Thus, the peer node may use its current value of its current state denoting the current assignment of the winner and loser roles to resolve the deadlock or potential deadlock.
For example, as a first scenario in the step 3) of the second protocol, assume the peer node's state is NO WINNER. In this first scenario, the initiator request for the first local lock of the peer node may be held and placed on a waiting queue where the request waits to be processed once the peer node's state is either A WINNER or B WINNER.
As another example, consider a second scenario in the step 3) of the second protocol. Assume the peer node's state indicates that the initiator node is the winner and the peer node is the loser. With the initiator as the winner, the initiator node's transaction proceeds and the loser's transaction is aborted while also releasing any acquired local locks for MD pages. Thus, as the winner, the initiator node's request for the conflicting first local lock of the peer node may proceed and wait on the queue associated with conflicting first local lock to await the release of the conflicting first local lock by the loser, the peer node. In connection with the outstanding request for the second local lock of the initiator node, the peer node as the loser may abort its conflicting transaction and release the first local lock of the peer node in connection with generally releasing all locks held or acquired for its conflicting transaction causing the detected potential deadlock due to the conflicting first local lock of the peer node. In response to releasing the first local lock of the peer node, the initiator node may be removed from the wait queue of the first local lock of the peer node, and then acquire the first local lock of the peer node. The loser peer node may subsequently retry the updates and the aborted transaction. More generally the techniques described herein may be applied for use in connection with any detected deadlock or potential deadlock in connection with any existing protocol having at least one message exchange.
The techniques herein may be performed by any suitable hardware and/or software. For example, techniques herein may be performed by executing code which is stored on any one or more different forms of computer-readable media, where the code may be executed by one or more processors, for example, such as processors of a computer or other system, an ASIC (application specific integrated circuit), and the like. Computer-readable media may include different forms of volatile (e.g., RAM) and non-volatile (e.g., ROM, flash memory, magnetic or optical disks, or tape) storage which may be removable or non-removable.
While the invention has been disclosed in connection with embodiments shown and described in detail, their modifications and improvements thereon will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present invention should be limited only by the following claims.
