Elasticsearch 5.6: готовимся к rolling upgrade на 6.0 через Upgrade Assistant

Elastic выпустил Elasticsearch 5.6 и сразу дал понять что это финальная точка ветки 5.x. Главная особенность релиза не в новых фичах - их немного. Главное: 5.6 это единственная версия 5.x, из которой поддерживается rolling upgrade до 6.0. То есть если вы планируете перейти на 6.x без полного рестарта кластера - сначала надо быть на 5.6.

Для наших managed-проектов это означает, что пришло время разобраться с планом миграции. Elastic Stack 6.0 уже в RC, GA ожидается совсем скоро. Мы начали подготовку.

Rolling upgrade: что это означает практически

Rolling upgrade позволяет обновить кластер узел за узлом, не выключая его целиком. Это не какая-то магия - механика простая: отключаешь шардовую аллокацию, останавливаешь один узел, обновляешь, запускаешь, ждёшь пока кластер перейдёт в green, повторяешь для следующего.

Для кластера из трёх-пяти узлов это означает что весь апгрейд проходит без окна простоя. Данные всё время доступны - просто на части узлов стоит 5.6, на другой части уже 6.0, пока идёт обновление. Elasticsearch специально поддерживает совместимость узлов разных версий в этом смежном окне.

Альтернатива - full cluster restart. Останавливаешь всё, обновляешь, поднимаешь. Простой гарантирован. Для небольших кластеров иногда проще, для продакшн с требованиями к доступности - хуже.

Чтобы rolling upgrade до 6.0 работал, нужно быть именно на 5.6. С 5.5 и ниже - только full restart. Вот почему этот минорный релиз важен как промежуточная точка.

Upgrade Assistant: это не формальность

Вместе с 5.6 в Kibana появился Upgrade Assistant - инструмент предполётной проверки. Мы его запустили на нескольких кластерах и получили список проблем, который оказался содержательнее чем ожидали.

Суть работы Upgrade Assistant: он проходит по индексам и настройкам кластера, проверяет всё что в 6.0 изменилось или удалено, и выдаёт список с критичностью проблем. Часть находок - просто предупреждения, часть - блокеры, без устранения которых 6.0 не взлетит корректно.

Что он нашёл у нас - по порядку.

Первое - multiple types в индексах. Это главная неприятность. В Elasticsearch 6.0 каждый индекс может иметь только один тип документов. В 5.x ограничения не было: один индекс - несколько типов, что исторически использовалось для группировки связанных данных. Upgrade Assistant нашёл несколько индексов где два и более типа сосуществуют.

Это именно тот случай, когда одно изменение в архитектуре Elasticsearch требует работы с данными до обновления, а не после.

Второе - устаревшие настройки в конфигах. Ряд параметров в elasticsearch.yml переименован или удалён в 6.0. Если оставить их как есть - Elasticsearch 6.0 откажется стартовать. Upgrade Assistant выдаёт конкретный список с заменами.

Третье - индексы, созданные на ES 2.x. Если у вас в кластере живут индексы, которые были созданы ещё на версии 2.x (и попали в 5.x через snapshot/restore или апгрейд кластера без reindex), то 6.0 их не откроет. Elasticsearch 6.0 понимает только данные в формате 5.x. Такие индексы нужно либо reindex-нуть, либо закрыть/удалить.

Что делать с multiple types

Это самая трудоёмкая часть. Логика простая: если индекс logs-app содержит типы nginx и application - перед миграцией на 6.0 их нужно разнести в отдельные индексы logs-app-nginx и logs-app-application, либо объединить в один тип с разделением через поле log_type.

У нас несколько таких индексов возникли исторически - в период когда мы только строили ELK и разбирались с маппингами. Паттерн «один индекс, несколько типов» казался удобным способом группировки. В 5.x это работало, в 6.0 - не будет.

План для каждого проблемного индекса:

• Если типы логически независимы - Reindex API в два отдельных индекса. Logstash pipeline переключить на новые имена. Старый индекс закрыть, потом удалить.
• Если типы связаны и их осмысленно объединить - Reindex в один индекс с единым типом и добавленным полем-дискриминатором. Обновить запросы в Kibana.
• Если индекс исторический и данные уже неактуальны - просто удалить, не тратить время.

Для нас осмысленных кейсов с несколькими типами оказалось два. Остальные - исторические артефакты, которые давно пора было убирать.

Что делаем дальше

Полная картина миграции сложнее чем просто обновление ES. Logstash 6.0 и Kibana 6.0 тоже выйдут одновременно, и там свои изменения - в первую очередь в конфигурации Logstash.

Текущий статус: 5.6 развёрнут в тестовой среде, Upgrade Assistant прошёл, список проблем есть. На продакшн обновление на 5.6 планируем на этой неделе. Работу с multiple types - параллельно. Сам переход на 6.0 - после GA-релиза и осмысления его changelog.

Upgrade Assistant в Kibana оказался полезнее чем казалось. Лучше знать список проблем за несколько недель до обновления, чем обнаружить их в ночь апгрейда.