Расчет ресурсов для VDI/RDS: CPU, RAM и IOPS на пользователя

Какая проблема решается и где чаще всего «упирается» VDI/RDS

VDI/RDS чаще тормозит не потому, что «мало железа вообще», а потому что в нужный момент заканчивается один конкретный ресурс. Поэтому полезнее считать потребление на одного пользователя и его профиль, а уже потом умножать на одновременность и добавлять запас. Это помогает избежать ситуации, когда CPU загружен на 40%, а люди жалуются на лаги из-за диска или сети.

Одинаковое число пользователей дает разную нагрузку. 50 сотрудников в офисных приложениях и 50 сотрудников, которые весь день держат десятки вкладок, тяжелые порталы и видеозвонки, потребляют разное количество CPU, RAM и дисковых операций. В RDS (терминальный сервер) пользователи делят одну ОС, и пики чаще «склеиваются». В VDI у каждого своя виртуальная машина, поэтому базовые требования к памяти и диску обычно выше.

На практике узкое место почти всегда находится в одном из четырех слоев: CPU (не хватает вычислений в пиковые секунды), RAM (начинается своп и все становится «вязким»), диск (растет задержка, логины и профили открываются мучительно долго) или сеть (в среднем «вроде хватает», но качество плохое из-за задержки, потерь или Wi‑Fi).

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

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

Базовые допущения: VDI vs RDS и что считать пользователем

VDI и RDS часто пытаются считать одинаково, но это разные модели.

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

Заранее решите, какие рабочие места будут: постоянные (persistent) или непостоянные (non-persistent). Persistent ближе к «обычному ПК»: профили и программы копятся, растет фон на диске и объем хранения. Non-persistent проще обслуживать и обновлять, но он чувствителен к пиковым событиям вроде массового входа утром и требует аккуратной работы с профилями.

Отдельно заложите накладные расходы от защитных и управленческих агентов: антивирус, шифрование, DLP, EDR, инвентаризация, а также регулярные обновления. Они добавляют CPU, RAM и особенно дисковые операции. Если эти компоненты обязательны, учитывайте их как постоянную надбавку, а обновления и плановые сканы - как отдельные пики.

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

Ключевой параметр - коэффициент одновременности: какая доля всех учетных записей реально активна одновременно. Например, в организации 300 сотрудников, но в пике активно 180. Коэффициент одновременности 0,6. Обычно именно от этого числа считают CPU, RAM и IOPS, а не от «всех по списку».

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

Типовые профили пользователей: офис и тяжелые веб-приложения

Расчет начинается не с железа, а с понятного описания того, как люди реально работают. Не пытайтесь сразу угадать vCPU и IOPS. Сначала зафиксируйте 2-3 профиля и привяжите их к измеримым привычкам.

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

Профиль «тяжелый веб» внешне похож, но ведет себя иначе: 20-60 вкладок, CRM/ERP, BI-дашборды, постоянные обновления страниц, расширения браузера, плюс видеозвонки. Здесь чаще страдают пики (рендеринг, кодеки, графики) и задержка диска при активных профилях.

Дизайн и инженерные приложения (CAD/3D, визуализация) не смешивайте с офисом в одном «среднем профиле». Часто нужен GPU, больше видеопамяти и другие требования к задержкам и сети. Такой профиль лучше считать отдельно и подтверждать пилотом.

Чтобы описать профиль, обычно хватает нескольких параметров: сколько вкладок и насколько «тяжелые» страницы (CRM, BI, карты), как часто идет работа с файлами (открытие, сохранение, автосейв), есть ли печать и сканирование, как часто бывают видеозвонки и в какие часы происходят пики.

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

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

CPU: как оценить vCPU на пользователя без гаданий

В VDI/RDS удобнее мыслить vCPU и реальной загрузкой процессора на хосте. Один vCPU - это доля вычислительного времени физических ядер. Задача не в том, чтобы угадать «сколько ядер купить», а в том, чтобы понять потребность на одновременных активных пользователей и держать запас на пики.

Средний процент CPU часто обманчив. Сессия может «в среднем» потреблять 10%, но при открытии тяжелой вкладки, запуске Teams или рендеринге страницы на 5-10 секунд подпрыгивает до 80-100%. Именно такие всплески ломают отклик: курсор дергается, звук заикается, интерфейс «липнет». Поэтому ориентируйтесь на 95-й процентиль нагрузки и ощущаемый отклик, а не на красивую среднюю цифру.

Для старта можно опираться на простые ориентиры и затем подтверждать их замерами:

• Офис (почта, документы, 5-10 вкладок, мессенджер): 1-2 vCPU на пользователя.
• Тяжелый веб (CRM/BI в браузере, много вкладок, видеоконференции): 2-4 vCPU на пользователя.

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

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

Мини-пример: 60 офисных пользователей в RDS. Стартовая оценка - 1,5 vCPU на пользователя, то есть 90 vCPU суммарно. Если планируете 2 хоста, распределяйте так, чтобы на каждом оставался запас около 20% под пики и фон, иначе утренний наплыв сессий сорвет отклик даже при «нормальной средней загрузке».

RAM: сколько памяти нужно и как не уйти в своп

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

Офисный профиль обычно упирается в браузер и фоновые агенты: вкладки, мессенджер, почта, антивирус, DLP/EDR, клиент печати, синхронизация. «Тяжелые» веб-приложения добавляют прожорливые вкладки (порталы с большим JS), кэш, рендеринг, иногда встроенные видеоконференции. В RDS память сильнее зависит от того, насколько одинаковые приложения у всех (общие библиотеки помогают), а в VDI каждая ВМ «несет» свою ОС и службы.

Когда хост или ВМ начинают активно использовать pagefile/swap, нагрузка переезжает на хранилище. Это почти всегда приводит к росту IOPS и задержки диска, а дальше по цепочке страдают логины, открытие профилей и запуск приложений. В итоге проблема выглядит как «медленный диск», хотя корень - недооцененная RAM.

Практичный подход - считать память слоями и сразу закладывать запас: базу ОС и служебных процессов, надбавку на профиль (приложения и браузерный сценарий), надбавку на агентов безопасности, а затем 15-25% запаса на рост нагрузки и фоновые события.

Ориентир по профилям: офисный пользователь с 8-12 вкладками, почтой и мессенджером часто стабильно занимает 2-3 ГБ, а «тяжелый веб» с частыми видеозвонками - 4-6 ГБ. Проверьте это на пилоте и считайте по 95-му процентилю, чтобы не уходить в своп в обычный день.

Диск: расчет IOPS и защита от логон-шторма

IOPS - это операции чтения/записи в секунду, но для VDI/RDS чаще важнее задержка (latency). Если задержка растет, сессии начинают «подвисать», даже когда IOPS по отчетам выглядят «нормально».

Дисковая нагрузка почти никогда не ровная. Есть steady-state (обычная работа днем) и есть короткие бурсты: массовый вход утром, обновления, сканирование антивирусом, пересборка кэшей. Если хранилище рассчитано только на средние значения, логон-шторм быстро упрется в очередь диска.

Основные источники записи - профили пользователей, TEMP, кэш браузера, почтовые клиенты, журналы, плюс фоновые процессы (антивирус, индексатор). В «тяжелом вебе» добавляются большие кэши и частые мелкие записи.

Для грубой прикидки можно взять такие диапазоны:

• Офис: 5-15 IOPS на пользователя в steady-state и 30-60 IOPS в пике при входе.
• Тяжелый веб: 10-25 IOPS в steady-state и 50-100 IOPS в пике.

Дальше умножайте на одновременность. Например, 200 офисных пользователей при 10 IOPS дадут около 2000 IOPS днем, но если 60 человек логинятся за 5-10 минут, нужен запас под пик и, главное, низкая задержка.

Что почти всегда помогает против логон-шторма: разделять системный диск ВМ и пользовательские профили (включая FSLogix), чтобы они не дрались за один и тот же ресурс, а также ограничивать рост кэшей и TEMP и выносить обновления и сканы из пиковых часов.

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

Сеть: сколько Мбит/с нужно и как не получить «тормоза»

В VDI/RDS сеть редко «заканчивается» по средней полосе. Проблема почти всегда в пиках, задержке или потерях. Поэтому в расчет закладывайте не только Мбит/с на пользователя, но и качество канала.

Трафик протокола отображения (часто RDP) зависит от того, что происходит на экране и какие устройства вы пробрасываете. Один и тот же офисный пользователь может потреблять около 0,3 Мбит/с в спокойной работе и 3-6 Мбит/с во время созвона с видео.

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

Для грубой оценки: офисный профиль часто укладывается в 0,5-1,5 Мбит/с на пользователя, «тяжелый веб» - в 1,5-4 Мбит/с, а пользователям с частыми созвонами разумно закладывать 3-6 Мбит/с.

Считайте канал по пику, а не по среднему: возьмите долю активных одновременно (например, 60-70%) и добавьте запас 20-30% на всплески. И отдельно проверьте задержку и потери. Обычно комфортнее держать RTT до 30-50 мс и потери ниже 0,5%.

Если «тормоза» появляются из-за чужого трафика, помогает сегментация и приоритизация: пользовательские сессии отдельно, управление и мониторинг отдельно, трафик хранилища отдельно (без конкуренции с RDP), резервное копирование по расписанию и с лимитами.

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

Рабочая схема выглядит так:

1. Опишите 2-4 профиля (например: офис, тяжелые веб-приложения, 1С/ERP, дизайн) и задайте коэффициент одновременности. Часто это 50-80% от общего числа учетных записей.

2. Заранее определите, что значит «нормально работает»: время входа, отклик приложений, допустимая задержка диска и сети. Это ваш внутренний SLA.

3. Для каждого профиля прикиньте потребление на пользователя: vCPU, RAM, IOPS (и отдельно пики при входе), а также средний и пиковый трафик.

4. Переведите «на пользователя» в «на хост/кластер»: умножьте на одновременность, добавьте накладные расходы платформы (гипервизор, брокер, антивирус, мониторинг), затем проверьте, что узкие места сходятся по мощности.

5. Добавьте запас: рост нагрузки (например, +20-30%), отказ узла (N+1), обслуживание (патчи, перезагрузка) и отдельный запас на утренний логон-шторм.

Короткий пример: есть 120 офисных пользователей и 30 пользователей «тяжелого веб», одновременность 70%. Ресурсы вы считаете на 105 активных сессий, а не на 150, и дальше складываете нагрузку по профилям. CPU и RAM растут почти линейно, а диск и сеть часто дают резкие пики в определенные часы.

Финальный шаг, без которого расчеты остаются теорией, - пилот. Запустите 10-20% от целевой нагрузки, включите сбор метрик по CPU, RAM, IOPS, задержкам диска и сети и посмотрите, что именно уходит в «красную зону». После пилота цифры почти всегда корректируют, особенно по диску и времени входа.

Пример расчета на реальных числах: смешанный офис + тяжелый веб

Сценарий: 120 пользователей, из них 80 офисных (почта, документы, 10-20 вкладок) и 40 с тяжелыми веб-приложениями (много вкладок, видеоконференции, BI в браузере).

CPU и RAM: считаем с учетом пиков и запаса

Возьмем простые нормы на пользователя (для старта, затем подтвердите пилотом):

• Офис: 0,3 vCPU в среднем и 0,6 vCPU в пик; RAM 1,8 ГБ.
• Тяжелый веб: 0,6 vCPU в среднем и 1,2 vCPU в пик; RAM 3,5 ГБ.

CPU в пик: 80 x 0,6 + 40 x 1,2 = 48 + 48 = 96 vCPU. Добавляем запас 20% на всплески и фоновые процессы: 96 x 1,2 = 115 vCPU.

RAM: 80 x 1,8 + 40 x 3,5 = 144 + 140 = 284 ГБ. Плюс 15% на ОС/службы/кэш: около 327 ГБ. На практике это означает, что кластер стоит проектировать так, чтобы после отказа одного узла оставался запас по памяти.

IOPS и сеть: обычный час и массовый вход

Диск в рабочее время (условно): офис 5 IOPS, тяжелый веб 10 IOPS. Итого: 80 x 5 + 40 x 10 = 800 IOPS.

Логон-шторм (первые 5-15 минут) часто в 5-10 раз тяжелее. Если принять 50 IOPS на офисного и 80 IOPS на тяжелого: 80 x 50 + 40 x 80 = 7200 IOPS. Здесь решает не только число IOPS, но и задержка: если latency растет, пользователи видят «подвисания» даже при нормальном CPU.

Сеть: для удаленного доступа прикинем среднее потребление 0,2 Мбит/с на офисного и 0,4 Мбит/с на тяжелого: 80 x 0,2 + 40 x 0,4 = 32 Мбит/с. Для пика умножьте на 3 и добавьте 30% на накладные расходы: около 125-130 Мбит/с. Для филиала это часто означает канал 150-200 Мбит/с с приоритетом для VDI/RDS-трафика.

Чтобы понять, что масштабировать дальше, отталкивайтесь от симптомов:

• CPU 80-90% в пик при нормальной задержке диска: добавляйте вычисления или выносите тяжелые роли в отдельный пул.
• RAM близко к пределу и появляется своп: добавляйте память, чистите автозапуск и фоновые агенты.
• Высокая задержка диска на логоне: усиливайте SSD-слой, пересматривайте профили и разносите I/O по пулам.
• Жалобы только из филиала при норме в ЦОД: ищите проблему в сети, QoS и стабильности канала.

Частые ошибки при планировании VDI/RDS

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

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

Еще часто недооценивают поведение при массовом входе. Логон-шторм - это не только запуск сессий, но и одновременное чтение профилей, применение политик, старт фоновых агентов, проверка обновлений и сканирование. Диск получает короткий, но очень жесткий удар по IOPS и задержке.

К чему это обычно приводит: одинаковые ресурсы всем без разделения на профили, планирование по «средним» без проверки пиков и без запаса на рост, раздувшиеся профили и перенаправленные папки, перегруз отдельных хостов из-за неверного распределения сессий, отсутствие контроля latency диска и качества сети.

Небольшой пример: в 09:00 одновременно заходят 80 сотрудников. Если в это время обновляются антивирусные базы и стартует сканирование, профили раздулись до нескольких гигабайт, а хранение профилей устроено без учета пиков, то даже быстрые по CPU хосты начнут «стоять» из-за диска. Пользователь видит это как долгий вход, зависания браузера и задержки в приложениях.

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

Перед тем как закупать оборудование или расширять кластер, пройдите короткую проверку:

• CPU: есть ли запас на пики и фоновые задачи (антивирус, индексирование, обновления).
• RAM: хватает ли памяти без ухода в своп в самый загруженный час.
• Диск: измеряете ли вы не только IOPS, но и задержку (latency) под реальной нагрузкой.
• Сеть: проверяете ли полосу и RTT до пользователей, особенно из филиалов и через VPN.
• Пики: отдельно ли считаете массовый вход утром, обновления и отчетные периоды.

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

Дальше проверьте отказоустойчивость. Минимум, который часто спасает проект, - N+1: даже при отказе одного хоста пользователи продолжают работу с приемлемой скоростью. Отдельно продумайте обслуживание без простоя: обновления гипервизора, патчи, замена дисков, тестирование бэкапов.

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

Следующий практичный шаг - пилот на 10-20 пользователей с теми же политиками, профилями и приложениями, что будут в проде. За 1-2 недели вы увидите логон-шторм, пиковые IOPS, типичную задержку диска и поведение сети, и дальше сможете масштабироваться по проверенным метрикам.

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