Pacemaker и Corosync — базовая связка для отказоустойчивого кластера в Linux. Corosync держит связь между узлами и считает кворум, Pacemaker управляет ресурсами: виртуальным IP, веб-сервером, базой. Ниже — сборка кластера из двух узлов, настройка fencing и проверка переключения без магии и лишних абстракций.

Роли компонентов

Corosync отвечает за транспорт: членство, heartbeat, доставку сообщений и голоса кворума. Pacemaker работает поверх него и решает, где запускать ресурс, что делать при падении узла и в каком порядке поднимать зависимости. Если Corosync потерял связь, Pacemaker теряет кворум и по умолчанию останавливает ресурсы — это защита от split-brain, когда два узла считают себя главными.

Для стенда достаточно двух виртуальных машин с Debian 12/13 или Ubuntu 24.04. В продакшене добавьте отдельный интерфейс для heartbeat и третью точку для кворума: два узла — худший вариант для кворума, поскольку при потере связи никто не может доказать, что он в большинстве.

Отдельная зона ответственности — сеть. Если heartbeat и трафик приложения идут через один интерфейс, всплеск трафика может вызвать ложное подозрение в отказе. На стенде это допустимо, но в продакшене второй интерфейс и отдельный VLAN снимают большую часть ложных срабатываний.

Подготовка узлов

Имена должны резолвиться одинаково на обоих узлах, время — совпадать, иначе TLS и логи будут путаться. Проверьте, что SSH между узлами работает по ключам, а порты 2224/tcp, 3121/tcp, 21064/tcp и 5405/udp открыты.

sudo hostnamectl set-hostname node1
echo "192.168.10.11 node1" | sudo tee -a /etc/hosts
echo "192.168.10.12 node2" | sudo tee -a /etc/hosts
sudo apt update && sudo apt install -y pacemaker corosync pcs fence-agents
sudo systemctl enable --now pcsd

На RHEL и производных пакеты называются pacemaker corosync pcs fence-agents-all, а firewall открывается сервисом high-availability. Не забудьте про SELinux: для нестандартных путей к скриптам ресурсов могут понадобиться политики.

Кворум и конфигурация Corosync

Проще всего создать конфигурацию через pcs: он разложит corosync.conf по узлам и запустит сервисы. Пароль пользователя hacluster должен совпадать на всех узлах.

sudo passwd hacluster
sudo pcs host auth node1 node2 -u hacluster
sudo pcs cluster setup --name webcluster node1 node2
sudo pcs cluster start --all
sudo pcs cluster enable --all
sudo pcs quorum status

В файле /etc/corosync/corosync.conf стоит проверить блок totem: транспорт knet, интерфейс heartbeat и токен. Для двух узлов кворум хрупок: добавьте qdevice на отдельной машине (pcs quorum device add model net host=qnetd.example.lan algorithm=lms) или хотя бы убедитесь, что параметр two_node выставлен осознанно. Политику no-quorum-policy=ignore не включайте «чтобы работало»: именно она приводит к двум активным копиям сервиса.

Минимальный corosync.conf выглядит так; pcs создаёт его автоматически, но при ручной правке проверяйте отступы и имена узлов.

totem {
  version: 2
  cluster_name: webcluster
  transport: knet
  token: 5000
  crypto_cipher: aes256
  crypto_hash: sha256
}

Ресурсы: VIP и веб-сервер

Ресурс IPaddr2 поднимает адрес на интерфейсе, systemd-ресурс управляет службой. Между ними нужны colocation и order, иначе веб-сервер может оказаться на узле без адреса.

sudo pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.10.100 cidr_netmask=24 op monitor interval=10s
sudo pcs resource create WebSite systemd:apache2 op monitor interval=20s
sudo pcs constraint colocation add WebSite with ClusterIP INFINITY
sudo pcs constraint order ClusterIP then WebSite
sudo pcs status --full

Проверьте, что apache2 слушает 0.0.0.0 или конкретный адрес, а страница отдаётся по VIP. Если сервис запускается долго, увеличьте интервал мониторинга и настройте timeout, иначе Pacemaker будет считать ресурс упавшим раньше времени.

Fencing: без него кластер опасен

STONITH (Shoot The Other Node In The Head) гарантирует, что старый владелец ресурса действительно мёртв, прежде чем ресурс поднимут на другом узле. В виртуалках используйте fence_ipmilan, fence_virsh или API гипервизора; в железе — IPMI/BMC. Пока fencing не настроен, stonith-enabled лучше оставить false только на стенде.

sudo pcs property set stonith-enabled=true
sudo pcs stonith create fence-node1 fence_ipmilan pcmk_host_list=node1 ipaddr=192.168.10.21 login=admin lanplus=1
sudo pcs stonith status

Пароль не храните в истории shell и в открытом виде в CIB: используйте passwd_script или менеджер секретов. Обязательно протестируйте fencing на одном узле до того, как на кластер поедет нагрузка.

Проверка переключения

Самый честный тест — вывести узел в standby и посмотреть, куда переедут ресурсы. Затем вернуть узел и повторить. Отдельно проверьте аварийный сценарий: погасите узел без предупреждения.

sudo pcs node standby node1
sudo pcs status
curl -I http://192.168.10.100/
sudo pcs node unstandby node1
sudo pcs resource clear WebSite

Команда pcs resource move полезна для планового обслуживания, но она создаёт временное ограничение. После работ его нужно снять через pcs resource clear, иначе ресурс останется привязанным к узлу.

Диагностика

Начинайте с pcs status --full и crm_verify -L -V: первый показывает текущее состояние, второй — ошибки конфигурации. Логи Corosync и Pacemaker смотрите вместе, по времени.

sudo corosync-cfgtool -s
sudo corosync-quorumtool -s
sudo crm_verify -L -V
sudo pcs resource failcount show
sudo journalctl -u corosync -u pacemaker --since "30 min ago"

Частые причины сбоев: несовпадение имён, закрытый порт, разное время, ошибка в агенте ресурса. После исправления сбросьте счётчик ошибок командой pcs resource cleanup WebSite.

Полезно заранее договориться, что считается аварийным состоянием: потеря кворума, недоступность VIP или падение ресурса. Для каждого случая должен быть свой порядок действий, иначе дежурный начнёт «чинить» кластер перезапуском всех служб.

Чек-лист перед продакшеном

  • Имена и время синхронизированы, порты открыты на всех узлах.
  • Кворум защищён qdevice или третьим узлом.
  • Fencing настроен и протестирован.
  • Colocation и order заданы для всех зависимых ресурсов.
  • Переключение проверено вручную и имитацией отказа.

Итог

Pacemaker и Corosync дают предсказуемое переключение, но требуют дисциплины: кворум, fencing и зависимости важнее, чем красивый вывод статуса. Соберите стенд, погасите узел, посмотрите логи — и только потом переносите на кластер боевые сервисы.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте