High-consistency storage distributed performance tester system

Abstract

The invention particularly relates to a high-consistency storage distributed performance testing system. According to the high-consistency storage distributed performance tester system, a master-slave architecture is adopted, and a master management node is used for configuring and starting a test environment, issuing a test task to each work execution node, collecting and integrating test results, and analyzing and generating a summary report; the work execution nodes are distributed on the cloud hard disk associated virtual machines and are used for receiving issued test tasks; and preparing a test environment, executing a test script, simulating an actual workload, reporting a test result to the main management node, and cleaning test residues. According to the high-consistency storage distributed performance testing system, the concurrency bottleneck of a traditional single-node test is broken through, the authenticity of a test scene is ensured, the interference of factors such as cache is reduced, a test result is closer to the system performance under the actual working load, and the test efficiency and the result repeatability are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and particularly relates to a strong-consistency storage distributed performance test system. BACKGROUND

[0002] With the rapid development of cloud computing technology and the explosive growth of data scale, the performance of the storage system as the core infrastructure supporting the upper-layer application directly affects the business continuity and user experience. Block storage technology has become the mainstream data storage solution in the cloud environment due to its fine resource management, low-latency access, and high reliability, etc.

[0003] The traditional storage performance test method mostly uses a single client to simulate user operations. This mode can reflect the basic performance indicators in a simple scenario, but it is difficult to fully expose the potential bottlenecks of the system in a real high-concurrency environment.

[0004] On the one hand, single-point testing is often limited by the processing speed of the client itself and the network bandwidth, and cannot truly reflect the performance of the system in a high-concurrency scenario. It cannot simulate the resource competition and scheduling overhead when multiple users and multiple tasks access in parallel, resulting in an underestimate of the system performance evaluation.

[0005] On the other hand, manual performance testing is not only time-consuming and laborious, but also faces problems such as poor operation synchronization, difficulty in standardizing and automating the testing process, etc. At the same time, without a unified clock and control logic, it is difficult to ensure that all clients complete the specified test actions within the same time period, resulting in a significant deviation of the test results from the actual production environment performance, further increasing the uncertainty of the test results.

[0006] In addition, with the popularity of distributed architecture, the coupling degree of the storage system and the computing node is reduced, and factors such as cross-node access and network delay further aggravate the complexity of performance evaluation.

[0007] Therefore, it is particularly urgent to develop a distributed performance test system that can simulate real high-concurrency access, ensure high synchronization of test instructions, and automatically execute.

[0008] Based on the above situation, the present application provides a strong-consistency storage distributed performance test system. SUMMARY

[0009] The present application provides a simple and efficient strong-consistency storage distributed performance test system to overcome the defects of the prior art.

[0010] The present application is implemented by the following technical solutions:

[0011] A kind of strong consistency storage distributed performance test party system, using master-slave architecture, including master node (master node) and working execution node (worker node);

[0012] The master node (master node) is used to:

[0013] Configure and start test environment, including loading worker node information, target cloud hard disk file system type, test tool and script;

[0014] Test task is issued to each working execution node (worker node);

[0015] Collect and integrate the test results reported by working execution node (worker node);

[0016] Analysis test data and generate summary report;

[0017] The working execution node (worker node) is distributed on each cloud hard disk associated virtual machine, for:

[0018] Receive the test task issued by master node (master node);

[0019] Prepare test environment, including creating test directory, formatting and establishing file system and mounting file system;

[0020] Execute test script, simulate actual workload, including new file, get file attribute, modify file attribute, sequential read, random read, append write, random write, file move, file deletion, directory creation, browse directory content, directory deletion and directory move;

[0021] Report test results to master node (master node), and clean up test residues.

[0022] When the master node (master node) configures and starts test environment, load configuration file containing working execution node (worker node) details, target cloud hard disk file system type, selected test tool and script, and start test management system by executing java-jar command.

[0023] The master node distributes the test system to each worker node based on the test scheme and executes the java-jar command to activate the test execution environment on each worker node after confirming that all worker nodes have been successfully deployed and are ready.

[0024] The worker node starts the test task, creates a test directory, formats and establishes a file system, mounts the new file system to the test directory, and finally uses the specified test tool and script to carry out performance testing in the test directory.

[0025] The worker node uses a triple guarantee mechanism to ensure that the test results are close to reality and are not affected by cache interference when performing random read and write operations.

[0026] The triple guarantee mechanism includes random file selection, random selection of file read / write offset, and use of Direct I / O mode for file read / write operations.

[0027] When performing the test task, the worker node calls the pwrite function of the operating system to perform the write operation and the pread function to perform the read operation.

[0028] When performing file read / write operations, the worker node passes in the O_DIRECT flag to notify the operating system to use the Direct I / O mode.

[0029] The worker node uses an optimization strategy to randomly determine the offset of the file, as follows:

[0030] (1) Get the largest file and set the random number range, which is 0 to the number of file blocks.

[0031] (2) Randomly determine a number within the set random number range as the global random number.

[0032] (3) Use the global random number to divide the product of the number of file blocks to be read and written and the block size to obtain the offset of the file.

[0033] After the test is completed, the worker node feeds back the test data to the master node, and cleans up the test residues by using the rm-rf and umount commands to restore the initial state; the master node then gathers all the reported test results and integrates them into the summary report.

[0034] The strong consistency storage distributed performance test system of the application breaks through the concurrent bottleneck of traditional single-node testing, ensures the authenticity of the test scene, reduces the interference of factors such as cache, makes the test result closer to the system performance under actual work load, and significantly improves the test efficiency and result repeatability. BRIEF DESCRIPTION OF DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0036] Figure 1 The strong consistency storage distributed performance test system of the application is shown in the figure. DETAILED DESCRIPTION

[0037] In order to make the person skilled in the art better understand the technical solutions in the present application, the following will combine the embodiments of the present application to make a clear and complete description of the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should belong to the scope of protection of the present application.

[0038] Block storage, as a mature data storage solution, presents storage resources to users in the unit of fine-grained "data blocks", each of which represents a piece of independent and continuous hard disk space. Cloud disk is a virtual block storage service specially designed for virtual machine environment. It creates a storage solution with low cost, high reliability and flexible expansion capacity by flexibly allocating a predetermined capacity. Users can freely build file systems such as ext4 and xfs on this basis to fully realize the potential of cloud disk. However, when evaluating the performance peak of such systems, single-client testing often fails to fully exploit the potential of the server. Therefore, deploying multiple clients to mount the same cloud disk together and exerting maximum pressure on the system has become a necessary means to test its true performance limit. Artificially performing such tests is not only a tedious procedure that is difficult to automate, but also difficult to ensure that all clients operate synchronously, resulting in test results that may deviate from the actual performance indicators of the system.

[0039] The strong consistency storage distributed performance test system adopts a master-slave architecture, including a master node and a worker node, realizes centralized and efficient test management, and distributed and flexible test execution.

[0040] The master node is configured to:

[0041] Configure and start the test environment, including loading worker node information, target cloud disk file system type, test tools and scripts;

[0042] Distribute test tasks to each worker node;

[0043] Collect and integrate test results reported by the worker nodes;

[0044] Analyze test data and generate a summary report;

[0045] The worker node is distributed on each cloud disk associated virtual machine and is configured to:

[0046] Receive test tasks distributed by the master node;

[0047] Prepare the test environment, including creating a test directory, formatting and establishing a file system, and mounting the file system;

[0048] The test script is executed to simulate the actual workload. The worker node needs to be able to fully simulate the actual work pressure, so when executing the command, more extensive operations should be included, including creating a new file, obtaining file attributes, modifying file attributes, sequential reading, random reading, appending writing, random writing, file moving, file deleting, directory creating, browsing directory content, directory deleting and directory moving;

[0049] The test results are reported to the master node, and the test residues are cleaned up.

[0050] When the master node is configured and started, the configuration file containing the details of the worker node, the target cloud hard disk file system type, the selected test tool and the script is loaded, and the test management system is started by executing the java-jar command.

[0051] When the master node is configured and deployed to the worker node, according to the worker node information recorded in the configuration file, after confirming that all worker nodes have been successfully deployed and are on standby, based on the pre-planned test scheme, the test system is distributed to each worker node using the scp command, and the java-jar command is executed on each worker node to activate the respective test execution environment.

[0052] After receiving the instruction, the worker node starts the test task, strictly follows the preset test procedure, creates a test directory (mkdir), formats and establishes a file system (mkfs.X) according to the requirements, mounts the new file system to the test directory (mount), and finally uses the specified test tool and script to carry out performance testing in the test directory, simulating user interaction and system load in real application scenarios.

[0053] When the worker node performs random reading and random writing operations, a triple guarantee mechanism is adopted to ensure that the test results are close to reality and are not affected by cache interference.

[0054] The triple guarantee mechanism includes random file selection, random selection of file reading and writing offset position, and use of DirectI / O mode for file reading and writing operations.

[0055] The worker node calls the pwrite function of the operating system to perform a write operation and calls the pread function to perform a read operation when performing a test task; before calling, the pwrite function and the pread function are respectively configured with parameters of a file descriptor, a buffer address, a file offset, and a content size.

[0056] When the worker node performs a file read / write operation, in order to prevent potential interference of page cache on the test conclusion, the operating system is notified to use the Direct I / O mode by passing in the O_DIRECT flag; it should be noted that the O_DIRECT macro definition of different operating systems is not necessarily the same. For example, in the Galaxy Kirin operating system environment, the O_DIRECT macro is mapped to the integer value 0200000; in contrast, in the Ubuntu operating system, it is defined as 040000. Therefore, the performance test tool needs to be able to identify the current operating system version and dynamically adapt the correct integer value corresponding to O_DIRECT according to different operating systems to ensure consistency and effectiveness across platforms.

[0057] In order to prevent the CPU resources from being burdened when generating random numbers, the worker node uses an optimization strategy to randomly determine the offset of the file, the process being as follows:

[0058] (1) Obtain the largest file and set the random number range, which is 0 to the number of file blocks (assuming that the file size is 1MB and the block size is 4KB, the random number range in this case is 0-256).

[0059] (2) Randomly determine a number in the set random number range as the global random number;

[0060] (3) Divide the product of the global random number and the number of file blocks to be read / written and the block size to obtain the offset of the file.

[0061] Through the above method, the random file read / write offset is selected using one random number, which effectively controls the resource consumption while ensuring randomness.

[0062] After the test is completed, the worker node quickly feeds back the test data to the master node, and cleans up the test residues through the rm-rf and umount commands to restore the initial state; the master node then gathers all the reported test results and integrates them into the summary report in detail to provide detailed data support for the technical team and operation and maintenance personnel, and to assist in in-depth analysis.

[0063] The strong consistency storage distributed performance test system effectively solves the limitations of traditional single-point testing, provides a quantifiable performance benchmark for cloud storage services, and is particularly suitable for storage performance evaluation scenarios in a hybrid cloud environment due to its cross-platform design and anti-interference technology.

[0064] Compared with the prior art, the system has the following characteristics:

[0065] 1) The master-slave architecture is used to realize multi-client concurrent loading, simulate the extreme pressure of million-level I / O requests in a real business scenario, and break through the concurrency bottleneck of traditional single-node testing.

[0066] 2) Centralized task scheduling and distributed execution realize the full life cycle automation of test environment deployment, load generation, data collection and result analysis, and significantly improve the test efficiency and result repeatability.

[0067] 3) The test instructions cover a wide range of file operations, combined with random number optimization strategy and Direct I / O mode, to ensure the authenticity of the test scenario, reduce the interference of factors such as cache, and make the test results closer to the system performance under actual work load.

[0068] The above-described embodiments are only one of the specific embodiments of the present application, and the usual changes and substitutions made by those skilled in the art within the scope of the technical solutions of the present application should be included in the protection scope of the present application.

Claims

1. A strong consistency distributed storage performance testing system, characterized in that: It adopts a master-slave architecture, including a master management node and worker execution nodes; The main management node is used for: Configure and start the test environment, including loading worker node information, target cloud disk file system type, test tools and scripts; Distribute the test tasks to each work execution node; Collect and integrate the test results reported by the work execution nodes; Analyze test data and generate a summary report; The execution nodes are distributed across virtual machines associated with each cloud disk and are used for: Receive test tasks issued by the main management node; Prepare the test environment, including creating the test directory, formatting and establishing the file system, and mounting the file system; Execute test scripts to simulate real workloads, including creating files, getting file attributes, modifying file attributes, sequential reading, random reading, appending, random writing, moving files, deleting files, creating directories, browsing directory contents, deleting directories, and moving directories. The test results are reported to the main management node, and test remnants are cleaned up.

2. The strongly consistent distributed storage performance testing system according to claim 1, characterized in that: When configuring and starting the test environment, the main management node loads a configuration file containing details of the worker execution nodes, the target cloud disk file system type, the selected test tools and scripts, and starts the test management system by executing the java-jar command.

3. The strongly consistent distributed storage performance testing system according to claim 2, characterized in that: When configuring and deploying to the worker execution nodes, the main management node, based on the worker execution node information recorded in the configuration file, after confirming that all worker execution nodes have been successfully deployed and are ready, uses the scp command to distribute the test system to each worker execution node according to the pre-planned test scheme, and executes the java-jar command on each worker execution node to activate its respective test execution environment.

4. The strongly consistent distributed storage performance testing system according to claim 1, characterized in that: After receiving the instruction, the execution node starts the test task, follows the preset test procedure, creates a test directory, formats and establishes a file system according to the requirements, mounts the new file system to the test directory, and finally uses the specified test tools and scripts to carry out performance testing in the test directory, comprehensively simulating user interaction and system load under real application scenarios.

5. The strongly consistent distributed storage performance testing system according to claim 1, characterized in that: When performing random read and random write operations, the execution node employs a triple guarantee mechanism to ensure that the test results closely reflect reality and are not affected by cache interference. The triple guarantee mechanism includes random file selection, random selection of the offset position for file reading and writing, and use of Direct I / O mode for file reading and writing operations.

6. The strongly consistent distributed storage performance testing system according to claim 5, characterized in that: When the execution node performs a test task, it calls the operating system's pwrite function to perform a write operation and the pread function to perform a read operation. Before the call, the parameters of the configuration file descriptor, buffer address, file offset, and content size are configured for the pwrite function and the pread function, respectively.

7. The strongly consistent distributed storage performance testing system according to claim 6, characterized in that: When performing file read / write operations, the worker execution node notifies the operating system to use Direct I / O mode by passing in the O_DIRECT flag. The performance testing tool can identify the current operating system version and dynamically adapt the correct integer value corresponding to O_DIRECT according to different operating systems.

8. The strongly consistent distributed storage performance testing system according to claim 7, characterized in that: The execution node uses an optimization strategy to randomly determine the file offset, as follows: (1) Get the largest file and set a random number range, from 0 to the number of file blocks; (2) Select a random number from the set random number range and determine it as the global random number; (3) Use a global random number to divide the product of the number of file blocks to be read and the block size to obtain the file offset.

9. The strongly consistent distributed storage performance testing system according to claim 1, characterized in that: After the test is completed, the working execution node reports the test data back to the main management node and cleans up test remnants and restores the initial state using the rm-rf and umount commands; the main management node then gathers all reported test results and integrates them into a summary report.

Images