Овербукинг и неравномерная нагрузка: как KeyVRM выполняет балансировку ВМ между гипервизорами

Почему в облаке используют овербукинг

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

Овербукинг позволяет плотнее размещать виртуальные машины и повышать использование оборудования. При этом переподписка сама по себе не означает перегрузку: неприятности возникают, когда фактическое потребление нескольких ВМ одновременно возрастает и нагрузка концентрируется на одном гипервизоре.

KeyVRM не управляет коэффициентом овербукинга и не изменяет объём ресурсов, выделенных ВМ. При превышении настроенного порога перегрузки гипервизора алгоритм режима LB ищет возможность перенести часть нагрузки на менее загруженные гипервизоры с помощью живой миграции.

Почему ручная балансировка усложняется с ростом инфраструктуры

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

При этом каждая запланированная миграция меняет расчётное состояние инфраструктуры. Например, гипервизор, который до первой миграции имел достаточный запас по CPU и RAM, после переноса одной или нескольких ВМ может приблизиться к допустимому пределу нагрузки. Если при выборе следующей цели не учитывать уже запланированные перемещения, несколько ВМ можно последовательно направить на один и тот же гипервизор, превысив тем самым установленный порог нагрузки. Или переносить виртуальные машины по кругу бесконечно, что так же не выглядит эффективным решением.

Поэтому после каждого запланированного переноса KeyVRM пересчитывает ожидаемое состояние хост-агрегата. Следующая рекомендация формируется уже с учётом ранее запланированных миграций.

Как KeyVRM оценивает нагрузку и выявляет перегруженные гипервизоры

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

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

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

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

Как KeyVRM выбирает ВМ и целевой гипервизор

Если гипервизор признан перегруженным, KeyVRM определяет, какие размещённые на нём ВМ можно перенести, и ищет для них подходящие целевые гипервизоры. При этом недостаточно выбрать гипервизор с более низкой текущей нагрузкой: после миграции он должен оставаться в пределах допустимой нагрузки и располагать ресурсами, необходимыми для размещения ВМ.

При выборе целевого гипервизора KeyVRM проверяет доступные vCPU, RAM и дисковую ёмкость, а также применяет настроенные ограничения размещения. При включённых соответствующих фильтрах KeyVRM учитывает политики affinity и anti-affinity, заданные для серверных групп OpenStack. Они определяют, должны ли связанные ВМ размещаться совместно или, наоборот, на разных гипервизорах.

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

Если подходящий целевой гипервизор найден, KeyVRM формирует рекомендацию на живую миграцию. Если допустимой цели нет, рекомендация для такой миграции не создаётся.

Как запускается балансировка: автоматически или после подтверждения

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

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

Такой подход позволяет либо полностью автоматизировать балансировку, либо оставить запуск миграций под контролем администратора. При этом для режима HA действует другой порядок: после подтверждения отказа и успешной изоляции гипервизора отдельное подтверждение администратора для эвакуации ВМ не требуется.

Как KeyVRM совмещает режимы HA и LB

В режиме HA+LB аварийное восстановление и балансировка не выполняются одновременно в рамках одного цикла. Сначала KeyVRM проверяет, требуется ли аварийное восстановление. Если по результатам этой проверки сформированы рекомендации на эвакуацию ВМ, алгоритм режима LB в этом цикле не запускается.

К балансировке KeyVRM переходит только при отсутствии рекомендаций режима HA и с учётом настроенной периодичности режима LB. Такой порядок даёт аварийному восстановлению приоритет перед оптимизацией нагрузки.

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

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

Ошибки живой миграции обрабатывает тот же компонент Executor, который используется для эвакуации ВМ в режиме HA: KeyVRM фиксирует сбой, выполняет предусмотренные восстановительные действия и повторяет рекомендацию в пределах заданных лимитов. Подробнее этот процесс разобран в первой статье о HA-режиме KeyVRM.

В режиме HA+LB аварийное восстановление имеет приоритет перед балансировкой. После каждой рекомендации на миграцию KeyVRM пересчитывает ожидаемое состояние хост-агрегата
Источник: ITKey

Что показывает результат работы режима LB

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

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

Автор: Денис Векслер, архитектор ITKey