Технология виртуализации настольных систем позволяет размещать в надежных ЦОД полноценные рабочие станции на базе виртуальных машин без необходимости использования WTS/XenApp. Этот подход обладает рядом дополнительных преимуществ и делает концепцию централизованного предоставления приложений привлекательной для тех предприятий, которые до сих пор так и не смогли приспособиться к технологии Windows Terminal Server (WTS) или по каким-то иным причинам вынуждены были отказаться от централизации приложений. Сегодня виртуальные настольные системы способны обеспечить надежную реализацию даже таких экзотических и на первый взгляд неразрешимых задач, как централизованное выполнение сложных и ресурсоемких приложений 3D CAD. В стремлении привлечь внимание клиентов производители соответствующих решений (Microsoft, Citrix, VMware, Kaviza и другие), каждый из которых обладает обширным набором продуктов, разработали предложения для реализации практически любых вариантов технологий предоставления приложений и их комбинаций.

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

 

Рисунок 1. Типичная «смесь приложений» на компьютере пользователя.

 

Отделы ИТ сталкиваются с постоянно возрастающими требованиями к обеспечению экономически выгодного и надежного предоставления приложений, кроме того, необходимо организовать быстрое реагирование на изменения. По этой причине многие предприятия уже довольно давно занялись вопросами централизации корпоративных приложений на основе WTS (как правило, в сочетании с Citrix XenApp), то есть одновременно они частично отказались от тяжеловесной и дорогостоящей концепции «толстых» клиентов. Однако тот факт, что многие приложения были разработаны именно для использования на «толстых» клиентах, при переводе приложений на централизованную платформу создает ряд концептуальных и технических трудностей, которые необходимо преодолеть.

Концепции централизованного предоставления приложений за последние годы претерпели несколько изменений: начиналось все с «серверных вычислений» (Server-Based Computing), затем заговорили о «доставке приложений» (Application Delivery), а сейчас разговор ведется о «виртуализации приложений во внутренних “облаках”» (Application Virtualization in the Private Cloud). О «внутренних» «облаках» речь идет в том случае, если предоставление вычислительных мощностей, приложений, а также ресурсов систем хранения и сетей осуществляется централизованно на основе технологии виртуализации и стандартизованных и высокоавтоматизированных процессов в собственном ЦОД предприятия.

 

ТРЕБОВАНИЯ

Что касается предъявляемых к этой технологии требований, то, по сравнению с развитием общей концепции, здесь ситуация менее динамична. До сих пор для всех проектов актуально следующее: все приложения должны по-прежнему работать так же, как на «толстом» клиенте, и взаимодействовать бесперебойно. Все приложения, предоставляемые на базе централизованной платформы, в отношении производительности, совместимости и функциональности не должны отличаться от своих локальных двойников, размещенных на «толстых» клиентах. Если же они поддерживают лишь ограниченный объем функций, их производительность ухудшилась или приложения уже не могут привычным образом обмениваться динамическими данными (через DDE, OLE и др.), то такие проекты по централизации ресурсов в большинстве случаев изначально обречены на провал из-за их неприятия пользователями.

Предположим, что в ЦОД уже существует четко структурированная инфраструктура внутреннего «облака», поэтому мы будем рассматривать лишь сам процесс интеграции приложений (см. Рисунок 2). Как правило, в проектах по централизации ресурсов этот процесс отнимает наибольшее время, поскольку переход от локальных приложений к централизованным редко происходит по принципу «большого взрыва». Поэтому обычно приложения переводятся на новую централизованную платформу блоками, а отделу ИТ следует уделить пристальное внимание тому, насколько приложения зависят от внутренних систем (Backend) и от других приложений.

 

Рисунок 2. Интеграция «облачных» приложений в решение по централизованному предоставлению приложений.

 

ПРОБЛЕМАТИЧНАЯ СМЕСЬ ПРИЛОЖЕНИЙ

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

По этой причине на платформе WTS/XenApp взаимосовместимые приложения предоставляются в так называемых бункерах приложений (Application Silos). Каждый связанный с «бункером» сервер получает один и тот же спектр приложений, которые частично зависимы друг от друга и способны без взаимных помех параллельно функционировать в рамках пользовательских сеансов — тогда они беспрепятственно контактируют, как это происходит в случае «толстых» клиентов. Таким образом офисные приложения могут обмениваться динамической информацией, интегрировать дополнения (Add-ons) и многое другое. Все это функционирует в рамках одного сеанса WTS/XenApp, а на рабочем месте пользователя, на экране, только отображаются данные.

К сожалению, на практике не всегда получается реализовать централизованное предоставление всех программ из одного единственного «бункера» приложений. Администратору приходится изолировать все «несочетаемое» ПО в пределах одного «бункера» и распределять эти программы между двумя или более бункерами. Следует, однако, упомянуть, что ожидаемый «DLL-ад», который в прошлом наводил такой ужас, сегодня возникает лишь в исключительных случаях. Качественно выполненное пакетирование приложений позволяет эксплуатировать в масштабных средах ИТ серверы XenApp, на которых установлено более 400 приложений, не мешающих друг другу. В результате удается избежать типичных проблем, часто возникающих при разделении несовместимых приложений.

 

«ОБЛАКА» И БРАУЗЕРЫ

В случае приложений, предоставляемых из внешнего (Public) «облака», то есть публичного «облачного» сервиса из внешнего источника, чаще всего речь идет о приложениях для браузера. При этом возникает закономерный вопрос: в каком браузере будет выполняться приложение из «облака»? Программы, работающие на WTS, хоть и отображаются на стороне клиента, но на самом деле выполняются на терминальном сервере. Иными словами, если требуется, чтобы «облачное» приложение обменивалось данными с другими приложениями своего «бункера», то нужно использовать браузер на терминальном сервере. Если же «облачное» приложение работает без каких-либо взаимозависимостей, то оно может выполняться и в локальном браузере клиента. Это необходимо принимать во внимание при аренде решений на основе внешних «облаков».

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

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

 

АВТОМАТИЗАЦИЯ И СТАНДАРТИЗАЦИЯ

Для автоматизированной и стандартизированной установки приложений на платформу WTS/XenApp в виртуализированной среде необходимо использовать инструменты для пакетирования и развертывания (Deployment) программного обеспечения. При создании распределяющих программных пакетов крайне важно принимать во внимание специальные требования к пакетированию со стороны терминальных серверов.

Программные пакеты, разработанные для «толстых» клиентов, нередко лишь частично соответствуют требованиям терминальных серверов. В большинстве своем они нуждаются в дополнительной настройке или расширении, то есть их нельзя просто заимствовать — хотя эта идея на рынке упорно пропагандируется. Чем обширнее централизованная платформа ИТ, тем тщательнее следует осуществлять пакетирование ПО, чтобы впоследствии получить стабильную и производительную общую систему.

 

ПОТОКОВАЯ ПЕРЕДАЧА ПРИЛОЖЕНИЙ

Целью потоковой передачи приложений (Application Streaming) с помощью Microsoft App-V, VMware ThinApp или других аналогичных решений является изолирование проблемных приложений, чтобы они могли работать в том же «бункере» приложений лишь с незначительными ограничениями. Ограничения в коммуникационном плане и более высокий расход ресурсов по сравнению с обычной установкой снижают общую эффективность систем в многопользовательской среде на базе терминальных серверов, поэтому к этой технологии следует прибегать, только когда возникают затруднения при традиционной установке приложений. Дополнительные проблемы, связанные с потоковой передачей приложений, могут возникать и в вопросах технической поддержки, если возможность потоковой передачи заранее не оговаривалась с разработчиком приложения. Весьма велик риск, что в итоге можно остаться без техподдержки со стороны производителя, и если программа имеет критическую важность для деятельности предприятия, этот вопрос следует выяснить заранее.

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

 

ВИРТУАЛЬНЫЕ НАСТОЛЬНЫЕ СИСТЕМЫ

Все вышеупомянутые методы касаются предоставления приложений на терминальном сервере Windows — до сих пор это наиболее распространенный и выгодный метод. Почти все крупные среды с централизацией приложений функционируют на базе WTS с XenApp. Главным достоинством являются, прежде всего, административные функции XenApp. Если WTS/XenApp технически невозможно реализовать или он не подходит для предприятия, в качестве альтернативного варианта можно использовать решение на основе виртуальных настольных систем с Windows XP или Windows 7. Но поскольку концепция виртуальных настольных систем базируется на максимальной унификации параметров конфигурации, то и в этом случае следует создать однородную среду.

В отличие от терминальных серверов, виртуальные настольные системы не являются многопользовательскими платформами — они представляют собой замену традиционных настольных систем на основе централизованной виртуальной машины (Virtual Machine, VM). Если бы каждому пользователю требовалось обеспечить соединение с его персональной системой, то образы виртуальных настольных систем занимали бы слишком много дорогостоящего места в центральных ЦОД, поэтому перед внедрением любого проекта по виртуализации настольных компьютеров необходимо осуществить консолидацию нескольких приложений. Таким образом можно сформировать идентичные пулы рабочих систем, а потребность в централизованных ресурсах останется в допустимых пределах.

Но не всегда виртуальные настольные системы должны полностью заменять платформу WTS/XenApp. Во многих случаях они послужат прекрасным дополнением к среде WTS, если на виртуальную настольную систему будут устанавливаться только те приложения, которые совсем не работают на платформе WTS. Еще одно идеальное дополнение — индивидуальные централизованные рабочие места для разработчиков с локальными правами администрирования для пользователей, поскольку это невозможно в среде WTS.

Франк Зайберт — главный технический директор в компании AppSphere.