RemoteFX. Часть 4 — клиентская инфраструктура и отличия от «классического» RDP
Поговорив об обоих возможных сценариях использования RemoteFX на стороне сервера, пришло время рассказать о том, что изменилось со стороны клиента. Но для начала стоит сделать ещё одно теоретическое отступление — и вкратце поговорить о том, чем RemoteFX так сильно отличается от традиционного протокола Удалённого рабочего стола (RDP версиий 7.0 и младше). В общем-то, обо всём этом мы вскользь упоминали в предыдущих статьях этого цикла, однако явно не проговаривали.
На всякий случай напоминаю, что RemoteFX — это не отдельный протокол или продукт, а новая технология, входящая в состав RDP 7.1. Поэтому и сравнивать мы будем не два разных протокола, а две версии одного протокола — 7.0 (и более младшие — все, где не используется RemoteFX — «традиционный» или «классический» RDP) и 7.1 (для простоты иногда мы будем упоминать о нём как о просто «RemoteFX»).
Сравнение с традиционным RDPДело в том, текущая реализация RDP ориентирована на то, чтобы как можно большее количество работы по отрисовке графики переложить на сторону клиента. Такой подход был более чем оправдан в мире серверов «Удалённых рабочих столов» (Terminal Services, а затем RDSH). Как правило, на клиентском рабочем месте установлено устройство с более мощной видеокартой, чем та, которой обладает сервер. Так пускай эта карта и работает.
По сети передаются графические примитивы и инструкции, которые должна выполнить видеокарта на клиентском устройстве. Например, если вы хотите демонстрировать видео или использовать интерфейс Winodws Aero, то эти возможности должно поддерживать ваше клиентское устройство. В случае, если клиентское устройство не обладает требуемым функционалом, клиент с сервером согласовывают приемлемый для обоих сторон способ разрешения проблемы. Например, вместо Windows Aero будет использоваться упрощённая схема оформления. Видео же будет обрабатываться процессором сервера, а затем передаваться клиенту в виде набора двухмерных растровых изображений. Я думаю, вы сами хоть раз сталкивались с такой ситуацией. И могли заметить, что производительность этого решения настолько далека от приемлемой, что, как правило, от сложной графической информации в сеансах Удалённого рабочего стола приходится просто отказываться. Всё вышесказанное свойственно как традиционным серверам RDSH, так и решениям VDI.
Но всё принципиально меняется, когда на сцену выходит RemoteFX. В результате работы компонента RCC в виртуальную машину (и далее в протокол RDP) передаются не графические примитивы и инструкции DirectX, а уже отрисованное растровое изображение, произведённое видеокартой сервера и готовое для отображения на клиентском устройстве. Да — в чём-то это похоже на только что описанный метод передачи, используемый сегодня тех типов графики, которые не могут быть обработаны на клиентском устройстве. Однако здесь есть два важных отличия. Во-первых, производительность отрисовки на видеокарте — устройстве, специально разработанном именно для этого типа задач, — несоизмеримо выше, чем в ситуации, когда эту работу приходится выполнять центральному процессору. А во-вторых, сжатие изображений кодеком RemoteFX существенно уменьшает объём передаваемых данных.
Кроме того, предусмотрена возможность использования на стороне клиента аппаратной реализации протокола RemoteFX — чипа ASIC, который будет выполнять всю работу по распаковке изображения, сжатого на стороне сервера. Напоминаю, что в процессе сжатия на сервере может принимать участия такая же аппаратная реализация протокола. Причём способ сжатия, используемый на сервере, не накладывает никаких ограничений на способ распаковки, используемый на клиенте. Иными словами, вы можете, например, использовать аппаратное сжатие на сервере и программную распаковку на клиенте, а можете наоборот.
Вот что какое место занимает RemoteFX в работе протокола «Удалённого рабочего стола» на клиентском устройстве.
Требования к каналам связиОчевидно, что передача готовых изображений в сценарии RemoteFX занимает большую полосу пропускания и, что ещё важнее, более требовательна к отсутствию задержек в сети, в сравнении с передачей инструкций и примитивов в сценарии с классическим RDP. Ведь как ты ни сжимай изображение, оно всё равно будет занимать больше памяти, чем набор примитивов или инструкций. Именно поэтому в текущей реализации RemoteFX позиционируется только для использования в условиях быстрой и надёжной сети (LAN). Впрочем, уже объявлены партнёрские решения, которые помогут снизить требования RemoteFX и адаптировать его для работы по медленным каналам связи.
Если просуммировать всё сказанное выше, можно сделать два важных вывода.
- В сценарии VDI сейчас по сети передаются инструкции и примитивы, а затем отрисовываются на клиентском устройстве. В случае с RemoteFX меняется точка отрисовки изображения, и оно будет передаваться уже готовым. Следовательно, с использованием RemoteFX качество изображения возрастёт, а объём передаваемых данных будет больше.
- В сценарии RDSHметод отрисовки не меняется. Поэтому данные остаются теми же самыми, но они сжимаются более эффективным кодеком RemoteFX. Следовательно, качество изображения не изменится, а объём передаваемых данных будет меньше, чем сейчас, без RemoteFX.
Конечно же, сравнительные характеристики удовлетворяют не всех — и в комментариях к одной из предыдущих заметок этого цикла уже был задан вопрос о численных показателях. Во-первых, хочу ещё раз повторить: наиболее критичный показатель для работы RemoteFX — это не пропускная способность (Bandwidth), а задержки (Latency) в канале связи. Во-вторых, точных данных и рекомендаций по планированию нагрузки пока нет — потому что нагрузочное тестирование производить пока рано. На текущей стадии разработки продукта основное внимание уделяется функционалу и исправлению ошибок, а не оптимизации производительности. Ну а в-третьих, возьмём на себя риск всё-таки поделиться некоторыми соображениями.
- Старайтесь не допускать задержек больше 50 ms (оптимально — не более 20 ms).
- Рекомендуется начинать тестирование исходя из пропускной способности не менее 2,5 mbps (оптимально — от 10 mbps). На объём полосы, которую займут данные RDP, напрямую влияет размер экрана — поэтому примерные цифры вам придётся установить самостоятельно.
- Не более 0,1%-0,2% потерь.
Мы уже говорили о том, что размер экрана также влияет на объём видеопамяти, выделяемой той или иной виртуальной машине — а значит, на количество машин, которые вы сможете запустить на одном сервере. К счастью, показатели загрузки здесь гораздо более предсказуемые, чем в части про использование сети. Поэтому уже сейчас существуют официальные данные.
Следующая таблица показывает объём видеопамяти, необходимый каждой виртуальной машине в зависимости от заданных ожидаемых параметров монитора. Поэтому не надо без необходимости задавать в свойствах виртуальной машины слишком большие параметры экрана — это повлечёт за собой неоправданный расход видеопамяти.