Storage Spaces Direct на WS2019: NVMe-кластер и дедупликация, которая работает не по расписанию

Storage Spaces Direct появился в WS2016 и по тем временам это был шаг с претензией: гиперконвергентный кластер на стандартном железе без внешнего SAN. Работало, но с оговорками - про производительность NVMe много говорили, реальность была скромнее, а дедупликация работала по расписанию раз в неделю. В WS2019 Microsoft обещала исправить и то, и другое. Мы наконец проверили на реальном кластере.

Железо и мотивация

Клиент из группы managed-инфраструктур переходил с iSCSI-СХД на что-то менее монолитное. Железо уже закупили: четыре ноды, в каждой NVMe под кеш и SATA SSD под ёмкость. Под WS2016 такой кластер работал, но NVMe в этой конфигурации давал заметно меньше IOPS чем железо позволяет - узкое место было на стороне S2D, не диска. В WS2019 заявили улучшенный драйвер для NVMe и пересмотренный планировщик I/O. Хотелось проверить живьём.

Второй мотив - дедупликация. У клиента в среде виртуализации много VM с похожими базовыми образами: Windows Server 2016, несколько вариантов. На WS2016 дедупликация NTFS работала по расписанию - обычно ночью или раз в неделю. Вне окна планировщика новые блоки не дедуплицировались. На активно пишущей среде это означало что реальная экономия места запаздывала и была менее предсказуемой.

Сборка кластера

Четыре ноды, WS2019 Datacenter, роль Hyper-V, кластер через Failover Cluster Manager. S2D включается одной командой, но перед ней надо пройти несколько шагов которые документация любит упоминать вскользь.

# Валидация конфигурации - обязательно перед включением S2D
Test-Cluster -Node node1,node2,node3,node4 -Include "Storage Spaces Direct"

# Включение S2D
Enable-ClusterStorageSpacesDirect -PoolFriendlyName "S2D-Pool"

Валидация выдала предупреждение про firmware версии на одном из дисков - поставили прошивку, перезапустили тест. Это не блокер, но игнорировать не стоит: S2D чувствителен к прошивкам дисков, и проблемы в продакшне потом объяснять неудобно.

Storage tier-ы настроили вручную: NVMe-диски в Performance tier, SATA SSD в Capacity tier. Виртуальный диск с Mirror-All-Flash для IOPS-чувствительных VM, Parity для архивных данных.

Дедупликация в реальном времени

Это главное что хотели проверить. В WS2019 дедупликация NTFS получила режим реального времени, который работает в потоке записи, без отложенного расписания.

Включается просто:

Enable-DedupVolume -Volume "C:\ClusterStorage\Volume1" -UsageType HyperV
Set-DedupVolume -Volume "C:\ClusterStorage\Volume1" -MinimumFileAgeDays 0

MinimumFileAgeDays 0 - это и есть включение обработки без возраста файла. В WS2016 минимум был 3 дня и нельзя было поставить ниже для большинства типов томов.

Загрузили базовые VM-образы (несколько экземпляров Windows Server 2016 и 2019), развернули первые тестовые машины. Посмотрели статистику через неделю:

Get-DedupStatus -Volume "C:\ClusterStorage\Volume1"

Занятое место на томе сократилось примерно на 40% по сравнению с номинальным размером файлов. Это по ощущениям заметно лучше чем давал тот же набор данных на WS2016 за первую неделю - там дедупликация успевала пройти только один-два раза, и цифра была скромнее.

Важная оговорка: 40% - это на конкретном наборе данных с похожими VM-образами. На разнородных данных результат будет другим. Не стоит ждать такой же экономии на томе с базами данных или медиафайлами.

Производительность NVMe

По IOPS ситуация улучшилась по сравнению с нашим опытом с WS2016, но не драматично. NVMe в Cache tier работает ощутимо шустрее, латентности на случайном чтении мелких блоков упали - это видно на синтетических тестах (DiskSPD) и ощущается на VM с активными базами данных.

Конкретные цифры приводить смысла нет - они сильно зависят от конфигурации железа, нагрузки и размера кластера. Важнее качественное наблюдение: WS2019 перестал быть узким местом на NVMe-кешировании, и диск теперь ограничивающий фактор, а не ОС. В WS2016 на похожем железе это было наоборот.

Что было неочевидно

Хранилище кворума. Для четырёх нод нужен witness. Использовали Cloud Witness (Azure Storage Account) - в продакшне это оказалось проще чем держать отдельный файловый сервер для witness. В WS2016 Cloud Witness тоже был, но в WS2019 настройка через WAC стала в три клика вместо PowerShell-магии.

Обновление кластера. Cluster-Aware Updating работает, но с S2D требует аккуратности. При обновлении ноды S2D уходит в режим reduced resiliency пока нода оффлайн. С двумя нодами в обновлении одновременно получишь прерывание работы. Обновляли по одной ноде с паузами.

WAC как основной интерфейс. Windows Admin Center для WS2019 стал значительно удобнее для работы с кластером - дашборд S2D показывает состояние дисков, нагрузку по нодам, статус дедупликации. Для оперативного мониторинга хватает. Для автоматизации и алертинга всё равно нужен PowerShell или внешняя система - WAC не заменяет.

Что в итоге

Кластер работает вторую неделю в продакшне, нареканий нет. Дедупликация реального времени на гиперконвергентной среде с однотипными VM-образами - это реально работающая фича, а не маркетинговый слоган. Для клиентов с типовой средой виртуализации на Windows это конкретная экономия дискового пространства без изменения рабочих процессов.

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