Elasticsearch7.15 CCR偶发无法打开远程集群代理连接 重启Pod可恢复如何排查

环境说明 #

• 采用Helm部署两套跨地域ELK 7.15集群，运行在OpenShift平台，单集群3节点，未使用Operator
• 已开启集群安全与TLS配置
• 跨集群复制（CCR）流量通过F5 LoadBalancer转发，日常运行稳定

问题现象 #

CCR功能偶发完全失效，无任何配置变更前提下，仅重启主节点Pod即可恢复正常运行。
故障报错日志如下：

[2021-11-19T14:16:58,628][WARN ][o.e.t.TcpTransport ] [elasticsearch-master-0] exception caught on transport layer 
[Netty4TcpChannel{localAddress=/XXX.XXX.XXX.XXX:47822, remoteAddress=elk-master.local.net/YYY.YYY.YYY.YYY:443, profile=default}], closing connection

io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[2021-11-19T14:16:58,629][WARN ][o.e.x.c.a.ShardFollowNodeTask] [elasticsearch-master-0] shard follow task encounter non-retryable error

java.lang.IllegalStateException: Unable to open any proxy connections to remote cluster [elasticsearch-cluster-2]

恢复日志如下：

[2021-11-22T10:24:31,168][INFO ][o.e.x.c.a.ShardFollowTasksExecutor] [elasticsearch-master-0] [myindex-2021.11.18-000001][0] Starting to track leader shard [myindex-2021.11.18-000001][0]

[2021-11-22T10:24:31,558][INFO ][o.e.x.c.a.ShardFollowNodeTask] [elasticsearch-master-0] [myindex-2021.11.18-000001][0] following leader shard [myindex-2021.11.18-000001][0], follower global checkpoint=[-1], mapping version=[2], settings version=[1], aliases version=[1]

可能的根因 #

• F5 TLS会话复用异常：F5配置的SSL会话超时时间短于Elasticsearch的TCP长连接保活时间，会话过期后F5返回的证书链不完整/使用了未被ES信任的临时证书，触发PKIX路径校验失败，ES的SSL上下文不会主动刷新异常会话，导致后续所有连接都握手失败。
• JDK证书缓存异常：OpenJDK默认会缓存成功的SSL证书校验结果，也会缓存失败的校验结果，默认失败缓存时间为10秒，但如果出现网络闪断导致连续校验失败，部分JDK版本存在缓存僵死的问题，不会自动刷新校验结果，只有进程重启才能清空缓存。
• Elasticsearch跨集群连接池僵死：ES的跨集群连接池在底层连接被F5强制断开后，没有正确销毁异常连接对象，复用失效连接时持续触发SSL握手失败，内部重试机制没有触发连接池重建逻辑。

排查思路 #

• 核对F5侧配置：检查F5针对ELK 443端口的SSL配置，包括会话超时时间、证书链配置、是否开启了会话复用、断连日志，确认故障时间点是否有会话过期、后端节点切换的记录。
• 验证证书有效性：故障发生时不要立刻重启主节点，先登录主节点Pod，用curl -v --cacert <ES信任根证书路径> https://elk-master.local.net 测试远端集群证书是否正常返回、证书链是否完整，排除证书本身过期/替换的问题。
• 检查JDK证书缓存配置：查看ES启动参数中sun.security.ssl.certpath.failCacheTimeout、sun.security.ssl.certpath.successCacheTimeout的配置，确认是否设置了不合理的缓存时间。
• 抓取TCP流量：在主节点和F5侧同时抓包，故障时分析SSL握手阶段的报文，确认是F5返回的证书异常还是ES侧校验逻辑异常。

解决方案 #

• 临时恢复方案：保留当前重启主节点的应急操作，可配置OpenShift监控告警，检测到CCR任务失败、SSL握手PKIX报错时自动触发主节点滚动重启。
• F5侧优化：将F5的SSL会话超时时间调整为大于等于ES的TCP保活时间（默认ES transport层tcp保活时间为2小时），关闭不必要的SSL会话复用，确认F5转发时始终返回完整的证书链，不要截断根证书/中间证书。
• ES侧优化：在ES的jvm.options中添加配置：-Dsun.security.ssl.certpath.failCacheTimeout=10 强制失败的证书校验缓存最多保留10秒，避免僵死；调整跨集群连接配置，增加transport.ping_schedule: 30s 定期探测跨集群连接有效性，异常时自动销毁重建连接。
• 可选方案：如果F5侧调整成本高，可将CCR的通信模式改为直接通过OpenShift Route/NodePort对接，绕过F5负载均衡的TLS终止，直接在两个ES集群之间做TLS校验。

内容的提问来源于stack exchange，提问作者Fabry