Distributed Replicated Block Device - это сетевой RAID-1 на блочном уровне для linux систем. Он должен состоять из двух узлов, хотя возможны конфигурации, когда строятся цеопчки из DRBD-устройств. Поддеживается несколько режимов работы: Master/Slave и Master/Master. В первом случае запись возможна только на Master узле, во втором на любом узле. DRBD низкоуровневое устройство, т.е. оно оперирует с данными на блочном уровне, а не на уровне файловой системы. Таким образом, поверх DRBD-устройства может функционировать любая поддерживамая файловая система или виртуальная машина, например XEN, в общем с ним можно обращаться как с обычным жестким диском, создавать разделы, LVM-тома и т.д.

Существует три протокола синхронизации DRBD-устройств. Синхронный «C», когда запись считается завершенной только если оба узла сообщили об успешном выполнении операции. Асинхронный «A», когда запись выполнилась на локальном узле, а на удаленный узел данные только отправлены. И промежуточный вариант «B», когда запись выполнилась на локальном узле, а удаленный узел подтвердил получение данных(но не запись их!).

Работает DRBD на уровне ядра (как подгружаемый модуль). В качестве транспортного уровня используется протокол TCP 4 или 6 версии без шифрования и аутентификации. Также поддерживается некоторый экзотический протокол SuperSockets с низкими задержками, но он поддерживается только очень редким спецефическим оборудованием, в общем по факту этого протокола нет и о нем в большинстве случаев можно не думать Целостность передаваемых данных по каналам связи может контролироваться с помощью контрольных сумм, например md5.

Основная единица, с которой оперирует DRBD - ресурс. Серсурсом в данном контексте называется одно DRBD-устройство, у которого есть имя и номер(а также ряд других настроек, все это задается в конфигурационном файле). Имя ресурса используется при выполнении административных операций с помощью утилит администрирования, а номер(может начинаться с 0) - это порядковый номер DRBD-устройства /dev/drbdX.

Оба узла в нормальном режиме всегда имеют актуальную локальную копию ресурсов, т.к. при записе на мастере, данные тут же отображаются на слейве(в случае протокола С), но возможны ситуации, когда слейв был недоступен, а в этот момент выполнялась запись на мастер, тогда происходит рассинхронизация ресурсов. В таком случае ресурс на слейве получает статус Outdated. После восстановления связи, будет выполнена синхнронизация между мастером и слейвом.

Кроме автоматической синхронизации возможна автоматическая(с помощью cron) или ручная верификация данных. Т.е. на одном из узлов, считающимся эталонным, выполняется поблоковое чтение и рассчет контрольной суммы блока, которая затем передается на другой узел и там выполняется аналогичная операция, затем контрольные суммы сравниваются. Если они отличаются, то блок помечается как рассинхронизированный и в логи пишется сообщение. Затем может быть выполнена синхронизация. Для верификации не требуется отключение устройств, т.е. она может выполняться в онлайне. Верификация не сильно грузит сеть, т.к. передаются только контрольные суммы, а не сами не сами блоки данных. Но при этом процессор и дисковая подсистема испытывают ощутимую нагрузку.

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

У всех современных дисков и raid-контроллеров есть встроенный кеш, таким образом, при выполнении операций записи, они сообщают операционной системе о том, что операция завершилась, когда все данные влезли в кеш, но на самом деле еще могли не записаться на энергонезависимые носители. Это может привести к порче как самих данных, так и метаданных DRBD-устройств в случае сбоев электропитания. Чтобы предотвратить подобные ситуации, рекомендуется отключать встроенный кеш дисков и контроллеров(disk flushes). Но если raid-контроллер имеет на борту батарейку, которая позволит сохранить данные в кеше в случае непредвиденного отключения электропитания, disk flushes можно отключить, это может ощутимо повысить производительность операций записи.

Существует две стратегии обработки проблем с блочными устройствами поверх которых работает DRBD:

• Passing on I/O errors - если устройство сообщаем о проблемах с вводом/выводом, то эта ошибка передается дальше, на верхний уровень, например файловой системе, что в свою очередь может привести к перемонитированию ее в ремим только для чтения. Такой подход не обеспечивает отказоустойчивости и не рекомендуется к применению.
• Masking I/O errors - если устройство сообщаем о проблемах с вводом/выводом, то в зависимости от конфигурации, DRBD может выполнить detach для проблемного устройства и перевести его в режим diskless. Однако сама ошибка ввода/вывода никак не сообщается вверх по уровню, проблемный блок будет прочитан по сети на втором узле. Не смотря на то, что производительность при этом пострадается, система продложит функционировать.

Бывает несколько вариантов рассинхронизации данных: inconsistent и outdated. Первый случай может быть к примеру когда еще не выполнена первичная синхронизация данных, второй, когда случилась рассинхронизация по причине потери связи между узлами.

После создания, инициализации и синхронизации ресурса, один из узлов(или оба) становится мастером. Если перезагрузить слейв, то он после запуска подключится к мастеру и синхронизирует все изменения. Но если перезагрузить мастер, то он после загрузки станит в режим слейв. Т.е. оба узла будут в режиме слейв и нужно будет вручную повысить один из узлов до уровня мастер. Но как правило DRBD используется с системами кластеризации, такими как pacemaker, в этом случае все эти действия выполняет менеджер кластера.

В случае использования в качестве транспорта TCP, крайне желательно, даже настоятельно рекомендуется, соединять узлы между собой прямым соединением, т.е. без промежуточного свитча(кросс-кабелем). Это нужно для того, чтобы исключить дополнительную точку отказа на транспортном уровне, т.к. подобные сбои приносят большие проблемы(об этом ниже). Часто на практике используют резервирование каналов(linux bonding в режиме master/backup).

В случае потери канала связи, по которому происходит синхронизация и при этом используется система управления кластером, либо по другим причинам, например человекческий фактор, может сложиться такая ситуация, когда оба узла переходят в режим мастер, но при этом не синхронизируются друг с другом, в результате чего у каждого узла получается своя модифицированная версия данных, которую уже невозможно синхронизировать, это явление называется split brain.