В CSS вы можете обновить версию кластера Elasticsearch, чтобы использовать новые функции и улучшения производительности или исправить известные проблемы.
Тип обновления | Сценарий | Процесс обновления |
|---|---|---|
Обновление той же версии | Обновите патчи ядра кластера. Кластер обновляется до последнего образа текущей версии для исправления известных проблем или оптимизации производительности. Например, если текущая версия кластера 7.10.2(7.10.2_24.3.3_0102), при обновлении той же версии кластер будет обновлен до последнего образа 7.10.2(7.10.2_24.3.4_0109) версии 7.10.2. (Номера версий, использованные здесь, являются лишь примерами.) |
Узлы в кластерах обновляются по одному, чтобы не прерывать сервисы. |
Обновление между версиями | Обновите кластер до последнего образа целевой версии, чтобы расширить функциональность или включить версии. Например, если текущая версия кластера 7.6.2(7.6.2_24.3.3_1224), при обновлении между версиями кластер будет обновлен до последнего образа 7.10.2(7.10.2_24.3.4_0109) версии 7.10.2. (Номера версий, используемые здесь, являются примером.) | |
Обновление между движками | Обновите кластер Elasticsearch до последнего образа целевой версии OpenSearch. Например, если версия кластера Elasticsearch 7.10.2(7.10.2_24.3.3_0102), при кросс‑движковом обновлении кластер Elasticsearch будет обновлён до последнего образа 1.3.6(1.3.6_24.3.4_0109) версии OpenSearch 1.3.6. (Здесь указанные номера версий являются лишь примерами.) Эта функция пока не поддерживается. |
Поддержка версий
Поддерживаемые целевые версии различаются в зависимости от текущей версии. Для подробностей см. Таблица 2.
Текущая версия | Целевая версия |
|---|---|
Elasticsearch: 6.2.3 | Elasticsearch: 6.5.4 or 6.8.23 |
Elasticsearch: 6.5.4 | Elasticsearch: 6.8.23 |
Elasticsearch: 6.8.23 | Elasticsearch: 7.6.2 or 7.10.2 |
Elasticsearch: 7.1.1 | Elasticsearch: 7.6.2 или 7.10.2 |
Elasticsearch: 7.6.2 | Elasticsearch: 7.10.2 |
Elasticsearch: 7.10.2 | OpenSearch: 1.3.6 |
Примечание:
| |
Ограничения
- Одновременно может быть обновлено не более 20 кластеров.
- Во время обновления данные на обновляемых узлах должны быть перенесены на другие узлы. Таймаут миграции данных на один узел составляет 48 часов. Обновление завершится с ошибкой, если этот таймаут истечёт. Если в кластере хранится большое количество данных, рекомендуется вручную настроить скорость миграции данных и избегать выполнения миграции в пиковые часы.
Влияние обновления
Перед обновлением кластера необходимо оценить потенциальные последствия и просмотреть операционные рекомендации. Это позволяет правильно спланировать время обновления, обеспечивая плавный процесс обновления и минимизируя прерывания обслуживания.
- Влияние на производительность
Узлы кластера обновляются по одному, чтобы обеспечить непрерывность обслуживания. Однако миграция данных, происходящая во время обновления, потребляет I/O производительность, и вывод отдельных узлов из сети всё равно оказывает некоторое воздействие на общую производительность кластера.
Чтобы минимизировать это воздействие, рекомендуется регулировать скорость миграции данных в зависимости от цикла трафика кластера: увеличить скорость миграции данных в непиковые часы, чтобы сократить длительность задачи, и уменьшить её до пиковые часы приходят, чтобы обеспечить оптимальную производительность кластера. Скорость миграции данных определяется indices.recovery.max_bytes_per_sec параметр. Значение по умолчанию этого параметра равно количеству vCPUs, умноженному на 32 MB. Например, для четырёх vCPUs скорость миграции данных составляет 128 MB. Установите этот параметр в диапазоне от 40 MB до 1000 MB в зависимости от требований вашего сервиса.
PUT /_cluster/settings{"transient": {"indices.recovery.max_bytes_per_sec": "1000MB"}} - Влияние на обработку запросов
Во время обновления узлы обновляются по одному. Запросы, отправленные на узел, который обновляется, могут завершиться с ошибкой. Чтобы смягчить это влияние, можно принять следующие меры:
- Используйте VPC endpoint или выделенный load balancer для обработки запросов доступа к вашему кластеру, что гарантирует автоматическую маршрутизацию запросов к доступным узлам.
- Включите на клиенте механизм экспоненциального отката и повторных попыток (настройте три повторных запроса).
- Выполняйте обновление в часы низкой нагрузки.
- Восстановление Kibana и Cerebro
Kibana и Cerebro будут перестроены во время обновления, что сделает их временно недоступными. Кроме того, из‑за проблем совместимости разных версий Kibana может стать недоступной во время обновления. Эти проблемы исчезнут после завершения обновления.
- Характеристики процесса обновления
После запуска задача обновления не может быть остановлена, пока она не завершится успешно или с ошибкой. Сбой обновления затрагивает только один узел и не прерывает сервисы, если существуют реплики данных. При необходимости вы можете восстановить узел, не прошедший обновление, выполнив Замена указанного узла в кластере Elasticsearch.
Продолжительность обновления
Следующая формула может быть использована для оценки того, сколько времени требуется для обновления кластера:
Продолжительность обновления (мин) = 15 (мин) x Общее количество узлов, подлежащих обновлению + Продолжительность миграции данных (мин)
где,
- 15 минут указывает, сколько обычно занимает операция, не связанная с миграцией данных (например, инициализация и обновление образа) на один узел. Это эмпирическое значение.
- Общее количество узлов — это сумма количества узлов данных, узлов‑мастеров, клиентских узлов и узлов холодных данных в кластере.
Продолжительность миграции данных (мин) = Общий объём данных (MB)/[Общее количество vCPU узлов данных x 32 (MB/s) x 60 (s) x Параллельность]
где,
- Как правило, когда параллельность выше 1, фактическая скорость миграции данных может достигать лишь половины пропускной способности, предусмотренной настроенной параллельностью, в зависимости от нагрузки кластера.
- 32 MB/s указывает, что каждый vCPU может обрабатывать 32 MB данных в секунду. Это эмпирическое значение.
Приведённые выше формулы используют оценки при идеальных условиях. На практике рекомендуется добавить 20% до 30% избыточности.
Pre-Upgrade Check
Чтобы обеспечить успешное обновление, необходимо проверить элементы, перечисленные в следующей таблице, перед выполнением обновления.
Элемент проверки | Метод проверки | Описание | Нормальный статус |
|---|---|---|---|
Статус кластера | Системная проверка | После начала задачи обновления система автоматически проверяет статус кластера. Кластеры, статус которых зеленый или желтый могут корректно предоставлять услуги и не имеют нераспределённых основных шардов. | Кластер доступен и текущих задач нет. |
Количество узлов | Проверка системы | После запуска задачи обновления система автоматически проверяет количество узлов. Чтобы обеспечить непрерывность обслуживания, для кластера в каждом из его AZ должно быть как минимум два узла каждого типа. Для кластера с мастер‑узлами должно быть как минимум два узла данных. Для кластера без мастер‑узлов количество узлов данных плюс узлов холодных данных должно быть не менее трёх. |
|
Емкость диска | Проверка системы | После запуска задачи обновления система автоматически проверяет ёмкость диска. Во время обновления узлы выводятся из эксплуатации один за другим, после чего создаются новые узлы. Убедитесь, что общая ёмкость диска оставшихся узлов достаточна для обработки всех данных кластера и что использование диска узлами остаётся ниже 80%. | После вывода из эксплуатации отдельного узла общая ёмкость дисков оставшихся узлов достаточна для обработки всех данных кластера, и использование дисков узлами остаётся ниже 80%. |
Реплики данных | Проверка системы | Проверьте, что оставшиеся узлы данных и узлы холодных данных могут обрабатывать максимальное количество основных и резервных шардов индексов в кластере. Во время обновления не должно быть нераспределённых реплик. | Количество узлов данных + Количество узлов холодных данных > Максимальное количество реплик индекса + 1 |
Данные Бэкап | Проверка системы | Перед обновлением выполните резервное копирование данных, чтобы предотвратить потерю данных, вызванную сбоями обновления. При отправке задачи обновления вы можете выбрать, проверять ли полные снимки индекса. | Проверьте, были ли данные резервно скопированы. |
Ресурсы | Проверка системы | После запуска задачи обновления система автоматически проверяет ресурсы. Во время обновления будут созданы новые ресурсы. Убедитесь, что ресурсы доступны. | Ресурсы доступны и достаточны. |
Пользовательские плагины | Системная и ручная проверка | Выполняйте эту проверку только в том случае, если в исходном кластере установлены пользовательские плагины. Если у кластера есть пользовательский плагин, загрузите все пакеты плагинов целевой версии на странице управления плагинами до обновления. Во время обновления установите пользовательский плагин на новых узлах. В противном случае пользовательские плагины будут потеряны после успешного обновления кластера. После запуска задачи обновления система автоматически проверяет, был ли загружен пакет пользовательского плагина, но вам необходимо проверить, корректен ли загруженный пакет плагина. NOTE: Если загруженный пакет плагина некорректен или несовместим, пакет плагина не может быть автоматически установлен во время обновления. В результате задача обновления завершается сбоем. Чтобы восстановить кластер, вы можете завершить задачу обновления и восстановить узел, который не удалось обновить, выполнив Замена указанного узла для кластера Elasticsearch. После завершения обновления статус пользовательского плагина сбрасывается на Загружено. | Пакет плагина кластера, который будет обновлен, загружен в список плагинов. |
Пользовательские конфигурации | Проверка системы | Во время обновления система автоматически синхронезирует содержимое файла конфигурации кластера elasticsearch.yml. | Пользовательские конфигурации кластеров не теряются после обновления. |
Нестандартные операции | Ручная проверка | Проверьте, были ли выполнены в кластере нестандартные операции. Нестандартные операции относятся к ручным действиям, которые не фиксируются. Эти операции не могут быть автоматически переданы во время обновления, например, модификация kibana.yml файл конфигурации, системные настройки и маршруты возврата. | Некоторые нестандартные операции совместимы. Например, изменение плагина безопасности можно сохранить через metadata, а изменение системной конфигурации можно сохранить с использованием images. Некоторые нестандартные операции, такие как изменение kibana.yml файл, не может быть сохранён, и вы должны заранее выполнить резервное копирование файла. |
Проверка совместимости | Системная и ручная проверка | После запуска задачи перекрестного обновления версии система автоматически проверяет, есть ли несовместимые конфигурации между исходной и целевой версиями. Если для кластера установлен пользовательский плагин, совместимость версии пользовательского плагина необходимо проверять вручную. | Конфигурации до и после перекрестного обновления версии совместимы. |
Проверить нагрузку кластера | Системная и ручная проверка | Если кластер сильно нагружен, велика вероятность того, что обновление зависнет или завершится с ошибкой. Рекомендуется проверять нагрузку кластера перед обновлением и проводить обновление только в непиковые часы. Вы также можете выбрать проверку нагрузки Кластера при настройке информации об обновлении. |
|
Выполнение задачи обновления
- Войдите в консоль управления CSS.
- В навигационной панели слева выберите Кластеры > Elasticsearch.
- В списке кластеров щелкните имя целевого кластера. Отображается страница информации о кластере.
- Нажмите Снапшоты кластера вкладку, и выполните полное резервное копирование данных. Для получения подробной информации см. Ручное создание Снапшота.
При создании задачи обновления вы можете выбрать проверку, был ли полный индекс данных сохранён с помощью снапшотов. Это помогает предотвратить потерю данных в случае сбоя обновления.
- Нажмите Обновление версии вкладку и задайте параметры обновления.
Таблица 4 Параметры обновления Параметр
Описание
Тип обновления
Выберите тип обновления.
- Обновление той же версии: обновление патчей ядра до последних образов в текущей версии кластера.
- Обновление между версиями: обновить Кластер до последнего образа целевой версии.
- Обновление между движками: обновить Elasticsearch Кластер до OpenSearch Кластера. Эта функция пока не поддерживается.
Целевой образ
Образ целевой версии. При выборе образа отображаются имя образа и детали целевой версии.
Поддерживаемые целевые версии отображаются в раскрывающемся списке Целевой образ. Если целевой образ недоступен, возможные причины перечислены ниже:
- Текущий Кластер находится на последней версии.
- Текущий Кластер был создан до 2023 года и имеет векторные индексы.
- Образы новой версии недоступны в текущем регионе.
- Текущий Кластер не поддерживает выбранный тип обновления.
- Нажмите Отправить.
- В отображаемом диалоговом окне настройте проверку обновления и параметры ускорения.
- Выберите, включить ли Проверить полный снимок индекса.
При включении CSS проверяет действительные снимки, сопоставляя индексы по имени. Снимки помогают предотвратить потенциальную потерю данных, вызываемую сбоями обновления.
CSS не может проверять содержимое или время резервного копирования снимков. Вам следует вручную проверять существующие снимки. Если какой-либо из них старше одного месяца, создайте последний снимок.
- Выберите, включить ли Проверить нагрузки кластера.
Во время обновления миграция данных и перезапуск узлов будут потреблять ресурсы кластера и увеличивать нагрузки. При включении этой опции CSS оценивает риски перегрузки кластера и снижает вероятность сбоя обновления кластера, вызванного перегрузкой.
Элементы проверки следующие:
- nodes.thread_pool.search.queue < 1000: Проверьте, что максимальное количество запросов в очереди поиска меньше 1000.
- nodes.thread_pool.write.queue < 200: Проверьте, что максимальное количество запросов в очереди записи меньше 200.
- nodes.process.cpu.percent < 90: Проверьте, что максимальное использование CPU узлов кластера меньше 90%.
- nodes.os.cpu.load_average/Number of vCPUs < 80%: Проверьте, что количество работающих процессов плюс количество процессов, ожидающих CPU, меньше 80% от общего количества vCPUs.
Если любой из результатов аномальный, дождитесь снижения нагрузки или активно оптимизируйте её до выполнения обновления.
- Установить Контроль параллельности миграции данных.
Увеличение параллельности миграции данных может ускорить процесс обновления, но более быстрая миграция приводит к более высокому использованию I/O. Более высокая параллельность, скорее всего, приведет к большей нагрузке на кластер, что может повлиять на производительность кластера. Рекомендуется оставить значение по умолчанию 1. Значение не должно превышать половину количества узлов данных.
- Выберите, включить ли Проверить полный снимок индекса.
- Щелкните OK для запуска проверки перед обновлением. Система автоматически выполняет проверку на основе Проверка перед обновлением, и если проверка выполнена успешно, производится обновление.
Если проверка обновления не проходит, информация об ошибке отображается в правом верхнем углу консоли. Отрегулируйте конфигурацию кластера соответствующим образом и повторите попытку.
Рисунок 1 Ошибки проверки обновления
Когда Статус задачи в списке задач ниже изменяется на Успешно, обновление завершено.
- Подтвердите результат обновления.
- В списке кластеров нажмите имя целевого кластера. Отображается страница информации о кластере.
- На Обзор вкладке, проверьте версию кластера в Информация о кластере области, чтобы определить, успешно ли обновление.
Проверка задачи обновления
На Обновление версии странице, найдите текущую задачу обновления в Задачи списке.
Разверните задачу и нажмите Просмотр прогресса чтобы проверить прогресс обновления.
Если статус задачи Не удалось, вы можете повторить или завершить задачу.
- Повторить задачу: нажмите Повторить в Операция колонка.
- Завершить задачу: Нажмите Завершить в Операция колонка.
После завершения задачи обновления узлы, которые не удалось обновить, останутся в текущем состоянии, тогда как узлы, успешно обновлённые, не будут откатаны к предыдущей версии. В результате узлы в одном кластере могут иметь разные версии. Рекомендуется перезапустить обновление, как только будут решены соответствующие проблемы, обеспечивая наличие одинаковой версии у всех узлов.
Во время кросс-верссионного обновления, если Task Status является Failed, вы можете завершить задачу обновления только в том случае, если все узлы ещё не обновлены.