haproxy 初識

時間 2019-11-17

原文原文鏈接

官方網站：http://www.haproxy.org

描述

HAProxy的是一個免費的，很是快速和可靠的解決方案，提供高可用性，負載均衡和代理對TCP和基於HTTP的應用程序。它特別適用於流量很是高的網站，併爲世界上訪問量最大的網站提供支持。多年來，它已成爲事實上的標準開源負載均衡器，如今隨大多數主流Linux發行版一塊兒提供，而且一般默認部署在雲平臺中。
javascript

它的操做模式使其與現有體系結構的集成很是容易且無風險，利於快速部署，同時仍然提供了不將脆弱的Web服務器暴露給網絡的可能性，以下所示：css

HAProxy涉及操做系統體系結構中常見的幾種技術，以實現絕對最大性能：html

單進程，事件驅動模型大大下降了上下文切換和內存使用的成本。能夠在一毫秒內處理數百個任務，而且每一個會話的內存使用量大約爲幾千字節，而在preforked或線程服務器中消耗的內存更多的是每一個進程的兆字節數量級。
容許它的系統上的O（1）事件檢查器（Linux和FreeBSD）容許在成千上萬的任何鏈接上即時檢測任何事件。
使用延遲事件緩存對事件檢查器的延遲更新可確保咱們永遠不會更新事件，除非絕對須要。這節省了大量的系統調用。
單緩衝，儘量在讀取和寫入之間不進行任何數據複製。這節省了大量CPU週期和有用的內存帶寬。一般，瓶頸將是CPU和網絡接口之間的I / O總線。在10-100 Gbps時，內存帶寬也可能成爲瓶頸。
使用Linux下的splice（）系統調用能夠進行零拷貝轉發，從而實現從Linux 3.5開始的真正零拷貝。這容許一個小於3瓦的設備（如Seagate Dockstar）以1千兆位/秒的速度轉發HTTP流量。
MRU 內存分配器使用固定大小的內存池進行即時內存分配，有利於熱緩存區域而不是冷緩存區域。這大大減小了建立新會話所需的時間。
工做因子，例如一次多個accept（），以及在多進程模式下運行時限制每次迭代的accept（）數量的能力，以便在進程之間均勻分配負載。
在多進程模式下運行時支持CPU親和性，或者只是爲了適應硬件，而且儘量與管理NIC的CPU核心最接近，而不與之衝突。
基於樹的存儲，大量使用彈性二叉樹，我已經開發了好幾年了。這用於保持定時器的順序，以保持命令的運行隊列，管理循環和最少conn隊列，在表中查找ACL或密鑰，只須要O（log（N））成本。
優化的計時器隊列：若是推遲計時器，它們不會在樹中移動，由於它們被知足的可能性接近於零，由於它們主要用於超時處理。這進一步優化了ebtree的使用。
優化的HTTP標頭分析：標頭被解析爲動態解釋，而且優化解析以免從新讀取任何先前讀取的存儲區域。當使用不完整的頭到達緩衝區的末尾時使用檢查點，這樣當讀取更多數據時，解析不會從頭開始。在快速Xeon E5上解析平均HTTP請求一般須要半微秒。
當心減小昂貴的系統調用次數。大多數工做默認在用戶空間中完成，例如時間讀取，緩衝區聚合，文件描述符啓用/禁用。
內容分析通過優化，只能攜帶指向原始數據的指針，除非須要轉換數據，不然永遠不會複製。這確保了很是小的結構被攜帶而且在不絕對必要時不會複製內容。

即便在中等負載下，全部這些微優化也會致使CPU使用率很是低。即便在很是高的負載下，當CPU飽和時，一般會注意到5％用戶和95％系統等數字，這意味着HAProxy進程比系統對應的消耗少20倍。這就解釋了爲何調整操做系統很是重要。這就是咱們最終構建本身的設備的緣由，以便從最終用戶那裏保存複雜而關鍵的任務。前端

在生產中，當很是昂貴的高端硬件負載平衡器忽然在第7層處理中失敗時，HAProxy已經屢次安裝做爲緊急解決方案。某些硬件負載平衡器仍然不在數據包級別使用代理和處理請求，而且在支持跨多個數據包的請求和高響應時間方面存在很大困難，由於它們根本不進行緩衝。另外一方面，軟件負載平衡器使用TCP緩衝，而且對長請求和高響應時間不敏感。一個很好的反作用的HTTP緩衝是經過減小會話持續時間來增長服務器的鏈接接受度，從而爲新請求留出空間。java

有三個重要因素用於衡量負載均衡器的性能：node

會話速率
此因素很是重要，由於它直接肯定負載均衡器什麼時候沒法分發它收到的全部請求。它主要依賴於CPU。有時候，你會聽到關於請求/秒命中/ s，而且它們是相同的會話/秒HTTP / 1.0或HTTP / 1.1與保活禁用。啓用保持活動的請求/一般要高得多（由於它顯着減小了系統端工做），但對於面向Internet的部署一般沒有意義，由於客戶端常常打開大量鏈接，而且在轉換時不會爲每一個鏈接發送許多請求。該因子是用不一樣的對象大小來測量的，最快的結果一般來自空對象（例如：HTTP 302,304或404響應代碼）。2014年，Xeon E5系統的會話速率約爲100,000會話/秒。
會話併發
此因素與前一個因素相關聯。一般，當併發會話數增長時，會話速率將降低（ epoll或kqueue輪詢機制除外）。服務器越慢，同一會話速率的併發會話數越多。若是負載均衡器每秒接收10000個會話，而且服務器在100毫秒內響應，則負載均衡器將具備1000個併發會話。此數量受內存量和系統可處理的文件描述符數量的限制。對於16 kB緩衝區，HAProxy每一個會話須要大約34 kB，這致使每GB大約30000個會話RAM。實際上，系統中的套接字緩衝區也須要一些內存，每GB RAM 20000個會話更合理。第4層負載平衡器一般會宣佈數百萬個併發會話，由於它們須要處理系統在代理中免費處理的TIME_WAIT套接字。它們也不處理任何數據，所以它們不須要任何緩衝區。此外，它們有時被設計用於直接服務器返回模式，其中負載均衡器僅看到前向流量，而且強制它在結束後長時間保持會話以免在關閉以前切斷會話。
數據轉發率
該因素一般與會話率相反。它以兆字節/秒（MB / s）爲單位，有時以千兆位/秒（Gbps）爲單位。使用大型對象能夠實現最高的數據速率，從而最大限度地減小會話設置和拆卸形成的開銷。大對象一般會增長會話併發性，而高數據速率的高會話併發性須要大量內存來支持大型窗口。高數據速率會在軟件負載平衡器上燒燬大量CPU和總線週期，由於必須將數據從輸入接口複製到存儲器而後再返回到輸出設備。硬件負載平衡器傾向於直接將數據包從輸入端口切換到輸出端口以得到更高的數據速率，但沒法處理它們，有時沒法觸摸標頭或cookie。40 Gbps。無風扇1.6 GHz Atom CPU略高於1 Gbps。

負責平衡器與這些因素相關的性能一般是針對最佳狀況宣佈的（例如：會話速率爲空對象，數據速率爲大對象）。這不是由於供應商缺少誠實，而是由於沒法確切地說出它在每種組合中的表現如何。所以，當知道這3個限制時，客戶應該意識到它一般會在全部這些限制之下執行。對軟件負載平衡器的一個好的經驗法則是考慮平均大小對象的最大會話和數據速率的一半的平均實際性能。web

配置 HAProxy:
正則表達式

2.1 配置文件格式算法

HAProxy的配置處理3類來主要參數來源：
  ——最優先處理的命令行參數，
  ——「global」配置段，用於設定全局配置參數；
  ——proxy相關配置段，如「defaults」、「listen」、「frontend」和「backend」；

2.2 時間格式apache

一些包含了值的參數表示時間，如超時時長。這些值通常以毫秒爲單位，但也可使用其它的時間單位後綴。 us: 微秒(microseconds)，即1/1000000秒； ms: 毫秒(milliseconds)，即1/1000秒； s: 秒(seconds)； m: 分鐘(minutes)； h：小時(hours)； d: 天(days)；

2.3 例子

下面的例子配置了一個監聽在全部接口的80端口上HTTP proxy服務，它轉發全部的請求至後端監聽在127.0.0.1:8000上的"server"。 global 　　　　　　　　　　#「global」配置中的參數爲進程級別的參數，且一般與其運行的OS相關。 daemon maxconn 25600 defaults　　　　　　　　　　　　# 「defaults」段用於爲全部其它配置段提供默認參數，這配置默認配置參數可由下一個「defaults」所從新設定。 mode http timeout connect 5000ms    timeout client 50000ms
        timeout server 50000ms

    frontend http-in　　　　　　　　#「frontend」段用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之創建鏈接。
        bind *:80
        default_backend servers

    backend servers　　　　　　　　 #「backend」段用於定義一系列「後端」服務器，代理將會將對應客戶端的請求轉發至這些服務器。
        server server1 127.0.0.1:8080 maxconn 32

2.4 全局配置

「global」配置中的參數爲進程級別的參數，且一般與其運行的OS相關。 * 進程管理及安全相關的參數 - 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：設定每進程所可以打開的最大文件描述符數目，默認狀況下其會自動進行計算，所以不推薦修改此選項； - 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：在BSD系統上禁用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相關的參數 - debug - quiet

2.5 代理

代理相關的配置能夠以下配置段中。 - defaults <name>
 - frontend <name>
 - backend  <name>
 - listen   <name> 「defaults」段用於爲全部其它配置段提供默認參數，這配置默認配置參數可由下一個「defaults」所從新設定。 「frontend」段用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之創建鏈接。 「backend」段用於定義一系列「後端」服務器，代理將會將對應客戶端的請求轉發至這些服務器。 「listen」段經過關聯「前端」和「後端」定義了一個完整的代理，一般只對TCP流量有用。

 frontend http-in
        bind *:80
        default_backend servers

    backend servers
        server server1 127.0.0.1:8000 maxconn 32

區別：

isten http-in
        bind *:80
        server server1 127.0.0.1:8000 maxconn 32

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

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

3.1 balance balance <algorithm> [ <arguments> ] balance url_param <param> [check_post [<max_wait>]] 定義負載均衡算法，可用於「defaults」、「listen」和「backend」。<algorithm>用於在負載均衡場景中挑選一個server，其僅應用於持久信息不可用的條件下或須要將一個鏈接從新派發至另外一個服務器時。支持的算法有： roundrobin：基於權重進行輪叫，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，這表示其權重能夠在運行時進行調整，不過，在設計上，每一個後端服務器僅能最多接受4128個鏈接； static-rr：基於權重進行輪叫，與roundrobin相似，可是爲靜態方法，在運行時調整其服務器權重不會生效；不過，其在後端服務器鏈接數上沒有限制； leastconn：新的鏈接請求被派發至具備最少鏈接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的，能夠在運行時調整其權重； source：將請求的源地址進行hash運算，並由後端服務器的權重總數相除後派發至某匹配的服務器；這可使得同一個客戶端IP的請求始終被派發至某特定的服務器；不過，當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不一樣的服務器；經常使用於負載均衡無cookie功能的基於TCP的協議；其默認爲靜態，不過也可使用hash-type修改此特性； 　　　　hash-type：
 　　　　　　　　map-based   靜態權重算法
　　　　　　　  consistent   一致性哈希算法


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

  　　　　hash-type：
 　　　　　　　　map-based   靜態權重算法
　　　　　　　  consistent   一致性哈希算法


　url_param：經過<argument>爲URL指定的參數在每一個HTTP GET請求中將會被檢索；若是找到了指定的參數且其經過等於號「=」被賦予了一個值，那麼此值將被執行hash運算並被服務器的總權重相除後派發至某匹配的服務器；此算法能夠經過追蹤請求中的用戶標識進而確保同一個用戶ID的請求將被送往同一個特定的服務器，除非服務器的總權重發生了變化；若是某請求中沒有出現指定的參數或其沒有有效值，則使用輪叫算法對相應請求進行調度；此算法默認爲靜態的，不過其也可使用hash-type修改此特性； hdr(<name>)：對於每一個HTTP請求，經過<name>指定的HTTP首部將會被檢索；若是相應的首部沒有出現或其沒有有效值，則使用輪叫算法對相應請求進行調度；其有一個可選選項「use_domain_only」，可在指定檢索相似Host類的首部時僅計算域名部分(好比經過www.test.com來講，僅計算test字符串的hash值)以下降hash算法的運算量；此算法默認爲靜態的，不過其也可使用hash-type修改此特性，最有用的應該是cookie 字段； rdp-cookie :遠程桌面協議 rdp-cookie(name)： 3.2 bind bind [<address>]:<port_range> [, ...] bind [<address>]:<port_range> [, ...] interface <interface> 此指令僅能用於frontend和listen區段，用於定義一個或幾個監聽的套接字。 <address>：可選選項，其能夠爲主機名、IPv4地址、IPv6地址或*；省略此選項、將其指定爲*或0.0.0.0時，將監聽當前系統的全部IPv4地址； <port_range>：能夠是一個特定的TCP端口，也但是一個端口範圍(如5005-5010)，代理服務器將經過指定的端口來接收客戶端請求；須要注意的是，每組監聽的套接字<address:port>在同一個實例上只能使用一次，並且小於1024的端口須要有特定權限的用戶才能使用，這可能須要經過uid參數來定義； <interface>：指定物理接口的名稱，僅能在Linux系統上使用；其不能使用接口別名，而僅能使用物理接口名稱，並且只有管理有權限指定綁定的物理接口； 3.3 mode mode { tcp|http|health } 設定實例的運行模式或協議。當實現內容交換時，前端和後端必須工做於同一種模式(通常說來都是HTTP模式)，不然將沒法啓動實例。 tcp：實例運行於純TCP模式，在客戶端和服務器端之間將創建一個全雙工的鏈接，且不會對7層報文作任何類型的檢查；此爲默認模式，一般用於SSL、SSH、SMTP等應用； http：實例運行於HTTP模式，客戶端請求在轉發至後端服務器以前將被深度分析，全部不與RFC格式兼容的請求都會被拒絕； health：實例工做於health模式，其對入站請求僅響應「OK」信息並關閉鏈接，且不會記錄任何日誌信息；此模式將用於響應外部組件的健康狀態檢查請求；目前業講，此模式已經廢棄，由於tcp或http模式中的monitor關鍵字可完成相似功能； 3.4 hash-type hash-type <method> 定義用於將hash碼映射至後端服務器的方法；其不能用於frontend區段；可用方法有map-based和consistent，在大多數場景下推薦使用默認的map-based方法。 map-based：hash表是一個包含了全部在線服務器的靜態數組。其hash值將會很是平滑，會將權重考慮在列，但其爲靜態方法，對在線服務器的權重進行調整將不會生效，這意味着其不支持慢速啓動。此外，挑選服務器是根據其在數組中的位置進行的，所以，當一臺服務器宕機或添加了一臺新的服務器時，大多數鏈接將會被從新派發至一個與此前不一樣的服務器上，對於緩存服務器的工做場景來講，此方法不甚適用。 consistent：hash表是一個由各服務器填充而成的樹狀結構；基於hash鍵在hash樹中查找相應的服務器時，最近的服務器將被選中。此方法是動態的，支持在運行時修改服務器權重，所以兼容慢速啓動的特性。添加一個新的服務器時，僅會對一小部分請求產生影響，所以，尤爲適用於後端服務器爲cache的場景。不過，此算法不甚平滑，派發至各服務器的請求未必能達到理想的均衡效果，所以，可能須要不時的調整服務器的權重以得到更好的均衡性。 3.5 log log global log <address> <facility> [<level> [<minlevel>]] 爲每一個實例啓用事件和流量日誌，所以可用於全部區段。每一個實例最多能夠指定兩個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 maxconn <conns> 設定一個前端的最大併發鏈接數，所以，其不能用於backend區段。對於大型站點來講，能夠儘量提升此值以便讓haproxy管理鏈接隊列，從而避免沒法應答用戶請求。固然，此最大值不能超出「global」段中的定義。此外，須要留心的是，haproxy會爲每一個鏈接維持兩個緩衝，每一個緩衝的大小爲8KB，再加上其它的數據，每一個鏈接將大約佔用17KB的RAM空間。這意味着通過適當優化後，有着1GB的可用RAM空間時將能維護40000-50000併發鏈接。 若是爲<conns>指定了一個過大值，極端場景下，其最終佔據的空間可能會超出當前主機的可用內存，這可能會帶來意想不到的結果；所以，將其設定了一個可接受值方爲明智決定。其默認爲2000。 3.7 default_backend default_backend <backend> 在沒有匹配的"use_backend"規則時爲實例指定使用的默認後端，所以，其不可應用於backend區段。在"frontend"和"backend"之間進行內容交換時，一般使用"use-backend"定義其匹配規則；而沒有被規則匹配到的請求將由此參數指定的後端接收。 <backend>：指定使用的後端的名稱； 使用案例： use_backend dynamic if url_dyn use_backend static if url_css url_img extension_img default_backend dynamic 3.8 server server <name> <address>[:port] [param*] 爲後端聲明一個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將在後續的請求中被選中，其目的在於實現持久鏈接的功能；

基於瀏覽器cookie實現session sticky：
            backend websrvs
                balance     roundrobin
                cookie SERVERID insert nocache indirect
                server web1 172.16.100.68:80 check weight 1 cookie websrv1
                server web2 172.16.100.69:80 check weight 3 cookie websrv2

            要點：
                (1) 每一個server有本身唯一的cookie標識；
                (2) 在backend中定義爲用戶請求調度完成後操縱其cookie

 maxconn <maxconn>：指定此服務器接受的最大併發鏈接數；若是發往此服務器的鏈接數目高於此處指定的值，其將被放置於請求隊列，以等待其它鏈接被釋放； maxqueue <maxqueue>：設定請求隊列的最大長度； observe <mode>：經過觀察服務器的通訊情況來斷定其健康狀態，默認爲禁用，其支持的類型有「layer4」和「layer7」，「layer7」僅能用於http代理場景； redir <prefix>：啓用重定向功能，將發往此服務器的GET和HEAD請求均以302狀態碼響應；須要注意的是，在prefix後面不能使用/，且不能使用相對地址，以避免形成循環；例如： server srv1 172.16.100.6:80 redir http://imageserver.test.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.test.com server apache1 192.168.1.1:443 check port 80 使用案例： server first 172.16.100.7:1080 cookie first  check inter 1000 server second 172.16.100.8:1080 cookie second check inter 1000

3.9 capture request header capture request header <name> len <length> 捕獲並記錄指定的請求首部最近一次出現時的第一個值，僅能用於「frontend」和「listen」區段。捕獲的首部值使用花括號{}括起來後添加進日誌中。若是須要捕獲多個首部值，它們將以指定的次序出如今日誌文件中，並以豎線「|」做爲分隔符。不存在的首部記錄爲空字符串，最常須要捕獲的首部包括在虛擬主機環境中使用的「Host」、上傳請求首部中的「Content-length」、快速區別真實用戶和網絡機器人的「User-agent」，以及代理環境中記錄真實請求來源的「X-Forward-For」。 <name>：要捕獲的首部的名稱，此名稱不區分字符大小寫，但建議與它們出如今首部中的格式相同，好比大寫首字母。須要注意的是，記錄在日誌中的是首部對應的值，而非首部名稱。 <length>：指定記錄首部值時所記錄的精確長度，超出的部分將會被忽略。 能夠捕獲的請求首部的個數沒有限制，但每一個捕獲最多隻能記錄64個字符。爲了保證同一個frontend中日誌格式的統一性，首部捕獲僅能在frontend中定義。 3.10 capture response header capture response header <name> len <length> 捕獲並記錄響應首部，其格式和要點同請求首部。 3.11 stats enable 啓用基於程序編譯時默認設置的統計報告，不能用於「frontend」區段。只要沒有另外的其它設定，它們就會使用以下的配置： - stats uri   : /haproxy?stats - stats realm : "HAProxy Statistics"
  - stats auth : no authentication - stats scope : no restriction 儘管「stats enable」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。下面是一個配置案例。 backend public_www server websrv1 172.16.100.11:80 stats enable stats hide-version stats scope . stats uri /haproxyadmin?stats stats realm Haproxy\ Statistics stats auth statsadmin:password stats auth statsmaster:password 3.12 stats hide-version stats hide-version 啓用統計報告並隱藏HAProxy版本報告，不能用於「frontend」區段。默認狀況下，統計頁面會顯示一些有用信息，包括HAProxy的版本號，然而，向全部人公開HAProxy的精確版本號是很是有風險的，由於它能幫助惡意用戶快速定位版本的缺陷和漏洞。儘管「stats hide-version」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。具體請參照「stats enable」一節的說明。 3.13 stats realm stats realm <realm> 啓用統計報告並高精認證領域，不能用於「frontend」區段。haproxy在讀取realm時會將其視做一個單詞，所以，中間的任何空白字符都必須使用反斜線進行轉義。此參數僅在與「stats auth」配置使用時有意義。 <realm>：實現HTTP基本認證時顯示在瀏覽器中的領域名稱，用於提示用戶輸入一個用戶名和密碼。 儘管「stats realm」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。具體請參照「stats enable」一節的說明。 3.14 stats scope stats scope { <name> | "." } 啓用統計報告並限定報告的區段，不能用於「frontend」區段。當指定此語句時，統計報告將僅顯示其列舉出區段的報告信息，全部其它區段的信息將被隱藏。若是須要顯示多個區段的統計報告，此語句能夠定義屢次。須要注意的是，區段名稱檢測僅僅是以字符串比較的方式進行，它不會真檢測指定的區段是否真正存在。 <name>：能夠是一個「listen」、「frontend」或「backend」區段的名稱，而「.」則表示stats scope語句所定義的當前區段。 儘管「stats scope」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。下面是一個配置案例。 backend private_monitoring stats enable stats uri /haproxyadmin?stats stats refresh 10s 3.15 stats auth stats auth <user>:<passwd> 啓用帶認證的統計報告功能並受權一個用戶賬號，其不能用於「frontend」區段。 <user>：受權進行訪問的用戶名； <passwd>：此用戶的訪問密碼，明文格式； 此語句將基於默認設定啓用統計報告功能，並僅容許其定義的用戶訪問，其也能夠定義屢次以受權多個用戶賬號。能夠結合「stats realm」參數在提示用戶認證時給出一個領域說明信息。在使用非法用戶訪問統計功能時，其將會響應一個「401 Forbidden」頁面。其認證方式爲HTTP Basic認證，密碼傳輸會以明文方式進行，所以，配置文件中也使用明文方式存儲以說明其非保密信息故此不能相同於其它關鍵性賬號的密碼。 儘管「stats auth」一條就可以啓用統計報告，但仍是建議設定其它全部的參數，以避免其依賴於默認設定而帶來非期後果。 3.16 stats admin stats admin { if | unless } <cond> 在指定的條件知足時啓用統計報告頁面的管理級別功能，它容許經過web接口啓用或禁用服務器，不過，基於安全的角度考慮，統計報告頁面應該儘量爲只讀的。此外，若是啓用了HAProxy的多進程模式，啓用此管理級別將有可能致使異常行爲。 目前來講，POST請求方法被限制於僅能使用緩衝區減去保留部分以外的空間，所以，服務器列表不能過長，不然，此請求將沒法正常工做。所以，建議一次僅調整少數幾個服務器。下面是兩個案例，第一個限制了僅能在本機打開報告頁面時啓用管理級別功能，第二個定義了僅容許經過認證的用戶使用管理級別功能。 backend stats_localhost stats enable stats admin if LOCALHOST backend stats_auth stats enable stats auth haproxyadmin:password stats admin if TRUE

frontend  main *:8080

    default_backend             webserver

listen stats_test          #配置stats 監聽實例
    bind *:1080            #綁定監聽端口 1080
    stats enable           #啓動stats 功能
    stats hide-version     #隱藏 haproxy 版本
    #stats scope .         #指定管理範圍
    stats uri /haproxyadmin?stats        #指定訪問路徑
    stats realm "HAproxy\ Statistics"     #指定名稱
    stats auth   zy:zzzzy                #指定認證用戶名，密碼
    stats admin if TRUE     #啓用管理功能





 3.17 option httplog option httplog [ clf ] 啓用記錄HTTP請求、會話狀態和計時器的功能。 clf：使用CLF格式來代替HAProxy默認的HTTP格式，一般在使用僅支持CLF格式的特定日誌分析器時才須要使用此格式。 默認狀況下，日誌輸入格式很是簡陋，由於其僅包括源地址、目標地址和實例名稱，而「option httplog」參數將會使得日誌格式變得豐富許多，其一般包括但不限於HTTP請求、鏈接計時器、會話狀態、鏈接數、捕獲的首部及cookie、「frontend」、「backend」及服務器名稱，固然也包括源地址和端口號等。 3.18 option logasap no option logasap option logasap no 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 3.19 option forwardfor option forwardfor [ except <network> ] [ header <name> ] [ if-none ] 容許在發往服務器的請求首部中插入「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。 下面是一個例子。 frontend www mode http option forwardfor except 127.0.0.1

3.20 errorfile errorfile <code> <file> 在用戶請求不存在的頁面時，返回一個頁面文件給客戶端而非由haproxy生成的錯誤代碼；可用於全部段中。 <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 3.21 errorloc 和 errorloc302 
　　　　　　#errorloc location 方式
　　　　　　# 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狀態碼給客戶端。 3.22 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

5、ACL

haproxy的ACL用於實現基於請求報文的首部、響應報文的內容或其它的環境狀態信息來作出轉發決策，這大大加強了其配置彈性。其配置法則一般分爲兩步，首先去定義ACL，即定義一個測試條件，然後在條件獲得知足時執行某特定的動做，如阻止請求或轉發至某特定的後端。定義ACL的語法格式以下。 acl <aclname> <criterion> [flags] [operator] <value> ... <aclname>：ACL名稱，區分字符大小寫，且其只能包含大小寫字母、數字、-(鏈接線)、_(下劃線)、.(點號)和:(冒號)；haproxy中，acl能夠重名，這能夠把多個測試條件定義爲一個共同的acl； <criterion>：測試標準，即對什麼信息發起測試；測試方式能夠由[flags]指定的標誌進行調整；而有些測試標準也能夠須要爲其在<value>以前指定一個操做符[operator]； [flags]：目前haproxy的acl支持的標誌位有3個： -i：不區分<value>中模式字符的大小寫； -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 <integer> be_sess_rate(backend) <integer> 用於測試指定的backend上會話建立的速率(即每秒建立的會話數)是否知足指定的條件；經常使用於在指定backend上的會話速率太高時將用戶請求轉發至另外的backend，或用於阻止攻擊行爲。例如： backend dynamic mode http acl being_scanned be_sess_rate gt 50 redirect location /error_pages/denied.html if being_scanned 5.1.2 fe_sess_rate <integer> fe_sess_rate(frontend) <integer> 用於測試指定的frontend(或當前frontend)上的會話建立速率是否知足指定的條件；經常使用於爲frontend指定一個合理的會話建立速率的上限以防止服務被濫用。例以下面的例子限定入站郵件速率不能大於50封/秒，全部在此指定範圍以外的請求都將被延時50毫秒。 frontend mail bind :25 mode tcp maxconn 500 acl too_fast fe_sess_rate ge 50 tcp-request inspect-delay 50ms tcp-request content accept if ! too_fast tcp-request content accept if WAIT_END 5.1.3 hdr <string> hdr(header) <string> 用於測試請求報文中的全部首部或指定首部是否知足指定的條件；指定首部時，其名稱不區分大小寫，且在括號「()」中不能有任何多餘的空白字符。測試服務器端的響應報文時可使用shdr()。例以下面的例子用於測試首部Connection的值是否爲close。 hdr(Connection) -i close 5.1.4 method <string> method <string> 測試HTTP請求報文中使用的方法。 5.1.5 path_beg <string> 用於測試請求的URL是否以<string>指定的模式開頭。下面的例子用於測試URL是否以/static、/images、/javascript或/stylesheets頭。 acl url_static path_beg -i /static /images /javascript /stylesheets 5.1.6 path_end <string> 用於測試請求的URL是否以<string>指定的模式結尾。例如，下面的例子用戶測試URL是否以jpg、gif、png、css或js結尾。 acl url_static path_end -i .jpg .gif .png .css .js 5.1.7 hdr_beg <string> 用於測試請求報文的指定首部的開頭部分是否符合<string>指定的模式。例如，下面的例子用記測試請求是否爲提供靜態內容的主機img、video、download或ftp。 acl host_static hdr_beg(host) -i img. video. download. ftp. 5.1.8 hdr_end <string> 用於測試請求報文的指定首部的結尾部分是否符合<string>指定的模式。

   acl url_static  path_beg         /static /images /img /css
   acl url_static  path_end         .gif .png .jpg .css .js
   acl host_www    hdr_beg(host) -i www
   acl host_static hdr_beg(host) -i img. video. download. ftp.

acl es req.fhdr(accept-language),language(es;fr;en) -m str es
acl fr req.fhdr(accept-language),language(es;fr;en) -m str fr
acl en req.fhdr(accept-language),language(es;fr;en) -m str en
use_backend spanish if es
use_backend french  if fr
use_backend english if en
default_backend choose_your_language

acl clear      dst_port  80
acl secure     dst_port  8080
acl login_page url_beg   /login
acl logout     url_beg   /logout
acl uid_given  url_reg   /login?userid=[^&]+
acl cookie_set hdr_sub(cookie) SEEN=1

redirect prefix   https://mysite.com set-cookie SEEN=1 if !cookie_set
redirect prefix   https://mysite.com           if login_page !secure
redirect prefix   http://mysite.com drop-query if login_page !uid_given
redirect location http://mysite.com/           if !login_page secure
redirect location / clear-cookie USERID=       if logout

訪問控制：
        http_request
        tcp_request

自定義報文首部：

　　具體使用方法請查看官方文檔

 - reqadd     <string>
  - reqallow   <search>
  - reqiallow  <search>
  - reqdel     <search>
  - reqidel    <search>
  - reqdeny    <search>
  - reqideny   <search>
  - reqpass    <search>
  - reqipass   <search>
  - reqrep     <search> <replace>
  - reqirep    <search> <replace>
  - reqtarpit  <search>
  - reqitarpit <search>
  - rspadd     <string>
  - rspdel     <search>
  - rspidel    <search>
  - rspdeny    <search>
  - rspideny   <search>
  - rsprep     <search> <replace>
  - rspirep    <search> <replace>

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。