国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Nginx http運行狀況健康檢查配置

animabear / 2532人閱讀

摘要:服務器被標記為不健康,并且在再次通過運行狀況檢查之前不會向其發送客戶端請求。對于上面聲明的樣本組中的第一個服務器,運行狀況檢查會請求。響應必須滿足塊中定義的所有條件,以便服務器通過運行狀況檢查。

原文鏈接:何曉東 博客

翻譯自 官方文檔
被動檢查

對于被動健康檢查,NGINX 和 NGINX Plus 會在事件發生時對其進行監控,并嘗試恢復失敗的連接。如果仍然無法恢復正常,NGINX 開源版和 NGINX Plus 會將服務器標記為不可用,并暫時停止向其發送請求,直到它再次標記為活動狀態。

上游服務器標記為不可用的條件是為每個上游服務器定義的,其中包含塊中 server 指令的參數 upstream

fail_timeout - 設置服務器標記為不可用時必須進行多次失敗嘗試的時間,以及服務器標記為不可用的時間(默認為 10 秒)。

max_fails - 設置在 fail_timeout 服務器標記為不可用期間必須發生的失敗嘗試次數(默認為 1 次嘗試)。

在以下示例中,如果 NGINX 未能在 30 秒內向服務器發送請求或未收到響應 3 次,則表示服務器在 30 秒內不可用:

upstream backend {
    server backend1.example.com;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

需要注意的是如果只有一個單一的服務器組中,將 fail_timeoutmax_fails 參數被忽略,服務器永遠不會標記為不可用。

服務器慢啟動

最近恢復的服務器很容易被連接淹沒,這可能導致服務器再次被標記為不可用。慢啟動允許上游服務器在恢復或變得可用之后逐漸將其權重從零恢復到其標稱值。這可以指定 upstream 的 server 模塊的 slow_start 參數來完成:

upstream backend {
    server backend1.example.com slow_start=30s;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

注意:如果組中只有一臺服務器,則 slow_start 參數將被忽略,而服務器永遠不會被標記位不可用狀態。慢啟動是 NGINX Plus 的專有功能

NGINX Plus的主動檢查

NGINX Plus 可以通過向每個服務器發送特殊的健康檢查請求并驗證正確的響應來定期檢查上游服務器的運行狀況。

要啟用活動運行狀況檢查:

location 區塊將 requests(proxy_pass)傳遞給上游組的過程中,包含 health_check 指令:

server {
    location / {
        proxy_pass http://backend;
        health_check;
    }
}

此代碼段定義了一個服務器,它將所有請求匹配到 location / 傳遞給調用的上游組 backend。它還使用該 health_check 指令啟用高級運行狀況監視:默認情況下,NGINX Plus 每五秒向組中的每個服務器發送一個 "/" 請求 backend。如果任何通信錯誤或發生超時(在服務器返回的狀態碼超出 200- 399的范圍)的健康檢查失敗。服務器被標記為不健康,并且 NGINX Plus 在再次通過運行狀況檢查之前不會向其發送客戶端請求。

另一個可選項:您可以指定另一個用于運行狀況檢查的端口,例如,用于監視同一主機上的許多服務的運行狀況。使用指令的 port 參數指定新端口 health_check:

server {
    location / {
        proxy_pass   http://backend;
        health_check port=8080;
    }
}

在上游服務器組,使用 zone 指令定義一個共享內存區域:

http {
    upstream backend {
        zone backend 64k;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
        server backend4.example.com;
    }
}

該區域在所有工作進程之間共享,并存儲上游組的配置。這使工作進程能夠使用同一組計數器來跟蹤組中服務器的響應。

可以使用 health_check 指令的參數覆蓋活動運行狀況檢查的默認值:

location / {
    proxy_pass http://backend;
    health_check interval=10 fails=3 passes=2;
}

此處,該 interval 參數將運行狀況檢查之間的延遲從默認的 5 秒增加到 10 秒。該 fails 參數要求服務器三次運行狀況檢查失敗時,以將其標記為運行狀況不佳(從默認值開始)。最后,passes 參數意味著服務器必須通過兩次連續檢查才能再次標記為健康,而不是默認值。

指定請求的URL

health_check 指令中指定 uri 參數來設置健康檢查請求的路由:

location / {
    proxy_pass http://backend;
    health_check uri=/some/path;
}

指定的 URI 將附加到為 upstream 塊中的服務器設置的服務器域名或IP地址。對于backend 上面聲明的樣本組中的第一個服務器,運行狀況檢查會請求URI http://backend1.example.com/s...。

定義自定義條件

您可以設置響應必須滿足的自定義條件,以便服務器通過運行狀況檢查。條件在match塊中定義,該塊match在health_check指令的參數中引用。

http {} 級別,指定 match {} 塊并為其命名,例如:"server_ok"

http {
    #...

    match server_ok {
        # tests are here
        
    }
}

health_check 通過指定塊的 match 參數和 match 參數塊的名稱:

http {
    #...

    match server_ok {
        status 200-399;
        body !~ "maintenance mode";
    }
    server {
        #...
        
        location / {
            proxy_pass http://backend;
            health_check match=server_ok;
        }
    }
}

如果響應的狀態代碼在范圍中,則傳遞運行狀況檢查 200- 399 并且其正文不包含字符串: "maintenance mode"

該 match 指令使 NGINX Plus 能夠檢查狀態代碼,標題字段和響應正文。使用此指令可以驗證狀態是否在指定范圍內,響應是否包含標頭,或者標頭或正文是否與正則表達式匹配。該 match 指令可以包含一個狀態條件,一個正文條件和多個標題條件。響應必須滿足 match 塊中定義的所有條件,以便服務器通過運行狀況檢查。

例如,下面的 match 指令匹配有狀態代碼響應 200,精確值 text/html 的Content-Type 標題,頁面中的文字:"Welcome to nginx!".

match welcome {
    status 200;
    header Content-Type = text/html;
    body ~ "Welcome to nginx!";
}

以下示例使用感嘆號(!)來定義響應不得通過運行狀況檢查的特征。在這種情況下,健康檢查在非 301,302,303,或 307狀態碼,同時并沒有 Refresh 頭信息時將通過檢查,。

match not_redirect {
    status ! 301-303 307;
    header ! Refresh;
}

健康檢查可以在其他非 HTTP 協議中啟用, 例如 FastCGI, memcached, SCGI, uwsgi 甚至 TCP 和 UDP。

很多很好的特性,就是需要 Nginx Plus 才能使用。

順道推薦幾個質量不錯的小冊 → 去看看

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/31515.html

相關文章

  • Nginx http運行狀況健康檢查配置

    摘要:服務器被標記為不健康,并且在再次通過運行狀況檢查之前不會向其發送客戶端請求。對于上面聲明的樣本組中的第一個服務器,運行狀況檢查會請求。響應必須滿足塊中定義的所有條件,以便服務器通過運行狀況檢查。 原文鏈接:何曉東 博客 翻譯自 官方文檔 被動檢查 對于被動健康檢查,NGINX 和 NGINX Plus 會在事件發生時對其進行監控,并嘗試恢復失敗的連接。如果仍然無法恢復正常,NGINX...

    daydream 評論0 收藏0
  • Nginx 學習總結(6) —— 負載均衡

    摘要:實現負載均衡負載均衡是反向代理技術的一種運用。而實現負載均衡的核心在于如何將請求合理地分配給不同的后端服務器。 這是 Nginx 學習總結的第六篇,上一篇介紹到了 Nginx 學習總結(5) —— 反向代理,本文主要演示結合 proxy 和 upstream 模塊的使用來實現 Nginx 的負載均衡。 Nginx 官網中對 upstream 模塊的介紹:ngx_http_upstrea...

    wwq0327 評論0 收藏0
  • 負載均衡-私有云負載均衡

    摘要:當負載均衡器接受到來自客戶端的請求后,會通過一系列負載均衡算法,將訪問請求路由分發到后端虛擬機服務器池進行請求處理,同時由將處理結果返回給客戶端。支持內網和外網兩種類型負載均衡器,滿足內網數據中心及互聯網服務負載均衡應用場景。4.7.1 負載均衡概述負載均衡( Load Balance )是由多臺服務器以對稱的方式組成一個服務器集合,每臺服務器都具有等價的地位,均可單獨對外提供服務而無須其它...

    ernest.wang 評論0 收藏0
  • 反向代理 and 負載均衡

    摘要:負載均衡的平衡機制輪詢,向應用服務器的請求以循環方式分發。服務器健康檢查中的反向代理實現包括帶內或被動服務器運行狀況檢查。 nginx 負載均衡的平衡機制 輪詢,向應用服務器的請求以循環方式分發。 最少連接,下一個請求被分配給具有最少數量活動連接的服務器(最清閑的服務器)。 ip-hash,哈希函數用于確定下一個請求(基于客戶端的IP地址)應選擇哪個服務器(相同IP 的發送到同一個服...

    OnlyLing 評論0 收藏0

發表評論

0條評論

animabear

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<