DRBD: репликация блочного устройства между серверами

DRBD — модуль ядра и набор утилит, которые превращают локальный блочный диск в сетевой RAID-1 между двумя серверами. Всё, что записано на первичном узле, синхронно уходит на вторичный. Это не резервное копирование и не замена снапшотам, но надёжный способ пережить отказ одного сервера без потери данных. Ниже — установка, конфигурация, первичная синхронизация и разбор аварийных ситуаций.

Что даёт DRBD и чего не даёт

DRBD работает на уровне блока, ниже файловой системы. Это значит, что поверх него можно положить ext4, XFS или LVM, и приложение не заметит подмены. Синхронный режим подтверждает запись только после того, как её получил второй узел, поэтому при аварии данные не теряются.

Ограничения важны не меньше преимуществ. DRBD не защищает от логических ошибок: удаление файла реплицируется мгновенно. Он не заменяет бэкап, не работает как активный-активный для обычных файловых систем и требует отдельного диска или раздела. Кроме того, между узлами нужен стабильный канал с низкой задержкой.

Подготовка дисков и установка

Возьмите одинаковые по размеру разделы на обоих серверах. Если диск больше 2 ТБ, используйте GPT и раздел, а не целый диск без таблицы. Установите утилиты и загрузите модуль ядра.

sudo apt install drbd-utils
sudo modprobe drbd
lsmod | grep drbd
sudo drbdadm --version

Проверьте, что имена узлов совпадают с теми, что вы укажете в конфигурации. DRBD идентифицирует партнёров по hostname, и расхождение — частая причина, по которой ресурс не поднимается. Убедитесь также, что порт 7788 открыт только между двумя серверами.

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

Современный формат — отдельный файл на ресурс в каталоге /etc/drbd.d. В примере используется устройство /dev/drbd0, локальный диск /dev/vdb1 и два узла с адресами 10.0.0.21 и 10.0.0.22.

resource r0 {
    protocol C;
    device /dev/drbd0;
    disk /dev/vdb1;
    meta-disk internal;

    on node1 {
        address 10.0.0.21:7788;
    }
    on node2 {
        address 10.0.0.22:7788;
    }
}

Протокол C означает синхронную запись с подтверждением от партнёра. Протокол A быстрее, но допускает потерю последних данных при аварии, протокол B — компромисс. Для баз данных выбирайте C и следите за задержкой сети: каждая запись ждёт ответа второго узла.

Первичная синхронизация

Метаданные создаются один раз на каждом узле. Команда create-md откажется работать, если на диске уже есть данные или старая подпись. Затем ресурс поднимается, и один узел назначается первичным с принудительной синхронизацией.

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

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

Посмотреть прогресс можно через /proc/drbd в старых версиях или через drbdadm status в DRBD 9. Не запускайте синхронизацию одновременно в обе стороны: это гарантированный конфликт.

Файловая система и переключение ролей

Файловую систему создают только на первичном узле и только после завершения синхронизации. На вторичном узле монтировать устройство нельзя — ядро не даст это сделать, пока роль не изменена.

sudo mkfs.ext4 /dev/drbd0
sudo mount /dev/drbd0 /srv/data
sudo drbdadm secondary r0
sudo drbdadm primary r0

При переключении порядок обратный: размонтируйте файловую систему, переведите узел в secondary, затем на другом узле выполните primary и смонтируйте. Автоматизировать это удобно через systemd-юниты или Pacemaker, но сначала отработайте вручную.

Split-brain и восстановление

Если связь между узлами пропала, а оба продолжали записывать, DRBD обнаружит расхождение и перейдёт в состояние StandAlone или SplitBrain. Это защита от тихого повреждения данных: система не знает, какая копия правильная.

Восстановление требует решения человека. Определите, на каком узле данные актуальнее, и выберите его источником. Второй узел придётся отбросить — все изменения на нём будут потеряны.

# на узле с устаревшими данными
sudo drbdadm disconnect r0
sudo drbdadm connect --discard-my-data r0
# на узле с актуальными данными
sudo drbdadm primary --force r0

Команда discard-my-data выполняется на узле, который вы признали устаревшим. После этого запускается полная или частичная ресинхронизация. Никогда не применяйте её на узле с актуальными данными — восстановить их будет нечем.

Политика поведения после сбоя

Автоматика не должна угадывать, чьи данные правильные. Явные правила в секции net снимают неопределённость и не дают узлам молча разойтись. Политика discard-zero-changes безопасна: она отбрасывает узел только тогда, когда на нём нет ни одной записи, отличающейся от партнёра. Добавьте этот блок внутрь уже описанного ресурса r0.

net {
    after-sb-0pri discard-zero-changes;
    after-sb-1pri discard-secondary;
    after-sb-2pri disconnect;
}

Для двух первичных узлов оставляйте disconnect: пусть администратор разберётся вручную. Автоматическое разрешение конфликта удобно, но однажды оно выберет не ту сторону. Перед изменением политики проверьте её на стенде, где данные не жалко потерять.

Мониторинг

Следите не только за статусом Connected, но и за отставанием репликации, количеством ошибок и состоянием диска. События удобно читать через drbdsetup events2, а метрики — через node_exporter или собственный скрипт.

sudo drbdadm status r0
sudo drbdsetup status r0 --verbose
sudo drbdsetup events2 --statistics
sudo journalctl -k -n 50 --no-pager

Тревога должна срабатывать на состояния StandAlone, WFConnection, SyncTarget и Diskless. Состояние Diskless означает, что локальный диск недоступен, и узел работает только как получатель — это авария, а не норма. Порог задержки репликации зависит от нагрузки и типа диска, поэтому измерьте нормальное значение заранее и опирайтесь на него, а не на условные секунды из чужой статьи.

Чек-лист

• Разделы на обоих узлах одинакового размера, метаданные созданы.
• Порт 7788 открыт только между партнёрами.
• hostname в конфигурации совпадает с реальным именем узла.
• Протокол репликации выбран осознанно, задержка сети измерена.
• Порядок переключения ролей описан и протестирован.
• Настроены оповещения о SplitBrain, StandAlone и Diskless.
• Есть независимый бэкап: DRBD не защищает от удаления файлов.

Итог

DRBD даёт прозрачную репликацию блока и позволяет пережить отказ сервера без потери данных. Цена — дисциплина в переключении ролей и внимание к состоянию репликации. Начните с тестового стенда, проверьте аварию и восстановление, и только после этого переносите на production. И помните: реплика не отменяет резервное копирование.