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 (см. пояснения ниже).

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

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

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

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

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

  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-groupopenstack --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;donefor 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

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

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