リモートクラスターのトラブルシューティング

クロスクラスター複製やクロスクラスター検索のためにリモートクラスターを設定する際に、いくつかの問題に直面することがあります。

一般的なトラブルシューティング

リモートクラスターが正常に接続されているか確認する

リモートクラスターを追加または更新するためのクラスター設定更新APIへの成功した呼び出しは、必ずしも構成が成功したことを意味するわけではありません。ローカルクラスターがリモートクラスターに正常に接続されているかを確認するには、リモートクラスター情報APIを使用してください。

Python

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

Ruby

  1. response = client.cluster.remote_info
  2. puts response

Js

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

コンソール

  1. GET /_remote/info

APIは"connected" : trueを返すべきです。APIキー認証を使用している場合、"cluster_credentials": "::es_redacted::"も返すべきです。

コンソール-結果

  1. {
  2. "cluster_one" : {
  3. "seeds" : [
  4. "127.0.0.1:9443"
  5. ],
  6. "connected" : true,
  7. "num_nodes_connected" : 1,
  8. "max_connections_per_cluster" : 3,
  9. "initial_connect_timeout" : "30s",
  10. "skip_unavailable" : false,
  11. "cluster_credentials": "::es_redacted::",
  12. "mode" : "sniff"
  13. }
  14. }
リモートクラスターは正常に接続されました。
存在する場合、リモートクラスターは、
APIキー認証を使用して接続されていることを示します。
証明書ベースの認証の代わりに接続されています。

リモートクラスターサーバーの有効化

APIキー認証を使用する場合、クロスクラスターのトラフィックはリモートクラスターインターフェースで発生し、トランスポートインターフェースでは発生しません。リモートクラスターインターフェースはデフォルトでは有効になっていません。これは、ノードがデフォルトで受信クロスクラスターリクエストを受け入れる準備ができていないことを意味し、送信クロスクラスターリクエストを送信する準備ができていることを意味します。リモートクラスターのすべてのノードでリモートクラスターサーバーを有効にしたことを確認してください。elasticsearch.ymlの中で:

  • remote_cluster_server.enabledtrueに設定します。
  • リモートクラスターサーバートラフィックのバインドおよび公開アドレスを構成します。たとえば、remote_cluster.hostを使用します。アドレスを構成しないと、リモートクラスターのトラフィックがローカルインターフェースにバインドされ、他のマシンで実行されているリモートクラスターが接続できなくなる可能性があります。
  • 必要に応じて、remote_cluster.portを使用してリモートサーバーポートを構成します(デフォルトは9443です)。

一般的な問題

以下の問題は、リモートクラスターを設定する際に発生する可能性のある順序でリストされています。

リモートクラスターに到達できない

症状

ローカルクラスターがリモートクラスターに到達できない理由はいくつかあります。たとえば、リモートクラスターサーバーが有効になっていない、ホストまたはポートが不正確に設定されている、またはファイアウォールがトラフィックをブロックしている可能性があります。リモートクラスターに到達できない場合は、ローカルクラスターのログでconnect_exceptionを確認してください。

リモートクラスターがプロキシモードで構成されている場合:

Txt

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

リモートクラスターがスニッフモードで構成されている場合:

Txt

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

解決策

  • リモートクラスターのホストとポートが正しいことを確認してください。
  • リモートクラスターでリモートクラスターサーバーが有効になっていることを確認してください。
  • 通信をブロックしているファイアウォールがないことを確認してください。

リモートクラスター接続が不安定

症状

ローカルクラスターはリモートクラスターに接続できますが、接続が信頼できません。たとえば、いくつかのクロスクラスターリクエストが成功する一方で、他のリクエストは接続エラーを報告したり、タイムアウトしたり、リモートクラスターの応答を待っているように見えることがあります。

Elasticsearchがリモートクラスター接続が機能していないことを検出すると、ログに次のメッセージが報告されます:

Txt

  1. [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キープアライブを有効にし、完全にサポートし、短い再送信タイムアウトを設定する必要があります。
  • Linuxシステムでは、ss -tonieを実行して、クラスター間の各ネットワーク接続の構成の詳細を確認します。
  • 問題が続く場合は、接続の両端でネットワークパケットをキャプチャし、遅延や失われたメッセージを探すためにトラフィックを分析します。

TLS信頼が確立されていない

TLSはローカルまたはリモートクラスターで誤って構成される可能性があります。その結果、ローカルクラスターはリモートクラスターによって提示された証明書を信頼しません。

症状

ローカルクラスターのログにfailed to establish trust with server:

Txt

  1. [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
  2. 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:

Txt

  1. [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}

解決策

ローカルクラスターの警告ログメッセージを注意深く読み、障害の正確な原因を特定します。たとえば:

  • リモートクラスターの証明書は信頼できるCAによって署名されていませんか?これが最も可能性の高い原因です。
  • ホスト名の検証が失敗していますか?
  • 証明書は期限切れですか?

原因がわかれば、ローカルクラスターまたはリモートクラスターのリモートクラスター関連のSSL設定を調整することで修正できるはずです。

問題はしばしばローカルクラスターにあります。たとえば、必要な信頼できるCAを構成することで修正します(xpack.security.remote_cluster_client.ssl.certificate_authorities)。

  1. ## APIキー認証の問題
  2. ### APIキー認証を使用する際のトランスポートポートへの接続
  3. APIキー認証を使用する場合、ローカルクラスターはリモートクラスターのリモートクラスターサーバーポート(デフォルトは`````9443`````)に接続する必要があります。トランスポートポート(デフォルトは`````9300`````)ではありません。誤った構成は、いくつかの症状を引き起こす可能性があります:
  4. #### 症状1
  5. トランスポートインターフェースとリモートクラスターサーバーインターフェースに異なるCAと証明書を使用することをお勧めします。この推奨に従うと、リモートクラスタークライアントノードはトランスポートインターフェース上のリモートクラスターによって提示されたサーバー証明書を信頼しません。
  6. ローカルクラスターのログに`````failed to establish trust with server`````:
  7. #### Txt
  8. ``````txt
  9. [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]
  10. sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
  11. `

リモートクラスターのログにclient did not trust this server's certificate:

Txt

  1. [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:

Txt

  1. [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
  2. io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

リモートクラスターのログにEmpty client certificate chain:

Txt

  1. [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
  2. io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Empty client certificate chain

症状3

リモートクラスタークライアントがmTLS用に構成され、有効なクライアント証明書を提供している場合、クライアントが期待される認証ヘッダーを送信しないため、接続が失敗します。

ローカルクラスターのログにmissing authentication:

Txt

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

これはリモートクラスターのログには表示されません。

症状4

リモートクラスターで匿名アクセスが有効になっており、認証を必要としない場合、匿名ユーザーの権限に応じて、ローカルクラスターは次のようなログを記録することがあります。

匿名ユーザーが接続するために必要な権限を持っていない場合、ローカルクラスターのログにunauthorized:

Txt

  1. org.elasticsearch.transport.RemoteTransportException: [remote-node][192.168.0.42:9309][cluster:internal/remote_cluster/handshake]
  2. 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]:

Txt

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

解決策

ポート番号を確認し、リモートクラスターサーバーに接続していることを確認してください。トランスポートインターフェースではありません。

クロスクラスターAPIキーなしでの接続

ローカルクラスターは、リモートクラスターに接続するモデルを決定するためにクロスクラスターAPIキーの存在を使用します。クロスクラスターAPIキーが存在する場合、APIキーに基づく認証を使用します。そうでない場合、証明書ベースの認証を使用します。ローカルクラスターで使用されているモデルを確認するには、リモートクラスター情報APIを使用します:

Python

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

Ruby

  1. response = client.cluster.remote_info
  2. puts response

Js

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

コンソール

  1. GET /_remote/info

APIは"connected" : trueを返すべきです。APIキー認証を使用している場合、"cluster_credentials": "::es_redacted::"も返すべきです。

コンソール-結果

  1. {
  2. "cluster_one" : {
  3. "seeds" : [
  4. "127.0.0.1:9443"
  5. ],
  6. "connected" : true,
  7. "num_nodes_connected" : 1,
  8. "max_connections_per_cluster" : 3,
  9. "initial_connect_timeout" : "30s",
  10. "skip_unavailable" : false,
  11. "cluster_credentials": "::es_redacted::",
  12. "mode" : "sniff"
  13. }
  14. }
リモートクラスターは正常に接続されました。
存在する場合、リモートクラスターは、
APIキー認証を使用して接続されていることを示します。
証明書ベースの認証の代わりに接続されています。

リモートクラスター情報APIの応答を確認するだけでなく、ログも確認できます。

症状1

クロスクラスターAPIキーが使用されていない場合、ローカルクラスターは証明書ベースの認証方法を使用し、トランスポートインターフェースのTLS構成を使用してリモートクラスターに接続します。リモートクラスターがトランスポートとリモートクラスターサーバーインターフェースに異なるTLS CAと証明書を持っている場合(これは推奨される構成です)、TLS検証は失敗します。

ローカルクラスターのログにfailed to establish trust with server:

Txt

  1. [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]
  2. 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:

Txt

  1. [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:

Txt

  1. 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を使用してキーストアを再読み込みします。

間違ったAPIキータイプの使用

APIキーに基づく認証にはクロスクラスターAPIキーが必要です。REST APIキーでは機能しません。

症状

ローカルクラスターのログにauthentication expected API key type of [cross_cluster]:

Txt

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

これはリモートクラスターのログには表示されません。

解決策

リモートクラスターの管理者に依頼して、クロスクラスターAPIキーを作成し配布してもらいます。ローカルクラスターのすべてのノードのElasticsearchキーストアにこのクロスクラスターAPIキーを置き換えます。ノードのセキュア設定を再読み込みAPIを使用してキーストアを再読み込みします。

無効なAPIキー

クロスクラスターAPIは認証に失敗する可能性があります。たとえば、資格情報が不正確である場合、または無効化または期限切れである場合です。

症状

ローカルクラスターのログにunable to authenticate:

Txt

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

リモートクラスターのログにAuthentication using apikey failed:

Txt

  1. [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キーを作成し配布してもらいます。ローカルクラスターのすべてのノードのElasticsearchキーストアにこのクロスクラスターAPIキーを置き換えます。ノードのセキュア設定を再読み込みAPIを使用してキーストアを再読み込みします。

APIキーまたはローカルユーザーに権限が不十分

リモートクラスターでリクエストを実行しているローカルユーザーの有効な権限は、クロスクラスターAPIキーの権限とローカルユーザーのremote_indices権限の交差によって決まります。

症状

権限不足によるリクエストの失敗は、次のようなAPIレスポンスを引き起こします:

Js

  1. {
  2. "type": "security_exception",
  3. "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]"
  4. }

これはログには表示されません。

解決策

  • 1. ローカルユーザーが必要なremote_indices権限を持っていることを確認します。必要に応じて十分なremote_indices権限を付与します。
  • 2. ローカルで権限に問題がない場合、リモートクラスターの管理者に依頼してクロスクラスターAPIキーを作成し配布してもらいます。ローカルクラスターのすべてのノードのElasticsearchキーストアにこのクロスクラスターAPIキーを置き換えます。ノードのセキュア設定を再読み込みAPIを使用してキーストアを再読み込みします。

ローカルユーザーにremote_indices権限がない

これは権限不足の特別なケースです。この場合、ローカルユーザーはターゲットリモートクラスターに対してremote_indices権限をまったく持っていません。Elasticsearchはそれを検出し、より明示的なエラーレスポンスを発行できます。

症状

これにより、次のようなAPIレスポンスが生成されます:

Js

  1. {
  2. "type": "security_exception",
  3. "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"
  4. }

解決策

ローカルユーザーに十分なremote_indices権限を付与します。