Сетевой администратор, который однажды наблюдал, как 10-гигабитная сеть при копировании виртуальных машин выдаёт жалкие 200-300 МБ/с, хорошо знает это ощущение. Железо дорогое, кабели новые, коммутаторы - последнего поколения. А скорость - как в прошлом веке. Причина почти всегда одна: SMB работает не так, как мог бы. Протокол, которому уже несколько десятков лет, за последнее время превратился в мощный инструмент с нетривиальными возможностями тюнинга - и большинство из них по умолчанию либо не активированы, либо настроены без учёта реальной нагрузки.

Разобраться в механике SMB 3.x - значит понять, почему одни корпоративные хранилища работают как локальные диски, а другие постоянно становятся узким местом всей инфраструктуры.

Как SMB Multichannel превращает несколько каналов в один мощный поток

SMB Multichannel появился в версии 3.0 и решает задачу, которая кажется очевидной, но реализация которой нетривиальна: использовать несколько сетевых адаптеров или несколько сетевых путей одновременно для единственной SMB-сессии. До SMB 3.x протокол жёстко привязывался к одному TCP-соединению, и даже при наличии четырёх 10-гигабитных портов на сервере эффективно работал лишь один.

Механика Multichannel строится на автоматическом обнаружении. При установке сессии клиент и сервер обмениваются информацией о доступных сетевых интерфейсах, после чего протокол самостоятельно создаёт несколько параллельных соединений - по одному на каждый доступный путь. Результат - агрегация полосы пропускания: два порта по 10 Гбит/с дают суммарную пропускную способность до 20 Гбит/с для одной передачи. Попутно решается задача отказоустойчивости: если один сетевой путь обрывается, сессия продолжает работу через оставшиеся каналы без каких-либо ошибок на стороне приложения.

Важный нюанс, который часто упускают: Multichannel включён по умолчанию начиная с Windows Server 2012, но это не означает, что он реально работает. Для активации агрегации требуется либо несколько физических адаптеров, либо адаптер с поддержкой RSS (Receive Side Scaling) - только тогда Multichannel создаёт несколько параллельных подключений. Проверить фактическое состояние можно через PowerShell:

Get-SmbMultichannelConnection

Вывод покажет, сколько соединений реально открыто в рамках сессии, какие интерфейсы задействованы и используется ли RDMA. Если в колонке SmbInstance стоит одно соединение - значит, Multichannel по какой-то причине не работает, и нужно разбираться с конфигурацией интерфейсов.

Ещё один момент для тех, кто использует NIC Teaming: в Windows Server 2012 R2 и более ранних версиях объединение адаптеров в тиминг отключало RDMA-возможности. Начиная с Windows Server 2016 ситуацию исправил Switch Embedded Teaming (SET) - он совместим с RDMA и позволяет получить и агрегацию каналов, и отказоустойчивость, и прямой доступ к памяти одновременно.

SMB Direct и RDMA - когда сеть работает в обход процессора

Если Multichannel - это про ширину канала, то SMB Direct (он же SMB over RDMA) - это про задержку и нагрузку на CPU. Remote Direct Memory Access позволяет сетевому адаптеру передавать данные напрямую между оперативной памятью двух машин, минуя операционную систему и процессор в критическом пути операции. Звучит как технический трюк, но на практике это меняет всё для workload-интенсивных сценариев.

Конкретная картина такова: при обычном SMB через TCP передача больших файлов или поток операций Hyper-V загружает CPU сервера на 30-50% только сетевыми задачами. С SMB Direct та же нагрузка потребляет единицы процентов. Задержка при этом падает до уровня, при котором удалённое хранилище начинает вести себя неотличимо от локального NVMe.

SMB Direct поддерживают три класса адаптеров: iWARP (реализует RDMA поверх стандартного TCP/IP), InfiniBand (традиционный вариант для HPC) и RoCE/RoCEv2 - RDMA over Converged Ethernet, наиболее распространённый в корпоративных дата-центрах сегодня. Адаптеры от Mellanox (ныне NVIDIA), Chelsio, Intel и Broadcom поддерживают один из этих стандартов.

При наличии RDMA-адаптеров SMB Direct включается автоматически - если включён Multichannel, который и отвечает за обнаружение RDMA-возможностей. Проверка состояния:

Get-SmbClientNetworkInterface
Get-WindowsOptionalFeature -Online -FeatureName SMBDirect

Долгое время существовало неприятное ограничение: включение SMB-шифрования автоматически отключало прямое размещение данных, и RDMA деградировал до скорости обычного TCP. Это делало выбор между безопасностью и производительностью взаимоисключающим. Windows Server 2022 и Windows 11 закрыли эту проблему: теперь данные шифруются до операции прямого размещения, что позволяет получить одновременно и RDMA-скорость, и защиту канала. Деградация производительности при включённом шифровании из катастрофической стала умеренной.

Шифрование без потери скорости - выбор алгоритма имеет значение

SMB-шифрование в 2026 году - не опциональная функция для параноиков, а базовое требование для любой корпоративной сети. Вопрос не в том, включать ли его, а в том, как настроить так, чтобы не платить за безопасность производительностью.

Алгоритмический ландшафт выглядит следующим образом. SMB 3.1.1 по умолчанию согласовывает AES-128-GCM - это оптимальный баланс между скоростью и стойкостью. Начиная с Windows Server 2022 и Windows 11 доступны AES-256-GCM и AES-256-CCM для сред с повышенными требованиями к безопасности. Более старые версии Windows и SMB 3.0 используют AES-128-CCM.

Практическая разница между GCM и CCM существенна: режим GCM значительно быстрее на процессорах с аппаратным ускорением AES (AES-NI), которое есть в любом серверном CPU последних десяти лет. Переход на AES-256-GCM добавляет заметный прирост безопасности ценой умеренного снижения производительности по сравнению с 128-битным вариантом.

Включение шифрования и управление алгоритмом через PowerShell:

# Шифрование на уровне сервера
Set-SmbServerConfiguration -EncryptData $true -Force

# Шифрование конкретной шары
Set-SmbShare -Name "DataShare" -EncryptData $true

# Принудительное использование AES-256-GCM на клиенте
Set-SmbClientConfiguration -EncryptionCiphers "AES_256_GCM" -Confirm:$false

Важное различие, которое путают даже опытные администраторы: "включить шифрование" и "требовать шифрование" - разные режимы. В первом случае клиенты, поддерживающие SMB 3.x, будут использовать шифрование, но устаревшие клиенты всё равно получат доступ. Во втором - сервер отклоняет незашифрованные подключения с ошибкой "Access denied". Для Production-среды правильный выбор - второй вариант, с одновременным аудитом клиентского парка через Group Policy.

Windows Server 2025 и Windows 11 24H2 добавили возможность аудита: администратор может получить отчёт о том, какие клиенты подключаются без поддержки подписи или шифрования - до того как принудительно включить ограничения.

Persistent Handles и Transparent Failover для workload без прерываний

Хранение файлов виртуальных машин и баз данных SQL Server на SMB-шарах - это не экзотика, а стандартная практика в масштабируемых инфраструктурах. Гипервизор не готов к тому, что файловый дескриптор неожиданно закроется: он не обрабатывает такие ошибки корректно, и результат - падение виртуальной машины или перевод базы данных в режим offline.

SMB Transparent Failover решает эту задачу через механизм persistent handles. Работает это следующим образом: когда SMB-клиент открывает файл на шаре с атрибутом Continuous Availability, он запрашивает у сервера не обычный дескриптор, а persistent handle. Сервер через компонент Resume Key Filter записывает состояние этого дескриптора - вместе с уникальным ключом от клиента - в стабильное хранилище, доступное всем узлам кластера.

При плановом обслуживании или непредвиденном сбое узла кластера клиент пытается переподключиться к другому узлу. Получив тот же resume key, новый узел через Resume Key Filter восстанавливает состояние дескриптора точно таким, каким оно было до сбоя. Приложение не видит никаких ошибок - только кратковременную паузу ввода-вывода в несколько секунд, пока идёт переключение.

Для защиты от потери данных persistent handles всегда открываются в режиме write-through: кеширование записи отключено, что гарантирует сохранность незафиксированных данных при сбое узла.

Prerequisite для Transparent Failover жёстко определён:

  • Windows Server Failover Cluster с минимум двумя узлами
  • Cluster Shared Volume (CSV) как общее хранилище
  • Шара с атрибутом Continuously Available
# Создание CA-шары
New-SmbShare -Name "VMStorage" -Path "C:\ClusterStorage\Volume1" -ContinuouslyAvailable $true

# Проверка атрибута
Get-SmbShare -Name "VMStorage" | Select ContinuouslyAvailable

Проверить, что клиент действительно работает через persistent handle, можно командой Get-SmbOpenFile | Select ContinuouslyAvailable непосредственно на узле кластера - поле должно показывать True.

Комплексная настройка производительности - что делать с BIOS, драйверами и счётчиками

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

Первое, на что обращают внимание при диагностике медленного SMB - режим питания. Power Management в BIOS должен быть переведён в High Performance, а C-States процессора - отключены или минимизированы. Агрессивное управление питанием добавляет задержки при пробуждении адаптеров, которые накапливаются в потоке мелких операций и убивают показатели IOPS.

Второй момент - приоритет и свежесть драйверов сетевых адаптеров. Некоторые производители выпускают драйверы, которые по умолчанию отключают RDMA в целях совместимости. Это нужно проверить явно через Get-NetAdapterRdma и при необходимости включить принудительно. Драйвера должны быть актуальными: старые версии могут не поддерживать RoCEv2 или иметь баги в реализации SMB Direct.

Robocopy для массовых операций копирования через SMB стоит запускать с ключом /MT (многопоточность) - он значительно ускоряет передачу большого количества мелких файлов, где однопоточная запись становится узким местом.

Мониторинг фактического состояния SMB-стека строится на нескольких ключевых счётчиках Performance Monitor:

  • SMB Client Shares: Data Bytes/sec - фактическая пропускная способность
  • SMB Client Shares: Read Bytes/sec и Write Bytes/sec - баланс нагрузки
  • SMB Direct Connection: RDMA Bytes/sec - проверка, что RDMA действительно работает
  • Network Interface: Bytes Total/sec - сравнение с теоретическим максимумом линка

Если RDMA Bytes/sec стремится к нулю при активном трафике - SMB Direct не функционирует, и стоит начать с проверки Get-SmbMultichannelConnection и состояния адаптеров.

Почему правильно настроенный SMB меняет архитектурные решения

Когда SMB работает так, как задумано, он перестаёт быть ограничением и становится строительным материалом для масштабируемой инфраструктуры. Storage Spaces Direct, Scale-Out File Server, Hyper-V с хранилищем на шарах - всё это работает поверх SMB 3.x и напрямую зависит от его производительности.

Организации, которые однажды правильно настроили SMB Direct с шифрованием на Windows Server 2022 или 2025, обнаруживают неожиданную вещь: разница между SAN-архитектурой и файловым сервером на SMB нивелируется до уровня, когда первая перестаёт быть обязательным требованием для многих workload. Удалённое NVMe-хранилище, доступное через SMB с RDMA, при правильной настройке даёт задержку в единицы миллисекунд и пропускную способность, ограниченную только физическим каналом.

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