Масштабирование In/Down

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

• Во время операции масштабирования вниз данные на удаляемых узлах необходимо мигрировать на оставшиеся узлы. Тайм‑аут миграции данных для каждого узла составляет 48 часов. Масштабирование вниз завершится с ошибкой, если этот тайм‑аут истечёт.
• Если в кластере хранится большое количество данных, рекомендуется вручную регулировать скорость миграции данных и избегать выполнения миграции в пиковые часы.
• После завершения операции масштабирования вниз использование диска кластера должно быть ниже 80 %.
• Правила масштабирования вниз кластера без узлов master:
  • Условие: масштабирование вниз разрешено только когда the number of data nodes + the number of cold data nodes ≥ 3.
  • Максимальное количество узлов, которое можно удалить за одну операцию масштабирования вниз: нельзя удалить половину или более текущих data nodes и cold data nodes кластера.

    Например, если в кластере три data node, три client node и три cold data node, максимальное количество узлов, которое можно удалить за один раз, равно двум. Формула: (3+3)/2 = 3; и количество узлов, которое можно удалить, должно быть меньше 3, поэтому правильный результат — 2.

  • Надёжность данных: после операции масштабирования вниз общее количество оставшихся data nodes и cold data nodes должно быть больше максимального количества реплик индексов в кластере.

    Например, если максимальное количество реплик для всех индексов в кластере равно 2, общее количество data nodes и cold data nodes после масштабирования вниз должно быть не менее 3.

• Правила масштабирования вниз кластера с узлами master:
  • Узлы, не являющиеся master (data nodes, client nodes или cold data nodes): для каждого типа узлов количество узлов должно быть не менее 2, прежде чем можно будет выполнить операцию масштабирования вниз.
  • Узлы master: за одну операцию масштабирования вниз можно удалить менее половины узлов master.

    Например, если в кластере два data node и пять master node, для текущей операции масштабирования вниз можно удалить только два master node. Формула: 5/2 = 2.5; и количество узлов, которое можно удалить, должно быть меньше 2.5, поэтому правильный результат — 2.

• Правила удаления узлов из многозонального кластера:
  • Равномерное распределение: после операции scale-in разница в количестве узлов одного типа в разных AZ не должна превышать 1.
  • Минимальное количество узлов, необходимое для обеспечения высокой доступности:
    • For a two-AZ cluster, должно быть не менее четырёх data nodes (или cold data nodes), по два в каждом AZ; и должно быть не менее двух client nodes (если они настроены), по одному в каждом AZ.
    • For a three-AZ cluster, каждый доступный тип узлов должен иметь как минимум один узел в каждом AZ. Это означает, что каждый тип узлов должен иметь как минимум три узла в сумме.
  • Повышение производительности: чтобы предотвратить неравномерное распределение данных и обеспечить оптимальную производительность запросов и загрузки, количество data nodes или cold data nodes должно быть целым кратным количеству AZ.
• Для диапазонов количества узлов, поддерживаемых каждым типом узлов, см. Table 2.

  Table 2 Диапазоны количества узлов

  Node Type	Value Range
  Data nodes	Without master nodes: 1 to 32 With master nodes: 1 to 200
  Master nodes	3, 5, 7, или 9 (должно быть нечётным числом от 3 до 9)
  Client nodes	1~64
  Холодные узлы данных	1–32

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

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

  Во время масштабирования вниз (scale-in) шарды на удаляемых узлах мигрируют на оставшиеся узлы. Этот процесс будет потреблять I/O‑производительность. Поэтому рекомендуется выполнять операцию в непиковые часы.

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

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

• Воздействие на нагрузку Кластера

  После масштабирования вниз (scale-in) оставшиеся узлы должны будут обрабатывать всю нагрузку Кластера. Это может привести к повышенному использованию CPU, памяти и дискового I/O, влияя на производительность запросов и загрузки данных. При неравномерном распределении шардов могут возникнуть узкие места в производительности. Поэтому перед масштабированием вниз необходимо оценить, способны ли оставшиеся узлы справиться с текущей нагрузкой Кластера.

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

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

Для оценки длительности операции масштабирования вниз (scale-in) можно использовать следующую формулу:

Scale-in duration (min) = 5 (min) x Number of nodes to be removed + Data migration duration (min)

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

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

где,

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

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

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

   Table 3 Удаление узлов случайным образом

   Параметр	Описание
   Action	Выберите Scale in.
   Resources	Количество ресурсов уменьшено.
   Nodes	Уменьшите количество узлов в столбце Nodes. Вы можете изменить несколько типов узлов одновременно. Для диапазона количеств узлов, поддерживаемых каждым типом узла, см. Constraints.

6. Нажмите Next.
7. Подтвердите информацию и нажмите Submit.
8. Нажмите Back to Cluster List, чтобы вернуться на страницу Clusters. Task Status равно Scaling in. Когда Cluster Status меняется на Available, кластер успешно уменьшен.

1. Войдите в консоль управления CSS.
2. В панели навигации слева выберите Clusters > Elasticsearch.
3. В списке кластеров найдите целевой кластер и выберите More > Modify Configuration в столбце Operation. Отобразится страница Modify Configuration.
4. На странице Modify Configuration нажмите вкладку Scale In Nodes.
5. Установите параметры scale-in.

   Table 4 Удаление указанных узлов (Scale In Nodes)

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

6. Нажмите Next.
7. Подтвердите информацию об изменении и нажмите Submit. В диалоговом окне подтверждения выберите миграцию данных, что помогает предотвратить потерю данных, и нажмите OK.

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

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

• Для кластера Elasticsearch вы также можете оптимизировать затраты, изменив спецификации узлов и типы дисков EVS. Подробнее см. Changing Node Specifications.
• Если вы хотите уменьшить количество узлов кластера, хотя ваш кластер не подходит для операции scale-in, вы можете просто создать новый кластер. Затем можно перенести данные в новый кластер с помощью снимков и удалить старый кластер после завершения миграции данных.