Управление полосой пропускания: Часть 1 – Старомодный способ

Введение

Хотите верьте, хотите нет, но у вычислений на основе серверов есть некоторые серьезные «проблемы дизайна», которые некоторые недоброжелатели сочли бы похоронным звоном для этой технологии. Печать, интеграция приложений, управление затратами и пропускной способностью — вот некоторые из наиболее распространенных проблем, возникающих в течение жизненного цикла серверной среды. Управление полосой пропускания, хотя часто одна из ПОСЛЕДНИХ проблем в умах многих архитекторов, должно быть главным среди соображений для успешной реализации.

Достаточно верно то, что ICA и RDP являются ОЧЕНЬ хорошими гражданами, насколько протоколы уровня представления идут в наших корпоративных LAN/WAN. Однако протоколы уровня представления очень чувствительны к задержке и нестабильности соединения. Таким образом, мы, как архитекторы, должны рассмотреть стратегии по этому вопросу. Существуют две основные стратегии управления пропускной способностью. Существуют ВНУТРЕННИЕ и ВНЕШНИЕ решения по управлению полосой пропускания, помогающие контролировать ICA/RDP в сети. В первой части этой серии статей мы рассмотрим управление трафиком ICA/RDP ВНУТРИ пакетов ICA или ВНУТРЕННИМ, уделяя особое внимание некоторым «старым» или «опытным» методам решения этой проблемы. Имейте в виду, что необходим целостный подход как ВНУТРЕННИХ, так и ВНЕШНИХ решений. На самом деле мало пользы от реализации всех рекомендаций в этой статье только для того, чтобы ВНЕШНЕЕ FTP-приложение раздавило сеть и, например, отключило наши соединения ICA.

В современных (последние пару лет) реализациях служб терминалов Windows весь трафик сеанса (будь то ICA или RDP) инкапсулируется в кадр TCP (или дейтаграмму), который отправляется по сети вместе с остальным трафиком. Таким образом, в сети пакет ICA, содержащий обновления экрана, не имеет «ощутимого» отличия от следующего пакета ICA, содержащего, например, задание на печать. На первый взгляд это кажется «не проблемой», пока мы не посмотрим на «гибкость» сеанса на проводе.

Если мы предположим, что типичный сеанс ICA/RDP потребляет около 20-30 кбит/с в активном состоянии, мы можем довольно легко провести математику и увидеть, что обычное сетевое соединение со скоростью 100 Мбит/с может поддерживать МНОГО одновременных активных сеансов. Там, где это становится проблемой проектирования, является глобальная сеть или удаленные пользователи. Задайте себе этот вопрос. Был ли у меня когда-либо удаленный офис, в котором сеансы ICA в 90% случаев работали нормально, но иногда у нас были периоды ДЕЙСТВИТЕЛЬНО медленных сеансов или, возможно, даже прерываний сеансов? Если это ваша сеть, вам может понадобиться использовать управление пропускной способностью. «Малоизвестный факт» о соединениях ICA/RDP заключается в том, что скорость 20-30 кбит/с соответствует ЕЖЕДНЕВНОМУ среднему значению… она НЕ включает случайные МОНОЛИТНЫЕ задания на печать, которые выполняются, например, через ICA или веб-браузер на веб-сайтах с интенсивной графикой. Когда пользователи обращаются к таким сайтам или распечатывают большие задания внутри ICA/RDP, количество пакетов ICA (и передача данных) увеличивается ДРАМАКТИЧЕСКИ! В локальной сети это обычно не проблема, но в глобальной сети или удаленно последствия могут быть катастрофическими. Это может привести к задержке и «скачкам» в канале, что УБИВАЕТ производительность протоколов уровня представления.

Итак, мы рассмотрим методы, доступные с Citrix Presentation Server 4.0 (извините, только пользователи служб терминалов, просто пока недостаточно способов улучшения протокола, чтобы писать о них статью). Опять же, в этой статье и практических рекомендациях мы сосредоточимся на том, что мы можем сделать «изначально» с помощью Presentation Server и ICA для управления использованием полосы пропускания. В основном существует три «подметода» для ВНУТРЕННЕГО контроля над тем, как ICA работает в сети:

1. МАРКИРОВКА ПАКЕТОВ ПРИОРИТЕТА ICA
2. НАСТРОЙКА СВОЙСТВ THINWIRE ДЛЯ ДАННОГО СЕРВЕРА
3. ПОЛИТИКА CITRIX

ПРИМЕЧАНИЕ:
Несмотря на то, что политика Citrix сегодня является предпочтительным методом, мы сохраним его для второй части этой серии, поскольку это тема, требующая целой статьи!

МАРКИРОВКА ПАКЕТОВ ПРИОРИТЕТА ICA

ICA PRIORITY PACKET TAGGING — это функция, которую Citrix использует внутри пакета ICA. По сути, в стандартном пакете ICA доступно 32 виртуальных канала. Из 32 доступных только около 6-10 фактически используются во время типичного сеанса Citrix (и многие никогда не использовались, поскольку они нужны разработчикам для расширения протокола). Примером использования виртуального канала может быть перенаправление диска или возможность подключения и использования локального диска на стороне клиента во время сеанса ICA. Многие «функции» ICA имеют несколько доступных виртуальных каналов, таких как печать. Каждому из 32 виртуальных каналов ICA присваивается приоритет важности «по умолчанию» для передачи и повторной сборки на другом конце… идея состоит в том, что обновления экрана должны быть БОЛЕЕ важными, чем, скажем, звук. Поэтому несколько лет назад Citrix заключила партнерское соглашение с CISCO и некоторыми другими производителями известных брендов, чтобы позволить их устройствам QoS «видеть» пакеты ICA и позволить умным парням изменять приоритет пакетов при их прохождении через коммутаторы для лучшего соответствия сети. дизайн. Для получения дополнительной информации по этому вопросу я рекомендую вам ознакомиться с литературой по QoS, предоставленной производителем вашего коммутатора/маршрутизатора. Но, прежде чем вы слишком углубитесь в это восхитительное чтение, я дам вам знать, что пользователи Presentation Server 3 и 4, у которых включен протокол надежности сеанса (то есть большинство из вас и не без оснований), вы НЕ сможете используйте функцию QoS ваших аппаратных устройств, чтобы больше «читать» пакеты ICA. Похоже, что Session Reliability «отключает» возможность чтения в ICA-пакете информации о тегах. Итак, для тех из вас, кто все еще хочет попробовать этот вариант, есть в основном один способ сделать это — отредактировать реестр на ваших серверах презентаций. В следующей таблице описываются различные виртуальные каналы ICA, их приоритеты по умолчанию (что может быть весьма поучительно), а затем в следующем разделе описывается метод, с помощью которого вы можете их настроить. Имейте в виду, что вы должны ТЩАТЕЛЬНО протестировать эти изменения в своих лабораториях, прежде чем внедрять их в свою производственную среду. Кроме того, ознакомьтесь с информацией, доступной по этому вопросу в базе знаний Citrix, поскольку определения виртуальных каналов и приоритеты по умолчанию могут быть изменены.

Виртуальный канал	Приоритет по умолчанию	Описание
CTXTW	0	Обновление экрана удаленного сеанса (THINWIRE)
CTXWI	0	Плавное обновление экрана Windows (THINWIRE)
CTXCLIP	1	буфер обмена
CTXCAM	1	Сопоставление аудио клиента
CTXLIC	1	Управление лицензиями
CTXVFM	1	Видеосервер (умер — помните VideoFrame?)
CTXPN	1	Программное соседство
CTXCCM	2	Сопоставление клиентских COM-портов
CTXCDM	2	Сопоставление клиентских дисков
CTXCM	3	Управление клиентами (автоматическое обновление)
CTXLPT1	3	Сопоставление принтеров для клиентов без буферизации
CTXLPT2	3	Сопоставление принтеров для клиентов без буферизации
CTXCOM1	3	Сопоставление принтеров для клиентов без буферизации
CTXCOM2	3	Сопоставление принтеров для клиентов без буферизации
CTXCPM	3	Сопоставление принтеров для клиентов буферизации (почти всех)

Таблица 1: Краткий список некоторых виртуальных каналов ICA по умолчанию

Чтобы настроить параметры данного сервера, нужно просто отредактировать следующий раздел реестра:

HKLMSystemCurrentControlSetControlTerminal ServerWdsicawdPriority

Просто отредактируйте значение PRIORITY REG MUTLI STRING, чтобы оно содержало виртуальные каналы с их желаемыми настройками, как показано ниже.

CTXCOM1,1
CTXLPT1,2
CTXCLIP,3
CTXPN,0

ПРИМЕЧАНИЕ:
«Имя канала» должно состоять из 7 символов, в противном случае вы должны дополнить значение завершающими пробелами, как показано выше, с помощью CTXPN!

НАСТРОЙКИ ДИСПЛЕЯ и ПРОПУСКНОЙ ПОЛОСЫ ПРИНТЕРА

ICA Display раньше назывался Thinwire; названный так в честь виртуального канала Thinwire, который управлял обновлениями экрана, перерисовкой и обновлением. Парням из отдела маркетинга, должно быть, не понравилось название Thinwire, поэтому оно было уничтожено примерно в то же время, когда MetaFrame 1.8 исчез из поля зрения. В любом случае, следующий вариант управления пропускной способностью можно найти в двух вариантах: параметры уровня FARM и затем индивидуальная настройка тех же параметров на серверах, которые являются членами фермы. Для краткости рассмотрим только настройки уровня фермы.

Первая из этих настроек — это настройки дисплея ICA, как показано на рис. 1 ниже.

Рисунок 1: Настройки ICA на уровне фермы

Раздел вокруг ICA DISPLAY, как показано выше со стрелкой, позволяет настроить параметры ICA Display или «Thinwire» для всех серверов в ферме. Как правило, перечисленных здесь настроек достаточно для большинства сред, но иногда вам может понадобиться внести в них некоторые «настройки». Таблица 2 описывает функцию и плюсы и минусы настроек.

Параметр	По умолчанию	Когда использовать
Откажитесь от избыточных графических операций	ВКЛЮЧЕНО	Отличная функция, устраняющая множество «ненужных» перерисовок экрана. Основная предпосылка заключается в том, что ТОЛЬКО та часть экрана, которая изменилась, будет «передаваться», что значительно снижает необходимую пропускную способность. Вот почему «анимация» может вызвать ОГРОМНЫЕ проблемы с пропускной способностью через сеанс (например, JavaScript для прокрутки баннеров на веб-сайтах!) РЕКОМЕНДУЕМАЯ НАСТРОЙКА – ВКЛЮЧЕНО КОГДА ИЗМЕНЯТЬ – НЕКОТОРЫЕ приложения, которые могут использовать сильно настроенный «рендеринг», могут не отображать информацию правильно, если это включено… таким образом, отключение заставит приложение работать правильно. Имейте в виду, что это параметр ВСЕЙ ФЕРМЫ, который влияет на КАЖДЫЙ сеанс на КАЖДОМ сервере.
Альтернативный метод кэширования	ВКЛЮЧЕНО	Еще одно большое улучшение продукта PS (хотя он существует уже некоторое время). По сути, эта функция изменяет «способ» отображения экрана, а не сверху вниз, слева направо… она позволяет хорошо работать с «многостраничными» приложениями, такими как веб-сайты, таким образом, «только» показывая экран пользователю, когда ВСЯ страница готова к просмотру (это избавляет нас от рендеринга экрана, прокрутки страницы, ожидания, рендеринга экрана, прокрутки страницы, ожидания и т. д.) РЕКОМЕНДУЕМАЯ НАСТРОЙКА – ВКЛЮЧЕНО КОГДА ИЗМЕНЯТЬ – За последние несколько лет не наблюдалось веских причин для изменения.
Максимальный объем памяти, используемый для графики каждого сеанса в килобайтах	5625	Давным-давно Citrix и Microsoft решили, что 5,5 МБ ОЗУ «достаточно» для создания виртуальной видеокарты для каждой сессии. Именно это «ограничение» определяет максимальные настройки разрешения и комбинации цветовой палитры. По сути, именно поэтому вы не можете запустить сеанс с 32-битным цветом и разрешением 1600×1200. РЕКОМЕНДУЕМАЯ НАСТРОЙКА – 5625 (макс.) КОГДА ИЗМЕНЯТЬ — Если вы используете приложение 256 Color, которое работает с разрешением 800 × 600, вы можете «уменьшить это», чтобы сэкономить НЕБОЛЬШОЙ объем памяти за сеанс.
Предвзятость деградации	СНАЧАЛА УНИЧТОЖИТЬ РАЗРЕШЕНИЕ	Это просто говорит серверу «настроить» параметры для пользователя DOWN, чтобы они соответствовали «виртуальным» видеокартам с 5,5 МБ ОЗУ. РЕКОМЕНДУЕМАЯ НАСТРОЙКА — зависит от среды, если приложения публикуют изображения или настольные компьютеры, обычно лучше сначала уменьшить «разрешение», если это приложения для работы с электронными таблицами или диаграммами, предпочтительными настройками обычно являются уменьшение цветов
Уведомлять пользователя о деградации сеанса	ВКЛЮЧЕНО	Делает то, что говорит… РЕКОМЕНДУЕМАЯ НАСТРОЙКА — во многих средах отключите это… это просто еще одно «всплывающее окно», о котором пользователи могут открыть тикет в службу поддержки?

Таблица 2: Краткий список некоторых виртуальных каналов ICA по умолчанию

Последними настройками уровня FARM, на которые я бы порекомендовал обратить внимание, будут функции SPEEDSCREEN для УСКОРЕНИЯ БРАУЗЕРА, УСКОРЕНИЯ FLASH и УСКОРЕНИЯ МУЛЬТИМЕДИА. Мы рассмотрим эти функции более подробно в следующей статье (и в некоторой степени будем управлять ими с помощью политики), поэтому я приберегу «кровавые» подробности до тех пор. Единственное, что я хочу отметить здесь, это то, что ОБЫЧНО клиенты выигрывают от включения этих функций и что эти функции существуют в большей или меньшей степени в зависимости от версии Presentation Server, развернутой в вашей среде.

Последний параметр FARM LEVEL (хотя на самом деле это SERVER by SERVER), на который мы можем обратить внимание, это пропускная способность принтера. Это ДЕЙСТВИТЕЛЬНО хорошие настройки для «CAP» по всем направлениям, так как по умолчанию он не ограничен. Итак, чтобы освежить ваше мнение о том, ПОЧЕМУ мы хотели бы ограничить это… У меня есть 15 пользователей в удаленном месте через канал ISDN. Производительность всех сеансов приемлема до тех пор, пока кто-нибудь не начнет печатать, после чего все сеансы зависают (или прерываются) до тех пор, пока задание печати не будет завершено. Итак, управление пропускной способностью принтера через ICA — отличная идея! Это ОЧЕНЬ легко сделать, просто перейдите в Presentation Server Management Console к узлу Printer Management, а затем выберите вкладку Bandwidth. Посмотрите на рисунок 2, который содержит функцию «редактирования» инструмента.

Рис. 2. Настройки пропускной способности принтера на уровне фермы

Я бы рекомендовал установить «лимит» на это, основываясь на нескольких факторах… и это скорее «искусство, чем наука». Некоторыми из факторов могут быть тип заданий на печать, расположение клиентов и принтеров, на которые они будут печатать, а также уровень «допуска», чтобы замедлить задание, чтобы не повредить сеть, но не разозлить пользователя, ожидающего печати. выход!

В большой ферме вы можете отредактировать один сервер, а затем просто КОПИРОВАТЬ настройку на все остальные серверы. Теперь я большой поклонник этой функции, и она существует уже в нескольких версиях, но я укажу на несколько ограничений.

1. Ограничение пропускной способности печати работает ТОЛЬКО для печати ЧЕРЕЗ ICA (поэтому, если Presentation Server печатает НЕПОСРЕДСТВЕННО на локально подключенный принтер на сервере (редко) или в СЕТЕВУЮ ОЧЕРЕДЬ ПЕЧАТИ (обычно), то он НЕ будет контролировать пропускную способность — только через соединения ICA. (обычно автоматически созданные принтеры)
2. Этот параметр влияет на ВСЕХ пользователей, которые используют сервер конфигурации… поэтому пользователи локальной сети, которые МОГУТ не нуждаться в дросселировании, ТАКЖЕ будут ограничены!

Как указывалось ранее, в зависимости от вашей версии Presentation Server у вас будет больше или меньше функциональных возможностей с этой функцией. В следующей статье мы рассмотрим НАМНОГО превосходный метод (доступный для пользователей PS 3 и 4) использования политики Citrix для управления пропускной способностью печати (и другими типами трафика) для каждого пользователя, сети за сетью, или по принципу «соединение за соединением»… так что ждите долгожданного продолжения в следующем месяце!

Вывод

Мы впервые рассмотрели управление полосой пропускания и рассмотрели некоторые типичные сценарии реализации такого решения. В этой статье, первой из серии, мы рассмотрели исторический способ (и в некоторых случаях до сих пор лучший) управления пропускной способностью с использованием ВНУТРЕННИХ методов, встроенных в продукт. В следующих статьях этой серии мы более подробно рассмотрим новинку в этом блоке, политику Citrix для контроля всех аспектов ВНУТРЕННЕГО управления полосой пропускания и ВНЕШНИХ решений для управления полосой пропускания в сети в целом.