Понимание выбора мастера Elasticsearch и требований к кворуму

Elasticsearch — это распределенная система, которая полагается на координацию между узлами для поддержания согласованного представления состояния кластера. В основе этой координации лежит Узел-мастер. Узел-мастер является единственным источником истины для метаданных кластера, и обеспечение его стабильности и корректного выбора имеет первостепенное значение для работоспособности, масштабируемости и отказоустойчивости кластера.

В этой статье подробно рассматриваются критически важные обязанности узла-мастера, объясняется современный процесс выбора, используемый в последних версиях Elasticsearch (7.x+), и разъясняется основная концепция кворума — механизма, необходимого для предотвращения катастрофического сценария, известного как проблема разделения мозга (split-brain).

Критическая роль узла-мастера

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

Обязанности узла-мастера

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

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

Понимание выбора мастера и голосования

В распределенной системе процесс выбора требуется всякий раз, когда текущий узел-мастер выходит из строя или становится недоступным. Начиная с Elasticsearch 7.0, механизм выбора был значительно упрощен и усовершенствован, в основном за счет устранения сложной настройки discovery.zen.minimum_master_nodes и введения самоуправляемых конфигураций голосования.

Процесс выбора (Elasticsearch 7.x+)

Выбор мастера теперь автоматически обрабатывается узлами, имеющими право быть мастером, которые определяются в конфигурации с помощью node.roles: [master, data] или просто node.roles: [master] для выделенных мастеров.

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

Начальная загрузка кластера

При первом запуске нового кластера Elasticsearch должен знать, какие узлы должны участвовать в первоначальной конфигурации голосования. Это делается с помощью настройки cluster.initial_master_nodes. Эта настройка должна использоваться только один раз при первоначальном запуске кластера.

# Фрагмент elasticsearch.yml для начальной настройки
cluster.name: my-production-cluster
node.name: node-1
node.roles: [master, data]

# Список имен всех узлов, имеющих право быть мастером, используемых для начальной загрузки
cluster.initial_master_nodes: [node-1, node-2, node-3]

Совет: После того как кластер запущен и стабилен, вам следует удалить или закомментировать настройку cluster.initial_master_nodes из файлов конфигурации всех узлов, чтобы избежать потенциальных проблем при последующих перезапусках узлов в смешанном состоянии.

Требования к кворуму и предотвращение разделения мозга

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

Что такое разделение мозга?

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

Правило кворума (Консенсус большинства)

Для предотвращения разделения мозга Elasticsearch применяет правило консенсуса большинства, требуя минимального количества узлов голосования для согласия по любому изменению состояния кластера. Этот минимум и есть кворум, рассчитываемый по формуле:

$$\text{Кворум} = \lfloor (\text{Количество узлов голосования} / 2) \rfloor + 1$$

Требуя строгого большинства, если сеть разделяется, только большая сторона (которая имеет большинство) может достичь кворума и продолжить работу. Меньшая сторона, неспособная выбрать мастера, остановится и будет ждать восстановления сетевого соединения, тем самым избегая записи данных в разделенный сегмент.

Количество узлов-мастеров голосования (N)	Требуемый кворум (N/2 + 1)
3	2
5	3
7	4

Предупреждение о лучшей практике: Всегда развертывайте нечетное количество узлов, имеющих право быть мастером (например, три или пять). Развертывание четного количества (например, четырех) обеспечивает такую же отказоустойчивость, как и предыдущее нечетное количество (три), но требует больше ресурсов. Например, кластер голосования из 4 узлов требует 3 голоса (N/2+1), что означает, что он может выдержать только один сбой, как и кластер из 3 узлов, но использует один дополнительный сервер.

Настройка выделенных узлов-мастеров

Для производственных сред, особенно для больших кластеров (20+ узлов данных), настоятельно рекомендуется использовать выделенные узлы-мастера. Это отделяет ресурсоемкие задачи поиска/индексирования от критически важных административных функций мастера.

Пример конфигурации узла (выделенный мастер)

Чтобы настроить узел как имеющий право быть мастером, но не хранящий данные или не выполняющий конвейеры приема, используйте следующие роли в elasticsearch.yml:

# Узел 1: Выделенный мастер
node.name: es-master-01
node.roles: [master]

# Отключить HTTP/Transport трафик для чистых мастеров (необязательно, но хорошая практика безопасности)
# http.enabled: false 
# transport.bind_host: [private_ip_of_master]

Пример конфигурации узла (выделенный узел данных)

И наоборот, выделенному узлу данных следует запретить участие в процессе выбора мастера:

# Узел 4: Выделенный узел данных
node.name: es-data-04
node.roles: [data]

# Примечание: Если роли не указаны, Elasticsearch по умолчанию использует [master, data, ingest] (по умолчанию до версии 8.0)

Настройки обнаружения кластера

Все узлы должны быть настроены для поиска одного и того же набора узлов, имеющих право быть мастером, с использованием настройки discovery.seed_hosts. Эта настройка перечисляет сетевые адреса, по которым Elasticsearch может попытаться связаться с другими узлами для присоединения к кластеру.

# Общая настройка для всех узлов в кластере
discovery.seed_hosts: ["10.0.0.1:9300", "10.0.0.2:9300", "10.0.0.3:9300"]

Этот список должен содержать адреса узлов, имеющих право быть мастером (es-master-01, es-master-02, es-master-03 и т. д.).

Устранение проблем с выбором

Если кластер не может выбрать мастера, он обычно переходит в состояние 'красный' или 'желтый' и регистрирует постоянные ошибки. Распространенные причины включают:

Проблема	Описание и решение
Сетевые проблемы	Узлы не могут связаться друг с другом из-за правил брандмауэра, проблем маршрутизации или высокой задержки. Убедитесь, что порты 9200 (HTTP) и 9300 (Transport) открыты между узлами.
Несоответствие конфигурации	`cluster.name` неверен или `discovery.seed_hosts` не указывает на правильные узлы, имеющие право быть мастером. Проверьте, используют ли все узлы идентичные настройки.
Потеря кворума	Слишком много узлов, имеющих право быть мастером, вышли из строя одновременно (например, два сбоя в конфигурации мастера из 3 узлов). Может потребоваться ручное вмешательство (например, с использованием API `api/cluster/decommission/voting_config_exclusions`) для принудительного исключения вышедших из строя узлов из списка голосования.
Дисковый ввод-вывод	Дисковый ввод-вывод узла-мастера перегружен, что мешает ему быстро публиковать состояние кластера, вызывая тайм-ауты и повторные выборы.

Проверка конфигурации голосования

Вы можете проверить текущую конфигурацию голосования с помощью Cluster API:

GET /_cluster/state?filter_path=metadata.cluster_coordination.voting_config_excluding_deferred

Этот вывод подтверждает, какие узлы в настоящее время учитываются при подсчете кворума, гарантируя, что ваша конфигурация соответствует вашим целям отказоустойчивости.

Резюме

Процесс выбора узла-мастера является основой отказоустойчивости кластера Elasticsearch. Понимая обязанности мастера и корректно применяя правило кворума (используя нечетное количество узлов, имеющих право быть мастером, и обеспечивая правильность cluster.initial_master_nodes во время начальной загрузки), администраторы могут надежно предотвращать сценарии разделения мозга и поддерживать высокодоступную распределенную систему. Всегда используйте выделенные узлы-мастера в производстве для изоляции административных задач и обеспечения надежной публикации состояния кластера.