nginx後端節點健康檢查
一、nginx健康檢查的三種方式
1、ngx_http_proxy_module 模組和ngx_http_upstream_module模組（自帶） 官網地址：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream 2、nginx_upstream_check_module模組 官網網址：https://github.com/yaoweibin/nginx_upstream_check_module
二、ngx_http_proxy_module 模組和ngx_http_upstream_module模組（自帶）
嚴格來說，nginx自帶是沒有針對負載均衡後端節點的健康檢查的，但是可以通過預設自帶的ngx_http_proxy_module 模組和ngx_http_upstream_module模組中的相關指令來完成當後端節點出現故障時，自動切換到健康節點來提供訪問。
ngx_http_proxy_module 模組中的 proxy_connect_timeout 指令、proxy_read_timeout指令和proxy_next_upstream指令
設定與後端伺服器建立連線的超時時間。應該注意這個超時一般不可能大於75秒。 語法: proxy_connect_timeouttime; 預設值: proxy_connect_timeout 60s; 上下文: http, server, location 定義從後端伺服器讀取響應的超時。此超時是指相鄰兩次讀操作之間的最長時間間隔，而不是整個響應傳輸完成的最長時間。如果後端伺服器在超時時間段內沒有傳輸任何資料，連線將被關閉。 語法: proxy_read_timeout time; 預設值: proxy_read_timeout 60s; 上下文: http, server, location 語法: 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 指定在何種情況下一個失敗的請求應該被髮送到下一臺後端伺服器： error # 和後端伺服器建立連線時，或者向後端伺服器傳送請求時，或者從後端伺服器接收響應頭時，出現錯誤 timeout # 和後端伺服器建立連線時，或者向後端伺服器傳送請求時，或者從後端伺服器接收響應頭時，出現超時 invalid_header # 後端伺服器返回空響應或者非法響應頭 http_500 # 後端伺服器返回的響應狀態碼為500 http_502 # 後端伺服器返回的響應狀態碼為502 http_503 # 後端伺服器返回的響應狀態碼為503 http_504 # 後端伺服器返回的響應狀態碼為504 http_404 # 後端伺服器返回的響應狀態碼為404 off # 停止將請求傳送給下一臺後端伺服器 需要理解一點的是，只有在沒有向客戶端傳送任何資料以前，將請求轉給下一臺後端伺服器才是可行的。也就是說，如果在傳輸響應到客戶端時出現錯誤或者超時，這類錯誤是不可能恢復的。 http { proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header; }
ngx_http_upstream_module模組中的server指令
示例： 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; }
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自帶的兩個和後端健康檢查相關的模組。
二、nginx_upstream_check_module模組
除了自帶的上述模組，還有一個更專業的模組，來專門提供負載均衡器內節點的健康檢查的。這個就是淘寶技術團隊開發的 nginx 模組 nginx_upstream_check_module，通過它可以用來檢測後端 realserver 的健康狀態。如果後端 realserver 不可用，則所以的請求就不會轉發到該節點上。
在淘寶自己的 tengine 上是自帶了該模組的，大家可以訪問淘寶tengine的官網來獲取該版本的nginx，官方地址：http://tengine.taobao.org/。
2.1 安裝方法
A. 可以為nginx打補丁
B. 現有的nginx替換成tengine：原nginx編譯引數不變，只進行make操作，然後把編譯成功的(tengine中objs下)nginx命令替換到原有的nginx命令即可。
[[email protected] ~]# wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master [[email protected] ~]# unzip master [[email protected] ~]# ll -d nginx_upstream_check_module-master drwxr-xr-x 6 root root 4096 Aug 12 22:42 nginx_upstream_check_module-master [[email protected]192-168-7-77 ~]# cd /usr/local/src/nginx-1.10.3 #進入nginx原始碼目錄 [[email protected] nginx-1.10.3]# patch -p1 < ../nginx_upstream_check_module-master/check_1.5.12+.patch #選擇補丁版本 [[email protected] nginx-1.10.3]# ./configure --prefix=/etc/nginx --with-pcre=../pcre-8.36 --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf \ --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock \ --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp \ --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module \ --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module \ --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module \ --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-openssl=/usr/local/src/openssl-1.0.2o --with-http_v2_module \ --add-module=../nginx_upstream_check_module-master #以上編譯引數需要和原來一樣 [[email protected] nginx-1.10.3]# make #只進行make，不要make install [[email protected] nginx-1.10.3]# mv /usr/sbin/nginx /usr/sbin/nginx.bak [[email protected] nginx-1.10.3]# cp objs1/nginx /usr/sbin/nginx [[email protected] nginx-1.10.3]# nginx -t [[email protected] nginx-1.10.3]# kill -USR2 `cat /var/run/nginx.pid`
2.2 在nginx的配置檔案中加入如下內容：
upstream app { server 192.168.7.71:8080; server 192.168.7.72:8080; #對app負載均衡的條目中的所有節點，每3秒檢測一次，請求1次則標記為realserver狀態為up，如果檢測3次都失敗，則標記realserver為down狀態，超時時間3秒 check interval=3000 rise=1 fall=3 timeout=3000 type=http; #配置http傳送請求，其預設值為1，表示tengine完成1次請求後即關閉連線 check_keepalive_requests 1; #配置http健康檢查包傳送的請求內容，在採用GET方法的情況下，請求uri的size不宜過大，確保可以在1個interval內傳輸完成，否則會被健康檢查模組視為後端服務或網路異常 #其中/status/status.html需要在後端主機中建立目錄和檔案，只要能訪問到就可以，內容隨意。 check_http_send "GET /status/status.html HTTP/1.1\r\nConnection: close\r\nHost: localhost\r\n\r\n"; #該指令指定HTTP回昨的成功狀態，預設為2XX和3XX的狀態是健康的 check_http_expect_alive http_2xx http_3xx; }
3.3 安裝tengine過程中的報錯，因為openssl的版本過高，替換成openssl-1.0.2o版本後問題消失。
參考：http://www.iyunv.com/thread-38535-1-1.html