Lock Management Method in Cluster, Lock Server, and Client

• US 20180234503A1
• Filed: 04/17/2018
• Published: 08/16/2018
• 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
• Granted Patent: US 10,257,282 B2
• Time in Patent Office: 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 from the first client in the clients, the memory storing the write lock request queue recording identifiers of the clients in the cluster comprising 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 same 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 recording identifiers of the clients in the cluster comprising 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 same 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 in the clients;

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.

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

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

an interface card coupled to the memory and configured to;

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

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

send a first message carrying the write lock allocation identifier to the first client.

15. The lock server of claim 14, wherein the first message indicates that the first client is in the read lock waiting state when the write lock allocation identifier indicates that the write lock has been allocated.

16. The lock server of claim 14, wherein the memory is further configured to store a read lock allocation count indicating a quantity of read locks allocated for the shared resource, the interface card being further configured to increase the read lock allocation count according to a quantity of read locks allocated to the first client when the write lock allocation identifier indicates that the write lock is not allocated, and the first message indicating that the first client obtains the read lock.

17. The lock server of claim 15, wherein the clients further comprise a second client, the memory being further configured to store a write lock request queue recording identifiers of the clients in the cluster comprising an identifier of a client in a write lock waiting state for the shared resource and an identifier of a client obtaining the write lock for the shared resource, and an identifier of the second client being stored in a memory address of a queue head of the write lock request queue when the write lock allocation identifier indicates that the write lock has been allocated.

18. The lock server of claim 14, wherein the clients further comprise a third client, an identifier of the third client being stored in a memory address of a queue head of the read lock request queue, and the first memory address carried in the first read lock request in the read lock request queue comprising a memory address in a sequence from the queue head to a queue tail of the read lock request queue into which the identifier of the first client can be written.

19. The lock server of claim 16, wherein when the first client obtains the read lock, the interface card is further configured to:

receive a read lock release request carrying the first memory address in the read lock request queue in which the identifier of the first client is stored from the first client;

decrease the read lock allocation count in the memory according to the quantity of read locks allocated to the first client; and

delete the identifier of the first client from the first memory address in the read lock request queue.

20. The lock server of claim 16, wherein when the first client becomes faulty after obtaining the read lock, the interface card is further configured to:

decrease the read lock allocation count in the memory according to the quantity of read locks allocated to the first client; and

delete the identifier of the first client from the first memory address in the read lock request queue.