Upgrading OpenSearch
Проект OpenSearch регулярно выпускает обновления, которые включают новые функции, улучшения и исправления ошибок. OpenSearch использует семантическое версионирование, что означает, что разрушающие изменения вводятся только между основными версиями. Чтобы узнать о предстоящих функциях и исправлениях, ознакомьтесь с дорожной картой проекта OpenSearch на GitHub. Чтобы просмотреть список предыдущих релизов или узнать больше о том, как OpenSearch использует версионирование, смотрите раздел “График релизов и политика обслуживания”.
Мы понимаем, что пользователи заинтересованы в обновлении OpenSearch, чтобы воспользоваться последними функциями, и мы будем продолжать расширять эти документы по обновлению и миграции, чтобы охватить дополнительные темы, такие как обновление OpenSearch Dashboards и сохранение пользовательских конфигураций, например, для плагинов.
Если вы хотите, чтобы был добавлен конкретный процесс или хотите внести свой вклад, создайте задачу на GitHub. Ознакомьтесь с Руководством для участников, чтобы узнать, как вы можете помочь.
Учет рабочих процессов
Потратьте время на планирование процесса перед внесением каких-либо изменений в ваш кластер. Например, рассмотрите следующие вопросы:
- Сколько времени займет процесс обновления?
- Если ваш кластер используется в производственной среде, насколько критично время простоя?
- У вас есть инфраструктура для развертывания нового кластера в тестовой или разработческой среде перед его переводом в эксплуатацию, или вам нужно обновить производственные узлы напрямую?
Ответы на такие вопросы помогут вам определить, какой путь обновления будет наиболее подходящим для вашей среды.
Минимально вы должны:
- Ознакомиться с разрушающими изменениями.
- Ознакомиться с матрицами совместимости инструментов OpenSearch.
- Ознакомиться с совместимостью плагинов.
- Создать резервные копии файлов конфигурации.
- Создать снимок.
Остановить любую несущественную индексацию перед началом процедуры обновления, чтобы устранить ненужные требования к ресурсам кластера во время выполнения обновления.
Ознакомление с разрушающими изменениями
Важно определить, как новая версия OpenSearch будет интегрироваться с вашей средой. Ознакомьтесь с разделом “Разрушающие изменения” перед началом любых процедур обновления, чтобы определить, нужно ли вам вносить изменения в ваш рабочий процесс. Например, компоненты, находящиеся выше или ниже по потоку, могут потребовать модификации для совместимости с изменением API (см. мета-проблему #2589).
Ознакомление с матрицами совместимости инструментов OpenSearch
Если ваш кластер OpenSearch взаимодействует с другими службами в вашей среде, такими как Logstash или Beats, вам следует проверить матрицы совместимости инструментов OpenSearch, чтобы определить, нужно ли обновлять другие компоненты.
Ознакомление с совместимостью плагинов
Проверьте плагины, которые вы используете, чтобы определить их совместимость с целевой версией OpenSearch. Официальные плагины проекта OpenSearch можно найти в репозитории проекта OpenSearch на GitHub. Если вы используете сторонние плагины, вам следует ознакомиться с документацией для этих плагинов, чтобы определить, совместимы ли они.
Перейдите в раздел “Доступные плагины”, чтобы увидеть справочную таблицу, которая подчеркивает совместимость версий для встроенных плагинов OpenSearch.
Основные, второстепенные и патч-версии плагинов должны соответствовать основным, второстепенным и патч-версиям OpenSearch для обеспечения совместимости. Например, версии плагинов 2.3.0.x работают только с OpenSearch 2.3.0.
Резервное копирование файлов конфигурации
Снизьте риск потери данных, создав резервные копии любых важных файлов перед началом обновления. Обычно эти файлы будут находиться в одной из двух директорий:
opensearch/configopensearch-dashboards/config
Некоторые примеры включают opensearch.yml, opensearch_dashboards.yml, файлы конфигурации плагинов и сертификаты TLS. Как только вы определите, какие файлы хотите сохранить, скопируйте их на удаленное хранилище для безопасности.
Если вы используете функции безопасности, обязательно ознакомьтесь с разделом “Предостережение” для получения информации о резервном копировании и восстановлении ваших настроек безопасности.
Создание снимка
Рекомендуется создать резервную копию состояния вашего кластера и индексов с помощью снимков. Снимки, сделанные перед обновлением, могут быть использованы в качестве точек восстановления, если вам нужно будет откатить кластер к его оригинальной версии.
Вы можете дополнительно снизить риск потери данных, храня ваши снимки на внешнем хранилище, таком как смонтированная файловая система сети (NFS) или облачное хранилище, как указано в следующей таблице.
| Местоположение репозитория снимков | Требуемый плагин OpenSearch |
|---|---|
| Amazon Simple Storage Service (Amazon S3) | repository-s3 |
| Google Cloud Storage (GCS) | repository-gcs |
| Apache Hadoop Distributed File System (HDFS) | repository-hdfs |
| Microsoft Azure Blob Storage | repository-azure |
Методы обновления
Выберите подходящий метод для обновления вашего кластера до новой версии OpenSearch в зависимости от ваших требований:
- Постепенное обновление (rolling upgrade) обновляет узлы по одному без остановки кластера.
- Обновление с перезапуском кластера (cluster restart upgrade) обновляет службы, пока кластер остановлен.
Обновления, охватывающие более одной основной версии OpenSearch, потребуют дополнительных усилий из-за необходимости повторной индексации. Для получения дополнительной информации обратитесь к API повторной индексации. См. таблицу совместимости индексов, включенную позже в этом руководстве, для помощи в планировании миграции данных.
Постепенное обновление
Постепенное обновление — отличный вариант, если вы хотите сохранить работоспособность вашего кластера на протяжении всего процесса. Данные могут продолжать поступать, анализироваться и запрашиваться, пока узлы поочередно останавливаются, обновляются и перезапускаются. Вариация постепенного обновления, называемая “замена узла” (node replacement), следует точно такому же процессу, за исключением того, что хосты и контейнеры не повторно используются для нового узла. Вы можете выполнить замену узла, если также обновляете базовые хосты.
Узлы OpenSearch не могут присоединиться к кластеру, если менеджер кластера работает на более новой версии OpenSearch, чем узел, запрашивающий членство. Чтобы избежать этой проблемы, обновляйте узлы, имеющие право на управление кластером, последними.
Смотрите раздел “Постепенное обновление” для получения дополнительной информации о процессе.
Обновление с перезапуском кластера
Администраторы OpenSearch могут выбрать выполнение обновления с перезапуском кластера по нескольким причинам, например, если администратор не хочет проводить обслуживание работающего кластера или если кластер мигрируется в другую среду.
В отличие от постепенного обновления, при котором только один узел отключен в любой момент времени, обновление с перезапуском кластера требует остановки OpenSearch и OpenSearch Dashboards на всех узлах кластера перед продолжением. После остановки узлов устанавливается новая версия OpenSearch. Затем OpenSearch запускается, и кластер загружается на новую версию.
Совместимость
Узлы OpenSearch совместимы с другими узлами OpenSearch, работающими на любой другой минорной версии в рамках одного основного релиза. Например, версия 1.1.0 совместима с 1.3.7, поскольку они являются частью одной основной версии (1.x). Кроме того, узлы OpenSearch и индексы обратно совместимы с предыдущей основной версией. Это означает, что, например, индекс, созданный узлом OpenSearch, работающим на любой версии 1.x, может быть восстановлен из снимка в кластер OpenSearch, работающий на любой версии 2.x.
Узлы OpenSearch 1.x совместимы с узлами, работающими на Elasticsearch 7.x, но продолжительность работы смешанной версии не должна превышать период обновления кластера.
Совместимость индексов определяется версией Apache Lucene, которая создала индекс. Если индекс был создан кластером OpenSearch, работающим на версии 1.0.0, то этот индекс может использоваться любым другим кластером OpenSearch, работающим до последнего релиза 1.x или 2.x. См. таблицу совместимости индексов для версий Lucene, работающих в OpenSearch 1.0.0 и более поздних версиях, а также в Elasticsearch 6.8 и более поздних версиях.
Если ваш путь обновления охватывает более одной основной версии и вы хотите сохранить существующие индексы, вы можете использовать API повторной индексации (Reindex API), чтобы сделать ваши индексы совместимыми с целевой версией OpenSearch перед обновлением. Например, если ваш кластер в настоящее время работает на Elasticsearch 6.8 и вы хотите обновиться до OpenSearch 2.x, вам сначала нужно обновиться до OpenSearch 1.x, заново создать ваши индексы с помощью API повторной индексации и, наконец, обновиться до 2.x. Одной из альтернатив повторной индексации является повторное извлечение данных из источника, например, воспроизведение потока данных или извлечение данных из базы данных.
Справочная таблица совместимости индексов
Если вы планируете сохранить старые индексы после обновления версии OpenSearch, вам может потребоваться повторная индексация или повторное извлечение данных. Обратитесь к следующей таблице для версий Lucene в недавних релизах OpenSearch и Elasticsearch.
| Версия Lucene | Версия OpenSearch | Версия Elasticsearch |
|---|---|---|
| 9.10.0 | 2.14.0 | |
| 2.13.0 | 8.13 | |
| 9.9.2 | 2.12.0 | — |
| 9.7.0 | 2.11.1 | |
| 2.9.0 | 8.9.0 | |
| 9.6.0 | 2.8.0 | 8.8.0 |
| 9.5.0 | 2.7.0 | |
| 2.6.0 | 8.7.0 | |
| 9.4.2 | 2.5.0 | |
| 2.4.1 | 8.6 | |
| 9.4.1 | 2.4.0 | — |
| 9.4.0 | — | 8.5 |
| 9.3.0 | 2.3.0 | |
| 2.2.x | 8.4 | |
| 9.2.0 | 2.1.0 | 8.3 |
| 9.1.0 | 2.0.x | 8.2 |
| 9.0.0 | — | 8.1 |
| 8.0 | ||
| 8.11.1 | — | 7.17 |
| 8.10.1 | 1.3.x | |
| 1.2.x | 7.16 | |
| 8.9.0 | 1.1.0 | 7.15 |
| 7.14 | ||
| 8.8.2 | 1.0.0 | 7.13 |
| 8.8.0 | — | 7.12 |
| 8.7.0 | — | 7.11 |
| 7.10 | ||
| 8.6.2 | — | 7.9 |
| 8.5.1 | — | 7.8 |
| 7.7 | ||
| 8.4.0 | — | 7.6 |
| 8.3.0 | — | 7.5 |
| 8.2.0 | — | 7.4 |
| 8.1.0 | — | 7.3 |
| 8.0.0 | — | 7.2 |
| 7.1 | ||
| 7.7.3 | — | 6.8 |
Тире (—) указывает на то, что нет версии продукта, содержащей указанную версию Apache Lucene.
