Устойчивость в небольших кластерах

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

Кластер из одного узла не устойчив. Если узел выйдет из строя, работа кластера прекратится. Поскольку в кластере из одного узла нет реплик, данные невозможно хранить дублированно. Однако по умолчанию для состояния кластера green требуется как минимум одна реплика. Чтобы ваш кластер мог отображать состояние green, переопределите значение по умолчанию, установив index.number_of_replicas в значение 0 для каждого индекса.

При отказе узла вам может потребоваться восстановить более старую копию потерянных индексов из снапшота.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда ваш кластер станет больше трёх узлов, вы можете начать специализировать узлы в зависимости от их задач, позволяя масштабировать их ресурсы независимо, по мере необходимости. Вы можете иметь столько узлов данных, узлов Ingest, узлов машинного обучения и т.д., сколько нужно для поддержки вашей рабочей нагрузки. По мере роста кластера мы рекомендуем использовать специализированные узлы для каждой роли. Это позволяет независимо масштабировать ресурсы для каждой задачи.

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

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

Кластер будет устойчив к потере любого узла, если: