«Bridging the gap»© между российскими ВКС и VDI
Виртуализация должна была упростить пользовательский опыт в больших и гео‑распределенных компаниях и снять нагрузку с ИТ‑служб. Но на практике оказалось, что перенос рабочего места в дата‑центр решает одни проблемы и одновременно создаёт новые. Почему?
Когда начался «бум» российского VDI в 2022 году, звучали фразы «мы полностью заменяем Citrix, мы сделали 80–90% функционала VMware» и тому подобное. Понадобилось время, чтобы вендоры VDI получили доказательства, что функционал замещения Citrix\VMWare (особенно протоколов удаленного доступа) считается по типам приложений, которые можно виртуализовать так, чтобы опыт работы пользователей был аналогичным или мало отличался от работы тех же приложений на ПК.
VDI (Virtual Desktop Infrastructure) отлично справляется с офисными приложениями, неплохо живёт с web‑сценариями и требует особого подхода к CAD‑ и мультимедийным нагрузкам. Но самый парадоксальный эффект проявляется в ВКС.
Мы решили разобраться, почему разные классы приложений по‑разному «чувствуют» VDI, где возникает системная деградация производительности, почему видеосвязь требует особых подходов к оптимизации, без которых цифровое рабочее место остаётся только наполовину виртуальным, какие есть российские ВКС и что делать их поставщикам в текущей ситуации, чтобы не ломался UX.
Как появились VDI и терминальные серверы
Технологии виртуализации приложений выросли из вполне практических задач, с которыми крупные компании столкнулись ещё в конце 1990-х. Когда IBM и Microsoft развивали свои корпоративные платформы, стало очевидно: управлять тысячами отдельных рабочих станций силами ИТ‑служб становится слишком дорого и сложно.
Любое обновление ПО требовало физического доступа к машине. Каждая проблема безопасности и выхода новой версии ПО запускала новый цикл обновлений. Данные компании хранились на локальных дисках и постоянно создавали риски утечек или потери вместе с устройством. На этом фоне идея централизованного рабочего окружения выглядела всё более логичной.
При этом сама концепция не была новой даже для 90-х годов. Идея выделенной вычислительной среды для каждого пользователя и удалённого доступа к ней появилась ещё во времена мейнфреймов. По сути, VDI стал развитием этой модели уже на новом уровне производительности и сетевой инфраструктуры.
К началу 2000-х технология всё ещё не была готова к массовому внедрению: не хватало производительности, пропускной способности сетей и зрелости гипервизоров. Ситуация изменилась в середине‑концу десятилетия, когда Citrix и VMware представили первые коммерческую VDI‑платформы. ПО Citrix XenDesktop быстро стал одним из отраслевых стандартов. Начиная с 2010 года, VDI активно распространяется и сегодня уже является неотъемлемой частью современной корпоративной ИТ‑инфраструктуры.
Преимущества виртуализации по сравнению с классической desktop‑моделью были очевидны.
Во‑первых, централизованное управление. Администраторы получили возможность обновлять, устанавливать и удалять ПО сразу для всех пользователей, а не обновлять рабочие станции пусть и централизованно, но все‑таки по отдельности.
Во‑вторых, безопасность. Критичные данные перестали храниться на локальных устройствах, которые можно потерять, украсть или скомпрометировать.
В‑третьих, экономика эксплуатации. Несмотря на высокую стоимость внедрения, через несколько лет VDI‑инфраструктура часто выходила на сопоставимый TCO с парком ПК, а затем начинала снижать затраты на поддержку и обслуживание.
Наконец, гибкость доступа. Пользователь мог безопасно подключиться к своему рабочему окружению практически с любого устройства и из любой точки мира, сохраняя привычную конфигурацию рабочего стола и приложений.
Почему браузер, CAD и ВКС требуют разного подхода в VDI‑инфраструктуре
Когда компании начали массово внедрять VDI, быстро выяснилось, что далеко не все приложения одинаково хорошо работают в виртуальной среде, и тип нагрузки имеет принципиальное значение.
Офисные приложения (текстовые редакторы, электронные таблицы, таск‑трекеры и корпоративные порталы) создают относительно низкую и предсказуемую нагрузку. Это умеренное потребление памяти, минимальная загрузка CPU и работа с небольшими объёмами данных. В стабильной VDI‑среде плотность может достигать 120–200 пользователей на один физический сервер. Такие приложения практически идеально подходят для виртуализации и редко становятся источником проблем с производительностью.
Совсем иначе ведут себя мультимедийные приложения: видеоплееры, аудиоредакторы, инструменты для создания контента, различные системы вебинаров. Они постоянно работают с потоковыми данными, активно используют кодеки и критичны к задержкам кодирования и декодирования. Для нормальной работы им часто требуется GPU‑ускорение.
Web‑приложения тоже оказались не такими простыми, как ожидалось. Современный браузер с десятками вкладок, расширениями и облачными сервисами создаёт нестабильную и трудно прогнозируемую нагрузку. Особенно болезненны утечки памяти и плохая оптимизация браузеров в VDI‑среде: потребление RAM на пользователя резко растёт, начинается paging, а вместе с ним — высокая нагрузка на подсистему ввода‑вывода.
Отдельная категория — CAD/CAM‑системы вроде Компас 3D, AutoCAD, SolidWorks или Siemens NX. Это уже один из самых тяжёлых типов офисного ПО для VDI‑инфраструктуры. Такие приложения критичны к производительности графического конвейера: вращение моделей, масштабирование и навигация в 3D должны происходить без задержек. Здесь обязательны GPU‑vGPU решения уровня NVIDIA GRID, большие объёмы RAM на каждую ВМ, отсутствие переподписки по vCPU и высокая частота процессоров. Дополнительно требуется аппаратное ускорение декодирования VDI‑протокола на стороне клиента.
Но самый сложный сценарий — это ВКС.
Видеоконференцсвязь одновременно работает с несколькими видеопотоками, кодирует и декодирует видео в реальном времени, обрабатывает аудио с минимальными задержками и при этом должна оставаться устойчивой к фризам, потере пакетов и артефактам. Дополнительно ВКС создаёт серьёзную нагрузку на канал связи и активно использует клиентскую камеру.
Во время видеоконференций сервер виртуализации фактически вынужден в режиме разделения времени обрабатывать десятки или сотни видеопотоков одновременно, распределяя CPU и другие ресурсы между множеством виртуальных машин.
При этом ВКС внутри виртуальной машины часто не видит реальных сетевых условий и фактически доступных аппаратных ресурсов. VDI‑клиент может находиться за узким каналом связи, а сам ВКС‑клиент — внутри дата‑центра с высокой пропускной способностью. В результате приложение принимает неверные решения по адаптации видеопотока и кодеков.
Как при виртуализации «лоб» ломается UX
Долгое время многие компании пытались виртуализировать приложения максимально прямолинейно. Они брали ПО, рассчитанное на локальный ПК с полным доступом к ресурсам, и просто запускали его внутри ВМ без какой‑либо адаптации. Результат обычно был предсказуемым: система начинала работать заметно медленнее, чем на физической рабочей станции.
Первая проблема — конкуренция за ресурсы. Даже если каждой ВМ выделено достаточно CPU и памяти, десятки или сотни виртуальных машин на одном сервере неизбежно начинают влиять друг на друга. Классический пример — «синдром шумного соседа»: одна ВМ внезапно запускает антивирусное сканирование или индексирование диска, после чего задержки начинают испытывать все остальные.
Вторая проблема — собственно overhead виртуализации. Гипервизор сам потребляет ресурсы и добавляет дополнительные слои абстракции. Любое обращение к памяти, диску или сети в VDI‑среде неизбежно проходит через дополнительные уровни обработки. Полностью избавиться от этих задержек невозможно.
Третья проблема — протоколы доставки изображения: PCoIP, HDX, RDP, SPICE и другие. Любое действие пользователя превращается в длинную цепочку:
клик → передача события на сервер → обработка → обновление экрана → кодирование изображения → передача обратно → декодирование на клиенте → отображение.
Каждый этап добавляет задержку. По отдельности это миллисекунды, но суммарно пользователь начинает ощущать систему «тяжёлой» и медленной.
Почему ВКС требует отдельной оптимизации в VDI
Для ВКС эти проблемы становятся критичными. Видеоконференции требуют одновременной обработки видео, аудио и сетевого трафика в реальном времени. Если ВКС просто запускается внутри VDI без специализированной оптимизации, появляются типовые проблемы.
Рост задержек
Поток с камеры проходит длинную цепочку:
камера клиента → кодирование → передача в ВМ → обработка сервером → передача другим участникам → декодирование → отображение.
Каждый этап увеличивает задержку. Если в обычной среде задержка составляет 80–120 мс, то в VDI без оптимизации она может вырастать до 300–500 мс. В результате это выливается не только в некомфортное общение по технической причине, но и в то, что пользователи начинают перебивать друг друга из‑за задержек обратной связи.
Рассинхронизация аудио и видео
Нередко звук и видео начинают идти раздельно: пользователь уже договорил фразу, а движение губ отображается с задержкой в секунду или больше. Обычно это связано с тем, что аудио‑ и видеопотоки передаются раздельно и проходят через разные механизмы обработки внутри VDI, либо ВМ просто не успевает синхронно обрабатывать оба потока.
Артефакты и потери пакетов
ВКС и без того агрессивно сжимает видео, пытаясь уложиться в доступную полосу пропускания. Но в VDI поверх этого добавляется ещё и сжатие самого VDI‑протокола. Потери пакетов начинают накапливаться на нескольких уровнях сразу, и изображение быстро деградирует: появляются блоки, фризы и «рассыпание» картинки.
Проблемы с кодеками и CPU
Многие отечественные ВКС‑системы используют собственные реализации кодеков, рассчитанные на нестабильные каналы связи и специфические условия эксплуатации. Часто такие реализации слабо используют аппаратные возможности CPU, GPU и камер.
Если подобное приложение запускается в VDI без адаптации, нагрузка на процессоры серверов виртуализации резко возрастает. А поскольку на одном физическом CPU одновременно работают десятки ВМ с ВКС, эффект «шумного соседа» начинает масштабироваться многократно.
Кроме того механизмы адаптации к качественным мгновенным характеристикам сети, встроенные в отечественные ВКС, могут конфликтовать с механизмами оптимизации самого VDI‑протокола. В итоге обе системы пытаются одновременно управлять буферизацией, восстановлением пакетов и адаптацией bitrate — и только ухудшают пользовательский опыт.
Оптимизация VDI‑приложений: где начинается стабильный UХ
Оптимизация виртуальных приложений — это необходимое требование, без которого невозможно получить ожидаемый ROI (return on investment) от вложений в VDI‑инфраструктуру и обеспечить стабильный пользовательский опыт. Основной подход к оптимизации в VDI заключается в корректном распределении нагрузки между виртуальной машиной и клиентским устройством.
Почему не требуется оптимизация офисных приложений
Офисные приложения в VDI работают достаточно стабильно даже без специальной оптимизации. Это связано с их изначально низким потреблением ресурсов и хорошо предсказуемым характером нагрузки, который естественным образом ложится на модель виртуализации.
Даже при «чистом» запуске в VDI производительность остаётся приемлемой: пользователь не ощущает существенной разницы между работой в Microsoft Word, Excel или аналогичных инструментах в виртуальной среде и на локальном ПК.
Оптимизация мультимедийных приложений
Мультимедийные приложения требуют более сложного подхода, и здесь оптимизация строится вокруг нескольких механизмов.
Аппаратное ускорение — ключевой элемент. Вместо CPU‑обработки кодирования и декодирования видео используется GPU (NVENC/NVDEC в случае NVIDIA). Это снижает нагрузку на процессор в 10–15 раз и существенно ускоряет обработку видеопотоков. При этом важно учитывать ограничения: GPU‑инфраструктура дорогая, а доступ к лицензиям и технологиям NVIDIA в ряде сценариев может быть затруднён.
Multimedia redirection и поддержка VDI‑протоколов — второй важный механизм. В некоторых случаях мультимедийный контент передаётся не как поток пикселей, а как исходные данные для рендеринга на клиенте. Такой подход реализуется в рамках HDX, RDP, PCoIP и аналогичных протоколов.
В оптимизированной схеме ВМ не занимается рендерингом видео, а передаёт клиенту значительно более компактные данные (например, поток в формате MP4 вместо кадров FullHD 30 fps). Декодирование выполняется на стороне клиента, что разгружает CPU сервера и повышает масштабируемость.
Эти механизмы доступны в основном в сценариях работы с ВМ с ОС Windows и позволяют добиться существенного эффекта: воспроизведение FullHD‑видео в ВМ даёт нагрузку, сопоставимую с простыми офисными приложениями, при сохранении высокой плотности пользователей.
Оптимизация web‑приложений
Web‑приложения в VDI упираются в высокое потребление памяти и CPU со стороны браузера. Подход к оптимизации здесь во многом похож на multimedia redirection.
Браузер в виртуальной машине может не выполнять полноценный рендеринг страницы. Вместо этого используется один из двух механизмов:
URL redirection — перенаправление URL на клиент VDI
Browser Content Redirection — передача уже подготовленного контента на клиент
Оба подхода реализуются через виртуальные каналы VDI‑протокола и позволяют существенно снизить нагрузку на сервер и сетевую инфраструктуру. При этом уменьшается и объём передаваемых данных, что снижает требования к каналу связи.
Ограничение здесь — доступность технологий: такие механизмы в полном объёме реализованы в основном в продуктах Citrix и VMware/Omnissa.
Оптимизация CAD/CAM‑приложений
CAD/CAM‑приложения требуют наиболее комплексной оптимизации.
vGPU (виртуальные GPU) — базовый слой оптимизации. Физический GPU на сервере либо шарится между ВМ с распределением ресурсов, либо пробрасывается в виде выделенной графической карты. Каждая ВМ получает изолированный графический контекст с гарантированной долей производительности.
Однако одной серверной графики недостаточно, необходима поддержка аппаратного декодирования H.264/H.265 на стороне клиента и соответствующая интеграция с VDI‑протоколом. Также важно учитывать профиль CPU‑нагрузки самого приложения: одни CAD‑системы хорошо масштабируются по ядрам, другие критичны к высокой частоте одного ядра.
Современные VDI‑протоколы в целом поддерживают такие сценарии. Среди отечественных решений можно отметить российский протокол LoudPlay, который обеспечивает сопоставимую функциональность с HDX и Blast Extreme при работе с 3D‑приложениями и поддерживает как Windows‑, так и Linux‑среды, включая российские дистрибутивы.
Как обеспечить оптимизацию видеоконференсвязи
Сложность оптимизации ВКС в VDI обусловлена несколькими факторами. Видеоконференцсвязь работает в реальном времени, поэтому любые задержки сразу заметны пользователю. Одновременно обрабатываются несколько потоков: видео с камеры, демонстрация экрана, аудио и сигнальные данные конференции. Все потоки должны оставаться синхронизированными и каждый из них требует своего кодирования. Дополнительно система должна адаптивно менять качество передачи в зависимости от качества сети у участников.
Мировая пандемия 2020 года и события 2022 года выступили ключевыми триггерами для развития рынка ВКС. Когда западные системы (Zoom, MS Teams, Cisco, …) стали ограниченно доступны или нестабильны в России, начался рост отечественных ВКС‑систем. При этом быстро выяснилось, что они нуждаются в специальной оптимизации для работы в VDI‑среде.
Подход, который работает для всех типов ВСК, — это минимизация пути передачи медиаданных.
Вместо полного прохождения цепочки:
захват медиа → VDI‑протокол → ВМ → обработка → обратная передача
оптимизированные решения используют клиентские плагины и компоненты в ВМ, которые позволяют медиапотокам обходить виртуальную машину.
Например, в сценариях Webex или Teams медиа потоки могут передаваться напрямую на сервер ВКС или даже между участниками, минуя ВМ. Это радикально снижает нагрузку: CPU серверов виртуализации падает с уровней близким к 100% до 9–10%. Дополнительно задействуются аппаратные возможности клиента для кодирования, декодирования и рендеринга медиа потоков.
Кроме того, трафик ВКС теперь «честный»: он не прячется внутри трафика протокола удаленного доступа (а значит к нему можно применить стандартные для ВКС механизмы обеспечения качества — настройка QoS/CoS, выделение в отдельные VLAN и так далее). Условия работы клиента ВКС тоже становятся прозрачными для компонентов ВКС авто‑определяющих качество канала связи и производительность «железа» клиента. Теперь ВКС сможет видеть, что связь на самом деле идет по тонким каналам (через которые работает клиент VDI), а не через десятки гигабит дата‑центра, где работает ВМ.
В такой архитектуре пользователь получает стабильное качество видеосвязи, а ИТ‑инфраструктура сохраняет высокую плотность виртуальных машин на сервер — на уровне, сопоставимом с офисными сценариями (сотни ВМ на один сервер).
Парадокс оптимизации ВСК на российском рынке: обзор систем
Особенности российского рынка заключаются в том, что после 2022 года развитие VDI‑решений и ВКС‑систем шло параллельно, но в значительной степени независимо.
С одной стороны, активно развивались отечественные платформы виртуализации рабочих мест. С другой — создавались собственные ВКС‑приложения. Однако оптимизация ВКС для работы в VDI‑среде — это процесс, который требует глубокого понимания двух областей одновременно: архитектуры VDI‑инфраструктуры и специфики realtime‑медиа‑обработки внутри виртуализированной среды.
На текущий момент основными игроками российского рынка видеоконференцсвязи являются:
CommuniGate Pro
IVA MCU
TrueConf
Контур Толк
Яндекс Телемост
МТС Линк
Рассмотрим характеристики и системные требования клиентской части этих ВКС‑решений.
Communigate Pro
Если говорить про системные требования к клиенту, то разработчик не предоставляет таких сведений в официальной документации, что делает оценку возможностей данной ВКС в VDI затруднительной.
IVA MCU
IVA MCU — платформа ВКС от компании IVA Technologies. Для подключения в конференции компания предлагает два клиента:
· IVA Connect Desktop — полноценный клиент для операционных систем Windows и Linux.
· IVA Connect WEB — браузерный клиент для работы подключения к видео‑ и аудио‑конференциям
Рассмотрим аппаратные требования и требования к сети для каждого из клиентов:
1. IVA Connect Desktop
Таблица 1 — Минимальные требования к аппаратному обеспечению для работы с IVA Connect Desktop
Процессор для настольных ПК | Intel Core‑i5 6-го поколения или аналогичный AMD |
Процессор для мобильных ПК | Intel Core‑i5 6-го поколения или аналогичный AMD |
Оперативная память | 8 ГБ |
Разрешение экрана монитора | 1024×768 |
Разрешение видеокамеры | VGA (640×480) |
Размер экрана | 1920×1080 (FullHD) |
Наличие микрофона, колонок или аудиогарнитур | да |
Наличие звуковой карты | да |
Таблица 2 — Минимальные требования к сети для работы с IVA Connect
Скорость соединения | не менее 512 кбит/с для разрешения 360р |
Задержка пакетов | не более 150 мс |
Потеря пакетов | не более 1% |
2. IVA Connect Web
Браузерный клиент имеет аналогичные требования к аппаратному обеспечению и к сети, что и desktop‑версия клиента.
В приложенных требованиях отсутствует информация о количестве ядер и их производительности для указанных процессоров. Если говорить про VDI, то эта информация критична: производительность виртуальной машины, как правило, ниже, чем у полноценного физического ПК, а сами ядра, доступные в виртуальной машине, не могут быть ею монополизированы, так как ядра виртуальные и их производительность распределяется на все ВМ в пуле.
TrueConf
В документации представлена таблица с рекомендуемыми системными требованиями, но нас интересуют требования к клиентскому оборудованию, которое предназначено для видеоконференций. В таблице с требуемыми процессорами указано большое количество моделей, которые могут быть на борту компьютера, для того чтобы обеспечивать то или иное качество видеосвязи. Например, разработчик заявляет, что для обеспечения видеоконференции в 720p 30 fps подходят процессоры, начиная от Athlon 2 (сокет AM3) и заканчивая процессором Intel Core i5 2-го поколения. Но требования к VDI и терминальным серверам для клиента отсутствуют, соответственно, можно сделать вывод: к виртуальным машинам и терминальным серверам будут предъявляться аналогичные требования, что и к физическим ПК.
Такой разброс по требованиям к производительности даёт повод сомневаться в стабильности видеоконференции в виртуальной среде, где процессорные ядра не монополизируются виртуальной машиной.
С другой стороны, хотелось бы сказать спасибо команде TrueConf за подробную детализацию требований клиента ВКС к CPU, RAM и тому подобное. Она позволяет заранее сказать, какое качество видеосвязи можно ожидать на том или ином «железе». Далеко не каждый вендор ВКС указывает подробные требования к клиентской части, из‑за чего становится невозможным прогнозировать качество ВКС без установки клиента на устройство.
Если говорить про требования к сети, то, например, для обеспечения видеоконференции в HD качестве, требуется 512 кб/с, что является распространенным значением среди решений на рынке, однако существующие популярные VDI протоколы могут использовать полосу в 256 кб/с для обеспечения качества FHD 30 fps (например, тот же ICA от Citrix).
Контур Talk
Контур Толк — платформа ВКС от компании СКБ Контур.
Разработчик заявляет о следующих технических характеристиках:
· CPU: Intel Core i3 или аналогичный.
· RAM: 4 гб и выше.
· Наличие микрофона и камеры.
Сетевые требования ограничиваются лишь показателями задержки, которая не должна превышать 100 мс.
Несмотря на то, что разработчик заявлял о поддержке работы в VDI и о наличии оптимизации для VDI, никакой информации о том, как работает и как настроить, в документации нет. Более того, если мы говорим про демонстрацию экрана рабочего стола, то эта функция недоступна для VDI, что ставит под вопрос необходимость внедрения и эксплуатации такого рода решений в VDI.
Яндекс телемост
Если говорить о требованиях к аппаратному обеспечению клиента и к инфраструктуре VDI, то документация Яндекс Телемост не располагает подобными сведениями. В связи с этим появляются сложности для оценки производительности системы при участии в видеоконференции.
Интересно, что общим в системных требованиях клиентов российских ВКС является наличие достаточно высокопроизводительного CPU на клиенте, отсутствие какой‑либо декларации зависимости поддерживаемого качества видеосвязи от аппаратных возможностей GPU клиента и клиентской камеры по кодированию\декодированию медиа‑потоков. Можно предположить, что вся нагрузка ложится на CPU. Это очень сильно отличается от, скажем, Skype for Business и MS Teams, где использование камеры с аппаратным сжатием потока в H.264 и задействование GPU для кодирования\декодирования медиа позволяет в 2–2.5 раза поднять разрешение видео сессии на том же CPU, в т ч и на слабых CPU тонких клиентов VDI.
МТС Линк
МТС оказалась практически единственной крупной российской компанией, которая активно использовала, продавала и интегрировала средства виртуализации (VMware, Citrix) и одновременно разрабатывала собственные ВКС‑решения. Это позволило компании «прочувствовать» необходимость оптимизации ВКС для работы в VDI на собственном опыте, так как они столкнулись с этой проблемой при внедрении VDI для собственных нужд и при консультировании клиентов.
В результате МТС разработала ВКС‑приложение (МТС Линк), которое изначально создавалось с учётом требований VDI‑среды (Citrix). Платформа использует специализированные кодеки, поддерживает прямую передачу видеопотоков, оптимизирована для работы с нестабильными сетями (что актуально для России), и демонстрирует производительность, близкую к западным аналогам.
Другие отечественные вендоры ВКС сосредоточились на функциональности и удобстве использования, но не уделили достаточного внимания оптимизации для VDI‑среды. В результате их приложения работают в VDI, но не эффективно: плотность пользователей остаётся низкой, требуется выделение большего количества ресурсов на одного пользователя, и производительность не соответствует тому, что достигается при использовании зарубежных аналогов или МТС‑решения.
Заключение
Текущая ситуация на российском рынке обнажила системную проблему. Дело в том, что значительная часть отечественных ВКС‑решений проектировалась без учета работы в VDI‑инфраструктурах, которые сегодня являются базовым элементом гибридных цифровых сред предприятий. Вендоры ВКС развивали продукты с фокусом на видеосвязь как таковую, тогда как специфика виртуализированной среды и её ограничения часто оставались вне архитектурных требований. В свою очередь, разработчики VDI традиционно не погружались в детали реализации ВКС, что привело к разрыву на уровне совместимости.
В результате когда внедряется VDI и ожидается производительность на уровне локального ПК, ВКС становится узким местом. Без должной оптимизации ВКС непропорционально потребляет CPU, усиливает нагрузку на сеть и не обеспечивает ожидаемое качество связи.
При этом в гибридных инфраструктурах эффект усиливается. А попытки заменить западные решения отечественными при отсутствии глубокой интеграции с VDI часто воспринимаются как шаг назад. В ответ компании начинают вводить обходные сценарии, как, например, вынос ВКС на локальные устройства или использование разных решений под разные кейсы. Это усложняет ИТ‑инфраструктуру, снижает безопасность, и в итоге замедляет цифровую трансформацию, нивелируя преимущества «тонких клиентов».
При внедрении комплексных систем, в которых должны уживаться и VDI, и ВКС, важно помнить инженерное правило, что «вычислительная мощность не берётся из ниоткуда и не исчезает в никуда». Нельзя просто сэкономить несколько десятков vCPU на серверах ВКС — за это придётся заплатить либо пятикратно большим потреблением ресурсов в VDI, либо начать использовать ПК вместо тонких клиентов. А это уже ставит под вопрос экономическую эффективность всей VDI‑инфраструктуры.
Что делать:
Отечественным вендорам ВКС и платформ виртуализации при планировании дорожной карты стоит обратить внимание на оптимизацию ВКС для работы в VDI. Это не точечное техническое улучшение, а мировой подход, напрямую влияющий на пользовательский опыт и эффективность использования инфраструктуры. И для его реализации нужна работа по четырем направлениям.
1. Глубокое понимание архитектуры VDI
ВКС‑вендорам необходимо выстраивать плотное взаимодействие с разработчиками VDI‑платформ и заказчиками инфраструктуры. Понимание ограничений и особенностей VDI‑среды, реальных сценариев использования в условиях продуктивной (не тестовой) нагрузки, поможет корректно реализовать оптимизацию.
На практике это означает совместные тестирования, обмен инженерным опытом и, в ряде случаев, совместную разработку интеграционных механизмов между ВКС и VDI.
2. Разработка специализированных модулей оптимизации
Каждая ВКС‑система должна иметь поддержку ключевых VDI‑платформ: Citrix, VMware, а также отечественных решений (Basis Workplace, HostVM, Space, Termidesk и др.).
Для реализации можно использовать плагины, расширения или встроенную поддержку специализированных каналов и протоколов доставки мультимедиа.
3. Инвестиции в кодеки и протоколы доставки
Современные оптимизированные ВКС требуют применения актуальных кодеков (VP9, AV1), поддержки аппаратного ускорения кодирования и декодирования на клиентских устройствах, включая встроенные GPU в CPU, а также специализированных протоколов передачи мультимедиа.
В отдельное направление стоит выделить возможности периферийных устройств. Например, камеры уровня Logitech HD Pro Webcam C920e могут выполнять аппаратное кодирование видео в FullHD 30 fps и снижать нагрузку на CPU клиента. В такой архитектуре клиентский CPU разгружается, а виртуальная машина получает косвенный выигрыш за счёт снижения общей нагрузки в VDI.
Тут важно подсветить, что реализация подобных механизмов требует значительных финансовых, и временных ресурсов. При этом это долгосрочные инвестиции, которые действительно формируют преимущество в технологиях и открывают путь к конкурентоспособности на международном рынке.
4. Тестирование и документирование практик
Испытания ВКС в реальных VDI‑сценариях должны проводиться регулярно. Необходимо фиксировать результаты, формировать набор инженерных best practices и делиться ими не только внутри компаний‑разработчиков, но и с интеграторами и заказчиками.
Вывод: как закрыть технологический разрыв между российскими ВКС и VDI
Глобальный рынок давно движется в этом направлении. Основные ВКС‑платформы (Microsoft Teams, Google Meet, Cisco Webex, Zoom, Avaya) уже имеют специализированные оптимизации под VDI. А вендоры виртуализации (VMware, Citrix) работают в тесной связке с разработчиками ВКС, обеспечивая совместимость и производительность в типовых корпоративных сценариях.
Российский же рынок находится в точке принятия архитектурного решения. Если развитие ограничится переносом существующих подходов без учёта специфики VDI, это приведёт к сохранению ограничений производительности и замедлению цифровой трансформации.
Если оптимизация ВКС для VDI будет рассмотрена как базовая инженерная компетенция, а не дополнительная функция, это позволит создать решения, сопоставимые с мировыми аналогами и адаптированные под реальные условия эксплуатации.
В этом случае ВКС перестанет быть узким местом гибридной инфраструктуры и станет её полноценным компонентом, обеспечивающим стабильную работу современных цифровых рабочих мест.
