Как узлы рафта узнают о коллегах?

Я только что закончил работу с плотом и начинаю работу над реализацией. Однако я понял, что немного запутался в одной важной детали. Как узлы рафта «знают» о своих коллегах? Я не встречал упоминания об этом в документе, поэтому предполагаю, что это зависит от конкретной реализации, но, на мой взгляд, это приводит к ряду вопросов:

  • Статичен ли размер кластера плотов? Поскольку каждый узел должен знать обо всех других узлах (для отправки RPC), как новый узел присоединится к существующему кластеру? Как существующие узлы узнают об этом новом узле?
  • Должно ли при инициализации расположение каждого узла в сети быть жестко запрограммировано в каждом другом узле? Как узел узнает, куда отправлять свои RPC?

Был бы очень признателен за помощь в этом. Мне действительно интересно полностью понять raft, и я рад возможности реализовать его, но я немного заблудился в этой части системной архитектуры. Мне не кажется правильным, что узлы должны быть статически настроены с жестко заданными сетевыми местоположениями, поскольку в реальном мире я определенно мог предвидеть необходимость добавления нового узла в существующий кластер. Спасибо!


distributed-system raft consensus
person mlz7    schedule 27.01.2021    source источник

Ответы (1)


arrow_upward
4
arrow_downward

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

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

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

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

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

person kuujo    schedule 27.01.2021