Разворот и базовая настройка VMware vRealize Automation 8.3

Продукт VMware vRealize Automation 8.3 – это современная платформа автоматизации виртуальной среды, дающая доступ к приватным и мульти-облачным средам в VMware Cloud. В его задачи входит автоматизация самообслуживания, DevOps, управление конфигурацией и возможности автоматизации сети, позволяющие увеличить продуктивность и эффективность, а также гибкость бизнеса в целом, и IT – в частности. С помощью этой платформы легко интегрировать, оптимизировать и модернизировать традиционные, родные для облаков и мульти-клаудные инфраструктуры, значительным образом упрощая работу IT-отделов и обеспечивая готовность к адекватному ответу на текущие и будущие вызовы.

Сегодня именно vRealize Automation будет в фокусе нашего внимания, мы поговорим о необходимой в работе с ним теоретической базе, требованиях к самому продукту и его окружению, о его функциях и возможностях, а также научимся грамотно его разворачивать и настраивать в базовом варианте. Конкретно администрированию и расширенному функционалу, пожалуй, уделим отдельную статью в цикле о vRA, и, традиционно, еще одну – вопросам апгрейда с прошлых версий на актуальную. Тем более что совсем недавно, как мы уже писали в новости «VMware vRealize Automation 8.3 Release Notes», а именно 4 февраля 2021 года, появился минорный релиз, и переход на него, наверняка, многим будет интересен.

По факту, vRA существует в двух ипостасях: on-premises решение и vRealize Automation Cloud – попробуем рассказать ключевые моменты по обоим. Однако, не будем забегать наперед, и начнем с самых азов…

Что необходимо знать о VMware vRealize Automation 8.3?

vRA 8.3 – это on-premises решение глобального vRealize Automation Cloud (SaaS на основе веб), включающего в себя такие сервисные компоненты VMware Cloud, как Cloud Assembly, Service Broker и Code Stream.

Cloud Assembly – это облачный сервис, используемый в создании и развороте машин, приложений и служб для множества облаков с такими ключевыми характеристиками и функционалом:

Работа со множеством облачных аккаунтов;
Помощь в создании и управлении блюпринтами как кодом в YAML-формате;
Доступ к VMware Marketplace с целью загрузки и управления Appliance и блюпринтами;
Использование инстанса vRealize Orchestrator для разработки и управления рабочими процессами в пользовательских IT-ресурсах;
Применение инфраструктуры VMware Enterprise PKS для разворота кластеров Kubernetes с нуля или импорта существующих нативных;
Полностью само-обслуживаемая система;
Возможность гибкого масштабирования во всех смыслах.

Примечание: Здесь и ниже по тексту статьи мы постоянно будем чередовать термины «блюпринты» (Blueprint) и «облачные шаблоны» (VMware Cloud Templates – заменили блюпринты с версии 8.2), так как многим привычнее именно первое. Однако суть их идентична.

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

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

Service Broker занимается агрегацией контента в требуемом формате из множества облаков и платформ, уплотняя его в общий каталог для облегченного потребления из VMware Cloud:

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

Code Stream – это непрерывная интеграция и доставка (CICD) софта, для которой характерны скорость, надежность и небольшие накладные расходы:

Решение поддерживает развертывание монолитных унаследованных приложений, Docker и Kubernetes контейнеров, работающих в нескольких облаках. Автоматизация этапов разработки приложений (сборки, тестирования и слияния) дополняется автоматическим выпуском приложений в репозиторий и автоматическим же развертыванием в фазах продакшена. Code Stream пользуются администраторы DevOps или разработчики с целью автоматизации всего жизненного цикла релиза DevOps, одновременно применяя существующие инструменты разработки, вроде Git или Jenkins. Ближайшей здесь аналогией будет конвейер, заправляющий всеми действиями в рамках жизненного цикла ПО.

На момент написания этой статьи Code Stream поддерживает Amazon AWS, Microsoft Azure, GCP и облака на vSphere для развертывания кода.

Преимущества сервисов VMware Cloud:

Бесплатное пробное использование, плата только за то, что применяется;
Максимальный уровень защиты, нет нужды в пропатчивании, апгрейде или мониторинге;
Доступ к новейшим функциям сразу, без ожидания 6-12 месяцев до релиза;
Постоянный доступ к чату саппорта;
Единый доступ к множеству облаков всех типов и дата-центров.

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

Ниже, в подразделе «Аутентификация в vRA 8.3 и роли», мы поговорим о том, какое существует разделение ролей для доступа и управления всеми этими сервисами, в «Подготовке к настройке базового функционала vRA», расскажем, что нужно сделать, чтобы адаптация Cloud Assembly, Service Broker и Code Stream прошла без проблем, а в разделе «Базовая начальная настройка vRA» опробуем на практике их главный функционал, создав работоспособную структуру и протестировав опорные моменты автоматизации.

Архитектура и компоненты

Архитектура vRA может быть стандартной (Standard) или кластерной (Clustered) (подходящий тип выбирается в процессе разворота – см. ниже). Standard – это вариант исключительно для сред самых малых размеров и самым элементарным функционалом, тестов базовых возможностей (PoC) и демонстраций. А вот кластерная архитектура является идеальным вариантом для продакшен-сред, ведь она позволяет реализовать массу конфигураций самых различных свойств и особенностей, включая внедрение балансировщика нагрузки (NSX-T Data Center/F5 BIG IP/Citrix NetScaler) и обеспечивая НА.

Обычно, комплексный разворот инструментов vRealize включает в себя следующий порядок архитектурных компонентов:

Lifecycle Manager,
VMware Identity Manager,
vRealize Automation.

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

vRealize Lifecycle Manager – это единая платформа инсталляции и управления для самых разнообразных продуктов серии vRealize Suite:

Lifecycle Manager автоматизирует Day-0/Day-2-операции всего vRealize Suite и vRealize Network Insight – инсталляцию, настройку и управление контентом, мониторинг здоровья среды, доступ к маркетплейсу и обновление. И все это – с единой платформы. А результатом становится фокусировка ресурсов администрирования и управления облаками на бизнес-критических инициативах, улучшая время окупаемости, надежность и согласованность. Но, самой важной особенностью предпочтения Lifecycle Manager считается полная унификация задач по управлению виртуальной средой, а также приятное нивелирование ошибок реализации вследствие воздействия человеческого фактора при ручных операциях. К тому же доступно видение продуктов по всему времени их жизненного цикла с возможностью возврата к предыдущему состоянию конфигурации.

Важно! vRealize Automation ставится исключительно через LCM.

Упомянутая выше технология Identity Manager активно продвигаема VMware как IDaaS-решение, предоставляющее контроль над условиями доступа, SSO для SaaS, интернета, облаков и нативных мобильных приложений. Это решение Enterprise-уровня лицензирования, агрегирующийся со всеми передовыми продуктами вендора и опирающийся на OAuth 2.0 фреймворке авторизации. Сегодня мы осветим моменты его непосредственной агрегации с vLCM и vRA, но параллельно анонсируем будущий фундаментальный материал, посвященный этой технологии, так как в сотрудничестве с другими решениями VMware он все больше вытесняет все прочие способы аутентификации.

Возвращаясь к компонентам конкретно vRA, его Appliance работает на базе ОС Photon 3.0 и включает родные для Kubernetes (K8S) службы для контейнеризации хостов:

Все корневые для vRA сервисы запускаются как поды Kubernetes, и контейнеры внутри пода хостятся с использованием движка Docker.

Стандартная шина сообщений в vRA – это RabbitMQ, и работает она как под. А в качестве дефолтной и единственной поддерживаемой базы данных используется PostgreSQL (TCP-порт 5432, бесплатный open-source, поддерживающий репликацию между нодами базы данных), аналогично бегающая как под и использующая Persistent Volume (PV) для хранения данных. PV является хранилищем в кластере Kubernetes и предоставляет путь к хосту (/mnt/data) или к тому NFS, iSCSI:

Kubernetes как одной из самых интересных и передовых технологий когда-нибудь обязательно посвятим выпуск отдельной статьи в нашем блоге. И там попробуем уделить внимание включению vRealize Orchestrator в качестве пода в Kubernetes. Этот момент очень важный, так как пользователи могут инсталлировать плагины с помощью Control Center и использовать веб-интерфейс vRealize Orchestrator для их настройки, создания и запуска рабочих процессов, а также предоставления не лимитированной расширяемости. Control Center также может применяться для изменения дефолтного поведения vRealize Orchestrator – в управлении пользователями, экспорте/импорте конфигураций, настройке свойств запуска рабочих процессов и в доступе к файлам логов, а также их параметрам через браузер.

Важно! Все компоненты vRealize Lifecycle Manager, VMware Identity Manager, vRealize Automation и vRealize Orchestrator должны быть синхронизированы в одинаковой временной зоне. Рекомендуется UTC+0.

Если от vRA требуется расширенный функционал (многое, его касающееся, обязательно рассмотрим в статье «Администрирование…»), необходимо проинсталлировать и настроить инстанс vRealize Orchestrator. Это может быть, как внешний, так и встроенный вариант, но с целью оптимизации производительности вендором рекомендуется второй, как наиболее адекватный. Скачать его можно в том же разделе, что и vRA секции «Infrastructure & Operations Management» отсюда:

High Availability компонентов vRA и продуктов-спутников

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

vIDM разворачивается аналогично, причем, так же позади балансировщика нагрузки. А вот vRealize Lifecycle Manager принципы НА-разворота не поддерживает. В маленьких разворотах (тесты и PoC) достаточно по одному развернутому Appliance vRealize Lifecycle Manager, vIDM и vRA, но в больших вариациях придется развернуть все тот же один vRealize Lifecycle Manager, однако по три Appliance vIDM и vRA (последние два – с LB).

Все компоненты vRealize Lifecycle Manager, VMware Identity Manager, vRealize Automation и vRealize Orchestrator следует инсталлировать в одном и том же управляющем кластере. Машины же предоставляются в отдельном кластере, чтобы пользовательские и серверные рабочие нагрузки были изолированы.

Аутентификация в vRA 8.3 и роли

Актуальная версия vRA нуждается во внешнем инстансе VMware Identity Manager. Это может быть уже существующий продукт, используемый в работающей среде, либо же можно обратиться к новому его развороту с помощью vRealize Lifecycle Manager.

Важно! Без установки или импорта VMware Identity Manager из Lifecycle Manager невозможно получить доступ к любой другой среде.

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

Вообще же, роли в vRA, что, впрочем, справедливо и для других продуктов вендора, определяют набор привилегий, ассоциированных с пользователями, – задач, которые юзеры могут предпринимать в том или ином случае. Каждому пользователю может сопоставляться одна или более ролей. В широком смысле в vRA роли можно поделить на два глобальных вида: организационные и сервисные. Первые определяются на самом высоком уровне продукта и, в свою очередь, подразделяются на Organization Owner (доступ к вкладкам «Services», «Identity & Access Management» и «Branding» – интерфейс в деталях изучим в статье «Администрирование…», может назначать роли для пользователей AD) и Organization Member (доступ только к вкладке «Services», может создавать блюпринты и осуществлять из них развороты). Сервисные же помогают достучаться до индивидуальных сервисов, предлагаемых vRA (Cloud Assembly, Code Stream, Orchestrator, Service Broker):

В каждом развороте vRA может существовать единственная организация, но каждый его сервис способен иметь более одной роли. Например, если взять Cloud Assembly, для него можно организовать роли администратора и пользователя. И здесь администратор может создавать и управлять:

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

А пользователь, для сравнения, только:

создавать блюпринты,
разворачивать машины и сервисы,
управлять разворотами.

В отношении Service Broker имеем такую картину:

Роль администратора (настройка источников контента, определений политик, добавление облачных аккаунтов и клауд-зон);
Роль пользователя (доступ к каталогу самообслуживания, разворот машин и сервисов, управление разворотами).

А для Code Stream:

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

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

Администратора (доступ к встроенным рабочим процессам, действиям и политикам, к встроенным пакетам, конфигурациям и ресурсам, добавление Git-репозиториев);
Проектировщика рабочих процессов (создание новых рабочих процессов, действий и политик, импорт пакетов, конфигураций и ресурсов).

При этом каждому пользователю vRA следует назначить организационную роль с ассоциированной с ней сервисной. Если этого не сделать получим ошибку вида:

а в сервисах пользователя будет пусто:

Назначение ролей происходит в консоли vRA на вкладке «Identity & Access Management» – процесс подробно изучим в статье про «Администрирование…»

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

VMware Identity Manager

vIDM используется в управлении пользовательской аутентификацией, политиками доступа и выдачи прав пользователям на ресурсы. Сам продукт, как мы уже писали, входит в стандартный разворот Enterprise-уровня, и инсталляция VMware Identity Manager осуществляется после установки vLCM и с его же подачи. Ниже, в главе «Процедура разворота…» мы будем подробно описывать, как ее добиться на практике, сейчас же попробуем пояснить, как все это работает.

Сервис идентификации запускается как под в Kubernetes, а его identity-db является PostgreSQL базой данных:

И функционирует он так: как только пользователь пытается зайти в vRA, сервис идентификации перенаправляет этот запрос на VMware Identity Manager URL, Aplliance vIDM сверяет учетную запись пользователя с AD, и, если все хорошо, доступ предоставляется.

Ниже в процессе разворота мы будем назначать пароль для администратора дефолтной конфигурации – роли, имеющий полный доступ к vIDM и права на все с ним операции:

Под этой ролью можно настраивать разнообразные функции, вроде мобильного SSO, доступа к приложениям при условии на основе распределения прав и статуса соответствия, мульти-факторную аутентификацию, восстанавливать пароли, заниматься мгновенным предоставлением пользователей и т. п. Корпоративная директория интегрируется с vIDM с целью синхронизации пользователей и групп. Поддерживаемые типы директорий:

Active Directory over LDAP (используется для подключения к одиночной доменной среде AD. В этом случае коннектор привязывается к AD при помощи простой аутентификации привязки);
Active Directory, Integrated Windows Authentication (удобно для мульти-доменной среды AD или с многочисленными лесами. Коннектор привязывается к AD при помощи интегрированной Windows-аутентификации);
OpenLDAP directory (доступна интеграция исключительно одно-доменной OpenLDAP-директории, и vIDM поддерживает только те OpenLDAP имплементации, которые работают с поисковыми запросами с постраничной разбивкой).

В начальном варианте создается системная директория по дефолту с пользователем, роль которого определена как администратора конфигурации. Затем можно создавать множество локальных директорий с помощью опции «Local User Directory». Настраивать интеграцию с AD и учиться работать с VMware Identity Manager, в целом, будем в следующей нашей статье из цикла по vRA «Администрирование…».

Кроме этого, в процессе работы с vRA будет доступна синхронизация групп AD с vIDM – об этом также обязательно поговорим позднее. А работе с консолью VMware Identity Manager и всему богатству его функционала, как уже анонсировалось, уделим внимание в персональной статье.

Поддержка мульти-тенатности

vRA поддерживает связанную мульти-тенантную инфраструктуру через отдельный процесс в vRealize Suite Lifecycle Manager (LCM). Эту возможность можно включить специально, и дополнительно она под себя ничего не требует. При этом создается дефолтная организация провайдера, и его администратор может создавать новые тенанты, добавлять их администраторов, инициировать синхронизацию директорий и вносить новых пользователей, а также брать на себя весь функционал администраторов тенантов. Администратор каждого тенанта, в свою очередь, контролирует синхронизацию директорий для своего тенанта, дает доступ пользователям к сервисам внутри него, настраивает Policies, Governance, Cloud Zones и Profiles, доступ к контенту и предоставляемым ресурсам:

Что одиночный SDDC общего доступа, что отдельные SDDC могут использоваться тенантами в зависимости от доступности ресурсов. Подготовку к включению мульти-тенантности и саму его процедуру в деталях рассмотрим в будущей статье по администрированию vRA, а результат его отобразится на консоли LCM отдельной карточкой сервисов:

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

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

Туда можно добавлять уникальные или общего пользования облачные аккаунты с ассоциированными вычислительными мощностями, хранилищами и сетевым устройством, а также теги. И весь процесс, на самом деле, полностью идентичен тому, что мы будем делать ниже в разделе о базовой настройке по облачным зонам и профилям для типичной организации в vRA. Единственное, на чем стоит акцентировать внимание – каждый тенант может размещать у себя более одной VPZ.

Кстати, с версии 8.3 vRA сопоставления образов и особенностей выделены из VPZ и размещены независимо в Tenants под Tenant Management:

Преимущества и best practice мульти-тенантности

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

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

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

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

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

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

Cloud-системы, обычно, нужны тестировщикам или разработчикам частных приватных облаков, ищущим большую гибкость в доставке новых или проапдейченных ИТ-сервисов с нуля, либо же они уже пользуются необлачными методами и нуждаются в уменьшении времени этой доставки. Также среди клиентов решения – IaaS-частные облака, целью которых является оптимизация и максимизация эффективности затрат существующего вычислительного положения путем применения атрибутов публичного облака к приватному. Независимо от типа организации, требуется четкий ответ на такие поставленные в процессе оценки и анализа вопросы:

Какое бизнес-решение будет представлять корпоративное облако?
Какие бизнес-операции нуждаются в облачной поддержке?
Каковы ограничения бизнеса?
Нужно ли запускать разные рабочие процессы на различных же платформах?
Нуждаются ли конечные пользователи в портале самообслуживания?
Нужна ли мульти-тенантность?
Каковы прогнозы бизнеса на будущее?
Какие риски должны быть идентифицированы или смягчены?
Есть ли ограничения по бюджету?
Необходимо ли сохранить уже существующую систему управления IP-адресами?
Важно ли для организации следовать требованиям регуляторных стандартов?
Нужна ли интеграция с внешней биллинговой системой?
Хочет ли клиент сохранить старые серверы с более медленными процессорами и меньшей памятью?
Достаточны ли пространство сетевых адресов для поддержки миграции в облако, спецификация CPU, памяти и хранилищ, пропускная способность сети и т. д.?

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

Уровни дизайна vRA

По итогу аудита имеющейся ИТ-инфраструктуры, формулировки и анализа бизнес-требований к развороту и использованию внедряемого решения, рисков, ограничений и последствий вначале создается концептуальный дизайн – как базис для разработки логического, а затем и физического дизайна.

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

Принципы грамотного дизайна

Описанные только что уровни дизайна должны опираться на следующие принципы:

доступность (НА),
управляемость (простота использования, масштабирования, управления жизненным циклом и планирования емкости),
производительность,
восстанавливаемость,
безопасность.

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

Уровни архитектуры и дизайн облачных ресурсов

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

В vSphere вычислительными ресурсами являются кластера vSphere DRS и vSphere НА, которые, в свою очередь, могут быть логическими подразделениями, а также подразделяться на уровни (gold/silver/bronze):

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

Вычислительный ресурс может представлять собой хост, кластер хостов или пул в платформе виртуализации, виртуальный дата-центр, регион Amazon, где предоставляются машины и т.д. Администратор IaaS может добавлять или удалять вычислительные ресурсы из структурной группы, а администратор структуры, со своей стороны, – создавать резервирование на них для указанной бизнес-группы. При этом пользователям бизнес-группы выдаются права на предоставление машин на этом вычислительном ресурсе.

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

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

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

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

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

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

Также интересна возможность разделения кластеров вычислительных ресурсов по физическим сайтам. Но, если мы говорим о кластеризации среды, все будет гораздо сложнее, так как основные компоненты vRA (Appliances, веб-сервера IaaS, серверы IaaS Manager и т.д.) должны помещаться на одном сайте. Хотя прокси-агенты IaaS и рабочие серверы можно устанавливать и удаленно. Поэтому best practice в нашем случае считается запрет на распределение ресурсов бизнес-группы по нескольким физическим сайтам. Даже если у организации во владении их много, все ресурсы для конкретной бизнес-группы должны располагаться только на одном из них. Очень помочь в данном случае может определение упомянутых выше локаций дата-центра.

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

Советы по управлению ресурсами

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

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

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

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

Стандартизация в корпоративном дизайне

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

Чем короче и проще имена – тем лучше;
Зашифрованные имена – плохая практика, так как их сложнее использовать;
Имя объекта должно быть информативным, включая (в каком-то виде) либо его функцию, либо название департамента или бизнес-группы, либо операционную систему/уровень тира и т.д.

Например, если мы говорим об управлении машинами, рекомендуется использовать префиксы – естественно, короткие и простые, – идентифицирующие, минимум, одну из знаковых характеристик (ОС, функцию, бизнес-группу).

Разрабатывая стандарты именования следует учесть, что некоторые имена видны по всем границам тенантов. Это имена конечных точек, префиксы машин, вычислительных ресурсов, профилей компонентов, резервирований, словаря свойств, управляемых машин, сетей. Так что, если есть повышенные требования по секретности, при мульти-тенантной инфраструктуре будьте аккуратнее при формулировании стандартов.

Важно! Если речь о DNS-поименовании, допустимы исключительно знаки ASII (A-Z, 0-9), без спецсимволов. Если речь о Windows-машинах, их имена не должны содержать более 15 знаков.

Больше узнать о дизайне vRA можно на специальном одноименном авторизированном курсе VMware.

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

Важно! 8.х-семейство vRA не поддерживает вложенные виртуальные среды типа ESX > ESX > vRA.

vRA 8.3 поддерживает vRealize Suite Lifecycle Manager 8.0.0 и более современные, а также VMware Identity Manager 3.3.1 и свежее (только для импорта). По другим продуктам:

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

Виртуальное железо

Требования к виртуальному железу и дисковому устройству у vRA 8.3 следующие:

	Профиль Medium	Профиль Extra Large
Размер диска, всего, ГБ	236 (только при инсталляции одиночной ноды)	236 (только при инсталляции одиночной ноды)
vCPU	12	24
Память, ГБ	42	96
Объем системной партиции, ГБ	50	50
Объем партиции данных, ГБ	144	144
Объем партиции метрик, ГБ	20	20
Объем партиции логов, ГБ	22	22
Объем хранилища, ГБ	222	222

Так как ниже будем рассматривать единственно доступный способ разворота vRA – через vRealize Suite Lifecycle Manager и сопровождать его очень полезным в продакшен-средах Enterprise-уровня лицензирования Identity Manager, приведем требования по ключевым характеристикам и для этих двух продуктов:

	vRealize Suite Lifecycle Manager	Identity Manager
Размер диска, всего, ГБ	78	60
vCPU	2	8
Память, ГБ	6	16
Объем системной партиции, ГБ	10	8
Объем партиции данных, ГБ	50	–
Размер свопа, ГБ	8	6
Объем партиции tomcat, ГБ	–	10
Объем партиции var, ГБ	–	10
Объем партиции db, ГБ	10	10
Объем хранилища, ГБ	48	100

Спецификация Workspace ONE Access индивидуальна, так как рассчитывается, исходя из количества пользователей в директориях. Подробно этот вопрос будем рассматривать в нашем будущем отдельном материале, посвященному этому решению.

Сеть

Для vRA необходимо обеспечить уникальный статический IPv4 и сетевой адрес, обязательно организовать доступ к DNS-серверу, а также вручную настроить валидный FQDN в прямой и обратной зоне DNS-сервера. Все компоненты должны разворачиваться на L2 рядом. Не допускается разворот с IP-адресами или внешними сервисами с IP-адресами в этих диапазонах. Кроме того, следует обеспечить реверс сетевых диапазонов 10.244.0.0/22 и 10.244.4.0/22 для коммуникации внутренних сервисов.

Важно! После инсталляции vRA запрещены изменения IP-адресации и переименование хоста.

Для реализации vRA допускается максимальная задержка при связи между нодами в кластере в размере 5 мс, независимо от размера разворота, а при связи с хранилищем – 20 мс (по каждой I/O из любой ноды vRA).

Доступ к vRA осуществляется через 443-порт, который должен быть защищен само-подписанным сертификатом, создаваемым в процессе инсталляции. vRealize Automation Appliance, кроме 443, пользуется 5480 и 22. Также помним, что инстансы vCenter Server и ESXi-хостов аналогично пользуются 443. При использовании внешнего LB следует настроить его работу на этом порте. Вообще же для 8.х vRA нужно предусмотреть открытие таких портов:

Источник	Пункт назначения	Порт	Протокол	Цель	Примечание
vRA	VMWare Identity Manager	443	TCP	Коммуникация между компонентами	Только прямой доступ
vRA	vRealize Lifecycle Manager	443	TCP	Коммуникация между компонентами
vRA	vRA	8008	TCP	Мониторинг здоровья	Только прямой доступ
VMWare Identity Manager	vRA	22	TCP	Доступ по SSH
Пользователь	vRealize Lifecycle Manager	443	TCP	Связь
Пользователь	VMWare Identity Manager	443	TCP	Связь	Только прямой доступ
Пользователь	vRA	443	TCP	Связь	Только прямой доступ
vRealize Lifecycle Manager	VMWare Identity Manager	22	TCP	Доступ по SSH
vRealize Lifecycle Manager	vRA	22	TCP	Доступ по SSH
vRA	vRA	10250	TCP	Коммуникация внутри кластера
vRA	vRA	6443	TCP	Коммуникация внутри кластера
vRA	vRA	8285	UDP	Коммуникация внутри кластера
vRA	vRA	2379	TCP	Коммуникация внутри кластера
vRA	vRA	2380	TCP	Коммуникация внутри кластера
vRA	vRA	500	UDP	Коммуникация внутри кластера
vRA	vRA	4500	UDP	Коммуникация внутри кластера

Что касается требований к балансировщику нагрузки в контексте vRA, документация VMware рекомендует пользоваться известными для «восьмерки», в целом, требованиями. И все, что работает в отношении последней версии NSX-T DC 3.1, актуально и в этом случае.

Важно! Всю необходимую теоретическую базу по LB в сетевой виртуализации можно почерпнуть из нашей статьи «Дизайн VMware NSX-T Data Center 3.1», а конкретные рекомендации по практическому применению технологии – в «Администрирование и настройка VMware NSX-T Data Center 3.1».

Требования по SaltStack Config в тандеме с vRA

Использование SaltStack Config в среде vRA – опционально. Оно позволяет предоставлять, настраивать и разворачивать софт на ВМ в любом масштабе с применением автоматизации на базе событий. Также это шанс определить и внедрить оптимальное и совместимое состояние ПО по всей среде.

Чтобы интеграция этой управляющей конфигурационной системы прошла успешно, следует отключить режим FIPS в vRA, а сама она разворачивается прямиком из vRealize SLM. На конкретике ее разворота остановимся в деталях в статье «Администрирование…».

Масштабируемость и конкурентные максимумы

Как уже упоминалось выше, vRA может разворачиваться в двух типах профилей: Medium и Extra Large (XL). Попробуем озвучить максимумы, до которых разрешено на этом этапе жизненного цикла продукта его масштабировать (рассмотрим наиболее сложную и интересную конструкцию с мульти-тенантностью и НА):

	Medium	Extra Large
Кол-во тенантов	20	20
Облачных аккаунтов (приватные конечные точки – vCenter, NSX/NSX-T)	50	50
Облачных аккаунтов (публичные конечные точки – AWS, Azure, GCP, VMC)	20	20
ESXi-хостов на одном vCenter (вычислительных ресурсов)	600	600
ESXi-хостов по всем 50-ти vCenter (вычислительных ресурсов)	2 000	2 000
Облачных зон для всех конечных точек	200	200
Облачных зон для одной конечной точки	10	10
Машин сборки данных (и в приватном, и в публичном облаке)	200 000	280 000
Собранных образов	150 000	150 000
Сопоставлений образов и особенностей	150	150
Облачных зон и образов на каждое сопоставление образов	100	124
Облачных зон и особенностей на каждое сопоставление особенностей	100	124
Созданных VPZ тенантом провайдера из одной конечной точки	50	50
Созданных VPZ тенантом провайдера по всем конечным точкам	300	300
VPZ-назначений по каждому тенанту	60	60
Ресурсов на разворот	100	300
Кол-во блюпринтов	8 000	10 000
Кол-во объектов каталога	8 000	10 000
Кол-во источников контента в каталоге	1 000	2 000
Проектов	5 000	18 000
Пользователей на проект	5 000	5 000
Проектов на пользователя	5 000	17 000
Кастомных ролей по всем тенантам	500	1 000
Кастомных ролей на одного пользователя	100	500
Кол-во подписок всего	3 000	3 000
Кол-во подписок на разворот	40	40
Блокировок подписок по каждому топику события	50	50
Неблокируемых подписок по каждому топику события	50	50
Одобренных политик	4 500	4 500
Конвейеров	3 000	5 000
Действий ABX (AWS Lambda и Azure провайдеры)	1 000	2 000
Действий ABX (On-prem провайдер)	150	150
Активных алертов HCMP	70 000	70 000
Максимальная задержка для приватных конечных точек, мс	300	300

Также важно понимание того, сколько одновременных обращений может выдержать наш разворот:

	Medium	Extra Large
Конкурентного предоставления ресурсов блюпринтам / Day 2 действий на разворотах / предоставляемых ресурсов / ABX-действий / дополнительных запросов рабочих процессов vRO в очереди	250	750
Конкурентных выполнений конвейеров	20 в минуту	50 в минуту
Импортируемых пакетом машин с использованием рабочих процессов адаптации при множественных планах	19 000 в час	30 000 в час
Импортируемых пакетом машин с использованием рабочих процессов адаптации при одиночном плане	3 500 в час	6 000 в час

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

Лицензирование

Выбор уровня лицензии при покупке vRA – шаг очень ответственный. Доступно всего три варианта: Standard Plus, Advanced и Enterprise. Проиллюстрируем их ключевые возможности и различия таблицей:

Функции	Standard Plus	Advanced	Enterprise
Cloud Assembly		+	+
Service Broker		+	+
Code Stream			+
vRealize Orchestrator		+	+
Интеграция с Public Cloud (мульти-облачность)			+
Поддержка Kubernetes			+
Агностик-блюпринты Cloud			+
SaltStack Config	+	+	+
Централизованная политика и контроль		+	+
Интеграция с vRO		+	+
Поддержка VMware Solution Exchange		+	+
Гибридные облака с VMware Cloud на AWS		+	+
Мульти-тенантность		+	+
Само-обслуживаемая сеть		+	+
Шаблоны VMC		+	+
Интеграция со сторонними инструментами конфигурирования			+

Подготовка к развороту vRA 8.3

Разворот vRA может использовать как стандартный подход, так и кластеризацию, в соответствии с бизнес-требованиями и размером инфраструктуры. Учтите, что разворот типа Standard применим исключительно в тестах и PoC. В продакшене рекомендуется исключительно кластеризация разворота. Обо всем этом мы уже говорили в теории выше.

Так как процедура разворота предполагает комплекс из инсталляции и конфигурирования сразу трех Appliance, рекомендуется обязательно предварительно проверить свою среду на соответствие требованиям по ресурсам, описанные выше в подразделе «Требования и совместимость» и по vRA, и по Lifecycle Manager, и по Identity Manager.

Важно! Эти ресурсы по виртуальному «железу» система выделяет самостоятельно, и отредактировать их в процессе установки невозможно.

Так как работать ниже будем с Easy Installer (поможет развернуть сразу комплекс из vRealize Automation, VMware Identity Manager и vRealize Suite Lifecycle Manager), скачиваем его отсюда:

Кроме того, предварительно следует открыть все нужные порты, настроить LB и перекроить топологию NSX-T так, чтобы она в полной мере поддерживала структуру и функционал vRA. Если имеем дело с F5 BIG-IP LTM, помимо конфигурации LB важно завершить настройку DNS-сервера. И в любом случае убедиться в достаточности лицензирования сетевых компонентов. Ниже распишем, как правильно настраивать NSX-T под vRA (если интересует настройка F5 Big-IP LTM и Citrix NetScaler ADC – добро пожаловать на курсы VMware c изучением соответствующих вопросов или заказывайте консультацию у специалистов сферы).

Настройка NSX-T

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

У Т1-шлюза с балансировщиком нагрузки должен быть доступ к компонентам vRealize Automation/vRealize Orchestrator поверх сети. Теперь нам нужно сделать следующее:

Добавляем новый профиль приложения для https-запросов. Проходим на вкладку «Networking», выбираем в левой панели «Load Balancing» и в нем – вкладку «PROFILES». Сверху слева выбираем из выпадающего меню кнопки «Add Application Profile» и «Fast TCP Profile», заполняем новую карточку профиля, придумав для него имя:

Добавляем постоянный профиль. То же самое, но в типе профиля выбираем «PERSISTENCE», а в самой карточке – «Source IP», вписываем имя и устанавливаем «Persistence Entry Timeout» на 1500 с:

Добавляем активный Health Monitor. Проходим в «Networking» – «Load Balancing» – «MONITORS», нажимаем на «Add ACTIVE MONITOR» и выбираем «HTTP», вписываем имя и устанавливаем значения следующих опций: «Monitoring Port» (8008), «Monitoring Interval» (3), «Timeout Period» (10), «Fall Count» (3) и «Rise Count» (3). В секции «Additional Properties» по «HTTP Request» нажимаем на кликабельное «Configure»:

И назначаем параметры на обоих вкладках окна следующим образом:

Добавляем Server Pool. Проходим в «Networking» – «Load Balancing» – «SERVER POOLS» и нажимаем на «ADD SERVER POOL», вводим имя и выбираем по «Algorithm» – «LEAST_CONNECTION», настраиваем «SNAT Translation Mode» как «Automap», затем кликаем на «Select Members» в колонке «Members/Group»:

и нажимаем «ADD MEMBER»:

(указываем порт 443);

Настраиваем виртуальные серверы. Проходим в «Networking» – «Load Balancing» – «VIRTUAL SERVERS» и кликаем на «ADD VIRTUAL SERVER». Выбираем порт 443 (тип обозначится как L4 TCP), созданный выше профиль приложения, Server Pool и постоянный профиль:

Настраиваем LB. Проходим в «Networking» – «Load Balancing» – «LOAD BALANCERS» и нажимаем на «ADD LOAD BALANCER», после чего выбираем имя, подходящий размер LB (зависит от размера кластера vRA) и ранее созданный логический маршрутизатор на Т1:

Добавляем виртуальные серверы к LB. Проходим в «Networking» – «Load Balancing» – «VIRTUAL SERVERS» и открываем на редактирование созданные выше виртуальные серверы, назначив только что добавленный LB:

Приведем еще несколько полезных в процессе подготовки к инсталляции vRA замечаний по LB:

С LB рекомендовано использовать SSL-протокол по причине более простого разворота (не нужно разворачивать сертификаты vRA или vRealize Orchestrator на LB), отсутствия накладных расходов при обновлении сертификатов в будущем и упрощения связи (уникальные имена хостов компонентов помещаются в соответствующее поле сертификата, благодаря чему клиент не имеет проблем с доступом к нодам LB);
LB, в любом случае, должен инсталлироваться перед нодами vRA Appliance. Когда происходит инсталляция vRA, только одна нода должна быть активной в LB (отключаем все вторичные VA и IaaS из пулов LB), и обязательно открытие TCP-портов 443 и 8444 (5480 – не требуется, но рекомендуется). Порт 8283 нужен для доступа к vRealize Orchestrator Control Center;
Перед разворотом vRA Appliance и IaaS-компонетов позади существующего LB следует отключить хелс-чеки на всех балансировщиках нагрузки (по окончанию, конечно же, все включить обратно) или временно возвратить их к значению «default_tcp_monitor», убедившись, что трафик все так же пересылается на главные ноды;
Хорошей практикой считается настроить email-оповещение администратора от LB о любом случае падения нод vRA или vRealize Orchestrator (для NetScaler настраиваются специфические SNMP-ловушки, после попадания в которые менеджер SNMP посылает предупреждения);
Большинство разворотов используют one-arm-топологию, когда LB физически не находится на пути трафика (входящий и исходящий трафик путешествуют через один и тот же сетевой интерфейс). Применяется NAT для такого клиентского трафика и LB там указывается как адрес источника, а ноды посылают свой обратный трафик перед тем, как передать его клиенту, иначе он попробует добраться до клиента напрямую и связь упадет. В случае же multi-arm-конфигурации, трафик маршрутизируется через LB, а конечные устройства применяют его как свой дефолтный шлюз.

Важно! Для VMware Identity Manager LB не нужен. Как и для внутренних серверов vRealize Orchestrator, а также для внутренней базы данных PostgreSQL.

Подготовка к настройке базового функционала vRA

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

Подготовка к адаптации vRA Cloud Assembly

Случай интеграции уже функционирующей облачной структуры в vRA Cloud Assembly встречается весьма часто. И при этом следует учесть множество нюансов и вариантов имплементации, чтобы и конечной цели добиться, и не навредить текущей работе среды. Конечно, строить все с нуля проще, однако, наш материал был бы не полным, если бы мы не рассмотрели и такую ситуацию.

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

Создать учетную запись My VMware, используя корпоративный email (нужно для подписки и дальнейшего логгирования в vRA Cloud Assembly);
Открыть 443 порт для исходящего трафика с доступом через файервол к «*.vmwareidentity.com», «gaz.csp-vidm-prod.com» и «*.vmware.com» (нужно для подключения к сервисам vRA);
Далее, в зависимости от выбора облачного провайдера (или их группы), нужно предусмотреть:

Для AWS. Организацию пользовательского аккаунта с правами на чтение и запись максимального уровня (PowerUserAccess) в системе AWS IAM с 20-значным ID ключа доступа и соответствующим Secret Access Key.

Важно! Если используется внешний http-прокси, его нужно настроить для IPv4.

Рекомендуется разрешить следующие функции автомасштабирования:

- Для операций автоскейлинга (autoscaling:DescribeAutoScalingInstances / autoscaling:AttachInstances / autoscaling:DeleteLaunchConfiguration / autoscaling:DescribeAutoScalingGroups / autoscaling:CreateAutoScalingGroup / autoscaling:UpdateAutoScalingGroup / autoscaling:DeleteAutoScalingGroup/autoscaling:DescribeLoadBalancers);
- Для ресурсов автомасштабирования (предоставить все необходимые разрешения).

Для внедрения функций AWS Security Token Service (AWS STS) с целью поддержки временных учетных данных с ограниченными привилегиями нужно предоставить все разрешения на STS-ресурсы.

Для ЕС2 нужно предоставить все разрешения на ресурсы ЕС2 и такие действия: ec2:AttachVolume / ec2:AuthorizeSecurityGroupIngress / ec2:DeleteSubnet / ec2:DeleteSnapshot / ec2:DescribeInstances / ec2:DeleteTags / ec2:DescribeRegions / ec2:DescribeVolumesModifications / ec2:CreateVpc / ec2:DescribeSnapshots / ec2:DescribeInternetGateways / ec2:DeleteVolume / ec2:DescribeNetworkInterfaces / ec2:StartInstances / ec2:DescribeAvailabilityZones / ec2:CreateInternetGateway / ec2:CreateSecurityGroup / ec2:DescribeVolumes / ec2:CreateSnapshot / ec2:ModifyInstanceAttribute / ec2:DescribeRouteTables / ec2:DescribeInstanceStatus / ec2:DetachVolume / ec2:RebootInstances / ec2:AuthorizeSecurityGroupEgress / ec2:ModifyVolume / ec2:TerminateInstances / ec2:DescribeSpotFleetRequestHistory / ec2:DescribeTags / ec2:CreateTags / ec2:RunInstances / ec2:DescribeNatGateways / ec2:StopInstances / ec2:DescribeSecurityGroups / ec2:CreateVolume / ec2:DescribeSpotFleetRequests / ec2:DescribeImages / ec2:DescribeVpcs / ec2:DeleteSecurityGroup / ec2:DeleteVpc / ec2:CreateSubnet / ec2:DescribeSubnets / ec2:RequestSpotFleet.

Для использования функций балансировщика нагрузки нужно дать разрешение на его ресурсы и действия: elasticloadbalancing:DeleteLoadBalancer / elasticloadbalancing:DescribeLoadBalancers / elasticloadbalancing:RemoveTags / elasticloadbalancing:CreateLoadBalancer / elasticloadbalancing:DescribeTags / elasticloadbalancing:ConfigureHealthCheck / elasticloadbalancing:AddTags / elasticloadbalancing:CreateTargetGroup / elasticloadbalancing:DeleteLoadBalancerListeners / elasticloadbalancing:DeregisterInstancesFromLoadBalancer / elasticloadbalancing:RegisterInstancesWithLoadBalancer / elasticloadbalancing:CreateLoadBalancerListeners.

Дополнительно для AWS IAM можно включить опциональные разрешения: iam:SimulateCustomPolicy / iam:GetUser / iam:ListUserPolicies / iam:GetUserPolicy / iam:ListAttachedUserPolicies / iam:GetPolicyVersion / iam:ListGroupsForUser / iam:ListGroupPolicies / iam:GetGroupPolicy / iam:ListAttachedGroupPolicies / iam:ListPolicyVersions.

Для Microsoft Azure. Вначале нужно создать инстанс Microsoft Azure и получить валидную подписку, в которой конкретно сейчас нас интересует ID подписки. Затем создается приложение AD, опираясь на эти рекомендации.

Важно! Если используется внешний http-прокси, его нужно настроить для IPv4.

Кроме ID подписки нам понадобятся:

- ID тенанта (авторизация конечной точки для приложений AD, созданная в аккаунте Microsoft Azure);
- ID клиентского приложения (предоставляет доступ к AD в персональном аккаунте Microsoft Azure);
- Секретный ключ клиентского приложения (генерируется для сопоставления с ID клиентского приложения).

Помимо этого, нужны следующие разрешения:

- Для вычислений:

Microsoft.Compute/virtualMachines/extensions/write

Microsoft.Compute/virtualMachines/extensions/read

Microsoft.Compute/virtualMachines/extensions/delete

Microsoft.Compute/virtualMachines/deallocate/action

Microsoft.Compute/virtualMachines/delete

Microsoft.Compute/virtualMachines/powerOff/action

Microsoft.Compute/virtualMachines/read

Microsoft.Compute/virtualMachines/restart/action

Microsoft.Compute/virtualMachines/start/action

Microsoft.Compute/virtualMachines/write

Microsoft.Compute/availabilitySets/write

Microsoft.Compute/availabilitySets/read

Microsoft.Compute/availabilitySets/delete

Microsoft.Compute/disks/delete

Microsoft.Compute/disks/read

Microsoft.Compute/disks/write

- Для сети:

Microsoft.Network/loadBalancers/backendAddressPools/join/action

Microsoft.Network/loadBalancers/delete

Microsoft.Network/loadBalancers/read

Microsoft.Network/loadBalancers/write

Microsoft.Network/networkInterfaces/join/action

Microsoft.Network/networkInterfaces/read

Microsoft.Network/networkInterfaces/write

Microsoft.Network/networkInterfaces/delete

Microsoft.Network/networkSecurityGroups/join/action

Microsoft.Network/networkSecurityGroups/read

Microsoft.Network/networkSecurityGroups/write

Microsoft.Network/networkSecurityGroups/delete

Microsoft.Network/publicIPAddresses/delete

Microsoft.Network/publicIPAddresses/join/action

Microsoft.Network/publicIPAddresses/read

Microsoft.Network/publicIPAddresses/write

Microsoft.Network/virtualNetworks/read

Microsoft.Network/virtualNetworks/subnets/delete

Microsoft.Network/virtualNetworks/subnets/join/action

Microsoft.Network/virtualNetworks/subnets/read

Microsoft.Network/virtualNetworks/subnets/write

Microsoft.Network/virtualNetworks/write

- Для ресурсов:

Microsoft.Resources/subscriptions/resourcegroups/delete

Microsoft.Resources/subscriptions/resourcegroups/read

Microsoft.Resources/subscriptions/resourcegroups/write

- Для хранилища:

Microsoft.Storage/storageAccounts/delete

Microsoft.Storage/storageAccounts/listKeys/action

Microsoft.Storage/storageAccounts/read

Microsoft.Storage/storageAccounts/write

- Для Web:

Microsoft.Web/sites/read

Microsoft.Web/sites/write

Microsoft.Web/sites/delete

Microsoft.Web/sites/config/read

Microsoft.Web/sites/config/write

Microsoft.Web/sites/config/list/action

Microsoft.Web/sites/publishxml/action

Microsoft.Web/serverfarms/write

Microsoft.Web/serverfarms/delete

Microsoft.Web/sites/hostruntime/functions/keys/read

Microsoft.Web/sites/hostruntime/host/read

Microsoft.web/sites/functions/masterkey/read

Если используется Microsoft Azure с расширяемостью на основе действий этот список нужно дополнить такими разрешениями:

Microsoft.Web/sites/read

Microsoft.Web/sites/write

Microsoft.Web/sites/delete

Microsoft.Web/sites/*/action

Microsoft.Web/sites/config/read

Microsoft.Web/sites/config/write

Microsoft.Web/sites/config/list/action

Microsoft.Web/sites/publishxml/action

Microsoft.Web/serverfarms/write

Microsoft.Web/serverfarms/delete

Microsoft.Web/sites/hostruntime/functions/keys/read

Microsoft.Web/sites/hostruntime/host/read

Microsoft.Web/sites/functions/masterkey/read

Microsoft.Web/apimanagementaccounts/apis/read

Microsoft.Authorization/roleAssignments/read

Microsoft.Authorization/roleAssignments/write

Microsoft.Authorization/roleAssignments/delete

Если используется Microsoft Azure с расширяемостью на основе действий с расширениями этот список нужно дополнить такими разрешениями:

Microsoft.Compute/virtualMachines/extensions/write

Microsoft.Compute/virtualMachines/extensions/read

Microsoft.Compute/virtualMachines/extensions/delete

Для GCP. При создании и валидации облачных аккаунтов на Google Cloud Platform нужны учетные записи администратора проекта и владельца.

Важно! Если используется внешний http-прокси, его нужно настроить для IPv4.

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

- Для полного контроля над всеми ресурсами вычислительного ядра: roles/compute.admin;
- Для доступа пользователей, управляющих настроенными как запускаемыми в качестве сервисного аккаунта инстансами ВМ, к: compute.* / resourcemanager.projects.get / resourcemanager.projects.list / serviceusage.quotas.get / serviceusage.services.get / serviceusage.services.list, – нужно организовать роль roles/iam.serviceAccountUser;
- Для предоставления разрешений на вывод списка и чтение образов без других разрешений на них, а также создания пользователями ресурсов вроде инстансов и постоянных дисков, базирующихся на образах в проекте, нужно организовать на уровне проекта роль compute.imageUser с такими разрешениями: compute.images.get / compute.images.getFromFamily / compute.images.list / compute.images.useReadOnly / resourcemanager.projects.get / resourcemanager.projects.list / serviceusage.quotas.get / serviceusage.services.get / serviceusage.services.list;

- Для разрешения на создание, изменение и удаление инстансов ВМ, а также для настройки параметров экранированного VMBETA нужна роль roles/compute.instanceAdmin с такими функциями: compute.acceleratorTypes / compute.addresses.get / compute.addresses.list / compute.addresses.use / compute.autoscalers / compute.diskTypes / compute.disks.create / compute.disks.createSnapshot / compute.disks.delete / compute.disks.get / compute.disks.list / compute.disks.resize / compute.disks.setLabels / compute.disks.update / compute.disks.use / compute.disks.useReadOnly / compute.globalAddresses.get / compute.globalAddresses.list / compute.globalAddresses.use / compute.globalOperations.get / compute.globalOperations.list / compute.images.get / compute.images.getFromFamily / compute.images.list / compute.images.useReadOnly / compute.instanceGroupManagers / compute.instanceGroups / compute.instanceTemplates / compute.instances / compute.licenses.get / compute.licenses.list / compute.machineTypes / compute.networkEndpointGroups / compute.networks.get / compute.networks.list / compute.networks.use / compute.networks.useExternalIp / compute.projects.get / compute.regionOperations.get / compute.regionOperations.list / compute.regions / compute.reservations.get / compute.reservations.list / compute.subnetworks.get / compute.subnetworks.list / compute.subnetworks.use / compute.subnetworks.useExternalIp / compute.targetPools.get / compute.targetPools.list / compute.zoneOperations.get / compute.zoneOperations.list / compute.zones / resourcemanager.projects.get / resourcemanager.projects.list / serviceusage.quotas.get / serviceusage.services.get / serviceusage.services.list;
- Для полного контроля над инстансами вычислительного ядра, группами инстансов, дисков, снэпшотами и образами, доступа ко всем сетевым ресурсам вычислительного ядра нужна роль roles/compute.instanceAdmin.v1 с разрешениями: compute.acceleratorTypes / compute.addresses.get / compute.addresses.list / compute.addresses.use / compute.autoscalers / compute.backendBuckets.get / compute.backendBuckets.list / compute.backendServices.get / compute.backendServices.list / compute.diskTypes / compute.disks / compute.firewalls.get / compute.firewalls.list / compute.forwardingRules.get / compute.forwardingRules.list / compute.globalAddresses.get / compute.globalAddresses.list / compute.globalAddresses.use / compute.globalForwardingRules.get / compute.globalForwardingRules.list / compute.globalOperations.get / compute.globalOperations.list / compute.healthChecks.get / compute.healthChecks.list / compute.httpHealthChecks.get / compute.httpHealthChecks.list / compute.httpsHealthChecks.get / compute.httpsHealthChecks.list / compute.images / compute.instanceGroupManagers / compute.instanceGroups / compute.instanceTemplates / compute.instances / compute.interconnectAttachments.get / compute.interconnectAttachments.list / compute.interconnectLocations / compute.interconnects.get / compute.interconnects.list / compute.licenseCodes / compute.licenses / compute.machineTypes / compute.networkEndpointGroups / compute.networks.get / compute.networks.list / compute.networks.use / compute.networks.useExternalIp / compute.projects.get / compute.projects.setCommonInstanceMetadata / compute.regionBackendServices.get / compute.regionBackendServices.list / compute.regionOperations.get / compute.regionOperations.list / compute.regions / compute.reservations.get / compute.reservations.list / compute.resourcePolicies / compute.routers.get / compute.routers.list / compute.routes.get / compute.routes.list / compute.snapshots / compute.sslCertificates.get / compute.sslCertificates.list / compute.sslPolicies.get / compute.sslPolicies.list / compute.sslPolicies.listAvailableFeatures / compute.subnetworks.get / compute.subnetworks.list / compute.subnetworks.use / compute.subnetworks.useExternalIp / compute.targetHttpProxies.get / compute.targetHttpProxies.list / compute.targetHttpsProxies.get / compute.targetHttpsProxies.list / compute.targetInstances.get / compute.targetInstances.list / compute.targetPools.get / compute.targetPools.list / compute.targetSslProxies.get / compute.targetSslProxies.list / compute.targetTcpProxies.get / compute.targetTcpProxies.list / compute.targetVpnGateways.get / compute.targetVpnGateways.list / compute.urlMaps.get / compute.urlMaps.list / compute.vpnTunnels.get / compute.vpnTunnels.list / compute.zoneOperations.get / compute.zoneOperations.list / compute.zones / resourcemanager.projects.get / resourcemanager.projects.list / serviceusage.quotas.get / serviceusage.services.get / serviceusage.services.list.
Для облачного аккаунта NSX-T. Создать аккаунт с привилегиями на чтение и запись для роли NSX-T Enterprise Administrator и учетную запись для доступа, IP-адрес или FQDN NSX-T. Этому администратору также понадобится доступ к vCenter Server в разрезе разрешений под агент vSphere (для облачных аккаунтов на базе vCenter).
Для облачного аккаунта vCenter. Нужен аккаунт с правами на чтение и запись под IP-адрес или FQDN vCenter и доступ к vCenter Server в разрезе разрешений под агент vSphere (для облачных аккаунтов на базе vCenter).
Для VMware Cloud на AWS. Необходим аккаунт cloudadmin@vmc.local или любой пользовательский из группы CloudAdmin, роль NSX Enterprise Administrator и учетная запись для доступа, доступ через NSX Cloud Admin к SDDC-среде организации на VMware Cloud на AWS, доступ как администратора к SDDC-среде организации на VMware Cloud на AWS, API-токен VMware Cloud на AWS, а также IP-адрес или FQDN vCenter. Доступ к vCenter Server в разрезе разрешений под агент vSphere (для облачных аккаунтов на базе vCenter) нужен аналогично.

При перечислении облачных подключений мы неоднократно упоминали разрешения, в которых нуждается агент vSphere, если речь об управлении облачными аккаунтами на базе vCenter или VMware Cloud на AWS. Эти разрешения должны быть включены для всех кластеров в vCenter Server, а не только для тех, что хостят конечные точки. В целом, чтобы полноценно работать со средой такого типа, администратору необходимы учетные записи конечных точек vSphere, либо же те, под которыми службы агента запускаются в vCenter. В частности, в разрезе сфер влияния выделяются такие группы разрешений:

Хранилище данных (выделение места, поиск по хранилищу, низкоуровневые операции с файлами);
Кластер хранилища данных (настройка);
Папка (создание/удаление);
Глобальная группа (назначение и управление пользовательскими параметрами);
Сеть (назначение сети);
Разрешения (изменение разрешений);
Ресурсы (назначение ресурсного пула ВМ, миграция выключенных/включенных ВМ);
Библиотека контента (добавление, удаление, исключение, синхронизация и обновление объекта библиотеки/создание, удаление и обновление локальной библиотеки/создание, удаление, исключение, синхронизация и обновление библиотеки с подпиской/загрузка файлов/чтение с хранилища/самоанализ типа/обновление параметров конфигурации, файлов, библиотеки/просмотр параметров конфигурации. Чтобы назначать разрешения по библиотеке контента администратор должен предоставить пользователю разрешения глобальной группы);
Теги (назначение и открепление, создание и удаление, редактирование тегов vSphere/создание, удаление и редактирование категории тегов для vSphere, изменение поля UsedBy для тега или категории);
vApp (импорт/настройка приложений);

Важно! vApp.Import требуется для OVF-шаблонов и для предоставления ВМ из библиотеки контента. vApp.vApp необходимо при использовании cloud-init в скриптовании облачной конфигурации. Последний параметр разрешает модификацию внутренней структуры vApp, например, информации о продукте и его свойств.

Инвентарь ВМ (клонирование/создание нового/перемещение/удаление);
Взаимодействие с ВМ (настройка CD-медиа/работа с консолью/подключение устройств/включение/выключение/перезагрузка/перевод в статус Suspend/инсталляция инструментов);
Настройка ВМ (добавление существующего или нового, удаление диска/изменение счетчика CPU и ресурсов/расширение виртуального диска/отслеживание изменений диска/настройка памяти/модификация параметров устройств/переименование/добавление аннотаций/настройка параметров/размещение свопа/расширенные настройки);
Предоставление ВМ (кастомизация/клонирование шаблона/клонирование ВМ/разворот шаблона/чтение параметров кастомизации);
Статус ВМ (создание, удаление и возвращение к снэпшоту).

Подготовка к адаптации vRA Service Broker

Чтобы сервис Service Broker корректно заработал, предварительно администратору автоматизации следует собрать информацию и проделать такую подготовительную работу:

ID VMware после того, как завели аккаунт «My VMware» с использованием корпоративного email (для подписки и логгирования в vRA Service Broker);
Открыть порт 443 для исходящего трафика с доступом через файервол к «*.vmwareidentity.com», «gaz.csp-vidm-prod.com», «*.vmware.com» (для подключения к облачным сервисам VMware);
Импортировать облачные шаблоны vRA Cloud Assembly из ассоциированного инстанса (для проектов нужно знать, кто является членом и какого проекта в Cloud Assembly – это для того, чтобы можно было добавить источник контента облачных шаблонов);
Импортировать шаблоны Amazon CloudFormation, хранящиеся в S3-buckets Amazon, если нужно, в разрезе проектов (идентификация членов каждого проекта в Cloud Assembly), имен buckets, ключей доступа к buckets и секретных ключей, целевых аккаунтов разворота и регионов (информация о настроенных в Cloud Assembly облачных аккаунтах и регионах, где будут разворачиваться шаблоны) – это для добавления источника шаблонов Amazon CloudFormation;
Назначить пользовательский аккаунт с правом на чтение и запись (максимальный уровень, 20-значный ID ключа доступа и соответствующий секретный ключ доступа) – это для добавления облачного аккаунта Amazon Web Services в качестве целевого региона при развороте шаблона, если необходимо.

Подготовка к адаптации vRA Code Stream

Доступ к сервису Code Stream vRA дается администраторам или разработчикам, и для него необходима подписка на аккаунт My VMware с использованием корпоративной почты и вход в систему под соответствующими привилегиями. Также, как и в случае с другими сервисами автоматизации, должен быть открыт порт 443 для исходящего трафика с доступом через файервол к «*. vmwareidentity.com», «gaz.csp-vidm-prod.com» и «*. vmware.com».

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

Процедура инсталляции vRA 8.3

VMware рекомендует приступать к развороту vRA путем использования vRealize Easy Installer – единой инсталляционной консоли, значительно сокращающей время установки vRA и количество шагов по претворению этой цели в жизнь. Она вначале развернет Lifecycle Manager, который, в свою очередь, займется разворотом и начальной настройкой VMware Identity Manager и vRealize Automation:

Важно! Начиная с версии 8.0, установка vRA не зависит от Windows.

План процедуры разворота vRA с Easy Installer выглядит так:

Скачиваем ISO vRealize Easy Installer, подмонтируем этот образ и запускаем выполняемый файл;
Разворачиваем Lifecycle Manager и осуществляем его настройку;
Разворачиваем Identity Manager с помощью Lifecycle Manager;
Разворачиваем vRA с помощью Lifecycle Manager;
Создаем кластеры Identity Manager и vRA;
Настраиваем vRA и проверяем работу всех сервисов.

Приступим к его воплощению в действительность.

Установка Appliance с помощью Easy Installer

Для начала монтируем скаченный (см. выше) образ Easy Installer «vra-lcm-installer.iso» (работает с гостевыми ОС Linux/macOS/Windows):

Проходим в его директорию «vrlcm-ui-installer», выбираем папку с нашей ОС (для Windows – папка «win32», для macOS – «mac») и запускаем приложение «installer»:

В случае Linux заходим на ВМ с ней, запускаем

apt-get install p7zip-full

7z x vra-lcm-installer.iso

chmod +x vrlcm-ui-installer/lin64/installer

apt install libnss3 (если еще не проинсталлировано)

vrlcm-ui-installer/lin64/installer

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

Выбор типа инсталляции. Здесь доступны две возможности: проинсталлировать все три Appliance с нуля или смигрировать данные с предыдущей, уже работающей версии Lifecycle Manager, в новый Appliance:

В случае миграции перенесутся дата-центры и системы vCenter Server, все существующие среды, DNS, SNMP, NTP, My VMware и прокси-настройки. Нас сейчас интересует бокс «Install»;

Важно! Миграция по Easy Installer поддерживается для Lifecycle Manager 1.3 и свежее. Если используются инстансы более старых версий, вначале их нужно проапгрейдить до 1.3.

Introduction. Рассказ о продуктах в составе разворота. «Next» (см. первый скриншот этой главы);
End User License Agreement. Принимаем лицензионное соглашение и CEIP:

«Next»;

Appliance Deployment Target. Указываем FQDN vCenter Server, порт и учетную запись администратора:

Вылетит предупреждение о сертификате – соглашаемся «Accept»:

«Next»;

Select a Location. Выбираем дата-центр и папку, куда поместить устанавливаемые Appliancе:

«Next»;

Select a Compute Resource. Выбираем кластер vSphere:

«Next»;

Select a Storage Location. Выбираем хранилище данных (предпочтительно указать тип «thin provisioning»):

«Next»;

Network Configuration. Здесь задаем все, что заводили в подразделе «Настройка NSX-T» раздела «Подготовка…» выше (порт-группу, маску подсети, дефолтный шлюз, DNS-сервера, DNS доменное имя и т.д.):

«Next»;

Password Configuration. Пароли задаются для всех устанавливаемых продуктов (рута для vRealize Automation и Lifecycle Manager, администратора для VMware Identity Manager, пользователя для SSH-доступа, пароль рута общий и пароль для пользователя дефолтной настройки, используемый при интеграции всех продуктов):

«Next»;

Важно! Пароли должны содержать, минимум, одну цифру, одну большую букву, одну маленькую букву, один спецсимвол (!@#$%^&). Длина пароля от 8 до 16 знаков.

Lifecycle Manager Configuration. Задаем конфигурацию Lifecycle Manager. Ввод лицензионного ключа не требуется:

«Next»;

Identity Manager Configuration. Задаем конфигурацию Если это первая установка, выбираем из списка «Install new vIDM» и заполняем поля «Virtual Machine Name», «IP Address», «Hostname» и«Default Configuration Admin». Если нужно импортировать данные уже существующего инстанса (не ниже версии 3.3.1), выбираем «Import Existing vIDM» и заполняем «Hostname», «Admin Password», «System Admin Password», «SSH User Password», «Root Password», «Default Configuration Admin» и «Default Configuration Admin Password». Ввод лицензионного ключа не требуется:

«Next»;

vRealize Automation Configuration. На этом шаге можно пропустить инсталляцию vRA, если пока она не нужна (ползунок в самом верху «Skip vRealize Automation installation»), но учтите, что потом придется зайти в UI Lifecycle Manager и устанавливать продукт вручную. Выбираем тип разворота простой (Standard Deployment – только для микросред, тестов и PoC):

или кластеризацию (Clustered Deployment – продакшен-развороты):

и заполняем имя среды vRA, валидный лицензионный ключ, включаем или выключаем, по желанию, режим FIPS, выбираем размер нод и в случае стандартного разворота просто предоставляем информацию о названии ВМ, ее IP-адресе и имени хоста, а в случае кластера – данные балансировщика нагрузки, и все то же самое, что и в простом типе, но не только для мастер-ноды, а и для двух вторичных. Также во втором варианте будет доступен блок расширенной настройки, в котором можно указать, использовать ли дефолтную или пользовательскую конфигурацию внутренних подов и сервисов, а также диапазон IP кластера и служб K8S. «Next»;

Summary. Покажет все заданные нами настройки, соглашение с которыми запустит сам инсталляционный процесс:

«Submit».

Следить за инсталляцией можно прямо из этого визарда. Если в процессе что-то произойдет, и он прервется, следует зайти в Lifecycle Manager, кликнув на соответствующую ссылку:

Там, под сфейлившимся статусом нужно нажать на детали, и после их анализа и устранения причин неудачи кликнуть на «Retry», если речь о запросе, или на «Redeploy», если не удался весь разворот.

Там же можно поменять дефолтный пароль, если что (учетная запись по умолчанию – admin@local).

Теперь мы можем зайти в UI Lifecycle Manager:

Здесь в левой панели есть секция «Environments», и в правой рабочей области мы можем увидеть наш дефолтный vRA:

Ниже этой секции – «Request», на которой показывается общий статус продукта и среды, информация обо всех типах запросов, запущенных в среде (In Progress/Completed/Failed):

Выше – секция «Dashboard», где будут все установленные службы:

Кстати, открыть детали запросов можно и отсюда, кликнув на «Lifecycle Operations», а затем – на конкретно интересующий запрос.

Итак, мы развернули все три вида базовых Appliance, необходимых для дальнейшей работы с vRA.

Базовая начальная настройка vRA

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

Настройка vRA Cloud Assembly

Заметим, все, о чем ниже будет речь в этом подразделе, делается в UI сервиса Cloud Assembly, получить доступ в который можно из консоли vRA (вкладка «Services», в рабочем поле справа под блоком «My Services»), куда зайти можно, набрав URL: https://<vRealize_Automation_FQDN>.

Для начала оговоримся, что если речь о самом начале знакомства с Cloud Assembly, микроскопическом развороте, тесте базовых функций или PoC, можно прямо из консоли vRA нажать на «Launch Quickstart» под правами администратора дефолтной конфигурации (назначенными нами при развороте Appliance):

И далее нам предложат задать самые элементарные настройки среды для on-premises SDDC с vRA, заполнить каталог самообслуживания и развернуть свой первый блюпринт:

Существует принципиальная разница в Quickstart vRA под on-premises vCenter Server и под VMware Cloud Foundation, если именно он используется в управлении SDDC. Полный перечень задач, поддерживаемых помощником Quickstart, с использованием возможностей Cloud Assembly и Service Broker vRA в случае vCenter Server:

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

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

В случае Cloud Foundation имеем то же самое, за исключением первого пункта: добавление облачного аккаунта vCenter Server происходит для ассоциированного с выбранным SDDC-менеджером домена рабочих нагрузок инстанса vCenter Server.

Учтите, что полный запуск с нуля Quickstart повторно невозможен – однажды использованный он добавляется на сервисную страницу консоли, и открыв его снова можно только добавить новый инстанс vCenter Server или Cloud Foundation. Если нужно все перезадать с самого начала или если необходим другой тип клауд-аккаунта, VMware предлагает второй тип помощника – Guided Setup.

Использование Quickstart в начальной настройке vRA Cloud Assembly

Пробежимся по всем секциям помощника в случае on-premises vCenter Server:

vCenter Server. Из выпадающего списка выбираем «Add a new vCenter Server account» (это для первого аккаунта. Если просто добавляем дополнительные – выбираем «Use an existing vCenter Server account»), вписываем IP-адрес или FQDN vCenter Server, имя пользователя и пароль (все без пробелов) и кликаем на кнопку «VALIDATE»:

Важно! Если сертификаты не сконфигурированы, появится предупреждение о не доверенном сертификате. На этом шаге либо решаете проблему, либо нажимаете «Accept», чтобы оставить все, как есть.

После успешной валидации появится поле «Allow provisioning to these datacenters», где выбираем нужные дата-центры для разворота (каждый дата-центр добавится как клауд-зона аккаунта региона в vRA):

Нажимаем на кнопку «Create and go to next step»;

NSX. Выбираем версию NSX (Т/V/None), вводим IP-адрес или FQDN, имя пользователя и пароль, а в поле «NSX Mode» выбирается способ управления конечной точкой:

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

Нажимаем на кнопку «Validate and Create», а затем – на «Next Step»;

Content. Здесь происходит назначение элементов инфраструктуры и создание первых облачных шаблонов, которые станут доступными в каталоге Service Broker. В поле «Datacenter» выбирается наш дата-центр (он станет клауд-зоной в vRA Cloud Assembly), в «VM templates» выбираем шаблоны ВМ на инстансе vCenter Server, кликаем на «Select Templates» и находим их, выбираем «Datastore / cluster», который станет профилем хранилища, в «Network» нажимаем на «Browse» и выбираем нужную сеть (это должна быть сеть NSX – не сеть vCenter Server), которая станет клауд-зоной, поддерживающей наш сетевой профиль, а в «IP assignment type» нажимаем на «Configure» и настраиваем DHCP или статический тип IP-связи (это будет сетевой профиль).

Чтобы добавить шаблоны NSX, кликаем на «Also add sample NSX cloud tempaltes to the catalog» и выбираем «Tier-0 logical router» и «Edge cluster»:

«Next step»;

Project. Из выпадающего списка выбираем «Create a new project» (если создаем первый новый, а если хотим просто добавить новые шаблоны в уже существующий проект – «Use an existing project»), даем ему имя и опционально – описание, добавляем пользователей в графы «Administrators» и «Members»:

«Next step»;

Policies. Здесь назначаются стартовые политики и политики именования машин, ассоциированные с созданным выше проектом, чтобы произошла унификация для всех разворотов в разрезе требований по одобрению, времени аренды и пр.

В первом блоке «Approval» нажимаем на «Edit» и назначаем администратора, который будет одобрять запрос на разворот ресурсов (если хочется назначить другого пользователя, нужно выдать ему соответствующие разрешения – см. раздел «Подготовка…» выше):

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

Третий блок «Machine» позволяет редактировать метод нумерации и политику именования машин:

«Next step»;

Summary. Проверяем созданную нами конфигурацию и нажимаем «Run Quickstart», чтобы применить изменения:

В случае Cloud Foundation прохождение помощника Quickstart выглядит следующим образом:

SDDC Manager. Выбираем из списка «Add a new SDDC Manager» (или выбираем для расширения уже заведенный), задаем его FQDN, имя администратора и пароль, после чего нажимаем на кнопку «Validate»:

Если сертификаты не настроены, вылетит аналогичное первому случаю предупреждение. Затем после успешной валидации наша первая секция расширится на пункт назначения домена рабочих нагрузок, в котором надо выбрать подходящий и нажать внизу на кнопку «Create and go to next step»:

Cloud Account. Вводим имя облачного аккаунта, если хотим автоматически создать учетные записи для сервисов, ставим галочку в «Auto Configuration», задаем имя vCenter Server, имя его пользователя и пароль, и снова нажимаем на «Validate». После этого задаем имя NSX Manager, имя пользователя и пароль NSX, а также режим NSX, и опять – «Validate». А в блоке «Configuration» в поле «Allow provisioning to these datacenters» выбираем соответствующий SDDC дата-центр и кликаем на кнопку «Create and go to next step»:

NSX. Заполняем блок, касающийся настроек NSX, включая «Tier-0 logical router» и «Edge cluster», уже по традиции проверяем валидность кнопкой «Validate and Create» и переходим к следующему этапу по «Next Step»:

Далее будут полностью аналогичные первому варианту работы с Quickstart секции, касающиеся создания и разворота облачных шаблонов, нашего первого проекта и политик, после чего снова проверяем все сделанные нами настройки в секции «Summary» – должны получить что-то вроде такого:

Кнопкой «Run Quickstart» инициируем их имплементацию.

Использование Guided Setup в начальной настройке vRA Cloud Assembly

Если, как мы уже говорили выше, мы имеем дело с облачными сервисами других вендоров, или просто хотим получить гораздо более объемный функционал и тонкую настройку нашего инстанса Cloud Assembly, используем помощник Guided Setup в UI одноименного сервиса. Его инструкции проведут нас по такому пути (заходим под правами администратора облака):

Добавление облачного аккаунта («Infrastructure» – «Connections» – «Cloud Accounts») – «Create Cloud Account»;
Добавление облачной зоны («Infrastructure» – «Configure» – «Cloud Zones») – «Create Cloud Zone»;
Добавление проекта («Infrastructure» – «Configure» – «Projects») – «Create Project»;
Добавление сопоставления особенностей («Infrastructure» – «Configure» – «Flavor Mappings») – «Create Flavor Mapping»;
Добавление сопоставления образов («Infrastructure» – «Configure» – «Image Mappings») – «Create Image Mapping»;
Создание облачного шаблона («Design» – «Cloud Templates» – «New From») – «Create Cloud Template»;
Обзор развернутого облачного шаблона и сами развороты.

Кликабельное название этого помощника находится в правом верхнем углу интерфейса vRA:

То, на чем фокусируется в данный момент помощник, зависит от контекста вкладки, где в данный момент завис пользователь. В примере на скриншоте выше мы получим гайд по «Deployments».

Если в появившейся подсказке нажать на «Guided Setup Overview» в следующем окошке можем ознакомиться с диаграммой (раскрывается при нажатии на верхнюю строчку «Guided setup diagram»), которая проиллюстрирует в графическом формате все те шаги, которые мы только что перечислили. Ниже будут сами этапы настройки Cloud Assembly для работы, и, кликая на каждый, в окне получим подсказки порядка заполнения форм, в которые нас перекинет. А вот, собственно, все этапы с примерами заполнения и текстом подсказок:

Теперь на вкладке «Deployments» UI vRA мы можем управлять разворотами, следить за процессом предоставления ресурсов, траблшутить сфейлившиеся запросы и т.д.:

Настройка vRA Service Broker

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

Предположим, у нас уже есть какие-то развернутые облачные шаблоны Cloud Assembly и осуществлен вход в систему под правами администратора облака. Заметим, все делается в UI сервиса Service Broker, получить доступ в который можно из консоли vRA (вкладка «Services», в рабочем поле справа под блоком «My Services»). Далее нам нужно, поэтапно:

Импортировать реализованные облачные шаблоны («Content & Policies» – «Content Sources» – «New»). Здесь выбираем тип шаблона (в нашем примере – «VMware Cloud Templates»), называем источник, выбираем проект-источник, ассоциированный с этими облачными шаблонами, в «Source Project» и кликаем на «Validate», чтобы проверить связь и увидеть, сколько именно шаблонов планируется импортировать, а затем нажимаем кнопку «Save & Import»:

Сделать доступными импортированные объекты для проектов («Content & Policies» – «Content Sharing» – <выбор проекта>). Здесь выбираем целевой проект из выпадающего меню «Project» и тогда ниже будет табличка с уже расшаренными ранее объектами (если подобное уже делалось), где можно галочками выбирать необходимые, либо же добавить новый объект кнопкой «Add Items» вверху таблички и в появившемся окне выделить нуждающийся в общем пользовании новый контент. Там есть выпадающее меню «Content Sources», в котором, если нужно назначить только определенные облачные шаблоны, выбираем «All Content». «Save»:

Развернуть каталог объектов, опираясь на имеющийся проект («Catalog» – <объект каталога> – «Request»). Заходим на вкладку «Catalog», выбираем карточку с облачным шаблоном, который нуждается в развороте, и нажимаем на кликабельную ссылку «Request» на ней. Появится окошко, где выбираем соответствующий проект, заполняем имя разворота, опционально приводим его описание, а также кол-во ресурсов, отдаваемых под этот шаблон:

«Submit»;

Убедиться, что разворот осуществился успешно и есть доступ к нему по IP-адресу или другими методами («Deployments» – <имя разворота>). За процессом разворота можно следить на второй вкладке UI «Deployments», задействовав опции фильтрации или поиска интересующего разворота. Когда разворот полностью завершится, кликаем на его карточку и проверяем, обнаружился ли IP-адрес:

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

При желании то же самое можно сделать с шаблонами Amazon CloudFormation – обязательно рассмотрим в следующей статье, посвященной администрированию vRA.

Важно! Разворот всегда должен быть либо одиночной машиной, либо приложением.

Базовые операции с vRA Code Stream

Предваряя разговор о Code Stream, нужно сказать, что все три сервиса vRA очень тесно взаимосвязаны: Cloud Assembly помогает разворачивать облачные шаблоны, Code Stream создает конвейеры и управляет ими, а Service Broker публикует эти конвейеры и запускает их.

Под привилегиями администратора создаются конечные точки, чтобы рабочие инстансы были доступны девелоперам. Обе роли – и администратора, и разработчика – могут создавать, управлять, связывать конвейеры, а также делать массу других полезных вещей, о которых более подробно поговорим в материале про администрирование. Например, убедиться в том, что код успешно прошел все стадии конвейера, можно в «Executions», или же при сбое конвейера можно заглянуть в «Dashboards» и понять, в чем именно была ошибка.

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

Перед тем, как приступить к базовой настройке и изучению минимального функционала vRA Code Stream, следует убедиться, что доступны on-premises репозитории GitLab или GitHub и в них есть тот код, который должен использовать наш конвейер.

Научиться работать с сервисом Code Stream поможет уже знакомый нам по предыдущим подразделам Guided Setup, зайти в который нужно из консоли vRA, перейдя в UI Code Stream из блока My Services:

А в целом же, нам нужно сделать следующее, по порядку:

Добавить конечную точку (Git), чтобы связать vRA Code Stream и on-premises репозиторий, кликнув на «Add Endpoints» – «My Git» в помощнике, либо же из левой панели под «Configure» на «Endpoints» и добавив новую. В открывшейся карточке нужно выбрать проект, тип конечной точки, назвать ее и опционально можно привести описание, выбрать кластер и тип аутентификации, а также, при необходимости, отметить как ограниченную в «Mark restricted»:

Обязательно после заполнения карточки нужно нажать на «Validate», чтобы проверить связь с конечной точкой. «Create»;

Создать конвейер из того же помощника, либо из меню левой панели (отдельная секция «Pipelines»). Процесс создания конвейеров – многокомпонентный, включающий инициацию этапов и задач. Интересно, что один и тот же конвейер может иметь доступ ко множеству конечных точек и запускать комплексные задачи, касающиеся, например, рабочего пространства (включение именования конечных точек хостов, локаций построения образов, ограничения ресурсов и т.д.), ввода/вывода (проектируется для сбора пользовательских данных при запуске конвейера и вывода переменных в различные системы и задачи конвейеров), этапов разворота (предоставление логического порядка процессов и систем разработчику), а также назначения индивидуального блока кода каждой стадии:

После создания конвейера нужно добавить для него задачу, использующую конечную точку Git. Также опционально можно настроить оповещение по email. После сохранения конвейера кнопкой «Save», в списке всех созданных его нужно найти и выбрать по нему действие «Enable», чтобы он мог запуститься:

А потом из его карточки нужно нажать на кнопку «Run».

В секции левой панели «Executions» (или из Guided Setup – шаг 4) можно наблюдать за процессом работы конвейера. А если в процессе замечена какая-то проблема, всегда можно перейти в секцию «Dashboards» (5-й шаг помощника) и уточнить, в чем причина.

Что нужно сделать после инсталляции vRA?

Включить все не главные ноды на LB и включить на балансировщике нагрузки все мониторы. Это – обязательно. Также, в зависимости от нужд и конфигурации системы, можно предпринять следующее:

Настроить лицензию vRA (впоследствии будет доступна ее замена – рассмотрим подробно в будущей статье по «Администрированию…»);
Создать сертификаты продуктов, развернутых в vRealize Suite Lifecycle Manager;
Сменить дефолтные пароли;
Настроить AD-группы в vRealize Suite Lifecycle Manager;
Инициировать синхронизацию инвентаря, чтобы идентифицировать текущий статус разворота vRA.

А далее приступать к непосредственному использованию vRA, построению и настройке его архитектуры, расширению функционала – но, это уже повод для нашего следующего разговора в рамках отдельной статьи по «Администрированию…».

Добавление и импорт лицензий, сертификатов и смена дефолтных паролей

С первыми тремя разновидностями операций в Lifecycle Manager справляется комплексное приложение Locker. Благодаря ему с единственной панели можно управлять лицензиями, сертификатами и паролями. Для этого на «Dashboard» UI Lifecycle Manager правее «Lifecycle Operations» кликаем на «Locker». Далее, в зависимости от того, с чем конкретно необходимо поработать, выбираем на левой панели соответствующую иконку:

Пароли (иконка «ключа»). Нажимаем в правой рабочей области на «ADD», вводим псевдоним и пароль, повторно пароль и его описание, а также валидное имя пользователя. «Add»;
Сертификаты (блок «Certificate»). Здесь можно выбрать «Generate CSR» или «Import Certificate». В первом случае входим в требуемые текстовые боксы и следуем их подсказкам в процессе заполнения. Вводим FQDN или IP-адрес, чтобы опция загрузила PEM-файл для подписи доверенного сертификата, выбираем длину ключа и нажимаем на «Generate». Если нужно импортировать уже существующий сертификат, вводим валидное имя сертификата, в текстовом боксе «Passphrase» вводим пароль, нажимаем на «Browse File» и находим сохраненный PEM-файл, подгружаем его, ключ и подробности цепочки заполнятся после подгрузки автоматически. Если генерируем новый, то просто вводим ключ и подробности цепочки вручную, после чего нажимаем на «Import»;

Важно! Если сертификат истекает менее, чем через 15 дней, его нельзя импортировать.

Лицензии (иконка «License»). Нажимаем на «ADD», вводим псевдоним в текстовое поле «License Alias», ключ и кликаем на «Validate». Если валидация прошла нормально, нажимаем на «Add».

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

Что ж, по итогам сегодняшнего разговора можно резюмировать, что наше первое знакомство с vRealize Automation прошло относительно успешно. Надеемся, этот материал был полезен и достаточно прост в понимании, а в следующей статье цикла по автоматизации «Администрирование…» мы обязательно коснемся всех вопросов, вышедших за его рамки, научимся полноценно использовать функционал vRA, решать самые разнообразные практические задачи, а также постараемся коснуться тем расширенных функций и многого другого. И, конечно же, отдельно рассмотрим нюансы перехода с устаревших версий на самую свежую на сегодняшний день.

Если же у вас остались какие-то вопросы или хочется погрузиться глубже в тему дизайна и имплементации vRealize Automation 8.3, обязательно постарайтесь записаться на соответствующие авторизованные курсы VMware или же обращайтесь к опытным консультантам сферы.

Что необходимо знать о VMware vRealize Automation 8.3?

Архитектура и компоненты

Важно! vRealize Automation ставится исключительно через LCM.

Важно! Все компоненты vRealize Lifecycle Manager, VMware Identity Manager, vRealize Automation и vRealize Orchestrator должны быть синхронизированы в одинаковой временной зоне. Рекомендуется UTC+0.

High Availability компонентов vRA и продуктов-спутников

Аутентификация в vRA 8.3 и роли

Важно! Без установки или импорта VMware Identity Manager из Lifecycle Manager невозможно получить доступ к любой другой среде.

VMware Identity Manager

Поддержка мульти-тенатности

Преимущества и best practice мульти-тенантности

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

Уровни дизайна vRA

Принципы грамотного дизайна

Уровни архитектуры и дизайн облачных ресурсов

Советы по управлению ресурсами

Стандартизация в корпоративном дизайне

Важно! Если речь о DNS-поименовании, допустимы исключительно знаки ASII (A-Z, 0-9), без спецсимволов. Если речь о Windows-машинах, их имена не должны содержать более 15 знаков.

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

Важно! 8.х-семейство vRA не поддерживает вложенные виртуальные среды типа ESX > ESX > vRA.

Виртуальное железо

Сеть

Важно! После инсталляции vRA запрещены изменения IP-адресации и переименование хоста.

Требования по SaltStack Config в тандеме с vRA

Масштабируемость и конкурентные максимумы

Рекомендованные имена хостов, роли серверов и их сертификаты, принципы соединения при разворотах малого и большого типа

Лицензирование

Подготовка к развороту vRA 8.3

Важно! Эти ресурсы по виртуальному «железу» система выделяет самостоятельно, и отредактировать их в процессе установки невозможно.

Настройка NSX-T

Важно! Для VMware Identity Manager LB не нужен. Как и для внутренних серверов vRealize Orchestrator, а также для внутренней базы данных PostgreSQL.

Подготовка к настройке базового функционала vRA

Подготовка к адаптации vRA Cloud Assembly

Важно! Если используется внешний http-прокси, его нужно настроить для IPv4.

Важно! Если используется внешний http-прокси, его нужно настроить для IPv4.

Важно! Если используется внешний http-прокси, его нужно настроить для IPv4.

Подготовка к адаптации vRA Service Broker

Подготовка к адаптации vRA Code Stream

Процедура инсталляции vRA 8.3

Важно! Начиная с версии 8.0, установка vRA не зависит от Windows.

Установка Appliance с помощью Easy Installer

Важно! Миграция по Easy Installer поддерживается для Lifecycle Manager 1.3 и свежее. Если используются инстансы более старых версий, вначале их нужно проапгрейдить до 1.3.

Важно! Пароли должны содержать, минимум, одну цифру, одну большую букву, одну маленькую букву, один спецсимвол (!@#$%^&). Длина пароля от 8 до 16 знаков.

Базовая начальная настройка vRA

Настройка vRA Cloud Assembly

Использование Quickstart в начальной настройке vRA Cloud Assembly

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

Использование Guided Setup в начальной настройке vRA Cloud Assembly

Настройка vRA Service Broker

Важно! Разворот всегда должен быть либо одиночной машиной, либо приложением.

Базовые операции с vRA Code Stream

Что нужно сделать после инсталляции vRA?

Добавление и импорт лицензий, сертификатов и смена дефолтных паролей

Важно! Если сертификат истекает менее, чем через 15 дней, его нельзя импортировать.