Настройки голосования

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

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

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

Текущая конфигурация голосования хранится в состоянии кластера, поэтому вы можете проверить ее содержимое следующим образом:

resp = client.cluster.state(
    filter_path="metadata.cluster_coordination.last_committed_config",
)
print(resp)

response = client.cluster.state(
  filter_path: 'metadata.cluster_coordination.last_committed_config'
)
puts response

const response = await client.cluster.state({
  filter_path: "metadata.cluster_coordination.last_committed_config",
});
console.log(response);

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

Более крупные конфигурации голосования обычно более устойчивы, поэтому Elasticsearch обычно предпочитает добавлять узлы, имеющие право на роль мастер, в конфигурацию голосования после их присоединения к кластеру. Аналогично, если узел в конфигурации голосования покидает кластер, а в кластере есть другой узел, имеющий право на роль мастер, но не включенный в конфигурацию голосования, предпочтительнее заменить эти два узла. Размер конфигурации голосования при этом не меняется, но ее устойчивость увеличивается.

Автоматически удалять узлы из конфигурации голосования после их выхода из кластера не так просто. Разные стратегии имеют свои преимущества и недостатки, поэтому правильный выбор зависит от того, как будет использоваться кластер. Вы можете управлять автоматическим уменьшением конфигурации голосования, используя cluster.auto_shrink_voting_configuration параметр.

Существуют ситуации, в которых Elasticsearch может переносить потерю нескольких узлов, но это не гарантируется во всех последовательностях сбоев. Если cluster.auto_shrink_voting_configuration параметр установлен в значение false, необходимо вручную удалить вышедшие из строя узлы из конфигурации голосования. Используйте API исключений из конфигурации голосования для достижения желаемого уровня устойчивости.

Независимо от настроек Elasticsearch не столкнётся с несоответствием «разделенного мозга». Параметр cluster.auto_shrink_voting_configuration влияет только на его доступность при выходе из строя некоторых узлов и административные задачи, которые необходимо выполнять при присоединении и выходе узлов из кластера.

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

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

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

Важно, чтобы конфигурация запуска точно определяла, какие узлы должны голосовать на первом этапе выбора. Недостаточно настроить каждый узел с ожиданием того, сколько узлов должно быть в кластере. Также важно отметить, что конфигурация запуска должна поступать извне кластера: нет безопасного способа для кластера самостоятельно определить конфигурацию запуска.

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

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