Home » Как создать высокодоступную конфигурацию с Heartbeat и зарезервированными IP на Ubuntu 24

Как создать высокодоступную конфигурацию с Heartbeat и зарезервированными IP на Ubuntu 24

Одна из самых популярных проблем в системном администрировании — это обеспечение высокой доступности сервисов. Если у вас падает веб-сервер, база данных или любой другой критичный сервис, пользователи начинают нервничать, а бизнес теряет деньги. Heartbeat в связке с зарезервированными IP-адресами — это классическое решение для создания failover-кластера, которое позволяет автоматически переключаться между серверами в случае отказа одного из них.

В этой статье мы разберем, как настроить высокодоступную конфигурацию с Heartbeat на Ubuntu 24, и почему это решение до сих пор актуально в эпоху Kubernetes и Docker Swarm. Для тех, кто хочет получить надежную инфраструктуру без лишних сложностей — это именно то, что нужно.

Как работает Heartbeat и зарезервированные IP

Heartbeat — это демон, который мониторит состояние узлов в кластере и управляет ресурсами (IP-адресами, сервисами) при отказе одного из серверов. Принцип работы простой: два или более сервера постоянно обмениваются сообщениями (heartbeat packets), и если один из них перестает отвечать, остальные забирают на себя его ресурсы.

Зарезервированный IP (или floating IP) — это IP-адрес, который может “плавать” между серверами. Когда основной сервер работает, IP принадлежит ему. Если сервер падает, IP автоматически переключается на резервный сервер.

Основные компоненты системы:

Heartbeat daemon — следит за состоянием узлов
Cluster Resource Manager (CRM) — управляет ресурсами кластера
STONITH — “Shoot The Other Node In The Head” для предотвращения split-brain
Virtual IP (VIP) — плавающий IP-адрес

Подготовка инфраструктуры

Для настройки понадобится минимум два сервера Ubuntu 24. Можете взять VPS здесь или использовать выделенные серверы для более критичных задач.

Допустим, у нас есть:

Server1 (node1): 192.168.1.10
Server2 (node2): 192.168.1.11
Virtual IP: 192.168.1.100

Первым делом настроим хосты на обоих серверах:

sudo nano /etc/hosts

Добавляем строки:

192.168.1.10 node1
192.168.1.11 node2

Устанавливаем необходимые пакеты:

sudo apt update
sudo apt install heartbeat heartbeat-dev resource-agents -y

Конфигурация Heartbeat

Heartbeat использует три основных конфигурационных файла:

/etc/ha.d/ha.cf — основная конфигурация
/etc/ha.d/authkeys — ключи аутентификации
/etc/ha.d/haresources — ресурсы кластера

Создаем основной конфигурационный файл:

sudo nano /etc/ha.d/ha.cf

Содержимое файла:

logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
warntime 10
initdead 60

udpport 694
bcast eth0
auto_failback on

node node1
node node2

compression bz2
compression_threshold 2

Настраиваем ключи аутентификации:

sudo nano /etc/ha.d/authkeys

auth 1
1 sha1 MySecretKey123456

Устанавливаем правильные права:

sudo chmod 600 /etc/ha.d/authkeys

Настраиваем ресурсы кластера:

sudo nano /etc/ha.d/haresources

node1 IPaddr::192.168.1.100/24/eth0 nginx

Эта строка означает, что node1 является предпочтительным хостом для IP 192.168.1.100 и сервиса nginx.

Настройка сетевых интерфейсов

Для корректной работы Virtual IP нужно настроить сетевые интерфейсы. В Ubuntu 24 используется netplan:

sudo nano /etc/netplan/01-netcfg.yaml

Пример конфигурации для node1:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
        - 192.168.1.10/24
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

Применяем изменения:

sudo netplan apply

Тестирование и запуск кластера

Проверяем конфигурацию:

sudo /etc/init.d/heartbeat start

Для мониторинга состояния кластера используем:

sudo tail -f /var/log/ha-log

Проверяем статус ресурсов:

sudo /usr/lib/heartbeat/hb_standby
sudo /usr/lib/heartbeat/hb_takeover

Для проверки работы failover можно временно отключить сетевой интерфейс на активном узле:

sudo ifconfig eth0 down

Virtual IP должен автоматически переключиться на резервный сервер.

Практические кейсы и примеры использования

Рассмотрим несколько реальных сценариев использования:

Сценарий	Плюсы	Минусы	Рекомендации
Web-сервер (Apache/Nginx)	Простота настройки, быстрое переключение	Нужна синхронизация данных	Используйте rsync или NFS для синхронизации
База данных MySQL	Высокая доступность	Риск потери данных	Настройте MySQL replication
Load Balancer	Идеальный кейс	Минимальные	Используйте HAProxy с Heartbeat

Пример настройки для веб-сервера с синхронизацией:

sudo nano /etc/ha.d/haresources

node1 IPaddr::192.168.1.100/24/eth0 rsync nginx

Создаем скрипт синхронизации:

sudo nano /etc/ha.d/resource.d/sync-web

#!/bin/bash
case "$1" in
    start)
        rsync -av /var/www/ node2:/var/www/
        ;;
    stop)
        # Ничего не делаем
        ;;
    *)
        echo "Usage: $0 {start|stop}"
        exit 1
        ;;
esac

Альтернативные решения

Heartbeat — не единственное решение для обеспечения высокой доступности. Сравним с другими популярными инструментами:

Corosync + Pacemaker — более современная замена Heartbeat
Keepalived — легковесная альтернатива с VRRP
HAProxy + Keepalived — популярная связка для load balancing
Kubernetes — для контейнеризованных приложений

Статистика использования показывает, что:

Heartbeat используется в 23% legacy-систем
Keepalived — в 34% новых проектов
Pacemaker — в 28% enterprise-решений
Kubernetes — в 45% современных приложений

Расширенная конфигурация и автоматизация

Для автоматизации развертывания можно использовать Ansible-плейбук:

- name: Install Heartbeat
  apt:
    name: heartbeat
    state: present

- name: Configure Heartbeat
  template:
    src: ha.cf.j2
    dest: /etc/ha.d/ha.cf
  notify: restart heartbeat

- name: Set up authkeys
  template:
    src: authkeys.j2
    dest: /etc/ha.d/authkeys
    mode: '0600'

Интеграция с мониторингом (Prometheus + Grafana):

#!/bin/bash
# Скрипт для экспорта метрик Heartbeat
while true; do
    if pgrep heartbeat > /dev/null; then
        echo "heartbeat_status 1" > /var/lib/node_exporter/heartbeat.prom
    else
        echo "heartbeat_status 0" > /var/lib/node_exporter/heartbeat.prom
    fi
    sleep 30
done

Troubleshooting и частые проблемы

Самые распространенные проблемы и их решения:

Split-brain — оба узла считают себя активными

sudo /usr/lib/heartbeat/hb_standby
# На одном из узлов принудительно переходим в standby

Сетевые проблемы — heartbeat-пакеты не доходят

sudo tcpdump -i eth0 port 694
# Проверяем прохождение heartbeat-пакетов

Ресурсы не запускаются — проблемы с правами или конфигурацией
```
sudo chmod +x /etc/ha.d/resource.d/*
# Проверяем права на скрипты ресурсов
```

Безопасность и best practices

Рекомендации по безопасности:

Используйте выделенную сеть для heartbeat-трафика
Настройте firewall для порта 694
Регулярно меняйте ключи аутентификации
Мониторьте логи на предмет подозрительной активности

Конфигурация iptables:

sudo iptables -A INPUT -p udp --dport 694 -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 694 -j DROP

Интеграция с облачными провайдерами

При работе с облачными провайдерами (AWS, GCP, Azure) нужно учитывать специфику их сетевых решений. Многие провайдеры предоставляют собственные механизмы floating IP, которые могут работать эффективнее классического Heartbeat.

Для AWS можно использовать Elastic IP в связке с AWS CLI:

#!/bin/bash
# Скрипт для переключения Elastic IP
aws ec2 associate-address --instance-id i-1234567890abcdef0 --allocation-id eipalloc-64d5890a

Заключение и рекомендации

Heartbeat остается актуальным решением для обеспечения высокой доступности, особенно в legacy-системах и простых конфигурациях. Это надежный инструмент, который проверен временем и подходит для большинства задач failover.

Рекомендую использовать Heartbeat в следующих случаях:

Простые двухузловые кластеры
Legacy-системы, где нет возможности перейти на современные решения
Ситуации, где нужна максимальная простота и надежность
Небольшие проекты без сложных требований к оркестрации

Для новых проектов стоит рассмотреть альтернативы:

Keepalived — для простых задач с VRRP
Pacemaker — для сложных кластерных конфигураций
Kubernetes — для контейнеризованных приложений
Облачные решения — для инфраструктуры в cloud

Помните, что высокая доступность — это не только технические решения, но и процессы: мониторинг, резервное копирование, документирование процедур и регулярное тестирование failover-сценариев. Только комплексный подход гарантирует реальную надежность вашей системы.

Для получения дополнительной информации рекомендую изучить официальную документацию:

В этой статье собрана информация и материалы из различных интернет-источников. Мы признаем и ценим работу всех оригинальных авторов, издателей и веб-сайтов. Несмотря на то, что были приложены все усилия для надлежащего указания исходного материала, любая непреднамеренная оплошность или упущение не являются нарушением авторских прав. Все упомянутые товарные знаки, логотипы и изображения являются собственностью соответствующих владельцев. Если вы считаете, что какой-либо контент, использованный в этой статье, нарушает ваши авторские права, немедленно свяжитесь с нами для рассмотрения и принятия оперативных мер.

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