Главная Windows, Без рубрики, Новое Балансировка нагрузки в Citrix XenApp
  • Балансировка нагрузки в Citrix XenApp

    balancing_act Одним из преимуществ использования Citrix XenApp по сравнению с базовым функционалом Терминальных Служб Windows (по новому – RDS) является расширенные возможности по балансировке нагрузки. Данный функционал реализован компонентом Load Manager.

    В этой статье я попытался описать технические детали того, как работает балансировка нагрузки в Citrix XenApp.

    Load Manager позволяет администратору:

    • Оптимизировать использование ресурсов в терминальной ферме 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 файла. На рисунке ниже начальный и конечный этапы отмечены красным подчеркиванием:

    1

    (полностью процесс логона пользователя на сервер можно посмотреть в CPS Logon Process Chart от Брайана Мэддэна ).

    Метрики

    В качестве метрик для LMS могут выступать два класса метрик:

    Специфичные для XenApp:

    • Server User Load – количество сессий терминальных служб, здесь считаются не тоько ICA сессии, но и RDP, причем как активные, так и disconnected
    • Application User Load – количество сессий с определенным приложением, полезно тогда, когда вы хотите ограничить количество экземпляров приложения, запущенного на сервере
    • Logon Throttling – Метрика, позволяющая “обманывать” LMS завышая рассчитанную нагрузку в момент массовых логонов пользователей
    • Расписание – тут все просто, выставляете, в какое время суток сервер доступен, в остальное время он будет сообщать о своей полной загрузке
    • IP Range – с помощью этой метрики вы можете разрешить доступ к серверу только определенным подсетям

    Стандартные счетчики производительности

    Используются стандартные счетчики производительности, которые можно посмотреть с помощью утилиты perfmon. Описание деталей доступно в статье http://support.citrix.com/article/ctx111965

    Load Evaluator Rule Описание Имя счетчика прозводительности
    CPU Utilization Calculates load based on a moving average of total CPU utilization across all processors in the server. Processor \ (_Total) \ % Processor Time
    Memory Usage Calculates load based on virtual and physical memory currently in use. Memory \ % Committed Bytes In Use
    Context Switches Calculates load based on CPU Context switches. System \ Context Switches/sec
    Disk Data I/O Calculates a load based on the disk I/O throughput in kilobytes. PhysicalDisk(_Total) \ Disk Bytes/sec
    Disk Operations Calculates a load based on the number of disk operations per second. PhysicalDisk(_Total) \ Disk Writes/sec + PhysicalDisk(_Total) \ Disk Reads/sec
    Page Faults Calculates load based on the number of page faults per second. Memory \ Page Faults/sec
    Page Swap Calculates load based on the number of page swaps per second. Memory \ Pages/sec

    Главное что нужно помнить – в метриках XenApp выдается не значение счетчика производительности, а значение метрики, в соответствии с настроенным правилом. т.е. если правило Load Evaluator настроено сообщать о 100% нагрузке на сервер при загрузке CPU в 80%, то число 50 в метрике будет говорить о 40% нагрузке на CPU

    CPU Load

    Как считаются метрики производительности?

    Было бы глупо и долго, если бы LMS опрашивал все сервера фермы при обращении каждого пользователя, поэтому в Dynamic Datastore хранятся значения текущей загрузки для каждого из серверов фермы. Это значение называется “Load Index” и может быть от 0 до 10000. При запуске приложения выбирается сервер с минимальным значением Load Index. Текущее значение Load Index можно посмотреть с помощью команды qfarm /load. Если разделить “Load Index” на 100, мы получим текущую загрузку сервера в процентах, именно это число можно увидеть в консоли XenApp Advanced Configuration (ранее – Citrix Management Console)

    Load Manager

    C:\> qfarm /load

    Server Name           Server Load
    ——————–  ————
    MSK-CXA101            300

    в данном примере сервер загружен только на 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?

    Load Index это не среднее всех метрик, он рассчитывается по формуле:
    LoadIndex = ЗначениеМаксимальнойМетрики*100 + (Метрика1*100)* 5%+ (Метрика2*100)* 5%+ (МетрикаN*100)* 5%
    Здесь кроется небольшой подвох – dsquery в поле RuleLoads выдает значения деленные на 100 и округленные до целого числа, поэтому у нас при проверке не получится совсем точный результат

    т.е. в данном случае – 62*100+6*100*0.05+36*100*0.05=6410, что является близким к реальной нагрузке

    Где хранятся метрики, и когда они обновляются?

    Метрики хранятся в памяти на Data Collector (DС), в так называемом Dynamic Data Store они не записываются в базу данных DataStore на сервере баз данных
    Инициатором обновления является рядовой терминальный сервер, он сообщает свои метрики на DC
    Обновляются метрики в следующих случаях:

    при logon или logoff пользователя

    если метрика изменилась на +/- 500

    Локальные метрики На DC обновляются каждые 30 секунд

    Если рядовой сервер за 1 минуту о себе ничего не сообщил, DC “пингует” по протоколу IMA данный сервер, для того чтоб узнать, жив ли тот.

    Если обновлений не было 5 минут, DC запрашивает обновление метрик.

    Load Throttling

    В алгоритме балансировки существует одна брешь – пользователь всегда направляется на наименее загруженный сервер, и это нормально при одновременном старте всех серверов (пользователи распределяются равномерно). Но представьте себе ферму из 5 серверов, на каждом из которых открыто по 90 сессий, и тут администратор добавляет новый сервер в ферму. Что произойдет? – все вновь подключающиеся пользователи будут попадать на этот новый сервер, ведь он наименее загружен! А отошлет он метрику c уровнем своей загрузки не раньше чем после окончания логона пользователя. И тут-то кроется самое страшное – во время логона, даже одного пользователя, нагрузка на сервер может составлять до 100%, а если таких пользователей будет прибывать по 30 в минуту? Если у вас Windows 2003, и не важно на каком сервере, с вероятностью 99% сессии у вас начнут отваливаться начиная уже с 10 пользователя. И при этом, на сервер вновь и вновь будут направляться пользователи.

    Для того чтобы бороться с этой проблемой был внедрен такой механизм как Load Throttling, или Динамическая регулировка нагрузки. Суть его проста, начиная с момента инициализации сессии Data Collector искусственно увеличивает хранящийся в его памяти Load Index для сервера увеличивает он его по следующей формуле:

    ВременныйLoadIndex = LoadIndex + (10000 – LoadIndex )/LoadImpact


    Откуда берется LoadImpact? Это число выставляемое правилом impact of logons on load при создании Load Evaluator.

    Load Throttling

    Значение LoadImpact может быть таким:

    • Extreme: 1
    • High: 2
    • Medium-High: 3
    • Medium: 4
    • Medium-Low: 5

    Таким образом вы можете указать насколько сильно влияет процесс входа пользователя на производительность сервера.

    Следует понимать, что LoadIndex в формуле может быть и временным, рассчитанным при входе предыдущего пользователя

    Для того чтобы понять, как работает Load Throttling представим себе упрощенную ситуацию: что у нас есть сервер, на котором работает 60 пользователей, что составляет 60% от мощности сервера. Вы включаете еще один такой же сервер, на котором соответственно никого пока нет.
    Сервер1

    Сервер2

    Количество пользователей LoadIndex Временный LoadIndex Количество пользователей LoadIndex Временный LoadIndex
    60 6000 0 0 0 0
    Наступает 9 часов утра, и на сервера с интервалом в 5 секунд начинают приходить новые пользователи, для простоты представим себе что процесс логона занимает 1 минуту, т.е как минимум 1 минуту реальный LoadIndex не будет обновлен

    Приходит user1, попадает на сервер 2, у которого LoadIndex=0<6000

    60 6000 0 1 0 0+(10000-0)/2=5000
    60 6000 0 1 0 5000
    Приходит user2, попадает на сервер 2, у которого временный LoadIndex=5000<6000
    60 6000 0 1 0 5000+(10000-5000)/2=7500
    60 6000 0 2 0 7500
    Приходит user3, попадает на сервер 1, у которого LoadIndex=6000<7500
    61 6000 6000+(10000-6000)/2=8000 2 0 7500
    61 6000 8000 2 0 7500
    Приходит user4, попадает на сервер 2, у которого LoadIndex=7500<8000
    61 6000 8000 3 0 7500+(10000-7500)/2=8750
    61 6000 8000 3 0 8750
    Приходит user5, попадает на сервер 1, у которого LoadIndex=8000<8750
    62 6000 8000+(10000-8000)/2=9000 3 0 7500+(10000-7500)/2=8750
    62 6000 9000 3 0 8750

    Таким образом, нагрузка, создаваемая процессом входа пользователя на сервер будет более равномерно распределена и у пользователей будет меньше проблем, а значит и администратор будет крепче спать 🙂

Комментарии

  1. Хорошая статья, но вот у меня родился вопрос – а разве Remote Desktop Connection Broker не умеет похожим образом балансировать нагрузку?

  2. 2Alexx
    Спасибо!
    Не совсем, Connection Broker умеет балансировать нагрузку только по количеству сессий, имеет намного меньший функционал и его архитектура менее отказоустойчивая.

  3. Цитрикс всегда славился балансировщиком нагрузки, в общем-то ради этого его теперь и покупают. Раньше хоть, в качестве преимущества, были бесшовные окна…

  4. Денис, привет!
    Скажи, что значит архитектура Session Broker менее отказоустойчивая?

    Отсутствие какого функционала кроме собственно балансировки нагрузки по большему числу параметров (кроме числа сессий) ты называешь “имеет намного меньший функционал”?

    Да будет известно досточимой публике, что Session Brocker теперь для Windows Server 2008 штука расширяемая, и любой программер может довольно быстро налабать простенькую DLL, которая будет балансировать нагрузку используя любое сочетание параметров производительности, характеристики хостов в ферме и любую другую извращенную логику. http://blogs.msdn.com/rds/archive/2008/09/25/ts-session-broker-extensibility-part-2.aspx

    Я конечно не презываю всех бросаться писать COM DLL-ки. Более того, для нас (MSFT) это традиционно делает наш лучший партенр в области Presentation Virtualization (Citrix – если вы еще не поняли о ком я). Но тем не менее, уже давольно много и доморощенных решений – надо лишь погуглить.

  5. Константин привет,
    Session Broker устанавливается на одном сервере или же на кластере, но кластер удорожает систему и усложняет ее.
    Load Manager же контролируется с помощью DataCollector, DC это выборная роль и ее в течении 30 секунд может подхватить любой из серверов в зоне. Зона же может быть распределена между различными сетями и при этом не нужно ничего специального настраивать.
    DataStore, в котором хранится кроме всего прочего информация о подключенных сессиях, может храниться в зеркалируемой базе SQL, реплицируемой между несколькими кластерами (чего там еще по отказоустойчивости SQL08 есть? 🙂 И даже если SQL будет недоступен в течении 30 дней, ничего страшного не произойдет, LocalHostCache на каждом из серверов хранит все необходимые данные из DataStore.

    Дальше больше, про выбор сервера:
    архитектура с Session Broker сначала подключает пользователя на любой случайный сервер, а потом уже перенаправляет на выбранный по алгоритму.
    В XenApp пользователь сразу получает адрес конкретного сервера, на котором есть конкретное приложение, и тестовый автоматический запуск этого приложения и прокликивание по всем окошкам проходит без ошибок за условленное время (такой тест можно проводить из разных регионов и при этом происходит реальная установка сессии), если приложение работает некорректно или медленно, сервер может выключиться из балалансируемых и перезагружен
    Дальше, другие автоматические тесты проверяют работу всех требуемых служб, и корректность того что отвечает к примеру XML Service или то что спулер формирует тестовую страницу. Если что-то не работает, сервер отправляется в перезагрузку
    Дальше – служба XML, через которую идет общение WebInterface с DataCollector работает на всех серверах фермы, и WebInterface умеет опрашивать их все, не выдавая ошибок пользователю. а если между WI и XML поставить входящий в комплект NetScaler VPX Express, то он будет автоматически выбирать наиболее быстро отвечающий и корректно отвечающий XML Service.
    Немного другой компонент при всем этом будет держать в резерве некоторое количество серверов (к примеру 10% от общего количества) и если кто-то сломался, на его место автоматом придет другой.
    это было краткое и сумбурное описание отказоустойчивости LB 🙂

    про функционал – кроме количества счетчиков:
    во-первых их можно комбинировать и настраивать по вкусу
    во-вторых Load Evaluator (комбинация счетчиков и правил) может применяться как к серверам, так и к приложениям. к разным серверам можно применять разные Load Evaluators.
    в-третьих, в XA есть понятие зон, и балансировка может быть внутри каждой зоны
    в-четвертых такие метрики как подсеть и расписание может применяться для того, чтобы, к примеру, с 1 ночи до 6 утра по московскому времени направлять Хабаровского пользователя, запускающего Excel на наименее загруженный сервер во Владивостоке, а с 6 до 18 – на московский сервер, а если же он будет запускать фотошоп, то направляться будет только на тот сервер, на котором копий фотошопа запущено не больше 3-х, и только в том случае, если всего в ферме запущено максимум 10 копий приложения.

    Про функционал тоже можно много чего рассказывать с разными сценариями, но он явно больше 🙂

    И если RemoteApp технически является полным клоном ThinWire (Seamless Windows) то RD Session Broker устроен совсем по другому, и Citrix его никак не использует и никогда не использовал.

    Да, самое главное, почти все описанные выше сценарии нужно естественно настроить, но все это доступно из коробки, ни строчки кода писать не надо 🙂

  6. Да, красиво…, но, ИМХО, надо это только очень крупному бизнесу. Не раз замечал, что MS говорит про Citrix, как про своего партнера, который “допиливает” их продукты под более серьезные задачи 🙂
    Кстати, Денис, вы как-то умолчали про стоимость продукта, можете дать кратенькое сравнение?

  7. Alexx, про стоимость и не было желания рассказывать, да и сравнивать тут нечего, Вы покупаете RDS CAL в любом случае, а если хотите дополнительных функций – доплачиваете еще и Citrix. Естественно любой функционал стоит денег, но Load Balancing – это порядка %5 от того, что Citrix добавляет к RDS

    По поводу малого бизнеса – у Citrix есть XenApp Fundamentals, который стоит в разы дешевле, но рассчитан на маленькие компании с числом ПК до 75

    [реклама моде он]
    По вопросам приобретения и внедрения ПО Citrix можно обращаться ко мне по адресу citrix@itbubble.ru
    [реклама моде офф]

  8. А где можно узнать поподробней о балансировке Citrix приложениями? В частности интересует бесперебойная работа опубликованных приложений, чтобы при “падении” одного сервера, приложения продолжали работать.