Question

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

Bundle extras = getIntent().getExtras();
byte[] byteArray = extras.getByteArray("Image");
//convert it to bitmap again
Bitmap bmp = BitmapFactory.decodeByteArray(byteArray, 0, byteArray.length);
ImageView image = (ImageView) findViewById(R.id.imageView1);
//set image to bitmap
image.setImageBitmap(bmp);

我阅读了haproxy如何运行检查的信息，但是Layer6超时并没有告诉我太多。超时可能是什么原因？到底是什么意思？

这是我的后端配置

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.

Answer 1

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

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

由于您尚未为服务器配置fall计数，这意味着正在使用默认值3，这意味着您的服务器实际上在连续3次运行状况检查之前都没有通过，直到被标记掉。

请考虑在后端声明中添加option log-health-checks，这将在最终的失败导致后端标记降低之前创建那些最初失败的检查的其他日志条目。

增加允许的时间可以避免失败，但是可能仅对测试有效（而不是修复），因为如果后端无法在2000毫秒内可靠地响应检查，那么它也不能可靠地响应在该时间段内连接到客户端连接，等待响应的时间很长。

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

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

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

1 个答案: