Shared access storage function test system, method, device, medium and product

Abstract

The invention discloses a test system, method and device for a shared access storage function, a medium and a product, and relates to the technical field of storage management and testing, a shared directory of a shared access storage space is created through a storage device, and at least one of shared directory information, mounting information, login information and test configuration information is obtained by using a test component; and mounting the shared directory to the client, generating the test configuration file according to the test configuration parameter, writing the test configuration file into at least one client, and testing the shared access storage function of the storage device by the client, thereby realizing one-key starting of an automatic IO test and confirmation of an execution result. According to the method and the device, the technical problems of low test efficiency and high error rate of mounting and testing a large batch of NFS shared directories in related technologies are solved, and the technical effects of avoiding tedious operation of a user and improving the test efficiency and accuracy are achieved.

Description

Technical Field

[0001] The present application relates to the field of storage management and testing technology, and in particular to a test system, method, device, medium and product for shared access storage function. Background Art

[0002] With the development of network storage technology, NAS (Network Attached Storage) provides a shared storage mechanism based on the NFS (Network File System) protocol, enabling clients to efficiently and conveniently access remote storage resources. To ensure the reliability and stability of NFS sharing in real-world applications, it is typically necessary to enable and pre-configure the NAS service on the server, then perform a mount operation on the client and perform I / O (Input / Output) testing to verify its performance.

[0003] However, when faced with large quantities of NFS shared directories and their diverse mounting and load requirements, the testing process currently relies mainly on manual operations, which are inefficient, cumbersome and error-prone, making it difficult to meet the needs of large-scale storage testing and deployment. Summary of the Invention

[0004] The present application provides a test system, method, device, medium and product for shared access storage function, so as to at least solve the technical problems in the related art of low testing efficiency and easy errors when mounting and testing large quantities of NFS shared directories.

[0005] The present application provides a testing system for a shared access storage function, comprising: a storage device, the storage device comprising at least one storage node, configuring shared access storage space at any storage node, and creating a shared directory of the shared access storage space; at least one client, configured to configure and use the shared access storage space of the storage device; a testing component, configured to obtain at least one of shared directory information, mount information, login information, and test configuration information, mount the shared directory to the client according to at least one of the shared directory information and the mount parameters in the mount information, generate a test configuration file according to the test configuration parameters in the test configuration information, and write the test configuration file to at least one client based on the login information; the client tests the shared access storage function of the storage device based on the test configuration file.

[0006] The present application also provides a method for testing a shared access storage function, which is applied to a test component of the above-mentioned test system for shared access storage function, wherein the method includes: obtaining at least one of shared directory information, mounting information, login information, and test configuration information; mounting the shared directory to the client according to at least one of the mount parameters in the shared directory information and the mount information; generating a test configuration file according to the test configuration parameters in the test configuration information, writing the test configuration file into at least one client based on the login information, and the client testing the shared access storage function of the storage device based on the test configuration file.

[0007] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of the above-mentioned test method for shared access to storage function when executing the computer program.

[0008] The present application also provides a non-volatile computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the test method for the shared access storage function are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned test method for shared access storage function when the computer program is executed by a processor.

[0010] Through this application, a shared directory for shared access to storage space is created through a storage device, and a test component is used to obtain at least one of the shared directory information, mounting information, login information, and test configuration information. The shared directory is mounted on the client, and a test configuration file is generated according to the test configuration parameters. The test configuration file is written to at least one client, and the client tests the shared access storage function of the storage device, realizing one-click startup of automated IO testing and confirmation of execution results. Therefore, the technical problems of low test efficiency and easy errors in the related technology for mounting and testing large quantities of NFS shared directories can be solved, thereby avoiding the user's tedious operations and improving the technical effect of testing efficiency and accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 A schematic diagram of the structure of a test system for shared access storage function provided in an embodiment of the present application; Figure 2An overall flow chart of a test system for a shared access storage function provided in one embodiment of the present application; Figure 3 A flowchart of mounting a shared directory provided for one embodiment of the present application; Figure 4 A flowchart of updating IO parameters provided in one embodiment of the present application; Figure 5 A flowchart of a method for testing a shared access storage function provided in an embodiment of the present application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0013] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0014] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0015] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0016] Figure 1 This is a schematic diagram of the structure of the test system for shared access storage function provided in the embodiment of the present application. Figure 1 As shown, the test system 10 for shared access storage function includes: a storage device 101 , at least one client 102 and a test component 103 .

[0017] Among them, the storage device 101 includes at least one storage node, shared access storage space is configured at any storage node, and a shared directory of the shared access storage space is created; at least one client 102 is used to configure and use the shared access storage space of the storage device 101; the test component 103 is used to obtain at least one of shared directory information, mount information, login information, and test configuration information, and mount the shared directory to the client 102 according to at least one of the mount parameters in the shared directory information and the mount information, generate a test configuration file according to the test configuration parameters in the test configuration information, and write the test configuration file to at least one client 102 based on the login information; the client 102 tests the shared access storage function of the storage device 101 based on the test configuration file.

[0018] Among them, storage device 101 refers to the server side that provides NAS services, which can manage the file system and allow multiple clients to share access to the same storage space; shared access storage space is a storage resource provided by the storage device and can be accessed by multiple clients through a network protocol (such as NFS); client 102 is a client server for configuring and using NAS NFS sharing; the test configuration file is a configuration file generated based on the configuration parameters provided by the user, which is used to guide the test tool on how to perform specific test tasks, including but not limited to settings such as file size and number of files.

[0019] It can be understood that the storage device 101 of the embodiment of the present application includes at least one storage node, and a storage space allowing shared access is configured on any storage node, and a corresponding shared directory is created; at least one client 102 is used to configure and use the shared access storage space on the storage device 101; the test component 103 is responsible for obtaining relevant information about the shared directory, parameters required for mounting, login credentials, and configuration requirements for IO testing. Based on the obtained shared directory information and mounting parameters, the test component 103 will mount the specified shared directory to the client 102. Subsequently, according to the test configuration parameters, the test component 103 generates a corresponding test configuration file and writes this file to at least one client 102 using the login information. Finally, the client 102 tests and verifies the shared access storage function of the storage device 101 based on the received test configuration file, thereby achieving a high degree of automation in the process of executing IO tests on NAS's NFS shares and verifying the validity of the results, greatly reducing the complexity and workload of manual operations and improving testing efficiency.

[0020] In an embodiment of the present application, a test tool is configured on the client 102, and the test tool generates a test load according to a test configuration file, and performs at least one of a read operation and a write operation on the shared access storage space based on the test load.

[0021] The test tool may be Vdbench, which is a tool for generating specific I / O (Input / Output) loads and performing storage performance tests. The tool can simulate different load conditions to test storage devices according to a provided test configuration file.

[0022] It can be understood that the client 102 of the embodiment of the present application is configured with a testing tool, which can generate a specific test load based on the test configuration file. Based on this test load, the client 102 can perform at least one operation on the shared access storage space provided by the storage device 101, namely a read operation or a write operation. Specifically, the testing tool can create corresponding I / O loads according to predefined parameters, and use these loads to evaluate the performance and stability of the shared storage space.

[0023] In an embodiment of the present application, the test component 103 logs in to the client 102 based on the login information, detects whether the client 102 is configured with a test tool, and installs the test tool on the client 102 if the client 102 is not configured with the test tool.

[0024] The login information includes login method, user name, password and other information, which is used to remotely log in to the client 102.

[0025] It is understandable that before starting the test, the test component 103 of the embodiment of the present application needs to log in to the client 102 based on the login information and detect whether the client 102 has been configured with the required test tools, such as Vdbench. If the test component 103 finds that the client 102 has not yet been configured with the test tool, it will automatically install the corresponding test tool on the client 102 so that the IO test task can be performed according to the generated test configuration file later, ensuring that all necessary software environments are ready, so that the read and write operation tests performed on the NAS NFS share can proceed smoothly.

[0026] According to the test system for the shared access storage function of the embodiment of the present application, a shared directory of the shared access storage space can be created through a storage device, and a test component can be used to obtain at least one of the shared directory information, mounting information, login information, and test configuration information. The shared directory is mounted on the client, and a test configuration file is generated according to the test configuration parameters. The test configuration file is written to at least one client, and the client tests the shared access storage function of the storage device, realizing one-click startup of automated IO testing and confirmation of execution results, thereby achieving the technical effect of avoiding tedious operations of users and improving test efficiency and accuracy.

[0027] The following further describes the test system for shared access storage function using a specific embodiment.

[0028] The specific implementation of this embodiment involves three types of devices and roles: storage device (referring to the server that builds the storage system and can provide NAS services), client (NFS sharing client, referring to the client server used to configure and use NAS NFS sharing), and test component (referring to the server used to deploy and install automation devices and store some public tools, such as the Vdbench tool package that can be stored for users to download and use).

[0029] In this embodiment, NAS pre-configuration is first performed on the storage system, and the shared directories are summarized and classified according to the mounting parameters and IO test parameters. The two parameters are the same and classified into one category. The shared directories of the same category can be input into the automation device at the same time; the shared directories of different categories can be input into the automation device in batches; the device receives the parameters input by the user (storage device information, NFS sharing client device information, shared directory name, IO parameters, mounting parameters), first mounts the shared directory on the NFS sharing access client according to the mounting parameters, and then calculates and writes the IO configuration file based on the provided IO parameters (this embodiment uses Vdbench as the IO testing tool), and finally starts the IO test and verifies the validity of the test; the flow chart is as follows Figure 2 As shown, the details are as follows: Step (1) Pre-configure NAS on the storage side All operations involved in this step need to be performed on the storage device. You can perform operations in the graphical user interface or using the background command line. You need to create a storage pool on the storage system, enable the NAS service, create a file system, configure the business address of the NAS share, and create an NFS share. Users can create them in sequence as needed.

[0030] Step (2) Classify shared directories according to mount parameters / IO parameters The user can determine the mount parameters (such as -o vers=4, which means to specify the use of NFSv4 (NFS version 4 protocol for mounting) and IO configuration parameters (such as —xfsize 4k, --fileio random, where —xfsize 4k specifies the transfer size of the I / O operation, indicating that each I / O operation will process 4 kilobytes of data, and --fileio random indicates the access mode of the I / O operation) according to actual needs, and group the same parameters into one category; the user can also group the same parameters together while creating in step (1); the parameters in this step are provided by the user according to actual needs.

[0031] Step (3) Input the shared directory and user parameters into the automation device The automation device of this embodiment requires the user to input the NFS shared directory created in step (1), the IO configuration parameters and mounting parameters determined in step (2), and provide the specific login information of the device (storage device, NFS sharing client) (such as login method, login user name, and password for remote login of the execution machine).

[0032] Step (4): NFS share client mounts the shared directory Since the business address of the storage node where the NAS shared directory is located is required for mounting, it is necessary to first query the corresponding business address in the storage system based on the shared directory. NAS services are usually deployed on a dual-controller storage system, that is, a storage system consisting of two storage nodes (set the two nodes as node1 and node2 respectively). Each NAS file system has a home node, and its corresponding shared directory also uses the business IP of the corresponding node. The shared directory mounting process is as follows: Figure 3 As shown, the specific process is as follows: First, query the specified shared directory name on node1. If it can be found, it means that the file system corresponding to the shared directory belongs to node1. In this case, you need to obtain the business address of node1. Otherwise, you need to obtain the business address of node2. Then create a mounted local directory on the NFS share client; then determine whether the user has passed in the parameters corresponding to the mount requirements (such as -mount_param "-o vers=3,tcp", which is used to specify the specific options when mounting NFS shares, where the specific explanation of the parameters is: -o is an option of the mount command, which is used to specify the various options used when mounting the file system. When mounting NFS shares, -o is followed by a series of options specific to NFS; vers=3 specifies the version of the NFS protocol to be used, vers=3 means using NFS version 3 protocol; tcp specifies using TCP (Transmission Control Protocol) as the transport protocol). If there are mount parameters, then mount_param is set to the passed-in parameters and the mount is performed with the parameters. Otherwise, the mount parameters are left empty and the mount is performed directly. At the same time, due to the differences between IPV4 (Internet Protocol version 4) and IPV6 (Internet Protocol version 6), 6, Internet Protocol Version 6) has a different mounting format. When mounting, you must also distinguish whether the business address is IPV4 or IPV6. If it is IPV4, perform IPV4 NFS mounting with mount_param. Otherwise, perform IPV6 NFS mounting with mount_param.

[0033] Step (5): Calculate and write the IO configuration file Update IO parameter flow chart as follows Figure 4 As shown, since this embodiment uses the Vdbench tool as the IO load generator, the automated device will first detect whether the tool is installed on the NFS share client (first checking whether the Vdbench tool directory exists, and then checking whether the Vdbench executable file exists). If it is detected that the tool does not exist on the NFS client, it will download it from the execution machine server and install it on the NFS share client. If the tool already exists on the NFS client, it will continue to execute the subsequent steps. After confirming that the tool has been installed, it is necessary to generate a configuration file (auto_param) required for Vdbench to perform IO testing based on the IO parameters entered by the user. The parameters in this file include some common IO parameters and user-customized parameters. Some common IO parameters can be directly obtained from user input, such as the number of threads (threads), the proportion of read-only load in the load (rdpct), and the compression ratio of written data (compratio). Some user-customized parameters, such as the number of files created in the lowest-level directory (files) and the file size (fsize), need to be checked and adapted to the actual situation before being written into the IO configuration file. If the file size is entered, the maximum number of files that can be accommodated can be calculated based on the actual space size of the mount directory. If the user also enters the number of files, the smaller of the entered value and the actual calculated value is used. (When the user provides both the file size and the number of files, if the actual storage space is not taken into account, insufficient space will result and IO execution will fail. Therefore, it is necessary to adjust the file size or the number of files written to the configuration file. This article adopts the method of adjusting the number of files.) If the user does not enter the file size (fsize), it is calculated based on the actual mounted directory space divided by the total number of files (at least one of the file size and the number of files must be provided; the total number of files is the directory width (width) multiplied by the directory depth (depth) power, multiplied by the number of files (files)). If the user wants to enable data verification during IO reading and writing, the file size must be an integer multiple of the data size (xfersize) for a single transfer.

[0034] Step (6) Start Vdbench on the NFS share client to perform IO testing The automation device starts Vdbench on the NFS share client by remotely logging in from the execution machine and sending commands to the NFS share client. Vdbench generates IO load according to the specified IO configuration file, and then performs IO read and write tests on the specified directory space.

[0035] Step (7): Validation after IO test is completed When Vdbench performs an IO test, it will generally print a log in the corresponding log directory file. The validity of the IO test can be determined by checking the final printed information of the log. If "Vdbench execution completed successfully" is detected in the final printout, it means that the test is valid. Different types of NFS shares can be input into the automation device in batches, and IO tests can be started in sequence to obtain test results.

[0036] Next, a test method for the shared access storage function provided by an embodiment of the present application is described with reference to the accompanying drawings. Figure 5 A flow chart of a test method for a shared access storage function provided in an embodiment of the present application is provided. The method is applied to a test component of the test system for the shared access storage function, such as Figure 5 As shown, the method includes the following steps: In step S201, at least one of shared directory information, mounting information, login information, and test configuration information is obtained.

[0037] Among them, shared directory information refers to the relevant information of the NFS shared directory provided by NAS, including but not limited to the directory name, path, etc.; mount information involves the parameters and requirements for mounting remote files locally, including mount parameters; login information contains the authentication information required to access the storage device or client, such as login method, user name, password, etc., which is used to realize remote login and operation; test configuration information refers to the various parameter settings required for IO performance testing. Some common IO parameters can be obtained directly from user input, including but not limited to the number of threads, the proportion of read-only in the load, file size, etc.

[0038] It can be understood that the embodiment of the present application first obtains shared directory information, mounting information, login information or test configuration information. Based on the collected information, the following series of operations from mounting the shared directory to executing and verifying the IO test results can be automatically completed.

[0039] In step S202, the shared directory is mounted to the client according to the shared directory information and at least one of the mount parameters in the mount information.

[0040] It can be understood that the embodiment of the present application can mount the specified NFS shared directory to the client device based on the provided shared directory information and at least one of the mount parameters in the mount information. That is, by using the shared directory information and the necessary mount parameters (such as the specified protocol version, transmission type, etc.), the required remote storage resources can be correctly mounted on the client device, ensuring that the client can access and use the specific shared storage space on the NAS according to specific needs, and prepare for subsequent IO testing or other operations.

[0041] In an embodiment of the present application, a shared directory is mounted to a client based on at least one of the shared directory information and the mount parameters in the mount information, including: extracting the shared directory name in the shared directory information; querying the business address of the corresponding target storage node from the storage device based on the shared directory name, wherein the target storage node creates a shared access storage space; creating a local mount directory on the client, mounting the business address to the local mount directory, and if the mount parameters exist, carrying the mount parameters during mounting.

[0042] The shared directory name is the shared directory identifier, used to locate specific shared resources on the storage device. The business address of the target storage node refers to the network address (i.e., IP (Internet Protocol) address) of the node providing NFS services on the storage device, used for communication between the client and the storage device. The local mount directory is a directory created locally on the client and used as a mount point to mount remote NFS shared directories.

[0043] It can be understood that the embodiment of the present application mounts the shared directory to the client based on at least one of the mount parameters in the shared directory information and the mount information. First, the shared directory name in the shared directory information is extracted, and then the business address of the corresponding target storage node is queried from the storage device based on this name, that is, the IP address of the node providing NFS service. In this process, it is determined which storage node created the shared access storage space. Next, a local mount directory is created on the client, and the obtained business address is mounted to this local directory. If there are mount parameters, these parameters are carried when performing the mount operation, so as to ensure that the mount process is correctly configured according to the user's needs. Thus, the correct mounting of the remote NFS shared directory on the client is achieved through an automated process, which provides necessary preparations for subsequent IO testing or other operations.

[0044] In an embodiment of the present application, mounting the business address to the local mount directory includes: identifying the type of the business address, determining the target mount format according to the type; and mounting the business address on the local mount directory using the target mount format.

[0045] The types of business addresses include IPv4 addresses and IPv6 addresses. The target mount format is the corresponding mount command format determined by the type of business address. For example, IPv4 addresses may directly use the standard mount syntax, while IPv6 addresses require square brackets around the address.

[0046] It can be understood that the embodiment of the present application mounts the business address to the local mount directory. First, it is necessary to identify the type of the business address, that is, to determine whether it is an IPv4 address or an IPv6 address. Based on the identified address type, a suitable target mount format is selected. For example, if the business address is an IPv4 address, one mount format is used; if it is an IPv6 address, the mount format needs to be adjusted to adapt to the IPv6 specification (such as adding square brackets around the IPv6 address). Subsequently, the determined target mount format is used to mount the business address in the local mount directory on the client, ensuring that no matter what type the business address is, it can be mounted correctly to the specified local directory, laying the foundation for subsequent IO testing or other operations.

[0047] In step S203, a test configuration file is generated according to the test configuration parameters in the test configuration information, and the test configuration file is written to at least one client based on the login information. The client tests the shared access storage function of the storage device based on the test configuration file.

[0048] Among them, the test configuration information contains all the information required for IO performance testing, such as the number of threads, read-write ratio, file size, etc.; the test configuration parameters will be described in detail below and will not be repeated here; the test configuration file is a file generated based on the test configuration parameters, which is used to guide the test tool on how to perform specific test tasks.

[0049] It can be understood that the embodiment of the present application can automatically generate a corresponding test configuration file based on the specific test configuration parameters in the test configuration information, and use the provided login information to deploy the test configuration file to at least one client. Based on the received test configuration file, the client uses the parameters defined therein to test the shared access storage function of the storage device. The entire process ensures that the test can be automatically executed according to the preset requirements, and effectively evaluates the performance and stability of the NFS share. In this way, the IO test and verification of the NAS NFS share can be completed efficiently and accurately.

[0050] In an embodiment of the present application, the test configuration parameters include at least one of the file size and the number of files, and the test configuration file is written to at least one client based on the login information, and further includes: logging in to the client based on the login information; determining the target space required for the test configuration file based on at least one of the file size and the number of files, and obtaining the actual space of the client's local mount directory; updating the file size or number of files of the configuration file based on the target space and the actual space, and writing the updated configuration file to at least one client.

[0051] The target space is the required storage space calculated based on the file size and number of files provided by the user. If both the file size and the number of files are provided, the target space is the product of the two. If only one parameter is provided, the other parameter must be calculated based on the actual situation. The actual space refers to the actual available storage space of the local mounted directory on the client.

[0052] It can be understood that the embodiment of the present application logs in to at least one client based on login information, and determines the target space required for the test configuration file based on at least one of the file size and the number of files in the test configuration parameters, obtains the actual available space of the client's local mount directory, and adjusts the file size or number of files in the test configuration file based on the comparison between the calculated target space requirement and the actual space to ensure that the test task can be effectively executed within the actual available space range. Finally, the adjusted and updated configuration file is written to the client, so that the client can accurately test the shared access storage function of the storage device according to the finally confirmed configuration parameters, ensuring that the test not only meets the user's initial settings, but also runs smoothly within physical limitations.

[0053] In an embodiment of the present application, before writing the test configuration file to at least one client based on the login information, it also includes: identifying whether the user expects to turn on the data verification function; if it is identified that the user expects to turn on the data verification function, determining the size of data transmitted each time, and setting the test configuration file size to an integer multiple of the size of data transmitted each time.

[0054] The test configuration file size is set to an integer multiple of the size of each transmitted data in order to ensure that the verification requirements of the test tool are met and that all transmitted data can be correctly verified.

[0055] It can be understood that before writing the test configuration file to at least one client according to the login information, the embodiment of the present application will first identify whether the user wishes to enable the data verification function. If it is identified that the user wants to enable this function, the size of the data transmitted each time is further determined. Subsequently, the file size in the test configuration file is adjusted to ensure that it is an integer multiple of the size of the data transmitted each time to maintain data integrity and accuracy, and ensure that when data verification is enabled, all transmitted data can be correctly checked and verified, thereby improving the reliability and accuracy of the test results. After completing these steps, the updated test configuration file will be written to the client in preparation for subsequent IO testing.

[0056] According to the testing method for the shared access storage function provided in the embodiment of the present application, a shared directory of the shared access storage space can be created through a storage device, and a test component is used to obtain at least one of the shared directory information, mounting information, login information, and test configuration information. The shared directory is mounted on the client, and a test configuration file is generated according to the test configuration parameters. The test configuration file is written to at least one client, and the client tests the shared access storage function of the storage device, realizing one-click startup of automated IO testing and confirmation of execution results, thereby achieving the technical effect of avoiding tedious operations of users and improving test efficiency and accuracy.

[0057] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0058] For descriptions of features in the embodiment corresponding to the test method for shared access to storage function, reference may be made to the relevant descriptions of the embodiment corresponding to the test system for shared access to storage function, which will not be described in detail here.

[0059] The embodiment of the present application also provides an electronic device, such as Figure 6 As shown, it includes a memory 301 and a processor 302. The memory 301 stores a computer program, and the processor 302 is configured to run the computer program to execute the steps in the embodiment of the test method for shared access to storage function.

[0060] An embodiment of the present application further provides a non-volatile computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of the above-mentioned test method embodiment of the shared access storage function when running.

[0061] In an exemplary embodiment, the non-volatile computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0062] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in the embodiment of the test method for shared access to storage function are implemented.

[0063] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps in the above-mentioned test method embodiment for shared access storage function.

[0064] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0065] The above is a detailed introduction to the test system, method, device, medium and product for shared access storage function provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A test system for shared access storage function, characterized in that: include: A storage device, the storage device comprising at least one storage node, configuring a shared access storage space at any storage node, and creating a shared directory of the shared access storage space; at least one client, configured to configure and use the shared access storage space of the storage device; a test component configured to obtain at least one of shared directory information, mount information, login information, and test configuration information, mount the shared directory to the client according to at least one of the shared directory information and mount parameters in the mount information, generate a test configuration file according to the test configuration parameters in the test configuration information, and write the test configuration file to at least one of the clients based on the login information; The client tests the shared access storage function of the storage device based on the test configuration file.

2. The test system for shared access storage function according to claim 1, characterized in that: A test tool is configured on the client, and the test tool generates a test load according to the test configuration file, and performs at least one of a read operation and a write operation on the shared access storage space based on the test load.

3. The test system for shared access storage function according to claim 2, characterized in that: The test component logs in to the client based on the login information, detects whether the client is configured with the test tool, and installs the test tool on the client if the client is not configured with the test tool.

4. A method for testing a shared access storage function, characterized in that: The method is applied to a test component of a test system for shared access storage functions according to any one of claims 1 to 3, wherein the method comprises: Obtain at least one of shared directory information, mount information, login information, and test configuration information; Mounting the shared directory to the client according to at least one of the shared directory information and the mount parameter in the mount information; A test configuration file is generated according to the test configuration parameters in the test configuration information, and the test configuration file is written into at least one of the clients based on the login information. The client tests the shared access storage function of the storage device based on the test configuration file.

5. The method for testing the shared access storage function according to claim 4, wherein: Mounting the shared directory to the client according to at least one of the shared directory information and the mount parameter includes: Extracting the shared directory name from the shared directory information; querying a business address of a corresponding target storage node from a storage device based on the shared directory name, wherein the target storage node has the shared access storage space created therein; A local mount directory is created on the client, and the service address is mounted to the local mount directory. If the mount parameters exist, the mount parameters are carried during the mounting.

6. The method for testing the shared access storage function according to claim 5, characterized in that: Mounting the business address to the local mount directory includes: Identifying the type of the business address and determining a target mount format according to the type; The business address is mounted on the local mount directory using the target mount format.

7. The method for testing the shared access storage function according to claim 4, wherein: The test configuration parameter includes at least one of a file size and a number of files, and the step of writing the test configuration file to at least one of the clients based on the login information further includes: Logging in to the client based on the login information; Determine the target space required for the test configuration file based on at least one of the file size and the number of files, and obtain the actual space of the local mount directory of the client; The file size or the number of files of the configuration file is updated according to the target space and the actual space, and the updated configuration file is written into at least one of the clients.

8. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the method for testing the shared access storage function as claimed in any one of claims 4 to 7 when executing the computer program.

9. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the test method for shared access storage function according to any one of claims 4 to 7 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method for testing a shared access storage function as claimed in any one of claims 4 to 7 are implemented.

Images