VMware Virtual SAN в бете: конвергентная инфраструктура без выделенного SAN

На VMworld 2013 VMware показала Virtual SAN - технологию, которая агрегирует локальные диски ESXi-хостов в распределённый datastore прямо в гипервизоре. Никакого выделенного SAN-массива, никаких FC-коммутаторов, никаких лицензий на стороннее хранилище. Нам это показалось достаточно интересным, чтобы записаться в бета-программу и не ждать общего доступа.

Стенд собрали из трёх хостов, у каждого - одна SSD под кеш записи и два HDD под ёмкость. vSphere 5.5, бета-лицензия vSAN, стандартный 10GbE между хостами. Минимальная конфигурация по требованиям VMware: три хоста, один SSD + минимум один HDD на каждый. Мы в эти рамки уложились.

Идея. vSAN работает как программная прослойка прямо в ядре ESXi. Виртуальные машины пишут в объекты хранилища, которые vSAN автоматически зеркалирует между хостами согласно политике (Number of Failures to Tolerate, NFT). При NFT=1 каждый объект живёт как минимум на двух хостах плюс witness-компонент на третьем. Три хоста - минимум для этого режима, и именно поэтому меньше трёх VMware не пускает.

Первые замеры latency на синтетических нагрузках оказались неплохими. SSD работает как write buffer - запись уходит сначала на кеш и только потом вымывается на HDD. Задержки на запись субъективно ощутимо ниже, чем на аналогичном iSCSI-стенде с традиционным массивом. Читать чуть сложнее: если данные ещё в SSD-кеше, быстро, если уже вымылись на HDD - обычные дисковые задержки. Ничего неожиданного, но важно понимать это при планировании нагрузки.

Отказоустойчивость проверяли методом «выдернуть кабель». Остановили один хост, подождали. vSAN через несколько секунд перешёл в degraded-режим, ВМ на оставшихся двух хостах продолжили работу без ребута - доступность данных сохранилась. Потом вернули хост - началась ресинхронизация объектов в фоне, ВМ не заметили. Классический behaviour для зеркалирования, но приятно видеть его работающим без отдельного storage-контроллера.

Есть несколько моментов, которые настораживают на этапе беты:

• Сеть - узкое место. Весь inter-node трафик идёт через тот же 10GbE, что и трафик VM. При интенсивной ресинхронизации (например, после возврата упавшей ноды) это чувствуется. VMware рекомендует выделять отдельный vmkernel port для vSAN трафика, и это не просто совет.
• Поддерживаемое железо. Бета пока требует HCL-совместимых SSD и HDD. Наши диски прошли, но список пока короткий - есть риск, что в продакшне под требования не попадут диски, которые уже стоят в хостах.
• Нет дедупликации и компрессии. В текущей бете их нет. Эффективная ёмкость - ровно то, что физически есть на дисках, делённое на коэффициент зеркалирования.
• Мониторинг сырой. В vSphere Web Client появился базовый health view для vSAN, но глубокую диагностику пока сложно получить без CLI.

Отдельно стоит сравнить с тем, что мы смотрели раньше. Ceph мы щупали в июле - open-source, гибко, но требует серьёзной экспертизы в настройке и операционно сложнее. Storage Spaces в Windows Server 2012 - хорошая идея, но живёт только в Windows-стеке. vSAN встроен прямо в ESXi и не требует дополнительной ОС - это реальное преимущество для тех, кто уже на VMware.

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

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