WO2022077777A1 - Procédé de réapplication de verrouillage, procédé de gestion de verrou et serveur - Google Patents

Procédé de réapplication de verrouillage, procédé de gestion de verrou et serveur Download PDF

Info

Publication number
WO2022077777A1
WO2022077777A1 PCT/CN2020/141986 CN2020141986W WO2022077777A1 WO 2022077777 A1 WO2022077777 A1 WO 2022077777A1 CN 2020141986 W CN2020141986 W CN 2020141986W WO 2022077777 A1 WO2022077777 A1 WO 2022077777A1
Authority
WO
WIPO (PCT)
Prior art keywords
lock
server
target object
client
request
Prior art date
Application number
PCT/CN2020/141986
Other languages
English (en)
Chinese (zh)
Inventor
张明谦
珮瓦雷西
库玛阿吉特
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN202080018013.5A priority Critical patent/CN114710976B/zh
Publication of WO2022077777A1 publication Critical patent/WO2022077777A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/176—Support for shared access to files; File sharing support
    • G06F16/1767—Concurrency control, e.g. optimistic or pessimistic approaches
    • G06F16/1774—Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • G06F16/183—Provision of network file services by network file servers, e.g. by using NFS, CIFS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/825—Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking

Definitions

  • the present application relates to the field of computer technology, and in particular, to a lock reassertion method, a lock management method, and a server.
  • Network file system (NFS) version 3 (NFS version 3, NFSv3) is a stateless network file sharing protocol, which can provide file read and write services for multiple NFS clients at the same time.
  • NFS Network file system
  • the server fails and restarts it will read the client information from the persistence layer and send a message to the client to inform the client to re-apply for the lock that has been added when the capacity is expanded or contracted.
  • the server will set a silent period. During the silent period, only the client is allowed to reiterate the lock, and new lock requests are not allowed. When the silent period ends, the lock request from any client can be received normally. But in the process of lock reiteration, the client may reiterate the lock that was not added before the failure.
  • the present application provides a lock reiteration method, a lock management method and a server, which are used to reduce abnormal lock reiteration of clients.
  • a first aspect of the present application provides a lock reassertion method, which includes: a server receiving a lock reassertion request from a client; Locked file; the server locks the target object from the lock identifier in the extension information corresponding to the target object, and the lock identifier indicates that the target object was locked before the server failure.
  • the target object may be a file, directory, etc. in the file system, or may be a block or a logical unit number (LUN) in a block storage system, or an object in an object storage system.
  • LUN logical unit number
  • the server when it determines that there is a move-in event, it mutes each object area in the server, and obtains the locked client information in the feature log, so as to release the silent state of the object area that does not need to be muted.
  • the object area in the file system, the object area is the file area or the directory area; in the block storage system, the object area is the metadata area of the block or LUN; in the object storage system, it is the metadata area of the object.
  • the corresponding server receives the lock reiteration request from the client, and obtains the lock reiteration request from the client.
  • Locked target object The objects in the server of the present application all have corresponding extension information, the data in the extension information is non-volatile data, the server can determine whether there is a lock mark in the extension information of the target object, if there is the lock mark, The server can lock the target file, and if there is no lock identification, the server can reject the lock reiteration request.
  • This application only locks the object with the lock identification, and rejects the client's lock reiteration request for the object without the lock identification, so as to reduce the abnormal lock reiteration of the client.
  • the extended information also includes the number of locks, and in the above steps, before the server locks the target object according to the lock reiteration request, the method further includes: when the number of lock reiteration requests corresponding to the target object exceeds the number of locks. , the server marks the end of the target object lock reassurance.
  • the extended information of each object in the server of the present application further includes the number of locks, and the number of locks may indicate the number of locks added before the server restarts.
  • the server also needs to determine the target object corresponding to the lock reiteration request, whether the number of reiterated locks after the server restarts exceeds the number of locks, and if so, the client's lock reiteration request is directly rejected. If the number of locks is exceeded, the corresponding locking operation can be performed according to the client's lock reiteration request. In this way, abnormal lock reiteration by clients can be further reduced.
  • the method further includes: when the successful lock reiteration request corresponds to the client, and the lock of the object area where the target object is located.
  • the server stores the locking relationship between the client and the object area where the target object is located in the feature log.
  • the server can detect whether the target successful client and the locking relationship of the object area are stored in the feature log, if so, do not perform other operations, if not, the server can store the Locking relationship for double protection against locking.
  • the method before the server receives the lock reiteration request from the client in the above steps, the method further includes: the server receives the lock request from the client; the server determines the target object according to the lock request; the server extends the corresponding extension of the target object.
  • the lock identification is stored in the information.
  • the server before the server restarts, the server can determine the target object according to the object identifier in the client's locking request, and if the target object can be locked, the locking identifier is stored in the extension information of the target object, So that after the server restarts, it can be determined through the lock identifier that the target object has been locked before the server restarts, so as to improve the feasibility of the solution.
  • the extended information further includes the number of locks
  • the method further includes: the server correspondingly increases the number of locks.
  • the server when multiple clients request locks on the target object, the server correspondingly increases the number of locks according to the number of requests that can be successfully locked, so that the feasibility of the solution can be improved.
  • the method further includes: the server receives an unlock request from one or more clients; the server determines the target object according to the unlock request; When the number of unlock requests of the target object is the same as the number of lock requests, the server clears the lock flag.
  • the server after the server stores the lock identifier in the extension information corresponding to the target object, if the locked client does not need to be locked, it can send an unlock request to the server.
  • the server can detect the number of unlock requests and the number of lock requests of the target object in the cache. If the number of unlock requests is less than the number of lock requests, the lock identifier in the extended information is retained. If the number of unlock requests is equal to the number of lock requests, Then the server deletes the lock identification in the extended information, which can improve the reliability of lock reiteration.
  • the method further includes: the server receives an unlock request from the client; the server determines the target object according to the unlock request; the server correspondingly reduces the number of locks; when the number of locks is 0 , the server clears the lock flag.
  • the server when the extended information includes the number of locks, the server also needs to correspondingly reduce the number of locks according to the unlock request. If the number of locks is 0, it means that there is no lock on the target object, then clear the lock identification to Improve the reliability of lock reiteration.
  • the method further includes: when the locking relationship between the client and the target area where the target object is located is not stored in the feature log, the server stores the client and the target object. The locking relationship of the object area where the target object is located is stored in the feature log.
  • the locking relationship between the successfully locked client and the object area where the target object is located is stored in the feature log, so that the lock can be reiterated later.
  • a second aspect of the present application provides a lock management method.
  • the method includes: the server obtains a lock identifier of a target object; and the server records the lock identifier in extended information of the target object.
  • the locking request that the client applies for locking to the target object carries the locking identification
  • the server obtains the locking identification in the locking request, and stores the locking identification in the extension information of the target object. , so that after the server restarts, it can be determined through the lock identifier that the target object has been locked before the server restarts.
  • the server obtains the lock quantity of the target object; the server records the lock quantity in the extended information of the target object.
  • the server when there is no unlock request, can use the number of lock requests stored by the target object in the cache as the number of locks of the target object, and then record it in the extension information of the target object, so that after the server restarts
  • the number of clients locked on the target object can be determined by the number of locks.
  • the server when releasing the lock of the target object, deletes the lock identification from the extended information of the target object.
  • the client when it completes the operation and does not need to lock, it can send an unlock request to the server, and accordingly, the server can release the lock on the target object and delete the lock identifier in the extended information.
  • the server when the lock on the target object is a write lock or there is only one read lock, the server deletes the lock ID upon receiving the unlock request.
  • the server can delete the extended information after receiving the unlock request. The lock identifier corresponding to the unlock request.
  • the server when restoring the lock of the target object, acquires the lock identifier from the extended information stored in the hard disk.
  • the lock identification can be obtained from the extended information stored in the hard disk.
  • the lock reiteration requests that the target object be locked accordingly.
  • the method is applied to a distributed file storage system.
  • a third aspect of the present application provides a server, the server comprising: a receiving unit for receiving a lock reiteration request from a client; a determining unit for determining a target object corresponding to the client according to the lock reiteration request, where the target object is the client The object to be locked after the server restarts; the re-locking unit is used to lock the target object according to the lock reiteration request when the extension information corresponding to the target object determines that there is a lock mark, and the lock mark indicates the target object Locked before server failure.
  • the server is configured to execute the method of the foregoing first aspect or any implementation manner of the first aspect.
  • a fourth aspect of the present application provides a server, the server comprising: an acquiring unit, configured to acquire a locking identifier of a target object; and a recording unit, configured to record the locking identifier in extended information of the target object.
  • the server is configured to execute the method of the foregoing second aspect or any implementation manner of the second aspect.
  • a fifth aspect of the present application provides a computer device, including: a processor, a memory, and a communication interface, where the processor is configured to execute instructions stored in the memory, so that the computer device executes the first aspect or any one of the first aspects
  • the communication interface is used for receiving or sending an indication.
  • a sixth aspect of the present application provides a computer device, including: a processor, a memory, and a communication interface, where the processor is configured to execute instructions stored in the memory, so that the computer device executes the second aspect or any one of the second aspects.
  • the method provided by the optional manner, the communication interface is used for receiving or sending an indication.
  • the specific details of the computer device provided by the sixth aspect reference may be made to the second aspect or any optional manner of the second aspect, which will not be repeated here.
  • a seventh aspect of the present application provides a computer-readable storage medium, where a program is stored in the computer-readable storage medium, and when the computer executes the program, the computer executes the first aspect or any optional manner of the first aspect. method.
  • An eighth aspect of the present application provides a computer-readable storage medium, where a program is stored in the computer-readable storage medium.
  • the computer executes the program, the computer executes the second aspect or any optional manner of the second aspect. method.
  • a ninth aspect of the present application provides a computer program product.
  • the computer program product When the computer program product is executed on a computer, the computer executes the method provided in the foregoing first aspect or any optional manner of the first aspect.
  • a tenth aspect of the present application provides a computer program product.
  • the computer program product When the computer program product is executed on a computer, the computer executes the method provided in the second aspect or any optional manner of the second aspect.
  • FIG. 1 is a block diagram of a server-client system provided by an embodiment of the present application.
  • FIG. 3 is a schematic diagram of an embodiment of a lock reassertion method provided by an embodiment of the present application
  • FIG. 4 is a schematic diagram of another embodiment of a lock reassertion method provided by an embodiment of the present application.
  • FIG. 5 is a schematic diagram of an embodiment of a locking method provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram of another embodiment of the locking method provided by the embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of a server provided by an embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of a server according to an embodiment of the present application.
  • FIG. 9 is another schematic structural diagram of a server provided by an embodiment of the present application.
  • FIG. 10 is another schematic structural diagram of a server provided by an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of a computer device according to an embodiment of the present application.
  • Embodiments of the present application provide a lock reiteration method, a lock management method, and a server, which are used to reduce abnormal lock reiteration by clients.
  • NFS Network file system
  • a network file system allows a server to share files and directories with clients over a network. This allows clients to access remote files and directories in the same way that clients would access local files and directories.
  • the NFS structure can provide many advantages. For example, clients use less storage space because data can be stored on a single server and still be accessible by clients. Thus, data that would otherwise be replicated on each client can be stored in a single location and accessed by multiple clients on the network.
  • a storage device of a data storage system may implement one or more file systems to organize data stored on it.
  • a "file system” may refer to the structure or organization of files or directories, and a "file” may refer to a set of data.
  • Each file can be associated with a filename that allows the file to be uniquely identified and located. Depending on the specific requirements and desired application, a number of different file systems can be used.
  • the PortMapper protocol uses fixed ports to manage ports for various NFS services.
  • NLM network lock manager
  • TCP transmission control protocol
  • UDP user datagram protocol
  • the network status monitoring (NSM) protocol registers the listening port with the PortMapper module when the NFS service starts.
  • the client and the server inform each other of their own status through this protocol, which is used for NLM cleanup and recovery in the scenario of client failure and server failure.
  • FIG. 1 is a block diagram of a server-client system provided by an embodiment of the present application.
  • the system 100 may include a client 101 in communication with an NFS server 103 (ie, a server, exemplified here as an NFS server) over a network 102 .
  • NFS server 103 may access storage device 104 including file system 1041 .
  • storage device 104 may be included in NFS server 103 .
  • a client 101 may issue a request to access or perform an operation on a data object on the NFS server 103 through the network 102 .
  • a request can be encapsulated into a standardized message format defined by the NFS protocol.
  • a "data object" may refer to any of data, files, applications, subdirectories, directories, file systems, combinations thereof, and the like.
  • the NFS server 103 may allow the client 101 to access the data object from the file system 1041 of the storage device 104.
  • NFS server 103 may send data objects from file system 1041 to requesting client 101 .
  • NFS server 103 may allow client 101 to mount a remote directory of file system 1041 on a local directory at client 101 .
  • NFS server 103 may also allow client 101 to perform one or more operations on data objects. For example, client 101 may open data objects, read data objects, write data objects, close data objects, create data objects, lock data objects, delete data objects, delegate data objects, combinations thereof, and the like. NFS server 103 may track some or all of these operations in the form of state. NFS server 103 may track one or more of these states associated with one or more data objects. In some embodiments, client 101 may additionally track these states.
  • NFS server 103 may first determine whether client 101 has appropriate permissions to access or perform certain operations on data objects in file system 1041 of storage device 104 .
  • "permission" defines access control options that can be applied to one or more users.
  • NFS server 103 may examine metadata associated with a data object to ensure that the requesting user (eg, a user ID associated with client 101) is associated with a "read" operation of the data object.
  • NFS server 103 may deny client 101 access to the data object if the requesting user is not associated with the operation.
  • state information for data objects is stored in volatile memory for fast access and update compared to non-volatile memory.
  • volatile memory is erased when the storage system is powered down.
  • conventional NFS protocols often rely on clients to resend all previous state information and/or related data to the server during a smooth recovery period.
  • the state information of data objects on one storage device can be difficult to copy from volatile memory to another storage device.
  • typically only the data objects themselves will be migrated, and it may be desirable to migrate the state of the data objects, however, during migration, data (eg, state information) stored in volatile memory will typically not be migrated to destination storage device.
  • systems and methods are provided for capturing and storing state information corresponding to various states of NFS.
  • the disclosed systems and methods can automatically collect and synchronously write state changes made to NFS to non-volatile storage.
  • state information corresponding to the NFS system can be automatically imported from the non-volatile storage device, so that the NFS service can be restored immediately and transparently.
  • the state information can be transferred from the non-volatile storage to the destination storage device, which can then import the state information into memory to mirror the source storage device.
  • FIG. 2 is a server-client lock recovery scenario provided by an embodiment of the present application.
  • the client 101 includes an NSM1 module and an NLM1 module
  • the server 103 includes an NSM2 module, an NLM2 module, and a lock service module.
  • NLM1 After the NLM1 module is successfully locked, it will notify the NSM1 module to save the locked server information, and the NSM1 module is responsible for persisting this information.
  • NSM1 reads the server information from the persistence layer, and sends a notification message to the NSM2 module of the server 103, instructing the server 103 to clear all locking requests sent from the client 101.
  • the NLM2 module After the NLM2 module receives the lock request, it will submit the request to the lock service module (LockServer) to process the lock business logic (locking, unlocking, lock conflict checking, etc.), and persist the client information.
  • the server 103 restarts due to a failure, it will read the client information from the persistence layer when expanding or shrinking the capacity, and send a notification message to the client 101, informing the client 101 to re-apply for the lock that has been added.
  • the server 103 During the reiteration process, the server 103 will set a silent period. During the silent period, only the client 101 is allowed to reiterate the lock, and a new client's lock request is not allowed. When the silent period ends, the lock request from any client can be received normally.
  • the embodiment of the present application provides a lock reiteration method.
  • the method includes: the server receives a lock reiteration request from the client; the server determines a target file corresponding to the client according to the lock reiteration request, and the target file is a file that the client wants to lock after the server restarts; The target file is locked with the lock mark of the lock mark, and the lock mark indicates that the target file was locked before the server failure.
  • the client can only perform lock reiteration on the files that were locked before the failure, reducing the abnormal lock reiteration of the client.
  • the server in this embodiment may be a network attached storage (NAS) server, which is a dedicated data storage server. It is data-centric, completely separates storage devices from servers, and centrally manages data, thereby freeing bandwidth, improving performance, reducing total cost of ownership, and protecting investments. Its cost is much lower than using server storage, and its efficiency is much higher.
  • NAS is defined as a special dedicated data storage server, including storage devices (such as disk arrays, compact disc (CD)/digital versatile disc (DVD) drives, tape drives or removable storage media ) and embedded system software to provide cross-platform file sharing.
  • NAS usually has its own node on a local area network (LAN) without the intervention of the application server, allowing users to access data on the network. In this configuration, the NAS centrally manages and processes all data on the network. Offload the load from the application or enterprise server, effectively reduce the total cost of ownership and protect user investment.
  • LAN local area network
  • the server configures the file with extended information that can store non-volatile data.
  • the lock reiteration request is processed according to the lock ID of the extended information.
  • the server processes the lock reiteration request according to the lock identifier of the extended information.
  • a period of silence is set for the client to reiterate the lock.
  • the server may be configured to end the silence in advance, or may not be configured to end the silence in advance.
  • the server is not configured to end the silence in advance.
  • the server determines the move-in event, it sets each file area to be silent, and reads the client information from the feature log.
  • the migration event is that when one node in the server fails, another node takes over the physical storage of the failed node. resource.
  • the server can silence each file area to prevent other clients from applying for locking and affecting the locking service of the client before the failure.
  • the server can read the client information from the feature log of the physical storage resource, and the client information can be the locking relationship between the client and the file area where the file in the server is located, indicating that the client is in a certain file area in the file area. The file is locked.
  • the server can determine which file areas and which clients have been locked before the server fails according to the locking relationship between the client and the file area in the server in the client information.
  • the server can de-quiesce the file area that has not been locked before the failure, so that the lock application of other clients can be executed normally.
  • the server sends a lock reiteration message to the client according to the client information.
  • the failure of the server can be a crash or other failure.
  • the server is restarted, the data in the cache is lost, and the locks on each file are also cleared.
  • the client needs to restore all previous state information and/or during the recovery period (ie the silent time). Or the relevant data is resent to the server, and the server can send a lock reiteration message to the client that locked the file before the server failure, informing the client that the file lock needs to be re-applied.
  • the client sends a lock reiteration request to the server according to the lock reiteration message.
  • the client can send a lock reiteration request to the server based on the file lock recorded in the cache, and the lock reiteration request may include the file identifier of the target file to be re-locked.
  • the lock reiteration request also includes the lock status reply flag (reclaim).
  • the client needs to restore the file lock previously applied for. At this time, the reclaim in the lock reiteration request message is set to 1, and the value is 0 in other cases.
  • the server determines the target file corresponding to the client according to the lock reiteration request.
  • the server After the server receives the lock reiteration request, it can determine the target file to be applied for by the client from the file system according to the above-mentioned file identifier.
  • Each file in the file system is provided with extended information, which is used to store non-volatile data.
  • the server determines the target file and needs to restore the lock of the target file, the server obtains the lock identifier from the extended information stored in the hard disk, for example, the data in the extended information corresponding to the target file can be read into the cache , if there is no lock identification in the extended information, the server can reject the client's lock reiteration request. If the lock identification exists in the extended information, the server can read and lock or write the target file accordingly according to the lock reiteration request. lock, wherein the lock identifier is used to indicate that the target file has been locked before the server fails.
  • the server can directly perform corresponding operations according to the data in the cache without reading the extended information.
  • the server stores the lock relationship between the client and the file region where the target file is located in the feature log.
  • the server can determine whether the locking relationship between the client and the file area where the target file is located has been written after a lock identification exists in the extended information and a corresponding locking operation is performed on the target file according to the lock reiteration request. If it has been written, it does not need to be written repeatedly. If it has not been written, the lock relationship between the client and the file area where the target file is located can be stored in the feature log to ensure data reliability.
  • the server confirms the lock identification from the extended information of the target file reiterated by the client, and rejects the lock reiteration request of the client for the file without the lock identification, because the reiterated file in the lock reiteration request of the client is not necessarily It is a file to which the client was locked before the server failure.
  • the client's lock reiteration request can be rejected for a file that has not been locked before the server failure, which can reduce abnormal lock reiteration by the client.
  • the server configuration ends the silence in advance.
  • the server determines the move-in event, it sets each file area to be silent, and reads client information from the feature log.
  • the server sends a lock reiteration message to the client according to the client information.
  • the client sends a lock reiteration request to the server according to the lock reiteration message.
  • the server determines the target file corresponding to the client according to the lock reiteration request.
  • Steps 401 to 405 in this embodiment may refer to the relevant descriptions of steps 301 to 305 in the lock reassertion method shown in FIG. 3 , and details are not repeated here.
  • the server marks the end of lock reiteration of the target file.
  • the scope of influence of the silence at the file area level is relatively large, and the silence cannot be released in advance during silence, and the influence time is relatively long, generally 60s.
  • the NAS server since the NAS server does not save the file information locked by the client, it cannot prevent the client from using the reiterated rules to apply for a lock that does not belong to itself during the reiteration.
  • Each file in the file system is provided with extended information, which is used to store non-volatile data.
  • the server determines the target file, it can read the data in the extension information corresponding to the target file into the cache. If there is no lock identification in the extension information, the server can reject the client's lock reiteration request.
  • the lock identifier the server can also obtain the number of locks in the extended information, and the number of locks is used to indicate the number of locks added to the target file before the server fails.
  • the target file can be set to multiple reads before the server fails.
  • the server can judge whether the number of multiple lock reiteration requests of the target file exceeds the number of locks after restarting. Within the range, the server can reject the current lock reiteration request and mark the end of the lock reiteration process of the target file, that is, the silence of the target file can be ended in advance.
  • the lock identification is used to indicate that the target file has been locked before the server fails.
  • the server locks the target file according to the lock reiteration request.
  • the server can directly The target file is read-locked or write-locked accordingly according to the lock reiteration request.
  • the server stores the lock relationship between the client and the file region where the target file is located in the feature log.
  • step 408 in this embodiment reference may be made to the relevant description of step 307 in the lock reassertion method shown in FIG. 3 , and details are not repeated here.
  • the server confirms the lock identification from the extended information of the target file reiterated by the client, and rejects the lock reiteration request of the client for the file without the lock identification, because the reiterated file in the lock reiteration request of the client is not necessarily It is a file to which the client was locked before the server failure.
  • the client's lock reiteration request can be rejected for a file that has not been locked before the server failure, which can reduce abnormal lock reiteration by the client.
  • the server can mark the end of the lock reiteration of the target file, that is, end the silence of the target file in advance, and other clients can proceed normally. Applying for a lock can also prevent the client from applying for a lock that does not belong to itself through the lock reiteration during the reiteration period, ending the silence in advance, and reducing the time affected by the failure.
  • the server sets the lock flag to the extended information of the file when the client applies for lock.
  • a period of silence is set for the client to reiterate the lock.
  • the server may be configured to end the silence in advance, or may not be configured to end the silence in advance.
  • the server is not configured to end the silence in advance.
  • the client sends a lock request to the server.
  • the client can check whether there is a file lock on the server when accessing a file in the server, so there will be no conflict when all clients access the same file.
  • the client can send a lock request for the file to the server.
  • the client can request a read lock or a write lock, and when there is only a read lock on the file, the client can only apply for a read lock.
  • the server determines the target file according to the lock request.
  • the lock request sent by the client includes the identifier of the file to be accessed by the client, and the server can determine the target file to be locked by the client according to the identifier.
  • the server stores the locking relationship between the client and the file region where the target file is located in the feature log.
  • the server can judge whether the locking relationship between the client and the file area where the target file is located has been written into the feature log (Feature log). and the locking relationship of the file area where the target file is located is stored in the feature log as the basis for the client to reiterate the lock.
  • the server stores the lock identifier in the extension information corresponding to the target file.
  • Each file in the file system is provided with extended information, which is used to store non-volatile data.
  • the server may determine the target file, obtain the lock identifier of the target file, and store the lock identifier in the extension information of the target file, and the lock identifier indicates the lock identifier of the target file.
  • the target file is currently locked, which can be used to indicate that the target file was locked before the server failed.
  • the extended information only records the lock identification once, which can save memory resources.
  • the target file has only one write lock, and can have one or more read locks.
  • the extended information may record the lock identification only once.
  • the client sends an unlock request to the server.
  • the client After the client accesses the file in the server, it needs to release the locked state of the file, and can send an unlock request for the file to the server, wherein the number of clients sending the unlock request to the server can be one or more.
  • the server determines the target file according to the unlock request.
  • the server determines the target file to be unlocked by the client according to the file identifier included in the unlock request.
  • the server clears the lock identifier.
  • the number of lock requests and unlock requests of all clients to the target file are stored in the cache. That is, the lock to be released by the current unlock request is the last lock of the target file, and the server can know the lock identifier in the extension information corresponding to the target file. Remove the lock sign from .
  • the server configures extended information for the file, and whether the lock identifier in the extended information exists can indicate whether the file has been locked when the server is restarted. For files that have not been locked before the server fails, the server can Rejecting the client's lock reiteration request can reduce the client's abnormal lock reiteration.
  • the server configuration ends the silence in advance.
  • the client sends a lock request to the server.
  • the server determines the target file according to the lock request.
  • the server stores the locking relationship between the client and the file region where the target file is located in the feature log.
  • the server stores the lock identifier in the extension information corresponding to the target file.
  • Steps 601 to 604 in this embodiment may refer to the relevant descriptions of steps 501 to 504 in the locking method shown in FIG. 5 , and details are not repeated here.
  • the server correspondingly increases the number of locks.
  • the extended information also includes the number of locks of the target file.
  • the server When the server receives a lock request that can be implemented, it will perform the corresponding lock operation on the target file, and then the number of locks of the target file can be obtained, and correspondingly.
  • the number of locks is recorded in the extended information, for example, an increase operation can be performed on the number of locks in the extended information. Exemplarily, after the server locks the target file, the number of locks is incremented by 1.
  • the client sends an unlock request to the server.
  • the server determines the target file according to the unlock request.
  • Steps 606 to 607 in this embodiment may refer to the relevant descriptions of steps 505 to 506 in the locking method shown in FIG. 5 , and details are not repeated here.
  • the server correspondingly reduces the number of locks.
  • the server after receiving the unlock request, the server reduces the number of locks in the extension information corresponding to the target file.
  • the number of locks is decremented by 1.
  • the server can clear the lock flag in the extension information of the target file, that is, when releasing the lock of the target file, the server will remove the lock from the target file from the target file. Delete the lock mark from the extended information of the file.
  • the server configures extended information for the file, and whether the lock identifier in the extended information exists can indicate whether the file has been locked when the server is restarted, so that there is no locked file before the server fails, the server The client's lock reiteration request can be rejected, which can reduce the client's abnormal lock reiteration.
  • the extended information also includes the number of locks, and the number of locks can provide the server with the number of locks added to the file after the server restarts, so that the server can end the file silence in advance according to the number of locks after restarting.
  • the lock reassertion method in this embodiment of the present application may be implemented through a system architecture.
  • FIG. 7 is a schematic diagram of the architecture of the server in this embodiment of the present application.
  • the server 103 includes an NFS module 1031, a lock server module 1032, Feature log module 1033 and file system 1034.
  • the lock server module 1032 further includes: a recovery (recover) module 10321, a lock manager (lock manager) module 10322 and a persistent (persistent) module 10323.
  • the NFS module 1031 After receiving the lock request from the client, the NFS module 1031 parses the lock information, and sends the lock information to the lock management module 10322 .
  • the NFS module 1031 executes steps 501 and 505 in FIG. 5 or steps 601 and 606 in FIG. 6 .
  • the lock management module 10322 determines whether the information of the locked client has been written into the feature log module 1033. If it has been written, it will not be written again. If the feature log module 1033 has not been written before, the client information will be written into the feature log module. 1033.
  • the lock management module 10322 may perform steps 502, 503, 506 and 507 in FIG. 5 or steps 602, 603, 607 and 609 in FIG. 6 .
  • the lock management module 10322 sends the lock information to the persistence module 10323, and the persistence module 10323 determines whether to write to the file system.
  • the persistence module 10323 determines whether the current server is configured with the function of ending the silence early. If the silent function is not terminated in advance, only the identifier of the first NFS lock needs to be written into the extended information of the file. When the client is unlocked, when the last lock is unlocked, the lock identifier in the extended information of the file is cleared. If the function of prematurely ending the silence is set, the number of locks (the number of locks) will be written into the extended information of the file. The number of locks in the extended information of the refresh file when the client is unlocked.
  • the lock management module 10322 may perform step 504 in FIG. 5 or steps 605 and 608 in FIG. 6 .
  • the recovery module 10321 After receiving the migration event, the recovery module 10321 reads the lock client information from the feature log module 1033 , and then sends the client information to the NFS module 1031 .
  • the recovery module 10321 can perform steps 301 and 302 in FIG. 3 or steps 401 and 402 in FIG. 4 .
  • the NFS module 1031 sends a lock reassertion message to the client, and receives a lock reassertion request from the client, parses the lock information, and sends the lock information to the lock management module 10322.
  • the NFS module 1031 may perform steps 303 and 304 in FIG. 3 or steps 403 and 404 in FIG. 4 .
  • the lock management module 10322 reads the extended information through the persistence module 10323. If it has already been read, it does not need to be read repeatedly, but can be read directly from the cache. If there is no setting to end the silent function in advance, you only need to judge whether there is a lock mark. If there is a lock identification, the logical judgment of lock reiteration is performed. If there is no lock flag, an error is returned and the client's lock reassertion is rejected. If the early termination of silence function is set, it is judged whether the number of locks reiterated is equal to the number of locks read, and if it is less than the number of locks read, the logical judgment of lock reiteration is performed. If the number of locks reiterated is equal to the number of locks read, the end of lock reiteration is marked.
  • the persistence module 10323 may perform step 306 in FIG. 3 or steps 406 and 407 in FIG. 4 .
  • the lock management module 10322 determines whether the information of the locked client has been written into the feature log module 1033. If it has been written, it will not be written again. If the feature log module 1033 has not been written before, the client information will be written into the feature log module. 1033.
  • the lock management module 10322 may perform steps 305 and 307 in FIG. 3 or steps 405 and 408 in FIG. 4 .
  • FIG. 8 is a schematic diagram of an embodiment of a server 80 in an embodiment of the present application.
  • an embodiment of the present application provides a structure of the server 80 including:
  • a receiving unit 801 configured to receive a lock reiteration request from a client
  • a determination unit 802 configured to determine the target object corresponding to the client according to the lock reiteration request, and the target object is the object that the client wants to lock after the server restarts;
  • the re-locking unit 803 is configured to lock the target object from the lock identifier in the extension information corresponding to the target object, where the lock identifier indicates that the target object was locked before the server failure.
  • another structure of the server 90 provided in this embodiment of the present application includes:
  • a receiving unit 901 configured to receive a lock reiteration request from a client
  • the determining unit 902 is used to determine the target object corresponding to the client according to the lock reiteration request, and the target object is the object that the client wants to lock after the server restarts;
  • the re-locking unit 903 is configured to lock the target object from the lock identifier in the extension information corresponding to the target object, where the lock identifier indicates that the target object was locked before the server failure.
  • the extended information further includes the number of locks
  • the server further includes a marking unit 904
  • the marking unit 904 is specifically configured to: when the number of lock reiteration requests corresponding to the target object exceeds the number of locks, mark the end of lock reiteration of the target object.
  • the target object may be a file, directory, etc. in the file system, or may be a block or a logical unit number (Logical Unit Number, LUN) in a block storage system, or an object in an object storage system.
  • LUN Logical Unit Number
  • the server further includes a first storage unit 905, and the first storage unit 905 is specifically configured to: when the successful lock reiteration request corresponds to the client, and the locking relationship of the object area where the target object is located is not stored in the feature log.
  • the lock relationship between the client and the target area where the target object is located is stored in the feature log.
  • the object area in the file system, the object area is the file area or the directory area; in the block storage system, the object area is the metadata area of the block or LUN; in the object storage system, it is the metadata area of the object.
  • the server also includes a locking unit 906, and the locking unit 906 is specifically used to: receive a locking request from the client; determine a target object according to the locking request, and the target object is the object to be locked by the client; The lock identification is stored in the corresponding extended information.
  • the extended information further includes the number of locks, and the locking unit is also used for: correspondingly increasing the number of locks.
  • the server further includes a first unlocking unit 907, and the first unlocking unit 907 is specifically configured to: receive unlocking requests from one or more clients; determine the target object according to the unlocking request, and the target object is the target object; When the number of unlock requests is the same as the number of lock requests, the lock flag is cleared.
  • the server further includes a second unlocking unit 908, and the second unlocking unit 908 is specifically configured to: receive the unlocking request from the client; determine the target object according to the unlocking request; reduce the number of locks accordingly; When the number of lock requests is the same, the lock flag is cleared.
  • the server further includes a second storage unit 909, and the second storage unit 909 is specifically configured to: when the locking relationship of the object area where the client and the target object are located is not stored in the feature log, store the object where the client and the target object are located. The locking relationship of the region is stored in the feature log.
  • another structure of the server 100 provided in this embodiment of the present application includes:
  • Obtaining unit 1001 for obtaining the lock identification of the target object
  • the recording unit 1002 is configured to record the lock identification in the extended information of the target object.
  • the obtaining unit 1001 is further configured to obtain the lock quantity of the target object; the recording unit 1002 is further configured to record the lock quantity in the extended information of the target object.
  • the server 100 further includes a deletion unit 1003, the deletion unit 1003 is configured to delete the lock identification from the extended information of the target object when the lock of the target object is released.
  • the server 100 further includes a reading unit 1004, and the reading unit 1004 is configured to acquire the lock identification from the extended information stored in the hard disk when restoring the lock of the target object.
  • the server 100 is applied to a distributed file storage system.
  • Computer device 110 includes: processor 1101 , communication interface 1102 , storage system 1103 , and bus 1104 .
  • the processor 1101 , the communication interface 1102 , and the storage system 1103 are connected to each other through a bus 1104 .
  • the processor 1101 is configured to control and manage the actions of the computer device 110.
  • the processor 1101 is configured to execute the steps performed by the storage management apparatus in the method embodiment of FIG. 3 .
  • Communication interface 1102 is used to support computer device 110 to communicate.
  • the storage system 1103 is used to store program codes and data of the computer device 110 .
  • the processor 1101 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logical blocks, modules and circuits described in connection with this disclosure.
  • the processor 1101 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and the like.
  • the bus 1104 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (Extended Industry Standard Architecture, EISA) bus or the like.
  • PCI Peripheral Component Interconnect
  • EISA Extended Industry Standard Architecture
  • Embodiments of the present invention may be specifically implemented by software, for example, by instructions, or by hardware, or by both software and hardware. This embodiment of the present invention does not limit this.
  • the embodiment of the present invention can be used in a storage array supporting a file system, and can also be used to perform the above operations of the embodiment of the present invention on a directory in the file system.
  • the embodiments of the present invention may also be applied to a block storage system or an object storage system.
  • the block storage system may be a distributed block storage system or a storage array.
  • the foregoing operations in the embodiments of the present invention may be used for operations on blocks or LUNs.
  • an object storage system the foregoing operations in the embodiments of the present invention may be applied to objects in the object storage system.
  • a computer-readable storage medium is also provided, where computer-executable instructions are stored in the computer-readable storage medium.
  • the processor of the device executes the computer-executable instructions
  • the device executes the above-mentioned FIG. 3 to The steps of the lock reassurance method performed by the server in FIG. 6 .
  • a computer program product includes computer-executable instructions, and the computer-executable instructions are stored in a computer-readable storage medium; when a processor of a device executes the computer-executable instructions , the device executes the steps of the lock reassertion method executed by the server in the above-mentioned FIG. 3 to FIG. 6 .
  • the server in this embodiment of the present invention may be a lock server, an array controller in a storage array, a server providing corresponding functions in a distributed storage system, and the like, which is not limited in this embodiment of the present invention.
  • Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, device and unit described above may refer to the corresponding process in the foregoing method embodiments, which will not be repeated here.
  • the disclosed system, apparatus and method may be implemented in other manners.
  • the apparatus embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or modules may be combined or Can be integrated into another system, or some features can be ignored, or not implemented.
  • the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.
  • the above-mentioned integrated units may be implemented in the form of hardware, or may be implemented in the form of software functional units.
  • the integrated unit if implemented in the form of a software functional unit and sold or used as an independent product, may be stored in a computer-readable storage medium.
  • the technical solutions of the present application can be embodied in the form of software products in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, and the computer software products are stored in a storage medium , including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), magnetic disk or optical disk and other media that can store program codes .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Procédé de réapplication de verrouillage, procédé de gestion de verrou et serveur, destinés à être utilisés dans la réduction de réapplications de verrouillage anormal d'un client. Le procédé comprend, après réception d'une demande de réapplication de verrouillage du client, le serveur devant détecter si un identifiant de verrouillage est présent sur des informations d'extension d'un objet cible demandé par la requête de réapplication de verrouillage et l'objet cible pouvant être verrouillé uniquement lorsque l'identifiant de verrouillage est présent.
PCT/CN2020/141986 2020-10-16 2020-12-31 Procédé de réapplication de verrouillage, procédé de gestion de verrou et serveur WO2022077777A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202080018013.5A CN114710976B (zh) 2020-10-16 2020-12-31 一种锁重申方法、锁管理方法以及服务器

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202031045050 2020-10-16
IN202031045050 2020-10-16

Publications (1)

Publication Number Publication Date
WO2022077777A1 true WO2022077777A1 (fr) 2022-04-21

Family

ID=81207627

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/141986 WO2022077777A1 (fr) 2020-10-16 2020-12-31 Procédé de réapplication de verrouillage, procédé de gestion de verrou et serveur

Country Status (2)

Country Link
CN (1) CN114710976B (fr)
WO (1) WO2022077777A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7143097B1 (en) * 2003-07-30 2006-11-28 Hewlett-Packard Development Company, L.P. Method and apparatus for migrating file locks from one server to another
CN102375955A (zh) * 2010-08-17 2012-03-14 伊姆西公司 网络文件系统联合命名空间内文件加锁的系统与方法
US20160217051A1 (en) * 2013-06-27 2016-07-28 International Business Machines Corporation Unobtrusive Failover in Clustered Network-Attached Storage
CN108023939A (zh) * 2014-11-12 2018-05-11 华为技术有限公司 分布式系统中锁服务器故障的处理方法及其系统
US20190199801A1 (en) * 2015-12-14 2019-06-27 Huawei Technologies Co., Ltd. Lock Management Method in Cluster, Lock Server, and Client

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105208124A (zh) * 2015-09-29 2015-12-30 华为技术有限公司 管理锁的方法及装置、确定锁管理服务器的方法及装置
CN110990190A (zh) * 2019-10-31 2020-04-10 苏州浪潮智能科技有限公司 一种分布式文件锁故障处理方法、系统、终端及存储介质
CN111125048B (zh) * 2019-12-06 2022-04-22 浪潮电子信息产业股份有限公司 一种故障通知方法、装置、设备及计算机可读存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7143097B1 (en) * 2003-07-30 2006-11-28 Hewlett-Packard Development Company, L.P. Method and apparatus for migrating file locks from one server to another
CN102375955A (zh) * 2010-08-17 2012-03-14 伊姆西公司 网络文件系统联合命名空间内文件加锁的系统与方法
US20160217051A1 (en) * 2013-06-27 2016-07-28 International Business Machines Corporation Unobtrusive Failover in Clustered Network-Attached Storage
CN108023939A (zh) * 2014-11-12 2018-05-11 华为技术有限公司 分布式系统中锁服务器故障的处理方法及其系统
US20190199801A1 (en) * 2015-12-14 2019-06-27 Huawei Technologies Co., Ltd. Lock Management Method in Cluster, Lock Server, and Client

Also Published As

Publication number Publication date
CN114710976A (zh) 2022-07-05
CN114710976B (zh) 2023-06-16

Similar Documents

Publication Publication Date Title
US10853339B2 (en) Peer to peer ownership negotiation
US9804929B2 (en) Centralized management center for managing storage services
US8239648B2 (en) Reclamation of thin provisioned disk storage
US8041907B1 (en) Method and system for efficient space management for single-instance-storage volumes
US8706694B2 (en) Continuous data protection of files stored on a remote storage device
US10852981B2 (en) System for migrating virtual tape volumes between filesystems
US8332600B2 (en) Storage system and method for operating storage system
US9176853B2 (en) Managing copy-on-writes to snapshots
US11169835B1 (en) VM data migration between storage devices
US9760457B2 (en) System, method and computer program product for recovering stub files
US11327686B2 (en) Apparatus and method for managing integrated storage supporting hierarchical structure
JP4726909B2 (ja) ストレージ階層内のデータの冗長記憶を管理する方法、システムおよびコンピュータ・プログラム
US20110282917A1 (en) System and method for efficient resource management
CN106528338B (zh) 一种远程数据复制方法、存储设备及存储系统
US20060156030A1 (en) Data processing system and method
US8868503B1 (en) Method and system for managing clones of replicated storage
CN111399760A (zh) Nas集群元数据处理方法、装置、nas网关及介质
US20110173356A1 (en) Exclusive access during a critical sub-operation to enable simultaneous operations
WO2022077777A1 (fr) Procédé de réapplication de verrouillage, procédé de gestion de verrou et serveur
WO2023273803A1 (fr) Procédé et appareil d'authentification et système de stockage
US20190121899A1 (en) Apparatus and method for managing integrated storage
US11467929B2 (en) Reducing failover time between data nodes
US20240007441A1 (en) Internet protocol based security over port forwarding tunnels
US20240143454A1 (en) System and techniques for backing up scalable computing objects
US10592527B1 (en) Techniques for duplicating deduplicated data

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20957551

Country of ref document: EP

Kind code of ref document: A1