Storage Spaces Direct в TP5: гиперконвергенция на Windows без SAN и без доплат

У нас есть несколько SMB-клиентов, которым нужна виртуализация, но которым SAN - это дорого, громоздко и вообще непонятно зачем. Раньше разговор заходил в тупик: либо покупаете СХД, либо терпите отсутствие живой миграции и shared-хранилища. Третьего не было. С появлением Storage Spaces Direct в Windows Server 2016 Technical Preview 5 третье, кажется, появилось.

Что такое S2D и почему это интересно

Storage Spaces Direct - это механизм в Windows Server, который позволяет объединить локальные диски нескольких серверов в общий пул хранения через SMB3 без какой-либо внешней СХД. Cluster Shared Volumes поверх этого пула, Hyper-V поверх CSV - и получается гиперконвергентный кластер из обычного железа.

Звучит похоже на VSAN от VMware. Разница принципиальная для определённого сегмента заказчиков: S2D входит в Windows Server 2016 Datacenter без отдельной лицензии на программно-определяемое хранилище. Для тех, кто уже платит за Windows и Hyper-V, это не дополнительная строка в счёте.

В TP5 функциональность наконец стала достаточно полной чтобы её можно было тестировать без ощущения что что-то обязательно отвалится через пять минут.

Стенд

Три физических сервера, каждый с парой NVMe-дисков и сетью 10G. Ничего экзотического - то, что можно купить у обычного поставщика железа. Операционная система - Windows Server 2016 TP5 (Technical Preview 5, вышедший в мае 2016).

Схема кластера стандартная для S2D:

• три ноды с локальными дисками
• Failover Cluster поверх
• SOFS (Scale-Out File Server) как слой хранения
• CSV на базе Storage Spaces Direct
• виртуалки на Hyper-V с дисками на CSV

Настройка занимает меньше времени, чем мы ожидали. Ключевые шаги в PowerShell:

# Включить S2D на кластере
Enable-ClusterStorageSpacesDirect -CacheMode Disabled

# Создать пул и том
New-Volume -FriendlyName "VMs" -FileSystem CSVFS_ReFS -StorageTierFriendlyNames Performance -StorageTierSizes 2TB

После этого /ClusterStorage/VMs появляется на всех нодах и доступен для Hyper-V. Живая миграция работает. Это само по себе уже хорошо.

Что показало тестирование

NVMe в S2D без cache-tier ведут себя ожидаемо хорошо на случайных операциях. На sequential write три ноды с NVMe дают достойный суммарный результат - хотя конкретные цифры мы намеренно не приводим, потому что они сильно зависят от железа и конфигурации, и переносить их на другой стенд некорректно.

Важнее качественное наблюдение: S2D использует локальные диски с read cache поверх хранилища. Если данные читаются преимущественно с той же ноды, где они физически лежат, - latency низкая. Если виртуалка переехала на другую ноду, чтение идёт через сеть. 10G тут не роскошь, а минимум - на 1G-стыках всё это выглядит заметно хуже.

Отдельный момент - ReFS вместо NTFS. S2D рекомендует ReFS как файловую систему для CSV, и это правильно: ReFS умеет Mirror Accelerated Parity, что даёт более разумное использование пространства при трёх и более нодах. NTFS технически тоже работает, но теряет некоторые оптимизации.

Почему это важно для SMB

Раньше разговор про высокодоступную виртуализацию на Windows-стеке для небольшого заказчика выглядел примерно так: нужен Hyper-V кластер, нужен shared storage, значит нужна СХД, значит либо дорогой дисковый массив, либо iSCSI через что-то вроде StarWind или Starboard, либо Ceph - но это уже Linux и другой стек. Ни один из вариантов не был по-настоящему дешёвым и простым одновременно.

S2D на managed-инфраструктуре закрывает этот пробел конкретно. Три стандартных сервера, Windows Server 2016 Datacenter (который многие заказчики всё равно берут под лицензионные нужды), и кластер с shared-хранилищем готов. Без отдельной СХД, без дополнительного ПО, без Linux рядом.

Для клиента с пятнадцатью-двадцатью виртуалками и бюджетом, где СХД выглядит непропорционально дорогой, - это первый вариант на Windows-стеке, который звучит разумно.

Шероховатости TP5

Технологическое превью остаётся превью. Пара наблюдений:

• Обновление прошивки дисков - S2D в TP5 не всегда корректно переживает обновление прошивки NVMe без ручного вмешательства. Документация Microsoft об этом честно предупреждает.
• Удаление ноды из кластера - операция работает, но требует внимания к тому, что S2D делает с данными при drain-е. На трёх нодах минимальная конфигурация для отказоустойчивости, и убрать одну ноду на обслуживание можно только если оставшихся двух хватает по месту.
• Мониторинг - нормального внешнего мониторинга для S2D в TP5 нет. Get-StorageHealthReport и Get-PhysicalDisk дают информацию, но интеграции в Zabbix или Prometheus из коробки нет - нужно писать скрипты.

Ни одно из этих ограничений не смертельно для тестового стенда. Для продакшн, скорее всего, нужно дождаться GA.

Где мы сейчас

Стенд работает третью неделю. Живая миграция между нодами - без вопросов. Симулировали потерю одной ноды: кластер пережил, виртуалки перезапустились на оставшихся двух, восстановление Storage Spaces после возврата ноды заняло несколько минут.

Для одного из клиентов, которого мы рассматривали в контексте замены устаревшей СХД, S2D теперь в списке вариантов. Конкретное решение будет после GA Windows Server 2016 - брать продакшн на TP5 мы не готовы. Но картина уже достаточно понятная чтобы начать считать спецификацию.

Параллельно продолжаем смотреть на Ceph для Linux-стека - не все заказчики на Windows, и выбор инструмента зависит от конкретного контекста, а не от симпатий.