Обновление версии кластера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

где,

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

Продолжительность миграции данных (мин) = Общий размер данных (МБ) / [Общее количество vCPU узлов данных × 8 (МБ/с) × 60 (с) × Concurrency]

где,

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

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

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

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

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

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

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

   Параметр	Описание
   Тип обновления	Выберите тип обновления. Обновление той же версии: обновите патчи ядра до последних образов в текущей версии кластера. Обновление между версиями: обновите кластер до последнего образа целевой версии.
   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, и если проверка успешна, переходит к обновлению.

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

   Рисунок 1 Ошибки проверки обновления

   
   

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

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

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

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

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

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

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

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