› › ›

Отказоустойчивость в кластерах большего размера

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

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

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

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

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

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

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

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

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

Кластеры с двумя зонами

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

Кластеры с двумя зонами и решающим голосом

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

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

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

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

Кластеры с тремя или более зонами

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

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

Заключение

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

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

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/high-availability-cluster-design-large-clusters.html