Установка и настройка Citrix XenApp 6.5 (часть 4)

• Установка и настройка Citrix XenApp 6.5 (часть 2)
• Установка и настройка Citrix XenApp 6.5 (часть 3)

В третьей части этой серии статей я описал этапы настройки Citrix XenApp 6.5 в параметрах «Администраторы» и «Опубликованное приложение». Теперь мы продолжим с другими вариантами.

Политики балансировки нагрузки

Эта опция доступна только в редакции Enterprise или выше. Это позволяет разделить сеансы по рабочим группам на основе четырех фильтров; Контроль доступа, IP-адрес клиента, имя клиента и пользователи. На основе одного или комбинации этих фильтров вы можете указать, к какой рабочей группе (группам) на основе приоритета будет отнесен пользователь. Также этот компонент можно использовать для указания способа доставки/запуска Citrix Application Virtualization. Ранее я написал подробную статью о политиках балансировки нагрузки, которую можно найти на моем веб-сайте VanBragt.Net Virtualization.

Рисунок 1: Политики балансировки нагрузки

Оценщик нагрузки

Несмотря на то, что названия очень похожи, и администраторы/консультанты Citrix часто называют оценщики нагрузки балансировкой нагрузки, у оценщика нагрузки другая цель, чем только что описанная политика балансировки нагрузки. Оценщик нагрузки определяет нагрузку на серверы Citrix XenApp на основе правил оценки нагрузки. По умолчанию доступны два оценщика нагрузки; По умолчанию (на основе пользовательской нагрузки и регулирования нагрузки) и расширенного (на основе использования ЦП, использования памяти, регулирования нагрузки и подкачки страниц). Оба имеют некоторые недостатки, поэтому часто создается новый пользовательский оценщик нагрузки.

Лучше всего использовать комбинацию правил Пользовательская нагрузка (где значение должно определяться тестами производительности), Использование памяти, Использование ЦП и Регулирование нагрузки. Поскольку использование ЦП и использование памяти имеют динамический характер, я хочу, чтобы эти правила вступали в действие только тогда, когда использование довольно высоко. Поэтому для настройки без нагрузки я использую довольно высокое значение, например 70 или 80 процентов, что делает пользовательскую загрузку правилом, которое используется в обычных ситуациях. Я объясню это немного подробнее, потому что у администраторов много путаницы по поводу того, как рассчитывается нагрузка. Из правил будет использоваться самое высокое значение в сочетании со средними значениями других правил (которые умножаются на 0,1). Таким образом, в моих лучших практиках пользовательская нагрузка будет иметь самое высокое значение по умолчанию, или ЦП или память должны иметь высокое значение.

Рисунок 2: Пользовательский оценщик нагрузки

Политики

По сравнению с XenApp 6.5 политики сильно изменились. Первое большое изменение — это способ настройки политик. В предыдущих версиях это можно было сделать только в Citrix Management Console, но в настоящее время вы также можете настроить политики в Active Directory. По логике вы должны принять решение использовать одну из возможностей, потому что они не могут быть объединены. Преимущество Active Directory заключается в том, что настройки могут быть общими для нескольких ферм Citrix, а метод AD всегда используется для развертывания политик (также, если вы настраиваете их в консоли Citrix). Преимуществом использования консоли Citrix является независимость от AD (например, если вы не являетесь администратором AD) и понятно, что политики предназначены для какой фермы XenApp (если настроено несколько ферм).

Политики могут применяться на двух уровнях: на уровне компьютера или на уровне пользователя (так же, как работает объект групповой политики Active Directory). Можно настроить несколько политик, которые можно назначить с помощью фильтров и приоритетов. Использование настроек части приоритетов может быть отменено более высоким приоритетом. Фильтрация на уровне компьютера может основываться на организационном подразделении AD и/или рабочих группах. Полезно знать, что несколько параметров настройки в настоящее время встроены в часть политик, тогда как в более ранних версиях они были доступны как отдельные параметры в консоли. Некоторыми примерами являются назначение Load Evaluator на уровне сервера, конфигурация перезагрузки, лицензирование, мониторинг работоспособности и восстановление, оптимизация ЦП/памяти и т. д.

Второй уровень находится на уровне пользователя. Логически на уровне пользователя та же концепция используется для определения приоритетов и фильтрации. Однако доступно больше фильтров:

• Контроль доступа

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

• Филиальный повторитель

Использование этого параметра фильтра будет применяться в зависимости от способа подключения клиента, через повторитель ответвления или без повторителя ответвления.

• IP-адрес клиента

На основании (части) клиентских IP-адресов политика будет применена или отклонена. Подстановочные знаки можно использовать для определения наборов клиентов для применения или отклонения политики. Некоторыми вариантами использования являются настройки, определенные для соединений WAN, внешнего доступа (если контроль доступа не установлен), настройки конкретного отдела/местоположения и т. д.

• имя клиента

Использование (части) имени клиента для применения или отклонения политики. Опять же, для определения группы клиентов можно использовать подстановочные знаки. Может использоваться для различных настроек в зависимости от типа клиента (ноутбуки, настольные компьютеры и тонкие клиенты), конфигурации конкретного отдела или аналогичных вариантов использования.

• Организационная единица

Точно так же, как действуют пользовательские политики по умолчанию для Active Directory, политика применяется или запрещается в зависимости от местоположения пользователя в схеме подразделения AD.

• Пользователь или группа

Фильтрация политики основана на пользователях или группах. Это могут быть как локальные, так и пользователи или группы Active Directory, где имеет смысл использовать группы Active Directory для такого рода фильтрации.

• Рабочая группа

Таким образом, пользовательская политика будет применяться на основе сервера, на котором запущен сеанс. Таким образом, если сервер является членом настроенной рабочей группы, политика будет применена или отклонена.

Рис. 3. Пользовательские политики Citrix. Фильтры.

В этот раз я не буду обсуждать все параметры политики один за другим. Если есть интерес, мы можем сделать для него отдельную серию статей.

Рабочие группы

В XenApp 6.0 также представлены рабочие группы. Рабочая группа — это просто группа серверов. Сервер может быть членом одной, ни одной или нескольких рабочих групп. Рабочие группы часто используются для объединения похожих серверов, используемых для назначения одной и той же конфигурации. Например, вы можете назначить опубликованное приложение рабочей группе. Если сервер добавлен, опубликованное приложение автоматически становится доступным на этом сервере (или наоборот). Кроме того, применение политик Citrix с использованием рабочих групп является хорошей возможностью, особенно потому, что сервер может быть назначен большему количеству рабочих групп. Я использую эту концепцию, чтобы вывести сервер из эксплуатации с помощью Load Evaluator (теперь его можно настроить только с помощью части Machine Policy) и рабочих групп (см. эту статью для получения дополнительной информации). Также требуются определенные рабочие группы с использованием политик балансировки нагрузки.

Зоны

В настоящее время зоны используются только для организации коммуникационного трафика между серверами Citrix XenApp (и указания предпочтения сборщика данных для каждой зоны). По умолчанию все серверы Citrix XenApp взаимодействуют друг с другом в зоне. Когда ферма Citrix разделена на несколько местоположений (с ограниченной пропускной способностью), может быть важно ограничить трафик между этими расположениями. Создавая зону для каждого местоположения, трафик между зонами ограничивается, когда общается только один сервер каждой зоны. Другие серверы напрямую взаимодействуют только с серверами в той же зоне.

Выборы Preference могут быть настроены для каждой зоны. Это определяет, какой сервер будет выполнять роль сборщика данных. В каждой зоне будет один сервер, который будет выполнять эту роль. Если этот сервер недоступен, будут проведены выборы, и на основе предпочтения выбора сервера будет выбран новый сервер для размещения роли.

Рисунок 4: Установка предпочтений для выборов

Конфигурация прослушивателя ICA

Как указывалось ранее, за пределами консоли управления все еще есть несколько настроек для конкретной конфигурации. Прослушиватель ICA является наиболее важным, поскольку это единственное место, где вы можете настроить ограничения сеанса для завершения отключенного сеанса и лимита активного сеанса. В политиках Citrix доступны те же параметры, но они применяются только к XenDesktop. Я не рекомендую изменять другие настройки в этой конфигурации прослушивателя ICA.

Рисунок 5: Конфигурация прослушивателя ICA

Диспетчер сокращения задержки SpeedScreen

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

Конфигурация SSL-ретранслятора Citrix

При обмене данными между фермой XenApp и технологиями доступа, такими как веб-интерфейс, безопасный шлюз, шлюз доступа или облачный шлюз, по умолчанию используется обычный XML/HTTP-трафик. Это можно защитить с помощью SSL-трафика. С помощью Citrix SSL Relay Configuration вы можете настроить параметры SSL для серверов XenApp для защиты связи между настроенными серверами и технологиями доступа.

Вывод

В этой последней части я продолжил описание и обсуждение возможностей конфигурации XenApp. В этой серии статей я показал и описал базовую установку и настройку среды XenApp на основе XenApp 6.5.

• Установка и настройка Citrix XenApp 6.5 (часть 2)
• Установка и настройка Citrix XenApp 6.5 (часть 3)