Видеоконференции (Zoom, MS Teams, Cisco Webex, TrueConf, IVA, Jitsi) — это настоящий кошмар для инфраструктуры виртуальных рабочих столов (VDI). Если видео и звук обрабатываются в виртуальной машине пользователя, это приводит к «сжиганию» колоссальных вычислительных ресурсов серверов VDI и забивает канал связи без возможности управления ее качеством (QoS).
За последние два года мы получили сразу несколько параллельных трендов. Это массовый переход на отечественные решения VDI и ВКС, рост доли удаленной работы и повсеместное использование видеоконференций. По нашим наблюдениям, сегодня более 90% сотрудников регулярно используют ВКС, и почти в каждой инфраструктуре VDI эти сценарии уже стали критически важными.
При этом именно видеоконференции оказались самым болезненным типом нагрузки для виртуальных машин. Использование ВКС в VDI часто ухудшает пользовательский опыт и влияет на эффективность цифровых рабочих мест. Мы решили разобраться почему и что с этим можно сделать.
Почему VDI «не тянет» видеоконференции
На этапе проектирования
Для большинства типовых офисных сценариев такая модель оправдана и экономически эффективна. Работа с электронной почтой, корпоративными порталами, офисными документами, CRM-системами, браузером и другими бизнес-приложениями не требует постоянного выделения вычислительных ресурсов в режиме реального времени. Даже кратковременные задержки в предоставлении процессорного времени обычно остаются незаметными для пользователя.
Однако видеоконференцсвязь относится к другому классу нагрузок. Обработка аудио- и видеопотоков происходит непрерывно и предъявляет жесткие требования к производительности, задержкам и стабильности выделения ресурсов.
Клиент ВКС внутри виртуальной машины одновременно выполняет несколько ресурсоемких задач. Приложение кодирует и декодирует видео, обрабатывает аудиопоток, рендерит пользовательский интерфейс, а также принимает и передает данные от камеры, микрофона и гарнитуры пользователя. В отличие от большинства офисных приложений, все эти операции должны выполняться непрерывно и в режиме, приближенном к реальному времени.
При этом программный клиент ВКС, работающий внутри виртуальной машины, не имеет объективной информации о фактически доступных ему ресурсах. Операционная система сообщает приложению, что в его распоряжении находятся выделенные ресурсы с фиксированными характеристиками: определённое количество процессорных ядер, память и сетевой интерфейс. Но в реальности эти ресурсы распределяются гипервизором между множеством виртуальных машин и предоставляются по мере доступности.
В результате, при возникновении пиковых нагрузок на сервер виртуализации, клиент ВКС продолжает работать исходя из предположения, что вычислительная среда остается стабильной. Приложение пытается обрабатывать мультимедийные потоки с прежними параметрами качества и не может своевременно компенсировать ухудшение условий. С учетом особенностей среды это неизбежно приводит к деградации качества связи, что проявляется в искажениях звука, артефактах видеопотока, выпадении отдельных кадров и фрагментов речи.
Одним из характерных симптомов становится рост джиттера (jitter), то есть колебаний времени доставки и потери сетевых пакетов. При стабильной работе системы ожидается, что они должны поступать через равные промежутки времени и с минимальными потерями. Если же интервалы начинают меняться в широком диапазоне, клиенту ВКС становится сложнее поддерживать непрерывное воспроизведение мультимедиа. Из-за этого «заикается» звук, нарушается синхронизация аудио и видео. Для коммуникационных сервисов такие отклонения критичны. Однако, джиттер и потери пакетов являются лишь внешним проявлением проблемы, которая на самом деле лежит на уровне архитектуры.
Как показали наши исследования, клиент ВКС, работающий в виртуальной машине, не способен корректно оценивать и компенсировать изменения характеристик вычислительной среды. В отличие от физического рабочего места, где приложение напрямую взаимодействует с процессором, памятью, сетью и периферийными устройствами, в
Как работают привычные подходы «добавить ресурсов» и «облегченные режимы»
При возникновении проблем с ВКС в VDI команды, отвечающие за инфраструктуру, в первую очередь предлагают увеличить объем ресурсов. Например, добавить виртуальные процессоры, память или расширить вычислительные мощности серверов виртуализации. На первый взгляд такой подход выглядит логичным, однако на практике он редко устраняет первопричину.
Более того, подобное решение часто оказывается экономически неэффективным, потому что происходит перенос затрат из одного центра затрат в другой. Каждый вычислительный ресурс, который не удалось сэкономить за счет оптимизации работы ВКС-клиента или инфраструктуры видеоконференцсвязи, приходится компенсировать дополнительными ресурсами
Проблема в том, что в сценариях ВКС в VDI редко существует единственное узкое место. Как правило, на качество связи одновременно влияют несколько факторов: конкуренция виртуальных машин за процессорное время, особенности работы протоколов удаленного доступа, способ обработки мультимедийных потоков, а также сетевые характеристики, критичные для сервисов реального времени, — задержка, джиттер и потери пакетов. Поэтому простое увеличение ресурсов виртуальной машины можно сравнить с попыткой ехать быстрее на старом «Запорожце» через увеличение мощности двигателя автомобиля, не меняя качество дороги и организацию движения (на гоночном треке — тестовой среде — такой «Франкенштейн» может и покажет достойный результат, но в городе — в реальных условиях эксплуатации — так и будет ехать от светофора до светофора, регулярно догоняя конец пробки).
Второй распространенный подход решения проблем с ВКС в VDI — это использование облегченных режимов работы программного клиента ВКС. В этом случае отдельные функции отключаются или упрощаются для снижения нагрузки на виртуальную машину. Однако сам клиент видеоконференцсвязи по-прежнему не получает достоверной информации о доступных ресурсах и текущем состоянии сети. Он не может учитывать реальные значения задержки, джиттера и потерь пакетов, а значит, не способен корректно адаптировать параметры обработки мультимедиа под условия виртуализированной среды. В дополнение, если в компании используется гибридный подход, то создаётся разрыв в пользовательском опыте при подключении к ВКС с ПК и при подключении к ВКС с тонких клиентов.
Как следствие применения второго подхода незначительно снижается нагрузка на инфраструктуру виртуализации рабочих столов, но корневая причина остается, так как архитектура не меняется.
Поэтому ни наращивание вычислительных ресурсов, ни использование облегченных режимов не позволяют обеспечить стабильно высокое качество видеоконференцсвязи в
Где реальное узкое место при обработке мультимедиа
Критическое значение имеет место обработки мультимедийных потоков, а не объем выделенных ресурсов. Если кодирование и декодирование аудио и видео выполняются внутри виртуальной машины, все ограничения
Дополнительная сложность проявляется в том, что программный клиент ВКС, работающий внутри виртуальной машины, не обладает полной информацией о фактическом состоянии вычислительной среды. Он не видит реальную загрузку хоста виртуализации, доступную вычислительную мощность в конкретный момент времени и характеристики сетевого соединения, критичные для сервисов реального времени. Соответственно, приложение не может своевременно скорректировать параметры обработки мультимедиа, например, изменить качество видеопотока, разрешение изображения или интенсивность кодирования в ответ на ухудшение условий выполнения.
Для оценки влияния этих факторов были проведены испытания, моделирующие работу
По мере роста числа участников видеоконференций увеличивался джиттер, возрастало количество потерь пакетов и снижалась стабильность передачи аудио- и видеопотоков. При этом ухудшение пользовательского опыта наблюдалось даже в тех случаях, когда средняя загрузка процессоров оставалась в допустимых пределах. Пользователи сталкивались с искажениями звука, выпадением отдельных фраз, артефактами изображения и нестабильной работой видео.
Полученные результаты показали, что проблему создает сама архитектура обработки мультимедиа внутри виртуальной машины. Пока клиент ВКС остается зависимым от ресурсов
Что на самом деле означает оптимизация ВКС для VDI
За последние годы ведущие разработчики
Поэтому в Citrix, VMware Horizon и других зрелых
В такой архитектуре камера, микрофон и гарнитура взаимодействуют непосредственно с локальным устройством, а медиапоток передается напрямую между клиентом ВКС и сервером видеоконференцсвязи. Виртуальная машина исключается из критического пути и наиболее ресурсоемкой части процесса.
Для этого используются специальные клиенты ВКС, оптимизированные для работы в
Результат такого подхода хорошо заметен на практике. Если обработка видео и аудио выполняется внутри виртуальной машины, загрузка процессора может достигать
При этом важно отличать полноценную оптимизацию ВКС от частичного ускорения отдельных компонентов. Некоторые решения ограничиваются оптимизированной передачей потоков от камеры и микрофона, но продолжают обрабатывать аудио- и видеоданные внутри виртуальной машины. Это может снизить нагрузку на отдельные элементы инфраструктуры, однако не устраняет фундаментальную причину и не обеспечивает качество связи, которое достигается при полном выносе обработки мультимедиа на клиентское устройство.
В чем подвох проброса камеры
Перенос обработки медиапотока на сторону клиента действительно решает проблему производительности, но здесь важно не путать технологии. Оптимизированный проброс камеры в сессию VDI не равноценен полноценной разгрузке серверов. По сути, проброс камеры — это вынужденная полумера, компромиссный вариант, который лишь частично сглаживает ограничения среды. Реальная оптимизация предполагает принципиально иной класс решений, в котором захват, обработка и маршрутизация видеопотока происходят локально на конечном устройстве пользователя, полностью минуя виртуальную машину.
Такой подход исключает задержки, минимизирует паразитный трафик и делает работу ВКС предсказуемой. Максимальный эффект достигается в сценариях, где виртуальная среда отвечает исключительно за отрисовку интерфейса и бизнес-логику, а вся тяжелая работа с мультимедиа вынесена за пределы VDI. На практике это обеспечивает кратное падение серверной нагрузки, так утилизация CPU снижается с
Почему совместимость является главным барьером
Отдельной и часто недооцененной проблемой остается совместимость
В российских реалиях ситуация складывалась иначе. Многие отечественные ВКС-решения изначально разрабатывались без учета особенностей работы в
Дополнительную сложность создает отсутствие единых механизмов взаимодействия между ВКС и VDI. Поэтому каждая комбинация продуктов требует отдельной адаптации и тестирования. В результате качество связи определяется не только возможностями самих решений, но и тем, насколько корректно они работают друг с другом. Поэтому сочетание VDI и ВКС от разных производителей нередко приводит к ухудшению пользовательского опыта.
Что это значит для ИТ-команд
Если на предприятии внедрен VDI, пользователи регулярно используют ВКС и жалуются на качество связи, то проблема почти наверняка кроется в мультимедийной нагрузке внутри виртуальной машины. Такие ситуации часто проявляются через взаимодействие ИТ-подразделений. ВКС и VDI, как правило, внедряют разные специалисты, и в результате каждая команда оценивает ситуацию в границах своей зоны ответственности. Команда VDI считает, что «ресурсов достаточно», а команда ВКС — что «клиенту не хватает производительности». Если возникают такие симптомы, это означает, что VDI используется в сценарии, для которого она изначально не оптимизирована. И этот вопрос касается всей ИТ-архитектуры.
Практические советы
1. При планировании
2. Используйте механизмы переноса обработки медиапотоков на клиентские устройства (offloading). Это дает максимальный эффект по снижению нагрузки.
3. Используйте механизмы QoS и приоритизацию трафика.
Без этого ВКС всегда проигрывает в конкуренции за ресурсы.
4. Контролируйте сетевые параметры. Джиттер должен оставаться ниже 50 мс, это критический порог.
5. Для снижения проектных рисков отдавайте предпочтения решениям, для которых производители подтвердили совместную работу VDI и ВКС в типовых корпоративных сценариях, а для сжатия аудио и видео используют стандартные аудио и видео кодеки, для которых большинство современных ПК и ТК обеспечат декодирование на аппаратном уровне.
Мы видим, что рынок VDI в России неизбежно будет расти, и вместе с этим будет расти и нагрузка от мультимедиа. Следующим этапом развития станут клиентские решения, которые выносят медиапоток из ВМ, обеспечивают стабильное качество ВКС и работают независимо от конкретной связки VDI и ВКС.
Мы рассматриваем это направление как ключевое. Потому что в любой комбинации — российский VDI с иностранным ВКС либо российский ВКС с российским VDI — компании получают проблему. И сегодня главный вопрос уже не в том, «как развернуть VDI», а в том, как сделать его эффективным для реальной коммуникации.
