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

С помощью репликации между кластерами вы можете реплицировать индексы между кластерами для:

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

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

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

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

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

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

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

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

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

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

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

На следующей схеме данные из ЦОД А реплицируются в ЦОД Б и ЦОД С, в которых оба содержат только для чтения копии индекса-лидера из ЦОД А.

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, вы индексируете документ, названный doc_1 в ЦОД А, который реплицируется в ЦОД Б. Если клиент подключается к ЦОД Б и пытается обновить 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 или позднее.

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

Репликация между кластерами предназначена для репликации индексов, созданных пользователем, и в настоящее время не реплицирует следующее:

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