Поисковые снимки

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

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

Поиск в индексе поискового снимка аналогичен поиску в любом другом индексе.

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

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

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

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

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

Скорость восстановления индекса поискового снимка ограничена параметром репозитория max_restore_bytes_per_sec и параметром узла indices.recovery.max_bytes_per_sec, как и при обычном процессе восстановления. По умолчанию max_restore_bytes_per_sec не ограничен, но значение по умолчанию для indices.recovery.max_bytes_per_sec зависит от конфигурации узла. См. настройки восстановления.

Рекомендуется объединить индексы в один сегмент на фрагмент перед созданием снимка, который будет смонтирован как индекс поискового снимка. Каждый чтение из репозитория снимков занимает время и стоит денег, а чем меньше сегментов, тем меньше чтений требуется для восстановления снимка или для ответа на запрос.

Используйте любой из следующих типов репозиториев с поисковыми снимками:

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

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

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

Для поиска в снимке его необходимо сначала смонтировать локально в виде индекса. Обычно ILM делает это автоматически, но вы также можете вызвать API монтирования снимка самостоятельно. Существует два варианта монтирования индекса из снимка, каждый из которых обладает различными характеристиками производительности и размером локального хранилища:

Для частичного монтирования индекса необходимо наличие одного или нескольких узлов с общим кешем. По умолчанию узлы выделенного уровня замороженных данных (узлы с ролью data_frozen и без других ролей данных) имеют общий кеш, настроенный на максимальное значение из 90% от общего объёма диска и общий объём диска за вычетом запаса в 100 ГБ.

Использование выделенного уровня замороженных данных настоятельно рекомендуется для использования в рабочей среде. Если у вас нет выделенного уровня замороженных данных, вы должны настроить параметр xpack.searchable.snapshot.shared_cache.size для резервирования места для кеша на одном или нескольких узлах. Частично смонтированные индексы назначаются только узлам, имеющим общий кеш.

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

Вы можете настроить настройки в elasticsearch.yml:

xpack.searchable.snapshot.shared_cache.size: 4TB

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

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

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

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

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

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

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

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

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

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