Nginx【有与无】【NP-AG3-4】TCP运行状况检查

最新推荐文章于 2024-05-23 17:59:04 发布

琴韵

最新推荐文章于 2024-05-23 17:59:04 发布

阅读量282

点赞数

分类专栏： Nginx 文章标签： nginx

本文链接：https://blog.csdn.net/u012549626/article/details/111637242

版权

Nginx 专栏收录该内容

25 篇文章 1 订阅

订阅专栏

说明

NP: NGINX Plus
AG: Admin Guide
会话: session
上游: upstream
流量：traffic
后端：backend

7.精细调整(Fine-Tuning)TCP运行状况检查

8.“match {}”配置块

1.TCP运行状况检查

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

2.介绍

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

3.先决条件

你已在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;
    }
    #...
}

4.被动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;
}

5.服务器缓慢启动

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

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

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

6.活动TCP运行状况检查

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

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

要启用主动健康检查：

1.指定一个共享的内存区域(shared memory zone)– 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;
    }
    #...
}

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

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

3.如有必要，请使用health_check_timeout指令减少两次连续运行状况检查之间的超时。此指令会覆盖运行状况检查的proxy_timeout值，因为对于运行状况检查，此超时需要大大缩短：

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

4.默认情况下，NGINX Plus将运行状况检查消息发送到upstream块中server指令指定的端口。你可以指定另一个端口进行运行状况检查，这在监视同一主机上许多服务的运行状况时特别有用。要覆盖端口，请指定health_check指令的port参数：

stream {
    #...
    server {
        listen               12345;
        proxy_pass           stream_backend;
        health_check         port=12346;
        health_check_timeout 5s;
    }
}

7.精细调整(Fine-Tuning)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次连续检查才能再次被视为健康。

8.“match {}”配置块

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

1.在stream {}级别上，指定match {} 块并将其命名，例如tcp_test：

stream {
    #...
    match tcp_test {
        #...
    }
}

此块将包含步骤3中描述的测试。

2.通过指定match参数和match块的名称来引用health_check指令中的块：

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

3.在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响应。

琴韵

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
1
评论
Nginx【有与无】【NP-AG3-4】TCP运行状况检查

说明NP: NGINX Plus AG: Admin Guide 会话: session 上游:upstream 流量：traffic 后端：backend目录1.TCP运行状况检查2.介绍3.先决条件4.被动TCP运行状况检查5.服务器缓慢启动6.活动TCP运行状况检查7.精细调整(Fine-Tuning)TCP运行状况检查8.“match {}”配置块1.TCP运行状况检查本章介绍如何配置TCP的运行状况检查。2.介绍NGINX和NGI..
复制链接

扫一扫