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  CurrentDload  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  CurrentDload  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 凌晨