Миграция в Managed Service for Elasticsearch с помощью снапшотов

Кластер Managed Service for Elasticsearch поддерживает механизм снапшотов. Это позволяет мигрировать в него данные из другого кластера Elasticsearch. Подробнее о механизме снапшотов см. в документации Elasticsearch.

Чтобы мигрировать данные из кластера-источника Elasticsearch в кластер-приемник Managed Service for Elasticsearch:

1. Подготовьте рабочее окружение.
2. Создайте снапшот на кластере-источнике.
3. Восстановите снапшот в кластере-приемнике.
4. Закончите миграцию.

Если используемые ресурсы вам больше не нужны, удалите их.

Подготовьте рабочее окружениеПодготовьте рабочее окружение

Создайте необходимые ресурсыСоздайте необходимые ресурсы

Завершите настройку и проверьте доступ к ресурсамЗавершите настройку и проверьте доступ к ресурсам

1. Настройте ACL для бакета:

   1. В выпадающем списке Выберите пользователя укажите созданный ранее сервисный аккаунт.
   2. Задайте разрешения READ и WRITE для выбранного сервисного аккаунта.
   3. Нажмите кнопку Добавить.
   4. Нажмите кнопку Сохранить.

2. Установите плагин repository-s3 на все хосты кластера-источника.

3. Чтобы плагин repository-s3 заработал, перезапустите сервисы Elasticsearch и Kibana на всех хостах кластера-источника.

4. Убедитесь, что вы можете подключиться к кластеру-приемнику Managed Service for Elasticsearch с помощью Elasticsearch API и Kibana.

5. Убедитесь, что у кластера-источника Elasticsearch есть доступ в интернет.

Создайте снапшот на кластере-источникеСоздайте снапшот на кластере-источнике

1. Подключите бакет в качестве репозитория снапшотов на кластере-источнике:

   1. Добавьте сведения о ключе статического доступа в хранилище ключей (keystore) Elasticsearch.

      Выполните процедуру на всех хостах кластера-источника.

      Добавьте:

      • Идентификатор ключа:

        $ES_PATH/bin/elasticsearch-keystore add s3.client.default.access_key
        

      • Секретный ключ:

        $ES_PATH/bin/elasticsearch-keystore add s3.client.default.secret_key
        

        Примечание

        Путь к Elasticsearch ($ES_PATH) зависит от выбранного способа установки. Найти путь к установленному Elasticsearch можно в документации по установке (например, для DEB, RPM).

   2. Загрузите данные из хранилища ключей:

      curl -X POST "https://<FQDN_кластера-источника>:9200/_nodes/reload_secure_settings"
      

   3. Зарегистрируйте репозиторий:

      curl "https://<FQDN_кластера-источника>:9200/_snapshot/<имя_репозитория>" \
           -X PUT \
           -H 'Content-Type: application/json' -d '
             {
               "type": "s3",
               "settings": {
                 "bucket": "<имя_бакета>",
                 "endpoint": "storage.yandexcloud.net"
               }
             }'
      

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

   Внимание

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

2. Запустите создание снапшота на кластере-источнике. Можно создать снапшот всего кластера или части данных. Разместите снапшот в репозитории, созданном на предыдущем шаге. Подробнее см. в документации Elasticsearch.

   Пример создания снапшота с именем snapshot_1 для всего кластера:

   curl -X PUT \
        "https://<FQDN_кластера-источника>:9200/_snapshot/<имя_репозитория>/snapshot_1?wait_for_completion=true&pretty"
   

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

   curl -X GET \
        "https://<FQDN_кластера-источника>:9200/_snapshot/<имя_репозитория>/snapshot_1/_status?pretty"
   

Восстановите снапшот в кластере-приемникеВосстановите снапшот в кластере-приемнике

1. Настройте доступ к бакету со снапшотами для кластера-приемника. Используйте созданный ранее сервисный аккаунт.

2. Подключите к кластеру-приемнику бакет Object Storage в качестве хранилища снапшотов:

   curl "https://admin:<пароль_пользователя_admin>@<FQDN_кластера-приемника>:9200/_snapshot/<имя_репозитория>" \
        -X PUT \
        -H 'Content-Type: application/json' -d '
          {
            "type": "s3",
            "settings": {
              "bucket": "<имя_бакета>",
              "endpoint": "storage.yandexcloud.net"
            }
          }'
   

3. Выберите способ восстановления индексов на кластере-приемнике:

   При настройках по умолчанию попытка восстановления индекса завершится неудачей, если в кластере уже открыт индекс с тем же именем. Даже если кластер Managed Service for Elasticsearch не содержит пользовательских данных, в нем есть открытые системные индексы (такие как .apm-custom-link, .kibana_* и другие), что может помешать восстановлению. Чтобы этого избежать, воспользуйтесь одной из политик восстановления:

   • Только пользовательские индексы — существующие системные индексы не переносятся, в процессе импорта участвую только индексы, созданные на кластере-источнике пользователем.

   • Delete and restore — существующие индексы закрываются и удаляются, вместо них создаются новые пустые с такими же именами, после чего наполняются данными из снапшота.

   • Rename on restore — существующие индексы не затрагиваются, создаются новые с измененными именами. Данные из снапшота восстанавливаются в новые индексы.

   Важно

   Закрытие всех индексов приведет к временной неработоспособности Kibana. После того как будут открыты системные индексы, Kibana вновь станет доступна.

   Например, эта команда закроет все индексы в кластере-приемнике:

   curl -X POST \
        "https://admin:<пароль_пользователя_admin>@<FQDN_кластера-приемника>:9200/_all/_close?pretty"
   

   Пример восстановления снапшота целиком:

   curl -X POST \
        "https://admin:<пароль_пользователя_admin>@<FQDN_кластера-приемника>:9200/_snapshot/<имя_репозитория>/snapshot_1/_restore"
   

4. Запустите восстановление из снапшота на кластере-приемнике. Можно восстановить весь снапшот или отдельные индексы. Подробнее см. в документации Elasticsearch.

   Пример восстановления снапшота с указанием пользовательских индексов, которые нужно восстановить в кластере-приемнике:

   curl -X POST \
        -H 'Content-Type: application/json' 'https://admin:<пароль_пользователя_admin>@<FQDN_кластера-приемника>:9200/_snapshot/<имя_репозитория>/snapshot_1/_restore' -d '
        {
          "indices": "<список_индексов>"
        }'
   

   Где список индексов — список восстанавливаемых индексов через запятую, например my_index*, my_index_2.*. Перенос только пользовательских индексов позволит избежать ошибок при восстановлении снапшота — системные индексы не затрагиваются.

   Процесс восстановления может занять длительное время. Отслеживайте ход выполнения операции с помощью инструментов Elasticsearch, например:

   curl -X GET \
        "https://admin:<пароль_пользователя_admin>@<FQDN_кластера-приемника>:9200/_snapshot/<имя_репозитория>/snapshot_1/_status?pretty"
   

5. При необходимости после завершения операции восстановления откройте все закрытые индексы.

   Например, эта команда откроет все индексы в кластере-приемнике:

   curl -X POST \
        "https://admin:<пароль_пользователя_admin>@<FQDN_кластера-приемника>:9200/_all/_open?pretty"
   

Закончите миграциюЗакончите миграцию

1. Убедитесь, что все нужные данные перенесены в кластер-приемник Managed Service for Elasticsearch.

   Это можно сделать, например, с помощью Kibana.

2. При необходимости отключите репозиторий снапшотов на стороне кластера-источника и кластера-приемника.

Удалите созданные ресурсыУдалите созданные ресурсы

Некоторые ресурсы платные. Чтобы за них не списывалась плата, удалите ресурсы, которые вы больше не будете использовать: