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

Published on Февраль 19, 2009 by   ·   Комментариев нет

Управление пропускной способностью — одна из наиболее сложных проблем, с которой сталкиваются компьютерные инженеры. Протоколы уровня представления, как ICA и RDP, очень чувствительны к латентности и устойчивости ссылок. Данная статья является первой из серии, посвященной Управлению пропускной способностью.

Вступление

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

ICA и RDP являются довольно надежными типами протоколов уровня представления на наших корпоративных LAN/WAN. Однако протоколы данного типа чрезвычайно чувствительны к латентности и стабильности соединений. Поэтому, мы, как компьютерные архитекторы, должны усилить соответствующую сторону нашей системы. Существуют две основные стратегии Управления пропускной способностью: ВНУТРЕННЯЯ и ВНЕШНЯЯ, помогающие сохранять контроль над ICA/RDP в сети. В серии данных статей мы рассмотрим контролирование трафика ICA/RDP ИЗНУТРИ Пакетов ICA, (ВНУТРЕННИЙ способ), рассматривая некоторые старые испытанные способы. Помните, что подчас необходимо знание как ВНУТРЕННЕГО так и ВНЕШНЕГО способов. Будет довольно непрактично рассмотреть только ВНЕШНИЕ приложения FTP и оставить без внимания соединения ICA.

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

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

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

  1. Приоритетное тегирование пакетов в ICA
  2. Установка МАЛОПРОВООДНОГО соединения для выбранного сервера
  3. Политика CITRIX

Запомните:
Так как предпочтительным методом в настоящее время является Политика Citrix, мы оставим для данного метода целую статью и не будем его касаться в настоящем выпуске!

Приоритетное тегирование пакетов в ICA

Citrix осуществляет данный метод «изнутри» Пакета ICA. В принципе, в стандартном пакете ICA доступно 32 виртуальных канала, из которых лишь 6-10 действительно используются на реальных сессиях Citrix (остальные практически не используются, а присутствуют для возможности подключения внешних протоколов). Примером использования виртуального канала может служить переадресация или возможность подключения и использования локального клиента в ходе сессии ICA. Различные ‘характеристики’ ICA имеют множественные виртуальные каналы подключения (к примеру — распечатка). Каждый из 32 каналов снабжен преимущественными установками ‘по умолчанию’ для осуществления передачи и сборки на противоположном конце сети… Идея заключается в том, что обновления для экрана должны быть БОЛЕЕ важные, нежели для аудио. Так, несколько лет назад, Citrix объединился с CISCO и некоторыми другими известными производителями в целях «разрешения» отображения их устройств QoS в пакете ICA и «позволения» the smart guys изменять приоритетные установки пакетов для обеспечения лучшего сетевого дизайна. Для получения большей информации я рекомендую Вам пересмотреть литературу о QoS, предоставленную соответствующим производителем. Однако, пока Вы не углубились в эту тему, я скажу Вам, что пользователи Presentation Server 3 и 4 с активированным протоколом надежности сессии (те., большая часть таких же пользователей, как и Вы) НЕ могут использовать установки соответствующих устройств QoS для «чтения» содержимого пакетов ICA. Похоже, Надежность сессии деактивирует способность считывать содержимое пакетов ICA для тегирования информации. Поэтому, если кто-то из Вас захочет удалить данную опцию, ему следует воспользоваться опцией редактирования реестра Серверов представления. Нижеприведенная таблица отображает различные виртуальные каналы ICA, их возможности по умолчанию (которые могут быть с легкостью изменены), а следующая секция содержит методы управления ими. Пожалуйста, помните, что Вы должны ТОЧНО протестировать все произведенные изменения перед их непосредственным применением в серверной среде. Также просмотрите всю доступную информацию по данному поводу в Базе данных Citrix, разъясняющей значения виртуальных каналов и их свойства.

Виртуальный канал Величина по умолчанию Описание
CTXTW 0 Обновление экрана при удаленной сессии (МАЛОПРОВОДНОЕ)
CTXWI 0 Цельное обновление экрана Windows (МАЛОПРОВОДНОЕ)
CTXCLIP 1 Буфер
CTXCAM 1 Отображение аудио клиента
CTXLIC 1 Управление лицензиями
CTXVFM 1 Видеосервер (Заблокирован – запомнить видеорамку? )
CTXPN 1 Соотнесенность программ
CTXCCM 2 Отображение порта клиента COM
CTXCDM 2 Отображение драйвера клиента
CTXCM 3 Управление клиентом (автообновление)
CTXLPT1 3 Отображение принтера для клиентов, не использующих спулер печати (Non-Spooling Clients)
CTXLPT2 3 Отображение принтера для клиентов, не использующих спулер печати (Non-Spooling Clients)
CTXCOM1 3 Отображение принтера для клиентов, не использующих спулер печати (Non-Spooling Clients)
CTXCOM2 3 Отображение принтера для клиентов, не использующих спулер печати (Non-Spooling Clients)
CTXCPM 3 Отображение принтера для клиентов, использующих спулер печати (Spooling Clients) (практически все)

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

Для регулирования установок выбранного сервера следует лишь отредактировать ключ реестра:

HKLM\System\CurrentControlSet\Control\Terminal Server\Wds\icawd\Priority

Нужно лишь отредактировать значение ПРИОРИТЕТНОГО REG MUTLI STRING для наделения указанных виртуальных каналов желаемыми характеристиками, как:

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

ПОМНИТЕ:
“Имя канала” должно содержать 7 символов, в противном случае Вам следует разгрузить величину хвостовыми пробелами, как в случае с CTXPN!

Установки пропускной способности для Дисплея и Принтера

Дисплей ICA относится к Виртуальному малопроводному каналу, контролирующему обновления экрана, и его перестройку. Некоторым не нравится наименование «малопроводной», поэтому оно было исключено из нашего лексикона вместе с отказом от использования MetaFrame 1.8. В любом случае, следующая опция управления пропускной способностью может быть найдена на двух уровнях: в установках уровня ФЕРМЫ и регулировках установок на сервере независимо от фермы. В целях экономии времени мы рассмотри лишь первый из указанных уровней.

Первая установка — Дисплей ICA — отображена на Рисунке 1.

Картинка монтажа фермы

Рисунок 1: Установки ICA уровня ФЕРМЫ

Секция ICA DISPLAY со стрелкой позволяет Вам регулировать установки Дисплея для всех серверов Фермы. Данные установки применимы в большинстве сред, однако, в некоторых случаях Вы можете их отрегулировать. Таблица 2 отображает принципы, плюсы и минусы подобной регулировки.

Установка

Значение по умолчанию

Когда использовать

Графические операции с устранением ненужных функций

АКТИВИРОВАНО

Превосходная характеристика, устраняющая большое количество ненужных обновлений экрана. Главное условие заключается в том, что только изменяющаяся секция экрана будет загружать буфер. Вот почему продукты, с часто меняющимся экраном, могут повлечь ОГРОМНУЮ загруженность буфера во время сессии (к примеру, Java для баннеров на web-сайтах!)

РЕКОМЕНДУЕМАЯ УСТАНОВКА – АКТИВАЦИЯ

КОГДА ИЗМЕНЯТЬ – НЕКОТОРЫЕ приложения могут работать некорректно при передаче информации с данной активированной опцией… Деактивация определит корректную работу всех приложений. Помните, что это—установка ФЕРМЫ, которая будет вводиться в действие КАЖДУЮ сессию на КАЖДОСМ сервере.

Метод альтернативного кэширования

АКИВИРОВАНО

Еще одно замечательное улучшение продукта PS. Данная опция изменяет «способ» отображения экрана вместе привычного сверху—вниз—влево—вправо… данная опция прекрасно совместима с мультистраничными приложениями, как web-сайты, отображая экран пользователю только при загрузке ВСЕЙ страницы целиком (Это избавляет нас от переворачивания страниц, долгого ожидания и т.п.)

РЕКОМЕНДУЕМАЯ УСТАНОВКА — АКТИВИРОВАНО

КОГДА ИЗМЕНЯТЬ – нет никаких причин в изменении установок данной опции.

Максимальный объем памяти в кб для каждой графической сессии

5625

Очень давно Citrix и Microsoft решили, что объем в 5,5 Мб оперативной памяти достаточен для создания виртуальной видео карты для каждой сессии. Данное ограничение серьезно сужает максимум возможного разрешения и цветовой гаммы. Вот почему вы не можете загружать сессии с цветами 32 бита и разрешением 1600×1200.

РЕКОМЕНДУЕМАЯ УСТАНОВКА — 5625 (максимальное значение)

КОГДА ИЗМЕНЯТЬ – если вы используете приложение с 256 цветами и разрешением 800×600, то можно снизить установленную величину в целях экономии памяти для каждой сессии.

Снижение значения установок

СНАЧАЛА СНИЗИТЬ РАЗРЕШЕНИЕ

Установки сервера снижаются до оптимальных для пользователя, исходя из положенных 5,5 Мб памяти виртуальной видео карты.

РЕКОМЕНДУЕМАЯ УСТАНОВКА – Зависит от конкретной среды использования. Если приложения являются картинками, то снижение разрешения — наилучший способ. Однако если приложения представляют собою крупноформатные таблицы или диаграммы, то следует уменьшить значение цветовой гаммы.

Обращение внимания пользователя на уменьшение значения установок сессии

АКТИВИРОВАНО

Говорит само за себя…

РЕКОМЕНДУЕМЫЕ УСТАНОВКИ – В большинстве рабочих сред следует деактивировать… это лишь еще одно «ухищрение» для того, чтобы обратить внимание пользователей на панель справки.

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

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

Последняя установка уровня Фермы, заслуживающая рассмотрения, это печатная пропускная способность. Это действительно ХОРОШАЯ установка для ‘ограничения печати’, поскольку по умолчанию она не ограничивается в возможностях. Зачем нам нужно это?.. Предположим, у меня есть 15 пользователей по ссылке ISDN. Работа по всем сессиям идет удачно, пока кто-нибудь не начнет делать распечатку. Все сессии сразу же встанут, пока распечатка не будет закончена. Поэтому, ограничение распечатки через ICA действительно хорошая идея! Все ОЧЕНЬ легко сделать: просто переведите Консоль управления сервером представления к узлу Управление Распечаткой и выберите вкладку Пропускная способность. Посмотрите на Рисунок 2, содержащий инструменты «правки».

Способы усиления пропускной способности

Рисунок 2: Установки пропускной способности распечатки уровня Фермы

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

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

  1. Ограничение пропуска распечатки работает ТОЛЬКО при распечатке через ICA (т.е., если Сервер представления посылает данные НЕПОСРЕДСТВЕННО на локальный принтер (редко) или на СЕТЬ ЛОКАЛЬНЫХ ПРИНТЕРОВ (обычно), то контроль пропускной способности производиться НЕ будет).
  2. Установки будут отражаться на ВСЕХ пользователях, использующих сконфигурированный сервер… Так, пользователи локальной сети, которые НЕ ДОЛЖНЫ ограничиваться, ТАКЖЕ будут ограничены по всем параметрам!

Как уже говорилось, в зависимости от Вашей версии Сервера представления, возможно снижение производительности в работе при активации данной опции. В следующей статье мы рассмотрим метод MUCH (доступный для пользователей PS 3 и 4) использования политики Citrix для контролирования пропускной способности печати (и других типов трафика) на пользовательской, сетевой и соединительной базе… Так что ждите до следующего месяца, если хотите узнать больше!

Заключение

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

www.windowsnetworking.com







Смотрите также:

Tags: , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]