DRBD [362.1]

Рейтинг: 61% · 6 голосов
Специализация LPIC-3 306 (v3.0): кластеры HA (Pacemaker/Corosync), балансировка (LVS, keepalived, HAProxy), DRBD, кластерные и распределённые ФС (GFS2, OCFS2, GlusterFS, Ceph), iSCSI/multipath, advanced RAID/LVM.
Ответить
Аватара пользователя
Sergey_Sysadmin
Сообщения: 134
Зарегистрирован: 11 май 2026, 05:31

DRBD [362.1]

Сообщение Sergey_Sysadmin »

Оглавление курса (14)
  1. Введение в LPIC-3 306: высокая доступность и хранилища
  2. Концепции и теория высокой доступности [361.1]
  3. Кластеры с балансировкой нагрузки [361.2]
  4. Failover-кластеры: Corosync и Pacemaker [361.3, часть 1]
  5. Pacemaker: ресурсы, ограничения, fencing [361.3, часть 2]
  6. DRBD [362.1] (вы здесь)
  7. Доступ к кластерному хранилищу [362.2]
  8. Кластерные файловые системы [362.3]
  9. Распределённое хранилище GlusterFS [363.1]
  10. Ceph: архитектура [363.2, часть 1]
  11. Ceph: использование и эксплуатация [363.2, часть 2]
  12. Отказоустойчивость узла: железо и сервисы [364.1]
  13. Продвинутый RAID
  14. Продвинутый LVM и сетевая отказоустойчивость [364.3 + 364.4]
Урок 5. DRBD [362.1]

DRBD (Distributed Replicated Block Device) решает задачу, которую не закрывает обычный RAID: он зеркалит блочное устройство не на соседний диск, а на диск другого сервера через сеть. По сути это сетевой RAID-1 уровня ядра. Администратору это нужно там, где надо держать одни и те же данные синхронно на двух (а в DRBD 9 и больше) узлах, чтобы при падении одного второй мгновенно подхватил сервис без потери записей. В этом уроке разберём протоколы репликации A/B/C, настройку через drbdadm, первую синхронизацию и роли primary/secondary, связку с Pacemaker для автопереключения, управление парком ресурсов через LINSTOR и, главное, как выходить из split-brain.

Изображение

Как это работает

DRBD вклинивается между файловой системой и реальным диском. Приложение пишет в устройство /dev/drbd0, модуль ядра дублирует запись: одну копию на локальный backing device, вторую отправляет по TCP (или RDMA) на узел-партнёр. Когда удалённый узел подтвердил запись, DRBD сообщает приложению, что блок сохранён. Насколько рано приходит это подтверждение - и определяет протокол.

Протокол A (асинхронный): локальная запись завершена, как только данные ушли в TCP-буфер отправки. Быстро, но при падении узла данные из буфера теряются. Годится для репликации на дальние плечи, где задержка велика. Протокол B (полусинхронный, memory-synchronous): подтверждение приходит, когда пакет принят удалённым ядром, но ещё не лёг на его диск. Компромисс, используется редко. Протокол C (синхронный): запись считается завершённой только после того, как партнёр записал блок на свой диск. Это единственный режим с настоящей гарантией - данные есть на обоих узлах. В кластерах высокой доступности применяют почти исключительно C.

В DRBD 9 ушла главная боль восьмёрки: появился механизм quorum. Узел сам себя демонтирует из primary (замораживает или сбрасывает I/O), если теряет большинство голосов. Это убивает причину split-brain в зародыше, а не лечит последствия. LINSTOR при создании ресурса с двумя репликами по умолчанию доставляет третью бездисковую (diskless) реплику-арбитра, чтобы кворум был нечётным.

Split-brain - это ситуация, когда оба узла побывали primary независимо, у каждого свои изменения, и DRBD после восстановления связи отказывается сливать данные автоматически: он не знает, чьи записи важнее. Лечится выбором жертвы, чьи изменения выкидываются.

Команды и примеры

Установка. Debian 13 / Ubuntu 24.04:

Код: Выделить всё

apt install drbd-utils
modprobe drbd
RHEL 10 / Fedora 41+ (модуль чаще из ELRepo или DKMS от LINBIT, утилиты - из репозитория):

Код: Выделить всё

dnf install drbd-utils kmod-drbd
modprobe drbd
Описываем ресурс в /etc/drbd.d/r0.res. Идентичный файл должен лежать на ОБОИХ узлах:

Код: Выделить всё

resource r0 {
    protocol C;
    net {
        verify-alg sha256;
        # после split-brain в роли primary/secondary - откатить secondary
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }
    options {
        quorum majority;
        on-no-quorum io-error;
    }
    on node-a {
        device    /dev/drbd0;
        disk      /dev/vg0/lv_data;
        address   10.0.0.1:7788;
        meta-disk internal;
    }
    on node-b {
        device    /dev/drbd0;
        disk      /dev/vg0/lv_data;
        address   10.0.0.2:7788;
        meta-disk internal;
    }
}
Создаём метаданные и поднимаем ресурс на обоих узлах:

Код: Выделить всё

drbdadm create-md r0
drbdadm up r0
drbdadm status r0
Первичная синхронизация. Сразу после create-md оба узла в состоянии Inconsistent - DRBD не знает, чьи данные эталон. Назначаем эталон ТОЛЬКО на одном узле, форсируя его в primary:

Код: Выделить всё

drbdadm primary --force r0
Пойдёт фоновая синхронизация (видно в drbdadm status как percent-выполнено). Дождитесь UpToDate/UpToDate. Теперь можно создать ФС поверх /dev/drbd0 на primary:

Код: Выделить всё

mkfs.ext4 /dev/drbd0
mount /dev/drbd0 /mnt/data
Ручное переключение ролей (для теста, не в боевом кластере с Pacemaker):

Код: Выделить всё

# на бывшем primary
umount /mnt/data
drbdadm secondary r0
# на втором узле
drbdadm primary r0
mount /dev/drbd0 /mnt/data
Интеграция с Pacemaker. Ролями DRBD должен рулить кластер, не руки. Заводим promotable-клон (в современном pcs это пришло на смену старым master/slave-ресурсам):

Код: Выделить всё

pcs resource create drbd_r0 ocf:linbit:drbd drbd_resource=r0 \
    op monitor interval=20s role=Promoted \
    op monitor interval=30s role=Unpromoted
pcs resource promotable drbd_r0 promoted-max=1 promoted-node-max=1 \
    clone-max=2 clone-node-max=1 notify=true
Дальше монтирование привязываем к роли Promoted через constraint, чтобы ФС поднималась только на том узле, где DRBD стал primary. Важное правило: при использовании ocf:linbit:drbd запретите автозапуск drbd через systemd (systemctl disable drbd) - стартом и сменой ролей должен заниматься исключительно ресурс-агент.

LINSTOR. Когда ресурсов десятки, .res-файлы руками не ведут. LINSTOR - это управляющий слой: controller хранит описание, satellite на каждом узле дёргает drbdadm. Базовый поток:

Код: Выделить всё

linstor node create node-a 10.0.0.1
linstor storage-pool create lvm node-a pool0 vg0
linstor resource-definition create db
linstor volume-definition create db 50G
linstor resource create db --auto-place 2
Разрешение split-brain. Признак - в логах Split-Brain detected, статус StandAlone. Выбираем жертву (узел, чьи изменения НЕ нужны) и на ней:

Код: Выделить всё

drbdadm secondary r0
drbdadm connect --discard-my-data r0
На уцелевшем узле (survivor), если он сам отвалился в StandAlone:

Код: Выделить всё

drbdadm connect r0
После этого жертва откатится и синхронизируется с survivor.

Частые грабли
  • Запустить mkfs или mount на узле в роли secondary - устройство там read-only и недоступно, файловую систему монтируют только на primary.
  • Дать обоим узлам primary --force в ходе первой синхронизации - получите искусственный split-brain на ровном месте. Эталон форсируют только на одном.
  • Оставить drbd под управлением systemd при работе с Pacemaker - кластер и init подерутся за роли, ресурс будет флапать.
  • Понадеяться на after-sb-* как на защиту. Это политики автослияния уже СЛУЧИВШЕГОСЯ split-brain, и они могут молча выкинуть нужные данные. Реальная защита - quorum и фенсинг.
  • allow-two-primaries без кластерной ФС (GFS2/OCFS2) поверх - две обычные ext4-записи разнесут данные в труху.
  • Несовпадающие .res-файлы на узлах или забытый firewall на порту 7788 - ресурс не соединится, висит в WFConnection.
  • Внутренние метаданные (meta-disk internal) съедают место в конце backing-устройства. Если LV занят данными под завязку, create-md не разместит метаданные.
Мини-лаба
  • Поднимите две ВМ (node-a, node-b), на каждой выделите LV одинакового размера в vg0.
  • Установите drbd-utils, напишите идентичный /etc/drbd.d/r0.res с протоколом C и quorum majority.
  • Выполните create-md и up на обоих, проверьте drbdadm status - должно быть Inconsistent/Inconsistent.
  • На node-a сделайте primary --force, дождитесь UpToDate, создайте ext4 и запишите файл.
  • Переключите роли вручную (secondary на A, primary на B), убедитесь, что файл виден на B.
  • Спровоцируйте split-brain: оборвите сеть между узлами и сделайте обоих primary, затем верните сеть и разрулите через discard-my-data.
  • Соберите Pacemaker-кластер с promotable-клоном drbd_r0 и проверьте автоперенос роли при standby узла.
Контрольные вопросы
  • Чем гарантия протокола C отличается от A и B, и почему именно C берут в HA-кластеры?
  • Что произойдёт с I/O на primary, если задан quorum majority и on-no-quorum io-error, а узел потерял связь с большинством?
  • Какую роль играет diskless-реплика, которую LINSTOR добавляет по умолчанию к двум репликам?
  • Почему drbd нужно убрать из автозапуска systemd при управлении через Pacemaker, и кто тогда меняет роли?
  • Чем отличаются действия на узле-жертве и на узле-выжившем при ручном разрешении split-brain?
  • Что делает promotable-клон ocf:linbit:drbd и зачем ему параметры promoted-max и notify=true?
👍4 ❤️3 🔥1 😄 🤔3
Аватара пользователя
maryo
Сообщения: 1
Зарегистрирован: 16 май 2026, 12:15

Re: DRBD [362.1]

Сообщение maryo »

А если оба узла в StandAlone после обрыва, на survivor тоже руками connect делать или он сам подцепится когда жертва откатится?
👍1 ❤️ 🔥1 😄 🤔1
Аватара пользователя
bun_coder
Сообщения: 1
Зарегистрирован: 19 май 2026, 06:54

Re: DRBD [362.1]

Сообщение bun_coder »

На проде словил флап ролей пока не выключил systemctl disable drbd - реально кластер и systemd дрались за primary, спасибо что вынесли это в грабли отдельно
👍 ❤️1 🔥 😄 🤔
Ответить
← Предыдущая глава
Pacemaker: ресурсы, ограничения, fencing [361.3, часть 2]
Следующая глава →
Доступ к кластерному хранилищу [362.2]

Все главы курса «LPIC-3 306: высокая доступность и хранилища»

Поделиться темой: ✈ Telegram VK

Вернуться в «LPIC-3 306: высокая доступность и хранилища»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость