Маленькое лирическое отступление
Сейчас довольно модно подводить итоги года, думаю тоже удариться в этот мейнстрим. Статьи я начал писать с января 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
В случае с обычным web сервером, этих настроек нам будет вполне достаточно.
Однако, если у нас есть какое-нибудь приложение, которое само обращается по сети к своим клиентам, мы получим некоторые проблемы (например, zabbix).
Да, да, именно благодаря системе мониторинга я огреб немало проблем в свое время.
А конкретно:
- Предположим, у нас есть 2 ноды zabbix-server. zabbix1 с адресом 192.168.1.2 и zabbix2 с адресом 192.168.1.3
- Создаем плавающий 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
- И проверяем кластер:
В моменте создания ресурса, до добавления его в группу, вы получите ошибку: 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 попробует запустить ресурс на обеих нодах, а вторая нода в данный момент не будет обслуживать наш адрес.
- Проверяем исходящий адрес:
- При этом вторая нода будет отвечать со своего личного адреса:
- Если у нас упадет основная нода, вторая моментально подхватит виртуальный IP и начнет свои обращения с него: