vRA: управление ресурсами | "Всё, что нажито..."

Управление ресурсами в vRealize Automation может показаться сложным и недостаточно гибким. Однако, если не спеша и последовательно разобраться, то всё сделано просто и вполне логично. Мы рассмотрим работу с ресурсами на платформе виртуализации VMware vSphere (как самый распространённый случай при внедрении vRA), для адаптации материала к другим платформам обратитесь к документации, если отличия и будут, то незначительные.

Основные понятия

Для начала определимся с основными терминами, которые используются в vRA при работе с ресурсами:
Fabric Groups. Группы устройств – являются обязательной частью vRA. Используются для разделения прав администраторов или просто для разграничения вычислительных ресурсов, например, по типу нагрузки:

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

Compute Resources. Вычислительными ресурсами являются хосты или кластеры (для vSphere) на которых будут создаваться виртуальные машины. Один и тот же вычислительный ресурс может одновременно входить в несколько Fabric Groups.
Reservations. Резервирование (бронь) – выделенная для определенной бизнес-группы доля ресурсов на заданном вычислительном ресурсе. Резервирование задаёт объём доступной памяти и ресурсов хранения, количество виртуальных машин, разрешенные к использованию сети. Для создания виртуальных машин бизнес-группе нужно предоставить хотя бы одно резервирование. Каждое резервирование принадлежит только одной конкретной бизнес-группе, но любой бизнес-группе можно назначить несколько резервирований.
Reservation Policy. Политики резервирования позволяют ограничить размещение создаваемых машин определенным списком резервирований. Упрощенно политику резервирования можно представить как набор доступных для использования резервирований.
Storage Reservation Policy. Политика резервирования для управления размещением дисков виртуальных машин по разным хранилищам.

Сценарии выделения ресурсов

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

Сокращения:

BP_n – Blueprint;
RP_n – Reservation Policy;
R_n – Reservation;
BG_n – Business Group;
U_n – User.

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

	BP₁	BP₂	BP₃	BP₄
U₁	R₁	R₁	R₄	R₁/R₂/R₄
U₂	R₁ или R₃	R₁ или R₃	R₄	R₁/R₂/R₄ или R₃
U₃	R₃	R₃	X	R₃

Вот некоторые из возможных сценариев работы:

Пользователь 1 (U₁) делает запрос на BP₁: размещение BP₁ ограничено при помощи политики RP₁, которая используется в Резервированиях 1 и 3 (R₁ и R₃). Поскольку пользователь входит только в BG₁, то новая виртуальная машина будет однозначно размещена в R₁;

Пользователь 2 (U₂) делает запрос на BP₂: размещение BP₂ также ограничено политикой RP₁: R₁ и R₃. Размещение виртуальной машины определится по бизнес-группе, от которой U₂ отправит запрос: если будет использована BG₁, то на R₁, если будет использована BG₂, то на R₃;

Пользователь 3 (U₃) делает запрос на BP₃: размещение BP₃ ограничено политикой RP₂, но у бизнес-группы BG₂ нет ни одного резервирования с данной политикой. Запрос завершится с ошибкой: Error requesting machine. No reservation is available to allocate within the group BG2. Total 35 GB of storage was requested. Selected reservation policy was [RP2].

Пользователь 3 (U₃) делает запрос на BP₄ (его размещение не ограничено политиками резервирования). Пользователю U₃ (группа BG₂) доступно только резервирование R₃ в нём и будут выделены необходимые ресурсы.

Пользователь 1 (U₁) делает запрос на BP₄ (его размещение не ограничено политикой резервирования). Пользователю U₁ (группа BG₁) доступны три резервирования: R₁, R₂ и R₄; выбор резервирования будет определяться по установленным приоритетам (см. ниже Приоритеты).

Пользователь делает запрос, но в доступных ему резервированиях недостаточно ресурсов. Такой запрос завершится с ошибкой: Error requesting machine. No reservation is available to allocate within the group BG1. Total 150 GB of storage was requested. Selected reservation policy was [RP1].
- Примечание: Квота на виртуальные машины учитывает только включенные в данный момент машины. Например, если резервирование имеет квоту в 50 виртуальных машин и уже содержит 40 машин, их которых только 20 включены, то использованными считаются 40 процентов квоты, а не 80.

Приоритеты

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

Выбирается резервирование с самым высоким приоритетом (меньшее число в записи приоритета соответствует более высокому приоритету: приоритет 1 выше, чем приоритет 2).
Если несколько резервирований имеют одинаковый приоритет, будет выбрано то резервирование, у которого самый низкий процент использования квоты на виртуальные машины (Machine quota).
Если несколько резервирований имеют одинаковый приоритет и процент использования квот, то машины распределяются между ними по кругу.

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

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

Дополнительные настройки

Storage Reservation Policy. Иногда требуется разместить некоторые диски виртуальных машин отдельно от других дисков на выделенных хранилищах: swap (скорость доступа), лог-файлы (доступный объём, цена гигабайта на СХД), данные приложений (резервирование, защита). В vRA данная возможность реализуется при помощи Storage Reservation Policy. Политики резервирования хранилищ создаются там же, где и обычные политики резервирования. С конечными хранилищами эти политики связываются в настройках Compute Resources, и каждую политику можно применить к нескольком хранилищам одновременно. После этого можно указывать политики в настройках дисков в редакторе блюпринтов или при добавлении дисков к уже имеющимся виртуальным машинам (reconfigure). Не забудьте выделить место на данных хранилищах при настройке резервирований. Если пользователь сделает запрос на виртуальную машину с заданной Storage Reservation Policy не диске, но без выделения ресурсов в резервировании, то такое развертывание завершится с ошибкой: Cannot allocate storage request with storage reservation policies SRP2 on reservation R1.

Формат дисков. Можно делать более “тонкую” настройку параметров размещения, задавая пользовательские свойства (Custom properties). Пользовательские свойства указываются на разных уровнях: блюпринты, бизнес-группы, резервирования… При задании пользовательских свойств для резервирований они применяются ко всем машинам, размещаемым на данном резервировании. Следующие два свойства задают формат дисков VM, их удобнее указывать на уровне резервирований:

VirtualMachine.Admin.ThinProvision. Определяет, будет ли использоваться тонкий формат дисков (Thin Provision). Чтобы использовать Thin Provision, задайте значение «True». Значение «False» заставит использовать стандартный формат дисков.
VirtualMachine.Admin.EagerZero. Если задано значение «True», это значит, что диски виртуальной машины будут создаваться в формате Eager Zero.

Политики размещения. Следующие свойства оказывают влияние на работу с хранилищами:

VirtualMachine.DiskN.StorageReservationPolicy. Позволяет указать политику резервирования хранилища, которую нужно использовать для диска N. В качестве значения указывается имя политики.
VirtualMachine.DiskN.StorageReservationPolicyMode. Это свойство Вы можете использовать для предотвращения сбоя при нехватке места в хранилище, заданном политикой резервирования хранилища. При нехватке места оно разрешает vRA выбирать другое хранилище, не указанное в политике. Принимает значения ‘NotExact’ (неточно) и ‘Exact’ (точно).
VirtualMachine.DiskN.Storage. Позволяет вручную задать хранилище данных, на котором должен быть размещен диск N, например DS01.

Полное описание всех доступных параметров и работы с ними: vrealize-automation-74-custom-properties.pdf

"Всё, что нажито…"

Leave a comment Отменить ответ