Comments 10
Если одна нода упадет, то pacemaker смигрирует ее ресурс на одну из работающих нод, в результате чего эта нода возьмет обязаности упавшей ноды, и будет отвечать на запросы вдвое чаще чем другая.
Если бы нод было, допустим, хотя бы четыре и две из них умрут, pacemaker запустит по два ресурса на каждой из оставшихся нод.
Насколько быстро кластер поймет, что одна из нод выключилась?
Это настраивается в параметре op monitor interval="10s" для вашего ресурса.
Балансировщик это HAProxy ( nginx) и стоит уже за vIP.
Задача pacemaker именно в поддержке vIP.
Отключение кворума при 3-ёх нодах — несколько странно. Т.к. обычно это практикуют при 2-ух и в целях экономии железа. Когда отключаете кворум, нужно чётко понимать зачем это и использовать stonith с fencing'ом. И помним о split brain и его последствиях.
Если задача только vIP для трёх серверов, pacemaker + corosync это слишком тяжёлое решение имхо.
Зачем для pacemaker назначать ту задачу, которая ему не свойственна?
Если данная функция реализованна разработчиком, то почему вы считаете что она ему не свойствена?
Балансировщик это HAProxy ( nginx) и стоит уже за vIP.
Я не имею ничего против HAProxy, я просто рассказал еще об одном способе балансировки.
Для кластеров в одном сегменте сети — он наиболее удобен и не требует установки отдельного балансировщика.
Отключение кворума при 3-ёх нодах — несколько странно
В данном конкретном случае задача была описать настройку именно clonned IPaddr.
Для его нормальной работы — ни кворум ни stonich не сделают никакой погоды.
Кроме того, в статье есть про это оговорка и ссылка на инструкцию по настройке.
Если задача только vIP для трёх серверов, pacemaker + corosync это слишком тяжёлое решение имхо.
Подразумевалось, что помимо vIP могут быть и другие ресурсы контролируемые pacemaker, для которых он собственно и настраивается.
Если данная функция реализованна разработчиком, то почему вы считаете что она ему не свойствена?
как бы сказать помягче, все эти RA это просто скрипты, в них можно засунуть всё что угодно, и управлять чем угодно. Но если в них это добавлено, это не значит что это наиболее оптимальная реализация.
Подразумевалось, что помимо vIP могут быть и другие ресурсы контролируемые pacemaker, для которых он собственно и настраивается.
безопасно без кворума и стониса можно использовать только полностью stateless ресурсы
основной поинт, я за разные решения на pacemaker, если такая балансировка работает — то хорошо.
но после продолжительного использования pacemaker и corosync, для себя сделал вывод — не стоит усложнять
Я правильно понимаю, что осталось настроить синхронизацию conntrack(если конечно conntrack-tools умеет синхронизацию мастер-мастер) и можно получить маршрутизатор с балансировкой нагрузки?
Либо использовать clusterip_hash = sourceip-sourceport-destport
Идея интересная, я думаю, что это должно сработать.
Балансировка нагрузки с Pacemaker и IPaddr (Active/Active cluster)