原文地址：http://nolinux.blog.51cto.com/4824967/1594029
|
1
2
3
4
5
6
|
1、ngx_http_proxy_module 模塊和ngx_http_upstream_module模塊（自帶） 官網地址：http://nginx.org/cn/docs/http/ngx_http_proxy_module.html#proxy_next_upstream2、nginx_upstream_check_module模塊 官網網址：https://github.com/yaoweibin/nginx_upstream_check_module3、ngx_http_healthcheck_module模塊 官網網址：http://wiki.nginx.org/NginxHttpHealthcheckModule |
|
1
2
3
|
語法:
proxy_connect_timeout time;默認值:
proxy_connect_timeout 60s;上下文:
http, server, location |
|
1
2
3
|
語法:
proxy_read_timeout time;默認值:
proxy_read_timeout 60s;上下文:
http, server, location |
|
1
2
3
|
語法:
proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...;默認值:
proxy_next_upstream error timeout;上下文:
http, server, location |
|
1
2
3
4
5
6
7
8
9
|
error # 和後端服務器建立連接時，或者向後端服務器發送請求時，或者從後端服務器接收響應頭時，出現錯誤timeout # 和後端服務器建立連接時，或者向後端服務器發送請求時，或者從後端服務器接收響應頭時，出現超時invalid_header # 後端服務器返回空響應或者非法響應頭http_500 # 後端服務器返回的響應狀態碼爲500http_502 # 後端服務器返回的響應狀態碼爲502http_503 # 後端服務器返回的響應狀態碼爲503http_504 # 後端服務器返回的響應狀態碼爲504http_404 # 後端服務器返回的響應狀態碼爲404off # 停止將請求發送給下一臺後端服務器 |
|
1
2
3
|
http {proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header;} |
|
1
2
3
|
語法:
server address [parameters];默認值:
—上下文:
upstream |
|
1
2
3
4
|
upstream name { server 10.1.1.110:8080 max_fails=1 fail_timeout=10s; server 10.1.1.122:8080 max_fails=1 fail_timeout=10s; } |
|
1
2
3
4
5
6
|
max_fails=number # 設定Nginx與服務器通信的嘗試失敗的次數。在fail_timeout參數定義的時間段內，如果失敗的次數達到此值，Nginx就認爲服務器不可用。在下一個fail_timeout時間段，服務器不會再被嘗試。 失敗的嘗試次數默認是1。設爲0就會停止統計嘗試次數，認爲服務器是一直可用的。 你可以通過指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream來配置什麼是失敗的嘗試。 默認配置時，http_404狀態不被認爲是失敗的嘗試。fail_timeout=time # 設定服務器被認爲不可用的時間段以及統計失敗嘗試次數的時間段。在這段時間中，服務器失敗次數達到指定的嘗試次數，服務器就被認爲不可用。默認情況下，該超時時間是10秒。 在實際應用當中，如果你後端應用是能夠快速重啓的應用，比如nginx的話，自帶的模塊是可以滿足需求的。但是需要注意。如果後端有不健康節點，負載均衡器依然會先把該請求轉發給該不健康節點，然後再轉發給別的節點，這樣就會浪費一次轉發。 可是，如果當後端應用重啓時，重啓操作需要很久才能完成的時候就會有可能拖死整個負載均衡器。此時，由於無法準確判斷節點健康狀態，導致請求handle住，出現假死狀態，最終整個負載均衡器上的所有節點都無法正常響應請求。由於公司的業務程序都是java開發的，因此後端主要是nginx集羣和tomcat集羣。由於tomcat重啓應部署上面的業務不同，有些業務啓動初始化時間過長，就會導致上述現象的發生，因此不是很建議使用該模式。 並且ngx_http_upstream_module模塊中的server指令中的max_fails參數設置值，也會和ngx_http_proxy_module 模塊中的的proxy_next_upstream指令設置起衝突。比如如果將max_fails設置爲0，則代表不對後端服務器進行健康檢查，這樣還會使fail_timeout參數失效（即不起作用）。此時，其實我們可以通過調節ngx_http_proxy_module 模塊中的 proxy_connect_timeout 指令、proxy_read_timeout指令，通過將他們的值調低來發現不健康節點，進而將請求往健康節點轉移。 以上就是nginx自帶的兩個和後端健康檢查相關的模塊。 |
|
1
2
3
4
5
|
[root@localhost ~]# cd /usr/local/srcwget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/masterunzip master[root@localhost /usr/local/src]# ll -d nginx_upstream_check_module-masterdrwxr-xr-x. 6 root root 4096 Dec 1 02:28 nginx_upstream_check_module-master |
|
1
2
3
4
5
6
7
8
|
[root@localhost /usr/local/src]# cd nginx-1.6.0 # 進入nginx的源碼目錄[root@localhost nginx-1.6.0]# patch -p1 < ../nginx_upstream_check_module-master/check_1.5.12+.patch[root@localhost nginx-1.6.0]# ./configure --user=nginx --group=nginx --prefix=/usr/local/nginx-1.6.0 --with-http_ssl_module --with-openssl=/usr/local/src/openssl-0.9.8q --with-pcre=/usr/local/src/pcre-8.32 --add-module=/usr/local/src/nginx_concat_module/ --add-module=../nginx_upstream_check_module-master/make (注意：此處只make，編譯參數需要和之前的一樣)[root@localhost nginx-1.6.0]# mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx-1.6.0.bak[root@localhost nginx-1.6.0]# cp ./objs/nginx /usr/local/nginx/sbin/[root@localhost nginx-1.6.0]# /usr/local/nginx/sbin/nginx -t # 檢查下是否有問題[root@localhost nginx-1.6.0]# kill -USR2 `cat /usr/local/nginx/logs/nginx.pid` |
|
1
2
3
4
5
6
|
upstream name { server 192.168.0.21:80; server 192.168.0.22:80; check interval=3000 rise=2 fall=5 timeout=1000 type=http; } |
|
1
2
3
|
Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]Default: 如果沒有配置參數，默認值是：interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcpContext: upstream |
|
1
2
3
4
5
6
7
8
9
10
11
12
|
- interval：向後端發送的健康檢查包的間隔。 - fall(fall_count): 如果連續失敗次數達到fall_count，服務器就被認爲是down。 - rise(rise_count): 如果連續成功次數達到rise_count，服務器就被認爲是up。 - timeout: 後端健康請求的超時時間。 - default_down: 設定初始時服務器的狀態，如果是true，就說明默認是down的，如果是false，就是up的。默認值是true，也就是一開始服務器認爲是不可用，要等健康檢查包達到一定成功次數以後纔會被認爲是健康的。 - type：健康檢查包的類型，現在支持以下多種類型 - tcp：簡單的tcp連接，如果連接成功，就說明後端正常。 - ssl_hello：發送一個初始的SSL hello包並接受服務器的SSL hello包。 - http：發送HTTP請求，通過後端的回覆包的狀態來判斷後端是否存活。 - mysql: 向mysql服務器連接，通過接收服務器的greeting包來判斷後端是否存活。 - ajp：向後端發送AJP協議的Cping包，通過接收Cpong包來判斷後端是否存活。 - port: 指定後端服務器的檢查端口。你可以指定不同於真實服務的後端服務器的端口，比如後端提供的是443端口的應用，你可以去檢查80端口的狀態來判斷後端健康狀況。默認是0，表示跟後端server提供真實服務的端口一樣。該選項出現於Tengine-1.4.0。 |
|
1
2
3
|
Syntax: check_keepalive_requests request_numDefault: 1Context: upstream |
|
1
2
3
|
Syntax: check_http_send http_packetDefault: "GET / HTTP/1.0\r\n\r\n"Context: upstream |
|
1
2
3
|
Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]Default: http_2xx | http_3xxContext: upstream |
|
1
2
3
|
Syntax: check_shm_size sizeDefault: 1MContext: http |
|
1
2
3
|
Syntax: check_status [html|csv|json]Default: check_status htmlContext: location |
|
1
2
3
|
/status?format=html/status?format=csv/status?format=json |
|
1
2
|
/status?format=html&status=down/status?format=csv&status=up |
|
1
2
3
4
5
6
7
8
9
10
|
http { server { location /nstatus { check_status; access_log off; #allow IP; #deny all; } }} |
