Какие существуют алгоритмы для отказоустойчивости в распределенной системе?

Я планирую создать распределенную систему баз данных, используя общедоступную архитектуру и multiversion concurrency control. Резервирование будет достигнуто с помощью асинхронной репликации (это позволило потерять некоторые недавние изменения в случае сбоя, если данные в системе остаются согласованными). Для каждой записи базы данных один node имеет главную копию (только для node есть доступ на запись к ней), в дополнение к которой один или несколько узлов имеют вторичные копии записи для целей масштабируемости и избыточности (вторичные копии только для чтения). Когда основная копия записи обновляется, она присваивается по времени и отправляется асинхронно узлам со вторичными копиями, чтобы, наконец, получить последнюю версию записи. node, у которого есть главная копия, может измениться в любое время - если другой node должен записать эту запись, он запросит у текущего владельца основной копии указание, что node является собственностью этой основной копии записи, и после получения права собственности, что node может записать запись (все транзакции и записи являются локальными).

В последнее время я думал о том, что делать, когда node в кластере идет вниз, и какую стратегию использовать для перехода на другой ресурс. Вот несколько вопросов. Я надеюсь, что вы знаете доступные альтернативы, по крайней мере, некоторым из них.

Какие существуют алгоритмы для выполнения отказоустойчивости в распределенной системе?
Какие существуют алгоритмы для консенсуса в распределенной системе?
Как узлы в кластере определить, что a node не работает?
Как узлы будут определять, какие записи базы данных имели свою главную копию при неудавшемся node во время сбоя, чтобы другие узлы могли восстановить эти записи?
Как решить, что node (s) имеет последнюю вторичную копию какой-либо записи?
Как решить, какая дополнительная node вторая копия должна стать новой главной копией?
Как справиться с этим, если node, который должен был быть опущен, внезапно возвращается, как будто ничего не произошло?
Как избежать сплит-мозговых сценариев, когда сеть временно разделяется на две части, и обе стороны считают, что другая сторона умерла?

Ответ 1

* What algorithms there are for doing failover in a distributed system?

Возможно, не алгоритмы, а также системы. Вы должны спроектировать свою архитектуру вокруг вопросов, которые вы задали.

* What algorithms there are for consensus in a distributed system?

Вероятно, вы хотите реализовать Paxos. Простой Paxos не слишком сложно, чтобы получить право. Если вы пытаетесь сделать это пуленепробиваемым, прочитайте статью Google "Paxos Made Live". Если вы надеетесь сделать его высокопроизводительным, посмотрите на Multi-Paxos.

* How should the nodes in the cluster determine that a node is down?

Зависит. Heartbeats на самом деле довольно хороший способ сделать это. Проблема в том, что у вас есть ложные срабатывания, но это неизбежно, и в кластере в той же локальной сети с управляемой нагрузкой они точны. Хорошая вещь о Paxos заключается в том, что ложные срабатывания обрабатываются автоматически. Однако, если вам действительно нужна информация о сбоях для какой-либо другой цели, вам необходимо убедиться, что вы обнаруживаете node как не пройденный, но на самом деле он просто находится под нагрузкой и требует времени, чтобы реагировать на биение.

* How should the nodes determine that what database entries had their master copy on the failed node at the time of failure, so that other nodes may recover those entries?
* How to decide that which node(s) has the latest secondary copy of some entry?
* How to decide that which node secondary copy should be promoted to be the new master copy?

Я думаю, что вам, возможно, очень полезно прочитать документ Google FileSystem. В GFS есть выделенный мастер node, который отслеживает, какие узлы имеют блоки. Эта схема может работать для вас, но ключ заключается в том, чтобы доступ к этому мастеру был минимальным.

Если вы не храните эту информацию в специальном node, вам придется хранить ее повсюду. Попробуйте пометить данные с помощью идентификатора ведущего владельца.

* How to handle it, if the node which was though to be down, suddenly comes back as if nothing happened?

См. выше, но основной момент состоит в том, что вы должны быть осторожны, потому что node, который больше не является хозяином, может подумать, что это так. Одна вещь, которую я не думаю, что вы решили: как получить обновление у мастера - то есть как клиент знает, к какому node отправить обновление?

* How to avoid split-brain scenarios, where the network is temporarily split into two, and both sides think that the other side has died?

Paxos работает здесь, предотвращая прогресс в случае идеального раскола. В противном случае, как и прежде, вы должны быть очень осторожны.

В общем, решим вопрос о том, какой node получает элемент данных в качестве мастера, и вам будет долгий путь к исправлению вашей архитектуры. Обратите внимание, что вы не можете просто получить node получение обновления мастером - что делать, если два обновления происходят одновременно? Не полагайтесь на синхронизированные глобальные часы - так безумие. Вероятно, вы хотите избежать консенсуса в отношении каждой записи, если можете помочь, поэтому вместо этого у вас будет медленный протокол перехода на второй уровень и быстрый путь записи.

Не стесняйтесь стрелять в меня по почте, если вы хотите узнать больше деталей. Мой блог http://the-paper-trail.org имеет дело с этим.

веселит,

Генри

Ответ 2

Вы задаете совершенно серьезный вопрос, и многое из того, что вы хотите знать, все еще находится в активном исследовании.

Некоторые мысли:

Распределенные системы сложны, потому что нет надежных систем для устранения сбоев; в асинхронной системе нет никакого способа убедиться, что параметр node не работает или есть сетевая задержка. Это может показаться тривиальным, но на самом деле это не так.
Достижение консенсуса может быть выполнено семейством алгоритмов Paxos, версии которых используются в Google bigtable и в других местах.

Вам нужно вникать в учебник распределенных систем (или несколько). Мне нравится Распределенные системы Танненбаума: принципы и парадигмы

Ответ 3

Отличный блог, в котором много говорится о распределенных системах и распределенных алгоритмах, включая реализацию Paxos, - http://the-paper-trail.org/

Ответ 4

Эта проблема была решена DEC для VMS с Distributed Lock Manager. Современные решения основаны на этом дизайне. Прочтите статью в Википедии для некоторых современных решений. Вы должны посмотреть OCFS2, который теперь является частью ядра Linux.

Ответ 5

Решая небольшую часть вашего вопроса: в сценарии, который вы описываете, нет (в реферате), в котором node (s) есть последняя вторичная копия. В лучшем случае некоторые node могут опросить и определить (после небольшого количества сообщений), кто среди узлов, которые они знают/могут видеть, и что они знают/могут их видеть, и которые не могут видеть, что старый мастер имеет самая последняя копия. Но:

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

По более широким вопросам вы можете посмотреть, как что-то вроде memcached и т.п. справляется с проблемами, и особенно просматривает списки, чтобы увидеть, с какими проблемами они столкнулись, когда теория выполнила практику.

Ответ 6

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