Репликация между кластерами

С кросс-кластерной репликацией вы можете реплицировать индексы между кластерами, чтобы:

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

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

Вы настраиваете кластеры кросс-кластерной репликации в одностороннем или двустороннем режиме:

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

Матрица совместимости версий

	Локальный кластер
Удаленный кластер	5.0–5.5	5.6	6.0–6.6	6.7	6.8	7.0	7.1–7.17
5.0–5.5
5.6
6.0–6.6
6.7
6.8
7.0
7.1–7.17

Используйте кросс-кластерную репликацию для создания нескольких многокластерных архитектур в Elastic Stack:

Посмотрите вебинар о кросс-кластерной репликации, чтобы узнать больше о следующих сценариях использования. Затем настройте кросс-кластерную репликацию на своем локальном компьютере и пройдите по демонстрации из вебинара.

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

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

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

На следующей диаграмме данные из дата-центра A реплицируются в дата-центр B и дата-центр C, оба из которых имеют только для чтения копию лидер-индекса из дата-центра A.

Вы можете реплицировать данные между несколькими центрами обработки данных, чтобы создать цепочку репликации. На следующей диаграмме Центр обработки данных А содержит лидирующий индекс. Центр обработки данных B реплицирует данные из Центра обработки данных А, а Центр обработки данных C реплицирует данные из ведомых индексов в Центре обработки данных B. Соединение между этими центрами обработки данных образует цепочечную схему репликации.

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

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

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

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

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

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

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

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

Хотя вы настраиваете межкластерную репликацию на уровне индекса, Elasticsearch выполняет репликацию на уровне фрагмента. Когда создается ведомый индекс, каждый фрагмент этого индекса получает изменения от соответствующего фрагмента в лидирующем индексе, что означает, что ведомый индекс имеет такое же количество фрагментов, как и лидирующий индекс. Все операции с лидером реплицируются ведомым, например, операции по созданию, обновлению или удалению документа. Эти запросы могут обрабатываться с любой копии лидирующего фрагмента (основной или реплики).

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

Если запрос на чтение завершается ошибкой, причина ошибки проверяется. Если причина ошибки считается исправимой (например, сетевая ошибка), ведомый фрагмент входит в цикл повторной попытки. В противном случае ведомый фрагмент приостанавливает работу до возобновления.

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

Например, вы индексируете документ под названием doc_1 в Центре обработки данных А, который реплицируется в Центр обработки данных B. Если клиент подключается к Центру обработки данных B и пытается обновить doc_1, запрос завершается ошибкой. Чтобы обновить doc_1, клиент должен подключиться к Центру обработки данных А и обновить документ в лидирующем индексе.

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

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

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

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

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

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

Удаленное восстановление — это ресурсоёмкий процесс, который передаёт все файлы сегментов Lucene из лидирующего кластера в ведомый кластер. Ведомый запрашивает инициацию сессии восстановления на первичном фрагменте в лидирующем кластере. Затем ведомый запрашивает фрагменты файлов параллельно из лидирующего кластера. По умолчанию процесс параллельно запрашивает пять фрагментов файлов по 1 МБ. Это поведение по умолчанию предназначено для поддержки лидирующих и ведомых кластеров с высокой задержкой сети между ними.

Используйте API восстановления в кластере, содержащем ведомый индекс, чтобы получить информацию об удалённом восстановлении в процессе. Поскольку Elasticsearch реализует удалённое восстановление с помощью инфраструктуры создания и восстановления моментальных снимков, выполняемые удалённые восстановления имеют метку типа snapshot в API восстановления.

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

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

Параметр index.soft_deletes.retention_lease.period определяет максимальное время хранения аренды истории фрагмента перед тем, как она считается просроченной. Этот параметр определяет, как долго кластер, содержащий ваш ведомый индекс, может быть оффлайн, по умолчанию — 12 часов. Если копия фрагмента восстанавливается после истечения срока действия аренды, но недостающие операции всё ещё доступны в лидирующем индексе, Elasticsearch создаст новую аренду и скопирует недостающие операции. Однако Elasticsearch не гарантирует сохранение операций без аренды, поэтому также возможно, что некоторые из недостающих операций были удалены лидером и теперь полностью недоступны. Если это произойдёт, ведомый индекс не может автоматически восстановиться, поэтому вы должны пересоздать его.

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

В следующих разделах приводится более подробная информация о настройке и использовании репликации между кластерами: