Ключевые слова:drbd, disk, cluster, replication, (найти похожие документы)
From: Игорь Чубин <http://xgu.ru>;
Date: Mon, 18 Sep 2007 14:31:37 +0000 (UTC)
Subject: Настройка репликации дисков в Linux на основе DRBD
Оригинал: http://xgu.ru/wiki/DRBD
Автор: Игорь Чубин
Взято за основу: Howto get started with DRBD 0.7, (начал Lars Ellenberg)
На этой странице детально рассматривается процедура подготовки двух
систем для синхронизации одного из своих дисковых разделов с помощью
DRBD.
Может применяться для организации отказоустойчивых систем хранения
данных и отказоустойчивых кластерных систем.
Содержание
1 Что такое DRBD?
2 Как работает DRBD?
2.1 Какое отношение DRBD имеет к HA-кластерам?
2.2 DRBD и кластерные файловые системы
3 DRBD: подготовка модуля ядра Linux
4 Настройка DRBD
5 Пример настройки
6 См. также на xgu.ru
7 Дополнительная информация
Что такое DRBD?
DRBD (англ. Distributed Replicated Block Device -- распределённое
реплицируемое блочное устройство) -- это блочное устройство,
предназначенное для построения отказоустойчивых кластерных систем на
операционной системе Linux. DRBD занимается полным отражением
(mirroring) по сети всех операций с блочным устройством. Можно
считать, что DRBD это сетевой RAID-1.
DRBD берёт данные, записывает их на локальный диск и пересылает на
другой хост. На другом хосте они тоже записываются на диск.
Помимо DRBD в кластере должно быть ещё два важных компонента:
1. cluster membership service (в качестве которого чаще всего
выступает heartbeat);
2. приложение, работающее поверх распределённого блочного устройства.
Примеры приложений:
* Файловая система c fsck;
* Журналируемая файловая система;
* СУБД;
* домен Xen.
Как работает DRBD?
Каждое DRBD-устройство (а DRBD-устройств одновременно может быть
много) находится в одном из двух состояний:
* primary -- первичном;
* secondary -- вторичном.
На узле, на котором DRBD-устройство находится в первичном состоянии,
операционная система или процессы могут работать с DRBD-устройством
(оно доступно через файл-устройства /dev/drbdX).
Каждое обращение на запись к DRBD-устройству отправляется локальном к
нижележащему устройству и на узел, на котором находится реплика
устройства, работающая во вторичном состоянии. Вторичное устройство,
получившее запрос, выполняет запись.
Чтение выполняется всегда только локально.
Если основной узел падает, heartbeat переключает запасной узел в
состояние ведущего и запускает приложения на нём (если используется
нежурналируемая файловая система, кроме всего прочего ещё выполнится
fsck).
Когда сбойный узел поднимается, DRBD-устройство на нём находится в
состоянии второстепенного (secondary), и оно начинается
синхронизироваться с основным устройством. Конечно же, это происходит
в фоне, без нарушения работы системы.
Естественно, что синхронизируются только те части устройства, которые
подверглись изменению. DRBD старается выполнять ресинхронизацию
максимально эффективным способом. Начиная с DRBD-0.7 существует
возможность создания так называемых активных множеств (active set)
определённого размера. Что позволяет выполнять ресинхронизацию на 1--3
минуты, независимо от размера устройства (сегодня до 4TB) даже после
падения активного узла.
Какое отношение DRBD имеет к HA-кластерам?
Сегодня HA-кластеры (отказоуйстойчивые кластеры) используют в своей
работе внешние храналища, которые подключаюся сразу к нескольким
узлам. Обычно это делается с помощью шин SCSI или Fibre Channel (но не
обязательно).
DRBD позволяет делать похожие вещи, только оно не использует никакого
специального оборудования, а работает поверх обычных IP-сетей.
DRBD и кластерные файловые системы
DRBD-устройство работает на одном из узлов в режиме главного (primary
role), а на других -- в режиме второстепенного (secondary role).
Запись идёт на устройство, которое находится в режиме главного, а на
остальные просто выполняется репликация. Такой режим применим для
классических отказоустойчивых кластеров, его следует использовать,
если на 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.
Нужно отредактировать этот файл в соответствии с вашими требованиями,
а потом скопировать его на оба узла. Затем убедиться, что meta-disk'и
находятся в правильных местах.
Если вы настраиваете синхронизацию нескольких ресурсов, убедитесь, что
в файле /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
В результате должна выполниться полная синхронизация нижележащих
устройств.
Устройство готово к использованию. Если у вас ещё нет файловой системы
на нём, можно её создать прямо сейчас.
Теперь:
* смонтируйте 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 ; don
Подробнее можно почитать в файлах 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:100
0 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, но в случае проблем с сетью будет
паника из-за отсутствия доступа к правильным данным. Поэтому лучше так
не делать никогда.
См. также на xgu.ru
* Использование доменов Xen поверх DRBD-устройств
Дополнительная информация
* www.drbd.org (англ.) домашняя страница проекта DRBD
* 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 (англ.)
* LVM Project Page (англ.) - кластерный LVM
* A cluster with DRBD and Heartbeat HA cluster with DRBD and Heartbeat (англ.)
Обсуждения:
* 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 (англ.)
Вообщем так : У меня получилось все это дело поднять НО :
1) Замаунтить /dev/drbdХ можно только на одной ноде...
2) meta-disk internal; нигде не заработало..
пришось создавать отдельный раздел на обоих нодах для метаданных..
3) Ничего общего с НА эта система не иммет как по мне... я еще не разбирался с Heartbeat но мне кажеться что он не суммет автоматически маунтить и анмаунтить нужный раздел на нужной ноде в случае падения одной из них...
Если основной узел падает, heartbeat переключает запасной узел в состояние ведущего и запускает приложения на нём (если используется нежурналируемая файловая система, кроме всего прочего ещё выполнится fsck). Когда сбойный узел поднимается, DRBD-устройство на нём находится в состоянии второстепенного (secondary), и оно начинается синхронизироваться с основным устройством. Конечно же, это происходит в фоне, без нарушения работы системы. Естественно, что синхронизируются только те части устройства, которые подверглись изменению. DRBD старается выполнять ресинхронизацию максимально эффективным способом. Начиная с DRBD-0.7 существует возможность создания так называемых активных множеств (active set) определённого размера. Что позволяет выполнять ресинхронизацию на 1--3 минуты, независимо от размера устройства (сегодня до 4TB) даже после падения активного узла. Какое отношение DRBD имеет к HA-кластерам? Сегодня HA-кластеры (отказоуйстойчивые кластеры) используют в своей работе внешние храналища, которые подключаюся сразу к нескольким узлам. Обычно это делается с помощью шин SCSI или Fibre Channel (но не обязательно). DRBD позволяет делать похожие вещи, только оно не использует никакого специального оборудования, а работает поверх обычных IP-сетей. DRBD и кластерные файловые системы DRBD-устройство работает на одном из узлов в режиме главного (primary role), а на других -- в режиме второстепенного (secondary role). Запись идёт на устройство, которое находится в режиме главного, а на остальные просто выполняется репликация. Такой режим применим для классических отказоустойчивых кластеров, его следует использовать, если на 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. Нужно отредактировать этот файл в соответствии с вашими требованиями, а потом скопировать его на оба узла. Затем убедиться, что meta-disk'и находятся в правильных местах. Если вы настраиваете синхронизацию нескольких ресурсов, убедитесь, что в файле /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 В результате должна выполниться полная синхронизация нижележащих устройств. Устройство готово к использованию. Если у вас ещё нет файловой системы на нём, можно её создать прямо сейчас. Теперь: * смонтируйте 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 ; don Подробнее можно почитать в файлах 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:100 0 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, но в случае проблем с сетью будет паника из-за отсутствия доступа к правильным данным. Поэтому лучше так не делать никогда. См. также на xgu.ru * Использование доменов Xen поверх DRBD-устройств Дополнительная информация * www.drbd.org (англ.) домашняя страница проекта DRBD * 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 (англ.) * LVM Project Page (англ.) - кластерный LVM * A cluster with DRBD and Heartbeat HA cluster with DRBD and Heartbeat (англ.) Обсуждения: * 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 (англ.)
