nginx upstream 容錯機制
轉自：http://saiyaren.iteye.com/blog/1914865
1. 摘要
（1） 結論
詳細描述了nginx記錄失效節點的6種狀態(time out、connect refuse、500、502、503、504，後四項5XX需要配置proxy_next_upstream中的狀態才可以生效)、失效節點的觸發條件和節點的恢復條件、所有節點失效後nginx會進行恢復並進行重新監聽。
（2） Nginx 負載均衡方式介紹
Nginx的負載均衡方式一共有4種：rr(輪詢模式)、ip_hash、fair、url_hash。
（3） Ngxin負載均衡和相關反向代理配置內容
Nginx負載均衡和與容錯相關的反向代理的配置。
（4） 獲取後端流程
後端server的自動容錯流程圖。
（5） 測試環境和測試結果
針對幾種錯誤方式進行自動容錯測試。
2. 結論
（1） nginx 判斷節點失效狀態
Nginx 默認判斷失敗節點狀態以connect refuse和time out狀態為準，不以HTTP錯誤狀態進行判斷失敗，因為HTTP只要能返回狀態說明該節點還可以正常連接，所以nginx判斷其還是存活狀態；除非添加了proxy_next_upstream指令設置對404、502、503、504、500和time out等錯誤進行轉到備機處理，在next_upstream過程中，會對fails進行累加，如果備用機處理還是錯誤則直接返回錯誤信息（但404不進行記錄到錯誤數，如果不配置錯誤狀態也不對其進行錯誤狀態記錄），綜述，nginx記錄錯誤數量只記錄timeout 、connect refuse、502、500、503、504這6種狀態，timeout和connect refuse是永遠被記錄錯誤狀態，而502、500、503、504只有在配置proxy_next_upstream後nginx才會記錄這4種HTTP錯誤到fails中，當fails大於等於max_fails時，則該節點失效；
（2） nginx 處理節點失效和恢復的觸發條件
nginx可以通過設置max_fails（最大嘗試失敗次數）和fail_timeout（失效時間，在到達最大嘗試失敗次數後，在fail_timeout的時間範圍內節點被置為失效，除非所有節點都失效，否則該時間內，節點不進行恢復）對節點失敗的嘗試次數和失效時間進行設置，當超過最大嘗試次數或失效時間未超過配置失效時間，則nginx會對節點狀會置為失效狀態，nginx不對該後端進行連接，直到超過失效時間或者所有節點都失效後，該節點重新置為有效，重新探測；
（3） 所有節點失效後nginx將重新恢復所有節點進行探測
如果探測所有節點均失效，備機也為失效時，那麽nginx會對所有節點恢復為有效，重新嘗試探測有效節點，如果探測到有效節點則返回正確節點內容，如果還是全部錯誤，那麽繼續探測下去，當沒有正確信息時，節點失效時默認返回狀態為502，但是下次訪問節點時會繼續探測正確節點，直到找到正確的為止。
3. nginx負載均衡
Nginx的負載均衡方式一共有4種：rr(輪詢模式)、ip_hash、fair、url_hash；
Nginx自帶的2種負載均衡為rr和ip_hash，fair和url_hash為第三方的插件，nginx在不配置負載均衡的模式下，默認采用rr負載均衡模式。
l RR負載均衡模式：
每個請求按時間順序逐一分配到不同的後端服務器，如果超過了最大失敗次數後（max_fails,默認1），在失效時間內(fail_timeout，默認10秒)，該節點失效權重變為0，超過失效時間後，則恢復正常，或者全部節點都為down後，那麽將所有節點都恢復為有效繼續探測，一般來說rr可以根據權重來進行均勻分配。
l Ip_hash負載均衡模式：
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端服務器，可以解決session的問題，但是ip_hash會造成負載不均，有的服務請求接受多，有的服務請求接受少，所以不建議采用ip_hash模式，session共享問題可用後端服務的session共享代替nginx的ip_hash。
l Fair（第三方）負載均衡模式：
按後端服務器的響應時間來分配請求，響應時間短的優先分配。
l url_hash（第三方）負載均衡模式：
和ip_hash算法類似，是對每個請求按url的hash結果分配，使每個URL定向到一個同 一個後端服務器，但是也會造成分配不均的問題，這種模式後端服務器為緩存時比較好。
4. Nginx 負載均衡配置
Nginx的負載均衡采用的是upstream模塊
其中默認的采用的負載均衡模式是輪詢模式rr(round_robin),具體配置如下：
1) 指令：
ip_hash
語法：ip_hash
默認值：none
使用字段：upstream
這個指令將基於客戶端連接的IP地址來分發請求。
哈希的關鍵字是客戶端的C類網絡地址，這個功能將保證這個客戶端請求總是被轉發到一臺服務器上，但是如果這臺服務器不可用，那麽請求將轉發到另外的服務器上，這將保證某個客戶端有很大概率總是連接到一臺服務器。
無法將權重（weight）與ip_hash聯合使用來分發連接。如果有某臺服務器不可用，你必須標記其為“down”，如下例:
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}
server
語法：server name [parameters]
默認值：none
使用字段：upstream
指定後端服務器的名稱和一些參數，可以使用域名，IP，端口，或者unix socket。如果指定為域名，則首先將其解析為IP。
l weight = NUMBER - 設置服務器權重，默認為1。
l max_fails = NUMBER - 在一定時間內（這個時間在fail_timeout參數中設置）檢查這個服務器是否可用時產生的最多失敗請求數，默認為1，將其設置為0可以關閉檢查，這些錯誤在proxy_next_upstream或fastcgi_next_upstream（404錯誤不會使max_fails增加）中定義。
l fail_timeout = TIME - 在這個時間內產生了max_fails所設置大小的失敗嘗試連接請求後這個服務器可能不可用，同樣它指定了服務器不可用的時間（在下一次嘗試連接請求發起之前），默認為10秒，fail_timeout與前端響應時間沒有直接關系，不過可以使用proxy_connect_timeout和proxy_read_timeout來控制。
l down - 標記服務器處於離線狀態，通常和ip_hash一起使用。
l backup - (0.6.7或更高)如果所有的非備份服務器都宕機或繁忙，則使用本服務器（無法和ip_hash指令搭配使用）。
示例配置
upstream backend {
server backend1.example.com weight=5;
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
}
註意：如果你只使用一臺上遊服務器，nginx將設置一個內置變量為1，即max_fails和fail_timeout參數不會被處理。
結果：如果nginx不能連接到上遊，請求將丟失。
解決：使用多臺上遊服務器。
upstream
語法：upstream name { … }
默認值：none
使用字段：http
這個字段設置一群服務器，可以將這個字段放在proxy_pass和fastcgi_pass指令中作為一個單獨的實體，它們可以可以是監聽不同端口的服務器，並且也可以是同時監聽TCP和Unix socket的服務器。
服務器可以指定不同的權重，默認為1。
示例配置
upstream backend {
server backend1.example.com weight=5;
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
}
請求將按照輪詢的方式分發到後端服務器，但同時也會考慮權重。
在上面的例子中如果每次發生7個請求，5個請求將被發送到backend1.example.com，其他兩臺將分別得到一個請求，如果有一臺服務器不可用，那麽請求將被轉發到下一臺服務器，直到所有的服務器檢查都通過。如果所有的服務器都無法通過檢查，那麽將返回給客戶端最後一臺工作的服務器產生的結果。
2) 變量
版本0.5.18以後，可以通過log_module中的變量來記錄日誌：
log_format timing ‘$remote_addr - $remote_user [$time_local] $request ‘
‘upstream_response_time $upstream_response_time ‘
‘msec $msec request_time $request_time‘;
log_format up_head ‘$remote_addr - $remote_user [$time_local] $request ‘
‘upstream_http_content_type $upstream_http_content_type‘;
l $upstream_addr
前端服務器處理請求的服務器地址
l $upstream_cache_status
0.8.3版本中其值可能為：
MISS
EXPIRED - expired。請求被傳送到後端。
UPDATING - expired。由於proxy/fastcgi_cache_use_stale正在更新，將使用舊的應答。
STALE - expired。由於proxy/fastcgi_cache_use_stale，後端將得到過期的應答。
HIT
l $upstream_status
前端服務器的響應狀態。
l $upstream_response_time
前端服務器的應答時間，精確到毫秒，不同的應答以逗號和冒號分開。
l $upstream_http_$HEADER
隨意的HTTP協議頭，如：$upstream_http_host
l $upstream_http_host
3) Proxy指令：
proxy_next_upstream
語法: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 - 禁止轉發請求到下一臺服務器。
轉發請求只發生在沒有數據傳遞到客戶端的過程中。
其中記錄到nginx後端錯誤數量的有500、502、503、504、timeout，404不記錄錯誤。
proxy_connect_timeout
語法：proxy_connect_timeout timeout_in_seconds
默認值：proxy_connect_timeout 60s
使用字段：http, server, location
指定一個連接到代理服務器的超時時間，單位為秒，需要註意的是這個時間最好不要超過75秒。
這個時間並不是指服務器傳回頁面的時間（這個時間由proxy_read_timeout聲明）。如果你的前端代理服務器是正常運行的，但是遇到一些狀況（例如沒有足夠的線程去處理請求，請求將被放在一個連接池中延遲處理），那麽這個聲明無助於服務器去建立連接。
可以通過指定時間單位以免引起混亂，支持的時間單位有”s”(秒), “ms”(毫秒), “y”(年), “M”(月), “w”(周), “d”(日), “h”(小時),和 “m”(分鐘)。
這個值不能大於597小時。
proxy_read_timeout
語法：proxy_read_timeout time
默認值：proxy_read_timeout 60s
使用字段：http, server, location
決定讀取後端服務器應答的超時時間，單位為秒，它決定nginx將等待多久時間來取得一個請求的應答。超時時間是指完成了兩次握手後並且狀態為established的超時時間。
相對於proxy_connect_timeout，這個時間可以撲捉到一臺將你的連接放入連接池延遲處理並且沒有數據傳送的服務器，註意不要將此值設置太低，某些情況下代理服務器將花很長的時間來獲得頁面應答（例如如當接收一個需要很多計算的報表時），當然你可以在不同的location裏面設置不同的值。
可以通過指定時間單位以免引起混亂，支持的時間單位有”s”(秒), “ms”(毫秒), “y”(年), “M”(月), “w”(周), “d”(日), “h”(小時),和 “m”(分鐘)。
這個值不能大於597小時。
proxy_send_timeout
語法：proxy_send_timeout seconds
默認值：proxy_send_timeout 60s
使用字段：http, server, location
設置代理服務器轉發請求的超時時間，單位為秒，同樣指完成兩次握手後的時間，如果超過這個時間代理服務器沒有數據轉發到被代理服務器，nginx將關閉連接。
可以通過指定時間單位以免引起混亂，支持的時間單位有”s”(秒), “ms”(毫秒), “y”(年), “M”(月), “w”(周), “d”(日), “h”(小時),和 “m”(分鐘)。
這個值不能大於597小時。
5. 獲取後端流程
GET_RR_PEER： 通過RR算法獲取後端流程
K:是判斷peer是否宕機和判斷失效狀態算法
FAIL:嘗試次數用盡有，跳轉到失敗流程，如果有備機，備機再嘗試監聽，如果監聽失敗則返回NGX_BUSY,成功則返回當前狀態
6. 測試環境
操作系統：centos5.6
Cpu:16核
內存：32g
Web 服務器:nginx
Web 應用服務器：tomcat(2臺)
7. 測試結果
l 設置tomcat1超時時間，造成超時狀態（總有一臺server為有效狀態）：
Tomcat1的connectionTimeout 設置為-1，永遠超時，nginx設置tomcat1和tomcat2權重為10，tomcat1的max_fails為10，fail_timeout=120；在連接tomcat1的10次後，返回給nginx為10次超時，ngxin判斷tomcat1為失效，然後將tomcat1超時時間恢復為1000重新啟動tomcat1，在這段時間內nginx判斷tomcat1還是失效狀態，所以在2分鐘後，nginx繼續監聽到tomcat1正常後，那麽nginx會將tomcat1判斷為有效，將連接繼續均勻分配到2個tomcat上。
l 設置tomcat1連接數量，造成超時狀態（總有一臺server為有效狀態）：
Tomcat1的線程數量設置為1，nginx設置tomcat1和tomcat2權重為10，tomcat1的max_fails為10，fail_timeout=120；在連接tomcat1超過線程接受數量後，tomcat1會返回超時狀態，在返回給nginx10次超時狀態後，ngxin判斷tomcat1為失效，然後將tomcat線程數量恢復為700,重新啟動tomcat1，在這段時間內nginx判斷tomcat1還是失效狀態，超過2分鐘失效後，nginx繼續監聽到tomcat1正常後，那麽nginx會將tomcat1判斷為有效，將連接繼續均勻分配到2個tomcat上。
l 設置tomcat1關閉，造成拒絕狀態（總有一臺server為有效狀態）：
Tomcat1為關閉，nginx設置tomcat1和tomcat2權重為10，tomcat1的max_fails為10，fail_timeout=120；在連接tomcat1的10次後，nginx收到tomcat1返回connect refuse狀態，ngxin判斷tomcat1為失效，然後重新啟動tomcat1，在這段時間內nginx判斷tomcat1還是失效狀態，超過2分鐘失效後，nginx繼續監聽到tomcat1正常後，那麽nginx會將tomcat1判斷為有效，將連接繼續均勻分配到2個tomcat上。
l 設置tomcat1在nginx1標記失效，tomcat1恢復正常，在nginx失效範圍內，將全部服務變為失效，然後重啟：
Tomcat1為關閉，nginx設置tomcat1和tomcat2權重為10，tomcat1的max_fails為10，fail_timeout=120；在連接tomcat1的10次後，nginx收到tomcat1返回connect refuse狀態，ngxin判斷tomcat1為失效，然後重新啟動tomcat1，在這段時間內nginx判斷tomcat1還是失效狀態，然後將tomcat2關閉，然後重啟tomcat2，由於所有服務均失效，所以nginx 將所有服務重新置為有效進行監聽，然後將2連接均勻分布到了tomcat1和tomcat2上。
l http錯誤狀態，nginx是否記錄失效：
nginx設置tomcat1和tomcat2權重為10，tomcat1的max_fails為10，fail_timeout=120；配置proxy_next_upstream 500、404、502、503、504、timeout後，當HTTP狀態為500、502、503、504(timeout和refuse默認是記錄失效的)時，nginx會判斷該次請求為失敗記錄失敗狀態，其他所有HTTP均不記錄失敗。
nginx upstream 容錯機制