С уходом иностранных вендоров большинство ИТ-компаний стали изучать возможности по замене зарубежного ПО отечественными аналогами. Конечно, системы VDI далеко не на первом месте в списке на импортозамещение, и более или менее серьезные проекты начинаются только сейчас.
Мы тестировали около десятка российских VDI-решений — на базе ПО с открытым исходным кодом OpenUDS и написанных полностью «с нуля». У продуктов отличается функционал и ценовая политика. Характерная черта, которая объединяет все эти продукты, — отсутствие специализированного протокола подключения пользователей, сопоставимого по производительности и функционалу с VMware Blast и Citrix ICA/HDX. Нельзя сказать, что разработка протоколов не ведется совсем — они все-таки есть: RX от Etersoft, GLINT на основе проекта freerdp от «Даком М», модификация SPICE от ГК «Астра». Но все они пока далеки от того, чтобы стать реальным российским стандартом для VDI «на все случаи жизни». Пока российские решения не обладают целым рядом того функционала, который есть у зарубежных аналогов: динамическая оптимизация работы протокола под канал связи (работа с «хорошими» и «плохими» каналами), возможность управлять работой протокола (тюнинг протокола в ручном режиме), эффективные алгоритмы сжатия трафика, дополнительный функционал протокола — SSO, контроль USB-устройств, работа в HTML5-режиме, поддержка vGPU.
В 2021 году мы познакомились с коллегами из компании Loudplay, которые работают в области облачного гейминга. Оказалось, что у них есть свой собственный протокол, оптимизированный для работы на нестабильных каналах, выдающий максимально возможный User Experience для геймеров. С этого момента мы начали совместно с Loudplay и вендорами VDI работать над интеграцией и адаптацией этого протокола.
В этой статье мы затронем наиболее актуальную реализацию протокола Loudplay для VDI. Об основной реализации для облачного гейминга можно почитать в другом посте на Хабре.
Итак, для подключения по протоколу Loudplay нам потребовалось развернуть два компонента: серверную и клиентскую части. Первая разворачивается на виртуальной машине, к которой будем подключаться, вторая — на клиентском устройстве. Настройка параметров подключения производится в файлах конфигурации как на сервере, так и на клиенте. Основные параметры конфигурации серверной части:
«preset»: «veryslow» / «slower» / «slow» / «medium» / «fast» / «faster» / «veryfast» / «superfast» / «ultrafast» — пресет H.264 энкодера, определяющий соотношение скорости энкодинга к уровню компрессии. Чем ниже параметр, тем выше уровень компрессии. Но чем сильнее компрессия и выше FPS, тем выше нагрузка на процессор виртуальной машины.
«profile»: «baseline» / «main» / «high» / «high10» / «high422» / «high444» — профиль работы H.264 энкодера, отвечающий за функционал кодирования трафика. Его необходимо настраивать в соответствии с типом передаваемых данных. Для работы с VDI достаточно протестировать профили от «baseline» (низкое качество картинки, низкие требования к каналу) до «high». Остальные параметры больше подходят для передачи профессионального графического контента.
Основные настройки клиентской части:
«proto»: «TCP» / «UDP» — выбор режима работы протокола Loudplay. UDP дает ниже задержки. Но с учетом того, что протокол однонаправленный, для нестабильных каналов, хоть и быстрых (как, например, Wi-Fi), требуется включение избыточности передаваемых данных. Иначе может возникнуть эффект залипания клавиш. На хороших каналах UDP выдаст результат лучше, но на узких и нестабильных каналах лучше работает TCP с отключенной избыточностью.
«capture2: («dda» / «ffmpeg-dda») – аппаратный либо программный энкодер. В первом случае используется при наличии графической карты на сервере (целевая виртуальная машина), во втором случае нагрузка по энкодингу ложится на CPU виртуальной машины.
«hw_decoder»: true/false — использование аппаратного ускорения при рендеринге экрана на клиенте. При включенном аппаратном декодировании, если клиент поддерживает, нагрузка на процессор будет ниже.
«auto_bitrate»: <значение в Kbit/s> — стартовая скорость видеопотока.
«auto_fps»: <значение кадров в сек.> — стартовая частота FPS.
После подключения к виртуальной машине некоторые значения настроек можно менять:
Основные параметры здесь:
Скорость видеопотока (от 0,1 до 30 Мбит/с) — можно искусственно ограничить ширину канала передачи данных.
Стойкость видеопотока — тут определяется избыточность трафика, полезная для работы в режиме UDP на нестабильных каналах. Параметры могут быть: «Авто» (сначала выставляется 100% избыточность, после первой минуты корректируется), «Нет» (0%), «Низкая» (50%), «Средняя» (100%), «Высокая» (200%).
Можно также поменять разрешение экрана и FPS. Смена режима курсора (Игры / Программы) меняет подход к прорисовке курсора для минимизации задержек при движении мышкой. На нашем стенде мы не смогли реализовать сценарий, который бы наглядно показал разницу. Задержек при перемещении не было ни в одном из сценариев тестирования.
Еще помогает в тестировании дополнительное окно мониторинга, которое можно открыть сочетанием клавиш «Alt+2»:
Bitrate, KB/s — используемая ширина канала для передачи видеопотока (Kbit/s);
Iframe, KB — размер передаваемого кадра iframe;
FEC redundancy, % — объем передаваемой избыточности от общего объема трафика;
Dropped frames — количество отброшенных кадров в случае возникновения потерь;
Capture time, ms — время захвата одного кадра на сервере;
Encoder time, ms — время энкодирования одного кадра на сервере;
Server framerate, 1/c — частота кадров в секунду на сервере;
Decoder time, ms — время декодирования кадра на клиенте;
Decoder queue size — количество кадров в очереди на декодирование;
Client render time, ms — время отрисовки кадра на клиенте;
Render queue size — количество кадров в очереди на отрисовку;
Client framerate, 1/c — частота кадров в секунду на клиенте;
RTT, ms — круговое время доставки сетевого пакета от сервера до клиента (задержки);
Network efficiency, % — отношение потерянных пакетов к отправленным;
Video jitter, ms — джиттер на сети при передаче видео;
Client lossrate, % — объем потерь на клиентской стороне.
Что мы протестировали?
До недавнего времени протокол мог работать только при наличии видеокарты, проброшенной на виртуальную машину, т. к. использовал ее ресурсы для кодирования передаваемого видео. Однако, несмотря на то, что у нас на стенде это можно реализовать, и свое первое знакомство с протоколом мы начали именно с его GPU-реализации, интереснее было дождаться выхода CPU-реализации протокола и сравнить его поведение с проприетарным Microsoft RDP. Сейчас мы рассматриваем RDP как основной протокол для развертывания российских решений VDI. Пару месяцев назад появилась новая реализация протокола Loudplay. Мы сразу же обновили наш стенд и решили прогнать тесты в двух основных сценариях:
Работа с динамичным контентом, при высоком объеме передачи данных, но «узкое горлышко» на стороне пользователя — например, работа через 4G-модем в движущемся транспорте.
Работа в ситуации, когда есть серьезные ограничения по пропускной способности сети и «узким горлышком» является не последняя пользовательская миля, а ширина канала в ЦОД, где установлен VDI-кластер и куда подключаются все пользователи. Особенно, когда их счет переходит на сотни и даже тысячи.
Поскольку у RDP нет встроенной возможности для ограничения ширины канала, нам потребовалось внешнее сетевое устройство Linktropy Mini от Apposite Technologies, которое мы подключали в разрыв сети между ноутбуком и тестовой сетью.
Виртуальная машина, к которой мы подключались, работала на базе Windows 10 Ent. с четырьмя ядрами 3,2 GHz vCPU и 8 GB RAM — классическая офисная конфигурация. К сожалению, серверная часть протокола пока что реализована только для ОС семейства Windows (Linux-реализация в процессе разработки).
При первом подходе мы запускали видеоролики на YouTube и постепенно на Linktropy меняли пропускную способность сети с 20 Мбит/с до 1 Мбит/с. Протокол RDP динамически никак не подстраивается под изменение ширины канала — можно только изначально при подключении выбрать профиль в настройках. Из-за этого уже на 10 Мбит/с картинка начинала подвисать, кадры выпадали. С протоколом Loudplay всё было интереснее: он достаточно быстро автоматически перестраивался. На момент переключения некоторые кадры выпадают, но буквально через несколько секунд протокол выжимает максимально возможное качество из картинки с сохранением FPS. Здесь очевидно его «геймерское» назначение. При этом нагрузку на CPU протоколы показывали примерно одинаковую — около 40%.
Этот тест можно посмотреть в нашем ролике.
При втором подходе мы выставляли в настройках минимальное качество картинки для двух протоколов и пытались понять, можно ли с этим работать на скоростях 256/512 Кбит/с хотя бы с текстовыми документами и табличками. Мы отметили более высокую скорость отклика на печать на клавиатуре и прокручивании окон в случае с Loudplay. FPS при этом на обоих протоколах колебался в пределах 3–5 кадров в секунду. Чуда не произошло — работать на таких скоростях можно только с текстовыми документами, но очевидно, что просидеть за таким виртуальным рабочим местом полный рабочий день будет непростым испытанием для глаз и нервов сотрудника. Хотя тут стоит отметить, что Loudplay показал себя чуть лучше в плане отзывчивости интерфейса.
С пробросом устройств функционал RDP выглядит лучше — можно пробросить почти всё. Но в режиме ВКС микрофон и камера работают откровенно плохо: медиатрафик почти не сжимается, дает высокую нагрузку на канал. Всё это приводит к высоким задержкам. Общаться даже просто голосом фактически невозможно. Loudplay умеет пробрасывать только микрофон — опять возврат к геймерскому назначению, — но делает это хорошо. Голосовое общение, можно сказать, уже реализовано.
В заключение хочется отметить, что надежда получить хороший универсальный протокол для VDI в среднесрочной перспективе (два-три года) определенно есть. То, что Citrix и VMware уже давно реализовали, не выглядит недостижимыми результатами для российских разработчиков. Протокол Loudplay уже сейчас оптимизирует трафик лучше, чем Microsoft RDP. В скором времени мы планируем сделать сравнение с Citrix ICA/HDX, чтобы лучше понять, насколько велик разрыв.