Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Не очень хорошо получается. Во-первых, кто будет разбираться после краха какой сервер взять за 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 описывает ещё одну маленькую деталь — создание диска для кворума, что немного выправляет ситуацию.
Инструкция на сайте рекомендует делать два 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 описывает ещё одну маленькую деталь — создание диска для кворума, что немного выправляет ситуацию.
мое мнение такое. в случае краха в ситуации когда совсем непонятно кто главный — берем любой и назначаем его primary, второй по вами указанной инструкции выводим\вводим\синхронизируем. В случае если что то не работает — восстанавливаем из backup виртуальную машину ( мы же делаем backup на отдельное хранилище\хост !). Зато в режиме primary/primary если упадет один (любой ) хост — мы ничего даже не заметим. В неравном режиме если падает prime — то secondary до манипуляций ручками не работает — только r/o. по-крайней мере так есть у меня на тестовых кроликах.
ну а два ресурса или больше — это уже вопрос процедуры восстановления… Это просто позволяет не гасить машины на время восстановления. Но если 7\24 то имеет смысл таки нормальное хранилище купить отдельное. и по iSCSI. Все-таки drbd — это некий костыль. ну как программный рейд.
Диск для кворума — это третий хост. т.е другая задача. Конечно с ним лучше. А еще с него можно fencing устроить и полноценный HA Cluster без всяких аппаратных iLO
ну а два ресурса или больше — это уже вопрос процедуры восстановления… Это просто позволяет не гасить машины на время восстановления. Но если 7\24 то имеет смысл таки нормальное хранилище купить отдельное. и по iSCSI. Все-таки drbd — это некий костыль. ну как программный рейд.
Диск для кворума — это третий хост. т.е другая задача. Конечно с ним лучше. А еще с него можно fencing устроить и полноценный HA Cluster без всяких аппаратных iLO
DRBD версии от 8.3.13 уже нормально справляется развалом и синхронизирует на разных узлах только измененные участки (при условии что изменения не наложились на обоих узлах, если машины не мигрировали в момент развала, то вероятность этого минимальна)
Как бы при нулевой установке, зачем такие пляски? Можно просто в приглашении boot, при установке написать:
Этим мы займем 20Гб пространства диска, остальное свободно для дальнейших манипуляций. И я бы положил DRBD на LVM раздел, оставив немного свободного места для дальнейших возможных манипуляций (например снапшота раздела для бэкапа или увеличения емкости). Это дополнительная абстракция, но на скорость не влияет. А вот проделать такое получится проще, да и мало ли что в будущем понадобится, вынести DRBD на внешний кластер хранения, например.
linux ext4 maxroot=8 swapsize=2 maxvz=10Этим мы займем 20Гб пространства диска, остальное свободно для дальнейших манипуляций. И я бы положил DRBD на LVM раздел, оставив немного свободного места для дальнейших возможных манипуляций (например снапшота раздела для бэкапа или увеличения емкости). Это дополнительная абстракция, но на скорость не влияет. А вот проделать такое получится проще, да и мало ли что в будущем понадобится, вынести DRBD на внешний кластер хранения, например.
ух ты! браво!
только после Вашей подсказки нашел описание этой фичи ( задать как разбить диски при установке Proxmox ) причем в разделе Debugging Proxmox VE Install
Будем проверять как оно работает.
только после Вашей подсказки нашел описание этой фичи ( задать как разбить диски при установке Proxmox ) причем в разделе Debugging Proxmox VE Install
Будем проверять как оно работает.
По завершении wfc-timeout сервер загрузится и DRBD будет работать как standalone.
Правильно я понял, что в данном случае мы имеет слои PV -> LVM -> DRBD -> LVM?
нет. DBRD делается на «сырое» пространство. а LVM строится уже поверх DBRD. Все предидущие манипуляции нужны чтоб выделить это сырое постранство т.к PROXMOX по-умолчанию после установки занимает все пространство диска. Что, с учетом комментария уважаемого Supme, скорее стало практическим занятием чем реальной надобностью )))
Вообще то как показывает опыт — правильно под DBRD отдавать отдельный физический диск на каждом из серверов. Так более оптимально работает система в целом.
Вообще то как показывает опыт — правильно под DBRD отдавать отдельный физический диск на каждом из серверов. Так более оптимально работает система в целом.
Ну тогда я не очень понимаю.
Из статьи:
т.е. создаём drbd0 поверх уже существующей lv «drbd»
Поверх drbd0 уже создаётся vg «drbd-0».
Т.е. всё-таки «LVM -> DRBD -> LVM»?
Насчёт сырого пространства — если под этим подразумевается целый раздел на диске, то в случае с proxmox он всё равно займёт на диске всё место под vg «pve», какие параметры не задавай.
Из статьи:
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», какие параметры не задавай.
пусть гуру меня поправят но я так понимаю что мы создаем 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 как с хранилищем.
команда указанная вами — это создание 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 как с хранилищем.
И всё-таки, в данном случае мы создаём поверх DRBD именно LV, который создан в VG, находящейся в PV /dev/sda2 :)
Это легко проверить — lvdisplay покажет, что lv «drbd-0» меньше lv «drbd» как раз на размер метаданных DRBD.
И, кстати, большой вопрос — как удалось получить систему с двумя разделами, когда при установке proxmox создаёт один раздел — и никакими параметрами, как я понял, это изменить нельзя.
Это легко проверить — lvdisplay покажет, что lv «drbd-0» меньше lv «drbd» как раз на размер метаданных DRBD.
И, кстати, большой вопрос — как удалось получить систему с двумя разделами, когда при установке proxmox создаёт один раздел — и никакими параметрами, как я понял, это изменить нельзя.
да, я исправился. в данном конкретном случае drbd поверх LVM. так просто проще)) поскольку мы просто уменьшили раздел PVE-DATA и на оставшемся месте сделали новый раздел DRBD. создать два раздела ( ну в смысле сразу раздел под дату и под drbd ) при инсталяции proxmox нельзя ( скажем так — я не знаю как ) но благодаря комментарию можно заранее оставить место, чтобы не играться с resize.
Хотя весь мой опыт говорит — сделайте drbd на отдельном физическом диске для нормальной работы. Будет быстрее, надежнее и проще.
Хотя весь мой опыт говорит — сделайте drbd на отдельном физическом диске для нормальной работы. Будет быстрее, надежнее и проще.
В этом случае вам нужно правильно настроить фильтр в /etc/lvm/lvm/conf, иначе у вас один и тот же PV будет два раза обрабарываться, сначала как /dev/pve/drbd, а потом как /dev/drbd0 (а может и в обратном порядке). В таком случае можно лекго набедокурить.
в общем да. в рекомендациях по установке drbd есть такой момент — добавить в /etc/lvm/lvm/conf
в запись filter = [… ] добавить " r|/dev/drbd0/| " что исключает /dev/drbd0 из обработки.
я забыл тут упомянуть этот момент.
в запись filter = [… ] добавить " r|/dev/drbd0/| " что исключает /dev/drbd0 из обработки.
я забыл тут упомянуть этот момент.
Кстати, это актуально так же и в случае, если DRBD на физическом разделе.
Я делаю так для надёжности:
Я делаю так для надёжности:
filter = [ "r|^/dev/sda3|", "a|^/dev/sd|", "a|^/dev/drbd|" ,"r/.*/" ]
стандартный фильтр что то типа
поэтому часто достаточно сделать
где /dev/DEVNAME — основа для drbd.
В учебных целях я тестировал систему без установки фильтров. Я не смог создать ситуации когда б это разрушило целостность или существенно снизило быстродействие. да вообще хоть как-то заметно повлияло.
Но логика подсказывает что так (без фильтрования) неправильно да и сами разработчики настоятельно рекомендуют учитывать этот момент.
filter = [ "a/.*/" ] поэтому часто достаточно сделать
filter = [ "r|^/dev/DEVNAME/|", "a/.*/" ] где /dev/DEVNAME — основа для drbd.
В учебных целях я тестировал систему без установки фильтров. Я не смог создать ситуации когда б это разрушило целостность или существенно снизило быстродействие. да вообще хоть как-то заметно повлияло.
Но логика подсказывает что так (без фильтрования) неправильно да и сами разработчики настоятельно рекомендуют учитывать этот момент.
Проблема возникнет тогда, когда у тебя замапятся логические диски не из DRBD, а /dev/sdaX, т.е. данные в LVM будут изменяться снизу и DRBD будет не в курсе изменений.
> поэтому часто достаточно сделать
Я исключаю всё и добавляю только нужное, чтобы не рисковать, т.к. логические тома LVM доступны не только как /dev/vgname/xxx, но и /dev/dm-nnn.
> поэтому часто достаточно сделать
Я исключаю всё и добавляю только нужное, чтобы не рисковать, т.к. логические тома LVM доступны не только как /dev/vgname/xxx, но и /dev/dm-nnn.
И вот ещё важное: pve.proxmox.com/wiki/DRBD#WARNINGS
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение drbd-зеркала на Proxmox-3.0