Veeam v11a и Windows Server 2022: тестируем SMB over QUIC бэкапы без VPN для филиалов

Veeam выпустил v11a в начале ноября, и главный повод обновиться - полная поддержка Windows Server 2022 в качестве платформы для компонентов Veeam и источника/цели бэкапа. Плюс официально задекларирована поддержка SMB over QUIC-транспорта для бэкапа файловых ресурсов. У нас как раз в работе клиент, где только что подняли WS2022-серверы - решили не откладывать.

Что изменилось в v11a

Обновление позиционируется как точечное: v11 вышел в феврале, и за девять месяцев накопился список проблем с новым окружением - прежде всего с WS2022 и Hyper-V нового поколения. v11a их закрывает.

Конкретно по WS2022:

• Veeam Backup Server и Proxy теперь официально встают на WS2022, без предупреждений о «непроверенной платформе» в установщике.
• Агент на WS2022 работает корректно со всеми функциями Secured-Core: HVCI, VBS, Device Guard. В v11 были edge-кейсы с агентом на системах с включённым HVCI, v11a это исправляет.
• SMB over QUIC как транспорт для File Backup заданий - Veeam теперь умеет подключаться к файловому ресурсу через QUIC-транспорт и бэкапить его как обычный сетевой путь.

Зачем нам это нужно: кейс с филиалом

Клиент из сектора профессиональных услуг, несколько небольших региональных офисов. В каждом стоит WS2022 с файловым ресурсом - рабочие документы, шаблоны, локальные базы. Центральный бэкап через Veeam в головном офисе.

До сих пор схема была простой и скучной: site-to-site VPN, поверх него Veeam-агент ходит к файловому серверу и гонит данные в центральный репозиторий. Работает, но каждый VPN - это отдельная точка обслуживания: за IPSec-туннелями надо следить, при аварии канала задание виснет и требует ручного вмешательства.

В августе мы тестировали SMB over QUIC как транспорт для пользовательского файлового доступа - тогда отметили, что восстановление соединения после разрыва у QUIC лучше, чем у TCP-VPN. Теперь интересно проверить то же самое, но со стороны Veeam.

Как выглядит настройка

WS2022 Azure Edition на файловом сервере в филиале уже стоял - это обязательное условие для SMB over QUIC на стороне сервера, мы об этом писали. TLS-сертификат на сервер выдан от внутреннего CA, клиент (Veeam Proxy в центральном офисе) имеет этот CA в доверенных.

Со стороны Veeam настройка выглядит прозрачно: в задании File Backup указываешь путь вида \\filserver.company.com\share - и если сервер отдаёт SMB over QUIC, Veeam его использует. Никакого специального переключателя «включить QUIC» в интерфейсе нет, транспорт выбирается автоматически через механизм согласования Windows.

На практике это означает: если путь резолвится и сертификат в порядке - всё просто работает. Это хорошо.

Что мы измеряли

Сравнивали два режима на одном задании с одного файлового сервера: бэкап через OpenVPN site-to-site (тот же канал, поверх тоннеля) и бэкап через SMB over QUIC напрямую.

Скорость бэкапа на хорошем канале - разница в пределах погрешности. Veeam сам сжимает и дедуплицирует данные до отправки, поэтому транспортный слой здесь не узкое место. QUIC добавляет своё шифрование (TLS 1.3 внутри протокола), которое накладывается на шифрование Veeam - двойной overhead реален, но на современном железе с AES-NI это не ощущается в throughput.

Поведение при нестабильном канале - вот тут разница есть. Имитировали packet loss около 3-5% и случайные обрывы на несколько секунд. Задание через VPN при обрыве уходило в ошибку с таймаутом и требовало перезапуска. SMB over QUIC переживал кратковременные обрывы прозрачно - задание продолжалось после паузы без ошибки. Это прямое следствие того, как QUIC обрабатывает connection migration.

Overhead на шифрование - смотрели CPU на Veeam Proxy во время задания. При SMB over QUIC нагрузка чуть выше, чем при VPN-туннеле: QUIC шифрует транспортный уровень, Veeam шифрует данные - два слоя AES. На конкретном железе с Xeon E-2200 разница оказалась незначительной, в пределах нескольких процентов CPU. На слабом железе или при очень высоком throughput это стоит перепроверить отдельно.

Что не понравилось

Azure Edition - по-прежнему обязательное условие. Серверная часть SMB over QUIC работает только в Azure Edition WS2022. У нас в этом кейсе она стоит, но для клиентов где серверы в собственном ЦОД на Standard/Datacenter - этот сценарий закрыт. Veeam здесь ни при чём, это ограничение Microsoft.

Мониторинг транспорта в Veeam-логах скромный. В логах задания нет явного указания «использован QUIC-транспорт». Проверить, что Veeam действительно ходит через QUIC, а не через обычный TCP SMB, можно только через Get-SmbConnection на стороне сервера или через Wireshark - видишь UDP 443 вместо TCP 445. Для production хочется это в логах задания.

KDC Proxy если нет VPN - аутентификация через Kerberos без VPN требует настройки KDC Proxy, иначе Veeam Proxy не получит тикет от DC в головном офисе. Это решаемо, но добавляет компонент в схему. Кто пойдёт по этому пути - закладывайте время на настройку.

Итог

v11a на WS2022 работает устойчиво - по крайней мере на нашей конфигурации с Secured-Core и стандартными ролями. SMB over QUIC как транспорт для бэкапа интересен именно для небольших филиалов с нестабильным каналом: задание меньше дёргается при мелких сбоях и не требует отдельного VPN-туннеля между площадками.

Для клиентов на managed-сопровождении с WS2022 Azure Edition в схеме - рекомендуем обновить Veeam до v11a и попробовать этот транспорт в пилоте. Для тех, у кого в филиалах Standard-редакция - пока остаёмся на классической VPN-схеме.