App Volumes в Horizon 8 2012 – Aleksandr Mykhalchenko`s Blog

В самых общих словах о технологии App Volumes рассказывалось в статье «Установка VMware Horizon Version 2012 от «А» до «Я»». Напомним, ее использование помогает в одновременной доставке приложений в виртуализированные среды десктопов и централизованном управлении ими, а доступна она только для клиентов уровня VMware Horizon Enterprise Edition-лицензии.

Этот продукт рука об руку идет с Horizon, являясь ценнейшим его дополнением в крупных корпоративных разворотах с жесткими требованиями к сложности, многосоставности и безопасности работы с приложениями в применяемой VDI-концепции:

О технологии App Volumes

Вкратце отметим, что App Volumes является инструментом управления жизненным циклом и процессом доставки в режиме реального времени приложений. Он доставляет софт, не относящийся к золотым образам ВМ VDI и RDSH, на десктопы с помощью виртуальных дисков, не модифицируя при этом ни сами приложения, ни рабочие столы, с которых они будут загружаться.

Преимуществ использования App Volumes немало. В частности, стоит отметить следующее:

Стабильный пользовательский опыт работы при нестабильных условиях экономики;
Разделение управления приложениями и процессов конкурентной доставки;
Возможность задавать пользовательские настройки для управления жизненным циклом приложений. В том числе сочетать логику менеджмента с бизнес-требованиями, мгновенно обновлять настройки и сами приложения, либо же при следующем входе с систему, обеспечивать их изолированность и делать проще все ключевые операции с AppStack.

App Volumes с равным успехом применяется в облачных, гибридных и on-premise-средах, отлично масштабируется, не меняя свои коренные подходы в работе, в разы снижает интенсивность обращений в саппорт и количество тикетов в хелп-деск. Приятно, что с точки зрения пользователя, работа записываемых томов и AppStack совершенно незаметна.

Архитектура App Volumes

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

Он устанавливается в гостевой операционной системе непостоянных ВМ, связывается с инстансами App Volumes Manager с целью определить права на пакеты и записываемые тома:

Компоненты App Volumes

Помимо App Volumes Agent среда продукта обладает виртуальными дисками и базовой ОС. Логическими компонентами решения являются:

App Volumes Manager (AVM) – консоль для управления App Volumes (конфигурирование, создание приложений и пакетов, назначение пакетов и записываемых томов) и распределения нагрузок агента;
App Volumes Agent – работает на виртуальных десктопах или RDSH-серверах и является уровнем абстракции файловой системы и реестра в целевой системе, занимается виртуализацией записи в файловой системе по мере необходимости;
База данных App Volumes (SQL для продакшена или SQL Express для не продакшен-сред), содержащая информацию о конфигурации AppStack, Writable volume, транзакциях, пользователях, виртуальных машинах и правах. Множество серверов App Volumes Manager могут подключаться к единственной SQL-БД;
Приложение – используется в назначении AD-разрешений для пакетов и является компонентом, содержащим один или несколько пакетов. Поддерживает маркерные и пакетированные типы назначений;
Пакет приложений – том (только для чтения), являющийся, по сути, виртуальным диском и содержащий любое кол-во Windows-приложений. Пакеты добавляются к приложениям, используемым в процессе их назначения AD-разрешениям (группам, пользователям, OU, машинам). Каждой персональной системе или пользователю можно сопоставлять множество пакетов. Однажды созданный пакет может разворачиваться где-угодно и монтируется при каждом входе пользователя на рабочий стол. По дефолту шаблон пакета имеет размер в 20 ГБ, а общее число создаваемых пакетов лимитируется максимальным количеством дисковых присоединений в Windows и vSphere;
Программа – софт, захваченный пакетом. Пакет может захватить как одну, так и несколько программ;
Writable volume – специфический пользовательский том, где пользователь сохраняет свои данные, записывается информация локального профиля, в т. ч. и настройки приложений, лицензирование и др. В каждый момент времени пользователю назначается только один записываемый том;
Маркер – атрибут приложения, используемый для обозначения текущего пакета, значительно упрощающий задачи управления его жизненным циклом;
AD – используется для назначения пользователей и определения их прав на пакеты и записываемые тома;
vCenter Server – им пользуется App Volumes для подключения к ресурсам в vSphere-среде. Он управляет хостами vSphere с целью присоединения и отсоединения пакетов и записываемых томов к целевой ВМ;
Упакованные ВМ – очищенные с помощью App Volumes Agent Windows-ВМ, которые используются для захвата софта в пакеты для распределения.

Так как все эти компоненты содержатся в хранилище данных, его производительность конкретно влияет на их работу.

Лимиты конфигурации и использования App Volumes

Для ключевых компонентов App Volumes существуют декларированные вендором лимиты конфигурации. Рассмотрим их в разрезе составляющих решения.

Размер сервера AVM:

Кол-во конкурентных входов	< 2 000	2 000 – 5 000	5 000 – 7 000	> 7 500
AVM на под	2	3	4	4+1 на каждые 2 500 пользователей
CPU на AVM	4	6	8	8
RAM на AVM, ГБ	4	8	16	16
Кол-во vCenter на под	2	3	4	4+1 на каждые 2 000 ВМ
Изменения в Manager\clock.yml	Servers:4 Workers:1 (Default)	Servers:6 Workers:2	Servers:8 Workers:2	Servers:8 Workers:2
Логинов в секунду	2	3	4	4+1 на каждый AVM

Размер среды:

Виртуальных машин на каждый ESXi-хост должно быть не более 110 (цифра актуальна для «железа» уровня Dual Intel Xeon E5-2686 v4(18 core 2.3GHz, 2.7GHz All Core Turbo));
Гостевая ВМ должна иметь 2 vCPU и 4 ГБ RAM;
На каждом vCenter – не более 2 000 машин. В продакшен-средах рекомендуется применение нескольких vCenter Server, чтобы для больших Horizon-подов, множественных дата-центров или сайтов стала доступной масштабируемость. Если работали с множественными vCenter Server, обратно возвращаться к сольной конфигурации не рекомендуется.

Ограничения по хранилищу:

На одну ВМ должно быть 8-10 AppStack (наилучшие результаты при 5);

Важно! По количеству AppStack от среды к среде цифры сильно отличаются. Но в любом случае рекомендовано создавать логические группы приложений на меньшем кол-ве AppStack для лучшей производительности.

Кол-во пользовательских подмонтирований на AppStack (VMDK) – 1 000 (VMFS), 2 000 (vSAN);
Кол-во UWS на хранилище данных – 1 000 (VMFS), 2 000 (vSAN).

Важно! Группы хранилищ с VMFS используются для достижения большей масштабируемости.

Советы по дизайну App Volumes

Разработка грамотного дизайна имплементации решения позволяет добиться его высокой пользовательской полезности, безупречности функционирования даже в критических ситуациях и покрытия конкретных бизнес-требований к текущим задачам предприятия. Следующие рекомендации включают в себя нюансы организации App Volumes, в т. ч. его масштабируемость, балансировку нагрузок и защищенность:

Использовать минимум два сервера App Volumes Manager, сконфигурированные позади балансировщика нагрузок (необходим SQL Server общего доступа). Если используется четыре менеджера и больше, load balancer жизненно необходим. Либо же DNS-сервер, разрешающий каждый App Volumes Manager циклически;
Ограничивать инстанс App Volumes SQL-БД;
Размещать любые приложения режима ядра в базовом образе, а не в пакете;
Для агрегирования нагрузок и IOPS использовать группы хранилищ (если не применяется vSAN) двух типов – группу хранения пакетов (для репликации) и группу хранения записываемых томов (для распределения). В этом случае доступны две опции:

- автоматической репликации (пакеты помещаются на любой датастор в группе и реплицируются по всем хранилищам в группе),
- автоматического импорта (после репликации пакет импортируется в App Volumes Manager и доступен для назначения из всех датасторов в группе);

Размещать пакеты в оптимизированном для чтения хранилище (100%-оптимизация операций чтения);
Размещать записываемые тома в хранилище, оптимизированном для рандомных IOPS (50/50% чтение/запись);
Назначать как можно меньше пакетов каждому пользователю или устройству. Соответствующие ограничения см. выше в подразделе «Лимиты…». В идеале нужно создать пакет ключевых программ, получаемых большинством или всеми юзерами сразу, а также специализированные пакеты для департаментов;

Важно! Пакеты и ВМ нельзя помещать в один и тот же датастор, если используется VMFS, NFS и тому подобные. С vSAN такое ограничение неактуально.

Важно! App Volumes 4 по дефолту использует оптимизированную конфигурацию Machine Managers:

Вносить изменения только в случае крайней необходимости.

Включить опцию «Mount Local storage» в App Volumes для первоочередной проверки локального стораджа и затем проверку центрального хранилища данных. В этом случае размещенные локально на ESXi-хосте пакеты будут монтироваться быстрее. Рекомендуется поместить VMDK на локальном хранилище и его дубликаты на центральном для подстраховки в случае падений хостов. Тогда ВМ будут перезагружаться на других, имеющих доступ к размещенным на центральном хранилище VMDK, хостах.

Важно! Все хосты vSphere должны иметь одинаковые учетные записи пользователя уровня рута.

В процессе принятия дизайна App Volumes важно опираться на изложенные в статье «Установка VMware Horizon Version 2012 от «А» до «Я»» теоретические знания и соображения по архитектуре решения Horizon, а также на best practice организации и масштабирования vSphere (наш материал «Инсталляция и разворот VMware vSphere 7.0»).

Требования и совместимость

По сетевым требованиям вся необходимая информация, касающаяся открытия портов и использования протоколов, выложена в разделе «Порты для связи App Volumes Manager с другими компонентами Horizon» нашей статьи «Установка VMware Horizon Version 2012 от «А» до «Я»» .

Совместимость с версиями баз данных проверяется здесь.

А с версиями самого Horizon, ThinApp, клауд-архитектур, DEM, VMware Tools, vRO, vCenter Server, vSAN и ESXi – здесь.

Максимальный на момент написания этой статьи функционал доступен в следующей конфигурации:

Гипервизор vSphere 7.0U1;
vCenter 7.0U1;
Windows Server 2019 на ВМ с App Volumes Manager;
SQL Server 2016;
Windows 10 и Windows Server 2019 ОС агентов.

Также в процессе подготовки к развороту App Volumes стоит опираться на ограничения, изложенные в подразделе «Лимиты…» выше. Единственное, на чем целесообразно остановиться отдельно – это на размере пакетов и записываемых томов. Они должны быть достаточно большими, чтобы позволять инсталлировать программы, равно как и их апдейты. Важно помнить, что для пакетов всегда следует оставлять доступными до 20% свободного места на диске, чтобы администраторы могли без проблем обновлять программы без изменения размера томов пакетов. Конечно же, так как технология применяет VMFS, место на хранилище не потребляется сразу же.

App Volumes совместим со следующими браузерами:

Internet Explorer 9 и свежее,
Mozilla Firefox 28 и позднее,
Safari 7 и выше,
Google Chrome 21 и новее.

А теперь немного о требованиях к безопасности в больших продакшен-средах. На App Volumes Manager и SQL следует открывать только необходимые порты файервола. В идеале – использовать NSX для динамического назначения политик файервола, основываясь на роли сервера.

Обязательно следует заменить самоподписанный TLS/SSL-сертификат на подписанный App Volumes Manager по доступной авторизации сертификатов. Подробный гайд по процедуре, если с ней еще не знакомы, можно изучить здесь. Затем нужно убедиться, что App Volumes Manager принимает сертификат vCenter Server как доверенный.

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

Стоит учесть, что иногда производственные схемы требуют наделения временными привилегиями по требованию пользователей или их групп для разрешения разовых инсталляций приложений – важно аккуратно оценивать риски безопасности в каждом таком случае. В целом же, под App Volumes рекомендуется завести отдельный служебный аккаунт AD, а для применения сервис-аккаунта App Volumes хорошо создать отдельную роль администратора в vCenter Server.

Подготовка к развороту App Volumes

Подготовка к развороту App Volumes относительно проста и в ее рамках нам нужно будет сделать следующее:

Создать и настроить нужные пользовательские аккаунты и группы безопасности в AD и vCenter Server (см. чуть ниже соответствующий подраздел);
Убедиться, что среда и все ее компоненты удовлетворяют нормам главы «Требования и совместимость» выше;
Записать в блокнотик FQDN сервера, на котором будет инсталлироваться App Volumes Manager;
Убедиться, что .NET Framework 3.5 или свежее установлен на этом сервере;
Загрузить ISO-инсталлятор App Volumes.

На данный момент актуальной является 2012-я версия App Volumes 4:

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

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

App Volumes Manager разворачивается на каждом поде каждого сайта, а App Volumes Machine Manager настраивается для связи с vCenter Server в каждом ресурсном блоке. Серверы менеджера должны представлять собой виртуальные машины vSphere. Приятно, что при этом все доступные функции среды, вроде НА кластера, репликации и SRM, применимы и к App Volumes. Machine Manager позволяет использовать разные учетные записи для каждого vCenter Server. Имена хранилищ данных и хостов vSphere должны быть уникальными в рамках всей среды;
App Volumes поддерживает как однодоменную инфраструктуру AD, так и со множеством доменов, независимо от того, настроено ли между ними доверие. При использовании нескольких AD с Universal Security Groups все домен-контроллеры, доступные для App Volumes Manager, должны хостить Global Catalog (GC) (следует включить). Если подобное по каким-либо причинам недоступно, следует настроить указанные домен-контроллеры в конфигурации App Volumes Manager. Добавить несколько AD домен-контроллеров можно, зайдя на вкладку «Active Directories» в секции «Configuration» App Volumes Manager. Кроме того, требуется разрешить объекты, не присоединенные ни к какому домену («Non-Domain Entities»):

Вместо UPN, App Volumes Manager ищет объекты AD по GUID, благодаря чему пользователи по доменам и OU могут перемещаться как угодно, и даже переименовываться (как и компьютеры), и при этом на доступе их к приложениям, пакетам, AppStack и записываемым томам это никак не отразится. Также важно заметить, что App Volumes Manager поддерживает запись в базе данных для любой AD, главное, чтобы они были видны агенту или назначены определенному приложению, пакету, AppStack или записываемому тому. При этом доступны процессы ежечасной синхронизации (до 100 объектов AD, а если объектов больше – все, что не вошли в эту синхронизацию, в первую очередь обработаются при следующей, через час);

Важно! В случае, когда пользователь был удален, а затем с таким же именем был добавлен в AD, и App Volumes автоматически директорию еще не синхронизировал, могут создаваться конфликтующие записи во Writable Volumes. Они будут показываться в менеджере, пока не произойдет синхронизация.

Для обеспечения адекватной работы App Volumes Manager даже в случае высокого спама логинов, лучше подключить дополнительный внешний балансировщик нагрузок (NSX Advanced Load Balancer). О том, как это сделать писалось в статьях «Дизайн VMware NSX-T Data Center 3.1» и «Администрирование и настройка VMware NSX-T Data Center 3.1» нашего цикла по сетевой виртуализации. Работа внутреннего балансировщика нагрузок в простейшей ситуации с двумя App Volumes Manager:

App Volumes одинаково хорошо сотрудничает с группами SQL Server «FCI» и «Always On availability». SQL-БД должны размещаться на Microsoft SQL Server с НА и только так;
По управлению местом существуют две опции в менеджменте свободного пространства для записываемых томов:
- Создание Writable Volumes при следующем логине пользователя (процессы хранилища и выделения емкости зависят от поведения юзера);
- Перенаправление доступа к записываемым томам (в т. ч. начальное создание) на конкретный десктоп или группу десктопов (поведение пользователя диктует, когда шаблон Writable Volumes копируется).

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

Процесс присоединения пакетов состоит из двух этапов:

Подмонтирование диска (упакованный VMDK к ВМ);
Виртуализация контента пакета (объединение файлов и регистрация входов гостевых ОС).

Время завершения последнего сильно варьируется, в зависимости от состава и тяжести программ в пакете.

Важно! В именах пакетов нельзя использовать символы «& “ ‘ < >».

Важно! На запакованной ВМ и целевой должны быть одинаковый патч ОС и уровень сервис-пака. Запакованную машину нельзя использовать, если ранее была деинсталлирована любая из захватываемых программ, иначе захват не будет успешен.

Также напомним, что перед процессом упаковки ВМ или присоединения к ней пакетов обязательно снять снэпшот. А если в среде ранее применялся App Volumes, установка новой версии или апгрейд до нее в обязательном порядке требует предварительной деинсталляции агента и перезагрузки машины.

Интеграция App Volumes в среду Horizon

Чаще всего, когда мы говорим об App Volumes, имеется в виду разворот данного решения в среде Horizon. В этой связи также нужно обозначить несколько правил и краеугольных камней имплементации:

Никогда нельзя включать Horizon Agent в пакет App Volumes. Агент устанавливается на золотом образе ВМ. Рекомендуется оптимизация золотого образа под VDI или RDSH (обязательно рассмотрим в нашей следующей статье про администрирование Horizon), а также использование оптимизации ОС;
Нельзя использовать виртуалку Horizon как очищенную упакованную ВМ. Вначале нужно деинсталлировать агент, если он там есть. Это важно, так как ранее установленные агентом зависимости (например, SxS-библиотеки общего пользования Microsoft) не переустанавливаются, из-за чего не могут быть захвачены процессом упаковки;
При установке агента App Volumes следует убедиться, что таргетированный пользователь не является объектом применения DEM GPO;
При возврате машины десктопа с App Volumes Agent к старому снэпшоту нужно убедиться, что она корректно выключена во избежание проблем с синхронизацией (касается упакованных ВМ десктопа, а также машин рабочих столов и золотого образа для связанных и мгновенно склонированных пулов);
При использовании пулов связанных клонов стоит убедиться, что политика «Delete or Refresh machine on logoff» в Desktop Pool Settings установлена на значение «Refresh Immediately», чтобы достичь согласованности между данными ВМ при входе в систему.

Создание пользовательских аккаунтов и учетных записей AD для работы с App Volumes

Предварительно, перед начальной инсталляцией App Volumes нужно завести пользовательские аккаунты и учетные записи AD:

Служебный аккаунт через vCenter Server с привилегиями администратора (для интеграции App Volumes в vCenter Server);
Подготовить данные ролей с правами администратора на всех ESXi-хостах, если планируется в будущем использовать прямое подключение к таким хостам или же применение функции «Mount to Host» со связью vCenter Server.

Важно! Имена пользователей должны содержать исключительно ASCII-символы.

Принцип процедуры создания в AD учетных записей с разными типами прав описывался в подробностях в статье «Установка VMware Horizon Version 2012 от «А» до «Я»». Далее нам понадобятся два типа записей: служебный аккаунт AD и группа администраторов. Пользователь служебного аккаунта AD для работы с App Volumes предоставляет доступ к AD для чтения и необязательно должен быть администратором. Но, в настройках обязательно задать, что для его пароля срок истечь не может. В задачи группы администраторов (локальных) будет вменяться:

Устанавливать компоненты App Volumes на целевых серверах;
Использовать записываемые тома с проинсталлированными пользователями приложениями;
Упаковывать пакеты приложений.

Разворот App Volumes

Разворот App Volumes представляет собой последовательную инсталляцию App Volumes Manager, агентов App Volumes и связанных компонентов.

Инсталляция App Volumes Manager

App Volumes Manager ставится на Windows-сервер и представляет собой веб-интерфейс для управления и доставки приложений конечным пользователям. Он помогает в автоматизации упаковки приложений, сборе пользовательской информации и обновляет историю административных действий. Для его установки делаем следующее:

Монтируем ISO инсталлятора на ВМ Windows Server, либо же извлекаем его содержимое в расшаренную папку, доступную с этой виртуалки;
В папке «Installation» дважды кликаем на файл «setup.msi», после чего откроется соответствующий визард. Пробежимся по его страничкам;

«VMware App Volumes Installation Wizard». Просто жмем «Next»;

«License Agreement». Галочкой принимаем и «Next»;

«App Volumes Install Screen». Выбираем «Install App Volumes Manager» и жмем «Install»:

После этого автоматически перебрасывает на визард «App Volumes Manager Setup» и на первой его страничке просто жмем «Next». Далее по страницам:

«Choose a Database». Выбираем «Install Local SQL Server Express Database» и жмем «Next»;

«Database Server». Отжимаем галочку на «Enable SQL Server certificate validation». «Next»:

Ждем несколько минут, пока установится БД.

«Choose Network Ports and Security Options». «Next»;

«Custom Setup». «Next»;

«Ready to Install App Volumes Manager». «Install»;

«Completed the App Volumes Manager Setup». «Finish». Опять ждем.

Первичная настройка App Volumes Manager

Заходим в веб-браузер на «https://<appvolumesHostname>», где «appvolumesHostname» – это имя хоста сервера App Volumes Manager или его IP-адрес. Появится приветственная страничка:

где нажимаем «Get Started». Далее сделаем следующие необходимые настройки:

На вкладке «AD Domains» регистрируем ранее созданный AD-домен, заполнив все поля, кроме:

«Active Directory Domain Name» (FQDN AD-домена);

«Username» (имя ранее созданного пользовательского аккаунта AD-домена, можно и без прав администратора);

«Password»;

«Security» (из выпадающего меню выбираем «LDAP over TLS» и «Disable certificate validation (insecure)» – для демонстрации принципа инсталляции этого хватит),

Остальное оставляем пустым:

Теперь он появится в общем списке доменов на этой вкладке.

На вкладке «Admin Roles» используем кнопку «Search» в поле «Search Groups», чтобы найти группу, созданную для администрирования App Volumes и жмем на «Assign» внизу:

Теперь она появится в общем списке этой вкладки;

На вкладке «Machine Managers» назначаем:

«Type» – выбираем «vCenter Server» из выпадающего меню;

«Hostname» – вводим FQDN машины vCenter Server;

«Username» – имя служебного аккаунта с административными привилегиями на vCenter Server

«Password».

Остальное можно оставить по дефолту:

Может появится предупреждение о сертификации – принимаем его кнопкой «Accept».

Назначенный vCenter Server должен появится в списке. «Next»;

На вкладке «Storage» вводим дефолтное местонахождение хранилища для пакетов приложений и записываемых томов:

«Next»;

Появится окно «Confirm Storage Settings», где нужно нажать на «Set Defaults»;

На странице «Upload Templates» по строке «Host» выбираем «Use vCenter» из выпадающего меню, ставим галочки на нужных шаблонах и кликаем «Upload», чтобы началась подгрузка:

На вкладке «Settings» кликаем «Next».

Установка App Volumes Agent

Для работы App Volumes помимо установленного менеджера нам нужно иметь один или несколько клиентов на целевых десктопах и пакующем компьютере, для которых указывается адрес агента App Volumes Manager (адрес балансировщика нагрузки).

Важно! Нельзя ставить агент на ту же самую машину, что и App Volumes Manager.

Проинсталлировать агент можно по silent-методу, либо же используя обычный способ.

В первом случае применяется Microsoft Windows Installer (MSI), для чего открываем командную строку Windows на целевой машине и заходим на файл «App Volumes Agent.msi». Вводим следующую команду:

msiexec.exe /i “App Volumes Agent.msi” /qn MANAGER_ADDR=<Manager_FQDN/IP> MANAGER_PORT=<port> EnforceSSLCertificateValidation=<0or1>

Важно! Параметр «EnforceSSLCertificateValidation» опциональным стал только в App Volumes 4U1. В мажорном обновлении все параметры обязательны.

Для доступа к назначенным записи компьютера опубликованным приложениям, равно как и к базовому образу, следует добавить параметр типа «DelayVirtualizationType», «DWORD», к «HKLM\SYSTEM\CurrentControlSet\services\svservice\Parameters», установив его значение, равное «0».

При втором методе следуем такой процедуре:

Запускаем инсталлятор «App Volumes», принимаем лицензионное соглашение, а затем вместо установки App Volumes Manager, которая описывалась выше, выбираем «Install App Volumes Agent» и жмем «Next»;
Вводим IP-адрес и порт;
Опционально снимаем галочку с «Disable Certificate Validation with App Volumes Manager», если не хотим, чтобы агент валидировал сертификат менеджера. «Install»;
Следуем далее всем инструкциям и финально запускаем инсталляцию кнопкой «Finish»;

Теперь осталось только перезагрузить упакованную ВМ, чтобы агент окончательно установился, и настроить SSL-сертификаты для него, если галочку, как советовалось выше, с валидации не снимали.

Аналогично silent-методу, для доступа к назначенным записи компьютера опубликованным приложениям и к базовому образу добавляем описанный выше параметр.

Администрирование и использование App Volumes

Теперь, когда менеджер и агент у нас установлены, можно переходить непосредственно к работе с App Volumes.

UI App Volumes

Пользовательский интерфейс App Volumes Manager весьма информативен и понятен в процессе навигации администратора решения по его функционалу. Каждая вкладка его верхнего меню («Inventory», «Directory», «Infrastructure», «Activity», «Configuration») раскрывает свой соответствующий комплект страничек:

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

Inventory

На этой вкладке перечислены все компоненты инвентаря: Application, Packages, Programs, Assignments, Attachments, Writables (см. скриншот выше):

«Application». Здесь можно смотреть список приложений App Volumes, создавать новые, импортировать, создавать для выбранного приложения пакет, редактировать его или удалять, назначать его одному или нескольким объектам;
«Packages». Позволяет паковать приложения, устанавливать на определенном пакете маркер, редактировать его, перемещать при ручной репликации и удалять;
«Programs». В этом списке мы найдем все программы, используемые нашими пакетами, она очень полезна для нахождения дубликатов и устранения конфликтов между его членами, а также для уточнения информации по конкретной программе, включая издателя, точную версионность, ассоциированные с ней пакеты и т. п.;
«Assignments». Здесь можно управлять назначениями приложений определенным объектам (пользователям, компьютерам, группам или организационным юнитам) – там виден весь их список, а также ассоциированные с приложениями пакеты.
«Attachments». Помогает понять, какие пакеты и записываемые тома прикреплены к ВМ, что доставлено пользователю и что используется прямо сейчас, а также тип подмонтирования, назначения и другую важную информацию.
«Writables». Здесь можно найти весь инструментарий для управления записываемыми томами (смотреть существующий список, создавать новые, импортировать их, апдейтить, редактировать, включать или выключать, удалять, назначать и многое другое – подробнее их функционала коснется наша следующая статья из цикла по Horizon, посвященная «Dynamic Environment Manager»).

Infrastructure

Вкладка «Infrastructure» дает понимание инфраструктуры App Volumes, в целом, и полезную информацию по каждой ее составляющей (машинам, хранилищам и группам хранения). Она включает странички «Machines», «Storages», «Storage Groups»:

«Machines». Можно просматривать существующие и удаленные машины, которые распознаны этим инстансом App Volumes Manager, в чем помогает удобный фильтр, а также повторно ресканировать vCenter Server, чтобы обновить по ним информацию;
«Storages». Здесь показан список хранилищ, включая расшаренные датасторы, которые видит App Volumes Manager, и если нажать по конкретному «+», покажется информация о том, прикреплен ли этот сторадж, используется ли он, количество AppStack и пакетов, записываемых томов, а также полный перечень доступных хранилищ и многое другое;
«Storage Groups». Можно создавать группы хранения, что полезно для автоматизации репликации пакетов и AppStack, а также в процессе распределения записываемых томов по разным датасторам. Ключевыми опциями для групп хранения является назначение стратегии распределения (Spread/Round-robin) и тип автоматизации (импорт и репликация), также при задании новой группы можно выбирать шаблон хранилища и его самого, используя список или фильтрацию по префиксу имени.

Activity

Незаменимая, поистине, в траблшутинге и мониторинге вкладка «Activity» состоит из подвкладок «Pending Actions», «Activity Log» и «System Messages»:

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

Configuration

На этой вкладке задаются все нужные в работе App Volumes Manager настройки. Когда мы описывали процедуру разворота этого Appliance выше, нам пришлось разобраться с его первичной настройкой, пробежавшись по визарду «Get Started». Однако, там было далеко не все, что нужно для полноценного функционирования продукта, да и впоследствии слишком часто случаются ситуации, когда нужно многое менять. И тогда мы обращаемся к вкладке «Configuration», состоящей из разделов «License», «AD Domains», «Admin Roles», «Machine Managers» и «Storage Settings»:

«License». Здесь следует проверить, показана ли информация о лицензии, а также задавать данные новой, нажав на кнопку «Edit», а затем – «Upload» и пройдясь по всем предложенным пунктам, предварительно загрузив файл с ней со страницы загрузок VMware;

«AD Domains». Эта страница показывает информацию о настроенных доменах и список домен-контроллеров и позволяет зарегистрировать новый, а также управлять уже введенными в систему. По каждому AD домену можно уточнить Netbios, базу LDAP, имя пользователя, задать защищенное или незащищенное соединение, порт, домен-контроллер и дату его создания, а по каждому домен-контроллеру – статус соединения, время последнего подключения, последний случай сбоя и счетчик фейлов;

«Admin Roles». Здесь доступен просмотр и управление ролями, назначенными для AD-групп, выбор набора привилегий под каждую. Уточнять детали и знакомиться со списком помогает «Manage Roles», а удаление ранее назначенной роли доступно после выбора ее здесь и нажатия на «Remove». Еще можно на этой подвкладке зайти в «Assign Role» и выбрать встроенную или настраиваемую роль (доступные встроенные – «Administrators», «AppStacks Administrators», «Administrators (Read only)», «Security Administrators», «Writables Administrators»);
«Machine Managers». На этой подвкладке регистрируется и настраивается Machine Manager, то есть, определяется тип менеджера (vCenter Server/ESXi (Single Host)/VHD In-Guest), задается имя хоста, пользователя и пароль, и если напрямую подключение должно идти к ESXi-серверам, то заполняется поле «Mount ESXi», а также другие типы возможных подключений, если они актуальны, задается максимальное кол-во конкурентных операций подмонтирования в очереди. И, конечно же, просматривается доступный список уже подготовленных Machine Manager;
«Storage Settings». Доступны настройки хранилища для пакетов, записываемых томов и AppStack (для более старых версий App Volumes), можно создавать удобные шаблоны стораджей, чтобы потом всегда иметь их под рукой для подгрузки и назначения.

Научиться в деталях работать с GUI App Volumes Manager и обрести глубокое понимание практического применения его функционала помогут выложенные в свободном доступе лаборатории вендора по этой тематике, родная «песочница», а также специализированные курсы VMware.

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

Настройка упаковывающей ВМ и виртуальных машин конечных точек

Упаковывающая ВМ используется для захвата битов приложений виртуальным диском (VMDK или VHD-файлом) для последующего распределения к пользователям или компьютерам. В приложении App Volumes может быть одна или несколько версий пакетов приложений.

Чтобы создавать такие пакеты, нужно первоначально настроить упаковывающую ВМ. Она должна максимально соответствовать версии ОС и уровню ее патчей по отношению к машинам конечных точек. И, конечно же, на упаковывающей виртуалке должно быть проинсталлировано ПО агента. Как и на машинах конечных точек.

Для начала создаем оптимизированный образ Windows для виртуального десктопа Horizon (как это сделать рассказано в статье «Базовые инструменты администрирования VMware Horizon Version 2012 и настройка групповых политик»), но на пункте инсталляции агентов виртуальных рабочих столов устанавливаем исключительно агент App Volumes:

Затем:

Приветственную страницу визарда просто прокликиваем кнопкой «Next»;
На странице «Server Configuration» вводим FQDN сервера App Volumes Manager:

«Next»;

На странице «Ready to Install App Volumes Agent» нажимаем «Install»;
На странице «Completed the App Volumes Agent Setup» – «Finish».

Может запросить перезагрузить ВМ – делаем.

Чтобы проверить правильность установки агента App Volumes на упаковывающей машине, следует зайти на App Volumes Manager в секцию «DIRECTORY» на вкладку «Computers» – она должна появиться в списке:

Важно! Ни агент Horizon, ни DEM нельзя устанавливать на упаковывающей машине.

По окончанию создания упаковывающей ВМ, следует ее выключить и снять с нее снэпшот. Обязательно записать себе где-то имя этой машины.

Для создания и настройки виртуальных машин конечных точек нужно создать золотой образ, которые будет использоваться в подготовке пулов виртуальных десктопов или ферм RDSH-серверов (на эту тему рассказано достаточно в нашей статье «Установка VMware Horizon Version 2012 от «А» до «Я»»), а также иметь готовый оптимизированный образ Windows для виртуальных десктопов Horizon (см. выше).

После этого следует создать мгновенно-склонированный десктопный пул (как это делать рассказывалось в вышеупомянутой статье), используя этот золотой образ при помощи агентов Horizon и App Volumes (предварительно они инсталлируются в таком порядке: сначала Horizon Agent, затем агент DEM и только после этого – App Volumes Agent). И, наконец, с помощью консоли Horizon стоит предоставить пользовательскому аккаунту права на использование этого пула.

Управление приложениями с помощью App Volumes

Ключевым отличием App Volumes 4 от предыдущих версий стало разделение процессов упаковки от доставки, полное управление жизненным циклом приложений из одной точки, а также возможность упаковывать их однажды, а затем распространять в любое время и везде. Упаковкой занимается единственное приложение, способное к индивидуализации своих задач и доставке в любой комбинации затребованного, а динамическое назначение использует маркеры, благодаря чему новый пакет получает маркер «CURRENT» и становится доступным для всех, кто определен для получения именно этой версии.

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

Создание пакета приложений

Перед тем, как мы приступим к созданию первого нашего пакета приложений, следует убедиться, что на сетевой шаре, доступной с упаковывающей машины, загружены две версии инсталлятора приложений, например, Notepad++, которые будут использоваться в процессах упаковки. Также нам понадобятся все установленные и настроенные до этого компоненты (App Volumes Manager, сама упаковывающая ВМ и машины конечных точек, а также агенты на них, созданный виртуальный десктопный пул из виртуалок с агентом App Volumes), а пользователю аккаунта конечной точки выданы права на использование этого пула.

Для начала заходим через браузер на «https://<appvolumesHostname>», где «appvolumesHostname» – это FQDN сервера App Volumes Manager, под учетной записью администратора. Затем открываем инвентарь App Volumes («INVENTORY») и на вкладке «Packages» создаем новый пакет приложений:

Отметьте, мы попросили создать новый пакет отсюда, так как, когда создавалось приложение, галочка стояла на «Create a Package». Если ее не поставить, приложение можно выделить на вкладке «Applications» и прийти к тому же результату:

И в том, и в другом случае в окне создания пакета нам необходимо задать его имя (у нас сейчас, к примеру, «Notepad++») и хранилище, после чего кликнуть «Create», а затем снова согласиться в окне подтверждения действия.

После этого новосозданный пакет объявится на вкладке «Packages», и там можно узнать все детали не только о нем, но и о приложениях в его составе. Пока, как мы видим, статус пакета «Unpackaged», так как мы еще не захватили инсталляцию приложения на упаковывающей машине.

Построение пакета приложений

Теперь переходим к построению пакета. Для этого нам надо в App Volumes Manager выделить этот новый созданный пакет, указать упаковывающую машину для него, а затем проинсталлировать (захватывая и его инсталляцию) приложение на назначенной упаковывающей машине следующим образом:

Открываем браузер и заходим в App Volumes Manager как администратор;
На вкладке «Packages» инвентаря находим искомый пакет и кликаем на него:

На открывшейся соответствующей странице пакета кликаем на «Package», а затем на странице «Package» ищем имя машины, которую хотим использовать с целью упаковки приложения, ставим точку по ее строке в списке и нажимаем «Package». Иногда спрашивает подтверждение, там тогда жмем «Start Packaging»:

Теперь пакет будет прикреплен к компьютеру. Можно зайти на упаковывающую машину и проинсталлировать приложение;

Через веб-клиент vSphere или по RDP заходим на упаковывающую машину под правами администратора, запускаем инсталлятор приложения из сетевого общего ресурса, а затем настраиваем приложение после его установки;

Важно! Вот в таком окошке:

не нажимайте на «ОК» пока инсталляция полностью не завершится. Иначе прервете процесс. Это окно обязательно должно появиться, в противном случае следует перезагрузить ВМ.

Наконец, высветится окно:

где нужно согласиться с окончанием установки, нажав на «Yes». И последнее окно завершения упаковки «Finalize Package» продемонстрирует базовые данные приложения, с которым работаем, где нужно нажать на кнопку «Finalize». После этого в процессе упаковки все время будут показываться сообщения о прогрессе, может запросить перезагрузить машину.

После перезагрузки следует зайти на упаковывающую машину снова и нажать «ОК» в сообщение об успешной упаковке:

Входим в инвентарь App Volumes Manager на вкладку «Packages», кликаем на него и убеждаемся, что статус сменился на «Enabled»:

А программа появилась в списке вкладки «Programs»;

На страничке с этим пакетом кликаем на кнопку в верхней правой части «Set Current» для установки маркера.

Назначение приложения конечному пользователю

Теперь перейдем к назначению приложения конечному пользователю с помощью маркера типа назначения (именно за этим мы только что кликнули на нем на «Set Current»). Кстати, назначить приложение можно не только по маркеру, но и по самому имени пакета. Это полезно, когда части пользователей, к примеру, нужно назначить текущую версию приложения, а тести – новую. Далее:

Заходим в инвентарь App Volumes Manager на вкладку «Applications» и кликаем на искомое приложение;
На его страничке нажимаем на «Assign»:

На новой странице назначения кнопкой «Search» ищем пользовательский аккаунт (например, выбрав атрибут «Begins» и первые буквы аккаунтов, чтобы подсветить все начинающиеся с них), ставим галочку напротив искомого аккаунта в списке «Entity», проверяем, что тип назначения выставлен как «Marker» и в конце нажимаем «Assign»:

Если вылетит предупреждение, подтверждаем и его.

Теперь назначение будет показано на вкладке приложений в секции «Assignments»;

Заходим через клиент Horizon на машину конечной точки (десктоп из пула рабочих столов) как только что назначенный пользователь и убеждаемся, что наше приложение успешно развернулось:

Разворот новой версии приложения

Апдейт пакетов позволяет инкрементировать изменения вместо создания полностью нового приложения с нуля, отвечая новейшим функциям управления жизненным циклом приложений с помощью App Volumes.

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

Через веб-клиент vSphere возвращаемся на упаковывающей машине к снэпшоту, который мы брали перед тем, как упаковать более раннюю версию софта, указав эту ВМ и выключив ее, а затем выделив ее в меню «ACTIONS» и выбрав«Snapshots» – «Manage Snapshots», найдя искомый снэпшот и кликнув на «REVERT TO». «Done»;
Включаем упаковывающую ВМ (проследите, чтобы ни один юзер к ней пока не подключался);
Заходим в инвентарь «App Volumes Manager» на вкладку «Applications» и кликаем на наше приложение;
На его страничке выбираем «Create Package» и задаем имя нового пакета, отражающее новую версию приложения (у нас это, к примеру, Notepad++ 7.8.3), проверяем правильность выбора хранилища и шаблона, после чего жмем кнопку «Create», и, если запросит, соглашаемся с созданием пакета;
После того, как новый пакет появился в списке «Packages», его статус будет «Unpackaged»;
Строим пакет с новой версией софта, как было описано в соответствующем подразделе выше, а затем назначаем ему маркер кнопкой «Set CURRENT»:

Заходим в клиент Horizon на конечную точку, как назначенный пользователь (для этого приложения пользователей мы уже назначали), и убеждаемся, что нужная версия софта является доступной:

Назначение ярлыков этапам жизненного цикла пакетов

Можно задать ярлык для пакета, чтобы отражать этап жизненного цикла, на котором он сейчас находится. Эта практика помогает отвечающим за упаковку администраторам, тестерам и собственникам приложений отслеживать, что происходит с пакетом. Сейчас это ярлыки «New», «Tested», «Published» и «Retired». Чтобы назначить ярлык делаем следующее:

Заходим в инвентарь App Volumes Manager на вкладку «Applications» и кликаем на наше приложение;
На его страничке в секции «Packages» обращаем внимание, что по колонке «Stage» значится «New»:

Выбираем версию, которая новее, к примеру;

На его странице нажимаем сверху справа кнопку «Edit»:

В открывшейся странице из списка этапов выбираем «Published» и нажимаем «Save»:

Теперь в списке пакетов ярлык этапа сменится:

Репликация пакетов приложений и реконструкция отношений и прав

В 4-й версии App Volumes представлена конструкция приложений, пакетов, маркеров и других компонентов Simplified Application Management (SAM) для упрощения управления жизненным циклом, в т. ч. такого важного процесса репликации. Но, известная метода автоматизации репликации пакетов с помощью групп хранения не в состоянии реплицировать отношения данных типа «приложение в пакет» или же новые SAM-атрибуты. Для понимания, в чем именно состоит проблема, рассмотрим конкретную ситуацию.

На первичном сайте создано приложение, например, тот же упомянутый нами выше Notepad++. Создавались три пакета, в каждом – разная версия программы. Пакеты и их программы добавлены в приложение, установлены, как описывалось выше, маркеры и заполнено поле «Description»:

Когда все три пакета были реплицированы на вторичный сайт и импортированы, App Volumes Manager создал новый объект репликации для каждого пакета:

Да, имя созданной репликации совпадает с именем пакета, но маркеры не установлены, а поле «Description» стало пустым. И теперь по завершению репликации нужно переназначать взаимоотношения между приложениями и пакетами, переприменять приложения и атрибуты пакетов. Здесь существует два пути решения задачи: вручную или же используя VMware Fling.

Ручная репликация

Если приложения содержат несколько пакетов, начать следует с исправления отношений приложение-пакет. Сперва создается приложение с таким же именем, как имя приложения на первичном сайте. Затем по каждому пакету кнопкой «Move» перемещаются пакеты в новое приложение с правильным именем:

Когда перенесется последний пакет, высветится предложение удалить пустое приложение:

Теперь нужно переопределить для нового приложения атрибуты «Owner», «Description» и «Assignments» и назначить, куда требуется, маркер «Current».

VMware Fling

Доступна автоматизация процесса синхронизации прав с помощью App Volumes Entitlement Sync Tool (памятка по нему доступна здесь и отсюда же можно загрузить это полезное дополнение к App Volumes). Этот встроенный инструмент работает, перечисляя пакеты на каждом сайте. Он собирает данные об ассоциированных приложениях, маркерах пакетов, их собственнике и описании, и выдает сообщение, если отношения приложений или пакетов не установлены между сайтами. Исправить это несоответствие можно просто используя его опцию «Fix Apps».

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

Дополнительные опции настройки записываемых томов

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

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

Заходим на «HKLM\System\CurrentControlSet\Services\svdriver»;
Создаем там новый ключ реестра и называем его «Parameters» (если такового еще нет);
Создаем в нем новый ключ «ReportSystemFreeSpace» со значением «DWORD» равным «0»:

Либо же делаем это командой из CMD при входе под высокими привилегиями:

reg add hklm\system\currentcontrolset\services\svdriver\parameters /v ReportSystemFreeSpace /t REG_DWORD /d 0

(После этих изменений требуется перезагрузка, а не простой вход-выход.)

В результате, если раньше пользователи видели соотношение свободного и полного места на диске «С:», то теперь значение свободного места будет отражать только данные по записываемому тому. Это помогает им точнее рассчитывать свои действия.

Также можно увеличить Writable Volumes (по дефолту их емкость равна 10 ГБ). Делается это по каждому пользователю, который испытывает подобную нужду, из консоли App Volumes Manager:

Находим пользовательский записываемый том во вкладке «Writables» вкладки «Volumes» и раскрываем информацию по интересующему тому;
Кликаем на «Expand Volume» и вводим нужное значение в ГБ;
Пользователь должен выйти и зайти снова, и тогда он увидит, что доступное ему пространство выросло.

Инсталляция и использование продуктов семейства Microsoft Office с App Volumes

Если пользователи не планируют редактировать огромные Excel или Project-файлы, вполне достаточно и 32-битных версий Microsoft Office.

Важно! Совмещение 32- и 64-битных инсталляций офиса на одной и той же машине не поддерживается.

Для лучшей функциональности рекомендуется использовать RDSH на Windows 2008 R2.

Матрица совместимости версий:

Версия офиса\Версия App Volumes	2.10	2.12	4 (2006) и новее
2010	+	+	+
2013	+	+	+
2016	–	+	+
2019	–	–	+

App Volumes поддерживает KMS-лицензирование для майкрософтовского офиса. Поэтому могут использоваться только ISO с VLSC. Соответствующий KMS-сервер конфигурируется в процессе подготовки (используя OSPP.VBS с нужными опциями), либо же обращаются к дефолтному процессу обнаружения KMS вместе с GVLK по умолчанию, которые, обычно, уже встроены в нестандартные ISO-носители.

Подготовка и создание AppStack (для App Volumes 2.х)

Необходимые приложения должны быть подготовлены со свежим AppStack. Для всех компонентов следует использовать дефолтную локацию инсталляции. Помните, что открывать какие-либо приложения Microsoft Office в процессе запрещено.

KMS-ключи устанавливать нужно только на KMS-сервере до имплементации App Volumes. Вводить их в процессе или после инсталляции AppStack нельзя. Для подготовки инсталлятора нужно зайти в его папку «proplus.ww» и открыть файл «config.xml» на редактирование. Там меняется параметр «SettingId» для указания на KMS-сервер, используемый в развороте. Например, вот так:

Затем следует убедиться, что в базовом образе есть следующие файлы: «vc_redist_2015.x64.exe» (Win10) или «vcredist_2013_x64.exe» (Win7).

После этого, собственно, сама подготовка AppStack:

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

Далее создаем AppStack с помощью App Volumes Manager (см. выше) и инсталлируем там офисные приложения. Теперь нам осталось осуществить назначение AppStack. Для этого вначале убеждаемся, что целевая машина идентична подготовленной в плане апдейтов софта и ОС. Затем назначаем подготовленный Office AppStack для пользователя или группы (аналогично см. выше), заходим под администратором на машину, которой был назначен AppStack, и проверяем, что он присоединен и его приложения видны.

Обновление App Volumes до 4-й версии

В рамках этого гайда по App Volumes сегодня мы будем рассматривать полноценную миграцию с версий 2.18.х до «четверки»:

Случай планового сосуществования версий 2.18.х и 4 считается весьма экзотическим и, по правде говоря, сложным, поэтому за консультацией по нему лучше обращаться к сертифицированным экспертам.

Важно! Учтите, что некоторые функции AppStack недоступны в App Volumes 4. Например, ограничение привязок, опция ограничения привязок конкретного AppStack к указанному компьютеру, мгновенная привязка, редактирование типа операционной системе, к которой привязан AppStack, приоритетность, переназначение записываемого тома компьютера. Кстати, если все это действительно терять не хочется, вот именно в этом случае интересно рассматривать вариант сосуществования разных версий App Volumes. Либо же прибегнуть к полной конвертации AppStack 2.х в пакеты App Volumes 4.

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

Подготовка к накатыванию апдейта

Заметьте, что все версии до 2.18.х сначала нужно грейдить до этого класса, а затем уже осуществлять переход на самый свежий, на сегодняшний день, вариант.

Проверить, возможен ли апгрейд App Volumes с определенной версии традиционно можно в секции «Upgrade Path» VMware Product Interoperability Matrices:

Затем следует сделать бэкап SQL-базы данных App Volumes, руководствуясь такой инструкцией:

Открываем SQL Server Management Studio, раскрываем папку с базами данных и кликаем правой кнопкой на БД App Volumes. Ищем «Tasks» и в появившемся меню – «Back Up…»:

В соответствующем окне выбираем в выпадающем меню «Full» и ставим галочку на «Copy-only backup», убедившись, что путь выбран корректно, после чего жмем «ОК»:

Готовый бэкап с расширением «*.bak» будет лежать в том месте, которое мы указали.

Далее в процессе подготовки нам следует скачать 4-ю версию App Volumes со страницы загрузок VMware, а также второй файл в этой секции – «Unlimited desktops license key».

Процедура обновления до App Volumes 4

Перед тем, как начать процесс, нужно остановить все подключенные к центральной базе данных сервера App Volumes Manager:

Важно! Если конфигурация решения предполагает наличие нескольких инстансов App Volumes Manager, все они обновляются по порядку, по одному за раз.

Далее копируем инсталлятор App Volumes Manager и запускаем файл «setup.msi»:

А затем полностью повторяем все то, что делали при прохождении соответствующего визарда в первичной установке App Volumes Manager в «Инсталляция App Volumes Manager» главы «Разворот App Volumes» выше.

Агенты обновляем по схеме, аналогичной приведенной выше для первичной установки. Единственное что, именно в их отношении стоит сделать несколько важнейших замечаний:

Вначале нужно проапдейтить AppStack 2.х до Applications 4.x, и только затем обновлять каждый агент. Перенести все существующие AppStack в пакеты можно, используя описанный выше VMware Fling. Однако следует помнить, что утилита миграции не разделяет программы в AppStack на индивидуальные пакеты. Если же в эти пакеты хочется поместить единственную программу, следует просто перепаковать программы, используя шаблон-упаковщик;
В идеале апгрейд AppStack лучше вначале полностью протестировать на песочнице, и только затем уже работать с обновлениями непосредственно на живой инфраструктуре;
Рекомендуется для обновления агентов выбрать окно техобслуживания.

Миграция AppStack

При инициации апгрейда в консоли менеджера появится специальная вкладка «VOLUMES (2.X)», а когда он завершится, и доступ к ней уже потеряет актуальность, ее можно выключить на вкладке «Configuration» – «Settings» – «Advanced Settings»:

Важно! VMware Fling совместим только с Windows 7 или 10-машинами. Для успешной конвертации AppStack в актуальные для App Volumes 4 пакеты, должен быть организован доступ этих ВМ к датастору с нуждающимся в миграции AppStack и проинсталлирован .NET 4.5.

Сама процедура:

Загружаем утилиту и инсталлируем ее на машине (попросит в какой-то момент ребут);
Первый запуск затребует спецификации пути к хранилищу output-файлов, ниже ставим галочку на «VMDK» и кликаем «Next»:

Заходим на свой App Volumes Manager, выбираем нужный AppStack для миграции (статус поменяется с «Ready» на «Scheduled») и кликаем на «Migrate»:

По завершению этого процесса статус сменится на «Done», и сгенерируются два файла (с расширениями «*.json» и «*.vmdk»):

Копируем эти файлы на сервер App Volumes Manager в папку «\ppv\packages», где проинсталлирован продукт:

Заходим на подвкладку «Storage» вкладки «Configuration» и нажимаем «Upload Templates»:

Смигрированное приложение теперь должно появиться в списке, ставим на нем галочку и жмем внизу на «Upload»:

Появится окно подтверждения, в котором жмем аналогичную кнопку:

После всей проделанной работы на подвкладке «Applications» инвентаря появится смигрированное из AppStack приложение. Теперь можно задавать его назначение прямо отсюда, а на подвкладке «Packages» появится пакет, названный как наше приложение. Здесь можно задавать параметры его жизненного цикла и, при необходимости, устанавливать маркер – делать все, чему мы учились в главе «Администрирование…» выше. Кстати, по итогу, и на подвкладке «Programs» появится программа, ради которой мы все это затеяли.

Операции постапгрейда

После обновления серверов App Volumes Manager, в первую очередь, необходимо применить новый лицензионный ключ решения. Для этого:

Заходим в GUI менеджера, перемещаемся на подвкладку «License» вкладки «Configuration» и нажимаем «Edit»:

В появившемся окне нажимаем на «Browse» и ищем предварительно загруженный файл с ключами, затем кликаем «Open»:

И, наконец, «Upload»:

Также теперь можно активировать регистрацию безопасности.

Вот, собственно, все, что хотелось сегодня рассказать о продукте App Volumes. На специфике применения App Volumes в облачных средах постараемся остановиться в запланированном цикле по cloud-решениям VMware.

Надеемся, этот материал был интересен и полезен читателю, а если остались какие-то вопросы, хочется узнать больше о методах применения и функционале данного решения, добро пожаловать на авторизованные курсы VMware по Horizon, в программу которых включен блок App Volumes.