DRBD - Все що стосується Linux/Unix систем <!--%IFTH1%0%-->- <!--%IFEN1%0%--> - Каталог статей - Світило & Ант
Четвер
23.02.2017
19:10
 

 Галичина
Приветствую Вас Призовник | RSSГлавная | Каталог статей | Регистрация | Вход
Меню сайта
Категории каталога
Загальні [11]Все що стосується Linux/Unix систем [2]
Цікава інформація
Все що стосується Windows [0]Зброя [0]
Флора і фауна [0]Авто світ [4]
Жилізо ПК [8]Відео [2]
Вампіризм і Перевертні [9]
Мини-чат


Главная » Статьи » Все що стосується Linux/Unix систем

DRBD
Что такое 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) .

Как работает 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 описаны здесь: 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, но в случае проблем с сетью будет паника из-за отсутствия доступа к правильным данным. Поэтому лучше так не делать никогда.


Источник: http://xgu.ru/wiki/DRBD
Категория: Все що стосується Linux/Unix систем | Добавил: kleoo-svitulo (27.09.2008) | Автор: Игорь Чубин
Просмотров: 627 | Рейтинг: 0.0/0 |
Всего комментариев: 0

Ім`я *:
Email *:
Код *:


Форма входа
Поиск
Друзья сайта
Статистика

Онлайн всього: 1
Гостей: 1
Користувачів: 0
Copyright MyCorp © 2017
Хостинг від uCoz