Хабрахабр

Как мы тестировали VMware vSAN™: для чего это подходит на практике

Год назад я собрал дата-центр из стопки Intel NUC. Там была программная система хранения данных, которую не смогла порушить уборщица, пару раз развалившая кластер.

Конечно, у нас был ряд успешных внедрений в продакшен у наших заказчиков, где vSAN успешно решает поставленные задачи, но провести всеобъемлющее тестирование не доводилось. И вот теперь мы решили погонять vSAN на нескольких серверах в очень хорошей конфигурации, чтобы всецело оценить производительность и отказоустойчивость решения. Собственно, результатами тестов я и хочу сегодня поделиться.

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

Что вообще такое VMware vSAN и зачем мы в это полезли?

Есть обычный серверный кластер для виртуальных машин. В нём куча независимых компонентов, гипервизор запускается непосредственно на железе, а хранилище конфигурируется отдельно на базе DAS, NAS или SAN. Медленные данные на HDD, горячие — на SSD. Всё привычно. Но тут возникает проблема развёртывания и администрирования этого зоопарка. Особенно весело становится в ситуациях, когда отдельные элементы системы от разных вендоров. В случае проблем стыковка тикетов для техподдержки разных производителей — своя особая атмосфера.

Есть отдельные железки, которые с точки зрения сервера выглядят как диски для записи.

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

Ключевой фишкой продукта является тесная интеграция с платформой виртуализации VMware vSphere, являющейся лидером среди решений по виртуализации, что позволяет развёртывать на серверах виртуализации программное хранилище для виртуальных машин за считаные минуты.
VMware vSAN как раз и относится к решениям, на базе которых развёртывается
гиперконвергентная инфраструктура. Прозрачность работы системы несколько снижается, но в результате всё работает, что называется, automagically vSAN можно сконфигурировать как гибридное хранилище и в виде all-flash-варианта. vSAN непосредственно берёт на себя управление операциями ввода/вывода на низком уровне, оптимально распределяя нагрузку, занимается кэшированием операций чтения/записи и делает ещё кучу вещей с минимальной нагрузкой на память и процессор. Управление с помощью их же веб-клиента vSphere очень удобное за счёт тесной интеграции с другими продуктами. Масштабируется как горизонтально добавлением новых узлов в кластер, так и вертикально, увеличивая количество дисков в отдельных узлах.

Понятно, что суммарная ёмкость несколько ниже в сравнении с гибридной конфигурацией, использующей магнитные диски, но тут мы решили проверить, как это частично можно обойти, используя erasure coding, а также дедупликацию и компрессию на лету. Мы остановились на чистой all-flash конфигурации, которая по расчётам должна быть оптимальной по соотношению цены и производительности. В итоге эффективность хранения становится ближе к гибридным решениям, но существенно быстрее при минимальном оверхеде.

Как тестировали

Для тестирования производительности использовалось ПО HCIBench v1.6.6, которое автоматизирует процесс создания множества виртуальных машин и последующее сведение результатов. Само тестирование производительности выполняется средствами ПО Vdbench — одного из наиболее популярных ПО для синтетического нагрузочного тестирования. Железо было в следующих вариантах конфигурации:

  1. All-flash — 2 дисковые группы: 1xNVMe SSD Samsung PM1725 800 GB + 3xSATA
  2. SSD Toshiba HK4E 1.6 TB.
  3. All-flash — 1 дисковая группа: 1xNVMe SSD Samsung PM1725 800 GB + 6xSATA SSD Toshiba HK4E 1.6 TB.
  4. All-flash — 1 дисковая группа: 1xNVMe SSD Samsung PM1725 800GB + 6xSATA SSD Toshiba HK4E 1.6 TB + Space Efficiency (дедупликация и компрессия).
  5. All-flash — 1 дисковая группа: 1xNVMe SSD Samsung PM1725 800GB + 6xSATA SSD Toshiba HK4E 1.6 TB + Erasure Coding (RAID 5/6).
  6. All-flash — 1 дисковая группа: 1xNVMe SSD Samsung PM1725 800GB + 6xSATA SSD Toshiba HK4E 1.6 TB + Erasure Coding (RAID 5/6) + Space Efficiency (дедупликация и компрессия).

В процессе тестов мы эмулировали три различных объёма активных данных, используемых приложениями: 1 Тб (по 250 Гб на сервер), 2 Тб (по 500 Гб на сервер) и 4 Тб (по 1 Тб, соответственно).

Для каждой конфигурации выполнялся одинаковый набор тестов со следующими профилями нагрузки:

  1. 0 чтение/100 запись, случайно 50%, размер блока — 4k.
  2. 30 чтение/70 запись, случайно 50%, размер блока — 4k.
  3. 70 чтение/30 запись, случайно 50%, размер блока — 4k.
  4. 100 чтение/0 запись, случайно 50%, размер блока — 4k.

Первый и четвёртый варианты были нужны, чтобы понять, как система будет вести себя под максимальными и минимальными нагрузками. А вот второй и третий уже максимально приближены к реальному типовому сценарию использования: например, 30 чтение/70 запись — VDI. Те нагрузки, с которыми я сталкивался в продакшене, были очень к ним близки. В процессе мы тестировали эффективность механизма управления данными vSAN.

По результатам тестирования мы поняли, что можем рассчитывать на показатели в районе 20 тысяч IOPS на узел. В целом система показала себя очень неплохо. Ниже я привёл графики с результатами: Для рядовых и высоконагруженных задач это хорошие показатели с учётом задержек в 5 мс.





Итоговая таблица с результатами тестирования:

Зелёным цветом отмечены активные данные, полностью попадающие в кэш.

Отказоустойчивость

Я вырубал один узел за другим, несмотря на возмущение машины, и смотрел на реакцию системы в целом. После отключения первого узла вообще ничего не произошло, кроме небольшого падения производительности, примерно на 10–15%. Потушил второй узел — часть виртуальных машин отключилась, но остальные продолжили работу с небольшой деградацией производительности. В целом живучесть порадовала. Перезапустили все узлы — система чуть задумалась и снова синхронизировалась без каких-либо проблем, все виртуальные машины запустились без каких-либо проблем. Как в своё время на NUC’ах. Целостность данных тоже не пострадала, что очень порадовало.

Общие впечатления

Программно-определяемые системы хранения данных (SDS) уже вполне зрелая технология.

Если вы создаёте инфраструктуру с нуля, может получиться, что традиционная система хранения данных в сходной конфигурации будет стоить примерно столько же. Сегодня один из ключевых стоп-факторов, стоящих на пути внедрения vSAN, — это достаточно высокая стоимость лицензии в рублях. Так что сегодня при выборе решения для хранения данных виртуальных машин на платформе виртуализации vSphere стоит очень хорошо взвесить все плюсы и минусы использования традиционных решений и внедрения технологии программного-определяемого хранения. Но при этом будет менее гибкой как с точки зрения администрирования, так и масштабирования.

Поэтому если вы уже работаете на инфраструктуре VMware, то вам будет гораздо проще с развёртыванием. Можно собрать решение на том же Ceph или GlusterFS, но при работе с инфраструктурой VMware подкупает тесная интеграция vSAN с отдельными компонентами, а также простота администрирования, развёртывания и заметно большая производительность, особенно на небольшом количестве узлов. Вы реально делаете десяток кликов и получаете работающую SDS из коробки.

Такая конфигурация позволяет получить отказоустойчивое хранилище для виртуальных машин со всеми технологиями и производительностью vSAN всего на двух узлах. Другой мотивацией к развёртыванию именно vSAN может быть использование её для филиалов, которое позволяет зеркалить узлы в удалённых подразделениях с witness хостом в дата-центре. Кстати, для использования vSAN есть отдельная схема лицензирования по количеству виртуальных машин, что позволяет сократить затраты в сравнении с традиционной схемой лицензирования vSAN по процессорам.

В сравнении с традиционными системами вы экономите место в стойке, экономите на SAN-сети за счёт отказа от Fibre Channel в пользу более универсального стандарта Ethernet. Архитектурно решение требует 10 Gb Ethernet с двумя линками на узел для адекватного распределения трафика при использовании all-flash решения. Для обеспечения fault tolerance требуется минимум три узла, на двух будут храниться реплики объектов с данными, а на третьем — witness объекты для этих данных, решает проблему сплитбрейна.

Теперь несколько вопросов к вам:

  1. Когда вы определяетесь с системой хранения, то какие критерии для вас наиболее важны?
  2. Какие стоп-факторы вы видите на пути внедрения программно-определяемых систем хранения данных?
  3. Какие программно-определяемые системы хранения данных вы в принципе рассматриваете в качестве варианта для внедрения?

UPD: Совсем забыли написать конфигурацию стенда и параметры нагрузки:

Описание железа. 1. 6TB
Storage Config #2:
1xPM1725 800GB
6xToshiba HK4E 1. Например:
Сервера – 4xDellR630, в каждом:
• 2xE5-2680v4
• 128GB RAM
• 2x10GbE
• 2x1GbE for management/VM Network
• Dell HBA330
Storage Config #1:
2xPM1725 800GB
6xToshiba HK4E 1. 6TB

Описание версий ПО:
vSphere 6. 2. 6. 5U1 (7967591) (vSAN 6. патчи после Meltdown/Spectre
vCenter 6. 1), т.е. 5U1g
Latest supported drivers and FW by vSAN and ESXi for all components
LACP for vSAN and vMotion traffic (with NIOC shares/limits/reservation enabled)
All other setting are default

Параметры нагрузки:
• HCIBench 1. 3. 6
• Oracle Vdbench — 5. 6. 06
• 40VM per cluster (10 per node)
• 10 vmdk per VM
• 10GB size of vmdk and 100/50/25% Workload set percentage
• Warmup time-1800sec (0. 04. 5 hour), Test time 3600 (1 hour)
• 1 Threads per vmdk

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть