Облачная платформаAdvanced

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

Эта статья полезна?
Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Если в кластере Elasticsearch есть избыточная ёмкость из‑за трафика в непиковые часы или уменьшенного объёма данных, вы можете уменьшить количество его узлов для оптимизации затрат.

Таблица 1 Сценарии масштабирования

Тип

Сценарий

Процесс изменения

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

Случайным образом удаляет узлы кластера для оптимизации затрат.

  1. Переместите шарды с удаляемых узлов на оставшиеся узлы.
  2. После миграции данных выведите узлы из сети и измените конфигурацию кластера.

Узлы удаляются по одному, чтобы избежать прерывания сервисов.

Удаление указанных узлов

Удаляет указанные узлы кластера для оптимизации затрат.

Влияние на биллинг

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

Ограничения

  • Во время scale-in данные на узлах, которые будут удалены, необходимо перенести на оставшиеся узлы. Таймаут миграции данных на каждый узел составляет 48 часов. Scale-in завершится неудачей, если этот таймаут истечёт. Когда в кластере хранится большое количество данных, рекомендуется вручную регулировать скорость миграции данных и избегать выполнения миграции в пиковые часы.
  • Для кластера без master‑узлов:
    • Scale-in разрешён только если количество узлов данных плюс узлов холодных данных составляет минимум три.
    • Во время scale-in можно удалять менее половины узлов данных плюс узлов холодных данных.

      Например, если кластер имеет три узла данных, три клиентских узла и три узла холодных данных, за одну операцию можно удалить максимум два узла. Формула: (3+3)/2 = 3; и количество удаляемых узлов должно быть меньше 3.

    • Чтобы обеспечить надёжность данных, оставшееся количество узлов данных плюс узлов холодных данных после scale-in должно быть больше максимального количества реплик индексов.

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

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

      Например, если в кластере два узла данных и четыре мастер‑узла, только один мастер‑узел может быть удалён в текущей операции масштабирования‑вниз. Формула: 4/2 = 2; и количество узлов, которое можно удалить, должно быть менее 2.

  • После масштабирования‑вниз использование диска узлов кластера должно быть менее 80%.
  • После масштабирования‑вниз в каждом AZ должен присутствовать хотя бы один узел каждого типа. Для кластера, охватывающего несколько AZ, разница между количествами узлов одного типа в разных AZ не может превышать 1.
  • Для диапазона количеств узлов, поддерживаемых каждым типом узлов, см. Таблица 2.
    Таблица 2 Диапазоны количества узлов

    Тип узла

    Диапазон значений

    Узлы данных

    • Без узлов master: от 1 до 32
    • С узлами master: от 1 до 200

    Узлы master

    3, 5, 7 или 9 (должно быть нечётным числом от 3 до 9)

    Узлы клиента

    1–32

    Узлы холодных данных

    1–32

Влияние изменения

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

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

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

    Чтобы минимизировать это влияние, рекомендуется регулировать скорость миграции данных в зависимости от цикла трафика кластера: увеличивать скорость миграции данных в часы низкой нагрузки, чтобы сократить длительность задачи, и уменьшать её до приходят часы пик, чтобы обеспечить оптимальную работу кластера. Скорость миграции данных определяется indices.recovery.max_bytes_per_sec параметр. Значение по умолчанию этого параметра равно количеству vCPU, умноженному на 32 MB. Например, для четырёх vCPU скорость миграции данных составляет 128 MB. Установите этот параметр в диапазоне от 40 MB до 1000 MB в зависимости от требований вашей службы.

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

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

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

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

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

Продолжительность масштабирования‑вниз

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

Продолжительность масштабирования‑вниз (мин) = 5 (мин) x Количество узлов, подлежащих удалению + Продолжительность миграции данных (мин)

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

Продолжительность миграции данных (мин) = Общий объём данных узлов, которые будут удалены (MB) ÷ [Общее количество vCPUs данных узлов x 32 (MB/s) x 60 (s)]

где,

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

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

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

где,

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

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

где,

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

Требования

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

  1. Войдите в консоль управления CSS.
  2. В навигационной панели слева выберите Кластеры > Elasticsearch.
  3. В списке кластеров найдите целевой кластер и выберите Подробнее > Изменить конфигурацию в Операция столбце. Изменить конфигурацию страница отображена.
  4. Нажмите Масштабировать кластер вкладка.
  5. Нажмите Уменьшить масштаб для установки параметров.
    Таблица 3 Удаление узлов случайным образом

    Параметр

    Описание

    Действие

    Выбрать Снизить масштаб.

    Ресурсы

    Количество ресурсов уменьшено.

    Узлы

    Уменьшить количество узлов в Узлы столбце. Вы можете изменить несколько типов узлов одновременно.

    Для диапазона количеств узлов, поддерживаемых каждым типом узла, см. Ограничения.

  6. Нажмите Далее.
  7. Подтвердите информацию и нажмите Отправить.
  8. Нажмите Назад к списку кластеров вернуться к Кластеры страница. Состояние задачи это Масштабирование вниз. Когда Состояние кластера изменяется на Доступно, кластер успешно масштабирован вниз.

Удаление указанных узлов

  1. Войдите в консоль управления CSS.
  2. В навигационной панели слева выберите Кластеры > Elasticsearch.
  3. В списке кластеров найдите целевой кластер и выберите Больше > Изменить конфигурацию в Операция столбец. The Modify Configuration страница отображена.
  4. На Modify Configuration страница, нажмите Scale In Nodes вкладка.
  5. Установите параметры scale-in.
    Таблица 4 Удаление указанных узлов (Scale In Nodes)

    Параметр

    Описание

    Тип узла

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

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

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

  8. Нажмите Вернуться к списку кластеров чтобы вернуться к Кластеры странице. Состояние задачи является Сокращение. Когда Состояние кластера изменяется на Доступно, кластер был успешно сокращён.

Связанные документы

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