В 9:00 на терминальный сервер одновременно вошли 32 сотрудника. Авторизация растянулась, окна открывались с задержкой, отклик вышел за ожидаемые 200 мс. После утреннего пика загрузка вернулась к норме — и сервер снова выглядел исправным.
Так бывает, когда железо покупают «на 50 человек», но не считают одновременные входы, открытые приложения и профиль работы. Тебе нужно другое число: сколько активных сессий выдержит узел в пик и когда пора ставить второй.
Считать нужно сессии, а не сотрудников в штате
Компания из 80 человек может создавать 35 одновременных сессий: часть сотрудников работает посменно, часть — вне офиса. В другом отделе из 50 человек все входят между 8:55 и 9:05. Для сервера второй случай тяжелее.
Microsoft рекомендует учитывать тип нагрузки, одновременные сессии, требуемое время отклика и частоту входов. Именно утренний вход часто первым упирается в процессор. Хост загружает профиль, запускает приложения и обрабатывает групповые политики, пока программный RDP-кодировщик делит ядра с остальными процессами.
Поэтому расчёт начинается с трёх исходных данных:
- сколько пользователей работают одновременно;
- какие приложения они запускают;
- сколько человек входит в течение одного короткого пика.
Без них фраза «сервер на 50 пользователей» не описывает нагрузку.
Офисные сессии и CAD нельзя складывать в одну норму
Дальше считаем один профиль работы. В этой статье это браузер, почта, офисные документы и клиент 1С. Такой набор позволяет разместить на одном хосте десятки сессий, если приложения не забирают память фоновыми задачами.
CAD, 3D, монтаж видео и несколько мониторов требуют другого расчёта. Microsoft советует использовать GPU, если приложения активно работают с графикой или суммарное разрешение рабочего места превышает 3840 × 2160. На CPU-хосте такая нагрузка снижает плотность сессий и может вызвать артефакты, зависание кадров и пикселизацию.
Смешивать инженера с большой 3D-моделью и бухгалтера с клиентом 1С в усреднённого «пользователя» нельзя. Тяжёлая сессия способна занять ядра, которыми в этот момент пользуется весь отдел.
Модельный замер даёт 16 ядер и 128 ГБ на 50 сессий
Возьмём измеримый исходник. На тестовом сервере с 8 физическими ядрами работают 20 активных пользователей. В пик процессор занят на 55%, а система вместе с их приложениями использует 44 ГБ памяти.
Допускаем, что целевой сервер получит те же версии Windows Server, приложений и клиента 1С. Пользователи выполняют те же действия с той же частотой. При другом стеке переносить результат нельзя.
Методика 1С разрешает линейно переносить замер модельной системы на целевую, если совпадают приложения, версии, расположение компонентов и профиль нагрузки. Коэффициент для 50 сессий:
50 / 20 = 2,5
На модельном сервере нагрузка занимает:
8 ядер × 55% = 4,4 ядра
Переносим её на 50 сессий:
4,4 × 2,5 = 11 ядер
Если терминальный сервер работает в виртуальной машине, закладываем 20% сверху. Это верхняя граница потери ёмкости из диапазона 15–20%, который приводит Microsoft:
11 × 1,2 = 13,2 ядра
Округляем до доступной конфигурации — 16 физических ядер. Частота одного ядра должна быть не ниже, чем у модельного сервера: дополнительные медленные ядра не компенсируют просадку однопоточных операций при входе.
Память считаем отдельно:
44 ГБ × 2,5 = 110 ГБ
Ещё 8 ГБ оставляем гипервизору. Получаем 118 ГБ и округляем до 128 ГБ ECC RDIMM.
Это расчёт для терминального узла, а не для всей инфраструктуры. Если рядом работает СУБД или сервер приложений 1С, добавь их ресурсы по расчёту отдельного сервера 1С.
Ёмкость ограничивает пик
Средняя загрузка процессора за рабочий день скрывает короткие очереди. В 11:30 сервер может занимать 35% CPU, но утром упираться в него во время массового входа.
После запуска приложений ограничителем становится память. Microsoft отмечает: при её дефиците переход с 8 до 16 ГБ способен увеличить число сессий больше чем вдвое. Причина не в самой памяти, а в том, что система реже обращается к файлу подкачки.
Третий ограничитель — накопители. Профили, кэши браузера и временные файлы создают множество мелких операций. Для активных профилей нужны SSD или NVMe; HDD-массив добавит задержку именно в тот момент, когда пользователи одновременно входят и запускают программы.
Просто удвоить число ядер тоже не получится. По данным Microsoft, отдача от каждого следующего ядра снижается: синхронизация процессов и общие ресурсы системы не масштабируются линейно.
После 50 сессий два узла полезнее одного крупного
По исходному замеру можно получить три конфигурации.
Для 25 одновременных сессий коэффициент равен 25 / 20 = 1,25. Процессорный расчёт с запасом на виртуализацию даёт 8 × 55% × 1,25 × 1,2 = 6,6 ядра. Берём 8 физических ядер. Память: 44 × 1,25 + 8 = 63 ГБ, поэтому ставим 64 ГБ.
Для 50 сессий нужны рассчитанные выше 16 ядер и 128 ГБ.
Для 80 сессий я бы ставил два узла по 16 ядер и 128 ГБ, распределяя примерно по 40 пользователей. На один узел расчёт даёт 8 × 55% × 2 × 1,2 = 10,56 ядра и 44 × 2 + 8 = 96 ГБ. Округление до 16 ядер и 128 ГБ оставляет запас на неравномерное распределение сессий.
Один крупный сервер требует меньше корпусов, блоков питания и серверных лицензий. Зато его отказ останавливает всю удалённую работу. Два узла дороже и требуют балансировки, но часть сотрудников продолжит работать при отказе одного хоста. Планирование RDS у Microsoft прямо включает высокую доступность в требования к архитектуре.
Если SQL Server, файловое хранилище и другие виртуальные машины должны жить на тех же хостах, их нагрузку придётся прибавить. Для этого нужен отдельный расчёт сервера виртуализации для офиса.
Спецификация под 50 одновременных офисных пользователей
Считаем конфигурацию для 50 активных RDP-сессий с браузером, документами, почтой и клиентом 1С. СУБД и сервер приложений работают отдельно.
- Процессор: один CPU на 16 физических ядер, с архитектурой и частотой ядра не ниже модельного сервера. Расчёт требует 13,2 ядра с поправкой на виртуализацию; остаток закрывает пик входов.
- Память: 128 ГБ ECC RDIMM. Из них 110 ГБ получены переносом модельного замера, 8 ГБ оставлены гипервизору, остальное — округление до доступного объёма.
- Накопители: два серверных NVMe в RAID 1 под ОС, приложения и пользовательские профили. Массив переживёт отказ одного накопителя без остановки узла.
- Сеть: два порта 10 GbE. Такая скорость нужна не для RDP-трафика, а для подключения общего хранилища и последующего добавления второго узла.
- Питание: два блока с горячей заменой. Отказ одного БП не должен завершать 50 сессий.
- Корпус: 2U, минимум четыре свободных слота памяти и два свободных дисковых отсека. Это позволит добавить память и накопители без замены платформы.
Перед заказом повтори замер на одном пилотном сервере и постепенно наращивай число сессий. Для крупного внедрения Microsoft предлагает имитировать реальные действия пользователей средствами автоматизации: такой тест покажет утренний пик до покупки всей партии оборудования.
Правило пересчёта короткое: перенеси пиковую загрузку CPU и RAM модельного сервера пропорционально числу активных сессий. Для виртуальной машины умножь результат по процессору на 1,2. Если расчёт вышел за 16 ядер или удалённая работа не должна останавливаться при отказе хоста, ставь два узла.
Эта спецификация закрывает только терминальные сессии. Размещать на тех же 16 ядрах SQL Server, сервер 1С и файловое хранилище без отдельного расчёта нельзя: тогда запас существует лишь в коммерческом предложении.
