RDP-сервер для удалённого офиса: сколько CPU, RAM и дисков закладывать на пользователя

Неудобный вопрос звучит так: вы хотите купить терминальный сервер или просто надеетесь, что «на 30 человек как-нибудь хватит»? В RDP-проектах железо часто выбирают по грубой формуле: один сервер, много памяти, процессор помощнее. Иногда это работает. Но чаще через пару месяцев выясняется, что утром всё тормозит, 1С открывается рывками, браузер съедает память, профили пользователей разрастаются, а диски постоянно заняты мелкими операциями.

Ниже — практичный buyer guide для инженеров и интеграторов: какие ресурсы закладывать на пользователя, где нужен запас, когда терминальный сервер подходит, а когда лучше смотреть в сторону VDI, отдельного сервера виртуализации или GPU-сценариев.

Считать надо не сотрудников, а рабочие профили

В терминальном сервере RDP один и тот же сервер одновременно обслуживает десятки интерактивных сессий. Поэтому вопрос «сервер на 20 пользователей» слишком грубый. Два офиса на 20 человек могут отличаться по нагрузке в разы.

Сначала разделите пользователей на профили:

• Лёгкий офис: почта, Word/Excel, PDF, мессенджер, 1–3 вкладки браузера.
• Бухгалтерия и операторы 1С: тонкий клиент 1С, офисные документы, печать, сканирование, обмен файлами.
• Браузерная нагрузка: CRM, маркетплейсы, личные кабинеты, много вкладок, веб-приложения с тяжёлым JavaScript.
• Инженерные и графические задачи: CAD, просмотр 3D, монтаж, работа с видео, GIS, медицинские снимки.

Для первых двух сценариев классический RDP обычно уместен. Для третьего — возможен, но требуется больше памяти и дисциплина по вкладкам. Для четвёртого обычный терминальный сервер чаще становится компромиссом: там уже стоит обсуждать VDI, проброс GPU, отдельные рабочие станции или GPU сервер.

Вторая переменная — одновременность. Если в компании 40 сотрудников, но одновременно в RDP активно работают 22–25, считать нужно активные сессии плюс запас. Если все приходят к 9:00 и открывают одни и те же приложения, пиковая нагрузка будет выше, чем при равномерной работе в течение дня.

Третья переменная — размещение приложений и данных. Один сценарий — RDP-сервер только запускает клиентские приложения, а SQL, файловые базы и сервисы лежат отдельно. Другой — на нём же крутятся 1С, файловые папки, антивирусная консоль, резервное копирование и ещё пара «временных» служб. Во втором случае расчёт по пользователям быстро теряет смысл: сервер начинает конкурировать сам с собой.

Ориентиры по CPU, памяти и дискам на одного RDP-пользователя

Ниже — не универсальная норма, а стартовые ориентиры для предварительного подбора. Перед финальной закупкой полезно проверить нагрузку на пилоте или хотя бы снять метрики с текущей инфраструктуры.

Процессор

Для RDP важны не только ядра, но и частота, задержки и поведение под интерактивной нагрузкой. Пользователь чувствует не среднюю загрузку CPU за сутки, а задержку при открытии окна, пересчёте таблицы, запуске 1С или рендере веб-страницы.

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

• лёгкий офис: 1 физическое ядро на 4–6 активных пользователей;
• 1С тонкий клиент, офис, печать: 1 ядро на 3–5 активных пользователей;
• тяжёлый браузер и веб-CRM: 1 ядро на 2–4 активных пользователей;
• смешанная нагрузка с пиками: закладывайте минимум 20–30% резерва по CPU.

Если сервер строится как виртуальная машина, не раздавайте ей все ядра хоста «на всякий случай». В средах Hyper-V и Proxmox важно учитывать оверсабскрипшн, соседние ВМ и конкуренцию за CPU. По этой теме полезно сверяться с официальными материалами: обзор Hyper-V от Microsoft и документация Proxmox VE.

Оперативная память

Память в RDP заканчивается незаметно: один пользователь открыл Excel, другой оставил 12 вкладок, третий не вышел из сессии неделю. Когда начинается активный swap, пользователи видят «тормозит всё», хотя CPU может быть загружен умеренно.

Ориентиры по RAM на активного пользователя:

• лёгкий офис: 1,5–2,5 ГБ;
• офис + 1С тонкий клиент: 2–4 ГБ;
• браузерная работа: 3–6 ГБ;
• тяжёлые Excel-файлы, отчёты, несколько приложений сразу: считать отдельно по фактическому потреблению.

К этому добавляется память под ОС, службы, антивирус, кэш, RDS-роли и резерв. Для Windows Server разумно не опускаться ниже 8–12 ГБ под систему и служебные процессы, а на рабочих конфигурациях оставлять свободный запас.

Для терминального сервера, особенно если на нём постоянно открыты базы, документы и пользовательские профили, уместна ECC память. Она не делает систему быстрее, но снижает риск незаметных ошибок в памяти. Для RDP это не «магическая защита от всего», а нормальная инженерная гигиена там, где сервер обслуживает бизнес-процессы.

Диски

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

Минимальная практичная схема:

• SSD или NVMe под ОС и роли RDS;
• отдельный быстрый том под пользовательские профили, если они локальные или используются контейнеры профилей;
• RAID1 или зеркало для системного тома;
• отдельное хранилище под общие файлы и базы, если нагрузка заметная;
• регулярный бэкап, который не лежит только на том же сервере.

HDD для активных RDP-профилей — плохая идея, если пользователей больше нескольких человек. HDD ещё можно использовать для архива, холодных данных или резервных копий, но интерактивную нагрузку лучше держать на SSD/NVMe.

Пример расчёта: удалённый офис на 25 активных пользователей

Возьмём типичный сценарий для интегратора: компания переводит сотрудников на удалённую работу через RDP. Всего пользователей — 32, одновременно активно работают около 25. Нагрузка: 1С тонкий клиент, офисные документы, PDF, печать, 4–6 вкладок браузера. SQL-сервер и файловое хранилище размещаются отдельно.

CPU

Берём ориентир 1 ядро на 3–5 активных пользователей для офисной нагрузки с 1С.

Расчёт:

• 25 активных пользователей / 4 ≈ 6–7 физических ядер;
• добавляем запас на пики, антивирус, обновления, фоновые процессы;
• практичный диапазон: 8–12 физических ядер или сопоставимая конфигурация с достаточным числом потоков и хорошей частотой.

Если это виртуальная машина на хосте, лучше начать, например, с 8 vCPU и смотреть метрики: очередь процессора, загрузку по ядрам, задержки в пиках. Бездумно выдавать 24 vCPU одной ВМ не всегда полезно: планировщику гипервизора сложнее обслуживать такую машину, особенно если рядом есть другие нагрузки.

RAM

Для 1С тонкий клиент + офис берём 3 ГБ на активного пользователя как средний безопасный ориентир.

Расчёт:

• пользователи: 25 × 3 ГБ = 75 ГБ;
• ОС и службы: 8–12 ГБ;
• резерв: 15–25%.

Итог: 96–128 ГБ RAM выглядят разумнее, чем 64 ГБ. На 64 ГБ такой сервер может жить, если пользователи дисциплинированны, браузерная нагрузка умеренная, профили чистятся, а пик ниже расчётного. Но для удалённого офиса, где RDP — основной рабочий контур, лучше не загонять память в упор.

Диски

Практичная схема:

• 2 × NVMe SSD в зеркале под ОС, RDS и профили;
• отдельный том или отдельное хранилище под общие данные;
• резервное копирование по расписанию с проверкой восстановления;
• если 1С файловая и лежит рядом с пользователями — пересчитать отдельно, потому что это уже не просто терминальный сервер, а комбинированная нагрузка.

Сеть

Для RDP-трафика сам по себе 1 Гбит/с часто достаточен, если нет видео, тяжёлой графики и массовой передачи файлов через сессии. Но если сервер активно ходит к NAS, SQL, резервному хранилищу или нескольким VLAN, 10 Гбит/с между ключевыми узлами может быть оправдан. Не из-за красоты цифры, а чтобы не получить узкое место между RDP, базами и файлами.

Важно: лицензирование Windows Server, RDS CAL, пользовательские лицензии приложений и правила доступа нужно считать отдельно. Железо не решает юридическую часть проекта.

Когда RDP-сервер подходит, а когда лучше выбрать другой сценарий

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

RDP обычно подходит, если:

• нужно дать удалённый доступ к 1С, офисным приложениям и внутренним сервисам;
• есть филиалы или сотрудники на удалёнке с разными устройствами;
• важно централизовать обновления, доступы и хранение документов;
• приложения плохо работают через VPN напрямую с пользовательского ПК;
• требуется единая среда для бухгалтерии, отдела продаж, операторов, техподдержки.

В связке с отдельным SQL и нормальным хранилищем RDP может быть аккуратным и предсказуемым решением для малого и среднего бизнеса.

RDP не стоит выбирать автоматически, если:

• пользователи работают с 3D, CAD, видео, большими изображениями или графическими интерфейсами с высокой частотой обновления;
• нужно изолировать рабочие места друг от друга на уровне отдельных виртуальных машин;
• много USB-оборудования, нестандартных драйверов, касс, сканеров, токенов;
• сотрудники в основном работают в SaaS через браузер, и RDP нужен только «по привычке»;
• интернет-канал нестабилен, а приложение чувствительно к обрывам сессии;
• есть строгие требования к сегментации, журналированию и контролю данных.

Для графических задач иногда уместнее VDI или GPU сервер с корректно подобранными видеокартами и лицензиями. Для смешанной инфраструктуры — отдельный сервер виртуализации, где RDP будет одной из ВМ, а не единственной ролью физического узла. Для нагрузки 1С в ряде случаев правильнее разделить роли: отдельный сервер для 1С, отдельный SQL, отдельный RDS. Это усложняет схему, зато снижает взаимное влияние нагрузок.

Типичные ошибки при выборе RDP-сервера

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

1. Считать всех пользователей одинаковыми

Оператор с одной формой 1С и менеджер с 20 вкладками браузера — разные нагрузки. Если усреднить их до «одного пользователя», расчёт будет слишком оптимистичным.

2. Экономить на памяти

CPU ещё можно пережить за счёт очередей и кратковременных пиков. Нехватка RAM быстро превращает сервер в медленную систему со swap, задержками и раздражающими зависаниями. Для RDP память почти всегда дешевле, чем последующая диагностика и переделка.

3. Ставить профили и кэш на медленные диски

Пользователи открывают браузеры, документы, временные файлы, почтовые вложения. Всё это создаёт мелкий I/O. Если диски не справляются, даже мощный процессор не спасает интерактивность.

4. Совмещать слишком много ролей

RDP, файловая база 1С, SQL, бэкап, антивирусная консоль, файловый сервер и контроллер домена на одном узле — распространённая схема «пока так». Для маленького офиса она может быть допустима, но при росте пользователей становится трудно понять, что именно тормозит.

5. Не учитывать антивирус и обновления

Антивирусные проверки, индексация, обновления Windows, обновления браузеров и офисного ПО создают пики. Их нужно планировать по расписанию и исключениям, а не ждать, пока они совпадут с началом рабочего дня.

6. Забывать про профили пользователей

Локальные профили разрастаются. Перемещаемые профили могут долго входить. Контейнеры профилей требуют быстрого хранилища. Если не продумать это заранее, вход в систему станет отдельной болью.

7. Покупать «про запас» без архитектуры

Большой сервер без разделения ролей, мониторинга и резервного копирования не становится надёжной инфраструктурой автоматически. Иногда лучше взять умеренный RDP-узел и отдельно спроектировать SQL, NAS, бэкап и виртуализацию.

Чек-лист перед подбором железа для RDP

Перед тем как выбирать процессор, память и диски, соберите исходные данные. Это занимает меньше времени, чем потом объяснять, почему сервер «на 50 пользователей» не выдерживает 25 активных сессий.

1. Пользователи

• Сколько всего учётных записей?
• Сколько активных одновременно утром, днём, в конце месяца?
• Есть ли сезонные пики: отчётность, инвентаризация, массовая обработка заказов?

2. Приложения

• Какие программы открыты постоянно?
• Сколько вкладок браузера обычно держит пользователь?
• Есть ли 1С, CRM, офисные пакеты, PDF, ЭДО, банк-клиенты?
• Где расположены базы: на RDP-сервере, SQL-сервере, NAS, облаке?

3. Профили и данные

• Локальные профили, перемещаемые или контейнеры?
• Где хранится рабочий стол, загрузки, кэш браузера?
• Есть ли ограничения на размер профиля?
• Как выполняется резервное копирование и проверка восстановления?

4. Железо

• CPU: достаточно ли ядер и частоты под интерактивную нагрузку?
• RAM: есть ли запас 20–30% после расчёта активных пользователей?
• Диски: SSD/NVMe под профили и временные файлы?
• Сеть: хватает ли пропускной способности до SQL, NAS, бэкапа?
• Питание и охлаждение: сервер рассчитан на круглосуточную работу?

5. Эксплуатация

• Настроен ли мониторинг CPU, RAM, дисков, сети и сессий?
• Есть ли регламент обновлений?
• Настроены ли политики завершения зависших и забытых сессий?
• Продуманы ли RDS-лицензии, права доступа и аудит?

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

Ещё по теме на huananzhi.ru

• Серверы для офиса
• В наличии в России

Читайте также

• X99 на Xeon в 2026 году: рабочая серверная платформа или ловушка дешёвого бюджета
• 5 ошибок при выборе серверной материнской платы: где ломается конфигурация под 1С, GPU, NAS и VDI
• ECC или обычная память в сервере: как понять, где коррекция ошибок обязательна, а где это лишняя сложность

Автор статьи