Method for lock management in cluster, lock server and client

Abstract

The present invention provides a solution for lock management in a cluster. The cluster includes a client and a lock server. The lock server includes an interface card and a memory. The memory stores a queue of read lock requests, and records the records of clients waiting for a read lock or obtaining a read lock. ID, the memory also stores the write lock request queue to record the ID of the client who is waiting for the write lock or obtains the write lock. The memory also contains the read lock allocation count and the write lock allocation ID. The former is used to record the allocated read lock, and the latter is used In order to indicate whether the write lock has been allocated, the interface card of the client and the lock server communicates through the RDMA protocol to perform the lock operation.

Description

technical field [0001] The invention relates to the field of information technology, in particular to a method for lock management in a cluster, a server and a client. Background technique [0002] There are multiple clients in the cluster. In order to obtain the processing permission of shared resources in the cluster, such as write permission or read permission, a client needs to apply for processing permission from the lock server in the cluster, which is usually called applying for a lock. Usually write permission is also called write lock, or exclusive lock, and read permission is called read lock or shared lock. [0003] As shown in FIG. 1 , the prior art client applies for a write lock, and the cluster includes a lock server, client A, and client B. Client A writes the identity of client A to the memory address of the lock server using the Remote Direct Memory Access (RDMA) protocol, such as using the atomic operation Compare-and-Swap in the RDMA protocol to apply fo...

AI Technical Summary

Problems solved by technology

[0004] In the implementation scheme of the existing technology, client A fails, because the lock server does not know that client B is in the write lock waiting state, so client B cannot apply for the write lock, and is always in the write lock waiting state

As can be seen from the above description, the lock server in the prior art can only obtain the lock status of the current client

Images