Когда ИТ-архитектор выбирает платформу VDI (Virtual Desktop Infrastracture), он обычно опирается на три документа — матрица совместимости, тесты производительности и коммерческое предложение. Четвертый документ — финансовая модель на три года — остаётся за скобками обсуждения. Между тем именно архитектура протокола определяет, сколько пользователей поместится на один хост, какую долю CPU и GPU съест конвейер кодеков и во что обойдётся инфраструктура в пересчёте на рабочее место. В этой статье рассмотрим влияние выбора протокола удаленного доступа на стоимость владения и приобретения инфраструктур VDI на примере западных решений, при этом выводы в той же, если не большей, мере относятся к российским VDI и ВКС.
Кодеки, CPU и плотность: где сгорают циклы
Полнокадровое кодирование H.264 — это простой и предсказуемый процесс, потому что каждый пиксель экрана проходит через один и тот же кодек. Если сессия на 80% состоит из статического текста и на 20% из видео, полнокадровый кодировщик тратит вычислительные ресурсы на сжатие текстовых областей так же интенсивно, как на движение. Это не оптимизация, а равномерное распределение нагрузки там, где его можно избежать.
Технология удалённого отображения Citrix Thinwire использует многокодековое кодирование в одном кадре. Так классификатор содержимого определяет текстовые области, видео и зоны высокой интенсивности движения, после чего к статике применяется MDRLE (без потерь, минимальный битрейт), а к движущимся фрагментам — H.264 или H.265. Классификатор добавляет циклы CPU, но стоимость этой классификации существенно ниже стоимости кодирования, сэкономленной за счёт отказа от H.264 на статике. Для типичного «продвинутого» сотрудника, использующего документы, браузер, таблицы, потребление CPU в Thinwire заметно ниже, чем при полнокадровом H.264 без vGPU.
Это имеет прямое следствие для плотности пользователей на хост. Плотность ограничена не только ядрами, но и тем, сколько циклов CPU остаётся после вычета нагрузки на кодирование. Протокол, который тратит меньше циклов на сессию, позволяет разместить больше сессий на том же физическом сервере. А плотность — это и есть основная единица стоимости в VDI, потому что чем больше пользователей на хост, тем ниже CAPEX и OPEX на рабочее место.
Клиентский оффлоад: когда видеокарта пользователя работает на экономику
Перенос части обработки изображения на клиентское устройство не является благотворительностью со стороны вендора. Это перекладывание вычислительной нагрузки с хоста, за который платит заказчик, на конечную точку, за циклы которой он обычно не платит.
Механизм HDX Graphics Superresolution Upscaling, появившийся в CVAD 2603, работает именно так. Агент виртуального рабочего стола VDA (Virtual Delivery Agent) идентифицирует видео и области высокой интенсивности движения, применяет дополнительное сжатие с понижением эффективного разрешения перед кодированием. Вычислительная стоимость H.264/H.265 масштабируется линейно от числа пикселей. Уменьшение размеров (разрешения) на 50% снижает вычислительную стоимость кодирования этой области примерно на 75%. Реконструкция до исходного разрешения выполняется на совместимом графическом процессоре конечной точки. Нагрузка на VDA снижается, нагрузка на клиент растёт, но клиент уже есть у пользователя.
Второй эффект — это пропускная способность. Снижение битрейта видеофрагментов на
Superresolution против редиректа
Здесь необходима оговорка, которую вендоры редко добавляют в презентациях. Superresolution Upscaling — это не замена Multimedia Redirection (перенаправление воспроизведения медиа с ВМ на клиент) и Browser Content Redirection. Это инструмент для сценариев, где редирект неприменим по архитектурным причинам, так как контент не имеет доступного клиенту кодека или URL, DRM-защита блокирует перенаправление, а приложение использует проприетарный рендеринг, не поддающийся перехвату.
Если редирект возможен, он даёт больший эффект. При Multimedia Redirection сервер не декодирует и не кодирует контент вообще, он передаёт сжатый поток клиенту для локального декодирования и рендеринга. CPU VDA не тратится ни на декодирование, ни на повторное кодирование. Superresolution Upscaling в этом смысле — компромисс, так как сервер всё равно кодирует, только с меньшим разрешением. Он полезен там, где редирект не работает, но не должен рассматриваться как его замена.
Сценарии, где Superresolution имеет смысл, это — спутниковые каналы с ограниченной полосой, SD-WAN с оплатой за трафик, 4K-сессии на каналах, которые ранее тянули только 1080p. Сценарии, где редирект эффективнее, — это корпоративные медиапорталы, обучающие видео, веб-конференции с известными источниками контента.
ВКС и экономика VDI: скрытая статья расходов
Оптимизация ВКС в VDI важна не только с точки зрения качества связи для пользователя. Плохо оптимизированный ВКС-клиент в виртуальной сессии может потреблять ресурсы хоста совершенно непропорционально количеству пользователей. Декодирование видео, эхо-подавление, микширование аудио — всё это выполняется на стороне агента виртуального рабочего стола VDA, то есть на хосте VDI, если не задействован оптимизированный медиа-путь.
Интеграция SlimCore (New Teams) в Citrix HDX — это пример архитектурного решения, которое влияет на плотность. Когда медиапоток ВКС обрабатывается через оптимизированный виртуальный канал с оффлоадом кодеков на клиент или специализированный медиа-движок, нагрузка на хост снижается. Когда ВКС работает как обычное приложение внутри сессии, каждый звонок создает дополнительную нагрузку на CPU и сеть. Для организации с сотнями пользователей, проводящих в звонках по два-три часа в день, разница в плотности между оптимизированным и неоптимизированным ВКС может измеряться десятками сессий на хост.
Это та самая статья, которую FinOps, модель финансового управления ИТ-затратами, часто упускает. Стоимость ВКС определяется не в лицензиях, а в том, сколько хостов необходимо докупить из-за неоптимизированной обработки медиапотока.
Компромиссы выбора платформы
Архитектурная асимметрия между платформами — это не повод для принципиальных споров, а основа для модели затрат.
Citrix HDX/EDT остаётся эталоном для WAN-развёртываний с постоянно превышающим 50 мс временем отклика в обоих направлениях, для графически интенсивных рабочих мест (САПР, настольные издательские системы, финансовые торговые платформы с высокой плотностью отображения) и для сценариев, где Superresolution Upscaling даёт прямую экономию на полосе пропускания.
Механизм контроля перегрузки на основе задержек и многокодековый рендеринг — это не маркетинговые термины, а факторы, напрямую влияющие на плотность и стоимость канала.
Omnissa Blast является рациональным выбором для организаций с глубокими инвестициями в vSphere/NSX и локальными пользователями, где задержка WAN не является основным ограничением. Blast поддерживает H.264 4:4:4, HEVC 4:4:4, AV1 и оффлоад на vGPU, но не имеет многокодекового рендеринга по областям кадра и механизма оффлоада масштабирования на клиент. Любое улучшение визуального качества требует пропорционально большего объёма серверных ресурсов — линейное масштабирование затрат, которого в Citrix структурно нет.
Microsoft RDP архитектурно устарел для задач, выходящих за пределы локальных сетей с простыми рабочими нагрузками. Отсутствие H.265, AV1, контроля перегрузки на основе задержки и приоритизации виртуальных каналов — это не случайность, а следствие фокуса Microsoft на Azure Virtual Desktop. RDP приемлем для небольших локальных развёртываний, но не должен рассматриваться как основа для распределённой инфраструктуры.
Parallels RAS превосходит базовый RDP за счёт управления QoS в XTCP и дифференциального кэша на клиенте, но потолок ограничен кодеками RDP. Для малых и средних предприятий с локальным подключением и приоритетом простоты эксплуатации это работающий инструмент, а для корпоративного VDI в WAN — нет.
Вывод для архитекторов
Протокол — это не только пользовательский опыт. Это множитель, который определяет, сколько вы платите за каждый цикл CPU, за каждый мегабит пропускной способности и за каждого пользователя, которого можно посадить на существующий хост. Важно помнить, что модель затрат, которая игнорирует архитектуру протокола, оптимизируя лицензии, забывает и про серверы, и про пользовательский опыт.
При выборе платформы VDI архитектору стоит оценивать протокол по трём измеримым величинам — стоимости кодирования на сессию, стоимости доставки бита по реальному каналу и предельной плотности пользователей на хост. Эти три величины складываются в ту самую статью бюджета, которая остаётся за скобками матриц совместимости. И именно они, а не число установленных устройств, определяют, во что инфраструктура обойдётся через три года.
