VK Private Cloud logo
Помощь
Обновлена 17 июля 2026 г. в 15:55

Балансировка нагрузки

В Платформе предусмотрены следующие виды балансировки:

  1. Балансировка на уровне администраторов Платформы:

  2. Балансировка на уровне администраторов проектов:

    • Octavia balancer — распределяет задания/трафик между несколькими сетевыми устройствами (например, серверами) с целью оптимизации использования ресурсов, сокращения времени обслуживания запросов, горизонтального масштабирования кластера (динамическое добавление/удаление устройств), обеспечения отказоустойчивости (подробнее — в разделе Балансировщики нагрузки).

Управление метаданными агрегата

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

Чтобы просмотреть список метаданных агрегата:

  1. Перейдите в раздел Администрирование → Агрегаты узлов.
  2. Нажмите на значок слева от поля поиска и выберите вариант Реальные данные (по умолчанию показаны Кешированные данные).
  3. Нажмите на значок ••• справа от названия агрегата и выберите пункт Обновление метаданных.

Чтобы добавить новые или редактировать существующие метаданные агрегата:

  1. Откройте список метаданных агрегата (описание процесса приведено в предыдущей инструкции).
  2. Нажмите кнопку Редактировать.
  3. Добавьте метаданные из области слева или укажите пользовательские метаданные в формате Имя-Значение в одноимённых полях.
  4. Нажмите кнопку Сохранить изменения.

Дальнейшая балансировка будет выполняться в соответствии с указанными метаданными для агрегата.

Миграция ресурсов гипервизоров

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

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

  • Портал администратора.
  • OpenStack CLI.

Портал администратора

Чтобы выполнить миграцию ресурсов гипервизоров в Портале администратора:

  1. Перейдите в раздел Администрирование → Вычислительные узлы.

  2. Выберите один или несколько гипервизоров, которые будут участвовать в миграции, отметив флажок в списке. Степень их загруженности отображается в столбцах cpu_idle (остаток свободного CPU в процентах к сумме ядер) и free_mem (остаток свободного ОЗУ в МБ).

  3. Нажмите кнопку Мигрировать над таблицей. Задайте параметры:

    • Использование процессора — целевая процентная нагрузка по CPU после выполнения миграции. Например, значение 0.5 означает загрузку на 50% по CPU (пояснения приведены ниже).

    • Использование памяти — целевой объём ОЗУ в МБ после выполнения миграции. Учитывается максимальный объём, указанный в шаблоне ВМ.

    • Ограничение количества ВМ для миграции — максимальное количество ВМ для миграции.

    • Название зоны для живой миграции — название зоны доступности (AZ), в рамках которой выполняется миграция. Используется в случае наличия на нескольких гипервизорах нескольких AZ.

    • Название агрегата для живой миграции — название агрегата узлов, в рамках которого будет выполняться миграция. Это позволит ограничить список миграций только ВМ определённых агрегатов и не затронуть остальные.

    • Включить VIP-проекты — опция включения VIP-проектов. ВМ, помеченные как VIP, не будут участвовать в расчётах и останутся на текущем вычислительном узле. Включение опции вызовет большее количество миграций обычных (не VIP) ВМ. VIP ВМ будут рассчитываться в качестве кандидатов наравне с другими ВМ.

    • Игнорировать отключенные гипервизоры — позволять использовать отключенные вычислительные узлы в качестве кандидатов для миграции. Отключенные вычислительные узлы будут рассматриваться как потенциальные кандидаты для миграции наравне с включёнными.

  4. Нажмите кнопку Следующий шаг.

  5. Выберите ВМ, подходящие для выполнения миграции. Если найденные ВМ не подходят для миграции, нажмите кнопку Предыдущий шаг и измените параметры поиска.

  6. При необходимости укажите хост назначения:

    1. Нажмите кнопку Хост назначения: отключено.
    2. Включите переключатель Включен.
    3. В поле Хост назначения укажите целевой хост, куда будет выполнена миграция.
    4. Нажмите кнопку Применить.

  7. Выберите одну или несколько ВМ, которые будут отправлены на миграцию.

  8. Нажмите кнопку Завершить.

После запуска процесса миграции отследить его ход можно в разделе Облачные вычисления → Экземпляры ВМ при выборе типа данных Реальные данные. История миграции ВМ доступна в разделе Администрирование → Миграции.

OpenStack CLI

В отличие от миграции с помощью Портала администратора, миграция с использованием OpenStack CLI не имеет количественных параметров и предназначена для миграции всех инстансов с целевого гипервизора.

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

$ nova host-servers-migrate <HOST>

Здесь <HOST> — название целевого гипервизора, откуда будет осуществлена полная миграции.

Управление нагрузкой с помощью правил планировщика (sheduler)

Настройки правил планировщика находятся на управляющем узле в конфигурационном файле Nova (nova.conf). Чтобы изменить правила размещения ВМ на агрегатах:

  1. Выполните подготовительные операции (подробнее — в разделе Вход для Администратора Платформы).

  2. Найдите параметр scheduler_available_filters в конфигурационном файле nova.conf.

  3. Добавьте/удалите фильтры (полный список фильтров приведён в документации Compute schedulers OpenStack).

  4. Сохраните файл и перезагрузите сервис openstack-nova-scheduler на всех управляющих узлах:

    # systemctl restart openstack-nova-scheduler

Политики affinity и anti-affinity для размещения ВМ

Правила размещения ВМ на узлах кластера может настраиваться политиками, в частности, с политикой affinity ВМ будут создаваться только на одном узле, а с anti-affinity — только на разных (или с максимальным распределением по узлам, если создаваемых ВМ больше, чем узлов). Далее приведён пример добавления политик affinity и anti-affinity.

Чтобы добавить политики affinity и anti-affinity:

  1. Выполните подготовительные операции (подробнее — в разделе Вход для Администратора Платформы).

  2. Создайте группы серверов с политиками affinity и anti-affinity, выполнив команды:

    # openstack --insecure server group create --policy anti-affinity anti-affinity-group# openstack --insecure server group create --policy affinity affinity-group

  3. Отобразите список созданных групп:

    # openstack --insecure server group list
    Пример отображения информации о группах серверов
    +--------------------------------------+---------------------+---------------+| ID                                   | Name                | Policies      |+--------------------------------------+---------------------+---------------+| ae7a655b-4b18-425b-82cb-415930669d7b | anti-affinity-group | anti-affinity || bd5a029e-1fb2-4133-b019-a52eed372fcb | affinity-group      | affinity      |+--------------------------------------+---------------------+---------------+

Чтобы убедиться в корректности работы политик, одновременно создайте несколько ВМ, указав для них политики affinity и anti-affinity:

# for i in 1 2 3;do openstack --insecure server create --image <НАЗВАНИЕ_ОБРАЗА> --flavor Basic-1-1 --hint group=<ID_ГРУППЫ_СО_СВОЙСТВОМ_AFFINITY> --nic net-id=<ID_СЕТИ> vm-affinity-$i;done# for i in 1 2;do openstack --insecure server create --image <НАЗВАНИЕ_ОБРАЗА> --flavor Basic-1-1 --hint group=<ID_ГРУППЫ_СО_СВОЙСТВОМ_ANTI-AFFINITY> --nic net-id=<ID_СЕТИ> vm-anti-affinity-$i;done

ВМ будут размещены в соответствии с применённой политикой.

Была ли статья полезна?