1.基本配置詳解
global # 全局參數global模塊的設置
log 127.0.0.1 local2 # log語法：log <address_1>[max_level_1] # 全局的日誌配置，使用log關鍵字，指定使用127.0.0.1上的syslog服務中的local0日誌設備，記錄日誌等級爲info的日誌
chroot /var/lib/haproxy #工作目錄
pidfile /var/run/haproxy.pid #進程pid文件
maxconn 4000 #最大連接數
user haproxy #所屬用戶
group haproxy #所屬用戶組
daemon #以守護進程方式運行haproxy
stats socket /var/lib/haproxy/stats #定義socket套接字，針對在線維護很有幫助
defaults # defaults模塊的設置
mode http #默認的模式{ tcp|http|health},health只會返回OK
log global #應用全局的日誌配置
option httplog #啓用日誌記錄HTTP請求，默認不記錄HTTP請求日誌
option dontlognull # 啓用該項，日誌中將不會記錄空連接。所謂空連接就是在上游的負載均衡器者監控系統爲了探測該 服務是否存活可用時，需要定期的連接或者獲取某一固定的組件或頁面，或者探測掃描端口是否在監聽或開放等動作被稱爲空連接；官方文檔中標註，如果該服務上游沒有其他的負載均衡器的話，建議不要使用該參數，因爲互聯網上的惡意掃描或其他動作就不會被記錄下來
option http-server-close #每次請求完畢後主動關閉http通道
option forwardfor except 127.0.0.0/8 #如果服務器上的應用程序想記錄發起請求的客戶端的IP地址，需要在HAProxy上配置此選項， 這樣 HAProxy會把客戶端的IP信息發送給服務器，在HTTP 請求中添加"X-Forwarded-For"字段。 啓用 X-Forwarded-For，在requests 頭部插入客戶端IP發送給後端的server，使後端server獲取到客戶端的真實IP。
option redispatch # 當使用了cookie時，haproxy將會將其請求的後端服務器的serverID插入到cookie中，以保證會話的SESSION持久性；而此時，如果後端的服務器宕掉 了， 但是客戶端的cookie是不會刷新的，如果設置此參數，將會將客戶的請 求強制定向到另外一個後端server上，以保證服務的正常。
retries 3 # 定義連接後端服務器的失敗重連次數，連接失敗次數超過此值後將會將對應後端服務器標記爲不可用
timeout http-request 10s #http請求超時時間
timeout queue 1m #一個請求在隊列裏的超時時間
timeout connect 10s #連接超時
timeout client 1m #客戶端超時
timeout server 1m #服務器端超時
timeout http-keep-alive 10s #設置http-keep-alive的超時時間
timeout check 10s #檢測超時
maxconn 3000 #每個進程可用的最大連接數
listen stats #定義一個listen模塊，用於狀態檢測
mode http #模式採用http
bind 0.0.0.0:8888 #綁定本機的地址及端口
stats enable #啓用狀態檢測功能
stats uri /haproxy-status #狀態檢測的URI
stats auth haproxy:123456 #訪問檢測界面的用戶名和密碼
frontend main *:80 #frontend模塊的設置，定義了一個前端
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js #這裏定義了一個acl規則
use_backend static if url_static #如果匹配到了acl，則訪問後端的static模塊
default_backend my_webserver #如果沒有匹配到acl，則將請求丟給默認的模塊
backend static #定義第一個後端模塊，static
balance roundrobin #負載均衡算法爲輪詢
server static 127.0.0.1:80 check #後端服務器地址
backend my_webserver #定第二個後端，my_wenserver
balance roundrobin #負載均衡算法
server web01 172.31.2.33:80 check inter 2000 fall 3 weight 30 #定義的多個後端
server web02 172.31.2.34:80 check inter 2000 fall 3 weight 30 #定義的多個後端
server web03 172.31.2.35:80 check inter 2000 fall 3 weight 30 #定義的多個後端
Haproxy作爲Loadblance，支持對backend的健康檢查，以保證在後端backend不能服務時，把從frontend進來的request分配至其他可以服務的backend，從而保證整體服務的可用性。
2. 健康檢查相關配置
httpchk <method><uri><version>
option httpchk HEAD / HTTP/1.0
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狀態。
server web-node2 192.168.56.22:8080 check inter 2000 rise 30 fall 15
3. 檢測方式
3.1 通過監聽端口進行健康檢測
這種檢測方式，haproxy只會去檢查server的端口，並不能保證服務真正可用。
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2
3.2 通過URI進行健康檢測
這種檢測方式，是用去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.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2
3.3 通過request獲取的頭部信息進行匹配進行健康檢測
這種檢測方式，是基於一些高級、精細的監測需求，通過對後端頭部訪問的頭部信息進行匹配檢測。
listen http_proxy 0.0.0.0:80
mode http
cookie SERVERID
balance roundrobin
option httpchk HEAD /index.jsp HTTP/1.1\r\n\Host:\www.xxx.com
server web1 192.168.1.1:80 cookie server01 check
server web2 192.168.1.2:80 cookie serve02 check inter 500 rise 1 fall 2
————Blueicex 2020/03/26 16:38 [email protected]