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

    Год назад я собрал дата-центр из стопки 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 — одного из наиболее популярных ПО для синтетического нагрузочного тестирования. Железо было в следующих вариантах конфигурации:

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

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

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

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

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

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


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

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

    2. Описание версий ПО:
    vSphere 6.5U1 (7967591) (vSAN 6.6.1), т.е. патчи после Meltdown/Spectre
    vCenter 6.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

    3. Параметры нагрузки:
    • HCIBench 1.6.6
    • Oracle Vdbench — 5.04.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.5 hour), Test time 3600 (1 hour)
    • 1 Threads per vmdk
    КРОК 110,80
    №1 по ИТ-услугам в России
    Поделиться публикацией
    Похожие публикации
    Комментарии 22
      0
      вы экономите место в стойке

      Спорный аргумент на мой взгляд. Современные СХД — 3U, минимум для SDS — 3 ноды по 1U.
      экономите на SAN-сети за счёт отказа от Fibre Channel

      Так же на мой взгляд спорно, ввиду того, что традиционные схд давно работают по iSCSI.
        0
        Спорный аргумент на мой взгляд. Современные СХД — 3U, минимум для SDS — 3 ноды по 1U.

        Верно, если говорить об использовании SDS как отдельно стоящего решения, аналогично традиционным СХД. Но если говорить про гиперконвергентные решения, где на одном сервере объединяются вычислительные мощности для ВМ и дисковые ресурсы для SDS, то здесь экономия мест на лицо — вообще не нужно место для СХД, только для серверов.

        Так же на мой взгляд спорно, ввиду того, что традиционные схд давно работают по iSCSI.
        Использование iSCSI с традиционными СХД позволяет сэкономить, в сравнении с Fiber Channel, за счет отказа от специализированного FC-оборудования и использования Ethernet.
        Кстати, если есть необходимость предоставить ресурсы хранения vSAN серверам работающим не под управлением гипервизора ESXi — это можно сделать также через iSCSI.
          0
          если говорить об использовании SDS как отдельно стоящего решения

          Согласен, но вы по-моему про vSAN, как отдельно стоящее решение и пишите. И в этом же контексте делаете выводы.
            0
            В этой статье мы сделали фокус на vSAN, как на SDS решение. Но в реальной жизни рассматривать vSAN в отрыве от платформы виртуализации vSphere и гиперконвергентного сценария не стоит.
              0
              Я то понимаю, но вы бы в статье на это больше акцент сделали.
        0
        Прочитал предыдущую статью
        дата-центр из стопки Intel NUC

        И задумался. А можно ли на Intel NUC собрать кластер с vsan?
        или какое нибудь похожее компактное решение в которое можно впихнуть пару sata дисков и диск под кеш? плюсом засунуть 2-х портовую карточку на 10 ГБ? Хочу собрать такой лабораторный стенд. Закупить железа с того же али чтобы много денег не тратить.
        Уложиться в 300-350$ за ноду
        По поводу vSAN как я понял вы брали диски из списка совместимости vmware?
        Т.е. купили пустые корзины для дисков, заказали совместимые диски и установили их в сервер?
        Мне для 1 проекта считали vSAN решение и оно вышло просто космос. В основном из-за очень большой стоимости вендорских дисков. Просто читал что идеология vSAN допускает использование каких нибудь потребительских SSD?
          0
          Если говорить про NUC и другие компактные решения, то основным ограничениям можно отнести отсутсвие сетевых интерфейсов 10 GbE (который нужен, если мы рассчитываем на хорошую производительность) и относительно маленькое количество дисков, которое можно установить в подобное решение.
          Что касается дисков, то vSAN может работать с любыми дисками которые доступны гипервизору ESXi. В том числе, и с дисками для потребительского рынка, но их ресурс и производительность могут быть меньше, чем у корпоративных. Но ключевым, с точки зрения производительности и надежности инфраструктуры vSAN, является дисковый контроллер, который как раз и делает установленные в сервер диски доступными ESXi. Крайне желательно, чтобы дисковый контроллер поддерживал режим Host Bus Adapter, который на прямую подключает диски, минуя необходимость создавать RAID0 для каждого.
            0

            Думаю, что вопрос касался использовали вы родные диски Dell с их контроллером или же взяли OEM Samsung и Toshiba из HCL. И были ли какие-то нюансы, например с firmware.

              0
              У нас были диски OEM. На этом стенде (и вообще по опыту) проблем с дисками у меня не было. Чаще проблемы возникают, если пробовать использовать старые дисковые контроллеры, которых нет в HCL. Но, как правило, это тоже решается созданием RAID0 для каждого диска.
              В HCL указывается не только поддерживается диск или нет, но и сведения о версии ESXi, драйвера, прошивки и для каких задач его можно использовать (кэширование и/или хранение).
              Вот пример сведений о диске, который мы использовали под кэш, в HCL — www.vmware.com/resources/compatibility/detail.php?deviceCategory=ssd&productid=40177&deviceCategory=ssd&details=1&vsan_type=vsanssd&keyword=PM1725&vsanrncomp=true&page=3&display_interval=10&sortColumn=Partner&sortOrder=Asc

                0
                В продакш это можно использовать? Или возможны проблемы с поддержкой Dell?
                  0
                  Насчет поддержки Dell не уверен, а с VMware проблем не будет, поскольку устройство есть в HCL.
          0
          с дисками для потребительского рынка

          Для некоторых классов задач хватает и этого. Всякие демо стенды, или не нагруженные проекты. Если что проект перевозим в продакшен а стенд отдаём дальше.
          А где покупать салазки для дисков? Например есть сервера DELL R730.
          И правильно ли я понимаю что если у сервера корзина для SAS то SATA диски в неё поставить можно?
          является дисковый контроллер
          про контроллер понятно.
          Буду иметь в виду. Насколько критично наличие именно дисков в списке совместимость с vSAN?
          Я правильно понял что ESXi умеет вложенную виртуализацию?
          Что имея например ПК с CPU 8/16 (очень жду новый интел ) ), RAM 64 ГБ и VMware Workstation Pro можно сделать 3 виртуалки с ESXi и поднять уже на ESXi другие VM?
          и будет такой демо стенд?

            0
            А где покупать салазки для дисков?

            ебай, да и у нас полно контор, кто таким торгует, хоть на авито можно найти по сходной цене
            то SATA диски в неё поставить можно

            можно
            ESXi умеет вложенную виртуализацию

            там кое что надо докрутить, но в целом — да, я hyper-v разворачивал на стенде vmware
              0
              Наличие диска в списке совместимости гарантирует его корректную работу c vSAN, а если возникнут какие-либо проблемы, том можно будет обратиться в техническую поддержку VMware за помощью. При этом отсутсвие диска в списке совместимости не означает, что он не будет работать. В моем понимании, большинство современных дисков работать будет, но лучше тестировать пред покупкой.

              Относительно вложенной виртуализации, да, это возможно, но ожидать от такой конфигурации производительности не стоит. У меня был успешный опыт с вложенными ESXi, Hyper-V и KVM.
              0
              Гм… Интересненько. Как раз заканчиваю построение бюджетной ГКС для одного небольшого Заказчика Proxmox VE + Ceph Bluestore + Open vSwitch на 3-х нодах. Еще один старичок ML150 G6 используется как iSCSI хранилище с ZFS — бэкапы, образы дисков, темплейты LXC.
              Параметры серверного железа — 2xCPU 4108, 128 GB DDR4 2400, 16 GB SD-карта Class10 под ОС, 1 TB SSD NVMe, 2x6 TB Sata HDD, 2x1Gbit, 2x10Gbit.
              Нарезал SSD по 4 OSD + кусочки под wal/db HDD. Производительность и отказоустойчивость радует.
              В сторону vSAN тоже смотрел — но не устроила цена, лицензии vSphere Essentials Plus + vSAN оказались дороже железа.
                0
                Proxmox VE + Ceph Bluestore + Open vSwitch на 3-х нодах

                Если не супер секретно и не затруднит то хотелось бы увидеть цикл статей.
                Что можно использовать как альтернативу VMWARE в инсталляциях на 3-4 сервера.
                Для не большой инфраструктуры.
                  0

                  Конечно не секретно, статьи пишутся. Я с командой админов 2 месяца уже над этим работаю, пока тесты, разные варианты ceph, развертывания VM и прочее.
                  Через пару недель ввод в эксплуатацию, затем вылизывание мелочей, документация на систему, тогда и начну выкладывать статьи.

                    0
                    Я с командой админов 2 месяца уже над этим работаю,...

                    Скажите, пожалуйста, а эти затраты (и будущие затраты на вылизывание мелочей) Вы учитывали при сравнении цен различных решений?

                    И к слову, конфигурация 2xCPU 4108, 128 GB несколько не сбалансирована по памяти. У сильверов память 6-и канальная и лучше распределять установленную память по всем из них.
                      0

                      Ну админы Заказчика и я получают ЗП (Заказчиком является работодатель, просто я рассматриваю это как проектную работу). Это наша работа, вылизать систему, чтобы спать потом спокойно ;)
                      По памяти я конечно в курсе, апгрейд никто не отменял. Задача была в этом году обновить серверную группу за определенный бюджет и перенести существующие сервисы. На следующий год планирую расширение системы, так как осенью будет внедрение СЭД, далее в течении пары лет MES, ERP.

                    0

                    Очень познавательно, спасибо.

                      0
                      Спасибо, получилась очень интересная статья. Безусловно, для онлайн процессинга и БД в целом требования по задержкам дисковой подсистемы значительно выше. Но для значительной части корпоративных приложений, инфраструктурных служб, по нашему опыту, задержки в 10-15 мс не сильно влияют на производительность, а, например, для виртуализации рабочих станций (VDI) задержки в 25-30 мс практически не заметны пользователю и, соответсвенно, никак не влияют на его работу.

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

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