oVirt self-hosted engine workaround

В текущих версиях oVirt нет self-hosted engine (фича запланированна на v3.4), но можно сделать некое подобие, реализующие те же функции: ovirt-engine крутится в качестве виртуалки на тех же нодах, что предназначены для самого ovirt-а, при падении ноды - engine перезапускается на другой ноде и восстанавливает нормальную работу кластера.
Пример use-case: блейд-шасси с одинаковыми мощными блейдами и общим схд, других серверов или даже ПК нет. В подобной ситуации несколько стремно отдавать целый блейд только под ovirt-engine, а если учесть необходимую отказоустойчивость - то и все два. Поэтому нужно чтобы engine был виртуальной машиной, которая крутится на тех же блейдах-нодах, что выделены в кластер в самом ovirt-e.
Решение построено на использовании pacemaker-кластера для хостинга виртуалки с ovirt-engine и адаптацию его работы вместе с vdsm-ом, который необходим для работы нод ovirt-а.

1. Ставим необходимый софт

Все необходимое для pacemaker-а и ovirt-а нужно поставить на ноды заранее (подключив epel и ovirt репозитории).

yum -y install cman pacemaker resource-agents fence-agents pcs vdsm vdsm-cli qemu-kvm-tools tuned

2. Подготавливаем диск для виртуалки с ovirt-engine

На схд нужно создать отдельный lun под виртуалку с ovirt-engine, сделать его доступным для всех нод кластера.
После того, как lun увидят все сервера, необходимо внести небольшое изменение - нужно сделать владельцем этого блочного устройства юзера vdsm с группой kvm (именно под этим пользователем работает kvm/libvirt после установки vdsm-демона), иначе не получится запустить виртуалку под engine.
Для этого необходимо:

• получить scsi_id этого диска: scsi_id --whitelisted /dev/sdX, где sdX - имя блочного устройства с нужным lun-ом.
• создать udev-правило для этого scsi_id, с приоритетом больше 60 (чтобы отрабатывало после стандартных правил блочных/мультипас устройств; /etc/udev/rules.d/60-names.rules, например): KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace /dev/$name", RESULT=="36001405a8852516594a4dd1a7b78d60a", NAME="sdd", OWNER="vdsm", GROUP="kvm", MODE="0660". "Result", "Name" - заменить своими значениями scsi_id и именем устройства.
• ребутнуть сервак или сделать udevadm test

3. Создаем pacemaker-кластер

Процедуру описывать небуду, благо есть официальная документация + я уже описывал вкратце тут, остановлюсь только на паре моментов:

• для исключения ситуации split-brain и упрощения конструкции - лучше включить в pacemaker-кластер все ноды, планируемые для работы с ovirt
• обязательно настроить и протестировать quorum и fencing
• для снижения влияния на сам ovirt-кластер, в pacemaker-кластере активными лучше оставить только 2 ноды, а остальные держать в режиме standby (для кворума), это сократит время ребута standby-нод, т.к не будет двойного фенсинга (от pacemaker кластера и ovirt кластера)

4. Подготовка виртуалки ovirt-engine

После установки vdsm-а, он перенастраивает libvirt на авторизацию через sasl2, поэтому необходимо добавить конфиг и ключи для pacemaker-а. На всех нодах необходимо создать файл /etc/libvirt/auth.conf с примерно таким содержимым:

[credentials-pcmk]
authname=pcmk
password=somepass
[auth-libvirt-node-1]
credentials=pcmk
[auth-libvirt-node-2]
credentials=pcmk
...
[auth-libvirt-node-N]
credentials=pcmk
[auth-libvirt-localhost]
credentials=pcmk

(необходимо указать имена всех нод кластера)
Затем выполнить на каждой ноде команду saslpasswd2 -a libvirt pcmk, введя тот же пароль, что указали в auth.conf.
После этого "virsh list" и "virsh -c qemu+ssh://node-X/system list" с любой ноды должен отрабатывать без запроса пароля.
Для корректной работы online-миграции виртуалки средствами ресурса VirtualDomain необходимо изменить последовательность запуска/остановки pacemaker-а, чтобы он останавливался до libvirt-guests (иначе при перезагрузке ноды виртуалка с engine-ом уйдет в суспенд из-за libvirt-guests, pacemaker не сможет ее мигрировать и будет фенсить ноду до посинения). Для этого нужно:

• отредактировать /etc/init.d/pacemaker , заменить "# chkconfig: - 99 01" на "# chkconfig: - 99 00"
• пересоздать линки в rc.d: chkconfig --del pacemaker && chkconfig --add pacemaker && chkconfig pacemaker on

Выполнив эти изменения, можно создавать ресурс ocf:heartbeat:VirtualDomain и ставить ОС на виртуалке.

5. Промежуточный итог

На этом этапе должен получится работающий pacemaker-кластер, все сервера в него должны входить, в кластере быть кворум и нормально работать fencing. Из ресурсов кластера - должна быть виртуалка, для нее работать стандартные операции start/stop, а также онлайн-миграция, как по команде move, так и автоматически при переводе ноды в standby или перезагрузке/остановке сервиса pacemaker. Очень рекомендую на этом шаге провести всевозможные симуляции отказов оборудования: вырубать питание на серверах, ребутить, выключать интерфейсы, килять процессы и т.п.

6. Ставим ovirt-engine на виртуалке

Тут все по документации, ставим необходимые пакеты, делаем инициализацию engine, создаем в нем DC, cluster, необходимые сети.

7. Добавляем ноды в ovirt-кластер

Начать нужно с нод, находящихся в standby-режиме в pacemaker-кластере, их можно добавить в овирт безболезненно. Единственный момент - необходимо снимать галку про автоконфигурирование фаерволла, иначе траффик pacemaker-кластера будет заблокирован.
После успешного добавления всех standby-нод (после того, как в овирте они станут со статусом "up"), необходимо перевести одну из них в pacemaker-е в online и мигрировать engine на нее. После этого перевести оставшуюся ноду в standby, добавить в овирт кластер и перевести обратно в online.

8. Результат

Если все сделано правильно - получаем полноценную среду виртуализации oVirt с отказоустойчевым engine-ом. На той же ноде, на которой крутится виртуалка с engine-ом, могут крутиться гостевые виртуалки, управляемые ovirt-ом; в случае отказа этой ноды - engine перезапустится на другой ноде, зафиксирует отказ ноды и перезапустит HA виртуалки на других нодах, т.е. весь необходимый функционал будет работать как положено. Исключаем единую точку отказа без введения дополнительных серверов в инфраструктуру.