company_banner

Что показали тесты новой flash-СХД EMC XtremIO

    image
    Вот так выглядела транспортная коробка, которая к нам приехала. Железка стоит по прайсу как 3-4 квартиры в Москве.

    В начале марта мы проводили открытый тест-драйв новой flash СХД от EMC — EMC XtremIO. Система считается одной из самых быстрых в мире СХД. Особенность — inline-дедупликация на борту. Железо дорогое, но как сказал один из наших заказчиков: «Нифига себе, я только на лицензиях буду экономить 3 миллиона долларов в год». Потому что массив позволяет сократиться с 128 ядер до 64, а лицензии часто считаются именно по ядрам. И ещё, особенно интересна система будет тем, кто работает с виртуальными средами, кто ищет способ уменьшить время отклика СХД и у кого есть проблемы с производительностью.

    В меню были включены следующие тесты: IOPS 100% read, random 4k; IOPS 50% read 50% write, random 4k; IOPS 100% write, random 4k. Проводились с помощью IOmeter. Еще пробовали систему в боевом режиме, смотрели ее реакцию на отказы компонентов (вытаскивали диск «на живую» под высокой нагрузкой, перезагружали контроллер, отключали питание по одному из вводов, выключали UPS) и пиковую нагрузку.
    В общем, было на что посмотреть. Подробности ниже.

    Flash vs HDD


    XtremIO занимает в 10 раз меньше места в дата-центре, чем решения на обычных дисках, чем экономит место в серверной и питание. Тут вообще уместно сравнить flash с аналогичными решениями на дисках. Обычный шкаф c дисками даст порядка 50 тысяч IOPS, если считать, что в шкаф поместится в среднем 250 дисков, и каждый выдаст по 200 IOPS (хотя это с большим запасом). И IOPSы эти будут с уровнем задержки 3-9 миллисекунд. Шкаф XtremIO выдаст до 1 миллиона IOPS, если это потребуется, а главное — задержки будут менее 1 мс, что очень важно для целевых приложений.

    Тесты


    Тесты на чтение проводились на дисках с созданными разделами и файловой системой, в тестах на запись попробовали тестировать на сырых устройствах без разделов, там результат близок к линии, судя по всему, такую неравномерность результата вносит драйвер ФС. Тестировали на последнем Iometer с шаблоном Full random 4K Read, Full random 4K Write, Full random 4K Write 50%. Вендор заявил соответственно 250к IOPS, 100-150k IOPS в зависимости от уникальности данных, и 150k IOPS при соотношении чтение/запись — 50/50, ниже покажу насколько массив уложился в заявленные параметры.

    В качестве результатов привожу мгновенное значение на массиве и более подробные измерения на хосте, с которого проводилось тестирование. Для хостовых графиков зелёный – IOPS, красный – задержка.

    Чтение


    С чтением результат был очень обнадёживающий, мы легко достигли заявленных показателей и даже превзошли их.

    image



    Запись


    С записью получилось следующим образом:
    На суб-милисекундных задержках заявленных характеристик не получили, вот предел которого мы добились:





    Тем не менее, выжать максимум, если не смотреть на задержку, вышло достаточно легко:





    Только задержка на массиве, конечно, выросла выше 1 мс.

    Чтение/запись


    Тут нам не хватило каких-то 5 десятков IOPS чтобы достигнуть заявленных значений:





    Само собой, интереса ради попробовали добить эти IOPS, но задержка неизбежно поползла вверх и вышла за миллисекунду, причём, что забавно, поползла именно задержка на чтение:





    Общие ощущения от массива


    В целом, с точки зрения администратора система очень удобна и приятна в управлении, настройка минимальна и не требует серьёзного планирования конфигурации. Фактически единственное, про что не надо забывать – подключать хост к обоим контроллерам (об этом нередко забывают). При этом, несмотря на малое число параметров, интерфейс весьма информативен и нагляден, более-менее опытному администратору хватит пары минут, чтобы со всем разобраться.

    С точки зрения сервисного инженера массив достаточно больших размеров по сравнению с аналогами. На мой взгляд, очень чётко просматривается заточка массива под VDI, и хранение «горячих» данных для БД финансового, страхового, научного и энергетического сектора, решению весьма критична возможность дедуплицировать данные максимально сильно.

    Из того, что еще понравилось – большинство компонент массива очень удобно менять, у аналогов обычно всё сложнее.

    Вообще, о дедупликации на лету для флеш СХД до недавнего времени никто даже не думал из-за возможных вносимых задержек. Компания ЕМС не только подумала, но и смогла представить СХД корпоративного уровня, где эта технология стала ключевой. Такая дедупликация позволяет не записывать данные на диск, если они уже имеются где-то. То есть операция записи, по сути, осуществляется в кэш-памяти, обеспечивая ещё лучшее время отклика. Сейчас EMC единственные, кто делает инлайновую дедупликацию внутри СХД. Другие делают это либо отдельной железкой, либо не «на лету», что, в частности, позволяет избавиться от костылей в виде дедупликации RAM-кэша (он просто не нужен: данные туда попадают уже обработанными). Новый дублирующий блок сразу заменяется на ссылку, где бы внутри системы он не находился – что в кэше, что на SSD. При этом система не старается хранить данные в кэше, а сразу пишет их на SSD – это потребовало от разработчика пересмотра архитектуры, но дало выигрыш в производительности. Всё это в комплексе для решений типа VDI может сокращать количество записей на сами диски до 30 и более раз.

    Цена


    Каждый раз, когда я показываю такую или похожую коробку, возникает много вопросов по цене. Отвечу на основные. Во-первых, сколько стоит: цена по прайсу – 28 миллионов рублей, но по факту она всегда отличается вниз (и существенно) из-за большого количества программ и специальных условий вендора. Именно поэтому цены на такие решения обычно не объявляются, а указываются в коммерческом предложении на конкретное внедрение. Если вы работаете с высоконагруженными приложениями, то вполне понимаете, что она оправдана: это очень быстрая СХД сама по себе (она убирает «бутылочные горлышки», например, в банках, страховых и у сотовых операторов), плюс «заточенность» под виртуальные среды. Если пересчитывать на многие практические highload-решения, эксплуатация оказывается куда дешевле дисковой (интересна конкретика – пишите, отправлю предложение) И, наконец, эта СХД идёт с поддержкой. Базовая подразумевает кроме софта и консультаций замену любых узлов в течение 1 рабочего дня, а расширенная – выезд в течение 4 часов максимум.

    Приглашаю на тест


    Система с фото выше сейчас у нас, и используется для тестов и демо. Если вы хотите протестировать её для своих задач (в частности, по своей программе) — пишите мне на vbolotnov@croc.ru.
    КРОК
    IT-компания

    Comments 18

      +8
      Молодец, что сразу цену указали :) Обычно в обзорах СХД ее не упоминают вовсе.
        0
        > Железка стоит по прайсу как 3-4 квартиры в Москве.
        > Шкаф XtremIO выдаст до 1 миллиона IOPS

        … и будет стоить как небольшое островное королевство? :)
          +2
          Это же не решение для small business, а железка для банков и ко, где экономия от производительности, питания, охлаждения и временных затрат окупится очень быстро. Так что, стоимость оправдана, тем более, обычно, конечная стоиомсть может быть и вполовину меньше начального ценника. Один раз на фирме видел скидку в 98% на полку забитую ssd дисками :)
            +3
            Да я понимаю. Более того, стоимость шкафа сабжей может быть незначительной частью бюджета проекта.

            Просто не каждая статья на Хабре вызывает перемещение глаз на лоб два раза подряд. :)
          0
          Не понял каким образом такой массив позволет экономить вычислительные ядра на серверах и соответственно меньше тратиться на софтовые лицензии.
          Inline дедупликацию внутри СХД уже довольно таки давно умеет делеть Pure Storage.
            0
            Это тонкий момент связанный с работой CPU. С момента, когда процессор отправил команду на чтение или запись куска данных до момента подтверждения он входит в цикл ожидания. Для БД это параметр IO_WAIT. В некоторых случаях он может достигать 70% всего времени работы. Если СХД отвечала не 5мс, а 0.5мс, это существенно повышает реальную эффективность CPU. Получается, что либо больше транзакций/виртуалок и т.п на ядро, либо меньше ядер на тот же объем данных.

            Pure Storage, Nimble Data, Whiptail (Cisco), Nimbus и др. – следим за ними, но в РФ о них пока рано говорить, если речь идет о сегменте Enterprise.
              +4
              … И старательно обходим упоминания Nutanix :D, с которого фактически EMC (точнее Xtremio) «слизывало» идею, но при этом сильно отстает

              Смотрим на 4-ю версию NOS и сравниваем функционал :))

              www.nutanix.com/nos-4-launch/
                +1
                > С момента, когда процессор отправил команду на чтение или запись куска данных до момента подтверждения он входит в цикл ожидания.

                Эй, погодите, ерунда какая-то, а как же асинхронный ввод-вывод? Отправлена команда на запись, пока она идет — БД занята другими важными делами.
                Да и без нее, процесс, находящийся в состоянии заблокированного ввода-вывода — не загружает процессор, он может пока выполнять соседний процесс/тред/етц.

                В уменьшение потребности в оперативной памяти (читай: дисковых кешах, buffer_pool оракловый, и все такое) — верю. В увеличение загруженности процессоров — верю (больше данных успеваем писать/читать, больше данных обрабатывается процессором).

                Уменьшение потребности в процессоре как следствие увеличения производительности дисковой подсистемы — это какой-то нонсенс. Ну либо я ничегошеньки не понимаю в СУБД и дисковых подсистемах.
                  0
                  Я весьма рад, что БД занимается другими «важными делами», однако, тот факт, что если данных в кэш-памяти нет, то пока они не придут от СХД, транзакция не выполнится я думаю, вы не отрицаете? То, что процессор не загружен не означает, что ему есть чем заняться эти 5мс, которые он ждет каждый IO. Тем более, раз вы верите в увеличение загруженности процессоров, что неизменно приводит к росту производительности в пересчете на процессор. Это мы видели уже на боевом внедрении, когда утилизация мощных RISC серверов наконец-то «взлетела» при шестикратном росте производительности приложения.
                    +1
                    Ситуация «ждем ввода-вывода, больше заняться нечем» обычно называется «узкое место по I/O».
                    Да, при увеличении производительности I/O растет утилизация процессоров.
                    Да, если БД больше нечем заняться, и она ожидает окончания ввода-вывода. Но процессоры при этом — простаивают, и ничего не делают. Следовательно, количество процессоров (в этой системе под этой нагрузкой) — избыточно.

                    И это прямо противоречит вашему описанию, цитирую:

                    > Железо дорогое, но как сказал один из наших заказчиков: «Нифига себе, я только на лицензиях буду экономить 3 миллиона долларов в год». Потому что массив позволяет сократиться с 128 ядер до 64, а лицензии часто считаются именно по ядрам.

                    В данной цитате утверждается, что замена СХД на вашу — позволяет снизить загрузку процессоров, и, как следствие, уменьшить их количество. Каким магическим образом улучшение производительности I/O позволяет «сократиться с 128 ядер до 64»? Чем загружены процессоры в конфигурации со «старой» СХД?

                    <irony>Ох, мне пришла в голову интересная мысль, которая все объясняет: ваша СХД — УХУДШАЕТ производительность I/O, процессоры простаивают, и их количество можно сократить?</irony>
                      0
                      Коллега, противоречия тут нет. Конечно, мой уважаемый заказчик не станет «выдерать» 64 ядра из своего сервера :) Основная идея, т.к. моей целью является именно освещение новых подходов, а не погружение в дискуссии о терминах, в том, что механические диски достигли своего «потолка» по скорости вращения и, как результат, времени отклика. Во многих случаях, как вы верно заметили, бутылочное горлышко именно в СХД. Добавляя шпинделей мы увеличим пропускную способность и максимальное количество операций ввода-вывода, но я говорю о принципиально другом подходе: полный переход на флеш. Это влечет за собой лавинный эфект при проектировании системы: количество процессоров, количество лицензий, количество серверов, количество стоек в ЦОДе, количество портов в коммутаторах. И мне эти изменения действительно нравится.
                        0
                        Ох, умеете вы выворачиваться. Презентации заказчикам, наверное, очень хорошо читаете.

                        Так и напишите: фразу про ядра ввернули для красного словца, технического обоснования не имеем.
                        Спасибо за дискуссию.
                  +1
                  В описанном вами случае можем смело уменьшать количество процессоров/ядер и не потеряем в производительности, так как затык в подсистеме ввода-вывода. Стоит просто адекватно подбирать компоненты решения, чтобы не было явных «бутылочных горлышек». Так что по-прежнему не вижу как XtremIO позволяет экономить на софтовых лицензиях.

                    0
                    технические вопросы, похоже, слиты, коллега. :)
                0
                А можно ламерский вопрос человека далекого от этого всего
                Насколько я понимаю железо производится другими конторами стандартно, SSD диск самсунга или Intel (или EMC что-то сами делают, или все сами???) так вот вопрос, сколько из этих 28 это стоимость самого железа?
                  0
                  диски там расходники, остальное все емс делают сами, вместе со шкафом если надо :) ну и очевидно стоимость железяки там процентов 20 в лучшем случае. Остальное суппорт, R&D и понт.
                  0
                  А какая ёмкость этой СХД?
                  Какой уровень избыточности?
                    0
                    Полезная емкость без учета дедупликации порядка 7Тб. Уровень избыточности N+2 с восстановлением данных вышедшего из строя диска параллельно на все «живые» диски в системе. Т.е. вместо дисков горячей замены используется зарезервированная под это емкость, либо свободная доступная емкость на дисках.

                  Only users with full accounts can post comments. Log in, please.