Настройка DRBD для синхронной репликации в HA-кластере

Вы настроили HA-кластер, но при падении одной ноды данные теряются — база данных не может переключиться без общего хранилища. Покупать SAN дорого и требует специального оборудования, а DRBD работает по Ethernet и не имеет таких требований. Мы гарантируем, что при отказе одной ноды вторая мгновенно возьмёт нагрузку без потери данных за счёт синхронной репликации. Наш опыт — более 7 лет, 50+ внедрённых кластеров, средний uptime — 99.99%.

Как DRBD обеспечивает синхронную репликацию?

DRBD (Distributed Replicated Block Device) создаёт «сетевой RAID-1»: два сервера, два диска, синхронная репликация по TCP. Для ОС устройство /dev/drbd0 выглядит как обычный локальный диск — можно форматировать в ext4 или XFS, ставить базу данных (PostgreSQL, MySQL, 1С) и монтировать в кластер. При отказе primary-ноды secondary промоутируется и берёт нагрузку без потери данных. В отличие от SAN с его значительными капитальными затратами, DRBD не требует специального оборудования и даёт тот же уровень отказоустойчивости с задержками менее 1 мс в локальной сети.

Почему синхронная репликация (протокол C) обязательна для баз данных?

Протокол C гарантирует, что запись подтверждается только после фиксации на обоих узлах. Для транзакционных систем (PostgreSQL, MySQL, 1С) это единственный приемлемый вариант. Протокол A (асинхронный) теряет последние записи при отказе primary, протокол B (полусинхронный) — при одновременном отказе обоих. На одном из проектов мы столкнулись с ситуацией, когда клиент выбрал протокол A для экономии задержек, и при сбое питания потерял 5 минут транзакций. После перехода на протокол C инциденты с потерями данных прекратились.

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

Установка на обоих серверах (Debian/Ubuntu):

apt install drbd-utils modprobe drbd echo 'drbd' >> /etc/modules 

Конфигурация /etc/drbd.d/r0.res:

resource r0 {
    protocol C;
    disk {
        on-io-error detach;
        fencing resource-only;
    }
    net {
        max-buffers 8000;
        max-epoch-size 8000;
        sndbuf-size 1024k;
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }
    startup {
        wfc-timeout 30;
        degr-wfc-timeout 120;
    }
    on server1 {
        device /dev/drbd0;
        disk /dev/sdb;
        address 192.168.20.1:7788;
        meta-disk internal;
    }
    on server2 {
        device /dev/drbd0;
        disk /dev/sdb;
        address 192.168.20.2:7788;
        meta-disk internal;
    }
}

protocol C — синхронная репликация. Запись подтверждается только после того, как оба сервера записали данные на диск. Единственный безопасный протокол для баз данных. Протокол A (async) и B (semi-sync) допустимы только при медленных WAN-каналах и с пониманием возможной потери данных.

after-sb-0pri discard-zero-changes — политика разрешения split-brain при нулевом primary. after-sb-2pri disconnect — если оба считают себя primary, отключаемся и ждём ручного вмешательства.

Инициализация и первоначальная синхронизация

drbdadm create-md r0 drbdadm up r0 drbdadm -- --force primary r0 

Для больших дисков полная синхронизация занимает часы. --clear-bitmap говорит DRBD считать оба диска идентичными — только если вы знаете, что оба диска чистые. Для уже существующих данных — полная синхронизация обязательна.

Как избежать split-brain?

Split-brain — самая опасная ситуация в DRBD. Чтобы её избежать, используйте:

• STONITH — принудительное отключение ноды при сбое.
• Ограничение ролей: только один primary в кластере (master-max=1).
• Правильные политики after-sb-*: after-sb-2pri disconnect.

Если split-brain произошёл, ручное восстановление:

# На той ноде, данные которой жертвуем
drbdadm disconnect r0
drbdadm -- --discard-my-data connect r0
# На той ноде, данные которой сохраняем
drbdadm connect r0

После этого начинается полная ресинхронизация. До её завершения защита от следующего отказа отсутствует.

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

DRBD без кластерного менеджера — это ручное управление failover. В production нужен Pacemaker:

apt install pacemaker corosync pcs
pcs resource create drbd_r0 ocf:linbit:drbd \
  drbd_resource=r0 op monitor interval=30s role=Master
pcs resource master ms_drbd_r0 drbd_r0 \
  master-max=1 master-node-max=1
pcs resource create fs_data ocf:heartbeat:Filesystem \
  device=/dev/drbd0 directory=/data fstype=ext4
pcs constraint colocation add fs_data with ms_drbd_r0 INFINITY with-rsc-role=Master
pcs constraint order promote ms_drbd_r0 then start fs_data

Для надёжности добавляем STONITH: pcs stonith create fence_ipmilan с настройками IPMI. Без STONITH при потере связи обе ноды могут попытаться стать primary — гарантированный split-brain.

Сравнение DRBD и аппаратного SAN

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

Мониторинг DRBD

DRBD экспортирует статус через /proc/drbd. Для Prometheus — готовые экспортёры. Критические состояния: Inconsistent, Outdated, DUnknown. Норма — UpToDate/UpToDate на обеих нодах. Настройте алерты в Alertmanager на состояния, отличные от UpToDate.

Типичные ошибки при настройке DRBD

• Использование протокола A или B для баз данных — гарантированная потеря данных при отказе.
• Отсутствие STONITH — почти 100% вероятность split-brain при сетевых сбоях.
• Неправильная политика after-sb-2pri — если стоит discard-younger-primary, можно потерять последние записи на обеих нодах.
• Игнорирование задержек сети: синхронная репликация чувствительна к latency. Используйте выделенную VLAN с jumbo frames (MTU 9000) для трафика DRBD.
• Пропуск тестирования сценариев отказа: kill primary, разрыв сети, отключение питания. Без тестов runbook не имеет ценности.

Что входит в работу

При заказе настройки DRBD под ключ мы предоставляем:

• Проектирование схемы отказоустойчивости с учётом ваших приложений и топологии сети.
• Установку и конфигурацию DRBD на обеих нодах.
• Настройку Pacemaker + Corosync для автоматического failover.
• Интеграцию с существующей инфраструктурой (мониторинг, бэкапы).
• Документацию: runbook по восстановлению, схему репликации, конфиги.
• Обучение вашей команды (1–2 часа).
• Тестирование сценариев отказа (kill primary, разрыв сети).
• Гарантию на настройки — 3 месяца.

Сроки

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Получите консультацию и оценку вашего проекта. Наши инженеры с 7-летним опытом помогут настроить надёжную отказоустойчивость. Закажите аудит — мы подберём оптимальную конфигурацию.