Изменение спецификаций узлов и типа хранилища кластера Elasticsearch

Impact on Billing

Constraints

• Спецификации узла и тип хранилища нельзя изменить для узлов, использующих локальные диски.
• Спецификации узла и тип хранилища нельзя изменить одновременно.
• Тип хранилища узла можно изменить только для узлов данных и узлов холодных данных.
• При изменении типа хранилища узла данные необходимо перенести между различными узлами. Время ожидания переноса данных на каждый узел составляет 48 часов. Обновление завершится с ошибкой, если это время ожидания истечёт. Если в кластере хранится большое количество данных, рекомендуется вручную регулировать скорость переноса данных и избегать выполнения переноса в часы пика.
• Для кластера без master nodes тип хранилища узла можно изменить только если суммарное количество узлов данных и узлов холодных данных составляет не менее трёх.
• Для кластера с master nodes эта операция разрешена только при наличии как минимум двух узлов данных.
• Во время изменения типа хранилища узла всегда есть один недоступный узел. Чтобы обеспечить непрерывность сервиса, убедитесь, что общее количество узлов данных и узлов холодных данных превышает максимальное количество реплик индексов плюс 1. Для кластера с одним AZ или двумя AZ также убедитесь, что в каждом из его AZ есть как минимум два узла каждого типа.
• Во время изменения спецификаций узлов узлы выводятся из сети для внесения изменений. Чтобы обеспечить непрерывность сервиса, убедитесь, что у всех шардов имеются реплики.
• Убедитесь, что использование диска всегда ниже 80% во время изменения.

Change Impact

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

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

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

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

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

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

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

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

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

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

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

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

Продолжительность изменения

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

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

  где,

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

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

  где,

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

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

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

  где,

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

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

  где,

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

Предварительные требования

• Состояние кластера Доступно, и нет текущих задач.
• Ваши квоты ресурсов CSS достаточны для расширения ёмкости, которое вы собираетесь выполнить. Вы можете проверить доступные ресурсы на Изменить конфигурацию странице.
• Все критически важные данные были резервно скопированы до изменения типа хранилища узла. Это делается для предотвращения потери данных. Подробности см. Создание Снапшотов для резервного копирования данных кластера Elasticsearch.

Изменение характеристик узла и типа хранилища

1. Войдите в консоль управления CSS.
2. В навигационной панели слева выберите Кластеры > Elasticsearch.
3. Проверьте, что все данные службы имеют реплики, чтобы сервисы не были прерваны во время изменения.
   1. В отображаемом списке кластеров найдите целевой кластер и щелкните Получить доступ к Kibana в Операция столбце для входа в консоль Kibana.
   2. В левой навигационной панели выберите Инструменты разработки.
   3. Запустите GET _cat/indices?v команду в Kibana.
      • Если возвращённый реплика значение больше 0, реплики данных существуют. Перейдите к следующему шагу.
      • Если возвращено rep значение равно 0, реплик данных нет. Рекомендуется вручную создать снимок для кластера перед переходом к следующему шагу. Подробнее см Создание снимков для резервного копирования данных кластера Elasticsearch.
4. В списке кластеров найдите нужный кластер и выберите Подробнее > Изменить конфигурацию в Операция колонке. Изменить конфигурацию страница отображается.
5. Нажмите Масштабировать кластер вкладка.
6. Щелкните Изменить характеристики для установки параметров.

   Таблица 2 Изменение спецификаций узла и типа хранилища

   Параметр	Описание
   Действие	Выбрать Изменить характеристики.
   Ресурсы	Показывает изменение ресурсов для этой операции.
   Узлы	Настройте изменения, которые вы хотите внести. Выберите тип узла в Тип узла столбце. Выберите новый Флейвор в Спецификации узла столбце, или выбрать новый тип хранилища в Node Storage столбце. Спецификации узла и тип хранилища не могут быть изменены одновременно.

7. Нажмите Далее.
8. Подтвердите информацию и нажмите Отправить.
9. В отображаемом диалоговом окне подтвердите пункты проверки и нажмите OK чтобы начать изменение спецификаций.
   • Проверьте пункты изменения спецификаций узла: Проверьте копии индекса и Проверка статуса Кластера.
   • Проверьте пункты изменения типа хранилища узла: Проверьте нагрузку Кластера.

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

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

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

10. Нажмите Назад к списку кластеров чтобы вернуться к Кластеры странице. Эта Статус кластера является Конфигурация изменена. Когда Статус кластера изменяется на Доступно, характеристики узлов кластера были успешно изменены.