一、HAProxy簡介

（1）HAProxy 是一款提供高可用性、負載均衡以及基于TCP（第四層）和HTTP（第七層）應用的代理軟件，支持虛擬主機，它是免費、快速并且可靠的一種解決方案。 HAProxy特別適用于那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數以萬計的 并發連接。并且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上。

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

（3）HAProxy 支持連接拒絕 : 因為維護一個連接的打開的開銷是很低的，有時我們很需要限制***蠕蟲（attack bots），也就是說限制它們的連接打開從而限制它們的危害。 這個已經為一個陷于小型DDoS***的網站開發了而且已經拯救

了很多站點，這個優點也是其它負載均衡器沒有的。

（4）HAProxy 支持全透明代理（已具備硬件防火墻的典型特點）: 可以用客戶端IP地址或者任何其他地址來連接后端服務器. 這個特性僅在Linux?2.4/2.6內核打了cttproxy補丁后才可以使用. 這個特性也使得為某特殊服務器處理部分流量同時又不修改服務器的地址成為可能。

性能

HAProxy借助于OS上幾種常見的技術來實現性能的最大化。

1，單進程、事件驅動模型顯著降低了上下文切換的開銷及內存占用。

2，O(1)事件檢查器(event checker)允許其在高并發連接中對任何連接的任何事件實現即時探測。

3，在任何可用的情況下，單緩沖(single buffering)機制能以不復制任何數據的方式完成讀寫操作，這會節約大量的CPU時鐘周期及內存帶寬；

4，借助于Linux?2.6 (>= 2.6.27.19)上的splice()系統調用，HAProxy可以實現零復制轉發(Zero-copy forwarding)，在linux?3.5及以上的OS中還可以實現零復制啟動(zero-starting)；

5，內存分配器在固定大小的內存池中可實現即時內存分配，這能夠顯著減少創建一個會話的時長；

6，樹型存儲：側重于使用作者多年前開發的彈性二叉樹，實現了以O(log(N))的低開銷來保持計時器命令、保持運行隊列命令及管理輪詢及最少連接隊列；

7，優化的HTTP首部分析：優化的首部分析功能避免了在HTTP首部分析過程中重讀任何內存區域；

8，精心地降低了昂貴的系統調用，大部分工作都在用戶空間完成，如時間讀取、緩沖聚合及文件描述符的啟用和禁用等；

所有的這些細微之處的優化實現了在中等規模負載之上依然有著相當低的CPU負載，甚至于在非常高的負載場景中，5%的用戶空間占用率和95%的系統空間占用率也是非常普遍的現象，這意味著HAProxy進程消耗比系統空間消耗低20倍以上。因此，對OS進行性能調優是非常重要的。即使用戶空間的占用率提高一倍，其CPU占用率也僅為10%，這也解釋了為何7層處理對性能影響有限這一現象。由此，在高端系統上HAProxy的7層性能可輕易超過硬件負載均衡設備。

在生產環境中，在7層處理上使用HAProxy作為昂貴的高端硬件負載均衡設備故障故障時的緊急解決方案也時長可見。硬件負載均衡設備在“報文”級別處理請求，這在支持跨報文請求(request across multiple packets)有著較高的難度，并且它們不緩沖任何數據，因此有著較長的響應時間。對應地，軟件負載均衡設備使用TCP緩沖，可建立極長的請求，且有著較大的響應時間。

HAProxy目前主要有三個版本： 1.3 ， 1.4 ，1.5，CentOS6.6 自帶的RPM包為 1.5 的。

二，安裝配置HAProxy

以下實驗環境均為CentOS6.6 i686平臺。

1，安裝haproxy

2，詳解配置文件

haproxy 的配置文件由兩部分組成：全局設定和對代理的設定，共分為五段：global，defaults，frontend，backend，listen。

2.1 配置文件格式

HAProxy的配置處理3類來主要參數來源：

——最優先處理的命令行參數;

——“global”配置段，用于設定全局配置參數；

——proxy相關配置段，如“defaults”、“listen”、“frontend”和“backend”；

2.2 時間格式

一些包含了值的參數表示時間，如超時時長。這些值一般以毫秒為單位，但也可以使用其它的時間單位后綴。

2.3 全局配置

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

– chroot <jail dir>：修改haproxy的工作目錄至指定的目錄并在放棄權限之前執行chroot()操作，可以提升haproxy的安全級別，不過需要注意的是要確保指定的目錄為空目錄且任何用戶均不能有寫權限；

– daemon：讓haproxy以守護進程的方式工作于后臺，其等同于“-D”選項的功能，當然，也可以在命令行中以“-db”選項將其禁用；

– gid <number>：以指定的GID運行haproxy，建議使用專用于運行haproxy的GID，以免因權限問題帶來風險；

– group <group name>：同gid，不過指定的組名；

– log <address> <facility> [max level [min level]]：定義全局的syslog服務器，最多可以定義兩個；

– log-send-hostname [<string>]：在syslog信息的首部添加當前主機名，可以為“string”指定的名稱，也可以缺省使用當前主機名；

– nbproc <number>：指定啟動的haproxy進程的個數，只能用于守護進程模式的haproxy；默認只啟動一個進程，鑒于調試困難等多方面的原因，一般只在單進程僅能打開少數文件描述符的場景中才使用多進程模式；

– pidfile：

– uid：以指定的UID身份運行haproxy進程；

– ulimit-n：設定每進程所能夠打開的最大文件描述符數目，默認情況下其會自動進行計算，因此不推薦修改此選項；Linux默認單進程打開文件數為1024個

– user：同uid，但使用的是用戶名；

– stats：用戶訪問統計數據的接口

– node：定義當前節點的名稱，用于HA場景中多haproxy進程共享同一個IP地址時；

– description：當前實例的描述信息；

?

* 性能調整相關的參數

– maxconn <number>：設定每個haproxy進程所接受的最大并發連接數，其等同于命令行選項“-n”；“ulimit -n”自動計算的結果正是參照此參數設定的；

– maxpipes <number>：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 <number>：設定buffer的大小，同樣的內存條件小，較小的值可以讓haproxy有能力接受更多的并發連接，較大的值可以讓某些應用程序使用較大的cookie信息；默認為16384，其可以在編譯時修改，不過強烈建議使用默認值；

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

– tune.maxaccept <number>：設定haproxy進程內核調度運行時一次性可以接受的連接的個數，較大的值可以帶來較大的吞吐率，默認在單進程模式下為100，多進程模式下為8，設定為-1可以禁止此限制；一般不建議修改；

– tune.maxpollevents <number>：設定一次系統調用可以處理的事件最大數，默認值取決于OS；其值小于200時可節約帶寬，但會略微增大網絡延遲，而大于200時會降低延遲，但會稍稍增加網絡帶寬的占用量；

– tune.maxrewrite <number>：設定為首部重寫或追加而預留的緩沖空間，建議使用1024左右的大小；在需要使用更大的空間時，haproxy會自動增加其值；

– tune.rcvbuf.client <number>：

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

– tune.sndbuf.client：

– tune.sndbuf.server：

?

* Debug相關的參數

* 超時時長

* 實現訪問控制：

2.4 代理

代理相關的配置可以如下配置段中。

“defaults”段用于為所有其它配置段提供默認參數，這配置默認配置參數可由下一個“defaults”所重新設定。
“frontend”段用于定義一系列監聽的套接字，這些套接字可接受客戶端請求并與之建立連接。
“backend”段用于定義一系列“后端”服務器，代理將會將對應客戶端的請求轉發至這些服務器。
“listen”段通過關聯“frontend”和“backend”定義了一個完整的代理，通常只對TCP流量有用。

所有代理的名稱只能使用大寫字母、小寫字母、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外，ACL名稱會區分字母大小寫。

三、配置文件中的關鍵字參考

3.1 balance

定義負載均衡算法，可用于“defaults”、“listen”和“backend”。用于在負載均衡場景中挑選一個server，其僅應用于持久信息不可用的條件下或需要將一個連接重新派發至另一個服務器時。支持的算法有：

3.11 roundrobin：基于權重進行輪叫，在服務器的處理時間保持均勻分布時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重可以在運行時進行調整，不過，在設計上，每個后端服務器僅能最多接受4128個連接；并支持慢啟動。

3.12 static-rr：基于權重進行輪叫，與roundrobin類似，但是為靜態方法，在運行時調整其服務器權重不會生效；不過，其在后端服務器連接數上沒有限制；不支持慢啟動，在高負荷的情況下，服務器重新上線時會立即被分配大量連接。

3.13 leastconn（WLC）：適用于長連接的會話，新的連接請求被派發至具有最少連接數目的后端服務器；在有著較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其并不太適用于較短會話的應用層協議，如HTTP；此算法是動態的，

可以在運行時調整其權重；

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

1，對原地址hash，第一次調度時使用WLC
source：IP層，位于同一個NAT服務器背后的多個請求都會定向至同一個upstream server，不利于負載均衡，一般只有不支持使用cookie插入又需要保持會話時使用
cookie：應用層，有更好的負載均衡效果；

2，hash/weight%ip ：除以權重取模

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

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

3.17 hdr(<name>)：對于每個HTTP請求，通過<name>指定的HTTP首部將會被檢索；如果相應的首部沒有出現或其沒有有效值，則使用輪叫算法對相應請求進行調度；其有一個可選選項“use_domain_only”，可在指定檢索類似Host類的首部時僅計算域名部分(比如通過www.feiyu.com來說，僅計算feiyu字符串的hash值)以降低hash算法的運算量；此算法默認為靜態的，不過其也可以使用hash-type修改此特性；

3.18 rdp-cookie(name)

，表示根據據cookie(name)來鎖定并哈希每一次TCP請求。

3.2 bind

此指令僅能用于frontend和listen區段，用于定義一個或幾個監聽的套接字。

<address>：可選選項，其可以為主機名、IPv4地址、IPv6地址或*；省略此選項、將其指定為*或0.0.0.0時，將監聽當前系統的所有IPv4地址；<port_range>：可以是一個特定的TCP端口，也可是一個端口范圍(如5005-5010)，代理服務器將通過指定的端口來接收客戶端請求；需要注意的是，每組監聽的套接字<address:port>在同一個實例上只能使用一次，而且小于1024的端口需要有特定權限的用戶才能使用，這可能需要通過uid參數來定義；<interface>：指定物理接口的名稱，僅能在Linux系統上使用；其不能使用接口別名，而僅能使用物理接口名稱，而且只有管理有權限指定綁定的物理接口；

3.3 mode

設定實例的運行模式或協議。當實現內容交換時，前端和后端必須工作于同一種模式(一般說來都是HTTP模式)，否則將無法啟動實例。

tcp：實例運行于純TCP模式，在客戶端和服務器端之間將建立一個全雙工的連接，且不會對7層報文做任何類型的檢查；通常用于SSL、SSH、SMTP等應用；
http：實例運行于HTTP模式，客戶端請求在轉發至后端服務器之前將被深度分析，所有不與RFC格式兼容的請求都會被拒絕；此為默認模式；
health：實例工作于health模式，其對入站請求僅響應“OK”信息并關閉連接，且不會記錄任何日志信息；此模式將用于響應外部組件的健康狀態檢查請求；目前來講，此模式已經廢棄，因為tcp或http模式中的monitor關鍵字可完成類似功能；

?

3.4 hash-type

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

map-based：hash表是一個包含了所有在線服務器的靜態數組。其hash值將會非常平滑，會將權重考慮在列，但其為靜態方法，對在線服務器的權重進行調整將不會生效，這意味著其不支持慢速啟動。此外，挑選服務器是根據其在數組中的

位置進行的，因此，當一臺服務器宕機或添加了一臺新的服務器時，大多數連接將會被重新派發至一個與此前不同的服務器上，對于緩存服務器的工作場景來說，此方法不甚適用。

consistent：“一致性哈希算法”，hash表是一個由各服務器填充而成的樹狀結構，將服務器散列在hash環上；基于hash鍵在hash樹中查找相應的服務器時，最近的服務器將被選中。此方法是動態的，支持在運行時修改服務器權重，因此兼

容慢速啟動的特性。添加一個新的服務器時，僅會對一小部分請求產生影響，因此，尤其適用于后端服務器為cache的場景。不過，此算法不甚平滑，派發至各服務器的請求未必能達到理想的均衡效果，因此，可能需要不時的調整服務器的權

重以獲得更好的均衡性。

?

3.5 log

為每個實例啟用事件和流量日志，因此可用于所有區段。每個實例最多可以指定兩個log參數，不過，如果使用了“log global”且”global”段已經定了兩個log參數時，多余了log參數將被忽略。

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

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

<facility>：可以為syslog系統的標準facility之一；

<level>：定義日志級別，即輸出信息過濾器，默認為所有信息；指定級別時，所有等于或高于此級別的日志信息將會被發送；

?

3.6 maxconn

設定一個前端的最大并發連接數，因此，其不能用于backend區段。對于大型站點來說，可以盡可能提高此值以便讓haproxy管理連接隊列，從而避免無法應答用戶請求。當然，此最大值不能超出“global”段中的定義。此外，需要留心的是，haproxy會為每個連接維持兩個緩沖，每個緩沖的大小為8KB，再加上其它的數據，每個連接將大約占用17KB的RAM空間。這意味著經過適當優化后，有著1GB的可用RAM空間時將能維護40000-50000并發連接。

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

3.7 default_backend

在沒有匹配的”use_backend”規則時為實例指定使用的默認后端，因此，其不可應用于backend區段。在”frontend”和”backend”之間進行內容交換時，通常使用”use-backend”定義其匹配規則；而沒有被規則匹配到的請求將由此參數指定的后端接收。

<backend>：指定使用的后端的名稱；

使用案例：

3.8 server

為后端聲明一個server，因此，不能用于defaults和frontend區段。

<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>：指定此服務器接受的最大并發連接數；如果發往此服務器的連接數目高于此處指定的值，其將被放置于請求隊列，以等待其它連接被釋放；

haproxy 有n個進程，每個支持m個連接，后端有x個服務器，每個最大支持y個連接，則 n*m <= x*y，如果后端服務器支持排隊，則n*m <= x*（y+z），z為每個服務器的排隊隊列

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

observe <mode>：通過觀察服務器的通信狀況來判定其健康狀態，默認為禁用，其支持的類型有“layer4”和“layer7”，“layer7”僅能用于http代理場景；

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

weight <weight>：權重，默認為1，最大值為256，0表示不參與負載均衡（不被調度）；

檢查方法：

使用案例：

3.9 capture request header

捕獲并記錄指定的請求首部最近一次出現時的第一個值，僅能用于“frontend”和“listen”區段。捕獲的首部值使用花括號{}括起來后添加進日志中。如果需要捕獲多個首部值，它們將以指定的次序出現在日志文件中，并以豎線“|”作為分隔符。不存在的首部記錄為空字符串，最常需要捕獲的首部包括在虛擬主機環境中使用的“Host”、上傳請求首部中的“Content-length”、快速區別真實用戶和網絡機器人的“User-agent”，以及代理環境中記錄真實請求來源的“X-Forward-For”。

<name>：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出現在首部中的格式相同，比如大寫首字母。需要注意的是，記錄在日志中的是首部對應的值，而非首部名稱。

<length>：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。

可以捕獲的請求首部的個數沒有限制，但每個捕獲最多只能記錄64個字符。為了保證同一個frontend中日志格式的統一性，首部捕獲僅能在frontend中定義。

?

3.10 capture response header

捕獲并記錄響應首部，其格式和要點同請求首部。

?

3.11 stats enable

啟用基于程序編譯時默認設置的統計報告，不能用于“frontend”區段。只要沒有另外的其它設定，它們就會使用如下的配置：

盡管“stats enable”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定而帶來非期后果。下面是一個配置案例。

3.12 stats hide-version

啟用統計報告并隱藏HAProxy版本報告，不能用于“frontend”區段。默認情況下，統計頁面會顯示一些有用信息，包括HAProxy的版本號，然而，向所有人公開HAProxy的精確版本號是非常有風險的，因為它能幫助惡意用戶快速定位版本的缺陷和漏洞。盡管“stats hide-version”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定而帶來非期后果。具體請參照“stats enable”一節的說明。

3.13 stats realm

啟用統計報告并高精認證領域，不能用于“frontend”區段。haproxy在讀取realm時會將其視作一個單詞，因此，中間的任何空白字符都必須使用反斜線進行轉義。此參數僅在與“stats auth”配置使用時有意義。

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

盡管“stats realm”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定而帶來非期后果。具體請參照“stats enable”一節的說明。

3.14 stats scope

啟用統計報告并限定報告的區段，不能用于“frontend”區段。當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，所有其它區段的信息將被隱藏。如果需要顯示多個區段的統計報告，此語句可以定義多次。需要注意的是，區段名稱檢測僅僅是以字符串比較的方式進行，它不會真檢測指定的區段是否真正存在。

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

盡管“stats scope”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定而帶來非期后果。下面是一個配置案例。

3.15 stats auth

啟用帶認證的統計報告功能并授權一個用戶帳號，其不能用于“frontend”區段。

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

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

此語句將基于默認設定啟用統計報告功能，并僅允許其定義的用戶訪問，其也可以定義多次以授權多個用戶帳號。可以結合“stats realm”參數在提示用戶認證時給出一個領域說明信息。在使用非法用戶訪問統計功能時，其將會響應一個“401 Forbidden”頁面。其認證方式為HTTP Basic認證，密碼傳輸會以明文方式進行，因此，配置文件中也使用明文方式存儲以說明其非保密信息故此不能相同于其它關鍵性帳號的密碼。

盡管“stats auth”一條就能夠啟用統計報告，但還是建議設定其它所有的參數，以免其依賴于默認設定而帶來非期后果。

3.16 stats admin

在指定的條件滿足時啟用統計報告頁面的管理級別功能，它允許通過web接口啟用或禁用服務器，不過，基于安全的角度考慮，統計報告頁面應該盡可能為只讀的。此外，如果啟用了HAProxy的多進程模式，啟用此管理級別將有可能導致異常行為。

目前來說，POST請求方法被限制于僅能使用緩沖區減去保留部分之外的空間，因此，服務器列表不能過長，否則，此請求將無法正常工作。因此，建議一次僅調整少數幾個服務器。下面是兩個案例，第一個限制了僅能在本機打開報告頁面時啟用管理級別功能，第二個定義了僅允許通過認證的用戶使用管理級別功能。

3.17 option httplog

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

clf：使用CLF格式來代替HAProxy默認的HTTP格式，通常在使用僅支持CLF格式的特定日志分析器時才需要使用此格式。

默認情況下，日志輸入格式非常簡陋，因為其僅包括源地址、目標地址和實例名稱，而“option httplog”參數將會使得日志格式變得豐富許多，其通常包括但不限于HTTP請求、連接計時器、會話狀態、連接數、捕獲的首部及cookie、“frontend”、“backend”及服務器名稱，當然也包括源地址和端口號等。

3.18 option logasap

啟用或禁用提前將HTTP請求記入日志，不能用于“backend”區段。

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

3.19 option forwardfor

允許在發往服務器的請求首部中插入“X-Forwarded-For”首部。

<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。

下面是一個例子。

3.20 errorfile

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

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這里可用的狀態碼有200、400、403、408、500、502、503和504；

<file>：指定用于響應的頁面文件；

例如：

3.21 errorloc 和 errorloc302

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

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這里可用的狀態碼有200、400、403、408、500、502、503和504；

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

需要留意的是，這兩個關鍵字都會返回302狀態嗎，這將使得客戶端使用同樣的HTTP方法獲取指定的URL，對于非GET法的場景(如POST)來說會產生問題，因為返回客戶的URL是不允許使用GET以外的其它方法的。如果的確有這種問題，可以使用errorloc303來返回303狀態碼給客戶端。

3.22 errorloc303

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

<code>：指定對HTTP的哪些狀態碼返回指定的頁面；這里可用的狀態碼有400、403、408、500、502、503和504；

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

例如：

四、ACL

haproxy的ACL用于實現基于請求報文的首部、響應報文的內容或其它的環境狀態信息來做出轉發決策，這大大增強了其配置彈性。其配置法則通常分為兩步，首先去定義ACL，即定義一個測試條件，而后在條件得到滿足時執行某特定的動作，如阻止請求或轉發至某特定的后端。定義ACL的語法格式如下。

<aclname>：ACL名稱，區分字符大小寫，且其只能包含大小寫字母、數字、-(連接線)、_(下劃線)、.(點號)和:(冒號)；haproxy中，acl可以重名，這可以把多個測試條件定義為一個共同的acl；

<criterion>：測試標準，即對什么信息發起測試；測試方式可以由[flags]指定的標志進行調整；而有些測試標準也可以需要為其在之前指定一個操作符[operator]；

[flags]：目前haproxy的acl支持的標志位有3個：

-i：不區分中模式字符的大小寫；

-f：從指定的文件中加載模式；

--：標志符的強制結束標記，在模式中的字符串像標記符時使用；

<value>：acl測試條件支持的值有以下四類：

整數或整數范圍：如1024:65535表示從1024至65535；僅支持使用正整數(如果出現類似小數的標識，其為通常為版本測試)，且支持使用的操作符有5個，分別為eq、ge、gt、le和lt；

字符串：支持使用“-i”以忽略字符大小寫，支持使用“\”進行轉義；如果在模式首部出現了-i，可以在其之前使用“–”標志位；

正則表達式：其機制類同字符串匹配；

IP地址及網絡地址；

同一個acl中可以指定多個測試條件，這些測試條件需要由邏輯操作符指定其關系。條件間的組合測試關系有三種：“與”(默認即為與操作)、“或”(使用“||”操作符)以及“非”(使用“!”操作符)。

5.1 常用的測試標準(criteria)

5.1.1 be_sess_rate

用于測試指定的backend上會話創建的速率(即每秒創建的會話數)是否滿足指定的條件；常用于在指定backend上的會話速率過高時將用戶請求轉發至另外的backend，或用于阻止***行為。例如：

5.1.2 fe_sess_rate

用于測試指定的frontend(或當前frontend)上的會話創建速率是否滿足指定的條件；常用于為frontend指定一個合理的會話創建速率的上限以防止服務被濫用。例如下面的例子限定入站郵件速率不能大于50封/秒，所有在此指定范圍之外的請求都將被延時50毫秒。

5.1.3 hdr <string>

用于測試請求報文中的所有首部或指定首部是否滿足指定的條件；指定首部時，其名稱不區分大小寫，且在括號“()”中不能有任何多余的空白字符。測試服務器端的響應報文時可以使用shdr()。例如下面的例子用于測試首部Connection的值是否為close。

5.1.4 method <string>

測試HTTP請求報文中使用的方法。

5.1.5 path_beg <string>

用于測試請求的URL是否以指定的模式開頭。下面的例子用于測試URL是否以/static、/p_w_picpaths、/JavaScript或/stylesheets頭。

5.1.6 path_end <string>

用于測試請求的URL是否以<string>指定的模式結尾。例如，下面的例子用戶測試URL是否以jpg、gif、png、css或js結尾。

5.1.7 hdr_beg <string>

用于測試請求報文的指定首部的開頭部分是否符合<string>指定的模式。例如，下面的例子用記測試請求是否為提供靜態內容的主機img、video、download或ftp。

5.1.8 hdr_end <string>

用于測試請求報文的指定首部的結尾部分是否符合<string>指定的模式。

五、配置案例

前端調度器IP：192.168.1.210
后端應用服務器IP: 192.168.1.111 和 192.168.1.112

定義獨立日志文件

一個最簡單的http服務的配置

?

haproxy統計頁面的輸出機制

?

動靜分離示例：

?

http服務器配置完整示例

?

負載均衡MySQL服務的配置示例