nginx负载均衡实验笔记
Posted 李迟
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了nginx负载均衡实验笔记相关的知识，希望对你有一定的参考价值。
本文是nginx负载均衡实验的一些笔记。
概述
前面已经完成了转发的程序，也尝试了一些负载均衡算法，本文对 nginx 的负载均衡做一些简单的测试，有部分实验是为了解答笔者与同事交流时产生的疑惑。
程序
本文所用程序，为笔者之前实现的转发程序，实际上任何能响应 post 请求的程序均可。
环境
本文实验环境如下：
虚拟机 Linux 运行容器。
虚拟机 Windows 发送 POST 请求。
本文使用镜像centos/nginx-116-centos7进行测试。
启动命令如下：
# $PWD/bin保存了后端的服务，故挂载之
docker run -itd --name nginx -p 8080:8080 -v $PWD/bin:/home/latelee/bin centos/nginx-116-centos7 nginx -g "daemon off;"
为了配置 nginx，需 root 权限，故使用如下命令进入容器：
sudo docker exec -u root -it nginx bash
后端服务运行命令如下：
/home/latelee/bin/httpforward_back.exe -p 9001 -i "hello in 9001"
/home/latelee/bin/httpforward_back.exe -p 9002 -i "hello in 9002"
/home/latelee/bin/httpforward_back.exe -p 9003 -i "hello in 9003"
重启 nginx 命令如下：
nginx -s reload
nginx 配置文件如下：
cat > /etc/nginx/nginx.conf <<-EOF
worker_processes auto;
error_log /var/opt/rh/rh-nginx116/log/nginx/error.log;
pid /var/opt/rh/rh-nginx116/run/nginx/nginx.pid;
# Load dynamic modules. See /opt/rh/rh-nginx116/root/usr/share/doc/README.dynamic.
include /opt/rh/rh-nginx116/root/usr/share/nginx/modules/*.conf;
events
worker_connections 1024;
http
log_format main '[$time_local] $remote_addr: "$request" '
'$status "$http_referer" '
'"$http_user_agent" [$upstream_addr $upstream_status $upstream_response_time ms $request_time ms]';
access_log /var/opt/rh/rh-nginx116/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
proxy_connect_timeout 10;
include /etc/opt/rh/rh-nginx116/nginx/mime.types;
default_type application/octet-stream;
# Load modular configuration files from the /etc/nginx/conf.d directory.
# See http://nginx.org/en/docs/ngx_core_module.html#include
# for more information.
include /opt/app-root/etc/nginx.d/*.conf;
server
listen 8080 default_server;
listen [::]:8080 default_server;
server_name _;
root /opt/app-root/src;
# Load configuration files for the default server block.
include /opt/app-root/etc/nginx.default.d/*.conf;
location /
proxy_pass http://foobar;
proxy_set_header Host $proxy_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location /fee/sleep
proxy_pass http://foobar;
upstream foobar
server 127.0.0.1:9001;
server 127.0.0.1:9002;
#upstream foobar
# server 127.0.0.1:9001 weight=3;
# server 127.0.0.1:9002 weight=1;
#
#upstream foobar
# ip_hash;
# server 127.0.0.1:9001;
# server 127.0.0.1:9002;
# server 127.0.0.1:9003;
#
EOF
该配置文件主要设置了上游服务foobar的IP和端口。再进行具体 URL 的映射，如下：
location /
proxy_pass http://foobar;
]
location /fee/sleep
proxy_pass http://foobar;
]
下面主要针对upstream foobar部分进行修改，达到使用不同算法的实验目的。
实验
为了进行实验，需启动若干个终端进入容器，如：修改配置并重启 nginx，执行程序，观察日志，等等。
查看访问日志：
tail -f /var/opt/rh/rh-nginx116/log/nginx/access.log
在另一终端（可在Windows或虚拟机中）执行如下请求命令：
curl http://192.168.28.11:8080/ -X POST -F "file=@sample.json"
下面给出配置和相应的日志和观察到的现象。
基础的实验
默认轮询
配置：
upstream foobar
server 127.0.0.1:9001;
server 127.0.0.1:9002;
日志：
[21/Sep/2021:04:47:26 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.000 ms 0.001 ms]
[21/Sep/2021:04:47:27 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.001 ms 0.001 ms]
[21/Sep/2021:04:47:29 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.002 ms 0.003 ms]
[21/Sep/2021:04:47:31 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:04:47:34 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:04:47:35 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.001 ms 0.001 ms]
结论： 9001 和 9002 依次出现。
加权轮询
配置：
upstream foobar
server 127.0.0.1:9001 weight=4;
server 127.0.0.1:9002 weight=1;
日志：
[21/Sep/2021:04:52:17 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.000 ms 0.000 ms]
[21/Sep/2021:04:52:18 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.001 ms 0.001 ms]
[21/Sep/2021:04:52:18 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.000 ms 0.000 ms]
[21/Sep/2021:04:52:19 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.001 ms 0.001 ms]
[21/Sep/2021:04:52:20 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
结论： 9001 和 9002 依次出现 4 次和 1 次。
注：经测试发现，nginx 加权轮询本身就是平滑加权轮询，此处为了演示，特意将权重值扩大。
平滑加权轮询
配置：
upstream foobar
server 127.0.0.1:9001 weight=2;
server 127.0.0.1:9002 weight=5;
server 127.0.0.1:9003 weight=3;
日志：
第一轮：
[21/Sep/2021:05:00:39 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:05:00:39 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:05:00:40 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9003 200 0.001 ms 0.000 ms]
[21/Sep/2021:05:00:41 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9003 200 0.000 ms 0.001 ms]
[21/Sep/2021:05:00:42 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.008 ms 0.009 ms]
[21/Sep/2021:05:00:43 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:05:00:44 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:05:00:44 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.000 ms 0.001 ms]
[21/Sep/2021:05:00:45 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.000 ms 0.001 ms]
[21/Sep/2021:05:00:46 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9003 200 0.001 ms 0.001 ms]
第二轮
[21/Sep/2021:05:03:24 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:05:03:25 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.001 ms 0.001 ms]
[21/Sep/2021:05:03:26 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.000 ms 0.000 ms]
[21/Sep/2021:05:03:27 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9003 200 0.000 ms 0.000 ms]
[21/Sep/2021:05:03:28 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.000 ms 0.000 ms]
[21/Sep/2021:05:03:29 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:05:03:30 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9003 200 0.002 ms 0.001 ms]
[21/Sep/2021:05:03:31 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9001 200 0.001 ms 0.001 ms]
[21/Sep/2021:05:03:31 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.000 ms 0.000 ms]
[21/Sep/2021:05:03:32 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
结论： 从权重上看，9001、9002 和 9003 保持配置中的值，即依次出现 2、5、3 次。从顺序上看，权重大的服务器并没有集中出现，三者轮询相对较均匀。从2轮实验结果看，每一次的轮询，某个服务器出现的顺序并不相同。
与前面自实现平滑算法对比如下：
自实现：
2 3 1 2 2 3 2 1 3 2
nginx的：
2 2 3 3 1 2 2 1 2 3
2 1 2 3 2 2 3 1 2 2
可以看到，二者还是有区别的。
ip_hash 轮询
配置：
upstream foobar
ip_hash;
server 127.0.0.1:9001;
server 127.0.0.1:9002;
server 127.0.0.1:9003;
为模拟不同的 IP 访问，在虚拟机、物理机以及其它的容器中发送 POST 请求，观察日志。如下：
[21/Sep/2021:06:59:55 +0000] 127.0.0.1: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9003 200 0.002 ms 0.042 ms]
[21/Sep/2021:06:59:55 +0000] 127.0.0.1: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9003 200 0.001 ms 0.041 ms]
[21/Sep/2021:06:59:56 +0000] 127.0.0.1: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9003 200 0.001 ms 0.041 ms]
[21/Sep/2021:07:02:20 +0000] 172.17.0.1: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9002 200 0.001 ms 0.041 ms]
[21/Sep/2021:07:02:23 +0000] 172.17.0.1: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9002 200 0.001 ms 0.044 ms]
[21/Sep/2021:07:03:20 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:07:03:21 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:07:03:22 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.000 ms 0.000 ms]
[21/Sep/2021:07:03:22 +0000] 192.168.28.5: "POST / HTTP/1.1" 200 "-" "curl/7.73.0" [127.0.0.1:9002 200 0.001 ms 0.001 ms]
[21/Sep/2021:07:03:54 +0000] 172.17.0.3: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9002 200 0.000 ms 0.042 ms]
[21/Sep/2021:07:04:07 +0000] 172.17.0.3: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9002 200 0.002 ms 0.042 ms]
[21/Sep/2021:07:04:08 +0000] 172.17.0.3: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9002 200 0.002 ms 0.044 ms]
[21/Sep/2021:07:04:42 +0000] 192.168.28.11: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9002 200 0.001 ms 0.042 ms]
[21/Sep/2021:07:04:49 +0000] 192.168.28.11: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9002 200 0.001 ms 0.042 ms]
[21/Sep/2021:07:04:50 +0000] 192.168.28.11: "POST / HTTP/1.1" 200 "-" "curl/7.29.0" [127.0.0.1:9002 200 0.002 ms 0.043 ms]
结论：其中127.0.0.1为 nginx 所在容器的本地 IP，172.17.0.3是另一容器，192.168.28.5是物理机，192.168.28.11是虚拟机。从日志中看，每个源 IP 均由相同端口的服务响应。但不知为何，9001 端口服务没有被轮询到。
自定义的实验
下面是一些笔者一直想做的实验。
后端服务未启动访问－返回502
模拟场合：所有的后端服务均未启动，但在 nginx 配置文件中指定了后端服务。
nginx 访问日志：
[21/Sep/2021:06:43:48 +0000] 192.168.28.5: "POST / HTTP/1.1" 502 "-" "curl/7.73.0" [127.0.0.1:9003, 127.0.0.1:9002, 127.0.0.1:9001 502, 502, 502 0.000, 0.000, 0.001 ms 0.001 ms]
curl 请求返回：
$ curl http://192.168.28.11:8080/ -X POST -F "file=@sample.json"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 493 100 157 100 336 78500 164k --:--:-- --:--:-- --:--:-- 481k<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.16.1</center>
</body>
</html>
结论：返回 502，注意，访问日志中提示了所有的后端服务均返回 502，猜测 nginx已经做了一次轮询。
服务处理中突然－返回502，当次服务失败
模拟场合：某服务在处理请求中突然停止服务（如出现段错误或断电）。
为了模拟该情况，特意实现一个 sleep 请求，该请求中延时 4 秒，以方便停止服务。
nginx 访问日志：
[21/Sep/2021:06:49:18 +0000] 192.168.28.5: "POST /fee/sleep HTTP/1.1" 502 "-" "curl/7.73.0" [127.0.0.1:9001 502 3.035 ms 3.035 ms]
可以看到，其响应处理耗时 3 秒多，因为笔者在大概 3 秒时才停止后端服务。
curl 请求返回：
$ curl http://192.168.28.11:8080/fee/sleep -X POST -F "file=@sample.json"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 493 100 157 100 336 40 85 0:00:03 0:00:03 --:--:-- 125<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.16.1</center>
</body>
</html>
结论：对于请求者而言，返回信息与上一实验相同，但在访问日志看到，只有 9001 才提示 502，但还有其它后端服务在运行，因此，再请求时，能返回正常，此时 nginx 会找正常工作的机器。
在处理中重新配置 nginx－会等待该处理完成
模拟场合：在多台后端服务中，需停止部分并升级，再启动，再升级其它的服务。
先将两台服务器权重扩大，如 9001 为 10， 9002 为 1，保证请求大部分转发到 9001 端口。在请求处理中，修改 nginx 配置，去掉 9001 服务，再重启 nginx。观察。
结论：nginx 等待 9001 服务处理完请求，后续请求不再转发该服务。因此确保在处理中的请求一定能处理完毕。
设置超时响应时间
配置：
location /
proxy_pass http://foobar;
proxy_set_header Host $proxy_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 1;
proxy_read_timeout 1;
proxy_send_timeout 1;
注： 不知如何实验。因为是来 gin 框架实现，有对应的响应函数，一旦进入，就认为响应了，直接用前面 sleep 模式的，也不行。
知识
不能在upstream里面的 IP 地址加上 URL 后缀。否则提示
nginx: [emerg] invalid host in upstream "127.0.0.1:9001/foobar" in /etc/opt/rh/rh-nginx116/nginx/nginx.conf:54
可以在location地址添加对应的 URL，如location /foobar。
为方便观察请求日志，需要设置 nginx 日志，本文配置如下：
log_format main '[$time_local] $remote_addr: "$request" '
'$status "$http_referer" '
'"$http_user_agent" [$upstream_addr $upstream_status $upstream_response_time ms $request_time ms]';
小结
许久前，在看分布式的视频时，里面介绍了负载均衡，雪花算法，一致性哈希算法，等，让笔者大开眼界，趁着中秋佳节无法外出，集中夜晚时间研究研究，从自实现的基于请求内容的转发工具，到 nginx 的负载均衡算法，基本过了一次。至于其它的知识，暂时未有计划。
2021.9.23 凌晨
以上是关于nginx负载均衡实验笔记的主要内容，如果未能解决你的问题，请参考以下文章