DRBD 8 + Heartbeat 2: Active/Passive кластер для PostgreSQL без аппаратного RAID

Один из клиентов попросил нас поднять отказоустойчивость для PostgreSQL. База небольшая - учёт заказов, склад, 15 пользователей - но если она падает, работа встаёт. Покупать дорогой SAN с аппаратным кластером ни он, ни мы не хотели: смысл экономить на серверах, если потом доплачивать за «железный» HA в три цены?

Решение нашли в связке DRBD 8 и Heartbeat 2. Коротко: DRBD - это «сетевой RAID-1» на уровне блочного устройства, Heartbeat занимается мониторингом и переключением ресурсов. Вместе они дают Active/Passive кластер без общего хранилища.

Что собирали

Два идентичных сервера на CentOS 5.2, обычные SATA-диски, гигабитная сеть. Выделенный интерконнект между узлами - отдельный кабель, чтобы DRBD-трафик не мешал клиентскому. Никакого Fibre Channel, никаких полок.

Схема работы простая:

• Мастер держит DRBD-устройство в primary-режиме, на нём смонтирован /var/lib/pgsql, PostgreSQL работает.
• Резерв держит устройство в secondary-режиме, DRBD синхронно реплицирует каждую запись по сети.
• Heartbeat следит за мастером через несколько каналов (dedicated link + публичная сеть), при потере связи переводит резерв в primary и запускает PostgreSQL там.

Синхронная репликация на уровне блоков - главное отличие от инструментов вроде Slony-I или pgpool, которые работают на уровне SQL и добавляют свой слой сложности. Каждый fsync подтверждается только после записи на оба узла. Это стоит задержки, но зато при переключении данные актуальны на момент последней подтверждённой транзакции.

Конфигурация, которая у нас заработала

В /etc/drbd.conf главное - protocol C (синхронный), размер буфера и правило split-brain:

resource pgsql {
  protocol C;
  net {
    after-sb-0pri discard-younger-primary;
    after-sb-1pri call-pri-lost-after-sb;
  }
  disk {
    on-io-error detach;
  }
  on node1 { device /dev/drbd0; disk /dev/sdb1; address 192.168.10.1:7789; meta-disk internal; }
  on node2 { device /dev/drbd0; disk /dev/sdb1; address 192.168.10.2:7789; meta-disk internal; }
}

Heartbeat 2 с pacemaker управляет тремя ресурсами: DRBD (promote/demote), монтирование файловой системы и сам PostgreSQL. Порядок важен - без него pacemaker может попытаться запустить базу до того, как устройство станет primary.

В haresources это выглядит как цепочка: сначала DRBD-master, потом filesytem, потом PostgreSQL. С pacemaker это описывается через order и colocation constraints - немного многословно, зато явно.

Переключение: что реально происходит

Мы намеренно убивали мастер несколькими способами - halt -f, выдергивание кабеля питания, отключение интерконнекта. Результат стабильный: от момента потери связи до того, как PostgreSQL на резерве принимает подключения, проходит от 15 до 25 секунд.

Большая часть времени уходит не на переключение DRBD, а на таймауты Heartbeat - он по умолчанию ждёт несколько heartbeat-интервалов перед тем, как объявить узел мёртвым. Это сделано специально: слишком быстрое переключение при кратковременном флапе сети хуже, чем 20-секундный простой.

Один сценарий потребовал ручного вмешательства - split-brain при одновременном отключении обоих каналов связи (интерконнекта и публичной сети) при живом мастере. DRBD правильно остановил оба узла вместо того, чтобы угадывать, кто primary. Мы подняли вручную. Это не баг - это корректное поведение при полной потере связи: лучше остановиться, чем допустить два primary с разными данными.

Что важно учесть

Fencing (STONITH) - слабое место нашей конфигурации. Без него Heartbeat теоретически может переключиться на резерв, пока мастер ещё жив но недоступен по сети. Для полноценного production нужен либо IPMI/iDRAC для удалённого выключения, либо управляемый PDU. Мы добавили IPMI в список требований для следующего клиента.

Монитор DRBD надо включить в Zabbix или Nagios отдельно - стандартные проверки хоста не видят состояние синхронизации. Нам достаточно cat /proc/drbd и парсинга статуса, чтобы ловить ситуацию когда узлы разошлись (InconsistentData после сбоя узла и его подъёма).

Время пересинхронизации после отказа резервного узла и его возврата - зависит от размера тома и нагрузки на мастер. На нашем объёме (около 80 ГБ данных) полная пересинхронизация заняла несколько часов. В этот период кластер работает без резерва.

Итог

Для SMB-клиента без бюджета на SAN это вполне рабочее решение. DRBD 8 стабилен, Heartbeat 2 с pacemaker настраивается предсказуемо, 20 секунд переключения для PostgreSQL с учётом клиентских retry - приемлемо. Сопровождение такой конфигурации входит в рамки нашего управляемого обслуживания.

Главный вывод: основные риски не в самом DRBD, а в периметре - fencing, мониторинг состояния синхронизации, обработка split-brain. Вот где надо думать заранее, а не в момент инцидента.