В этом подробном гайде разберём, как правильно развернуть RDS-ферму на Windows Server 2022 с акцентом на отказоустойчивость (HA) для двух ключевых инфраструктурных компонентов — RD Connection Broker и RD Gateway. Пройдём архитектуру, требования, варианты балансировки нагрузки, настройку БД для HA, сертификаты, тестирование и основные шаги по восстановлению после отказа. Статья подходит как для виртуализованных, так и для физических окружений.
Кому будет полезно
— Системным администраторам, которым нужно построить масштабируемую RDS-инфраструктуру.
— Инженерам, готовящим отказоустойчивую площадку для удалённых рабочих столов.
— Тем, кто мигрирует существующую RDS-ферму на Windows Server 2022 и хочет убрать слабые места.
Ключевые понятия
— RD Connection Broker (RDCB) — «распределитель» сессий, нужен для восстановления сессий и балансировки. Для HA требует общую базу данных (SQL).
— RD Gateway — публичный шлюз для RDP через HTTPS; может быть масштабирован за счёт балансировщика.
— Балансировщик (NLB или сторонний L4/L7 LB) — отвечает за равномерное распределение входящих подключений и доступность.
Архитектурная схема (рекомендованная)
1. AD Domain Controllers (>=2) — аутентификация.
2. SQL Server кластер/AG (минимум 2 ноды) — хранит БД RDCB для HA.
3. RD Connection Broker (минимум 2 сервера) — настроены на использование SQL-БД RDCB.
4. RD Session Host (пул) — несколько серверов для пользовательских сессий.
5. RD Gateway (минимум 2 сервера) — стоят за внешним LB (Hardware LB / Azure LB / F5 / HAProxy и т.д.).
6. Optional: RD Web / RD Licensing (HA: License server можно дублировать, но ключи и активация отдельны).
Почему RDCB и Gateway — самые критичные точки
— RDCB хранит состояние пользовательских сессий (перенаправление при переподключении). Один доступный RDCB — single point of failure, если используется только локальное BCD. Чтобы обеспечить HA, RDCB должна быть сконфигурирована на центральную SQL-БД.
— RD Gateway — единственная точка входа для удалённых клиентов по HTTPS; при её падении внешние RDP-подключения теряются, поэтому требует LB и дублирования.
Подготовительный этап — требования и рекомендации
— AD: контроллеры домена доступны, синхронизация времени работают корректно.
— Сеть: открытые порты между ролями (RDCB ↔ SQL TCP/1433, RD Gateway ↔ RD Session Host RDP/3389 (внутренне) и HTTPS/443 наружу через LB).
— Сертификаты: публичный сертификат для RD Gateway (SAN — содержит имя шлюза), сертификаты для RD Web/Connection Broker при необходимости.
— SQL: используйте поддерживаемый движок (SQL Server 2019/2022) с HA (Always On Availability Groups или Failover Cluster Instance). Рекомендуется использовать OLE DB/правильный драйвер — есть нюансы с устаревшим SQL Native Client.
Пошаговый план развёртывания
1) Разворачиваем SQL-HA для RDCB
— Разверните SQL Server в отказоустойчивой конфигурации: Failover Cluster Instance (FCI) или Always On AG.
— Создайте отдельную базу для RDCB или используйте автоматическую процедуру установки RDCB, которая создаст БД.
— Убедитесь, что учетная запись, от имени которой работает RDCB, имеет права на создание/управление БД (dbcreator/db_owner по инструкции MS).
2) Установка ролей RD Connection Broker (две ноды)
— На двух серверах через Server Manager → Remote Desktop Services добавьте роль RD Connection Broker на оба устройства.
— При настройке HA укажите адрес SQL-инстанса и имя БД. Если всё правильно — RDCB будет работать в кластере и использовать общую БД.
3) Установка RD Session Host → пул
— Добавьте сервера RD Session Host в деплоймент, объедините в коллекцию.
— Настройте профиль сбалансированного распределения сессий (load balancing) — тип «session-based desktop» или удалённые приложения.
4) Разворачивание RD Gateway в HA
— Установите RD Gateway на минимум двух серверах.
— Поместите RD Gateway за внешним балансировщиком (обязательная рекомендация): использовать аппаратный/виртуальный L4/L7 LB или облачный LB (Azure Load Balancer/Application Gateway). NLB (Windows Network Load Balancing) — возможен, но часто менее предпочтителен в современных средах по сравнению со сторонним LB.
— На LB настройте health checks на порт 443 и проверку URL (RD Gateway Manager Health) чтобы быстро исключать упавшие ноды.
5) Сертификаты и DNS
— Публичный DNS-имя для шлюза (например, rds.example.com) — указывает на виртуальный IP балансировщика. Сертификат SAN/UC выдан центром доверия должен покрывать это имя.
— Внутренние сервис-имена (RDCB, RD Web) также желательно иметь в сертификатах, особенно если используется HTTPS между сервисами.
6) Тестирование и валидация
— Тест 1: подключение извне через RD Gateway (RDP клиент с настройкой шлюза).
— Тест 2: отключение одной ноды RDCB — сеансы должны оставаться доступными, а новые соединения перенаправляться.
— Тест 3: отключение одной ноды RD Gateway — подключение извне через LB должно оставаться.
Практические советы и типовые ошибки
— Не использовать SQL Express для продакшен-HA RDCB — он не поддерживает AG и масштаб.
— Проверяйте совместимость драйверов SQL: сейчас рекомендуют современный OLE DB драйвер, а не устаревший SQL Native Client. Это убережёт от неожиданных ошибок при HA конфигурации.
— Не забывайте о лицензировании RDS (RDS CALs) — наличие HA не отменяет требований по лицензиям.
— Для RD Gateway избегайте использования Windows NLB в средах с SSL Offload без тщательного тестирования — многие предпочитают аппаратный/виртуальный LB с прозрачной проксингацией SSL.
Мониторинг и поддержка
— Сбор логов: Event Viewer (RemoteDesktopServices-*), RD Gateway логирование, SQL-логи.
— Автоматические проверки доступности через мониторинг LB и внешние synthetic tests (имитировать подключение RDP через Gateway).
— Резервное копирование: регулярно бэкапьте SQL-базу RDCB и снимки конфигураций RD-серверов.
План восстановления при отказе (RTO/RPO)
1. При падении одной ноды RD Gateway — LB исключит ноду автоматически, доступ восстановится при переключении.
2. При падении всей группы RD Gateway — запасной публичный IP/ALB в другой зоне / DR-сайт.
3. При потере SQL: если настроен AG или FCI — переключение на вторую ноду. При отсутствии HA SQL — восстановление из бэкапа приведёт к потере последних данных BCD (влияет на перенаправление сессий).
Чеклист перед вводом в эксплуатацию
— [ ] SQL настроен в HA (AG/FCI) и бэкапится.
— [ ] RDCB установлены минимум на двух нодах и указывают на SQL.
— [ ] RD Gateway за балансировщиком, публичный сертификат установлен.
— [ ] Тесты отказа и восстановления пройдены (RDCB, RD Gateway, Session Host).
— [ ] Мониторинг и оповещения настроены.
Развёртывание отказоустойчивой RDS-фермы на Windows Server 2022 сводится к 3 основным элементам: правильно настроенный HA-SQL для RDCB, дублированные ноды RD Connection Broker и RD Gateway и передний балансировщик, который управляет внешними запросами. При соблюдении рекомендаций вы получите масштабируемую и отказоустойчивую платформу для удалённых рабочих столов, которую легко тестировать и сопровождать.
