Изменение устройства DRBD

Пытаюсь обуздать proxmox.
1. На машине с proxmox (p1) создается lvm-группа: vg.
2. Создаем логический диск в группе vg: lv.
3. То же самое проделываем на другой машине с proxmox (p2).
4. На логических дисках (lv) делаем drbd-устройство: drbd0.
5. Поверх drbd0 создаем еще одну lvm-группу, которую уже и используем в proxmox.

Пытаюсь изменить размер drbd0:
- увеличиваю размер логического диска lv (на p1 и p2).
- а дальше? видимо мне надо обновить мета-данные, но у drbdadm не нашел такого параметра.

Вообще возможно изменить размер без потери данных?

Если я правильно понял и правильно помню.

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

Этой командой, мы указываем о необходимости синхронизировать данные, расположенные на primary с данными на secondary сервере. После завершении синхронизации, данные на secondary будут перезаписаны.

Marley написал:

Этой командой, мы указываем о необходимости синхронизировать данные

Кажется, я плохо объяснил:
- drbd собран поверх lvm-диска и занимает весь его объем;
- увеличиваю размер lvm-диска;
- теперь нужно как-то сообщить drbd о том, что размер поменялся. Данные, которые поверх drbd должны остаться целыми.

Ой! Нашлось!
Как до этого момента искал *PARDON*
Тему можно убить.

GUID написал:

Пытаюсь обуздать proxmox.
1. На машине с proxmox (p1) создается lvm-группа: vg.
2. Создаем логический диск в группе vg: lv.
3. То же самое проделываем на другой машине с proxmox (p2).
4. На логических дисках (lv) делаем drbd-устройство: drbd0.
5. Поверх drbd0 создаем еще одну lvm-группу, которую уже и используем в proxmox.

Пытаюсь изменить размер drbd0:
- увеличиваю размер логического диска lv (на p1 и p2).
- а дальше? видимо мне надо обновить мета-данные, но у drbdadm не нашел такого параметра.

Вообще возможно изменить размер без потери данных?

Вот не надо сейчас на drbd громоздить lvm-тома. А именно - имел на прошедший Новый Год (в аккурат на праздники) большую проблему с этим. Даже не проблему, а фатальный крах на связке CentOS-6.5+drbd+LVM. Долгое время всё работало без проблем. А вот здесь решил обновить систему. Обновилось, как водится и ядро оси. Ну а после этого рухнули (от слова абсолютно) LVM-разделы, что жили на одном большом drbd-томе. Ситуация была устойчивой и уверенно воспроизводилась как на реальном, рабочем, железе, так и на виртуальных машинах.
Так что теперь вместо одного drbd-тома и нескольких LVM-томов на нем пользую несколько мелких LVM-томов, которые связываю по drbd. Соответсвенно, не знаю исправилась на более новых ядрах ситуация или нет. Не знаю.

Но бэкапы - рулят. Без них была бы форменная катастрофа.

drbd вообще какой то нестабильный. а актив/актив вообще нельзя трогать (и поддержка linbit это подтверждает)

Спасибо за комментарии - задумался.

"Cruiser78" написал:

Вот не надо сейчас на drbd громоздить lvm-тома

Мне эта идея тоже не понравилась, но это делалось для proxmox: он создает логические тома в группе при создании диска VM.
А какая была версия drbd?

"dyasny" написал:

drbd вообще какой то нестабильный

"я же говорил: место проклятое, а ты: "руки кривые, руки кривые" (с) анек
То-то он у меня на тестовой связке пару раз легко слетел.

"dyasny" написал:

актив/актив вообще нельзя трогать

После того как выяснилось, что fencing у меня будет в лучшем случае вручную, то наверное сделаю primary/secondary, т.к. в любом случае ручками лазить придется.

"GUID" написал:

То-то он у меня на тестовой связке пару раз легко слетел.

именно поэтому его лучше вообще не трогать. есть ceph, gluster, zfs наконец

"GUID" написал:

После того как выяснилось, что fencing у меня будет в лучшем случае вручную, то наверное сделаю primary/secondary, т.к. в любом случае ручками лазить придется.

я о другом. у меня было много встреч с linbit и они сами прямо говорят не трогать режим a/a ни в коем случае

"dyasny" написал:

есть ceph, gluster, zfs наконец

Для двух хиленьких недо-серверов, соединеных 1Gb сетью:
- ceph: не подходит по ТТХ (3 сервера, не очень слабые);
- gluster: быстрый гуглеж показал наличие отзывов о нестабильности и показалось, что мое железо тоже не сильно подходит;
- zfs: а разве это "сетевая" фс?!

"dyasny" написал:

не трогать режим a/a

Я правильно понял:
- "а/а" == primary/primary ?
- "не трогать" == не использовать ?

"GUID" написал:

- ceph: не подходит по ТТХ (3 сервера, не очень слабые);

там есть варианты, 3 это стандарт для очень больших установок, для мелких и двух хватит

"GUID" написал:

- gluster: быстрый гуглеж показал наличие отзывов о нестабильности и показалось, что мое железо тоже не сильно подходит;

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

"GUID" написал:

- zfs: а разве это "сетевая" фс?!

там возможна репликация ZVOL через сеть

"GUID" написал:

- "а/а" == primary/primary ?

актив/актив, да

"GUID" написал:

- "не трогать" == не использовать ?

более того, даже не задумываться о таком варианте

GUID написал:

Спасибо за комментарии - задумался.

[quote="Cruiser78"]Вот не надо сейчас на drbd громоздить lvm-тома

Мне эта идея тоже не понравилась, но это делалось для proxmox: он создает логические тома в группе при создании диска VM.
А какая была версия drbd?
[/quote]

Версия - 8.4.4. Последняя на декабрь прошлого года. Какая сейчас последняя - не скажу, не знаю. Работало всё в режиме Primary/Secondary и никак иначе. Компилировалась она на нужное ядро самостоятельно, на виртуальной машине стенда. Причем, что самое печальное - LVM на DRBD жил у меня несколько лет вполне утойчиво и беспроблемно. Менялось при обновлениях ядро - автоматом (после загрузки с новым ядром) перекомпилировался соответствующий модуль drbd и всё работало как часы. Я просто не ожидал такой полянки, делал большое новогоднее обновление из дома... А оно - возьми и обломайся полностью. Хорошо была неделя в запасе на починку установки.

По гластеру - мне он тоже нравится. И я его тоже использую, храню на нём архивы и конфигурационные файлы и различные скрипты, которые должны быть синхронизированы на нескольких серверах. Очень удобно. Но у него есть один недостаток - он плохо ложится под самбу. Не держит он блокировок самбовых. В результате у меня 1С (7.7 файловый) на нём валился на раз при совместном доступе. И еще тот же ворд от мелкомягких не мог открывать сетевые файлы. Вис намертво. Перенёс всю самбу на drbd - всё работает четко, как в аптеке.

Такой вот личный опыт. Скоро опять Новогодние каникулы... Может еще что нового для себя открою...

"Cruiser78" написал:

Перенёс всю самбу на drbd - всё работает четко, как в аптеке

гластер - имплементация posixFS с распределением по сети, drbd - репликация на блочном уровне, FS там нет. Их сложно сравнивать без контекста

dyasny написал:

[quote="Cruiser78"]Перенёс всю самбу на drbd - всё работает четко, как в аптеке

гластер - имплементация posixFS с распределением по сети, drbd - репликация на блочном уровне, FS там нет. Их сложно сравнивать без контекста[/quote]
Это понятно. Я их и не сравниваю. Я как раз об особенностях применения пишу. Особенностях, которые вылезают при работе третьих (если не четвертых) приложений.
Хотя - до сих пор понять не могу - что же там в LVM изменилось, что оно на DRBD жить не захотело...

"Cruiser78" написал:

что же там в LVM изменилось, что оно на DRBD жить не захотело...

глюк в одном блоке или неверный оффсет, и LVM может слететь.

Спасибо за содержательный ответ!
[offtop]
Узнал даже то, чего не спрашивал. А если бы чуть активнее искал в гугле, то нашел бы ответ _только_ на свой вопрос и вероятнее всего встал бы на те же грабли.
[/offtop]

GUID написал:

Спасибо за содержательный ответ!
[offtop]
Узнал даже то, чего не спрашивал. А если бы чуть активнее искал в гугле, то нашел бы ответ _только_ на свой вопрос и вероятнее всего встал бы на те же грабли.
[/offtop]

Ну, тогда еще грабелек разложу.
Исходники DRBD до версии 8.4.4 включительно шли собранными в один пакет. Начиная с версии 8.4.5 политика распространения изменилась. Модуль ядра идет в пакете drbd-8.4.5, а весь остальной управляющий утиль вынесен в отдельный архив drbd-utils-8.9.X Так вот, При попытке собрать 8.9.1 возникает ошибка с руганью, что нет требуемого drbd-udev. Собираем тогда 8.9.0. Там такой ругачки нет. Накатываем новый DRBD (кстати, данные на томах сохраняются, проверил личной практикой на стенде, на виртуалках, и в продакшене) и имеем неожиданное удовольствие, которое не с первого взгляда и заметишь. DRBD 8.4.5 работает с данными, со своими томами как часы, но вот ссылки на /dev/drbdN в каталогах /dev/disk/by-res (и так далее) не создаются ни разу. Нету удавных на то правил правил...

Так что, после не самой удачной попытки обновить DRBD откатился на прежнюю версию, на 8.4.4.

"Cruiser78" написал:

Нету удавных на то правил

Можно же написать, или проверить пригодность уже имеющихся от старого пакета. Не копал, но думаю, что в тарболе с исходниками должны быть или заготовки, или уже готовые правила, которые достаточно при создании пакета скопировать в $PKG/lib/udev/rules.d.

yars написал:

[quote="Cruiser78"]Нету удавных на то правил

Можно же написать, или проверить пригодность уже имеющихся от старого пакета. Не копал, но думаю, что в тарболе с исходниками должны быть или заготовки, или уже готовые правила, которые достаточно при создании пакета скопировать в $PKG/lib/udev/rules.d.[/quote]

Для этого вначале надо понять, что проблема существует. И что обычное обновление пакета не очень корректно проходит. Не знаешь - есть много шансов, что пролетит мимо тебя.
Например, если моетируешь каталог командой mount /dev/drdb0 - то всё намано. Это хорошо, если у тебя только один drbd диск. А если несколько? Тогда надо обращаться к ним по имени ресурса, а там опаньки... Эффекты могут быть очень интересными и непредсказуемыми.