Я пытаюсь настроить активный / пассивный (2 узла) кластер Linux-HA с corosync и pacemaker, чтобы поддерживать базу данных PostgreSQL в рабочем состоянии. Работает через DRBD и service-ip. Если node1 выходит из строя, node2 должен взять на себя ответственность. То же самое, если PG работает на node2 и не работает. Все работает нормально, кроме STONITH.
Между узлами есть выделенное HA-соединение (10.10.10.X), поэтому у меня следующая конфигурация интерфейса:
eth0 eth1 host
10.10.10.251 172.10.10.1 node1
10.10.10.252 172.10.10.2 node2
Stonith включен, и я тестирую с помощью ssh-agent для уничтожения узлов.
crm configure property stonith-enabled=true
crm configure property stonith-action=poweroff
crm configure rsc_defaults resource-stickiness=100
crm configure property no-quorum-policy=ignore
crm configure primitive stonith_postgres stonith:external/ssh \
params hostlist="node1 node2"
crm configure clone fencing_postgres stonith_postgres
crm_mon -1 показывает:
============
Last updated: Mon Mar 19 15:21:11 2012
Stack: openais
Current DC: node2 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
4 Resources configured.
============
Online: [ node2 node1 ]
Full list of resources:
Master/Slave Set: ms_drbd_postgres
Masters: [ node1 ]
Slaves: [ node2 ]
Resource Group: postgres
fs_postgres (ocf::heartbeat:Filesystem): Started node1
virtual_ip_postgres (ocf::heartbeat:IPaddr2): Started node1
postgresql (ocf::heartbeat:pgsql): Started node1
Clone Set: fencing_postgres
Started: [ node2 node1 ]
Проблема в том, что когда я прерываю соединение между интерфейсами eth0, он убивает оба узла. Думаю, проблема с кворумом, ведь узлов всего 2. Но я не хочу добавлять третий узел только для расчета нужного кворума.
Есть какие-нибудь идеи по решению этой проблемы?
Это немного более старый вопрос, но представленная здесь проблема основана на неправильном представлении о том, как и когда работает отработка отказа в кластерах, особенно в двухузловых кластерах.
Суть такова: Вы не можете выполнить тестирование аварийного переключения, отключив связь между двумя узлами. В результате вы получите именно то, что вы видите, - сценарий расщепления мозга с дополнительным общим STONITH. Если вы хотите проверить возможности ограждения, простой killall -9 corosync на активном узле подойдет. Другие способы crm node fence или stonith_admin -F.
Из не совсем полного описания вашего кластера (где вывод crm configure show и cat /etc/corosync/corosync.conf?) Кажется, вы используете адреса 10.10.10.xx для обмена сообщениями, то есть для связи Corosync / кластера. Адреса 172.10.10.xx - это ваши обычные / служебные сетевые адреса, и вы можете получить доступ к данному узлу, например, используя SSH, по его адресу 172.10.10.xx. DNS также, похоже, разрешает имя хоста узла, например node1 по 172.10.10.1.
У вас есть STONITH, настроенный на использование SSH, что само по себе не очень хорошая идея, но вы, вероятно, просто тестируете. Я сам не использовал его, но предполагаю, что агент SSH STONITH входит в другой узел и выдает команду выключения, например ssh root@node2 "shutdown -h now" или что-то подобное.
Что произойдет, если вы отключите кластерную связь между узлами? Узлы больше не видят каждый узел живым и здоровым, потому что между ними больше нет связи. Таким образом, каждый узел предполагает, что он единственный оставшийся в живых после какого-то неудачного события, и пытается стать (или остаться) активным или основным узлом. Это классический и страшный сценарий раздвоения мозга.
Часть этого - удостовериться другой, очевидно и предположительно отказавший узел, не работает навсегда, и именно здесь на помощь приходит STONITH. Имейте в виду, что обе узлы теперь играют в ту же игру: пытаются стать (или оставаться) активными и захватить все ресурсы кластера, а также стреляют в голову другому узлу.
Вы, наверное, догадались, что происходит сейчас. node1 делает ssh root@node2 "shutdown -h now" и node2 делает ssh root@node1 "shutdown -h now". При этом используется не сеть связи кластера 10.10.10.xx, а служебная сеть 172.10.10.xx. Поскольку оба узла фактически живы и здоровы, у них нет проблем с выдачей команд или получением SSH-соединений, поэтому оба узла стреляют друг в друга одновременно. Это убивает оба узла.
Если вы не используете STONITH, то разделение мозга может иметь еще худшие последствия, особенно в случае DRBD, когда оба узла могут стать первичными. Вероятно, что произойдет повреждение данных, и разделение мозга придется решать вручную.
Рекомендую прочитать материал по http://www.hastexo.com/resources/hints-and-kinks который написан и поддерживается ребятами, которые внесли (и до сих пор вносят свой вклад) большую часть того, что мы сегодня называем «стеком Linux HA».
TL; DR: Если вы отключаете кластерную связь между узлами, чтобы протестировать настройку ограждения, Ты делаешь это неправильно. Использовать killall -9 corosync, crm node fence или stonith_admin -F вместо. Прерывание связи кластера приведет только к сценарию разделения мозга, который может и приведет к повреждению данных.
Вы можете попробовать добавить auto_tie_breaker: 1 в раздел кворума /etc/corosync/corosync.conf
Когда включен ATB, в кластере могут одновременно выходить из строя до 50% узлов детерминированным образом. Раздел кластера или набор узлов, которые все еще находятся в контакте с узлом, имеющим наименьший nodeid, сохранят кворум. Остальные узлы будут без текста.
Проверьте это для кластера высокой доступности с помощью Pacemaker: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html
Попробуйте прочитать Кворум и двухузловые кластеры главу документации Pacemaker.