DellEMC Unity 400F: небольшое тестирование

В начале мая 2016 года, еще до окончания объединения с Dell, компания EMC2 объявила о выходе нового поколения массивов среднего уровня под именем Unity. В сентябре 2016 года к нам привезли демо-массив Unty 400F в конфигурации с 10 SSD дисками на 1.6TB каждый. В чем различие между моделями с индексом F и без оного можете почитать по данной ссылке в блоге Дениса Серова. Так как перед передачей демо дальше заказчику возник временной лаг, то было принято решение погонять массив тем же самым тестом, которым ранее уже нагружались VNXe3200 и VNX5400. Что бы посмотреть хотя бы на «синтетике» так ли хорош Unity по сравнению с предыдущими поколениями массивов EMC2, как это расписывает вендор. Тем более что, судя по презентациям вендора, Unity 400 является прямой заменой VNX5400.

9cd63a46e4894af6b2e49f074044c5f6.jpg

А DellEMC утверждает, что новое поколение по крайней мере в 3 раза производительнее, чем VNX2.
Если интересно, что из всего этого вышло, то…

Описание стенда и теста


Под спойлером
Изначально для тестирования был собран стенд все из того же старого HP DL360 G5 c 1 CPU (4-core) и ОЗУ 4GB. Только в PCI-E слоты были поставлены две одно-портовые 8Gb/s HBA Emulex LPE1250-E, подключенные напрямую к FC 16Gb/s портам Unity 400F. Как выяснилось чуть позже, производительности CPU данного сервера оказалось недостаточно, что бы загрузить СХД. По этому, как дополнительный источник генерации IOPS, к массиву был подключен Blade HP BL460c G7 c 1 CPU (12-core) и ОЗУ 24GB. Правда в Blade корзине стоят FC-свитчи с портами на 4G. Но как говориться «дареному коню в зубы не смотрят». Других вычислителей под рукой все равно не было. На серверах использовалась OS Win2012R2 SP1 и софт PowerPath от компании EMC2 для управления путями доступа к LUN.
На массиве Unity 400F был создан пул в конфигурации Raid5 (8+1). На пуле разместились два тестовых LUN, которые были подключены к серверам. На LUN-ах были созданы файловые системы NTFS и тестовые файлы размером 400GB, что бы исключить влияние кэш контроллеров на результат.

Настройки в IOMETER при этом выглядят следующим образом:
5181e8f0ba3645dcaee31aeeba17bd2a.jpg

7e119492a11f4406b14455a8b8b7e74d.jpg

Т.е. на каждом сервере работало по 4 worker-а (всего 8), на которых на каждом последующем этапе тестирования двухкратно увеличивалось количество потоков ввода\вывода. Таким образом на каждый worker последовательно 1, 2, 4, 16, 32, 64, 128, 256, 512 потоков. А всего на массив приходилось на каждом этапе по 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096 потоков.


По традиции немного расчетов


DellEMC при расчетах производительности рекомендует для SSD дисков использовать максимальное значение в 20000 IOPS.

4f2ca7d324b94ce99bffd652addbc88d.jpg

То есть максимально в теории наши 9 дисков могут выдать 20000×9=180000 IOPS. Нам необходимо посчитать сколько IOPS получат с этих дисков сервера, с учетом нашего профиля нагрузки. Где соотношение чтения/записи в процентном отношении составляет 67%/33%. И еще нужно учесть накладные расходы на запись в RAID5. Получаем следующее уравнение с одной неизвестной 180000=X*0.33*4+X*0.67. Где X это у нас те IOPS, которые получат сервера с наших дисков, а 4 — это размер «пенальти» на запись для Raid5. В итоге получаем в среднем X=180000/1.99= ~90452 IOPS.

Тест и Результаты


В результате теста у нас получилась следующая зависимость IOPS от количества потоков I/O:

cf0dde64d12a4429acb5c8445e476669.jpg

По графику хорошо видно, что насыщение наступило при 512 потоках I/O на тестируемые LUN-ы и при этом было достигнуто значение примерно в 142000 IOPS. Если посмотреть на тестирование VNX5400, то видно, что даже при тестировании кэша контроллеров, максимальные значения по IOPS не превышали порога в 32000 IOPS. А насыщение массива VNX5400 по вводу/выводу наступало примерно на 48 потоках. Тут еще нужно отметить, что один сервер HP DL360 G5, в описанной выше конфигурации, выдавал в максимуме около 72000 IOPS. После чего упирался в 100% загрузки CPU. Почему собственно и пришлось искать второй «вычислитель».

У Unity есть не плохой функционал сбора статистики производительности по различным компонентам массива. Так например можно посмотреть графики нагрузки по IOPS по дискам массива (по каждому в отдельности или сразу по всем).

47c4e93134e1405cb7882def10daf5e3.jpg

84f82c2d5f9b45b59783833314ba3c45.jpg

Из графика видно, что в максимуме диски выдают «несколько» больше, чем значение, которое рекомендует брать вендор при расчете производительности.

Время отклика на тестируемой конфигурации Unity росло следующим образом:

639879100c0841c7820e47558380a345.jpg

Т.е. даже в «точке насыщения», когда при увеличении количества потоков IOPS-ы перестают расти (512 потоков), время отклика не превысило 5ms.

Зависимость времени отклика от количества IOPS.

bfd059ad21df4c25b61be86df1a6b832.jpg

Опять же если сравнивать с временем отклика при тестирования кэша контроллеров на VNX5400, то можно увидеть, что на VNX5400 время отклика в 1ms достигалось уже примерно при 31000 IOPS и около 30 потоках ввода/вывода (и это фактически на ОЗУ). На Unity же на SSD дисках это происходит только при ~64000 IOPS. И если в нашу Unity добавить еще SSD дисков, то эта точка пересечения с значением в 1ms на графике сдвинется намного дальше по шкале IOPS.

Зависимость пропускной способности от количества потоков ввода/вывода:

f6057086b00045aeb94fe050873ef271.jpg

Получается, что массив принимал и отдавал потоки пакетов размером по 8KB на скорости около 1TB/s (терабайта в секунду).

Да бы не утомлять читателя, ряд графиков производительности различных компонентов массива Unity 400F упрятано для любопытных…

Под вторым спойлером
4e0d5e2460ab493485451c95fa4cdf1b.jpg
4b4158c79ce0404d977b1fcce5e32263.jpg
6d867c77a6724a9ea035c3b6ef9b466b.jpg
2346139568cc4d04a7e5581d3d464208.jpg
567d567f116b453f848ef61ad35f1a8e.jpg
a879883321ab47908ef0df7fd74400ff.jpg
1680ec2c62e948d1b1415908cbdd477d.jpg
4efefc03eaf244e3ba63a78fd851d273.jpg
1e075e15dc404fd7b2fb30505ba7cb9c.jpg

Ссылка на файл с исходными данными IOMETR-a.

Выводы


Выводы я думаю каждый сделает для себя сам.

Как по мне, так на рынке появилась новая интересная система хранения, которая даже при небольшом количестве SSD дисков показывает высокую производительность. А если учесть доступные сейчас размеры SSD (а у DellEMC для Unity уже доступны SSD диски объемом 7.68 TB и в ближайшее время должна появиться поддержка 15.36TB SSD), то думаю, что в ближайшие несколько лет гибридные массивы со смесью SSD и шпиндильных дисков станут историей.

P.S. Для любителей задавать вопросы «сколько это стоит?». В своих презентациях вендор указывает, что ценник на Unity F (All Flash) начинается от 18k$, а для Hybrid конфигурации от менее чем 10k$. Но так как презентации все «буржуйские», то в наших российских реалиях ценник может отличаться. В любом случае лучше уточнять в каждой конкретной ситуации у местного вендора или его партнеров.

Комментарии (2)

  • 14 октября 2016 в 09:53

    0

    Unty 400F в конфигурации с 10 SSD дисками на 1.6TB каждый.

    ценник на Unity F (All Flash) начинается от 18k$

    То есть это цена за шасси, без дисков?
    • 14 октября 2016 в 09:58

      0

      Нет, я думаю вендор имеет в виду цену за шасси с минимальным набором дисков. Для Unity F это как раз 10 дисков, насколько я знаю. Исходя из рекомендованной конфигурации для SSD Raid5 (8+1) и плюс 1 SSD как HS. Без дисков массивы у EMC никогда не продавались, не считая уже не существующей линейки NAS-систем Iomega.

© Habrahabr.ru