Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.
Если узел в кластере Elasticsearch неисправен, его можно заменить для восстановления сервисов.
Процесс замены узла выглядит следующим образом:
Перенесите данные с узла, который необходимо заменить, на другие доступные узлы.
Создайте новый узел, используя текущий ID, IP‑адрес, характеристики и AZ этого узла.
Добавьте новый узел в кластер. Система автоматически инициирует перераспределение шардов, перемещая часть шардов на новый узел.
Этот процесс не прерывает сервисы, поскольку данные мигрируют с заменённого узла на другие доступные узлы.
Ограничения
Одновременно можно заменить только один узел. Каждый новый узел создаётся с использованием ID, IP‑адреса, характеристик и AZ узла, который он заменяет.
Конфигурации, изменённые вручную, не сохранятся после замены узла. Например, если вы вручную добавили обратный маршрут для исходного узла, его необходимо добавить повторно для нового узла после завершения замены.
Если заменяемый узел является узлом данных или узлом холодных данных, обратите внимание на следующие предосторожности:
При замене узла данных или узла холодных данных его данные сначала мигрируют на другие узлы данных. Это означает, что общее количество узлов данных и узлов холодных данных должно быть больше максимального количества реплик индекса плюс 1.
Кластеры Elasticsearch версии ниже 7.6.2 не могут иметь закрытых индексов. В противном случае их узлы данных или узлы холодных данных нельзя заменить.
В AZ, содержащем заменяемый узел данных или узел холодных данных, должен быть как минимум ещё один узел данных или узел холодных данных.
Если в кластере нет мастер‑узлов, общее количество узлов данных и узлов холодных данных должно быть не менее трёх.
Приведённые выше меры предосторожности не применяются, если вы заменяете неисправный узел, независимо от его типа. Это происходит потому, что неисправные узлы не включены в _cat/nodes.
Влияние изменений
Перед заменой узла необходимо оценить потенциальные последствия и изучить операционные рекомендации. Это позволяет правильно спланировать замену узла, минимизируя прерывания обслуживания.
Влияние на производительность
Замена узла не прерывает сервисы. Однако миграция данных, происходящая в этом процессе, потребляет I/O‑производительность, и вывод отдельных узлов из эксплуатации всё же оказывает некоторое влияние на общую производительность кластера.
Чтобы минимизировать это влияние, рекомендуется регулировать скорость миграции данных в зависимости от цикла трафика кластера: увеличивать скорость миграции данных в часы низкой нагрузки, чтобы сократить продолжительность задачи, и уменьшать её до наступления пиковых часов, чтобы обеспечить оптимальную производительность кластера. Скорость миграции данных определяется параметром indices.recovery.max_bytes_per_sec. Значение параметра по умолчанию равно количеству vCPU, умноженному на 8 МБ. Например, для четырёх vCPU скорость миграции данных составляет 32 МБ/с. Вы можете изменить её в соответствии с требованиями сервиса.
PUT /_cluster/settings
{
"transient": {
"indices.recovery.max_bytes_per_sec": "128MB"
}
}
Влияние на обработку запросов
Пока узел заменяется, запросы, отправленные к нему, могут завершаться с ошибкой. Чтобы смягчить это влияние, можно принять следующие меры:
Используйте VPC endpoint или выделенный балансировщик нагрузки для обработки запросов доступа к вашему кластеру, что гарантирует автоматическую маршрутизацию запросов к доступным узлам.
Включите механизм экспоненциального отката & повторных попыток на клиенте (настройте три попытки).
Выполняйте эту операцию в часы низкой нагрузки.
Характеристики этого процесса
После запуска задачу замены узла нельзя остановить, пока она не завершится успешно или с ошибкой. Сбой задачи влияет только на один узел и не прерывает сервисы, если существуют реплики данных, однако неисправный узел всё же необходимо быстро восстановить.
Продолжительность замены узла
Для оценки времени, необходимого для замены указанного узла кластера, можно использовать следующую формулу:
Время изменения (min) = 15 (min) + Время миграции данных (min)
где 15 минут указывает, как долго обычно занимают операции, не связанные с миграцией данных (например, инициализация) на каждый node. Это эмпирическое значение.
Время миграции данных (min) = Общий размер данных (MB)/[Общее количество vCPU данных node x 8 (MB/s) x 60 (s)]
где,
8 MB/s указывает, что каждый vCPU может обрабатывать 8 MB данных в секунду. Это эмпирическое значение.
Приведённые выше формулы используют оценки при идеальных условиях. Фактическая скорость миграции зависит от нагрузки Кластера.
В панели навигации слева выберите Clusters > Elasticsearch.
В списке Кластеров найдите целевой кластер и выберите More > Modify Configuration в столбце Operation. Отобразится страница Modify Configuration.
На странице Modify Configuration нажмите вкладку Replace Node.
На вкладке Replace Node задайте параметры по необходимости.
Table 1 Замена указанного узла
Parameter
Description
Node Type
Выберите узел, который хотите заменить. Вы можете развернуть тип узла, чтобы проверить все узлы под ним.
Нажмите Submit. В диалоговом окне подтверждения миграции данных выберите миграцию данных и нажмите OK.
Во время миграции данных система переносит все данные с заменяемого узла на оставшиеся узлы и заменяет узел после завершения миграции данных. Если данные на заменяемых узлах имеют реплики на других узлах, миграцию данных можно пропустить, и изменение кластера будет выполнено быстрее.
Нажмите Back to Cluster List, чтобы вернуться на страницу Clusters. Статус Task Status — Replacing nodes. Когда Cluster Status меняется на Available, узел успешно заменён.