Configuration-less network locking infrastructure for shared file systems

• US 9,026,510 B2
• Filed: 03/01/2011
• Issued: 05/05/2015
• Est. Priority Date: 03/01/2011
• Status: Active Grant

• Current Assignee: Vmware LLC (Broadcom, Inc.)
• Original Assignee: VMware, Inc. (Broadcom, Inc.)
• Inventors: Li, Jinyuan, Vilayannur, Murali, Rawat, Mayank
• Primary Examiner(s): Reyes, Mariela
• Assistant Examiner(s): Black, Linh
• Application Number:
  US13/037,808
• Publication Number:
  US 20120226673A1
• Time in Patent Office: 1,526 Days
• Field of Search: 707/801, 707/704, 707821-831, 711/114, 711/117, 711/152, 711/209
• US Class Current: 707/704
• CPC Class Codes: G06F 11/0712 in a virtual computing platform, e.g. logically partitioned systems
• CPC Class Codes: G06F 11/0757 by exceeding a time limit, i.e. time-out, e.g. watchdogs
• 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: G06F 16/951 Indexing; Web crawling techniques

Abstract

A network-based method for managing locks in a shared file system (SFS) for a group of hosts that does not require any configuration to identify a server for managing locks for the SFS. Each host in the group carries out the steps of checking a predetermined storage location to determine whether there is a host ID written in the predetermined location. If there is no host ID written in the predetermined location, the first host to notice this condition writes its host ID in the predetermined location to identify itself as the server for managing locks. If there is a host ID written in the predetermined location, the host ID of the server for managing locks is maintained in local memory. When the host needs to perform IO operations on a file of the SFS, it communicates with the server for managing locks over the network using the host ID of the server for managing locks to obtain a lock to the file.

Claims

1. A method of managing locks in a shared file system (SFS) for a group of hosts, including first and second hosts, that are coupled to one or more storage arrays through a first network and to each other through a second network, comprising:

when the first host determines that there is no host ID written in a predetermined storage location in the storage arrays, obtaining, by said first host, exclusive access to the predetermined storage location, and writing, by said first host, a host ID of the first host in the predetermined storage location to identify the first host as a server for managing locks;

at each of the other hosts including the second host, reading the predetermined storage location to obtain the host ID of the first host and communicating with the first host over the second network to obtain one or more locks to files of the SFS;

determining, by the second host, that the first server is inactive; and

responsive to the determining by the second host,

overriding, by the second host, the exclusive access to the predetermined storage area obtained by the first host and

writing, by the second host, a host ID of the second host in the predetermined storage location to identify the second host as the server for managing locks.

2. The method of claim 1, further comprising:

at said server for managing locks, receiving a lock request from a host over the second network and granting the lock request if the lock is not currently held by another host.

3. The method of claim 2, wherein granting the lock request includes writing a host ID of the requesting host in a data structure for the lock.

4. The method of claim 1, further comprising:

at said server for managing locks, checking a cache of locks that have been granted, and granting or rejecting the lock request based on contents of the cache.

5. The method of claim 1, wherein the second host determines that the first server is inactive by

examining a liveness information of the first server and

determining that the liveness information of the first server has not been updated within a predetermined period of time.

6. The method of claim 1, further comprising:

when one of the other hosts determines that its communication with said server for managing locks over the second network has failed, posting a message in a data structure owned by said server for managing locks to employ an alternative locking technique that does not rely on communications with said server for managing locks over the second network.

7. The method of claim 6, wherein said server for managing locks, in response to seeing the message in the data structure that it owns, posts a confirmation message to confirm use of the alternative locking technique.

8. The method of claim 7, further comprising:

after one of the other hosts has determined that its communication with said server for managing locks over the second network has failed, periodically communicating with said server for managing locks over the second network, and upon successful reconnection with said server for managing locks over the second network, reverting back to the locking technique that relies on communications with said server for managing locks over the second network.

9. In a computer system having a group of hosts that are coupled to one or more storage arrays through a first network and to each other through a second network, wherein files stored in the storage arrays are managed using a shared file system (SFS) for the hosts, a method carried out by a host to determine an identity of a server for managing locks for the SFS, comprising:

checking a predetermined storage location in the storage arrays to determine whether or not there is a host ID written in the predetermined storage location;

if there is no host ID written in the predetermined storage location, obtaining exclusive access to the predetermined storage location, and writing a host ID of said host in the predetermined storage location to identify said host as said server for managing locks; and

if there is a host ID written in the predetermined storage location, then;

determining whether said server for managing locks is inactive;

if said server for managing locks is inactive, overriding an exclusive access to the predetermined storage area previously obtained by said server for managing locks and writing the host ID of said host in the predetermined storage area to identify said host as said server for managing locks; and

if said server for managing locks is not inactive, storing the host ID of said server for managing locks in a local memory of said host.

10. The method of claim 9, wherein obtaining exclusive access to the predetermined storage area comprises

obtaining a lock to the SFS.

11. The method of claim 10, wherein the lock is obtained using a SCSI reservation protocol.

12. The method of claim 9, wherein determining that said server for managing locks is inactive comprises:

examining a liveness information of said server for managing locks; and

determining that the liveness information of said server for managing locks has not been updated within a predetermined period of time.

13. The method of claim 9, further comprising:

invalidating the host ID stored in the local memory of said host; and

reading a new host ID of said server for managing locks from the predetermined storage location and storing the new host ID of said server for managing locks in the local memory of said host.

14. The method of claim 9, further comprising:

receiving a request to perform an IO operation to a file of the SFS; and

submitting a request for a lock to said file to said server for managing locks over the second network.

15. A non-transient computer readable medium comprising instructions that are to be executed in a host that is part of a computer system having a group of hosts that are coupled to one or more storage arrays through a first network and to each other through a second network, wherein files stored in the storage arrays are managed using a shared file system (SFS) for the hosts, and wherein the instructions, when executed in said host, cause said host to carry out the steps of:

checking a predetermined storage location in the storage arrays to determine whether or not there is a host ID written in the predetermined storage location;

if there is no host ID written in the predetermined storage location, obtaining exclusive access to the predetermined storage location and writing a host ID of said host in the predetermined storage location to identify said host as a server for managing locks; and

if there is a host ID written in the predetermined storage location, then;

determining whether said server for managing locks is inactive;

if said server for managing locks is inactive, overriding an exclusive access to the predetermined storage area previously obtained by said server for managing locks and writing the host ID of said host in the predetermined storage area to identify said host as said server for managing locks; and

if said server for managing locks is not inactive, storing the host ID of said server for managing locks in a local memory of said host.

16. The non-transient computer readable medium of claim 15, wherein obtaining exclusive access to the predetermined storage area comprises

obtaining a lock to the predetermined storage location.

17. The non-transient computer readable medium of claim 16, wherein the lock is obtained using a SCSI reservation protocol.

18. The non-transient computer readable medium of claim 15, wherein determining that said server for managing locks is inactive comprises

examining a liveness information of said server for managing locks;

and

determining that the liveness information of said server for managing locks has not been updated within a predetermined period of time.

19. The non-transient computer readable medium of claim 15, further comprising instructions, which when executed in said host, cause said host to carry out the steps of:

invalidating the host ID stored in the local memory of said host; and

reading a new host ID of said server for managing locks from the predetermined storage location and storing the new host ID of said server for managing locks in the local memory of said host.

20. The non-transient computer readable medium of claim 15, further comprising instructions, which when executed in said host, cause said host to carry out the steps of:

receiving a request to perform an IO operation to a file of the SFS; and

submitting a request for a lock to said file to said server for managing locks over the second network.