Pull to refresh

Microsoft Server App-V — что это, и с чем его едят

Reading time 7 min
Views 47K
Server App-V — интересный продукт Microsoft, несправедливо, на мой взгляд, обделённый вниманием. Вообще заметил, что пока маркетологи и пиарщики этой корпорации ломают копья, демонстрируя очередные таблицы поддержки максимального количества процессоров и терабайт памяти в их продуктах, по-настоящему интересные и полезные вещи проплывают незамеченными и известными лишь узкому кругу увлечённых.
Коротко говоря, Server App-V обеспечивает механизм виртуализации приложений, изоляции их от ОС и упрощает их доставку, как и App-V, только для серверов. В данный момент подаётся с System Center Virtual Machine Management 2012, поскольку может значительно ускорить процедуру развёртывания серверных платформ, что делает его хорошим подспорьем в деле создания и поддержки разного рода «облаков».
Данной статьёй хочу поделиться своим взглядом на концепцию виртуализации приложений в целом, предоставить известную мне информацию о Server App-V (а также упорядочить её в своей голове) и показать, как выглядит процедура развёртывания, на простом примере.

image

Сказать, что виртуализация облегчает управление ИТ, значит соврать. Виртуализация сама по себе экономит место, энергию, деньги, но не время и трудозатраты. Ибо процедуры настройки и обслуживания что виртуального, что физического серверов практически идентичны: подготовить «железо», установить ОС, установить нужные приложения, настроить всё это, а далее обновлять, патчить и траблшутить.
Облегчают управление ИТ различные средства автоматизации. И тут нам помогают системы управления виртуальной инфраструктурой — SCVMM, vCenter… Можно приготовить шаблоны виртуальных машин, как в части virtual hardware, так и в части настроек ОС. Однако остаётся третий слой инфраструктуры — приложения. И здесь, как показывает практика, прогресса практически не наблюдается со времён… даже не знаю. За весь мой 12-летний опыт работы, мало что поменялось. Дистрибутивы, разве что, больше стали.

Итак, какие способы набивки ОС (не важно, сервера или рабочей станции) приложениями нам доступны?

1. Классический — вставляем диск/флешку или идём в общую папку «Distrib» на файлообменнике и запускаем инсталлятор. Способ простой, надёжный, но отнюдь не быстрый. А главное — нудный и утомительный, если надо штамповать машины на регулярной основе. Можно установить приложения непосредственно в шаблон ВМ, чтобы после развёртывания уже получить всё установленное, но, во-первых, каждая ВМ требует свой набор софта, а во-вторых, для обновления каждой программы нужно будет перетряхивать все шаблоны. Ладно если есть централизованная система обновления, как у Microsoft WSUS или там 2GIS, но это не у всех, а оставлять апдейты на откуп пользователю тоже плохая идея.

2. Централизованное развёртывание (group policy, SCCM, скрипты). Снимает проблему рутины (по крайней мере в части массово используемых приложений), снимает проблему обновления. Создаёт новые трудности. Влияние на виртуальную среду. Массовый апдейт Adobe Reader может ввести ферму VDI в кому на пол дня. Мало того, что машины потянут дистрибутив по сети примерно в одно время, так вдарит ещё и по процессору и по дискам. Кроме того, не все приложения можно развернуть в режиме «тихой» установки.

Оба вышеуказанных способа имеют такой общий недостаток, как то, что приложения становятся, по сути, частью ОС — наполняют её своими библиотеками, записями в реестре, службами, конфигами и разными непонятными файлами. Не всё бывает возможно вычистить или даже корректно обновить, а порой удачно рухнувшее приложение или повреждённая DLL тащит за собой операционную систему в пучину BSOD и прочих нежелательных явлений. Ещё одним общим недостатком можно считать то, что два (и более) разных приложения могут требовать разных версий java, например, или иным образом взаимоисключать друг друга (в бытность поддержки мной Microsoft Exchange 2003, помню, нельзя было использовать Outlook на сервере с установленным Exchange из-за того, что оба использовали библиотеку с одинаковым названием, но разным функционалом)

3. Доставка виртуальных приложений (App-V, ThinApp, XenApp). Это когда приложение специальным образом подготавливается — устанавливается в специальный виртуальный контейнер и доставляется в конечную ОС простым копированием (App-V, ThinApp) или вообще запускается и работает на удалённом сервере (Citrix XenApp). Снимает проблему рутины, снимает проблему обновления, снижает нагрузку на процессоры и диски при развёртывании, изолирует систему от последствий сбоев приложения и упрощает процедуру подготовки виртуальных машин — помимо того, что надо отметить галочками нужные шаблоны конфигурации и ОС, нужно будет указать, какое ПО нам нужно будет иметь внутри ВМ и, по сути, всё. Конечно, это не волшебная таблетка, тут есть свои недостатки, начиная от стоимости дополнительных лицензий и заканчивая тем, что не всё ПО можно вот так виртуализировать, но, думаю, иметь представление об этом пути надо, а если есть возможность, то и использовать. Когда-то и виртуализация серверов казалась сомнительным мероприятием.

Server App-V


По сути, решение Server App-V аналогично продукту App-V. Также для «упаковки» приложений используется [Server] App-V Sequencer, а для развёртывания на конечной системе нужен App-V Agent. Для доставки App-V на десктопы используется специальный сервер App-V (App-V Server), а для Server App-V — VMM.

image

Использование одинаковых терминов в названии приводит к путанице для поисковиков, что ещё сильнее уменьшает шанс Server App-V получить известность и вызывает раздражение при поиске информации.
При всей схожести, однако, это два разных продукта и не стоит пытаться использовать Server App-V Sequencer для создания Desktop App-V приложений. И наоборот.

Для чего нам нужна виртуализация приложений на серверах? Это ж не десктопы, тут зачастую один сервер — одно приложение, и сомнительно, что можно виртуализовать, например, Exchange. Это да, нельзя. Как и Microsoft SQL Server (а вот, MySQL, слышал, что можно), SharePoint. возможно ещё какое-то крупное серверное ПО. В разработке следующих версий есть приоритет на поддержку Sharepoint и ролей Exchange. Также под ограничение попадают антивирусы и программы, предполагающие работу на уровне ядра и/или «железа». Списка явно поддерживаемого ПО я тоже не встречал, однако известно, что Server App-V оптимизирован для приложений со следующими атрибутами:
  • хранящиеся локально на диске;
  • web-приложения (для IIS);
  • Windows Services;
  • SQL Server Report Services;
  • взаимодействие с реестром (registry), объектами COM+/DCOM, WMI, использование функционала локальных пользователей и групп, планировщика задач.


image

Собственно, поддержка большего числа этих атрибутов и отличает Server App-V от App-V для десктопов.Сравнение конкретных возможностей в таблице:
App-V Server App-V
  • Изменение конфигурации и данных применяется ко всем пользователям
  • Файлы приложения (а также COM / DCOM, службы и WMI-провайдеры) доступны только самому приложению
  • Добавление новых процессов в виртуальную среду производится вручную

  • Изменения конфигурации и данных применяются к конкретному пользователю
  • Файлы приложения (а также COM / DCOM, службы и WMI-провайдеры) доступны всем процессам компьютера. Например, службой из контейнера App-V можно управлять через Service Manager в общем списке служб сервера
  • Добавление новых процессов в виртуальную среду производится секвенсером на основе эвристики. Конечно, возможно добавление вручную.



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

Установка


Установочные файлы можно найти либо на носителе с System Center VMM 2012 в директории X:\SAV, либо на сервере с установленным VMM — C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\SAV.
Включают в себя установщик секвенсера, агента и cmdlet' для того и другого.
Установить можно на ОС следующих версий:
  • Windows 2003 R2 SP2;
  • Windows 2008 SP2;
  • Windows 2008 R2;
  • Windows 2012.

Сама установка, что секвенсора, что агента, думаю, ни у кого трудностей не вызовет. Стоит иметь ввиду, что секвенсор лучше устанавливать на чистую свежую ОС. Даже агента App-V на ней быть не должно.
Агент может быть установлен в тихом режиме:
AgentSetup.exe /q INSTALLDIR=c:\serverappv SWIGLOBALDATA=c:\SWIGlobalData SWIUSERDATA=c:\SWIUserData SWIFSDRIVE=q /ACCEPTEULA 


INSTALLDIR – путь установки.
SWIGLOBALDATA – определяет директорию, где будут храниться основные данные (включая пакеты приложений).
SWIUSERDATA – определяет директорию хранения пользовательских данных.
SWIFSDRIVE – определяет букву диска для файловой системы виртуальной среды.
ACCEPTEULA – принимает лицензионное соглашение. Обязательный параметр для «тихой» установки.
Также доступны следующие ключи:
/q – активация «тихого» режима.
/u – деинсталляция.
/? – вызов справки, привязанной к инсталлятору.
Лог установки сохраняется в %Temp%.


И агент и секвенсор в ходе установки создают виртуальный диск (по умолчанию — Q:) для файловой системы виртуальной среды.

Sequencing


Не знаю, как точно перевести этот термин. Вариант «постановка приложения в очередь», увиденный в описании курса УЦ Специалист, кажется бредовым. Я называю этот процесс «упаковкой».
Итак, мы установили секвенсор. На свежеустановленную, чистую ОС. «Упаковка» каждого приложения требует чистой ОС. И тут нам неоценимую помощь могут оказать снапошоты ВМ. Что ещё следует иметь ввиду перед началом процедуры:
  • Лучше всего чтобы версия и редакция ОС совпадала с версией и редакцией целевой ОС (куда будет развёртываться).
  • Необходимые роли и средства (Roles and Features), если они требуются приложению, должны быть установлены ДО процедуры его виртуализации.
  • Если виртуализуемое приложение предполагает создание баз данных в MS SQL, требуется установленный Microsoft SQL Server 2012 Feature Pack


Далее запускаем секвенсор (как выглядит его главное окно, можно увидеть в начале данной статьи). Для создания нового пакета виртуального приложения (Virtual Application Package) выбираем целевой дистрибутив, задаём имя и обращаем внимание, что конечной директорией по умолчанию будет указан наш диск виртуальной файловой системы (Q:). Без необходимости его менять не стоит, а кроме того, установить приложение надо будет туда же в ту же папку.

image

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

image

Развёртывание


Для развёртывания пакета виртуального приложения на целевой ОС должен быть установлен Server App-V Agent. Необходимые приложению Roles and Features сервера должны быть установлены ДО развёртывания приложения. Распространение полученных пакетов осуществляется средствами VMM (Library — Application Profiles), но для разового развёртывания, например в тестовой среде, можно воспользоваться PowerShell cmdlets (AgentCmdletsSetup.exe).

PS C:\> Set-ExecutionPolicy Remotesigned
PS C:\> Import-Module ServerAppVAgent
PS C:\> Add-ServerAppvPackage –Name MyApp –Manifest C:\MyApp\MyApp_manifest.xml –SFT C:\MyApp\MyApp.sft –Configuration C:\MyApp\deploymentconfig.xml

Пример:

image

В результате мы получим в меню «Пуск» ссылку на новое приложение. Размещаться оно будет на диске Q:. Ссылка в свойствах ярлыка будет иметь примерно такой вид:

"C:\Program Files (x86)\Server Application Virtualization\savlnch.exe" /launch:"7-Zip File Manager 9.20.0.0" 


Вот и всё. Можно пользоваться.
Tags:
Hubs:
+13
Comments 10
Comments Comments 10

Articles