Изменение спецификаций узла

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

• Спецификации узла и тип хранилища нельзя изменить для узлов, использующих локальные диски.
• Спецификации узла и тип хранилища нельзя изменять одновременно.
• Тип хранилища узла можно изменить только для узлов данных и узлов холодных данных.
• При изменении типа хранилища узла данные необходимо мигрировать между различными узлами. Тайм‑аут миграции данных для одного узла составляет 48 часов. Обновление завершится неудачей, если этот тайм‑аут истечёт. Если в кластере хранится большое количество данных, рекомендуется вручную регулировать скорость миграции данных и избегать выполнения миграции в пиковые часы.
• Для кластера без master‑узлов спецификации узла и тип хранилища узла можно изменить только если количество узлов данных и узлов холодных данных составляет минимум три.
• Для кластера с master‑узлами эта операция разрешена только если в кластере имеется минимум два узла данных.
• Во время изменения типа хранилища узла всегда есть один недоступный узел. Чтобы обеспечить непрерывность сервиса, убедитесь, что total number of data nodes and cold data nodes is greater than the maximum number of index replicas plus 1. Для кластера с одним AZ или двумя AZ также убедитесь, что в каждом AZ кластера присутствует минимум два узла каждого типа.
• Во время изменения спецификаций узла узлы выводятся из эксплуатации для внесения изменений. Чтобы обеспечить непрерывность сервиса, убедитесь, что у всех шардов есть реплики.
• Убедитесь, что использование диска всегда ниже 80 % во время изменения.

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

• Влияние на производительность (только при изменении типа хранилища узла)

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

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

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

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

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

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

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

• Влияние на OpenSearch Dashboards и Cerebro

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

• Характеристики этого процесса

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

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

  Change duration (min) = 10 (min) x Total number of nodes to change + Data recovery duration (min)

  где,

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

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

  где,

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

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

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

  где,

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

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

  где,

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

• Состояние кластера Available, и нет текущих задач.
• Ваши квоты ресурсов CSS достаточны для расширения ёмкости, которое вы собираетесь выполнить. Вы можете проверить доступные ресурсы на странице Modify Configuration.
• Все критически важные данные были сохранены перед изменением типа хранилища узла. Это делается для предотвращения потери данных. Подробности см. в Creating Snapshots to Back Up Data.

1. Войдите в консоль управления CSS.
2. В левой панели навигации выберите Clusters > OpenSearch.
3. Убедитесь, что все данные сервисов имеют реплики, чтобы сервисы не прерывались во время изменения спецификаций.
   1. В списке кластеров найдите целевой кластер и нажмите Dashboards в столбце Operation, чтобы войти в OpenSearch Dashboards.
   2. В левой панели навигации выберите Dev Tools.
   3. Выполните команду GET _cat/indices?v в OpenSearch Dashboards.
      • Если возвращённое значение rep больше 0, реплики данных существуют. Перейдите к следующему шагу.
      • Если возвращённое значение rep равно 0, реплики данных отсутствуют. Рекомендуется вручную создать снапшот кластера перед переходом к следующему шагу. Подробности см. в Creating Snapshots to Back Up Data.
4. В списке кластеров найдите целевой кластер и выберите More > Modify Configuration в столбце Operation. Отобразится страница Modify Configuration.
5. Нажмите вкладку Scale Cluster.
6. Нажмите Change specifications, чтобы задать параметры.

   Таблица 2 Изменение спецификаций

   Parameter	Description
   Action	Выберите Change specifications.
   Resources	Отображает изменение ресурсов для этой операции.
   Nodes	Настройте изменения, которые вы хотите выполнить. Выберите тип узла в столбце Node Type. Выберите новый флейвор в столбце Node Specifications, или выберите новый тип хранилища в столбце Node Storage. Спецификации узла и тип хранилища нельзя изменять одновременно.

7. Нажмите Next.
8. Подтвердите информацию и нажмите Submit.
9. В отображаемом диалоговом окне подтвердите пункты проверки и нажмите OK, чтобы начать изменение спецификаций.
   • Пункты проверки изменения спецификаций узла: Verify index copies & nodes и Cluster status check.
   • Проверьте элементы для изменения типа хранилища узла: Check cluster load.

   Table 3 Проверьте описание элемента

   Элемент	Описание
   Проверьте реплики индексов & узлы	Проверка наличия реплик индексов помогает повысить безопасность данных. Вы можете пропустить этот шаг, но отсутствие реплик индексов может повлиять на надежность данных при изменении спецификаций узла. Проверка узлов данных гарантирует, что у кластера достаточно мощности для обработки запросов. Пропуск этой проверки повышает риск прерывания сервисов при изменении спецификаций узла. Действуйте с осторожностью. Правила проверки: Если вы выбираете Verify index copies & nodes и в кластере нет мастер‑узлов, каждый индекс должен иметь как минимум одну реплику, а кластер должен содержать как минимум три узла данных плюс узлы холодных данных. Если вы выбираете Verify index copies & nodes и в кластере есть мастер‑узел, каждый индекс должен иметь как минимум одну реплику, но количество узлов в кластере не ограничивается.
   Проверка статуса кластера	Во время изменения спецификаций узла статус кластера проверяется по умолчанию для повышения вероятности успеха и обеспечения безопасности данных. Узлы изменяются по одному. Для каждого узла система изменяет его спецификации, перезапускает его и проверяет, что все его процессы успешно запущены, прежде чем перейти к следующему узлу. В экстренных ситуациях (например, когда кластер перегружен и сервисы работают с ошибками, что может помешать выполнению запроса на изменение спецификаций) вы можете пропустить проверку статуса кластера, чтобы освободить больше ресурсов для восстановления кластера. Однако такой пропуск может привести к неисправности кластера и прерыванию сервисов. Будьте осторожны.
   Check cluster load	Во время изменения типа хранилища узла миграция данных между узлами и остановка и перезапуск узлов потребляют ресурсы кластера, вызывая рост нагрузки кластера. Проверка нагрузки кластера может выявить возможные риски перегрузки кластера и снизить вероятность того, что условие перегрузки приведёт к сбою изменения типа хранилища узла. Элементы проверки нагрузки кластера следующие: 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.

   Note

   Если запрос на изменение не может быть отправлен и отображается сообщение о необходимости обновления кластера, это означает, что текущая версия кластера не поддерживает изменение типа хранилища узла. Обновите кластер до последней версии образа и повторите попытку. Подробное руководство по обновлению см. в Upgrading the Cluster Version.

10. Нажмите Back to Cluster List, чтобы вернуться на страницу Clusters. Cluster Status имеет значение Configuration modified. Когда Cluster Status меняется на Available, спецификации узлов кластера успешно изменены.