Привет друзья!

Это мой последний топик в уходящем году.

Мои вопросы.

1. Кто из вас использует децентрализованные одноранговые вычислительные системы и как вы выбираете мастера?
2. Используете-ли подмножество протколов Paxos(Raft).
3. Бывают-ли у вас непрерывные процессы голосования?
4. Бывают-ли у вас ситуации split-brain?
5. Используете-ли zookeeper? Как обеспечиваете его надёжность?
6. Используете-ли Apache Cassandra?
7. Используете-ли Apache Ignite?

Вопросы телезрителей.

1. Один из мемберов интересовался причиной выпиливания zookeeper из Кафки. Прошу прокомментировать кто вкурсе.



О себе

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

Мои знания в использовании подобных систем остались в 2000х годах. Где были *.ini файлы
и список ip адресов в конфигах.

Что мы НЕ будем обсуждать.

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

Ссылки по теме
- толстая бумажка из Стендфорского Университета которая описывает принципы Raft https://raft.github.io/raft.pdf
- просто визуализация работы Raft https://raft.github.io/
- теоретические основы Paxos https://www.cs.rutgers.edu/~pxk/417/notes/paxos.html

Ссылки на вики вы найдете сами.

Go-go читать и отвечать.

Как у тебя клиенты узнавали куда ходить?

И какого уровня согласованность требовалась.
Просто если это DNS то там вообще пофиг куда ходить.

А вобщем об изменении в кластере должны знать сразу все участники. У тебя мастер с адресом 192.168.1.1 упал.
Его по рангу подхватил следующий. 192.168.1.2. К нему идут клиенты. Далее - ты починил мастер и он снова
поднялся. Как узнают клиенты что они должны переключиться? А как третий slave с адресом 192.168.1.3
узнает откуда ему тянуть свежие данные?

А где лежат данные?

Ну... если у тебя так всё хорошо - тогда тебе и мастер не нужен. И этот топик вобщем тоже не нужен.

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

DNS в силу своей иерархичности решает эти проблемы по другому. И TTL и невысокая скорость ротации
информации позволяют DNS долго находится разным уровням в изоляции друг от друга и не испытывать
особых проблем.

Вобщем в данном топике DNS - плохой пример.

Детализирую 4 вопрос

4. Бывают-ли у вас ситуации split-brain?

Изначально Raft-кластер обладает сведениями о количестве нод и их сетевых ендпоинтах.
В данном примере 5-узловой кластер работает в условиях когда все ноды видят всех.

Допустим ноды S1,S2 стоят в Los-Angelos, Chicago, а S3,S4,S5 - Лондон, Париж, Франкфурт.
При пропадении сети межу США и Европой возможна ситуация когда S1,S2 и S3,S4,S5 образуют
свои собственные мастер узлы и таким образом в кластере наступает шизофрения.

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

Разумеется я придумал гипотетическую ситуацию. Между США и Европой сеть вряд-ли пропадет.
Там существуют резервные каналы и даже наверное с избыточностью. Но мой вопрос в основном
пока теоретический.

По поводу этого вопроса

3. Бывают-ли у вас непрерывные процессы голосования?

В документе от стенфорда описывают фазу неудачных выборов. Хотелось-бы узнать условие
стабильности. Тоесть возможны ли такие мои конфигурации или условия в сети при которых
выборы идут бесконечно?

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

Хорошо. Приведу пример. Вы строите систему наподобие NoSQL (key-value) хранилища.
В типовых конфигурациях нам обычно предлагают схему Master-Slave
или схему 1-Мастер и несколько Slaves для обеспечения масштаба. Наивное предположение
о том что будет больше читающих транзакций. Ну да ладно. Пускай.

Мастер - пишет транзакции и позволяет чтение. Слейвы - просто реплицируют измерения с мастера
и предлагают услугу доступа в режиме R/O для отчотов или каких-то других транзакций которым
этого режима достаточно.

Ситуация аварий. Либо работает арбитр. Это некий третий сервер который "видит всё" и принимает
решение о том что пора переключаться с умершего мастера на любого из слейвов.

Либо просто админ или девопс видя ситуацию по мониторам аварий - принимает решение
о переключении.

Последнюю схему я встречал чаще всего. И обычно она либо не работала по разным причинам.
Либо переключение занимало слишком много времени (тут был человеческий фактор в основном).
Либо резервная конфигурация была слабее (типично для гос-предприятий 2000х) и ее вобщем
никто на нагрузку не тестировал. Просто она существовала как "на всякий пожарный случай".

Модель одноранговая - мне нравится. С автоматическим выбором мастера. Вот почему я и поднял этот топик.

Ситуацию конкурирующих UPDATES можно себе представить когда из 5 например PostgresQL баз с 1 мастером
после сплита мозга - стартовало по 1 мастеру в Америке и Европе. И клиенты успели напихать в оба мастера
бизнес операций которые могут друг друга взаимно отменять.

(Это всё моё видение проблемы. Если я не прав или вы видите не так - то прошу рассказать)

P.S. В этих протоколах выбора мастера я пока еще не разбираюсь поэтому мне простительно делать
ошибки именно в предположениях и контрактах относительно ИХ РАБОТЫ и ИХ РОЛИ в управлении
кластерами.

hck2, спасибо. Добавлю Apache Cudu к списку.

Я трекаю пока набор просто названий чтоб хотя-бы понять что есть что терминологически.
Тоесть где какая аббревиатура что значит. И какой алгоритм или протокол использует софт.

Пока вот что нарисовал.

NameUses or depends onApache IgniteTCP/IP discovery(?), ZooKeeper DiscoveryInfinispan2PC ?Apache CassandraPaxos ?, Gossip protocol, Phi Accural Failure DetectionHazelcastRaft ?Apache StormNimbus ?ZooKeeperZABApache CuduRaft ?ConsulPGPoolLogical Clocktwo-phase commit protocol (2PC)three-phase commit protocol (3PC)ZAB (ZooKeeper Atomic Broadcast protocol)

Еще у Apache Ignite была топология наподобие Token Ring. Забыл как она у них называлась. Наверное надо найти
и вписать.

И есть еще целый пласт Hadoop технологий у которых тоже есть свой алгоритм определения мастера.

Тогда получается что если в кластере 4 узла и происходит split поровну - то с такой квотой Raft не смог-бы создать
кластер вообще.

Спасибо. Добавил в список.

Еще с презентаций по отказоустойчивому Postgres я вспомнил про такой менеджер выборов как Patroni.
Тоже добавлю его к сравнению.

Я думаю да. В моём вопросе есть как-бы отсылка к задачам парадоксам наподобие "задачу двух генералов".
Теоретически такая ситуация возможна. Но на практике скорее всего падения половины узлов не будет.

Тоесть грубо говоря. Я предполагаю что Raft и Paxos и им подобные имеют недоказуемую теоретически
но практически рабочую идею.

MongoDb и ее коробочный вариант отказоустойчивого кластера.
Я чет непонял.

В книге "Mongo in Action пишут" что минимальная рекомендуемая конфигурация
содержит 3 узла. 1 мастер и 1 реплики и 1 арбитр. Этот арбитр внушает недоверие.
Непонятна рекомендация по его место-расположению.

Пускай знающие монго-воды прокомментируют.

Хотя стоп. Возможно я гоню на монго. Книжка старая а я нашел видос где Raft используется в совокупости с Mongo кластером.