Кластерные FS и iSCSI

С двумя lv, кстати, может сработать без clvm, а следовательно без corosync и прочих сущностей.

Не знаю, что у тебя не так пошло с ocfs2. У меня она работает, хоть и медленно.

Меня вот смущает, не будет ли с gv конфликтов? lvm при работе туда ничего не пишет?

А не рассматривали ли drbd?

Тупо разбить диск на sdb1/sdb2 и подмонтировать каждую в своей ноде.

Всё остальное - огород.

они могли бы писать/читать туда одновременно

Если в один раздел - без кластерной ФС никак, иначе посыпется все к чертовой бабушке. А если ты собрался писать на 2 разных раздела - зачем тебе общий сторадж?

Цель — бекапы

Упс, пролюбил этот момент. Если устраивает то, что каждой ноде будет доступно только пространство того раздела, который ей выделен - делай так. Не надо будет заморачиваться с блокировками и прочим.

Но учти, эта «архитектура» не масштабируется без дополнительных телодвижений(переразбивки).

Если в один раздел - без кластерной ФС никак

Таки образом:
- если подрубить один logical volume, сделанный на общей через clvm vg, форматнуть его в ext4 и писать туда с двух систем - будет фарш?
- если использовать, что-то, что работает напрямую с lvm(vl? vg?) - оно будет нормально делить его локами?

Прошу прощения за сумбурность второй части вопроса, я недостаточно хорошо понимаю механизм функционирования lvm.
Если есть пример юзкейсов конфигурации с clvm - буду признателен.
Я недавно задавался подобным вопросом, пришел к выводу что gfs2, в принцепе, для обратного - объединения дискового пространства с нескольких серверов в единый том, и сейчас тестирую OCFS2.

напрямую с lvm(vl? vg?) - оно будет нормально делить его локами?

Вот это меня тоже интерессует.

если подрубить один logical volume, сделанный на общей через clvm vg, форматнуть его в ext4 и писать туда с двух систем - будет фарш?

Да, файловой системе кранты. Не-кластерная ФС не предполагает что кто-то кроме неё может вносить изменения, а значит во-первых - какие-то данные будут кешироваться, а во-вторых внезапное изменение журнала кем-то снаружи тоже радости не добавит

если использовать, что-то, что работает напрямую с lvm(vl? vg?) - оно будет нормально делить его локами?

Без clvm любые ОДНОВРЕМЕННЫЕ изменения метаданных lvm(количество lv в vg, их размер и т.д.) с разных нод чреваты разрушением volume group. Для того чтобы этого не происходило clvm и придумали. clvm гарантирует что в единицу времени только одна нода будет менять метаданные lvm, он же гарантирует что изменения сразу увидятся всеми остальными. Я первый раз по неопытности долго вдуплял почему без clvm при создании lv на другой ноде он не появляется пока не сделаешь lvscan. Разгадка проста - кеш.

Однако если запись идет непосредственно на сами тома - метаданные самого vg не пострадает(что очевидно)

Блочное устройство в lvm никакими локами не защищено. clvm защищает только метаданные самого lvm, в блочные устройства по-прежнему можно писать откуда угодно.

Если нужно у одно блочное устройство писать с разных нод - то тут только кластерная фс. Со своим менеджер блокировок и т.д.

тут только кластерная фс

А какие есть варианты? Ну, OCFS выше упомянули, а хочется «всех посмотерть».

Glusterfs же

Из того с чем сталкивался я - GFS2. Правда сталкивался я так, издалека, что с OCFS что с GFS2.

GlusterFS это же вроде distributed storage(как Ceph), а не shared-disk, или я что-то путаю?

Glusterfs и то, и то. Там даже nfs протокол поддерживается

Glusterfs

Он тормозит, как сучка.

Попробуй lustre / orangefs.

Поэтому с ним нужно аккуратно и вдумчиво.

Поэтому с ним нужно аккуратно и вдумчиво.

В смысле тоже начать тормозить?

Нет, сидеть в их gerrit'е и #gluster-dev. Можно узнать много нового и неожиданного.

100% создать два таргета вместо одного, отдельный под каждую систему. это если iscsi обязателен. что бы там ни было с другой стороны, это самый правильный вариант, даже лучше двух lv. для бекапа основное — надежность, а распределенный и/или общий сторедж это всегда самое слабое место любой системы, которая им (вынужденно) пользуется. говорю как последние-пару-лет-занимающийся-исключительно-distributed/shared-storage'ом-кун.

Нет, сидеть в их gerrit'е и #gluster-dev. Можно узнать много нового и неожиданного.

Гм... Ну или поставить lustre и провести это время более продуктивно. Я вот знаю, что ребята из РосГосСтрах от glusterfs плюются и пытаются с него сбежать последний год.

lustre

Хочу более детальную историю успеха. Мне интересно.

ребята из РосГосСтрах от glusterfs плюются и пытаются с него сбежать последний год

Слабаки :). Я вот коммитить начал.

сбежать *на что*? для того что он делает Гластер безальтернативен, ну разве что у них РосГосСотниНефти на IBM GPFS. или они используют его там где он на самом деле не нужен.