Pull to refresh

Comments 24

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

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

а какие кластерные фс работают на 3-5 хостов?
Смотря что имеется в виду под «работают». Ceph, gfs2, elliptics — смотря какие задачи стоят
DRBD мультимастер через набор разных разделов, каждый который сингл мастер дает R=2 (N+1) на 2-5 нодах лишь с небольшим геморроем и почти нулевым оверхедом.
Кто из вышеозначенных позволяет создать отказоустойчивую (durable) сборку без значительного оверхеда, и так чтоб любая машина была умираема?
Руками разруливать сплит-брейн с ненулевым шансом дропнуть латест дата — это называется небольшой гемморой???
стоп-стоп-стоп. я предлагаю мультимастер как два синглмастера, а не один блокдевайс на оба тазика в мастере.
небольшой геморрой — в создание пар.
Вы не думаете, что в старом DRDB мультимастер с набором разных разделов — это скорее оверинжиниринг и костыли, чем production решение?
Кто из вышеозначенных позволяет создать отказоустойчивую (durable) сборку без значительного оверхеда, и так чтоб любая машина была умираема?

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

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

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

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

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

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

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

было
M1 S1 --
-- M2 S2
S3 -- M3

средний узел сепарировался
M1 M1 --
-- M2 M2
S3 -- M3

потом сплит пропал.
конфликт отдельно по блоку 1, отдельно по блоку 2.
Или Вы планируете решение конфликта оставить на стороне приклада?
три хоста = кворум. если второй отсплитился, его кластером уводим в слейв, да хоть и коросинком с пейсмейкером. чем угодно.

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

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

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

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

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

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

нет, drbd не внутри. но вопрос как поднимать на файлах, а не на файле-образе. помнится записи в файл-образ реплицируются на кластерных фс не моментльно (файл же не закрыт, а синк не всегда требует успешной репликации иначе все дико тормозит).
Я все-таки не понимаю, прошу прощения, какую задачу Вы решаете с помощью DRDB. Т.е. синхронизация файлов stateless приложений между VM, синхронизация образов VM между различными нодами с гипервизором… или что происходит?
дрбд обеспечивает реалтайм репликацию между нодами. на мастере смонтировно в фс, с фс запущены контейнеры.
мастер-слейв, монтирование и запуск контейнеров в кластерменеджере
На 2х хостах, это всё, что есть. На этом надо сделать HA решение.
на 2-х принципиально нельзя, иначе роете себе яму. Как минимум нужно 3. Это теория.
на двух потребуется человек-арбитр для переброса, во избежание сплита.
но система вполне работает
В случае сплита, действительно оператор исправит запуск второго мастера, но шанс такого поведения у нас мал. Даже в случае сплита, один мастер будет работать и мы получим деградацию в производительности, которой можно пренебречь. Во всех остальных случаях мы получим high availability решение.
Вся эта конструкция рассыпется при первом сплитбрейне
Какие же вы невнимательные, clvm не даст писать если кластер развалится, это одна из проблем при старте второго мастера после его отключения.
Спасибо за материал.
Небольшое замечание по терминологии
развернуть отказоустойчивое High Available хранилище

Если не ошибаюсь для термина «Отказоустойчивый» в английском языке соответствует «Fault Tolerant», а для термина «Высокой Доступности» = «High Available».
Only those users with full accounts are able to leave comments. Log in, please.