Сервер удаленных рабочих столов: от установки до оптимизации производительности

Сервер удалённых рабочих столов - это машина, на которой одновременно работают сеансы многих сотрудников. Приложения крутятся на сервере, пользователю едет картинка, обратно - нажатия клавиш и движения мыши. В мире Windows эта роль называется Remote Desktop Services, RDS; в разговоре её чаще зовут терминальным сервером.

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

RDS, RDP, VDI и «терминалка»: что чем называется

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

Главное различие - между сеансовым режимом и VDI. В сеансовом все пользователи делят одну операционную систему, одно ядро и общие ресурсы: дёшево, плотно, но чужой зависший процесс задевает соседей, а персонализация ограничена. В VDI у каждого своя виртуальная машина со своей ОС: полная изоляция и свобода настроек, но и железа нужно кратно больше. Что выбрать и сколько это стоит по ресурсам, разбирается в статье про VDI-сервер и требования к железу.

Отдельно стоит сказать про саму аббревиатуру. В поиске «RDS» живёт своей жизнью: так называется система передачи данных в автомагнитолах (Radio Data System), российская дрифт-серия и управляемые базы данных у облачных провайдеров. Если вы пришли сюда за одним из них - вам не сюда.

Зачем компании сервер удалённых рабочих столов

Причин обычно четыре, и все они про управляемость.

Обновления в одной точке. Вышла новая версия 1С - поставили на сервер, и все сотрудники работают в ней с понедельника. Никаких обходов кабинетов и разбирательств, у кого какая сборка.

Данные не уезжают на устройства. Сотрудник работает в сеансе, файлы остаются в серверной. Ноутбук потеряли в такси - учётную запись отключили, и на этом история закончилась.

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

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

Обратная сторона тоже есть, и её лучше знать заранее: сервер становится единой точкой отказа. Пока работала схема «у каждого свой компьютер», поломка задевала одного человека. Теперь остановка сервера останавливает всех сразу.

Из чего состоит RDS: роли по порядку

Развёртывание собирается из ролей. В небольшой компании их ставят на одну машину, в крупной разносят.

Про RD Licensing стоит сказать отдельно, потому что о нём чаще всего забывают. После установки роли RDS даётся льготный период в 120 дней, в течение которого ферма работает без лицензий - это время на настройку и проверку. Когда период кончается, пользователь без выданной сервером лицензии в сеанс просто не войдёт. Сюрприз обычно случается в разгар рабочего дня через четыре месяца после запуска. Как устроены сами лицензии и чем RDS CAL отличается от обычных клиентских, разбирается в статье про лицензирование Windows Server.

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

Сколько железа нужно: считаем по нагрузке

Здесь чаще всего берут цифру с потолка. У Microsoft есть официальные рекомендации по сайзингу узлов сеансов, и они устроены не через «гигабайты на пользователя», а через плотность: сколько пользователей помещается на одно виртуальное ядро.

Важная оговорка про vCPU. В таблице речь о виртуальных, то есть логических ядрах - потоках. На процессоре с многопоточностью одно физическое ядро даёт два логических. Если считать по физическим, ошибётесь примерно вдвое: 16-ядерный процессор с многопоточностью - это 32 vCPU.

Считается просто. Тридцать человек со средней нагрузкой - это 30 / 4, около 8 логических ядер плюс запас на систему и на пики; в физических это скромный процессор. Тот же тридцатник в САПР - уже 30 логических ядер, и разговор идёт о другой машине.

Дальше несколько правил, которые экономят деньги и нервы.

• Ядра масштабируются не линейно. Удвоение числа ядер не удваивает число пользователей: коэффициент по опыту Microsoft лежит в пределах 1,5-1,9 и падает по мере роста. Переход с 4 ядер на 8 даёт больше, чем с 8 на 16.
• Не гонитесь за одной большой машиной. Разумный диапазон - от 4 до 24 ядер на узел. Выше 32 синхронизация съедает прибавку: два узла по 16 ядер обслужат людей лучше, чем один на 32.
• Диски решают не меньше процессора. Профили, временные файлы и запуск приложений - это тысячи мелких операций. SSD обязателен, NVMe желателен; систему, профили и данные разносят по разным томам.
• Утренний вход - отдельная нагрузка. Логон интенсивно грузит процессор, и сервер, который спокойно тянет тридцать работающих человек, может лечь, когда те же тридцать заходят в течение десяти минут. Считайте по пику в девять утра, а не по установившемуся режиму.
• Память лечит узкое место быстрее всего. Когда упирается именно в неё, рост с 16 ГБ до 32 может больше чем удвоить число пользователей на том же процессоре.

Ориентир по качеству работы у Microsoft тоже есть: задержка отклика на действие пользователя должна укладываться в 200 мс. Всё, что выше, люди замечают и начинают жаловаться.

Отдельно про графику. Если пользователи выводят картинку на разрешение суммарно выше 3840 × 2160, кодирование видео на процессоре начинает конкурировать с приложениями, и появляются артефакты, подвисания кадров и «квадратики». Это тот порог, за которым в сервер ставят видеокарту.

Установка: что происходит при развёртывании

Развёртывание не требует магии: Server Manager, добавление ролей Remote Desktop Services, выбор типа развёртывания - сеансовый или на основе виртуальных машин. Дальше настраиваются коллекции, публикуются рабочие столы или отдельные приложения.

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

Что действительно стоит решить до установки, а не после: где будут храниться профили пользователей. От этого зависит и скорость входа, и то, увидит ли человек свои настройки на другом узле фермы. Рабочий вариант на 2026 год - контейнеры FSLogix; перемещаемые профили работают, но Microsoft называет их устаревающими, а User Profile Disks больше не развивает. Разбор всех вариантов с правами на папку и ключами реестра - в статье про управление профилями пользователей на терминальном сервере.

Оптимизация: что даёт эффект

Развернуть сервер - половина работы. Дальше начинается настройка, и большая часть выигрыша достаётся не апгрейдом железа, а групповыми политиками и дисциплиной сеансов.

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

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

Третье - тяжёлые приложения. Браузер с полусотней вкладок, графические пакеты, САПР ведут себя в общей ОС плохо: один пользователь способен просадить работу остальных. Такие сценарии либо выносят на отдельный узел, либо переводят в VDI, где у человека своя машина и своя нагрузка.

Четвёртое - мониторинг до жалоб, а не после. Смотреть надо на процессор, память, очередь к дискам, число активных сеансов и время входа. Именно время входа обычно начинает расти первым, задолго до того, как люди скажут «всё тормозит».

Более подробный разбор настроек производительности - в статье про настройку терминального сервера с оптимизацией.

Доступ извне: как не открыть дверь всем

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

Правильная схема - RD Gateway: подключения снаружи идут по HTTPS, шлюз проверяет, кому и куда можно, и только после этого пропускает к узлам сеансов. Наружу торчит один защищённый сервис вместо самих терминалов.

Дальше - второй фактор при входе, блокировка учётной записи после серии неудачных попыток, обычные требования к паролям. Российским компаниям стоит смотреть на решения, которые доступны здесь и работают с Active Directory локально, - привязываться к облачным сервисам, отключённым для юрлиц из России, смысла нет.

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

Своё железо или аренда

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

Аренда выигрывает, когда нагрузка скачет, проект временный или компания не готова к капитальным затратам. Своё железо выигрывает, когда нагрузка ровная и предсказуемая, работа идёт из офиса, а данные не хочется отдавать наружу. Отдельный аргумент - те самые 15-20% ёмкости, которые съедает виртуализация: физический сервер под терминалы обслуживает больше людей при тех же характеристиках.

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

Когда RDS не нужен

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

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

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