Парсер Хабра: pacemaker: как добить лежачего

четверг, 31 октября 2013 г.

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: