Построение drbd-зеркала на Proxmox-3.0

В данной статье я хочу описать how-to по созданию drbd зеркалирования на Proxmox 3.0 хост-машинах. Объединить машины в proxmox кластер имеет смысл до этих операций – хотя в общем то нет никакой разницы.
Основным отличием данного материала от многих, раскинутых на просторах интернета, то что мы делаем drbd раздел не на новом физическом диске, подключенном вторым, а на lvm разделе в пределах единственного наличествующего диска.
Вопрос целесообразности таких действий достаточно спорный – будет ли быстрее drbd на «сыром» диске или нет, но в любом случае это 100% опробованный вариант. В копилку так сказать. Да и работа с «сырым» диском – это просто частный случай данной инструкции.


Собственно Proxmox 3.0 при установке ( так же как и его предшественник 2.0 ) не напрягает вопросами разбиения на разделы и все разбивает сам учитывая только общие размеры диска и объем памяти. Мы получаем раздел /pve/data занимающий большую часть диска и видимый в Proxmox как хранилище local. Вот за счет него и будут производиться действия.

1. Обновляем пакеты до актуальных
#aptitude update && aptitude full-upgrade

2. Устанавливаем необходимые пакеты
#aptitude install drbd8-utils

3. Освобождение места под новый раздел.
Отмонтируем /dev/pve/data ( он же /var/lib/vz ). Все следующие действия шага 3 можно делать только на отмонтированном ресурсе – соответственно перед этим гасим все VM которые используют хранилище local на данном узле. Остальное можно не трогать если очень нужно.
#umount /dev/pve/data

3.1. Уменьшение /dev/pve/data.
В принципе несколько следующих шагов можно заменить командами
#lvresize -L 55G /dev/mapper/pve-data
#mkfs.ext3 /dev/pve/data

Ну или чуть более развернуто. И по-моему чуть более корректно.
#lvremove /dev/pve/data
#lvcreate -n data -l 55G pve
#mkfs.ext3 /dev/pve/data

Но при этом мы теряем все что есть на хранилище local. Если Proxmox свежеустановленый (что в общем то рекомендуется для манипуляций такого рода), то на этом все и идем к шагу 4. Если же стоит вопрос все-таки сохранить данные в хранилище local, то действуем иначе.

3.2. Уменьшение /dev/pve/data без потери информации.
Я исхожу из того что занято на local меньше чем 50G. Если у вас другая ситуация то просто поменяйте «новый размер» в командах.

#umount /dev/pve/data

Обязательная проверка, без нее не сработает resize2fs
#e2fsck -f /dev/mapper/pve-data
e2fsck 1.42.5 (29-Jul-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/pve-data: 20/53223424 files (0.0% non-contiguous), 3390724/212865024 blocks

Сжимаем файловую систему до 50G. Если данный шаг пропустить то с вероятностью 90% после lvresize мы получим битую систему. Причем число намеренно немножко меньше чем результирующий раздел. С запасом.
#resize2fs /dev/mapper/pve-data 50G
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mapper/pve-data to 13107200 (4k) blocks.
The filesystem on /dev/mapper/pve-data is now 13107200 blocks long.

#e2fsck -f /dev/mapper/pve-data

Сжимаем непосредственно раздел /pve/data до 55G
#lvresize -L 55G /dev/mapper/pve-data
WARNING: Reducing active logical volume to 55.00 GiB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce data? [y/n]: y
Reducing logical volume data to 55.00 GiB
Logical volume data successfully resized

Занимаем системой все доступное пространство. В принципе если ваш «запас» на предидущем шаге не большой, то этого можно и не делать. Зачем экономить на спичках? ;)
#resize2fs /dev/mapper/pve-data
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mapper/pve-data to 14417920 (4k) blocks.
The filesystem on /dev/mapper/pve-data is now 14417920 blocks long.

Возвращаем /dev/pve/data системе.
#mount /dev/pve/data

4. Создание раздела для drbd
Смотрим свободное место. Убеждаемся что все предидущие шаги дали то, что неободимо. Т.е свободное место на разделе /dev/sda2
#pvdisplay
--- Physical volume ---
PV Name /dev/sda2
VG Name pve
PV Size 931.01 GiB / not usable 0
Allocatable yes
PE Size 4.00 MiB
Total PE 238339
Free PE 197891
Allocated PE 40448
PV UUID 6ukzQc-D8VO-xqEK-X15T-J2Wi-Adth-dCy9LD

Создаем новый раздел на всё свободное пространство.
#lvcreate -n drbd0 -l 100%FREE pve
Logical volume "drbd" created

5. Готовим файл конфигурации drbd
#nano /etc/drbd.d/r0.res
resource r0 {

startup {
wfc-timeout 120;
degr-wfc-timeout 60;
become-primary-on both;
}

net {
cram-hmac-alg sha1;
shared-secret «proxmox»;
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
syncer {
rate 30M;
}
on p1 {
device /dev/drbd0;
disk /dev/pve/drbd;
address 10.1.1.1:7788;
meta-disk internal;
}
on p2 {
device /dev/drbd0;
disk /dev/pve/drbd;
address 10.1.1.2:7788;
meta-disk internal;
}
}

Параметр wfc-timeout некоторые рекомендуют ставить в 0. Смысл его – если при старте мы не видим соседа drbd то через wfc-timeout секунд перезагрузится для повторной попытки. 0 – означает отключить подобное действие.
Rate 30M – ограничение передачи между drbd хостами. Значение соответствует 1G соединению. Рекомендовано как 30% от реальной пропускной способности канала между хостами. В примере ниже на «тестовых кроликах» пропускная способность на 100M соединении около 11Mb/s т.е rate надо уменьшить до 3M. При 10G соединении между хостами явно имеет смысл увеличить.

6. Создание мета-данных и запуск drbd раздела.
#modprobe drbd

#drbdadm create-md r0
md_offset 830015008768
al_offset 830014976000
bm_offset 829989642240

Found some data

==> This might destroy existing data! <==

Do you want to proceed?
[need to type 'yes' to confirm] yes

Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
Success

#drbdadm up r0

Посмотреть результат можно так:
#cat /proc/drbd
version: 8.3.13 (api:88/proto:86-96)
GIT-hash: 83ca112086600faacab2f157bc5a9324f7bd7f77 build by root@sighted, 2012-10-09 12:47:51
0: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/DUnknown C r----s
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:810536760

7. Подготавливаем второй хост
Шаги 1-6 потворяем на второй хост машине. Важный момент(!). Размер раздела drbd должен быть идентичен на обоих хостах.

8. Синхронизация.
Берем один из хостов ( не имеет значения на какой ). Назовем его до полной синхронизации primary. Второй соответственно secondary. После полной синхронизации они станут равноценными -такой режим мы задали.

#drbdadm -- --overwrite-data-of-peer primary r0

# cat /proc/drbd
version: 8.3.13 (api:88/proto:86-96)
GIT-hash: 83ca112086600faacab2f157bc5a9324f7bd7f77 build by root@sighted, 2012-10-09 12:47:51
0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r----s
ns:0 nr:0 dw:0 dr:664 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:810536760

после чего на обоих хостах
#drbdadm down r0
#service drbd start

На primary результат будет выглядеть так:
Starting DRBD resources:[ d(r0) s(r0) n(r0) ]..........
***************************************************************
DRBD's startup script waits for the peer node(s) to appear.
- In case this node was already a degraded cluster before the
reboot the timeout is 60 seconds. [degr-wfc-timeout]
- If the peer was available before the reboot the timeout will
expire after 120 seconds. [wfc-timeout]
(These values are for resource 'r0'; 0 sec -> wait forever)
To abort waiting enter 'yes' [ 18]:
.

На secondary:

Starting DRBD resources:[ d(r0) s(r0) n(r0) ]..........
***************************************************************
DRBD's startup script waits for the peer node(s) to appear.
- In case this node was already a degraded cluster before the
reboot the timeout is 60 seconds. [degr-wfc-timeout]
- If the peer was available before the reboot the timeout will
expire after 120 seconds. [wfc-timeout]
(These values are for resource 'r0'; 0 sec -> wait forever)
To abort waiting enter 'yes' [ 14]:
0: State change failed: (-10) State change was refused by peer node
Command '/sbin/drbdsetup 0 primary' terminated with exit code 11
0: State change failed: (-10) State change was refused by peer node
Command '/sbin/drbdsetup 0 primary' terminated with exit code 11
0: State change failed: (-10) State change was refused by peer node
Command '/sbin/drbdsetup 0 primary' terminated with exit code 11
.

Ошибки\задержки связаны с тем что мы перезапустили все одновременно. В нормальной ситуации запуск выглядит просто:

#service drbd start
Starting DRBD resources:[ d(r0) s(r0) n(r0) ].

# cat /proc/drbd
version: 8.3.13 (api:88/proto:86-96)
GIT-hash: 83ca112086600faacab2f157bc5a9324f7bd7f77 build by root@sighted, 2012-10-09 12:47:51
0: cs:SyncSource ro:Primary/Primary ds:UpToDate/Inconsistent C r-----
ns:199172 nr:0 dw:0 dr:207920 al:0 bm:11 lo:1 pe:24 ua:65 ap:0 ep:1 wo:b oos:810340664
[>....................] sync'ed: 0.1% (791348/791536)M
finish: 19:29:01 speed: 11,532 (11,532) K/sec

тут мы видим, что началась синхронизация дисков.
Запустим мониторинг этого процесса и идем погулять. В зависимости от размеров диска и скорости соединения между хостами гулять можем от пары часов до суток…

#watch –n 1 “cat /proc/drbd”

И ждем заветного 100%

cs:SyncSource ro:Primary/Primary ds:UpToDate/ UpToDate

9. Создание lvm volume group
Процесс долог, потому продолжим на primary хосте.
#vgcreate drbd-0 /dev/drbd0
No physical volume label read from /dev/drbd0
Writing physical volume data to disk "/dev/drbd0"
Physical volume "/dev/drbd0" successfully created
Volume group "drbd-0" successfully created


10. Подключение группы в Proxmox

Выбираем раздел Датацентр-Хранилище в GUI Proxmox. Добавить. Тип — LVM, ID произвольно — это просто название. Группа разделов drbd-0, + включить, + общедоступно.
Обратите внимание на выделенные моменты. drbd-0 это группа созданная на шаге 9.
Ну а общедоступность выставляется для того чтоб Proxmox не пытался скопировать сам образы хост-дисков машин в процессе миграции.

11. Все.
Дождавшись окончания синхронизации можно создавать машины выбирая drbd в качестве хранилища image-disk, переносить их с хоста на хост в кластере не теряя связи с виртуальной машиной для обслуживания хост машины. В общем все готово для построения High Availability Cluster — Proxmox

Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 18

    +2
    Не очень хорошо получается. Во-первых, кто будет разбираться после краха какой сервер взять за primary? Как бороться с split brain?
    Инструкция на сайте рекомендует делать два DRBD раздела, primary-secondary каждый — pve.proxmox.com/wiki/DRBD#Recovery_from_split_brain_when_using_two_DRBD_volumes для упрощения восстановления. Инфтрукция pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster#Quorum_Disk_Configuration описывает ещё одну маленькую деталь — создание диска для кворума, что немного выправляет ситуацию.
      0
      мое мнение такое. в случае краха в ситуации когда совсем непонятно кто главный — берем любой и назначаем его primary, второй по вами указанной инструкции выводим\вводим\синхронизируем. В случае если что то не работает — восстанавливаем из backup виртуальную машину ( мы же делаем backup на отдельное хранилище\хост !). Зато в режиме primary/primary если упадет один (любой ) хост — мы ничего даже не заметим. В неравном режиме если падает prime — то secondary до манипуляций ручками не работает — только r/o. по-крайней мере так есть у меня на тестовых кроликах.
      ну а два ресурса или больше — это уже вопрос процедуры восстановления… Это просто позволяет не гасить машины на время восстановления. Но если 7\24 то имеет смысл таки нормальное хранилище купить отдельное. и по iSCSI. Все-таки drbd — это некий костыль. ну как программный рейд.
      Диск для кворума — это третий хост. т.е другая задача. Конечно с ним лучше. А еще с него можно fencing устроить и полноценный HA Cluster без всяких аппаратных iLO
        0
        DRBD версии от 8.3.13 уже нормально справляется развалом и синхронизирует на разных узлах только измененные участки (при условии что изменения не наложились на обоих узлах, если машины не мигрировали в момент развала, то вероятность этого минимальна)
        +1
        Как бы при нулевой установке, зачем такие пляски? Можно просто в приглашении boot, при установке написать:
        linux ext4 maxroot=8 swapsize=2 maxvz=10
        Этим мы займем 20Гб пространства диска, остальное свободно для дальнейших манипуляций. И я бы положил DRBD на LVM раздел, оставив немного свободного места для дальнейших возможных манипуляций (например снапшота раздела для бэкапа или увеличения емкости). Это дополнительная абстракция, но на скорость не влияет. А вот проделать такое получится проще, да и мало ли что в будущем понадобится, вынести DRBD на внешний кластер хранения, например.
          0
          ух ты! браво!
          только после Вашей подсказки нашел описание этой фичи ( задать как разбить диски при установке Proxmox ) причем в разделе Debugging Proxmox VE Install
          Будем проверять как оно работает.
          0
          По завершении wfc-timeout сервер загрузится и DRBD будет работать как standalone.
            0
            Правильно я понял, что в данном случае мы имеет слои PV -> LVM -> DRBD -> LVM?
              0
              нет. DBRD делается на «сырое» пространство. а LVM строится уже поверх DBRD. Все предидущие манипуляции нужны чтоб выделить это сырое постранство т.к PROXMOX по-умолчанию после установки занимает все пространство диска. Что, с учетом комментария уважаемого Supme, скорее стало практическим занятием чем реальной надобностью )))
              Вообще то как показывает опыт — правильно под DBRD отдавать отдельный физический диск на каждом из серверов. Так более оптимально работает система в целом.
                0
                Ну тогда я не очень понимаю.

                Из статьи:
                device /dev/drbd0;
                disk /dev/pve/drbd;

                т.е. создаём drbd0 поверх уже существующей lv «drbd»

                vgcreate drbd-0 /dev/drbd0

                Поверх drbd0 уже создаётся vg «drbd-0».
                Т.е. всё-таки «LVM -> DRBD -> LVM»?

                Насчёт сырого пространства — если под этим подразумевается целый раздел на диске, то в случае с proxmox он всё равно займёт на диске всё место под vg «pve», какие параметры не задавай.
                  0
                  пусть гуру меня поправят но я так понимаю что мы создаем dtbd поверх /dev/sda2
                  команда указанная вами — это создание LVM поверх DRBD. т.е /dev/sda2 -> DRBD -> LVM
                  сам раздел /dev/sda2 должен быть либо блочным устройством либо разделом LVM. в описаном случае вы правы но это просто один из вариантов. т.е совершенно не обязательно.
                  DRBD® works on top of block devices, i.e., hard disk partitions or LVM's logical volumes. It mirrors each data block that it is written to disk to the peer node. © http://www.drbd.org/home/mirroring

                  целесообразность делать DRBD over LVM обсуждается на форумах постоянно. кто то за, сложно аргументируя, кто то против.
                  А внутри DRBD строится LVM из-за того что именно с LVM умеет работать PROXMOX как с хранилищем.
                    0
                    И всё-таки, в данном случае мы создаём поверх DRBD именно LV, который создан в VG, находящейся в PV /dev/sda2 :)
                    Это легко проверить — lvdisplay покажет, что lv «drbd-0» меньше lv «drbd» как раз на размер метаданных DRBD.
                    И, кстати, большой вопрос — как удалось получить систему с двумя разделами, когда при установке proxmox создаёт один раздел — и никакими параметрами, как я понял, это изменить нельзя.
                      0
                      да, я исправился. в данном конкретном случае drbd поверх LVM. так просто проще)) поскольку мы просто уменьшили раздел PVE-DATA и на оставшемся месте сделали новый раздел DRBD. создать два раздела ( ну в смысле сразу раздел под дату и под drbd ) при инсталяции proxmox нельзя ( скажем так — я не знаю как ) но благодаря комментарию можно заранее оставить место, чтобы не играться с resize.
                      Хотя весь мой опыт говорит — сделайте drbd на отдельном физическом диске для нормальной работы. Будет быстрее, надежнее и проще.
                        0
                        В этом случае вам нужно правильно настроить фильтр в /etc/lvm/lvm/conf, иначе у вас один и тот же PV будет два раза обрабарываться, сначала как /dev/pve/drbd, а потом как /dev/drbd0 (а может и в обратном порядке). В таком случае можно лекго набедокурить.
                          0
                          в общем да. в рекомендациях по установке drbd есть такой момент — добавить в /etc/lvm/lvm/conf
                          в запись filter = [… ] добавить " r|/dev/drbd0/| " что исключает /dev/drbd0 из обработки.
                          я забыл тут упомянуть этот момент.
                            0
                            Кстати, это актуально так же и в случае, если DRBD на физическом разделе.
                            Я делаю так для надёжности:
                            filter = [ "r|^/dev/sda3|", "a|^/dev/sd|", "a|^/dev/drbd|" ,"r/.*/" ]
                            
                            Последовательно: исключить /dev/sda3, сканировать все остальные /dev/sd*, сканировать /dev/drbd, исключить всё остальное, где /dev/sda3 это основа для drbd0.
                              0
                              стандартный фильтр что то типа
                              filter = [ "a/.*/" ]
                              поэтому часто достаточно сделать
                              filter = [ "r|^/dev/DEVNAME/|", "a/.*/" ]
                              где /dev/DEVNAME — основа для drbd.

                              В учебных целях я тестировал систему без установки фильтров. Я не смог создать ситуации когда б это разрушило целостность или существенно снизило быстродействие. да вообще хоть как-то заметно повлияло.
                              Но логика подсказывает что так (без фильтрования) неправильно да и сами разработчики настоятельно рекомендуют учитывать этот момент.
                                0
                                Проблема возникнет тогда, когда у тебя замапятся логические диски не из DRBD, а /dev/sdaX, т.е. данные в LVM будут изменяться снизу и DRBD будет не в курсе изменений.

                                > поэтому часто достаточно сделать
                                Я исключаю всё и добавляю только нужное, чтобы не рисковать, т.к. логические тома LVM доступны не только как /dev/vgname/xxx, но и /dev/dm-nnn.
                              0
                              И вот ещё важное: pve.proxmox.com/wiki/DRBD#WARNINGS

              Only users with full accounts can post comments. Log in, please.