Обновление версии Cluster

Поддерживаемые целевые версии зависят от текущей версии. Подробнее см. Table 2.

• Одновременно может быть обновлено не более 20 кластеров.
• Во время обновления данные на обновляемых узлах необходимо перенести на другие узлы. Тайм‑аут миграции данных для одного узла составляет 48 часов. Обновление завершится с ошибкой, если тайм‑аут истечёт. Если в кластере хранится большой объём данных, рекомендуется вручную регулировать скорость миграции данных и избегать выполнения миграции в часы пик.

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

• Влияние на производительность

  Узлы кластера обновляются по одному, чтобы обеспечить непрерывность сервиса. Однако миграция данных, происходящая во время обновления, потребляет I/O‑производительность, и вывод отдельных узлов из эксплуатации всё же оказывает некоторое влияние на общую производительность кластера.

  Чтобы минимизировать это влияние, рекомендуется регулировать скорость миграции данных в зависимости от цикла трафика кластера: увеличивать скорость миграции данных в часы низкой нагрузки, чтобы сократить продолжительность задачи, и уменьшать её до пиковых часов, чтобы обеспечить оптимальную производительность кластера. Скорость миграции данных определяется параметром indices.recovery.max_bytes_per_sec. Значение параметра по умолчанию равно количеству vCPUs, умноженному на 8 MB. Например, для четырёх vCPUs скорость миграции данных составляет 32 MB/s. Вы можете изменить её в соответствии с требованиями сервиса.

  PUT /_cluster/settings  
  {  
    "transient": {  
      "indices.recovery.max_bytes_per_sec": "128MB"  
    }  
  }
  
  

• Влияние на обработку запросов

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

  • Используйте VPC endpoint или выделенный load balancer для обработки запросов доступа к вашему кластеру, что гарантирует автоматическую маршрутизацию запросов к доступным узлам.
  • Включите механизм экспоненциального отката & повторных попыток на клиенте (настройте три попытки).
  • Проводите обновление в часы низкой нагрузки.
• Пересборка Kibana и Cerebro

  Kibana и Cerebro будут пересобраны во время обновления, что сделает их временно недоступными. Кроме того, из‑за проблем совместимости разных версий Kibana может стать недоступной во время обновления. Эти проблемы исчезнут после завершения обновления.

• Характеристики процесса обновления

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

Для оценки времени, необходимого для обновления кластера, можно использовать следующую формулу:

Продолжительность обновления (мин) = 15 (мин) × Общее количество узлов для обновления + Продолжительность миграции данных (мин)

где,

• 15 минут — это типичное время, которое операции, не связанные с миграцией данных (например, инициализация и обновление образа), занимают на каждый узел. Это эмпирическое значение.
• Общее количество узлов равно сумме количества узлов данных, мастер‑узлов, клиентских узлов и узлов холодных данных в кластере.

Data migration duration (min) = Total data size (MB)/[Total number of vCPUs of the data nodes x 8 (MB/s) x 60 (s) x Concurrency]

где,

• Как правило, при значении concurrency более 1 фактическая скорость миграции данных может достигать лишь половины пропускной способности, предусмотренной настроенной concurrency, в зависимости от нагрузки кластера.
• 8 MB/s указывает, что каждый vCPU может обрабатывать 8 MB данных в секунду. Это эмпирическое значение.

Приведённые выше формулы используют оценки при идеальных условиях. На практике рекомендуется добавить 20 %–30 % резерв.

Чтобы обеспечить успешное обновление, необходимо проверить элементы, перечисленные в таблице ниже, перед выполнением обновления.

1. Войдите в консоль управления CSS.
2. В панели навигации слева выберите Clusters > Elasticsearch.
3. В списке кластеров нажмите имя целевого кластера. Отобразится страница информации о кластере.
4. Нажмите вкладку Cluster Snapshots и выполните полный бэкап данных. Подробности см. в Manually Creating a Snapshot.

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

5. Нажмите вкладку Version Upgrade и задайте параметры обновления.

   Table 4 Параметры обновления

   Parameter	Description
   Upgrade Type	Выберите тип обновления. Same-version upgrade: обновление патчей ядра до последних образов в текущей версии кластера. Cross-version upgrade: обновление кластера до последнего образа целевой версии. Cross-engine upgrade: обновление кластера Elasticsearch до кластера OpenSearch. Эта функция пока не поддерживается.
   Target Image	Образ целевой версии. При выборе образа отображаются имя образа и детали целевой версии. Поддерживаемые целевые версии отображаются в раскрывающемся списке Target Image. Если целевой образ недоступен, возможные причины следующие: Текущий кластер имеет последнюю версию. Текущий кластер был создан до 2023 года и содержит векторные индексы. Образы новой версии недоступны в текущем регионе. Текущий кластер не поддерживает выбранный тип обновления.

6. Нажмите Submit.
7. В отображаемом диалоговом окне настройте параметры проверки обновления и ускорения.
   1. Выберите, включить ли Check Full Index Snapshot.

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

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

   2. Выберите, включить ли Check Cluster Loads.

      Во время обновления миграция данных и перезапуск узлов будут потреблять ресурсы кластера и увеличивать нагрузку. Когда эта опция включена, 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% от общего количества vCPU.

      Если любой из результатов аномален, дождитесь снижения нагрузки или активно оптимизируйте её перед выполнением обновления.

   3. Установите Data migration concurrency control.

      Увеличение параллелизма миграции данных может ускорить процесс обновления, но более быстрая миграция данных приводит к более высокому использованию I/O. Более высокий параллелизм, вероятно, приведёт к большей нагрузке кластера, что может повлиять на производительность кластера. Рекомендуется оставить значение по умолчанию 1. Значение не должно превышать половину количества узлов данных.

8. Нажмите OK, чтобы начать предварительную проверку обновления. Система автоматически выполняет проверку на основе Pre-Upgrade Check, и если проверка успешна, переходит к обновлению.

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

   Figure 1 Ошибки проверки обновления

   
   

   Когда Task Status в списке задач ниже меняется на Successful, обновление завершено.

9. Подтвердите результат обновления.

   В списке кластеров найдите целевой кластер и проверьте версию кластера в столбце Version, чтобы увидеть, успешно ли выполнено обновление.

На странице обновления вы можете проверить текущую задачу обновления в области Upgrade Records, чтобы узнать прогресс и статус задачи.

Разверните список задач и нажмите View Progress, чтобы проверить прогресс обновления и статус узлов.

Если Task Status равно Failed, вы можете повторить задачу или завершить её.

• Повторить задачу: нажмите Retry в столбце Operation.
• Завершить задачу: нажмите Terminate в столбце Operation. Перед завершением задачи кросс-версионного обновления убедитесь, что ни один из узлов не был обновлён.

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