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

в 10:29, , рубрики: Erasure Coding, VZ Storage, Блог компании Virtuozzo, виртуализация, высокая производительность, программно-определяемое хранилище, производительность, резервное копирование, хранение данных

В предыдущем нашем посте мы поделились своими измерениями производительности гипервизора после установки патчей против уязвимостей 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

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

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

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

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

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

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

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

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

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

Заключение

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

Автор: Gummio_7

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js