Сервер под VDI: как рассчитать CPU, RAM, GPU и диски на 10, 50 и 100 пользователей

Сервер под VDI рассчитывают не по общему числу сотрудников, а по числу одновременных пользователей, типу их задач и пиковым нагрузкам. Для 10 офисных пользователей часто достаточно одного сервера с запасом по процессору, памяти и быстрыми SSD/NVMe-дисками, при этом если это пользователи "тяжёлых" CAD-систем ситуация может в корне поменяться. Для 50 обычных офисных пользователей уже важно отдельно считать профили, хранение и отказоустойчивость. Для 100 пользователей обычно лучше рассматривать не один максимально мощный сервер, а несколько узлов, чтобы инфраструктура переживала обслуживание, рост нагрузки и отказ одного сервера.

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

Из-за этого VDI нельзя считать как обычный файловый сервер или сервер под одну бизнес-систему. Здесь важно не только «сколько ядер и гигабайт памяти», но и насколько быстро открываются приложения, сколько пользователей входит в систему утром, как ведет себя браузер с десятками вкладок, есть ли видеосвязь, сканеры, USB-ключи, электронная подпись, CAD или 3D-графика.

Отдельно стоит отметить, что VDI - это не про оптимизацию прямых расходов, общее внедрение часто довольно чувствительно в бюджете. Помимо расходов на сервер, необходимо учесть и стоимость лицензий на ПО, включая "гостевые" операционные системы, гипервизоры и системы оркестраций. Но мы сосредоточимся в рамках этого материала сугубо на аппаратной части.

Чем VDI отличается от обычной виртуализации

В обычной серверной виртуализации нагрузка часто предсказуемее: база данных, веб-сервер, почта, система учета. У VDI нагрузка ближе к поведению живых людей. Пользователь может 20 минут читать документ, а потом одновременно открыть браузер, таблицу, мессенджер, видеозвонок и тяжелый PDF. Если таких пользователей десятки, кратковременные всплески становятся общей нагрузкой на весь сервер.

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

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

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

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

Фраза «нам нужен VDI на 50 человек» почти ничего не говорит о сервере. Пятьдесят бухгалтеров, пятьдесят операторов склада, пятьдесят разработчиков и пятьдесят инженеров-конструкторов — это совершенно разные инфраструктуры с разными требованиями.

Обычно пользователей делят хотя бы на несколько профилей.

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

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

Пользователь с видеосвязью добавляет еще один слой нагрузки. Видеозвонки, демонстрация экрана, камера, гарнитура и мессенджеры требуют не только ресурсов сервера, но и правильной мультимедийной оптимизации. Иногда проблема возникает не на сервере, а на слабом тонком клиенте, плохом Wi-Fi или неоптимальном маршруте трафика.

Пользователь с периферией может быть легким по CPU и RAM, но сложным по внедрению. Принтеры, сканеры, USB-ключи, смарт-карты, электронная подпись, кассовое, складское или медицинское оборудование нужно проверять заранее. Не каждое устройство стабильно работает через удаленный рабочий стол.

Графический пользователь работает с CAD, 2D/3D-моделями, визуализацией, инженерными расчетами, видео или графическими редакторами. Здесь важны процессор, память, видеокарта, объем видеопамяти на пользователя и совместимость приложения с виртуализацией графики.

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

Одновременность важнее общего числа сотрудников

Если в компании 100 сотрудников, это не всегда значит, что одновременно работают 100 виртуальных рабочих столов. Но считать слишком оптимистично тоже опасно. В бухгалтерии перед отчетным периодом, в колл-центре, службе поддержки, инженерном отделе или офисе с единым рабочим графиком одновременность может быть близка к 100%.

Для расчета используют простую логику:

расчетное число пользователей = общее число пользователей × коэффициент одновременности + запас.

Для 10 пользователей обычно считают всех 10. Экономия на коэффициенте здесь почти не дает выигрыша, зато может быстро привести к нехватке ресурсов. Для 50 пользователей можно считать 40–50 активных, если часть сотрудников работает нерегулярно, но при обычном офисном графике лучше закладывать почти всех. Для 100 пользователей без точной статистики безопаснее считать 80–100 активных, а затем уточнять расчет по данным пилота.

Отдельно нужно учитывать входы в систему. Утром пользователь не просто «сидит за рабочим столом». Он входит в систему, получает профиль, запускает приложения, открывает браузер, подключает сетевые диски, запускает мессенджер, иногда сразу открывает видеозвонок. Если 50 человек делают это в течение 10–15 минут, нагрузка на CPU, диски, профильное хранилище, сеть, контроллеры домена и антивирус может оказаться намного выше, чем в середине рабочего дня, особенно с использованием временных виртуальных машин, которые создаются и запускаются при входе.

Как считать процессор

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

При расчете нужно различать физические ядра, потоки и виртуальные процессоры. Виртуальной машине можно выдать несколько vCPU, но это не означает, что на сервере должно быть столько же физических ядер, сколько vCPU суммарно у всех рабочих столов. В офисных сценариях допустима умеренная переподписка, потому что пользователи редко нагружают процессор одновременно на 100%. Но для тяжелых браузерных приложений, CAD, видеомонтажа, 3D и инженерных задач слишком плотная переподписка быстро приводит к задержкам.

Для предварительной оценки можно использовать такую схему:

нужные физические ядра = расчетные пользователи × процессорная нагрузка профиля ÷ целевая загрузка CPU.

Целевую загрузку не стоит планировать как 100%. Если сервер в обычном режиме уже держится у потолка, любой пик — вход утром, обновление, антивирусная проверка, отчет в браузерной системе — будет заметен пользователям. Для VDI лучше оставлять запас, чтобы короткие всплески не превращались в постоянные жалобы.

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

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

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

Как считать оперативную память

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

Расчет памяти можно делать по формуле:

RAM = память рабочих столов + память служебных машин + память гипервизора + запас 15–30%.

Для 10 пользователей запас лучше делать ближе к верхней границе, потому что маленькая инфраструктура хуже переносит ошибки расчета. Для 50 и 100 пользователей запас тоже нужен, но его можно распределять между узлами и уточнять после пилота.

Для офисного профиля стартовый ориентир — 4–6 ГБ на рабочий стол. Для активной работы в браузере — 6–8 ГБ. Для офисной работы с видеосвязью — 8–12 ГБ. Для легкой графики — 12–16 ГБ. Для CAD и 3D — от 16 ГБ и выше, иногда 32–64 ГБ на пользователя, если речь идет о больших моделях и тяжелых проектах.

Опасно рассчитывать на агрессивное перераспределение памяти. В VDI пользователи чувствительны к задержкам, а экономия на RAM часто заканчивается тем, что дорогие процессоры и быстрые диски не спасают систему от подвисаний. Лучше заложить больше памяти на старте, чем потом переносить рабочие столы, менять модули и объяснять пользователям, почему новая инфраструктура работает хуже локальных ПК.

Как считать диски: объем, операции и задержки

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

Здесь нужно считать три параметра.

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

   емкость = системные диски + профили + пользовательские данные + служебные машины + снимки + резерв 20–30%.

2. Количество операций ввода-вывода. В VDI много мелких операций чтения и записи. Поэтому простая скорость «мегабайт в секунду» не описывает картину полностью. Система может читать и писать небольшие блоки, обращаться к профилям, обновлять кэш, запускать приложения и одновременно обслуживать десятки пользователей.
3. Задержка. Для виртуального рабочего стола важна не только пропускная способность, но и то, насколько быстро хранилище отвечает на запрос. Если профильное хранилище перегружено или находится за медленной сетью, пользователь будет видеть задержки даже при неплохих процессорах и большом объеме памяти.

HDD не стоит использовать как основное хранилище для активных рабочих столов. Их можно оставить под архивы, резервные копии или холодные данные, но не под повседневную VDI-нагрузку. Для небольшой установки подойдут корпоративные SSD. Для 50–100 пользователей лучше смотреть в сторону NVMe или архитектуры, где есть быстрый уровень хранения под активные рабочие столы и профили. Microsoft выделяет диски виртуальных машин, пользовательские профили и приложения как разные области проектирования, а также связывает выбор хранилища с производительностью и пользовательским опытом.

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

Когда нужен GPU

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

Но есть сценарии, где GPU становится важным. Это CAD, 3D-моделирование, инженерные приложения, визуализация, обработка видео, графические редакторы, большие разрешения экранов, несколько мониторов, а иногда и насыщенные браузерные интерфейсы. Видеосвязь тоже может выигрывать от графического ускорения, но здесь результат зависит от платформы, клиента, настроек и того, как именно обрабатывается мультимедиа.

При расчете GPU нельзя смотреть только на название видеокарты. Важны поддержка виртуализации, совместимость с гипервизором, лицензирование, драйверы, профили разделения и объем видеопамяти на пользователя. Если видеокарту можно разделить между несколькими рабочими столами, это не значит, что ее можно делить бесконечно. Чем больше видеопамяти нужно каждому пользователю, тем меньше пользователей "поместится" на одну карту.

Для легкой 2D-графики и нескольких мониторов может хватить небольшого профиля или даже процессора. Но для CAD и 3D нужна обязательная проверка на реальных проектах. Для тяжелой инженерной графики иногда выгоднее выделить отдельные GPU-серверы для инженерного отдела, а не смешивать такие рабочие места с офисными пользователями на тех же узлах. NVIDIA в методике подбора виртуальных графических рабочих станций также предлагает начинать с профиля пользователя, приложения, требований к графике и видеопамяти, а затем проверять плотность пользователей тестированием.

Важно помнить: видеокарта не отменяет потребность в CPU, RAM и быстрых дисках. Если приложению не хватает процессорной частоты или памяти, установка GPU не сделает рабочий стол быстрым сама по себе.

Пример расчета для 10 пользователей

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

Для офисного сценария разумно закладывать 16–24 физических ядра суммарно, 128–256 ГБ RAM, корпоративные SSD или NVMe, RAID или другую схему защиты данных, отдельное место под профили и резерв. GPU обычно не нужен. Если рабочие столы непостоянные, нужно продумать, где будут храниться пользовательские профили и как быстро они будут подключаться при входе.

Для 10 пользователей с активным браузером, видеозвонками и мессенджерами лучше сразу увеличить запас по памяти. Минимальные 4 ГБ на рабочий стол могут оказаться слишком скромными, если пользователь держит открытыми корпоративный портал, CRM, почту, таблицы и видеоконференцию. Здесь лучше ориентироваться на 8–12 ГБ на пользователя и обязательно проверить качество видеосвязи.

Для 10 CAD-пользователей конфигурация меняется принципиально. Это уже не «малый офисный VDI», а графическая среда. Нужны GPU, больше памяти, быстрые диски и пилот на реальных проектах. Нельзя считать таких пользователей по тем же коэффициентам, что и сотрудников с почтой и документами. Один инженер с тяжелой моделью может потреблять больше ресурсов, чем несколько офисных пользователей.

Пример расчета для 50 пользователей

Для 50 пользователей уже нельзя ограничиться усредненной фразой «по 2 vCPU и 8 ГБ RAM каждому». Нужно понять состав нагрузки.

Допустим, в компании 30 офисных сотрудников, 15 пользователей активно работают в браузерных системах, а 5 сотрудников используют графические приложения. Для первых 30 важны стабильная работа документов, почты и печати. Для 15 браузерных пользователей — память, процессорные всплески и скорость открытия веб-страниц. Для 5 графических пользователей — отдельный расчет GPU, видеопамяти, CPU и RAM.

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

По памяти смешанный сценарий часто приводит к диапазону 512 ГБ — 1 ТБ RAM суммарно, в зависимости от профилей. По процессору важны не только ядра, но и частота, запас под пики и распределение пользователей между узлами. По дискам лучше использовать SSD/NVMe, отдельно оценивать профили и не размещать все активные компоненты на медленном общем хранилище.

Если среди 50 пользователей есть CAD-группа, ее лучше считать отдельно. Пять инженеров могут потребовать отдельную GPU-карту или даже отдельный серверный узел, тогда как остальные 45 пользователей останутся на обычных VDI-хостах.

Пример расчета для 100 пользователей

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

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

Для 100 пользователей с браузерными системами, видеосвязью и мессенджерами запас должен быть выше. Браузерные приложения часто создают нагрузку на CPU и RAM, видеосвязь добавляет требования к сети и мультимедиа, а профильное хранилище становится критичным. Сеть 1 Гбит/с в серверной части для такой инфраструктуры обычно уже выглядит слабым местом. Как минимум стоит рассматривать 10GbE, а при быстром хранилище, нескольких узлах и активных профилях — 25GbE.

Если среди 100 пользователей есть CAD/3D-группа, ее нужно выделить как отдельный класс нагрузки. Например, 80 офисных и браузерных пользователей могут обслуживаться на обычных VDI-узлах, а 20 инженеров — на GPU-узлах с отдельным расчетом видеопамяти и приложений. Смешивать всех в одной плотной модели опасно: офисные пользователи будут страдать от тяжелых графических задач, а инженеры — от нехватки предсказуемых ресурсов.

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

Периферия может стать главным ограничением

При расчете VDI часто обсуждают процессоры, память и диски, но забывают о периферии. В результате сервер работает нормально, а проект тормозит из-за сканеров, USB-ключей, камер, принтеров или электронной подписи.

Перед внедрением нужно проверить, какие устройства нужны пользователям. Работают ли они по сети или только через USB. Нужны ли драйверы внутри виртуального рабочего стола. Как устройство ведет себя при переподключении сессии. Есть ли задержки при сканировании. Поддерживает ли выбранная VDI-платформа проброс именно этого типа устройства.

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

Смарт-карты, USB-токены и электронная подпись требуют отдельной проверки. В некоторых сценариях лучше использовать сетевые устройства или специализированные решения, чем пытаться пробрасывать локальный USB напрямую в виртуальный рабочий стол.

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

Сеть и задержки

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

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

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

В серверной части для серьезной VDI-инфраструктуры 10GbE стоит рассматривать как минимально разумный уровень. Для 50–100 пользователей, быстрого NVMe-хранилища, активных профилей и нескольких узлов может быть оправдан переход на 25GbE. Особенно если рабочие столы, профили и пользовательские данные активно обмениваются данными по сети.

Отказоустойчивость и обслуживание

Расчет «один сервер на всех» может быть приемлемым для 10 пользователей, если бизнес готов к простою и есть понятный план восстановления. Для 50 пользователей это уже риск. Для 100 пользователей один сервер почти всегда выглядит слабым архитектурным решением, даже если его ресурсов хватает на бумаге.

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

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

Для 100 пользователей лучше сразу считать сценарий отказа одного узла. Например, если есть три VDI-сервера, нужно понять, сколько пользователей сможет работать при потере одного из них. Возможно, не все 100, но хотя бы критичные отделы должны сохранить доступ.

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

Типовые ошибки при расчете VDI

• Считать всех пользователей одинаковыми. В таблице они выглядят как «50 рабочих мест», но в реальности часть сотрудников работает только с почтой, часть постоянно держит открытой CRM, часть участвует в видеозвонках, а несколько человек запускают тяжелые инженерные приложения.
• Ориентироваться только на vCPU. Количество виртуальных процессоров в настройках рабочих столов не равно реальной производительности. Важно смотреть на физические ядра, частоту, переподписку, пики и поведение приложений.
• Экономить на памяти. Нехватка RAM быстро превращается в дисковую нагрузку, а пользователь видит это как общее замедление рабочего стола.
• Использовать медленные HDD под активные рабочие столы. Для VDI важны мелкие операции и задержки, поэтому дисковая подсистема должна быть быстрой и предсказуемой.
• Забывать про профили пользователей. Если системные диски быстрые, а профили лежат на перегруженном файловом ресурсе, входы и запуск приложений все равно будут медленными.
• Не учитывать утренние входы. Сервер может нормально работать днем, но плохо переживать первые 15 минут рабочего дня.
• Считать, что GPU решит все проблемы производительности. Он помогает в графических задачах, но не заменяет процессор, память и быстрые диски.
• Не проверять периферию. Сканеры, принтеры, USB-ключи, камеры и электронная подпись могут оказаться сложнее, чем расчет CPU.
• Покупать один большой сервер без плана отказоустойчивости. На бумаге это может быть дешевле, но в реальной эксплуатации такой сервер становится точкой отказа.
• Не проводить пилот. VDI зависит от реального поведения пользователей, поэтому расчет без теста всегда остается предположением.
• Считать, что использование VDI удешевит расходы на инфраструктуру, потому что не надо покупать мощные компьютеры. Чаще из-за стоимости оборудования и лицензий VDI увеличивает расходы, но повышает удобство управления и доступность.

Как проверить расчет перед покупкой

Перед закупкой сервера нужно провести инвентаризацию. Сколько пользователей работает одновременно. Какие приложения они запускают. Сколько вкладок браузера обычно открыто. Есть ли видеозвонки. Используются ли CAD, 3D, графика, большие таблицы, тяжелые PDF, сканеры, принтеры, USB-токены, электронная подпись.

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

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

Следующий шаг — пилот. Лучше проверить 5–10 типовых пользователей, чем сразу переносить весь офис. В пилоте нужно смотреть не только среднюю загрузку сервера, но и входы утром, запуск приложений, открытие браузера, видеосвязь, печать, сканирование, работу USB и электронную подпись.

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

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

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

Какой сервер выбрать под VDI на 10, 50 и 100 пользователей

Для 10 офисных пользователей обычно достаточно одного сервера с запасом: 16–24 физических ядра, 128–256 ГБ RAM, корпоративные SSD или NVMe, резервирование дисков, отдельное место под профили и нормальное резервное копирование. Если есть видеосвязь и активный браузер, лучше увеличить память и проверить мультимедиа. Если есть CAD, нужен отдельный расчет GPU.

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

Для 100 пользователей лучше проектировать инфраструктуру из нескольких узлов. Важно не только выдержать обычную нагрузку, но и переживать обслуживание, рост и отказ одного сервера. Офисный сценарий может обойтись без GPU, но потребует надежного хранения и сети. Смешанный сценарий с браузерами и видео требует большего запаса. CAD/3D-группу лучше выносить на отдельные GPU-узлы или хотя бы считать отдельно от офисных пользователей.

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