Год назад я собрал дата-центр из стопки Intel NUC. Там была программная система хранения данных, которую не смогла порушить уборщица, пару раз развалившая кластер.
И вот теперь мы решили погонять vSAN на нескольких серверах в очень хорошей конфигурации, чтобы всецело оценить производительность и отказоустойчивость решения. Конечно, у нас был ряд успешных внедрений в продакшен у наших заказчиков, где vSAN успешно решает поставленные задачи, но провести всеобъемлющее тестирование не доводилось. Собственно, результатами тестов я и хочу сегодня поделиться.
Будем мучить хранилище нагрузкой, ронять его и всячески тестировать отказоустойчивость. За подробностями всех приглашаю под кат.
Что вообще такое VMware vSAN и зачем мы в это полезли?
Есть обычный серверный кластер для виртуальных машин. В нём куча независимых компонентов, гипервизор запускается непосредственно на железе, а хранилище конфигурируется отдельно на базе DAS, NAS или SAN. Медленные данные на HDD, горячие — на SSD. Всё привычно. Но тут возникает проблема развёртывания и администрирования этого зоопарка. Особенно весело становится в ситуациях, когда отдельные элементы системы от разных вендоров. В случае проблем стыковка тикетов для техподдержки разных производителей — своя особая атмосфера.
Есть отдельные железки, которые с точки зрения сервера выглядят как диски для записи.
И есть гиперконвергентные системы. В них вам выдают универсальный юнит, который берёт на себя всю головную боль по взаимодействию сети, дисков, процессоров, памяти и тех виртуальных машин, которые на них крутятся. Все данные стекаются в одну панель управления, и при необходимости можно просто добавить ещё пару юнитов для компенсации выросшей нагрузки. Администрирование очень сильно упрощается и стандартизируется.
VMware vSAN как раз и относится к решениям, на базе которых развёртывается
гиперконвергентная инфраструктура. Ключевой фишкой продукта является тесная интеграция с платформой виртуализации VMware vSphere, являющейся лидером среди решений по виртуализации, что позволяет развёртывать на серверах виртуализации программное хранилище для виртуальных машин за считаные минуты. vSAN непосредственно берёт на себя управление операциями ввода/вывода на низком уровне, оптимально распределяя нагрузку, занимается кэшированием операций чтения/записи и делает ещё кучу вещей с минимальной нагрузкой на память и процессор. Прозрачность работы системы несколько снижается, но в результате всё работает, что называется, automagically vSAN можно сконфигурировать как гибридное хранилище и в виде all-flash-варианта. Масштабируется как горизонтально добавлением новых узлов в кластер, так и вертикально, увеличивая количество дисков в отдельных узлах. Управление с помощью их же веб-клиента vSphere очень удобное за счёт тесной интеграции с другими продуктами.
Мы остановились на чистой all-flash конфигурации, которая по расчётам должна быть оптимальной по соотношению цены и производительности. Понятно, что суммарная ёмкость несколько ниже в сравнении с гибридной конфигурацией, использующей магнитные диски, но тут мы решили проверить, как это частично можно обойти, используя erasure coding, а также дедупликацию и компрессию на лету. В итоге эффективность хранения становится ближе к гибридным решениям, но существенно быстрее при минимальном оверхеде.
Как тестировали
Для тестирования производительности использовалось ПО HCIBench v1.6.6, которое автоматизирует процесс создания множества виртуальных машин и последующее сведение результатов. Само тестирование производительности выполняется средствами ПО Vdbench — одного из наиболее популярных ПО для синтетического нагрузочного тестирования. Железо было в следующих вариантах конфигурации:
- All-flash — 2 дисковые группы: 1xNVMe SSD Samsung PM1725 800 GB + 3xSATA
- SSD Toshiba HK4E 1.6 TB.
- All-flash — 1 дисковая группа: 1xNVMe SSD Samsung PM1725 800 GB + 6xSATA SSD Toshiba HK4E 1.6 TB.
- All-flash — 1 дисковая группа: 1xNVMe SSD Samsung PM1725 800GB + 6xSATA SSD Toshiba HK4E 1.6 TB + Space Efficiency (дедупликация и компрессия).
- All-flash — 1 дисковая группа: 1xNVMe SSD Samsung PM1725 800GB + 6xSATA SSD Toshiba HK4E 1.6 TB + Erasure Coding (RAID 5/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 Тб, соответственно).
Для каждой конфигурации выполнялся одинаковый набор тестов со следующими профилями нагрузки:
- 0 чтение/100 запись, случайно 50%, размер блока — 4k.
- 30 чтение/70 запись, случайно 50%, размер блока — 4k.
- 70 чтение/30 запись, случайно 50%, размер блока — 4k.
- 100 чтение/0 запись, случайно 50%, размер блока — 4k.
Первый и четвёртый варианты были нужны, чтобы понять, как система будет вести себя под максимальными и минимальными нагрузками. А вот второй и третий уже максимально приближены к реальному типовому сценарию использования: например, 30 чтение/70 запись — VDI. Те нагрузки, с которыми я сталкивался в продакшене, были очень к ним близки. В процессе мы тестировали эффективность механизма управления данными vSAN.
В целом система показала себя очень неплохо. По результатам тестирования мы поняли, что можем рассчитывать на показатели в районе 20 тысяч IOPS на узел. Для рядовых и высоконагруженных задач это хорошие показатели с учётом задержек в 5 мс. Ниже я привёл графики с результатами:
Итоговая таблица с результатами тестирования:
Зелёным цветом отмечены активные данные, полностью попадающие в кэш.
Отказоустойчивость
Я вырубал один узел за другим, несмотря на возмущение машины, и смотрел на реакцию системы в целом. После отключения первого узла вообще ничего не произошло, кроме небольшого падения производительности, примерно на 10–15%. Потушил второй узел — часть виртуальных машин отключилась, но остальные продолжили работу с небольшой деградацией производительности. В целом живучесть порадовала. Перезапустили все узлы — система чуть задумалась и снова синхронизировалась без каких-либо проблем, все виртуальные машины запустились без каких-либо проблем. Как в своё время на NUC’ах. Целостность данных тоже не пострадала, что очень порадовало.
Общие впечатления
Программно-определяемые системы хранения данных (SDS) уже вполне зрелая технология.
Сегодня один из ключевых стоп-факторов, стоящих на пути внедрения vSAN, — это достаточно высокая стоимость лицензии в рублях. Если вы создаёте инфраструктуру с нуля, может получиться, что традиционная система хранения данных в сходной конфигурации будет стоить примерно столько же. Но при этом будет менее гибкой как с точки зрения администрирования, так и масштабирования. Так что сегодня при выборе решения для хранения данных виртуальных машин на платформе виртуализации vSphere стоит очень хорошо взвесить все плюсы и минусы использования традиционных решений и внедрения технологии программного-определяемого хранения.
Можно собрать решение на том же Ceph или GlusterFS, но при работе с инфраструктурой VMware подкупает тесная интеграция vSAN с отдельными компонентами, а также простота администрирования, развёртывания и заметно большая производительность, особенно на небольшом количестве узлов. Поэтому если вы уже работаете на инфраструктуре VMware, то вам будет гораздо проще с развёртыванием. Вы реально делаете десяток кликов и получаете работающую SDS из коробки.
Другой мотивацией к развёртыванию именно vSAN может быть использование её для филиалов, которое позволяет зеркалить узлы в удалённых подразделениях с witness хостом в дата-центре. Такая конфигурация позволяет получить отказоустойчивое хранилище для виртуальных машин со всеми технологиями и производительностью vSAN всего на двух узлах. Кстати, для использования vSAN есть отдельная схема лицензирования по количеству виртуальных машин, что позволяет сократить затраты в сравнении с традиционной схемой лицензирования vSAN по процессорам.
Архитектурно решение требует 10 Gb Ethernet с двумя линками на узел для адекватного распределения трафика при использовании all-flash решения. В сравнении с традиционными системами вы экономите место в стойке, экономите на SAN-сети за счёт отказа от Fibre Channel в пользу более универсального стандарта Ethernet. Для обеспечения fault tolerance требуется минимум три узла, на двух будут храниться реплики объектов с данными, а на третьем — witness объекты для этих данных, решает проблему сплитбрейна.
Теперь несколько вопросов к вам:
- Когда вы определяетесь с системой хранения, то какие критерии для вас наиболее важны?
- Какие стоп-факторы вы видите на пути внедрения программно-определяемых систем хранения данных?
- Какие программно-определяемые системы хранения данных вы в принципе рассматриваете в качестве варианта для внедрения?
Автор: SSkryl
