Управление нагрузкой Citrix Presentation Server — Часть 3: Оценщики нагрузки

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

Введение

Из всех компонентов подсистемы управления нагрузкой оценщики нагрузки и правила оценщиков нагрузки, вероятно, понимаются чаще всего. Довольно часто фермы Citrix Presentation Server используют оценщик нагрузки «по умолчанию», и часто администраторы даже не подозревают, что этот оценщик нагрузки используется. Если для Presentation Server специально не назначены оценщики нагрузки, к этому конкретному серверу будет автоматически применен оценщик нагрузки «по умолчанию». Подходит ли оценщик нагрузки «по умолчанию» для большинства сред Presentation Server? В большинстве случаев ответ на этот вопрос «нет», но есть исключения, которые следует изучить более подробно.

предоставленные Citrix оценщики нагрузки; Использовать или не использовать, вот в чем вопрос!

В базовой установке версий Presentation Server Advanced и Enterprise присутствуют два оценщика нагрузки; «По умолчанию» и «Дополнительно». Оценщик нагрузки «по умолчанию» состоит из одного правила «Нагрузка пользователей сервера» и является синонимом балансировки нагрузки «циклического перебора» в мире DNS. При установленном оценщике нагрузки «По умолчанию» единственными критериями, которые подсистема управления нагрузкой будет использовать при определении нагрузки на сервер, или «Оценка» является просто количество текущих сеансов ICA, запущенных на сервере. Оценщик нагрузки «по умолчанию» использует максимальное значение 100 сеансов, что означает, что полная нагрузка (значение нагрузки 10 000) достигается, когда конкретный сервер имеет 100 сеансов. Поскольку Citrix решила использовать красивое круглое число, такое как 100, становится довольно легко рассчитать, как это будет экстраполировать от нуля сеансов до 100 сеансов. Значение нагрузки будет 2500 при 25 активных сессиях, 5000 при 50 активных сессиях, 7500 при 75 активных сессиях и т.д. В фермах, где все серверы состоят из одной аппаратной конфигурации (количество процессоров, скорость процессора, объем памяти), И одни и те же приложения установлены на каждом сервере, И каждое приложение публикуется на всех серверах, И все пользователи используют все приложения одинаково, вероятно, будет достаточно оценщика нагрузки «по умолчанию». Однако имейте в виду, что оценщик нагрузки «по умолчанию» ничего не делает для учета того, как используются ресурсы, такие как процессор и память; его интересует только количество сеансов. Например, если два сервера имеют 25 и 26 активных сеансов соответственно и генерируется запрос на новый сеанс, сервер с 25 сеансами будет хостом этого нового сеанса. Вот так; даже если у сервера с 25 сеансами загрузка процессора на 50 процентных пунктов выше, чем у сервера с 26 сеансами, оценщик нагрузки «по умолчанию» «сбалансирует» нагрузку, заставив оба сервера обслуживать по 26 сеансов каждый.

Прежде чем приступить к отмене назначения оценщика нагрузки «по умолчанию» для всех ваших серверов Presentation Server, давайте рассмотрим второй из оценщиков нагрузки, поставляемых Citrix, «расширенную» модель. Большинство опытных администраторов Citrix согласятся с тем, что двумя наиболее важными ресурсами сервера Citrix являются процессор и память. Поскольку «Расширенный» оценщик нагрузки содержит оба этих правила (в дополнение к правилу «Замены страниц»), он должен быть билетом, верно? Оценщик нагрузки «Расширенный» действительно приводит к более интеллектуальному управлению нагрузкой по сравнению с оценщиком нагрузки «По умолчанию», поскольку сильно взвешивает два наиболее важных ресурса на Presentation Server. На самом деле, в некоторых случаях «Расширенный» оценщик нагрузки может быть частью очень успешной стратегии управления нагрузкой. Тем не менее, можно привести аргумент в отношении максимальных значений правил «Использование ЦП» и «Использование памяти», настроенных в «Расширенном» оценщике нагрузки, поскольку они оба установлены на 90%. Этот аргумент будет основан на том, что эти значения слишком высоки; что как только сервер достиг и поддерживает 90% любого из этих двух ресурсов, пользователи на этом конкретном сервере уже будут испытывать снижение производительности. Сервер презентаций, работающий с исчерпанием ресурсов процессора или памяти на 90 %, не обеспечит высокого качества взаимодействия с пользователем.

В какую сторону мы должны повернуть? Пользовательский оценщик нагрузки

Теперь были представлены аргументы против обоих предоставленных Citrix оценщиков нагрузки, оставив нас для размышлений, в какую сторону мы должны повернуть? Лучшей альтернативой является создание собственного пользовательского оценщика нагрузки с использованием правил оценщика нагрузки и максимальных значений, наиболее оптимальных для вашей текущей среды. Затем примените этот настраиваемый оценщик нагрузки к своим серверам презентаций, отслеживайте использование ресурсов и распределение нагрузки сеансов и настраивайте правила и/или значения оценщика нагрузки до тех пор, пока не будет достигнута нирвана балансировки нагрузки. Этот метод обеспечит более справедливое распределение сеансов по отношению к ресурсам сервера, а при наличии надлежащих максимальных значений также предотвратит перегрузку любых серверов в ферме.

Чтобы создать оценщик функциональной нагрузки, необходимо понять, как применяются правила оценщика нагрузки и как работают отдельные правила. На рис. 1 показан список доступных правил оценки нагрузки в консоли Citrix Presentation Server. Обратите внимание, что выбор определенного правила вызывает объяснение этого конкретного правила, как показано на рисунке 2. Это быстрый и простой способ узнать больше об отдельных правилах. Кроме того, правила обсуждаются в учебных курсах Citrix CTX-1256BI и в Load_Manager_Guide.pdf, который можно найти в «Document Central» на самом Presentation Server.

фигура 1

фигура 2

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

Осторожно: могут применяться несколько оценщиков нагрузки

Еще одной характеристикой оценщиков нагрузки является то, что их можно применять к серверам и опубликованным приложениям. Вы можете одновременно применять только один оценщик нагрузки либо к серверу, либо к опубликованному приложению; однако это не означает, что существует жесткое ограничение только одного оценщика нагрузки, применяемого на данном сервере. Рассмотрим сценарий, в котором создано десять оценщиков нагрузки, и первый оценщик нагрузки применяется к серверам в ферме. На данный момент все в порядке, но ненадолго, как вы увидите! Следующие шаги в этом сценарии состоят в применении каждого из оставшихся девяти оценщиков нагрузки к девяти опубликованным приложениям соответственно. При отсутствии пользовательских сеансов на сервере будет действовать один оценщик нагрузки; тот, который применяется к серверам. Однако, если пользовательские сеансы, присутствующие на этом конкретном сервере, запускают все девять опубликованных приложений на этом сервере, внезапно все десять оценщиков нагрузки будут действовать, и правило «не усложняй» будет нарушено. Представьте, насколько сложной была бы эта ситуация, если бы к каждому опубликованному приложению в ферме применялись отдельные оценщики нагрузки. Результатом будет полностью нефункциональная подсистема управления нагрузкой и, в конечном счете, серьезное влияние на производительность конечного пользователя.

Мониторинг процесса управления нагрузкой

После реализации разумной стратегии управления нагрузкой остается только эффективно контролировать этот процесс, чтобы гарантировать, что применяемая стратегия соответствует вашим целям. К счастью, Citrix предоставляет несколько инструментов для отслеживания процесса управления нагрузкой и обеспечения его оптимального состояния. Наименее полезные инструменты находятся в консоли Presentation Server; «Журнал диспетчера нагрузки», который находится на вкладке «Журнал» в узле «Оценщики нагрузки», и «Монитор диспетчера нагрузки», который находится на вкладке «Монитор диспетчера нагрузки» в свойствах конкретного сервера. Служба ведения журнала «Журнал диспетчера нагрузки» по умолчанию отключена, и ее необходимо включить вручную, чтобы начать сбор данных. Кроме того, файл журнала имеет жестко запрограммированное ограничение размера и не обеспечивает автоматической очистки старых данных; как только файл журнала заполнен, ведение журнала прекращается. Ведение журнала не начнется снова, пока файл журнала не будет вручную сохранен в другой файл и очищен. На рисунке 3 показаны варианты выбора «Журнал» в меню «Действия». Как видите, ведение журнала должно быть включено администратором, а журнал необходимо сохранять и очищать вручную.

Рисунок 3

«Монитор диспетчера нагрузки» предоставляет график оценщиков нагрузки, применяемых к конкретному серверу, по одному серверу за раз. График также можно просмотреть в окне, отдельном от консоли Presentation Server, но он дает слабое представление об управлении нагрузкой по сравнению с другими доступными инструментами.

Наиболее полезными инструментами для отслеживания процесса управления нагрузкой являются инструменты командной строки. Команда «QFARM /LOAD» обеспечивает просмотр в режиме реального времени серверов презентаций и соответствующих им значений нагрузки. На рис. 4 показан результат выполнения этой команды в простой ферме из двух серверов:

Рисунок 4

Еще один очень полезный инструмент командной строки — «QueryDS.exe». К сожалению, этот инструмент не установлен вместе с Presentation Server. Он расположен вместе с несколькими другими инструментами командной строки на компакт-диске Presentation Server в разделе «Supportdebugw2k3» для носителя с Windows 2003 или «Supportdebugw2k», если вы используете носитель с Windows 2000. Просто скопируйте этот файл на свои серверы презентаций, чтобы раскрыть его потенциал. QueryDS может запрашивать данные, содержащиеся в сборщиках данных, относительно подсистемы управления нагрузкой (LMS). Три таблицы, которые могут быть запрошены:

1. «LMS_AppLoadTable» — информация об управлении нагрузкой для опубликованных приложений. Эта таблица будет содержать данные только в том случае, если к опубликованному приложению применяется оценщик нагрузки.
2. «LMS_ServerLoadTable» — показывает текущее значение нагрузки для всех серверов в зоне, а также применяемые правила и текущее значение для каждого правила.
3. «LMS_LicensedServerTable» — предоставляет список всех лицензированных серверов в ферме и зону, членом которой является каждый сервер.

Рисунок 5 — результат выполнения следующей команды: «queryds /table:LMS_ServerLoadTable». Обратите внимание на две очень важные вещи; имена таблиц чувствительны к регистру, а две из трех таблиц отображают информацию только для локальной зоны. Единственная таблица, в которой будут отображаться данные из более чем одной зоны, — это «LMS_LicensedServerTable». Нет возможности указать зону, которую вы хотите запросить; QueryDS всегда запрашивает локальный сборщик данных. Аргумент «/query» позволяет фильтровать вывод на основе определенной желаемой информации. Указание аргумента «/query» и передача вывода команды QueryDS в утилиту, такую как «grep» или «findstr», может предоставить мощный метод мониторинга процесса управления нагрузкой.

Рисунок 5

Как вы можете видеть, QueryDS в режиме реального времени предоставляет информацию о значениях нагрузки для всех серверов в данной зоне, выходя за рамки только общего значения нагрузки на сервер и определяя отдельные правила и то, как каждое правило влияет. На рис. 5 выше мы можем см., что к этому конкретному серверу применяются 2 правила оценки нагрузки; правило № 3 (использование памяти) имеет значение 64, а правило № 1 (использование ЦП) имеет значение 0. Сравнение этих данных с информацией, собранной с помощью Windows Performance Monitor или Citrix Resource Manager, позволит вам судить о том, насколько эффективно ваше управление нагрузкой стратегия работает по плану. Дополнительными инструментами, предоставляемыми Citrix, являются утилита CTXtrace и ее аналог с графическим интерфейсом Common Diagnostic Facility, присутствующий в консоли Access Suite. Эти инструменты довольно сложны для эффективного использования и выходят далеко за рамки этой статьи, но вы должны знать, что эти опции существуют, если вам нужно глубже изучить процесс управления нагрузкой.

Вывод

Эта серия из трех частей дает представление о внутренней работе подсистемы управления нагрузкой, которая имеет решающее значение для успешного развертывания Citrix Presentation Server. Лучшее понимание компонентов, влияющих на управление нагрузкой, а также предложения по созданию и мониторингу успешной стратегии управления нагрузкой должны предоставить администраторам Citrix информацию, необходимую для решения этой небольшой, но мощной части среды Citrix Presentation Server.