Развёртывание и настройка oVirt 4.0. Часть 7. Расширение кластера и балансировка нагрузки

imageВ этой части для демонстрации возможностей масштабирования oVirt 4.0 мы рассмотрим пример ещё одного варианта добавления нового хоста в кластер oVirt в конфигурации Hosted Engine с последующей настройкой простейшего варианта балансировки нагрузки между хостами виртуализации в кластере с помощью функционала Scheduling Policy.

Добавление в кластер дополнительных хостов

Ранее мы рассматривали процедуру добавления дополнительных хостов в конфигурации Hosted Engine с помощью команды hosted-engine —deploy. В этой части мы рассмотрим альтернативный вариант добавления новых хостов, доступный в oVirt 4.0, — вариант с применением веб-консоли портала администрирования oVirt.

Учитывая то обстоятельство, что новый хост виртуализации будет добавляться в уже действующий кластер oVirt, на этапе подготовки хоста необходимо настроить его конфигурацию, в частности, в части в подключения к SAN, по аналогии с настройками уже действующих хостов кластера, чтобы в последствии у нас не возникло проблем при развёртывании нового хоста Hosted Engine в консоли oVirt. Перед началом развёртывания обязательно выполним предварительную подготовку хоста (см.пункт «Подготовка хостов к развёртыванию oVirt Hosted Engine» в первой части серии). После того, как хост готов, добавляем на хост репозитории, которые потребуются для развёртывания oVirt

# yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm
# yum -y install epel-release

После этого перейдём в веб-консоль портала администрирования oVirt и на вкладке Hosts воспользуемся кнопкой New

В открывшейся веб-форме добавления нового хоста на вкладке General зададим имя хоста, его адрес и пароль root-пользователя на подключаемом хосте:

На вкладке Power Management включим и настроим Fencing-агента по аналогии с уже описанной ранее процедурой:

Параметры остальных вкладок в большинстве случаев можно оставить со значениями по умолчанию. В нашем случае на вкладке Hosted Engine дополнительно включено развёртывание на добавляемом хосте компонент для обслуживания виртуальной машины Hosted Engine – Deploy 

Когда все параметры заданы, внизу формы добавления хоста жмём OK и дожидаемся когда управляющий код oVirt выполнит все процедуры по подключению и настройке хоста.

Если в процессе установки что-то пошло не так и процесс завершился ошибкой, то после исправления проблемы можно вызвать процедуру повторной установки выбрав пункт контекстного меню или кнопку Reinstall

В форме повторного развёртывания потребуется повторно указать пароль пользователя root с подключаемого хоста, а также при необходимости на вкладке Hosted Engine выбрать опцию Deploy 

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

# yum install ovirt-hosted-engine-setup

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

В процессе добавления хоста будет настроен Fencing-агент, произведён обмен ключами SSH, и запущена процедура развёртывания…

В процессе будут загружены и установлены все необходимые для функционирования хоста Hosted Engine пакеты.

Если ранее в вашей инфраструктуре oVirt были настроены логические сети, то по завершению добавления хоста, этот хост может перейти в состояние Non Operational. Это может быть связано с тем, что хост пока ещё не настроен на привязку к логическим сетям кластера с признаком Required, то есть тем сетям, которые должны присутствовать на каждом хосте кластера. Собственно информацию об этом мы сможем увидеть в области сообщений: 

Таким образом, всё что нам остаётся сделать, это настроить привязку логических сетей к новому хосту, а затем активировать хост кнопкой Activate

Хост изменит своё состояние на Up и будет готов к работе.

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

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

 

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

По мере увеличения количества хостов и виртуальных машин в кластере oVirt, может возникнуть вопрос о том, как можно автоматизировать процесс распределения ВМ по хостам внутри кластера. Для этого в oVirt 4.0 существует встроенный механизм, так называемых, политик планирования — Scheduling Policy . Политики планирования — это предопределённый набор настраиваемых параметров, используемый для механизма балансировки нагрузки между хостами виртуализации в кластере oVirt. Выбрать ту или иную преднастроенную политику можно в свойствах кластера на одноимённой вкладке. По умолчанию кластер не имеет привязки к политике планирования.

Как я понял из статьи Smart VM Scheduling in oVirt Clusters, механизм балансировки базируется на принципе расчёта очков исходя из параметров, заданных в той или иной политике планирования. На текущий момент в UI oVirt можно обнаружить несколько уже сконфигурированных политик планирования, каждая из которых имеет свой набор параметров

Информацию о том, какая политика планирования на что нацелена можно подчерпнуть, например, в документах oVirt Administration Guide и  oVirt Scheduler Policies, в частности из ряда созданных по умолчанию политик:

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

Создать собственную политику можно, выбрав пункт Configure в верхнем правом углу портала администрирования oVirt и перейдя во вкладку Scheduling Policies

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

Сохраним политику и перейдём в свойства кластера, чтобы выполнить привязку созданной политики планирования к кластеру:

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

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

И уже после того, как политика планирования вступила в действие, виртуальные машины с первого нагруженного хоста автоматически «растеклись» по разным хостам:

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

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

Дополнительные источники информации:

Только один комментарий Комментировать

  1. AlektroNik /

    Плюс Optaplanner (ovirt-optimizer) поддерживает только oVirt 3.6. ) Хотя вещь полезная, особенно когда отлаживаешь и тестируешь политики.

Добавить комментарий