{"id":12502,"date":"2019-07-10T07:39:14","date_gmt":"2019-07-10T05:39:14","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/huawei-dorado-6000-v3-benchmark\/"},"modified":"2019-07-10T07:39:14","modified_gmt":"2019-07-10T05:39:14","slug":"huawei-dorado-6000-v3-benchmark","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/huawei-dorado-6000-v3-benchmark\/","title":{"rendered":"Huawei Dorado 6000 V3 benchmark"},"content":{"rendered":"

I had the opportunity to test the new Dorada 6000 V3 All-Flash storage system.
\nSee what the all-new Dorado 6000 V3 All-Flash Storage system is capable as storage for your database system.<\/p>\n

<\/p>\n

Before you read<\/h2>\n

This is a series of different blog posts:
\nIn the first blog post, I talk about \u201cWhat you should measure on your database storage and why\u201d<\/a>.
\nThe second blog post will talk about \u201cHow to do database storage performance benchmark with FIO\u201d<\/a>.
\nThe third blog post will show \u201cHow good is the new HUAWEI Dorada 6000V3 All-Flash System for databases\u201d<\/a> measured with the methods and tools from post one and two (aka this one here).<\/p>\n

The first two posts give you the theory to understand all the graphics and numbers I will show in the third blog post.<\/p>\n

So in this post, we see, what are the results when we test a Huawei Dorado 6000V3 All-Flash storage system with these technics.<\/p>\n

I uploaded all the files to a github repository: Huawei-Dorado6000V3-Benchmark<\/a>.<\/p>\n

Foreword <\/h3>\n

The setup was provided by Huawei in Shengsen, China. I’ve got remote access with a timeout at a certain point. Every test run runs for 10h, because of the timeout I was sometimes not able to capture all performance view pictures. That’s why some of the pictures are missing. Storage array and servers were provided free of charge, there was no exercise of influence from Huawei on the results or conclusion in any way.<\/p>\n

Setup <\/h3>\n

4 Server were. provided, each with 4×16 GBit\/s FC adapter direct connected to the storage systems.
\nThere are 256 GByte of memory installed and 2x 14 Cores 2.6 GHz E5-2690 Intel CPUs.
\nHyperthreading is disabled.
\nThe 10 GBit\/s network interfaces are irrelevant for this test here because all storage. traffic runs over FC.<\/p>\n

The Dorado 6000 V3 System has 1 TByte of cache and 50x 900 GByte SSD from Huawei.
\nDeduplication was disabled.
\nTests were made with and without compression.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

Theoretical max speed <\/h3>\n

With 4x16GBit\/s a maximal throughput of 64 GBit\/s or 8 GByte\/s is possible.
\nIn IOPS this means we can transmit 8192 IOPS with 1 MByte block size or 1’048’576 IOPS with 8 KByte block size.
\nAs mentioned in the title, this is theoretically or raw bandwidth, the usable bandwidth or payload is, of course, smaller: A FC-frames is 2112 bytes with 36 bytes of protocol overhead.
\nSo in a 64 GBit\/s FC network we can transfer: 64GBit\/s \/ 8 ==> 8GByte\/s * 1024 ==> 8192 MByte\/s (raw) * (100-(36\/2.112))\/100 ==> 6795MByte\/s (payload).<\/p>\n

So we end up with a maximum of 6975 IOPS@1MByte or 869’841 IOPS@8KByte (payload) not included is the effect, that we are using multipathing* with 4x16GBit\/s, which will also consume some power.<\/p>\n

*If somebody out there has a method to calculate the overhead of multipathing in such a setup, please contact me!<\/p>\n

Single-Server Results <\/h3>\n

General<\/h4>\n

All single server tests were made on devices with enabled data compression. Unfortunately, I do not have the results from my tests with uncompressed devices for single server anymore, but you can see the difference in the multi-server section.<\/p>\n

8 KByte block size<\/h4>\n

The 8 KByte block size tests on a single server were very performant.
\nWhat we can already tell, as higher the parallelity as better the storage performs. This is not really a surprise. Most storage systems work better, as higher the parallel access is.
\nSpecialy for 1 thread, we see the differenc between having one disk in a diskgroup and be able to use 3967 IOPS or using e.g. 5 disks and 1 thread an be able to use 16700 IOPS.
\nThe latency for all tests was great with 0.25ms to 0.4ms for reading operation and 0.1 to 0.4ms for write operations.
\nThe 0.1ms for write is not that impressive, because it is mainly the performance of the write cache, but even when we exceeded the write cache we were not higher then 0.4ms<\/p>\n