Nginx的TCP运行时健康检查

最新推荐文章于 2024-05-19 19:57:23 发布

星河_赵梓宇

最新推荐文章于 2024-05-19 19:57:23 发布

阅读量2.8k

点赞数 1

文章标签： Nginx

本文链接：https://blog.csdn.net/Aria_Miazzy/article/details/103172930

版权

Nginx的TCP运行时健康检查

本章介绍如何配置TCP的运行状况检查。

介绍

NGINX和NGINX Plus可以持续测试您的TCP上游服务器，避免出现故障的服务器，并可以将恢复的服务器正常地添加到负载平衡组中。

先决条件

您已在stream上下文中配置了TCP服务器的上游组，例如：

stream {
    #...
    upstream stream_backend {
    server backend1.example.com:12345;
    server backend2.example.com:12345;
    server backend3.example.com:12345;
   }
    #...
}

您已经配置了将TCP连接传递到服务器组的服务器：

stream {
    #...
    server {
        listen     12345;
        proxy_pass stream_backend;
    }
    #...
}

被动TCP运行状况检查

如果连接上游服务器的尝试超时或导致错误，NGINX Open Source或NGINX Plus可以将服务器标记为不可用，并在指定的时间内停止向其发送请求。要定义NGINX认为上游服务器不可用的条件，请在server指令中包含以下参数

fail_timeout –在指定的连接尝试次数内必须失败的时间，服务器才被视为不可用。另外，NGINX将服务器标记为不可用之后认为服务器不可用的时间。
max_fails –在指定时间内NGINX认为服务器不可用的失败尝试次数。

默认值为10秒数和1尝试次数。因此，如果连接尝试超时或在10秒内至少失败一次，NGINX会将服务器标记为10秒钟不可用。该示例显示了如何在30秒内将这些参数设置为2个失败：

upstream stream_backend {
    server backend1.example.com:12345 weight=5;
    server backend2.example.com:12345 max_fails=2 fail_timeout=30s;
    server backend3.example.com:12346 max_conns=3;
}

服务器缓慢启动

最近恢复的上游服务器很容易被连接淹没，这可能导致服务器再次标记为不可用。慢速启动允许上游服务器在恢复或可用后将其权重从零逐渐恢复到其标称值。这可以通过slow_start上游server指令的参数来完成：

upstream backend {
    server backend1.example.com:12345 slow_start=30s;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

请注意，如果组中只有一台服务器，则将slow_start忽略该参数，并且永远不会将服务器标记为不可用。慢速启动是NGINX Plus独有的。

活动TCP运行状况检查

可以将运行状况检查配置为测试各种故障类型。例如，NGINX Plus可以连续测试上游服务器的响应能力，并避免出现故障的服务器。

NGINX Plus向每个上游服务器发送特殊的运行状况检查请求，并检查是否满足特定条件。如果无法建立与服务器的连接，则运行状况检查将失败，并且服务器将被视为运行状况不佳。NGINX Plus不会将客户端连接代理到运行状况不佳的服务器。如果为上游组配置了多个运行状况检查，则任何检查失败都会足以使相应的服务器不正常。

要启用主动健康检查：

指定一个共享内存区域 – NGINX Plus工作进程在其中共享计数器和连接状态信息的特殊区域。将zone指令添加到上游服务器组，并指定区域名称（此处为stream_backend）和内存量（64 KB）：
```
stream {
    #...
    upstream stream_backend {
        zone   stream_backend 64k;
        server backend1.example.com:12345;
        server backend2.example.com:12345;
        server backend3.example.com:12345;
    }
    #...
}
```

使用以下health_check指令为上游组启用主动运行状况检查：

stream {
    #...
    server {
        listen        12345;
        proxy_pass    stream_backend;
        health_check;
        #...
    }
}

如有必要，使用该health_check_timeout指令减少两次连续运行状况检查之间的超时。该指令将覆盖proxy_timeout运行状况检查的值，因为对于运行状况检查，此超时需要大大缩短：
```
stream {
    #...
    server {
        listen               12345;
        proxy_pass           stream_backend;
        health_check;
        health_check_timeout 5s;
    }
}
```
默认情况下，NGINX Plus将运行状况检查消息发送到块中server指令所指定的端口upstream。您可以指定另一个端口进行运行状况检查，这在监视同一主机上许多服务的运行状况时特别有用。要覆盖端口，请指定伪指令的port参数health_check：
```
stream {
    #...
    server {
        listen               12345;
        proxy_pass           stream_backend;
        health_check         port=12346;
        health_check_timeout 5s;
    }
}
```

微调TCP运行状况检查

默认情况下，NGINX Plus尝试每秒钟连接到上游服务器组中的每个服务器5 。如果无法建立连接，NGINX Plus会认为运行状况检查失败，将服务器标记为不正常，然后停止将客户端连接转发到服务器。

要更改默认行为，请在health_check伪指令中包含参数：

interval– NGINX Plus发送健康检查请求的频率（以秒为5 单位）（默认为秒）
passes–服务器必须响应才能被视为健康的连续健康检查次数（默认为 1）
fails–服务器必须不响应才能被视为不健康的连续健康检查次数（默认为 1）
```
stream {
    #...
    server {
        listen       12345;
        proxy_pass   stream_backend;
        health_check interval=10 passes=2 fails=3;
    }
    #...
}
```
在此示例中，两次TCP健康检查之间的时间增加到10几秒钟，服务器在3连续失败的健康检查后被视为不健康，并且服务器需要通过2连续检查才能再次被视为健康。

“ match {}”配置块

您可以创建自己的测试来验证服务器对运行状况检查的响应。这些测试是通过放置在上下文中的配置块定义的。match {}stream {}

在级别上，指定块并为其命名，例如：stream {}match {}tcp_test
```
stream {
    #...
    match tcp_test {
        #...
    }
}
```
该块将包含步骤3中描述的测试。

health_check通过指定match参数和match块名称，从指令中引用该块：

stream {
    #...
    server {
        listen       12345;
        health_check match=tcp_test;
        proxy_pass   stream_backend;
    }
    #...
}

在match块中，指定运行状况检查成功的条件或测试。该块可以接受以下参数：
- send –发送到服务器的文本字符串或十六进制文字（“ / x”后跟两个十六进制数字）
- expect –服务器返回的数据需要匹配的文字字符串或正则表达式
这些参数可以以不同的组合使用，但send一次expect最多只能指定一个参数：
- 如果未指定send或未expect指定参数，则将测试连接到服务器的能力。
- 如果expect指定了该参数，则期望服务器首先无条件发送数据：
```
match pop3 {
    expect ~* "\+OK";
}
```
- 如果send指定了该参数，则预期将成功建立连接并将指定的字符串发送到服务器：
```
match pop_quit {
    send QUIT;
}
```
- 如果同时指定send和expect参数，则参数中的字符串send必须与参数中的正则表达式匹配expect：
```
stream {
    #...
    upstream   stream_backend {
        zone   upstream_backend 64k;
        server backend1.example.com:12345;
    }
    match http {
        send      "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n";
        expect ~* "200 OK";
    }
    server {
        listen       12345;
        health_check match=http;
        proxy_pass   stream_backend;
    }
}
```
该示例显示，要使运行状况检查通过，必须将HTTP请求发送到服务器，并且服务器的预期结果中包含200 OK指示成功的HTTP响应的信息。

星河_赵梓宇

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
Nginx的TCP运行时健康检查

Nginx的TCP运行时健康检查本章介绍如何配置TCP的运行状况检查。介绍先决条件被动TCP运行状况检查服务器缓慢启动活动TCP运行状况检查微调TCP运行状况检查 “匹配”配置块介绍NGINX和NGINX Plus可以持续测试您的TCP上游服务器，避免出现故障的服务器，并可以将恢复的服务器正常地添加到负载平衡组中。先决条件...
复制链接

扫一扫