Принятие решений на основе кворума
Выбор главного узла (мастер-ноды) и изменение состояния кластера — две фундаментальные задачи, для выполнения которых узлы Elasticsearch должны взаимодействовать друг с другом. Важно, чтобы этот механизм работал надежно, даже если некоторые узлы вышли из строя. Elasticsearch обеспечивает такую надежность, подтверждая каждое изменение в кластере получением ответов от кворума, который является подмножеством узлов кластера, отвечающих требованиям стать главной нодой (master-eligible node). Кворумы тщательно отслеживаются, чтобы в кластере не было сценария «разделения мозга» (сетевое разделение), когда он разделен на две части, так что каждая часть может принимать решения, несовместимые с решениями другой части.
Elasticsearch позволяет добавлять и удалять мастер-ноды в работающем кластере. Обычно это можно сделать, просто запустив или остановив ноды по мере необходимости. При добавлении или удалении нод, Elasticsearch поддерживает отказоустойчивость, обновляя конфигурацию голосования кластера, которая представляет собой набор нод, чьи ответы учитываются при принятии решений, например, выбор новой мастер-ноды или фиксация нового состояния кластера. Решение принимается только после того, как ответят более половины узлов в конфигурации голосования. Обычно конфигурация голосования совпадает с набором всех мастер-нод, которые в настоящее время находятся в кластере.
Чтобы быть уверенным, что кластер остается доступным, нельзя останавливать половину или более узлов в конфигурации голосования одновременно. Пока доступно более половины нод для голосования, кластер может работать нормально. Это называется кворум.
После того, как новая нода присоединилась к кластеру или покинула его, выбранная мастер-нода должна разослать обновление состояния кластера, которое корректирует конфигурацию голосования для соответствия. Это может занять некоторое время. Перед удалением дополнительных нод из кластера важно дождаться завершения процесса корректировки.
Обслуживание кластера Elasticsearch, циклический перезапуск и миграция
Многие задачи обслуживания кластера включают временное отключение одного или нескольких нод с их последующим повторным запуском. По умолчанию Elasticsearch может оставаться доступным, если одна из нод, отвечающих критериям главного сервера, отключена, например, во время перезапуска. Кроме того, если несколько нод остановлены, а затем запущены снова, они автоматически вольются в кластер, например, во время полного перезапуска кластера. В этих случаях нет необходимости предпринимать какие-либо дальнейшие действия, поскольку набор главных узлов не изменится.Чтобы кластер оставался доступным, нельзя одновременно останавливать половину или более узлов в конфигурации голосования. Пока доступно более половины узлов для голосования, кластер может работать нормально. Например, если есть три или четыре мастер-ноды, кластер не развалится из-за одного недоступного узла. Если имеется две или меньше мастер-ноды, все они должны оставаться доступными.
Текущая конфигурация голосования хранится в состоянии кластера. Можно проверить его текущее содержимое следующим образом:
curl -X GET «localhost:9200/_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config&pretty»
Конфигурации для голосования большего размера обычно более устойчивы, поэтому Elasticsearch предпочитает добавлять узлы с правом стать мастер-нодой в конфигурацию голосования после того, как они присоединятся к кластеру. Точно так же, если узел в конфигурации голосования покидает кластер и в кластере есть другой узел, имеющий право на голос, который не находится в конфигурации голосования, то предпочтительно поменять местами эти два узла. Таким образом, размер конфигурации голосования не изменится, но ее устойчивость возрастет.
Не так просто автоматически удалить узлы из конфигурации голосования после того, как они покинули кластер. Разные стратегии имеют разные преимущества и недостатки, поэтому правильный выбор зависит от того, как будет использоваться кластер. Можно управлять автоматическим сжатием конфигурации голосования с помощью параметра cluster. auto_shrink_voting_configuration.
Если для cluster. auto_shrink_voting_configuration установлено значение true (что является рекомендуемым значением по умолчанию) и в кластере есть не менее трех узлов с ролью мастер, Elasticsearch остается способным обрабатывать обновления состояния кластера до тех пор, пока все, кроме одного, из его мастер-нод здоровы.
Существуют ситуации, в которых Elasticsearch может допустить потерю нескольких узлов, но это не гарантируется при последовательных сбоях. Если параметр cluster. auto_shrink_voting_configuration имеет значение false, нужно удалять вручную из конфигурации голосования исключенные узлы. Используйте API исключений голосования для достижения желаемого уровня устойчивости. Параметр cluster. auto_shrink_voting_configuration влияет только на его доступность в случае отказа некоторых из его узлов, а также на административные задачи, которые необходимо выполнить, когда узлы присоединяются к кластеру и покидают его.
Четное количество нод, имеющих право стать мастер-нодой
Обычно в кластере должно быть нечетное количество узлов с ролью мастер. Если число четное, Elasticsearch оставляет один из них вне конфигурации голосования, чтобы гарантировать, что общее количество нод с ролью мастер нечетно. Это не снижает отказоустойчивость кластера. Фактически, даже немного улучшает его: если кластер страдает от сетевого разделения (например, при пропадания связности двух ЦОДов), который делит его на две половины одинакового размера, тогда одна из половин будет содержать большую часть конфигурации голосования и сможет продолжать работу. Если бы были подсчитаны все голоса от узлов, имеющих право голоса, ни одна из сторон не содержала бы строгое большинство узлов, и поэтому кластер не смог бы штатно работать.Например, если в кластере четыре основных узла, имеющих право на голосование, и конфигурация голосования учитывает их, для принятия любого решения на основе кворума потребуются голоса как минимум трех из них. Эта ситуация означает, что кластер может выдержать потерю только одного основного узла. Если бы этот кластер был разделен на две равные половины, ни одна из половин не содержала бы трех основных узлов, и кластер не смог бы выбрать мастер-ноду. Если конфигурация голосования содержит только три из четырех основных узлов, имеющих право голоса, кластер по-прежнему полностью толерантен только к потере одного узла, но решения на основе кворума требуют голосов от двух из трех узлов с правом голоса. В случае равного разделения одна половина будет содержать два из трех узлов голосования, так что половина останется доступной.
Настройка начальной конфигурации голосования
Когда новый кластер запускается впервые, он должен выбрать свою первую мастер-ноду. Для этого выбора ему необходимо знать набор узлов, имеющих право голоса. Эта первоначальная конфигурация голосования известна как конфигурация начальной загрузки и устанавливается в процессе начальной загрузки кластера.Важно, чтобы конфигурация начальной загрузки точно определяла, какие узлы должны голосовать на первых выборах. Недостаточно настроить каждый узел с расчетом на то, сколько узлов должно быть в кластере. Конфигурация начальной загрузки должна поступать извне кластера: у кластера нет безопасного способа правильно определить конфигурацию начальной загрузки самостоятельно.
Если конфигурация начальной загрузки установлена неправильно, при запуске нового кластера существует риск того, что вы случайно сформируете два отдельных кластера вместо одного. Эта ситуация может привести к потере данных: вы можете начать использовать оба кластера до того, как заметите, что что-то пошло не так, и их невозможно позже объединить.
Чтобы проиллюстрировать проблему с настройкой каждого узла на ожидание определенного размера кластера, представьте, что запускаете трехузловой кластер, в котором каждый узел знает, что он будет частью трехузлового кластера. Большинство из трех узлов равно двум, поэтому обычно первые два узла, которые обнаруживают друг друга, образуют кластер, а третий узел присоединяется к ним через некоторое время. Теперь представьте, что вместо трех были ошибочно запущены четыре узла. В этом случае узлов достаточно, чтобы образовать два отдельных кластера. Конечно, если каждый узел запускается вручную, маловероятно, что будет запущено слишком много узлов. Однако, если вы используете автоматизированный оркестратор, можно попасть в такую ситуацию, особенно если оркестратор не устойчив к сбоям, таким как сетевое разделение.
Первоначальный кворум требуется только при первом запуске всего кластера. Новые узлы, присоединяющиеся к установленному кластеру, могут безопасно получать всю необходимую информацию от выбранного мастера. Узлы, которые ранее были частью кластера, будут хранить на диске всю информацию, которая требуется при их перезапуске.
Читайте другие наши статьи на Хабре:
Как лицензируется и чем отличаются лицензии Elastic Stack (Elasticsearch)
Elastic под замком: включаем опции безопасности кластера Elasticsearch для доступа изнутри и снаружи
Сайзинг Elasticsearch
Определение объёма кластера Elasticsearch и тестирование производительности в Rally
Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)
Приходите на наши курсы по Elaastic Stack: можно на два дня, а можно и на все три.
