Категория: Руководства
Автор: vik_kr Дата: 16 Апрель 2010. Категория: Терминальные технологии
В этой статье я попытался описать технические детали того, как работает балансировка нагрузки в Citrix XenApp.
Источниками вдохновения были статьи на http://support.citrix.com .
Перед прочтением крайне рекомендуется прочитать руководство администратора по Load Manager - CTX112423 – Load Manager Administrator's Guide
Балансировка в Citrix XenApp реализована как плагин к Citrix IMA (Independent Management Architecture). Название этого плагина - Load Management Subsystem (LMS). Основная задача балансировки - распределять терминальные сессии (не пользователей или приложения, а именно терминальные сессии) между серверами фермы XenApp. Процесс выбора, куда направить пользователя для инициализации терминальной сессии происходит в так называемое "Application Resolution Time". "Application Resolution Time" - это время, прошедшее от того когда XML служба инициировала звыбор сервера до выдачи ICA файла (Server Selection на CPS Logon Process Chart от Брайана Мэддэна ).
Было бы глупо и долго, если бы LMS опрашивала все сервера фермы при обращении каждого пользователя, поэтому в Datastore хранятся значения текущей загрузки для каждого из серверов фермы. Это значение называется "Load Index" и может быть от 0 до 10000. При запуске приложения выбирается сервер с минимальным значением Load Index. Текущее значение Load Index можно посмотреть с помощью команды qfarm /load. Если разделить "Load Index" на 100, мы получим текущую загрузку сервера в процентах, именно это число можно увидеть в консоли CMC
в данном примере сервер загружен только на 3%.
намного больше информации можно получить воспользовавшись очень полезной утилитой queryds, которую можно скачать по адресуhttp://support.citrix.com/article/ctx106318 .
так, запустив на том же сервере команду queryds /table:LMS_ServerLoadTable мы получим следующие данные:
C:\>queryds /table:LMS_ServerLoadTable
[LMS_ServerLoadTable]: 1 records.
name. 0c20-000c-0000133f
host. MSK-CXA101
zone. 10.72.56.0
RealTimeRules :
RuleLoads. d:0;b:3;
ProtocolMask. 64
00110008. 2
00110007. 0
Load. 12c
что мы здесь видим? Кучу параметров с шеснацетиричными значениями.
Самый простой параметр - Load, именно он и является Load Index. 0x12c = 300
RuleLoads это примененные правила балансировки и их значения.
Правила балансировки выбираются примененным Load Evaluator, ниже указанны их обозначения:
a: Application user load
b: Server User load
d: Load Throttling
1: CPU Utilization
2: Context switches
3: Memory Usage
4: Page Faults
5: Scheduling
6: Page Swaps
7: Disk Data I/O
8: Disk operations
9: IP Range
Из примера видно, что на сервере сейчас 3 пользователя (b:3)
ProtocolMask - это смещение значения нагрузки для Load throttling (о нем позже)
В данном примере был применен Default Load Evaluator, который измеряет только количество пользователей (максимум - 100 пользователей на сервер)
Если же к серверу применить Advanced Load Evaluator, то пример будет интереснее:
C:\>queryds /table:LMS_ServerLoadTable
[LMS_ServerLoadTable]: 1 records.
name. 0c20-000c-0000133f
host. MSK-CXA101
zone. 10.72.56.0
RealTimeRules :
ProtocolMask. c8
00110008
. 2
00110007
. 0
RuleLoads. 1:3e;d:0;6:6;3:24;
Load. 192a
В данном примере метрика CPU Utilization - 0x3e=62, Page Swaps - 0x6=6 и Memory Usage -0x24=36
Load Index при этом 0x192a=6442, т.е. сервер загружен на 65%
Load Index это не среднее всех метрик, он рассчитывается по формуле
LoadIndex = ЗначениеМаксимальнойМетрики*100 + 5%(ОстальныхМетрики*100)
Здесь кроется небольшой подвох - dsquery в поле RuleLoads выдает значенияделенные на 100 и округленные до целого числа, поэтому у нас при проверке не получится совсем точный результат
т.е. в данном случае - 62*100+6*100*0.05+36*100*0.05=6410, что является близким к реальной нагрузке
В качестве метрик для LMS могут выступать два класса метрик:
Спецефичные для XenApp:
Server User Load - количество сессий терминальных служб, здесь считаются не тоько ICA сессии, но и RDP, причем как активные, так и disconnected
Application User Load - количество сессий с определенным приложением, полезно тогда, когда вы хотите ограничить количество экземпляров приложения, запущенного на сервере
Logon Throttling - Метрика, позволяющая "обманывать" LMS завышая рассчитанную нагрузку в момент массовых логонов пользователей
Расписание - тут все просто, выставляете, в какое время суток сервер доступен, в остальное время он будет сообщать о своей полной загрузке
IP Range - с помощью этой метрики вы можете разрешить доступ к серверу только определенным подсетям
Стандартные счетчики производительности
Используются стандартные счетчики производительности, описание деталей доступно в статье http://support.citrix.com/article/ctx111965
Load Evaluator Rule
Главное что нужно помнить, что в метриках выдается не значение счетчика производительности, а значение именно метрики. т.е. если правило Load Evaluator настроено сообщать о 100% нагрузке на сервер при загрузке CPU в 80%, то число 50 в метрике будет говорить о 40% нагрузке на CPU
Метрики хранятся в памяти на Data Collector (DС), они не записываются в DataStore
Инициатором обновления является рядовой сервер, он "пушит" свои метрики на DC
Обновляются метрики в следующих случаях:
при logon или logoff
если метрика изменилась на +/- 500
На DC локальные метрики обновляются каждые 30 секунд
Если рядовой сервер за 1 минуту о себе ничего не сообщил, DC "пингует" по IMA данный сервер, для того чтоб узнать, жив ли тот.
Если обновлений не было 5 минут, DC запрашивает обновление метрик.
За прошлую неделю меня несколько раз спрашивали о сертификации Citrix, о том, какие сертификационные статусы сейчас существуют, какие экзамены, что рекомендуется для подготовки к экзамену.
Ответив на несколько таких запросов, я решил собрать здесь всю информацию, необходимую для ответа на такие вопросы.
В конце этого года компания решила изменить существовавшую систему сертификации, немного дополнив и расширив её.
Существует 2 трека - техническая сертификация и сертификация для продавцов решений. В каждом из этих треков есть различные статусы, о которых я расскажу ниже.
Начну с того, что самую свежую информацию по курсам, экзаменам и сертификации всегда можно получить на сайте - http://www.citrixtraining.com/
Сертификации для продавцов решений, предназначены для Партнёров и являются одним из необходимых условий для получения Партнёрского статуса. Называются эти статусы Citrix Certified Sales Professional (CCSP) с добавлением специализации.
Для получения этих статусов необходимо зарегистрироваться на сайте https://citrix.learning.accenture.com/citrix/lang-default/SYS_login.asp и после регистрации Вы сможете через Интернет прослушать он-лайн курсы, по окончании которых ответить на 15-20 вопросов по прослушанному материалу. Для получения каждого из статусов Вам необходимо обычно прослушать 3 электронных курса и конечно правильно ответить на вопросы.
В случае, если Вы выполните требования для всех 4 статусов CCSP, то автоматически получите 5-ый - CCSP for Application Delivery .
Раньше существовало три вида сертификатов CCA. CCEA и CCIA (Citrix Certified Administrator. Citrix Certified Enterprise Administrator и Citrix Certified Integration Architect ). В этом году компания добавила в этот список ещё два вида сертификатов - CCAA и CCEE (Citrix Certified Advanced Administrator и Citrix Certified Enterprise Engineer ).
Теперь деление по сериям осуществляется таким образом:
Серию для администраторов можно подразделить на треки:
С инженерской серией всё просто: CCEE будет объявлен в первом полугодии 2009 и сейчас существует только CCEA для XenApp (Presentation Server 4). Но для его получения придётся серьезно потрудится.
Архитекторская серия ограничивается только треком CCIA. Для его получения необходимо выполнить следующие требования:
Порядок сдачи здесь приведён условно, т.е. можно сначала сдать дизайн и анализ и только потом пройти он-лайн тест. Хотя на мой взгляд лучше идти так, как предлагает компания Citrix.
Для подготовки к сдаче экзаменов можно воспользоваться следующими ресурсами:
Вместе с изменением сертификационных треков, также произошло изменение названий курсов. Теперь, глядя на название, можно легко понять для кого он предназначен и по какому продукту проводится.
Новые названия курсов будут выглядеть так:
Префикс-Номер-Версия/Тип или на примере - CXA-200-1I .
Префикс - соответствует сокращению от названия продукта:
Исключения: WKS - Workshop и CMB - Комбинированные предложения.
Номер, описывает целевую аудиторию и сложность курса:
С версией наверное всё понятно и без объяснений, а тип означает, как проходит курс - I - проводится инструктором, W - слушается через Интернет.
Существует отдельная сертификация для тренеров. У Citrix она называется Citrix Certified Instructor (CCI) .
У неё есть тоже разделение по продуктам, поэтому для примера, я приведу требования для получения статуса CCI for XenApp 5 for Windows Server 2008 . Для получения этого статуса нужно:
Всё :). После выполнения всех этих пунктов Вы получаете "почётное" звание Citrix Certified Instructor.
Наверное, больше рассказать про сертификацию в общих чертах было бы сложно. Пишите, отвечу и при необходимости - дополню.
Хотя на первый взгляд, архитектура XenApp может показаться сложной в плане поддержки и обеспечения отказоустойчивости основных компонентов и всей платформы в целом. На самом деле, все проще чем кажется.
Если говорить о стандартных ролях Windows Server, таких как Active Directory и DNS. то здесь доступность достигается традиционной репликацией каталога и передачей зон на второстепенный или резервный сервер. Отказоустойчивость SQL-сервера (DataStore) обеспечивается кластеризацией. А постоянную доступность файлового сервера (AppHub) для узлов XenApp можно реализовать разместив копию профилей приложений на другом сервере и настроив DFS (Distributed File System). Все приведенные выше методики, давно известны и применяются повсеместно, не только с продуктами Citrix, по этому говорить об этом особо нечего.
Похожая ситуация и с серверными ролями от Citrix, веб-интерфейсом и Secure Gateway. Здесь для распределения нагрузки и обеспечения отказоустойчивости этих ролей предполагается использование входящих в состав Windows Server средств NLB (Network Load Balancing) или стороннего балансировщика, например NetScaler [1]. Естественно, это означает наличие как минимум двух серверов с этими ролями.
Немного интереснее ситуация со сборщиком данных (Data Collector). По умолчанию это первый сервер с ролью XenApp. Все последующие сервера добавленные в зону, так же могут выполнять эту функцию но делать этого не будут, пока основной сборщик данных функционирует. Но как только он станет недоступным, его функцию автоматически возьмет на себя сервер с наивысшим приоритетом в зоне. В общем, переживать по поводу сборщика данных при наличии нескольких серверов XenApp не стоит. Делегировать данную роль выделенному серверу нет ни какого смысла, т.к. на обслуживание 1000 серверов в зоне, сборщик данных задействует порядка 300 Мб ОЗУ. Единственное где может понадобиться внимание администратора – это установка приоритета серверам в зоне(рис №5).
Рис.№5. Установка приоритета серверам XenApp
Всего доступно четыре уровня приоритетов:
Most Preferred – Наиболее предпочтительный. Его имеет первый сервер в зоне. Он же по определению и является текущим сборщиком данных.
Preferred – предпочтительный. По умолчанию не имеет не один из серверов. Его может присвоить администратор. В случае выхода из строя основного сборщика данных, новый, в первую очередь будет выбран из серверов с этим приоритетом.
Default Preference – Предпочтение по умолчанию. Приоритет по умолчанию для всех серверов в зоне. Если сервера Preferred отсутствуют, то новый сборщик данных будет выбран из серверов с таким приоритетом.
Not Preferred – Не предпочтительный. По сути, отсутствие приоритета. Стоит присвоить серверам на которые не нужно возлагать роль сборщика данных. Например сервера с другими важными ролями. Стоит отметить, что в случае отказа всех серверов с другими приоритетами в зоне, он все равно будет обязан выполнять роль сборщика данных!
Еще запущенней ситуация с функцией XML Broker. Как уже говорилось, это одна из функций XML Service, которая в свою очередь присутствует и на каждом XenApp сервере. Получается, как и в случае со сборщиком данных, функцию брокера XML способен выполнять любой из серверов XenApp, если эта возможность не выключена на этапе подключения сервера к ферме. Но все не так радужно. При том, что брокер XML функционирует на каждом из серверов XenApp, задействован будет только тот который указан в настройках веб-интерфейса! И каких либо встроенных средств обеспечения доступности брокера XML или динамического изменения его адреса в настройках, нет. Эта жесткая привязка к конкретному брокеру, на мой взгляд является недочетом архитектуры. Единственный способ обеспечения доступности данной функции, который я вижу, это опять же NLB. который не совсем изящно смотрится для решения этой задачи.
Что касается тяжеловесов с ролью XenApp, то здесь все просто и прозрачно. В случае выхода из строя одного из серверов фермы, приложения пользователей работающих на этом сервере аварийно завершат работу. Но при их повторном запуске, роль веб-интерфейса, на сколько это возможно, равномерно распределит пользовательские подключения на оставшиеся сервера. По умолчанию, пользователи подключаются к разным серверам, но критерии распределения ресурсов, а так же их приделы тонко настраиваются c помощью правил.
Автор Юрий Медведев 17 февраля 2010 г. 23:11
Когда мы начинаем разбираться с какой-нибудь новой программой или системой, то стараемся, чтобы все заработало как можно быстрее. Иногда поджимают сроки, иногда мы сами так горим энтузиазмом, что остаемся после работы, лишь бы…
Когда мы начинаем разбираться с какой-нибудь новой программой или системой, то стараемся, чтобы все заработало как можно быстрее. Иногда поджимают сроки, иногда мы сами так горим энтузиазмом, что остаемся после работы, лишь бы поскорее увидеть функционирующую систему живьем. В этой статье вы найдете советы нетерпеливому администратору, которые помогут запустить Citrix XenApp Server в самые короткие сроки.
Все рекомендации основаны на реальном опыте автора по внедрению продуктов Citrix на предприятии, но не преследуют цель охватить все возможные нюансы установки и настройки, поскольку это не уместить в одной статье и даже книге.
Несмотря на то что приводимые примеры относятся к версии Citrix XenApp Server 4.5 (Web-интерфейс 4.6), я постарался построить материал так, чтобы он был полезен и пользователям других версий.
Юрий Медведев
внештатный эксперт
1. Сделайте правильный выбор аппаратной и программной платформы
Если есть возможность, развертывайте ферму Citrix на платформе x64. Поскольку в 64-бит среде для всей ОС доступно больше 4 Гбайт, а для ее ядра и каждой прикладной программы — больше 2 Гбайт оперативной памяти, то в Windows 2003 x64 по сравнению с Windows x86 количество одновременно работающих пользователей может быть увеличено почти в два раза в расчете на один сервер. Кроме того, на 32-бит системах производительность дисковой подсистемы или память ядра исчерпываются раньше, чем ресурсы процессоров.
Для увеличения производительности дисковой подсистемы терминального сервера рекомендуется использовать высокопроизводительные SCSI- или SAS-RAID-контроллеры с функцией Battery Backed Write Cache (BBWC — кэш записи с батарейным питанием). Для терминальных серверов BBWC настраивается в следующей пропорции — 50% запись и 50% чтение.
Данный вид кэша позволяет значительно увеличить производительность дисковых операций, так как контроллер, получив порцию данных, сразу отвечает серверу, что информация записана, а процедура записи на диск еще продолжается. Операции чтения происходят тоже быстрее, поскольку данные считываются большими порциями.
В случае неожиданного отключения питания сервера батарейное питание кэша позволит сохранить данные, которые не успели записаться на диск. В противном случае могут произойти необратимые изменения в файловой системе.
Переход на x64 улучшает масштабируемость системы в пределах одного сервера, а использование блейд-серверов — масштабируемость системы в целом.
2. Citrix не любит нестандартные конфигурации
«Установка Windows с CD-ROM — метод установки ОС, который стопроцентно проверен корпорацией Microsoft», — и в шутку, и всерьез когда-то говорил нам на ИТ-курсах инструктор. Технические форумы Citrix (да и не только Citrix) забиты сообщениями о проблемах, связанных с тем, что инженеры часто стараются настроить систему нестандартно. Приведу пример нестандартной настройки Citrix и связанных с этим последствий.
Порой мы хотим сократить время адаптации ленивых пользователей к новой системе. Как-то я решил оставить только один (а именно русский) язык в Web-интерфейсе Citrix. В этом случае не требуется переключать языки при первом входе на страницу Web-интерфейса. Для Web-интерфейса 4.6 недокументированная процедура выглядит следующим образом. В каталоге C:\inetpub\wwwroot\Citrix\AccessPlatform\conf найдите файл bootstrap.conf. Установите значение параметра DefaultLocale=ru (по умолчанию обычно en). Удалите файлы *.lang всех ненужных языков в каталоге c:\program files\citrix\web interface\4.6.0\languages. Перезапустите Internet Information Server (IIS). После загрузки Web-интерфейса в окне браузера Internet Explorer автоматически будет доступен только русский язык, большинство системных сообщений будут сразу отображаться по-русски.
Как впоследствии оказалось, этот способ следует использовать с осторожностью. Так, если после этой операции вы попытаетесь в Access Management Console добавить PNAgent Site, то будет создаваться неактивный сайт с ошибкой Произошла неизвестная ошибка.
Причем удалить сайт с помощью консоли будет невозможно. На технических форумах, посвященных технологиям Citrix, я не получил ни одного ответа или совета, как решить проблему,— кроме того, не нашлось ни одного описания ошибки в Интернете.
Я пребывал в недоумении, пока не понял, что проблема связана с моими действиями, а именно с удалением языка, необходимого для правильного функционирования консоли управления доступом (Access Management Console). Чтобы выйти из положения, я восстановил файл английского языка en.lang в соответствующей директории, и сайты снова стали управляемыми.
После создания сайта можно опять удалить en.lang, чтобы русский язык был единственным в Web-интерфейсе. Разработчикам Citrix следовало бы предусмотреть обработку ошибок, связанных с отсутствием английского языка в Web-интерфейсе.
3. Используйте технологии клонирования жестких дисков для ускоренной установки ферм терминальных серверов
Для ускорения развертывания системы терминального доступа можно использовать системы клонирования дисков, предназначенные для клонирования серверных ОС, например Symantec Ghost Solution Suite и др. Возможны два варианта клонирования терминальных серверов Citrix — клонирование непосредственно серверов Windows с последующей установкой на каждый сервер ПО Citrix вручную или клонирование полностью установленных серверов Citrix.
Если первый вариант клонирования практически не отличается от клонирования обычного Windows-сервера, то второй сложнее (требуется выполнить определенную последовательность административных действий над фермой Citrix), поэтому перед его выполнением необходимо ознакомиться со статьей Citrix:CTX107406.
1 2 3 4 5 
