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

Кворум главного узла Elasticsearch определяет, может ли ваш кластер безопасно выбрать лидера, публиковать изменения состояния кластера и избежать ситуации, когда две изолированные стороны одного и того же кластера принимают разные решения.

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

Критическая роль главного узла

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

Обязанности главного узла

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

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

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

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

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

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

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

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

При первом запуске совершенно нового кластера 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

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

Что такое Split-Brain?

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

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

Чтобы предотвратить 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 узлов, но использует один дополнительный сервер.

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

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

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

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

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

# Привяжите транспорт к частной сети и ограничьте доступ с помощью брандмауэров/групп безопасности.
# network.host: 10.0.0.1

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

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

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

# Если роли не указаны, Elasticsearch назначает набор ролей по умолчанию для этой версии.

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

Все узлы должны быть настроены на поиск одного и того же набора узлов, имеющих право на роль мастера, с помощью настройки 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 и т.д.).

Устранение неполадок при выборах

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

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

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

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

GET /_cluster/state?filter_path=metadata.cluster_coordination

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

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