Nginx 负载均衡与反向代理配置篇

  • 1.1 专业术语
  • 1.2 UpStream 配置
  • 1.3 负载均衡算法
  • 1.4 失败重试
  • 1.5 备份上游服务器
  • 1.6 不可用上游服务器
  • 1.7 心跳检测
  • 1.7.1 TCP心跳检测
  • 1.7.2 HTTP心跳检测


这篇博文来记录下Nginx负载均衡与反向代理配置研发秘术。

1.1 专业术语

专业术语

解释

上游服务器配置

使用upstream server 配置上游服务器

负载均衡算法

使用多个上游服务器时的负载均衡机制

失败重试机制

配置当超时或上游服务器不存活时是否需要重试其他上游服务器

服务器心跳检查

上游服务器的健康检查/心跳检查

1.2 UpStream 配置

upstream backend{
   server 192.168.61.1:9080 weight=1;
   server 192.168.61.1:9090 weight=2;
}
location /{
    proxy_pass http://backend;
}

upstream server的主要配置如下：

  • IP地址和端口：配置上游服务器的IP地址和端口
  • 权重: weight 用来配置权重，默认都是1，权重越高分配给这台服务器的请求就越多，需要根据服务器的实际处理能力设置权重。
  • 比如上面配置，为每三次请求中，一个请求转发给9080，其余两个请求转发给9090
  • 当访问Nginx时,会将请求反向代理到backend 配置的upstream server.

1.3 负载均衡算法

负载均衡算法

解释

round-robin

轮训,默认负载均衡算法，即以轮训的方式将请求转发到上游服务器

weight

通过weight配置可以实现基于权重的轮训。

ip_hash

根据客户IP进行负载均衡，即相同的IP将负载均衡到同一个upstream server

hash_key

-

Nginx只使用ip_hash 负载均衡算法配置示例

upstream backend{
   ip_hash;
   server 192.168.61.1:9080;
   server 192.168.61.1:9090;
}
location /{
    proxy_pass http://backend;
}

Nginx配置混合使用ip_hash 和weight 负载均衡算法配置示例

upstream backend{
   ip_hash;
   server 192.168.61.1:9080 weight=1;
   server 192.168.61.1:9090 weight=2;
}
location /{
    proxy_pass http://backend;
}

1.4 失败重试

Nginx自带有健康检查模块：ngx_http_upstream_module，可以做到基本的健康检查，配置如下：

upstream backend{
   ip_hash;
   server 192.168.61.1:9080 max_fails=2 fail_timeout=10s weight=1;
   server 192.168.61.1:9090 max_fails=2 fail_timeout=10s weight=1;
}
location /test{
    proxy_connect_timeout 5s;
    proxy_read_timeout 5s;
    proxy_send_timeout 5s;
    
    proxy_next_upstream error timeout;
    proxy_next_upstream_timeout 10s;
    proxy_next_upstream_tries 2;
    proxy_pass http://backend;
    add_header upstream_addr $upstream_addr;
}

说明：

  • 通过配置上游服务器的max_fails 和fail_timeout 来指定每个上游服务器，当fail_timeout
    时间内失败了max_fails 次请求，则认为该上游服务器不可用/不存活，然后摘掉该上游服务器。
  • fail_timeout 时间后会再次将该服务器加入到存活上游服务器列表进行重试。
  • 然后进行proxy_next_upstream 相关配置，当遇到配置的错误时，会重试下一台上游服务器。

缺点：

Nginx只有当有访问时后，才发起对后端节点探测。如果本次请求中，节点正好出现故障，Nginx依然将请求转交给故障的节点,然后再转交给健康的节点处理。
所以不会影响到这次请求的正常进行。但是会影响效率,因为多了一次转发,而且自带模块无法做到预警。

1.5 备份上游服务器

upstream backend{
   ip_hash;
   server 192.168.61.1:9080 weight=1;
   server 192.168.61.1:9090 weight=2 backup;
}
location /{
    proxy_pass http://backend;
}

将9090端口上游服务器配置为备上游服务器，当所有主上游服务器都不存活时，请求会转发给备上游服务器。

如通过缩容上游服务器进行压测时，要摘掉一些上游服务器进行压测，但是为了保险起见会配置一些备上游服务器，当压测的上游服务器都挂掉时，流量可以转发到备用服务器，从而不影响用户请求处理。

1.6 不可用上游服务器

upstream backend{
   ip_hash;
   server 192.168.61.1:9080 weight=1;
   server 192.168.61.1:9090 weight=2 down;
}
location /{
    proxy_pass http://backend;
}

9090端口上游服务器配置为永久不可用，当测试或者机器出现故障时候，暂时通过该配置临时摘掉机器。

1.7 心跳检测

nginx 商业版本可以通过安装 health_check 模块来进行主动健康检查
nginx 社区版本可通过安装第三方开源 nginx_upstream_check_module 模块来进行主动健康检查
nginx_upstream_check_module 支持TCP 和HTTP心跳检测
Tips:

该模块完全开源，由阿里巴巴淘宝团队借鉴了https://github.com/cep21/healthcheck_nginx_upstreams 而开发的用于nginx upstream 主动心跳检测模块

Github 地址：https://github.com/yaoweibin/nginx_upstream_check_module

官网地址: http://tengine.taobao.org/document/http_upstream_check.html

使用介绍参考：

1.7.1 TCP心跳检测

upstream backend{
ip_hash;
server 192.168.61.1:9080 weight=1;
server 192.168.61.1:9090 weight=2;
check interval=3000 rise=1 fall=3 timeout=2000 type=tcp;
}
location /{
proxy_pass http://backend;
}

配置参数名称 解释
interval 检测间隔时间，此处配置了每隔3s检测一次
fall 检测失败多少次后，上游服务器被标识为不存活
rise 检测成功多少次后，上游服务器被标识为存活，并可以处理请求
timeout 检测请求超时时间配置

1.7.2 HTTP心跳检测

upstream backend{
ip_hash;
server 192.168.61.1:9080 weight=1;
server 192.168.61.1:9090 weight=2;
check interval=3000 rise=1 fall=3 timeout=2000 type=http;
check_http_send “HEAD /status HTTP/1.0\r\n\r\n”
check_http_expect_alive http_2xx http_3xx;
}
location /{
proxy_pass http://backend;
}
Http心跳检测有如下两个需要额外配置。

配置参数名称

解释

check_http_send

即检查时发的HTTP请求内容

check_http_expect_alive

当上游服务器返回匹配的响应码时，则认为上游服务器存活。

注意：

  • 检查间隔时间不能太短，否则可能因为心跳检查包太多造成上游服务器挂掉，同时要设置合理的超时时间。
  • 淘宝Tengine自带该模块，如果我们没有使用Tengine，可以通过打补丁的方式把该模块加到我们自己的Nginx中。
  • 本文使用的是openresty/1.11.2.1 对应nginx-1.11.2 ,安装Nginx之前需要先打nginx_upstream__check_module补丁,到Nginx目录下执行如下Shell:
patch -p0 < /usr/servers/nginx_upstream_check_module-master/check_1.9.2+.patch

如果不安装补丁那么nginx_upstream_check_module 模块是不工作的，建议使用wireshark 抓包查看其是否工作。

本篇完～