GlusterFS 3.2 под ВМ: тест распределённого хранилища на четырёх нодах

Тема distributed storage под виртуальные машины всё настойчивее лезет в разговоры - на конференциях, в списках рассылки, в разговорах с коллегами. VMware в своих дорожных картах намекает на что-то вроде VSAN, Nutanix уже продаёт гиперконвергентные блоки, и параллельно живёт целый мир open-source решений, которые можно попробовать прямо сейчас без шести нулей в счёте.

Мы решили потрогать GlusterFS 3.2, который вышел этим летом. Выбрали его потому, что релиз принёс заметные доработки в механизм репликации - как раз то, что нужно для хранения данных ВМ.

Стенд

Четыре физических сервера с локальными дисками, объединённые в один Gluster-том. Схема - distributed replicated: данные разбиваются на два фрагмента, каждый из которых реплицируется на пару нод. Итого 2+2: отказ одной ноды из каждой пары переживаем, отказ двух нод из одной пары - нет.

Сеть - 10 GbE, без неё такие эксперименты не имеют смысла. Хорошо, что к этому моменту мы уже прошли через апгрейд сетевой фабрики.

Клиенты - несколько хостов ESXi 4.1, которые монтируют Gluster-том через NFS. Здесь сразу важная деталь: нативный FUSE-клиент GlusterFS с ESXi не дружит от слова «совсем», поэтому NFS-экспорт - единственный разумный вариант на текущий момент.

Что проверяли

Тестировали три сценария:

• Последовательное чтение/запись - файлы образов ВМ при старте и снятии снапшота.
• Случайные операции - база данных внутри ВМ под нагрузкой fio.
• Параллельная нагрузка - несколько ВМ одновременно, чтобы понять, как том ведёт себя при конкуренции.

Для сравнения брали тот же NetApp FAS, который стоит у клиента в продакшне. Цифры не буду приводить дословно - они от конфигурации зависят слишком сильно. Но общую картину описать можно.

Результаты, без украшений

На последовательных операциях Gluster держится неплохо - отставание от NetApp есть, но не катастрофическое. Жить можно, особенно если нагрузка нечастая: холодный старт ВМ, снапшоты раз в час.

На случайных операциях разрыв заметнее. Latency растёт - и это проблема именно для баз данных. GlusterFS добавляет свои накладные расходы на каждый IO, и в случайном паттерне это ощущается. NetApp со своими кешами и выделенными контроллерами выигрывает здесь ощутимо.

Параллельная нагрузка вскрыла ещё одну особенность: при записи на реплицированном томе Gluster синхронно ждёт подтверждения от обеих нод в паре. Это правильно с точки зрения надёжности, но в пиках нескольких одновременно пишущих ВМ можно наблюдать всплески latency - до этого мы не дошли, но понять механизм важно.

Где это реально работает

Производительность не дотягивает до проприетарного NAS - это честный вывод. Но есть сценарии, где это не критично:

• Dev/test окружения. Там latency в 2-3 раза выше продакшна никого не убивает, а сэкономить на хранилище хочется.
• Архивное хранилище. Старые бэкапы, логи, образы - всё, что читают редко.
• ВМ без дисковой нагрузки. Приложения, которые живут в памяти и пишут редко.

Для продакшн-баз данных или хранилища под нагруженные ВМ - пока не готовы рекомендовать. Не потому что плохо сделано, а потому что разрыв в производительности там будет чувствоваться.

Про цену

Вот здесь история интересная. Четыре ноды на обычном x86-железе с локальными дисками против NetApp FAS - разница в стоимости на терабайт примерно трёхкратная в пользу Gluster. Если добавить стоимость поддержки и лицензий NetApp, разрыв ещё шире.

Это делает сценарий реальным: взять Gluster для tier-2 хранилища, разгрузить дорогой NAS, перенести на него только то, что действительно требует производительности. Гибридная схема, которую можно построить без большого бюджета.

Что дальше

Тест показал, что технология рабочая, но с оговорками. Мы планируем прогнать ещё один цикл с другим распределением нагрузки - посмотреть, как том ведёт себя при выпадении одной ноды в каждой паре. Failover в GlusterFS работает, но нас интересует latency в момент переключения и поведение ESXi, который держит открытые образы ВМ через NFS.

Отдельный вопрос - мониторинг. Стандартный Zabbix с SNMP под Gluster не настроен из коробки, пришлось писать свои скрипты под gluster volume status. Мелочь, но в продакшне это важно.

Если занимаетесь сопровождением инфраструктуры и смотрите на distributed storage как способ снизить стоимость хранения - тема живая, но требует трезвого взгляда на профиль нагрузки. Не всякий терабайт одинаково ценен.