Storage Spaces Direct на трёх узлах: гиперконвергенция без SAN на GA-релизе

В сентябре мы гоняли S2D на TP5 и пришли к выводу, что для продакшна нужно дождаться GA. Дождались. Windows Server 2016 вышел GA в октябре, и в начале марта мы наконец собрали нормальный стенд на финальном релизе - три физических сервера, NVMe + SSD, реальная нагрузка. Рассказываем что получилось.

Конфигурация

Три ноды, каждая с двумя NVMe под кеш и четырьмя SATA SSD под ёмкость. Сетка - 25G между нодами. Операционная система - Windows Server 2016 Datacenter, Failover Cluster поверх, S2D включён через Enable-ClusterStorageSpacesDirect. CSV на ReFS - как и рекомендует Microsoft.

Это стандартная гиперконвергентная схема: хранилище и вычисление на тех же нодах, никакого внешнего массива. Hyper-V виртуалки живут на дисках, которые физически лежат в тех же серверах.

Важный момент про Enable-ClusterStorageSpacesDirect на GA: команда стала заметно умнее по сравнению с TP5. Она сама определяет тип дисков, правильно настраивает cache-tier и не требует ручного указания cache-режима в большинстве конфигураций. Мелочь, но приятно.

Что померяли

Чистых синтетических цифр без контекста приводить не будем - они зависят от железа, блока, глубины очереди и фазы луны, и сравнивать их с чужим стендом бессмысленно. Лучше расскажем про качественные наблюдения.

Случайное чтение - S2D хорошо использует NVMe-кеш. Горячие блоки стабильно обслуживаются с кеша, latency предсказуемо низкая. Пока данные лежат на той же ноде, где работает виртуалка, - это видно.

Случайная запись - тут интереснее. S2D пишет через mirror, то есть каждый блок идёт минимум на две ноды через сеть. 25G здесь не роскошь: на 10G-конфигурации мы видели существенно более высокую latency на write-нагрузке, и это ожидаемо. Если планируете S2D - закладывайте минимум 10G, в идеале 25G с RDMA.

Sequential - тут S2D не рекордсмен по сравнению с нормальной СХД, но для задач виртуализации хватает с запасом.

Общее впечатление: для OLTP-нагрузки на виртуалках - нормально. Для систем с действительно жёсткими требованиями к latency - разговор отдельный.

Отказоустойчивость при вылете диска

Вот это тестировали особо тщательно, потому что именно здесь интереснее всего.

Физически выдергивали SATA SSD из работающей ноды. S2D определяет потерю диска быстро - несколько секунд. Дальше начинается перестройка зеркала: данные с вышедшего диска восстанавливаются на оставшихся. На трёх нодах с трёхсторонним зеркалом виртуалки продолжали работать без прерывания - IO шёл через оставшиеся ноды.

Время восстановления зависит от объёма данных на погибшем диске. На нашем стенде перестройка на 200-300 ГБ заняла около часа при фоновой нагрузке. В процессе восстановления IO-производительность заметно проседает - это нужно учитывать при планировании окна обслуживания.

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

Поведение при потере целой ноды (симулировали жёстким выключением) - аналогичное. Виртуалки перезапустились на оставшихся двух нодах через несколько минут. Восстановление Storage Space после возврата ноды - автоматическое.

Мониторинг: всё ещё руками

Одна из шероховатостей, которую мы отметили ещё в TP5, никуда не делась: нормальной готовой интеграции для мониторинга S2D нет. Get-StorageSubSystem, Get-PhysicalDisk, Get-StorageJob - всё это работает и даёт нужную информацию, но автоматически она никуда не идёт.

Мы написали PowerShell-скрипты, которые экспортируют ключевые метрики в Zabbix через zabbix_sender. Набор примерно такой:

• состояние каждого физического диска (HealthStatus, OperationalStatus)
• состояние пула и виртуальных дисков
• объём оставшегося места с учётом реального использования (не raw)
• текущая нагрузка на IO по нодам

Без этого следить за здоровьем кластера можно только через графический диспетчер отказоустойчивости или PowerShell руками - что не вариант для управляемой инфраструктуры.

Лицензионный аспект

S2D доступен только в Datacenter-редакции. Для заказчика, который уже берёт Datacenter ради безлимитных Hyper-V-гостей - это ничего не добавляет к стоимости. Для тех, кто рассматривал Standard - это дополнительная строка в счёте при переходе.

Сравнение с VMware VSAN в лоб не всегда корректно из-за разных схем лицензирования, но для Windows-ориентированных заказчиков на Datacenter S2D выглядит честнее по деньгам.

Промежуточный итог

GA-версия S2D заметно зрелее TP5. Автоматическая настройка cache-tier, нормальное восстановление после потери диска, предсказуемое поведение Failover Cluster - это уже не «посмотреть интересно», а что-то, что можно ставить в продакшн.

Один из клиентов с устаревшей СХД - реальный кандидат на миграцию. Считаем спецификацию. Разговор будет по итогам более длительного прогона стенда под нагрузкой - несколько недель в TP5 и пара недель на GA дают картину, но не дают уверенности на год вперёд.