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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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