时间戳

首页 > 解决方案 > “原因：Layer6 超时”可能意味着什么？

haproxy - “原因：Layer6 超时”可能意味着什么？

问题描述

我在后端配置了两台服务器的 haproxy。偶尔，每 16-20 小时，其中一个会被 haproxy 标记为 DOWN：

haproxy.log-20190731:2019-07-30T16:16:24+00:00 <local2.alert> haproxy[2716]: Server be_kibana_elastic/kibana8 is DOWN, reason: Layer6 timeout, check duration: 2000ms. 0 active and 0 backup servers left. 8 sessions active, 0 requeued, 0 remaining in queue.

我做了一些阅读 haproxy 如何运行检查，但 Layer6 超时并没有告诉我太多。超时的可能原因是什么？它实际上是什么意思？

这是我的后端配置

backend be_kibana_elastic
    balance roundrobin
    stick   on src
    stick-table  type ip size 100k expire 12h
    server kibana8 172.24.0.1:5601 check ssl verify none
    server kibana9 172.24.0.2:5601 check ssl verify none

标签： haproxy

解决方案

第 6 层是指 TLS。后端正在接受 TCP 连接，但未在允许的时间内在运行状况检查连接上协商 TLS (SSL)。

配置值timeout connect、timeout check和interall 交互以确定允许、完成运行状况检查的时间，inter如果未指定，则默认值为 2000 毫秒，这就是您在此处看到的。默认情况下，inter（健康检查间隔）确定检查运行的频率以及允许它们完成的时间。

由于您没有fall为服务器配置计数，这意味着正在使用默认值 3，这意味着您的服务器实际上在被标记为关闭之前连续 3 次运行状况检查失败。

考虑添加option log-health-checks到后端声明，这将在最终失败检查导致后端被标记之前创建额外的日志条目。

增加允许的时间可以避免失败，但可能只对测试有效——不是修复——因为如果你的后端不能在 2000 毫秒内可靠地响应检查，那么它也不能可靠地响应客户端连接在那个时间范围内，等待响应的时间很长。

请注意，在典型环境中，间歇性数据包丢失通常会导致以 3000 毫秒为增量的缓慢行为，因为 TCP 堆栈通常使用 3 秒的重传超时 (RTO)。由于这超过 2000 毫秒，因此网络上的数据包丢失是问题的一种可能解释。

另一种可能的解释是后端的 CPU 负载过大，这与流量有关或与执行密集型任务的 cron 作业有关，因为 TLS 协商（相对而言）从 CPU 的角度来看是一个昂贵的过程。

推荐阅读