Как установить STONITH в активном/пассивном Linux с 2 узлами кластер кардиостимулятора HA?
Это немного более старый вопрос, но представленная здесь проблема основана на неправильном представлении о том, как и когда работает аварийное переключение в кластерах, особенно в двухузловых кластерах.
Суть такова: Вы можете не проводите тестирование переключения при отказе путем отключения связи между двумя узлами. В результате вы получите именно то, что вы видите, - сценарий расщепления мозга с дополнительным общим STONITH. Если вы хотите протестировать возможности ограждения, подойдет простая команда killall -9 corosync на активном узле. Другими способами являются crm node ограждение или 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 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 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 DNS также, кажется, разрешает имя узла узла, например node1 в 172.10.10.1.
У вас есть STONITH, настроенный на использование SSH, что само по себе не очень хорошая идея, но вы, вероятно, просто тестируете. Я сам не использовал его, но предполагаю, что агент SSH STONITH входит в другой узел и выдает команду выключения, например ssh DNS также, кажется, разрешает имя узла узла, например node1 в 172.10.10.1.
У вас есть STONITH, настроенный на использование SSH, что само по себе не очень хорошая идея, но вы, вероятно, просто тестируете. Я сам не использовал его, но предполагаю, что агент SSH STONITH входит в другой узел и выдает команду выключения, например sshкорень @ node2«shutdown -h now» или что-то подобное.
Что происходит, когда вы прерываете связь кластера между узлами? Узлы больше не видят каждый узел живым и здоровым, потому что между ними больше нет связи. Таким образом, каждый узел предполагает, что он единственный оставшийся в живых после какого-то неудачного события, и пытается стать (или остаться) активным или основным узлом. Это классический и устрашающий сценарий с разделенным мозгом .
Частично это делается для того, чтобы удостовериться в том, что другой, очевидно и предположительно отказавший узел не работает навсегда, и именно здесь STONITH Имейте в виду, что оба узла теперь играют в одну и ту же игру: пытаются стать (или оставаться) активными и захватить все ресурсы кластера, а также стреляют в голову другому узлу.
Вы, наверное, догадались, что происходит сейчас.root @ node2 "shutdown -h now" и node2 делает ssh root @ node1"выключение -h сейчас" . При этом используется не сеть связи кластера 10.10.10.xx, а служебная сеть 172.10.10.xx. Поскольку оба узла фактически живы и здоровы, у них нет проблем с выдачей команд или получением SSH-соединений, поэтому оба узла стреляют друг в друга одновременно. Это убивает оба узла.
Если вы не используете STONITH, то разделение мозга может иметь еще худшие последствия, особенно в случае DRBD, когда оба узла могут стать первичными. Вероятно, что произойдет повреждение данных, и разделение мозга придется решать вручную.
Я рекомендую прочитать материал на http://www.hastexo.com/resources/hints-and-kinks , который является написан и поддерживается ребятами, которые внесли (и до сих пор вносят свой вклад) большую часть того, что мы сегодня называем «стеком высокой доступности Linux».
TL; DR : Если вы прерываете кластерную связь между узлами, чтобы проверить настройку ограждения, вы делаете это неправильно . Используйте взамен killall -9 corosync , crm node ограждение или stonith_admin -F . Прерывание связи кластера приведет только к сценарию разделения мозга, который может и приведет к повреждению данных.
Проверьте это для кластера HA с помощью Pacemaker: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html
Вы можете попробовать добавить auto_tie_breaker: 1 в раздел кворума /etc/corosync/corosync.conf
Когда ATB включен, кластер может пострадать до 50% узлов отказ одновременно, детерминированным образом. Кластер раздел или набор узлов, которые все еще контактируют с узлом который имеет самый низкий nodeid, останется кворум. Остальные узлы будут inquorate.