Динамические изменения конфигурации кластера и предотвращение разделения мозга (Split-Brain) #6

New Issue

gvsafronov · 2026-08-17T21:23:25Z

gvsafronov commented

2026-08-17 21:23:25 +00:00

Проблема

В текущей реализации присутствует SplitBrainDetector, использующий эвристическое обнаружение на основе таймаутов и терминов Raft.
Однако полноценный механизм динамического изменения конфигурации кластера (добавление/удаление узлов) либо не завершён, либо не интегрирован атомарно с консенсусом Raft.
JointConsensusManager объявлен, но не имеет полной реализации, а RecoveryManager выполняет восстановление узлов без атомарной синхронизации с изменениями конфигурации Raft. При возникновении сетевого разделения две группы узлов могут избрать разных лидеров (split-brain), но детектор только логирует это состояние без автоматического устранения.
Кроме того, функциональность QuarantineNode изолирует узел, но не синхронизирует это состояние с остальным кластером, что потенциально оставляет кластер в несогласованном состоянии конфигурации, где разные узлы имеют разные представления о составе кластера.

Архитектурная проблема

Как обеспечить безопасные и атомарные изменения конфигурации кластера (добавление/удаление узлов) в распределённой системе с шардированием, сохраняя консенсус и предотвращая сценарии разделения мозга?

Пример сценария

Рассмотрим кластер из 5 узлов: {A, B, C, D, E}. Во время сетевого разделения кластер распадается на две группы: {A, B, C} и {D, E}. Группа 1 избирает A лидером (терм 5), а группа 2 избирает D лидером (терм 5). SplitBrainDetector.Detect() возвращает true, указывая на ситуацию разделения мозга. Стратегия устранения — изолировать узел D. Однако нет гарантии, что узел D перестанет принимать запись, поскольку решение об изоляции не распространяется через механизм консенсуса Raft. Это нарушает фундаментальное свойство безопасности — наличие ровно одного лидера на терм.

Предлагаемые направления исследований

Протокол совместного консенсуса (Joint Consensus) — полная реализация совместного консенсуса Raft для атомарных изменений конфигурации, при которой кластер переходит через промежуточное «совместное» состояние, включающее как старую, так и новую конфигурации.
Атомарные изменения состава кластера — применение изменений конфигурации атомарно через журнал Raft, гарантируя, что все узлы применяют изменение на одном и том же индексе журнала.
Предотвращение разделения мозга на основе кворума — использование различных размеров кворума для разных операций (чтение, запись, изменение конфигурации) для обеспечения безопасности при сетевых разделениях.
Токены ограждения (Fencing Tokens) — реализация механизма токенов ограждения, где каждые выборы лидера генерируют монотонно возрастающий токен, который должен предъявляться при каждой операции записи.
Формальная верификация — верификация протокола изменений конфигурации с использованием инструментов проверки моделей (TLA+, Promela) для доказательства свойств безопасности.
Механизм аренды лидера (Leader Lease) — реализация аренды лидера для предотвращения разделения мозга, когда лидеры из разных разделов не могут сосуществовать.

**Проблема** В текущей реализации присутствует SplitBrainDetector, использующий эвристическое обнаружение на основе таймаутов и терминов Raft. Однако полноценный механизм динамического изменения конфигурации кластера (добавление/удаление узлов) либо не завершён, либо не интегрирован атомарно с консенсусом Raft. JointConsensusManager объявлен, но не имеет полной реализации, а RecoveryManager выполняет восстановление узлов без атомарной синхронизации с изменениями конфигурации Raft. При возникновении сетевого разделения две группы узлов могут избрать разных лидеров (split-brain), но детектор только логирует это состояние без автоматического устранения. Кроме того, функциональность QuarantineNode изолирует узел, но не синхронизирует это состояние с остальным кластером, что потенциально оставляет кластер в несогласованном состоянии конфигурации, где разные узлы имеют разные представления о составе кластера. **Архитектурная проблема** Как обеспечить безопасные и атомарные изменения конфигурации кластера (добавление/удаление узлов) в распределённой системе с шардированием, сохраняя консенсус и предотвращая сценарии разделения мозга? **Пример сценария** Рассмотрим кластер из 5 узлов: {A, B, C, D, E}. Во время сетевого разделения кластер распадается на две группы: {A, B, C} и {D, E}. Группа 1 избирает A лидером (терм 5), а группа 2 избирает D лидером (терм 5). SplitBrainDetector.Detect() возвращает true, указывая на ситуацию разделения мозга. Стратегия устранения — изолировать узел D. Однако нет гарантии, что узел D перестанет принимать запись, поскольку решение об изоляции не распространяется через механизм консенсуса Raft. Это нарушает фундаментальное свойство безопасности — наличие ровно одного лидера на терм. **Предлагаемые направления исследований** 1. **Протокол совместного консенсуса (Joint Consensus)** — полная реализация совместного консенсуса Raft для атомарных изменений конфигурации, при которой кластер переходит через промежуточное «совместное» состояние, включающее как старую, так и новую конфигурации. 2. **Атомарные изменения состава кластера** — применение изменений конфигурации атомарно через журнал Raft, гарантируя, что все узлы применяют изменение на одном и том же индексе журнала. 3. **Предотвращение разделения мозга на основе кворума** — использование различных размеров кворума для разных операций (чтение, запись, изменение конфигурации) для обеспечения безопасности при сетевых разделениях. 4. **Токены ограждения (Fencing Tokens)** — реализация механизма токенов ограждения, где каждые выборы лидера генерируют монотонно возрастающий токен, который должен предъявляться при каждой операции записи. 5. **Формальная верификация** — верификация протокола изменений конфигурации с использованием инструментов проверки моделей (TLA+, Promela) для доказательства свойств безопасности. 6. **Механизм аренды лидера (Leader Lease)** — реализация аренды лидера для предотвращения разделения мозга, когда лидеры из разных разделов не могут сосуществовать.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gvsafronov/futriix#6