Управление нагрузкой Citrix Presentation Server (часть 1)

Введение

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

Архитектура управления нагрузкой

Архитектура управления нагрузкой состоит из нескольких компонентов фермы серверов. Первый из этих компонентов представляет собой модульную часть программного кода Presentation Server, отвечающую за распределение пользовательской нагрузки между серверами в определенной зоне, а также во всей ферме. Основной библиотекой в этом компоненте является LmsSS.dll, и она загружается в память сервера во время процедуры запуска службы независимой архитектуры управления (IMA). Этот файл.dll должен быть запущен на каждом Presentation Server в ферме; однако этот процесс не будет присутствовать ни на одном сервере с лицензией на стандартную версию Presentation Server, только на версии Advanced и Enterprise.

Возможно, наиболее важным компонентом является сборщик данных зоны, расположенный в каждой зоне. Сборщик данных зоны — это просто сервер презентаций, выполняющий роль сборщика данных в определенной зоне. Вы можете управлять предпочтениями сборщика данных, но независимо от этих настроек всегда будет один Presentation Server в каждой зоне, который должен выполнять эту роль сборщика данных. Сервер презентаций, поддерживающий список сборщиков данных, отвечает за направление всех запросов от клиентов ICA, запускающих опубликованные приложения; это само по себе не секрет. Что не является общеизвестным, так это то, какие факторы играют роль в процессе принятия решений и как именно происходит этот процесс принятия решений. Чтобы эффективно использовать подсистему управления нагрузкой, необходимо полностью понимать игроков и правила игры.

Следующий компонент — это само опубликованное приложение; без публикации определенных приложений или опубликованного рабочего стола фактическая балансировка нагрузки не выполняется. Простое подключение к терминальному серверу или Presentation Server через имя или IP-адрес сервера не вызовет подсистему балансировки нагрузки. Дополнительным фактором, который не следует упускать из виду, являются предпочтения зоны и параметры аварийного переключения, которые могут присутствовать в одной или нескольких политиках Citrix. Эти настройки могут определять, какие серверы презентаций в определенных зонах могут предоставлять запрошенное приложение соответствующим пользователям. На рисунках 1 и 2 ниже показаны настройки предпочтения зоны и политики отработки отказа. В этом примере все пользователи в подсети 10.1.30.0/255.255.255.0 будут перенаправлены на серверы презентаций в зоне с именем «Кентукки» с возможностью автоматического переключения на серверы презентаций в зоне с именем «Огайо», если в сети нет серверов презентаций. зона «Кентукки» доступна для предоставления желаемого приложения.

фигура 1

фигура 2

Последней частью головоломки управления нагрузкой является оценщик нагрузки или оценщики нагрузки, применяемые к серверам и/или опубликованным приложениям. Оценщик нагрузки — это просто набор правил, определяющих «оценку» конкретного сервера или текущее значение нагрузки. Именно эта «оценка» может в конечном итоге определить решения, распределяющие нагрузки внутри фермы серверов. Оценщики нагрузки могут применяться к серверам и/или опубликованным приложениям. (Оценщики нагрузки и соответствующие правила будут подробно рассмотрены в части III этой серии.)

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

Процесс управления нагрузкой всегда начинается с запроса пользователя на запуск опубликованного приложения или опубликованного рабочего стола в ферме Presentation Server. Первый шаг, который должен сделать пользователь или клиент ICA, — найти сборщик данных в соответствующей зоне. Любой Presentation Server, доступный пользователю, сможет указать имя и/или адрес сборщика данных в конкретной зоне. После обнаружения IP-адреса сборщика данных клиент ICA отправляет запрос конкретного опубликованного приложения непосредственно сборщику данных. Как только пользователь устанавливает связь со сборщиком данных, сборщик данных может получить доступ к данным в локальном кэше хоста (LHC) на сервере Presentation Server сборщика данных, данным сеанса в памяти (какие сеансы активны или в отключенном состоянии), а также а также хранящаяся в памяти база данных о нагрузках на серверы или «оценки» всех серверов презентаций в данной зоне.

Первым шагом в этом процессе принятия решения является определение того, есть ли у конкретного пользователя какие-либо существующие сеансы в активном или отключенном состоянии. Для этого может потребоваться межзональная связь между сборщиками данных в многозонной ферме. Причина этого шага связана с поведением по умолчанию, связанным с «совместным использованием сеанса», или склонностью Presentation Server запускать как можно больше приложений в рамках одного сеанса, а не создавать дополнительные сеансы. Например; Пользователь JDoe имеет существующее опубликованное приложение, работающее в сеансе ICA на SERVER1. Затем JDoe пытается запустить второе приложение на той же ферме серверов. Если запрошенное приложение доступно на SERVER1, а SERVER1 загружен не полностью (значение загрузки меньше 10 000), приложение будет открыто в этом существующем сеансе на SERVER1, и новый сеанс не будет создан. Одним из предостережений является требование, чтобы определенные свойства недавно запрошенного опубликованного приложения соответствовали свойствам приложения, которое уже запущено в сеансе (разрешение, цвета, настройки звука и т. д.). Как видите, такое поведение может привести к тому, что уже загруженный сервер будет принимать дополнительную нагрузку, независимо от нагрузки, присутствующей на других серверах. Хотя преимущества, получаемые при совместном использовании сеансов, намного перевешивают связанные с этим риски, было бы упущением не упомянуть об этом возможном результате, касающемся балансировки нагрузки серверных ресурсов. (Примечание. Компания Citrix выпустила расширение функции, позволяющее совместно использовать сеансы на полностью загруженных серверах — см. оперативное исправление Citrix PSE400R01W2K3010 или текущую статью базы знаний CTX111085.)

Когда доставка запрошенного приложения должна привести к созданию совершенно нового сеанса, LHC опрашивается, чтобы определить, на каких серверах доступно приложение, а также потенциальные данные политики Citrix, касающиеся предпочтения зоны и аварийного переключения. Эта информация предоставляет «краткий список» потенциальных серверов, которые доступны для предоставления запрошенного приложения конкретному пользователю. Только на этом этапе процесса вступает в действие реальная подсистема управления нагрузкой. «Оценка» или значение нагрузки теперь будет определять, какой сервер выбран из короткого списка, и в конечном итоге предоставит запрошенное приложение клиенту ICA.

Значение загрузки или «Оценка»

Чтобы понять и должным образом помочь в этом процессе принятия решений, мы должны узнать важность этой «оценки» или значения нагрузки и понять, как она рассчитывается и сообщается. Каждый Presentation Server генерирует свою собственную «оценку» и отправляет эту информацию сборщику данных в соответствующей зоне. Эта оценка будет представлять собой десятичное число от 0 до 10 000, где ноль представляет ситуацию «без нагрузки», а 10 000 указывает на то, что конкретный сервер полностью загружен и больше не принимает соединений. На рис. 3 показаны результаты выполнения команды QFARM /LOAD в ферме Presentation Server. Эта команда отобразит все серверы в ферме вместе с соответствующим значением нагрузки каждого сервера. Как вы можете видеть на рисунке 3, если запрос приложения должен был привести к созданию нового сеанса, сервер с именем «Instructor2» был бы счастливым победителем в этот момент времени из-за его более низкого значения нагрузки.

Рисунок 3

Как определяется это чрезвычайно важное число? Это результат вычислений и сумма значений всех правил в каждом оценщике нагрузки, который применяется к данному сценарию. Важно понимать один важный фактор : как только какое-либо отдельное правило достигает своего максимального значения, значение нагрузки для этого сервера становится равным 10 000, что эффективно устраняет конкуренцию отдельного сервера за новые сеансы. Отдельные серверы постоянно обновляют сборщик данных соответствующей зоны своим текущим счетом каждые 15 секунд в нормальных условиях или после каждого входа или выхода из сеанса пользователя. В очень загруженной среде Presentation Server многое может произойти за 15 секунд. Примером этого может быть определенное время рабочего дня, когда многие пользователи одновременно запускают приложения, например, начало рабочего дня. Когда большое количество пользователей одновременно обращаются к опубликованным приложениям Citrix, балансировка нагрузки между серверами может стать неравномерной. В случае, если один сервер имеет очень низкое значение нагрузки по сравнению с другими серверами в «шорт-листе» доступных серверов, можно временно перегрузить этот, казалось бы, «незанятый» сервер, направив много новых сессий на этот сервер в очень короткие сроки. короткий промежуток времени, вплоть до полной неработоспособности. Также возможно увидеть эту асимметричную балансировку нагрузки при другом условии; Если бы администратор вставил Presentation Server без нагрузки в загруженную ферму (или перезагрузил Presentation Server), конечный результат мог бы быть подобен открытию новой очереди на кассе в вашем любимом розничном заведении; безумная спешка к новой очереди на кассе, что привело к временному и болезненному узкому месту. Эта конкретная ситуация с балансировкой нагрузки Presentation Server была названа «эффектом черной дыры». Во второй части этой серии статей будет рассмотрено интеллектуальное смещение нагрузки (ILB), усовершенствование функции, выпущенное для Presentation Server 4.0, которое пытается решить эту проблему перегрузки сервера или эффект черной дыры.

Вывод

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