Storage Spaces Direct GA: первое production-внедрение S2D и что получилось с ценой хранилища

В сентябре мы гоняли S2D на TP5 и писали, что для одного из клиентов уже считаем спецификацию - но брать Technical Preview в продакшн не готовы. 12 октября Windows Server 2016 получил статус GA, и S2D вместе с ним стал официально поддерживаемым продуктом. Ждать больше нечего.

Клиент - небольшая производственная компания, у которой стоит СХД возрастом пять лет с истекающей поддержкой. Не катастрофа, но замену надо планировать, и замену дорогую: актуальный аналог той же марки с нужным объёмом стоит соответствующе. На этом фоне S2D выглядел интересно ещё полгода назад.

Конфигурация кластера

После нескольких итераций по спецификации и согласований бюджета пришли к гибридной схеме из пяти нод:

• Две ноды с NVMe - производительный tier для виртуалок с высокими требованиями к IOPS: база данных, ERP-система.
• Три ноды с HDD - ёмкостной tier для файловых хранилищ, архивов, менее требовательных виртуалок.

Сеть - 10G на каждой ноде, два порта в LACP. Это не опциональная роскошь: S2D гоняет весь трафик репликации между нодами через обычную сеть, и на 1G это сразу же ощущается.

Конфигурация Storage Spaces Direct с двумя tier-ами в PowerShell выглядит так:

# Включить S2D
Enable-ClusterStorageSpacesDirect

# Создать volume с явным распределением по tier-ам
New-Volume -FriendlyName "VMs-Performance" `
  -FileSystem CSVFS_ReFS `
  -StorageTierFriendlyNames Performance `
  -StorageTierSizes 4TB

New-Volume -FriendlyName "VMs-Capacity" `
  -FileSystem CSVFS_ReFS `
  -StorageTierFriendlyNames Capacity `
  -StorageTierSizes 20TB

S2D сам разобрался с NVMe как cache-tier для HDD-нод: write-back кэш поверх жёстких дисков без дополнительных настроек. На NVMe-нодах кэширование тоже работает - там NVMe выступают как performance tier напрямую.

Развёртывание: где ожидали сложности и где реально споткнулись

Ожидали проблем с совместимостью железа - S2D известен требовательностью к конфигурации, особенно по контроллерам. Выбрали железо из списка Windows Server Catalog, и этот момент прошёл чисто: все диски определились правильно, контроллеры не конфликтовали.

Реально споткнулись на сети. При первом запуске Enable-ClusterStorageSpacesDirect процесс завис на этапе проверки сетевой связности между нодами. Оказалось: на одном из коммутаторов был включён Spanning Tree в режиме, при котором порты уходили в learning-состояние дольше обычного. S2D при инициализации прогоняет проверку latency между нодами, и эта задержка STP его не устраивала. Перевели порты в PortFast - инициализация прошла.

Второй момент - драйверы сетевых карт. На двух нодах стояла версия драйвера, при которой RDMA (Remote Direct Memory Access) не поднимался корректно. S2D работал и без RDMA, но с явно худшей latency на трафике репликации. Обновление драйверов и настройка SMB Direct решили вопрос.

Про цену хранилища

Сравнение делали честно: итоговая стоимость S2D-кластера (пять серверов, диски, коммутаторы, лицензии WS2016 Datacenter) против актуального предложения на СХД того же вендора с аналогичными характеристиками по ёмкости и производительности.

Разница получилась в районе 2,5 раза в пользу S2D. Причём лицензии Datacenter - не дополнительные расходы сверху: клиент всё равно платил бы за Windows на серверах. S2D просто идёт в комплекте с Datacenter-редакцией без доплат.

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

Мониторинг: заранее, а не после

Прошлый тест на TP5 показал, что встроенного мониторинга S2D почти нет. В GA ситуация не сильно лучше: Get-StorageHealthReport и Get-PhysicalDisk есть, но это PowerShell, а не Zabbix.

Написали набор скриптов для managed-инфраструктуры, которые опрашивают состояние дисков, пулов и volumes через WMI и отдают метрики в Zabbix. Ничего сложного, но это примерно полдня работы которую надо делать сразу при развёртывании, а не когда что-то пойдёт не так.

Отдельно настроили алерт на OperationalStatus у физических дисков - S2D умеет работать при потере диска, но оповещение о проблемном диске должно приходить немедленно, не через сутки когда кто-то случайно посмотрит в консоль.

Где сейчас

Кластер работает первую неделю в production. Виртуалки перенесены, пользователи не заметили перехода - живая миграция с старого Hyper-V хоста прошла штатно. Производительность по субъективным ощущениям пользователей ERP-системы стала лучше - NVMe-tier это объясняет.

По S2D в production пока один вывод, который стоит фиксировать: это не «просто включили фичу». Это полноценная инфраструктурная система с требованиями к железу, сети, мониторингу и квалификации инженера. Но если всё сделано правильно - работает.