Nginx+upstream針對後端伺服器容錯的運維筆記

散盡浮華發表於2018-01-03
Nginx後端伺服器運維筆記

 

熟練掌握Nginx負載均衡的使用對運維人員來說是極其重要的！下面針對Nignx負載均衡upstream容錯機制的使用做一梳理性說明：

一、nginx的upstream容錯

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，但是下次訪問節點時會繼續探測正確節點，直到找到正確的為止。

4）通過proxy_next_upstream實現容災和重複處理問題
ngx_http_proxy_module 模組中包括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   表示停止將請求傳送給下一臺後端伺服器

運用場景

1）proxy_next_upstream http_500 | http_502 | http_503 | http_504 |http_404;
當其中一臺返回錯誤碼404,500...等錯誤時，可以分配到下一臺伺服器程式繼續處理，提高平臺訪問成功率，多可運用於前臺程式負載，設定

2、proxy_next_upstream off
因為proxy_next_upstream 預設值: proxy_next_upstream error timeout;

場景:
當訪問A時，A返回error timeout時，訪問會繼續分配到下一臺伺服器處理，就等於一個請求分發到多臺伺服器，就可能出現多次處理的情況，
如果涉及到充值，就有可能充值多次的情況，這種情況下就要把proxy_next_upstream關掉即可
proxy_next_upstream off

案例分析（nginx proxy_next_upstream導致的一個重複提交錯誤）：
一個請求被重複提交，原因是nginx代理後面掛著2個伺服器，請求超時的時候（其實已經處理了），結果nigix發現超時，有把請求轉給另外臺伺服器又做了次處理。

解決辦法：
proxy_next_upstream:off

二、nginx負載均衡
Nginx的負載均衡方式這裡介紹4種：rr(輪詢模式)、ip_hash、fair、url_hash；
Nginx自帶的2種負載均衡為rr和ip_hash，fair和url_hash為第三方的外掛，nginx在不配置負載均衡的模式下，預設採用rr負載均衡模式。
1）RR負載均衡模式：
每個請求按時間順序逐一分配到不同的後端伺服器，如果超過了最大失敗次數後（max_fails,預設1），在失效時間內(fail_timeout，預設10秒)，該節點失效權重變為0，超過失效時間後，則恢復正常，或者全部節點都為down後，那麼將所有節點都恢復為有效繼續探測，一般來說rr可以根據權重來進行均勻分配。
2）Ip_hash負載均衡模式：
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題，但是ip_hash會造成負載不均，有的服務請求接受多，有的服務請求接受少，所以不建議採用ip_hash模式，session共享問題可用後端服務的session共享代替nginx的ip_hash。
3）Fair（第三方）負載均衡模式：
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
4）url_hash（第三方）負載均衡模式：
和ip_hash演算法類似，是對每個請求按url的hash結果分配，使每個URL定向到一個同 一個後端伺服器，但是也會造成分配不均的問題，這種模式後端伺服器為快取時比較好。

三、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.kevin.com;
  server   backend2.kevin.com;
  server   backend3.kevin.com  down;
  server   backend4.kevin.com;
}

server
語法：server name [parameters]
預設值：none
使用欄位：upstream
指定後端伺服器的名稱和一些引數，可以使用域名，IP，埠，或者unix socket。如果指定為域名，則首先將其解析為IP。
[1]  weight = NUMBER - 設定伺服器權重，預設為1。
[2]  max_fails = NUMBER - 在一定時間內（這個時間在fail_timeout引數中設定）檢查這個伺服器是否可用時產生的最多失敗請求數，預設為1，將其設定為0可以關閉檢查，這些錯誤在proxy_next_upstream或fastcgi_next_upstream（404錯誤不會使max_fails增加）中定義。
[3]  fail_timeout = TIME - 在這個時間內產生了max_fails所設定大小的失敗嘗試連線請求後這個伺服器可能不可用，同樣它指定了伺服器不可用的時間（在下一次嘗試連線請求發起之前），預設為10秒，fail_timeout與前端響應時間沒有直接關係，不過可以使用proxy_connect_timeout和proxy_read_timeout來控制。
[4]  down - 標記伺服器處於離線狀態，通常和ip_hash一起使用。
[5]  backup - (0.6.7或更高)如果所有的非備份伺服器都當機或繁忙，則使用本伺服器（無法和ip_hash指令搭配使用）。

例項配置

upstream  backend  {
  server   backend1.kevin.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 kevin.com weight=5;
  server 127.0.0.1:8080       max_fails=3  fail_timeout=30s;
  server unix:/tmp/backend3;
}

請求將按照輪詢的方式分發到後端伺服器，但同時也會考慮權重。
在上面的例子中如果每次發生7個請求，5個請求將被髮送到backend1.kevin.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';

$upstream_addr
前端伺服器處理請求的伺服器地址

$upstream_cache_status
顯示快取的狀態

nginx在web應用上的佔用率越來越高，其帶的模組也越來越來。nginx_cache算是一個，雖和專業的cache工具相比略遜一籌，但畢竟部署簡單，不用另裝軟體
和資源開銷，所以在web cache中也佔了比重不小的一席。不過像squid和varnish等cache軟體都自帶的有cache檢視工具，而且還可以方便的在http header上
顯示出是否命中。nginx主要還是做web使用。所以想要得出命中率的大小，還需要通過日誌進行統計，不過想要增加header檢視倒很簡單
 
1）在http header上增加命中顯示
nginx提供了$upstream_cache_status這個變數來顯示快取的狀態，我們可以在配置中新增一個http頭來顯示這一狀態，達到類似squid的效果。
location  / {
        proxy_redirect          off;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout   180;
        proxy_send_timeout      180;
        proxy_read_timeout      180;
        proxy_buffer_size       128k;
        proxy_buffers           4 128k;
        proxy_busy_buffers_size 128k;
        proxy_temp_file_write_size 128k;
        proxy_cache cache;
        proxy_cache_valid 200 304 1h;
        proxy_cache_valid 404 1m;
        proxy_cache_key $uri$is_args$args;
        add_header  Nginx-Cache "$upstream_cache_status";
        proxy_pass http://backend;
    }
 
 
而通過curl或瀏覽器檢視到的header如下：
HTTP/1.1 200 OK
Date: Mon, 22 Apr 2013 02:10:02 GMT
Server: nginx
Content-Type: image/jpeg
Content-Length: 23560
Last-Modified: Thu, 18 Apr 2013 11:05:43 GMT
Nginx-Cache: HIT
Accept-Ranges: bytes
Vary: User-Agent
 
 
$upstream_cache_status包含以下幾種狀態：
·MISS 未命中，請求被傳送到後端
·HIT 快取命中
·EXPIRED 快取已經過期請求被傳送到後端
·UPDATING 正在更新快取，將使用舊的應答
·STALE 後端將得到過期的應答
=======================================================================================================================
nginx比較強大,可以針對單個域名請求做出單個連線超時的配置. 可以根據業務的：

proxy_connect_timeout :後端伺服器連線的超時時間_發起握手等候響應超時時間
proxy_read_timeout:連線成功後，等候後端伺服器響應時間_其實已經進入後端的排隊之中等候處理（也可以說是後端伺服器處理請求的時間）
proxy_send_timeout :後端伺服器資料回傳時間_就是在規定時間之內後端伺服器必須傳完所有的資料

$upstream_status
前端伺服器的響應狀態。

$upstream_response_time
前端伺服器的應答時間，精確到毫秒，不同的應答以逗號和冒號分開。

$upstream_http_$HEADER
隨意的HTTP協議頭，如：$upstream_http_host

$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小時。

四、Nginx upstream負載均衡獲取後端伺服器的流程
GET_RR_PEER： 通過RR演算法獲取後端流程

K：是判斷peer是否當機和判斷失效狀態演算法

FAIL:嘗試次數用盡有，跳轉到失敗流程，如果有備機，備機再嘗試監聽，如果監聽失敗則返回NGX_BUSY,成功則返回當前狀態。

五、驗證環境部署
Web伺服器: nginx
Web應用伺服器：tomcat(2臺)

Nginx反向代理tomcat，即通過upstream將請求負載到後端兩臺tomcat的對應服務埠上。部署過程此處省略......

六、驗證結果說明
1）設定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上。

2）設定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上。

3）設定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上。

4）設定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上。

5）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均不記錄失敗。

相關文章