Терминальный сервер годами был рабочей лошадкой российских компаний: на Windows Server поднимали роль RDS, публиковали приложения (чаще всего 1С), а сотрудники подключались тонкими клиентами. Схема удобная, но к 2026 году у неё накопились проблемы — от лицензий Microsoft до требований по импортозамещению. Разберём, почему компании ищут замену терминального сервера и как её закрывает российский VDI на примере Inscale.
Терминальный сервер (Microsoft RDS — Remote Desktop Services) — это сценарий, при котором приложения и рабочие столы запускаются централизованно на сервере, а до пользователя по протоколу RDP долетает только «картинка». Логика та же, что у VDI и тонкого клиента: вся нагрузка на сервере, на местах — лёгкое железо.
Почему от классического RDS уходят:
- Лицензии. Windows Server + RDS CAL на каждого пользователя — это постоянные платежи Microsoft, которые в России к тому же стало сложно легально продлевать.
- Зависимость от Microsoft. Санкционные риски, прекращение поддержки и обновлений, давление импортозамещения (особенно для госсектора и КИИ).
- Узкие места RDS. Один терминальный сервер — единая точка отказа; масштабирование через фермы RDS сложное; протокол RDP «из коробки» тяжело тюнить под слабые каналы.
Платформа Inscale — это система виртуализации и VDI, прямая альтернатива VMware и Citrix, в реестре отечественного ПО. Терминальный сценарий она поддерживает напрямую: помимо собственного проприетарного протокола доставки рабочих мест, есть режим RDSH для классического терминального доступа. То есть привычная схема «приложение на сервере, тонкий клиент на месте» сохраняется — меняется только то, что под капотом не Windows RDS, а российская платформа на переработанном ядре KVM.
И это не «обёртка» над open-source: ядро KVM глубоко пропатчено, от Libvirt разработчики отказались ещё в 2019-м (после работы с T-Mobile и Vodafone), а Control Level, работу с памятью и отказоустойчивость переписали на собственном проприетарном коде. Из чего вообще состоит такая платформа — в разборе российской системы виртуализации.
Классическая боль терминального сервера — региональные филиалы со слабым интернетом, где RDP начинает «лагать». У Inscale протокол доставки настраивается тонко — 27 параметров (компрессия, динамические цвета, лимит FPS, масштабирование разрешения), а сам он вырос из алгоритма компрессии, изначально созданного под высоконагруженные научные задачи.
Насколько это глубоко: в крайнем, исключительном кейсе (банковский бэк-офис в удалённом северном регионе, 15 человек на канале 1 Мбит/с) инженеры ужали одно рабочее место до 50 кбит/с. Это предел возможностей, а не штатный режим — но он показывает запас по оптимизации, которого у стандартного RDP нет. Подробнее — в статье VDI при плохой связи.
Терминальный сервер всегда упирается в ресурсы: чем больше сессий, тем выше риск, что «тяжёлый» пользователь положит остальных. На платформе это решается тоньше, чем в RDS:
- Режимы балансировки — производительности и плотности: либо гарантировать каждой ВМ ресурсы, либо плотно упаковать сессии под реальную утилизацию.
- Управление через cgroups — каждой машине нарезается ровно её пул вплоть до доли гигагерц, см. управление ресурсами через cgroups.
У классического RDS падение сервера = простой всех пользователей. На платформе отказоустойчивость работает на уровне гипервизора: при отказе узла рабочие ВМ автоматически перезапускаются на живых хостах, а независимый HA-контроллер рассчитан на удержание системы даже при потере центра управления. Как это устроено — в разборе отказоустойчивого кластера.
Терминальный сервер часто стоит «на периметре», и это риск. Inscale построен по принципу «не доверяй никому»: внешних пользователей встречает шлюз, который по сути является NGFW; до авторизации во внутреннюю сеть нет доступа, даже порты узлов закрыты; пользователи и администраторы заходят через разные порты. Ядро защищено по стандартам ФСТЭК — важно для госсектора и данных под 152-ФЗ (см. приказ ФСТЭК №117). Пользователи заводятся из существующего каталога — поддерживаются Active Directory, FreeIPA и OpenLDAP.
Чаще всего на терминальном сервере держат именно 1С. Этот сценарий мы разобрали отдельно: как вынести многопользовательскую 1С на сервер и раздать тонкими клиентами — в статье тонкий клиент для 1С (и в базовом разборе VDI для 1С).
Замена терминального сервера звучит как большой проект, но платформа разворачивается быстро: гипервизор первого типа ставится на «голое железо» и работает даже на одной ноде без дорогой СХД, а добавление нового хоста занимает около 10 минут. В кейсе крупного заказчика VDI на 1500 рабочих мест (кластер из 11 серверов) развернули за полтора дня. Логика миграции близка к переезду с Citrix — пошаговый план в гайде по миграции с Citrix на российское VDI.
Замена терминального сервера актуальна из-за лицензий Microsoft, зависимости от Windows и импортозамещения. Российский VDI закрывает тот же сценарий (RDSH-терминал + тонкие клиенты), но добавляет то, чего у классического RDS нет: тонко настраиваемый протокол для слабых каналов, точное деление ресурсов между сессиями, отказоустойчивость вместо единой точки отказа, безопасность по ФСТЭК и отсутствие лицензий Microsoft. Хотите оценить замену терминального сервера на вашем парке — запросите демо-доступ.
