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

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


На кластере должен быть активен stonith, а quorum отключен (поскольку кластер из двух узлов). Убедимся в этом
#pcs -f stonith.xml property show
...
 no-quorum-policy: ignore
 stonith-enabled: true
...

Если это не так, то
pcs -f stonith.xml property set stonith-enabled=true
pcs -f stonith.xml property set no-quorum-policy=ignore


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

#  pcs property show
 no-quorum-policy: ignore
 stonith-enabled: true
  • +1
  • 18.5k
  • 4
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 4

    0
    STONITH на кластере из 2х нод — это сильно! Да еще и кворум не игнорируется.
      0
      Если требуется строго монопольное использование ресурса, то это без STONITH не обойтись.

      Про кворум спасибо что напомнили. Метод «настроил и забыл» плох именно тем, что настроил и забыл. Сейчас дополню.
      0
      > Если требуется строго монопольное использование ресурса, то это без STONITH не обойтись.

      Кто кому в голову будет стрелять, если упадет сеть между нодами?
        0
        Смотря как сеть сделана.
        Если стрелять не через тот же канал, через который осуществляется связь между нодами, то да, бессмысленно и опасно.
        А если и выстрел и связь по одному линку будут проходить (грубо, 4 линка, eth+ipmi от каждой ноды, будут приходить в один коммутатор\маршрутизатор), то:
        1. eсли упал только eth линк, то выстрелят оба, но у одного eth линка нет и его выстрел не дойдет до адресата;
        2. eсли упали и eth, и ipmi линки, то выстрелят оба, ни один STONITH не сработает, ресурсы мигрировать не начнут.

      Only users with full accounts can post comments. Log in, please.