Немного о XenApp
Citrix XenApp — комплекс программного обеспечения для виртуализации, централизованного управления и доставки Windows-приложений на большинство существующих платформ и устройств. В основе XenApp лежат службы удаленных рабочих столов Windows (Remote Desktop Services, RDS) или попросту терминальный сервер, а также собственные средства виртуализации приложений. Ощущение того, что приложения реально работают на локальном компьютере, создается с помощью клиента Citrix Reciver, который выводит все необходимые ярлыки в меню.
Платформа требует грамотного планирования каждой роли и всей архитектуры в целом
Пуск или на рабочий стол, обеспечивает доступ к локальным каталогам и принтерам.
При открытии опубликованного приложения запускается почти обычная терминальная сессия, в рамках которой оно и открывается. При этом пользователь не видит ни рабочего стола сервера, ни панели задач, только основное окно приложения. Такой режим называют «бесшовным». Кроме терминальных сессий, особенно удобных в случае с тонкими клиентами и планшетами, возможна доставка всего виртуального приложения целиком на устройство пользователя. Применение такого метода позволяет работать при отсутствии подключения к сети.
Архитектура
Платформа XenApp состоит из девяти функциональных ролей, три из которых являются базовыми и шесть дополнительными. Базовые роли обеспечивают виртуализацию и доставку приложений конечным пользователям и являются обязательными для развертывания. Дополнительные расширяют функционал платформы. Их доступность зависит от редакции 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 возвращает список приложений и публикаций, доступных пользователю.
Компонент 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.
При такой схеме проблематично, а иногда и невозможно установить несколько версий одного и того же ПО. Кроме того, приложения будут жестко привязаны к конкретному серверу. Снять подобные ограничения поможет Streaming profiler — компонент, позволяющий выполнить установку приложения в изолированный контейнер. На практике такой контейнер представляет собой обычный каталог в файловой системе с инсталлированным приложением, всеми данными и необходимыми для работы ключами реестра.
Таким образом, например, может быть установлено и параллельно запущено несколько версий офисного пакета. Подобный процесс виртуализации называется профилированием, а конечный каталог с файлами и служебными данными — профилем. Профилирование должно выполняться в той ОС, в которую планируется доставка приложения.
Данный подход позволяет разорвать связь между конкретным сервером, его ОС и приложениями. Например, в случае выхода из строя одного из серверов XenApp, работающие на нем приложения могут быть тут же перезапущены с другого. Для того чтобы несколько серверов XenApp имели доступ к одному и тому же набору приложений и могли заменять друг друга, используется компонент AppHub. По сути, это общедоступный каталог на файловом сервере, в который помещаются профили, подготовленные с помощью Streaming profilera. Таким образом, получаем централизованное хранилище приложений и чистенькие серверы XenApp.
Проблемы изоляцииприложений
При профилировании приложений возможно включить в профиль любые сторонние каталоги или отредактировать параметры реестра и некоторые другие вещи. И все же есть и ограничения, на которые следует обратить внимание. В зависимости от выбранной системы при профилировании могут возникнуть проблемы со следующими типами приложений:
> Плагины, Add-On/модули, исполняемые и dll-файлы, которые встраиваются в приложение другого производителя, расширяя его функциональность.
> Приложения, представленные в системе в виде сервисов, запущенных под системной учетной записью, особенно когда параметры настройки хранятся в реестре.
> Приложения , взаимодействующие через DDE, OLE, DCOM, COM.
> Приложения, которые в конфигурационных файлах или реестре хранят пути к файлам, находящимся в профилях пользователей. Проблема заключается в том, что «упаковка» приложения выполняется под конкретной учетной записью (например, под Администратором), а запуск — под другими.
Дополнительные роли
Помимо базового функционала, существует еще ряд дополнительных ролей, расширяющих функционал XenApp. SingleSign-on Service обеспечивает безопасность паролей и реализует технологию единого входа для приложений Windows, работающих в среде Citrix и рабочих станциях. Пользователи один раз проходят аутентификацию, а служба Single Sign-on делает все остальное — автоматически выполняет вход в информационные системы, защищенные паролем, применяет политики паролей, отслеживает все события, касающиеся паролей, в том числе и их смену.
Power and Capacity Management обеспечивает динамический контроль нагрузки на серверы XenApp. При низкой загрузке простаивающие серверы могут быть автоматически выключены для экономии электроэнергии. EdgeSightServer обеспечивает детальный (до уровня отдельных сессий) мониторинг производительности приложений, работающих в среде XenApp. Предназначен для централизованного анализа и управления производительностью серверов, предотвращения и решения проблем в режиме реального времени.
SmartAuditorServerобеспечивает запись действий на экране, любого пользовательского сеанса, через любое подключение и с любого сервера XenApp. Также выполняет архивацию и хранение записей.
Организация инфраструктуры
Давайте рассмотрим организацию инфраструктуры.
Фермы
Первое, что предложит выполнить установщик после развертывания узла XenApp, — это создать новую ферму (Farm) или добавить текущий узел в существующую. Ферма представляет собой объединение серверов, кластер, в рамках каждой назначаются администраторы и их права, публикуются приложения, определяются зоны и группы серверов, а также описываются политики балансировки нагрузки. Конфигурация всех объектов фермы хранится в едином DataStore. Аналогию ферм XenApp можно провести с доменами Windows, которые во многом выполняют схожую организационную функцию.
Зоны
Архитектура продукта рассчитана как на маленькие внедрения из нескольких серверов, так и на очень большие инфраструктуры, состоящие из тысяч географически распределенных узлов XenApp.
В последнем случае используются зоны — группа узлов XenApp, расположенных в рамках одного сетевого сегмента со стабильными и производительными в первую очередь по задержкам (latency) каналами. Зоны, по сути, являются аналогами сайтов Active Directory и зависят от топологии сети.
Например, у компании существуют два центра обработки данных, в каждом из которых есть какое-то количество узлов XenApp. В случае если внешние каналы между ЦОД не являются достаточно стабильными и производительными, разумнее организовать отдельную зону для каждого ЦОД. Необходимо это потому, что в рамках одной зоны выбирается только один сборщик данных (Data Collector), который регулярно производит опрос узлов XenApp, что приводит к переизбытку трафика между ЦОД. Когда зоны две, как в текущем примере, то в каждой из них выбирается свой сборщик данных (обычно первый сервер в зоне). Они обмениваются конечной информацией о состоянии серверов в зонах, а также являются шлюзами для остальных узлов зоны.
Кроме минимизации трафика и упорядочивания инфраструктуры, на уровне зон возможно обеспечение отказоустойчивости, когда одна из зон начинает принимать подключения при выходе из строя основной зоны. Также можно просто привязать часть пользователей к серверам ближайшей зоны. Но при всех вроде бы весомых плюсах Citrix не рекомендует разводить их в больших количествах. Нужно стремиться к минимизации их числа и в идеале иметь только одну зону, где все узлы соединены производительными и стабильными каналами.
Группы
Для более удобного оперирования множеством серверов, их следует объединить в группы (Worker Group), в которые могут входить как отдельные серверы XenApp, так и целые организационные единицы (OU) из AD.
Намного проще, публикуя приложение, указать группу, чем выбирать отдельные серверы из списка. Или при добавлении новых серверов просто поместить их объекты в соответствующие OU каталога AD. Это избавляет от необходимости изменения настроек каждого опубликованного приложения.
Доставка приложений
В общем случае существует два основных вида доставки приложений.
Доставка приложений в терминальных сессиях— Accessed from a server
При этом приложение реально выполняется на сервере XenApp, а пользователь работает лишь с «картинкой». Плюсом данного подхода является то, что задействованы вычислительные ресурсы сервера, что позволяет запускать ресурсоемкие приложения на тонких клиентах или планшетах. Минус — при обрыве сетевого соединения приложение становится недоступным, невозможна и автономная работа (без подключения к серверу XenApp).
В данном случае приложение может быть установлено прямо на сервере XenApp или же в виде профиля на общем сетевом ресурсе (AppHub). Приложение должно быть спрофилировано под ОС сервера, так как фактически оно выполняется на нем.
Потоковая доставка приложений прямо на устройство пользователя— Streamed to client
При такой схеме профили приложений, размещенные на общем сетевом ресурсе, целиком доставляются/копируются на устройство пользователя и на нем же выполняются. Ресурсы сервера XenApp не задействуются. К плюсам можно отнести возможность работать автономно с приложениями в условиях, когда нет доступа к сети. Из минусов — необходимость дополнительно устанавливать Offline Plug-in, который доступен только для ОС Windows и требует дополнительного лицензирования.
Приложения должны быть спрофилированы под ОС конечных пользователей.
Существует еще и третий вариант доставки приложений, который, по сути, комбинирует оба предыдущих — Streaming if possible, otherwise accessed from a server.
В случае если клиентское устройство поддерживает потоковую доставку (установлен Offline Plug-in) и приложение спрофилировано под ОС пользователя, то такой вариант и станет использоваться. Иначе приложение будет доставлено в терминальной сессии.
Про редакции
Citrix XenApp распространяется в трех редакциях, отличающихся в основном составом ролей: Platinum, Enterprise и Advanced edition. А исчерпывающие разборы по конкретным функциям с их описанием доступны в Интернете [4].
О системных требованиях
Для версии XenApp 6.5, которая на текущий момент является последней, основное требование при развертывании — Windows Server 2008 R2 (за исключением редакций Server Core и Web server) в качестве базовой платформы.
Объем и производительность аппаратных ресурсов зависит от требований публикуемых приложений, числа активных сессий и рассчитывается индивидуально для каждой среды. Все дополнительные компоненты (.NET Framework 3.5 SP1, Microsoft Visual C++ 2005 SP1 Redistributable (x64)), а также роли Windows Server (RDS, IIS), необходимые для работы XenApp, будут автоматически развернуты и настроены мастером установки.
В случае если в сети нет SQL-сервера, соответствующего требованиям роли DataStore: Microsoft SQL Server 2005 SP3 (x32 and x64) или старше и Oracle 11 g R2 32-bit Enterprise Edition будет автоматически установлен MS SQL Server 2008 Express.
Что касается разнесения ролей по разным серверам, то здесь схема, приведенная на рис. 1, является рекомендуемой, но не обязательной, хотя стремиться к ней все же нужно. Все основные роли могут быть установлены на один сервер. Сервер не должен являться контроллером домена! Наличие AD не является обязательным, платформа XenApp нормально функционирует в рабочей группе и использует локальные учетные записи. Правда, такой вариант крайне неудобен и подходит только для небольших организаций. Отдельно хочется отметить бесполезность аппаратной виртуализации у используемых процессоров. Виртуализация приложений выполняется программными средствами на уровне ОС.
Доступ к приложениям
Для получения доступа к опубликованным приложениям можно воспользоваться браузером или настроить Citrix Reciver. При запуске приложения из браузера наличие Citrix Recivera также обязательно! Под настройкой понимается указание адреса веб-интерфейса и учетных данных пользователя. После чего будут созданы ярлыки на рабочем столе или в меню Пуск. В принципе в браузере выполняются только авторизация и выбор приложения, а дальше всю работу делает Reciver, что прозрачно для пользователя.
Основными версиями клиентского приложения являются: CitrixReciver— версия, которая по умолчанию предлагается для загрузки на официальном сайте [6]. Существует для большинства современных платформ, в том числе Windows (включая Mobile, RT и CE)LinuxUnixMaciOS AndroidChrome OSBlackBerySymbian. Выполняет основные функции и не требует прав администратора для установки.
CitrixReciverEnterprise[7] — расширена дополнительными возможностями, связанными в первую очередь с безопасностью. Поддерживает технологию единого входа (Single Sign-On), Pass-through authentication и авторизацию по смарт-картам. Существует только для платформы Windows.
OnlinePlug-in— обеспечивает доступ к опубликованным приложениям в терминальных сессиях. По умолчанию поставляется вместе с Citrix Reciver.
OfflinePlug-in— обеспечивает автономную работу при потоковой доставке приложений. Существует только для Windows.
Разграничение прав на работу с приложениями
Доступ к каждому публикуемому приложению настраивается индивидуально.
При наличии AD можно выбирать отдельных пользователей, группы, OU и даже целые домены или просто разрешить использование всем, как это предложено по умолчанию. Также присутствуют дополнительные фильтры по IP-адресам. Приложения, к которым у пользователя нет доступа, отсутствуют в списке.
Что касается административных функций, то здесь все очень гибко и просто. Все объекты инфраструктуры XenApp: серверы, группы серверов, приложения и прочее имеют ряд связанных с собой действий, которые выполняются администратором. XenApp содержит свой собственный список администраторов, в который может быть добавлен любой доменный или локальный пользователь. В интерфейсе Citrix AppCenter предусмотрено гибкое распределение полномочий между администраторами. Например, очень легко сделать так, что рядовой пользователь домена будет иметь все права по управлению инфраструктурой XenApp, а администратор домена или предприятия вовсе останутся без доступа. Также Citrix предоставляет систему журналирования всех вносимых изменений, которая активируется на уровне фермы.
Балансировка нагрузки и отказоустойчивость
Хотя на первый взгляд архитектура XenApp может показаться сложной в плане поддержки и обеспечения отказоустойчивости основных компонентов и всей платформы в целом, на самом деле все проще, чем кажется.
Если говорить о стандартных ролях Windows Server, таких как Active Directory и DNS, то здесь доступность достигается традиционной репликацией каталога и передачей зон на второстепенный или резервный сервер. Отказоустойчивость SQL-сервера (DataStore) обеспечивается кластеризацией. А постоянную доступность файлового сервера (AppHub) для узлов XenApp можно реализовать, разместив копию профилей приложений на другом сервере и настроив DFS (Distributed File System). Все приведенные выше методики давно известны и применяются повсеместно.
Похожая ситуация и с серверными ролями от Citrix, вебинтерфейсом и Secure Gateway. Здесь для распределения нагрузки и обеспечения их отказоустойчивости предполагается использование входящих в состав Windows Server средств NLB (Network Load Balancing) или стороннего балансировщика, например, NetScaler [5]. Естественно, это означает наличие как минимум двух серверов с этими ролями.
Немного интереснее ситуация со сборщиком данных (Data Collector). По умолчанию это первый сервер с ролью XenApp. Все последующие серверы, добавленные в зону, также могут выполнять эту функцию, но делать этого не будут, пока основной сборщик данных функционирует. Но, как только он станет недоступным, его функцию автоматически возьмет на себя сервер с наивысшим приоритетом в зоне.
В общем, переживать по поводу сборщика данных при наличии нескольких серверов XenApp не стоит. Делегировать данную роль выделенному серверу нет никакого смысла, так как на обслуживание 1000 серверов в зоне сборщик данных задействует порядка 300 Мб ОЗУ. Единственное, где может понадобиться внимание администратора, — это установка приоритета серверам в зоне.
Всего доступно четыре уровня приоритетов:
MostPreferred— наиболее предпочтительный. Его имеет первый сервер в зоне. Он же по определению и является текущим сборщиком данных.
Preferred— предпочтительный. По умолчанию его не имеет ни один из серверов. Приоритет может присвоить администратор. В случае выхода из строя основного сборщика данных новый в первую очередь будет выбран из серверов с этим приоритетом.
DefaultPreference — предпочтение по умолчанию. Приоритет по умолчанию для всех серверов в зоне. Если серверы Preferred отсутствуют, то новый сборщик данных будет выбран из серверов с данным приоритетом.
NotPreferred— не предпочтительный. По сути, отсутствие приоритета. Стоит присвоить серверу, на который не нужно возлагать роль сборщика данных. Стоит отметить, что в случае отказа всех серверов с другими приоритетами в зоне, этот все равно будет обязан выполнять роль сборщика данных!
Еще запущеннее ситуация с функцией XML Broker. Как уже говорилось, это одна из функций XML Service, которая, в свою очередь, присутствует и на каждом XenApp- сервере.
Получается, как и в случае со сборщиком данных, функцию брокера XML способен выполнять любой из серверов XenApp, если эта возможность не выключена на этапе подключения его к ферме. Но все не так радужно.
При том, что брокер XML функционирует на каждом из серверов XenApp, задействован будет только тот, который указан в настройках веб-интерфейса! И каких-либо встроенных средств обеспечения доступности брокера XML или динамического изменения его адреса в настройках нет. Эта жесткая привязка к конкретному брокеру, на мой взгляд, является недочетом архитектуры. Единственный способ обеспечения доступности данной функции, который я вижу, это опять же NLB, не слишком изящно смотрящийся при решении этой задачи.
Что касается тяжеловесов с ролью XenApp, то здесь все просто и прозрачно. В случае выхода из строя одного из серверов фермы приложения пользователей, работающих на этом сервере, аварийно завершат работу. Но при их повторном запуске роль веб-интерфейса, насколько это возможно, равномерно распределит пользовательские подключения на оставшиеся серверы. По умолчанию пользователи подключаются к разным серверам, но критерии распределения ресурсов, а также их пределы тонко настраиваются с помощью правил.
Платформа Citrix XenApp, на мой взгляд, является достаточно сложной системой в плане устройства и развертки, она состоит из множества ролей и компонентов. Возможно, по этой причине для развертывания и предлагается готовый образ для виртуальной машины.
Платформа требует грамотного планирования каждой роли и всей архитектуры в целом, и особенно при построении географически распределенной инфраструктуры.
1. Страница загрузки Citrix XenApp Trial — http://www.citrix.com/ products/xenapp/try.html.
2. Развертывание Citrix XenApp 6 EVA на XenServer —
3. Про установку и получение лицензий — http://ivirt-it.ru/2013/06/ install-and-licensing-citrix-xenapp.
4. Обзор отличий редакций XenApp 6 — http://www.vmstart.ru/tso- kalkulvator/202-sravnenie-vvPuskov-citrix-xenapp.
5. Обзор функционала NetScaler — http://habrahabr.ru/post/177329.
6. Страница загрузки Citrix Reciver для большинства платформ — http://www.citrix.ru/downloads/citrix-receiver.html.
7. Страница загрузки Citrix Reciver Enterprice —
8. Расчет примерной стоимости на 100 пользователей — http:// www.vmstart.ru/resheniva/256-citrix-xenapp-100-polzovatelej.