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

Я решил попробовать обновить текущий кластер с 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]]; ]

Мой файл elasticsearch.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 не настроен.

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


authentication amazon-web-services elasticsearch elasticsearch-plugin elasticsearch-shield
person Kareem    schedule 03.02.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

Если у вас есть какие-либо настраиваемые роли, проверьте их конфигурацию в /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, чтобы убедиться, что конфигурация не была изменена или перезаписана.

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

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

Выполните все описанные выше действия на всех остальных узлах.

Запустите поиск elastics на оставшихся узлах, по одному. Перед запуском следующего узла проверьте исправность репликации кластера.

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

person Kareem    schedule 29.02.2016