VDI: что это и какой сервер нужен для виртуальных рабочих столов

Что такое VDI простыми словами

VDI (Virtual Desktop Infrastructure) — инфраструктура виртуальных рабочих столов, в которой пользователь работает с настольной операционной системой в виртуальной машине на сервере. Клиентское устройство передаёт ввод и получает изображение; приложения и данные обрабатываются в центре обработки данных, если конкретное приложение не использует локальную разгрузку. Поэтому производительность зависит одновременно от серверного хоста, хранилища, сети, протокола и устройства сотрудника.

Один физический сервер может обслуживать много таких ВМ, но сам сервер ещё не образует готовый VDI-комплекс. Нужны гипервизор, механизм назначения рабочих столов, управление образами, пользовательскими данными и доступом. В архитектуре Horizon брокер назначает ресурс, а агент внутри гостевой ОС обеспечивает подключение. Состав ролей и поддерживаемые сочетания версий определяются выбранной платформой, а не количеством установленных процессоров.

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

VDI или терминальный сервер RDS: сравнение по задачам

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

При этом RDS — название инфраструктуры Microsoft, которая поддерживает и сессионные рабочие столы, и коллекции виртуальных рабочих машин. Поэтому противопоставление «VDI против всего RDS» неточно. Здесь под терминальным сервером понимается RD Session Host с многопользовательскими сессиями. В облачных продуктах терминология также отличается: например, pooled-пул Azure Virtual Desktop может размещать несколько пользователей на одном session host.

Для одинаковых офисных приложений сначала проверяют возможность общей сессионной среды. Отдельные ВМ рассматривают, когда нужны клиентская ОС, более самостоятельные настройки или раздельные окружения. Это не гарантирует совместимость любого ПО: ограничения установки, виртуализации и доступа проверяют у правообладателя приложения. Подробный аппаратный расчёт общей сессионной среды разобран в статье о терминальном сервере для RDS и 1С.

Постоянные и непостоянные рабочие столы

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

Непостоянные рабочие столы выдаются из пула и могут пересоздаваться или возвращаться к принятому состоянию. Пользовательские документы и настройки, которые должны пережить такое пересоздание, выносят в предусмотренный проектом механизм профилей и хранения данных. До внедрения проверяют не только запуск программы, но и сохранение её настроек после выхода, переподключения и замены ВМ.

Пул не устраняет нагрузку на инфраструктуру. В документации Omnissa отдельно рассматриваются операции подготовки и замены instant-clone-десктопов. Если многие сотрудники заканчивают смену одновременно, создание замен может совпасть со следующим массовым входом. Предварительно подготовленные свободные рабочие столы помогают обслужить спрос, но их количество и скорость пополнения проверяют в пилоте. Конкретная технология клонирования может существенно изменить характер нагрузки, поэтому её нельзя рассчитывать как обычную полную копию диска без проверки.

Расчёт хоста: ВМ на ядро, память и оверкоммит

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

Универсального коэффициента «столько-то ВМ на ядро» для VDI нет. vCPU — выделенный гостевой системе виртуальный процессор; он не равен гарантированно свободному физическому ядру. Оверкоммит позволяет назначить суммарно больше виртуальных ресурсов, чем одновременно доступно физически, но при совпадении активности появляется конкуренция. Начальную конфигурацию выбирают по документации ОС и приложений, а допустимую плотность устанавливают по отклику и метрикам гипервизора.

Память считают отдельно: рабочий объём для всех одновременно активных ВМ плюс расходы гипервизора, служебных ВМ и предусмотренный резерв. Умножение объёма одной ВМ на количество рабочих столов даёт лишь часть бюджета. Возможные механизмы разделения или возврата памяти зависят от платформы и настроек; экономию от них нельзя заранее считать гарантированной. Если система вынуждена постоянно обращаться к диску из-за нехватки памяти, быстрые SSD не превращают такой режим в полноценную замену RAM.

Практический порядок таков: задать профиль ВМ, измерить его под нагрузкой, увеличить число одновременно работающих ВМ и найти ограничивающий ресурс. После этого повторить проверку с резервом на обслуживание и отказ. Методику общего учёта ресурсов дополняет расчёт числа ВМ на сервере; эта статья уточняет его для рабочих столов, а не заменяет.

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

Хранилище: массовый вход, SSD и кэш

Хранилище проверяют как минимум в установившемся режиме и при массовом начале работы. Запуск гостевых ОС, загрузка профилей, старт приложений и фоновые операции могут совпадать. Такой пик часто называют «штормом загрузки», но нагрузка при создании клонов зависит от технологии платформы. Нельзя автоматически переносить результаты полной загрузки независимых ВМ на instant clones или наоборот.

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

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

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

GPU для VDI: когда он нужен

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

Нужно заранее определить способ предоставления GPU гостевой системе и проверить поддерживаемое сочетание сервера, гипервизора, карты, драйвера и VDI-платформы. Объём видеопамяти на профиль, доступность функций и права использования зависят от выбранного решения. Цифры из документации одного продукта нельзя переносить на другой способ виртуализации. Пилот должен использовать именно требуемую графическую программу и реальные файлы, а не только демонстрационное окно.

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

Сеть и отказоустойчивость кластера

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

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

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

Ошибки внедрения и что передать для подбора

Типичные ошибки — считать всех зарегистрированных пользователей одновременно активными или, наоборот, игнорировать утренний пик; оценивать CPU без RAM и хранилища; переносить таблицу плотности из другого приложения; смешивать постоянные и непостоянные рабочие столы; не проверять периферию и сохранение профиля. Ещё одна ошибка — принять поддерживаемый гипервизор за готовую платформу управления рабочими столами. Разделение этих задач помогает сравнить роли и критерии выбора гипервизоров.

Для подбора подготовьте группы пользователей, число одновременных подключений, приложения и их версии, требования к клиентской ОС, экранам и периферии. Добавьте решение о постоянстве рабочих столов, размещении профилей и данных, допустимом времени входа и восстановления. Укажите выбранную VDI-платформу или ограничения её выбора, доступные сети и площадки, а также результаты пилотных замеров. Неизмеренные параметры следует так и обозначить: это исходные данные следующего испытания, а не нулевые потребности.

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

Частые вопросы

Источники и границы расчёта

Архитектура и операции пулов: Omnissa Horizon 8 architecture. Модели сессионных и виртуальных рабочих столов: Microsoft Remote Desktop Services. Параметры оценки нагрузки: Microsoft: sizing session hosts. Различия облачных пулов: терминология Azure Virtual Desktop. Таблицы Azure не выданы за норму плотности локального физического сервера.