Внутри среды изоляции приложений Citrix Presentation Server

Citrix предлагает новые технологии

В предыдущей статье я определил три ключевые технологии, которые Citrix использовала в своем выпуске Presentation Server 4.0. Это управление использованием ЦП, управление виртуальной памятью и функции среды изоляции приложений. Вместе эти функции предназначены для предоставления администраторам гибкости в размещении приложений и управлении пользовательской нагрузкой на серверах. Мы кратко рассмотрели достоинства каждой технологии и ограничения, стоящие за ними, в предыдущей статье. На этот раз мы подробно рассмотрим потенциально наиболее интересную из этих технологий — изоляцию приложений.

Силосы приложений

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

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

Проблемы с разгрузкой очевидны. Для этого может потребоваться много аппаратного обеспечения, и оно не использует в полной мере то аппаратное обеспечение, которое у вас уже может быть. Использование сервера становится менее полезным критерием для определения нового пространства приложений, чем совместимость, а это означает, что одно из основных преимуществ использования серверов приложений становится устаревшим. Я был в средах, где было буквально 40 серверов приложений, на которых размещалось 40 приложений, и все они работали примерно с 5-процентной нагрузкой. Они просто не хотели головной боли, связанной с управлением несколькими, возможно конфликтующими, приложениями на одних и тех же серверах. Очевидно, что это огромная трата места, ресурсов и даже административного времени. Хотя это правда, что вы устраняете конфликты приложений, вы также увеличиваете количество оборудования, которое нужно отслеживать и заменять в случае сбоя.

Введите изоляцию приложений

Сторонние поставщики давно осознали слабость разрозненности приложений. За последние несколько лет было выпущено несколько продуктов, предоставляющих администраторам функции изоляции, и Citrix, наконец, предприняла шаги, чтобы включить их в свою линейку продуктов. Очень важно отметить, что функция изоляции приложений включена только в Enterprise Edition Presentation Server. В более ранней литературе по продукту указывалось, что она будет доступна в Advanced Edition, и несколько администраторов, к своему ужасу, обнаружили, что только что обновленная подписка Advantage не будет включать эту функцию. По сей день все еще есть примечания к продукту, в которых говорится, что изоляция приложений включена в Advanced Edition, а не только в Enterprise Edition. Так что внимательно проверяйте эти лицензии!

Citrix реализует свою среду изоляции приложений за счет использования виртуализации ресурсов. Между приложением и физическими ресурсами размещается «уровень виртуализации», который перенаправляет виртуальные ресурсы на физические. Ресурсы предоставляются приложению виртуально, и вместо этого любые модификации, запрошенные в ресурсе, происходят на виртуальном уровне. Приложение не знает о перехвате и (мы надеемся!) продолжает работать в обычном режиме. Сопоставление ресурсов между физическими и виртуальными ресурсами зависит от гибкого механизма правил, который позволяет администратору точно определить, что он хочет перенаправить.

Все это прекрасно звучит на бумаге, но что это означает на самом деле? На самом деле вы можете переназначить вызовы файловой системы, вызовы реестра и вызовы именованных объектов, включая COM-объекты. Сопоставление файловой системы очень полезно для приложений, которые используют общий INI-файл для пользовательских настроек, но которые вы хотите разрешить каждому пользователю настраивать. В то время как службы терминалов выполняют базовое перенаправление за счет использования индивидуальных каталогов Windows для каждого пользователя, сопоставление и перенаправление файловой системы дает вам гораздо больший диапазон контроля над файлами INI, расположенными в других каталогах. Помимо обеспечения индивидуальной настройки пользователя, он также обеспечивает уровень защиты от повреждения файлов. Изменения, внесенные в файл одним пользователем, больше не будут влиять на каждого пользователя этого приложения.

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

Последним компонентом изоляции приложений являются именованные объекты. Это может быть что угодно, от событий до COM-объектов, которые Windows создает и использует как часть процесса приложения. Часто однопользовательские приложения требуют монопольного доступа к этим ресурсам, а попытки нескольких экземпляров получить доступ к одному и тому же ресурсу могут привести к нестабильности приложения и даже системы. К именованным объектам относятся COM-объекты Windows, обычно используемые для интеграции данных приложений. Например, они позволяют пользователям встраивать данные из одной программы в другую.

Установка приложений в изолированной среде

С точки зрения администратора, установка приложения в изолированной среде является относительно простым делом. Вы даже можете использовать Installation Manager для простого развертывания в своей инфраструктуре, а с помощью служебных программ командной строки, которые являются частью пакета Application Isolation, вы даже можете использовать сторонние инструменты упаковки, такие как SMS, для развертывания приложений. Так как же узнать, что изолировать? Это сложный вопрос. Когда вы создаете новую среду приложения, Citrix также предоставляет вам набор правил по умолчанию. Этот набор правил по умолчанию использует максимальное количество правил изоляции, обеспечивая максимальную совместимость с большинством приложений. Недостатком, конечно же, является то, что вы также будете использовать гораздо больше системных ресурсов, используя набор правил по умолчанию, чем с набором правил изоляции, специально настроенных для ваших приложений.

Моя рекомендация, если вашему приложению требуется изолированная среда, состоит в том, чтобы понять ваше приложение и его требования. Существует множество бесплатных инструментов, которые действительно позволят вам добраться до сути приложения. Sysinternals (www.sysinternals.com) предлагает несколько чрезвычайно удобных инструментов для анализа вашего приложения и различных вызовов, которые оно выполняет. Изучите приложение с помощью Regmon, Filemon и даже Process Explorer. Как только вы узнаете, от чего зависит приложение и где оно хочет это найти, вы можете настроить свои правила изоляции и включить только те наборы правил, которые вам нужны.

Так почему бы не использовать его всегда?

Если изоляция приложений настолько хороша, почему бы просто не использовать ее постоянно? Есть несколько очень важных опасений по поводу изоляции приложений. Наиболее очевидным является увеличение требуемых ресурсов. Если вы стремитесь к максимальной плотности пользователей на своих серверах, сведение изоляции приложений к минимуму, вероятно, является хорошей идеей. Поскольку с каждым изолированным приложением теперь связан виртуальный уровень, системные ресурсы потребляются быстрее. Обязательно протестируйте каждое приложение и поймите влияние на ресурсы, прежде чем развертывать его на своих серверах.

Помимо влияния на ресурсы, существуют некоторые типы приложений, плохо подходящие для изоляции приложений. Если у вас есть конфликты из-за служб Windows, драйверов устройств, DCOM, имен классов Windows или любых исполняемых файлов приложений, которые не связаны с USER32.DLL. Поскольку изоляция приложений использует драйверы как режима ядра, так и режима пользователя, а также утвержденную корпорацией Майкрософт структуру драйверов фильтров, все перехваты приложений выполняются в пользовательском режиме, чтобы избежать нестабильности, которую может вызвать перехват в режиме ядра.

Изоляция приложений — это не решение всех ваших проблем с совместимостью, но это, несомненно, начало. И, конечно же, если у вас есть Enterprise Edition, она входит в состав программного обеспечения. Трудно возразить против бесплатного! Гибкость наборов правил, предоставляемых Citrix, довольно значительна, и при тщательном планировании вы можете снизить воздействие на системные ресурсы до незначительного уровня и свести к минимуму влияние на пользователя. Простое включение правил по умолчанию, безусловно, даст вам более совместимую среду для однопользовательских приложений и вряд ли потребует ваших административных навыков. Однако реальная ценность заключается в настройке и настройке среды приложения для ваших конкретных нужд. Потратив это время заранее, вы сэкономите время и ресурсы в будущем.