Масштабирование терминального сервера: сколько пользователей выдержит одна машина

«Сколько человек выдержит терминальный сервер?» — вопрос, на который в интернете есть десяток ответов, и все разные. Причина в том, что правильный ответ зависит не от железа, а от того, чем люди занимаются. Разберём, как считать под конкретный офис, какими счётчиками проверять расчёт на практике и в какой момент вертикальное наращивание перестаёт работать.

Сравним двух пользователей одного офиса.

Первый — кладовщик. Работает в одном окне 1С, вводит документы приёмки, других программ не открывает. Его сеанс потребляет около 400 МБ памяти и почти не грузит процессор.

Второй — главный бухгалтер. Одновременно открыты 1С с двумя базами, СБИС, браузер с десятком вкладок, Excel с большими таблицами, почта, мессенджер. Его сеанс — 3,5 ГБ памяти и заметная постоянная нагрузка на процессор.

Разница почти в девять раз по памяти. Любой расчёт «по числу людей» без учёта этого различия даёт результат, ошибочный в разы.

Поэтому считать надо по профилям. Мы делим пользователей на три категории:

Числа в последней колонке — из наших замеров на серверах с современными процессорами и частотой от 2,8 ГГц. На более медленных ядрах их надо уменьшать.

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

Порядок расчёта на конкретном примере: бухгалтерская фирма, 30 человек.

Шаг 1. Разложить по профилям. Допустим: 6 лёгких, 20 средних, 4 тяжёлых.

Шаг 2. Память. Складываем потребности сеансов и добавляем накладные расходы.

6 × 1 + 20 × 2,5 + 4 × 4 = 6 + 50 + 16 = 72 ГБ на сеансы. Плюс 8 ГБ операционной системе, плюс запас 15 % на пики. Итого около 92 ГБ, округляем до 96.

Шаг 3. Процессор. Считаем через плотность на ядро.

6 / 7 + 20 / 4,5 + 4 / 2,5 ≈ 0,9 + 4,4 + 1,6 = 6,9 ядра. Добавляем 2 ядра на систему и служебные задачи, округляем вверх: 10–12 vCPU.

Шаг 4. Диск. Терминальный сервер сам по себе диск грузит умеренно, но при 30 одновременных входах утром картина другая. SSD обязателен, объём — система плюс профили, если они локальные.

Шаг 5. Проверить на реальности. Расчёт даёт отправную точку, а не истину. Через месяц эксплуатации снимаем счётчики и корректируем.

Отдельно про количество ядер и частоту. Как и для сервера 1С, здесь частота важнее числа ядер, но не так однозначно: терминальный сервер обслуживает много независимых сеансов, и параллелизм ему полезен. Разумный баланс — не гнаться за максимальным числом ядер в ущерб частоте, но и не брать четырёхъядерный процессор под тридцать человек.

Расчёт проверяется замерами. Четыре счётчика отвечают на вопрос, упёрлись вы или нет.

Get-Counter -Counter @(
  "\Процессор(_Total)\% загруженности процессора",
  "\Система\Длина очереди процессора",
  "\Память\Доступно МБ",
  "\Память\Страниц/сек",
  "\Терминальные службы\Активные сеансы"
) -SampleInterval 15 -MaxSamples 240

Как трактовать:

Очередь процессора — самый честный индикатор. Загрузка 85 % при короткой очереди означает, что сервер работает эффективно. Загрузка 70 % при длинной очереди означает, что потоки ждут, и пользователи это чувствуют.

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

Полезная детализация — потребление по сеансам:

Get-Process -IncludeUserName |
  Where-Object SessionId -gt 0 |
  Group-Object SessionId |
  ForEach-Object {
    [PSCustomObject]@{
      Session = $_.Name
      User    = ($_.Group | Select-Object -First 1).UserName
      RAM_MB  = [int](($_.Group | Measure-Object WorkingSet64 -Sum).Sum / 1MB)
      CPU_s   = [int](($_.Group | Measure-Object CPU -Sum).Sum)
    }
  } | Sort-Object RAM_MB -Descending

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

Когда мощности перестаёт хватать, есть два пути: увеличить существующую машину или добавить вторую.

Наращивать одну машину проще: не нужны новые лицензии Windows Server, не усложняется администрирование, профили и настройки остаются на месте.

Предел этого пути наступает по трём причинам.

Первая — NUMA. На двухсокетном сервере память разделена между процессорами, и обращение к «чужой» памяти дороже. Виртуальная машина, не помещающаяся в один узел NUMA, теряет производительность непропорционально своему размеру.

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

Третья — обслуживание. Обновления Windows требуют перезагрузки. С одной машиной это всегда вечернее или ночное окно.

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

Наше практическое правило: от 25–30 одновременных пользователей имеет смысл переходить на два узла, даже если один справляется по ресурсам. Аргумент не в производительности, а в возможности обслуживать систему днём и переживать отказ.

Два узла по 8 vCPU и 48 ГБ обычно предпочтительнее одного с 16 vCPU и 96 ГБ при том же суммарном ресурсе. Разница в цене лицензий Windows Server при этом невелика — она считается по ядрам, а суммарное число ядер одинаково.

Несколько вещей, которые упираются раньше процессора и памяти.

Хранилище профилей. При контейнерных профилях утренний вход всех пользователей — это одновременное монтирование десятков VHDX. Файловый сервер становится узким местом раньше, чем узлы сеансов.

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

Диспетчер очереди печати. Обсуждали отдельно: массовое создание очередей при входе.

Контроллер домена. Тридцать одновременных входов означают тридцать аутентификаций плюс обработку групповых политик. На слабом DC это заметно.

Лицензии 1С. Ресурсов сервера может хватать, а лицензий — нет.

Сервер приложений 1С. Самое частое: терминальный сервер расширили, а сервер 1С остался прежним. Пользователи по-прежнему ждут, потому что упирается не терминал.

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

Клиент — торгово-производственная компания. Терминальный сервер разворачивали три года назад под 20 человек: 8 vCPU, 48 ГБ, один узел.

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

Мы начали не с расчёта, а с замеров, и картина оказалась не такой, как ожидали обе стороны.

Загрузка процессора в пике — 71 %, очередь процессора — 4 при 8 ядрах, то есть на грани, но без насыщения. Свободная память — 6 %, страниц в секунду до 2400 в утренние часы. Память была настоящим узким местом, процессор — нет.

Детализация по сеансам объяснила почему. Медианное потребление — 780 МБ, что нормально. А верхние пять сеансов держали от 4,8 до 7,2 ГБ каждый.

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

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

Что сделали, в порядке применения и по нарастанию стоимости:

• задали тайм-ауты: отключённый сеанс завершается через 12 часов, бездействующий отключается через 3 часа — свободной памяти в пике стало 19 % вместо 6;
• ограничили кэширование почты и вычистили автозагрузку в профиле по умолчанию;
• добавили серверу памяти с 48 до 96 ГБ — единственная покупка, недорогая;
• через месяц, по накопленным замерам, добавили второй узел сеансов.

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

Новый сервер, за расчётом которого обращались, не понадобился. Понадобились 48 ГБ памяти и две настройки коллекции, про которые забыли при первоначальном развёртывании.

Финальные цифры на 42 пользователях: загрузка процессора в пике 54 %, свободная память 31 %, страниц в секунду близко к нулю. Запас есть ещё примерно на пятнадцать человек.

Сколько пользователей выдержит терминальный сервер с 8 ядрами и 64 ГБ?

От 15 до 45 в зависимости от того, чем люди занимаются. Лёгкий профиль — один пользователь на 6–8 ядер и около гигабайта памяти; тяжёлый — 2–3 сеанса на ядро и до пяти гигабайт. Считать надо по профилям, а не по числу голов.

Что важнее для терминального сервера — память или процессор?

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

Когда переходить с одного сервера на ферму?

Практический порог — 25–30 одновременных пользователей, и дело не столько в ресурсах, сколько в обслуживании. С двумя узлами обновления ставятся днём через режим стока, а отказ одного хоста затрагивает половину офиса, а не всех.

Стоит ли просто добавить ресурсов одной виртуальной машине?

До определённого предела да, это проще и дешевле. Но виртуальная машина, не помещающаяся в один узел NUMA физического сервера, теряет производительность непропорционально размеру, а единая точка отказа остаётся. К тому же обслуживание одной машины всегда означает простой всего офиса.