Кластерное хранилище Pacemaker + DRBD (Dual primary) + ctdb

[gecube]

Задачу какую решали?
Вы же понимаете, что мастер-мастер в теории не работают?
split brain, все дела.
Как минимум, нужно три узла и программные средства, которые умеют в кворум/консенсус

[crazylh]

А чем не подошли нативные кластерные FS?

[datacompboy]

а какие кластерные фс работают на 3-5 хостов?

[crazylh]

Смотря что имеется в виду под «работают». Ceph, gfs2, elliptics — смотря какие задачи стоят

[datacompboy]

DRBD мультимастер через набор разных разделов, каждый который сингл мастер дает R=2 (N+1) на 2-5 нодах лишь с небольшим геморроем и почти нулевым оверхедом.
Кто из вышеозначенных позволяет создать отказоустойчивую (durable) сборку без значительного оверхеда, и так чтоб любая машина была умираема?

[crazylh]

Руками разруливать сплит-брейн с ненулевым шансом дропнуть латест дата — это называется небольшой гемморой???

[datacompboy]

стоп-стоп-стоп. я предлагаю мультимастер как два синглмастера, а не один блокдевайс на оба тазика в мастере.
небольшой геморрой — в создание пар.

[gecube]

Вы не думаете, что в старом DRDB мультимастер с набором разных разделов — это скорее оверинжиниринг и костыли, чем production решение?

Кто из вышеозначенных позволяет создать отказоустойчивую (durable) сборку без значительного оверхеда, и так чтоб любая машина была умираема?

Что значит «значительный оверхед»? Понятно, что чудес нет. И выигрывая в надежности, мы теряем в скорости. Но, извините, возможность сплит-брейна — это вообще отсутствие надежности, т.е. бинарная опция, а не какой-то параметр, который мы можем выразить непрерывной величиной (числом в диапазоне 0...max)

[datacompboy]

я спрашиваю про решение на три-пять тазиков.
На дрбд это:
M1 S1 --
-- M2 S2
S3 -- M3
и у нас N+1, никакого брейнсплита, есть кворум, все три мастера, при сдыхании один бурет роль двух мастеров пока не заменим/починим.

кластерные фс они от 10 хостов реально начинают работать с хорошим эффектом. но до 10 хостов надо еще дорасти…

[gecube]

есть кворум, все три мастера, при сдыхании один бурет роль двух мастеров пока не заменим/починим.

Это, по-моему, только в drdb9 только появилось? Прошу поправить, если неправ.
Касательно указанного конфига — glusterfs (я его ОЧЕНЬ не люблю), но нормально на трех ведрах работает.

[datacompboy]

почему? это и на 8м собирается. как три независимых раздела.

хмм… помню что-то было не то с глустером у меня. с него грузиться ось умеет?

[gecube]

хмм… помню что-то было не то с глустером у меня. с него грузиться ось умеет?

это зачем?

я спрашиваю про решение на три-пять тазиков.
На дрбд это:
M1 S1 — -- M2 S2
S3 — M3

я не понимаю и как это решает проблему сплита?

было
M1 S1 --
-- M2 S2
S3 -- M3
средний узел сепарировался
M1 M1 --
-- M2 M2
S3 -- M3
потом сплит пропал.
конфликт отдельно по блоку 1, отдельно по блоку 2.
Или Вы планируете решение конфликта оставить на стороне приклада?

[datacompboy]

три хоста = кворум. если второй отсплитился, его кластером уводим в слейв, да хоть и коросинком с пейсмейкером. чем угодно.

если все три изолироавлись — все в слейвах до ручного вмешательства.

а грузиться — это для VM с доступом к файлу, а не просто файл-образ держать.

[gecube]

три хоста = кворум. если второй отсплитился, его кластером уводим в слейв, да хоть и коросинком с пейсмейкером. чем угодно.

понял мысль. Т.е. внешними приблудами. Но это все равно опасно. Например, у нас сеть не стартанула, или сервис-арбитр, или еще что-то. И знаете, хуже даже не сплит сам. А когда был сплит, потом пошла синхронизация данных, а потом второй, но уже по второму месту и… приплыли.

Да, я только теоретизирую )

а грузиться — это для VM с доступом к файлу, а не просто файл-образ держать.

т.е. DRDB ВНУТРИ виртуалок?

[datacompboy]

да, есть варианты когда совсем нерешаемо. но это решаемо! :D
уровень такого сплита сопоставим просто со смертью дисков разом — поднимать бакапы и/или допустимые потери.
просто других способов наращивать мощность по одному в малых масштабов я пока не нашел, вот и спрашиваю всегда…

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

[gecube]

Я все-таки не понимаю, прошу прощения, какую задачу Вы решаете с помощью DRDB. Т.е. синхронизация файлов stateless приложений между VM, синхронизация образов VM между различными нодами с гипервизором… или что происходит?

[datacompboy]

дрбд обеспечивает реалтайм репликацию между нодами. на мастере смонтировно в фс, с фс запущены контейнеры.
мастер-слейв, монтирование и запуск контейнеров в кластерменеджере

[AlexGluck]

На 2х хостах, это всё, что есть. На этом надо сделать HA решение.

[gecube]

на 2-х принципиально нельзя, иначе роете себе яму. Как минимум нужно 3. Это теория.

[datacompboy]

на двух потребуется человек-арбитр для переброса, во избежание сплита.
но система вполне работает

[AlexGluck]

В случае сплита, действительно оператор исправит запуск второго мастера, но шанс такого поведения у нас мал. Даже в случае сплита, один мастер будет работать и мы получим деградацию в производительности, которой можно пренебречь. Во всех остальных случаях мы получим high availability решение.

[JuriM]

Вся эта конструкция рассыпется при первом сплитбрейне

[AlexGluck]

Какие же вы невнимательные, clvm не даст писать если кластер развалится, это одна из проблем при старте второго мастера после его отключения.

[OasisInDesert]

Спасибо за материал.
Небольшое замечание по терминологии

развернуть отказоустойчивое High Available хранилище

Если не ошибаюсь для термина «Отказоустойчивый» в английском языке соответствует «Fault Tolerant», а для термина «Высокой Доступности» = «High Available».