В этой статье объясняются различные механизмы обнаружения, ключевые настройки, обнаружение неисправностей, связанные журналы и многое другое. Обнаружение является важной темой при запуске кластера Elasticsearch. Обнаружение узлов внутри кластера или проведение выборов мастера - вот две основные задачи модуля обнаружения. Цель этой статьи - поделиться основными понятиями об обнаружении в Elasticsearch, чтобы вы могли лучше настроить свой кластер или лучше выполнять операции с ним.
Многоадресное обнаружение (Multicast Discovery)
Многоадресного обнаружения больше не существует. Оно было доступно только в виде плагина, начиная с Elasticsearch 2.0, и этот плагин был удален в Elasticsearch 5.0.
Одноадресное обнаружение (Unicast Discovery)
Одноадресное обнаружение настраивает статический список узлов для использования в качестве начальных узлов. Эти узлы могут быть указаны как имена хостов или IP-адреса; узлы, указанные как имена хостов, преобразуются в IP-адреса во время каждого раунда пингования. Вот пример одноадресной конфигурации в конфигурационном файле Elasticsearch (elasticsearch.yml):
| 1 | discovery.zen.ping.unicast.hosts: ["10.0.0.3", "10.0.0.4", "10.0.0.5"] |
Не все узлы Elasticsearch в кластере должны присутствовать в одноадресном списке для обнаружения всех узлов, но необходимо настроить достаточно адресов, чтобы каждый узел знал о доступном узле-сплетнике.
Обнаружение на основе файлов
В дополнение к хостам, предоставляемым настройкой discovery.zen.ping.unicast.hosts, вы можете предоставить список хостов из внешнего файла. Elasticsearch может обнаружить изменения в этом файле и перезагрузить его, так что список начальных хостов может быть изменен динамически без необходимости перезапуска узла. Чтобы включить обнаружение на основе файлов, настройте провайдера файловых хостов следующим образом:
| 1 | discovery.zen.hosts_provider: file |
Затем необходимо создать новый файл в каталоге конфигурации Elasticsearch как $ES_PATH_CONF/unicast_hosts.txt в следующем формате.
| 1 2 | 10.0.0.6 10.0.0.7 |
В сочетании со значениями, определенными в discovery.zen.ping.unicast.hosts в предыдущем разделе, окончательный список seed-хостов будет 10.0.0.{2,3,4,5,6,7}, поскольку используются как значения, определенные в unicast, так и определенные в файле unicast_hosts.txt.
Настройки обнаружения
В Elasticsearch есть две важные настройки для обнаружения, их следует настроить перед запуском:
- discovery.zen.ping.unicast.hosts
- discovery.zen.minimum_master_nodes
discovery.zen.ping.unicast.hosts
Эта настройка определяет статический список узлов для использования в качестве начальных узлов для Zen discovery. Эти узлы могут быть указаны как имена хостов или IP-адреса; узлы, указанные как имена хостов, преобразуются в IP-адреса во время каждого раунда пинга. Каждое значение должно быть в форме host:port или host. Другими словами, порт хоста является необязательным. Если порт пустой, то по умолчанию используется параметр transport.profiles.default.port, который возвращается к transport.port, если не задан. Имя хоста, которое разрешается в несколько IP-адресов, будет пробовать все разрешенные адреса. Можно также указать адреса IPv6. Кроме того, параметр discovery.zen.ping.unicast.resolve_timeout задает время ожидания поиска DNS в каждом раунде пинга. Оно задается в единицах времени и по умолчанию равно 5 с.
discovery.zen.minimum_master_nodes
Этот параметр определяет минимальное количество узлов с правами мастера для формирования кластера. Это очень важно для правильного формирования кластера и предотвращения потери данных. Без этого параметра кластер может пострадать, когда часть кластера (один или несколько узлов) теряет связь с главным узлом и формирует новый кластер. Это означает, что два разных кластера Elasticsearch работают независимо друг от друга. Чтобы этого не произошло, установите минимальное количество master-узлов как половину от количества master-eligible узлов плюс один, т.е. минимальное значение должно быть:
(master_nodes / 2) + 1
Например, если у вас 3 узла, пригодных для работы с мастерами, установите минимальное количество узлов как 2, потому что "(3 / 2) + 1 = 2".
discovery.zen.minimum_master_nodes: 2
Обнаружение неисправностей
Обнаружение неисправностей гарантирует, что главный узел и другие узлы подключены и "здоровы", так что выборы главного узла или удаление узла не требуются. С одной стороны, избранный мастер периодически проверяет связь и здоровье каждого из узлов в кластере; с другой стороны, каждый узел в кластере проверяет здоровье избранного мастера. Эти проверки известны как "проверки последователя" и "проверки лидера". Elasticsearch позволяет этим проверкам время от времени давать сбой или тайм-аут. Он считает узел неисправным только после того, как несколько проверок подряд закончились неудачей. Ниже приведены параметры для настройки обнаружения неисправностей (fd):
- discovery.zen.fd.ping_interval Как часто пингуется узел. (По умолчанию 1 с)
- discovery.zen.fd.ping_timeout Как долго ждать ответа ping. (По умолчанию 30 с)
- discovery.zen.fd.ping_retries Сколько неудач/таймаутов пинга заставляет узел считаться неисправным. (По умолчанию равно 3)
Журналы
Недостаточное количество обнаруженных основных узлов во время пинга
Здесь приведены некоторые журналы, связанные с Zen Discovery, которые могут помочь вам определить проблему вашего кластера.
Недостаточное количество обнаруженных основных узлов во время проверки
| 1 | WARN: not enough master nodes discovered during pinging (found […], but need [2]), pinging again |
Во время пинга обнаружено недостаточно мастер-узлов. Было найдено только N узлов, пригодных для работы в качестве мастера, но минимально необходимых узлов - 2. Найденные узлы описаны в списке выше [...]. Это происходит, вероятно, потому, что один или несколько узлов, отвечающих требованиям мастера, были отключены от сети или выключены. Поэтому параметр discovery.zen.minimum_master_nodes не выполняется. Выборы мастера не могут произойти, потому что недостаточно мастеров для выбора. Это критическая ошибка, которая не позволяет кластеру полностью функционировать. Когда это происходит, по умолчанию операции записи будут отклонены. Операции чтения будут успешными, основываясь на последней известной конфигурации кластера. Если параметром discovery.zen.no_master_block является не опция по умолчанию (запись), а опция all, то будут отклонены как операции чтения, так и записи.
Мастер "ушел"
| 1 | WARN: master left (reason = failed to ping, tried [3] times, each with maximum [30s] timeout), current nodes: … |
Это часть обнаружения неисправностей как "проверка лидера". Узел не смог пропинговать ведущий узел после 3 раз, каждый из которых имеет тайм-аут не более 30 с, поэтому он считает, что ведущий узел покинут, и решает присоединиться к другому ведущему узлу. Перед этим список текущих узлов записывается в журнал, чтобы зафиксировать текущую ситуацию. Список узлов извлекается из состояния кластера. Это может произойти, когда возникают серьезные проблемы с сетью или ведущий узел отключается/останавливается.