VM в pacemaker-кластере

Виртуалка в кластере - один из простых способов обеспечить отказоустойчивость сервиса, когда полноценные среды HA-виртуализации еще overkill, а отдельные хосты/скрипты/ручная работа уже не годится. В частности, если разворачивать oVirt, то его engine должен быть вне датацентра, а по-хорошему его тоже необходимо сделать высокодоступным, чтобы не лешиться управления средой виртуализации в критический момент.
Я опишу связку cman+pacemaker, т.к. она практически нигде не освещена, но только она под centos/rhel6 со стандартными rpm-ками позволяет использовать gfs2 и кучу ресурсов из heartbear/pacemaker (ocf:heartbeat:Route, в частности), которых нет в redhat cluster suite.

Базовая настройка кластера

Документация на clusterlabs весьма запутана, т.к. вначале описывается создание кластера с corosync, а потом конвертация всего этого под cman, но если настройка производится с нуля - это все лишнее. На деле все довольно просто.

1. Ставим необходимые пакеты: yum install cman pacemaker resource-agents fence-agents pcs
2. Пишем базовый cluster.conf для cman, в нем необходимо только дать название кластеру и перечислить ноды. fence-устройства для всех нод необходимо выбрать "fence_pcmk" - редирект в pacemaker. Имена нод должны совпадать с выводом команды "hostname" и резолвится через dns.
   

   <?xml version="1.0"?>
   <cluster config_version="1" name="mycluster">
     <logging debug="off"/>
     <clusternodes>
       <clusternode name="node-1" nodeid="1">
         <fence>
           <method name="pcmk-redirect">
             <device name="pcmk" port="node-1"/>
           </method>
         </fence>
       </clusternode>
       <clusternode name="node-2" nodeid="2">
         <fence>
           <method name="pcmk-redirect">
             <device name="pcmk" port="node-2"/>
           </method>
         </fence>
       </clusternode>
       <clusternode name="node-3" nodeid="3">
         <fence>
           <method name="pcmk-redirect">
             <device name="pcmk" port="node-3"/>
           </method>
         </fence>
       </clusternode>
     </clusternodes>
     <fencedevices>
       <fencedevice name="pcmk" agent="fence_pcmk"/>
     </fencedevices>
   </cluster> 

3. Копируем этот конфиг на все ноды и запускам cman. Должен сформироваться кластер, "cman_tool nodes" должен показать все ноды в онлайне. Запускаем pacemaker - он должен подхватить кластер, "pcs status" должен показать все ноды в онлайне, наличие кворума. Больше в cman/cluster.conf мы не лезем, все управление кластером через утилиту pcs.
4. Теперь в pacemaker-е необходимо описать и проверить fence-устройства, pcs stonith create ...
   Для примера, fence через обычный ipmi-интерфейс: pcs stonith create node-1 fence_ipmilan pcmk_host_list="node-1" ipaddr=xxx.xxx.xxx.xxx login=user passwd=password method=cycle

Настройка виртуалки в кластере

Для начала необходимо создать виртуалку и получть xml с ее конфигом. Естественно, что диски виртуалки должны быть расположены на общем для всех нод хранилище (nfs/iscsi+clvm/fc+clvm/drbd), xml-ник тоже рекомендую располагать на общем ресурсе (вот где gfs2 пригодится), чтобы не напрягаться по поводу синхронизации изменений в нем.
Для live-миграции виртуалки в кластере необходимо обеспечить вход root-а по ssh-ключам между всеми нодами кластера, ssh-keygen и ssh-copy-id в помощь.

После того, как все подготовлено - необходимо добавить ресурс "виртуалка" в кластер. Это ресурс ocf:heartbeat:VirtualDomain, необходимо указать параметры - config (путь до xml), migration_transport=ssh, meta allow-migrate=true (для разрешения live-миграции).
Пример: pcs resource create testVM ocf:heartbeat:VirtualDomain config=/mnt/testVM.xml migration_transport=ssh meta allow-migrate=true

Если xml с конфигом виртуалки находится на фс, монтируемой средствами кластера (как в моем случае - gfs2, клонированный ресурс запущенный на всех нодах кластера), то необходимо сделать constraint order - ограничение на порядок запуска/останова ресурсов: сначала должна монтироваться ФС, затем запускаться виртуалка; останов - в обратном порядке.
Пример: pcs constraint order add cxml-clone testVM

И последняя важная деталь - в rhel/centos есть сервис "libvirt-guests", который суспендит виртуалки при ребуте и обеспечивает автостарт виртуалок при запуске. Поскольку в процессе ребута/шатдауна этот сервис дергается первым, то запущенная pacemaker-ом виртуалка будет засуспендена и выключена до того, как управление будет отдано pacemaker-у. В результате мало того, что live-миграция обломится, но и после запуска этой ноды виртулка выйдет из суспенда и будет запущена одновременно на двух нодах кластера. Кластер на это отреагирует fence-ом ноды, перезапуском виртуалки и вся вакханалия повторится вновь когда ребутнутая нода подключится к кластеру.
Чтобы не допускать такой порнографии необходимо полностью выключить этот сервис и удалить симлинки "K01libvirt-guests" из /etc/rc.d/rcX.d (простого "chkconfig libvirt-guests off" недостаточно - "K01libvirt-guests" линки остаются).

После всех манипуляций получаем корректно работающий кластер - виртуалка запущена, работает live-миграция, как вручную ("resource move"), так и при отправке ноды в standby или ребуте. В случае потери связи с нодой - сработает fencing и нода будет перезагружена, виртуалка будет перезапущена на другой ноде.