Lock management method in cluster, lock server, and client

• US 10,257,282 B2
• Filed: 04/17/2018
• Issued: 04/09/2019
• Est. Priority Date: 12/14/2015
• Status: Active Grant

• Current Assignee: Huawei Technologies Co., Ltd. (Huawei Investment & Holding Co., Ltd.)
• Original Assignee: Huawei Technologies Co., Ltd. (Huawei Investment & Holding Co., Ltd.)
• Inventors: Lan, Wenhai, Zhang, Wei, Wang, Xueyou, Zhang, Yue
• Primary Examiner(s): Won, Michael
• Application Number:
  US15/955,276
• Publication Number:
  US 20180234503A1
• Time in Patent Office: 357 Days
• CPC Class Codes: G06F 15/17331 Distributed shared memory [DSM], e.g. remote direct memory access [RDMA]
• CPC Class Codes: G06F 15/177 Initialisation or configuration control processor initialisation G06F9/4405
• CPC Class Codes: G06F 3/0622 in relation to access
• CPC Class Codes: G06F 3/0637 Permissions
• CPC Class Codes: G06F 3/067 Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms
• CPC Class Codes: H04L 67/14 Session management for real-time applications in data packet communications networks H04L65/1066

Abstract

A lock management solution in a cluster, where the cluster includes a client and a lock server, the lock server includes an interface card and a memory, the memory stores a read lock request queue recording an identifier of a client waiting for a read lock or obtaining the read lock, the memory further stores a write lock request queue recording an identifier of a client waiting for a write lock or obtains the write lock, and the memory further includes a read lock allocation count and a write lock allocation identifier, where the read lock allocation count records an allocated read lock, and the write lock allocation identifier indicates whether the write lock has been allocated.

Claims

1. A lock management method in a cluster, the cluster comprising a plurality of clients and a lock server, the lock server comprising an interface card and a memory, and the method comprising:

receiving, by the interface card, a first write lock request carrying an identifier of a first client in the clients and a memory address of a queue head of a write lock request queue in the memory from the first client, the write lock request queue recording an identifier of a client in a write lock waiting state for a shared resource and an identifier of a client obtaining a write lock for the shared resource, a write lock allocation identifier indicating whether the write lock for the shared resource is allocated, and a read lock allocation count indicating a quantity of read locks allocated for the shared resource;

writing, by the interface card, the identifier of the first client into the memory address of the queue head of the write lock request queue;

querying, by the interface card, the read lock allocation count to determine whether a read lock has been allocated;

setting, by the interface card, the write lock allocation identifier to a write lock allocated state when the read lock is not allocated;

sending, by the interface card, a first message to the first client indicating that the first client obtains the write lock; and

sending, by the interface card, a second message indicating that the first client is in the write lock waiting state to the first client.

2. The method of claim 1, further comprising:

receiving, by the interface card, a second write lock request carrying an identifier of a second client in the clients and a first memory address in the write lock request queue from the second client in the clients, the first memory address comprising a memory address in a sequence from the queue head to a queue tail into which the identifier of the second client can be written except the memory address of the queue head of the write lock request queue;

writing, by the interface card, the identifier of the second client into the first memory address in the write lock request queue; and

sending, by the interface card, a message to the second client indicating that the second client is in the write lock waiting state.

3. The method of claim 1, wherein the memory of the lock server further comprises a read lock request queue recording an identifier of a third client in the cluster and obtaining the read lock for the shared resource when the read lock allocation count indicates that the read lock has been allocated.

4. The method of claim 1, wherein the first write lock request further carries a lock lease indicating a validity period of the write lock.

5. The method of claim 2, wherein after the first client obtains the write lock, the method further comprises:

receiving, by the interface card, a write lock release request carrying the memory address of the queue head of the write lock request queue from the first client;

setting, by the interface card, the write lock allocation identifier to a write lock unallocated state; and

deleting, by the interface card, the identifier of the first client from the memory address of the queue head of the write lock request queue.

6. The method of claim 5, further comprising:

querying, by the interface card, the write lock request queue to determine the second client in the write lock waiting state; and

sending, by the interface card, a notification to the second client instructing the second client to apply to the interface card for the write lock.

7. The method of claim 1, wherein when the first client becomes faulty after obtaining the write lock, the method further comprises:

setting, by the interface card, the write lock allocation identifier to a write lock unallocated state; and

deleting, by the interface card, the identifier of the first client from the memory address of the queue head of the write lock request queue.

8. The method of claim 7, further comprising sending, by the interface card, a notification indicating that the write lock held by the first client has been released to a client in the cluster except the first client.

9. A lock server, applied to a cluster comprising a plurality of clients, comprising:

a memory configured to store a write lock request queue, the write lock request queue recording an identifier of a client in a write lock waiting state for a shared resource and an identifier of a client obtaining a write lock for the shared resource, a write lock allocation identifier indicating whether the write lock for the shared resource is allocated, and a read lock allocation count indicating a quantity of read locks allocated for the shared resource; and

an interface card coupled to the memory and configured to;

receive a first write lock request carrying an identifier of a first client in the clients and a memory address of a queue head of the write lock request queue from the first client;

write the identifier of the first client into the memory address of the queue head of the write lock request queue;

query the read lock allocation count to determine whether a read lock has been allocated;

set the write lock allocation identifier to a write lock allocated state when the read lock is not allocated;

send a first message to the first client indicating that the first client obtains the write lock; and

send a second message indicating that the first client is in a write lock waiting state to the first client when the read lock has been allocated.

10. The lock server of claim 9, wherein the interface card is further configured to:

receive a second write lock request carrying an identifier of a second client in the clients and a first memory address in the write lock request queue from the second client in the clients, and the first memory address comprising a memory address in a sequence from the queue head to a queue tail into which the identifier of the second client can be written except the memory address of the queue head of the write lock request queue;

write the identifier of the second client into the first memory address in the write lock request queue; and

send a message to the second client indicating that the second client is in the write lock waiting state.

11. The lock server of claim 9, wherein the memory is further configured to store a read lock request queue recording an identifier of a third client in the cluster and that obtains the read lock for the shared resource when the read lock allocation count indicates that the read lock has been allocated.

12. The lock server of claim 9, wherein after the first client obtains the write lock, the interface card is further configured to:

receive a write lock release request carrying the memory address of the queue head of the write lock request queue from the first client;

set the write lock allocation identifier to a write lock unallocated state; and

delete the identifier of the first client from the memory address of the queue head of the write lock request queue.

13. The lock server of claim 9, wherein when the first client becomes faulty after obtaining the write lock, the interface card is further configured to:

set the write lock allocation identifier to a write lock unallocated state; and

delete the identifier of the first client from the memory address of the queue head of the write lock request queue.