Как перейти с Elasticsearch на OpenSearch

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

Table of Contents

Учет версий при переходе на OpenSearch

OpenSearch 1.0 может быть обновлен с Elasticsearch 6.8.0 до 7.10.2.

Если вы работаете с более ранней версией Elasticsearch, то вам необходимо сначала обновить версию до 6.8.0, как минимум. OpenSearch рекомендует обновить ES с 6.8.0 до 7.10.2 перед обновлением до OpenSearch 1.0.

Еще одним важным моментом является то, что минимальная поддерживаемая версия индекса - 6.0, поэтому все индексы версии 5.0 должны быть переиндексированы перед переходом.

Для этого можно воспользоваться таблицей путей обновления:

Версия Elasticsearch	Скользящий путь обновления	Путь обновления при перезапуске кластера
5.x	Обновление до версии 5.6, обновление до версии 6.8, переиндексация всех индексов версии 5.x, обновление до версии 7.10.2 и обновление до OpenSearch.	Обновление до версии 6.8, переиндексация всех индексов версии 5.x и обновление до OpenSearch.
6.x	Обновление до версии 6.8, обновление до версии 7.10.2 и обновление до OpenSearch.	Переход на OpenSearch.
7.x	Переход на OpenSearch.	Переход на OpenSearch.

Для проверки версии Elasticsearch можно выполнить команду: curl localhost:9200

{
  "name" : "Machine",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "JTt304FgSw6itSFPmMtvrg",
  "version" : {
    "number" : "7.10.2-SNAPSHOT",
    "build_flavor" : "oss",
    "build_type" : "tar",
    "build_hash" : "unknown",
    "build_date" : "2021-01-16T01:41:27.115673Z",
    "build_snapshot" : true,
    "lucene_version" : "8.7.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

{

"name" : "Machine",

"cluster_name" : "elasticsearch",

"cluster_uuid" : "JTt304FgSw6itSFPmMtvrg",

"version" : {

"number" : "7.10.2-SNAPSHOT",

"build_flavor" : "oss",

"build_type" : "tar",

"build_hash" : "unknown",

"build_date" : "2021-01-16T01:41:27.115673Z",

"build_snapshot" : true,

"lucene_version" : "8.7.0",

"minimum_wire_compatibility_version" : "6.8.0",

"minimum_index_compatibility_version" : "6.0.0-beta1"

"tagline" : "You Know, for Search"

}

В данном примере версия Elasticsearch равна 7.10.2, поэтому миграция возможна напрямую.

Можно ли перевести версии 7.11+ (после форка Opensearch) на OpenSearch?

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

Методы миграции

Как перенести данные из Elasticsearch в OpenSearch?

Существует, по сути, 4 метода миграции данных из ES в OS:

Скользящие обновления
Снапшоты
Reindex API
Инструмент обновления OpenSearch

Скользящие обновления и моментальные снимки берут на себя заботу о данных и конфигурации кластера. Reindex API полезен, если вам нужно только перенести данные с одного кластера на другой, не заботясь о конфигурации кластера или маппингах. Инструмент Opensearch Upgrade упрощает сам процесс.

Скользящие обновления

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

Скользящие обновления поддерживаются:

Между младшими версиями

с 5.6 до 6.8
С 6.8 по 7.14.1
С любой версии, начиная с 7.14.0, до 7.14.1

Обновление непосредственно до версии 7.14.1 с версии 6.7 или более ранней требует полного перезапуска кластера.

Как уже упоминалось в начале статьи, мы можем перейти непосредственно на Opensearch, если версия Elasticsearch находится в диапазоне от 6.8 до 7.10.2. В противном случае нам придется сначала обновить Elasticsearch до версии 6.8 (Opensearch даже рекомендует версию 7.10.2).

Для перехода на OpenSearch выполните следующие шаги:

Обновление Elasticsearch

Отключить выделение шардов:

PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "primaries"
}
}

PUT _cluster/settings

{

"persistent": {

"cluster.routing.allocation.enable": "primaries"

}

Остановите ES на одном узле (скользящее обновление) или на всех узлах (обновление с перезапуском кластера):

sudo systemctl stop elasticsearch.service

1	sudo systemctl stop elasticsearch.service

Выполните обновление отдельного узла или всех узлов.

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

sudo yum install elasticsearch-oss-7.10.2 --enablerepo=elasticsearch

1	sudo yum install elasticsearch-oss-7.10.2 --enablerepo=elasticsearch

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

Перезапустите Elasticsearch и дождитесь воссоединения узлов:

sudo systemctl start elasticsearch.service

1	sudo systemctl start elasticsearch.service

Повторите шаги 2-4, пока все узлы не будут использовать одну и ту же версию.

Проверьте версии с помощью:

# Elasticsearch OSS
curl -XGET 'localhost:9200/_nodes/_all?pretty=true'
# Открытый дистрибутив для Elasticsearch с включенным плагином безопасности
curl -XGET 'https://localhost:9200/_nodes/_all?pretty=true' -u 'admin:admin' -k

# Elasticsearch OSS

curl -XGET 'localhost:9200/_nodes/_all?pretty=true'

# Открытый дистрибутив для Elasticsearch с включенным плагином безопасности

curl -XGET 'https://localhost:9200/_nodes/_all?pretty=true' -u 'admin:admin' -k

Также можно использовать: GET _cat/indices?v, чтобы убедиться, что все индексы находятся в зеленом статусе.

Повторно включите распределение шардов:

PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}

PUT _cluster/settings

{

"persistent": {

"cluster.routing.allocation.enable": "all"

}

При переходе с версии 5.x на версию 6.x переиндексируйте все индексы. Повторять до тех пор, пока не будет достигнута нужная версия.

Процесс перехода на OpenSearch аналогичен и описан ниже.

Обновление OpenSearch

Когда узлы Elasticsearch имеют нужную версию (от 6.8.0 до 7.10.2), можно приступать к обновлению до OpenSearch.

Отключите выделение шардов:

PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "primaries"
}
}

PUT _cluster/settings

{

"persistent": {

"cluster.routing.allocation.enable": "primaries"

}

Остановите Elasticsearch на одном узле или на всех узлах:

sudo systemctl stop elasticsearch.service

1	sudo systemctl stop elasticsearch.service

Обновите отдельный узел или все узлы:

Распакуйте OpenSearch в новый каталог, чтобы не перезаписать каталоги конфигурации, данных и журналов Elasticsearch OSS.
(Необязательно) Скопируйте или переместите каталоги данных и журналов Elasticsearch OSS в новые директории. Например, можно переместить каталог /var/lib/elasticsearch в каталог /var/lib/opensearch.
Установите переменную окружения OPENSEARCH_PATH_CONF в каталог, содержащий opensearch.yml (например, /etc/opensearch).
В файле opensearch.yml установите параметры path.data и path.logs. Возможно, вам также захочется отключить на время плагин безопасности.

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

opensearch.yml может выглядеть примерно так:

path.data: /var/lib/opensearch
path.logs: /var/log/opensearch
plugins.security.disabled: true

path.data: /var/lib/opensearch

path.logs: /var/log/opensearch

plugins.security.disabled: true

Перенесите настройки из файла elasticsearch.yml в файл opensearch.yml. В большинстве настроек используются одинаковые имена. Как минимум, укажите cluster.name, node.name, discovery.seed_hosts и cluster.initial_master_nodes.

Запустите OpenSearch на отдельном узле или на всех узлах.

Дождитесь, пока все узлы вновь присоединятся к кластеру в OpenSearch.

Подтвердите это с помощью данного curl:

# Плагин безопасности отключен
curl -XGET 'localhost:9200/_nodes/_all?pretty=true'
# Плагин безопасности включен
curl -XGET -k -u 'admin:admin' 'https://localhost:9200/_nodes/_all?pretty=true'

# Плагин безопасности отключен

curl -XGET 'localhost:9200/_nodes/_all?pretty=true'

# Плагин безопасности включен

curl -XGET -k -u 'admin:admin' 'https://localhost:9200/_nodes/_all?pretty=true'

Повторять до тех пор, пока на всех узлах не заработает OpenSearch.

Повторно включите распределение шардов.

PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}

PUT _cluster/settings

{

"persistent": {

"cluster.routing.allocation.enable": "all"

}

Снимки (снапшоты)

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

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

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

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

GET _snapshot/backups

1	GET _snapshot/backups

Мы должны увидеть нечто подобное:

{
"backups" : {
"type" : "fs",
"settings" : {
"location" : "/mnt/snapshots"
}
}
}

{

"backups" : {

"type" : "fs",

"settings" : {

"location" : "/mnt/snapshots"

}

Эту же настройку мы можем использовать и в нашем кластере OpenSearch:

PUT localhost:9090/_snapshot/backups
{
"type": "fs",
"settings": {
"location": "/mnt/snapshots"
}
}

PUT localhost:9090/_snapshot/backups

{

"type": "fs",

"settings": {

"location": "/mnt/snapshots"

}

Теперь Elasticsearch и Opensearch имеют одну и ту же папку Snapshots.

Для создания моментального снимка выполните в Elasticsearch следующие действия:

PUT _snapshot/backups/es_bk
{
"indices": "snapshot_data"
}

PUT _snapshot/backups/es_bk

{

"indices": "snapshot_data"

}

Имя резервной копии - "es_bk", и мы восстанавливаем индекс "snapshot_data".

Подтвердите, что вы можете увидеть резервную копию, выполнив в Elasticsearch следующие действия:

GET _snapshot/backups/es_bk

1	GET _snapshot/backups/es_bk

После подтверждения восстановите снимок es_bk в Opensearch:

POST _snapshot/backups/es_bk/_restore
{
"accepted": true
}

POST _snapshot/backups/es_bk/_restore

{

"accepted": true

}

Прогресс восстановления можно отслеживать с помощью API восстановления:

GET _cat/recovery?v&active_only=true

1	GET _cat/recovery?v&active_only=true

API Reindex

API Reindex довольно прост. Вы просто задаете индекс источника и индекс назначения, и документы будут проиндексированы в этом индексе. (Некоторые советы по повышению производительности переиндексации см. здесь).

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

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

Главный плюс этого подхода - возможность миграции данных с Elasticsearch 5.x/6.x или 7.12.0+ на Opensearch 1.0.

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

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

Давайте быстро создадим индекс, чтобы изучить его конфигурацию.

POST test_index
{
"name": "Example name",
"otherproperty": "foo"
}

POST test_index

{

"name": "Example name",

"otherproperty": "foo"

}

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

GET test_index

1	GET test_index

И мы получаем такой ответ:

{
 "test_index": {
   "aliases": {},
   "mappings": {
     "properties": {
       "name": {
         "type": "text",
         "fields": {
           "keyword": {
             "type": "keyword",
             "ignore_above": 256
           }
         }
       },
       "otherproperty": {
         "type": "text",
         "fields": {
           "keyword": {
             "type": "keyword",
             "ignore_above": 256
           }
         }
       }
     }
   },
   "settings": {
     "index": {
       "number_of_shards": "1",
       "auto_expand_replicas": null,
       "provided_name": "test_index",
       "creation_date": "1632096818796",
       "priority": "0",
       "number_of_replicas": "1",
       "uuid": "eTux87PyRT6WZoOQrMJVVQ",
       "version": {
         "created": "7100299"
       }
     }
   }
 }
}

{

"test_index": {

"aliases": {},

"mappings": {

"properties": {

"name": {

"type": "text",

"fields": {

"keyword": {

"type": "keyword",

"ignore_above": 256

}

"otherproperty": {

"type": "text",

"fields": {

"keyword": {

"type": "keyword",

"ignore_above": 256

}

"settings": {

"index": {

"number_of_shards": "1",

"auto_expand_replicas": null,

"provided_name": "test_index",

"creation_date": "1632096818796",

"priority": "0",

"number_of_replicas": "1",

"uuid": "eTux87PyRT6WZoOQrMJVVQ",

"version": {

"created": "7100299"

}

Здесь мы должны удалить некоторые автоматически сгенерированные свойства:

"provided_name": "test_index",
"creation_date": "1632096818796",
"uuid": "eTux87PyRT6WZoOQrMJVVQ",
"version": {
"created": "7100299"
}

"provided_name": "test_index",

"creation_date": "1632096818796",

"uuid": "eTux87PyRT6WZoOQrMJVVQ",

"version": {

"created": "7100299"

}

И, наконец, мы можем создать наш целевой индекс в Opensearch:

PUT test_index_2
{
 "mappings": {
   "properties": {
     "name": {
       "type": "text",
       "fields": {
         "keyword": {
           "type": "keyword",
           "ignore_above": 256
         }
       }
     },
     "otherproperty": {
       "type": "text",
       "fields": {
         "keyword": {
           "type": "keyword",
           "ignore_above": 256
         }
       }
     }
   }
 },
 "settings": {
   "index": {
     "number_of_shards": "1",
     "auto_expand_replicas": null,
     "priority": "0",
     "number_of_replicas": "1"
   }
 }
}

PUT test_index_2

{

"mappings": {

"properties": {

"name": {

"type": "text",

"fields": {

"keyword": {

"type": "keyword",

"ignore_above": 256

}

"otherproperty": {

"type": "text",

"fields": {

"keyword": {

"type": "keyword",

"ignore_above": 256

}

"settings": {

"index": {

"number_of_shards": "1",

"auto_expand_replicas": null,

"priority": "0",

"number_of_replicas": "1"

}

Теперь мы можем запустить в нашем индексе OpenSearch:

POST _reindex
{
 "source": {
   "remote": {
     "host": "http://localhost:9200"
   },
   "index": "test_index",
   "query": {
     "match_all": {}
   }
 },
 "dest": {
   "index": "test_index_2"
 }
}

POST _reindex

{

"source": {

"remote": {

"host": "http://localhost:9200"

"index": "test_index",

"query": {

"match_all": {}

}

"dest": {

"index": "test_index_2"

}

Обратите внимание на запрос match_all, добавленный для иллюстрации сужения переиндексируемых документов. Теперь test_index_2 в OpenSearch будет содержать те же данные, что и test_index в Elasticsearch. Вы можете задать некоторые параметры, например, максимальное количество документов или количество запросов в секунду, как описано здесь.

Инструмент обновления OpenSearch

В выпуске Opensearch 1.1 появился новый инструмент обновления, позволяющий автоматизировать некоторые шаги, описанные в этой статье в разделе "Обновление Opensearch".

Полную документацию можно найти здесь.

Ограничения инструмента обновления

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

Как это работает

Подключается к работающей установке Elasticsearch.
Проверяет совместимость версии для миграции.
Импортирует настройки из файла elasticsearch.yml в файл opensearch.yml.
Копирует настройки JVM (jvm.options.d) и протоколирования (log4j2.properties) из ES в OS.
Устанавливает основные плагины. Сторонние плагины должны быть установлены вручную.
Импортирует настройки безопасности из elasticsearch.keystore в opensearch.keystore.

Как использовать инструмент обновления

Отключить выделение шардов:

PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "primaries"
}
}

PUT _cluster/settings

{

"persistent": {

"cluster.routing.allocation.enable": "primaries"

}

Загрузите и распакуйте OpenSearch в новый каталог.

Убедитесь, что переменные окружения установлены правильно:

ES_HOME - Путь к дому существующей установки Elasticsearch.
export ES_HOME = /home/workspace/upgrade-demo/node1/elasticsearch-7.10.2
ES_PATH_CONF - Путь к существующему каталогу конфигурации Elasticsearch.
export ES_PATH_CONF = /home/workspace/upgrade-demo/node1/es-config
OPENSEARCH_HOME - Путь к установке OpenSearch.
export OPENSEARCH_HOME = /home/workspace/upgrade-demo/node1/opensearch-1.0.0
OPENSEARCH_PATH_CONF - Путь к директории конфигурации OpenSearch.
export OPENSEARCH_PATH_CONF = /home/workspace/upgrade-demo/node1/opensearch-config

Запустите инструмент обновления:

./bin/opensearch-upgrade

1	./bin/opensearch-upgrade

Остановите Elasticsearch на узле:

sudo systemctl stop elasticsearch.service

1	sudo systemctl stop elasticsearch.service

Запустите OpenSearch на узле:

./bin/opensearch -d

1	./bin/opensearch -d

Повторить на всех узлах.

После того как все узлы будут обновлены, снова включите выделение шардов:

PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}

PUT _cluster/settings

{

"persistent": {

"cluster.routing.allocation.enable": "all"

}

Заключение

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