Платформа XenApp состоит из девяти функциональных ролей, три из которых являются базовыми и шесть дополнительных. Базовые роли обеспечивают виртуализацию и доставку приложений конечным пользователям и являются обязательными для развертывания. Дополнительные — расширяют функционал платформы. Их доступность зависит от редакции XenApp. Также существуют ряд опциональных компонентов, которые входят в состав ролей или реализованы отдельными сущностями.
Все роли, без исключений, могут быть развернуты на одном сервере или разнесены на отдельные физические или виртуальные сервера.
Типовая архитектура и набор основных ролей изображены на рисунке №1.
Рис. 1. Типовая архитектура и базовые роли Citrix XenApp
Для сокращения объема статьи, постараюсь совместить описание функциональных обязанностей основных компонентов с рассказом о том как все это работает.
Самый длинный путь проходят внешние пользователи, которые находятся вне сети организации и работают со своими приложениям по незащищенным каналам. Первой ролью, принимающей подключения от них, является Secure Gateway – обеспечивающий безопасный шлюз (но не авторизацию пользователей) между XenApp и конечным устройством. Данные передаваемые между удаленной рабочей станцией и Secure Gateway шифруются при помощи протокола SSL или TLS.
Использование данной роли не является обязательным, но настоятельно рекомендуется Citrix для повышения уровня безопасности корпоративной сети. Обработав подключение Secure Gateway, перенаправляет пользователя в веб-интерфейс представляющий собой единую точку подключения к ресурсам XenApp.
После авторизации в веб-интерфейсе, учетные данные пользователя передаются службе (компоненту) XML Service (в документации — XML Broker). Брокером ее называют потому что она является посредником, связующим звеном между остальными ролями инфраструктуры XenApp.
Примечание: Про XML Service и XML Broker. При чтении документации по продукту XenApp, повсеместно фигурирует служба XML Broker. Но при развертывании ролей и компонентов XenApp, а так же в интерфейсе конфигурирования она именуется XML Service. Лично у меня по началу не было четкого понимания кто есть кто. Фактически XML Broker это одна из функции выполняемых XML Service. Кроме того, термин XML Broker используется вместо XML Service, как более выразительный и наиболее четко характеризующий функции данной службы.
XML Service, просматривает конфигурацию приложений в DataStore. По сути это SQL база данных. Здесь хранятся статические данные к которым относится конфигурация ролей и публикуемых приложений, права доступа к ним и т.д. Получив всю необходимую информацию, XML Service возвращает список приложений и публикаций доступных пользователю. На рис.1 XML Service расположен на отдельном сервере. И хотя такой вариант возможен, это сделано, что бы выделить ее функциональное положение. Практически, служба XML Service автоматически устанавливается вместе с ролью XenApp и в связке с которой и работает на одном сервере.
Далее, следует запуск пользователем одного или нескольких приложений. Тут снова в процесс включается XML Service, только теперь обращение происходит к Citrix Licensing который обеспечивает управление и хранение лицензий на продукты XenApp.
Это первая роль которую необходимо установить и настроить для фермы XenApp (XenApp Farm) прежде чем пользователи смогут подключиться к приложениям. Так же одной из функций XML Service является определение наименее загруженного сервера в ферме XenApp для выполнения пользовательского приложения. Помогает ей в этом Data Collector, представляющий собой динамическую базу данных с постоянно обновляющейся информацией о загрузке серверов и их состоянии. В конечном итоге, веб-интерфейс передает пользователю XML файл со всей необходимой информацией для подключения к нужному серверу и запуска приложения. Полученный файл автоматически обрабатывает Citrix Reciver и на экране появляется окно выбранного приложения.
Где же здесь собственно XenApp? XenApp – ключевой компонент платформы хоть и говорить о нем особо нечего. Это обычный сервер удаленных рабочих столов с внесенными изменениями от Citrix, обеспечивающий вычислительные мощности для приложений и их доставку в терминальных сессиях, по протоколу ICA, конечным пользователям. Фактически, все публикуемые приложения выполняются на серверах с этой ролью и должны обладать достаточной производительностью.
Так как в основе XenApp лежит терминальный сервер Windows, лицензии Microsoft (Windows Server CAL) для каждого клиентского соединения на пользователя или на устройство, ни кто не отменял. Поэтому, еще одним обязательным компонентом для платформы XenApp является – Службы лицензирования удаленных рабочих столов с доступными лицензиями.
Дополнительные роли
Помимо базового функционала, существует еще ряд дополнительных ролей расширяющих функционал XenApp.
Single Sign-on Service – обеспечивает безопасность паролей и реализует технологию единого входа для приложений Windows работающих в среде Citrix и рабочих станциях. Пользователи один раз проходят аутентификацию, а служба Single Sign-On делает все остальное — автоматически выполняет вход в информационные системы, защищенные паролем, применяет политики паролей, отслеживает все события, касающиеся паролей в том числе и его смену.
Power and Capacity Management – обеспечивает динамический контроль нагрузки на сервера XenApp. При низкой загрузке, простаивающие сервера могут быть автоматически выключены для экономии электроэнергии.
EdgeSight Server — обеспечивает детальный (до уровня отдельных сессий) мониторинг производительности приложений, работающих в среде XenApp. Предназначен для централизованного анализа и управления производительностью серверов, предотвращения и решения проблем в режиме реального времени.
SmartAuditor Server – обеспечивает запись действий на экране, любого пользовательского сеанса, через любое подключение и с любого сервера XenApp. Так же выполняет архивацию и хранение записей.
Помогла ли вам статья?
