Cruiser78 пишет:

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

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

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

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

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

Спасибо за содержательный ответ!
[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.

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

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

Cruiser78 пишет:

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

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

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

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

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

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

Cruiser78 пишет:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пытаюсь обуздать 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. Соответсвенно, не знаю исправилась на более новых ядрах ситуация или нет. Не знаю.

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