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

Ви налаштували HA-кластер, але при падінні однієї ноди дані втрачаються — база даних не може переключитися без загального сховища. Купувати SAN дорого і вимагає спеціального обладнання, а DRBD працює по Ethernet і не має таких вимог. Наша компанія має 7+ років досвіду налаштування DRBD, 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 мс в локальній мережі. DRBD в 10 разів дешевший за апаратний SAN за початковими витратами.

Обов'язковість протоколу C для баз даних: Протокол C гарантує, що запис підтверджується тільки після фіксації на обох вузлах. Для транзакційних систем (PostgreSQL, MySQL, 1С) це єдиний прийнятний варіант. Протокол A (асинхронний) втрачає останні записи при відмові primary, протокол B (напівсинхронний) — при одночасній відмові обох. На одному з проектів клієнт обрав протокол A для економії затримок, і при збої живлення втратив 300 секунд транзакцій. Після переходу на протокол C інциденти з втратами даних припинилися.

Конфігурація та ініціалізація DRBD

1. Встановлення на обох серверах (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 

   Для великих дисків (наприклад, 1 ТБ) повна синхронізація займає близько 4 годин при швидкості 70 МБ/с. --clear-bitmap каже DRBD вважати обидва диски ідентичними — тільки якщо ви знаєте, що обидва диски чисті. Для вже існуючих даних — повна синхронізація обов'язкова.

   Уникнення split-brain та типові помилки

   Split-brain — найнебезпечніша ситуація в DRBD. Щоб її уникнути, використовуйте:

   • STONITH — примусове відключення ноди при збої. Без STONITH при втраті зв'язку обидві ноди можуть спробувати стати primary — гарантований split-brain.
   • Обмеження ролей: тільки один primary в кластері (master-max=1).
   • Правильні політики after-sb-*: after-sb-2pri disconnect.

   Типові помилки:

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

   Якщо split-brain стався, ручне відновлення:

   # На тій ноді, дані якої жертвуємо
   drbdadm disconnect r0
   drbdadm -- --discard-my-data connect r0
   # На тій ноді, дані якої зберігаємо
   drbdadm connect r0

   Після цього починається повна ресинхронізація (наприклад, 20% за 30 хвилин для диска 500 ГБ). До її завершення захист від наступної відмови відсутній.

   Інтеграція з 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.

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

   Порівняння DRBD та апаратного SAN

   Характеристика	DRBD + Pacemaker	Апаратний SAN
   Вартість (початкова)	Не вимагає додаткових витрат на обладнання	Значні капітальні вкладення (від 50 000 USD)
   Затримка запису	0.5–2 мс (синхронна)	<0.3 мс
   Максимальний розмір сховища	Обмежений дисками серверів (до 10 ТБ типово)	Теоретично не обмежений
   Складність адміністрування	Середня	Висока (потрібна сертифікація)
   Час відновлення після відмови	<30 с (автомат)	<10 с (апаратний failover)

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

   Обсяг робіт та терміни

   При замовленні налаштування DRBD під ключ ми надаємо:

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

   Терміни:

   Сценарій	Час
   Налаштування DRBD + ручний failover	2 дні
   +Pacemaker, автоматичний failover	3 дні
   +STONITH, тестування сценаріїв відмови	+1 день

   Вартість налаштування починається від 1500 USD і розраховується індивідуально після аудиту інфраструктури. Отримайте консультацію та оцінку вашого проекту. Наші інженери з 7-річним досвідом допоможуть налаштувати надійну відмовостійкість. Замовте аудит — ми підберемо оптимальну конфігурацію.