Hi all! As promised, we are publishing the results of a load test of a Russian-made data storage system - AERODISK ENGINE N2.
In the last article, we broke the storage system (that is, we performed crash tests) and the crash test results were positive (that is, we did not break the storage system). Crash test results are available .
In the comments to the previous article, wishes were made for additional - more tricky crash tests. We have fixed them all and will definitely implement them in one of the following articles. At the same time, you can visit our laboratory in Moscow at any time (come by foot or do it remotely via the Internet) and perform these tests yourself (you can even do testing for a specific project :-)). Write to us, we will consider all scenarios!
In addition, if you are not in Moscow, you can still get to know our storage system better by attending a free training event at the Competence Center in your nearest city.
Below is a list of upcoming events and dates for the centers of excellence.
- Ekaterinburg. May 16, 2019. Educational seminar. You can register using the link:
- Ekaterinburg. May 20 - June 21, 2019. Competence center. Come to a live demonstration of the AERODISK ENGINE N2 storage system at any working time. The exact address and registration link will be later. Follow the information.
- Novosibirsk. FOLLOW THE INFORMATION ON OUR SITE or on HABR.
October 2019 years - Kazan. FOLLOW THE INFORMATION ON OUR SITE or on HABR.
October 2019 years - Krasnoyarsk. FOLLOW THE INFORMATION ON OUR SITE or on HABR.
November 2019 years
We also want to share one more good news: we finally have our channel where you can watch videos from past events. We also regularly post our training videos there.
Test stand
So, back to the tests. We upgraded our laboratory ENGINE N2 storage system with additional SAS SSD drives, as well as Fiber Channel 16G Front-end adapters. In a symmetrical way, we upgraded the server from which we will start the load by adding FC 16G adapters there.
As a result, in our lab we have a 2-controller storage system with 24 SAS SSD 1,6 TB, 3 DWPD disks, which is connected via SAN switches to a physical Linux server via FC 16G.
The scheme of the test stand in the figure below.
Testing technique
For the best performance on block access, we will use DDP (Dynamic Disk Pool) pools, which we once created just for ALL-FLASH systems.
For testing, we created two LUNs of 1 TB each with a RAID-10 protection level. We will βspreadβ each LUN across 12 disks (24 in total) in order to fully use the potential of each of the installed disks in the storage system.
We present LUNs to the server through different controllers in order to maximize the utilization of storage resources.
Each of the tests will last one hour, and the tests will be performed by the Flexible IO (FIO) program, FIO data is automatically uploaded to Excel, in which graphs are already built, for clarity.
Load profiles
In total, we will perform three tests for one hour each, excluding the warm-up time, for which we allocate 15 minutes (that's how long it takes to warm up an array of 24 SSD drives). These tests emulate the most common load profiles we encounter, in particular, these or those DBMS, video surveillance systems, media content broadcasts and backup.
Also, in all tests, we deliberately disabled the possibility of caching to RAM on the storage system and on the host. Of course, this will worsen the results, but, in our opinion, in such conditions the test will be more honest.
Test results
Test number 1. Random loading in small blocks. Emulation of a highly loaded transactional DBMS.
- Block size = 4k
- Read/Write = 70%/30%
- Number of works = 16
- Queue Depth = 32
- Load Character = Full Random
Test results:
In total, with the younger mid-range Engine N2 system, we received 438k IOPS with delays of 2,6 milliseconds. Given the class of the system, in our opinion, the result is quite worthy. To understand if this is the limit for the system, we'll look at storage controller resource utilization.
We are primarily interested in the CPU, because, as mentioned above, we deliberately disabled the RAM cache so as not to distort the test results.
On both storage controllers, we see approximately the same picture.
That is, the load on the CPU is 50%. This suggests that this is far from the limit of this storage system and you can still easily scale it. Let's jump ahead a little: all the following tests also showed the load on the processors of the controllers in the region of 50%, so we won't give them again.
Based on our lab tests, the comfort limit of the AERODISK Engine N2 system, when counting random IOPS at 4k blocks, is ~700 IOPS. If this is not enough and you need to strive for a million, then we have the older model ENGINE N000.
That is, the story about millions of IOPS is ENGINE N4, and if a million is too much for you, then calmly use N2.
We return to the tests.
Test number 2. Sequential recording in large blocks. Emulation of video surveillance systems, loading data into an analytical DBMS or recording backups.
In this test, we are no longer interested in IOPS, since they do not make any sense with a sequential load in large blocks. First of all, we are interested in: the write stream (megabytes per second) and delays, which, of course, will be higher with large blocks than with small ones.
- Block size = 128k
- Read/Write = 0%/100%
- Number of works = 16
- Queue Depth = 32
- The nature of the load - Sequential
Total: we have a record of five and a half gigabytes per second with delays of eleven milliseconds. If compared with the closest foreign competitors, the result, in our opinion, is excellent, and is also not the limit of the ENGINE N2 system.
Test number 3. Sequential reading in large blocks. Emulation of broadcasting media content, generating reports from an analytical DBMS or restoring data from backups.
As in the previous test, we are interested in flow and delays.
- Block size = 128k
- Read/Write = 100%/0%
- Number of works = 16
- Queue Depth = 32
- The nature of the load - Sequential
The performance of streaming reading is predictably slightly better than that of streaming writing.
Interestingly, the latency score across the entire test is identical (straight line). This is not an error, with sequential reading in large blocks, in our case this is a common situation.
Of course, if we leave the system in this form for a couple of weeks, we will eventually see periodic jumps on the charts, which will be associated with external factors. But, in general, they will not affect the picture.
Conclusions
With the dual-controller system AERODISK ENGINE N2, we were able to squeeze out quite serious performance (~ 438 IOPS and ~ 000-5 gigabytes per second). Load tests showed that we are definitely not ashamed of our storage system. On the contrary, the indicators are very decent and correspond to a good storage system.
Although, as we wrote above, Engine N2 is a junior model, and besides, the results shown in this article are not its limit. Later we will publish a similar test from our older ENGINE N4 system.
Naturally, within the framework of one article, we cannot cover all possible tests, therefore, once again calling on readers to share their wishes for future tests in the comments, we will definitely take them into account in future publications.
In addition, we remind you that this year we are actively engaged in training, so we invite you to our competence centers, where you can get training on AERODISK storage systems, and at the same time have an interesting and fun time.
Duplicate information about upcoming training events.
- Ekaterinburg. May 16, 2019. Educational seminar. You can register using the link:
- Ekaterinburg. May 20 - June 21, 2019. Competence center. Come to a live demonstration of the AERODISK ENGINE N2 storage system at any working time. The exact address and registration link will be later. Follow the information.
- Novosibirsk. FOLLOW THE INFORMATION ON OUR SITE or on HABR.
October 2019 years - Kazan. FOLLOW THE INFORMATION ON OUR SITE or on HABR.
October 2019 years - Krasnoyarsk. FOLLOW THE INFORMATION ON OUR SITE or on HABR.
November 2019 years
Source: habr.com