NFS (Network File System) server working state detection method, system, equipment and medium

Abstract

The invention discloses a method, a system, equipment and a medium for detecting the working state of an NFS (Network File System) server, belongs to the technical field of information, and aims to solve the technical problem of how to directly detect the working state of the server on a node where the NFS server is located, eliminate the influence of a client and a network, shorten the fault time and improve the working efficiency. According to the technical scheme, an NFS service is externally provided based on NFS-Ganesha, support for the rear end of a CephFS distributed storage system is achieved by modifying an NFS-Ganesha source code and a configuration file, a client from a local loopback address 127.0. 0.1 is allowed to access, and the access permission of the local loopback address is released; the method comprises the following steps: regularly collecting statistical information of the NFS-Ganesha service during operation by adopting a ganeshats tool; analyzing the change of the operation count, and if the operation count does not change in a preset detection period, testing a shared directory which is mounted and exported by a local loopback address and setting timeout limitation; and if the mounting test fails, judging that the working state of the NFS server side is abnormal, and automatically executing graceful restart of the NFS-Ganesha service.

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] Network File System (NFS) is a widely used network file sharing protocol that allows different computers to share resources over the network as if the files were stored on local disks. NFS works based on a client-server model. In the client-server model, one or more servers share their file system resources, and clients can mount these remote file systems and read and write them as if they were accessing local files. With the rapid development of information technology, especially the rise of cloud computing and big data, higher requirements have been placed on NFS, including but not limited to dynamic scalability, cross-platform compatibility, and seamless integration of emerging storage technologies.

[0003] NFS-Ganesha was born as a high-performance network file system (NFS) server implemented in user space. Unlike traditional kernel-mode NFS implementations, NFS-Ganesha runs in user space and provides a modular plug-in architecture that allows users to easily add or replace storage backends (such as Ceph, GlusterFS, iSCSI, etc.) according to their needs. NFS-Ganesha has become an important choice for network file sharing in modern data centers and cloud environments due to its ease of use, flexibility, and support for enterprise-level features (such as high availability and security).

[0004] In a real work scenario, a client may have an extremely high load, causing the NFS server to respond too slowly or stop responding, that is, unable to process requests normally, resulting in low reliability of the network file system. At present, the conventional method for detecting the working status of the network file system server is: the client writes a file to the server in the mounted shared directory for testing. If the file is written successfully, the working status of the server is considered to be normal and the request can be processed normally. Otherwise, the working status of the server is considered to be abnormal and the request cannot be processed normally. However, when the above method is used to detect the server, it is impossible to determine whether the failure of the file writing is caused by a failure in the client, the server, or the network. The next step of 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 the 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 a method, system, device and medium for detecting the working status of an NFS server 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 the network, and shorten the failure time.

[0007] The technical task of the present invention is achieved in the following way: a method for detecting the working status of an NFS server, the method is 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, and access from clients of the local loopback address 127.0.0.1 is allowed, 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 the changes in the operation count. If there is no change 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 service externally based on NFS-Ganesha is specifically as follows: using CephFS file system provided by distributed storage system Ceph as storage backend through NFS-Ganesha to provide NFS service externally.

[0013] Preferably, when compiling the NFS-Ganesha source code, add the two options -DUSE_FSAL_CEPH=ON and -DUSE_RADOS_RECOV=ON, and when creating the export (EXPORT), specify the type of FSAL 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, which defines permissions for a specified list of clients and builds an ordered "access control list" to manage access rights to exported resources; if any permission option is specified here, the corresponding option will take precedence over settings at other levels; EXPORT{}: The next level of configuration, which defines the general permission settings for the entire export share; EXPORT_DEFAULTS{}: Sets global default permissions;

[0017] When a client attempts to access an exported resource, NFS-Ganesha checks the associated CLIENT blocks in turn to find a matching client entry. If a match is found, the permissions defined in the corresponding client block are applied. If there is no matching client entry, 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. 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, and the specific configuration is EXPORT_DEFAULTS{CLIENT{Clients=127.0.0.1 / 32;Access_Type=RW;}};

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

[0020] Preferably, modify the process of checking client permissions in the export in the NFS-Ganesha source code as follows:

[0021] (1) When a client accesses any export entry, NFS-Ganesha determines whether the client list in the CLIENT block in 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, execute 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 NFS-Ganesha services. It can provide real-time data about NFS-Ganesha service performance, resource usage, and operation counts, and supports JSON format output to monitor and analyze the health status, performance tuning, and troubleshooting of NFS-Ganesha.

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

[0031] Use the ganesha_stats json export command to obtain the status statistics of all exports on 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 usage status of each exported NFS protocol represents whether there is a client mounting the exported shared directory using the corresponding protocol, which is represented by the values ​​0 and 1. 0 means that no client mounts the shared directory using the corresponding version of the NFS protocol, and 1 means that a client mounts the shared directory using the corresponding version of the NFS protocol. The number of clients must be at least 1.

[0032] Traverse all the obtained exports and exclude virtual root directories and exports without client mounting, that is, exclude exports with identifier 0 and exports with NFS protocol usage status accumulated to 0, that is, exports without client mounting, to reduce 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 request operations of all clients that mount the export with 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 remain unchanged, excluding network problems, configuration problems, permission problems, and statistical tool problems, it means that all the 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 test 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 current 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] A NFS server working status detection system, the system is used to implement the above-mentioned NFS server working status detection method; the system includes at least one server node deploying 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 firewall is configured to open the TCP and UDP ports 2049 of 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 command of the ganesha_stats tool, 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 abnormality is detected on the NFS server, 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. 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, the working status is directly detected on the NFS server through the local loopback address mounting test and timeout processing mechanism, and the interference of client and network factors is effectively eliminated. The working status of the server is directly detected on the node where the NFS server is located, the influence of the client and the network is eliminated, and the failure time is shortened, the reliability and operation and maintenance efficiency of the network file system are improved, and the stable operation of the NFS service is ensured;

[0050] (ii) The present invention uses the ganesha_stats tool to implement refined monitoring, analyzes the mount status and operation count changes of all NFS protocols exported by NFS-Ganesha, and provides strong support for status detection; when it is detected that the operation count has not changed for a specified time, the local loopback address mount test and timeout processing mechanism are used to timely identify no client activity or service abnormalities. If it is determined that the working status of the server is abnormal, the NFS-Ganesha service is automatically restarted gracefully, which significantly shortens the failure time, simplifies the complexity of status detection, optimizes the operation and maintenance efficiency, ensures the stable operation of the NFS service, and provides strong support for network file system services in cloud computing and big data storage environments;

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

[0052] (IV) The present invention can timely discover NFS server failures and automatically restart NFS-Ganesha services, 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 the interference of client and network factors; once an abnormality is detected, the NFS-Ganesha service is automatically and gracefully restarted, which significantly reduces the failure time, improves the system reliability and operation and maintenance efficiency, simplifies the complexity of status detection, strengthens the system monitoring and fault recovery capabilities, and ensures the continuous and stable operation of the NFS service;

[0053] (V) 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] (VI) The present invention realizes automatic and elegant 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 is further described below in conjunction with the accompanying drawings.

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

[0057] Attached Figure 2 This is the flow chart of the server working status detection. 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 of the specification.

[0059] Embodiment 1:

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

[0061] S1. Provide NFS services based on NFS-Ganesha. Support the backend of CephFS distributed storage system by modifying NFS-Ganesha source code and configuration files. Allow access from clients of the local loopback address 127.0.0.1 and release access rights to the local loopback address.

[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 of the operation count. If there is no change within the 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, providing NFS service externally based on NFS-Ganesha specifically includes: using CephFS file system provided by distributed storage system Ceph as storage backend through NFS-Ganesha to provide NFS service externally.

[0066] Ceph is a highly scalable, high-performance open source distributed storage system. The core features of Ceph 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 without single point of failure; using replication and erasure coding technology to ensure high data availability, even if multiple hardware failures can ensure data is not lost; the built-in CRUSH algorithm automatically manages data distribution without manual intervention; well supports cloud platforms such as Kubernetes and OpenStack, suitable for cloud storage needs. CephFS (CephFile System) is a distributed file system provided by the Ceph project. It is built on the core storage cluster of Ceph and implements a POSIX-compatible file system interface. Since both CephFS and NFS support POSIX semantics, requests can be transparently transmitted to CephFS. NFS-Ganesha implements operations on CephFS through the Ceph library libcephfs. NFS-Ganesha is a high-performance, scalable user-mode NFS server that supports NFSv3, NFSv4, NFSv4.1, and NFSv4.2 protocols. With its unique user-space implementation, NFS-Ganesha breaks the limitations of traditional kernel-mode implementation and achieves high flexibility in service deployment and maintenance.

[0067] In this embodiment, when compiling the NFS-Ganesha source code, two options -DUSE_FSAL_CEPH=ON and -DUSE_RADOS_RECOV=ON are added, and when creating the export (EXPORT), the type of FSAL in the configuration is specified as Ceph, supporting 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] In order to directly detect the working status of the NFS server, this embodiment tests the local mounting of the NFS shared directory 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. Therefore, 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 of 127.0.0.1, which involves the export permission settings in NFS-Ganesha; among them, 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, which defines permissions for a specified list of clients and builds an ordered "access control list" to manage access rights to exported resources; if any permission option is specified here, the corresponding option will take precedence over settings at other levels; EXPORT{}: The next level of configuration, which defines the general permission settings for the entire export share; EXPORT_DEFAULTS{}: Sets global default permissions;

[0071] When a client attempts to access an exported resource, NFS-Ganesha checks the associated CLIENT blocks in turn to find a matching client entry. If a match is found, the permissions defined in the corresponding client block are applied. If there is no matching client entry, 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. 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 process of export 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 the 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 in 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, execute 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 present embodiment sets the default permissions at the global level, 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 usually 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 it is mainly transmitted through TCP, so the server node needs to open port 2049 of TCP and UDP protocols with a target address of 127.0.0.1. Use the firewall management tool iptables, and the commands are 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 NFS-Ganesha service runtime statistics and status, which can provide real-time data about NFS-Ganesha service performance, resource usage, and operation counts, and supports JSON format output, so as to monitor and analyze the health status, performance tuning, and troubleshooting of NFS-Ganesha;

[0086] Write a status detection script to parse the JSON data, and 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) Obtain the status statistics of all exports of the NFS-Ganesha server through the ganesha_stats json export command. 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 usage status of each exported NFS protocol represents whether there is a client mounting the exported shared directory using the corresponding protocol, represented by the values ​​0 and 1, 0 represents no client mounting using the corresponding version of the NFS protocol, 1 represents a client mounting using the corresponding version of the NFS protocol, and the number of clients is at least 1;

[0088] (2) traverse all the obtained exports, exclude virtual root directories and exports without client mounting, that is, exclude exports with identifier 0 and exports with NFS protocol usage status accumulated to 0, that is, exports without client mounting, 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 different versions of the NFS protocol for the current export. The operation count is the total number of request operations of all clients that mount the export using the corresponding version of the NFS protocol processed by the NFS-Ganesha server;

[0090] (IV) 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 remain unchanged, excluding network problems, configuration problems, permission problems, and statistical tool problems, it means that all the currently exported clients have no active requests, or the NFS server is in an abnormal working state and cannot process requests normally;

[0092] (V) By testing the currently exported shared directory locally 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:

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

[0094] (VI) 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.

[0095] Embodiment 2:

[0096] This embodiment provides an NFS server working status detection system, which is used to implement the NFS server working status detection method 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 firewall is configured to open the TCP and UDP ports 2049 of 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 command of the ganesha_stats tool, 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 abnormality is detected on the NFS server, thereby reducing server failure time and improving the reliability of the network file system.

[0101] Embodiment 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 described in any one of the present inventions.

[0105] The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (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 realizes 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, wherein 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 according to the use of the terminal, etc. In addition, the memory can also include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a 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 storage devices.

[0107] Embodiment 4:

[0108] This embodiment also provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions are loaded by a processor, so that the processor executes the NFS server working status detection method in any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided, on which a software program code that implements the functions of any of the above embodiments is stored, and a computer (or CPU or MPU) of the system or device reads and executes 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 a part of the present invention.

[0110] The storage medium embodiments for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Alternatively, the program code can be downloaded from a server computer by a communication network.

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

[0112] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or written to a memory provided in an expansion unit connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or the expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned 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 aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned 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, and access from clients of the local loopback address 127.0.0.1 is allowed, 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 the changes in the operation count. If there is no change 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.

2. The NFS server working status detection method according to claim 1, characterized in that: Based on NFS-Ganesha, NFS services are provided externally as follows: NFS-Ganesha uses the CephFS file system provided by the distributed storage system Ceph as the storage backend to provide NFS services externally.

3. The NFS server working status detection method according to claim 1 or 2, characterized in that: When compiling the NFS-Ganesha source code, add the two options -DUSE_FSAL_CEPH=ON and -DUSE_RADOS_RECOV=ON. When creating an export, specify the type of FSAL 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 tool that comes with NFS-Ganesha.

4. The NFS server working status detection method according to claim 3, 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 final configuration that takes effect: CLIENT{} represents the most specific level of configuration, which defines permissions for a specified list of clients and builds an ordered "access control list" to manage access rights to exported resources; if any permission option is specified here, the corresponding option will take precedence over settings at other levels; EXPORT{}: The next level of configuration, which defines the general permission settings for the entire export 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 to find a matching client entry. If a match is found, the permissions defined in the corresponding client block are applied. If there is no matching client entry, 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. The default is the permission value built into the code.

5. The NFS server working status detection method according to claim 4, characterized in that: In the NFS-Ganesha configuration file ganesha.conf, set a global default permission to allow the client 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 process of export checking client permissions in the NFS-Ganesha source code.

6. The NFS server working status detection method according to claim 5, characterized in that: The process of modifying the export in the NFS-Ganesha source code to check client permissions is as follows: (1) When a client accesses any export entry, NFS-Ganesha determines whether the client list in the CLIENT block in the current export configuration EXPORT block 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 assigned, execute 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.

7. The NFS server working status detection method according to claim 1, characterized in that: ganesha_stats is a tool for collecting and viewing runtime statistics and status of NFS-Ganesha services. It provides real-time data about NFS-Ganesha service performance, resource usage, and operation counts, and supports JSON format output to monitor and analyze the health status, performance tuning, and troubleshooting of NFS-Ganesha. Write a status detection script to parse the JSON data, and regularly obtain and analyze the working status of the NFS-Ganesha service. The specific process of NFS server working status detection is as follows: Use the ganesha_stats json export command to obtain the status statistics of all exports on 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 usage status of each exported NFS protocol represents whether there is a client mounting the exported shared directory using the corresponding protocol, which is represented by the values ​​0 and 1. 0 means that no client mounts the shared directory using the corresponding version of the NFS protocol, and 1 means that a client mounts the shared directory using the corresponding version of the NFS protocol. The number of clients must be at least 1. Traverse all the obtained exports and exclude the virtual root directory and the exports without client mounting, that is, exclude the exports with identifier 0 and the exports with NFS protocol usage status accumulated to 0, that is, the exports without client mounting; 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 request operations of all clients that mount the export with 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 remain unchanged, excluding network problems, configuration problems, permission problems, and statistical tool problems, it means that all the 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 test 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 current NFS server is considered to be in an abnormal working state and cannot process requests normally; Automatically and gracefully restart the NFS-Ganesha service to shorten business congestion time and NFS server failure time.

8. An NFS server working status detection system, characterized in that: The system is used to implement the NFS server working status detection method as described in any one of claims 1 to 7; 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 firewall is configured to open the TCP and UDP ports 2049 of 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 command of the ganesha_stats tool, 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 abnormality is detected in the NFS server.

9. 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 as described in any one of claims 1 to 7.

10. 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 as described in any one of claims 1 to 7 is implemented.

Images