Citrix XenApp — Все статьи Citrix XenApp
Для того что бы опубликовать приложение, и предоставить к нему доступ, оно должно быть где-то установлено. Самый простой способ, это инсталляция приложения прямо на сервере XenApp. При такой схеме, проблематично, а иногда и не возможно установить несколько версий одного и того же ПО. Кроме того, приложения будут жестко привязаны к конкретному серверу. Снять подобные ограничения поможет Streaming profiler – компонент, позволяющий выполнить установку приложения в изолированный контейнер. На практике, такой контейнер представляет из себя обычный каталог в файловой системе с инсталлированным приложением, всеми данными и необходимыми для работы ключами реестра. Таким образом, например, может быть установлено и параллельно запущенно несколько версий офисного пакета. Подобный процесс виртуализации называется профилированием, а конечный каталог с файлам и служебными данными – профилем. Профилирование, должно выполняться в той ОС в которую планируется доставка приложения. Citrix XenApp
Данный подход, позволяет разорвать связь между конкретным сервером, его ОС и приложениями. Например, в случае выхода из строя одного из серверов XenApp, работающие на нем приложения могут быть тут же перезапущены с другого. Для того, что бы несколько серверов XenApp имели доступ к одному и тому же набору приложений и могли заменять друг друга, используется компонент AppHub. По сути это общедоступный каталог на файловом сервере в который помещаются профили подготовленные с помощью Streaming profilera. Таким образом, получаем централизованное хранилище приложений и чистенькие сервера XenApp.
Проблемы изоляции приложений
При профилировании приложений возможно включить в профиль любые сторонние каталоги или отредактировать параметры реестра и некоторые другие вещи. И все же есть и ограничения, на которые следует обратить внимание. В зависимости от выбранной системы, профилирование может выполняется крайне проблемно со следующими типами приложений:
1. Плагины, Add-On/модули, исполняемые и dll файлы, которые встраиваются в приложение другого производителя, расширяя его функциональность.
2. Приложения представленные в системе в виде сервисов запущенных под системной учетной записью, особенно когда параметры настройки хранятся в реестре.
3. Приложения разных производителей или входящие в разные продукты одного производителя взаимодействующее через DDE, OLE, DCOM, COM.
4. Приложения которые в конфигурационных файлах или реестре хранят пути к файлам находящимся в профилях пользователей. Проблема заключается в том, что «упаковка» приложения выполняется под конкретной учетной записью (например под Администратором), а запуск — по другим. И если система виртуализации не преобразует «на лету» обращения к файлам из одного пользовательского профиля (под которым создан образ) в актуальный путь к файлу для текущего пользователя, то приложение работает с ошибкой и тяжело будет определить причину этой ошибки.
Помогла ли вам статья?
