烂泥：高负载均衡学习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、403、408、500、502、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、403、408、500、502、503和504；
<url>：Location首部中指定的頁面位置的具體路徑，可以是在當前服務器上的頁面的相對路徑，也可以使用絕對路徑；需要注意的是，如果URI自身錯誤時產生某特定狀態碼信息的話，有可能會導致循環定向；
需要留意的是，這兩個關鍵詞都會返回302狀態嗎，這將使得客戶端使用同樣的HTTP方法獲取指定的URL，對于非GET法的場景(如POST)來說會產生問題，因為返回客戶的URL是不允許使用GET以外的其它方法的。如果的確有這種問題，可以使用errorloc303來返回303狀態碼給客戶端。
20、關鍵詞errorloc303
errorloc303 <code> <url>
請求錯誤時，返回一個HTTP重定向至某URL的信息給客戶端，可用于所有配置段中。
<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這里可用的狀態碼有400、403、408、500、502、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
本文轉自 爛泥行天下 51CTO博客，原文鏈接：http://blog.51cto.com/ilanni/1687145
總結
以上是生活随笔為你收集整理的烂泥：高负载均衡学习haproxy之关键词介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 近期重构技能的一些心得
- 下一篇： CCNP之IS-IS实验