Обновление распределенных систем, в том числе Elasticsearch, может быть сложным процессом из-за большого объема данных, количества задействованных узлов и различных конфигураций, которые могут присутствовать в кластере. В этой статье мы расскажем, как минимизировать риски при обновлении кластера Elasticsearch.
Существует два подхода к обновлению версий службы Elasticsearch: полный перезапуск кластера и скользящий перезапуск. В оставшейся части статьи мы рассмотрим каждый из них по отдельности.
Всегда помните, что любые изменения в вашей системе могут привести к потере данных, если вы не будете правильно следовать инструкциям. Всегда тщательно тестируйте и планируйте обновление, а также делайте резервные копии данных перед выполнением любых обновлений.
Мы начнем с обзора важных моментов, но в любой момент можно перейти к инструкциям по обновлению с полным перезапуском кластера и обновлению со скользящим перезапуском.
Даты окончания срока службы продуктов Elastic (EOL - End Of Life)
Каждая версия Elasticsearch имеет свой срок окончания жизни, и Elasticsearch прямо указывает, что каждая основная версия (релиз) продуктов поддерживается в течение 18 месяцев после выпуска.
Версия Elasticsearch & Kibana & Logstash & Beat | EOL |
5.0.x | 26.04.2018 |
6.0.x | 14.05.2019 |
7.0.x | 10.10.2020 |
7.10.x | 11.05.2022 |
7.11.x | 10.08.2022 |
7.12.x | 23.09.2022 |
7.13.x | 25.11.2022 |
7.14.x | 03.02.2023 |
7.15.x | 22.03.2023 |
7.16.x | 07.06.2023 |
7.17.x | 01.08.2023 |
8.0.x | 10.08.2023 |
В общем случае рекомендуется всегда обновлять версию до максимально возможной, при условии совместимости / доступности используемых клиентских библиотек или плагинов. Кроме того, обратите внимание, что теперь не существует дат выхода минорных версий. Они просто заявляют, что релиз 8.x будет поддерживаться до "более позднего из 2024-08-10 или 6 месяцев после даты выпуска 9.0".
Матрица совместимости
Обновление с версии | Обновление до версии | Обновление до версии | Необходима полная модернизация кластера | необходимое обновление Версия JDK | Поддерживается ассистент обновления Kibana |
Elasticsearch версии 5.6.16 | Elasticsearch версии 6.8.23 | ✅ | ❌ | ❌ | ❌ |
Elasticsearch версии 6.8.23 | Elasticsearch версии 7.17.x | ✅ | ❌ | ❌ | ✅ |
Elasticsearch версии 7.17.x | Elasticsearch версии 8.7.1 | ✅ | ❌ | ✅ | ✅ |
Elasticsearch версии 7.17 - последняя версия, работающая с JDK 1.8.
Мастер-узлы или не мастер-узлы? Что следует обновить в первую очередь?
Прежде чем приступить к обновлению, необходимо разделить кластер на:
- Узлы с правом доступа к мастеру
- Узлы с правом доступа к мастеру
Причина такого деления заключается в том, что узлы Elasticsearch более высокой версии, имеющие право на обновление, всегда могут присоединиться к кластеру с узлом-мастером более низкой версии, а узлы более низкой версии, имеющие право на обновление, не могут присоединиться к кластеру более высокой версии.
Это означает, что если обновить узлы с правами мастера раньше узлов с правами мастера, то существует вероятность того, что некоторые узлы с правами мастера выйдут из кластера и не смогут к нему присоединиться. По этой причине необходимо сначала обновить все узлы, не имеющие права доступа к мастеру.
Узлы, соответствующие требованиям старого мастера | Новый узел с правом доступа к мастеру | |
Старые узлы, отвечающие требованиям мастера | ✅ | ❌ |
Новые узлы с правом доступа к мастеру | ✅ | ✅ |
Подготовка к обновлению узлов Elasticsearch
После обновления узлы Elasticsearch не могут быть переведены на новый уровень. Перед началом процесса обновления необходимо ознакомиться со следующим:
Проверьте журнал учета замечаний
Необходимо прочитать и устранить все проблемы, отмеченные в журнале устаревания. Эти журналы обычно располагаются в:
1 | /var/log/elasticsearch/Your-Cluster-Name_deprecation.log. |
Помощник обновления в Kibana
В последней минорной версии каждой мажорной версии, например 6.8.23 или 7.17.10, вы найдете помощника по обновлению, который поможет вам убедиться, что ваши настройки и конфигурации кластера совместимы со следующей версией. Для перехода к помощнику используйте меню в Kibana. Перед переходом на следующую версию необходимо устранить все проблемы с помощью помощника.
Ознакомьтесь с изменениями
С каждой новой версией публикуется документация об изменениях, чтобы вы знали о функциональности, которая может измениться или исчезнуть. Необходимо всегда проверять эту документацию, чтобы убедиться, что ни один из этих параметров, конфигураций или маппингов не используется в вашей системе. Основными элементами, которые могут быть затронуты, являются:
- Конфигурация узла (elasticsearch.yml)
- Маппинги и шаблоны индексов
- Настройки кластера
Проверка совместимости плагинов Elasticsearch
Если вы используете какие-либо подключаемые модули Elasticsearch, необходимо проверить доступность и совместимость модуля с новой версией.
Настройте тестовую среду
Перед обновлением рабочего кластера необходимо протестировать процесс обновления в тестовой или промежуточной среде, чтобы проверить и устранить все проблемы до обновления рабочего кластера.
Сделайте резервную копию и моментальные снимки данных
Помните, что понизить версию узла Elasticsearch невозможно, и единственным способом практически отменить неудачное обновление будет создание нового кластера со старой версией и восстановление данных из моментальных снимков. Поэтому перед началом процесса обновления необходимо сделать моментальные снимки всех индексов Elasticsearch.
Полное обновление с перезапуском кластера (автономное обновление)
Полное обновление с перезапуском кластера заключается в одновременном отключении всех узлов Elasticsearch, обновлении всех узлов и последующем перезапуске каждого узла. Этот тип обновления неизбежно потребует отключения кластера Elasticsearch на время процесса обновления.
Автономное обновление обычно проще, чем онлайн, поскольку не нужно одновременно управлять кластером с различными версиями узлов.
Процесс обновления состоит из следующих шагов:
- Отключить размещение шардов
- Опционально остановить несущественное индексирование и выполнить "промывку"
- Опционально остановить задачи, связанные с заданиями ML и потоками данных
- Остановите все узлы Elasticsearch и обновите их
- Обновите все подключаемые модули
- Запустите кластер Elasticsearch
- Повторное включение распределения шардов
- Обновление клиентских библиотек до новой версии
- Перезапустить узлы, отвечающие требованиям мастера
- Перезапустить узлы, отвечающие требованиям мастера
- Опционально перезапустить задачи, связанные с заданиями ML и потоками данных.
Обратите внимание, что при полном перезапуске кластера ведущие узлы должны быть запущены раньше не ведущих узлов. Это необходимо для того, чтобы главные узлы могли сформировать кластер и дать возможность другим узлам присоединиться к нему, и отличается от скользящего перезапуска, при котором узлы, не имеющие права доступа к мастеру, должны быть обновлены до узлов, имеющих право доступа к мастеру.
Обновление при скользящем перезапуске (обновление в режиме онлайн)
Обновление при скользящем перезапуске позволяет обновить кластер без простоев. В этом случае каждый узел обновляется и перезапускается по очереди без остановки всего кластера Elasticsearch.
Невозможно выполнить обновление с помощью скользящего перезапуска, связанное с изменением основных версий, за исключением следующих случаев:
- Обновление Elasticsearch версии 5.6.16 до версии 6.x.x
- Обновление Elasticsearch версии 6.8.23 до версии 7.x.x
- Обновление Elasticsearch версии 7.17.10 до версии 8.x.x
По этой причине, если вы хотите выполнить скользящее обновление между основными версиями, вы ВСЕГДА должны использовать последнюю минорную версию в качестве ступеньки для обновления до следующей основной версии. Например, если вы используете Elasticsearch 5.x.x, вы можете обновить его до версии 5.6.16, а затем до версии 6.8.23.
Правильный порядок модернизации узлов
Начните с обновления узлов, не имеющих права на использование мастера. Чтобы найти такие узлы, воспользуйтесь API-вызовом GET /_nodes/_all,master:false/_none или найдите узлы, сконфигурированные с параметром node.master: false.
- Выполните обновление на каждом уровне, начиная с "замороженного" уровня. Завершите обновление всех узлов каждого яруса данных, прежде чем переходить к следующему. Сначала обновите замороженный уровень, затем холодный, теплый и, наконец, горячий. Это гарантирует, что во время обновления данные по-прежнему будут проходить через все уровни.
- Чтобы получить список узлов определенного уровня, используйте запрос GET /_nodes. Например, GET /_nodes/data_frozen:true/_none.
- Наконец, обновите узлы, отвечающие требованиям мастера. Получите список этих узлов с помощью запроса GET /_nodes/master:true.
Соблюдение этого порядка гарантирует, что все узлы смогут присоединиться к кластеру в процессе обновления. Обновленные узлы могут присоединиться к кластеру со старым мастером, но старые узлы могут не присоединиться к кластеру с обновленным мастером.
Как обновлять узлы при скользящем обновлении
Процесс обновления узлов выглядит следующим образом: сначала обновляются все узлы NON, соответствующие требованиям мастера.
Убедитесь, что ваш кластер стабилен.
Необходимо убедиться, что все реплики доступны, чтобы отключение узла не привело к потере данных.
Отключите ненужное индексирование
Там, где это практически возможно, следует остановить все процессы индексирования, поскольку это повысит устойчивость кластера.
Опционально остановите задачи, связанные с заданиями ML и datafeeds
Несмотря на то что в процессе обновления можно оставить запущенными задания машинного обучения, это приведет к излишней нагрузке на кластер.
Отключите распределение шардов
Важно остановить ребалансировку шардов, чтобы при остановке узла для обновления кластер не перераспределял шарды на другой узел. (См. команду ниже).
Остановка узла Elasticsearch
Остановите узел Elasticsearch, прежде чем переходить к следующему шагу
Обновление Elasticsearch
Метод, используемый для обновления, зависит от метода установки, использованного при инсталляции.
Обновление подключаемых модулей
Elasticsearch не запустится, если подключаемый модуль не имеет той же версии, что и Elasticsearch.
Запуск Elasticsearch
Запустите Elasticsearch, прежде чем переходить к следующему шагу.
Повторное включение распределения шардов
Используйте команду, приведенную ниже.
Проверьте, что обновленный узел вернулся в кластер.
С помощью приведенной ниже команды можно проверить, сколько узлов находится в кластере.
Дождитесь, пока статус кластера станет зеленым
Команда, представленная ниже, также покажет прогресс процесса восстановления шардов на обновленном узле, пока кластер не перейдет в зеленое состояние.
Не спешите обновлять узлы, дождитесь полного восстановления кластера, прежде чем двигаться дальше. Если кластер не переходит в "зеленое" состояние, посмотрите в журналах, чтобы найти какие-либо проблемы, которые могут указывать на проблемы с обновлением или конфигурацией.
Повторите
Повторите весь описанный выше процесс для каждого узла.
По желанию перезапустите задания ML и потоки данных.
Примечание
Чтобы отключить выделение шардов, выполните команду:
1 2 3 4 5 6 | PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "primaries" } } |
Чтобы снова включить выделение шардов, выполните команду:
1 2 3 4 5 6 | PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": null } } |
Получите статус кластера и узнайте, сколько узлов находится в кластере:
1 | GET _cluster/health |