Hybrid Locking Using Network and On-Disk Based Schemes

• US 20100017409A1
• Filed: 09/23/2009
• Published: 01/21/2010
• Est. Priority Date: 02/06/2004
• Status: Active Grant

• Current Assignee: Vmware LLC (Broadcom, Inc.)
• Original Assignee: VMware, Inc. (Broadcom, Inc.)
• Inventors: LI, Jinyuan, VILAYANNUR, Murali, RAWAT, Mayank, SCALES, Daniel J.
• Granted Patent: US 8,543,781 B2
• Time in Patent Office: Days
• US Class Current: N/A
• CPC Class Codes: G06F 16/1774 Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
• CPC Class Codes: H04L 41/00 Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks

Abstract

A method of acquiring a lock by a node, on a shared resource in a system of a plurality of interconnected nodes, is disclosed. Each node that competes for a lock on the shared resource maintains a list of locks currently owned by the node. A lock metadata is maintained on a shared storage that is accessible to all nodes that may compete for locks on shared resources. A heartbeat region is maintained on a shared resource corresponding to each node so nodes can register their liveness. A lock state is maintained in the lock metadata in the shared storage. A lock state may indicate lock held exclusively, lock free or lock in managed mode. If the lock is held in the managed mode, the ownership of the lock can be transferred to another node without a use of a mutual exclusion primitive such as the SCSI reservation.

Claims

1. A method of acquiring a lock by a node, on a shared resource in a system of a plurality of interconnected nodes, the method comprising:

(a) probing a local lock metadata of the node to determine if a lock metadata of the lock exists in the local lock metadata, wherein the lock metadata includes an identity of the lock and a lock status;

(b) if the lock metadata does not exist in the local lock metadata, performing steps (i) to (iv),

(i) reading shared lock metadata of the lock from a shared storage, the reading includes identifying a current owner of the lock and a current status of the lock;

(ii) probing heartbeat region of the current owner of the lock to ascertain if the current owner is alive, wherein if the current owner is not alive, waiting for a lock lease time to run out and then acquiring the lock and updating the shared lock metadata to indicate that the lock is now owned by the node;

(iii) if the current status of the lock indicates that the current owner is holding the lock in an exclusive mode, returning a message to the node to notify that the lock is not free;

(iv) if the current status of the lock indicates that the current owner is holding the lock in a managed mode, sending a request to the current owner to release the lock, wherein if the current owner has already not released the lock to another requesting node, the lock is granted to the node without performing a mutual exclusive primitive operation on the shared resource, and the shared lock metadata is updated to indicate new lock ownership and lock status; and

(c) if the lock metadata exists in the local lock metadata, of the node, probing the lock status of the lock in the local lock metadata, if the lock status of the lock in the local lock metadata indicates that the lock being owned in a managed mode, changing the lock status of the lock in local lock metadata to indicate an exclusive use of the lock by the node and updating the shared lock metadata to indicate that the lock being owned by the node in an exclusive mode,

wherein the managed mode means that the lock is being owned by the node but the lock is not being used by the node.

2. The method as recited in claim 1, wherein waiting for the lock lease time to run out includes probing, at a selected interval the heartbeat region of the current owner of the lock to ascertain if the current owner is alive, wherein the selected interval is a time period which is less than the lock lease time.

3. The method as recited in claim 1, wherein if the local lock metadata of the node does not indicate that the lock is being owned by the node, updating the local lock metadata to indicate that the lock is being requested.

4. The method as recited in claim 1, wherein acquiring the lock includes updating the local lock metadata to include information that the node owns the lock, and updating the lock metadata in the shared storage to add a pointer to point to the heartbeat region.

5. The method as recited in claim 4, wherein updating the lock metadata including updating lock timestamp.

6. The method as recited in claim 4, wherein updating the lock metadata includes updating a status of the lock.

7. The method as recited in claim 1, wherein a process of identifying if the lock lease has expired includes:

maintaining in storage at least one heartbeat data structure, the heartbeat data structure including;

owner data identifying a current owner of the heartbeat;

state data identifying a current state of the heartbeat;

pulse data identifying a time of last renewal of the heartbeat; and

allowing the heartbeat to be modified if the pulse data is not changed within a selected period of time.

8. The method as recited in claim 7, the heartbeat data structure further including generation data identifying a version of the heartbeat.

9. The method as recited in claim 8, further including:

maintaining a lock data structure associated with one of a plurality of shared resources, the lock data structure including data identifying a heartbeat.

10. The method as recited in claim 9, wherein the data identifying the heartbeat includes one of owner data identifying a current owner of the heartbeat and address data identifying a location of the heartbeat.

11. A method of receiving, at a first node from a second node, a request to release a lock, the method comprising:

inspecting a local lock metadata of the first node;

sending a message to the second node indicating that the lock is in use if the local lock metadata includes information indicating that the lock is being owned in an exclusive mode;

removing information of the lock from the local lock metadata and updating information in a heartbeat region corresponding to the lock to grant the lock to the second node if the local lock metadata includes information indicating that the lock being held by the first node but not in use; and

returning back a message to the second node indicating that the lock is free,

wherein the request to release is received via an IP network.

12. The method as recited in claim 11, wherein, if the local lock metadata does not include an information regarding the lock, returning back a message to the second node indicating that the first node is not an owner of the lock;

13. The method as recited in claim 12, wherein, on receipt of the message, the second node re-reads the lock metadata in the heartbeat region again to determine any change in a status of the lock.

14. The method as recited in claim 13, wherein if the status of the lock has not changed between a first read and the re-read, attempting to break the lock.

15. The method as recited in claim 13, wherein if the status of the lock has changed between a first read and the re-read, determining if the lock is free.

16. The method as recited in claim 11, wherein the heartbeat region includes at least one heartbeat data structure, the heartbeat data structure including:

owner data identifying a current owner of the heartbeat;

state data identifying a current state of the heartbeat;

pulse data identifying a time of last renewal of the heartbeat; and

17. The method as recited in claim 16, further including

allowing the heartbeat to be modified if the pulse data is not changed within a selected period of time.

18. A method of managing a lock on a shared resource on a network, the method comprising:

maintaining a heartbeat region for the node, wherein the shared resource being accessible to the node and the heartbeat region being maintain on a shared storage on the network, the heartbeat region includes space to store heartbeats of the node and space to store a lock metadata of the lock;

maintaining a local lock metadata in the node to store status of the lock when the lock is owned by the node; and

wherein, when the node attempts to acquire the lock, checking in the local lock metadata to determine if the lock is already owned by the node, if the lock is not owned by the node, probing the lock metadata in the shared storage to retrieve the status of the lock and current owner of the lock, if the status indicates that the lock being held by another node in a managed mode, then requesting the another node to grant the lock to the node, wherein if the lock is granted to the node without a use of a mutual exclusive primitive,

wherein the managed mode means that the lock is being owned by the node but the lock is not being used by the node.

19. The method as recited in claim 18, wherein if the lock is already owned by the node, updating the status in the lock metadata and the local lock metadata in the node to indicate that the lock is being held exclusively by the node.

20. The method as recited in claim 19, wherein when the node no longer needs the lock, updating the status of the lock in the lock metadata and the local lock metadata to indicate that the lock is now being owned by the node in the managed mode.