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

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



    А 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 от компании EMC для управления путями доступа к LUN.
    На массиве Unity 400F был создан пул в конфигурации RAID5 (8+1). На пуле разместились два тестовых LUN, которые были подключены к серверам. На LUN-ах были созданы файловые системы NTFS и тестовые файлы размером 400GB, что бы исключить влияние кэш контроллеров на результат.

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




    Т.е. на каждом сервере работало по 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 (документ тут).



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

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


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



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

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





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

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



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

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



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

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



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

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

    Под вторым спойлером










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

    Выводы


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

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

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

    Подробнее
    Реклама

    Комментарии 10

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

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

      То есть это цена за шасси, без дисков?
        0

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

          0
          Наверняка от $18K можно купить только Unity 300F, а не рассматриваемую в статье 400F. А это уже другая железка.
            0

            Скорее всего да, цена для Unity 300F. Но отличие будет только в модели CPU и размере DIMM в контроллере. А значит и производительность скорее всего будет пониже. С другой стороны архитектура-то та же, а значит вряд ли "пониже" будет в разы.


            Насколько знаю Unity 300 в демо в России у дисти тоже уже появились. Никто не мешает запросить демо в тестирование и проверить его производительность, например на своих задачах.

        0
        Алексей, спасибо за грамотно проведенное и документированное тестирование.
        Это, кстати, тонкие луны тестировались?
          0

          Да, тестируемые луны были созданы в тонком формате.

          0
          Мне всё-таки по совсем понятно — достигли вы его максимальных возможностей или нет, учитывая что в первой конфигурации, по вашим словам захлебнулся проц, а на второй стоят 4Гб карты…

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

          Все вендоры по-моему так перестраховываются
            0

            При той конфигурации стенда и теста, которые использовались, я считаю максимум для СХД был достигнут. Если заглянуть под второй спойлер, то там первым идет график утилизации контроллеров массива. Как раз примерно на 7 "ступеньке" (512 потоков IO) утилизация CPU обоих контроллеров подходит вплотную к 100%. По каждому из FC портов массива поток данных составил в максимуме около 300 MB/s (графики там же под спойлером), что составляет примерно 75-80% от пропускной способности FC 4Gbit\s.


            Но если кто-то сможет погонять тот же тест на более современной конфигурации SAN и вычислителей, то я буду приятно удивлен, если ошибусь в своем утверждении.


            Кстати, тестировал еще в Unity отдельно один порт FC по IOPS, правда на 8Gbit/s. Упирался примерно в 62k IOPS. Хотя вендор указывает и для 16Gbit\s и для 8Gbit\s максимум в 45k IOPS (документ тут).

              0
              А, второй спойлер я что то пропустил :( Слишком много ссылок — глаз замазался :) Ну т.е. как и в большинстве случаев с недорогими системами — упирается в ресурсы массива, а не ссд.
                0
                И в случае с более дорогими системами, увы, тоже :)
                Вся разница в том, сколько SSD повесить на контроллер.
                Это свойство всех scale-up систем, где на контроллер навешивается все новая и новая нагрузка без увеличения процессорной мощности.

                Исключением не является даже является разве что DSSD D5, выдающий 10 миллионов IOPS из 5U коробки. Но там а) другая логика работы, где сервер может обращаться к флэш-ячейкам СХД напрямую, как к своей памяти и б) физически ограничено количество флэша, которое можно поставить

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое