Обновление Elasticsearch 2.1.1 до 2.2.0 - отсутствует токен аутентификации?

Question

Я решил попробовать обновить текущий кластер с ES2.1.1 до ES2.2.0. Зеркальная пара. Кластер работает в AWS, поэтому я использую cloud-aws Плагин для общения.

Я успешно обновил первый узел, и он принял статус главного, но я столкнулся со странной проблемой связи / аутентификации при обновлении второго узла.

Я обратил внимание на руководящие принципы здесь, но я все еще, кажется, испытываю странную проблему.

Из основного журнала кластера на 2-м узле:

[2016-02-03 12:29:41,241][INFO ][discovery.ec2            ] [Sharon Ventura] failed to send join request to master [{Space Phantom}{NzN7b7ZHT8uPu6oXJAORMg}{10.60.164.147}{10.60.164.147:9300}], reason [RemoteTransportException[[Space Phantom][10.60.164.147:9300][internal:discovery/zen/join]]; nested: IllegalStateException[failure when sending a validation request to node]; nested: RemoteTransportException[[Sharon Ventura][10.60.163.74:9300][internal:discovery/zen/join/validate]]; nested: ElasticsearchSecurityException[missing authentication token for action [internal:discovery/zen/join/validate]]; ]
[2016-02-03 12:29:42,455][DEBUG][action.admin.cluster.health] [Sharon Ventura] no known master node, scheduling a retry
[2016-02-03 12:29:44,255][INFO ][discovery.ec2            ] [Sharon Ventura] failed to send join request to master [{Space Phantom}{NzN7b7ZHT8uPu6oXJAORMg}{10.60.164.147}{10.60.164.147:9300}], reason [RemoteTransportException[[Space Phantom][10.60.164.147:9300][internal:discovery/zen/join]]; nested: IllegalStateException[failure when sending a validation request to node]; nested: RemoteTransportException[[Sharon Ventura][10.60.163.74:9300][internal:discovery/zen/join/validate]]; nested: ElasticsearchSecurityException[missing authentication token for action [internal:discovery/zen/join/validate]]; ]
[2016-02-03 12:29:47,269][INFO ][discovery.ec2            ] [Sharon Ventura] failed to send join request to master [{Space Phantom}{NzN7b7ZHT8uPu6oXJAORMg}{10.60.164.147}{10.60.164.147:9300}], reason [RemoteTransportException[[Space Phantom][10.60.164.147:9300][internal:discovery/zen/join]]; nested: IllegalStateException[failure when sending a validation request to node]; nested: RemoteTransportException[[Sharon Ventura][10.60.163.74:9300][internal:discovery/zen/join/validate]]; nested: ElasticsearchSecurityException[missing authentication token for action [internal:discovery/zen/join/validate]]; ]
[2016-02-03 12:29:49,472][DEBUG][action.admin.cluster.state] [Sharon Ventura] timed out while retrying [cluster:monitor/state] after failure (timeout [30s])
[2016-02-03 12:29:49,473][INFO ][rest.suppressed          ] /_cluster/settings Params: {}
MasterNotDiscoveredException[null]
        at org.elasticsearch.action.support.master.TransportMasterNodeAction$AsyncSingleAction$5.onTimeout(TransportMasterNodeAction.java:205)
        at org.elasticsearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onTimeout(ClusterStateObserver.java:239)
        at org.elasticsearch.cluster.service.InternalClusterService$NotifyTimeout.run(InternalClusterService.java:794)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
[2016-02-03 12:29:50,283][INFO ][discovery.ec2            ] [Sharon Ventura] failed to send join request to master [{Space Phantom}{NzN7b7ZHT8uPu6oXJAORMg}{10.60.164.147}{10.60.164.147:9300}], reason [RemoteTransportException[[Space Phantom][10.60.164.147:9300][internal:discovery/zen/join]]; nested: IllegalStateException[failure when sending a validation request to node]; nested: RemoteTransportException[[Sharon Ventura][10.60.163.74:9300][internal:discovery/zen/join/validate]]; nested: ElasticsearchSecurityException[missing authentication token for action [internal:discovery/zen/join/validate]]; ]

Мой файл asticsearch.yml:

cluster.name: cluster01
http.cors.enabled: true
network.host: 0.0.0.0
discovery.type: ec2
discovery.ec2.tag.project_code_info: "cluster01"
cloud.aws.region: eu-central-1

Я вижу в журналах, что он обнаружил 1-й узел: [Space Phantom][10.60.164.147:9300]Он обнаружил это без какого-либо вмешательства, но, очевидно, не может подтвердить подлинность.

Я подозреваю, что это может быть связано с Shield Плагин, который также установлен, но правильные и идентичные разрешения настроены так же, как и раньше. Больше ничего не изменилось.

Я использую имя пользователя и пароль в щит, SSL не настроен.

Кто-нибудь может помочь?

Answer 1

Мне удалось понять это, как и @user3458016.

Мне удалось решить эту проблему, сбросив (на всех узлах) все настройки и конфигурации, удалив плагины license, shieldудаление всех пользователей и повторное добавление их всех, как и раньше. Эти конфигурации были идентичны с самого начала, так что это странно.

Во-первых, остановите эластичный поиск на всех узлах. Остановите кибану, если работаете локально.

Если у вас есть какие-либо пользовательские роли, проверьте конфигурацию этого в /etc/elasticsearch/shield/roles.ymlобновите это из одной записанной конфигурации, если это возможно.

удалить плагины:

/usr/share/elasticsearch/bin/plugin remove elasticsearch/license/latest/usr/share/elasticsearch/bin/plugin remove elasticsearch/shield/latest

удалить пользователей:

/usr/share/elasticsearch/bin/shield/esusers userdel admin/usr/share/elasticsearch/bin/shield/esusers userdel logstash

повторно добавить плагины:

/usr/share/elasticsearch/bin/plugin install elasticsearch/license/latest -b/usr/share/elasticsearch/bin/plugin install elasticsearch/shield/latest -b

повторно добавить пользователей:

/usr/share/elasticsearch/bin/shield/esusers useradd admin -p adminuserpw -r admin/usr/share/elasticsearch/bin/shield/esusers useradd logstash -p logstashuserpw -r logstash

Если у вас есть пользовательские роли, дважды проверьте конфигурацию этого в /etc/elasticsearch/shield/roles.yml чтобы убедиться, что конфигурация не была изменена или перезаписана.

Начните поиск на первом узле. Запустите кибану, если работаете локально.

Проверьте правильность определения индексов и проверьте статус главного узла.

Выполните все вышеуказанные шаги на всех других узлах.

Начните поиск по остальным узлам, по одному за раз. Проверьте правильность репликации кластера перед запуском следующего узла.

Я надеюсь, что кто-то найдет это полезным.