爛泥：高負載均衡學習haproxy之關鍵詞介紹

本文由ilanniweb提供友情贊助，首發於爛泥行天下

上一篇文章咱們簡單講解了有關haproxy的安裝與搭建，在這篇文章咱們把haproxy配置文件中使用到的關鍵詞一一介紹下。

關注我微信ilanniweb

1、關鍵詞balance

balance用於定義負載均衡的算法，可用於defaults、listen和backend中。

balance使用方法以下：

balance <algorithm> [ <arguments> ]

balance url_param <param> [check_post [<max_wait>]]

<algorithm>用於在負載均衡場景中挑選一個server，其僅應用於持久信息不可用的條件下或須要將一個鏈接從新派發至另外一個服務器時。

balance支持的算法有：

roundrobin：基於權重進行輪詢，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重能夠在運行時進行調整。不過在設計上，每一個後端服務器僅能最多接受4128個鏈接。

source：將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器。這可使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不一樣的服務器；經常使用於負載均衡無cookie功能的基於TCP的協議；其默認爲靜態，不過也可使用hash-type修改此特性。

static-rr：基於權重進行輪詢，與roundrobin相似，可是爲靜態方法，在運行時調整其服務器權重不會生效；不過，其在後端服務器鏈接數上沒有限制。

leastconn：新的鏈接請求被派發至具備最少鏈接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的，能夠在運行時調整其權重。

uri：對URI的左半部分(「問題」標記以前的部分)或整個URI進行hash運算，並由服務器的總權重相除後派發至某匹配的服務器；這可使得對同一個URI的請求老是被派發至某特定的服務器，除非服務器的權重總數發生了變化；此算法經常使用於代理緩存或反病毒代理以提升緩存的命中率；須要注意的是，此算法僅應用於HTTP後端服務器場景；其默認爲靜態算法，不過也可使用hash-type修改此特性。

url_param：經過<argument>爲URL指定的參數在每一個HTTP GET請求中將會被檢索；若是找到了指定的參數且其經過等於號「=」被賦予了一個值，那麼此值將被執行hash運算並被服務器的總權重相除後派發至某匹配的服務器；此算法能夠經過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器，除非服務器的總權重發生了變化；若是某請求中沒有出現指定的參數或其沒有有效值，則使用輪叫算法對相應請求進行調度；此算法默認爲靜態的，不過其也可使用hash-type修改此特性。

hdr(<name>)：對於每一個HTTP請求，經過<name>指定的HTTP首部將會被檢索；若是相應的首部沒有出現或其沒有有效值，則使用輪叫算法對相應請求進行調度；其有一個可選選項「use_domain_only」，可在指定檢索相似Host類的首部時僅計算域名部分(好比經過www.ilanni.com來講，僅計算ilanni詞符串的hash值)以下降hash算法的運算量；此算法默認爲靜態的，不過其也可使用hash-type修改此特性；

2、關鍵詞bind

bind僅能用於frontend和listen區段，用於定義一個或幾個監聽的套接詞。

bind使用方法以下：

bind [<address>]:<port_range> [, ...]

bind [<address>]:<port_range> [, ...] interface <interface>

<address>：可選選項，其能夠爲主機名、IPv4地址、IPv6地址或*。省略此選項、將其指定爲*或0.0.0.0時，將監聽當前系統的全部IPv4地址。

<port_range>：能夠是一個特定的TCP端口，也但是一個端口範圍(如5005-5010)，代理服務器將經過指定的端口來接收客戶端請求。

須要注意的是，每組監聽的套接詞<address:port>在同一個實例上只能使用一次，並且小於1024的端口須要有特定權限的用戶才能使用，這可能須要經過uid參數來定義。

<interface>：指定物理接口的名稱，僅能在Linux系統上使用。其不能使用接口別名，而僅能使用物理接口名稱，並且只有管理有權限指定綁定的物理接口。

3、關鍵詞mode

mode用於設定實例的運行模式或協議。當實現內容交換時，前端和後端必須工做於同一種模式(通常說來都是HTTP模式)，不然將沒法啓動實例。

mode可被用與listen、defaults、frontend、backend區段。

mode使用方法以下：

mode { tcp|http|health }

tcp：實例運行於純TCP模式（即4層），在客戶端和服務器端之間將創建一個全雙工的鏈接，且不會對7層報文作任何類型的檢查；此爲默認模式，一般用於SSL、SSH、SMTP等應用。

http：實例運行於HTTP模式（即7層），客戶端請求在轉發至後端服務器以前將被深度分析，全部不與RFC格式兼容的請求都會被拒絕。

health：實例工做於health模式，其對入站請求僅響應「OK」信息並關閉鏈接，且不會記錄任何日誌信息；此模式將用於響應外部組件的健康狀態檢查請求；目前此模式已經廢棄，由於tcp或http模式中的monitor關鍵詞可完成相似功能；

4、關鍵詞hash-type

hash-type定義用於將hash碼映射至後端服務器的方法；其不能用於frontend區段；可用方法有map-based和consistent，在大多數場景下推薦使用默認的map-based方法。

hash-type使用方法以下：

hash-type <method>

map-based：hash表是一個包含了全部在線服務器的靜態數組。其hash值將會很是平滑，會將權重考慮在列，但其爲靜態方法，對在線服務器的權重進行調整將不會生效，這意味着其不支持慢速啓動。此外，挑選服務器是根據其在數組中的位置進行的，所以，當一臺服務器宕機或添加了一臺新的服務器時，大多數鏈接將會被從新派發至一個與此前不一樣的服務器上，對於緩存服務器的工做場景來講，此方法不甚適用。

consistent：hash表是一個由各服務器填充而成的樹狀結構；基於hash鍵在hash樹中查找相應的服務器時，最近的服務器將被選中。此方法是動態的，支持在運行時修改服務器權重，所以兼容慢速啓動的特性。添加一個新的服務器時，僅會對一小部分請求產生影響，所以，尤爲適用於後端服務器爲cache的場景。不過，此算法不甚平滑，派發至各服務器的請求未必能達到理想的均衡效果，所以，可能須要不時的調整服務器的權重以得到更好的均衡性。

5、關鍵詞log

log爲每一個實例啓用事件和流量日誌，所以可用於全部區段。每一個實例最多能夠指定兩個log參數，不過，若是使用了「log global」且"global"段已經定了兩個log參數時，多餘了log參數將被忽略。

log global

log <address> <facility> [<level> [<minlevel>]]

global：當前實例的日誌系統參數同"global"段中的定義時，將使用此格式；每一個實例僅能定義一次「log global」語句，且其沒有任何額外參數。

<address>：定義日誌發往的位置，其格式之一能夠爲<IPv4_address:PORT>，其中的port爲UDP協議端口，默認爲514；格式之二爲Unix套接詞文件路徑，但須要留心chroot應用及用戶的讀寫權限。

<facility>：能夠爲syslog系統的標準facility之一。

<level>：定義日誌級別，即輸出信息過濾器，默認爲全部信息；指定級別時，全部等於或高於此級別的日誌信息將會被髮送。

6、關鍵詞maxconn

maxconn設定一個前端的最大併發鏈接數，所以，其不能用於backend區段。

maxconn使用方法以下：

maxconn <conns>

對於大型站點來講，能夠儘量提升此值以便讓haproxy管理鏈接隊列，從而避免沒法應答用戶請求。固然，此最大值不能超出「global」段中的定義。此外，須要留心的是，haproxy會爲每一個鏈接維持兩個緩衝，每一個緩衝的大小爲8KB，再加上其它的數據，每一個鏈接將大約佔用17KB的RAM空間。這意味着通過適當優化後，有着1GB的可用RAM空間時將能維護40000-50000併發鏈接。

若是爲<conns>指定了一個過大值，極端場景下，其最終佔據的空間可能會超出當前主機的可用內存，這可能會帶來意想不到的結果；所以，將其設定了一個可接受值方爲明智決定。其默認爲2000。

7、關鍵詞default_backend

default_backend定義在沒有匹配的use_backend規則時爲實例指定使用的默認後端服務器，所以，其不可應用於backend區段。在frontend和backend之間進行內容交換時，一般使用use-backend定義其匹配規則；而沒有被規則匹配到的請求將由此參數指定的後端服務器接收。

default_backend使用方法以下：

default_backend <backend>

<backend>：指定使用的後端的名稱。

使用案例：

use_backend dynamic if url_dyn

use_backend static if url_css url_img

default_backend dynamic

8、關鍵詞server

server爲後端聲明一個server，所以，不能用於defaults和frontend區段。

server使用方法以下：

server <name> <address>[:port] [param*]

<name>：爲此服務器指定的內部名稱，其將出如今日誌及警告信息中；若是設定了http-send-server-name，它還將被添加至發往此服務器的請求首部中。

<address>：爲此服務器的的IPv4地址，支持使用可解析的主機名，同時也支持域名，只不過在啓動時須要解析主機名至相應的IPv4地址。

[:port]：指定將鏈接請求所發往的此服務器時的目標端口，其爲可選項；未設定時，將使用客戶端請求時的同一相端口。

[param*]：爲此服務器設定的一系參數；其可用的參數很是多，具體請參考官方文檔中的說明，下面僅說明幾個經常使用的參數；

服務器或默認服務器參數：

backup：設定爲備用服務器，僅在負載均衡場景中的其它server均不可用於啓用此server。

check：啓動對此server執行健康狀態檢查，其能夠藉助於額外的其它參數完成更精細的設定，如：

inter <delay>：設定健康狀態檢查的時間間隔，單位爲毫秒，默認爲2000；也可使用fastinter和downinter來根據服務器端狀態優化此時間延遲；

rise <count>：設定健康狀態檢查中，某離線的server從離線狀態轉換至正常狀態須要成功檢查的次數；

fall <count>：確認server從正常狀態轉換爲不可用狀態須要檢查的次數；

cookie <value>：爲指定server設定cookie值，此處指定的值將在請求入站時被檢查，第一次爲此值挑選的server將在後續的請求中被選中，其目的在於實現持久鏈接的功能；

maxconn <maxconn>：指定此服務器接受的最大併發鏈接數；若是發往此服務器的鏈接數目高於此處指定的值，其將被放置於請求隊列，以等待其它鏈接被釋放；

maxqueue <maxqueue>：設定請求隊列的最大長度；

observe <mode>：經過觀察服務器的通訊情況來斷定其健康狀態，默認爲禁用，其支持的類型有「layer4」和「layer7」，「layer7」僅能用於http代理場景；

一個標準的使用案例，以下：

server web1 192.168.5.171:8080 maxconn 1024 weight 3 check inter 2000 rise 2 fall 3

以上就是[param*]中比較常用的參數。

redir <prefix>：啓用重定向功能，將發往此服務器的GET和HEAD請求均以302狀態碼響應；須要注意的是，在prefix後面不能使用/，且不能使用相對地址，以避免形成循環；例如：

server srv1 192.168.5.174:80 redir http://imags.ilanni.com check

weight <weight>：權重，默認爲1，最大值爲256，0表示不參與負載均衡。

檢查方法：

option httpchk

option httpchk <uri>

option httpchk <method> <uri>

option httpchk <method> <uri> <version>：不能用於frontend段

例如：

backend https_relay

mode tcp

option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www.ilanni.com

server apache1 192.168.1.1:443 check port 80

9、關鍵詞stats enable

stats enable啓用基於程序編譯時默認設置的統計報告，stats enable不能用於frontend區段。只要沒有另外的其它設定，它們就會使用以下的配置：

stats uri : /stats

stats realm : "HAProxy Statistics"

stats auth : no authentication

stats scope : no restriction

儘管stats enable一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非指望的後果。下面是一個配置案例。

backend public_www

server websrv1 192.168.5.171:80

stats enable

stats hide-version

stats scope

stats uri /stats

stats realm Haproxy\ Statistics

stats auth admin:password

stats auth admin:password

10、關鍵詞stats hide-version

stats hide-version隱藏統計報告中haproxy版本號，不能用於frontend區段。默認狀況下，統計頁面會顯示一些有用信息，包括haproxy的版本號。

然而，向全部人公開haproxy的精確版本號是很是有風險的，由於它能幫助惡意用戶快速定位版本的缺陷和漏洞。

11、關鍵詞stats realm

stats realm啓用統計報告並高精認證領域，不能用於「frontend」區段。

stats realm <realm>

haproxy在讀取realm時會將其視做一個單詞，所以，中間的任何空白詞符都必須使用反斜線進行轉義。此參數僅在與「stats auth」配置使用時有意義。

<realm>：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用於提示用戶輸入一個用戶名和密碼。

12、關鍵詞stats scope

stats scope啓用統計報告並限定報告的區段，不能用於frontend區段。

當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，全部其它區段的信息將被隱藏。若是須要顯示多個區段的統計報告，此語句能夠定義屢次。須要注意的是，區段名稱檢測僅僅是以詞符串比較的方式進行，它不會真檢測指定的區段是否真正存在。

stats scope { <name> | "." }

<name>：能夠是一個listen、frontend或backend區段的名稱，而「.」則表示stats scope語句所定義的當前區段。

13、關鍵詞stats auth

stats auth啓用帶認證的統計報告功能並受權一個用戶賬號，其不能用於frontend區段。

stats auth <user>:<passwd>

<user>：受權進行訪問的用戶名；

<passwd>：此用戶的訪問密碼，明文格式；

此語句將基於默認設定啓用統計報告功能，並僅容許其定義的用戶訪問，其也能夠定義屢次以受權多個用戶賬號。能夠結合「stats realm」參數在提示用戶認證時給出一個領域說明信息。在使用非法用戶訪問統計功能時，其將會響應一個「401 Forbidden」頁面。其認證方式爲HTTP Basic認證，密碼傳輸會以明文方式進行，所以，配置文件中也使用明文方式存儲以說明其非保密信息故此不能相同於其它關鍵性賬號的密碼。

14、關鍵詞stats admin

stats admin在指定的條件知足時啓用統計報告頁面的管理級別功能，它容許經過web接口啓用或禁用服務器，不過，基於安全的角度考慮，統計報告頁面應該儘量爲只讀的。此外，若是啓用了HAProxy的多進程模式，啓用此管理級別將有可能致使異常行爲。

stats admin { if | unless } <cond>

目前來講，POST請求方法被限制於僅能使用緩衝區減去保留部分以外的空間，所以，服務器列表不能過長，不然，此請求將沒法正常工做。所以，建議一次僅調整少數幾個服務器。下面是兩個案例，第一個限制了僅能在本機打開報告頁面時啓用管理級別功能，第二個定義了僅容許經過認證的用戶使用管理級別功能。

backend stats_localhost

stats enable

stats admin if LOCALHOST

backend stats_auth

stats enable

stats auth admin:password

stats admin if TRUE

15、關鍵詞option httplog

option httplog啓用記錄HTTP請求、會話狀態和計時器的功能。

option httplog [ clf ]

clf：使用CLF格式來代替HAProxy默認的HTTP格式，一般在使用僅支持CLF格式的特定日誌分析器時才須要使用此格式。

默認狀況下，日誌輸入格式很是簡陋，由於其僅包括源地址、目標地址和實例名稱，而「option httplog」參數將會使得日誌格式變得豐富許多，其一般包括但不限於HTTP請求、鏈接計時器、會話狀態、鏈接數、捕獲的首部及cookie、「frontend」、「backend」及服務器名稱，固然也包括源地址和端口號等。

16、關鍵詞option logasap

option logasap

啓用提早將HTTP請求記入日誌，不能用於backend區段。

默認狀況下，HTTP請求是在請求結束時進行記錄以便能將其總體傳輸時長和詞節數記入日誌，由此，傳較大的對象時，其記入日誌的時長可能會略有延遲。option logasap參數可以在服務器發送complete首部時即時記錄日誌，只不過，此時將不記錄總體傳輸時長和詞節數。此情形下，捕獲Content-Length響應首部來記錄傳輸的詞節數是一個較好選擇。下面是一個例子。

listen http_proxy 0.0.0.0:80

mode http

option httplog

option logasap

log 172.16.100.9 local2

17、關鍵詞option forwardfor

option forwardfor容許在發往服務器的請求首部中插入「X-Forwarded-For」首部。即啓用獲取客戶端真實IP功能。

option forwardfor [ except <network> ] [ header <name> ] [ if-none ]

<network>：可選參數，當指定時，源地址爲匹配至此網絡中的請求都禁用此功能。

<name>：可選參數，可以使用一個自定義的首部，如「X-Client」來替代「X-Forwarded-For」。有些獨特的web服務器的確須要用於一個獨特的首部。

if-none：僅在此首部不存在時纔將其添加至請求報文問道中。

haproxy工做於反向代理模式，其發往服務器的請求中的客戶端IP均爲haproxy主機的地址而非真正客戶端的地址，這會使得服務器端的日誌信息記錄不了真正的請求來源，「X-Forwarded-For」首部則可用於解決此問題。haproxy能夠向每一個發往服務器的請求上添加此首部，並以客戶端IP爲其value。

須要注意的是，haproxy工做於隧道模式，其僅檢查每個鏈接的第一個請求，所以，僅第一個請求報文被附加此首部。若是想爲每個請求都附加此首部，請確保同時使用了「option httpclose」、「option forceclose」和「option http-server-close」幾個option。

下面是一個例子。

frontend www

mode http

option forwardfor except 127.0.0.1

18、關鍵詞errorfile

errorfile在用戶請求不存在的頁面時，返回一個頁面文件給客戶端而非由haproxy生成的錯誤代碼；可用於全部段中。

errorfile <code> <file>

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、40三、40八、500、50二、503和504。

<file>：指定用於響應的頁面文件。

例如：

errorfile 400 /etc/haproxy/errorpages/400badreq.http

errorfile 403 /etc/haproxy/errorpages/403forbid.http

errorfile 503 /etc/haproxy/errorpages/503sorry.http

19、關鍵詞errorloc和errorloc302

errorloc <code> <url>

errorloc302 <code> <url>

請求錯誤時，返回一個HTTP重定向至某URL的信息；可用於全部配置段中。

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有200、400、40三、40八、500、50二、503和504；

<url>：Location首部中指定的頁面位置的具體路徑，能夠是在當前服務器上的頁面的相對路徑，也可使用絕對路徑；須要注意的是，若是URI自身錯誤時產生某特定狀態碼信息的話，有可能會致使循環定向；

須要留意的是，這兩個關鍵詞都會返回302狀態嗎，這將使得客戶端使用一樣的HTTP方法獲取指定的URL，對於非GET法的場景(如POST)來講會產生問題，由於返回客戶的URL是不容許使用GET之外的其它方法的。若是的確有這種問題，可使用errorloc303來返回303狀態碼給客戶端。

20、關鍵詞errorloc303

errorloc303 <code> <url>

請求錯誤時，返回一個HTTP重定向至某URL的信息給客戶端，可用於全部配置段中。

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這裏可用的狀態碼有400、40三、40八、500、50二、503和504；

<url>：Location首部中指定的頁面位置的具體路徑，能夠是在當前服務器上的頁面的相對路徑，也可使用絕對路徑；須要注意的是，若是URI自身錯誤時產生某特定狀態碼信息的話，有可能會致使循環定向；

例如：

backend webserver

server 172.16.100.6 172.16.100.6:80 check maxconn 3000 cookie srv01

server 172.16.100.7 172.16.100.7:80 check maxconn 3000 cookie srv02

errorloc 403 /etc/haproxy/errorpages/sorry.htm

errorloc 503 /etc/haproxy/errorpages/sorry.htm