Nginx负载均衡health_check分析
在Nginx负载均衡中,我们很难保证说每一台应用服务器都能一直正常的运行下去。但是我们可以通过设置Nginx来检测这些应用服务器,检测这些服务器当中不能访问的。
Nginx的检测方式分为两种,一种是被动监测,另一种是主动监测。下面我们分别看一下这两种方式。
被动监测
当Nginx认为一台应用服务器不能被访问的时候,它会暂时停止向这台应用上面分发请求。直到Nginx认为该应用服务器可以再次被访问的时候才会再向这台应用服务器上面分发请求。
要实现对应用服务器的监测,需要通过两个参数来帮助。
fail_timeout——该参数表示停止分发请求至该应用服务器的时间。也就是说,如果Nginx认为一台应用服务器不能被访问了,则Nginx就会停止向这台应用服务器上分发请求。那需要多长时间Nginx才会认为该服务器可以被访问从而向其分发请求呢。这就需要通过该参数来设置这个时间了。
max_fails——设置访问失败的最大次数。当Nginx向一台服务器分发请求,如果失败的次数达到该参数设置的数量,则Nginx认为该应用服务器不能访问。在接下来的请求就不会再发给该应用服务器。直到达到fail_timeout设置的时间才会再次向这台应用分发请求。
例一
http {
upstream onmpw {
server 192.168.144.128;
server 192.168.144.132 max_fails=3 fail_timeout=30s;
server 192.168.144.131 max_fails=2;
}
server {
listen 80;
location / {
proxy_pass http://onmpw;
}
}
}
对于fail_timeout和max_fails的默认值分别为10s和1次。也就是说,当Nginx向一台应用服务器发送请求,如果失败则认为该应用服务器不可访问。接下来的10s中请求不再分发给该应用服务器。直到10s以后会再次将请求分发给该应用服务器。
对于例一,我们看到对于132应用,当请求失败次数达到3次。Nginx会在30s内不再向该应用分发请求。直到30s以后会再次分发新的请求到该应用服务器上。对于131应用,当请求次数达到2次,Nginx就会在10s内(因为没有设置fail_timeout,所以默认为10s)不再向这台应用发送请求。
这种方式需要我们在每台应用服务器对应的信息后面设置,所以称其为被动监测。
主动监测
由Nginx定期的向每台应用服务器发送特殊的请求,来监测应用服务器是否可以正常访问。这种方式称为主动监测。
为了实现主动监测这种方式,我们需要在Nginx负载均衡的配置文件中加入health_check指令。除此之外,我们还需要在设置应用服务器信息的组里加入zone指令。
例二
http {
upstream onmpw {
zone onmpw 64k;
server 192.168.144.128;
server 192.168.144.132;
server 192.168.144.131;
}
server {
listen 80;
location / {
proxy_pass http://onmpw;
health_check;
}
}
}
在这里我们设置了一组应用服务器。通过一个单一的location,将所有的请求都分发到这组应用服务器上。在这种情况下,每隔5s Nginx Plus就会向每一台应用服务器发送’/’请求。任何一台应用服务器连接错误或者响应超时亦或者是被代理的服务器响应了一个状态码2xx或者是3xx,health_check机制就会认为是失败的。对于任何一台应用服务器,如果health_check失败,则就会被认为是不稳定的。那么Nginx Plus就不再向这台应用服务器分发访问请求。
zone指令定义了一块儿内存空间。这块儿空间存储在各个工作进程中共享的运行环境的状态和应用服务器组的配置信息。这块儿空间应该根据实际情况尽量申请的大一些,要保证能存下这些信息。
下面我们再看这样的一个例子
例三
location / {
proxy_pass http://onmpw;
health_check interval=10 fails=3 passes=2;
}
在上面的例三中,interval=10表示两次进行health_check的间隔为10s,如果不设置默认两次的间隔是5s。fails=3表示一台应用服务器如果请求失败次数达到3次,则该应用服务器被认为不能访问。最后是passes=2表示,被认定为不能访问的服务器需要再次进行两次health_check 以后才会再次被认为是可以正常访问的。
在health_check中,我们可以指定请求的url。
例四
location / {
proxy_pass http://onmpw;
health_check uri=/some/path;
}
对于onmpw组中的第一台应用服务器128来说,一次health check请求的url是http://192.168.144.128/some/path。
上面两种监测方式是普遍被使用的,希望本文对大家有所帮助。
相关文章
Nginx 和 uWISG 服务器之间如何配合工作的
发布时间:2023/03/29 浏览次数:158 分类:网络
-
Nginx和uWISG是两个常用的服务器软件,它们可以协同工作以提供更加稳定和高效的网络服务。本文将详细介绍Nginx和uWISG之间的配合工作原理,以及如何配置它们以实现最佳性能。 一、
设置 PHP-FPM 和 Nginx Docker 容器
发布时间:2023/03/29 浏览次数:147 分类:PHP
-
在本篇文章中,我们将讨论在 Docker 上进行本地开发时如何设置 PHP、PHP-FPM 和 NGINX 容器。
在 Ubuntu 18.04 上使用 Nginx 安装 WordPress
发布时间:2022/10/15 浏览次数:223 分类:操作系统
-
WordPress 是最受欢迎的开源内容管理系统 (CMS) 之一,与 Drupal 或 Joomla 等其他 CMS 相比,其市场份额高达 60%。 WordPress 可用于开发任何类型的网站,无论是博客、小型企业还是大型企业。
Nginx 运行但是不提供站点服务
发布时间:2022/05/15 浏览次数:186 分类:网络
-
我们最近在一台新机器上安装了 nginx 版本 1.17。 在 sites-available`中创建的配置被符号链接到 `sites-enabled` ,但 nginx 没有为任何域名提供服务。
Nginx 如何修复 Reponse Status 0 Worker Process Exited on Signal 11
发布时间:2022/05/14 浏览次数:173 分类:网络
-
实际上,让我们首先澄清一下:HTTP 没有状态码 0(零)。 问题是 nginx 工作进程在处理请求时死亡,因此连接中断,导致没有任何响应数据的错误。
Nginx 如何修复 Unknown "connection_upgrade" Variable 错误
发布时间:2022/03/28 浏览次数:4924 分类:网络
-
在使用 Websockets 或使用 nginx 配置服务器时,我们可能会在 nginx 配置中遇到 `$connection_upgrade` 变量。 $connection_upgrade 变量默认不可用。 但是,建议在反向代理设置中定义和使用它。
Nginx - 如何修复 “ssl” Directive Is Deprecated, Use “listen … ssl” 错
发布时间:2022/03/23 浏览次数:130 分类:网络
-
本篇文章介绍如何修复 nginx 的 “ ‘ssl’ Directive Is Deprecated, Use ‘listen … ssl’ ” 错误。Nginx 使用类似 YAML 的定义格式来创建配置。 这种格式随着时间的推移通过添加、删除或更改关键
在 Ubuntu 20.04 如何使用 Let's Encrypt 结合 Nginx 配置 https
发布时间:2022/02/03 浏览次数:319 分类:操作系统
-
在本篇文章中,我们介绍了安装了 Let's Encrypt 客户端 certbot,为我们的域名下载 SSL 证书,配置 Nginx 来使用这些证书,并设置自动证书更新。
深入理解 Nginx Location 块匹配算法
发布时间:2022/01/15 浏览次数:76 分类:网络
-
与 Nginx 用于选择将处理请求的 Server 块的过程类似,Nginx 也有一个既定的算法来决定 Server 块中的哪个 Location 块用于处理请求。