Як налаштувати STONITH в 2-вузловий активний / пасивний кластер пейсмейкера HA Linux?

Я намагаюся налаштувати активний / пасивний (2 вузли) кластер Linux-HA з коросинхронізацією та кардіостимулятором, щоб підтримувати і працювати з DatagreSQL-Database. Він працює через DRBD та сервіс-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 для вбивства вузлів.

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 вузла. Але я не хочу додавати 3-й вузол лише для обчислення правильного кворуму.

Чи є ідеї для вирішення цієї проблеми?

Це дещо старше питання, але проблема, представлена ​​тут, базується на помилковому уявленні про те, як і коли відбувається відмова в кластерах, особливо кластерах з двома вузлами.

Суть полягає в тому, що ви не можете робити перевірку на відмову, відключаючи зв’язок між двома вузлами. Це призведе до того, що саме ви бачите, сценарій розділеного мозку з додатковим взаємним 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 також дозволяє вирішити ім'я хоста вузла, як-от node1172.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% вузлів одночасно. Розділ кластера або набір вузлів, які все ще контактують з вузлом, який має найнижчий вузол, залишаться лапкою. Інші вузли будуть допитливими.

Спробуйте прочитати розділ Кворум та двовузлові кластери документації Pacemaker.

Перевірте це на кластері HA за допомогою Pacemaker: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html