Как повысить отказоустойчивость сервисов в кластере виртуализации с помощью оптимизации их распределения

Суть проблемы

Кластер виртуализации содержит множество гипервизоров. На каждом гипервизоре разворачивается множество виртуальных машин. Каждая машина, как правило, отвечает за работу одного сервиса.

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

Далее под распределением сервисов предлагается понимать распределение виртуальных машин, на которых запущены части одного сервиса.

Гиперболизированный пример: если один уникальный сервис распределён абсолютно равномерно по 10 машининам на 10 гипервизорах, то при выходе одного гипервизора из строя откажет 1/10 часть и сервис скорее всего продолжит свою работу; В случае когда 10 машин работают на одном гипервизоре, то отказ этого гипервизора приведёт к полному отказу сервиса.

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

Исходные данные

В качестве исходных данных есть информация об одном реальном кластере, которая содержит:

1. Список всех гипервизоров (~42 шт.) с указанием их ресурсов (cpu, ram, storage);

2. Список всех виртуальных машин (~3900 шт.) с указанием их ресурсов (cpu, ram, storage). Для каждой машины указано имя соответствующего сервиса;

3. Сопоставление (mapping) каждой виртуальной машины своему гипервизору.

А есть ли вообще проблема?

Для анализа распределения была выбрана метрика концентрации сервиса. Возможные значения концентрации лежат в диапазоне от 0 до 1. Чем меньше значение концентрации, тем лучше. Для корректного сравнения концентраций сервисов между собой применялась нормализация.

По условной классификации были выделены следующие группы сервисов с соответствующими диапазонами значений нормализованных концентраций.

Было принято, что проблемными сервисами являются распределенные сервисы категорий medium, high и critical. Доля проблемных сервисов составляет около 12%. Если добавить к категориям проблемных сервисов категорию low, то доля таких сервисов возрастёт до 29%.

Эти значения показывают масштаб проблемы и потенциал оптимизации распределения. Целевым состоянием можно считать распределение, при котором все сервисы находятся в категориях best и good. Как будет показано далее, это состояние достижимо.

Цель

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

Ограничения

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

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

• Бюджет на перемещения ограничен. Он расходуется только на перемещение существующих виртуальных машин. Добавление новых машин не расходует бюджет.

Какие задачи потребовалось решить

Для достижения цели потребовалось решить несколько взаимосвязанных задач:

1. Разработать ресурсную модель, чтобы алгоритм мог оценивать валидность и оптимальность использования ресурсов при перемещении виртуальных машин;

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

3. Разработать алгоритм балансировки, который последовательно улучшает метрики отказоустойчивости с учётом ресурсной модели для заданного кластера;

4. Обеспечить качество модификации кода решения для настройки, масштабирования и кастомизации решения.

Выбор метрик

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

Метрики отказоустойчивости

Все четыре метрики отказоустойчивости принимают участие в процессе улучшения распределения машин по гипервизорам. Алгоритм завершает работу когда ни одна из этих метрик не показывает улучшения.

Средняя Концентрация (avg concentration)

Средняя Концентрация оценивает степень сосредоточения виртуальных машин всех сервисов на соответствующих гипервизорах в кластере. Помимо средней концентрации фиксировались значения метрики худшей концентрации. Худшей концентрацией обладает сервис с максимальной концентрацией в кластере. Меньшие значения — лучшее распределение.

Оценка заполнения (fill-gap score)

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

Информационная энтропия (entropy)

Информационная энтропия даёт численную оценку единообразия и разнообразия распределения сервиса по гипервизорам. Более высокие значения энтропии отражают лучшее разнообразие и сбалансированное распределение сервиса в кластере.

Средний Разброс (avg spread)

Значение разброса сервиса по сути противоположно концентрации сервиса и оценивает широту охвата гипервизоров кластера конкретным сервисом. Средний разброс оценивает совокупный разброс всех сервисов в кластере. Большее значение означает лучшее распределение.

Метрики ресурсов

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

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

Стоимость перемещения

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

Стоимость гипервизора

Стоимость гипервизора оценивает эффективность использования ресурсов на гипервизоре. Используется для вычисления общей стоимости кластера и выбора оптимального размещения виртуальных машин. Увеличение стоимости гипервизора является следствием перераспределения нагрузки по ресурсам, направленного на повышение отказоустойчивости. При наличии достаточного запаса по ресурсам такой рост не критичен.

Стоимость кластера

Стоимость кластера вычисляется как сумма стоимостей всех гипервизоров.

Результат и эффективность работы

Для доказательства эффективности работы решения предлагается сравнить два сценария работы алгоритма:

1. Распределения «с нуля» виртуальных машин кластера по пустым гипервизорам. Берутся все исходные данные за исключением сопоставления «машина-гипервизор».

2. Оптимизация «как есть» когда машины распределены по гипервизорам кластера согласно реальным данным. Берутся все исходные данные.

Согласно рабочей гипотезе распределение «с нуля» приведёт к глобальному оптимуму. А оптимизация «как есть» приведёт к локальному оптимуму.

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

Значение метрики худшей концентрации в обоих случаях находятся в диапазоне от 0.0 до 0.1. Таким образом после обоих сценариев все сервисы кластера находятся в категориях good и best.

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

Демонстрация

Для иллюстрации работы алгоритма рассмотрен сложный тестовый сценарий.

Формат запроса (request) содержит бюджет на перемещение, объект кластера (машины, гипервизоры и их сопоставление), идентификаторы выводимых из эксплуатации гипервизоров и перечень машин, которые необходимо добавить в кластер.

===== request:move budget: 9999999.9cluster: hvs: 4 vms: 6hvs to remove (1):hv_id_90W9D_YP3vms to add (3):id: vm_id_XV1PF_ZJB; cpu_cores: 1.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_Aid: vm_id_5H06J_8XQ; cpu_cores: 1.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_Aid: vm_id_KAAV2_7XL; cpu_cores: 1.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_A

Состояние кластера до оптимизации приведено ниже. Сервисы «C» и «B» распределены неравномерно.

===== cluster before:hvs (4):id: hv_id_MPVRJ_B2Z; cpu_cores: 12.0; memory: 32.0 GiB; storage: 1000.0 GiB; vms_count: 0hv vms: noneid: hv_id_MQ7CN_XJI; cpu_cores: 12.0; memory: 48.0 GiB; storage: 1000.0 GiB; vms_count: 3hv vms (3):id: vm_id_RSPUO_YY2; cpu_cores: 4.0; memory: 16.0 GiB; storage: 1.0 GiB; service: service_Cid: vm_id_8P56T_G5D; cpu_cores: 4.0; memory: 16.0 GiB; storage: 1.0 GiB; service: service_Cid: vm_id_5980J_RGB; cpu_cores: 4.0; memory: 16.0 GiB; storage: 1.0 GiB; service: service_Cid: hv_id_CHAC4_E53; cpu_cores: 12.0; memory: 32.0 GiB; storage: 1000.0 GiB; vms_count: 0hv vms: noneid: hv_id_90W9D_YP3; cpu_cores: 12.0; memory: 32.0 GiB; storage: 1000.0 GiB; vms_count: 3hv vms (3):id: vm_id_KUACL_5HK; cpu_cores: 2.0; memory: 6.0 GiB; storage: 50.0 GiB; service: service_Bid: vm_id_RGT5F_ZEV; cpu_cores: 3.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_Bid: vm_id_I14P4_U2W; cpu_cores: 3.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_B

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

После этих шагов этап распределения считается завершённым, в логе фиксируются метрики кластера.

===== rebalancer log:12:04:07,341 | INFO | Hypervisors had 0 virtual machines which caused overload12:04:07,345 | INFO | Rebalance: Validating budget 316.2812:04:07,347 | INFO | Rebalance: Removing 1 hypervisors12:04:07,350 | INFO | Removed hypervisor: hv_id_90W9D_YP312:04:07,351 | INFO | Removed hypervisors had 3 virtual machines12:04:07,352 | INFO | Rebalance: Restoring validity for 3 virtual machines12:04:07,356 | INFO | Allocation step 01: vm_id_I14P4_U2W -> hv_id_CHAC4_E5312:04:07,359 | INFO | Allocation step 02: vm_id_RGT5F_ZEV -> hv_id_MPVRJ_B2Z12:04:07,362 | INFO | Allocation step 03: vm_id_KUACL_5HK -> hv_id_CHAC4_E5312:04:07,363 | INFO | Rebalance: Allocating 3 new virtual machines12:04:07,365 | INFO | Allocation step 01: vm_id_KAAV2_7XL -> hv_id_MPVRJ_B2Z12:04:07,369 | INFO | Allocation step 02: vm_id_5H06J_8XQ -> hv_id_CHAC4_E5312:04:07,371 | INFO | Allocation step 03: vm_id_XV1PF_ZJB -> hv_id_CHAC4_E5312:04:07,372 | INFO | Cluster metrics after allocation: cost: 1.274279; entropy: 1.386294;fgs: 0.305778; avg spread: 0.555556; avg concentration: 0.666667; worst spread: 0.333333;worst concentration: 1.000000; validity: True

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

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

12:04:07,373 | INFO | Rebalance: Optimizing allocation for 9999683.62 remaining budget12:04:07,374 | INFO | Optimization step 001 cluster metrics: cost: 1.274279; entropy:1.386294; fgs: 0.305778; avg spread: 0.555556; avg concentration: 0.666667; worst spread:0.333333; worst concentration: 1.000000; validity: True12:04:07,382 | INFO | Choice (1): vm_id_RSPUO_YY2 -> hv_id_MPVRJ_B2Z;12:04:07,384 | INFO | Optimization step 002 cluster metrics: cost: 1.336449; entropy:1.791759; fgs: 0.211259; avg spread: 0.666667; avg concentration: 0.500000; worst spread:0.666667; worst concentration: 0.500000; validity: True12:04:07,391 | INFO | Choice (1): vm_id_5H06J_8XQ -> hv_id_MQ7CN_XJI;12:04:07,393 | INFO | Optimization step 003 cluster metrics: cost: 1.291305; entropy:2.371641; fgs: 0.130667; avg spread: 0.777778; avg concentration: 0.333333; worst spread:0.666667; worst concentration: 0.500000; validity: True12:04:07,400 | INFO | Choice (1): vm_id_I14P4_U2W -> hv_id_MQ7CN_XJI;12:04:07,402 | INFO | Optimization step 004 cluster metrics: cost: 1.275858; entropy:2.831480; fgs: 0.065778; avg spread: 0.888889; avg concentration: 0.166667; worst spread:0.666667; worst concentration: 0.500000; validity: True12:04:07,410 | INFO | Choice (1): vm_id_8P56T_G5D -> hv_id_CHAC4_E53;12:04:07,412 | INFO | Optimization step 005 cluster metrics: cost: 1.336401; entropy:3.295837; fgs: 0.000000; avg spread: 1.000000; avg concentration: 0.000000; worst spread:1.000000; worst concentration: 0.000000; validity: True12:04:07,420 | INFO | Denied: vm_id_KUACL_5HK -> hv_id_MQ7CN_XJI;12:04:07,421 | INFO | Optimization stop on step 005: Not improve service metrics12:04:07,422 | INFO | Remaining budget is 9999048.2212:04:07,423 | INFO | Cluster metrics after optimization: cost: 1.336401; entropy: 3.295837;fgs: 0.000000; avg spread: 1.000000; avg concentration: 0.000000; worst spread: 1.000000;worst concentration: 0.000000; validity: True

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

===== cluster after:hvs (3):id: hv_id_MPVRJ_B2Z; cpu_cores: 12.0; memory: 32.0 GiB; storage: 1000.0 GiB; vms_count: 3hv vms (3):id: vm_id_KAAV2_7XL; cpu_cores: 1.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_Aid: vm_id_RGT5F_ZEV; cpu_cores: 3.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_Bid: vm_id_RSPUO_YY2; cpu_cores: 4.0; memory: 16.0 GiB; storage: 1.0 GiB; service: service_Cid: hv_id_MQ7CN_XJI; cpu_cores: 12.0; memory: 48.0 GiB; storage: 1000.0 GiB; vms_count: 3hv vms (3):id: vm_id_5H06J_8XQ; cpu_cores: 1.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_Aid: vm_id_I14P4_U2W; cpu_cores: 3.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_Bid: vm_id_5980J_RGB; cpu_cores: 4.0; memory: 16.0 GiB; storage: 1.0 GiB; service: service_Cid: hv_id_CHAC4_E53; cpu_cores: 12.0; memory: 32.0 GiB; storage: 1000.0 GiB; vms_count: 3hv vms (3):id: vm_id_XV1PF_ZJB; cpu_cores: 1.0; memory: 8.0 GiB; storage: 1.0 GiB; service: service_Aid: vm_id_KUACL_5HK; cpu_cores: 2.0; memory: 6.0 GiB; storage: 50.0 GiB; service: service_Bid: vm_id_8P56T_G5D; cpu_cores: 4.0; memory: 16.0 GiB; storage: 1.0 GiB; service: service_C

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

В случае возникновения ошибок ответ будет содержать соответствующую информацию.

===== response:old cluster cost: 0.9366605494387001new cluster cost: 1.3364009891398139cost change: 42.7%move cost: 951.68actions (10):vm_id: vm_id_I14P4_U2W; hv_id: hv_id_CHAC4_E53vm_id: vm_id_RGT5F_ZEV; hv_id: hv_id_MPVRJ_B2Zvm_id: vm_id_KUACL_5HK; hv_id: hv_id_CHAC4_E53vm_id: vm_id_KAAV2_7XL; hv_id: hv_id_MPVRJ_B2Zvm_id: vm_id_5H06J_8XQ; hv_id: hv_id_CHAC4_E53vm_id: vm_id_XV1PF_ZJB; hv_id: hv_id_CHAC4_E53vm_id: vm_id_RSPUO_YY2; hv_id: hv_id_MPVRJ_B2Zvm_id: vm_id_5H06J_8XQ; hv_id: hv_id_MQ7CN_XJIvm_id: vm_id_I14P4_U2W; hv_id: hv_id_MQ7CN_XJIvm_id: vm_id_8P56T_G5D; hv_id: hv_id_CHAC4_E53===== error:text: No errors. Remaining budget is 9999048.22

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

Время работы оптимизации

Достаточно долгое время обработки первого запроса обусловлено неоптимальным начальным состоянием кластера. Время каждого шага оптимизации зависит от размера кластера и для приведённых выше исходных данных составляет около 25 секунд. Если принять число машин по типовой заявке равной 10, то время получения ответа займёт менее 5 минут.

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

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

Решение и способы его интеграции

Решение представляет собой программный модуль на Python, который возможно добавить в кодовую базу существующей системы виртуализации непосредственно. В случае, если такое не представляется возможным, то лучшим решением будет изоляция кода в контейнере и интеграция с системой виртуализации посредством API.

Для стабильной работы решения как микросервиса для одного кластера достаточно одного ядра ЦП и 4 Гб оперативной памяти. Данные между запросами не кэшируются и не сохраняются, поэтому требуемый объём хранилища не превышает 10–20 ГБ.

Масштабирование

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

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

Краткий итог

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

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

Вопросы и комментарии приветствуются!