Терминальный сервер на своём гипервизоре: схема для офиса

MAATRIX

Десяток сотрудников с одинаковым набором программ, каждому — отдельный мощный компьютер с лицензиями, апдейтами и локальными бэкапами, которые никто не проверяет. Знакомая картина для небольшого офиса. Терминальный сервер решает это иначе: одна VM с общими приложениями, к которой все подключаются удалённо, вместо парка индивидуальных рабочих станций. Ниже — практическая схема: сколько ресурсов заложить, какие грабли с лицензированием Windows вас ждут, как не открыть RDP наружу и что делать, если единственный терминальный сервер откажет.

Когда терминальный сервер вообще нужен

Терминальный сервер (в мире Windows — Remote Desktop Session Host, RDSH) — это не абстрактно «правильное» решение, а инструмент под конкретную ситуацию. Он оправдан, когда одновременно выполняются три условия:

• Команда от 5-7 человек и больше. На 2-3 сотрудников разворачивать отдельную VM, настраивать профили, решать вопрос лицензирования — избыточно: обычные компьютеры с локальными программами обойдутся дешевле и без лишней инфраструктуры.
• Однотипный набор приложений. Если все работают в одной учётке 1С, одном CRM-клиенте, одном пакете офисных программ — терминальный сервер идеально ложится на задачу. Если у каждого сотрудника своя специфика (дизайнер с тяжёлым Photoshop, разработчик со своей IDE, бухгалтер с 1С) — общий сервер только мешает: одному нужна GPU-мощность, другому — простой доступ к базе, и ужиться на одной VM с одинаковыми ресурсами для всех им сложно.
• Есть причина не давать всем локальные копии данных. Часто это база данных, к которой нужен единый точка входа (та же 1С, специализированный учёт), или требование не хранить данные компании на домашних и случайных компьютерах сотрудников.

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

Терминальный сервер как отдельная VM на гипервизоре

Первое архитектурное решение: терминальный сервер — это не голое железо и не роль на сервере, где крутится ещё что-то (файловый сервер, контроллер домена, 1С-сервер приложений). Это отдельная виртуальная машина на вашем гипервизоре (Proxmox, голый KVM, Hyper-V — конкретный выбор здесь вторичен, если вы уже определились между Proxmox и голым KVM).

Причины именно так:

1. Изоляция. Если терминальный сервер зависнет или потребует перезагрузки после обновлений Windows — это не должно ронять контроллер домена или файловый сервер на той же физической машине.
2. Ресурсное планирование. VM с фиксированными (или с разумным overcommit) CPU/RAM для терминального сервера не конкурирует напрямую за ресурсы с другими ролями — вы управляете лимитами на уровне гипервизора, а не гадаете, кто кого «объедает» на голом железе.
3. Снапшоты и откат. Перед накопительным обновлением Windows или установкой нового ПО в общий профиль — снапшот VM на уровне гипервизора, и в случае проблемы откат за минуты, а не переустановка с нуля.
4. Миграция. VM можно перенести на другой физический хост при плановом обслуживании железа без простоя для пользователей (если гипервизор и хранилище это позволяют).

Практическая раскладка ролей на гипервизоре для небольшого офиса обычно выглядит так: отдельная VM под терминальный сервер (RDSH), отдельная VM под контроллер домена и DNS (если используется Active Directory), отдельная VM или физический NAS под файловое хранилище и бэкапы. Раскидывать роли по разным VM, а не консолидировать всё в одну «универсальную» машину — тот случай, когда простота архитектуры окупается предсказуемостью при сбоях.

Если Windows разворачивается как гостевая VM на KVM/Proxmox — учитывайте нюансы виртуализации Windows, в частности драйверы virtio для сети и диска: без них производительность диска и сети в госте будет заметно хуже, чем на голом железе (разбор — в статье про Windows в KVM и virtio-драйверы).

Сколько ресурсов закладывать: считаем по одновременным пользователям, а не по штату

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

Если в офисе 20 сотрудников, но по факту одновременно в терминальном сервере работают 12-14 (часть в отпуске, часть на встречах, часть работает из дома в другую смену) — ресурсы нужно закладывать под пиковую одновременную нагрузку с запасом, а не под все 20 профилей сразу. Переплата за 20 «слотов», которые никогда не используются одновременно, — деньги на ветер; но и заниженный расчёт по «средней» нагрузке приведёт к тормозам в момент пика (конец месяца, закрытие отчётности, все на месте).

Методика прикидки:

1. Определите пиковое число одновременных сессий. Не штат целиком, а реальный максимум одновременно залогиненных пользователей — по опыту, для типичного офиса это 60-80% от штата, но точную цифру лучше смотреть по факту через несколько недель эксплуатации, а не гадать заранее.
2. Заложите ресурсы на одну сессию, исходя из профиля нагрузки. Ориентировочно (это именно ориентир, не измеренный бенчмарк — у вас цифры будут отличаться в зависимости от конкретных приложений):

• Лёгкая нагрузка (офисные документы, почта, браузер, лёгкий CRM-клиент) — порядка 1-1.5 ГБ RAM и небольшая доля CPU-ядра на сессию.
• Средняя нагрузка (1С, специализированный учётный софт с активной работой с базой) — порядка 2-3 ГБ RAM и заметная доля ядра на сессию.
• Тяжёлая нагрузка (работа с большими таблицами, множество открытых окон, локальные вычисления в сессии) — от 4 ГБ RAM и практически отдельное ядро на активного пользователя в пике.

1. Умножьте на пиковое число сессий и добавьте запас на саму ОС и системные процессы. Windows Server с ролью RDSH и её службами (профили, печать, антивирус, агенты мониторинга) съедает заметную часть ресурсов ещё до первого пользователя — закладывайте под это отдельно 2-4 ГБ RAM и одно-два ядра сверх пользовательской нагрузки.
2. Держите запас 20-30% сверху расчётного пика, а не выделяйте впритык — терминальный сервер, работающий на пределе, деградирует для всех пользователей одновременно, и это заметно сразу, а не постепенно.

Пример для ориентира (не точный расчёт под ваш случай, а иллюстрация логики): офис на 15 человек, пиковая одновременная нагрузка — 10 сессий, профиль средний (1С плюс офисные документы). Грубая прикидка: 10 сессий × ~2.5 ГБ ≈ 25 ГБ + 3-4 ГБ на ОС и службы + запас 25% ≈ 36-38 ГБ RAM на VM, и по CPU — порядка 6-8 виртуальных ядер с запасом. Это отправная точка для теста, а не гарантированная цифра — реальную нагрузку нужно смотреть в диспетчере ресурсов Windows после недели-двух работы и корректировать.

Держите в уме и то, что виртуальные CPU терминального сервера — общий пул с другими VM на том же гипервизоре: если хост уже нагружен другими ролями, overcommit CPU способен съесть запас именно в момент, когда все сотрудники одновременно активны.

Лицензирование Windows: RDS CAL — отдельная и обязательная тема

Здесь часто попадают в ловушку: развернуть Windows Server как VM и настроить роль Remote Desktop Session Host технически несложно, но легальный многопользовательский удалённый доступ к Windows Server требует отдельного лицензирования сверх самой ОС — это лицензии RDS CAL (Remote Desktop Services Client Access License), по пользователю или по устройству, в дополнение к обычной лицензии Windows Server.

Точные актуальные цены здесь приводить не буду — они зависят от программы лицензирования (розница, объёмные соглашения, условия провайдера) и региона, и любая названная сейчас цифра быстро устареет. Важнее сам факт существования этого требования: типичная ошибка — поднять RDSH, посадить туда десять сотрудников и вспомнить про CAL только при вопросе легальности или аудите лицензий.

Практические выводы для планирования:

• Закладывайте бюджет на RDS CAL как отдельную строку расходов, не считайте, что «Windows Server куплен — и всё включено».
• Разберитесь заранее, какая модель CAL (per user / per device) выгоднее для вашего конкретного случая — это зависит от того, сколько устройств приходится на одного сотрудника и работает ли кто-то посменно с одного и того же устройства.
• Учтите, что лицензирование Windows Server и лицензирование RDS CAL — разные, независимые сущности, и путаница между ними — частый источник заблуждений при планировании бюджета.

Подробный разбор частых заблуждений вокруг многопользовательского RDS-доступа и его лицензирования — в статье про лицензирование Windows Server при нескольких пользователях RDP, а более широкий список типичных ошибок и мифов вокруг лицензирования Windows Server в целом — в статье про заблуждения в лицензировании Windows Server. Прежде чем закупать сервер под продакшн-эксплуатацию с несколькими пользователями, стоит свериться с актуальными условиями лицензирования у вашего поставщика ПО или юриста по лицензионным вопросам — это не та область, где стоит полагаться на прикидки из статьи в интернете.

Сетевая архитектура: доступ через VPN, а не открытый RDP

Сотрудники должны подключаться к терминальному серверу удалённо — из дома, из другого офиса, в командировке. Здесь есть один принцип, от нарушения которого стоит предостеречь максимально прямо: не выставляйте RDP-порт (3389) напрямую в интернет.

Открытый наружу RDP — один из самых эксплуатируемых векторов атак на Windows-инфраструктуру: боты сканируют интернет на открытый 3389 непрерывно, брутфорсят пароли, а найденные уязвимости в самом протоколе RDP периодически становятся основой для массовых атак (включая шифровальщики) на серверы, выставленные так «для удобства». Это не гипотетический риск, а системная, регулярно эксплуатируемая практика атакующих — открытый RDP находят и атакуют, как правило, быстро.

Правильная схема:

1. Терминальный сервер живёт во внутренней сети (в изолированном VLAN или просто в приватной подсети гипервизора), без прямого маршрута из интернета на порт 3389.
2. Сотрудники поднимают VPN-подключение к внутренней сети офиса (WireGuard, OpenVPN, IKEv2 — конкретный протокол вторично, важен сам факт шифрованного туннеля с аутентификацией до того, как трафик вообще доберётся до RDP-порта).
3. Только после установления VPN-туннеля клиент RDP подключается к терминальному серверу по внутреннему адресу — снаружи для порта 3389 просто нет маршрута, и сканеры интернета его не увидят вообще.
4. Дополнительный слой — многофакторная аутентификация на самом VPN-подключении (а по возможности и на входе в Windows), чтобы кража одного пароля не давала прямого доступа.

Готовая типовая схема VPN-доступа для удалённой команды с разбором вариантов — в статье про VPN для удалённой команды, а сочетание именно VPN и RDP на Windows-инфраструктуре с акцентом на безопасность разобрано в статье про VPN и RDP на Windows. Если у вас уже есть WireGuard-туннель до внутренней сети — вариант проброса RDP именно через него, без отдельного клиента VPN на каждом устройстве, разобран в статье про RDP через WireGuard.

Отдельно: если офис на нескольких площадках (главный офис плюс филиал), а терминальный сервер физически стоит в одном месте, между площадками имеет смысл постоянный site-to-site VPN-туннель, а не отдельные подключения каждого сотрудника филиала — это снимает часть нагрузки с настройки клиентов и даёт единую точку контроля трафика между офисами.

Отказоустойчивость: единая точка отказа для всей компании

Здесь терминальный сервер принципиально отличается от парка индивидуальных рабочих станций по профилю риска. Если у сотрудника сломался личный компьютер — не работает один человек, остальные продолжают как ни в чём не бывало. Если отказал единственный терминальный сервер — не работает вся компания одновременно, потому что все сессии идут через одну точку. Это концентрированный риск, и для бизнес-критичного сценария его нужно рассматривать заранее, а не по факту первого простоя.

Уровни резервирования, от базового к более надёжному:

• Регулярные бэкапы VM на уровне гипервизора (снапшоты плюс выгрузка на отдельное хранилище) — минимальная защита. Она спасает данные, но не спасает от простоя: восстановление из бэкапа занимает время, и весь офис в это время не работает.
• Холодный резерв — вторая VM (на этом же или на другом хосте гипервизора) с образом терминального сервера наготове, но выключенная и не обновляемая в реальном времени. При отказе основной — включаете резервную и накатываете свежий бэкап данных. Простой измеряется десятками минут — часами, но компания не остаётся совсем без сервера на неопределённый срок.
• Горячий резерв — вторая VM в актуальном состоянии (репликация данных и настроек в реальном или почти реальном времени), готовая принять сессии сразу после переключения. Дороже и сложнее в поддержке, но простой измеряется минутами.

Какой уровень выбрать — вопрос экономики конкретного бизнеса: сколько стоит компании час простоя офиса против содержания резервной VM. Для многих небольших офисов достаточным компромиссом оказывается холодный резерв плюс проверенный процесс бэкапов с реальными тестами восстановления — когда оправдан горячий, а когда достаточно холодного резерва, разобрано в статье про горячий и холодный резервный сервер; экономику вопроса — в статье сколько стоит резервный сервер.

Резервную VM нужно периодически реально включать и проверять, что она поднимается и подключается — иначе риск обнаружить проблему с резервом именно в момент, когда он понадобился.

Частые вопросы