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

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

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

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

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

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

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

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

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

  Table 2 Node quantity ranges

  Node Type	Value Range
  Data nodes	Without master nodes: 1 to 32 With master nodes: 1 to 200
  Master nodes	3, 5, 7, or 9 (must be an odd number from 3 to 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"  
    }  
  }
  
  

• Влияние на нагрузку Кластера

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

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

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

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

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

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

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

где,

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

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

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

   Table 3 Случайное удаление узлов

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

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

1. Войдите в консоль управления CSS.
2. В панели навигации слева выберите Clusters > OpenSearch.
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. Click Back to Cluster List to go back to the Clusters page. Task Status is Scaling in. When Cluster Status changes to Available, the cluster has been successfully scaled in.

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