DRBD

Создан: 29.09.2010
Модиф: 16.12.2015
Иванов Аркадий

 

Сохранность данных традиционно обеспечивается вторым диском, который работает как зеркало для первого. Этот режим называется RAID первого уровня (Redundant Array of Inexpensive Disks -  избыточный массив недорогих дисков). По другому -RAID-1.

 

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

 

Технология DRBD (Distributed Replicated Block Device - Распределённое Реплицируемое Блочное Устройство) стала уже даже частью ядра Linux. Именно с её помощью и делается репликация данных с устройств через сеть.

 

В этом материале я описываю решение простейшей задачи -  сделать сетевое зеркало раздела. Вся могучесть DRBD и совмещение DRBD с кластерными штучками типа Heartbeat или Pacemaker или rgmanager здесь не рассматривается. Полная современная документация находится на сайте разработчика: http://www.drbd.org/users-guide

 

Рассмотрим случай, когда на одной машине есть раздел ext3 с данными, который надо дублировать в сети на другой машине. DRBD находится в стеке обращений к диску ниже слоя файловой системы и поэтому для приложений слой DRBD соврешенно прозрачен. DRBD никак не может повлиять на слой управления файловой системой и наоборот.  DRBD просто по сети отправляет на машину-зеркало блоки, которые изменились на локальном диске. Можно настроить DRBD для раздела, где уже есть данные. Именно такой случай я и рассматриваю.

  • Машина источник данных называется "serv". Машина приёмник называется "double".
  • Раздел с данными на "serv" - /dev/sda4. Раздел на "double" - /dev/sda4.
  • На /dev/sda4 машины "serv" есть уже данные и файловая система ext3.
  • На /dev/sda4 машины "double" есть только файловая система

 

   Замечу, что развлекался я в Alt Linux p5 с ванильным ядром 2.6.35.5

   Шаги по созданию сетевого зеркала:

 

  • Скачиваем с сайта http://oss.linbit.com/drbd последнюю версию. У меня была 8.3.8.1.
  • Компилирую и устанавливаю утилиты DRBD в систему.
    - Следует запустить autogen.sh
    - Он мне посоветовал затем запустить конфигурирование со следующими параметрами:
    ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
     
  • Модуль DRBD беру в ядре, а не собираю из дистрибутива. С ядром 2.6.35.5 попался на то, что модуль из дистрибутива не захотел компиляться (дистр DRBD не соответствовал изменениям в ядре).
    modprobe drbd
     
  • С помошью parted/gparted освобождаю на "double" место на диске, куда будут реплицироваться данные.
     
  • Смотрю fdisk-ом размер раздела sda4 на "serv" и делаю fdisk-ом раздел такого же размера на машине "double".
     
  • Создаю файловую систему на машине "double":
    mkfs -t ext3 /dev/sda4
     
  • Размонтирую файловые системы /dev/sda4 на обеих машинах.
     
  • Прогоняю fsck на обеих машинах:
    e2fsck -f /dev/sda4
     
  • DRDB использует МЕТАДАННЫЕ для синхронизации (в них хранится, например, перечни блоков для репликации). МЕТАДАННЫЕ можно хранить отдельно от реплицируемой файловой системы, а можно и в том же разделе. Чтобы хранить их в том же разделе, надо откусить кусочек от файловой системы, созданной в этом разделе. Приблизетельный размер, занимаемый МЕТАДАННЫМИ вычисляется по правилу:
    M < C/32768 + 72,  где
    - M - размер метаданных. в секторах
    - С - размер реплицируемого раздела. в секторах

    Чтобы узнать размер устройства в секторах, используйте:
    blockdev --getsz /dev/sda4

    По указанной формуле вычисляю размер , на сколько надо будет уменьшить размер файловой системы в разделе, чтобы оставить место для МЕТАДАННЫХ DRDB и после уменьшаю файловые системы на обеих машинах. Делается это с помощью программы resize2fs:

    resize2fs /dev/sda4 521300000s 
     
  • Теперь на обеих машинах настраиваю одинаковый /etc/drbd.conf и поясню секции и параметры конфигурации:
    global { usage-count yes; }
    common { protocol C; }
    resource r0 {
       syncer { rate 5M; } 
       on serv {
          device /dev/drbd1;
          disk /dev/sda4;
          address 192.168.1.1:7789;
          meta-disk internal;
        }
        on double {
            device /dev/drbd1;
            disk /dev/sda4;
            address 192.168.1.2:7789;
            meta-disk internal;
         }
    }
    • в секции global параметр usage-count говорит о том, что при установке и первом запуске DRBD следует отослать сообщение разработчикам, которое учтётся в общемировой статистике использования DRBD на сайтеhttp://usage.drbd.org.
    • в секции common указываю тип протокола синхронизации между узлами. 
      A - асинхронный, приложения получают от драйвера статус SUCCESS сразу при записи на Primary хосте, ещё до того, как данные будут отправлены и записаны на Secondary хосте.
      B - полусинхронный, приложения получают от драйвера статус SUCCESS после того, как в память на Secondary хосте прилетели данные от Primary.
      C - синхронный, приложения получают от драйвера статус SUCCESS только после того, как данные будут записаны  на диск на Secondary хосте
    •  В секции описания ресурсов должны быть указаны
      - полные имена машин. Если в сети используются не короткие имена, то на месте serv и double д.б. serv.mydomain и double.mydomain.
      - устройства, используемые DRBD,
      - тип хранения метаданных (у меня метаданные хранятся на том же разделе) - internal.
      - IP-адрес и порт использумые на хосте. Обратите внимание на то, чтобы firewall не запрещал соединения с этими хостами и портами.
      - Параметром syncer задаётся максимальная скорость синхронизации в байтах в секунду.
       
  • На обеих машинах запускаю создание метаданных:
    drbdadm create-md r0
     
  • Подключаю устройство хранения данных:
    drbdadm attach r0
     
  • Настраиваю параметры синхронизации:
    drbdadm syncer r0
     
  • Подсоединяюсь к узлу-партнёру:
    drbdadm connect r0
     
  • А вот это действие делается ТОЛЬКО НА ОДНОЙ МАШИНЕ - НА МАШИНЕ ИСТОЧНИКЕ ДАННЫХ. Задаю источник для синхронизации и стартую начальную синхронизацию.
    drbdadm -- --overwrite-data-of-peer primary r0
    Тут же начнётся синхронизация данных в фоне. Посмотреть на неё можно в /proc/drbd.
     
  • Всё. Теперь монтирую раздел /dev/drbd1 на машине-источнике и радостно им пользуюсь.
    На машине-приёмнике монтировать ничего не надо. Это не рекомендуется. Максимум, что вы можете (при условии полной синхронизации), это смонтировать раздел /dev/drbd1 в режиме ReadOnly.
     
  • На моей тестовой 100-мбитной сети
    watch -n 1 cat /proc/drbd
    давал вот такую картину :)  :

    version: 8.3.8 (api:88/proto:86-94)
    srcversion: 299AFE04D7AFD98B3CA0AF9

    1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r----
        ns:341792 nr:0 dw:576 dr:347273 al:6 bm:20 lo:0 pe:10 ua:0 ap:0 ep:1 wo:b oos:257396852
            [>....................] sync'ed:  0.2% (251364/251696)M delay_probe: 0
            finish: 18:37:10 speed: 3,820 (1,440) K/sec
  • Для начала это всё. Важные дополнительные команды для управления DRBD (down, primary, secondary) я расскажу дальше.

 

Управление DRBD на примерах.

Рассмотрю ситуацию отключения и повторного запуска DRBD.

 

  • Остановка DRBD на Secondary:
    drbdadm down r0
  • Запуска DRBD на Secondary:
    drbdadm attach r0
    drbdadm secondary r0
    drbdadm syncer r0
    drbdadm connect r0
    Параметр secondary говорит о роли хоста

Пока Secondary остановлен Primary знает об этом и просто отслеживает в метаданных какие блоки измнились.

Как только я включаю Secondary, начнётся синхронизация блоков, изменившихся за время простоя.

 

 

Если зачем-то необходим перезапуск Primary, то:

Остановка:

  drbadm down r0

Запуск:

 drbdadm attach r0
 drbdadm primary r0
 drbdadm syncer r0
 drbdadm connect r0
 Параметр primary говорит о роли хоста. Его важно указывать, поскольку после перезапуска без указания роли этот хост встанет в режим Secondary.