Зачем вам кластер Corosync и Pacemaker в 2026 году?
Corosync и Pacemaker остаются основой для построения высокодоступных кластеров в Linux-экосистеме. Эта проверенная связка технологий поддерживается всеми основными дистрибутивами и обеспечивает отказоустойчивость критических сервисов, таких как веб-серверы, базы данных или файловые системы. Руководство актуально для 2026 года и учитывает современные практики настройки и мониторинга.
Этот инструмент позволяет гарантировать бесперебойную работу сервисов, автоматически перемещая их на резервные узлы при сбоях. Вы минимизируете риски простоя и повышаете надежность инфраструктуры без значительных инвестиций в специализированное оборудование.
Архитектура кластера: как работают Corosync и Pacemaker
Кластер на базе Corosync и Pacemaker состоит из двух или более серверов (узлов), которые работают как единая система для обеспечения высокой доступности. Corosync отвечает за связь между узлами, а Pacemaker управляет сервисами и ресурсами.
Corosync: обеспечиваем связь и определяем кворум
Corosync это коммуникационный уровень кластера. Он использует multicast или unicast сообщения для постоянного обмена данными между узлами. Основная задача – детектирование сбоев: если один узёл не отвечает, другие узнают об этом через Corosync.
Ключевая концепция – кворум. Это механизм принятия решений, основанный на большинстве голосов (работающих узлов). Без достижения кворума кластер не может выполнять операции, например, перемещать ресурсы. Это защищает от ситуации "раскола мозга", когда две части кластера действуют независимо, что может привести к повреждению данных.
Pacemaker: интеллектуальное управление ресурсами и VIP
Pacemaker это Resource & Cluster Manager. Он получает информацию о состоянии узлов от Corosync и принимает решения о запуске, остановке или миграции сервисов (ресурсов). Ресурсом может быть система, IP-адрес или скрипт.
Pacemaker управляет виртуальным IP-адресом (VIP). Это плавающий IP, который клиенты используют для доступа к сервису. При сбое активного узла Pacemaker перемещает VIP на резервный, обеспечивая непрерывность обслуживания. Логика принятия решений основана на заданных правилах колокации (где ресурсы должны работать вместе) и порядка (последовательность их запуска).
Пошаговая установка и базовая настройка кластера
Предварительные требования: два сервера с ОС Rocky Linux 9, AlmaLinux 9 или аналогичной (на базе RHEL 9), настроенная сеть с статическими IP, одинаковые пароли root или настроенный SSH с ключами для аутентификации между узлами. Для тестирования можно временно отключить SELinux и firewall, но в production это требует дополнительной настройки правил.
Установка необходимых пакетов на всех узлах
На каждом узле выполните команды для установки базовых компонентов. Для дистрибутивов на базе RHEL 9:
dnf install -y corosync pacemaker pcs psmisc resource-agentsДля систем на базе Debian/Ubuntu (версии 2026 могут отличаться, проверяйте названия пакетов):
apt update && apt install -y corosync pacemaker pcs resource-agentsПакет pcs предоставляет удобную командную утилиту для управления кластером. resource-agents содержит набор скриптов для управления стандартными сервисами (OCF агенты).
Настройка firewall и создание кластера с помощью `pcs`
Corosync использует порты 5405, 5411 для multicast/unicast трафика. Настройте правила firewall на всех узлах:
firewall-cmd --permanent --add-service=high-availability
firewall-cmd --reloadЗапустите службы и разрешите их работу после загрузки:
systemctl start pcsd
systemctl enable pcsd
systemctl start corosync
systemctl enable corosync
systemctl start pacemaker
systemctl enable pacemakerСоздайте кластер. На одном из узлов (например, node1) выполните аутентификацию:
pcs host auth node1 node2 -u hacluster -p Затем создайте кластер с именем, например, cluster_ha:
pcs cluster setup cluster_ha node1 node2 --start --enableВизуально проверьте статус кластера:
pcs statusКоманда должна показать два узла в состоянии "Online". Отключите STONITH (для тестовой среды, в production его необходимо настроить):
pcs property set stonith-enabled=falseСоздание и управление ресурсами: от виртуального IP до реального сервиса
Ресурс в Pacemaker это абстракция сервиса, который кластер должен контролировать. Основные типы: примитивные (один экземпляр), клоны (много экземпляров на разных узлах) и мастер-слейв (для реплицируемых сервисов).
Настройка виртуального IP-адреса (VIP) – основа отказоустойчивости
VIP это точка входа для клиентов. Создайте ресурс с помощью OCF агента IPaddr2:
pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 nic=eth0 op monitor interval=30sПараметры: ip – виртуальный адрес, cidr_netmask – маска сети, nic – интерфейс. Операция monitor проверяет состояние каждые 30 секунд.
Проверьте работу: выполните ping 192.168.1.100 из внешней сети. Затем на активном узле, где работает VIP, остановьте кластерные службы или отключите сеть. Pacemaker автоматически переместит VIP на второй узёл, и ping должен продолжить работать.
Кейс: развертывание отказоустойчивого веб-сервера (Nginx/Apache)
Для создания отказоустойчивого веб-сервера сначала установите и настроите Apache или Nginx на обоих узлах. Убедитесь, что сервис не запускается автоматически системой (systemctl disable httpd), чтобы Pacemaker мог его контролировать.
Создайте ресурс для веб-сервера. Для Apache:
pcs resource create webserver systemd:httpd op monitor interval=20sНастройте строгую колокацию, чтобы веб-сервер всегда запускался на том же узле, где находится VIP:
pcs constraint colocation add webserver with vip INFINITYОпределите порядок запуска: сначала VIP, затем веб-сервер:
pcs constraint order vip then webserverТеперь при запросе к виртуальному IP 192.168.1.100 всегда будет отвечать работающий веб-сервер. При сбое узла Pacemaker сначала переместит VIP, затем запустит веб-сервер на новом узле.
Для автоматизации развертывания подобных кластеров можно использовать готовые playbook и шаблоны Ansible, которые включают конфигурацию Pacemaker, балансировщиков нагрузки и хранилищ.
Кейс: отказоустойчивый кластер для базы данных (PostgreSQL репликация)
Этот сценарий требует предварительной настройки streaming-репликации PostgreSQL между узлами. Pacemaker будет управлять ролями master и slave.
Создайте ресурс с использованием агента pgsql:
pcs resource create pgsql ocf:heartbeat:pgsql \
pgctl="/usr/bin/pg_ctl" \
psql="/usr/bin/psql" \
pgdata="/var/lib/pgsql/data" \
rep_mode="sync" \
repuser="replicator" \
node_list="node1 node2" \
master_ip="192.168.1.100" \
restart_on_promote="true" \
op monitor interval="30s"Настройте мастер-слейв ресурс:
pcs resource master pgsql-master pgsql master-max=1 master-node-max=1Затем создайте колокацию с VIP и порядок запуска, аналогично веб-серверу. При отказе мастер-узла Pacemaker выполнит промоут реплики на slave, переключит VIP и клиенты будут подключены к новой мастер-базе.
Мониторинг, проверка работоспособности и анализ ошибок
После развертывания кластера необходим постоянный контроль его состояния. Основные команды предоставляют всю необходимую информацию.
Ключевые команды для ежедневного контроля кластера
pcs status– общий статус кластера: узлы, ресурсы, последние события.pcs resource status– детальный статус всех ресурсов, их состояние и узёл размещения.pcs cluster status– информация о членах кластера и кворуме.crm_mon -1– альтернативный вывод статуса в удобном формате.
Для интеграции с системами мониторинга, такими как Prometheus или Zabbix, используйте агенты Pacemaker или скрипты, собирающие данные из этих команд.
Типичные ошибки при развертывании и их решение
1. "No quorum" – узлы не могут достичь кворума. Проверьте: сетевую связь между узлами (ping, порты Corosync), правила firewall, корректность адресов в corosync.conf. Убедитесь, что multicast трафик не блокируется.
2. Ресурсы не запускаются – часто проблема в отсутствии зависимостей или некорректном OCF агентe. Проверьте, установлен ли необходимый агент (pcs resource list agents). Убедитесь, что сервис не запущен вне контроля Pacemaker.
3. Предупреждения о STONITH – Pacemaker требует настроенного fencing устройства для безопасной изоляции неисправных узлов. Для тестовой среды можно временно отключить (pcs property set stonith-enabled=false), но для production это обязательный элемент. Настройте STONITH для вашего оборудования (DRAC, IPMI, гипервизор).
4. Ошибки конфигурации Corosync – проверьте синтаксис файла /etc/corosync/corosync.conf. Особое внимание на секции nodelist с правильными IP адресами и портами.
Логи для анализа: journalctl -u corosync, journalctl -u pacemaker, /var/log/pacemaker.log. Они содержат детализацию всех событий кластера.
Для комплексного мониторинга всей инфраструктуры, включая кластеры серверов, рассмотрите стек Prometheus+Grafana и специализированные инструменты, которые предлагают готовые дашборды для Pacemaker и Corosync.
Дальнейшие шаги и рекомендации для production-среды
Базовая настройка обеспечивает работу кластера, но для production среды требуются дополнительные меры.
Настройте STONITH (Shoot The Other Node In The Head). Это механизм аппаратной или программной изоляции неисправного узла для предотвращения "раскола мозга" и повреждения данных. Используйте fencing устройства, поддерживаемые вашим оборудованием или гипервизором. Например, для виртуальных машин в VMware используйте агент fence_vmware_soap.
Реализуйте резервный канал связи в Corosync (redundant ring). Настройте второй сетевой интерфейс или альтернативный метод связи (например, через отдельную VLAN) в файле corosync.conf. Это защитит кластер от сбоя основной сети.
Тюнинг параметров детектирования сбоев. В Pacemaker можно настроить таймауты мониторинга ресурсов (op monitor timeout) и интервалы проверки, адаптированные к вашим сервисам. Для медленно запускающихся приложений увеличьте startup timeout.
Ведите документацию конфигурации. Записывайте все изменения, выполненные через pcs, и сохраняйте резервные копии конфигурационных файлов Corosync и Pacemaker. Это критично для восстановления после сбоев.
Проводите регулярное тестирование отказоустойчивости на staging стенде. Имитируйте сбои узлов, сети и сервисов, чтобы убедиться в корректной реакции кластера и отсутствии побочных эффектов.
Для управления сложной инфраструктурой, включающей кластеры, микросервисы и оркестрацию, полезно систематизировать знания. База знаний IT помогает сократить время восстановления и упростить онбординг новых специалистов.
Перед внедрением кластера в production убедитесь, что у вас есть надежная стратегия резервного копирования всех узлов и данных. Готовые скрипты для автоматического резервного копирования сервера с BorgBackup, Rclone и rsync обеспечивают выполнение правила 3-2-1 и включают тесты восстановления.
Если ваша архитектура переходит от монолита к микросервисам, кластерная инфраструктура становится особенно важной. Практический план миграции включает развертывание микросервисов в Docker и Kubernetes с учетом требований высокой доступности.
Для автоматизации рутинных задач администрирования Linux и DevOps инфраструктуры в 2026 году используйте сборник проверенных инструкций, скриптов и конфигураций.
Для экспериментов с конфигурациями кластеров или тестирования новых агентов ресурсов может потребоваться доступ к различным API. Сервис AiTunnel предоставляет единый интерфейс для более 200 моделей нейросетей, включая GPT, Gemini и Claude, что полезно для генерации скриптов или анализа логов.