- PVSM.RU - https://www.pvsm.ru -
Год назад я собрал дата-центр из стопки Intel NUC [1]. Там была программная система хранения данных, которую не смогла порушить уборщица, пару раз развалившая кластер.
И вот теперь мы решили погонять vSAN на нескольких серверах в очень хорошей конфигурации, чтобы всецело оценить производительность и отказоустойчивость решения. Конечно, у нас был ряд успешных внедрений в продакшен у наших заказчиков, где vSAN успешно решает поставленные задачи, но провести всеобъемлющее тестирование не доводилось. Собственно, результатами тестов я и хочу сегодня поделиться.
Будем мучить хранилище нагрузкой, ронять его и всячески тестировать отказоустойчивость. За подробностями всех приглашаю под кат.
Есть обычный серверный кластер для виртуальных машин. В нём куча независимых компонентов, гипервизор запускается непосредственно на железе, а хранилище конфигурируется отдельно на базе DAS, NAS или SAN. Медленные данные на HDD, горячие — на SSD. Всё привычно. Но тут возникает проблема развёртывания и администрирования этого зоопарка. Особенно весело становится в ситуациях, когда отдельные элементы системы от разных вендоров. В случае проблем стыковка тикетов для техподдержки разных производителей — своя особая атмосфера.
Есть отдельные железки, которые с точки зрения сервера выглядят как диски для записи.
И есть гиперконвергентные системы. В них вам выдают универсальный юнит, который берёт на себя всю головную боль по взаимодействию сети, дисков, процессоров, памяти и тех виртуальных машин, которые на них крутятся. Все данные стекаются в одну панель управления, и при необходимости можно просто добавить ещё пару юнитов для компенсации выросшей нагрузки. Администрирование очень сильно упрощается и стандартизируется.
VMware vSAN как раз и относится к решениям, на базе которых развёртывается
гиперконвергентная инфраструктура. Ключевой фишкой продукта является тесная интеграция с платформой виртуализации VMware vSphere, являющейся лидером среди решений по виртуализации, что позволяет развёртывать на серверах виртуализации программное хранилище для виртуальных машин за считаные минуты. vSAN непосредственно берёт на себя управление операциями ввода/вывода на низком уровне, оптимально распределяя нагрузку, занимается кэшированием операций чтения/записи и делает ещё кучу вещей с минимальной нагрузкой на память и процессор. Прозрачность работы системы несколько снижается, но в результате всё работает, что называется, automagically vSAN можно сконфигурировать как гибридное хранилище и в виде all-flash-варианта. Масштабируется как горизонтально добавлением новых узлов в кластер, так и вертикально, увеличивая количество дисков в отдельных узлах. Управление с помощью их же веб-клиента vSphere очень удобное за счёт тесной интеграции с другими продуктами.
Мы остановились на чистой all-flash конфигурации, которая по расчётам должна быть оптимальной по соотношению цены и производительности. Понятно, что суммарная ёмкость несколько ниже в сравнении с гибридной конфигурацией, использующей магнитные диски, но тут мы решили проверить, как это частично можно обойти, используя erasure coding, а также дедупликацию и компрессию на лету. В итоге эффективность хранения становится ближе к гибридным решениям, но существенно быстрее при минимальном оверхеде.
Для тестирования производительности использовалось ПО HCIBench v1.6.6 [2], которое автоматизирует процесс создания множества виртуальных машин и последующее сведение результатов. Само тестирование производительности выполняется средствами ПО Vdbench — одного из наиболее популярных ПО для синтетического нагрузочного тестирования. Железо было в следующих вариантах конфигурации:
В процессе тестов мы эмулировали три различных объёма активных данных, используемых приложениями: 1 Тб (по 250 Гб на сервер), 2 Тб (по 500 Гб на сервер) и 4 Тб (по 1 Тб, соответственно).
Для каждой конфигурации выполнялся одинаковый набор тестов со следующими профилями нагрузки:
Первый и четвёртый варианты были нужны, чтобы понять, как система будет вести себя под максимальными и минимальными нагрузками. А вот второй и третий уже максимально приближены к реальному типовому сценарию использования: например, 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
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/282966
Ссылки в тексте:
[1] собрал дата-центр из стопки Intel NUC: https://habr.com/company/croc/blog/342820/
[2] HCIBench v1.6.6: https://labs.vmware.com/flings/hcibench
[3] Источник: https://habr.com/post/414125/?utm_campaign=414125
Нажмите здесь для печати.