A fault recovery method, an NFS server and a storage medium

Abstract

The embodiment of the application provides a fault recovery method, an NFS server and a storage medium, comprising: obtaining a VIP list corresponding to the NFS server from an HA server, and reading a VIP subdirectory in an NFS recovery directory in a TFS to obtain a to-be-recovered VIP; in the case that a first VIP in the to-be-recovered VIP is detected in the VIP list, reading a first NFS client subdirectory and a corresponding first lock count subdirectory under a first VIP subdirectory corresponding to the first VIP to obtain an NFS client identifier and a corresponding lock count value; in the case that a first lock request carrying a recovery identifier is received from the NFS client, detecting whether the identifier of the NFS client matches the NFS client identifier; if the identifier of the NFS client matches the NFS client identifier, sending the first lock request to the TFS for recovery, and reducing the lock count value by one; until the lock count value is zero, completing the fault recovery process.

Description

Technical Field

[0001] This application relates to the field of network file systems, and more particularly to a fault recovery method and an NFS server and storage medium. Background Technology

[0002] A cluster of Network File System (NFS) servers is deployed on a distributed file system (TFS), where the NFS servers provide the file system access interface. In an NFS v4 scenario, when a single-node NFS server fails, the NFS client detects the failure and enters the fault recovery phase. During this phase, the NFS client automatically sends open and lock requests with a reclaim flag to the NFS server for any open and lock messages it already holds. The NFS server then recovers from these reclaimed requests. However, currently, this only provides fault recovery capabilities for the local NFS server node and cannot recover from failures of other NFS server nodes, resulting in low intelligence in fault recovery. Summary of the Invention

[0003] This application provides a fault recovery method, an NFS server, and a storage medium, which can improve the intelligence of fault recovery.

[0004] The technical solution of this application is implemented as follows:

[0005] In a first aspect, embodiments of this application propose a fault recovery method applied to a network file system (NFS) server deployed on a distributed file system (TFS), the method comprising:

[0006] Obtain the list of virtual IP addresses (VIPs) corresponding to the NFS server from the high availability (HA) server, and read the VIP subdirectory in the NFS recovery directory of the TFS to obtain the VIPs to be recovered;

[0007] If the first VIP among the VIPs to be recovered is detected in the VIP list, the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory are read to obtain the NFS client identifier and the corresponding lock count value.

[0008] Upon receiving a first lock request carrying a reclaim identifier from an NFS client, check whether the identifier of the NFS client matches the identifier of the NFS client.

[0009] If the identifier of the NFS client matches the identifier of the NFS client, the first lock request is sent to the TFS for fault recovery, and the lock count value is decremented by one; until the lock count value is zero, the fault recovery process is completed.

[0010] Secondly, embodiments of this application propose an NFS server, which is deployed on TFS, and the NFS server includes:

[0011] The acquisition unit is used to obtain the list of virtual IP addresses (VIPs) corresponding to the NFS server from the high availability (HA) server.

[0012] The reading unit is used to read the VIP subdirectory in the NFS recovery directory in the TFS to obtain the VIP to be recovered; when the first VIP in the VIP to be recovered is detected in the VIP list, the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory are read to obtain the NFS client identifier and the corresponding lock count value.

[0013] The detection unit is used to detect whether the identifier of the NFS client matches the identifier of the NFS client when a first lock request carrying a reclaim identifier is received from the NFS client.

[0014] The fault recovery unit is configured to send the first lock request to the TFS for recovery if the identifier of the NFS client matches the identifier of the NFS client, and decrement the lock count value by one; until the lock count value is zero, the fault recovery process is completed.

[0015] Thirdly, this application provides an NFS server, which includes a processor and a memory; the processor executes a running program stored in the memory to implement the fault recovery method described above.

[0016] Fourthly, embodiments of this application propose a storage medium storing a computer program thereon, which, when executed by a processor, implements the fault recovery method as described above.

[0017] This application provides a fault recovery method, an NFS server, and a storage medium. The method includes: obtaining a list of VIPs corresponding to the NFS server from the HA server and reading the VIP subdirectory in the NFS recovery directory in TFS to obtain the VIP to be recovered; if the first VIP among the VIPs to be recovered is detected in the VIP list, reading the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory to obtain the NFS client identifier and the corresponding lock count value; if a first lock request carrying a reclamation identifier is received from the NFS client, checking whether the NFS client identifier matches the NFS client identifier; if the NFS client identifier matches the NFS client identifier, sending the first lock request to TFS for recovery and decrementing the lock count value by one; until the lock count value is zero, the fault recovery process is completed. The above-described solution manages the NFS servers in the HA cluster. It sets up an NFS recovery directory and its VIP subdirectory, NFS client subdirectory, and lock count subdirectory in TFS. This saves the VIP information, NFS client information, and their corresponding lock count values ​​from the memory of a single-node NFS server. During fault recovery, it can match the VIP and NFS client identifiers for the NFS servers in the cluster, thereby enabling fault recovery under the NFS servers in the cluster and improving the intelligence of fault recovery. Attached Figure Description

[0018] Figure 1 A flowchart illustrating a fault recovery method provided in this application embodiment;

[0019] Figure 2 A reference diagram illustrating an exemplary data structure of recovered data in TFS, provided for embodiments of this application;

[0020] Figure 3 A reference diagram illustrating an exemplary preset data structure for recovered data in memory, provided for embodiments of this application;

[0021] Figure 4 A reference diagram illustrating an exemplary process for recovering data records, provided for an embodiment of this application;

[0022] Figure 5 A reference diagram illustrating an exemplary fault recovery process provided in an embodiment of this application;

[0023] Figure 6 A schematic diagram of the structure of an NFS server provided in this application embodiment. Figure 1 ;

[0024] Figure 7 A schematic diagram of the structure of an NFS server provided in this application embodiment. Figure 2 . Detailed Implementation

[0025] In order to gain a more detailed understanding of the features and technical content of the embodiments of this application, the implementation of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for reference and illustration only and are not intended to limit the embodiments of this application.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0027] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. It should also be noted that the terms "first, second, third" used in the embodiments of this application are merely for distinguishing similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0028] This application provides a fault recovery method applied to an NFS server deployed on a TFS, such as... Figure 1 As shown, the method may include:

[0029] S101. Obtain the list of virtual IP addresses (VIPs) corresponding to the NFS server from the high availability (HA) server, and read the VIP subdirectory in the NFS recovery directory in TFS to obtain the VIPs to be recovered.

[0030] In this embodiment, when the NFS server is running, the VIP list corresponding to the NFS server is obtained from the HA server; or, upon receiving a message from the HA indicating that a VIP has migrated to the NFS server, the VIP list corresponding to the NFS server is obtained from the HA server. The specific application scenario for obtaining the VIP list corresponding to the NFS server from the HA server can be selected according to the actual situation, and this embodiment does not impose specific limitations.

[0031] It should be noted that in scenarios where a VIP migrates to the NFS server, the HA server sends a dbus message to the NFS server to trigger the NFS server to enter the grace period (a period during which the NFS server enters the fault recovery phase). At the same time, it reads the recovery data corresponding to the VIP to ensure failover capability. When the NFS server before the VIP migration returns to normal, the HA server also sends a dbus message to the NFS server before the VIP migration to trigger the NFS server before the VIP migration to enter the grace period. It also switches the existing open and lock messages of the NFS server before the VIP migration from the holding state to the recovery state to ensure fault recovery capability.

[0032] In this embodiment of the application, the HA server manages the NFS servers in the cluster, thereby obtaining the VIP list corresponding to the NFS service area from the HA server.

[0033] In this embodiment, the NFS server first records recovery data in the TFS; when the NFS server is started, an NFS recovery directory, a VIP subdirectory, and an empty backup subdirectory are created sequentially in the TFS; the VIP subdirectory is created by obtaining the VIP list of the NFS server from the HA server; when an access request is received from an NFS client using a second VIP, a corresponding second NFS client subdirectory and a second lock count subdirectory with a count value of zero are created under the second VIP subdirectory corresponding to the second VIP, and the identifier of the NFS client is recorded in the first client subdirectory corresponding to the first VIP; when a lock request is received from an NFS client, the lock count value in the second lock count subdirectory is incremented by one; when an unlock request is received from an NFS client, the lock count value in the second lock count subdirectory is decremented by one.

[0034] It should be noted that the recovered data is referenced in the TFS data structure. Figure 2 ,include:

[0035] 1. .nfs_recovery: NFS recovery directory; a hidden directory under the root directory of the TFS file system, which stores all recovered data.

[0036] 2. VIP: VIP subdirectory; a directory named after the Internet Protocol (IP) address string of the VIP, created as a subdirectory named ".nfs_recovery". There will be N such directories depending on the number of VIPs.

[0037] 3. ClientID: Client subdirectory; A directory named after the string converted from clientID, created as a subdirectory named "VIP", indicating that the NFS client connects to the NFS server through this VIP. There will be N such directories depending on the number of NFSclient connections.

[0038] 4. lock_count: Lock count subdirectory; files created with the command "lock_count" are named as files under "ClientID". There is only one file under each ClientID directory, and the file content is the number of locks under that ClientID.

[0039] 5. old: Backup subdirectory; A directory named "old" is created as a subdirectory named ".nfs_recovery". Only one such subdirectory is created and is used to back up the VIP directory during the recovery process to prevent data loss during recovery due to a failure.

[0040] It should be noted that after reading the VIP subdirectory in the NFS recovery directory within TFS to obtain the VIP to be recovered, a callback function is also registered in TFS. This callback function can be used to allow the NFS server to exit the fault recovery process prematurely after completion. Therefore, the NFS server does not need to exit according to a set time, reducing the time the NFS server provides normal service access.

[0041] In this embodiment of the application, since the TFS records the recovery data of the NFS server in the cluster, the VIP to be recovered can be read from the VIP subdirectory in the NFS recovery directory of the TFS.

[0042] S102. If the first VIP in the VIP to be recovered is detected in the VIP list, read the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory to obtain the NFS client identifier and the corresponding lock count value.

[0043] In this embodiment, the VIPs to be recovered are matched sequentially with the VIP list. When the first VIP in the VIPs to be recovered matches the second VIP in the VIP list, it is detected that the first VIP in the VIPs to be recovered is in the VIP list. At this time, the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory are searched. The first NFS client subdirectory and the first lock count subdirectory are read to obtain the NFS client identifier connected to the NFS server through the first VIP and the lock count value under the NFS client identifier. When the third VIP in the VIPs to be recovered does not match any VIP in the VIP list, it is detected that the third VIP is not in the VIP list. At this time, the process of matching the VIPs to be recovered with the VIP list continues.

[0044] It should be noted that after obtaining the NFS client identifier and the corresponding lock count value, the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory are also stored in memory according to a preset data structure. The preset data structure is: global variable linked list head, linked list nodes contained in the global variable linked list head, and members of each linked list node, including: lock count value and client identifier.

[0045] In an optional embodiment, a preset data structure in memory may be referenced. Figure 3 ,include:

[0046] 1. clid_list: Head of the global variable linked list.

[0047] 2. ClinetID: A linked list node of clinet_list.

[0048] 3. lock_count: A member of the ClientID node, recording the number of lock requests made before a failure under this NFS client identifier.

[0049] 4. clientid: A member of the ClientiD node, recording the NFS client identifier.

[0050] Furthermore, after obtaining the NFS client identifier and the corresponding lock counter value, the NFS client identifier and lock counter value are backed up to the backup subdirectory in the NFS recovery directory; so that in the event of an NFS server restart, the VIP subdirectory name can be obtained sequentially from the backup subdirectory and the NFS recovery directory.

[0051] It should be noted that for scenarios where fault recovery is performed during NFS server startup or restart, the VIP subdirectory name can be obtained sequentially from the backup subdirectory and the NFS recovery directory; for scenarios where fault recovery is performed when VIP drift occurs in HA, since there is no issue of fault recovery caused by multiple startups, the VIP subdirectory name can be obtained directly from the NFS recovery directory.

[0052] Understandably, when reading the VIP subdirectory in the NFS recovery directory, after obtaining the NFS client identifier and the corresponding lock counter value, the VIP and its subdirectory information will be moved to the backup subdirectory. This avoids the loss of recovery information caused by multiple failures during the fault recovery process due to direct deletion, and thus avoids the failure to delete the recovery information before the fault affects the new fault information generated during this service.

[0053] It should be noted that during this fault recovery process, after all the recovery data was written from TFS to memory, all the data in the backup subdirectory was deleted.

[0054] S103. Upon receiving a first lock request carrying a reclaim identifier from an NFS client, check whether the identifier of the NFS client matches the identifier of the NFS client.

[0055] In this embodiment, the NFS client can send a first lock request carrying a reclaim identifier, and can also send a second lock request without a reclaim identifier. When the NFS server receives the first lock request carrying a reclaim identifier from the NFA client, the NFS client checks whether its identifier matches the obtained NFS client identifier. It is understood that recording the client identifier in the TFS and performing NFS client identifier matching during fault recovery after receiving the first lock request ensures the reliability of recovery data across the cluster's NFS servers.

[0056] It should be noted that, upon receiving a second lock request from an NFS client that does not carry a reclaim flag, the system retrieves the executed lock information corresponding to the NFS client from TFS; it then matches the pending lock information corresponding to the second lock request with the executed lock information; if the pending lock information and the executed lock information match, the second lock request is rejected; if the pending lock information and the executed lock information do not match, the second lock request is executed.

[0057] Understandably, during the grace phase, the NFS server will not reject all second lock requests that do not carry a reclamation flag. Instead, it will determine whether to execute the second lock request based on the information of the already executed locks, thus providing normal business access during the grace phase.

[0058] S104. If the NFS client identifier matches the NFS client identifier, the first lock request is sent to the TFS for recovery, and the lock count is decremented by one; until the lock count is zero, the fault recovery process is completed.

[0059] In this embodiment, after the fault recovery process is completed with a lock count of zero, the fault recovery process can be exited via a callback function. This allows for early exit from the grace process, reducing fault recovery time and increasing the time the NFS server can provide services normally.

[0060] Understandably, by managing NFS servers in an HA cluster and setting up an NFS recovery directory and its VIP subdirectory, NFS client subdirectory, and lock count subdirectory in TFS, the VIP information, NFS client information, and their corresponding lock count values ​​stored in the memory of a single-node NFS server can be saved. This allows for the matching of VIP and NFS client identifiers for NFS servers in the cluster during fault recovery, thereby enabling fault recovery to be performed on the NFS servers in the cluster and improving the intelligence of fault recovery.

[0061] Based on the above embodiments, this application proposes a process for recovering data records, see [link to relevant documentation]. Figure 4 ,include:

[0062] 1. In the NFS server startup scenario, create the .nfs_recovery directory;

[0063] 2. Obtain the VIP list of the NFS server from the HA server;

[0064] 3. Based on the VIP list, create a VIP subdirectory under the .nfs_recovery directory;

[0065] 4. Create an empty backup subdirectory under the .nfs_recovery directory;

[0066] 5. In scenarios where the NFS client sends a request, the NFS client sends a setclientid_confirm request to the NFS server;

[0067] 6. Create a clientID directory on the NFS server;

[0068] 7. The NFS server creates a lock_count file and initializes its contents to 0.

[0069] 8. When the NFS client sends a lock request to the NFS server, the value in the lock_count file is incremented by 1.

[0070] 9. When an NFS client sends an unlock request to the NFS server, the value in the lock_count file is decremented by 1.

[0071] Based on the above embodiments, this application also proposes a fault recovery process, in which the grace phase can be triggered in the NFS server, and fault recovery is performed during the grace phase. See [link to relevant documentation]. Figure 5 ,include:

[0072] 1. Obtain the VIP list of the NFS server from the HA server;

[0073] 2. Read the backup VIP subdirectory in the backup subdirectory in sequence;

[0074] 3. Determine if the backup VIP subdirectory is in the VIP list;

[0075] 4. If the backup VIP subdirectory is not in the VIP list, then proceed to step 2;

[0076] 5. If the backup VIP subdirectory is in the VIP list, then read the clientID subdirectory under the backup VIP subdirectory and its lock_count record into clis_list;

[0077] 6. Determine if the backup subdirectory has been completely read;

[0078] 7. If the backup subdirectory has not been fully read, proceed to step 2;

[0079] 8. If the backup subdirectory has been read, then the VIP subdirectory in the .nfs_recovery directory will be read;

[0080] 9. Determine if the VIP subdirectory is in the VIP list;

[0081] 10. If the VIP subdirectory is not in the VIP list, then proceed to step 8;

[0082] 11. If the VIP subdirectory is in the VIP list, then read the clientID subdirectory under the VIP subdirectory and its lock_count record into clis_list;

[0083] 12. Move the VIP subdirectory and its subdirectories to the backup subdirectory;

[0084] 13. Determine if the .nfs_recovery directory has been completely read;

[0085] 14. If the .nfs_recovery directory has been read, the process will proceed to the grace phase.

[0086] 15. If the .nfs_recovery directory has not been fully read, proceed to step 8;

[0087] It should be noted that, for the NFS server startup scenario, the NFS server executes steps 1-15; for the VIP drift scenario in HA, when HA sends a VIP drift event to the NFS server, it triggers the NFS server to execute process 8-15, and the trigger for step 8 is that HA sends a message to the NFS server that HA has drifted to the NFS server.

[0088] 16. When the NFS client sends a first lock request carrying a reclaim flag, the NFS server checks whether it has entered the grace phase.

[0089] 17. If the process enters the grace phase, determine whether the identifier of the NFS client corresponding to the first lock request is in clis_list;

[0090] 18. If the grace phase has not been reached, proceed to step 20.

[0091] 19. If the identifier of the NFS client corresponding to the first lock request is not in clis_list, then execute 20;

[0092] 20. Return the error flag;

[0093] 21. If the identifier of the NFS client corresponding to the first lock request is in clis_list, then the first lock request is sent to TFS to perform fault recovery;

[0094] 22. Decrease the lock_count value in clis_list;

[0095] 23. Check if the lock_count in clid_list is 0;

[0096] 24. If lock_count in clid_list is 0, exit the grace phase and clear the backup subdirectory;

[0097] 25. If lock_count in clid_list is not 0, then return to execute 16.

[0098] Based on the above embodiments, this application provides an NFS server 1, which is deployed on TFS, such as... Figure 6 As shown, the NFS server 1 includes:

[0099] The acquisition unit 10 is used to obtain the list of virtual IP addresses (VIPs) corresponding to the NFS server from the high availability (HA) server.

[0100] Reading unit 11 is used to read the VIP subdirectory in the NFS recovery directory in the TFS to obtain the VIP to be recovered; when the first VIP in the VIP to be recovered is detected in the VIP list, the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory are read to obtain the NFS client identifier and the corresponding lock count value.

[0101] The detection unit 12 is used to detect whether the identifier of the NFS client matches the identifier of the NFS client when it receives a first lock request carrying a recycling identifier sent by the NFS client.

[0102] The fault recovery unit 13 is used to send the first lock request to the TFS for recovery if the identifier of the NFS client matches the identifier of the NFS client, and decrement the lock count value by one; until the lock count value is zero, the fault recovery process is completed.

[0103] Optionally, the NFS server 1 further includes: a backup unit;

[0104] The backup unit is used to back up the NFS client identifier and the lock count value to the backup subdirectory in the NFS recovery directory; so that when the NFS server restarts, the VIP subdirectory name can be obtained from the backup subdirectory and the NFS recovery directory in sequence.

[0105] Optionally, the acquisition unit 10 is further configured to acquire the VIP list corresponding to the NFS server from the HA server when the NFS server is started; or, when receiving a message sent by the HA indicating that a VIP has migrated to the NFS server, acquire the VIP list corresponding to the NFS server from the HA server.

[0106] Optionally, the NFS server 1 further includes: a matching unit and a processing unit;

[0107] The acquisition unit 10 is further configured to, upon receiving a second lock request from the NFS client that does not carry a reclaim identifier, acquire the executed lock information corresponding to the NFS client from the TFS.

[0108] The matching unit is used to match the lock information to be executed corresponding to the second lock request with the executed lock information;

[0109] The processing unit is configured to refuse to execute the second lock request if the lock information to be executed matches the lock information already executed; and to execute the second lock request if the lock information to be executed does not match the lock information already executed.

[0110] Optionally, the NFS server 1 further includes: a creation unit;

[0111] The creation unit is configured to, when the NFS server is started, sequentially create the NFS recovery directory, the VIP subdirectory, and an empty backup subdirectory in the TFS; the VIP subdirectory is created by obtaining the VIP list of the NFS server from the HA server; when an NFS client sends an access request using a second VIP, a corresponding second NFS client subdirectory and a second lock count subdirectory with a count value of zero are created under the second VIP subdirectory corresponding to the second VIP, and the identifier of the NFS client is recorded in the second NFS client subdirectory; when a lock request is received from the NFS client, the lock count value in the second lock count subdirectory is incremented by one; when an unlock request is received from the NFS client, the lock count value in the second lock count subdirectory is decremented by one.

[0112] Optionally, the NFS server 1 further includes: a registration unit and a logout unit;

[0113] The registration unit is used to register callback functions in the TFS;

[0114] The exit unit is used to exit the fault recovery process through the callback function.

[0115] Optionally, the NFS server 1 further includes: a storage unit;

[0116] The storage unit is used to store the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory into memory according to a preset data structure; the preset data structure is: a global variable linked list head, linked list nodes contained in the global variable linked list head, and members of each linked list node, wherein the members include: lock count value and client identifier.

[0117] This application provides an NFS server that obtains a list of VIPs corresponding to the NFS server from the HA server and reads the VIP subdirectory in the NFS recovery directory in TFS to obtain the VIPs to be recovered. If the first VIP in the list of VIPs to be recovered is detected, the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory are read to obtain the NFS client identifier and the corresponding lock count value. If a first lock request carrying a reclamation identifier is received from the NFS client, it is checked whether the NFS client identifier matches the NFS client identifier. If the NFS client identifier matches the NFS client identifier, the first lock request is sent to TFS for recovery, and the lock count value is decremented by one. The fault recovery process is completed when the lock count value is zero. Therefore, the NFS server proposed in this embodiment manages the NFS servers in the HA cluster and sets up an NFS recovery directory and its VIP subdirectory, NFS client subdirectory and lock count subdirectory in TFS. It saves the VIP information, NFS client information and their corresponding lock count values ​​in the memory of a single node NFS server. During the fault recovery process, it can match the VIP and NFS client identifiers for the NFS servers in the cluster, and thus perform fault recovery under the NFS servers in the cluster, thereby improving the intelligence of fault recovery.

[0118] Figure 7 A schematic diagram of the composition structure of an NFS server 1 provided in this application embodiment. Figure 2 In practical applications, based on the same disclosed concept of the above embodiments, such as Figure 7 As shown, the NFS server 1 in this embodiment includes: a processor 14, a memory 15, and a communication bus 16.

[0119] In specific embodiments, the processor 14 can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), CPU, controller, microcontroller, and microprocessor. It is understood that for different devices, the electronic device used to implement the processor function can also be other types, and this embodiment does not impose specific limitations.

[0120] In this embodiment, the communication bus 16 is used to establish communication between the processor 14 and the memory 15; when the processor 14 executes the running program stored in the memory 15, it implements the following fault recovery method:

[0121] The system retrieves the list of Virtual IP Addresses (VIPs) corresponding to the NFS server from the High Availability (HA) server and reads the VIP subdirectory from the NFS recovery directory in the TFS to obtain the VIPs to be recovered. If the first VIP among the VIPs to be recovered is detected in the VIP list, the system reads the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory to obtain the NFS client identifier and the corresponding lock count value. If a first lock request carrying a reclaim identifier is received from the NFS client, the system checks whether the NFS client identifier matches the NFS client identifier. If the NFS client identifier matches the NFS client identifier, the system sends the first lock request to the TFS for fault recovery and decrements the lock count value by one. The fault recovery process is completed when the lock count value is zero.

[0122] Furthermore, the processor 14 is also configured to back up the NFS client identifier and the lock count value to a backup subdirectory in the NFS recovery directory; so as to obtain the VIP subdirectory name sequentially from the backup subdirectory and the NFS recovery directory in the event of an NFS server restart.

[0123] Furthermore, the processor 14 is also configured to obtain the VIP list corresponding to the NFS server from the HA server when the NFS server is started; or, when receiving a message sent by the HA indicating that a VIP has migrated to the NFS server, obtain the VIP list corresponding to the NFS server from the HA server.

[0124] Furthermore, the processor 14 is also configured to, upon receiving a second lock request from an NFS client that does not carry a reclaim identifier, obtain the executed lock information corresponding to the NFS client from the TFS; match the lock information to be executed corresponding to the second lock request with the executed lock information; if the lock information to be executed and the executed lock information match, then refuse to execute the second lock request; if the lock information to be executed and the executed lock information do not match, then execute the second lock request.

[0125] Furthermore, the processor 14 is also configured to, when the NFS server is started, sequentially create the NFS recovery directory, the VIP subdirectory, and an empty backup subdirectory in the TFS; the VIP subdirectory is created by obtaining the VIP list of the NFS server from the HA server; when receiving an access request sent by an NFS client using a second VIP, create a corresponding second NFS client subdirectory and a second lock count subdirectory with a count value of zero under the second VIP subdirectory corresponding to the second VIP, and record the identifier of the NFS client in the second NFS client subdirectory; when receiving a lock request sent by the NFS client, increment the lock count value in the second lock count subdirectory by one; when receiving an unlock request sent by the NFS client, decrement the lock count value in the second lock count subdirectory by one.

[0126] Furthermore, the processor 14 is also used to register a callback function in the TFS; and to exit the fault recovery process through the callback function.

[0127] Furthermore, the processor 14 is also used to store the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory into memory according to a preset data structure; the preset data structure is: a global variable linked list head, linked list nodes contained in the global variable linked list head, and members of each linked list node, the members including: lock count value and client identifier.

[0128] This application provides a storage medium storing a computer program thereon. The computer-readable storage medium stores one or more programs, which can be executed by one or more processors and applied in an NFS server. The computer program implements the fault recovery method described above.

[0129] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0130] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause an image display device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this disclosure.

[0131] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A fault recovery method applied to a Network File System (NFS) server deployed on a distributed file system (TFS), the method comprising: Obtain the list of virtual IP addresses (VIPs) corresponding to the NFS server from the high availability (HA) server, and read the VIP subdirectory in the NFS recovery directory of the TFS to obtain the VIPs to be recovered; If the first VIP among the VIPs to be recovered is detected in the VIP list, the first NFS client subdirectory under the first VIP subdirectory corresponding to the first VIP and the first lock count subdirectory corresponding to the first NFS client subdirectory are read to obtain the NFS client identifier and the corresponding lock count value. Upon receiving a first lock request carrying a reclaim identifier from an NFS client, check whether the identifier of the NFS client matches the identifier of the NFS client. If the NFS client identifier matches the NFS client identifier, the first lock request is sent to the TFS for recovery, and the lock count value is decremented by one; until the lock count value is zero, the fault recovery process is completed.

2. The method according to claim 1, after reading the NFS client subdirectory and the corresponding lock count subdirectory under the first VIP subdirectory corresponding to the first VIP to obtain the NFS client identifier and the corresponding lock count value, the method further includes: Back up the NFS client identifier and the lock count value to the backup subdirectory of the NFS recovery directory; In the event of a restart of the NFS server, the VIP subdirectory name is obtained sequentially from the backup subdirectory and the NFS recovery directory.

3. The method according to claim 1, wherein obtaining the list of Virtual IP addresses (VIPs) corresponding to the NFS server from the high-availability (HA) server includes: When the NFS server is started, obtain the VIP list corresponding to the NFS server from the HA server; or, Upon receiving a message from the HA indicating that a VIP has migrated to the NFS server, the HA server retrieves the VIP list corresponding to the NFS server.

4. The method according to claim 1, further comprising: Upon receiving a second lock request from an NFS client that does not carry a reclaim identifier, retrieve the executed lock information corresponding to the NFS client from the TFS. Match the lock information to be executed corresponding to the second lock request with the already executed lock information; If the lock information to be executed matches the lock information already executed, then the second lock request is rejected. If the lock information to be executed and the lock information already executed do not match, then the second lock request is executed.

5. The method according to claim 1, further comprising: When the NFS server is started, the NFS recovery directory, the VIP subdirectory, and the empty backup subdirectory are created sequentially in the TFS. The VIP subdirectory is created by obtaining the VIP list of the NFS server from the HA server. Upon receiving an access request sent by an NFS client using a second VIP, a corresponding second NFS client subdirectory and a second lock count subdirectory with a count value of zero are created under the second VIP subdirectory corresponding to the second VIP, and the identifier of the NFS client is recorded in the second NFS client subdirectory; Upon receiving a lock request from the NFS client, increment the lock count value in the second lock count subdirectory by one; Upon receiving an unlock request from the NFS client, the lock count value in the second lock count subdirectory is decremented by one.

6. The method according to claim 1, wherein after reading the VIP subdirectory in the NFS recovery directory of the TFS to obtain the VIP to be recovered, and before reading the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory to obtain the NFS client identifier and the corresponding lock count value, the method further includes: Register a callback function in the TFS; After the lock count value reaches zero, the method further includes: The fault recovery process is exited through the callback function.

7. The method according to claim 1, further comprising: Store the first NFS client subdirectory and the corresponding first lock count subdirectory under the first VIP subdirectory into memory according to a preset data structure; The preset data structure is as follows: a global variable linked list head, linked list nodes contained in the global variable linked list head, and members of each linked list node, wherein the members include: lock count value and client identifier.

8. An NFS server, the NFS server being deployed on TFS, the NFS server comprising: The acquisition unit is used to obtain the list of virtual IP addresses (VIPs) corresponding to the NFS server from the high availability (HA) server. The reading unit is used to read the VIP subdirectory in the NFS recovery directory of the TFS to obtain the VIP to be recovered; If the first VIP among the VIPs to be recovered is detected in the VIP list, the first NFS client subdirectory under the first VIP subdirectory corresponding to the first VIP and the first lock count subdirectory corresponding to the first NFS client subdirectory are read to obtain the NFS client identifier and the corresponding lock count value. The detection unit is used to detect whether the identifier of the NFS client matches the identifier of the NFS client when a first lock request carrying a reclaim identifier is received from the NFS client. The fault recovery unit is configured to send the first lock request to the TFS for recovery if the identifier of the NFS client matches the identifier of the NFS client, and decrement the lock count value by one; until the lock count value is zero, the fault recovery process is completed.

9. An NFS server, the NFS server comprising: Processor and memory; When the processor executes the running program stored in the memory, it implements the method as described in any one of claims 1-7.

10. A storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of claims 1-7.

Images