LINUX.ORG.RU

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

 , , , ,


1

4

Исходная ситуация: необходимо подключить две ноды к одному iSCSI target, т.ч. они могли бы писать/читать туда одновременно. Цель — бекапы, т.ч. производительность не очень важна. Конкуретный доступ к одной FS тоже не обязателен. Таргет виден в обоих системах как /dev/sdb.

Стал разбираться со всеми этими ocfs2, gfs2, clvm и уже запутался. Попробовал ocfs2, но он у меня почему-то встал раком, наплодил кучу D state и машинки пришлось перегружать.

Как лучше сделать (и можно ли так сделать? Опыта с iscsi у меня к сожалению нет, а толковой инфы мало.)

  • Тупо разбить диск на sdb1/sdb2 и подмонтировать каждую в своей ноде.
  • Разбить диск lvm на 2 lv и так же как выше. Необходим ли тогда clvm? — у каждой ноды будет свой lv.
  • Продолжать мучать ocfs2, gfs2 ... и другие. (Как-то оно меня не очень убеждает.)

Главное сомнение — не погрызутся ли две ноды по IO к iSCSI в случае mbr/lvm решения?

★★★★★

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

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

Difrex ★★★★ ()
Ответ на: комментарий от Difrex

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

beastie ★★★★★ ()

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

int13h ★★★★★ ()

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

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

Mr_Alone ★★★★★ ()

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

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

Цель — бекапы

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

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

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

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

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

Yustas ★★★ ()
Последнее исправление: Yustas (всего исправлений: 1)
Ответ на: комментарий от Yustas

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

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

beastie ★★★★★ ()
Ответ на: комментарий от Yustas

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

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

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

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

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от beastie

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

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

Yustas ★★★ ()
Ответ на: комментарий от Yustas

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Bers666

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

Bers666 ★★★★ ()
Ответ на: комментарий от post-factum

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

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

kirk_johnson ★★ ()
Ответ на: комментарий от kirk_johnson

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

post-factum ★★★★★ ()

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

val-amart ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

kirk_johnson ★★ ()
Ответ на: комментарий от kirk_johnson

lustre

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

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

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

post-factum ★★★★★ ()
Ответ на: комментарий от kirk_johnson

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

val-amart ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.