Nginx 負載均衡實現(xiàn)上游服務(wù)健康檢查

Author：Arsen
Date：2024/06/20

前言

如果你使用云負載均衡（如阿里云 CLB），我們可以通過配置健康檢查來實現(xiàn)后端服務(wù)故障轉(zhuǎn)移（通過 4/7 層實現(xiàn)）。而如果你使用 Nginx 作為負載均衡器時，又如何實現(xiàn)后端（上游）服務(wù)器的健康檢查呢？要解決這個問題，就需要使用到 Nginx 的 nginx_upstream_check_module 模塊，因為在不使用 nginx_upstream_check_module 模塊的情況下，Nginx 的常規(guī)負載均衡機制并不具備自動移除不健康服務(wù)器的功能。默認情況下，Nginx 不會主動檢查上游服務(wù)器的健康狀態(tài)，因此無法在服務(wù)器出現(xiàn)故障時自動將其從負載均衡池中移除。

接下來將演示如何通過 nginx_upstream_check_module 實現(xiàn)負載均衡上游服務(wù)器的故障轉(zhuǎn)移。

注意：nginx_upstream_check_module 是一個第三方模塊，不屬于官方 NGINX 發(fā)行版的一部分，因此需要我們手動將其集成到 NGINX 中，而不是通過官方預(yù)編譯的 NGINX 包來使用它。

一、Nginx 部署并新增模塊

1、下載 nginx、nginx_upstream_check_module 源碼包

nginx_upstream_check_module 模塊地址：https://github.com/yaoweibin/nginx_upstream_check_module

wget http://nginx.org/download/nginx-1.18.0.tar.gz
wget https://github.com/yaoweibin/nginx_upstream_check_module/archive/refs/tags/v0.4.0.tar.gz

2、解壓安裝包

tar xzf v0.4.0.tar.gz
tar xzf nginx-1.18.0.tar.gz

3、為 NGINX 源碼打補丁

# 安裝補丁工具
yum install -y patch

補丁列表（在我們上面下載的第三方模塊中）：

在補丁文件列表中，沒有直接與 nginx-1.18.4 對應(yīng)的補丁文件。通常情況下，選擇一個版本號最接近但不高于你的 NGINX 版本的補丁文件會是最佳選擇。如上圖，使用 check_1.16.1+.patch，因為它是最接近 1.18.0 的可用補丁且不高于1.18.0 。

# 開始打補丁
cd nginx-1.18.0/
patch -p1 < ../nginx_upstream_check_module-0.4.0/check_1.16.1+.patch

4、開始編譯安裝

關(guān)于模塊安裝注意事項，可以查看有道云筆記 nginx 編譯安裝部分。

# 安裝nginx編譯安裝的依賴環(huán)境
yum -y install make gcc gcc-c++ pcre pcre-devel gd-devel openssl openssl-devel zlib zlib-devel

./configure \
--with-http_gzip_static_module \
--with-http_ssl_module \
--with-http_stub_status_module \
--with-http_ssl_module \
--with-pcre \
--with-file-aio \
--with-http_realip_module \
--without-http_scgi_module \
--without-http_uwsgi_module \
--without-http_fastcgi_module \
--with-compat --add-module=../nginx_upstream_check_module-0.4.0
# --with-compat 是一個用于構(gòu)建兼容模塊的選項，它允許你編譯 NGINX 時，使其模塊在不同版本的 NGINX 上保持兼容。
# 這里僅僅是測試使用，我就不具體規(guī)劃路徑了（如安裝路徑、日志路徑等），使用默認即可

如上圖，Nginx 編譯完成，默認輸出了相關(guān)的工作路徑，接下來就根據(jù)上圖路徑開始安裝了：

make && make install

此時我們需要驗證新增的第三方模塊是否被成功集成：

二、健康檢查配置

2.1 準備 nodeJS 應(yīng)用程序

1、node 安裝

過程略.

2、安裝 pm2 守護進程管理器

npm install -g pm2

3、創(chuàng)建測試項目并啟動項目

vim /data/nginx-test-projects/node-js-demo/app-1.js

const http = require('http');
const server = http.createServer((req, res) => {
    res.setHeader("Content-Type", "application/json");
    res.writeHead(200);
    res.end(`{ "status": "success", "message": "app-1 請求成功!\n" }`);
});
server.listen(3001, 'localhost', () => {
    console.log('running on http://localhost:3001/');
});

vim /data/nginx-test-projects/node-js-demo/app-2.js

const http = require('http');
const server = http.createServer((req, res) => {
    res.setHeader("Content-Type", "application/json");
    res.writeHead(200);
    res.end(`{ "status": "success", "message": "app-2 請求成功!\n" }`);
});
server.listen(3002, 'localhost', () => {
    console.log('running on http://localhost:3002/');
});

vim /data/nginx-test-projects/node-js-demo/app-3.js

const http = require('http');
const server = http.createServer((req, res) => {
    res.setHeader("Content-Type", "application/json");
    res.writeHead(200);
    res.end(`{ "status": "success", "message": "app-3 請求成功!\n" }`);
});
server.listen(3003, 'localhost', () => {
    console.log('running on http://localhost:3003/');
});

啟動應(yīng)用：

pm2 start /data/nginx-test-projects/node-js-demo/app-1.js
pm2 start /data/nginx-test-projects/node-js-demo/app-2.js
pm2 start /data/nginx-test-projects/node-js-demo/app-3.js

2.2 Nginx 配置負載均衡健康檢查

1、nginx 配置

vim /usr/local/nginx/conf/nginx.conf

http {
    upstream backend {
        server 127.0.0.1:8080;
        server 127.0.0.1:8081;
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "HEAD / HTTP/1.0\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

配置說明：

• upstream backend { ... }: 定義名為 backend 的上游服務(wù)器組。
• server 127.0.0.1:8080;: 定義一個地址為 127.0.0.1:8080 的上游服務(wù)器。
• check interval=3000 rise=2 fall=5 timeout=1000 type=http; 配置健康檢查參數(shù)：
  • interval=3000: 每隔 3000 毫秒（3 秒）進行一次健康檢查。
  • rise=2: 如果服務(wù)器連續(xù)通過 2 次健康檢查，則認為它是健康的。
  • fall=5: 如果服務(wù)器連續(xù) 5 次健康檢查失敗，則認為它是故障的。
  • timeout=1000: 每次健康檢查必須在 1000 毫秒（1 秒）內(nèi)完成。
  • type=http: 指定進行 HTTP 健康檢查。
• check_http_send "HEAD / HTTP/1.0\r\n\r\n";: 向服務(wù)器發(fā)送 HTTP HEAD 請求。
• check_http_expect_alive http_2xx http_3xx;: 如果服務(wù)器返回的狀態(tài)碼在 2xx 或 3xx 范圍內(nèi)，則認為服務(wù)器是健康的。

2、健康檢查驗證

while sleep 0.5; do curl http://192.168.56.120; done

后端服務(wù)健康情況時，是正常的負載均衡的：

這里我分兩種情況來驗證：

1）未配置 nginx_upstream_check_module 的情況

此時，我停掉 app-1

pm2 stop app-1

看看 nginx 的錯誤日志是否持續(xù)輸出，如果持續(xù)輸出，說明 nginx 一直在輪詢請求后端上游服務(wù)，且請求不到，這就證明默認的 nginx 負載均衡模式下，并不能實現(xiàn)后端上游服務(wù)的健康檢查，客戶的請求依然會打到壞掉的 app-1 服務(wù)上。如下圖，正符合我們的假設(shè)。

2）配置了 nginx_upstream_check_module 的情況

這里，我們先恢復(fù)后端服務(wù)，使 3 臺都正常工作。然后我們保持請求不要斷，繼續(xù)將 app-1 stop 掉，看會不會故障轉(zhuǎn)移到其他節(jié)點：判斷是否轉(zhuǎn)移其實就是你看 nginx 是否有如上圖相同的錯誤日志持續(xù)輸出，如果有，那證明這個檢測模塊我們就沒配置正確，否則證明我們的檢測模塊生效，且將壞掉的 app-1 從負載均衡中摘掉，恢復(fù)時自動加入負載均衡。

停掉 app-1

pm2 stop app-1

再看看 Nginx 的錯誤日志：

這里你會注意到，此時的錯誤日志與上一張圖的錯誤日志不同了，那他們的區(qū)別是什么呢？

1）未配置 nginx_upstream_check_module 的錯誤日志分析：

由于我們沒有配置了 Nginx 健康檢查，在連接已建立后，NGINX 嘗試連接到上游服務(wù)器時，連接被拒絕而拋出如下錯誤日志：

2024/06/20 13:19:55 [error] 14553#0: *510 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.56.120, server: localhost, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3001/", host: "192.168.56.120"

這通常是由于上游服務(wù)器未能正常啟動或者未響應(yīng)

客戶端請求處理：

• 如果 NGINX 配置中沒有健康檢查，或者健康檢查無法檢測到上游服務(wù)器的問題，客戶端的請求可能會繼續(xù)被發(fā)送到無法處理請求的上游服務(wù)器。
• 這種情況下，客戶端請求可能會因為上游服務(wù)器的問題而遭遇連接失敗或者長時間的等待響應(yīng)。

2）配置了 nginx_upstream_check_module 的錯誤日志分析：

由于我們配置了 Nginx 健康檢查，在連接已建立后，NGINX 嘗試發(fā)送數(shù)據(jù)到上游服務(wù)器時，連接被拒絕而拋出如下錯誤日志：

2024/06/20 13:35:06 [error] 15030#0: send() failed (111: Connection refused)
2024/06/20 13:35:09 [error] 15030#0: send() failed (111: Connection refused)
2024/06/20 13:35:12 [error] 15030#0: send() failed (111: Connection refused)
2024/06/20 13:35:15 [error] 15030#0: send() failed (111: Connection refused)

在連接建立后，即使上游服務(wù)器通過了健康檢查確認為健康狀態(tài)，但在實際發(fā)送數(shù)據(jù)時，服務(wù)器可能由于負載過高、連接限制或其他原因拒絕處理請求。

客戶端請求處理：

• 配置了健康檢查后，NGINX 會在發(fā)送實際請求之前先檢查上游服務(wù)器的健康狀態(tài)。
• 如果上游服務(wù)器在健康檢查時被標記為不可用，NGINX 將不會將客戶端的請求發(fā)送到該上游服務(wù)器。
• 這種情況下，客戶端的請求不會被打到處于故障狀態(tài)的上游服務(wù)器，因為 NGINX 在發(fā)送請求之前會先確認上游服務(wù)器的可用性。

小結(jié)

1、nginx 未設(shè)置健康檢查報錯

這類報錯是在連接建立階段出現(xiàn)連接被拒絕的錯誤，通常因為上游服務(wù)器未能正常啟動或者未響應(yīng)。

2、nginx 設(shè)置了健康檢查報錯

康狀態(tài)，但在實際發(fā)送數(shù)據(jù)時，服務(wù)器可能由于負載過高、連接限制或其他原因拒絕處理請求。

3、健康檢查的目的

實現(xiàn)高可用。

到此這篇關(guān)于Nginx 負載均衡實現(xiàn)上游服務(wù)健康檢查的文章就介紹到這了,更多相關(guān)Nginx 負載均衡健康檢查內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論