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

Для кластера с оплатой по использованию вы можете увидеть его новую цену при подтверждении изменения спецификаций узла или типа хранилища в 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 MB. Например, для четырёх vCPU скорость миграции данных составляет 32 MB/s. Вы можете изменить её в соответствии с требованиями сервиса.

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

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

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

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

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

• Влияние на Kibana и Cerebro

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

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

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

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

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

  где,

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

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

  где,

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

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

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

  где,

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

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

  где,

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

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

1. Войдите в консоль управления CSS.
2. В панели навигации слева выберите Clusters > Elasticsearch.
3. Убедитесь, что все данные сервисов имеют реплики, чтобы сервисы не прерывались во время изменения.
   1. In the displayed cluster list, find the target cluster, and click Access Kibana in the Operation column to log in to the Kibana console.
   2. In the left navigation pane, choose Dev Tools.
   3. Выполните команду GET _cat/indices?v в Kibana.
      • If the returned rep value is greater than 0, data replicas exist. Go to the next step.
      • If the returned rep value is 0, there are no data replicas. You are advised to manually create a snapshot for the cluster before moving on to the next step. For details, see Creating Snapshots to Back Up Data.
4. In the cluster list, find the target cluster, and choose More > Modify Configuration in the Operation column. The Modify Configuration page is displayed.
5. Click the Scale Cluster tab.
6. Click Change specifications to set parameters.

   Table 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 Проверьте описание элемента

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