Синхронизированные разделы: DRBD

Сначала настроим общие разделы узлов кластера средствами DRBD. Установка DRBD производится штатным для ALT Linux способом. Cмотрим, какие пакеты имеются в наличии:

[root@m1 ~]# apt-cache search drbd
drbd-tools - Distributed Redundant Block Device utilities
kernel-modules-drbd-ovz-smp - Linux drbd kernel modules for DRBD.
kernel-modules-drbd-std-smp - Linux drbd kernel modules for DRBD.
kernel-modules-drbd-std-up - Linux drbd kernel modules for DRBD.
kernel-modules-drbd-std26-smp - Linux drbd kernel modules for DRBD.
kernel-modules-drbd-std26-up - Linux drbd kernel modules for DRBD.
kernel-modules-drbd-vs26-smp - Linux drbd kernel modules for DRBD.
kernel-modules-drbd-wks26-smp - Linux drbd kernel modules for DRBD.
kernel-modules-drbd-wks26-up - Linux drbd kernel modules for DRBD.
kernel-source-drbd-0.7.21 - Kernel source for DRBD

$\begin{framed} В репозиториях ALT Linux ядро имеется в... ...�ы с ядром по версии и по типу сборки. \end{framed}$

Затем определяем, какое у нас ядро:

[root@m1 ~]# uname -a
Linux m1.mydomain.com 2.6.16-std26-up-alt10 #1 Wed Sep 13 20:06:02 MSD 2006 i686 GNU/Linux

На основании этой информации (std26-up) решаем, какие именно пакеты нам нужны, и устанавливаем их:

[root@m1 ~]# apt-get install kernel-modules-drbd-std26-up drbd-tools

Первый установленный нами пакет содержит модуль ядра, необходимый для работы DRBD, второй "-- userspace"=инструменты для управления DRBD. Конфигурирование DRBD сводится к редактированию файла /etc/drbd.conf. Минимальная, но вполне работоспособная конфигурация будет выглядеть так:

resource r0 {
    
    # протокол передачи
    # C: запись считается завершенной, если данные записаны на локальный и удаленный диск
    #    подходит для критически важных транзакций и в большинстве остальных случаев
    # B: запись считается завершенной, если данные записаны на локальный диск 
    #    и удаленный буферный кэш
    # A: запись считается завершенной, если данные записаны на локальный диск 
    #    и локальный буфер tcp для отправки
    #    подходит для для сетей с высокой задержкой   
    protocol B;
    
    # описание узла m1
    on m1.mydomain.com {
        device     /dev/drbd0;           # имя drbd-устройства
        disk       /dev/hda3;            # раздел диска, поверх которого оно работает 
        address    192.168.200.1:7788;   # адрес и порт демона drbd
        meta-disk  internal;             # хранить метаданные drbd на том же разделе диска
    }
    
    # описание узла m2
    on m2.mydomain.com {
        device    /dev/drbd0;            # имя drbd-устройства
        disk      /dev/hda3;             # раздел диска, поверх которого оно работает 
        address   192.168.200.2:7788;    # адрес и порт демона drbd
        meta-disk internal;              # хранить метаданные drbd на том же разделе диска
    }
}

В комплекте с DRBD поставляется очень детальный пример конфигурационного файла, в котором все параметры прокомментированы.

Для работы DRBD необходим специальный файл устройста (/dev/drbd0). Если в системе используется udev, то такой файл будет создаваться автоматически, в противном случае придется создать его вручную:

[root@m1 ~]# mknod /dev/drbd0 b 147 0

Последний шаг настройки "-- обеспечить запуск сервиса drbd при загрузке узла:

[root@m1 ~]# chkconfig --level 2345 drbd on

Эти операции необходимо повторить на узле m2, а затем на обоих узлах запустить сервис drbd:

[root@m1 ~]# service drbd start
Starting Starting DRBD resources:     service: [ d0 s0 n0 ].
...

После чего на обоих узлах кластера мы должны увидеть следующее:

[root@m1 ~]# service drbd status
drbd driver loaded OK; device status:
version: 0.7.21 (api:79/proto:74)
SVN Revision: 2326 build by builder@xeon.office.altlinux.ru, 2006-09-22 23:46:26
 0: cs:Connected st:Secondary/Secondary ld:Inconsistent
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

Итак, устройство /dev/drbd0 уже работает, но содержимое разделов /dev/hda3, лежащих уровнем ниже, еще не синхронизировано. Первый раз синхронизацию необходимо произвести вручную, выполнив на узле m1:

[root@m1 ~]# drbdadm -- --do-what-I-say primary all

После выполнения этой команды мы можем проследить за процесом синхронизации:

[root@m1 ~]# service drbd status
drbd driver loaded OK; device status:
version: 0.7.21 (api:79/proto:74)
SVN Revision: 2326 build by builder@xeon.office.altlinux.ru, 2006-09-22 23:46:26
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:1972 nr:0 dw:0 dr:10164 al:0 bm:0 lo:0 pe:30 ua:2048 ap:0
       [>...................] sync'ed:  0.2% (3158696/3160552)K
       finish: 0:26:19 speed: 1,856 (1,856) K/sec

После окончания синхронизации на узле m1 мы увидим:

[root@m1 ~]# service drbd status
drbd driver loaded OK; device status:
version: 0.7.21 (api:79/proto:74)
SVN Revision: 2326 build by builder@xeon.office.altlinux.ru, 2006-09-22 23:39:33
 0: cs:Connected st:Primary/Secondary ld:Consistent
    ns:731068 nr:1052796 dw:1782732 dr:193337 al:20 bm:356 lo:0 pe:0 ua:0 ap:0

По строке Primary/Secondary можно определить, что сейчас узел m1 является ведущим. На ведомом узле m2 в выводе той же самой команды мы увидим Secondary/Primary. Все операции с устройством /dev/drbd0 необходимо выполнять только на ведущем узле, при этом все изменения будут автоматически применены к разделам /dev/hda3 на обоих узлах кластера.

Создадим на устройстве /dev/drbd0 файловую систему и смонтируем ее:

[root@m1 ~]# mkfs.ext3 /dev/drbd0
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
395200 inodes, 790138 blocks
39506 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=809500672
25 block groups
32768 blocks per group, 32768 fragments per group
15808 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912

Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[root@m1 ~]# mkdir /d0
[root@m1 ~]# mount /dev/drbd0 /d0

Если теперь мы попытаемся смонтировать устройство /dev/drbd0 на узле m2, мы получим следующее сообщение об ошибке:

[root@m2 ~]# mkdir /d0
[root@m2 ~]# mount /dev/drbd0 /d0
/dev/drbd0: Input/output error
mount: block device /dev/drbd0 is write-protected, mounting read-only
/dev/drbd0: Input/output error
mount: /dev/drbd0 already mounted or /d0 busy

Такое (вполне разумное) поведение гарантируется только для ядер 2.6, в 2.4 была возможность смонтировать устройство /dev/drbd0 на обоих узлах кластера одновременно, что, в свою очередь, могло привести к повреждению файловой системы.

Чтобы все-таки смонтировать раздел /dev/drbd0 на узле m2, необходимо сделать его ведущим, выполнив на узлах m1 и m2 следующие команды:

[root@m1 ~]# umount /d0
[root@m1 ~]# drbdadm disconnect all
[root@m2 ~]# drbdadm disconnect all
[root@m1 ~]# drbdadm secondary all
[root@m2 ~]# drbdadm -- --human primary all
[root@m1 ~]# drbdadm connect all
[root@m2 ~]# drbdadm connect all
[root@m2 ~]# mount /dev/drbd0 /d0

В случае отказа узла m1 достаточно выполнить только те команды, которые приведены выше для узла m2. По большому счету, любители велосипедостроения (или оптимальных решений "-- иногда трудно отличить одно от другого) могут этим и ограничиться: написать скрипт, который будет следить на доступностью соседнего узла и монтировать раздел /dev/drbd0, если соседний узел перестал отвечать, можно самостоятельно. Другой вопрос: зачем, если Heartbeat умеет делать и это, и многое другое?

Eugene 2012-05-28