Развёртывание фермы RDS на Windows Server: рабочая схема для офиса до 50 мест

Терминальный сервер можно поднять за двадцать минут: включить удалённый доступ, добавить пользователей, готово. Так делают часто, и это работает — ровно до момента, когда одного сервера становится мало, а лицензии заканчиваются. Разберём, как развернуть полноценную ферму RDS сразу правильно: какие роли нужны, в каком порядке ставить, где чаще всего спотыкаются и что проверить перед вводом в эксплуатацию.

Четыре роли, и путать их назначение — источник большинства проблем при развёртывании.

RD Session Host (RDSH) — рабочая лошадка. Именно на нём запускаются приложения пользователей, здесь живут их сеансы, сюда уходят процессор и память. Таких серверов может быть несколько.

RD Connection Broker (RDCB) — распределяет подключения. Две задачи: балансировать новые сеансы между хостами и возвращать пользователя в его существующий сеанс, если он переподключается. Вторая задача важнее первой: без брокера человек, потерявший связь, попадёт на случайный хост и увидит пустой рабочий стол вместо своих открытых документов.

RD Web Access (RDWA) — веб-портал со списком опубликованных приложений и рабочих столов. Опционален, но удобен.

RD Gateway (RDG) — шлюз, принимающий подключения из интернета по HTTPS и транслирующий их внутрь. Позволяет не выставлять RDP наружу.

Плюс пятый компонент — сервер лицензирования RDS, который выдаёт клиентские лицензии. Формально отдельная роль, ставится обычно рядом с брокером.

Для офиса до 50 мест типовая схема: два RDSH, один сервер с ролями RDCB, RDWA, RDG и лицензированием. Итого три виртуальные машины.

Порядок имеет значение, потому что мастер развёртывания в диспетчере серверов проверяет доступность компонентов на каждом шаге.

1. Все серверы вводим в домен. RDS вне домена работать будет, но с ограничениями: без брокера, без нормальной балансировки, с отдельным лицензированием.
2. Собираем все серверы в пул диспетчера серверов на одной машине управления. Без этого мастер их не увидит.
3. Запускаем развёртывание служб удалённых рабочих столов и выбираем стандартное развёртывание, а не быстрый запуск. Быстрый ставит всё на одну машину, и разнести потом сложнее, чем сделать сразу.
4. Указываем серверы под роли: брокер, веб-доступ, узлы сеансов.
5. После развёртывания добавляем RD Gateway и сервер лицензирования через свойства развёртывания.
6. Активируем сервер лицензирования и устанавливаем на него купленные CAL.
7. Создаём коллекцию сеансов и включаем в неё узлы.

Развернуть то же самое можно и командами, что удобнее при повторяемых внедрениях:

New-RDSessionDeployment -ConnectionBroker rdcb.corp.local `
  -WebAccessServer rdcb.corp.local `
  -SessionHost @('rdsh01.corp.local','rdsh02.corp.local')

New-RDSessionCollection -CollectionName "Office" `
  -SessionHost @('rdsh01.corp.local','rdsh02.corp.local') `
  -CollectionDescription "Рабочие столы офиса" `
  -ConnectionBroker rdcb.corp.local

Частая ошибка на шаге 3 — выбрать «быстрый запуск», потому что он предлагается первым и звучит проще. Он ставит все роли на один сервер и разворачивает коллекцию с публикацией приложений, из которой потом приходится выпутываться.

Коллекция — это группа узлов сеансов с общими настройками и списком пользователей.

Настройки коллекции определяют почти всё пользовательское поведение: кто может подключаться, что перенаправляется с клиента, куда складывать профили, когда разрывать бездействующие сеансы.

Сколько коллекций заводить: по числу групп пользователей с существенно разными требованиями. Для типового офиса — одна.

Разделять имеет смысл, когда:

• часть пользователей работает с тяжёлым софтом и им нужны выделенные хосты;
• разные группы требуют разной политики перенаправления устройств;
• нужно изолировать подрядчиков или внешних пользователей;
• у части пользователей публикуются отдельные приложения (RemoteApp), а не полный рабочий стол.

Важные параметры коллекции, которые мы задаём сразу:

Set-RDSessionCollectionConfiguration -CollectionName "Office" `
  -DisconnectedSessionLimitMin 720 `
  -IdleSessionLimitMin 180 `
  -BrokenConnectionAction Disconnect `
  -TemporaryFoldersDeletedOnExit $true `
  -ClientDeviceRedirectionOptions AudioVideoPlayBack,PlugAndPlayDevice,Clipboard `
  -ConnectionBroker rdcb.corp.local

Первые два параметра — самые практичные. Отключённый сеанс живёт 12 часов и завершается; бездействующий отключается через 3 часа. Без них сеансы копятся неделями, съедая память и лицензии 1С.

BrokenConnectionAction Disconnect вместо End — принципиально: при обрыве связи сеанс сохраняется, и пользователь возвращается в свои открытые документы, а не теряет работу.

По умолчанию брокер хранит данные о сеансах в локальной базе Windows Internal Database. Это работает, но означает единственную точку отказа: упал брокер — новые подключения невозможны.

Для отказоустойчивости брокер переводится в режим высокой доступности, при котором данные хранятся в отдельной базе SQL Server, а брокеров становится два и больше.

Set-RDConnectionBrokerHighAvailability -ConnectionBroker rdcb01.corp.local `
  -DatabaseConnectionString "DRIVER=SQL Server Native Client 11.0;SERVER=sql.corp.local;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB" `
  -ClientAccessName rds.corp.local `
  -DatabaseFilePath "D:\SQLData\RDCB.mdf"

Add-RDServer -Server rdcb02.corp.local -Role RDS-CONNECTION-BROKER `
  -ConnectionBroker rdcb01.corp.local

Параметр ClientAccessName — это DNS-имя, по которому клиенты обращаются к ферме. На него заводятся A-записи всех брокеров, и работает round-robin.

Стоит ли это делать в офисе на 50 человек? Наш ответ: обычно нет. Второй брокер добавляет зависимость от SQL Server, усложняет обслуживание и решает проблему, вероятность которой невелика.

Куда важнее другое: несколько узлов сеансов. Падение RDSH выбивает только своих пользователей, остальные работают. А падение брокера не выбивает никого из уже подключённых — он нужен для установления соединений, а не для их поддержания.

То есть при одном брокере и двух хостах авария брокера означает «новые подключения невозможны», а не «все встали». Разница существенная, и для большинства офисов приемлемая.

RDS использует сертификаты в четырёх местах, и мастер по умолчанию генерирует самоподписанные. Пользователи при подключении видят предупреждения.

Четыре роли сертификатов:

Практичная схема для офиса: один сертификат от внутреннего центра сертификации на имя фермы для брокера, один публичный сертификат на внешнее имя для шлюза и портала.

Set-RDCertificate -Role RDGateway -ImportPath "C:\cert\rds-external.pfx" `
  -Password (Read-Host -AsSecureString) -ConnectionBroker rdcb.corp.local -Force
Set-RDCertificate -Role RDPublishing -ImportPath "C:\cert\rds-internal.pfx" `
  -Password (Read-Host -AsSecureString) -ConnectionBroker rdcb.corp.local -Force

Типичная ошибка: выпустить сертификат на имя сервера вместо имени фермы. Клиент обращается к rds.corp.local, получает сертификат на rdcb01.corp.local, имена не совпадают — предупреждение.

Вторая типичная: забыть про срок. Сертификат от Let's Encrypt живёт 90 дней, и без автопродления шлюз перестаёт работать через три месяца после развёртывания. Автопродление надо не только настроить, но и проверить, что после обновления файла сертификат переустанавливается в роль RDS — само оно туда не попадает.

В российских офисах терминальная ферма чаще всего разворачивается именно ради 1С, поэтому пару вещей стоит заложить в проект с самого начала.

Клиент 1С ставится на каждый узел сеансов, и версии должны совпадать до сборки. Разные версии платформы на разных хостах дают эффект, который сводит с ума при диагностике: пользователь жалуется через день, а его коллега с тем же документом проблемы не видит — просто потому, что брокер посадил их на разные узлы. Проверять надо не «примерно ту же версию», а конкретный номер сборки.

Список информационных баз должен быть общим. Иначе человек, попавший на другой хост, не найдёт привычную базу. Решается общим файлом ibases.v8i в сетевом каталоге и параметром CommonInfoBases в 1cestart.cfg.

; 1cestart.cfg в каталоге conf платформы на каждом узле
CommonInfoBases=\\srv-file\1c$\ibases.v8i
CommonCfgLocation=\\srv-file\1c$

Кэш 1С живёт в профиле пользователя. Это ключевой момент для выбора схемы профилей: перемещаемый профиль будет таскать по сети десятки мегабайт кэша при каждом входе и выходе. Каталог кэша стоит либо исключать из перемещения, либо использовать контейнерные профили.

Лицензии 1С на терминальном сервере считаются по сеансам. Тридцать человек в терминале — тридцать клиентских лицензий, ровно как если бы они сидели за своими компьютерами. Экономии тут нет, и это регулярно становится неприятным открытием на этапе внедрения.

Сервер 1С на том же хосте, что и RDSH, — плохая идея. Терминальные сеансы и сервер приложений конкурируют за память непредсказуемо, а тяжёлый отчёт одного пользователя начинает влиять на отзывчивость интерфейса у всех остальных. Разносить обязательно.

И последнее: если пользователи работают в 1С через терминал, замеры производительности стоит снимать именно из терминального сеанса. Замеры с рабочей станции администратора покажут другую картину — у него нет ни конкуренции за процессор хоста, ни особенностей терминальной графической подсистемы.

Список из десяти проверок, который мы прогоняем перед тем, как пускать людей.

1. Подключение изнутри сети по имени фермы — идёт ли балансировка между хостами.
2. Переподключение к существующему сеансу. Открыть окно, разорвать связь, подключиться заново — должен вернуться тот же сеанс с теми же окнами. Если нет — брокер не работает.
3. Подключение снаружи через шлюз, с другого канала, не из офиса.
4. Сертификаты не вызывают предупреждений ни изнутри, ни снаружи.
5. Лицензирование: сервер активирован, CAL установлены, режим задан, диагностика чистая.
6. Профили создаются в нужном месте, а не на системном диске хоста.
7. Печать с клиентского принтера работает.
8. Тайм-ауты сеансов заданы и проверены.
9. Вывод хоста из ротации работает: перевести RDSH в режим стока и убедиться, что новые сеансы идут только на второй.
10. Резервное копирование охватывает и хосты, и брокер, и профили.

Девятый пункт стоит пояснить. Режим стока (drain mode) не даёт новым сеансам садиться на хост, оставляя существующие работать. Это штатный механизм обслуживания: перед перезагрузкой хоста для обновлений вы переводите его в сток, ждёте, пока пользователи разойдутся, и обслуживаете.

Set-RDSessionHost -SessionHost rdsh01.corp.local -NewConnectionAllowed No `
  -ConnectionBroker rdcb.corp.local
# вернуть в работу
Set-RDSessionHost -SessionHost rdsh01.corp.local -NewConnectionAllowed Yes `
  -ConnectionBroker rdcb.corp.local

Без проверенного механизма стока обновление хостов превращается в ночную работу с выгоном пользователей. С ним — в плановую операцию, которую можно делать днём.

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

Нужен ли Connection Broker, если сервер один?

Формально нет, но с ним лучше: брокер возвращает пользователя в его существующий сеанс при переподключении. Без него человек, потерявший связь, рискует попасть в новый сеанс и потерять открытые документы. К тому же ферму потом проще расширять.

Ставить быстрый запуск или стандартное развёртывание?

Стандартное. Быстрый запуск размещает все роли на одной машине и сразу создаёт коллекцию с публикацией приложений — разносить это потом сложнее, чем изначально развернуть правильно.

Нужен ли второй Connection Broker для офиса на 50 человек?

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

Почему при подключении появляется предупреждение о сертификате?

Чаще всего сертификат выпущен на имя конкретного сервера, а клиент обращается по имени фермы, и имена не совпадают. Сертификат должен содержать то имя, которое клиенты вводят при подключении.