Это многостраничный печатный вид этого раздела. Нажмите что бы печатать.

Вернуться к обычному просмотру страницы.

Upgrading OpenSearch

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

1: Приложение по обновлениям
2: Постепенное обновление
3: Лаборатория последовательного обновления

Проект 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/config
opensearch-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.

1 - Приложение по обновлениям

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

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

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

Если вы хотите запросить конкретную тему, пожалуйста, оставьте комментарий по вопросу #2830 в проекте OpenSearch на GitHub.

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

2 - Постепенное обновление

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

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

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

Подготовка к обновлению

Ознакомьтесь с разделом “Обновление OpenSearch” для получения рекомендаций по резервному копированию ваших файлов конфигурации и созданию снимка состояния кластера и индексов перед внесением каких-либо изменений в ваш кластер OpenSearch.

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

Выполнение обновления

Проверьте состояние вашего кластера OpenSearch перед началом. Вам следует решить любые проблемы с индексами или распределением шардов перед обновлением, чтобы гарантировать сохранность ваших данных. Статус “green” указывает на то, что все первичные и реплика-шарды распределены. См. раздел “Состояние кластера” для получения дополнительной информации. Следующая команда запрашивает конечную точку API _cluster/health:

GET "/_cluster/health?pretty"

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

{
    "cluster_name": "opensearch-dev-cluster",
    "status": "green",
    "timed_out": false,
    "number_of_nodes": 4,
    "number_of_data_nodes": 4,
    "active_primary_shards": 1,
    "active_shards": 4,
    "relocating_shards": 0,
    "initializing_shards": 0,
    "unassigned_shards": 0,
    "delayed_unassigned_shards": 0,
    "number_of_pending_tasks": 0,
    "number_of_in_flight_fetch": 0,
    "task_max_waiting_in_queue_millis": 0,
    "active_shards_percent_as_number": 100.0
}

Отключите репликацию шардов, чтобы предотвратить создание реплик шардов, пока узлы отключаются. Это остановит перемещение сегментов индекса Lucene на узлах в вашем кластере. Вы можете отключить репликацию шардов, запросив конечную точку API _cluster/settings:

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

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

{
  "acknowledged": true,
  "persistent": {
    "cluster": {
      "routing": {
        "allocation": {
          "enable": "primaries"
        }
      }
    }
  },
  "transient": {}
}

Выполните операцию сброса на кластере, чтобы зафиксировать записи журнала транзакций в индексе Lucene:

POST "/_flush?pretty"

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

{
  "_shards": {
    "total": 4,
    "successful": 4,
    "failed": 0
  }
}

Ознакомьтесь с вашим кластером и определите первый узел для обновления. Узлы, имеющие право на управление кластером, должны обновляться последними, поскольку узлы OpenSearch могут присоединиться к кластеру с управляющими узлами, работающими на более старой версии, но не могут присоединиться к кластеру, в котором все управляющие узлы работают на более новой версии.
Запросите конечную точку _cat/nodes, чтобы определить, какой узел был повышен до управляющего узла кластера. Следующая команда включает дополнительные параметры запроса, которые запрашивают только имя, версию, роль узла и заголовки master. Обратите внимание, что версии OpenSearch 1.x используют термин “master”, который был устаревшим и заменен на “cluster_manager” в OpenSearch 2.x и более поздних версиях.

GET "/_cat/nodes?v&h=name,version,node.role,master" | column -t

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

name        version  node.role  master
os-node-01  7.10.2   dimr       -
os-node-04  7.10.2   dimr       -
os-node-03  7.10.2   dimr       -
os-node-02  7.10.2   dimr       *

Остановите узел, который вы обновляете. Не удаляйте объем, связанный с контейнером, когда вы удаляете контейнер. Новый контейнер OpenSearch будет использовать существующий объем. Удаление объема приведет к потере данных.
Подтвердите, что связанный узел был исключен из кластера, запросив конечную точку API _cat/nodes:

GET "/_cat/nodes?v&h=name,version,node.role,master" | column -t

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

name        version  node.role  master
os-node-02  7.10.2   dimr       *
os-node-04  7.10.2   dimr       -
os-node-03  7.10.2   dimr       -

Узел os-node-01 больше не отображается, потому что контейнер был остановлен и удален.

Разверните новый контейнер, работающий на желаемой версии OpenSearch и подключенный к тому же объему, что и удаленный контейнер.
Запросите конечную точку _cat/nodes после того, как OpenSearch запустится на новом узле, чтобы подтвердить, что он присоединился к кластеру:

GET "/_cat/nodes?v&h=name,version,node.role,master" | column -t

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

name        version  node.role  master
os-node-02  7.10.2   dimr       *
os-node-04  7.10.2   dimr       -
os-node-01  7.10.2   dimr       -
os-node-03  7.10.2   dimr       -

В примере вывода новый узел OpenSearch сообщает о работающей версии 7.10.2 в кластер. Это результат compatibility.override_main_response_version, который используется при подключении к кластеру с устаревшими клиентами, проверяющими версию. Вы можете вручную подтвердить версию узла, вызвав конечную точку API /_nodes, как в следующей команде. Замените <nodeName> на имя вашего узла. См. раздел “API узлов”, чтобы узнать больше.

GET "/_nodes/<nodeName>?pretty=true" | jq -r '.nodes | .[] | "\(.name) v\(.version)"'

Подтвердите, что ответ выглядит примерно так:

os-node-01 v1.3.7

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

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

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

{
  "acknowledged": true,
  "persistent": {
    "cluster": {
      "routing": {
        "allocation": {
          "enable": "all"
        }
      }
    }
  },
  "transient": {}
}

Подтвердите, что кластер здоров:

GET "/_cluster/health?pretty"

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

{
  "cluster_name": "opensearch-dev-cluster",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 4,
  "number_of_data_nodes": 4,
  "discovered_master": true,
  "active_primary_shards": 1,
  "active_shards": 4,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 100.0
}

Повторите шаги 2–11 для каждого узла в вашем кластере. Не забудьте обновить узел управляющего кластера последним. После замены последнего узла запросите конечную точку _cat/nodes, чтобы подтвердить, что все узлы присоединились к кластеру. Кластер теперь загружен на новую версию OpenSearch. Вы можете проверить версию кластера, запросив конечную точку API _cat/nodes:

GET "/_cat/nodes?v&h=name,version,node.role,master" | column -t

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

name        version  node.role  master
os-node-04  1.3.7    dimr       -
os-node-02  1.3.7    dimr       *
os-node-01  1.3.7    dimr       -
os-node-03  1.3.7    dimr       -

Обновление завершено, и вы можете начать пользоваться последними функциями и исправлениями!

Пошаговая перезагрузка

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

Чтобы выполнить пошаговую перезагрузку, следуйте шагам, описанным в разделе “Пошаговое обновление”, исключая шаги, связанные с обновлением бинарного файла OpenSearch или образа контейнера:

Проверьте состояние кластера Убедитесь, что статус кластера зеленый и все шардов назначены. (Шаг 1 пошагового обновления)
Отключите перераспределение шардов Предотвратите попытки OpenSearch перераспределить шардов, пока узлы находятся в оффлайне. (Шаг 2 пошагового обновления)
Сбросьте журналы транзакций Зафиксируйте недавние операции в Lucene, чтобы сократить время восстановления. (Шаг 3 пошагового обновления)
Просмотрите и определите следующий узел для перезагрузки Убедитесь, что вы перезагрузите текущий узел-менеджер кластера последним. (Шаг 4 пошагового обновления)
Проверьте, какой узел является текущим менеджером кластера Используйте API _cat/nodes, чтобы определить, какой узел является текущим активным менеджером кластера. (Шаг 5 пошагового обновления)
Остановите узел Корректно завершите работу узла. Не удаляйте связанный объем данных. (Шаг 6 пошагового обновления)
Подтвердите, что узел покинул кластер Используйте _cat/nodes, чтобы убедиться, что он больше не указан в списке. (Шаг 7 пошагового обновления)
Перезагрузите узел Запустите тот же узел (тот же бинарный файл/версия/конфигурация) и дайте ему повторно присоединиться к кластеру. (Шаг 8 пошагового обновления — без обновления бинарного файла)
Проверьте, что перезагруженный узел повторно присоединился Проверьте _cat/nodes, чтобы подтвердить, что узел присутствует и работает корректно. (Шаг 9 пошагового обновления)
Включите перераспределение шардов Восстановите полную возможность перемещения шардов. (Шаг 10 пошагового обновления)
Подтвердите, что состояние кластера зеленое Проверьте стабильность перед перезагрузкой следующего узла. (Шаг 11 пошагового обновления)
Повторите процесс для всех остальных узлов Перезагрузите каждый узел по одному. Если узел подходит для роли менеджера кластера, перезагрузите его последним. (Шаг 12 пошагового обновления — снова без шага обновления)

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

3 - Лаборатория последовательного обновления

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

Это упражнение полезно, если вы хотите протестировать процесс обновления в среде разработки.

Шаги, использованные в этой лаборатории, были проверены на произвольно выбранном экземпляре Amazon Elastic Compute Cloud (Amazon EC2) t2.large с использованием ядра Amazon Linux 2 версии Linux 5.10.162-141.675.amzn2.x86_64 и Docker версии 20.10.17, сборка 100c701. Экземпляр был предоставлен с прикрепленным корневым томом Amazon EBS объемом 20 GiB gp2. Эти спецификации включены для информационных целей и не представляют собой аппаратные требования для OpenSearch или OpenSearch Dashboards.

Ссылки в этой процедуре на путь $HOME на хост-машине представлены символом тильда (“~”), чтобы сделать инструкции более переносимыми. Если вы предпочитаете указывать абсолютный путь, измените пути томов, определенные в upgrade-demo-cluster.sh, и используемые в соответствующих командах в этом документе, чтобы отразить вашу среду.

Настройка окружения

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

docker container stop $(docker container ls -aqf name=os-); \
docker container rm $(docker container ls -aqf name=os-); \
docker volume rm -f $(docker volume ls -q | egrep 'data-0|repo-0'); \
docker network rm opensearch-dev-net

Эта команда удаляет контейнеры с именами, соответствующими регулярному выражению os-, тома данных, соответствующие data-0 и repo-0*, а также сеть Docker с именем opensearch-dev-net. Если у вас есть другие ресурсы Docker, работающие на вашем хосте, вам следует просмотреть и изменить команду, чтобы избежать случайного удаления других ресурсов. Эта команда не отменяет изменения конфигурации хоста, такие как поведение обмена памяти.

После выбора хоста вы можете начать лабораторию:

Установите соответствующую версию Docker Engine для вашего дистрибутива Linux и архитектуры системы.
Настройте важные системные параметры на вашем хосте:
- Отключите обмен и пейджинг памяти на хосте для повышения производительности:
```
sudo swapoff -a
```
- Увеличьте количество доступных для OpenSearch карт памяти. Откройте файл конфигурации sysctl для редактирования. Эта команда использует текстовый редактор vim, но вы можете использовать любой доступный текстовый редактор:
```
sudo vim /etc/sysctl.conf
```
- Добавьте следующую строку в /etc/sysctl.conf:
```
vm.max_map_count=262144
```
- Сохраните и выйдите. Если вы используете текстовые редакторы vi или vim, сохраните и выйдите, переключившись в командный режим и введя :wq! или ZZ.
- Примените изменение конфигурации:
```
sudo sysctl -p
```
Создайте новую директорию с именем deploy в вашем домашнем каталоге, затем перейдите в нее. Вы будете использовать ~/deploy для путей в скрипте развертывания, конфигурационных файлах и TLS-сертификатах:
```
mkdir ~/deploy && cd ~/deploy
```

Скачайте upgrade-demo-cluster.sh из репозитория документации проекта OpenSearch:

wget https://raw.githubusercontent.com/opensearch-project/documentation-website/main/assets/examples/upgrade-demo-cluster.sh

Запустите скрипт без каких-либо изменений, чтобы развернуть четыре контейнера, работающих с OpenSearch, и один контейнер, работающий с OpenSearch Dashboards, с пользовательскими самоподписанными TLS-сертификатами и заранее определенным набором внутренних пользователей:

sh upgrade-demo-cluster.sh

Проверьте, что контейнеры были успешно запущены:

docker container ls

Пример ответа

CONTAINER ID   IMAGE                                           COMMAND                  CREATED          STATUS          PORTS                                                                                                      NAMES
6e5218c8397d   opensearchproject/opensearch-dashboards:1.3.7   "./opensearch-dashbo…"   24 seconds ago   Up 22 seconds   0.0.0.0:5601->5601/tcp, :::5601->5601/tcp                                                                  os-dashboards-01
cb5188308b21   opensearchproject/opensearch:1.3.7              "./opensearch-docker…"   25 seconds ago   Up 24 seconds   9300/tcp, 9650/tcp, 0.0.0.0:9204->9200/tcp, :::9204->9200/tcp, 0.0.0.0:9604->9600/tcp, :::9604->9600/tcp   os-node-04
71b682aa6671   opensearchproject/opensearch:1.3.7              "./opensearch-docker…"   26 seconds ago   Up 25 seconds   9300/tcp, 9650/tcp, 0.0.0.0:9203->9200/tcp, :::9203->9200/tcp, 0.0.0.0:9603->9600/tcp, :::9603->9600/tcp   os-node-03
f894054a9378   opensearchproject/opensearch:1.3.7              "./opensearch-docker…"   27 seconds ago   Up 26 seconds   9300/tcp, 9650/tcp, 0.0.0.0:9202->9200/tcp, :::9202->9200/tcp, 0.0.0.0:9602->9600/tcp, :::9602->9600/tcp   os-node-02
2e9c91c959cd   opensearchproject/opensearch:1.3.7              "./opensearch-docker…"   28 seconds ago   Up 27 seconds   9300/tcp, 9650/tcp, 0.0.0.0:9201->9200/tcp, :::9201->9200/tcp, 0.0.0.0:9601->9600/tcp, :::9601->9600/tcp   os-node-01

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

Введите следующую команду, чтобы отобразить журналы для контейнера os-node-01 в терминальном окне:

docker logs -f os-node-01

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

Пример

[INFO ][o.o.s.c.ConfigurationRepository] [os-node-01] Node 'os-node-01' initialized

Нажмите Ctrl+C, чтобы остановить просмотр журналов контейнера и вернуться к командной строке.

Используйте cURL для запроса к OpenSearch REST API. В следующей команде os-node-01 запрашивается, отправляя запрос на порт 9201 хоста, который сопоставлен с портом 9200 на контейнере:

curl -s "https://localhost:9201" -ku admin:<custom-admin-password>

Пример ответа

{
    "name" : "os-node-01",
    "cluster_name" : "opensearch-dev-cluster",
    "cluster_uuid" : "g1MMknuDRuuD9IaaNt56KA",
    "version" : {
        "distribution" : "opensearch",
        "number" : "1.3.7",
        "build_type" : "tar",
        "build_hash" : "db18a0d5a08b669fb900c00d81462e221f4438ee",
        "build_date" : "2022-12-07T22:59:20.186520Z",
        "build_snapshot" : false,
        "lucene_version" : "8.10.1",
        "minimum_wire_compatibility_version" : "6.8.0",
        "minimum_index_compatibility_version" : "6.0.0-beta1"
    },
    "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

Совет: Используйте опцию -s с curl, чтобы скрыть индикатор прогресса и сообщения об ошибках.

Добавление данных и настройка безопасности OpenSearch

Теперь, когда кластер OpenSearch работает, пришло время добавить данные и настроить некоторые параметры безопасности OpenSearch. Данные, которые вы добавите, и настройки, которые вы сконфигурируете, будут проверены снова после завершения обновления версии.

Этот раздел можно разбить на две части:

Индексация данных с помощью REST API
Добавление данных с использованием OpenSearch Dashboards

Индексация данных с помощью REST API

Скачайте файл с образцом сопоставления полей:

wget https://raw.githubusercontent.com/opensearch-project/documentation-website/main/assets/examples/ecommerce-field_mappings.json

Затем скачайте объемные данные, которые вы будете загружать в этот индекс:

wget https://raw.githubusercontent.com/opensearch-project/documentation-website/main/assets/examples/ecommerce.ndjson

Используйте API создания индекса, чтобы создать индекс, используя сопоставления, определенные в ecommerce-field_mappings.json:

curl -H "Content-Type: application/json" \
   -X PUT "https://localhost:9201/ecommerce?pretty" \
   --data-binary "@ecommerce-field_mappings.json" \
   -ku admin:<custom-admin-password>

Пример ответа

{
   "acknowledged" : true,
   "shards_acknowledged" : true,
   "index" : "ecommerce"
}

Используйте Bulk API, чтобы добавить данные в новый индекс ecommerce из ecommerce.ndjson:

curl -H "Content-Type: application/x-ndjson" \
   -X PUT "https://localhost:9201/ecommerce/_bulk?pretty" \
   --data-binary "@ecommerce.ndjson" \
   -ku admin:<custom-admin-password>

Пример ответа (усеченный)

{
   "took": 123,
   "errors": false,
   "items": [
       {
           "index": {
               "_index": "ecommerce",
               "_id": "1",
               "_version": 1,
               "result": "created",
               "status": 201,
               "_shards": {
                   "total": 2,
                   "successful": 1,
                   "failed": 0
               },
               "_seq_no": 0,
               "_primary_term": 1
           }
       },
       ...
   ]
}


5. Запрос поиска также может подтвердить, что данные были успешно проиндексированы. Следующий запрос возвращает количество документов, в которых ключевое слово `customer_first_name` равно `Sonya`:

```bash
curl -H 'Content-Type: application/json' \
   -X GET "https://localhost:9201/ecommerce/_search?pretty=true&filter_path=hits.total" \
   -d'{"query":{"match":{"customer_first_name":"Sonya"}}}' \
   -ku admin:<custom-admin-password>

Пример ответа

{
   "hits" : {
      "total" : {
         "value" : 106,
         "relation" : "eq"
      }
   }
}

Добавление данных с использованием OpenSearch Dashboards

Откройте веб-браузер и перейдите на порт 5601 вашего Docker-хоста (например, https://HOST_ADDRESS:5601). Если OpenSearch Dashboards работает и у вас есть сетевой доступ к хосту из вашего клиентского браузера, вы будете перенаправлены на страницу входа.
- Если веб-браузер выдает ошибку из-за того, что TLS-сертификаты самоподписанные, вам может потребоваться обойти проверки сертификатов в вашем браузере. Обратитесь к документации браузера для получения информации о том, как обойти проверки сертификатов. Общее имя (CN) для каждого сертификата генерируется в соответствии с именами контейнеров и узлов для внутрикластерной связи, поэтому подключение к хосту из браузера все равно приведет к предупреждению “недействительное CN”.
Введите имя пользователя по умолчанию (admin) и пароль (admin).
На главной странице OpenSearch Dashboards выберите Добавить образцы данных.
В разделе Образцы веб-журналов выберите Добавить данные.
- (Необязательно) Выберите Просмотреть данные, чтобы просмотреть [Логи] панель веб-трафика.
Выберите кнопку меню, чтобы открыть панель навигации, затем перейдите в Безопасность > Внутренние пользователи.
Выберите Создать внутреннего пользователя.
Укажите имя пользователя и пароль.
В поле Роль в бэкенде введите admin.
Выберите Создать.

Резервное копирование важных файлов

Всегда создавайте резервные копии перед внесением изменений в ваш кластер, особенно если кластер работает в производственной среде.

В этом разделе вы будете:

Регистрировать репозиторий снимков.
Создавать снимок.
Резервировать настройки безопасности.

Регистрация репозитория снимков

Зарегистрируйте репозиторий, используя том, который был смонтирован с помощью upgrade-demo-cluster.sh:

curl -H 'Content-Type: application/json' \
   -X PUT "https://localhost:9201/_snapshot/snapshot-repo?pretty" \
   -d '{"type":"fs","settings":{"location":"/usr/share/opensearch/snapshots"}}' \
   -ku admin:<custom-admin-password>

Пример ответа

{
   "acknowledged" : true
}

Необязательно: Выполните дополнительную проверку, чтобы убедиться, что репозиторий был успешно создан:

curl -H 'Content-Type: application/json' \
   -X POST "https://localhost:9201/_snapshot/snapshot-repo/_verify?timeout=0s&master_timeout=50s&pretty" \
   -ku admin:<custom-admin-password>

Пример ответа

{
   "nodes" : {
      "UODBXfAlRnueJ67grDxqgw" : {
         "name" : "os-node-03"
      },
      "14I_OyBQQXio8nmk0xsVcQ" : {
         "name" : "os-node-04"
      },
      "tQp3knPRRUqHvFNKpuD2vQ" : {
         "name" : "os-node-02"
      },
      "rPe8D6ssRgO5twIP00wbCQ" : {
         "name" : "os-node-01"
      }
   }
}

Создание снимка

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

Создайте снимок, который включает все индексы и состояние кластера:

curl -H 'Content-Type: application/json' \
   -X PUT "https://localhost:9201/_snapshot/snapshot-repo/cluster-snapshot-v137?wait_for_completion=true&pretty" \
   -ku admin:<custom-admin-password>

Пример ответа

{
   "snapshot" : {
      "snapshot" : "cluster-snapshot-v137",
      "uuid" : "-IYB8QNPShGOTnTtMjBjNg",
      "version_id" : 135248527,
      "version" : "1.3.7",
      "indices" : [
         "opensearch_dashboards_sample_data_logs",
         ".opendistro_security",
         "security-auditlog-2023.02.27",
         ".kibana_1",
         ".kibana_92668751_admin_1",
         "ecommerce",
         "security-auditlog-2023.03.06",
         "security-auditlog-2023.02.28",
         "security-auditlog-2023.03.07"
      ],
      "data_streams" : [ ],
      "include_global_state" : true,
      "state" : "SUCCESS",
      "start_time" : "2023-03-07T18:33:00.656Z",
      "start_time_in_millis" : 1678213980656,
      "end_time" : "2023-03-07T18:33:01.471Z",
      "end_time_in_millis" : 1678213981471,
      "duration_in_millis" : 815,
      "failures" : [ ],
      "shards" : {
         "total" : 9,
         "failed" : 0,
         "successful" : 9
      }
   }
}

Резервное копирование настроек безопасности

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

Изменение YAML-файлов и запуск securityadmin.sh
Выполнение REST API запросов с использованием сертификата администратора
Внесение изменений с помощью OpenSearch Dashboards

Независимо от выбранного метода, OpenSearch Security записывает вашу конфигурацию в специальный системный индекс, называемый .opendistro_security. Этот системный индекс сохраняется в процессе обновления и также сохраняется в созданном вами снимке. Однако восстановление системных индексов требует повышенного доступа, предоставленного сертификатом администратора. Чтобы узнать больше, смотрите разделы Системные индексы и Настройка TLS-сертификатов.

Вы также можете экспортировать настройки безопасности OpenSearch в виде YAML-файлов, запустив securityadmin.sh с опцией -backup на любом из ваших узлов OpenSearch. Эти YAML-файлы могут быть использованы для повторной инициализации индекса .opendistro_security с вашей существующей конфигурацией. Следующие шаги помогут вам сгенерировать эти резервные файлы и скопировать их на ваш хост для хранения:

Откройте интерактивную сессию псевдо-TTY с os-node-01:
```
docker exec -it os-node-01 bash
```
Создайте директорию с именем backups и перейдите в нее:
```
mkdir /usr/share/opensearch/backups && cd /usr/share/opensearch/backups
```

Используйте securityadmin.sh, чтобы создать резервные копии ваших настроек безопасности OpenSearch в /usr/share/opensearch/backups/:

/usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh \
   -backup /usr/share/opensearch/backups \
   -icl \
   -nhnv \
   -cacert /usr/share/opensearch/config/root-ca.pem \
   -cert /usr/share/opensearch/config/admin.pem \
   -key /usr/share/opensearch/config/admin-key.pem

Пример ответа

Security Admin v7
Will connect to localhost:9300 ... done
Connected as CN=A,OU=DOCS,O=OPENSEARCH,L=PORTLAND,ST=OREGON,C=US
OpenSearch Version: 1.3.7
OpenSearch Security Version: 1.3.7.0
Contacting opensearch cluster 'opensearch' and wait for YELLOW clusterstate ...
Clustername: opensearch-dev-cluster
Clusterstate: GREEN
Number of nodes: 4
Number of data nodes: 4
.opendistro_security index already exists, so we do not need to create one.
Will retrieve '/config' into /usr/share/opensearch/backups/config.yml 
   SUCC: Configuration for 'config' stored in /usr/share/opensearch/backups/config.yml
Will retrieve '/roles' into /usr/share/opensearch/backups/roles.yml 
   SUCC: Configuration for 'roles' stored in /usr/share/opensearch/backups/roles.yml
Will retrieve '/rolesmapping' into /usr/share/opensearch/backups/roles_mapping.yml 
   SUCC: Configuration for 'rolesmapping' stored in /usr/share/opensearch/backups/roles_mapping.yml
Will retrieve '/internalusers' into /usr/share/opensearch/backups/internal_users.yml 
   SUCC: Configuration for 'internalusers' stored in /usr/share/opensearch/backups/internal_users.yml
Will retrieve '/actiongroups' into /usr/share/opensearch/backups/action_groups.yml 
   SUCC: Configuration for 'actiongroups' stored in /usr/share/opensearch/backups/action_groups.yml
Will retrieve '/tenants' into /usr/share/opensearch/backups/tenants.yml 
   SUCC: Configuration for 'tenants' stored in /usr/share/opensearch/backups/tenants.yml
Will retrieve '/nodesdn' into /usr/share/opensearch/backups/nodes_dn.yml 
   SUCC: Configuration for 'nodesdn' stored in /usr/share/opensearch/backups/nodes_dn.yml
Will retrieve '/whitelist' into /usr/share/opensearch/backups/whitelist.yml 
   SUCC: Configuration for 'whitelist' stored in /usr/share/opensearch/backups/whitelist.yml
Will retrieve '/audit' into /usr/share/opensearch/backups/audit.yml 
   SUCC: Configuration for 'audit' stored in /usr/share/opensearch/backups/audit.yml

Необязательно: Создайте резервную директорию для TLS-сертификатов и сохраните копии сертификатов. Повторите это для каждого узла, если вы используете уникальные TLS-сертификаты: Создайте директорию для сертификатов и скопируйте сертификаты в нее:
```
mkdir /usr/share/opensearch/backups/certs && cp /usr/share/opensearch/config/*pem /usr/share/opensearch/backups/certs/
```
Завершите сессию псевдо-TTY:
```
exit
```

Скопируйте файлы на ваш хост:

docker cp os-node-01:/usr/share/opensearch/backups ~/deploy/

Выполнение обновления

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

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

Отключите репликацию шардов, чтобы остановить перемещение сегментов индекса Lucene внутри вашего кластера:

curl -H 'Content-type: application/json' \
   -X PUT "https://localhost:9201/_cluster/settings?pretty" \
   -d'{"persistent":{"cluster.routing.allocation.enable":"primaries"}}' \
   -ku admin:<custom-admin-password>

Пример ответа

{
   "acknowledged" : true,
   "persistent" : {
      "cluster" : {
         "routing" : {
            "allocation" : {
               "enable" : "primaries"
            }
         }
      }
   },
   "transient" : { }
}

Выполните операцию сброса на кластере, чтобы зафиксировать записи журнала транзакций в индексе Lucene:

curl -X POST "https://localhost:9201/_flush?pretty" -ku admin:<custom-admin-password>

Пример ответа

{
   "_shards" : {
      "total" : 20,
      "successful" : 20,
      "failed" : 0
   }
}

Вы можете обновлять узлы в любом порядке, так как все узлы в этом демонстрационном кластере являются подходящими менеджерами кластера. Следующая команда остановит и удалит контейнер os-node-01, не удаляя смонтированный том данных:

docker stop os-node-01 && docker container rm os-node-01

Запустите новый контейнер с именем os-node-01 с образом opensearchproject/opensearch:2.5.0 и используя те же смонтированные тома, что и у оригинального контейнера:

docker run -d \
   -p 9201:9200 -p 9601:9600 \
   -e "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" \
   --ulimit nofile=65536:65536 --ulimit memlock=-1:-1 \
   -v data-01:/usr/share/opensearch/data \
   -v repo-01:/usr/share/opensearch/snapshots \
   -v ~/deploy/opensearch-01.yml:/usr/share/opensearch/config/opensearch.yml \
   -v ~/deploy/root-ca.pem:/usr/share/opensearch/config/root-ca.pem \
   -v ~/deploy/admin.pem:/usr/share/opensearch/config/admin.pem \
   -v ~/deploy/admin-key.pem:/usr/share/opensearch/config/admin-key.pem \
   -v ~/deploy/os-node-01.pem:/usr/share/opensearch/config/os-node-01.pem \
   -v ~/deploy/os-node-01-key.pem:/usr/share/opensearch/config/os-node-01-key.pem \
   --network opensearch-dev-net \
   --ip 172.20.0.11 \
   --name os-node-01 \
   opensearchproject/opensearch:2.5.0

Пример ответа

d26d0cb2e1e93e9c01bb00f19307525ef89c3c3e306d75913860e6542f729ea4

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

curl -s "https://localhost:9201/_cat/nodes?v&h=name,version,node.role,master" \
   -ku admin:<custom-admin-password> | column -t

Пример ответа

name        version  node.role  master
os-node-01  2.5.0    dimr       -
os-node-04  1.3.7    dimr       *
os-node-02  1.3.7    dimr       -
os-node-03  1.3.7    dimr       -

Опционально: Запросите кластер, чтобы увидеть, как изменяется распределение шардов по мере удаления и замены узлов. Вы можете выполнить эту команду в любое время в процессе, чтобы увидеть, как изменяются статусы шардов:

curl -s "https://localhost:9201/_cat/shards" \
   -ku admin:<custom-admin-password>

Пример ответа

security-auditlog-2023.03.06           0 p STARTED       53 214.5kb 172.20.0.13 os-node-03
security-auditlog-2023.03.06           0 r UNASSIGNED                           
.kibana_1                              0 p STARTED        3  14.5kb 172.20.0.12 os-node-02
.kibana_1                              0 r STARTED        3  14.5kb 172.20.0.13 os-node-03
ecommerce                              0 p STARTED     4675   3.9mb 172.20.0.12 os-node-02
ecommerce                              0 r STARTED     4675   3.9mb 172.20.0.14 os-node-04
security-auditlog-2023.03.07           0 p STARTED       37 175.7kb 172.20.0.14 os-node-04
security-auditlog-2023.03.07           0 r UNASSIGNED                           
.opendistro_security                   0 p STARTED       10  67.9kb 172.20.0.12 os-node-02
.opendistro_security                   0 r STARTED       10  67.9kb 172.20.0.13 os-node-03
.opendistro_security                   0 r STARTED       10  64.5kb 172.20.0.14 os-node-04
.opendistro_security                   0 r UNASSIGNED                           
security-auditlog-2023.02.27           0 p STARTED        4  80.5kb 172.20.0.12 os-node-02
security-auditlog-2023.02.27           0 r UNASSIGNED                           
security-auditlog-2023.02.28           0 p STARTED        6 104.1kb 172.20.0.14 os-node-04
security-auditlog-2023.02.28           0 r UNASSIGNED                           
opensearch_dashboards_sample_data_logs 0 p STARTED    14074   9.1mb 172.20.0.12 os-node-02
opensearch_dashboards_sample_data_logs 0 r STARTED    14074   8.9mb 172.20.0.13 os-node-03
.kibana_92668751_admin_1               0 r STARTED       33  37.3kb 172.20.0.13 os-node-03
.kibana_92668751_admin_1               0 p STARTED       33  37.3kb 172.20.0.14 os-node-04

Остановите os-node-02:

docker stop os-node-02 && docker container rm os-node-02

Запустите новый контейнер с именем os-node-02 с образом opensearchproject/opensearch:2.5.0 и используя те же смонтированные тома, что и у оригинального контейнера:

docker run -d \
   -p 9202:9200 -p 9602:9600 \
   -e "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" \
   --ulimit nofile=65536:65536 --ulimit memlock=-1:-1 \
   -v data-02:/usr/share/opensearch/data \
   -v repo-01:/usr/share/opensearch/snapshots \
   -v ~/deploy/opensearch-02.yml:/usr/share/opensearch/config/opensearch.yml \
   -v ~/deploy/root-ca.pem:/usr/share/opensearch/config/root-ca.pem \
   -v ~/deploy/admin.pem:/usr/share/opensearch/config/admin.pem \
   -v ~/deploy/admin-key.pem:/usr/share/opensearch/config/admin-key.pem \
   -v ~/deploy/os-node-02.pem:/usr/share/opensearch/config/os-node-02.pem \
   -v ~/deploy/os-node-02-key.pem:/usr/share/opensearch/config/os-node-02-key.pem \
   --network opensearch-dev-net \
   --ip 172.20.0.12 \
   --name os-node-02 \
   opensearchproject/opensearch:2.5.0

Пример ответа

7b802865bd6eb420a106406a54fc388ed8e5e04f6cbd908c2a214ea5ce72ac00

Остановите os-node-03:

docker stop os-node-03 && docker container rm os-node-03

Запустите новый контейнер с именем os-node-03 с образом opensearchproject/opensearch:2.5.0 и используя те же смонтированные тома, что и у оригинального контейнера:

docker run -d \
   -p 9203:9200 -p 9603:9600 \
   -e "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" \
   --ulimit nofile=65536:65536 --ulimit memlock=-1:-1 \
   -v data-03:/usr/share/opensearch/data \
   -v repo-01:/usr/share/opensearch/snapshots \
   -v ~/deploy/opensearch-03.yml:/usr/share/opensearch/config/opensearch.yml \
   -v ~/deploy/root-ca.pem:/usr/share/opensearch/config/root-ca.pem \
   -v ~/deploy/admin.pem:/usr/share/opensearch/config/admin.pem \
   -v ~/deploy/admin-key.pem:/usr/share/opensearch/config/admin-key.pem \
   -v ~/deploy/os-node-03.pem:/usr/share/opensearch/config/os-node-03.pem \
   -v ~/deploy/os-node-03-key.pem:/usr/share/opensearch/config/os-node-03-key.pem \
   --network opensearch-dev-net \
   --ip 172.20.0.13 \
   --name os-node-03 \
   opensearchproject/opensearch:2.5.0

Пример ответа

d7f11726841a89eb88ff57a8cbecab392399f661a5205f0c81b60a995fc6c99d

Остановите os-node-04:

docker stop os-node-04 && docker container rm os-node-04

Запустите новый контейнер с именем os-node-04 с образом opensearchproject/opensearch:2.5.0 и используя те же смонтированные тома, что и у оригинального контейнера:

docker run -d \
   -p 9204:9200 -p 9604:9600 \
   -e "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" \
   --ulimit nofile=65536:65536 --ulimit memlock=-1:-1 \
   -v data-04:/usr/share/opensearch/data \
   -v repo-01:/usr/share/opensearch/snapshots \
   -v ~/deploy/opensearch-04.yml:/usr/share/opensearch/config/opensearch.yml \
   -v ~/deploy/root-ca.pem:/usr/share/opensearch/config/root-ca.pem \
   -v ~/deploy/admin.pem:/usr/share/opensearch/config/admin.pem \
   -v ~/deploy/admin-key.pem:/usr/share/opensearch/config/admin-key.pem \
   -v ~/deploy/os-node-04.pem:/usr/share/opensearch/config/os-node-04.pem \
   -v ~/deploy/os-node-04-key.pem:/usr/share/opensearch/config/os-node-04-key.pem \
   --network opensearch-dev-net \
   --ip 172.20.0.14 \
   --name os-node-04 \
   opensearchproject/opensearch:2.5.0

Пример ответа

26f8286ab11e6f8dcdf6a83c95f265172f9557578a1b292af84c6f5ef8738e1d

Подтвердите, что ваш кластер работает на новой версии:

curl -s "https://localhost:9201/_cat/nodes?v&h=name,version,node.role,master" \
   -ku admin:<custom-admin-password> | column -t

Пример ответа

name        version  node.role  master
os-node-01  2.5.0    dimr       *
os-node-02  2.5.0    dimr       -
os-node-04  2.5.0    dimr       -
os-node-03  2.5.0    dimr       -

Последний компонент, который вы должны обновить, это узел OpenSearch Dashboards. Сначала остановите и удалите старый контейнер:

docker stop os-dashboards-01 && docker rm os-dashboards-01

Создайте новый контейнер, работающий на целевой версии OpenSearch Dashboards:

docker run -d \
   -p 5601:5601 --expose 5601 \
   -v ~/deploy/opensearch_dashboards.yml:/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml \
   -v ~/deploy/root-ca.pem:/usr/share/opensearch-dashboards/config/root-ca.pem \
   -v ~/deploy/os-dashboards-01.pem:/usr/share/opensearch-dashboards/config/os-dashboards-01.pem \
   -v ~/deploy/os-dashboards-01-key.pem:/usr/share/opensearch-dashboards/config/os-dashboards-01-key.pem \
   --network opensearch-dev-net \
   --ip 172.20.0.10 \
   --name os-dashboards-01 \
   opensearchproject/opensearch-dashboards:2.5.0

Пример ответа

310de7a24cf599ca0b39b241db07fa8865592ebe15b6f5fda26ad19d8e1c1e09

Убедитесь, что контейнер OpenSearch Dashboards запустился правильно. Команда, подобная следующей, может быть использована для подтверждения того, что запросы к https://HOST_ADDRESS:5601 перенаправляются (HTTP статус код 302) на /app/login?:

curl https://localhost:5601 -kI

Пример ответа

HTTP/1.1 302 Found
location: /app/login?
osd-name: opensearch-dashboards-dev
cache-control: private, no-cache, no-store, must-revalidate
set-cookie: security_authentication=; Max-Age=0; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure; HttpOnly; Path=/
content-length: 0
Date: Wed, 08 Mar 2023 15:36:53 GMT
Connection: keep-alive
Keep-Alive: timeout=120

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

curl -H 'Content-type: application/json' \
   -X PUT "https://localhost:9201/_cluster/settings?pretty" \
   -d'{"persistent":{"cluster.routing.allocation.enable":"all"}}' \
   -ku admin:<custom-admin-password>

Пример ответа

{
   "acknowledged" : true,
   "persistent" : {
      "cluster" : {
         "routing" : {
            "allocation" : {
               "enable" : "all"
            }
         }
      }
   },
   "transient" : { }
}

Проверка обновления

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

Для этого кластера шаги по проверке после обновления могут включать в себя проверку следующего:

Запущенная версия
Здоровье и распределение шардов
Согласованность данных

Проверка текущей запущенной версии ваших узлов OpenSearch:

curl -s "https://localhost:9201/_cat/nodes?v&h=name,version,node.role,master" \
   -ku admin:<custom-admin-password> | column -t

Пример ответа

name        version  node.role  master
os-node-01  2.5.0    dimr       *
os-node-02  2.5.0    dimr       -
os-node-04  2.5.0    dimr       -
os-node-03  2.5.0    dimr       -

Проверка текущей запущенной версии OpenSearch Dashboards:

Вариант 1: Проверьте версию OpenSearch Dashboards через веб-интерфейс.

Откройте веб-браузер и перейдите на порт 5601 вашего Docker-хоста (например, https://HOST_ADDRESS:5601).
Войдите с использованием имени пользователя по умолчанию (admin) и пароля по умолчанию (admin).
Нажмите кнопку “Справка” в правом верхнем углу. Версия отображается в всплывающем окне.
Снова нажмите кнопку “Справка”, чтобы закрыть всплывающее окно.

Вариант 2: Проверьте версию OpenSearch Dashboards, проверив файл manifest.yml.

Из командной строки откройте интерактивную сессию псевдо-TTY с контейнером OpenSearch Dashboards:

docker exec -it os-dashboards-01 bash

Проверьте файл manifest.yml на наличие версии:

head -n 5 manifest.yml

Пример ответа

---
schema-version: '1.1'
build:
   name: OpenSearch Dashboards
   version: 2.5.0

Завершите сессию псевдо-TTY:

exit

Проверка состояния кластера и распределения шардов

Запросите API-эндпоинт состояния кластера, чтобы увидеть информацию о здоровье вашего кластера. Вы должны увидеть статус “green”, что указывает на то, что все первичные и репликатные шарды распределены:

curl -s "https://localhost:9201/_cluster/health?pretty" -ku admin:<custom-admin-password>

Пример ответа

{
   "cluster_name" : "opensearch-dev-cluster",
   "status" : "green",
   "timed_out" : false,
   "number_of_nodes" : 4,
   "number_of_data_nodes" : 4,
   "discovered_master" : true,
   "discovered_cluster_manager" : true,
   "active_primary_shards" : 16,
   "active_shards" : 36,
   "relocating_shards" : 0,
   "initializing_shards" : 0,
   "unassigned_shards" : 0,
   "delayed_unassigned_shards" : 0,
   "number_of_pending_tasks" : 0,
   "number_of_in_flight_fetch" : 0,
   "task_max_waiting_in_queue_millis" : 0,
   "active_shards_percent_as_number" : 100.0
}

Запросите API-эндпоинт CAT shards, чтобы увидеть, как шардов распределены после обновления кластера:

curl -s "https://localhost:9201/_cat/shards" -ku admin:<custom-admin-password>

Пример ответа

security-auditlog-2023.02.27           0 r STARTED     4  80.5kb 172.20.0.13 os-node-03
security-auditlog-2023.02.27           0 p STARTED     4  80.5kb 172.20.0.11 os-node-01
security-auditlog-2023.03.08           0 p STARTED    30  95.2kb 172.20.0.13 os-node-03
security-auditlog-2023.03.08           0 r STARTED    30 123.8kb 172.20.0.11 os-node-01
ecommerce                              0 p STARTED  4675   3.9mb 172.20.0.12 os-node-02
ecommerce                              0 r STARTED  4675   3.9mb 172.20.0.13 os-node-03
.kibana_1                              0 p STARTED     3   5.9kb 172.20.0.12 os-node-02
.kibana_1                              0 r STARTED     3   5.9kb 172.20.0.11 os-node-01
.kibana_92668751_admin_1               0 p STARTED    33  37.3kb 172.20.0.13 os-node-03
.kibana_92668751_admin_1               0 r STARTED    33  37.3kb 172.20.0.11 os-node-01
opensearch_dashboards_sample_data_logs 0 p STARTED 14074   9.1mb 172.20.0.12 os-node-02
opensearch_dashboards_sample_data_logs 0 r STARTED 14074   9.1mb 172.20.0.14 os-node-04
security-auditlog-2023.02.28           0 p STARTED     6  26.2kb 172.20.0.11 os-node-01
security-auditlog-2023.02.28           0 r STARTED     6  26.2kb 172.20.0.14 os-node-04
.opendistro-reports-definitions        0 p STARTED     0    208b 172.20.0.12 os-node-02
.opendistro-reports-definitions        0 r STARTED     0    208b 172.20.0.13 os-node-03
.opendistro-reports-definitions        0 r STARTED     0    208b 172.20.0.14 os-node-04
security-auditlog-2023.03.06           0 r STARTED    53 174.6kb 172.20.0.12 os-node-02
security-auditlog-2023.03.06           0 p STARTED    53 174.6kb 172.20.0.14 os-node-04
.kibana_101107607_newuser_1            0 r STARTED     1   5.1kb 172.20.0.13 os-node-03
.kibana_101107607_newuser_1            0 p STARTED     1   5.1kb 172.20.0.11 os-node-01
.opendistro_security                   0 r STARTED    10  64.5kb 172.20.0.12 os-node-02
.opendistro_security                   0 r STARTED    10  64.5kb 172.20.0.13 os-node-03
.opendistro_security                   0 r STARTED    10  64.5kb 172.20.0.11 os-node-01
.opendistro_security                   0 p STARTED    10  64.5kb 172.20.0.14 os-node-04
.kibana_-152937574_admintenant_1       0 r STARTED     1   5.1kb 172.20.0.12 os-node-02
.kibana_-152937574_admintenant_1       0 p STARTED     1   5.1kb 172.20.0.14 os-node-04
security-auditlog-2023.03.07           0 r STARTED    37 175.7kb 172.20.0.12 os-node-02
security-auditlog-2023.03.07           0 p STARTED    37 175.7kb 172.20.0.14 os-node-04
.kibana_92668751_admin_2               0 p STARTED    34  38.6kb 172.20.0.13 os-node-03
.kibana_92668751_admin_2               0 r STARTED    34  38.6kb 172.20.0.11 os-node-01
.kibana_2                              0 p STARTED     3     6kb 172.20.0.13 os-node-03
.kibana_2                              0 r STARTED     3     6kb 172.20.0.14 os-node-04
.opendistro-reports-instances          0 r STARTED     0    208b 172.20.0.12 os-node-02
.opendistro-reports-instances          0 r STARTED     0    208b 172.20.0.11 os-node-01
.opendistro-reports-instances          0 p STARTED     0    208b 172.20.0.14 os-node-04

Проверка согласованности данных

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

Сравните ответ на этот запрос с ответом, который вы получили на последнем шаге индексации данных с помощью REST API:

curl -H 'Content-Type: application/json' \
   -X GET "https://localhost:9201/ecommerce/_search?pretty=true&filter_path=hits.total" \
   -d'{"query":{"match":{"customer_first_name":"Sonya"}}}' \
   -ku admin:<custom-admin-password>

Пример ответа

{
   "hits" : {
      "total" : {
         "value" : 106,
         "relation" : "eq"
      }
   }
}

Откройте веб-браузер и перейдите на порт 5601 вашего Docker-хоста (например, https://HOST_ADDRESS:5601).
Введите имя пользователя по умолчанию (admin) и пароль (admin).
На главной странице OpenSearch Dashboards выберите кнопку Меню в верхнем левом углу веб-интерфейса, чтобы открыть панель навигации.
Выберите “Панель управления”.
Выберите [Logs] Web Traffic, чтобы открыть панель управления, созданную при добавлении образцов данных ранее в процессе.
Когда вы закончите просмотр панели управления, выберите кнопку Профиль. Выберите “Выйти”, чтобы войти как другой пользователь.
Введите имя пользователя и пароль, которые вы создали перед обновлением, затем выберите “Войти”.