Замена неисправного узла

• Одновременно может быть заменён только один узел. Каждый новый узел создаётся с использованием ID, IP‑адреса, характеристик и AZ узла, который он заменяет.
• Конфигурации, изменённые вручную, не сохранятся после замены узла. Например, если вы вручную добавили обратный маршрут для исходного узла, его необходимо добавить повторно для нового узла после завершения замены.
• Если заменяемый узел является data node или cold data node, обратите внимание на следующие предосторожности:
  • При замене data node или cold data node его данные сначала мигрируют на другие data node. Это означает, что общее количество data node и cold data node должно быть больше максимального количества реплик индексов плюс 1.
  • В AZ, содержащем заменяемый data node или cold data node, должен быть как минимум ещё один data node или cold data node.
  • Если в кластере нет master node, общее количество data node и cold data node должно быть не менее трёх.
  • Приведённые выше предосторожности не применяются при замене неисправного узла, независимо от его типа. Это происходит потому, что неисправные узлы не включаются в _cat/nodes.

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

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

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

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

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

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

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

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

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

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

Продолжительность изменения (мин) = 15 (мин) + Продолжительность миграции данных (мин)

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

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

где,

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

• Состояние кластера Available, и нет текущих задач.
• Все критически важные данные были сохранены. Подробности см. в Creating Snapshots to Back Up Data.

1. Войдите в консоль управления CSS.
2. В панели навигации слева выберите Clusters > OpenSearch.
3. В списке кластеров найдите целевой кластер и выберите More > Modify Configuration в столбце Operation. Отобразится страница Modify Configuration.
4. На странице Modify Configuration нажмите вкладку Replace Node.
5. На вкладке Replace Node задайте параметры по необходимости.

   Table 1 Замена указанного узла

   Параметр	Описание
   Тип узла	Выберите узел, который нужно заменить. Вы можете развернуть тип узла, чтобы проверить все узлы под ним.

6. Нажмите Submit. В диалоговом окне подтверждения миграции данных выберите миграцию данных и нажмите OK.

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

7. Нажмите Back to Cluster List, чтобы вернуться на страницу Clusters. Task Status — Upgrading. Когда Cluster Status изменится на Available, узел будет успешно заменён.