› › ›

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

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

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/8.17/high-availability-cluster-design-large-clusters.html