Как работает балансировка нагрузки в Citrix XenApp

Автор: vik_kr Дата: . Категория: Терминальные технологии

В этой статье я попытался описать технические детали того, как работает балансировка нагрузки в 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

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 + 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

Description

Performance Monitor Value

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




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


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


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

при logon или logoff

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


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

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

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

 

Ссылка на оригинал: http://blog.itbubble.ru/2010/04/xenapp.html