pacemaker: как добить лежачего

При резервировании некоторых типов ресурсов, очень важно что бы одновременно ресурсом пользовалось не более одного клиента, как, например, с drbd: нельзя допускать что бы drbd была подмонтирована в RW режиме на двух системах. То же касается и дисковых систем, подключаемых к нескольким серверам.

За этим следит сам pacemaker, но могут возникнуть ситуации, когда pacemaker решит что ресурс нужно переносить, но команду на отключение на другом узле дать не сможет (например, потеря сетевой связности при использовании iscsi через отдельную сеть итд). Для борьбы с этим используется stonith (Shoot The Other Node In The Head). В pacemaker он настраивается как ресурс и способен решить многие проблемы.

Изначальная конфигурация будет простой:

• node1.eth, node2.eth — адреса узлов, на которых строится кластер
• node1.ipmi, node2.ipmi — IP адреса IPMI интерфейсов узлов
• FS — ресурс для которого требуется обеспечить высокую доступность

На первом шаге, во избежании проблем, делаем дамп текущей конфигурации

pcs cluster cib stonith.xml 

Затем создаем ipmi-stonith ресурсы (полный список возможных stonith ресурсов выдаст pcs stonith list, а полный список параметров доступен по pcs stonith describe <agent>)

pcs -f stonith.xml stonith create node1.stonith  fence_ipmilan ipaddr="node1.ipmi" passwd="xXx" login="xXx" action="reboot" method="cycle" pcmk_host_list="node1.eth" pcmk_host_check=static-list stonith-timeout=10s  op monitor interval=10s  pcs -f stonith.xml stonith create node2.stonith  fence_ipmilan ipaddr="node2.ipmi" passwd="xXx" login="xXx" action="reboot" method="cycle" pcmk_host_list="node2.eth" pcmk_host_check=static-list stonith-timeout=10s  op monitor interval=10s 

Особое внимание нужно обратить на два параметра: ipaddr и pcmk_host_list. Первый говорит о том по какому адресу находится IPMI интерфейс, а второй — какие узлы можно добить создаваемым ресурсом.

Поскольку stonith, с точки зрения pacemaker’a, — обычный ресурс он может мигрировать, как и все остальные ресурсы. Будет очень неприятно, если процесс отвечающий за перезагрузку node2 окажется на node2. По этому запрещаем stonith ресурсам попадать на узлы, которые они будут перегружать.

pcs -f stonith.xml constraint location node1.stonith avoids node1.eth=INFINITY pcs -f stonith.xml constraint location node2.stonith avoids node2.eth=INFINITY 

Настройка закончена. Заливам конфигурацию в pacemaker

pcs cluster push cib stonith.xml 

После этого простая проверка

stonith_admin -t 20 --reboot node1.eth 

даст понять что все получилось правильно.

Итоговая конфигурация должна выглядеть примерно так

# pcs status Online: [ node1.eth node2.eth ]  Full list of resources:   FS     (ocf::heartbeat:Filesystem):    Started node2.eth  node1.stonith     (stonith:fence_ipmilan):        Started node2.eth  node2.stonith     (stonith:fence_ipmilan):        Started node1.eth  # pcs constraint location Location Constraints:   Resource: node1.stonith     Disabled on: node1.eth   Resource: node2.stonith     Disabled on: node2.eth