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) в канале связи. Во-вторых, точных данных и рекомендаций по планированию нагрузки пока нет — потому что нагрузочное тестирование производить пока рано. На текущей стадии разработки продукта основное внимание уделяется функционалу и исправлению ошибок, а не оптимизации производительности. Ну а в-третьих, возьмём на себя риск всё-таки поделиться некоторыми соображениями.

1. Старайтесь не допускать задержек больше 50 ms (оптимально — не более 20 ms).
2. Рекомендуется начинать тестирование исходя из пропускной способности не менее 2,5 mbps (оптимально — от 10 mbps). На объём полосы, которую займут данные RDP, напрямую влияет размер экрана — поэтому примерные цифры вам придётся установить самостоятельно.
3. Не более 0,1%-0,2% потерь.

Требования к объёму видеопамяти

Мы уже говорили о том, что размер экрана также влияет на объём видеопамяти, выделяемой той или иной виртуальной машине — а значит, на количество машин, которые вы сможете запустить на одном сервере. К счастью, показатели загрузки здесь гораздо более предсказуемые, чем в части про использование сети. Поэтому уже сейчас существуют официальные данные.

Следующая таблица показывает объём видеопамяти, необходимый каждой виртуальной машине в зависимости от заданных ожидаемых параметров монитора. Поэтому не надо без необходимости задавать в свойствах виртуальной машины слишком большие параметры экрана — это повлечёт за собой неоправданный расход видеопамяти.

Текущая предварительная версия RemoteFX была протестирована в следующих максимальных конфигурациях.

• До четырёх видеокарт (GPU) на сервере;
• до 12 виртуальных машин на каждый GPU;
• до 24 виртуальных машин на сервере.

Все цифры могут меняться в обе стороны по мере продолжения разработки и приближения к окончательному выпуску.

Требования к клиентскому оборудованию и ПО

Очевидное преимущество RemoteFX перед традиционным RDP — то, что для вывода на экран простого двухмерного изображения, в отличие от выполнения инструкций, нам больше не нужны мощные графические устройства на стороне клиента. И это делает возможным использование целого ряда новых клиентских устройств — от унаследованных компьютеров до новых «ультра-тонких клиентов» (Ultra Lightweight Thin Clients или просто Ultra Thin Clients). Это новый класс устройств, которое ожидается на рынке после появления окончательной версии RemoteFX. Вот примерные характеристики такого устройства.

• Архитектура ARM, MIPS или PPC;
• встраиваемая операционная система (например, Windows CE или Linux);
• поддержка USB Redirection (подробнее об этой функции речь пойдёт в одной из следующих статей);
• очень низкое энергопотребление — 3-10 ватт;
• частота процессора 200 – 400 MHz;
• оперативная память — менее 256 MB;
• локальный накопитель — около 128 MB;
• использование аппаратного устройства (чипа ASIC) для декодирования протокола RemoteFX.

Очевидно, что физически это будет выглядеть как монитор с клавиатурой и мышью — без какого-либо даже намёка на системный блок. Если же вернуться с небес на землю — к тому оборудованию, которое существует на сегодня, — то картина получается следующая.

Для поддержки RemoteFX потребуется обновлённый клиент «Удалённого рабочего стола» — поддерживающий RDP версии 7.1. Очевидно, что этот клиент будет входить в состав Windows 7 Service Pack 1. Кроме того, он будет портирован для Windows Vista. Поддержки RemoteFX в клиенте для Windows XP не планируется.

Для всех прочих операционных систем готовых клиентов Microsoft распространять не будет. Вместо этого производители тонких клиентов и другие партнёры уже сейчас могут получить у Microsoft пример исходного кода клиентского приложения RDP 7.1, написанный на языке C++, — и реализовать поддержку по своему усмотрению.