Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.
Если узел в Elasticsearch кластере неисправен, его можно заменить для восстановления сервисов.
Процесс замены узла выглядит следующим образом:
Перенесите данные с узла, который нужно заменить, на другие доступные узлы.
Создайте новый узел, используя текущие ID, IP‑адрес, характеристики и AZ этого узла.
Добавьте новый узел в кластер. Система автоматически инициирует перераспределение шардов, перемещая часть шардов на новый узел.
Этот процесс не прерывает сервисы, потому что данные мигрируют с заменённого узла на другие доступные узлы.
Ограничения
Только один узел может быть заменён за раз. Каждый новый узел создаётся с использованием ID, IP‑адреса, характеристик и AZ узла, который он заменяет.
Конфигурации, изменённые вручную, не сохранятся после замены узла. Например, если вы вручную добавили обратный маршрут для исходного узла, его необходимо добавить повторно для нового узла после завершения замены.
Если узел, который вы хотите заменить, является узлом данных или холодным узлом данных, обратите внимание на следующие предосторожности:
Когда узел данных или холодный узел данных заменяется, его данные сначала мигрируют на другие узлы данных. Это означает, что общее количество узлов данных и холодных узлов данных должно быть больше максимального количества реплик индекса плюс 1.
Кластеры Elasticsearch, версия которых раннее 7.6.2, не могут иметь закрытые индексы. В противном случае их узлы данных или холодные узлы данных нельзя заменить.
В AZ, содержащем узел данных или холодный узел данных, который нужно заменить, должна быть как минимум еще один узел данных или холодный узел данных.
Если в кластере нет master-узлов, общее количество узлов данных плюс холодных узлов данных должно быть не менее трех.
Вышеуказанные предосторожности не применяются, если вы заменяете неисправный узел, независимо от его типа. Это происходит потому, что неисправные узлы не включаются в _cat/nodes.
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 эндпоинт или выделенный балансировщик нагрузки для обработки запросов доступа к вашему кластеру, что обеспечивает автоматическую маршрутизацию запросов к доступным узлам.
Включите механизм экспоненциального отката и повторных попыток на клиенте (установите три повторные попытки).
Выполняйте эту операцию в непиковые часы.
Характеристики этого процесса
После запуска задачу замены узла нельзя остановить, пока она не завершится успешно или с ошибкой. Ошибка задачи затрагивает только один узел и не прерывает сервисы, если существуют реплики данных, однако неисправный узел всё равно необходимо быстро восстановить.
Продолжительность замены узла
Следующую формулу можно использовать для оценки времени, необходимого для замены указанного узла кластера:
Продолжительность изменения (мин) = 15 (мин) + Продолжительность миграции данных (мин)
где 15 минут указывает типичную продолжительность операций без миграции данных (например, инициализация) на один узел. Это эмпирическое значение.
Продолжительность миграции данных (мин) = Общий размер данных (MB)/[Общее количество vCPU узлов данных x 32 (MB/s) x 60 (s)]
где,
32 MB/s указывает, что каждый vCPU может обрабатывать 32 MB данных в секунду. Это эмпирическое значение.
Приведённые выше формулы используют оценки при идеальных условиях. Фактическая скорость миграции зависит от нагрузки кластера.
В левой панели навигации выберите Кластеры > Elasticsearch.
В списке кластеров найдите целевой кластер и выберите Больше > Modify Configuration в Operation столбец. Эта Modify Configuration страница отображается.
На Modify Configuration страница, щелкните Replace Node вкладка.
On the Replace Node вкладка, задайте параметры по мере необходимости.
Table 1 Замена указанного узла
Parameter
Description
Node Type
Выберите узел, который хотите заменить. Вы можете развернуть тип узла, чтобы проверить все узлы под ним.
Нажмите Отправить. В диалоговом окне подтверждения миграции данных выберите миграцию данных и нажмите OK.
Во время миграции данных система переносит все данные с заменяемого узла на оставшиеся узлы и заменяет узел после завершения миграции данных. Если данные на заменяемых узлах имеют реплики на других узлах, миграцию данных можно пропустить, и изменение кластера будет выполнено быстрее.
Нажмите Назад к списку кластеров чтобы вернуться к Кластеры странице. Эта Статус задачи является Замена узлов. Когда Статус кластера изменения Доступно, узел был успешно заменен.