Windows Server 2012 Storage Spaces: тестируем software-defined хранилище на дешёвом JBOD

Storage Spaces в Windows Server 2012 Microsoft презентовал как «SAN для тех, кто не хочет покупать SAN». Звучит красиво, но красивые презентации Microsoft мы слышали много раз. Когда у одного из клиентов на сопровождении встал вопрос замены стареющего NAS, решили проверить, насколько это работает на практике.

Контекст задачи

Клиент - небольшая торговая компания, файловый сервер на Windows Server 2008 R2, около 30 пользователей, общий объём хранилища около 4 ТБ. Старый NAS (Synology на паре дисков) справлялся, но диски заполнялись, производительность на крупных файлах была посредственной, резервирование нулевое. Бюджет на замену - скромный. SAN с Fibre Channel - мимо, iSCSI-полка приличного уровня - тоже дорого. Вариант с Windows Storage Spaces на дешёвом JBOD-корпусе и нескольких SATA-дисках выглядел как возможный выход.

Взяли для теста четыре диска по 2 ТБ (Western Digital Red, предназначенные для NAS-устройств - с поддержкой TLER), недорогой JBOD-корпус с SAS-экспандером и Windows Server 2012 Datacenter, который уже был в лицензиях клиента.

Как устроены Storage Spaces

Технически Storage Spaces - это программный RAID с некоторыми дополнительными возможностями, но термин «программный RAID» немного упрощает.

Пул из физических дисков объединяется в один логический ресурс. Из пула создаются виртуальные диски - Storage Spaces. Каждый виртуальный диск можно настроить с разной схемой отказоустойчивости:

• Simple - без избыточности, данные на одном диске или полосами. Быстро, но при потере диска - всё.
• Mirror - двух- или трёхстороннее зеркало. Надёжно, но дорого по объёму.
• Parity - аналог RAID 5: избыточность с одним диском чётности на три рабочих. Эффективнее по месту, медленнее на записи.

Особенность, которая сразу привлекает внимание - thin provisioning. Виртуальный диск можно создать размером 6 ТБ при физическом пуле в 4 ТБ. Он будет реально занимать столько места, сколько в него записали. Это не экзотика: thin provisioning давно есть в дорогих СХД, но в бесплатной роли Windows Server - довольно неожиданно.

Что получилось на практике

Настройка через PowerShell прямолинейная. Создаём пул:

New-StoragePool -FriendlyName "DataPool" -StorageSubsystemFriendlyName "..." -PhysicalDisks (Get-PhysicalDisk -CanPool $true)

Создаём виртуальный диск с parity:

New-VirtualDisk -StoragePoolFriendlyName "DataPool" -FriendlyName "FileShare" -Size 4TB -ResiliencySettingName Parity -ProvisioningType Thin

Дальше - стандартный Windows: создаём том, форматируем NTFS, расшариваем через SMB 3.0.

Thin provisioning работает именно так, как описано: виртуальный диск на 6 ТБ при пуле 4 ТБ создаётся без ошибок, занимает реальное место по мере записи. Когда физический пул приближается к заполнению, Storage Spaces присылает алерт. Добавление диска в пул - онлайн, без остановки.

Автоматическое перераспределение нагрузки - это реально работающая вещь. Storage Spaces следит за тем, как данные распределены по физическим дискам в пуле, и при добавлении нового диска предлагает перебалансировать данные. Вручную это делается командой Optimize-StoragePool. В нашем случае после добавления пятого диска через три месяца баланс выровнялся за несколько часов без остановки сервиса.

Parity tier - самое слабое место. Производительность записи на parity-пространстве заметно ниже, чем на mirror. Для файлового сервера с крупными файлами это некритично, но если бы это был сервер баз данных - не подошло бы. Чтение работает нормально, запись на большие блоки - приемлемо, мелкая случайная запись - заметно хуже зеркала. На диски WD Red с их относительно скромными IOPS это особенно ощутимо.

Tiering. В Windows Server 2012 Storage Spaces поддерживает два уровня - SSD и HDD в одном пуле, с автоматическим размещением горячих данных на SSD. Мы этот сценарий не тестировали в данной конфигурации - клиент не добавлял SSD в пул, бюджет уже был потрачен на диски и корпус.

Где споткнулись

Первая неприятность - определение физических дисков. Дешёвый SAS-экспандер в JBOD-корпусе создавал путаницу с идентификаторами дисков: PowerShell видел диски, но SerialNumber у нескольких отображался одинаково - артефакт экспандера. Это не влияло на работу пула, но мешало однозначно идентифицировать диск по номеру слота при потенциальной замене. Решили наклейками и ведением таблицы соответствия вручную - не элегантно, но работает.

Второй момент - восстановление после потери диска. На тесте специально вытащили один диск из работающего parity-пула. Storage Spaces деградировал пул без отказа и начал ребилд после вставки нового диска. Ребилд на четырёх дисках по 2 ТБ занял несколько часов. В это время производительность падает заметно - Storage Spaces активно читает и пишет, ребилд не throttled по умолчанию. Для файлового сервера в рабочее время это был бы неприятный момент. Есть способ настроить приоритет ребилда через PowerShell, но это не очевидно из документации.

Итог на сегодня

Клиент переехал на Storage Spaces около месяца назад. Работает, претензий нет. Файловый сервер доступен, thin provisioning даёт запас по объёму без немедленной закупки дисков, производительность для задачи - достаточная.

Storage Spaces не заменяет нормальную СХД для нагрузок с интенсивной записью. Но для файлового сервера в небольшой компании, которой NAS класса Synology уже мал, а настоящий SAN не нужен и дорог - это вполне рабочий вариант. Особенно если Windows Server 2012 уже есть в лицензиях.

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