Paxos and Discovery

Question

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

Таким образом, они будут работать алгоритм на основе консенсуса, и кворум 5.

Теперь рассмотрим эти случаи:

1. Я вижу, что CPU слишком низко, и уменьшить размер кластера пополам, до 4 машин.
2. Существует разделение разделов, и каждый раскол получает 4 машины.

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

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

Является ли Paxos (и любые другие безопасные консенсусные алгоритмы) непригодными для использования в эластичной среде?

Answer 1

Консенсусные протоколы на основе кворума в основном требуют кворумов для работы. Оба Multi-Paxos и Raft могут использоваться в средах с динамически изменяющимися размерами кластера и кворума, но это должно осуществляться контролируемым образом, который всегда поддерживает постоянный кворум. Если, например, в настоящее время вы используете размер кластера 8 и хотите уменьшить этот кластер до 4, вы можете сделать это. Тем не менее, это решение уменьшить размер кластера до 4 должно быть согласованным решением, согласованным оригиналом 8.

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

Вы могли бы, конечно, сделать все эти решения вручную и заставить систему восстановить, закрыв консенсусную службу на каждой системе и переконфигурировав ее определение кворума вручную. Предполагая, что вы не испортите (что является чрезвычайно большим предположением для любого развертывания в реальном мире), это было бы безопасно. Лучше всего было бы разработать систему, чтобы один или два сетевых раздела либо не остановили систему (множество сайтов), либо использовали модель последовательной согласованности, которая изящно обрабатывает случайные сетевые разделы. Для ограничения ограничений CAP нет волшебной пули.

Answer 2

Паксос и друзья могут масштабироваться эластичным способом (несколько). Вместо того, чтобы менять размер кворума, просто добавьте learners. Учащиеся - это узлы, которые не участвуют в консенсусе, но принимают все решения. Точно так же, как акцепторы, учащиеся принимают чтение и пересылку писем лидеру.

Есть два стили учащегося.Первый прослушивает все события от акцепторов; во втором лидер направляет все совершенные переходы ученикам