RemoteFX. Часть 3 — Remote Desktop Session Host (RDSH, Terminal Services)

Говоря об архитектуре RemoteFX, мы не могли не упомянуть о том, как эта новая технология встраивается в существующий протокол «Удалённого рабочего стола» (Remote Desktop Protocol, RDP). После осознания этого факта сам собой напрашивается вопрос — а можно ли получить преимущества RemoteFX в сценарии не виртуальных рабочих мест (VDI), а традиционного сервера «Удалённых рабочих столов» (Remote Desktop Session Host, RDSH — он же ранее известный под именем Terminal Server)? Ответ, как это часто бывает в таких случаях, неоднозначен: и да, и нет.

Самая «интересная» часть RemoteFX — отрисовка изображений с использованием видеокарты физического сервера (Render) и их последующий захват (Capture) — работать, увы, не будет. Почему? Потому что для этого потребовалась бы виртуальная синтетическая видеокарта, а также компонент RCC — которые, очевидно, работают только с Hyper-V. Более того, один экземлпяр RCC способен обслуживать строго одну виртуальную видеокарту, а значит — одну пользователькую сессию. Всё это совершенно не соответствует парадигме сервера Удалённых рабочих столов (RDSH), где в пределах одной ОС (а значит — одного комплекта оборудования) выполняется сразу множество пользовательских сессий.

Что это значит? В сценарии RDSH вы не получите никаких новых возможностей вроде высокопроизводительной графики, поддержки DirectX или потокового видео. Это отнюдь не значит, что работая с сервером Удалённых рабочих столов пользователь ни в коем случае не сможет, например, насладиться Windows Aero. Просто для поддержки этих возможностей они должны быть реализованы на стороне клиента — как и раньше, при использовании RDP версии 7.0 и более ранних.

Однако, что же остаётся? Третья составляющая RemoteFX — а именно, сжатие. Именно этот компонент как раз доступен при работе сервера Удалённых рабочих столов под управлением Windows Server 2008 R2 Service Pack 1. Это распространятеся как на чисто программную реализацию, выполняющуюся полностью на CPU (помните, что в сценарии RDSH видеокарта сервера не используется!), так и на аппаратную — с использованием чипа ASIC.

Из этого следуют достаточно интересные выводы. Во-первых, если для реализации RemoteFX в сценарии VDI вам обязательно необходимо новейшее оборудование — процессор с поддержкой SLAT и мощная профессиональная видеокарта — то в случае RDSH это совершенно не так. Всё, что вам потребуется — это поддержка процессором набора инструкций Streaming SIMD Extensions 2 (SSE2). А ведь это — уже вполне щадящее требование. Абсолютное большинство серверов, которые находятся сейчас в эксплуатации, удовлетворяют этому условию. В результате вы почти наверняка сможете воспользоваться сжатием RemoteFX на своём существующем сервере Удалённых рабочих столов.

Во-вторых, в результате пользователи смогут получить то же качество изображения, что и раньше, — но это будет требовать меньшей полосы пропускания. В-третьих, для того, чтобы снять нагрузку по сжатию с процессора и увеличить масштабируемость, вы по-прежнему можете воспользоваться аппаратной реализацией кодека RemoteFX и приобрести для сервера Удалённых рабочих столов плату ASIC. Ну и в-четвёртых, требования к клиентским рабочим местам остаются такими же, как и в случае использования RemoteFX в сценарии VDI — и об этом мы подробно поговорим завтра.

Архитектурно RemoteFX в сценарии с Remote Desktop Session Host (без Hyper-V) выглядит следующим образом. Ещё раз обращаю ваше внимание на то, что компоненту RCC в этом сценарии места не нашлось.

(Мы понимаем, что не все названия компонентов и их взаимосвязь в иллюстрациях к этому циклу статей могут быть очевидны для наших читателей. Поэтому на всякий случай напоминаю о том, что мы всегда готовы давать развёрнутые пояснения по предмету статей и иллюстраций к ним, если они вызовут вопросы в комментариях).