Haproxy介紹

Haproxy的介紹

​ Haproxy提供高可用性、負載均衡以及基於TCP(第四層)和HTTP（第七層）應用的代理，支持虛擬主機，它是免費、快速而且可靠的一種解決方案。

​ haproxy特別適用於那些負載特別大的web站點，這些站點一般又須要會話保持或七層處理。haproxy運行在時下的硬件上，徹底能夠支持數以萬計的併發鏈接，而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中，同時能夠保護你的web服務器不被暴露到網絡上。

​ haproxy實現了一種事件驅動、單一進程模型，此模型支持很是大的併發鏈接數。多進程或多線程模型受內存限制、系統調度器限制以及無處不在的鎖限制，不多能處理數千併發鏈接。事件驅動模型由於在有更好的資源和時間管理的用戶端(User-Space)實現全部這些任務，因此沒有這些問題。此模型的弊端是，在多核系統上，這些程序一般擴展性較差。這就是爲何他們必須進行優化以使每一個CPU時間片(Cycle)作更多的工做。

haproxy的優勢

（1）免費開源，穩定性也是很是好。單haproxy也跑得不錯，穩定性能夠與硬件級的F5相媲美。

（2）根據官方文檔，haproxy能夠跑滿10Gbps，這個數值做爲軟件級負載均衡器是至關驚人的。

（3）haproxy支持鏈接拒絕:由於維護一個鏈接的打開的開銷是很低的，有時咱們很須要限制攻擊蠕蟲（attack bots），也就是說限制它們的鏈接打開從而限制它們的危害。這個已經爲一個陷於小型DDoS攻擊的網站開發了並且已經拯救了不少站點，這個優勢也是其它負載均衡器沒有的。

（4）haproxy支持全透明代理（已具有硬件防火牆的典型特色）:能夠用客戶端IP地址或者任何其餘地址來鏈接後端服務器。這個特性僅在Linux 2.4/2.6內核打了tcp proxy補丁後纔可使用。這個特性也使得爲某特殊服務器處理部分流量同時又不修改服務器的地址成爲可能。

（5）haproxy現多於線上的Mysql集羣環境，咱們經常使用於它做爲MySQL（讀）負載均衡。

（6）自帶強大的監控服務器狀態的頁面，實際環境中咱們結合Nagios進行郵件或短信報警。

（7）HAProxy支持虛擬主機，許多朋友說它不支持虛擬主機是錯誤的，經過測試咱們知道，HAProxy是支持虛擬主機的。

Haproxy的安裝

以在ubantu-16.04操做系統爲例

apt-get -y install haproxy

　　

經常使用命令以下：

ps -ef |grep haproxy
haproxy -v
cat /etc/haproxy/haproxy.cfg

　　

Haproxy的配置

啓動監控界面

listen stats
mode http
bind 0.0.0.0:1080
stats enable
stats hide-version
stats uri /stats
stats realm Haproxy\ Statistics
stats auth admin:admin123
stats admin if TRUE #啓用管理功能

　　

關鍵詞解析

balance

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

balance使用方法以下：

balance <algorithm> [ <arguments> ]

balance url_param [check_post [<max_wait>]]

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

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

 

bind

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

bind使用方法以下：

bind [

]:<port_range> [, …]

 

bind [

]:<port_range> [, …] interface

 

 

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

 

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

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

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

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關鍵詞可完成相似功能；

hash-type

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

hash-type使用方法以下：

hash-type

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

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

log

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

log global

log

[ []]

 

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

 

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

 

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

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

maxconn

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

maxconn使用方法以下：

maxconn

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

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

default_backend

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

default_backend使用方法以下：

default_backend

：指定使用的後端的名稱。

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

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

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

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

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

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

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

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

server srv1 192.168.5.174:80 redir http://www.baidu.com check

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

stats enable

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

stats uri : /stats

stats realm : 「HAProxy Statistics」

stats auth : no authentication

stats scope : no restriction

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

stats hide-version

stats hide-version隱藏統計報告中haproxy版本號，不能用於frontend區段。默認狀況下，統計頁面會顯示一些有用信息，包括haproxy的版本號。然而，向全部人公開haproxy的精確版本號是很是有風險的，由於它能幫助惡意用戶快速定位版本的缺陷和漏洞。

stats realm

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

stats realm

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

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

stats scope

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

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

stats scope { | 「.」 }

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

stats auth

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

stats auth :

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

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

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

stats admin

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

stats admin { if | unless }

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

backend stats_localhost

stats enable

stats admin if LOCALHOST

backend stats_auth

stats enable

stats auth admin:password

stats admin if TRUE

option httplog

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

option httplog [ clf ]

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

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

option logasap

option logasap

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

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

option forwardfor

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

option forwardfor [ except ][ header ] [ if-none ]

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

：可選參數，可以使用一個自定義的首部，如「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。

errorfile

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

errorfile

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

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

例如：

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

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

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

rrorloc和errorloc302

errorloc

errorloc302

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

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

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

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

errorloc303

errorloc303

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

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

：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

配置文件解析

haproxy的配置文件主要包含如下幾個部分：

global全局配置、defaults默認配置、監控頁面配置、frontend配置、backend配置。

global：全局配置參數，進程級的，用來控制Haproxy啓動前的一些進程及系統設置。

defaults：配置一些默認的參數，能夠被frontend，backend，listen段繼承使用。

frontend：用來匹配接收客戶所請求的域名，uri等，並針對不一樣的匹配，作不一樣的請求處理。

backend：定義後端服務器集羣，以及對後端服務器的一些權重、隊列、鏈接數等選項的設置。

listen：我將其理解爲frontend和backend的組合體。

global全局配置

全局配置的標誌參數爲global，全局配置主要用於設定義全局參數，屬於進程級的配置，一般和操做系統配置有關。

進程管理及安全相關的參數:

chroot ：修改haproxy的工做目錄至指定的目錄並在放棄權限以前執行chroot()操做，能夠提高haproxy的安全級別，不過須要注意的是要確保指定的目錄爲空目錄且任何用戶均不能有寫權限。

使用方法爲：

chroot /var/lib/haproxy

daemon：讓haproxy以守護進程的方式工做於後臺，其等同於「-D」選項的功能。固然，也能夠在命令行中以「-db」選項將其禁用。

uid：以指定的uid身份運行haproxy進程。

user：同uid參數，但使用的是用戶名。

gid ：以指定的gid運行haproxy，建議使用專用於運行haproxy的gid，以避免因權限問題帶來風險。

group ：同gid參數，不過指定的組名。

log

[max level [min level]]：

定義全局的syslog服務器，最多能夠定義兩個。

 

log-send-hostname []：在syslog信息的首部添加當前主機名，能夠爲「string」指定的名稱，也能夠缺省使用當前主機名。

nbproc ：指定啓動的haproxy進程個數，只能用於守護進程模式的haproxy。默認只啓動一個進程，鑑於調試困難等多方面的緣由，通常只在單進程僅能打開少數文件描述符的場景中才使用多進程模式。

pidfile：將haproxy的進程寫入pid文件。

ulimit-n：設定每進程所可以打開的最大文件描述符數目，默認狀況下其會自動進行計算，所以不推薦修改此選項。

stats socket ：定義統計信息保存位置。

性能調整相關的參數：

maxconn ：設定每一個haproxy進程所接受的最大併發鏈接數，其等同於命令行選項「-n」；「ulimit -n」自動計算的結果正是參照此參數設定的。

maxpipes ：haproxy使用pipe完成基於內核的tcp報文重組，此選項則用於設定每進程所容許使用的最大pipe個數。每一個pipe會打開兩個文件描述符，所以，「ulimit -n」自動計算時會根據須要調大此值；默認爲maxconn/4，其一般會顯得過大。

noepoll：在Linux系統上禁用epoll機制。

nokqueue：在BSE系統上禁用kqueue機制。

nopoll：禁用poll機制。

nosepoll：在Linux禁用啓發式epoll機制。

nosplice：禁止在Linux套接字上使用內核tcp重組，這會致使更多的recv/send系統調用；不過，在Linux 2.6.25-28系列的內核上，tcp重組功能有bug存在。

spread-checks <0..50, in="" percent="">：在haproxy後端有着衆多服務器的場景中，在精確的時間間隔後統一對衆服務器進行健康情況檢查可能會帶來意外問題；此選項用於將其檢查的時間間隔長度上增長或減少必定的隨機時長。

tune.bufsize ：設定buffer的大小，一樣的內存條件下，較小的值可讓haproxy有能力接受更多的併發鏈接，較大的值可讓某些應用程序使用較大的cookie信息；默認爲16384，其能夠在編譯時修改，不過強烈建議使用默認值。

tune.chksize ：設定檢查緩衝區的大小，單位爲字節；更大的值有助於在較大的頁面中完成基於字符串或模式的文本查找，但也會佔用更多的系統資源；不建議修改。

tune.maxaccept ：設定haproxy進程內核調度運行時一次性能夠接受的鏈接的個數，較大的值能夠帶來較大的吞吐率，默認在單進程模式下爲100，多進程模式下爲8，設定爲-1能夠禁止此限制；通常不建議修改。

tune.maxpollevents ：設定一次系統調用能夠處理的事件最大數，默認值取決於OS。其值小於200時可節約帶寬，但會略微增大網絡延遲，而大於200時會下降延遲，但會稍稍增長網絡帶寬的佔用量。

tune.maxrewrite ：設定爲首部重寫或追加而預留的緩衝空間，建議使用1024左右的大小。在須要使用更大的空間時，haproxy會自動增長其值。

tune.rcvbuf.client ：定義在客戶端內核套接字接收緩衝區的大小，單位爲字節，建議不要調整此值。

tune.rcvbuf.server ：設定內核套接字中服務端或客戶端接收緩衝的大小，單位爲字節；強烈推薦使用默認值。

tune.sndbuf.client：定義在客戶端內核套接字發送緩衝區的大小，單位爲字節，建議不要調整此值。

tune.sndbuf.server：定義在服務端內核套接字發送緩衝區的大小，單位爲字節，建議不要調整此值。

上邊的這些指令大多也是做爲了解便可，在實際中並不常會調整這些參數。

debug相關的參數：

debug：在調度haproxy時能夠啓用此參數，但在生產環境不該該啓用。

quiet：haproxy啓動後不會顯示任何相關信息，這與在命令行啓動haproxy時加上參數「-q」相同。

defaults默認配置

defaults段用於爲全部其它配置段提供默認參數，這配置默認配置參數可由下一個defaults所從新設定。

下面提供一個defaults模版配置，以下：

defaults

mode http

設置haproxy的運行模式，有三種｛http|tcp|health｝。注意：若是haproxy中還要使用4層的應用（mode tcp）的話，不建議在此定義haproxy的運行模式。

log global

設置日誌繼承全局配置段的設置。

option httplog

表示開始打開記錄http請求的日誌功能。

option dontlognull

若是產生了一個空鏈接，那這個空鏈接的日誌將不會記錄。

option http-server-close

打開http協議中服務器端關閉功能，使得支持長鏈接，使得會話能夠被重用，使得每個日誌記錄都會被記錄。

option forwardfor except 127.0.0.0/8

若是上游服務器上的應用程序想記錄客戶端的真實IP地址，haproxy會把客戶端的IP信息發送給上游服務器，在HTTP請求中添加」X-Forwarded-For」字段,但當是haproxy自身的健康檢測機制去訪問上游服務器時是不該該把這樣的訪問日誌記錄到日誌中的，因此用except來排除127.0.0.0，即haproxy身。

option redispatch

當與上游服務器的會話失敗(服務器故障或其餘緣由)時，把會話從新分發到其餘健康的服務器上,當原來故障的服務器恢復時，會話又被定向到已恢復的服務器上。還能夠用」retries」關鍵字來設定在斷定會話失敗時的嘗試鏈接的次數。

retries 3

向上遊服務器嘗試鏈接的最大次數，超過此值就認爲後端服務器不可用。

option abortonclose

當haproxy負載很高時，自動結束掉當前隊列處理比較久的連接。

timeout http-request 10s

客戶端發送http請求的超時時間。

timeout queue 1m

當上遊服務器在高負載響應haproxy時，會把haproxy發送來的請求放進一個隊列中，timeout queue定義放入這個隊列的超時時間。

timeout connect 5s

haproxy與後端服務器鏈接超時時間，若是在同一個局域網可設置較小的時間。

timeout client 1m

定義客戶端與haproxy鏈接後，數據傳輸完畢，再也不有數據傳輸，即非活動鏈接的超時時間。

timeout server 1m

定義haproxy與上游服務器非活動鏈接的超時時間。

timeout http-keep-alive 10s

設置新的http請求鏈接創建的最大超時時間，時間較短時能夠儘快釋放出資源，節約資源。

timeout check 10s

健康檢測的時間的最大超時時間。

maxconn 3000

最大併發鏈接數。

contimeout 5000

設置成功鏈接到一臺服務器的最長等待時間，默認單位是毫秒，新版本的haproxy使用timeout connect替代，該參數向後兼容。

clitimeout 3000

設置鏈接客戶端發送數據時的成功鏈接最長等待時間，默認單位是毫秒，新版本haproxy使用timeout client替代。該參數向後兼容。

srvtimeout 3000

設置服務器端迴應客戶度數據發送的最長等待時間，默認單位是毫秒，新版本haproxy使用timeout server替代。該參數向後兼容。

監控頁面配置

listen admin_status

frontend和backend的組合體,監控組的名稱，按需自定義名稱。

bind 0.0.0.0:1080

配置監聽端口。

mode http

配置監控運行的模式，在這爲http模式。

log 127.0.0.1 local3 err

配置錯誤日誌記錄。

stats refresh 5s

配置每隔5秒自動刷新監控頁面。

stats uri /stats

配置監控頁面的url。

stats realm Haproxy\ Statistics

配置監控頁面的提示信息。

stats auth admin:admin

配置監控頁面的用戶和密碼admin,能夠設置多個用戶名。以下：

stats auth admin1:admin1

配置監控頁面的用戶和密碼admin1。

stats hide-version

配置隱藏統計頁面上的HAproxy版本信息。

stats admin if TRUE

配置手工啓用/禁用,後端服務器(haproxy-1.4.9之後版本)。

frontend配置

frontend web_demo

定義一個名爲 web_demo的frontend。

bind 0.0.0.0:80

定義haproxy前端部分監聽的端口。

mode http

定義爲http模式。

log global

繼承global中log的定義。

option forwardfor

使後端server獲取到客戶端的真實IP。

acl php_web path_end .php

定義一個名叫php_web的acl，當請求的url末尾是以.php結尾的，將會被匹配到。

use_backend php_server if php_web

若是知足策略php_web時，就將請求交予backend php_server處理。

default_backend backend_default

若是以上策略都不知足時，就將請求交予default_backend處理。

acl使用以下：
acl 自定義acl名稱 acl方法 -i [匹配的路徑或者方法]
hdr_reg(host),hdr_dom(host),hdr_beg(host),url_sub,url_dir,path_beg,path_end
-i 表示不區分大小寫,後邊跟上匹配的路徑或文件或正則表達式
與ACL一塊兒使用的參數還有use_backend,usebackend後面須要跟上一個backend實例名,表示在知足ACL規則後去請求哪一個backend實例,與use_backend對應的還有default_backend參數,表示在沒有知足ACL條件的時候默認使用哪一個backend後端
例如：
acl static_down nbsrv(static_server) lt 1
定義一個名叫static_down的acl，當backend static_sever中存活機器數小於1時會被匹配到。
#acl php_web url_reg /*.php
acl php_web path_end .php
定義一個名叫php_web的acl，當請求的url末尾是以.php結尾的，將會被匹配到，上面兩種寫法任選其一。
#acl static_web url_reg /*.(css|jpg|png|jpeg|js|gif)$
acl static_web path_end .gif .png .jpg .css .js .jpeg
定義一個名叫static_web的acl，當請求的url末尾是以.css、.jpg、.png、.jpeg、.js、.gif結尾的，將會被匹配到，上面兩種寫法任選其一。
acl is_ilanni hdr_beg(host) -i ilanni.test.com
定義一個名叫is_ilanni的acl，當請求的是以ilanni.test.com開頭的主機的話，將會被匹配到。其中-i表示忽略大小寫。
acl is_dg hdr_beg(host) dg.test.com
定義一個名叫is_dg的acl，當請求的是以dg.test.com開頭的主機的話，將會被匹配到。
acl is_171 hdr_beg(host) 192.168.5.171
定義一個名叫is_171的acl，當請求的是以192.168.5.171開頭的主機的話，將會被匹配到。
acl is_ip src 192.168.5.140
定義一個名叫is_ip的acl，當客戶端的IP是192.168.5.140的話，將會被匹配到。
use_backend php_server if static_down
若是知足策略static_down時，就將請求交予backend php_server處理。
use_backend php_server if php_web
若是知足策略php_web時，就將請求交予backend php_server處理。
use_backend static_server if static_web
若是知足策略static_web時，就將請求交予backend static_server處理。
use_backend acl if is_171 is_ip
若是同時知足is_171和is_ip這兩條策略時，就將請求交予backend acl處理。
use_backend mui_acl if is_171 is_ip is_port
若是同時知足is_17一、is_ip和is_port這三條策略時，就將請求交予backend mui_acl處理。
use_backend dgserver if is_dg
若是知足策略is_dg時，就將請求交予backend dgserver處理。
use_backend ilanni if is_ilanni
若是知足策略is_ilanni時，就將請求交予backend ilanni處理。
use_backend 171server if is_171
若是知足策略is_171時，就將請求交予backend 171server處理。
default_backend backend_default
若是以上策略都不知足時，就將請求交予default_backend處理。

　　

backend配置

backend dgserver

定義dgserver服務器組

balance source

定義負載均衡方式，roundrobin平均方式

mode http

option httpchk GET /index.html

心跳檢測的文件

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

服務器定義，maxconn 1024 表示該服務器的最大鏈接數，check inter 2000是檢測心跳頻率，rise 2是2次正確認爲服務器可用，fall 3是3次失敗認爲服務器不可用，weight表明權重

Haproxy的使用示例

haproxy 的ssl 配置（處理https）

方式一：haproxy 自己提供ssl 證書，後面的web 服務器走正常的http

配置示例以下：

frontend https_frontend
  bind *:443 ssl crt /etc/ssl/certs/servername.pem ####關鍵#####
  mode http
  option httpclose
  option forwardfor
  reqadd X-Forwarded-Proto:\ https
  default_backend web_server
backend web_server
  mode http
  balance roundrobin
  cookie SERVERID insert indirect nocache
  server s1 192.168.250.47:80 check cookie s1
  server s2 192.168.250.49:80 check cookie s2
 注意：這裏的pem 文件是下面兩個文件合併而成：
  cat servername.crt servername.key |tee servername.pem

　　

附錄：簡單地演示生成自簽名證書的方式

$ sudo mkdir /etc/ssl/xip.io
$ sudo openssl genrsa -out /etc/ssl/xip.io/xip.io.key 1024
$ sudo openssl req -new -key /etc/ssl/xip.io/xip.io.key -out /etc/ssl/xip.io/xip.io.csr
> Country Name (2 letter code) [AU]:US
> State or Province Name (full name) [Some-State]:Connecticut
> Locality Name (eg, city) []:New Haven
> Organization Name (eg, company) [Internet Widgits Pty Ltd]:SFH
> Organizational Unit Name (eg, section) []:
> Common Name (e.g. server FQDN or YOUR name) []:*.xip.io
> Email Address []:
> Please enter the following 'extra' attributes to be sent with your certificate request
> A challenge password []:
> An optional company name []:
$ sudo openssl x509 -req -days 365 -in /etc/ssl/xip.io/xip.io.csr -signkey /etc/ssl/xip.io/xip.io.key -out /etc/ssl/xip.io/xip.io.crt
$ sudo cat /etc/ssl/xip.io/xip.io.crt /etc/ssl/xip.io/xip.io.key | sudo tee /etc/ssl/xip.io/xip.io.pem

　　

當購買真正的證書 時，你不必定會獲取拼接後的文件。你能夠要本身拼接它們。然而，不少機構也會提供一份拼接好的文件給你。若是你沒有獲取到拼接後的文件，則它可能不是一個 pem 文件，而是 bundle、cert、cert、key文件或一些相同概念但名稱相似的文件。

方式二：haproxy 自己只提供代理，後面的web服務器https

又稱SSL穿透，不須要從新編譯支持ssl，簡單方便。須要後面的web服務器配置好ssl 便可。

配置示例以下：

frontend https_frontend
  bind *:443
  mode tcp
  default_backend web_server
backend web_server
  mode tcp
  balance roundrobin
  stick-table type ip size 200k expire 30m
  stick on src
  server s1 192.168.250.47:443
  server s2 192.168.250.49:443
#注意，這種模式下mode 必須是tcp 模式

　　

haproxy的tcp應用

haproxy代理ssh

爲了安全起見，要求全部業務服務器都關閉公網的鏈接，只開放haproxy所在的服務器，而且其餘業務服務器的ssh鏈接經過haproxy來實現。

實際業務，訪問192.168.5.171的8098端口就是訪問192.168.5.174的ssh端口。

haproxy代理mysql

爲了安全起見，要求mysql數據庫的鏈接只能經過內網IP，可是由於使用的是雲數據庫，因此若是公司內部要鏈接數據庫的話要經過haproxy來實現。實際業務，訪問192.168.5.171的8099端口就是訪問192.168.7.7的3306端口。

以上兩個需求的配置以下：

由於是haproxy的7層和4層混合使用，因此在defaults中，咱們不定義haproxy的運行模式。

注意：有關http模式的相關配置參數不要出如今default中。

.....
listen 8099
bind 0.0.0.0:8099
mode tcp
server 174_22 192.168.5.174:22 maxconn 1024 weight 5 check inter 2000 rise 2 fall 3
listen 8098
bind 0.0.0.0:8098
mode tcp
server 77_3306 192.168.7.7:3306 maxconn 1024 weight 5 check inter 2000 rise 2 fall 3