Linux-負載均衡HAproxy

負載均衡之HAProxy

 現在常用的三大開源軟件負載均衡器分別是Nginx、LVS、HAProxy。三大軟件特點如下：

• LVS負載均衡的特點：

  （1）抗負載能力強，抗負載能力強、性能高、能達到F5硬件的60%；對內存和cpu資源消耗比較低。
  （2）工作在網絡4層，通過VRRP協議轉發（僅作分發之用），具體的流量由linux內核處理，因此沒有流量產生。
  （3）穩定性、可靠性好，自身有完美的熱備方案（如：LVS+Keepalived）。
  （4）應用范圍比較廣，可以對所有應用做負載均衡。
  （5）不支持正則處理，不能做動靜分離。
  （6）支持負載均衡算法：rr（輪循）、wrr（加權輪循）、lc（最小連接）、wlc（權重最小連接）。
  （7）配置復雜，對網絡依賴比較大，穩定性很高。

• Nginx負載均衡的特點：

  （1）工作在網絡的七層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構。
  （2）Nginx對網絡的依賴比較小，理論上能ping通就能進行負載均衡。
  （3）Nginx安裝和配置比較簡單，測試起來比較方便。
  （4）也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的並發。
  （5）對后端服務器的健康檢查，只支持通過端口檢測，不支持通過url來檢測。
  （6）Nginx對請求的異步處理可以幫助節點服務器減輕負載。
  （7）Nginx僅能支持http、https和Email協議，這樣就在使用范圍較小。
  （8）不支持Session的直接保持，但能通過ip_hash來解決，對Big request header的支持不是很好。
  （9）支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（加權輪循）、IP-hash（IP哈希）。
  （10）Nginx還能做Web服務器即Cache功能。

• HAProxy負載均衡的特點：

  （1）支持兩種代理模式：TCP（四層）和HTTP（七層）。
  （2）能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作。
  （3）支持url檢測后端的健康狀態。
  （4）更多負載均衡策略比如：動態加權輪循（Dynamic Round Robin），加權源地址哈希（Weighted Source Hash），加權URL哈希和加權參數哈希（Weighted Parameter Hash）。
  （5）單純從效率上來將HAProxy更會比Nginx有更出色的負載均衡速度。
  （6）HAProxy可以對Mysql進行負載均衡，對后端的DB節點進行檢測和負載均衡。
  （7）支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（加權輪循）、source（源地址保持）、RI（請求URL）、rdp-cookie（根據cookie）
  （8）不能做Web服務器即Cache 

這三大主流軟件負載均衡器使用業務場景：

（1）網站建設初期，可以選用Nginx/HAProxy作為反向代理負載均衡（或者流量不大都可以不選用負載均衡），因為其配置簡單，性能也能滿足一般的業務場景。如果考慮到負載均衡器是有單點問題，可以采用Nginx+Keepalived/HAProxy+Keepalived避免負載均衡器自身的單點問題。

（2）網站並發達到一定程度之后，為了提高穩定性和轉發效率，可以使用LVS、畢竟LVS比Nginx/HAProxy要更穩定，轉發效率也更高。不過維護LVS對維護人員的要求也會更高，投入成本也更大。

需要注意的是

Nginx和HAProxy比較：Nginx支持七層、用戶量最大，穩定性比較可靠。HAProxy支持四層和七層，支持更多的負載均衡算法，支持session保存等。具體選擇看使用場景。目前來說HAProxy由於彌補了一些Nginx的缺點致使其用戶量也不斷在提升。

衡量負載均衡器好壞的幾個重要因素

（1）會話率：單位時間內的處理的請求數

（2）會話並發能力：並發處理能力

（3）數據率：處理數據能力

經過官方測試統計，haproxy 單位時間處理的最大請求數為20000個，可以同時維護40000-50000個並發連接，最大數據處理能力為10Gbps。綜合上述，haproxy是性能優越的負載均衡、反向代理服務器。

HAProxy簡介

HAProxy是法國人Willy Tarreau開發的一款可應對客戶端10000以上的同時連接的高性能的TCP和HTTP負載均衡器。由於其豐富強大的功能在國內備受推崇，是目前主流的負載均衡器。Haproxy是一個開源的高性能的反向代理或者說是負載均衡服務軟件之一，它支持雙機熱備、虛擬主機、基於TCP和HTTP應用代理等功能。其配置簡單，而且擁有很好的對服務器節點的健康檢查功能（相當於keepalived健康檢查），當其代理的后端服務器出現故障時，Ｈaproxy會自動的將該故障服務器摘除，當服務器的故障恢復后haproxy還會自動重新添加回服務器主機。

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

Haproxy特別適用於那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。haproxy運行在當前的硬件上，完全可以支持數以萬計的並發連接。並且它的運行模式使得它可以很簡單安全的整合進當前架構中，同時可以保護web服務器不被暴露到網絡上。

Haproxy軟件引入了frontend，backend的功能，frontend（acl規則匹配）可以根據任意HTTP請求頭做規則匹配，然后把請求定向到相關的backend（server pools等待前端把請求轉過來的服務器組）。通過frontend和backend，可以很容易的實現Haproxy的7層負載均衡代理功能。

HAProxy是一種高效、可靠、免費的高可用及負載均衡解決方案，非常適合於高負載站點的七層數據請求。客戶端通過HAProxy代理服務器獲得站點頁面，而代理服務器收到客戶請求后根據負載均衡的規則將請求數據轉發給后端真實服務器。

同一客戶端訪問服務器，HAProxy保持會話的三種方案：

（1）HAProxy將客戶端IP進行Hash計算並保存，由此確保相同IP來訪問時被轉發到同一台真實服務器上。
（2）HAProxy依靠真實服務器發送給客戶端的cookie信息進行會話保持。
（3）HAProxy保存真實服務器的session及服務器標識，實現會話保持功能。

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進行郵件或短報警。

HAProxy主要工作位置

- HAProxy支持http反向代理

- HAProxy支持動態程序的反向代理

-HAProxy支持基於數據庫的反向代理

HAProxy 相關術語

訪問控制列表（ACL）

在負載均衡中，ACL用於測試某些狀況，並根據測試結果執行某些操作（例如選定一套服務器或者屏蔽某條請求），如下ACL示例

acl url_blog path_beg /blog

如果用戶請求的路徑以/blog 開頭，則匹配這條ACL。舉例來說，http://www.cnblogs.com/blog/blog-entry-1請求即符合這一條件。

Backend

所謂的backend是指一組服務器，負責接收各轉發請求。Backend在HAProxy配置中的backend部分進行定義。一般來講，backend的定義主要包括：

- 使用哪種負載均衡算法

- 一套服務器與端口列表

一條backend能夠容納一套或者多套服務器一一總體而言向backend中添加更多服務器將能夠將負載擴散至更多的服務器，從而增加潛在負載容量。這種方式也能夠提升可靠性，從而應對服務器發生故障的情況。

下面來看一套雙backend配置示例，分別為web-backend與blog-backend，其各自包含兩套web服務器，且監聽端口80：

backend web-backend
  balance roundrobin
  server web1 web1.kevin.com:80 check
  server web2 web2.kevin.com:80 check
 
backend blog-backend
  balance roundrobin
  mode http
  server blog1 blog1.kevin.com:80 check
  server blog2 blog2.kevin.com:80 check

其中：

• balance roundrobin行指定負載均衡算法，具體細節參考負載均衡算法部分
• mode http 則指定所使用的7層代理機制，具體參考負載均衡類型部分
• 結尾處的check 選項指定在這些后端服務器上執行運行狀態檢查

Frontend

一條frontend負責定義請求如何被轉發至backend。Frontend在HAProxy配置中的frontend部分。其定義由以下幾個部分組成：

• 一組IP地址與一個端口（例如10.1.1.2:80，*:443，等等）
• ACL
• use_backend規則，其負責根據當前ACL條件定義使用哪個backend，而default_backend規則處理一切其它情況

可以將同一frontend配置至多種不同網絡流量類型！

負載均衡的基本類型

無負載均衡

簡單的無負載均衡Web應用環境，用戶會直接接入Web服務器，即ktest.com且其中不存在負載均衡機智。如果單一Web服務器發生故障，用戶將無法進入到該服務器。另外，如果多位用戶同時訪問該服務器，且其無法處理該負載，則可能出現相應緩慢或者無法接入的情況

四層負載均衡

最為簡單的負載均衡方式，將網絡流量引導至多台服務器以使用四層（即傳輸層）負載均衡。這種方式會根據IP范圍與端口進行用戶流量轉發（如果有請求執行http://ktest.com/anything，則該流量將被轉發至backend，並由其處理全部指向ktest.com在端口80上的請求）

frontend web_80                            
   mode tcp
   bind :80
   default_backend web-backend
 
backend web-backend
   mode tcp
   server 192.168.1.25 192.168.1.25:80 weight 1 check inter 1s rise 2 fall 2
   server 192.168.1.26 192.168.1.26:80 weight 1 check inter 1s rise 2 fall 2

用戶訪問負載均衡器，后者將用戶請求轉發至后端服務器的web-backend組。被選定的后端服務器將直接影響用戶請求。總體而言，web-backend中的全部服務器都應當擁有同樣的內容，否則用戶可能會遭遇內容不一致的問題。請注意后端兩個Web服務器都接入同樣的數據庫服務器。

七層負載均衡

 另一種更為復雜的負載均衡方式，網絡流量使用7層（即應用層）負載均衡。使用7層意味着負載均衡器能夠根據用戶的請求內容將請求轉發至不同后端服務器。這種方式允許大家在同一域名及端口上運行多套Web應用服務器。下圖為一套簡單的7層負載均衡示例，在本示例中，如果用戶向ktest.com/blog發送請求，則會被轉發至blog后端，其包含一組運行有同一blog應用的服務器。其它請求則會被轉發至web-backend，其負責運行其應用。本示例中的兩套backend皆使用同樣的數據庫服務器。

frontend http
   bind *:80
   mode http
 
  acl url_blog path_beg /blog
  use_backend blog-backend if url_blog
 
  default_backend web-backend
 
backend web-backend
    mode http
    balance roundrobin
    cookie SERVERID insert indirect nocache
    option httpclose
    option forwardfor
    server web01 192.168.1.25:80 weight 1 cookie 3 check inter 2000 rise 2 fall 5
    server web01 192.168.1.26:80 weight 1 cookie 3 check inter 2000 rise 2 fall 5

這部分片段配置一套名為http的frontend，其負責處理端口80上的所有輸入流量。

• acl url_blog path_beg 這里的/blog表示匹配那些用戶請求路徑以/blog開頭的請求。
• use_backend blog-backend if url_blog 這里采用該ACL將流量代理至blog-backend。
• default_backend web-backend 這里指定全部其它流量將被轉至web-backend。

負載均衡算法

HAProxy支持的負載均衡算法

 負載均衡算法用於檢測后端中的哪套服務器被負載均衡機制選定進行請求響應。HAProxy提供多種算法選項。除了負載均衡算法之外，我們還能夠為服務器分配一個weight參數來指定該服務器被選定的頻率。由於HAProxy提供多種負載均衡算法，下面說明幾種常用的算法：

• roundrobin：表示簡單的輪循，即客戶端每訪問一次，請求輪循跳轉到后端不同的節點機器上
• static-rr：基於權重輪循，根據權重輪循調度到后端不同節點
• leastconn：加權最少連接，表示最少連接者優先處理
• source：表示根據請求源IP，這個跟Nginx的IP_hash機制類似，使用其作為解決session問題的一種方法
• uri：表示根據請求的URL，調度到后端不同的服務器
• url_param：表示根據請求的URL參數來進行調度
• hdr（name）：表示根據HTTP請求頭來鎖定每一次HTTP請求
• rdp-cookie（name）：表示根據cookie（name）來鎖定並哈希每一次TCP請求

常用的負載均衡算法

1. 輪循算法：roundrobin，Round Robin會對服務器進行輪流選定，亦為HAProxy的默認算法。即客戶端每訪問一次，請求就跳轉到后端不同的節點機器上。
2. 根據請求源IP算法：source，其根據源IP（即用戶IP地址）進行服務器選定。通過這種方式，我們可以確定同一用戶接入同一服務器。
3. 最少連接者先處理算法：lestconn，選定連接數量最少的服務器——建議在周期較長的會話中使用這一算法。同一后端中的服務器亦會以輪循方式進行輪流選定。

粘性會話

部分應用要求用戶始終接入同一后端服務器，這一點需要利用粘性會話實現，其要求在backend中使用appsession參數。

運行狀態檢查

HAProxy利用運行狀態來檢測后端服務器是否可用於處理請求。通過這種方式，我們不必以手動方式撤下不可用的后端服務器。默認運行狀態檢查會與目標服務器建立一條TCP連接，即檢查后端服務器是否在監聽所配置的IP地址和端口。

如果某套服務器未能通過運行狀態檢查，並因此無法相應請求，則其會在后端中被自動禁用——意味着流量將不再被轉發至該服務器處，直到其重新恢復狀態。如果后端中的全部服務器皆發生故障，則服務將不再可用，直到至少一套后端服務器重新恢復正常。

對於特定后端類型，列如特定狀態下的數據庫服務器，默認運行狀態檢查可能無法正確識別其正常與否。

其它解決方案

如果覺得HAProxy可能太過復雜，那么以下解決方案同樣值得考慮：

• LVS - 一套簡單且快速的4層負載均衡器，多數linux發行版都內置有這套方案
• Nginx - 一套快速且可靠的Web服務器，亦可用於代理及負載均衡。Nginx通常與HAProxy相結合以實現緩存及壓縮功能。

HAProxy部署

源碼編譯安裝

（1）安裝依賴軟件包

# yum install -y net-tools vim lrzsz tree screen lsof tcpdump nc mtr nmap gcc glib gcc-c++ make

（2）下載軟件包

# cd /usr/local/
# wget https://www.haproxy.org/download/1.9/src/haproxy-1.9.6.tar.gz

（3）編譯安裝

# tar xzf haproxy-1.9.6.tar.gz
# cd haproxy-1.9.6/
# make TARGET=linux2628 PREFIX=/usr/local/haproxy-1.9.6
# make install
# cp /usr/local/sbin/haproxy /usr/sbin/
# haproxy -v
HA-Proxy version 1.9.6 2019/03/29 - https://haproxy.org/

（4）啟動腳本 

# cp /usr/local/haproxy-1.9.6/examples/haproxy.init /etc/init.d/haproxy
# chmod 755 /etc/init.d/haproxy

（5）配置文件

# useradd -r haproxy    //創建haproxy用戶
# mkdir /etc/haproxy    //創建存放配置文件的目錄
# mkdir /var/lib/haproxy    //創建存放socket文件的目錄
# vim /etc/haproxy/haproxy.cfg    //編輯配置文件
global
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

listen admin
    bind 0.0.0.0:8088
    stats enable
    stats refresh 2s
    stats uri /status
    stats auth haproxy:superman
    stats realm "haproxy info"
    stats hide-version

（6）啟動haproxy

# systemctl start haproxy

說明：如果啟動HAProxy出現　/etc/rc.d/init.d/haproxy: line 26: [: =: unary operator expected　這個錯誤，修改/etc/init.d/haproxy  文件的26行 [ ${NETWORKING} = "no" ] && exit 0 為　[ "${NETWORKING}" = "no" ] && exit 0 

yum安裝

（1）直接yum安裝即可

# yum install haproxy -y

 （2）文件存放位置

/usr/sbin/haproxy    //二進制文件
/usr/share/haproxy    //共享文件
/var/lib/haproxy    //庫文件
/etc/rc.d/init.d/haproxy    //啟動二進制文件
/etc/logrotate.d/haproxy    //日志切割
/etc/sysconfig/haproxy    //配置
/etc/haproxy      //配置目錄

HAProxy配置

HAProxy配置過程的3個主要部分

• 命令行參數，這是最優先的 
• global（全局）段，設置進程級參數
• 代理配置段，通常位於“default”，“listen”，“frontend”，“backend”這樣的形式內

 配置文件的語法是由關鍵字后跟可選的一個或者多個參數（參數之間有空格）組成。如果字符串中包含空格，必須使用“\”進行轉義。\本身需要使用\進行轉義。

一些參數值為時間，比如說 timeout。時間通常單位為毫秒（ms），但是也可以通過加后綴來使用其他的單位，支持的單位有：

- us : microseconds. 1 microsecond = 1/1000000 second
- ms : milliseconds. 1 millisecond = 1/1000 second. This is the default.
- s  : seconds. 1s = 1000ms
- m  : minutes. 1m = 60s = 60000ms
- h  : hours.   1h = 60m = 3600s = 3600000ms
- d  : days.    1d = 24h = 1440m = 86400s = 86400000ms

HAProxy配置中的五大部分

HAProxy配置文件根據功能和用途，主要有5個部分組成，但有些部分不是必須的，可以根據需要選擇相應的部分進行配置。

• global：用來設定全局配置參數，屬於進程級的配置，通常和操作系統配置有關。
• defaults：默認參數的配置部分，有些部分設置的參數值，默認會自動引用到下面的frontend、backend和listen部分中，因此，如果某些參數屬於公用的配置，只需要在defaults部分添加一次即可。而如果在frontend、backend和listen部分中也配置了與defaults部分一樣的參數，那么defaults部分參數對應的值自動被覆蓋。
• frontend：此部分用於設置用戶請求的前端虛擬節點。匹配用戶接收客戶所請求的域名，url等，並針對不同的匹配，做不同的請求處理。
• backend：此部分用於設置集群后端服務集群的配置，也就是用來添加一組真實服務器，以及對后端服務器的一些權重、隊列、連接數等選項的設置。
• listen：此部分可以理解為frontend和backend的結合題。

 HAProxy配置文件的配置方法主要用兩種：

　　一種是有前端（frontend）和后端（backend）配置塊組成，前端和后端都可以有多個。

　　第二種是只有一個listen配置塊來同時實現前端和后端。

global  #全局參數的配置

log 127.0.0.1 local0 info
    # log語法：log [max_level_1]
    # 全局的日志配置，使用log關鍵字，指定使用127.0.0.1上的syslog服務中的local0日志設備，記錄日志等級為info的日志
maxconn 4096
    # 定義每個haproxy進程的最大連接數，由於每個連接包括一個客戶端和一個服務器端，所以單個進程的TCP會話最大數目將是該值的兩倍。
user haproxy
group haproxy
    # 設置運行haproxy的用戶和組，也可使用uid，gid關鍵字替代之
daemon
    # 以守護進程的方式運行
nbproc 16
    # 設置haproxy啟動時的進程數，根據官方文檔的解釋，我將其理解為：該值的設置應該和服務器的CPU核心數一致，即常見的2顆8核心CPU的服務器，即共有16核心，則可以將其值設置為：<=16 ，創建多個進程數，可以減少每個進程的任務隊列，但是過多的進程數也可能會導致進程的崩潰。這里我設置為16
maxconn 4096
    # 定義每個haproxy進程的最大連接數，由於每個連接包括一個客戶端和一個服務器端，所以單個進程的TCP會話最大數目將是該值的兩倍。
#ulimit -n 65536
    # 設置最大打開的文件描述符數，在1.4的官方文檔中提示，該值會自動計算，所以不建議進行設置
pidfile /var/run/haproxy.pid
    # 定義haproxy的pid

示例：

global
    maxconn 100000
    chroot /var/lib/haproxy
    pidfile /var/run/haproxy.pid 
    uid 99  
    gid 99 
    daemon
    nbproc 1 
    log 127.0.0.1 local3 info
    stats socket /var/lib/haproxy/stats

代理（Proxies）相關設置

使用HAProxy進行反向代理負載均衡，最常修改的部分就是代理相關的配置了，代理相關配置位於下列配置段中，

　　-defaults　　<name>

　　-frontend　　<name>

　　-backend　　<name>

　　-listen　　　  <name>

"defaults"段為其后的所有其他配置段設置默認參數。 "defaults"段可以有多個，后設置的總是會覆蓋之前的配置。查看下面的列表可以知道"defaults"段可以使用哪些配置參數。"defaults"關鍵字是可選的，但是為了更好的可讀性，建議加上。

"frontend"段描述了一組監聽的套接字，它們接受客戶端連接。

"backend"段描述了一組服務器，代理(Haproxy)會連接這些服務器並轉發客戶端請求到這些服務器上。

"listen"段定義了一個完整的代理，它的前段(frontend)和后端(frontend)都在這個配置段里。這種配置通常用於僅TCP的流量.

代理名必須由大（小）寫字母、數字、'-'、'_'、'.'、':'組成。ACL名字是大小寫敏感的，也即www和WWW分別指不同的代理。

由於歷史原因，所有的代理名字是可以重疊的，這種僅僅會導致日志有些問題。后來內容交換（Content Switching）的加入使得兩個有重復功能的代理（frontend/backend）必須使用不同的名字。然而，仍然允許frontend和backend使用同一個名字，因為這種配置會經常遇到。

當前，HAProxy支持兩種主要的代理模式: "tcp"也即4層，和"http"，即7層。在4層模式下，HAproxy僅在客戶端和服務器之間轉發雙向流量。7層模式下，HAProxy會分析協議，並且能通過允許、拒絕、交換、增加、修改或者刪除請求(request)或者回應(response)里指定內容來控制協議，這種操作要基於特定規則。

defaults 配置

defaults    # 默認部分的定義
mode http
     # mode語法：mode {http|tcp|health} 。http是七層模式，tcp是四層模式，health是健康檢測，返回OK
log 127.0.0.1 local3 err
     # 使用127.0.0.1上的syslog服務的local3設備記錄錯誤信息
retries 3
     # 定義連接后端服務器的失敗重連次數，連接失敗次數超過此值后將會將對應后端服務器標記為不可用
option httplog
     # 啟用日志記錄HTTP請求，默認haproxy日志記錄是不記錄HTTP請求的，只記錄“時間[Jan 5 13:23:46] 日志服務器[127.0.0.1] 實例名已經pid[haproxy[25218]] 信息[Proxy http_80_in stopped.]”，日志格式很簡單。
option redispatch
     # 當使用了cookie時，haproxy將會將其請求的后端服務器的serverID插入到cookie中，以保證會話的SESSION持久性；而此時，如果后端的服務器宕掉了，但是客戶端的cookie是不會刷新的，如果設置此參數，將會將客戶的請求強制定向到另外一個后端server上，以保證服務的正常。
option abortonclose
     # 當服務器負載很高的時候，自動結束掉當前隊列處理比較久的鏈接
option dontlognull
     # 啟用該項，日志中將不會記錄空連接。所謂空連接就是在上游的負載均衡器或者監控系統為了探測該服務是否存活可用時，需要定期的連接或者獲取某一固定的組件或頁面，或者探測掃描端口是否在監聽或開放等動作被稱為空連接；官方文檔中標注，如果該服務上游沒有其他的負載均衡器的話，建議不要使用該參數，因為互聯網上的惡意掃描或其他動作就不會被記錄下來
option httpclose
     # 這個參數我是這樣理解的：使用該參數，每處理完一個request時，haproxy都會去檢查http頭中的Connection的值，如果該值不是close，haproxy將會將其刪除，如果該值為空將會添加為：Connection: close。使每個客戶端和服務器端在完成一次傳輸后都會主動關閉TCP連接。與該參數類似的另外一個參數是“option forceclose”，該參數的作用是強制關閉對外的服務通道，因為有的服務器端收到Connection: close時，也不會自動關閉TCP連接，如果客戶端也不關閉，連接就會一直處於打開，直到超時。
contimeout 5000
     # 設置成功連接到一台服務器的最長等待時間，默認單位是毫秒，新版本的haproxy使用timeout connect替代，該參數向后兼容
clitimeout 3000
     # 設置連接客戶端發送數據時的成功連接最長等待時間，默認單位是毫秒，新版本haproxy使用timeout client替代。該參數向后兼容
srvtimeout 3000
     # 設置服務器端回應客戶度數據發送的最長等待時間，默認單位是毫秒，新版本haproxy使用timeout server替代。該參數向后兼容

示例：

defaults
    option http-keep-alive
    maxconn 100000
    mode http
    timeout connect 5000ms
    timeout client  50000ms
    timeout server 50000ms

Listen 配置

listen status    
    # 定義一個名為status的部分
bind 192.168.1.24:1080
    # 定義監聽的套接字
mode http
    # 定義為HTTP模式
log global
    # 繼承global中log的定義
stats refresh 30s
    # stats是haproxy的一個統計頁面的套接字，該參數設置統計頁面的刷新間隔為30s
stats uri /status
    # 設置統計頁面的uri為/status，訪問地址即為：http://192.168.1.24:1080/status
stats realm "Private lands"
    # 設置統計頁面認證時彈出對話框的提示內容
stats auth admin:password
    # 設置統計頁面認證的用戶和密碼，如果要設置多個，另起一行寫入即可
stats hide-version
    # 隱藏統計頁面上的haproxy版本信息

示例：

listen status
    mode http
    bind 192.168.1.24:1080
    stats enable
    stats uri     /status 
    stats auth    haproxy:superman
    stats hide-version

Frontend 配置

frontend http_80_in    
    # 定義一個名為http_80_in的前端部分
bind 0.0.0.0:80
    # http_80_in定義前端部分監聽的套接字
mode http
    # 定義為HTTP模式
log global
    # 繼承global中log的定義
option forwardfor
    # 啟用X-Forwarded-For，在requests頭部插入客戶端IP發送給后端的server，使后端server獲取到客戶端的真實IP
acl static_down nbsrv(static_server) lt 1
    # 定義一個名叫static_down的acl，當backend static_sever中存活機器數小於1時會被匹配到
use_backend php_server if static_down
    # 如果滿足策略static_down時，就將請求交予backend php_server

示例：

frontend frontend_www_example_com
    bind 192.168.1.24:80
    mode http
    option httplog
    log global
    default_backend backend_www_example_com    //應用后端自定義服務器組名backend_www_example_com

Backend 配置

backend php_server    #定義一個名為php_server的后端部分
mode http
     # 設置為http模式
balance source
     # 設置haproxy的調度算法為源地址hash
cookie SERVERID
     # 允許向cookie插入SERVERID，每台服務器的SERVERID可在下面使用cookie關鍵字定義
option httpchk GET /test/index.php
     # 開啟對后端服務器的健康檢測，通過GET /test/index.php來判斷后端服務器的健康情況
server php_server_1 10.12.25.68:80 cookie 1 check inter 2000 rise 3 fall 3 weight 2
server php_server_2 10.12.25.72:80 cookie 2 check inter 2000 rise 3 fall 3 weight 1
server php_server_bak 10.12.25.79:80 cookie 3 check inter 1500 rise 3 fall 3 backup
     # server語法：server [:port] [param*]
     # 使用server關鍵字來設置后端服務器；為后端服務器所設置的內部名稱[php_server_1]，該名稱將會呈現在日志或警報中、后端服務器的IP地址，支持端口映射[10.12.25.68:80]、指定該服務器的SERVERID為1[cookie 1]、接受健康監測[check]、監測的間隔時長，單位毫秒[inter 2000]、監測正常多少次后被認為后端服務器是可用的[rise 3]、監測失敗多少次后被認為后端服務器是不可用的[fall 3]、分發的權重[weight 2]、最為備份用的后端服務器，當正常的服務器全部都宕機后，才會啟用備份服務器[backup]

示例：

backend backend_www_example_com
    option forwardfor header X-REAL-IP
    option httpchk HEAD / HTTP/1.0
    balance source
    server web-node1  192.168.1.25:8080 cookie 1 check inter 2000 rise 3 fall 3
    server web-node2  192.168.1.26:8080 cookie 2 check inter 2000 rise 3 fall 3
    server web-node3_bak 192.168.1.27:80 cookie 3 check inter 1500 rise 3 fall 3 backup

HAProxy健康檢查

HAProxy作為Loadbalance，支持對 backend 的健康檢查，以保證在后端的 backend 不能服務時，把從 frontend進來的 request 分配至其它可服務的 backend，從而保證整體服務的可用性。

通過監聽端口進行健康檢測

這種檢測方式，haproxy 知會去檢查后端 server 的端口，並不能保證服務的真正可用

listen http_proxy 0.0.0.0:80 
        mode http 
        cookie SERVERID 
        balance roundrobin 
        option httpchk 
        server web1 192.168.1.25:80 cookie server01 check 
        server web2 192.168.1.26:80 cookie server02 check inter 500 rise 1 fall 2 

通過URL獲取進行健康檢測

這種檢測方式，是用過去GET 后端的 server 的web頁面，基本上可以代表后端服務的可用性

listen http_proxy 0.0.0.0:80 
        mode http 
        cookie SERVERID 
        balance roundrobin 
        option httpchk GET /index.html 
        server web1 192.168.1.25:80 cookie server01 check 
        server web2 192.168.1.26:80 cookie server02 check inter 500 rise 1 fall 2 

相關配置

option httpchk <method><uri><version>
啟用七層健康檢測
http-check disable-on-404     //如果backend返回404，則除了長連接之外的后續請求將不被分配至該backend 
http-check send-state         //增加一個header，同步HAProxy中看到的backend狀態。該header為server可見。 X-Haproxy-Server-State: UP 2/3; name=bck/srv2; node=lb1; weight=1/2; scur=13/22; qcur=0 

server option 
    check：啟用健康檢測
    inter：健康檢測間隔
    rise：檢測服務可用的連續次數
    fall：檢測服務不可用的連續次數
    error-limit：往server寫數據連續失敗的次數上限，執行on-error的設定
    observe <mode>：把正常服務過程作為健康檢測請求，即實時檢測
    on-error <mode>：滿足error-limit后執行的操作（fastinter、fail-check、sudden-death、mark-down）。其中fastinter表示立即按照fastinter的檢測延時進行。fail-check表示改次error作為一次檢測；sudden-death表示模仿一次fatal，如果緊接着一次fail則置server為down;mark-down表示直接把server置為down狀態。

其它
    retries：連接失敗重試的次數，如果重試該次數后還不能正常服務，則斷開連接。

 

 

參考文章：https://www.cnblogs.com/skyflask/p/6970154.html     https://www.cnblogs.com/kevingrace/p/6138150.html