А как вы используете GlusterFS в продакшен?

В толксы

дурным решениям типа DRBD с обвязкой из соплей непонятно кем и как написанных BASH-скриптов.

Это ты зря, скриптов там не припомню. Но для твоей задачи оно не подходит.

>Это ты зря, скриптов там не припомню

Есть они. Назначаются хандлерами на всякие разные события, которые можно все вместе охарактеризовать ёмкой фразой «ну вот опять Ж-а :(». Что и поражает в общем-то: ни один нормальной код не будет в таких случаях использовать что-то внешнее, поскольку по идее код основной программы лучше знает, что произошло, нежели вызываемый ею BASH-скрипт.

Да там простейшие скрипты были :). И, на сколько помню, они опциональны т.к. оно само в критических ситуациях умело всё делать без скриптов.

Например, split-brain хендлер тупо шлёт уведомление на почту, от него ничего не зависит.

У меня вообще конфиги были в пару строчек и без всяких скриптов(потому что управлялось через pacemaker, вот это уже мегасуровый лютый звездец со скриптами, xml-ом, тоннами пакетов, кучей глюков и сотнями страниц документации).

Скажи честно, ты читал офицальные доки или по инструкциям в инете настраивал?

Вот, чтобы не быть голословным, откапал мой реальный конфиг:

resource drbd1 {
  on storage1 {
    device    /dev/drbd1;
    disk      /dev/hdc3;
    address   host1:7790;
    meta-disk internal;
  }
  on storage2 {
    device    /dev/drbd1;
    disk      /dev/hdc3;
    address   host2:7790;
    meta-disk internal;
  }
}

Это было поднято на центос. Оно даже работало и синкалось. Ну а статус мониторился через cat /proc/drbd.

Работает и синкится, не спорю. Вот только работает на запись с одной стороны, да плюс работает до тех пор, пока не падает с грохотом. И да, я ещё ни разу не видел, чтобы DRBD из настоящего сплитбрэйна вышел сам. НИ РАЗУ. А вот ложные сплит-брэйн (выпадание сети, падение одной из нод), когда оно начинает ни с того, ни сего себя пересинхронизировать - бывают. Хочется конечно спросить какого чёрта, но в принципе хорошо хоть с этим DRBD справляется. Но вообще документация у них хорошая, а в работе на реальном продакшене DRBD без регулярных бэкапов лучше не использовать.

Прошу прощения, то что в скобках относится не к ложным срабатываниям а к настоящим разделениям голов. Такие ситуации DRBD обрабатывает из рук вон плохо и даже простая перезагрузка нод может привести к тоннам гемороя.

Вот только работает на запись с одной стороны

оно для этого создавалось, это блочная репликация.

А вот ложные сплит-брэйн (выпадание сети, падение одной из нод)

А что ей при этом делать? Как бы ты разрулил ситуацию? Поставь центральный сервер(как это делается у GlusterFS с его lock servers) и будет тоже самое.

даже простая перезагрузка нод может привести к тоннам гемороя.

отключаешь drbd на ноде, ребутаешься, включаешь обратно, не?

>А что ей при этом делать?

Поскольку данные пишутся через драйвер DRBD, то запоминать, что и где было изменено, а после анализировать. Я считаю, что вариант поведения, когда не противоречащие друг другу записи на разных нодах принимаются -в большинстве случаев подходит. Но если не кластер, а просто реплицируемое по сети хранилище, такая ситуация исключена (нода, которая не писала раньше, не будет пытаться ни с того, ни сего стать master'ом.

>оно для этого создавалось, это блочная репликация.

Это хрен знает что не пойми для чего. Людям нужен RAID по сети, а не какое-то убожество, сыпящееся от всего.

не противоречащие друг другу записи на разных нодах

это в принципе при блочной репликации.

Так а что в принципе? Если пропадает связт между нодами, то при кластерной логике они обе могут решить, что они - Primary и, например, бывший Secondary запустит у себя те же виртуальные машины или те же сервисы, что в действительности как ни в чём ни бывало продолжают работать на никуда не девшемся Primary. Тогда и получится, что будут писать обе ноды и обе - в одни и те же блоки даже.

В принципе ты не разрулишь коллизии при блочной репликации потому что drbd не известна структура данных который он реплицирует.

Для того чтобы не было проблем достаточно добавить третью тачку. Чем это отличается от glusterFS?

не самая лучшая затея без quorum server или device делать кластеры из 2х нод.
а в случае shared модели ещё и медиаторы нужны(не в курсе, как там с этим в линуксах)

не за drdb агитирую, а просто для куда читать.

true_admin, подожди, структура-то данных неизвестна, но каждой руке из пары, в которой правая не знает, что делает левая, известно, какие записи произвела она, именно эта рука. Из сплита при отсутствии второй руки ты всё равно не выйдешь, а когда всё же удастся совершить...хм, рукопожатие, можно наконец получить целостную картину, узнав, кто что и куда записал. Разруливает ситуацию тот, кто primary. Сам алгоритм разруливания в абсолютном большинстве случаев довольно просто, потому что реально только одна нода что-то писала, а вторая либо валялась в отключе, либо ничего не делала.
true_admin, ты же пойми, я не против того, что да, наверное совместную запись в одни и те же или даже в разные блоки довольно трудно разрулить (в DRBD, кстати, тоже предлагается «решение» на этот случай: отменить все изменения на одной из нод), я против того, что DRBD как правило даже не пытается ничего разруливать, так что все их росказни в документации о том, как чудесно ОНО само, автоматически выходит из состояния split-brain в несложных ситуациях - брехня. Без в лучшем случае получасового трахания мозга оператора/админа иногда ещё и с параллельными высерами явных exception'ов в лог ядра - оно ещё НИ РАЗУ не поднималось.
Повторюсь, не поднималось именно в реальных ситуациях, когда, например, один из серверов перегрелся и отключился. В процессе как бы нормальной жизнедеятельности DRBD то и дело с бодуна решает, что он засплитбрэйнился и героически выходит из этих ситуаций автоматом. Правда, только в том случае, если это Primary/Secondary. В случае Primary/Primary всё куда более трагично: вот стоит оно вроде работает, шуршит дисками и тут - бац, ...й, ...ля, что происходит?! - одна нода отвалилась, все виртуалки в стопор. А что было-то? А DRBD в split-brain, А почему? Да просто так. Потому что реально _ничего_ не было: сеть не отваливалась (машинки соединены через гигабитный свитч над ними) и на наносекунду, никто не подвисал, процессор не занят, памяти до хрена, ошибок ввода-вывода нет. Просто правая рука снова не знает, что делает левая, вот и вся недолга.

Кстати, есть ещё одна вещь, за которую я просто ненавидел DRBD года полтора назад (сейчас уже нет такой траблы, но ведь была!) : если одна из нод в режиме P/P не видит вторую ноду, она попросту берёт и гасит к чёрту свой listener. Через какое-то время подтягивается вторая нода и видит, что первой ноды нету - она ведь коннектится к lisener'у, а тот опущен. Ну и... да-да, вторая нода тоже опускает свой listener, так что даже если первая нода попытается сделать реконнект, то получит таймаут. Я не знаю, какая в таком поведении была логика, но по-моему это абсолютный, полнейший дебилизм!

>не самая лучшая затея без quorum server или device делать кластеры из 2х нод.

Я не спорю. С одной стороны. А с другой стороны, я издевался над Gluster'ом, который мы тут обсуждаем, просто по-чёрному и таки да, умудрился один раз завалить репликацию, уничтожив часть данных. Но это нужно было делать специально. А DRBD выходит из строя сам, без всякой посторонней помощи, не будучи способным даже элементарную ситуацию внезапной перезагрузки одной из нод разрулить.

Просто в GlusterFS есть эвристика, есть какие-то простейшие зачатки интеллекта, а в DRBD - нет.

Со splitbrain я все проблемы решил(по крайней мере мне так казалось). Третья нода назначала master-ом первую тачку которая вышла в онлайн. На второй всегда делался discard local changes. Как только мастер падал в мастера переходила вторая тачка а первая назначалась slave и discard local changes.

Но вот про split-brain без видимых причин да ещё во всех версиях не верю. Явно связь падала. А дальше, да, в кластере из двух серваков секс начинается.

>Третья нода назначала master-ом первую тачку которая вышла в онлайн

Хм... Но это уже действительно третья сторона. Главное, меня просто поражает, что как только люди не извращаются, лишь бы не покупать SAN!

Мне кажется ты на нервах пишешь :). Я понимаю, бывает что что-то не любишь и хочешь стереть это с лица земли. Но SAN это другое. Да и мне кажется что будущее за распределёнными стораджами, нафиг SAN.

Так Gluster и позволяет создавать распределённые сторэджи - как и Tahoe LAFS, как и LustreFS. А вот DRBD попросту сокращает издержки и делит надёжность в лучшем случае пополам

В-общем, так. В продакшне ЭТО использовать нельзя. Совсем. Т.е. ВООБЩЕ никак нельзя. Я пробовал. И теперь советую всем - ДАЖЕ НЕ ПЫТАЙТЕСЬ ИСПОЛЬЗОВАТЬ ЭТО В ПРОДАКШНЕ! Т.к. оно - тупо не работает. ВООБЩЕ не работает. Т.е. совсем. Да, задумка - хорошая. Но именно эта реализация задукми - тупо не работает. Используйте лучше DRBD, NFS, RSYNC на худой конец, но не ЭТО. Разве что - если вы хотите довести свой продакшн до уровня стабильности шиндошса, или даже хуже. При использовании ЭТОГО сервакам не помогает ничего, кроме хард-ресета. Нет, не используйте ЭТО в продакшне. Не используйте. Серьёзно.