Конфигурации голосования

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

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

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

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

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 исключает один из них из конфигурации голосования, чтобы она имела нечетное количество узлов. Это исключение не уменьшает толерантность кластера к сбоям. На самом деле, это слегка улучшает её: если кластер страдает от сетевого разрыва, который разделяет его на две равные половины, то одна из половин будет содержать большинство узлов в конфигурации голосования и сможет продолжить работу. Если все голоса от узлов, участвующих в голосовании, учитывались, ни одна сторона не содержала бы строгого большинства узлов, и кластер не смог бы продвинуться дальше.

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

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

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

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

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