HAProxy簡介

HAProxy簡介

HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，它是免費、開源、快速而且可靠的一種解決方案。

1 haproxy特色——引自散盡浮華的博客

1）HAProxy 也是支持虛擬主機的。

2）HAProxy 的優勢可以補充 Nginx 的一些缺點，好比支持 Session 的保持，Cookie的引導；同時支持經過獲取指定的 url 來檢測後端服務器的狀態。

3）HAProxy 跟 LVS 相似，自己就只是一款負載均衡軟件；單純從效率上來說HAProxy 會比 Nginx 有更出色的負載均衡速度，在併發處理上也是優於 Nginx 的。

4）HAProxy 支持 TCP 協議的負載均衡轉發，能夠對 MySQL 讀進行負載均衡，對後端的 MySQL 節點進行檢測和負載均衡，你們能夠用 LVS+Keepalived 對 MySQL主從作負載均衡。

5）HAProxy 負載均衡策略很是多， HAProxy 的負載均衡算法如今具體有以下8種：

1> roundrobin，表示簡單的輪詢，這個很少說，這個是負載均衡基本都具有的；

2> static-rr，表示根據權重，建議關注；

3> leastconn，表示最少鏈接者先處理，建議關注；

4> source，表示根據請求源 IP，這個跟 Nginx 的 IP_hash 機制相似，咱們用其做爲解決 session 問題的一種方法，建議關注；

5> ri，表示根據請求的 URI；

6> rl_param，表示根據請求的 URl 參數’balance url_param’ requires an URLparameter name；

7> hdr(name)，表示根據 HTTP 請求頭來鎖定每一次 HTTP 請求；

8> rdp-cookie(name)，表示根據據 cookie(name)來鎖定並哈希每一次 TCP 請求。

2 配置文件參數簡介

haproxy程序環境：          

• 主程序：/usr/sbin/haproxy          
  
• 主配置文件：/etc/haproxy/haproxy.cfg          
  
• Unit file：/usr/lib/systemd/system/haproxy.service
• 官方文檔：http://cbonte.github.io/haproxy-dconv/

2.1 global全局配置部分參數

1. 進程及安全管理：

   • chroot：限定工做目錄提高安全性，注意的是要確保指定的目錄爲空目錄且任何用戶均不能有寫權限；
   • deamon：讓haproxy以守護進程的方式工做於後臺；
   • user, group, uid, gid： 設定haproxy運行的用戶及組等；

2. log：定義全局的syslog服務器；最多能夠定義兩個；                      

   ​ log

   [len ] [max level [min level]]

   ​ 在代理配置段使用log global，則表示從全局繼承日誌設置。若是全局已經定義過兩個log了，此處除引用global外還自定義了一個log，則此自定義的log失效，由於只支持兩個日誌設置。

3. nbproc ：要啓動的haproxy的進程數量，官方建議單進程模式即1 ；

4. ulimit-n ：每一個haproxy進程可打開的最大文件數；不推薦手動指定，haproxy會自動調整 ；

5. 鏈接數相關：

   • maxconn ：設定每一個haproxy進程所能接受的最大併發鏈接數；          
     
   • maxconnrate ：每一個進程每秒種所能建立的最大tcp鏈接數量；                
     
   • maxsessrate ：每秒能建立的最大會話數；                
     
   • maxsslconn :設置每一個進程最大併發ssl鏈接數;              

6. spread-checks <0..50, in percent>  單位百分比，有時, 須要避免以固定的時間間隔,發送代理和健康檢查，不然會健康檢測會過多的佔用帶寬。例如, 當許多邏輯服務器位於同一物理服務器上或者後端服務器數量不少的狀況下。在這個參數的幫助下, 能夠在檢查間隔增長一些隨機性時間介於0和 +/-50之間。默認值保持爲0。

2.2 代理配置段

1. 「defaults」段用於爲全部其它配置段提供默認參數；
2. 「frontend」段用於定義一系列監聽的套接字，這些套接字可接受客戶端請求並與之創建鏈接；
3. 「backend」段用於定義一系列「後端」服務器，代理將會將對應客戶端的請求轉發至這些服務器；
4. 「listen」段經過同時指定監聽參數與後端服務器簡要的定義了一個完整的代理；

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

1. 部分經常使用參數，本段引自博客園——駿馬金龍博客

   http事務模型相關設置
   (no) option http-keep-alive
   啓用或禁用客戶端和服務端到haproxy之間的長鏈接。haproxy將處理全部請求和響應報文，請求完後haproxy兩端的鏈接都處於空閒狀態。因爲和後端保持了鏈接，能夠以最快的方式重用會話。

   (no) option http-server-close
   啓用或禁用在haproxy處理完第一次響應以後關閉haproxy到服務端之間長鏈接的功能，但客戶端的長鏈接還保持，後續的每次請求都從新創建和後端的鏈接，每次響應後都關閉和後端的鏈接。啓用該選項時，haproxy將會在轉發給後端server的request數據包中添加一個"Connection:Close"標記，後端Server看到此標記就會在響應後關閉tcp鏈接。

   (no) option forceclose
   啓用或禁用傳輸完響應報文後關閉兩端的鏈接。

   通常來講，對於高速局域網絡來講，若是後端響應的速度很是快(好比後端是靜態服務器響應小文件、後端是靜態緩存服務器)，這時創建tcp鏈接的代價就比較大，維持空閒鏈接的優點會很是明顯。若是後端是動態應用程序，響應給haproxy的速度相對較慢，維持空閒鏈接的代價很是大，徹底能夠先釋放長鏈接以騰出資源，在須要鏈接的時候再創建新tcp鏈接。 所以：
   (1).後端是靜態內容緩存服務器時，或者就是靜態服務器時，首選使用http-keep-alive模式；
   (2).後端是動態應用程序服務器時，首選使用http-server-close模式。

   balance負載均衡調度算法
   balance
   可用於default、listen、backend配置段。
   指定代理時負載均衡算法，支持的算法有：
   roundrobin(默認)：根據權重進行輪詢，在服務器的處理時間保持均勻分佈時，這是最平衡、最公平的算法。此算法是動態的，表示權重能夠在haproxy運行時調整後端服務器的權重並生效；
   static-rr：基於權重進行輪詢，與roundrobin相似，可是爲靜態方法，在haproxy運行時調整其服務器權重不會生效；
   leastconn：新的鏈接請求被派發至具備最少鏈接數目的後端服務器；在有着較長時間會話的場景中推薦使用此算法，如LDAP、SQL等，其並不太適用於較短會話的應用層協議，如HTTP；此算法是動態的，能夠在運行時調整其權重；
   source：將請求的源地址進行hash運算，使得同一個客戶端IP的請求始終被派發至某特定的服務器； 但當服務器權重總數發生變化時，如某服務器宕機或添加了新的服務器，許多客戶端的請求可能會被派發至與此前請求不一樣的服務器；相似於nginx的ip_hash，可用於負載均衡無cookie功能的基於TCP的協議。默認爲靜態；
   uri：對URI的左半部分 (域名後"?"標記以前的文件路徑部分)進行hash運算，併除以服務器的總權重來計算派發至某匹配服務器；這可使得對同一個URI的請求老是被派發至某特定的服務器，除非服務器的權重總數發生了變化；此算法經常使用於代理緩存以提升緩存的命中率；但此算法僅應用於提供http服務的後端服務器；默認爲靜態算法；缺點是後端server宕機會形成嚴重抖動，能夠經過hash-type設置hash算法爲consistent一致性哈希解決。
   url_param:通常用於將同一用戶ID轉發至同一服務器的狀況。在使用了basic認證時，url中的param通常都會使用user=XXX。使用該算法會對該參數進行hash運算，而後除以總權重以決定分配到哪臺後端server。
   hdr(name)：基於指定的請求首部名稱進行調度。首部中指定名稱相同的調度至同一服務器。通常使用"hdr(host)"根據請求首部中的host即目標主機來進行hash運算。使用use_domain_only選項能夠基於域名來哈希，使得訪問www.longshuai.com和web.longshuai.com的請求都調度至同一服務器。
   rdp-cookie 微軟的調度方式
   rdp-cookie(name)
   roundrobin和static-rr是有區別的，roundrobin是動態慢輪詢，不用重啓服務便可調整其權重，而static-rr必須重啓服務修改的權重才生效。例如原有2臺後端server，新添加一臺後，roundrobin會今後時開始慢慢的將請求輪詢至此新服務器 （即慢啓動），而static-rr因爲須要重啓，因此重啓前新server不會被調度到，重啓後新server和舊server平均調度。通常來講，考慮加權輪詢的時候，roundrobin要比static-rr好。
   通常可歸入考慮的算法有roundrobin/static-rr/leastconn/uri，其中leastconn算法用於代理ldap、mysql等長時間會話鏈接的狀況，uri算法用於代理後端爲緩存服務器的狀況。
   (1). 用於調度MySQL服務器，使用何種算法？答：leastconn
   (2). 用於調度靜態服務器組，使用何種算法？答：roundrobin
   (3). 調度動態應用程序服務器組，使用何種算法？答：一般客戶端須要和後端應用程序服務器保持聯繫，通常會使用cookie或者session來實現，但若是特殊狀況下沒法經過它們實現，則可使用source做爲最後"親和性"手段。注意，使用source算法時，後端服務器數量一改變，就會致使大量的會話斷開。
   (4). 調度緩存服務器，使用何種算法？答：uri，且設置hash-type爲一致性哈希算法。

2. server配置相關

   • server

     [:[port]][param*]

     定義後端主機的各服務器及其選項不可用於defaults與frontend配置段；             

   • default-server [settings ...]  

     指定server的默認值，不能用於frontend配置段；

   • ：服務器在haproxy上的內部名稱；出如今日誌及警告信息；

   • ：服務器地址，支持使用主機名；

   • [:[port]]：端口映射；省略時，表示同bind中綁定的端口；   

   • [param*]：爲此服務器設定的一系列參數

     • maxconn ：當前server的最大併發鏈接數；

     • backlog ：當前server的鏈接數達到上限後的後援隊列長度；

     • backup：設定當前server爲備用服務器；

     • check：對當前server作健康狀態檢測；

     • addr ：檢測時使用的IP地址；

     • port ：針對此端口進行檢測；

     • inter ：連續兩次檢測之間的時間間隔，默認爲2000ms;        

     • rise ：連續多少次檢測結果爲「成功」才標記服務器爲可用；默認爲2；

     • fall ：連續多少次檢測結果爲「失敗」才標記服務器爲不可用；默認爲3；

       注意：httpchk，"smtpchk", "mysql-check", "pgsql-check" and "ssl-hello-chk" 用於定義應用層檢測方法；

     • cookie ：爲當前server指定其cookie值，用於實現基於cookie的會話黏性； 

     • disabled：標記爲不可用；

     • redir ：將發往此server的全部GET和HEAD類的請求重定向至指定的URL；

     • weight ：權重，默認爲1;

3. 統計接口啓用相關的參數：                      

• stats enable ： 啓用統計頁；基於默認的參數啓用stats page；

  • stats uri   : /haproxy?stats  定義狀態頁路徑；

  • stats realm : "HAProxy Statistics" 認證領域名，即輸入用戶口令時的標題信息；

  • stats auth  : no authentication   是否開啓驗證；

  • stats scope : no restriction    

  • stats auth :    認證時的帳號和密碼，可以使用屢次；       

  • stats realm       認證時的realm；  

  • stats uri      自定義stats page uri ；   

  • stats refresh    設定自動刷新時間間隔；

  • stats admin { if | unless }    啓用stats page中的管理功能 ;    

    配置示例：                          

    listen stats                                
    
    bind :9099                                
    
    stats enable                                
    
    stats realm HAPorxy\ Stats\ Page                                
    
    stats auth admin:admin                                
    
    stats admin if TRUE

1. 基於cookie的session sticky的實現：

   cookie [ rewrite | insert | prefix ][ indirect ] [ nocache ]

​ 經常使用組合：insert nocache indirect

• ：設定cookie名稱

• rewrite：重寫cookie,不推薦使用;

• insert: haproxy將報文發給客戶端前，先插入一個cookie，cookie值由server項中cookie指定;

• indirect: 如下3段均引用自駿馬金龍博客https://www.cnblogs.com/f-ck-need-u/p/8553190.html#2-2-cookie-prefix

  若是不配合"indirect"選項，服務端能夠看到客戶端請求時的全部cookie信息。若是配合"indirect"選項，則haproxy在將請求轉發給後端時，將刪除本身設置的cookie，使得後端只能看到它本身的cookie，這樣對後端來講，整個過程是徹底透明的，它不知道前面有負載均衡軟件。

• nocache

  當客戶端和HAProxy之間存在緩存時(如CDN)，建議將insert配合nocache一塊兒使用 ，由於nocache確保若是須要插入cookie，則可緩存頁面將被標記爲不可緩存。這一點很重要，由於若是全部cookie都添加到可緩存的頁面上，則全部客戶都將從中間的緩存層獲取頁面，而且將共享同一個Cookie，從而致使某臺後端服務器接收的流量遠遠超過其餘後端服務器。

• prefix:

  haproxy將在已存在的cookie(例如後端應用服務器設置的)上添加前綴cookie值，這個前綴部分是server指令中的cookie設置的，表明的是服務端標識符。在客戶端再次訪問時，haproxy將會自動移除這部分前綴，使得服務端只能看到它本身發出的cookie。在一些特殊環境下，客戶端不支持多個"Set-Cookie"字段，這時可使用prefix。

  使用prefix的時候，cookie指令設置的cookie名必須和後端設置的cookie同樣(在本文的環境中是PHPSESSID)，不然prefix模式下的haproxy不會對響應報文作任何改變。

2.3 ACL

使用訪問控制列表 (ACL) 提供了一種靈活的解決方案來進行訪問流量控制, 一般是根據從請求、響應或任何環境狀態提取的內容來作出決策。

2.3.1 ACL語法

 acl [flags][operator] [ ] ...

• aclname : 指定ACL名稱，區分大小寫，可多條ACL同名，之間是或關係，value知足其一便是匹配。

• criterion：指定檢查標準：

  • 如4層：src、src_port、dst、dst_port，

  • 7層：

    • path     : 精確匹配字符串，例如：path -i /1.txt

      path_beg : 匹配 path的前綴部分              

      path_dir :  路徑子集匹配         

      path_dom : 域名子集匹配                

      path_end : 後綴匹配                  

      path_len : 長度匹配                  

      path_reg : 模式匹配                  

      path_sub : 字符串子集匹配

    • url     : exact string match                  

      url_beg : prefix match                  

      url_dir : subdir match                  

      url_dom : domain match                  

      url_end : suffix match                  

      url_len : length match                  

      url_reg : regex match                  

      url_sub : substring match

    • hdr([ [, ]])     : 精確匹配某首部最後一次出現的值                  

      hdr_beg([ [, ]]) : prefix match                  

      hdr_dir([ [, ]]) : subdir match                  

      hdr_dom([ [, ]]) : domain match                  

      hdr_end([ [, ]]) : suffix match                  

      hdr_len([ [, ]]) : length match                  

      hdr_reg([ [, ]]) : regex match                  

      hdr_sub([ [, ]]) : substring match

    • status : integer

      Returns an integer containing the HTTP status code in the HTTP response.

• flag：標誌位，經常使用如-i 不區分大小寫、-n禁止DNS解析。

3 動靜分離配置示例

frontend  web *:80
     acl url_static   path_beg       -i  /static /images /javascript /stylesheets
     acl url_static   path_end       -i  .jpg .gif .png .css .js .html .txt .htm

     use_backend staticsrvs          if url_static
     default_backend             appsrvs

backend staticsrvs
     balance     roundrobin
     server      stcsrv1 172.16.100.6:80 check

backend appsrvs
     balance     roundrobin
     server  app1 172.16.100.7:80 check
     server  app1 172.16.100.7:8080 check

listen stats
     bind :9091
     stats enable
     stats auth admin:admin
     stats admin if TRUE