При резервировании некоторых типов ресурсов, очень важно что бы одновременно ресурсом пользовалось не более одного клиента, как, например, с 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
Автор: Silvar
