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

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

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

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

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

Ознакомьтесь с разделом “Обновление 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 пошагового обновления — снова без шага обновления)

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