Производительность хранилища данных: новые цифры

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

    Благодаря оптимизациям VzKernel и его перекомпиляции c опцией «Retpoline» мы заменили уязвимые последовательности машинного кода и смогли практически полностью ликвидировать проблемы с производительностью, вызванные необходимостью защищать гипервизор от уязвимостей в процессорах Intel. В результате снижение производительности было уменьшено до 1-2%. Однако на этом фоне у многих возникли вопросы о работе хранилища данных. И это неудивительно, ведь в гиперконвергентных средах распределенное хранение данных играет основополагающую роль, и при медленном хранилище все преимущества производительности виртуальных машин и контейнеров могут сойти на нет.

    Сегодня мы хотим поделиться с вами двумя показательными тестами, которые были проведены для оценки производительности виртуальных машин и плотности размещения данных в распределенном хранилище VZ Storage, которое встраивается в семейство продуктов Virtuozzo 7. В качестве тестового стенда использовался кластер из 6 узлов, причем непосредственно хранением данных были заняты только 5 из них, а на оставшемся узле располагались виртуальные машины.

    Каждый узел обладал следующей конфигурацией:

    • CPU: 2 x Intel Xeon E5-2620 v4 @ 2.1 ГГц
    • RAM: 64 Гб DDR4 2133 МГц
    • NET: 2 x 10 Гбит/с – две отдельных подсети для разделения трафика теста и трафика распределенного хранилища данных
    • Емкости:

      • HDD: 8 x 1 Tб 7200 RPM – включая 7 HDD для чанк-серверов (CS)
      • SSD: 400 Гб Intel DC P3600 PCIe – для метаданных (MDS), журналирования и клиентского кэша

    Один из дисков на каждом узле был выделен под систему, а остальные 7 – под чанк-сервера (CS) для хранения данных. В итоге в кластере получилось 42 чанк-сервера. Для управления этим хозяйством мы запустили 3 сервера метаданных (MDS). Репликация данных была реализована по схеме 3:2, что можно считать стандартным решением для большинства типовых задач.

    По результатам теста WebBench, где мы оценивали производительность и плотность размещения виртуальных машин с Windows Server 2012 R2, количество запросов для виртуального хранилища в VZ7 оказывается значительно выше, а общая производительность в среднем на 30% превосходит результаты предыдущего поколения хранилища, которое поставлялось вместе с VZ6. При этом VZ Storage вместе с гипервизором Virtuozzo 7 может поддерживать одновременную работу свыше 100 виртуальных машин на кластере такого размера, обеспечивая им приемлемую производительность.

    WebBench: Плотность ВМ Windows 2012 R2 на базе VStorage


    Второй тест проводился с использованием утилиты SysBench и эмулировал уже не веб-запросы, а транзакции OLTP. Мы нагружали такие же виртуальные машины с Microsoft Windows Server 2012 R2 на этом же кластере и получили еще более интересные результаты. Помимо преимущества по производительности при количестве ВМ от 30 штук, VZ7 показала более высокую плотность размещения, справляясь с одновременной работой более 100 виртуальных машин. При этом устаревшее хранилище на VZ6 демонстрирует приемлемую производительность максимум для 60 виртуальных машин на кластере приведенного размера.

    SysBench: Плотность ВМ Windows 2012 R2 на базе VStorage




    И еще немного об Erasure Coding


    В дополнение ко всему сказанному выше, компания Virtuozzo остается сторонником использования технологий сжатия на базе кодов Рида-Соломона или Erasure Coding. Несмотря на широкое обсуждение этой технологии многие по-прежнему предпочитают использовать непосредственные копии и хранят в своей сети до 3 экземпляров данных. Однако, как показала практика, такой подход снижает производительность сети и замедляет работу процессов резервного копирования.

    Чтобы проверить этот факт, мы собрали два кластера, по 6 узлов в каждом. На обоих кластерах было запущено 3 сервера метаданных (MDS) и 66 чанк-серверов (CS) хранения данных поверх дисков SAS 15К. Один из кластеров был использован для размещения виртуальных машин, а другой – для резервного копирования. Мы попробовали два способа размещения бэкапов: EC в режиме 3+2 (на три фрагмента данных — две хэш-суммы) и полное резервирование 3:2 (в сети хранится две полные копии данных). С точки зрения защиты данных конфигурации идентичны – они дают возможность восстановить всю информацию даже при возникновении двух точек отказа. Однако с точки зрения производительности EC демонстрирует намного более высокие результаты.

    Erasure Coding и репликация данных в сценарии параллельного резервного копирования ВМ



    По оси абсцисс отмечено количество виртуальных машин, которые одновременно участвуют в процессах резервного копирования. А по оси ординат – средняя скорость создания резервной копии в Мбайт/с. Скорость рассчитывается на один узел, так что общая пропускная способность и производительность кластера оказывается значительно выше, кратно количеству узлов. Из графика видно, что при одновременном бэкапе 15 виртуальных машин c каждого узла, прирост производительности за счет использования EC оказывается на уровне 10%.

    Заключение


    Эти тесты показывают какие преимущества дает обновленная архитектура и улучшенная работа хранилища VZ Storage при работе с виртуальными машинами MS Windows, которые традиционно тяжелее оптимизируются и уплотняются, чем ВМ c гостевыми Linux, которые вообще можно преобразовать в системные контейнеры. При этом в тесте мы использовали жесткие диски SAS 15K, а не твердотельные накопители, для которых результаты были бы еще выше из-за увеличения общего времени отклика и скорости работы подсистемы хранения.
    Virtuozzo
    37,00
    Разработчик ПО для контейнерной виртуализации
    Поделиться публикацией

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

      +1
      Ничего себе — с течением времени не становится хуже! Конкуренты-то где? Сеф и вот это всё…

      С другой стороны, вы любите сравнивать ваше настроенное с чужим ненастроенным, так что, наверное, лучше не надо.
        0

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

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

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