Кластерный файловый сервер: Scale-Out File Server

Обычный кластерный файловый сервер — та роль, которую мы бегло упомянули в статье про основы Failover Clustering, — работает по принципу активный-пассивный: в каждый момент времени файловый ресурс обслуживает только один узел, а второй стоит наготове и подхватывает роль при отказе первого. Для большинства офисных файловых шар этого более чем достаточно. Но если нагрузка растёт — сотни одновременных SMB-сессий, тяжёлые операции ввода-вывода, например, под виртуальные диски Hyper-V или базы данных на файловом ресурсе, — упираешься в производительность одного сервера, даже с учётом отказоустойчивости. Здесь на сцену выходит Scale-Out File Server (SOFS): роль, где все узлы кластера обслуживают один и тот же файловый ресурс одновременно, а не по очереди.

В этой статье развернём SOFS поверх уже существующего кластера из srv-fs01 и srv-fs02 в домене itpages.lab.local, сеть 192.168.10.0/24, и разберём, чем эта роль принципиально отличается от привычного файлового сервера общего назначения.

Стоит сразу расставить ожидания честно: SOFS — не универсальный ускоритель файлового сервиса, который стоит включать «на всякий случай». Это узкоспециализированный инструмент под конкретный класс нагрузки, и его развёртывание имеет смысл, только если ты уже упёрся или явно предвидишь упор в производительность одного узла при активно-пассивной схеме. Для небольшой компании с парой десятков пользователей и обычными офисными документами два узла в режиме General Use File Server с грамотно настроенным DFS поверх них справятся ничуть не хуже, а конфигурация при этом будет проще в эксплуатации и диагностике.

General Use File Server и Scale-Out File Server: в чём разница

Ключевое отличие — в модели доступа к диску и в сценариях использования:

• General Use File Server — классическая активно-пассивная роль. Диск с данными принадлежит одному узлу, при failover право владения переходит другому узлу целиком. Подходит для обычных пользовательских шар с профилями, документами, домашними папками.
• Scale-Out File Server — все узлы кластера одновременно имеют доступ на запись к общему тому через Cluster Shared Volumes (CSV), а клиентские подключения балансируются между узлами. Подходит для сценариев с высокой нагрузкой на ввод-вывод от приложений: хранилище виртуальных машин Hyper-V, базы данных SQL Server на SMB-ресурсе, сценарии с постоянно открытыми файлами большого размера.

Важный нюанс: SOFS рассчитан именно на прикладную нагрузку, а не на классические пользовательские сценарии вроде открытия документа Word прямо с шары через проводник — для этого он не даёт особого выигрыша и по историческим причинам не поддерживает часть функций вроде DFS Namespaces интеграции так же гладко, как General Use File Server. Выбор роли — это выбор под конкретный сценарий, а не универсальное «более новое и мощное всегда лучше».

Предварительные требования

Для SOFS обязательно нужен работающий кластер с общим хранилищем, переведённым в режим Cluster Shared Volume — без CSV роль просто не создастся, потому что весь смысл SOFS в одновременном доступе с нескольких узлов к одному тому. Если кластер srv-fs01/srv-fs02 уже создан (см. статью про основы Failover Clustering), убеждаемся, что диск подключён и переведён в CSV:

Get-ClusterSharedVolume

Get-ClusterResource | Where-Object {$_.ResourceType -eq "Physical Disk"} |
  Select-Object Name, OwnerGroup, State

Если диск ещё не в CSV, переводим:

Get-ClusterResource -Name "Cluster Disk 1" | Add-ClusterSharedVolume

После перевода том становится доступен на обоих узлах по единому пути вида C:\ClusterStorage\Volume1, физически он остаётся на общем хранилище, но операционная система каждого узла видит его как локальный, с прозрачной маршрутизацией ввода-вывода через кластерную сеть, если узел не является текущим координатором тома.

Создание роли Scale-Out File Server

Роль создаётся одной командой поверх существующего кластера:

Add-ClusterScaleOutFileServerRole -Name "SOFS-DATA"

Get-ClusterResource -Name "SOFS-DATA"

В отличие от General Use File Server, у роли SOFS нет отдельного выделенного IP-адреса на каждый ресурс — клиенты обращаются по DNS-имени SOFS-DATA, которое через механизм DNS round-robin и последующее перенаправление SMB транспортом распределяет подключения между узлами, стоящими за этим именем. Это стоит держать в голове при диагностике: если ты пингуешь SOFS-DATA, ответ может прийти с разных физических адресов при разных попытках.

Создание файлового ресурса на CSV-томе

Теперь создаём саму общую папку на кластерном томе и публикуем её как SMB-шару, привязанную к роли SOFS:

New-Item -Path "C:\ClusterStorage\Volume1\VMShare" -ItemType Directory

New-SmbShare -Name "vmshare" `
  -Path "C:\ClusterStorage\Volume1\VMShare" `
  -FullAccess "ITPAGES\Domain Admins", "ITPAGES\Hyper-V-Hosts" `
  -ContinuouslyAvailable $true

Флаг -ContinuouslyAvailable $true — это то, что превращает обычную SMB-шару в по-настоящему отказоустойчивый ресурс: он включает механизм SMB Transparent Failover, который сохраняет состояние открытых handle-ов файлов и позволяет клиенту прозрачно переподключиться к другому узлу при отказе текущего, без обрыва операции записи и без ошибки на стороне приложения. Именно это отличает SOFS от простого «файлы на кластере». Стоит отдельно отметить, что этот флаг применим только к шарам на CSV-томах — попытка включить непрерывную доступность для обычной, не кластерной папки вернёт ошибку, потому что механизм транспарентного failover напрямую опирается на согласованное состояние тома между узлами кластера.

SMB Multichannel и производительность

Для реальной нагрузки от Hyper-V или SQL Server стоит убедиться, что задействован SMB Multichannel — он позволяет клиенту использовать сразу несколько сетевых путей к SOFS одновременно, увеличивая суммарную пропускную способность и добавляя устойчивость к отказу отдельного сетевого адаптера:

Get-SmbServerConfiguration | Select-Object EnableMultiChannel

Get-SmbClientNetworkInterface | Format-Table InterfaceIndex, FriendlyName, RSSCapable, RDMACapable

Если на узлах кластера установлено несколько сетевых адаптеров в одной подсети или адаптеры с поддержкой RDMA (что часто встречается в связке SOFS плюс Hyper-V), Multichannel задействуется автоматически и заметно поднимает пропускную способность файлового сервиса без какой-либо ручной настройки балансировки на стороне клиента.

Проверка отказоустойчивости SOFS

Проверять нужно не просто «поднимается ли роль», а именно то, ради чего вся эта конструкция затевалась — прозрачность переключения для клиента, который в этот момент активно читает или пишет файл. Практический тест: запусти на клиентской машине копирование крупного файла на шару \\SOFS-DATA\vmshare, и во время копирования выполни на узле, который сейчас обслуживает этот том, принудительную перезагрузку:

Get-ClusterSharedVolume | Select-Object Name, OwnerNode

# на узле-владельце тома
Restart-Computer -Force

При корректно настроенном Continuous Availability копирование должно продолжиться с короткой паузой в несколько секунд, а не оборваться с ошибкой. Если файл рвётся при каждом тесте — почти наверняка проблема в том, что шара была создана без -ContinuouslyAvailable $true, либо клиент слишком старый и не поддерживает SMB 3.0 Transparent Failover (актуально для очень старых версий Windows на стороне клиента).

Балансировка клиентов и роль SMB Witness

Отдельно стоит сказать про механизм SMB Witness — он работает поверх Continuous Availability и ускоряет обнаружение отказа узла на стороне клиента. Без Witness клиент узнаёт о недоступности узла только по таймауту TCP-соединения, что может занимать десятки секунд. С Witness кластер активно уведомляет клиента о смене владельца ресурса, и переключение происходит за секунды:

Get-SmbWitnessClient

Get-SmbServerConfiguration | Select-Object AnnounceServer, EnableSMB2Protocol

Witness задействуется автоматически при использовании SOFS и Continuous Availability — отдельно включать его не нужно, но полезно знать, что именно он отвечает за скорость переключения, которую ты видел в тесте с копированием файла выше.

Мониторинг и диагностика SOFS

В повседневной эксплуатации полезно понимать, кто и что сейчас держит открытым на ресурсе, и как распределены клиенты между узлами:

Get-SmbOpenFile | Format-Table ClientComputerName, Path, ShareRelativePath

Get-SmbSession | Format-Table ClientComputerName, ClientUserName, Dialect

Get-ClusterResource -Name "SOFS-DATA" | Get-ClusterParameter

Если после планового переноса нагрузки клиенты продолжают массово висеть на одном и том же узле вместо равномерного распределения — стоит проверить настройки DNS для имени SOFS-DATA и убедиться, что там действительно прописаны адреса обоих узлов, а не только одного, оставшегося с момента первоначальной настройки.

Частые ошибки и как их избежать

• SOFS для обычных пользовательских шар с профилями и документами. Это не тот сценарий, под который проектировался SOFS — накладные расходы на координацию между узлами не окупаются, а часть удобных функций работает хуже, чем на обычном General Use File Server. Используй SOFS для прикладной нагрузки: Hyper-V, SQL Server, аналогичные сценарии с большими файлами и интенсивным вводом-выводом.
• Забыли ContinuouslyAvailable при создании шары. Без этого флага SOFS технически работает, но теряет главное преимущество — прозрачное переключение при отказе узла превращается в разрыв соединения и ошибку на стороне клиентского приложения, то есть по факту ты получаешь просто файловую шару на кластере без реальной непрерывной доступности.
• Недостаточная пропускная способность сети между узлами и хранилищем. Если сеть, через которую узел без прямого доступа к тому маршрутизирует ввод-вывод к текущему координатору CSV, узкая или перегружена обычным трафиком, производительность SOFS может оказаться хуже, чем у обычного файлового сервера. Для серьёзной нагрузки закладывай отдельную выделенную сеть для трафика хранилища, желательно 10 Гбит/с и выше.
• Устаревшие клиенты без поддержки SMB 3.0. Continuous Availability и Transparent Failover — это возможности протокола SMB версии 3.0 и новее. Клиенты на очень старых версиях Windows или сторонних SMB-клиентах могут не поддерживать прозрачное переподключение и будут получать обрыв соединения при failover, даже если сама роль настроена правильно. Проверяй версию диалекта через Get-SmbConnection на клиенте, если переключение выглядит «рваным» именно для конкретных машин.

Автор — Команда IT-Pages