Расчет нагрузки RDS: CPU, RAM и профили без очередей

Почему RDS начинает тормозить и откуда берутся очереди

Пользователь редко говорит: «у нас не хватает CPU». Он видит ожидание. Вход в систему тянется, окна открываются с паузой, курсор подвисает, печать уходит через раз, а в 1С или браузере появляются задержки после клика. В RDS это почти всегда означает одно: десятки сессий одновременно упираются в общий ресурс и начинают ждать.

Проблема в том, что узкое место часто не одно. Это связка.

Например, процессор еще «терпит», но диски заняты профилями и временными файлами - и растет время входа. Или памяти вроде хватает, но из-за давления на RAM система активнее использует файл подкачки, и уже диск вытягивает на себе всю нагрузку. Еще одна частая история - сеть и принтеры. Пользователи думают, что «сервер тормозит», а на деле зависает печать или профиль грузится по медленному каналу.

Типовые «очереди», которые легко узнать по жалобам:

• долгий вход и «подготовка рабочего стола» при старте смены;
• задержки при запуске приложений и открытии файлов;
• подвисания при массовой печати, особенно на общих принтерах;
• тормоза в браузере, при работе с документами и вкладками;
• «лаги» в конце дня, когда много активных сессий и фоновых задач.

Масштабирование «на глаз» опасно вдвойне: можно купить лишнее железо и все равно получить очереди, потому что усилили не тот узел. Дальше нужен нормальный расчет нагрузки: оценка CPU и RAM на пользователя, понимание, где живут профили и кэш, и проверка гипотез тестами до закупок.

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

Собираем вводные: кто и как будет работать

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

Сначала определите реальное число одновременных сессий. Важно не «сколько сотрудников в компании», а сколько людей будут в RDS одновременно и когда именно. Часто пик приходится на 9:30-11:30 и 14:00-16:00, плюс отдельные всплески в конце месяца у бухгалтерии.

Дальше разделите пользователей на группы по поведению, а не по должностям. «Офисный» пользователь с почтой и 3-5 вкладками в браузере и пользователь, который открывает тяжелую учетную систему, могут отличаться по нагрузке в разы. Отдельно отметьте тех, кто:

• работает в браузерных системах с большим количеством вкладок;
• использует толстые клиенты (учет, ERP, СЭД) и часто печатает;
• запускает тяжелые приложения (CAD, аналитика, отчеты);
• проводит много времени в видеосвязи или часто воспроизводит видео.

Не забудьте про нагрузки, которые обычно «не считают», но они съедают ресурсы ежедневно: антивирус со сканированием, шифрование, агенты инвентаризации, резервного копирования, DLP, мониторинг. Уточните, что обязательно должно быть установлено в сессии, а что можно вынести на уровень образа или настроить через исключения.

Еще один важный блок - требования к отказоустойчивости. Один сервер проще и дешевле, но любой простой сразу останавливает работу. Ферма (несколько RDSH, брокер, профили, файловые сервисы) дороже, зато дает гибкость и план обслуживания без остановки.

Наконец, зафиксируйте ограничения: бюджет на серверы и СХД, сроки закупки, лицензии (Windows, RDS CAL), требования к локальному производству и поддержке. Например, в госсекторе Казахстана это часто влияет на выбор платформы и поставщика, а значит и на то, насколько быстро получится масштабироваться.

С чего начать: базовые замеры до расчетов

Перед тем как считать ядра и гигабайты, важно понять простую вещь: сколько ресурсов реально ест одна сессия именно у вас. Одинаковые «пользователи RDS» на бумаге могут вести себя по-разному из-за версии Windows, набора приложений, антивируса, политик, драйверов печати и даже качества сети.

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

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

• CPU: загрузка и длина очереди процессора;
• память: свободная память и активное потребление на сессию;
• диск: средняя длина очереди диска и задержки чтения/записи;
• сеть: входящий/исходящий трафик и потери/ошибки;
• отклик: насколько быстро реагирует интерфейс (по ощущениям пользователей и косвенным метрикам).

Метрики снимайте в рабочий день и обязательно в пик. Средние значения часто обманывают: «в среднем 40% CPU» может скрывать короткие пики до 95%, из-за которых пользователи видят зависания и ожидания. Поэтому кроме среднего фиксируйте перцентили (например, 95-й) - он лучше показывает, что происходит в худшие моменты.

Чтобы замеры были полезными, закрепите «эталон» окружения и не меняйте его по ходу:

• версия ОС и уровень обновлений;
• образ (gold image) и набор установленных приложений;
• GPO/политики безопасности, перенаправление папок;
• настройки профилей (локальные, контейнеры, перенаправление);
• антивирус и правила исключений.

Простой пример: бухгалтерия запускает 1С, почту и пару вкладок в браузере. «Средняя» сессия легкая, но в 10:00 все одновременно формируют отчеты и печатают. Если не поймать этот пик, расчет получится оптимистичным, а после запуска появятся очереди и долгий вход.

Методика оценки CPU: как прикинуть ядра на пользователя

CPU в RDS редко загружается ровно. Важно отличать среднюю загрузку (что видите большую часть дня) от пиков (что происходит в моменты логина, запуска 1С/браузера, открытия тяжелых отчетов). Для планирования ориентируйтесь на пик, иначе очереди появятся именно тогда, когда всем нужно работать.

Практическая схема проста: сначала измеряем, потом масштабируем.

Шаг 1: пилотная группа и замер «на живых»

Выберите пилот: 10-20 типичных пользователей с реальными задачами и теми же приложениями, что будут в проде. В течение 2-3 рабочих дней снимайте метрики на RDS-хосте и отмечайте события: начало смены, массовый логин, запуск ключевого приложения, печать.

Признаки того, что вы упираетесь именно в CPU (а не в диск или сеть), обычно такие:

• растет Processor Queue Length и держится не секунды, а минуты;
• время отклика приложений растет, хотя RAM еще есть;
• во время массовых логинов CPU скачет к 90-100% и не отпускает;
• задержки усиливаются при запуске новых сессий.

Дальше считайте «ядра на пользователя» по пику: возьмите пиковую загрузку CPU сервера в процентах и разделите на число активных сессий в этот момент. Например: 16 vCPU, пик 80%, активных сессий 40. Получается 16 * 0,8 / 40 = 0,32 vCPU на сессию. Для 120 сессий это уже около 38 vCPU. Сверху добавьте 15-25% запаса на рост и непредвиденные нагрузки.

Шаг 2: учитываем всплески и выбираем масштабирование

Всплески при логине и старте приложений часто важнее «ровного» дня. Если по пилоту видно, что пики короткие, но резкие, помогает не только добавление ядер, но и распределение пользователей.

Горизонтальное масштабирование (больше узлов) обычно лучше, если есть частые пики, нужна отказоустойчивость или приложения «съедают» ядро на сессию. Вертикальное (больше CPU на узел) уместно, когда управление проще на одном сервере и нагрузка достаточно ровная. В проектах системной интеграции, вроде тех, что делает GSE.kz, этот выбор обычно подтверждают пилотом и требованиями к простоям.

Методика оценки RAM: база, на сессию и запас

Нехватка RAM в RDS часто маскируется под проблему диска: пользователи жалуются, что все «ждет», а в мониторинге видно рост очередей на диске. На деле система начинает активно выгружать данные в файл подкачки, и даже быстрые SSD превращаются в узкое место из-за постоянных мелких операций.

Память съедают не только приложения в сессиях. Часть уходит на саму ОС, кэш файлов и обновлений, драйверы, службы печати, браузерные движки, а также агенты безопасности (EDR/антивирус), инвентаризацию и мониторинг. Эти «тихие потребители» особенно заметны после обновлений или при включении новых политик.

Рабочая методика такая: сначала фиксируйте «базу», затем добавляйте «на сессию» и проверяйте в пике.

• Замерьте потребление RAM сразу после загрузки и прогрева служб (база).
• Подключите 5-10 тестовых пользователей и посмотрите, сколько добавилось (на сессию).
• Умножьте «на сессию» на плановое число одновременных сессий и прибавьте базу.
• Проверьте результат нагрузочным тестом в сценарии «час пик».
• Оставьте запас под рост, обновления и тяжелые дни.

Запас лучше держать заметным: чтобы в пике не упираться в подкачку и не ловить цепочку задержек. Если планируете расширять набор ПО или знаете, что браузер и мессенджеры будут «разрастаться», запас нужен больше.

Признаки давления по памяти обычно очевидны: частые обращения к файлу подкачки, рост задержек при переключении между окнами, долгий вход в сеанс, внезапные вылеты приложений и подвисания при открытии документов. Если это повторяется, RAM уже не хватает, даже если CPU еще выглядит «в норме».

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

Очереди в RDS часто начинаются не в CPU, а в момент входа. При логине сервер читает профиль пользователя: ветки реестра (NTUSER), настройки приложений, кэши, ярлыки, файлы в AppData. Если профиль лежит на медленном хранилище или забит мелкими файлами, десятки одновременных входов превращаются в «шторм», и люди ждут рабочий стол.

По хранению профилей есть три базовых подхода.

Локально на каждом терминальном сервере вход обычно быстрый, но сложнее переносить пользователей при балансировке и отказах. На файловом сервере проще управлять, но растет зависимость от сети и дисков на стороне файлового хранилища. Третий вариант - контейнеры профилей (профиль в файле-контейнере, который подключается при входе). Часто он дает более предсказуемое время входа, потому что уменьшается «россыпь» мелких файлов по сети.

Для дисков важны не только гигабайты, а скорость реакции. В планировании стоит учитывать IOPS, среднюю задержку чтения и записи, длину очереди диска и реальную скорость на небольших блоках. Профиль на 300-800 МБ может грузиться долго не из-за объема, а из-за тысяч мелких объектов.

Отдельная боль - антивирус. Он любит проверять каждый маленький файл в профиле, и логин резко замедляется. Это особенно заметно утром: в 09:00 одновременно заходит 120 сотрудников, и файловый сервер получает всплеск операций чтения и записи.

Что обычно помогает снизить риск «шторма входов»:

• уменьшить профиль: чистка кэшей, перенос тяжелых данных из профиля, ограничение ненужных папок;
• настроить исключения антивируса для типовых путей профиля и контейнеров (по согласованию с ИБ);
• разнести массовые входы по времени: смены, автозапуск задач после логина с задержкой;
• держать профили и пользовательские данные отдельно, чтобы рабочий стол поднимался быстрее;
• проверять хранилище тестом на мелких файлах, а не только «скоростью в мегабайтах».

Если закупаете железо под RDS, полезно заранее проговорить с интегратором, где будут жить профили и какой ожидается пик одновременных входов. В проектах GSE.kz это обычно один из ключевых пунктов, потому что от него зависят и комфорт пользователей, и требования к дискам и сети.

Сопутствующие нагрузки: печать, браузер, видео и сеть

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

Печать и сканирование иногда забирают больше ресурсов, чем ожидается. Очередь печати растет, когда драйверы разные, принтеров много, а задания тяжелые (PDF, картинки, отчеты). Бывает, что проблема даже не в CPU, а в зависании драйвера в сессии: у пользователя подвисает «все», хотя приложение легкое. Если печати много, заранее договоритесь о стандартных драйверах и вынесите печать в отдельный сервер печати, чтобы сбои и очереди не били по терминальным узлам.

Браузер и видеосвязь легко поднимают CPU без «тяжелых программ». Один пользователь с десятком вкладок, веб-почтой и CRM иногда потребляет больше, чем учетная система. Видеозвонок в браузере часто дает всплески процессора на кодирование и декодирование, особенно при демонстрации экрана.

Нужна ли GPU

GPU обычно не нужна для офисных задач и «тонких» приложений. Но без нее сложно, если пользователи массово работают с 3D, картографией, тяжелыми дашбордами, частыми видеоконференциями или графическими редакторами. Практическое правило: если уже на тестах видно, что CPU держится на 80-100% из-за графики и видео, имеет смысл рассмотреть узлы с GPU или хотя бы проверить настройки аппаратного ускорения в приложениях.

Сеть между RDS и инфраструктурой важнее, чем «сколько гигабит». Для профилей и домашней папки критична задержка: лишние десятки миллисекунд могут превратить вход в систему в ожидание. То же относится к связи с файловым сервером, сервером профилей и хранилищем виртуальных машин.

Периферия и перенаправления

Перенаправление USB, смарт-карт, сканеров и аудио часто дает «странные» лаги, которые трудно связать с нагрузкой CPU/RAM. Проверьте заранее, что именно разрешено перенаправлять и где будет точка контроля.

Коротко, что стоит уточнить до масштабирования:

• сколько принтеров и какие драйверы, есть ли тяжелая печать PDF/изображений;
• сколько пользователей одновременно в браузере и сколько вкладок типично;
• есть ли постоянные видеозвонки и демонстрация экрана;
• где лежат профили и файлы, и какая задержка до хранилища;
• какие устройства будут перенаправляться в сессию и нужны ли исключения.

Если собираете RDS на новых узлах, полезно сразу заложить отдельные роли (например, печать отдельно от терминальных серверов) и проверить сетевые задержки до файловых сервисов. Для проектов в госсекторе и крупных организациях в Казахстане такие детали лучше проговаривать до закупок: позже они обходятся дороже, чем дополнительные ядра или память.

Тесты перед масштабированием: что прогнать до закупок

Перед тем как докупать железо или добавлять новые хосты, стоит провести короткий, но честный пилот. Он лучше любых формул показывает, где узкое место: CPU, RAM, диски, сеть или профили. Это особенно важно, если расчет делаете «впритык» и хотите избежать очередей на вход и зависаний в приложениях.

Соберите план теста так, чтобы он напоминал реальный день. Выберите пилотную группу (например, 10-20% пользователей) и контрольную (с тем же набором задач, но в обычном режиме). Затем увеличивайте число одновременных сессий ступенчато: 25%, 50%, 75%, 100% от плановой нагрузки, удерживая каждый уровень хотя бы 30-60 минут. Отдельно сделайте «утренний пик» - массовый логин за 10-15 минут.

Во время теста фиксируйте не только загрузку ресурсов, но и ощущение пользователя. Минимальный набор метрик:

• время входа в систему (до готовности рабочего стола);
• запуск ключевых приложений (первый старт и повторный);
• задержка ввода (печать в Word/1С, отклик меню);
• число зависаний, обрывов сессий и ошибок профиля;
• очередь диска и задержки чтения/записи на хранилище.

Чтобы имитировать работу, не ограничивайтесь «покликать мышкой». Используйте сценарии: открыть почту, 3-5 вкладок в браузере, документ, печать в PDF, работа в учетной системе, копирование файлов. Хороший признак - когда тестировщики выполняют обычные задачи по чеклисту, а не стараются «сломать» систему.

Профили и диск тестируйте отдельно. Например, прогоните 30-50 последовательных входов/выходов с очисткой кэша, затем массовый логин. Если время входа скачет, а на диске растут очереди, проблема чаще в хранении профилей и мелких файлах, а не в CPU.

Готовность к масштабированию удобнее оценивать по порогам. Красные флаги такие:

• вход дольше 60-90 секунд в пиковые моменты;
• заметная задержка ввода и подвисания при открытии меню;
• частые ошибки профиля или «временный профиль»;
• стабильные очереди диска и рост задержек при тех же действиях.

Если тест показывает упор в железо, дальше уже проще обсуждать конфигурацию: добавить хосты, вынести профили на отдельное хранилище или пересобрать роли. На практике такие пилоты часто делают на типовом сервере класса rack, чтобы заранее увидеть поведение под реальными сессиями и не гадать на закупке.

Мониторинг после запуска: признаки приближающегося перегруза

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

Ежедневно полезно смотреть одни и те же метрики в разрезе пиковых часов (утро, после обеда, конец дня):

• CPU и очередь процессора (если CPU не всегда 100%, но очередь растет, узлу уже тяжело);
• память (давление по памяти, активное использование, рост paging);
• диск и задержки I/O (особенно там, где лежат профили и временные файлы);
• логины: время входа и число ошибок входа (включая сбои профиля);
• плотность сессий: активные и отключенные сессии, их рост по дням.

Разовую проблему отличает след: один всплеск после обновления, сбойного драйвера печати или сетевого инцидента, а на следующий день все возвращается к норме. Системную проблему видно по тренду: каждую неделю в пиковые часы графики поднимаются выше, а «норма» становится хуже. Это часто случается, когда бизнес постепенно добавляет пользователей или приложения, а расчет делался под старый сценарий.

Пора добавлять узел или ресурсы, если в пике CPU держится высоким и очередь не опускается, если задержки диска стабильно растут, или если среднее время входа ухудшается неделю за неделей. Договоритесь с бизнесом о понятных SLA: например, «вход не дольше N секунд» и «отклик приложений без подвисаний при типовой операции».

Для разбора инцидентов заранее включите логирование событий входа, загрузки профиля, сбоев приложений и важных служб. Тогда вместо споров «у нас все нормально» будут факты: когда началось, у скольких пользователей и в какой момент инфраструктура уперлась в предел.

Типовые ошибки в расчетах RDS и как их избежать

Самая частая причина очередей в RDS проста: расчет делали по «средней температуре по больнице». В итоге система выглядит спокойной, пока не наступает час пик, массовый вход пользователей или запуск тяжелых задач.

Ошибки, которые чаще всего приводят к перегрузу

Ниже - типовые промахи и что делать вместо этого.

• Смотрят на среднюю загрузку CPU (например, 30%) и успокаиваются. Правильнее ориентироваться на пики по 95-99 перцентилю и на длину очереди процессора: если в пике CPU упирается в 90-100% даже на короткое время, пользователи это почувствуют как «все зависло».
• Сажают на один узел «всех подряд»: бухгалтерию, колл-центр, инженеров с тяжелыми приложениями. Разведите разные профили нагрузки по коллекциям или узлам и задайте лимиты (CPU/RAM) для самых прожорливых сценариев.
• Планируют ресурсы «как сейчас», но забывают про рост: обновления Windows и Office, антивирус, EDR-агенты, новые политики, браузерные плагины. Закладывайте запас и проверяйте изменения после каждого крупного апдейта на тестовом узле.
• Держат профили на медленном хранилище или на перегруженном файловом сервере. Это дает долгий вход и «черный экран» после логина. Проверяйте IOPS и задержки, разносите профили и общие папки, следите за количеством мелких файлов и антивирусным сканированием.
• Делают тест на 5 пользователях и умножают на 100. Так не работает: растет конкуренция за диск и сеть, появляются блокировки файлов, очереди печати. Нужен тест хотя бы на 20-30% реальной нагрузки и с похожими сценариями.

Пример: 200 операторов работают в браузере и CRM, но в понедельник с 9:00 все заходят почти одновременно. Если мерили только «в среднем за день», то пропустите узкое место в момент логина: профили, GPO, антивирус и диск.

Как не ошибиться в практике

Полезно заранее договориться о метриках успеха и замерять не только количество сессий, но и активность:

• время входа в сеанс и время появления рабочего стола;
• пиковая CPU/RAM по узлу и по процессам;
• задержки диска и пиковые IOPS (особенно на профилях);
• сетевые пики (обновления, печать, файловые операции).

Если эти цифры стабильны в пике и в сценариях «массовый вход» и «тяжелая задача», вероятность очередей после масштабирования заметно ниже.

Короткий чеклист и следующие шаги

Когда кажется, что вы уже все посчитали, именно мелочи чаще всего превращаются в очереди: лишние 2-3 секунды на вход в профиль, внезапная печать в конце смены или один «тяжелый» пользователь, который забирает CPU у всех.

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

• пользователи и пики: сколько одновременных сессий в среднем и в максимуме, какие приложения у каждой группы, есть ли сезонные всплески;
• CPU и RAM: оценка на сессию, проверка по пиковым часам, плюс запас на рост и фоновые службы (антивирус, обновления, агенты);
• профили и хранение: где лежат профили, сколько весят, как быстро открываются (важны задержки, а не только объем диска);
• диски и задержки: хватает ли производительности для профилей и временных файлов, нет ли просадок во время логина;
• план тестов: какие сценарии прогоняете и по каким цифрам решаете «проходит/не проходит» (время входа, отклик приложений, стабильность в пике).

Если этот список закрыт, расчет становится заметно точнее, а результаты проще защитить перед бизнесом.

Следующие шаги

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

• сделайте пилот на 1-2 узлах и наберите реальных пользователей (или максимально похожую нагрузку);
• зафиксируйте критерии успеха: например, вход в систему до N секунд, отсутствие подвисаний в типовом приложении, запас по CPU/RAM в пике;
• по итогам пилота уточните лимиты на пользователя и пересчитайте емкость фермы;
• масштабируйте постепенно, добавляя узлы и повторяя тесты на пиковых окнах.

Если нужна помощь с подбором серверов и внедрением RDS, имеет смысл привлекать интегратора, который закрывает и «железо», и проектную часть. GSE.kz как производитель и системный интегратор в Казахстане обычно подключается на этапе пилота: помогает выбрать конфигурации, спланировать хранение профилей и дальше сопровождать инфраструктуру в эксплуатации (в том числе 24/7).