PostgreSQL Active/Passive с Pacemaker и DRBD

Кратко: пошагово настраиваем Active/Passive кластер PostgreSQL на двух узлах с использованием DRBD для синхронной репликации блоков, Corosync для транспорта сообщений кластера и Pacemaker как менеджера ресурсов. В статье — подготовка сети и дисков, базовая конфигурация DRBD, интеграция с Pacemaker, тестирование переключения, план отката и рекомендации по безопасности и мониторингу.

Важно: пример рассчитан на CentOS 5.5 (64-бит). Принципы применимы и к другим RHEL-подобным дистрибутивам, но пути пакетов и команды могут отличаться.

Введение

Цель — получить отказоустойчивый PostgreSQL в режиме Active/Passive. Один узел принимает запросы (active), второй — резервный (passive). При падении активного узла пассивный автоматически становится активным. DRBD реплицирует блочные изменения между узлами в реальном времени; Pacemaker+Corosync управляют ресурсами и принимают решения о фейловере.

Краткое определение терминов:

DRBD — блочная репликация данных по сети (аналог аппаратного зеркалирования на уровне сети).
Corosync — транспорт сообщений и кластерный слой (membership, messaging).
Pacemaker — менеджер ресурсов (CRM), который стартует/останавливает сервисы и принимает решения о перемещении ресурсов.

Важно: DRBD реплицирует всё, что лежит на блочном устройстве (например, /dev/drbd0). На это устройство следует поместить PostgreSQL data directory (PGDATA).

Схема сети и номенклатура

В примере используются два физических узла:

node1.clusterbr.int — LAN 10.0.0.191, cross-over 172.16.0.1
node2.clusterbr.int — LAN 10.0.0.192, cross-over 172.16.0.2
dbip.clusterbr.int — виртуальный (floating) IP 10.0.0.190 — IP, на который направляют приложения

Сеть: на каждом узле по 2 гигабитных интерфейса: eth0 — LAN, eth1 — кроссовер для DRBD. Кроссовер снижает зависимость от сетевого коммутатора и повышает производительность репликации.

Диски: /dev/sda — система, /dev/sdb — выделенный диск/раздел для DRBD. Можно использовать раздел на одном диске, но важно, чтобы раздел/диск был выделен только под DRBD.

PostgreSQL: в примере версия 8.4, но инструкции по DRBD/Pacemaker релевантны и для более новых версий (за исключением ньюансов в пакетах и путях).

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

В этом блоке показаны базовые системные настройки, сети и проверки связи.

Отключение SELinux

Для упрощения примера SELinux отключается. В продакшне рассмотрите альтернативы (правильная политика SELinux и исключения).

vi /etc/selinux/config

Измените нужную строку:

SELINUX=disabled

Важно: отключение SELinux снижает уровень защиты. Если вы хотите сохранять SELinux включённым, придётся настроить политики для DRBD, PostgreSQL и Pacemaker.

Установка hostname и шлюза

Пример изменения сетевых опций:

vi /etc/sysconfig/network

Пример для node1:

NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=node1.clusterbr.int
GATEWAY=10.0.0.9

И для node2 аналогично меняем HOSTNAME на node2.clusterbr.int.

Конфигурация сетевых интерфейсов

Примеры конфигураций файлов в /etc/sysconfig/network-scripts/ для LAN (eth0) и кроссовера (eth1).

node1, eth0 (LAN):

vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=static
IPADDR=10.0.0.191
NETMASK=255.255.255.0
ONBOOT=yes
HWADDR=a6:1e:3d:67:66:78

node1, eth1 (cross-over):

vi /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
BOOTPROTO=static
IPADDR=172.16.0.1
NETMASK=255.255.255.0
ONBOOT=yes
HWADDR=ee:ef:ff:9a:9a:57

Аналогично для node2 с соответствующими IP и MAC.

DNS и /etc/hosts

Настройте /etc/resolv.conf и /etc/hosts на обоих узлах:

vi /etc/resolv.conf

search clusterbr.int
nameserver 10.0.0.9

vi /etc/hosts

127.0.0.1               localhost.localdomain localhost
10.0.0.191              node1.clusterbr.int   node1
10.0.0.192              node2.clusterbr.int   node2
10.0.0.190              dbip.clusterbr.int   node2

Примечание: IP виртуального интерфейса dbip в /etc/hosts указывает на node2 в примере; при фейловере Pacemaker будет перемещать IP между нодами.

Проверка сетевой связности

Проверяем пинги по LAN и кроссоверу. Пример:

ping -c 2 node2
ping -c 2 172.16.0.2

Убедитесь, что оба интерфейса работают и RTT приемлемый.

Инициализация/Runlevel

Автор предпочитает runlevel 3. Изменение:

vi /etc/inittab

id:3:initdefault:

Удалите автозапуск сервисов, которые будут управляться Pacemaker (PostgreSQL, DRBD). Они не должны быть в автозапуске, иначе возможны конфликты с CRM.

Проверка списка сервисов:

chkconfig --list | grep 3:sim

Перезагрузите узлы после всех изменений:

reboot

Установка пакетов и зависимостей

Устанавливаем PostgreSQL, компиляторы/утилиты и репозитории EPEL/ClusterLabs.

yum install -y postgresql84
gcc perl-mailtools perl-dbi php-pgsql

Добавляем EPEL (пример для CentOS 5 x86_64 — при использовании другой версии измените URL):

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm

Добавляем репозиторий ClusterLabs:

wget -O /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo

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

yum install -y pacemaker corosync drbd83 kmod-drbd83 heartbeat

Примечание: в зависимости от репозиториев названия пакетов и версии могут отличаться. DRBD 8.3 и drbd83 — пример.

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

DRBD обеспечивает зеркалирование блочного устройства. Далее — минимальная последовательность действий и пример конфигурации.

Создайте файл /etc/drbd.conf или включите ресурс в /etc/drbd.d/. Пример ресурса r0:

resource r0 {
  protocol C;
  on node1.clusterbr.int {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   172.16.0.1:7789;
    meta-disk internal;
  }
  on node2.clusterbr.int {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   172.16.0.2:7789;
    meta-disk internal;
  }
}

Объяснение:

protocol C — синхронная репликация (запись считается успешной после записи на оба узла). Это обеспечивает целостность, но увеличивает задержки.
meta-disk internal — метаданные лежат в начале указанного диска/раздела. Можно использовать внешний метараздел.

Инициализация и поднятие устройства:

drbdadm create-md r0
service drbd start
drbdadm up r0

Первичность и начальная синхронизация (на одном узле, который содержит актуальные данные):

drbdadm -- --overwrite-data-of-peer primary r0

После этого устройство /dev/drbd0 доступно и его можно форматировать и монтировать.

Форматирование и монтирование:

mkfs.ext4 /dev/drbd0
mkdir -p /var/lib/pgsql/data
mount /dev/drbd0 /var/lib/pgsql/data
chown -R postgres:postgres /var/lib/pgsql/data

Инициализация PostgreSQL (если база ещё не создана):

su - postgres
/usr/pgsql-8.4/bin/initdb -D /var/lib/pgsql/data
exit

Важно: при первом создании данных делайте primary на той ноде, где вы хотите иметь стартовую копию. После initial sync устройство на вторичной ноде будет в состоянии Secondary.

Тестирование DRBD

На primary создайте файл в монтируемой файловой системе и проверьте его наличие на второй ноде после монтирования (после того как ресурс станет первичным/вторичным).

Интеграция с Pacemaker и Corosync

Pacemaker будет управлять ресурсами: DRBD, файловая система (mount), виртуальный IP и сервис PostgreSQL. Принцип: Pacemaker знает о состоянии DRBD и может переводить ресурс в primary/secondary и монтировать FS только на узле, который в роли primary.

Примерный набор ресурсов в Pacemaker (логическая последовательность):

DRBD resource (r0)
Promote/demote для DRBD (переход в primary)
Файловая система (mount) на /var/lib/pgsql/data
Виртуальный IP (10.0.0.190)
Сервис PostgreSQL

Пример конфигурации через crm shell (упрощённо):

crm configure primitive p_drbd ocf:linbit:drbd params drbd_resource="r0" op monitor interval="15s"
crm configure ms ms_drbd p_drbd meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify=true

crm configure primitive p_fs ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/var/lib/pgsql/data" fstype="ext4" op monitor interval="20s"
crm configure primitive p_ip ocf:heartbeat:IPaddr2 params ip="10.0.0.190" cidr_netmask="24" op monitor interval="10s"
crm configure primitive p_pg ocf:heartbeat:pgsql params pgctl="/usr/pgsql-8.4/bin/pg_ctl" pgha_datadir="/var/lib/pgsql/data" op monitor interval="15s"

# Зависимости: сначала master DRBD, затем FS, затем PostgreSQL и IP
crm configure order o_drbd_fs inf: ms_drbd:promote p_fs:start
crm configure colocation coloc_fs_on_drbd inf: p_fs ms_drbd:promoted
crm configure order o_fs_pg inf: p_fs:start p_pg:start
crm configure colocation coloc_pg_on_fs inf: p_pg p_fs
crm configure colocation coloc_ip_on_pg inf: p_ip p_pg

Примечание: точный синтаксис OCF-скриптов и параметры для pgsql зависят от поставщика ресурса. Проверьте, что используемые OCF-скрипты доступны в системе (обычно /usr/lib/ocf/resource.d/).

STONITH (fencing)

Крайне важно настроить fencing (STONITH). Без корректного fencing возможен split-brain и повреждение данных. Для продакшна обязательно обеспечить механизмы аппаратного или программного отрубания «потерявшего контакт» узла (например, через IPMI, DRAC, виртуальные гипервизоры и т.д.).

Важно: Pacemaker обычно не допускает работу без корректно настроенного STONITH — это требование целостности.

Тестирование и проверка переключения

План тестирования:

Убедиться, что на node1 ресурс промотирован в primary и PostgreSQL запущен.
На node1 остановить службу postmaster или выключить node1 (reboot/poweroff) и проследить, как Pacemaker переведёт DRBD в primary на node2, примонтирует FS и запустит PostgreSQL, а также назначит виртуальный IP.
Проверить доступность базы по dbip.clusterbr.int.
Восстановить node1 и вернуть ресурсы обратно (если это требуется).

Команды для ручного промотирования/демотирования (если нужно вмешаться):

# на узле, где хотим сделать primary
crm resource migrate ms_drbd 
# либо через drbdadm
drbdadm primary r0

Не забывайте, что при первичной синхронизации для задания данных команды:

drbdadm -- --overwrite-data-of-peer primary r0

План отката и инцидент-ранбуки

Если после тестирования система оказалась в неконсистентном состоянии (split-brain):

Остановите PostgreSQL на обеих нодах.
Остановите DRBD: service drbd stop.
Выясните, какая нода содержит актуальные данные (логи PostgreSQL, wal, время последних бэкапов).
Пометьте менее актуальную сторону как заблокированную и выполните перезапись данных с актуального узла:

drbdadm disconnect r0
drbdadm -- --overwrite-data-of-peer primary r0

Перезапустите drbd, поднимите primary и запустите PostgreSQL.

Важно: операции с drbdadm –overwrite-data-of-peer перезапишут данные и могут привести к потере данных. Используйте только после уверенности в актуальности источника.

Критерии приёмки

При отключении активного узла резервный поднимается в течение ожидаемого окна и принимает на себя виртуальный IP и сервис PostgreSQL.
Данные доступны и консистентны (нет повреждённых таблиц, WAL-логов).
После восстановления исходного узла кластер возвращается в ожидаемое состояние без ручных правок.
STONITH корректно завершает некорректно работающий узел в сценариях «split-brain».

Безопасность и жёсткие требования

Если SELinux отключён — обеспечьте иные слои защиты: firewall, доступ по SSH только по ключам, ограничение доступа к PostgreSQL (pg_hba.conf).
Ограничьте доступ к кроссовер-интерфейсу (eth1) — он должен быть доступен только между узлами кластера.
Настройте регулярное резервное копирование PostgreSQL (pg_basebackup, pg_dump) даже при наличии DRBD — DRBD не защищает от логических ошибок или удаления данных.
Обновляйте пакеты безопасности и планируйте окна обслуживания для обновления ядра/DRBD/CRM.

Роли и чек-листы (кто за что отвечает)

Администратор системы:

Подготовка ОС, репозиториев и пакетов.
Настройка сетей и разделов.
Настройка STONITH и аппаратных интерфейсов.

DBA:

Инициализация и настройка PostgreSQL.
Создание плана бэкапов и проверка восстановления.
Тестирование согласованности данных после фейловера.

Сетевой инженер:

Настройка VLAN/физических связей и резервных путей.
Контроль MTU/производительности между узлами.

Проверка работоспособности — тест-кейсы

Отключить node1: проверить, что node2 становится active и виртуальный IP доступен.
Отключить только сетевой интерфейс eth0 на node1: убедиться, что кластер реагирует (если настроено следующее поведение).
Выполнить write-heavy нагрузку и снять нагрузку на primary: проверить отсутствие разрыва синхронизации.
Смоделировать split-brain (искусственно заставить оба узла считать себя primary) и проверить поведение fencing и процедуры восстановления.

Альтернативные подходы и когда это не подходит

Альтернативы:

Streaming replication + repmgr (мастер/слейв на уровне PostgreSQL) — обеспечивает репликацию на уровне СУБД, удобен для более новых версий PostgreSQL.
Лёгкие решения уровня приложения (sharding, репликация) — применимы в других случаях.

Когда Active/Passive с DRBD не подходит:

Необходима горизонтальная масштабируемость для чтения (много реплик для чтения) — тогда лучше смотреть на асинхронную репликацию PostgreSQL.
Высокие требования по задержкам на записи: синхронный DRBD (protocol C) увеличит задержки записи.
Когда инфраструктура виртуализирована и нет доступа к уровню питания/STONITH — fencing может быть сложным.

Совместимость и миграционные заметки

CentOS 5.5 и пакеты drbd83/pacemaker из примера — историческая конфигурация. На современных системах (CentOS 7/8, RHEL 7/8) используются systemd, pcs и другие версии пакетов; синтаксис и сервисы отличаются.
При миграции на новую платформу проверьте версии DRBD, совместимость OCF-скриптов и пути бинарников PostgreSQL.

Факто-бокс (ключевые моменты)

Минимум узлов: 2 (active + passive).
DRBD protocol C — синхронная репликация (устойчивость в ущерб latency).
Необходим STONITH для защиты от split-brain.
Репликация на уровне блоков — копирует и ошибки приложения и бэкапы; нужен дополнительный уровень резервирования.

Примеры полезных команд для отладки

Проверка статуса DRBD:

drbdadm status
cat /proc/drbd

Проверка ресурсов Pacemaker/Corosync:

crm_mon -1
crm status

Просмотр логов:

/var/log/messages
/var/log/cluster/corosync.log
/var/log/heartbeat.log

Краткая методология внедрения (по шагам)

Подготовить ОС, настроить сети и диски.
Установить пакеты и репозитории.
Настроить DRBD, провести initial sync.
Отформатировать /dev/drbd0 и инициализировать PostgreSQL на primary.
Настроить Pacemaker/Corosync, создать ресурсы и зависимости.
Настроить STONITH.
Провести интеграционные тесты и тесты фейловера.
Настроить мониторинг и бэкапы.

Заключение

Active/Passive кластер с DRBD + Pacemaker + Corosync — рабочее решение для обеспечения высокой доступности PostgreSQL, когда важна целостность данных и минимизация простоев. Оно требует тщательной настройки сетей, DRBD и STONITH, а также регулярного тестирования фейловеров и бэкапов. В современных средах рассмотрите также возможности стриминговой репликации PostgreSQL и инструментов управления кластерами, совместимых с вашей версией ОС.

Важно: перед переносом в продакшн обязательно прогоните полный набор тестов фейловера и процедуру восстановления из бэкапа.

Короткая сводка (Summary)

DRBD зеркалит блоки, Pacemaker управляет ресурсами, Corosync обеспечивает коммуникацию.
Настройте STONITH, протестируйте фейловер и бэкапы.
Рассмотрите альтернативы для масштабирования чтения или снижения задержек записи.

Настройка Active/Passive кластера PostgreSQL с Pacemaker, Corosync и DRBD (CentOS 5.5)