DRBD

Материал из Xgu.ru

(Перенаправлено с Drbd)

Автор: Игорь Чубин

Взято за основу: [1], (начал Lars Ellenberg)

На этой странице детально рассматривается процедура подготовки двух систем для синхронизации одного из своих дисковых разделов с помощью DRBD.

Может применяться для организации отказоустойчивых систем хранения данных и отказоустойчивых кластерных систем.

Содержание

1 Что такое DRBD?
2 Как работает DRBD?
- 2.1 Какое отношение DRBD имеет к HA-кластерам?
- 2.2 DRBD и кластерные файловые системы
3 DRBD: подготовка модуля ядра Linux
4 Настройка DRBD
5 Пример настройки
6 Поля в /proc/drbd
7 Дополнительная информация
8 Примечание

[править] Что такое DRBD?

DRBD (Distributed Replicated Block Device — распределённое реплицируемое блочное устройство) — это блочное устройство, предназначенное для построения отказоустойчивых кластерных систем на операционной системе Linux. DRBD занимается полным отражением (mirroring) по сети всех операций с блочным устройством. Можно считать, что DRBD это сетевой RAID-1.

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

Помимо DRBD в кластере должно быть ещё два важных компонента:

cluster membership service (в качестве которого чаще всего выступает heartbeat);
приложение, работающее поверх распределённого блочного устройства.

Примеры приложений:

Файловая система c fsck;
Журналируемая файловая система;
СУБД;
домен Xen.

DRBD работает как модуль ядра Linux. В других операционных системах DRBD использоваться не может. В качестве альтернативы DRBD для OpenSolaris можно рассмотреть Sun StorageTek Availability Suite (сокращённо AVS) , а в FreeBSD - HAST.

[править] Как работает DRBD?

Каждое DRBD-устройство (а DRBD-устройств одновременно может быть много) находится в одном из двух состояний:

primary — первичном;
secondary — вторичном.

На узле, на котором DRBD-устройство находится в первичном состоянии, операционная система или процессы могут работать с ним (устройство доступно через файл /dev/drbdX).

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

Чтение выполняется всегда только локально.

Если основной узел падает, heartbeat переключает запасной узел в состояние первичного и запускает приложения на нём (если используется нежурналируемая файловая система, кроме всего прочего может потребоваться выполнить проверку целостности при помощи fsck).

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

Синхронизируются только те части устройства, которые подверглись изменению. DRBD старается выполнять ресинхронизацию максимально эффективным способом. Начиная с DRBD-0.7 существует возможность создания так называемых активных множеств (active set) определённого размера. Что позволяет выполнять ресинхронизацию за 1—3 минуты, независимо от размера устройства (сегодня до 4TB) даже после падения активного узла.

[править] Какое отношение DRBD имеет к HA-кластерам?

Сегодня HA-кластеры (отказоустойчивые кластеры) используют в своей работе внешние хранилища, которые подключаются сразу к нескольким узлам. Обычно это делается с помощью шин SCSI или Fibre Channel (но не обязательно).

DRBD позволяет делать похожие вещи, только оно не использует никакого специального оборудования, а работает поверх обычных IP-сетей (похожие вещи делаются при помощи протоколов iSCSI/AoE, только в случае DRBD ещё обеспечивается отказоустойчивость).

[править] DRBD и кластерные файловые системы

Обычно DRBD-устройство работает на одном из узлов в режиме первичного (primary role), а на втором — в режиме вторичного или резервного (secondary role).Запись идёт на устройство, которое находится в режиме главного, а на второе (остальные в случае с DRBD9) просто выполняется репликация. Такой режим применим для классических отказоустойчивых кластеров, его следует использовать, если на DRBD-устройстве непосредственно находятся традиционные, не кластерные файловые системы (ext3, XFS, JFS и т.д.).

Начиная с DRBD-8.0.08 можно заставить работать оба узла в режиме primary. Это даёт возможность монтировать кластерную ФС сразу на двух узлах одновременно. Примеры таких кластерных файловых систем:

GFS;
OCFS2.

Кроме того, эта возможность DRBD позволяет выполнять живую миграцию доменов Xen, которые используют эти устройства. В этом случае использование кластерных систем в домене Xen не является обязательным, можно обойтись традиционными системами, такими как ext3, XFS, JFS.

[править] DRBD: подготовка модуля ядра Linux

Раньше код модуля ядра DRBD не был интегрирован в ядро Linux и предоставлялся в виде отдельных патчей. Начиная с 2.6.33^[1] модуль DRBD входит непосредственно в ядро.

Процедуры подготовки DRBD для различных дистрибутивов Linux описаны здесь: Howto Build and Install DRBD (англ.).

В Debian GNU/Linux подготовка выполняется очень просто:

1) Найти пакет

%# apt-cache search drbd
drbd0.7-module-source - RAID 1 over tcp/ip for Linux module source
drbd0.7-utils - RAID 1 over tcp/ip for Linux utilities
drbd8-module-source - RAID 1 over tcp/ip for Linux module source
drbd8-utils - RAID 1 over tcp/ip for Linux utilities
drbdlinks - Manages symlinks into a shared DRBD partition

2) Установить пакет

%# apt-get install drbd8-module-source

3) Собрать и загрузить

%# module-assistant auto-install drbd8

[править] Настройка DRBD

Если инсталляция выполняется из архива исходных текстов, нужно прочитать README, INSTALL и DRBD/HowTo/Install.

Нужно также ознакомиться с файлами upgrade*.txt в каталоге src/ drbd или непосредственно в репозитории проекта.

В дистрибутив входит хорошо прокомментированный конфигурационный файл-пример. В архиве исходных текстов он находится в ./scripts/drbd.conf; в пакетах может быть в одном из каталогов: /usr/{shared/,}doc/packages/drbd.

Пример конфигурационного файла drbd.conf:

resource dns {
    protocol C;
    net {
        allow-two-primaries;
        after-sb-0pri discard-least-changes;
        after-sb-1pri call-pri-lost-after-sb;
        after-sb-2pri call-pri-lost-after-sb;
    }
    syncer {
        rate 5M;
    }
    on dom0
    {
        device /dev/drbd1;
        disk /dev/XEN/dns;
        address 192.168.1.190:7792;
        meta-disk /dev/XEN/meta[1];
    }
    on dom0m
    {
        device /dev/drbd1;
        disk /dev/XEN/dns;
        address 192.168.1.191:7792;
        meta-disk /dev/XEN/meta[1];
    }
}

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

Если вы настраиваете синхронизацию нескольких ресурсов, убедитесь, что в файле /etc/drbd.conf указаны разные порты (или разные IP) для этих ресурсов.

Внимание! Два раза всё перепроверьте, перед тем как начинать следующий шаг. Если DRBD не найдёт метаданных там, где он их ожидает, он создаст новые. Если вы укажете на неверное место, будут переписаны несколько килобайтов или несколько мегабайтов возможно полезных данных! Если вы будете использовать внутренний метадиск (meta-disk=internal), убедитесь, что вы перед этим уменьшили файловую систему устройства (если она там есть).

В настоящий момент метаданные DRBD забирают 128M, независимо от настоящего размера физических данных. В связи с этим максимальный размер одного хранилища DRBD не может превышать ~4TB.

Скопируйте drbd.conf в /etc/drbd.conf на оба узла. После этого на обоих узлах выполните команду:

   drbdadm up all

Узлы должны подняться и перейти в состояние Secondary и Inconsistent.

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

Выберите, какой из узлов будет Primary (если есть данные, то это должен быть узел, на котором они уже есть). После этого выполните:

  drbdadm -- --do-what-I-say primary all

или

  drbdsetup /dev/drbd1 primary -o

(для установки одного устройства /dev/drbd1 в primary-режим). В результате должна выполниться полная синхронизация нижележащих устройств.

Устройство готово к использованию. Если у вас ещё нет файловой системы на нём, можно её создать прямо сейчас.

Теперь:

смонтируйте DRBD на Primary;
отредактируйте какие-нибудь файлы;
размонтируйте DRBD;
сделайте этот узел Secondary, а второй Primary;
смонтируйте DRBD на новом узле;
посмотрите изменения в файлах, которые вы сделали — они должны были отразиться.

Теперь можно интегрировать устройство с heartbeat или использовать как-нибудь ещё.

[править] Пример настройки

В этом примере используются устройства /dev/drbdX. Раньше использовались /dev/nbX. Исторически так сложилось что DRBD хищнически захватил мажорный номер NBD (43) и узлы устройств. Сейчас официально DRBD может использовать свой номер (147). В связи с этим начиная с версии 0.7.1 по умолчанию используются свои номера устройств и названия файлов устройств.

Если система ничего не знает о /dev/drbdX, нужно создать их командой наподобие такой:

  for i in $(seq 0 15) ; do mknod /dev/drbd$i b 147 $i ; done

Подробнее можно почитать в файлах upgrade*.txt, упоминавшихся выше.

# administration ips of the nodes:
left=10.0.0.1
right=10.0.0.2

vi drbd.conf
# double check.
scp drbd.conf $left:/etc/drbd.conf
scp drbd.conf $right:/etc/drbd.conf

cmd='modprobe drbd; drbdadm up all; dmesg | tail; cat /proc/drbd'
ssh root@$left -- "$cmd"
ssh root@$right -- "$cmd"

Фрагмент из dmesg (или syslog) должен выглядеть так (в примере хранилище размером 5М).

drbd: initialised. Version: 0.7.0 svn $Rev: 1442 $ (api:74/proto:74)
drbd: registered as block device major 147

  nb: to have it register as 43 (NBD) you can say
  modprobe drbd use_nbd_major

drbd0: Creating state block
drbd0: resync bitmap: bits=1250 words=40
drbd0: size = 5000 KB
drbd0: Assuming that all blocks are out of sync (aka FullSync)
drbd0: 5000 KB now marked out-of-sync by on disk bit-map.
drbd0: Handshake successful: DRBD Network Protocol version 74
drbd0: Connection established.
drbd0: I am inconsistent, but there is no sync? BOTH nodes inconsistent!
drbd0: Secondary/Unknown --> Secondary/Secondary

Файл /proc/drbd должен выглядеть так:

# cat /proc/drbd
version: 0.7.0 svn $Rev: 1442 $ (api:74/proto:74)

 0: cs:Connected st:Secondary/Secondary ld:Inconsistent
     ns:0 nr:0 dw:0 dr:0 al:0 bm:1 lo:0 pe:0 ua:0 ap:0

Пусть $left будет Primary:

ssh root@$left -- "drbdadm primary all"
# output is:
ioctl(,SET_STATE,) failed: Input/output error
Local replica is inconsistent (--do-what-I-say ?)
Command line was '/sbin/drbdsetup /dev/drbd0 primary'
drbdsetup exited with code 21

Замечание: Это приведёт к перезагрузке системы (!)

В действительности drbdadm просто выполняет команду "incon-degr-cmd". Поскольку в примере был "halt -f", вы сами попросили о перезапуске. Возможно, лучше указать что-то менее жёсткое. Это можно сделать, указав в файле drbd.conf:

incon-degr-cmd "echo 'DRBD: primary requested but inconsistent!' | wall; sleep 300000";

Ещё одна хорошая команда:

  killall -9 heartbeat ipfail ccm

Продолжаем.

# ok, this was expected.
# so double check that $left is the correct node.
# then force it:
ssh root@$left -- "drbdadm -- --do-what-I-say primary all"
# which will succeed silently.

## Bryce Porter suggests that:
## At this point, you need to connect the resource(s)
# ssh root@$left -- "drbdadm -- connect all"
#
## well, they should have been connected all along, see /proc/drbd excerpt above,
## so if this was neccessary, something "unexpected" happend already...
##     -- lge

ssh $left -- 'dmesg | tail ; cat /proc/drbd'
# output is:
drbd0: Resync started as SyncSource (need to sync 5000 KB [1250 bits set]).

version: 0.7.0 svn $Rev: 1442 $ (api:74/proto:74)

 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:9276 nr:0 dw:0 dr:9404 al:0 bm:2 lo:0 pe:915 ua:32 ap:0
        [=========>..........] sync'ed: 50.0% (4380/5000)K
        finish: 0:00:05 speed: 620 (620) K/sec

# or, to give an example from a larger device:
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:12940824 nr:0 dw:87492 dr:13690591 al:109 bm:1668 lo:1000 pe:1876 ua:1000 ap:0
        [========>...........] sync'ed: 44.4% (15858/28487)M
        finish: 0:09:20 speed: 28,933 (25,160) K/sec


# whereas on the other node:
ssh $right -- 'dmesg | tail ; cat /proc/drbd'
drbd0: Resync started as SyncTarget (need to sync 5000 KB [1250 bits set]).

version: 0.7.0 svn $Rev: 1442 $ (api:74/proto:74)

 0: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
    ns:0 nr:15000 dw:15000 dr:0 al:0 bm:6 lo:0 pe:0 ua:0 ap:0
        [=========>..........] sync'ed: 50.0% (5000/5000)K
        finish: 0:00:12 speed: 5 (5) K/sec

# or, to give an example from a larger device:
 0: cs:SyncTarget st:Secondary/Primary ld:Inconsistent
    ns:0 nr:27311780 dw:27311780 dr:0 al:0 bm:3447 lo:134 pe:493 ua:134 ap:0
        [==================>.] sync'ed: 93.7% (1818/28487)M
        finish: 0:01:07 speed: 27,482 (25,008) K/sec

Убедимся, что всё работает:

# if you have no file system yet, create one
# ssh root@$left -- 'mkreiserfs /dev/drbd0'

ssh root@$left -- 'mkdir -p /mnt/ha0; mount /dev/drbd0 /mnt/ha0 && touch /mnt/ha0/been_there'

# 'switch over'
ssh root@$left -- 'umount /mnt/ha0 && drbdadm secondary all'
# even during sync!
ssh root@$right -- 'drbdadm primary all'
ssh root@$right -- 'mkdir -p /mnt/ha0; mount /dev/drbd0 /mnt/ha0 && ls -l /mnt/ha0/been_there'

Обратите внимание, что хотя ошибки и не будет, но лучше так не делать: SyncTarget можно сделать Primary, но в случае проблем с сетью будет паника из-за отсутствия доступа к правильным данным. Поэтому лучше так не делать никогда.

[править] Поля в /proc/drbd

Источник: [2]

> 0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
  ^  ^            ^                    ^                    ^ ^-[*]
  |  |            |                    |                    |
  |  |            |                    |                    `-wire protocol
  |  |            |                    `- disk state
  |  |            `- state (should be named role, but historically)
  |  `- connection state
  `- minor


[*]: four characters showing certain flag bits

first:
[rs]: io running(resumed)/suspended, see drbdadm suspend-io/resume-io

next three show details of sync-after dependencies.
they all say '-' if currently unset.

if there is a resync running, but you have serialized resync of your devices
(because they share some resources (live on the same "spindle"),
or because you want some more important ones to be resynced first),
there are certain ways to suspend this resync.

a: implicitly paused because of sync-after dependency on this node
p: implicitly paused because of sync-after dependency on the peer node
u: explicitly suspended by the user, see drbdadm pause-sync/resume-sync

[править] Дополнительная информация

Нужно подчистить ссылки

http://allexit.blogspot.com/2011/12/drbd.html - Статья o DRBD в блоге allexit. Русский перевод некоторых полезный значений.
http://www.drbd.org/ (англ.) — домашняя страница проекта DRBD
The DRBD User's Guide — “official” release of the DRBD User’s Guide.
DRBD FAQ (англ.)
Howto Build and Install DRBD (англ.) — процедура подготовки DRBD, в частности модуля ядра Linux
Data Redundancy with DRBD (англ.) — статья о DRBD 0.6
DRBD How To in the IBB Wiki (англ.) — специфичное для RedHat (Fedora, RHEL, CentOS и других RedHat-based) описание процедуры поднятия DRBD
Xen with DRBD, GNBD and OCFS2 HOWTO (англ.)
CLVM Project Page (англ.) - кластерный LVM
(openvz-wiki) HA cluster with DRBD and Heartbeat HA cluster with DRBD and Heartbeat (англ.)
DRBD, Xen und Heartbeat (нем.)
http://te.to/~ts1/xen_cluster.html (англ.)

Обсуждения:

Sensible maximum number of drbd devices (англ.) - вопросы использования Xen и DRBD
(DRBD-user) DRBD 8.0, how to manage a split-brain on Master-Master (англ.)
(Xen-devel) Debian, Xen and DRBD: Enabling true server redundancy (англ.)

Схожие аппаратные решения:

LSI Syncro CS HA DAS Storage Overview (англ.)

[править] Примечание

↑ Linux 2.6.33 released, (англ.); это произошло 24 февраля 2010

Диски и разделы
Дисковая подсистема Linux \| FreeBSD
Файлы устройств: Блочное устройство \| Символьное устройство \| Raw-устройство \| loop-устройство
Диски: IDE \| SATA (SATA hotplug) \| SCSI \| USB
RAID-массивы: Аппаратный RAID \| Linux RAID \| FreeBSD RAID
Дисковые разделы: Раздел \| MBR \| fdisk \| parted \| disklabel \| GPT
Управление томами
Логический том \| Физический том \| Группа томов \| Снимок \| Клон
device-mapper \| dm-ioband \| dm-crypt \| dm-userspace \| multipath
Системы управления томами: LVM \| CLVM \| EVMS \| Btrfs* \| ZFS* \| AdvFS* \| Zumastor
Сетевые хранилища и репликация
Отказоустойчивость: DRBD \| Xen + DRBD \| ggate + gmirror \| HAST
Сетевые хранилища: AoE \| iSCSI \| FCoE \| GNBD
Файловые системы
Монтирование \| Проверка целостности \| Дефрагментация \| Суперблок \| inode \| Журнал \| Кэш \| VFS \| UUID \| FUSE
Локальные: ext3 \| ext3cow \| ext4 \| JFS \| Reiser4 \| XFS \| ZFS \| Btrfs \| AdvFS \| ISO \| aufs
Сетевые: NFS \| CIFS \| AFS \| POHMELFS
Кластерные: GFS \| OCFS2 \| CXFS \| VMFS \| GPFS
Распределенные: Lustre \| PVFS \| Ceph \| Coda
* Btrfs, ZFS и AdvFS — это файловые системы с возможностями управления томами e

[0] Linux 2.6.33 released, (англ.); это произошло 24 февраля 2010

[1]

DRBD

Материал из Xgu.ru

Содержание

[править] Что такое DRBD?

[править] Как работает DRBD?

[править] Какое отношение DRBD имеет к HA-кластерам?

[править] DRBD и кластерные файловые системы

[править] DRBD: подготовка модуля ядра Linux

[править] Настройка DRBD

[править] Пример настройки

[править] Поля в /proc/drbd

[править] Дополнительная информация

[править] Примечание

Просмотры

Личные инструменты

Навигация

Поиск

Инструменты

На других языках