NFS service end working state detection method, system, device and medium

Abstract

The application discloses an NFS server working state detection method, system, device and medium, and belongs to the field of information technology, and aims to solve the technical problem of how to directly detect the working state of the server on the node where the NFS server is located, eliminate the influence of the client and the network, and shorten the fault time, and the technical scheme is that: based on NFS-Ganesha, NFS services are provided externally, the source code and the configuration file of NFS-Ganesha are modified, the support for the back end of the CephFS distributed storage system is realized, and the access permission of the local loopback address is released; the ganesha_stats tool is used to regularly collect the runtime statistical information of the NFS-Ganesha service; the change of the operation count is analyzed, if there is no change in the predetermined detection period, the shared directory exported by the local loopback address is tested, and a timeout limit is set; if the mounting test fails, it is determined that the working state of the NFS server is abnormal, and the graceful restart of the NFS-Ganesha service is automatically performed.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to a method, system, equipment and medium for detecting the working status of an NFS server. Background Art

[0002] The Network File System (NFS) is a widely used network file sharing protocol that allows different computers to share resources over a network as if those files were stored on local disks. NFS operates based on a client-server model. In this model, one or more servers share their file system resources, and clients can mount these remote file systems and read and write to them as if they were local files. The rapid development of information technology, especially the rise of cloud computing and big data, has placed higher demands on NFS, including but not limited to dynamic scalability, cross-platform compatibility, and seamless integration with emerging storage technologies.

[0003] NFS-Ganesha was developed as a high-performance user-mode Network File System (NFS) server. Unlike traditional kernel-mode NFS implementations, NFS-Ganesha runs in user space and provides a modular plug-in architecture, allowing users to easily add or replace storage backends (such as Ceph, GlusterFS, and iSCSI) as needed. Due to its ease of use, flexibility, and support for enterprise-grade features such as high availability and security, NFS-Ganesha has become a key choice for network file sharing in modern data centers and cloud environments.

[0004] In real-world scenarios, a client might experience excessively high load, causing the NFS server to respond slowly or stop responding, meaning it cannot process requests properly, leading to low reliability for the network file system. Currently, the conventional method for detecting the working status of a network file system server is to test the server by having the client write a file to the mounted shared directory. If the file is written successfully, the server is considered to be operating normally and can process requests normally. Otherwise, the server is considered to be operating abnormally and cannot process requests normally. However, when using this method to detect the server, it is impossible to determine whether the failure in the file write occurred due to a fault in the client, the server, or the network. Further testing is required to determine the cause of the failure.

[0005] Therefore, how to directly detect the working status of the NFS server on the node where the server is located, eliminate the influence of the client and network, and shorten the failure time is a technical problem that needs to be solved urgently. Summary of the Invention

[0006] The technical task of the present invention is to provide an NFS server working status detection method, system, device and medium to solve the problem of how to directly detect the working status of the server on the node where the NFS server is located, eliminate the influence of the client and network, and shorten the failure time.

[0007] The technical task of the present invention is achieved in the following manner: a method for detecting the working status of an NFS server, the method being as follows:

[0008] Based on NFS-Ganesha, NFS services are provided to the outside world. By modifying the NFS-Ganesha source code and configuration files, support for the CephFS distributed storage system backend is implemented. Access is allowed from clients on the local loopback address 127.0.0.1, and access rights to the local loopback address are released.

[0009] Use the ganesha_stats tool to regularly collect runtime statistics of the NFS-Ganesha service. The runtime statistics include the mount status and operation counts of all exported NFS protocols on the NFS-Ganesha server.

[0010] Analyze changes in operation counts. If there are no changes within the predetermined detection period, test the local loopback address to mount the exported shared directory and set a timeout limit.

[0011] If the mount test fails, the NFS server is considered to be in an abnormal working state, and a graceful restart of the NFS-Ganesha service is automatically performed to restore normal service operation.

[0012] As a preferred embodiment, providing NFS services externally based on NFS-Ganesha specifically includes: using the CephFS file system provided by the distributed storage system Ceph as a storage backend through NFS-Ganesha to provide NFS services externally.

[0013] Better yet, when compiling the NFS-Ganesha source code, add the -DUSE_FSAL_CEPH=ON and -DUSE_RADOS_RECOV=ON options, and when creating an export, specify the FSAL type in the configuration as Ceph, to support the CephFS file system abstraction layer and RADOS recovery.

[0014] At the same time, when compiling the NFS-Ganesha source code, add the -DUSE_ADMIN_TOOLS=ON option to use the state management tool that comes with NFS-Ganesha.

[0015] Preferably, the export permission settings of NFS-Ganesha are as follows:

[0016] When setting export permission options, NFS-Ganesha follows the following order to determine the final configuration that takes effect: CLIENT{} represents the most specific level of configuration, defining permissions for a specified list of clients, building an ordered "access control list" to manage access rights to exported resources; if any permission options are specified here, the corresponding options will take precedence over settings at other levels; EXPORT{}: The next level of configuration, defining the general permission settings for the entire exported share; EXPORT_DEFAULTS{}: Sets the global default permissions;

[0017] When a client attempts to access an exported resource, NFS-Ganesha checks the associated CLIENT blocks in turn, looking for a matching client entry. If a match is found, the permissions defined in the corresponding client block are applied. If no client entry is matched, the permissions set in the corresponding EXPORT block are used. If any permissions are not explicitly set in either the CLIENT or EXPORT blocks, the permissions set in the EXPORT_DEFAULTS block are used, and the default is the permission value built into the code.

[0018] Preferably, a global default permission is set in the NFS-Ganesha configuration file ganesha.conf, that is, the client with IP address 127.0.0.1 is allowed to perform read and write operations. The specific configuration is EXPORT_DEFAULTS{CLIENT{Clients=127.0.0.1 / 32; Access_Type=RW;}};

[0019] At the same time, modify the export process of checking client permissions in the NFS-Ganesha source code.

[0020] Better yet, modify the export process in the NFS-Ganesha source code to check client permissions as follows:

[0021] (1) When a client accesses any export entry, NFS-Ganesha determines whether the client list in the CLIENT block of the current export configuration EXPORT block is empty:

[0022] ①If it is not empty, execute step (2);

[0023] ②If it is empty, jump to step (3);

[0024] (2) Determine whether there is a matching client entry:

[0025] ① If no client entry is assigned, proceed to step (3);

[0026] ②If there is a matching client entry, jump to step (4);

[0027] (3) Match the client list in the CLIENT block in the EXPORT_DEFAULTS block;

[0028] (4) Client matching is completed.

[0029] As a preferred option, ganesha_stats is a tool for collecting and viewing runtime statistics and status of the NFS-Ganesha service. It provides real-time data on NFS-Ganesha service performance, resource usage, and operation counts, and supports JSON format output, enabling monitoring and analysis of NFS-Ganesha health, performance tuning, and troubleshooting.

[0030] Write a status detection script to parse JSON data and regularly obtain and analyze the working status of the NFS-Ganesha service. The NFS server working status detection process is as follows:

[0031] Use the ganesha_stats json export command to obtain statistics about all exports on the NFS-Ganesha server. This statistics includes each export's unique identifier, shared directory, and the usage status of the NFSv3, NFSv4.0, NFSv4.1, and NFSv4.2 protocols. The NFS protocol usage status of each export indicates whether a client has mounted the exported shared directory using the corresponding protocol. The value is 0 or 1. 0 indicates no client has mounted the shared directory using the corresponding NFS protocol version, and 1 indicates a client has mounted the shared directory using the corresponding NFS protocol version. The number of clients must be at least one.

[0032] Traverse all obtained exports and exclude virtual root directories and exports without client mounts. Specifically, exclude exports with an identifier of 0 and exports with a cumulative NFS protocol usage status of 0 (i.e., exports without client mounts). This reduces the time and workload of status detection.

[0033] Use the ganesha_stats json total id command to obtain the operation counts of different versions of the NFS protocol for the current export. The operation count is the total number of client requests to mount the export using the corresponding version of the NFS protocol processed by the NFS-Ganesha server.

[0034] Determine whether the operation counts of all versions of the currently exported NFS protocol have changed within the set detection time:

[0035] If all the data remains unchanged, excluding network, configuration, permission, and statistics tool issues, it means that all currently exported clients have no active requests, or the NFS server is in an abnormal working state and cannot process requests normally.

[0036] By locally mounting the currently exported shared directory on the server node, the working status of the NFS server can be directly detected. The mount operation specifies that the IP address of the NFS service is the local loopback address 127.0.0.1 and sets the mount operation timeout:

[0037] If all mounts fail within the set number of tests, the NFS server is considered to be in an abnormal working state and cannot process requests normally.

[0038] To restore services as quickly as possible and improve the overall reliability of the network file system, the NFS-Ganesha service is automatically and gracefully restarted to shorten business congestion time and NFS server failure time.

[0039] An NFS server working status detection system is used to implement the above-mentioned NFS server working status detection method; the system includes at least one server node deploying the NFS-Ganesha service, an access control module, a status detection module, and a status detection module:

[0040] The server node is configured to use CephFS as the storage backend. The server node's firewall is configured to open TCP and UDP port 2049 on the local loopback address 127.0.0.1.

[0041] The access control module is used to ensure that clients at the local loopback address 127.0.0.1 have appropriate access rights for test mounts;

[0042] The status detection module is used to execute the ganesha_stats tool command to collect and analyze the runtime status of NFS-Ganesha, generate and parse statistical information in JSON format, and provide it to the monitoring and management system for performance monitoring and fault diagnosis.

[0043] The exception handling module is used to automatically perform a graceful restart of the service when an NFS server abnormality is detected, thereby reducing server failure time and improving the reliability of the network file system.

[0044] An electronic device comprising: a memory and at least one processor;

[0045] wherein the memory stores computer-executable instructions;

[0046] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the above-mentioned NFS server working status detection method.

[0047] A computer-readable storage medium stores computer-executable instructions, and when a processor executes the computer-executable instructions, the above-mentioned NFS server working status detection method is implemented.

[0048] The NFS server working status detection method, system, device, and medium of the present invention have the following advantages:

[0049] (1) The present invention provides NFS services to the outside world based on NFS-Ganesha. By modifying the NFS-Ganesha source code and configuration files, the access rights of the local loopback address are released. Secondly, through the local loopback address mount test and timeout processing mechanism, the working status is directly detected on the NFS server, effectively eliminating the interference of client and network factors, and realizing direct detection of the working status of the server on the node where the NFS server is located, eliminating the influence of client and network, shortening the failure time, improving the reliability and operation and maintenance efficiency of the network file system, and ensuring the stable operation of the NFS service;

[0050] (2) The present invention uses the ganesha_stats tool to implement refined monitoring, analyzing the mount status and operation count changes of all NFS protocols exported by NFS-Ganesha, providing strong support for status detection; when it detects that the operation count has not changed for a specified time, it promptly identifies no client activity or service abnormalities through the local loopback address mount test and timeout processing mechanism. If it is determined that the server's working status is abnormal, it automatically performs a graceful restart of the NFS-Ganesha service, significantly shortening the failure time, simplifying the complexity of status detection, optimizing operation and maintenance efficiency, ensuring the stable operation of NFS services, and providing strong support for network file system services in cloud computing and big data storage environments;

[0051] (3) The present invention solves the problem in the prior art of being unable to directly determine whether the low reliability of the network file system is caused by a failure of the NFS server. It achieves direct detection of the working status of the NFS server on the node where the server is located, eliminating the influence of the client and the network, shortening the failure time, improving the reliability and operation and maintenance efficiency of the network file system, and ensuring the stable operation of the NFS service;

[0052] (4) The present invention can promptly detect NFS server failures and automatically restart the NFS-Ganesha service, thereby improving the reliability of the network file system. Through precise permission configuration, the access rights of the local loopback address are released, which not only ensures the security of the service but also simplifies permission management. At the same time, through the local loopback address mount test and timeout processing mechanism, the working status is directly detected on the NFS server, effectively eliminating interference from client and network factors. Once an anomaly is detected, the NFS-Ganesha service is automatically and gracefully restarted, significantly reducing the downtime, improving system reliability and operation and maintenance efficiency, simplifying the complexity of status detection, strengthening system monitoring and fault recovery capabilities, and ensuring the continuous and stable operation of the NFS service.

[0053] (5) The present invention can generate and parse statistical information in JSON format and provide it to monitoring and management systems for performance monitoring and fault diagnosis;

[0054] (6) The present invention realizes automatic and graceful restart of NFS-Ganesha service, reduces server failure time, and improves the reliability of network file system. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] The present invention will be further described below with reference to the accompanying drawings.

[0056] Attachment Figure 1 Export a flow chart for detecting client access permissions on the server side;

[0057] Attachment Figure 2 This is the flow chart for detecting the working status of the server. DETAILED DESCRIPTION

[0058] The NFS server working status detection method, system, device and medium of the present invention are described in detail below with reference to the accompanying drawings and specific embodiments.

[0059] Example 1:

[0060] This embodiment provides a method for detecting the working status of an NFS server. The method is as follows:

[0061] S1. Provide NFS services based on NFS-Ganesha. By modifying the NFS-Ganesha source code and configuration files, support for the CephFS distributed storage system backend is implemented. Access is allowed from clients on the local loopback address 127.0.0.1, and access rights to the local loopback address are released.

[0062] S2. Use the ganesha_stats tool to regularly collect runtime statistics of the NFS-Ganesha service. The runtime statistics include the mount status and operation counts of all exported NFS protocols on the NFS-Ganesha server.

[0063] S3. Analyze the change in the operation count. If there is no change within a predetermined detection period, test the shared directory exported by mounting the local loopback address and set a timeout limit.

[0064] If the mount test fails, the NFS server is considered to be in an abnormal working state, and a graceful restart of the NFS-Ganesha service is automatically performed to restore normal service operation.

[0065] In this embodiment, NFS service is provided externally based on NFS-Ganesha specifically as follows: using the CephFS file system provided by the distributed storage system Ceph as a storage backend through NFS-Ganesha to provide NFS service externally.

[0066] Ceph is a highly scalable, high-performance, open-source distributed storage system. Its core features include: providing a unified interface, supporting object storage (RGW), block storage (RBD), and file system storage (CephFS); easily expanding storage capacity and performance by adding more storage nodes, eliminating the need for a single point of failure; using replication and erasure coding to ensure high data availability, ensuring data loss even in the event of multiple hardware failures; and using the built-in CRUSH algorithm to automatically manage data distribution without manual intervention. CephFS (Ceph File System) is a distributed file system provided by the Ceph project. Built on top of Ceph's core storage cluster, it implements a POSIX-compliant file system interface. Because both CephFS and NFS support POSIX semantics, requests can be transparently passed to CephFS. NFS-Ganesha implements CephFS operations through the Ceph library libcephfs. NFS-Ganesha is a high-performance, scalable user-space NFS server that supports NFSv3, NFSv4, NFSv4.1, and NFSv4.2. With its unique user-space implementation, NFS-Ganesha breaks the limitations of traditional kernel-space implementations and enables high flexibility in service deployment and maintenance.

[0067] In this embodiment, when compiling the NFS-Ganesha source code, the two options -DUSE_FSAL_CEPH=ON and -DUSE_RADOS_RECOV=ON are added. When creating the export (EXPORT), the FSAL type in the configuration is specified as Ceph, which supports the CephFS file system abstraction layer and RADOS recovery.

[0068] At the same time, when compiling the NFS-Ganesha source code, add the -DUSE_ADMIN_TOOLS=ON option to use the state management tool that comes with NFS-Ganesha.

[0069] This embodiment is to directly detect the working status of the NFS server by performing a local mount test on the server node. In order to eliminate the influence of the network on the status detection, the server node specifies that the IP address of the NFS server is the local loopback address 127.0.0.1 when performing the local mount operation. Because the mount operation is performed on the server node, the client and the server are in the same system and use the loopback interface for communication, so the IP address of the client that issues the mount request during this mount process is also 127.0.0.1, which requires NFS-Ganesha to release the access rights of the client with the IP address 127.0.0.1, which involves the export permission settings in NFS-Ganesha; wherein, the export permission settings of NFS-Ganesha are as follows:

[0070] When setting export permission options, NFS-Ganesha follows the following order to determine the final configuration that takes effect: CLIENT{} represents the most specific level of configuration, defining permissions for a specified list of clients, building an ordered "access control list" to manage access rights to exported resources; if any permission options are specified here, the corresponding options will take precedence over settings at other levels; EXPORT{}: The next level of configuration, defining the general permission settings for the entire exported share; EXPORT_DEFAULTS{}: Sets the global default permissions;

[0071] When a client attempts to access an exported resource, NFS-Ganesha checks the associated CLIENT blocks in turn, looking for a matching client entry. If a match is found, the permissions defined in the corresponding client block are applied. If no client entry is matched, the permissions set in the corresponding EXPORT block are used. If any permissions are not explicitly set in either the CLIENT or EXPORT blocks, the permissions set in the EXPORT_DEFAULTS block are used, and the default is the permission value built into the code.

[0072] In this embodiment, a global default permission is set in the NFS-Ganesha configuration file ganesha.conf, that is, the client with IP address 127.0.0.1 is allowed to perform read and write operations. The specific configuration is EXPORT_DEFAULTS{CLIENT{Clients=127.0.0.1 / 32; Access_Type=RW;}};

[0073] At the same time, modify the export process of checking client permissions in the NFS-Ganesha source code.

[0074] As attached Figure 1 As shown, the process of modifying the export in the NFS-Ganesha source code to check client permissions is as follows:

[0075] (1) When a client accesses any export entry, NFS-Ganesha determines whether the client list in the CLIENT block of the current export configuration EXPORT block is empty:

[0076] ①If it is not empty, execute step (2);

[0077] ②If it is empty, jump to step (3);

[0078] (2) Determine whether there is a matching client entry:

[0079] ① If no client entry is assigned, proceed to step (3);

[0080] ②If there is a matching client entry, jump to step (4);

[0081] (3) Match the client list in the CLIENT block in the EXPORT_DEFAULTS block;

[0082] (4) Client matching is completed.

[0083] Since the default permissions at the global level are set in this embodiment, the client with the IP address 127.0.0.1 can find a match and thus has access rights to all exports.

[0084] As a high-performance user-space NFS server, NFS-Ganesha typically uses standard NFS protocol ports to provide services. NFSv3 uses port 2049 by default and supports both TCP and UDP protocols. NFSv4 also uses port 2049, but primarily transmits data over TCP. Therefore, the server node needs to open port 2049 for both TCP and UDP protocols with a destination address of 127.0.0.1. Use the firewall management tool iptables with the following commands: iptables -A INPUT -p tcp --dport 2049-d127.0.0.1 -j ACCEPT and iptables -A INPUT -p udp --dport 2049-d127.0.0.1 -j ACCEPT.

[0085] In this embodiment, ganesha_stats is a tool for collecting and viewing runtime statistics and status of the NFS-Ganesha service. It can provide real-time data about NFS-Ganesha service performance, resource usage, and operation counts, and supports JSON format output, enabling monitoring and analysis of NFS-Ganesha health, performance tuning, and troubleshooting.

[0086] Write a status detection script to parse JSON data, regularly obtain and analyze the working status of the NFS-Ganesha service; Figure 2 As shown in the figure, the NFS server working status detection process is as follows:

[0087] (1) Use the ganesha_stats json export command to obtain the status statistics of all exports from the NFS-Ganesha server. The status statistics include the unique identifier of each export, the shared directory, and the usage status of the NFSv3, NFSv4.0, NFSv4.1, and NFSv4.2 protocols. The NFS protocol usage status of each export indicates whether a client has mounted the exported shared directory using the corresponding protocol. The status is represented by a value of 0 or 1, where 0 indicates that no client has mounted the shared directory using the corresponding NFS protocol version, and 1 indicates that a client has mounted the shared directory using the corresponding NFS protocol version. The number of clients must be at least 1.

[0088] (2) Traverse all the obtained exports and exclude virtual root directories and exports without client mounts, that is, exclude exports with identifier 0 and exports with NFS protocol usage status accumulated to 0, i.e., exports without client mounts, to reduce the time and workload of status detection;

[0089] (3) Use the ganesha_stats json total id command to obtain the operation counts of the different versions of the NFS protocol for the current export. The operation count is the total number of client requests to mount the export using the corresponding version of the NFS protocol that the NFS-Ganesha server has processed.

[0090] (4) Determine whether the operation counts of all versions of the currently exported NFS protocol have changed within the set detection time:

[0091] If all the data remains unchanged, excluding network, configuration, permission, and statistics tool issues, it means that all currently exported clients have no active requests, or the NFS server is in an abnormal working state and cannot process requests normally.

[0092] (5) Directly detect the working status of the NFS server by locally mounting the currently exported shared directory on the server node; the mount operation specifies that the IP address of the NFS service is the local loopback address 127.0.0.1, and sets the mount operation timeout:

[0093] If all mounts fail within the set number of tests, the NFS server is considered to be in an abnormal working state and cannot process requests normally.

[0094] (6) To restore services as quickly as possible and improve the overall reliability of the network file system, the NFS-Ganesha service is automatically and gracefully restarted to shorten service congestion time and NFS server failure time.

[0095] Example 2:

[0096] This embodiment provides an NFS server working status detection system, which is used to implement the NFS server working status detection method as described in Example 1; the system includes at least one server node deploying the NFS-Ganesha service, an access control module, a status detection module, and a status detection module:

[0097] The server node is configured to use CephFS as the storage backend. The server node's firewall is configured to open TCP and UDP port 2049 on the local loopback address 127.0.0.1.

[0098] The access control module is used to ensure that clients at the local loopback address 127.0.0.1 have appropriate access rights for test mounts;

[0099] The status detection module is used to execute the ganesha_stats tool command to collect and analyze the runtime status of NFS-Ganesha, generate and parse statistical information in JSON format, and provide it to the monitoring and management system for performance monitoring and fault diagnosis.

[0100] The exception handling module is used to automatically perform a graceful restart of the service when an NFS server abnormality is detected, thereby reducing server failure time and improving the reliability of the network file system.

[0101] Example 3:

[0102] This embodiment also provides an electronic device, including: a memory and at least one processor;

[0103] wherein the memory stores computer-executable instructions;

[0104] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the NFS server working status detection method according to any one of the present inventions.

[0105] The processor may be a central processing unit (CPU), or other general-purpose processors, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor may be a microprocessor or any conventional processor, etc.

[0106] The memory can be used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area. The program storage area can store an operating system, at least one application required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, the memory can also include high-speed random access memory and non-volatile memory, such as a hard disk, internal memory, a plug-in hard disk, a smart memory card (SMC), a secure digital (SD) card, a flash memory card, at least one disk storage period, a flash memory device, or other volatile solid-state memory devices.

[0107] Example 4:

[0108] This embodiment further provides a computer-readable storage medium storing a plurality of instructions, which are loaded by a processor and cause the processor to execute the NFS server operating status detection method according to any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided, wherein the storage medium stores software program code that implements the functions of any of the above-described embodiments, and a computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.

[0109] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute part of the present invention.

[0110] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code can be downloaded from a server computer via a communication network.

[0111] In addition, it should be clear that the functions of any of the above embodiments can be achieved not only by executing the program code read by the computer, but also by enabling the operating system operating on the computer to complete part or all of the actual operations based on the instructions of the program code.

[0112] In addition, it can be understood that the program code read from the storage medium is written into the memory provided in the expansion board inserted into the computer or into the memory provided in the expansion unit connected to the computer, and then based on the instructions of the program code, the CPU installed on the expansion board or expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above embodiments.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for detecting the working status of an NFS server, characterized in that: The method is as follows: Based on NFS-Ganesha, NFS services are provided to the outside world. By modifying the NFS-Ganesha source code and configuration files, support for the CephFS distributed storage system backend is implemented. Access is allowed from clients on the local loopback address 127.0.0.1, and access rights to the local loopback address are released. Use the ganesha_stats tool to regularly collect runtime statistics of the NFS-Ganesha service. The runtime statistics include the mount status and operation counts of all exported NFS protocols on the NFS-Ganesha server. Analyze changes in operation counts. If there are no changes within the predetermined detection period, test the local loopback address to mount the exported shared directory and set a timeout limit. If the mount test fails, the NFS server is considered to be in an abnormal working state and a graceful restart of the NFS-Ganesha service is automatically performed to restore normal service operation. Specifically, NFS-Ganesha provides external NFS services by using the CephFS file system provided by the distributed storage system Ceph as the storage backend through NFS-Ganesha to provide external NFS services. ganesha_stats is a tool for collecting and viewing runtime statistics and status of the NFS-Ganesha service. It provides real-time data about NFS-Ganesha service performance, resource usage, and operation counts, and supports JSON format output. It enables monitoring and analysis of NFS-Ganesha health, performance tuning, and troubleshooting.

2. The NFS server working status detection method according to claim 1, wherein: When compiling the NFS-Ganesha source code, add the -DUSE_FSAL_CEPH=ON and -DUSE_RADOS_RECOV=ON options. When creating an export, specify the FSAL type in the configuration as Ceph to support the CephFS file system abstraction layer and RADOS recovery. At the same time, when compiling the NFS-Ganesha source code, add the -DUSE_ADMIN_TOOLS=ON option to use the state management tools that come with NFS-Ganesha.

3. The NFS server working status detection method according to claim 1 or 2, characterized in that: The export permission settings of NFS-Ganesha are as follows: When setting export permission options, NFS-Ganesha follows the following order to determine the configuration that takes effect: CLIENT{} represents the most specific level of configuration, defining permissions for a specified list of clients, building an ordered "access control list" to manage access rights to exported resources; if any permission options are specified here, the corresponding options will take precedence over settings at other levels; EXPORT{}: The next level of configuration, defining common permission settings for the entire exported share; EXPORT_DEFAULTS{}: Sets global default permissions; When a client attempts to access an exported resource, NFS-Ganesha checks the associated CLIENT blocks in turn, looking for a matching client entry. If a match is found, the permissions defined in the corresponding client block are applied. If no client entry is matched, the permissions set in the corresponding EXPORT block are used. If any permissions are not explicitly set in either the CLIENT or EXPORT blocks, the permissions set in the EXPORT_DEFAULTS block are used, and the default is the permission value built into the code.

4. The NFS server working status detection method according to claim 3, characterized in that: In the NFS-Ganesha configuration file ganesha.conf, set a global default permission to allow clients with IP address 127.0.0.1 to perform read and write operations. The specific configuration is EXPORT_DEFAULTS { CLIENT { Clients = 127.0.0.1 / 32; Access_Type = RW;}}; At the same time, modify the export process of checking client permissions in the NFS-Ganesha source code.

5. The NFS server working status detection method according to claim 4, characterized in that: Modify the export process in the NFS-Ganesha source code to check client permissions as follows: (1) When a client accesses any export entry, NFS-Ganesha determines whether the client list in the CLIENT block in the EXPORT block of the current export configuration is empty: ①If it is not empty, execute step (2); ②If it is empty, jump to step (3); (2) Determine whether there is a matching client entry: ① If no client entry is found, proceed to step (3); ②If there is a matching client entry, jump to step (4); (3) Match the client list in the CLIENT block in the EXPORT_DEFAULTS block; (4) Client matching is completed.

6. The NFS server working status detection method according to claim 1, characterized in that: Write a status detection script to parse JSON data and regularly obtain and analyze the working status of the NFS-Ganesha service. The NFS server working status detection process is as follows: Use the ganesha_stats json export command to obtain statistics about all exports on the NFS-Ganesha server. This statistics includes each export's unique identifier, shared directory, and the usage status of the NFSv3, NFSv4.0, NFSv4.1, and NFSv4.2 protocols. The NFS protocol usage status of each export indicates whether a client has mounted the exported shared directory using the corresponding protocol. The value is 0 or 1. 0 indicates no client has mounted the shared directory using the corresponding NFS protocol version, and 1 indicates a client has mounted the shared directory using the corresponding NFS protocol version. The number of clients must be at least one. Traverse all obtained exports and exclude virtual root directories and exports without client mounts. That is, exclude exports with an identifier of 0 and exports with a cumulative NFS protocol usage status of 0, i.e., exports with no client mounts. Use the ganesha_stats json total id command to obtain the operation counts of different versions of the NFS protocol for the current export. The operation count is the total number of client requests to mount the export using the corresponding version of the NFS protocol processed by the NFS-Ganesha server. Determine whether the operation counts of all versions of the currently exported NFS protocol have changed within the set detection time: If all the data remains unchanged, excluding network, configuration, permission, and statistics tool issues, it means that all currently exported clients have no active requests, or the NFS server is in an abnormal working state and cannot process requests normally. By locally mounting the currently exported shared directory on the server node, the working status of the NFS server can be directly detected. The mount operation specifies that the IP address of the NFS service is the local loopback address 127.0.0.1 and sets the mount operation timeout: If all mounts fail within the set number of tests, the NFS server is considered to be in an abnormal working state and cannot process requests normally. Automatically and gracefully restart the NFS-Ganesha service, shortening service congestion and NFS server failure time.

7. An NFS server working status detection system, characterized in that: The system is used to implement the NFS server working status detection method according to any one of claims 1 to 6; the system includes at least one server node deploying the NFS-Ganesha service, an access control module, a status detection module, and a status detection module: The server node is configured to use CephFS as the storage backend. The server node's firewall is configured to open TCP and UDP port 2049 on the local loopback address 127.0.0.

1. The access control module is used to ensure that clients at the local loopback address 127.0.0.1 have appropriate access rights for test mounts; The status detection module is used to execute the ganesha_stats tool command to collect and analyze the runtime status of NFS-Ganesha and generate and parse statistical information in JSON format; The exception handling module is used to automatically perform a graceful restart of the service when an NFS server abnormality is detected; Among them, NFS services are provided externally based on NFS-Ganesha. Specifically, NFS-Ganesha uses the CephFS file system provided by the distributed storage system Ceph as the storage backend to provide NFS services externally; ganesha_stats is a tool for collecting and viewing runtime statistics and status of the NFS-Ganesha service. It provides real-time data about NFS-Ganesha service performance, resource usage, and operation counts, and supports JSON format output. It enables monitoring and analysis of NFS-Ganesha health, performance tuning, and troubleshooting.

8. An electronic device, characterized in that: include: memory and at least one processor; wherein the memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the NFS server working status detection method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the NFS server working status detection method according to any one of claims 1 to 6 is implemented.

Images