Реализация новых приложений может привести к огромным затратам на этапе подготовки и тестирования из-за часто возникающих конфликтов DLL, которые в английском разговорном называют «адом DLL». Держать эти проблемы под контролем позволит виртуализация приложений.

Привязка операционных систем и программ к отдельному рабочему месту обусловлена исторически. На этом фоне в «ландшафтах ИТ» с большим количеством пользователей или множеством приложений предоставление последних оборачивается немалыми проблемами. Любое распространенное приложение добавляет в операционную систему новые компоненты, к примеру ключи реестра, файлы (в особенности динамически подсоединяемые библиотеки - Dynamic Link Library, DLL), типы шрифтов, виртуальные машины Java и проч., или оно заменяет существующие системные компоненты собственными, якобы лучшими. В результате новые инсталляции и обновления отрицательно влияют как на стабильность операционной системы, так и на работу других приложений, нуждающихся в определенных системных компонентах в конкретной версии или непосредственно интегрированных в систему.

Особую проблему представляют собой среды с вычислениями на базе серверов (Server Based Computing, SBC), потому что многие - в том числе и современные - приложения созданы для применения одним пользователем на одной машине. Вопреки общепринятым стандартам программирования специфичную для каждого пользователя информацию - к примеру настройки конфигурации или временные переменные, - приложения часто сохраняют для всей машины: в виде записи HKEY_Local_Machine в реестре, в конфигурационных файлах, файлах .ini и т. д. Тем самым они делают использование приложений в многопользовательских средах практически невозможным. Наряду с этими основополагающими проблемами - конфликтами между приложениями, несколькими версиями и множеством пользователей - существует ряд прочих параметров, которые заметно затрудняют предоставление приложений. Достаточно вспомнить о жестко программируемом задании путей, о приложениях, которые могут запускаться хоть и несколькими пользователями, но лишь в определенной конфигурации, а также о пока еще не «вымерших» приложениях DOS.

ТРАДИЦИОННЫЕ ПОДХОДЫ К РЕШЕНИЮ

Различные утвердившиеся на рынке технические подходы адресуют один аспект распределения приложений: это скорее логистическая задача предоставления ряда приложений множеству пользователей за короткое время с организацией централизованного управления доступом. Инструменты для распределения программного обеспечения и управления рабочими столами автоматизируют инсталляцию операционных систем и пользовательского программного обеспечения и частично дополняют их функциями управления «заплатами» или миграции пользовательских конфигураций (см. статью Вильгельма Грайнера «Программное обеспечение из рукава» в январском номере «Журнала сетевых решений/LAN» за этот год).

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

Еще один, принципиально иной поход к предоставлению приложений пользователям представляют собой «вычисления на базе серверов»: выполнение приложений происходит централизованно, к примеру на Microsoft Terminal Server или Citrix MetaFrame Presentation Server. Пользователь посредством специальных клиентов получает отображение приложений с возможностью взаимодействия по сети. Преимущество подхода заключаются в том, что приложения требуется администрировать лишь на немногих центральных серверах, и только что выполненное обновление программного обеспечения без промедления становится доступно всем пользователям.

Для работы пользователь SBC должен иметь постоянное соединение с сервером. Кроме того, в последнее время все чаще возникают проблемы из-за несовместимости приложений в средах SMB: на совместимость приходится проверять приложения не только одного пользователя, но и все остальные. Для предотвращения известных конфликтов приложений предприятия организуют так называемые серверные «загоны», т. е. группы серверов, которые предоставляют лишь часть - предположительно, совместимых - приложений. Следствием являются дополнительные административные издержки и не полностью загруженные серверы.

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

ВИРТУАЛИЗИРОВАННЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ

Наиболее надежный на сегодняшний день способ разрешения конфликтов между приложениями предлагает технология виртуализации операционной системы на имитируемом аппаратном обеспечении, которая реализуется, к примеру, при помощи VMware или Microsoft Virtual Server. Инсталляция операционных систем на «виртуальном аппаратном обеспечении», а точнее, на виртуально выделенном аппаратном обеспечении, потенциально позволяет предоставить любому приложению собственную операционную систему. Накладными расходами на выделение аппаратных ресурсов операционным системам можно пренебречь. Тем не менее последовательный подход к виртуализации операционных систем для разделения приложений требует большого числа по-разному сконфигурированных систем и оборачивается неизбежным ростом административных издержек.

ВИРТУАЛИЗАЦИЯ ПРИЛОЖЕНИЙ

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

Рисунок 1. Сегодня виртуализация может распространяться на различные уровни.

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

Исходя из этого (возможно, позже переработанного пакета), на целевом компьютере ко времени выполнения создается «песочница». В ней содержатся все специфические для приложения компоненты. Одновременно она защищает приложение от доступа извне. Требования, предъявляемые приложением (к примеру, функция DLL), выполняются по возможности в пределах среды «песочницы». Если нужный компонент здесь отсутствует, то запрос переадресуется базисной операционной системе. Этот интеллектуальный, «полупрозрачный», подход позволяет сократить накладные расходы на построение виртуальной системной среды до приемлемого уровня. Необходимое для создания «песочницы» дисковое пространство равно нескольким мегабайтам в расчете на один пользовательский сеанс. Общее снижение производительности процессора также незначительно.

Использование «песочницы» обеспечивает одновременное предоставление различным приложениям, различным пользователям и операционной системе других версий DLL, конфигурационных файлов, записей в реестрах, виртуальных машин Java и т. д. Эта герметизация приложений, конечно, требует особого внимания к коммуникации и совместной работе приложений. Виртуальные приложения взаимодействуют из «песочницы» с базовой операционной системой и с реально инсталлированными приложениями без каких-либо ограничений. Таким образом обеспечивается взаимодействие через буфер обмена, общий доступ к дискам, сети или принтерам, а также использование групповых директив для всех видов доступа (см. Рисунок 2).

Рисунок 2. Принцип виртуализации приложений.

Ограничения следует учитывать, когда различные приложения, к примеру, обращаются друг к другу напрямую через объекты OLE. Для того чтобы такое было возможным, администратор помещает приложения - SAP или Excel - в одну «песочницу».

МНОГОСТУПЕНЧАТОЕ ПРЕДОСТАВЛЕНИЕ

Предоставление виртуализированных приложений в пределах платформы виртуализации происходит при взаимодействии множества компонентов в рамках прозрачного для пользователя многоступенчатого процесса. Создание пакета должно выполняться на пустом компьютере и состоять из инсталляции, тестирования и базовой конфигурации приложения (приложений). Пакеты - иногда они базируются на уже существующих пакетах - могут быть адаптированы: администратор, к примеру, может видоизменить виртуальную файловую систему или виртуальный реестр, а также инсталлировать дополнительные компоненты. Результатом становится пакет, включающий в себя готовое инсталлированное приложение, готовую конфигурацию и пиктограммы. Администратор копирует пакет на сервер и снабжает его пользовательскими правами из существующих пользовательских каталогов. Этот сервер по требованию предоставляет пакеты приложения - но без их обработки! Таким образом, он может обслуживать от многих сотен до нескольких тысяч пользователей на один процессор. Кроме того, сервер осуществляет контроль за правами и лицензиями, мониторинг и составление отчетов.

Клиентский компонент необходим для того, чтобы создать список приложений на основании регистрационной информации и построить на ПК «песочницу», где эти приложения будут работать. В отличие от концепции SBC система, на которой инсталлирован такой компонент, должна предоставлять необходимые ресурсы для выполнения приложения - прежде всего соответствующую задачам мощность процессора и оперативную память. В классической среде с персональными компьютерами или ноутбуками конечные устройства должны быть достаточно производительными для обработки приложений, даже когда сервер предоставляет их в виртуализированном виде. В этом отношении помещение приложений в «песочницу» отличается от концепции SBC: в среде Terminal Server упомянутый клиентский компонент устанавливается на терминальном сервере, а значит, ресурсы для обработки приложений в случае SBC должны находиться на сервере.

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

Управление пакетами виртуальных приложений со специфичными групповыми конфигурациями осуществляется централизованно. Специфичные изменения сохраняются в файл в пользовательском профиле и предоставляются при следующем обращении к приложению. Этот механизм кэширования - возможно, в комбинации с автономным предоставлением пакетов на накопителе USB или компакт-диске - позволяет также мобильным пользователям работать с виртуализированными приложениями при отсутствии соединения с сетью (см. Рисунок 3).

Рисунок 3. Доступ к серверу с виртуализированными приложениями может осуществляться с мобильных, стационарных и SBC-клиентов.

ПРЕИМУЩЕСТВА ВИРТУАЛИЗАЦИИ ПРИЛОЖЕНИЙ

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

Концепция «песочницы» как ядра виртуализации позволяет предоставлять различные комбинации приложений, несмотря на идентичную конфигурацию клиентской и серверной систем - без нанесения вреда операционной системе из-за намеренных и случайных попыток записи. Идеальной представляется такая реализация вычислительной системы, где наряду с обновлением системы безопасности инсталлирован только клиент виртуализации, а все выполняемые приложения предлагаются в виде виртуальных услуг.

При программном управлении можно сэкономить до 90% ресурсов на предоставлении приложений и обновлений. Максимальное сокращение расходов на администрирование и снижение стоимости аппаратного обеспечения достигается в средах SMB, так как предприятию больше не нужно инсталлировать несовместимые приложения в серверные «загоны» с относительно умеренной нагрузкой.

Фалько Грэфе - менеджер по продажам в дистрибьюторской компании AND. С ним можно связаться по адресу: wg@lanline.awi.de.

? AWi Verlag