Политики

В левой части виджета отображена фильтрация политик:

• All policies – все типы политик.
• Imported policies – импортированные политики.
• Manual policies – политики, созданные вручную.
• Defaults – политики, созданные по умолчанию.

В этом разделе представлены политики, созданные вручную.

Политика создаётся с использованием либо правил слияния (merge rule), либо общих правил (common rule).

Для получения кросс-кластерных Move-рекомендаций необходимо создать политику с правилом слияния (Merge rule) для перемещения ВМ между разными кластерами в рамках одного таргета, если администратор системы уверен, что физических ограничений на такую миграцию между кластерами нет.

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

Чтобы создать политику, необходимо:

1. Заполнить имя политики

2. Добавить связанные группы (Linked groups) - целевые группы, на которые будет воздействовать политика. Выбрать можно несколько групп объектов, к ним применятся все правила, если они применимы.

Пример: Если правило предназначено для изменения свойств виртуальных машин, а в выбранной целевой группе находятся только тома (Volumes), то такое правило не будет применено, так как оно не соответствует типу объектов в группе.

3. Заполнить хотя бы одно правило.

Набор правил (Rules):

• Reconfigure - изменение размера объектов. В нем можно настроить варианты работы действий (None, disable, recommend, manual, automate)
• Move - в каком порядке применяются действия: (None, disable, recommend, manual, automate)
• Action rules - правила автоматизации действий

Типы действий:

• None - сброс назначения по умолчанию
• Disable - отключение создания
• Recommend - рекомендации, которые нежелательно выполнять автоматически через Octopus. Используется для критически важных системных компонентов, таких как служебные ВМ (например, vCenter в VMware). Это позволяет администратору самостоятельно оценить рекомендацию и выбрать подходящий момент для её выполнения, исключая риск случайного или несвоевременного изменения конфигурации
• Manual - рекомендации, выполняемые пользователем вручную
• Automate - рекомендации создаются и отправляются на выполнение автоматически

Правила размещения (Placement Rules)

1. Тип размещения (Placement Type):

• none - сброс назначения по умолчанию
• place - разместить объекты из целевой группы на явно указанные поставщики ресурсов
• do_not_place - запретить размещение объектов из целевой группы на явно указанные поставщики ресурсов
• affinity - размещать совместно объекты из целевой группы на одном из явно указанных поставщиков ресурсов
• anty_affinity - запретить совместное размещение объектов из целевой группы на одном из явно указанных поставщиков

2. Тип отношений (Relations Type) - ограничения на типы объектов в целевой группе и группе поставщиков, которые будут учитываться при создании Placement rules:

• none - сброс назначения по умолчанию
• volume on storage - учитывать только volume из целевой группы, а из группы поставщиков учитывать только storage
• Virtual Machine on Physical Machine - учитывать только VM из целевой группы, а из группы поставщиков учитывать только PM

Правила слияния (Merge rules)

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

• none - сброс назначения по умолчанию
• cluster - ослабляет ограничения по перемещению между группами поставщиков с разных кластеров

Правила действий (Actions rules)

Доступно два типа действий:

• Reconfigure
• Move

Настройки (Settings)

Система позволяет сконфигурировать целевую загрузку различных типов объектов с помощью настроек UTILIZATION.

Рассмотрим их работу на примере:

Допустим, у нас есть ВМ с ёмкостью памяти 1000 МБ, текущий уровень загрузки памяти ВМ - 900 МБ (90%). По умолчанию настройка VM_MEM_UTILIZATION установлена на 70%. Таким образом система считает, что ВМ перегружена по памяти.Влиять на абсолютную величину загрузки оперативной памяти невозможно, поэтому будет изменяться ее емкость (1000 МБ). Поскольку текущая загрузка неизменна, система рассчитывает новую ёмкость: 900/0.7 = 1285,7143 МБ, после округления - 1286 МБ. Таким образом будет сгенерирована рекомендация по увеличению памяти для ВМ с 1000 до 1286 МБ.

Расчеты, представленные выше - достаточно грубое приближение работы аналитической машины, дающее общее представление о значении свойств с суффиксом "UTILIZATION".

1. Хранилище (Storage):

• DATASTORE_LATENCY_CAPACITY - это показатель производительности хранилища данных, который отражает максимальную допустимую задержку операций ввода-вывода. Измеряется в миллисекундах.
• RAID_TYPE - определяет конкретный уровень RAID, который будет использоваться для работы с данными.
• DATASTORE_ACCESS_CAPACITY - это показатель производительности хранилища данных, который отражает максимальную пропускную способность чтения записей по операциям за единицу времени. Измеряется в мегабайтах в секунду.
• STORAGE_CAPACITY - максимальный размер хранилища, который вы хотите создать.

Eсли в окружении пользователя есть высокопроизводительные жесткие диски, у которых IOPS > 200_000, при этом низкий LATENCY, необходимо создать группы для этих storage и задать значения DATASTORE_ACCESS_CAPACITY и DATASTORE_LATENCY_CAPACITY соответствующих размеров, чтобы не возникало проблем с анализом и потерей move рекомендаций.

2. Виртуальная машина (Virtual Machine):

• Memory_min_mb - в поле прописываем значение, ниже которого опуститься нельзя
• VM_MEM_UTILIZATION - значение, которое не рекомендуется изменять без рекомендации тех. поддержки. Оно явно влияет на реконфиг и косвенно на move
• VM_CPU_UTILIZATION - значение, которое не рекомендуется изменять без рекомендации тех. поддержки
• Memory_step - число, на сколько изменять текущее значение емкости, до тех пор, пока оно не превысит рекомендуемое нашей аналитической машиной.
• CPU_step - число, на сколько изменять текущее значение емкости, до тех пор, пока оно не превысит рекомендуемое нашей аналитической машиной.

3. Физическая машина (Physical Machine) - они явно влияют на move

• PM_MEM_UTILIZATION - см. пример.
• PM_CPU_UTILIZATION - см. пример

4. Объём (Volume).

• Storage_amount_step - шаг изменения ёмкости вольюма до достижения рекомендуемого значения.

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

Вместо автоматического изменения конфигураций следует:

• Оставить все ресайзы в статусе RECOMMEND;
• Выполнять изменения вручную после анализа всех рекомендаций.

Импортирование политик, созданных на стороне VMware

На стороне VMware имеется функционал по созданию политик.

Для этого нужно выбрать кластер и в конфигурациях открыть вкладку 'VM/Host Rules'.

Прописываем имя и выбираем тип, где:

• Keep Virtual Machine together - AFFINITY
• Separate virtual machines - ANTI_AFFINITY
• Virtual machine to hosts - PLACE (Must run/Should run)
• Virtual machine to hosts - DO_NOT_PLACE (Must not run/Should not run)

Virtual machines to Virtual Machines - не импортируется, не имеет аналога в Octopus.

В нижней таблице выбираем VM, которые будут содержаться в этой группе. Есть возможность выбрать уже созданные группы.

К примеру, создадим политику с именем 'Test3', выберем тип 'Virtual machine to hosts' и группу 'OldPms'. На платформе Octopus она отобразится с типом DO_NOT_PLACE.

Созданные политики отображаются на платформе Octopus и имеют тип discovered, поэтому изменить и удалить их невозможно.

Настройка расписания политик

Имя расписания

Обязательное к заполнению поле.

Допустимо прописать в нем короткое понятное имя, описывающее политику. Имя должно быть уникальным в системе.

Start Day и Start Time

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

По умолчанию, система устанавливает:

• start day - дата сегодняшнего дня в формате ДД/ММ/ГГГГ
• start time - текущее время, в формате 24-часового времени по региональному стандарту + 1 минута

Дата и время являются настраиваемыми.

Недопустимо:

• Выбирать прошедшее время.

Finish Day и Finish Time

Это параметры, которые определяют последний день и время выполнения политики в расписании. Они указывают дату и время, после которых задача считается завершённой.

По умолчанию, система устанавливает:

• дата равна началу политики
• время увеличивается на 1 час, относительно старта.

Допустимо:

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

Недопустимо:

• Выбирать прошедший день и время.

Duration

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

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

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

Допустимо:

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

Примеры: 10 минут, 1 час, 2 дня.

Repeat

Необходим для определения повторяемости события.

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

• день
• неделя
• месяц

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

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

При выборе дня, следует указать количество (1-31), а также начало и окончание события по времени.

При выборе повтора недели, можно указать ее кратность (1-5). Поле является обязательным.По умолчанию система отмечает день, равный заданной даты начала и является настраиваемый. Выбор дней является обязательным.

При выборе месяца следует указать: каждый день (1-31) из каждых месяцев (1-12). Поля являются обязательными.Поля времени начала и окончания также являются обязательными. По умолчанию система дублирует заданные ранее параметры.

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