› › ›

Отладка удаленных кластеров

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

Общая отладка

Проверка успешного подключения удаленного кластера

Успешный вызов API для обновления настроек кластера для добавления или обновления удаленных кластеров не обязательно означает успешную конфигурацию. Используйте API информации об удаленном кластере, чтобы проверить, успешно ли локальный кластер подключен к удаленному кластеру.

resp = client.cluster.remote_info()
print(resp)

response = client.cluster.remote_info
puts response

const response = await client.cluster.remoteInfo();
console.log(response);

GET /_remote/info

API должен вернуть "connected" : true. При использовании аутентификации по API-ключу, он также должен вернуть "cluster_credentials": "::es_redacted::".

{
  "cluster_one" : {
    "seeds" : [
      "127.0.0.1:9443"
    ],
    "connected" : true, 
    "num_nodes_connected" : 1,
    "max_connections_per_cluster" : 3,
    "initial_connect_timeout" : "30s",
    "skip_unavailable" : false,
    "cluster_credentials": "::es_redacted::", 
    "mode" : "sniff"
  }
}

	Удаленный кластер успешно подключился.
	Если присутствует, указывает, что удаленный кластер подключился с помощью аутентификации по API-ключу, а не аутентификации по сертификату.

Включение сервера удаленного кластера

При использовании аутентификации по API-ключу кросс-кластерный трафик происходит по интерфейсу удаленного кластера, а не по транспортному интерфейсу. Интерфейс удаленного кластера по умолчанию не включен. Это означает, что узел по умолчанию не готов принимать входящие кросс-кластерные запросы, в то время как он готов отправлять исходящие кросс-кластерные запросы. Убедитесь, что вы включили сервер удаленного кластера на каждом узле удаленного кластера. В elasticsearch.yml:

Установите remote_cluster_server.enabled на значение true.
Настройте адрес привязки и публикации для трафика сервера удаленного кластера, например, с помощью remote_cluster.host. Без настройки адреса трафик удаленного кластера может быть привязан к локальному интерфейсу, и удаленные кластеры, запущенные на других машинах, не смогут подключиться.
Дополнительно, настройте порт удаленного сервера с помощью remote_cluster.port (по умолчанию 9443).

Распространённые проблемы

Следующие проблемы перечислены в порядке их возможного возникновения при настройке удаленного кластера.

Удаленный кластер недоступен

Симптомы

Локальный кластер может не иметь возможности подключиться к удаленному кластеру по многим причинам. Например, сервер удаленного кластера может быть не включен, может быть настроена неправильная хост или порт или сетевой экран может блокировать трафик. Если удаленный кластер недоступен, проверьте журналы локального кластера для connect_exception.

Когда удалённый кластер настроен в режиме прокси:

[2023-06-28T16:36:47,264][WARN ][o.e.t.ProxyConnectionStrategy] [local-node] failed to open any proxy connections to cluster [my]
org.elasticsearch.transport.ConnectTransportException: [][192.168.0.42:9443] connect_exception

Когда удалённый кластер настроен в режиме сканирования:

[2023-06-28T16:38:37,731][WARN ][o.e.t.SniffConnectionStrategy] [local-node] fetching nodes from external cluster [my] failed
org.elasticsearch.transport.ConnectTransportException: [][192.168.0.42:9443] connect_exception

Решение

Убедитесь, что хост и порт для удаленного кластера правильные.
Убедитесь, что сервер удаленного кластера включен на удаленном кластере.
Убедитесь, что сетевой экран не блокирует соединение.

Подключение к удаленному кластеру ненадёжное

Симптомы

Локальный кластер может подключаться к удалённому кластеру, но подключение работает не надёжно. Например, некоторые кросс-кластерные запросы могут быть успешными, в то время как другие сообщают об ошибках подключения, таймаутах или выглядят как зависающие в ожидании ответа от удалённого кластера.

Когда Elasticsearch обнаруживает, что подключение к удаленному кластеру не работает, он запишет в свои логи следующее сообщение:

[2023-06-28T16:36:47,264][INFO ][o.e.t.ClusterConnectionManager] [local-node] transport connection to [{my-remote#192.168.0.42:9443}{...}] closed by remote

Это сообщение также будет записано, если узел удаленного кластера, к которому подключен Elasticsearch, выключится или перезапустится.

Обратите внимание, что в некоторых сетевых конфигурациях операционной системе может потребоваться несколько минут или часов, чтобы определить, что соединение перестало работать. До тех пор, пока ошибка не будет обнаружена и сообщена Elasticsearch, запросы, связанные с удаленным кластером, могут истечь или казаться зависшими.

Решение

Убедитесь, что сеть между кластерами является максимально надёжной.
Убедитесь, что сеть настроена для разрешения долгоживущих соединений бездействия.
Убедитесь, что сеть настроена для быстрого обнаружения неисправных подключений. В частности, вы должны включить и полностью поддерживать TCP keepalives и установить короткий таймаут повторной передачи.
В системах Linux выполните ss -tonie, чтобы проверить детали конфигурации каждого сетевого подключения между кластерами.
Если проблемы сохраняются, зафиксируйте сетевые пакеты на обоих концах соединения и проанализируйте трафик, чтобы найти задержки и потерянные сообщения.

Доверие TLS не установлено

TLS может быть неправильно настроен на локальном или удалённом кластере. В результате локальный кластер не доверяет сертификату, представленному удалённым кластером.

Симптомы

Локальный кластер записывает в журналы failed to establish trust with server:

[2023-06-29T09:40:55,465][WARN ][o.e.c.s.DiagnosticTrustManager] [local-node] failed to establish trust with server at [192.168.0.42]; the server provided a certificate with subject name [CN=remote_cluster], fingerprint [529de35e15666ffaa26afa50876a2a48119db03a], no keyUsage and no extendedKeyUsage; the certificate is valid between [2023-01-29T12:08:37Z] and [2032-08-29T12:08:37Z] (current time is [2023-08-16T23:40:55.464275Z], certificate dates are valid); the session uses cipher suite [TLS_AES_256_GCM_SHA384] and protocol [TLSv1.3]; the certificate has subject alternative names [DNS:localhost,DNS:localhost6.localdomain6,IP:127.0.0.1,IP:0:0:0:0:0:0:0:1,DNS:localhost4,DNS:localhost6,DNS:localhost.localdomain,DNS:localhost4.localdomain4,IP:192.168.0.42]; the certificate is issued by [CN=Elastic Auto RemoteCluster CA] but the server did not provide a copy of the issuing certificate in the certificate chain; this ssl context ([(shared) (with trust configuration: JDK-trusted-certs)]) is not configured to trust that issuer but trusts [97] other issuers
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Удаленный кластер записывает в журналы client did not trust this server's certificate:

[2023-06-29T09:40:55,478][WARN ][o.e.x.c.s.t.n.SecurityNetty4Transport] [remote-node] client did not trust this server's certificate, closing connection Netty4TcpChannel{localAddress=/192.168.0.42:9443, remoteAddress=/192.168.0.84:57305, profile=_remote_cluster}

Решение

Внимательно прочтите сообщение в журнале с предупреждениями локального кластера, чтобы определить точную причину сбоя. Например:

Сертификат удалённого кластера не подписан доверенной организацией? Это наиболее вероятная причина.
Проверка имени хоста не удалась?
Сертификат истек?

После того, как вы узнаете причину, вы должны сможете исправить её, скорректировав настройки SSL, связанные с удалённым кластером, либо на локальном, либо на удалённом кластере.

Часто проблема возникает на локальном кластере. Например, исправьте её, настроив необходимые доверенные организации (xpack.security.remote_cluster_client.ssl.certificate_authorities).

Если вы измените файл elasticsearch.yml, соответствующий кластер необходимо перезапустить, чтобы изменения вступили в силу.

Проблемы с аутентификацией по API-ключам

Подключение к порту транспорта при использовании аутентификации по API-ключам

При использовании аутентификации по API-ключам локальный кластер должен подключаться к порту сервера удаленного кластера (по умолчанию 9443), а не к порту транспорта (по умолчанию 9300). Неправильная конфигурация может привести к ряду симптомов:

Симптом 1

Рекомендуется использовать разные сертификаты и центры сертификации (CA) для интерфейса транспорта и интерфейса сервера удаленного кластера. Если это рекомендация соблюдается, узел клиента удаленного кластера не доверяет сертификату сервера, предоставленному удаленным кластером по интерфейсу транспорта.

В логах локального кластера отображается failed to establish trust with server:

[2023-06-28T12:48:46,575][WARN ][o.e.c.s.DiagnosticTrustManager] [local-node] failed to establish trust with server at [1192.168.0.42]; the server provided a certificate with subject name [CN=transport], fingerprint [c43e628be2a8aaaa4092b82d78f2bc206c492322], no keyUsage and no extendedKeyUsage; the certificate is valid between [2023-01-29T12:05:53Z] and [2032-08-29T12:05:53Z] (current time is [2023-06-28T02:48:46.574738Z], certificate dates are valid); the session uses cipher suite [TLS_AES_256_GCM_SHA384] and protocol [TLSv1.3]; the certificate has subject alternative names [DNS:localhost,DNS:localhost6.localdomain6,IP:127.0.0.1,IP:0:0:0:0:0:0:0:1,DNS:localhost4,DNS:localhost6,DNS:localhost.localdomain,DNS:localhost4.localdomain4,IP:192.168.0.42]; the certificate is issued by [CN=Elastic Auto Transport CA] but the server did not provide a copy of the issuing certificate in the certificate chain; this ssl context ([xpack.security.remote_cluster_client.ssl (with trust configuration: PEM-trust{/rcs2/ssl/remote-cluster-ca.crt})]) is not configured to trust that issuer, it only trusts the issuer [CN=Elastic Auto RemoteCluster CA] with fingerprint [ba2350661f66e46c746c1629f0c4b645a2587ff4]
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

В логах удаленного кластера отображается client did not trust this server's certificate:

[2023-06-28T12:48:46,584][WARN ][o.e.x.c.s.t.n.SecurityNetty4Transport] [remote-node] client did not trust this server's certificate, closing connection Netty4TcpChannel{localAddress=/192.168.0.42:9309, remoteAddress=/192.168.0.84:60810, profile=default}

Симптом 2

Центр сертификации (CA) и сертификат могут быть общими для интерфейса транспорта и интерфейса сервера удаленного кластера. Поскольку у клиента удаленного кластера по умолчанию нет клиентского сертификата, сервер не сможет проверить клиентский сертификат.

В логах локального кластера отображается Received fatal alert: bad_certificate:

[2023-06-28T12:43:30,705][WARN ][o.e.t.TcpTransport       ] [local-node] exception caught on transport layer [Netty4TcpChannel{localAddress=/192.168.0.84:60738, remoteAddress=/192.168.0.42:9309, profile=_remote_cluster}], closing connection
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

В логах удаленного кластера отображается Empty client certificate chain:

[2023-06-28T12:43:30,772][WARN ][o.e.t.TcpTransport       ] [remote-node] exception caught on transport layer [Netty4TcpChannel{localAddress=/192.168.0.42:9309, remoteAddress=/192.168.0.84:60783, profile=default}], closing connection
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Empty client certificate chain

Симптом 3

Если клиент удаленного кластера настроен для mTLS и предоставляет действительный клиентский сертификат, подключение завершается неудачно, поскольку клиент не отправляет ожидаемый заголовок аутентификации.

В логах локального кластера отображается missing authentication:

[2023-06-28T13:04:52,710][WARN ][o.e.t.ProxyConnectionStrategy] [local-node] failed to open any proxy connections to cluster [my]
org.elasticsearch.transport.RemoteTransportException: [remote-node][192.168.0.42:9309][cluster:internal/remote_cluster/handshake]
Caused by: org.elasticsearch.ElasticsearchSecurityException: missing authentication credentials for action [cluster:internal/remote_cluster/handshake]

В логах удаленного кластера это не отображается.

Симптом 4

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

Если у анонимного пользователя нет необходимых привилегий для подключения, локальный кластер отображает unauthorized:

org.elasticsearch.transport.RemoteTransportException: [remote-node][192.168.0.42:9309][cluster:internal/remote_cluster/handshake]
Caused by: org.elasticsearch.ElasticsearchSecurityException: action [cluster:internal/remote_cluster/handshake] is unauthorized for user [anonymous_foo] with effective roles [reporting_user], this action is granted by the cluster privileges [cross_cluster_search,cross_cluster_replication,manage,all]

Если у анонимного пользователя есть необходимые привилегии, например, это суперпользователь, локальный кластер отображает requires channel profile to be [_remote_cluster], but got [default]:

[2023-06-28T13:09:52,031][WARN ][o.e.t.ProxyConnectionStrategy] [local-node] failed to open any proxy connections to cluster [my]
org.elasticsearch.transport.RemoteTransportException: [remote-node][192.168.0.42:9309][cluster:internal/remote_cluster/handshake]
Caused by: java.lang.IllegalArgumentException: remote cluster handshake action requires channel profile to be [_remote_cluster], but got [default]

Решение

Проверьте номер порта и убедитесь, что вы подключаетесь к серверу удаленного кластера, а не к интерфейсу транспорта.

Подключение без межкластерного API-ключа

Локальный кластер использует наличие межкластерного API-ключа для определения модели, с помощью которой он подключается к удаленному кластеру. Если межкластерный API-ключ присутствует, используется аутентификация на основе API-ключа. В противном случае используется аутентификация на основе сертификатов. Вы можете проверить используемую модель с помощью API информации о удаленном кластере remote cluster info API на локальном кластере:

resp = client.cluster.remote_info()
print(resp)

response = client.cluster.remote_info
puts response

const response = await client.cluster.remoteInfo();
console.log(response);

GET /_remote/info

API должно вернуть "connected" : true. При использовании аутентификации по API-ключам также должно возвращаться значение "cluster_credentials": "::es_redacted::".

{
  "cluster_one" : {
    "seeds" : [
      "127.0.0.1:9443"
    ],
    "connected" : true, 
    "num_nodes_connected" : 1,
    "max_connections_per_cluster" : 3,
    "initial_connect_timeout" : "30s",
    "skip_unavailable" : false,
    "cluster_credentials": "::es_redacted::", 
    "mode" : "sniff"
  }
}

	Удаленный кластер успешно подключился.
	Если присутствует, указывает, что удаленный кластер подключился с использованием аутентификации по API-ключам, а не аутентификации на основе сертификатов.

Помимо проверки ответа API информации о удаленном кластере, вы также можете проверить логи.

Симптом 1

Если межкластерный API-ключ не используется, локальный кластер использует метод аутентификации на основе сертификатов и подключается к удаленному кластеру с использованием конфигурации TLS интерфейса транспорта. Если у удаленного кластера разные центры сертификации (CA) и сертификаты для интерфейсов транспорта и сервера удаленного кластера (что рекомендуется), проверка TLS завершится ошибкой.

В логах локального кластера отображается failed to establish trust with server:

[2023-06-28T12:51:06,452][WARN ][o.e.c.s.DiagnosticTrustManager] [local-node] failed to establish trust with server at [<unknown host>]; the server provided a certificate with subject name [CN=remote_cluster], fingerprint [529de35e15666ffaa26afa50876a2a48119db03a], no keyUsage and no extendedKeyUsage; the certificate is valid between [2023-01-29T12:08:37Z] and [2032-08-29T12:08:37Z] (current time is [2023-06-28T02:51:06.451581Z], certificate dates are valid); the session uses cipher suite [TLS_AES_256_GCM_SHA384] and protocol [TLSv1.3]; the certificate has subject alternative names [DNS:localhost,DNS:localhost6.localdomain6,IP:127.0.0.1,IP:0:0:0:0:0:0:0:1,DNS:localhost4,DNS:localhost6,DNS:localhost.localdomain,DNS:localhost4.localdomain4,IP:192.168.0.42]; the certificate is issued by [CN=Elastic Auto RemoteCluster CA] but the server did not provide a copy of the issuing certificate in the certificate chain; this ssl context ([xpack.security.transport.ssl (with trust configuration: PEM-trust{/rcs2/ssl/transport-ca.crt})]) is not configured to trust that issuer, it only trusts the issuer [CN=Elastic Auto Transport CA] with fingerprint [bbe49e3f986506008a70ab651b188c70df104812]
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

В логах удаленного кластера отображается client did not trust this server's certificate:

[2023-06-28T12:52:16,914][WARN ][o.e.x.c.s.t.n.SecurityNetty4Transport] [remote-node] client did not trust this server's certificate, closing connection Netty4TcpChannel{localAddress=/192.168.0.42:9443, remoteAddress=/192.168.0.84:60981, profile=_remote_cluster}

Симптом 2

Даже если проверка TLS не является проблемой, подключение завершается ошибкой из-за отсутствия учетных данных.

В логах локального кластера отображается Please ensure you have configured remote cluster credentials:

Caused by: java.lang.IllegalArgumentException: Cross cluster requests through the dedicated remote cluster server port require transport header [_cross_cluster_access_credentials] but none found. Please ensure you have configured remote cluster credentials on the cluster originating the request.

В логах удаленного кластера это не отображается.

Решение

Добавьте межкластерный API-ключ в хранилище ключей Elasticsearch на каждом узле локального кластера. Перезагрузите хранилище ключей с помощью API Nodes reload secure settings.

Использование неправильного типа API-ключа

Аутентификация на основе API-ключей требует межкластерных API-ключей. Она не работает с API-ключами REST.

Симптом

В логах локального кластера отображается authentication expected API key type of [cross_cluster]:

[2023-06-28T13:26:53,962][WARN ][o.e.t.ProxyConnectionStrategy] [local-node] failed to open any proxy connections to cluster [my]
org.elasticsearch.transport.RemoteTransportException: [remote-node][192.168.0.42:9443][cluster:internal/remote_cluster/handshake]
Caused by: org.elasticsearch.ElasticsearchSecurityException: authentication expected API key type of [cross_cluster], but API key [agZXJocBmA2beJfq2yKu] has type [rest]

В логах удаленного кластера это не отображается.

Решение

Попросите администратора удаленного кластера создать и распространить межкластерный API-ключ. Замените существующий API-ключ в хранилище ключей Elasticsearch на этот межкластерный API-ключ на каждом узле локального кластера. Перезагрузите хранилище ключей с помощью API Nodes reload secure settings.

Недействительный API-ключ

Межкластерный API может не пройти аутентификацию. Например, когда его учетные данные неверны, или если он аннулирован или истек.

Симптом

В логах локального кластера отображается unable to authenticate:

[2023-06-28T13:22:58,264][WARN ][o.e.t.ProxyConnectionStrategy] [local-node] failed to open any proxy connections to cluster [my]
org.elasticsearch.transport.RemoteTransportException: [remote-node][192.168.0.42:9443][cluster:internal/remote_cluster/handshake]
Caused by: org.elasticsearch.ElasticsearchSecurityException: unable to authenticate user [agZXJocBmA2beJfq2yKu] for action [cluster:internal/remote_cluster/handshake]

В логах удаленного кластера отображается Authentication using apikey failed:

[2023-06-28T13:24:38,744][WARN ][o.e.x.s.a.ApiKeyAuthenticator] [remote-node] Authentication using apikey failed - invalid credentials for API key [agZXJocBmA2beJfq2yKu]

Решение

API-ключ или локальный пользователь не имеют достаточных привилегий

Эффективные разрешения для локального пользователя, выполняющего запросы на удаленный кластер, определяются пересечением привилегий межкластерного API-ключа и привилегий локального пользователя.

Симптом

Ошибки запросов из-за недостаточных привилегий приводят к ответам API, таким как:

{
    "type": "security_exception",
    "reason": "action [indices:data/read/search] towards remote cluster is unauthorized for user [foo] with assigned roles [foo-role] authenticated by API key id [agZXJocBmA2beJfq2yKu] of user [elastic-admin] on indices [cd], this action is granted by the index privileges [read,all]"
}

Это не отображается в каких-либо логах.

Решение

Убедитесь, что у локального пользователя есть необходимые remote_indices или remote_cluster привилегии. Предоставьте достаточные remote_indices или remote_cluster привилегии, если необходимо.
Если проблема с правами не на стороне локального кластера, попросите администратора удаленного кластера создать и распространить межкластерный API-ключ. Замените существующий API-ключ в хранилище ключей Elasticsearch на этот межкластерный API-ключ на каждом узле локального кластера. Перезагрузите хранилище ключей с помощью API Nodes reload secure settings.

У локального пользователя нет привилегий `remote_indices`

Это особый случай недостаточных привилегий. В этом случае у локального пользователя вообще нет привилегий remote_indices для целевого удалённого кластера. Elasticsearch может это обнаружить и выдать более явный ответ об ошибке.

Симптомы

Это приводит к ответам API, таким как:

{
    "type": "security_exception",
    "reason": "action [indices:data/read/search] towards remote cluster [my] is unauthorized for user [foo] with effective roles [] (assigned roles [foo-role] were not found) because no remote indices privileges apply for the target cluster"
}

Решение

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

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/8.17/remote-clusters-troubleshooting.html

Отладка удаленных кластеров

Общая отладка

Проверка успешного подключения удаленного кластера

Включение сервера удаленного кластера

Распространённые проблемы

Удаленный кластер недоступен

Симптомы

Решение

Подключение к удаленному кластеру ненадёжное

Симптомы

Решение

Доверие TLS не установлено

Симптомы

Решение

Проблемы с аутентификацией по API-ключам

Подключение к порту транспорта при использовании аутентификации по API-ключам

Симптом 1

Симптом 2

Симптом 3

Симптом 4

Решение

Подключение без межкластерного API-ключа

Симптом 1

Симптом 2

Решение

Использование неправильного типа API-ключа

Симптом

Решение

Недействительный API-ключ

Симптом

Решение

API-ключ или локальный пользователь не имеют достаточных привилегий

Симптом

Решение

У локального пользователя нет привилегий remote_indices

Симптомы

Решение

У локального пользователя нет привилегий `remote_indices`