Добавить в корзинуПозвонить
Найти в Дзене
Записки сисадмина

Linux. Pacemaker + Corosync. Virtual IP и Virtual Source.

Сейчас довольно модно подводить итоги года, думаю тоже удариться в этот мейнстрим. Статьи я начал писать с января 2025 года, выкладывая по возможности свои наработки и делясь знаниями. За этот год была пара моих затяжных молчаний по несколько месяцев. Однако, даже так канал собрал более 120 часов просмотров за год. Учитывая специфичность своего контента и то, что канал был создан как собственная записная книжка, я считаю это успехом :) Честно признаться, рад каждому лайку и комментарию. Если мои статьи приносят пользу людям и помогают разобраться в каких-то узких аспектах - я уже счастлив. Буду честен, мне и самому иногда приходится перечитывать собственные статьи, чтобы вспомнить, как что работает. К сожалению, зачастую нет ни времени, ни сил соблюдать какой-либо контент план и писать статьи регулярно. Но обещаю (больше - самому себе) почаще, хоть и не регулярно, выкладывать что-то новое. Честно признаться, смотря на статистику публикаций, иногда сам удивляюсь, какие именно статьи ста
Оглавление

Маленькое лирическое отступление

Сейчас довольно модно подводить итоги года, думаю тоже удариться в этот мейнстрим. Статьи я начал писать с января 2025 года, выкладывая по возможности свои наработки и делясь знаниями. За этот год была пара моих затяжных молчаний по несколько месяцев. Однако, даже так канал собрал более 120 часов просмотров за год. Учитывая специфичность своего контента и то, что канал был создан как собственная записная книжка, я считаю это успехом :)

Честно признаться, рад каждому лайку и комментарию. Если мои статьи приносят пользу людям и помогают разобраться в каких-то узких аспектах - я уже счастлив.

Буду честен, мне и самому иногда приходится перечитывать собственные статьи, чтобы вспомнить, как что работает.

К сожалению, зачастую нет ни времени, ни сил соблюдать какой-либо контент план и писать статьи регулярно. Но обещаю (больше - самому себе) почаще, хоть и не регулярно, выкладывать что-то новое.

Честно признаться, смотря на статистику публикаций, иногда сам удивляюсь, какие именно статьи становятся популярными, а какие не взлетают вообще. Да и что-то слишком много я выкладываю информации по python, являясь linux администратором.

Не буду настаивать, но если у вас есть запрос на какую-то конкретную тему, можете написать об этом в комментариях, а я постараюсь ее раскрыть.

А теперь немного о кластерах

Пока мы все выходим с самых длительных за последние годы новогодних праздников, предлагаю разобрать одну маленькую механику кластеризации.

В этой статье мы создавали простой кластер на pacemaker и corosync, добавив в него плавающий виртуальный ip.

pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.122.140 cidr_netmask=24 op monitor interval=5s

Проверяем, что наш кластер все еще работает и обе ноды живы:

Также мы можем проверить, как именно сконфигурированы наши ресурсы в кластере:

pcs resource config
-2

В случае с обычным web сервером, этих настроек нам будет вполне достаточно.

Однако, если у нас есть какое-нибудь приложение, которое само обращается по сети к своим клиентам, мы получим некоторые проблемы (например, zabbix).

Да, да, именно благодаря системе мониторинга я огреб немало проблем в свое время.

А конкретно:

  • Предположим, у нас есть 2 ноды zabbix-server. zabbix1 с адресом 192.168.1.2 и zabbix2 с адресом 192.168.1.3
  • Мы создаем кластер с именем zabbix и присваиваем ему DNS запись zabbix.local IN A 192.168.1.4
  • Всем zabbix агентам мы указываем в конфиге Server=zabbix.local
  • Создаем плавающий IP в кластере 192.168.1.4 и запускаем наш zabbix-server
  • И тут же получаем отчеты о недоступности всех агентов.

Почему так произошло?

А потому что IPaddr2 в pacemaker отвечает только за входящий трафик. А наш zabbix сервер - активное приложение, которое шлет запросы само.

Получается так, что агенты ждут запросов с IP 192.168.1.4 (от резолвинга zabbix.local), а получают от 192.168.1.2, или 192.168.1.3 (в зависимости от того, какая нода сейчас активна).

Создаем исходящий маршрут

Пожалуй, не буду делиться своими изысканиями в поисках решения, а сразу покажу рабочий вариант.

В папке /usr/lib/ocf/resource.d/heartbeat/ мы можем найти все стандартные ресурсы pacemaker, которые добавляются с его установкой.

В прошлый раз мы использовали IPaddr2 для входящих соединений, сейчас нас интересует IPsrcaddr.

  • Создаем еще один ресурс:
pcs resource create VirtualSRC ocf:heartbeat:IPsrcaddr ipaddress=192.168.122.140 cidr_netmask=24 op monitor interval=5s
  • Добавляем его в группу:
pcs resource group add NginxBalance VirtualSRC --after VirtualIP
  • И проверяем кластер:
-3

В моменте создания ресурса, до добавления его в группу, вы получите ошибку: VirtualSRC start on debian-node-2 returned 'not installed' (We are not serving [192.168.122.140], hence can not make it a preferred source address)

Данное поведение нормально, поскольку при добавлении, pacemaker попробует запустить ресурс на обеих нодах, а вторая нода в данный момент не будет обслуживать наш адрес.

  • Проверяем исходящий адрес:
-4
  • При этом вторая нода будет отвечать со своего личного адреса:
-5
  • Если у нас упадет основная нода, вторая моментально подхватит виртуальный IP и начнет свои обращения с него:
-6