CN117997939B

CN117997939B - Method, device and system for monitoring state of NFS client

Info

Publication number: CN117997939B
Application number: CN202410394230.4A
Authority: CN
Inventors: 张国华; 郭家勇; 胡磊; 李庆节; 崔潜; 王鹏; 唐伟
Original assignee: Hunan Guoke Yicun Information Technology Co ltd
Current assignee: Hunan Guoke Yicun Information Technology Co ltd
Filing date: 2024-04-02
Publication date: 2024-07-02
Anticipated expiration: 2044-04-02

Abstract

The invention provides a method, a device and a system for monitoring the state of an NFS client, wherein the method comprises the following steps: defining that the client side is in an active state for performing file or directory operation on the file system, and the client side is not in an inactive state for performing file or directory operation on the file system within a specified time period, wherein errors are in an error state when the client side is in file or directory operation on the file system, and the state that the client side is not received in a request within a preset lease time is in a disconnection state; when the server receives a client request, acquiring the client and corresponding file system information; and in the process of executing the client request by the server, acquiring the state of whether the request is successfully executed or not and the active type of the request, recording the states of the current client and the corresponding file system, and updating the states into the corresponding state database. The invention can realize accurate monitoring of the connection state of the client and the NFS server, and avoid the problems of service interruption, data loss and the like caused by directly closing the NFS shared file system.

Description

Method, device and system for monitoring state of NFS client

Technical Field

The present invention relates to the field of information sharing technologies, and in particular, to a method, an apparatus, and a system for monitoring an NFS client state.

Background

NFS (network file system) is a system that implements shared data between different computers in a network environment, and an NFS client can access shared files mounted on a local NFS server like files in a local hard disk. In the current NFS system, only the problems that whether the number of clients actually linked by the NFS server is smaller than the number of clients theoretically linked, the number of clients connected by the server and bandwidth allocation are unreasonable are usually focused, and whether the clients are connected with the NFS service or using the file system cannot be accurately known, and whether the clients temporarily do not use the NFS service or are in a downtime state cannot be determined. When the NFS system is maintained or upgraded, an administrator of the NFS storage system needs to close the NFS shared file system first, and then perform related operations on the NFS system. If the NFS shared file system is directly closed, the connected client and the read-write NFS client can be blocked, service is interrupted and the like, and further data is lost and the like.

In the prior art, monitoring of equipment or service information is usually achieved by regularly acquiring certain state information of the equipment or service, and a state value of a monitored party can be directly acquired, wherein the acquiring mode can be that the monitored party actively inquires the state information of the monitored party or the monitored party actively reports the state information to the monitoring party. But this requires the monitored party to have the ability to acquire status values and communicate with the monitoring party. If the client is considered to monitor the state of a client connected with an NFS service or using a file system by adopting a traditional monitoring information manner, the NFS client needs to have a function of acquiring a state or generating a state value, and an interface for actively reporting or passively acquiring is provided to realize the acquisition of the state information of the NFS client, that is, the NFS client needs to be modified, which affects the normal operation of the NFS client, so that the general NFS client becomes a special NFS client. In an actual use environment, there are various different clients that use NFS services, and the conventional monitoring manner greatly affects the user experience of the client.

Disclosure of Invention

The technical problem to be solved by the invention is as follows: aiming at the technical problems in the prior art, the invention provides a method, a device and a system for monitoring the state of an NFS client with simple structure and wide applicability, so as to realize maintenance and management of an NFS storage system, accurately monitor the connection state of the client and an NFS server, determine whether to close an NFS shared file system by using the monitoring state, and effectively avoid the problems of service interruption, data loss and the like caused by directly closing the NFS shared file system.

In order to solve the technical problems, the technical scheme provided by the invention is as follows:

a method of monitoring NFS client status, comprising:

Defining that the client side is in an active state for performing file or directory operation on the file system, the client side is not in an inactive state for performing file or directory operation on the file system within a specified time period, and the client side is in an error state when performing file or directory operation on the file system and is in a disconnection state when not receiving a request client side within a preset lease time;

when the server receives a client request, acquiring information of the client and a corresponding file system;

And in the process of executing the request of the client by the server, acquiring the state of whether the request is successfully executed and the active type of the request, recording the states of the current client and the corresponding file system, updating the states into the corresponding state database, wherein if the request is executed in error, the state is correspondingly updated into an error state, if the file or the directory operation of the file system is being carried out by the client in the process of executing the request by the server, the state is correspondingly updated into an active state, if the file or the directory operation of the file system is not carried out by the client in the appointed duration, the state is correspondingly updated into an inactive state, and if the state of the request client is not received by the server in the preset lease time, the state corresponding to the updated client is an off state.

Further, the method further comprises the step of defining the state that the server side does not receive the request client side in the preset lease time as a disconnection state, and updating the state corresponding to the client side as the disconnection state if the state that the server side does not receive the request client side in the preset lease time is judged.

Further, the client requests include active requests and inactive requests, the active requests including any request other than an offload request and a single request; the inactive request comprises a single request for SEQUENCE;

When a server receives a client request, if the client request is a request except mounting and unloading, judging whether the request is successfully executed, if so, updating the corresponding client state according to the active type of the client request, otherwise, updating the client states corresponding to the client IP and the file system name into an error state;

If the client request is a mounting request, a new active state record of the client is inserted into a database;

And if the client request is an unloading request, deleting the state record corresponding to the IP and the file system name of the client.

Further, the updating the corresponding client state according to the active type of the client request includes:

when the client request is an inactive request, maintaining an inactive state record corresponding to the current client IP;

And when the client request is an active request, checking whether records corresponding to the current client IP and the file system name exist in the client active state cache, if so, skipping the current request, and otherwise, updating the client active state record.

Further, the method further comprises the step of grading each state in advance, and the step of carrying out degradation update on each state recorded in the state database according to the state type and the update trend in the appointed time period periodically, so that if the target state is unchanged in the appointed time period, the target state is reduced to the state of the appointed grade.

Further, each state is sequentially configured into an active state, an inactive state, a disconnected state and an error state according to the level, and the step of periodically performing degradation update on each state recorded in the state database according to the state type and the update trend within a specified duration comprises the following steps:

if the target state in the state database is an active state and the time interval between the last updating time of the target state and the current time exceeds the preset lease time, updating the target state in the database into an inactive state;

And if the target state in the state database is an inactive state and the time interval between the last updating time of the target state and the current time exceeds the preset lease time, updating the target state in the database into a disconnected state.

Further, the method also comprises the steps of identifying the request of client side mounting and the file system needing mounting, and the steps comprise:

the server side associates and stores file handles of export catalogues of the file system and corresponding file system names;

when receiving a session request, the server acquires and stores the IP and the session_id of the corresponding client, and uses the session_id as a unique identifier to set a corresponding state value for indicating that the corresponding client is being mounted and recording the current time stamp;

when the server receives the search request, judging whether a state value corresponding to the session_id is in the mounting of the client, if not, ending the current flow; otherwise, judging whether the obtained directory file handle is consistent with the file handle of the export directory of the file system, if not, ending the process, if so, judging that the client is mounted, obtaining the corresponding file system name through the file handle of the directory, inserting the client state record in the active state, storing the client IP and the file system name in an associated mode, and setting the state value corresponding to the session_id as the mounted state of the client.

Further, when the NFS shared file system needs to be closed, judging whether to close the current NFS shared file system according to the state of the NFS client recorded in the state database, wherein the steps include:

Judging whether the current received request is a forced closing request, if so, directly closing the NFS shared file system;

If the currently received request is not a forced closing request, acquiring all file system names and corresponding client state records of a server side, judging the type of required operation, if the operation belongs to the operation of closing the NFS shared file system, controlling to close the NFS shared file system according to whether an active state or an inactive state of the client side exists, wherein if the active state or the inactive state of the client side exists, closing the NFS shared file system is prevented, otherwise, directly closing the NFS shared file system; if the operation belongs to the restarting service, controlling to restart the NFS shared file system according to whether the client in the active state exists, wherein if the client in the active state exists, the NFS shared file system is prevented from being restarted, otherwise, the NFS shared file system is directly restarted.

Further, the step of determining whether to close the current NFS shared file system according to the NFS client state recorded in the state database, and if the current NFS shared file system is allowed to close or restart in the background, creating a background checking task and adding the background checking task into a background task queue, where the step of processing the background task in the background task queue includes:

judging whether a background task queue is empty, and entering a sleep waiting state if the background task queue is empty:

if the background task queue is not empty, acquiring a background task and judging the type of the task;

If the background task is judged to belong to the operation of closing the NFS shared file system, judging whether an active state or an inactive state client exists, if the active state or the inactive state client exists, re-creating the background closed NFS shared file system task, adding the background closed NFS shared file system task into a background task queue, and otherwise, directly closing the NFS shared file system;

If the background task is judged to belong to the operation of restarting the NFS shared file system, judging whether an active client exists, if the active client exists, recreating the background task of restarting the NFS shared file system, and adding the background task into a background task queue, otherwise, directly restarting the NFS shared file system.

An apparatus for monitoring NFS client status, comprising:

the state definition module is used for defining that the file system is subjected to file or directory operation by the client as an active state, the file system is not subjected to file or directory operation by the client as an inactive state within a specified duration, and an error is an error state when the file system is subjected to file or directory operation by the client;

the information acquisition module acquires information of the client and a corresponding file system when the server receives a client request;

The state recording module is used for acquiring the state of whether the request is successfully executed or not and the active type of the request in the process of executing the request of the client by the server, recording the states of the current client and the corresponding file system, updating the states into the corresponding state database, wherein the states are correspondingly updated into error states if the request is executed in error, the states are correspondingly updated into active states if the file system is subjected to file or directory operation by the client in the process of executing the request by the server, and the states are correspondingly updated into inactive states if the file system is not subjected to file or directory operation by the client in the appointed duration.

The NFS system comprises a server, a client and a file system, and further comprises a processor and a memory, wherein the memory is used for storing a computer program, and the processor is used for executing the computer program to execute the method in the process of executing a client request by the server.

Compared with the prior art, the invention has the advantages that:

1. The invention defines the state of the client according to the state of the client for carrying out file or directory operation on the file system, acquires the state of whether the client is successfully executed or not and the active type of the request in the process of executing the request of the client by the server, records the states of the current client and the corresponding file system, and updates the states into the corresponding state database. The server can accurately know the condition that the client is connected with the NFS server and the state that the client uses the file system, the condition that the connected client and the read-write NFS client are blocked and the service is interrupted due to the fact that the NFS shared file system is directly closed can be effectively avoided, the consequences of data loss and the like are effectively avoided, and the use experience of a user is improved.

2. The invention is helpful for finding and solving the potential problems of the system by monitoring the operation state of the client in real time, reduces the failure rate of the system and provides the stability of the system. In addition, when the execution request is wrong, the corresponding update state database is in an error state, so that an NFS system administrator can quickly locate the problem, and the problem solving efficiency is effectively improved.

3. The invention further compares the time interval between the last updated time of the target state and the current time with the preset lease time, and when the time interval between the last updated time of the target state and the current time exceeds the preset lease time, the current state of the client is degraded through the degradation strategy, so that whether the state of the client is temporarily unused NFS service or is down is accurately known, server resources are reasonably allocated, and the running efficiency of the whole system is improved.

Drawings

FIG. 1 is a flow chart of a method for monitoring NFS client status in accordance with an embodiment of the present invention.

FIG. 2 is a flow chart of a method for monitoring the status of an NFS client in an embodiment of the invention.

Fig. 3 is a flowchart of a service end degradation check and degradation operation according to an embodiment of the present invention.

Fig. 4 is a schematic diagram of an update and degradation operation and state transition of a client state by a server according to an embodiment of the present invention.

FIG. 5 is a schematic diagram of the device components for monitoring the status of NFS clients according to an embodiment of the present invention.

FIG. 6 is a flowchart illustrating an embodiment of determining whether to stop NFS shared file systems according to NFS client status.

FIG. 7 is a flowchart illustrating a background task process according to an embodiment of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

An administrator of the NFS storage system needs to perform maintenance management on the entire NFS storage system, including an operation to close the NFS shared file system. When the NFS shared file system needs to be closed, if the NFS shared file system is directly closed, if a client side is performing file or directory operation on the file system at the moment, the connected client side and the read-write NFS client side can be blocked and have service interruption, so that data loss is caused, user experience is affected, and other results are caused. If an administrator can confirm whether a client is connected with the NFS service or is using the file system when closing the NFS shared file system, and then decide whether to close the NFS shared file system, the problems of service interruption, data loss and the like caused by directly closing the NFS shared file system can be effectively avoided. In order to realize that before closing the NFS shared file system, whether a client is connected with the NFS service or the file system is being used is confirmed, the file system of the server, the client IP and the client request are distinguished, corresponding states are obtained and saved for external application to obtain, the control of closing the NFS shared file system can be carried out by utilizing the monitoring information, and when the NFS shared file system needs to be closed, whether the current NFS shared file system can be directly closed can be accurately judged according to the states recorded in the state database.

As shown in fig. 1, the steps of the method for monitoring the state of the NFS client according to the present embodiment include:

Step 1, defining that a client performs file or directory operation on a file system as an active state, defining that the client does not perform file or directory operation on the file system as an inactive state within a specified duration, and defining that an error is an error state when the client performs file or directory operation on the file system.

According to the embodiment, firstly, the active state/inactive state of the client is defined according to whether the client is performing file or directory operation on the file system, meanwhile, the error state is defined when the client makes errors when the client is performing file or directory operation on the file system, and then the judgment and recording of the active state, the inactive state and the error state of the client are correspondingly performed when the client request is executed.

Preferably, the embodiment further includes defining a state that the server side does not receive the request client side in the preset lease time as an off state, and if it is determined that the server side does not receive the request client side in the preset lease time, updating the state corresponding to the client side as the off state.

In a specific application embodiment, the defined client states are respectively:

1) Active state: the client is doing file or directory operations on the file system. The server receives any request except the unloading request and the single request, and defines the client state as active state.

2) Inactive state: the client does not perform any file or directory operations on the file system for a period of time. The server side does not receive any active request within a specified duration, but receives a single SEQUENCE request, and defines the state of the client side as an inactive state. The request is not a SEQUENCEN request from the database, but a request containing only the request from the client.

3) Off state: and if the server side does not receive any request within the preset lease time, the client side is defined to enter a disconnection state.

4) Error status: and when the client makes errors when the file system is in file or directory operation and the server executes an active request, defining that the client enters an error state.

And 2, when the server receives the client request, acquiring information of the client and a corresponding file system.

In this embodiment, the client request includes an active request and an inactive request, where the active request may be any request other than an offload request and a single request, and the inactive request is a single request, and the specific division of the request types may be configured according to actual requirements.

In this embodiment, the server uses the state database table to store the state information of the client, and the external application obtains the state information of the client by querying the state database table, where the state information of the client is composed of a file system name mounted on the client, a client IP, a last update time of the state, and a client state type, and other more types of information are added according to actual requirements.

And step 3, acquiring a state of whether the request is successfully executed and an active type of the request in the process of executing the request of the client by the server, recording the states of the current client and the corresponding file system, and updating the states into the corresponding state database, wherein the states are correspondingly updated into error states if the request is executed in error, the states are correspondingly updated into active states if the file system is subjected to file or directory operation by the client in the process of executing the request by the server, and the states are correspondingly updated into inactive states if the file system is not subjected to file or directory operation by the client in the appointed duration.

In the embodiment, when a server receives a client request, the type of the client request is judged; if the client request is a request except mounting and unloading, judging whether the execution is successful, if the execution is successful, updating the corresponding client state according to the active type of the client request, otherwise, updating the client states corresponding to the client IP and the file system name into error states; if the client request is a mounting request, inserting a new active state record of the client into the database; and if the client request is an uninstall request, deleting the state record corresponding to the IP and the file system name of the client.

If the client request is a mount request, when a new active state record of the client is inserted into the database, detecting whether records of the corresponding client IP and file system names already exist in the state record database before the new active state record of the client is inserted, if so, deleting the records of the corresponding client IP and file system names, and then inserting.

In this embodiment, updating the corresponding client state according to the active type of the client request includes:

When the client request is an active request, checking whether records corresponding to the current client IP and the file system name exist in the client active state cache, if so, skipping the current request, and otherwise, updating the client active state record.

As shown in fig. 2, in a specific application embodiment, the detailed steps after the server receives the client request include:

Step 301, if the client request is a mount request, inserting a new active state record of the client into the state database, detecting whether records of the corresponding client IP and file system names already exist in the state record database before inserting the new active state record of the client, if so, deleting the records of the corresponding client IP and file system names, and then inserting;

step 302, if the client request is an uninstall request, deleting the state records corresponding to the client IP and the file system name;

Step 303, if the client request is other types of requests, waiting for the completion of the request execution, and judging whether the execution is successful or not;

if the execution fails, updating the client states corresponding to the corresponding client IP and file system names into error states; if the execution is successful, judging whether the active type of the client request is an active request or not;

Step 304, if the active type of the client request is an inactive request, maintaining an inactive state record corresponding to the client IP; if the active type of the client request is an active request, checking whether a record corresponding to the active request IP and the file system name exists in an active state cache of the client;

Step 305. If there is a record corresponding to the active state request IP and the file system name of the client, i.e. it is already in the active state cache of the client, skipping the active request; if the record corresponding to the file system name and the IP is requested by the active state of the client, the active state record of the client is updated and cached if the record is not cached in the active state cache of the client.

In the NFS4 protocol, the client mount is completed by multiple requests, where the server can confirm that the client is connected to the server through the request type, and can obtain the IP of the client through the network socket, but since the mount request of the client is not represented by a specific request type when the file system is mounted, the file handle of the directory to be finally mounted is obtained through multiple LOOKUP requests from the root directory, and the file handle of the directory to be finally accessed is obtained through multiple LOOKUP requests, the server cannot directly determine whether the request belongs to the request of the client mount through the request type, and cannot directly obtain the name of the file system to be mounted by the client. The embodiment further identifies, from the server, a request for client mount and a file system name to be mounted without modifying the client, and specifically includes the steps of:

When the server receives the search request, judging whether a state value corresponding to the session_id is in the mounting of the client, if not, ending the current flow; if not, ending the process, if yes, judging that the client is mounted, acquiring the corresponding file system name through the file handle of the directory, inserting the client state record in an active state, storing the client IP and the file system name in an associated mode, and setting a state value corresponding to the session_id as the mounted client.

Further, if the state value corresponding to the session_id in the specified time is always in the process that the client is being mounted, setting the state value corresponding to the session_id as the mounting timeout after the specified time is exceeded.

Further, the method comprises the steps of identifying a client unloading request and a file system name to be unloaded from a server, and when the server receives the client unloading request, acquiring a client IP and a corresponding file system name according to session_id and deleting a state record corresponding to the client.

In a specific application embodiment, the specific steps of identifying, from the server, a request for client mount/dismount and a file system name to mount/dismount without modifying the client are:

1) The server side associates and stores file handles of export catalogues of the file system and corresponding file system names;

2) The server acquires and saves the IP and session_id (SESSION number) of the client when receiving the create_session creation SESSION request. And setting a state value corresponding to the session_id by using the session_id as a unique identifier, wherein the state value is used for indicating that the client is in mounting, and recording the current timestamp.

3) If the server receives the LOOKUP request, judging whether the state value corresponding to the session_id is in the state that the client is in the mounting process, and if the client is not in the state in the mounting process, ending the current flow.

4) If the client is in mounting, judging whether the acquired directory file handle is consistent with the file handle of the export directory of the file system, if not, ending the current flow; if the file names are consistent, the client is considered to be mounted, the corresponding file system names are obtained through file handles of the catalogues, the client state records in the active state are inserted, the client IP and the file system names are stored in an associated mode, and finally the state value corresponding to the session_id is set to be mounted.

5) If the state value corresponding to the session_id in the specified time is always in the process that the client is being mounted, setting the state value corresponding to the session_id as the mounting timeout after the specified time is exceeded.

6) When the server receives the destreoysession deletion SESSION request, the client is considered to initiate an unloading request, the client IP and the corresponding file system name are acquired according to the session_id, and the state record corresponding to the client is deleted.

The embodiment further includes a step 4 of grading each state in advance, and periodically performing degradation update on each state recorded in the state data according to the state type and the update trend in the specified duration, so that if the state in which the target state is not changed exists in the specified duration, the state is reduced to the state of the specified grade.

As shown in fig. 4, the operations of updating and degrading the client state by the server are defined as:

Degradation: the last update time of the state within the lease time is not updated, the state is changed from a high level to a low level step by step, the degradation operation is the lowest and can only be changed into disconnection, and the error state can not be completed by degradation;

updating: changing the state and changing the last update time of the state to the current time.

In this embodiment, the operation of the server to the client state further includes:

Maintaining: the state is not changed, and only the last update time of the state is changed into the current time;

deletion: deleting a file system name and a client state record corresponding to the client IP;

Insertion: and adding a file system name, a client IP and a record of the active state, and setting the last update time of the state as the current time.

In this embodiment, the steps 4 of configuring the active state, the inactive state, the off state and the error state in order according to the level in advance, and reducing the state unchanged in the specified period to the state lower by the specified level include:

Step 401, if the target state in the state database is an active state and the time interval between the last update time of the target state and the current time exceeds the preset lease time, updating the target state in the database to an inactive state;

step 402, if the target state in the state database is inactive, and the time interval between the last update time of the target state and the current time exceeds the preset lease time, the target state in the database is updated to be in an off state.

It can be understood that the specific degradation policy may be adjusted according to the actual requirement, for example, configured to directly reduce the designated number of levels when it is determined that the degradation condition is satisfied, or configured to configure the corresponding degradation policy for each level according to the priority of the state, and specifically configured according to the actual requirement.

As shown in fig. 3, in a specific application embodiment, the server performs the degradation check and the degradation operation by starting another thread, which specifically includes the following steps:

1) The degradation checking thread updates the state in the active state cache of the client to the database, and empties the active state cache;

2) The database is in an active state, and the record that the interval between the last updating time and the current time exceeds the lease time is updated to be in an inactive state;

3) The database is in an inactive state, and the record of the interval between the last updating time and the current time exceeding the lease time is updated to be in a disconnected state;

4) Waiting for lease time of a specified proportion;

5) Judging whether the degradation check is set to be finished, if not, continuing to jump to the step 1), and if so, ending the degradation check thread.

According to the method and the device, the state of the NFS client is checked when the NFS shared file system is closed, whether the current NFS service can be closed or not is determined according to the state of the NFS client, the problems of service interruption, data loss and the like caused by directly closing the NFS shared file system can be effectively avoided, and user experience is improved.

In this embodiment, whether to close the current NFS shared file system is determined according to the NFS client state recorded in the state database, and the steps include:

As shown in fig. 6, in a specific application embodiment, the detailed steps for determining whether to close the NFS shared file system according to the state of the NFS client are as follows:

1) The administrator restarts or shuts down the service;

2) The management system judges whether the request is a request of forced closing, if the request is the forced closing, the NFS shared file system is directly closed, and if the request is not the forced closing, the following steps are carried out;

3) Acquiring all file system names and corresponding client state records of a server;

4) Judging whether the operation type belongs to restarting the NFS shared file system or closing the NFS shared file system;

5) If the operation belongs to the operation of closing the NFS shared file system, judging whether an active state or an inactive state client exists, if the active state or the inactive state client exists, stopping closing the NFS shared file system, otherwise, directly closing the NFS shared file system, and ending the flow;

6) If the operation belongs to the restarting service, judging whether an active client exists, if so, stopping restarting the NFS shared file system, otherwise, directly restarting the NFS shared file system, and ending the flow;

7) And judging whether the background is allowed to close or restart the NFS shared file system, and if not, skipping the current step. If the NFS shared file system is allowed to be closed or restarted in the background, a background checking task is created and added into a background task queue;

8) And returning the IP of the client, prompting an administrator that the client is in an active state, and suggesting to close or restart the NFS shared file system after stopping the use of the client.

In this embodiment, whether to close the current NFS shared file system is determined according to the NFS client state recorded in the state database, and if the current NFS shared file system is allowed to be closed or restarted, a background check task is created and added to a background task queue, and the processing steps for the background task in the background task queue include:

As shown in fig. 7, the detailed steps of the background task processing in the specific application embodiment are as follows:

1) Starting a background task processing thread;

2) Waiting for a specified duration;

3) Judging whether a background task queue is empty, and if so, entering a sleep waiting state: if not, acquiring a background task;

4) Judging the type of the task, wherein the task belongs to restarting the NFS shared file system and closing the NFS shared file system;

5) If the operation belongs to the operation of closing the NFS shared file system, judging whether an active state or an inactive state client exists, if the active state or the inactive state client exists, re-creating a background closed NFS shared file system task, adding the background closed NFS shared file system task into a background task queue, otherwise, directly closing the NFS shared file system, and returning an execution result;

6) If the operation belongs to the operation of restarting the NFS shared file system, judging whether an active client exists, if the active client exists, recreating a background task for restarting the NFS shared file system, adding the background task into a background task queue, otherwise, directly restarting the NFS shared file system, and returning an execution result;

7) Judging whether the background task processing thread needs to be ended or not, and if so, ending the thread; if not, re-enter step 2).

The embodiment also provides an apparatus for monitoring the state of an NFS client, including:

In this embodiment, the system further includes a state update module, configured to periodically update, in a demotion manner, each state recorded in the state database according to a state type and an update trend within a specified duration, so that if the target state does not change within the specified duration, the target state is reduced to a state of a specified level.

In this embodiment, the state update module specifically checks whether all client state information satisfies a degradation condition according to lease time, and if so, degrades the corresponding client state.

In this embodiment, the system further includes a closing control module, configured to determine, according to a state recorded in the state database, whether the current NFS shared file system can be closed currently when the NFS shared file system needs to be closed.

As shown in fig. 5, the information acquisition module of this embodiment specifically includes:

The state acquisition unit is used for acquiring different client states, client IP and file system names according to the request of the client;

the state caching unit is used for filtering repeated state updating requests and caching the state of the client;

And the state storage unit is used for connecting the database and providing interfaces for inquiring, updating, inserting, deleting and the like of the state information.

The embodiment also provides an NFS system, which includes a server, a client, a file system, and a processor and a memory, where the memory is configured to store a computer program, and the processor is configured to execute the computer program to execute the method in a process of executing a client request by the server.

It will be understood that the method in this embodiment may be performed by a single device, for example, a computer or a server, or may be implemented by a plurality of devices in a distributed scenario, where one device of the plurality of devices may perform only one or more steps in the method in this embodiment, and the plurality of devices interact to implement the method. The processor may be implemented as a general-purpose CPU, a microprocessor, an application-specific integrated circuit, or one or more integrated circuits, etc. for executing the relevant program to implement the methods described in this embodiment. The memory may be implemented in the form of read-only memory ROM, random access memory RAM, static storage devices, dynamic storage devices, etc. The memory may store an operating system and other application programs, and when the methods of the present embodiments are implemented in software or firmware, the associated program code is stored in the memory and invoked for execution by the processor.

It will be appreciated by those skilled in the art that the above-described embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein. The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. The foregoing is merely a preferred embodiment of the present application and is not intended to limit the present application in any way. While the application has been described with reference to preferred embodiments, it is not intended to be limiting. Therefore, any simple modification, equivalent variation and modification of the above embodiments according to the technical substance of the present application shall fall within the scope of the technical solution of the present application.

The foregoing is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. While the invention has been described with reference to preferred embodiments, it is not intended to be limiting. Therefore, any simple modification, equivalent variation and modification of the above embodiments according to the technical substance of the present invention shall fall within the scope of the technical solution of the present invention.

Claims

1. A method of monitoring NFS client status, comprising:

Defining that the client side is in an active state for performing file or directory operation on the file system, the client side is not in an inactive state for performing file or directory operation on the file system within a specified time period, the client side is in an error state when performing file or directory operation on the file system, and the state of not receiving a request client side within a preset lease time is in a disconnection state;

in the process of executing the request of the client by the server, acquiring the state of whether the request is successfully executed and the active type of the request, recording the states of the current client and the corresponding file system, updating the states into the corresponding state database, wherein if the request is executed in error, the state is correspondingly updated into an error state, if the file system is being subjected to file or directory operation by the client in the process of executing the request by the server, the state is correspondingly updated into an active state, if the file system is not subjected to file or directory operation by the client in a specified duration, the state is correspondingly updated into an inactive state, and if the state of the request client is not received by the server in preset lease time, the state corresponding to the updated client is an off state;

if the client request is an unloading request, deleting the state records corresponding to the IP and the file system name of the client;

the updating the corresponding client state according to the active type of the client request comprises the following steps:

The client requests include active requests and inactive requests, the active requests including any request other than an offload request and a single request; the inactive request comprises a single request for SEQUENCE;

2. The method of monitoring NFS client status according to claim 1, further comprising pre-ranking each status, periodically downgrading each status recorded in the status database according to status type and update trend over a specified period of time such that if there is no change in the target status over the specified period of time, the target status is reduced to a specified ranked status.

3. The method of monitoring NFS client status according to claim 2, wherein each status is configured as an active status, an inactive status, a disconnected status, and an error status in order of level, the step of periodically downgrading each status recorded in the status database according to status type and update trend over a specified period of time comprises:

4. The method of monitoring NFS client status of any of claims 1-3, further comprising identifying a request for client mount and a file system that needs to be mounted, the steps comprising:

5. The method for monitoring NFS client status according to any one of claims 1 to 3, further comprising determining whether to currently close the current NFS shared file system according to the NFS client status recorded in the status database when the NFS shared file system needs to be closed, the step comprising:

6. The method for monitoring the state of NFS clients according to claim 5, wherein the step of determining whether to close the current NFS shared file system based on the state of the NFS clients recorded in the state database, and if the NFS shared file system is allowed to be closed or restarted in the background, creating a background check task and adding the background check task to a background task queue, the step of processing the background task in the background task queue comprises:

7. An apparatus for monitoring the status of an NFS client, comprising:

the state recording module is used for acquiring the state of whether the request is successfully executed or not and the active type of the request in the process of executing the request of the client by the server, recording the states of the current client and the corresponding file system, and updating the states into the corresponding state database, wherein the states are correspondingly updated into error states if the request is executed in error, the states are correspondingly updated into active states if the file system is subjected to file or directory operation by the client in the process of executing the request by the server, and the states are correspondingly updated into inactive states if the file system is not subjected to file or directory operation by the client in the appointed duration;

8. NFS system comprising a server, a client and a file system, and further comprising a processor and a memory, the memory being configured to store a computer program, wherein the processor is configured to execute the computer program to perform the method according to any of claims 1-6 during execution of a client request by the server.