Вот моя установка:

Два экземпляра Ubuntu 16.04. Второй клон сделан из первого. ElasticSearch устанавливается только на гостевые (Ubuntu) ОС. Конфигурация была скорректирована после клонирования ВМ.

Я работаю с мостовой сетью в VirtualBox - каждый экземпляр получил свой IP-адрес от маршрутизатора. Брандмауэр Windows (хост) настроен соответствующим образом. Все машины могут пинговать друг друга. Тестирование Ping, Netstat и nmap показывает, что порты 9200 и 9300 ОТКРЫТЫ (также проверены «удаленные» хосты).

Служба ElasticSearch работает надлежащим образом. Я могу "свернуть -XGET" как локально, так и удаленно и получить правильные результаты.

Проблема в том, что ES со второй машины не входит в кластер.

Вот файлы конфигурации:

Первый:

cluster.name: p4g4n_cluster
node.name: master
node.master: true
network.host: 192.168.0.12
discovery.zen.ping.unicast.hosts: ["192.168.0.12", "192.168.0.17"]

Второй:

cluster.name: p4g4n_cluster
node.name: node1
node.master: false
network.host: 192.168.0.17
discovery.zen.ping.unicast.hosts: ["192.168.0.12", "192.168.0.17"]

Если я попытаюсь curl -XGET 192.168.0.17:9200/_cluster/health, я получу master_not_discovered_exception. И если я попробую базовый запрос GET, я увижу, что node1 имеет _na _ для cluster_uuid" property, while on first machine - *master* cluster_uuid`.

Версия ElasticSearch работает: 5.4.0, а версия Lucene: 6.5.0

Может кто-нибудь помочь мне с тем, что должно произойти, чтобы node1 увидел и присоединился к кластеру?

1
Ivan Davidov 28 Май 2017 в 08:23

2 ответа

Лучший ответ

Я смог решить эту проблему.

Просмотр журналов показал, что это не проблема конфигурации сети.

Поскольку я сначала сконфигурировал весь стек ELK на одной машине, а затем клонировал его, ES и logstash уже работали и закачивали журналы системного журнала в эластик.

Из-за этого клонированная машина имела ту же папку с данными, что и существующая. Как оказалось, узел UUID встроен в папку данных, и решением было удалить папку данных на клонированной ВМ.

Ошибка, обнаруженная в журналах: обнаружил существующий узел {xxx} с тем же идентификатором, но это другой экземпляр узла ... Итак, произошел очевидный конфликт.

Я обнаружил эту проблему с github ES и эту SO answer, которая занималась той же проблемой.

2
Ivan Davidov 28 Май 2017 в 18:31

Вы можете попробовать добавить network.bind_host: 0.0.0.0 на обоих серверах

0
NGUYEN Nhu Van 28 Май 2017 в 10:18