HAProxy詳解

 HAProxy概述與配置

1、HAProxy概述

　　HAProxy是由 WillyTarreau開發的一款具有高可用性、負載均及基於 TCP和 HTTP的應用代理開源軟件，基於HAProxy的負載均衡架構是最爲常見的免費、快速且具有可靠性的集羣負載均衡架構解決方案。此外，HAProxy特別適合應用於須要會話保持或七層處理的高負載 web站點，就當前常見硬件體系架構，基於HAProxy的負載均衡系統徹底能夠支撐數以萬計的併發鏈接．同時，HAProxy的運行模式使其整合到用戶當前的基礎架構中是個很是簡單且安全的過程。經過 HAProxy的代理，還能夠避免用戶的 Web服務器直接暴露到外部網絡中。

　　HAProxy實現的是一種事件驅動、單一進程的架構模型，此類模型的優勢在於可以支撐高併發大規模的鏈接。反之，多進程或多線程模型受內存和系統調度器的限制以及無處不在的鎖限制，很難應對數以萬計的高併發鏈接。HAProxy支持鏈接拒絕，經過拒絕鏈接，能夠限制某些非法或有意的攻擊型鏈接，從而下降其對網站帶來的危害。的這一功能已成爲目前應對小型 DDOS攻擊的主要方法之一，而且其餘負載均衡器很難作到這點。此外， HAProxy還支持全透明代理，便可以將客戶端地址或者任何指定地址直接鏈接到後端服務器，經過全透明代理，能夠不用修改某些特殊服務器地址而使其直接接收並處理部分特定流量。

　　HAProxy主要爲基於 HTTP和 TCP訪問的應用服務提供負載均衡，如基於 Internet的鏈接服務和基於 web的應用服務。經過負載均衡算法， HAproxy可以接受數以萬計的訪問請求並將其轉發到後端服務器池中進行處理，然後端服務器池就如一個強大的虛擬服務器接受 HAProxy轉發的請求並進行處理。 HAproxy的請求調度器（Scheduler）決定了後端服務器中每一個服務器接受和處理的請求量，在沒有權重的調度算法下，調度器爲每臺服務器分配相同數量的請求，而在加權調度算法下，調度器根據每臺服務器的權重爲每一個後端服務器分配不一樣數量的請求。 HAProxy容許用戶自定義多個代理，併爲每一個代理提供負載均衡服務，代理由一個前端和一個或多個後端構成，前端定義了代理監聽的IP地址（Virtual IP )和端口，同時還需在前端定義中關聯與其相關的後端，而在HAProxy中，後端主要用於定義服務器池和負載均衡算法。HAProxy的負載均衡服務在7層，即應用層，在不少狀況下，因爲商業應用連續性的要求，管理員一般須要部署HAProxy，從而爲基於HTTP的應用提供負載均衡和高可用性。

　　HAProxy的配置文件是/etc/haproxy/haproxy.cfg，該文件是 HAProxy功能配置的集中文件，其代理和負載均衡功能的配置均位於該配置文件中。 HAProxy的配置文件主要分爲四個部分，即全局功能配置段、默認屬性配置段、前端代理配置段、後端負載均衡配置段，各個配置段常見屬性設置和功能描述以下。

一、全局配置段

　　全局配置段的參數將被應用到所有運行 HAProxy的節點中，全局配置段並不針對具體的代理和負載均衡進行設置，其須要配置的參數也相對簡單，典型的haproxy.cfg全局配置段內容以下：

global
daemon
maxconn 　 4000
Pidfile　　/var/run/HAproxy.pid
user　　   HAproxy
group　　  HAproxy
stats　　  socket　/var/lib/HAproxy/stats
log　　    127.0.0.1 　ocal0

　　上述HAProxy的全局配置段中，用戶爲HAProxy經常使用的全局變量配置了參數，這些參數一般是進程級別並與操做系統相關的參數，並在全局`限定了HAProxy的工做特性，幾個重要的參數解釋以下。 

daemon：指定HAProxy之後臺進程的形式運行。

group：運行 HAproxy的用戶屬組，此處爲 HAproxy。

maxconn：HAProxy代理容許的最大並行鏈接數，此處爲4000，默認爲2000。

user：運行HAProxy的用戶，此處爲 HAproxy。

pidfile：HAProxy的進程文件，此處爲/var/run/haproxy.pid。

log：設置HAProxy運行日誌的輸出設備，一般默認爲本機的並默認記錄 INFO級別的日誌，用戶能夠將 HAProxy的日誌輸出到本機或者遠程主機的日誌設備上，並設置須要記錄的日誌級別，如 ERROR和 WARN。

 

　　全局配置段須要注意 HAPrxoy的日誌設備配置，對於大規模集羣，負載均衡器可能會由運行 HAProxy的多個節點組成，若是每一個 HAProxy節點都將日誌存放到本地，則日誌監控和查看極爲不便，所以一般會藉助遠程日誌記錄功能（如 rsyslog)將分散的節點日誌集中到某臺日志服務器上，這時就須要在每一個 HAProxy的全局配置段中指定遠程日誌服務器的地址和對應的日誌記錄設備，同時在遠程日誌記錄服務器上進行相應的設置。在雲端日誌服務器上開啓 rsyslog的 HAProxy日誌記錄功能所需作的設置以下：

一、將/etc/rsyslog.onf中的以下兩行註釋取消
  $M0dLoad imudp
  $UDPServerRun514

二、爲HAProxy設置日誌設備和輸出文件，這裏定義的日誌設備要與haproxy·cfg全局配置段中log參故設置的匹配，在/etc/rsyslog.conf中添加以下語句：
  local0.* /var/log/haproxy/haproxy.log
在/etc/sysconfig/rsyslog中修改SYSLOGD_OPTIONS的值爲以下：
  SYSLOGD_OPTIONS="-r -m 0 -c 2" 

三、分別重啓 rsyslog和 haproxy 
systemctl restart rsyslog.server 
systemctl restart haproxy.service 

四、跟蹤 haproxy的日誌
tail -f /var/10g/haproxy/haproxy.log

二、默認配置段

　　默認(default)配置段設置的參數會被haproxy.cfg的其餘配置段繼承，如frontend、backend和 listen配置段都會繼承 default配置段參數，同時這些配置段也能夠寫default配置段的參數值，一般狀況下，用戶能夠將具備共性的參數放到default段進行統一配置，而後再到各個配置段中進行個性修改，常見的 default配置段以下：

defaults
mode    http
log     global
option  httplog
option  dontlognull
retries 3
timeout  http-request 10s
timeout  queue 1m
timeout  connect 10s
timeout  client 1m
maxconn  10000
timeout  client 1m
timeout  server 1m
timeout  check 10s

默認配置段主要配置參數的解釋以下：

mode：指定 HAProxy實例使用的鏈接協議，即源請求到後端服務器之間的鏈接協議，可能值爲 HTTP和 TCP。對基於HTTP的 web應用服務，一般使用 HTTP模式，對於其餘應用服務，一般使用 TCP模式。

log：指定日誌地址和記錄日誌條目的 syslog/rsyslog日誌設備，此處的 global表示使用 global配置段中設定的log值。

option：日誌記錄選項， httplog表示記錄與 HTTP會話相關的各類屬性值，包括 HTTP請求、會話狀態、鏈接數、源地址以及鏈接時間等。dontlognull表示不記錄空會話鏈接日誌，
　　　　即 HAProxy不會記錄沒有數據傳輸的會話鏈接日誌，基於互聯網的 web應用中不推薦使用dontlognull由於不少空會話鏈接可能包含有惡意行爲，如惡意的端口漏洞掃描就是
　　　　一種沒有數據傳輸的空鏈接。 retries：在鏈接失敗後從新嘗試請求鏈接的次數，超過設置的嘗試次數將認爲鏈接失敗。

timeout:設置各類請求、鏈接、響應的 Timeout時間，單位爲秒(s)或者毫秒(m)。

HTTP-Request：等待客戶端完整 HTTP請求的時間，此處爲等待10s。

queue：設置刪除鏈接和客戶端收到503或服務不可用等提示信息前的等待時間，此處等待時間爲10毫秒。

connect：設置等待服務器鏈接成功的時間，此處爲等待10s。

client：設置容許客戶端處於非活動狀態，即既不發送數據也不接收數據的時間，此處爲1毫秒。

server：設置服務器超時時間，即容許服務器處於既不接收也不發送數據的非活動時間，此處爲1毫秒。

三、Frontend配置

　　前端配置主要完成兩個功能：一是配置監聽客戶端請求的 IP地址和端口，在高可用環境下，此處的監聽 IP地址一般爲虛擬 IP；二是將監聽到的客戶端請求轉發到指定的後端配置中進行負載均衡。典型的 HAProxy前端配置以下。

frontend  WEB
bind  192.168.0.10:80
default_backend  app

　　HAProxy中容許配置多個前端，前端名稱能夠自定義，此處設置了名爲 web的HAProxy前端，經過bind參數指定該前端監聽的IP爲192.168.0.10，端口爲80，而該前端對應的後端名稱是app，一旦前端監聽到鏈接，就會將該鏈接直接轉給名爲app的後端處理，前端與後端是HAProxy配置中的關鍵部分，一般前端負責監聽請求鏈接，後端負責負載均衡。在 openstack高可用集羣配中，因爲要爲每一個 openstack服務進行高可用配置，所以最佳作法就是將每一個服務配置爲一個前端和後端的組合，並將前端監聽的 VIP經過Pacemaker或者Keeplived進行高可用設計。基於HAProxy的Openstack高可用集羣前端配置的例子爲：

數據庫服務前端：
frontend vip-db
bind 192.168.142.201:3306
timeout client 90m
default—backend db-vms-Galera

qpid消息服務前端：
froatend Vip-qpid
bind192·16八、142·215：5672
timeout client120s
default—backend qpid-vms

dashboard服務前端：
frontendvip—horizon
bind192．16八、142·211：80
timeout client180s
cookie SERVERID insert indirect nocache
default backend horizon-vms

四、 Backend配置

　　後端配置主要實現兩個主要功能：一是負載均衡調度算法的設置；二是設置最終響應請求的服務器池各個節點的IP地址和端口，並設置每一個節點的健康檢查方式。一個典型的後端配置以下。

backend app
balance roundrobin
server appl 192.168.1.1：80 check
server app2 192.168.1.2：80 check
server app3 192.168.1.3：80 check inter 2s rise 4 fall 3
server app4 192.168.1.4：80 backup

　　HAProxy容許配置多個後端，而且每一個後端都有一個前端與其對應，後端實例的名稱能夠用戶自定義，可是必定要與對應前端中設置的後端名稱一致。上述後端配置中，後端實例的名稱是 app,採用 Round-Robin負載均衡算法，server行定義後端的真實服務器，服務器的名稱爲app一、app二、app3和 app4，這裏的服務器名稱並不是真實的後端服務器主機名，而只是便於識別的自定義服務器名稱，服務器的具體地址經過緊隨其後的地址和端口號來肯定。此外，在定義後端服務器的同時，經過check參數還可指定HAProxy對服務器的健康檢查方式，上述配置中，後端服務器app3中的inter 2s指定了對app3進行健康檢查的時間隔是2s，rise 4 表示 HAproxy對app3發起4次健康檢查均正常則認爲app3正常，3表示連續3次健康檢查失敗則認爲app3己經故障，HAproxy後端配置中指定了負載均衡所採用的算法， HAProxy支持多種負載均衡算法，用戶能夠根據後端服務器池中各個節點的實際資源配置進行不一樣的算法選取， HAProxy支持的負載均衡算法有如下幾種。

Round-Robin（roundrobin）：與Keeplived的Round-Robin相似，使用這種算法服務請求會被輪詢轉發到服務器池中的每個服務器上，而不去評估服務器的‰負載和處理能力，服務器池中的每一個節點都被輪詢轉發請求。

Static Round-Robin（static-rr）：與 Round-Robin同樣輪詢轉發請求到每個後端服務器，可是不容許對後端服務器進行動態加權設置，即服務器的權重是靜態固定的，而因爲權重靜態固定，後端服務器池中的節點數目不受限。

Least-connection（leastconn）：即最少鏈接數算法，與Keepalived的最少鏈接數算法相似，後端服務器活動鏈接數越多，則接收到的服務請求就越少，反之，則接收到的服務請求越多。

Source（source）：該算法將請求中的源IP地址進行HASH後除以所有正常運行的後端服務器權重來決定接收服務請求的服務器，在這種算法中，同一個客戶端（相同的源 IP地址）發出的請求會被固定轉發給某一個固定的後端服務器。
　　　　　　　　　　可是，若是服務器權重大小發生改變或者服務器數目出現變更，則響應該客戶端請求的後端服務器會改變，由於這時的 HASH/Wight值已經改變。

URL（url）：該算法將請求URL字符串進行HASH併除以所有正常運行的後端服務器權重來決定接收服務請求的服務器，在這種算法中，指向同一目標站點的服務請求會被固定轉發到相同的後端服務器上。URL也稱爲基於目標地址
　　　　　　　的HASH負載均衡算法，主要用於Web Cache集羣中，經過URL負載均衡算法，能夠避免請求由於指向不一樣的cache服務器而致使缺頁，而缺頁會致使刷新 cache最終下降系統響應速率。

URL Parameter（uri_param）：該算法經過查詢源 HTTP請求報文中的某一字符串參數並將其進行 HASH後除以所有服務器權重來決定接收服務請求的服務器。若是HTTP報文中沒有須要的參數，則默認使用Round_Robin算法

Header Name（hdr）：該算法經過查詢HTTP請求報文中的HEAD字段並將HASH後除以所有服務器權重來決定接收服務請求的服務器。若是報文中沒有HEAD參數，則默認使用Round_Robin算法。

　　在高可用集羣配置中，爲了實現服務的高可用，一般每一個後端配置中都須要提供兩個以上的後端服務器進行負載均衡。

五、HAProxy監控頁面

　　HAProxy爲每一個監聽代理提供了實時監控，並能夠將監控參數以 GUI頁而的形式呈現給用戶。要使用HAProxy的GUI頁面，須要在/etc/haproxy/haproxy.cfg配置文件中配置相應的監聽參數，一般須要配置一個Listen置段（也能夠是 Frontend或 Backend配置段)，便可經過 HTTP協議訪問HAProxy的監控頁面，最爲經常使用的HAProxy監控頁面配置以下：

listen status　　    #定義一個listen，也能夠放在frontend或backend段中
mode http 　　　　　　 #使用協議
bind 192.168.142.110:8080 #監聽地址和端口
stats enable 　　　　　　#啓用信息統計功能
stats hide-version     #隱藏版本號
stats uri /HAproxy     #訪問URL
stats realm HAProxy\Statistics #登陸提示信息
stats auth admin:admin         #admin界面，驗證成功後容許管理節點
stats refreah 10s              #頁面刷新時間 

 HAProxy的監控頁面：

　　HAProxy的監控頁面將每項資源的監控參數以表格形式呈現給用戶，並將監控參劃分爲七個類別，即 Queue、Session rate、Sessions、Bytes、Denied、Errors、 Warning、server，每組參數類別下又有多個詳細參數，其中各個參數的解釋以下。

（1）Queue
　　cur:表示當前隊列的請求數量。
　　Max:表是當前隊列最大的請求數量。
　　Limit:表示隊列的限制數量。

（2） Session rate
　　Cur:每秒會話鏈接數量。
　　Max：每秒會話數量最大值。囗 Limit：每秒會話數量的限制值。

（3） Sessions
　　Total:總共會話數量。
　　Cur：當前的會話數量。
　　Max：最大會話數量。
　　Limit;會話鏈接限制。
　　Lbtot：選中一臺服務器所用的總時間。
　　Last：最後一次會話時間。

（4） Bytes
　　In：網絡會話輸人字節數總量。
　　Out:網絡會話輸出字節數總量。

（5） Denied
　　Req：被拒絕的會話請求數量。
　　Resp：拒絕迴應的請求數量。

（6） Errors
　　Req：錯誤的請求數量。
　　Conn：錯誤鏈接數量。
　　Resp：錯誤響應數量。

（7） Warnings
　　 Retr：從新嘗試鏈接的請求數量。
　　 Redis：從新發送的請求數量。

（8） Server
　　status：後端服務器狀態，能夠有 UP和 DOWN兩種狀狀態。
　　LastChk：持續檢查後端服務器的時間。
　　Wght：服務器權重。
　　Act：活動後端服務器數量。
　　Bck：後端備份服務器的數量。
　　Down：狀態爲 Down的後端服務器數量。
　　Downtime：服務器總的 Downtime時間。
　　Throttle：狀態 Backup變爲 Active的服務器數量。

六、 HAProxy配置參考

　　做爲一個專業的負載均衡代理軟件， HAProxy具備很是豐富的配置選項， HAProxy還有不少詳細功能配置項，爲了知足不一樣應用場景下用戶的 HAProxy配置參考，本節將會對 HAProxy配置文件 haproxy.cfg中各個配置段的配置參數，以及這些參數的功能做用進行解釋和總結，用戶能夠根據本身的需求在相應配置段中進行參數取捨，HAProxy各個配置段示例以下。

一、全局配置段參考

global

maxconn20000 　　　　　　 #默認最大鏈接數
log $host_ip local0 　　 #level爲 err/warning/info/debug日誌記錄設備
chroot /var/haproxy/ 　　#chroot運行的路徑
uid 200 　　　　　　　　　　#HAProxy進程屬組UID
gid 200 　　　　　　　　　　#HAproxy進程屬組
daemon 　　　　　　　　　　 #之後臺形式運行HAProxy 
nbproc 2 　　　　　　　　　#進程數量，能夠設置多個進程提升性能
pidfile /var/run/haproxy.pid 　　#HAProixy的pid存放路徑
ulimit-n 65535 　　　　　　　　　　 #ulimit讓的數量限制

 二、默認配置段參考

defaults

log global 　　　　　　　　 #使用global定義的日誌記錄設備
mode {tcp|http|health}   #設置實例的運行模式或協議，當實現內容交換時，前端和後端，必須做在同一種模式 
maxconn 20000　　　　　　  #最大鏈接數
option httplog 　　　　　　#日誌類別爲http日誌格式
option httpclose 　　     #每次請求完畢後主動關閉http通道 
option dontlognull 　　   #不記錄健康檢查的日誌信息
option forwardfor 　　　　 #容許在發往服務器的請求頭部中插入「X-Forwarded-For」頭部
option Redispath 　　　　  #serverid對應的服務器掛掉後，強制定向到其它健康的服務器
option abortonclose 　　  #容許結束掉當前隊列中一直pending的鏈接 
stats refresh 30 　　　　  #統計頁面刷新間隔
retries 3 　　　　　　　　  #認爲服務不可用的嘗試鏈接次數
balance roundrobin 　　　 #默認的負載均衡的方式，這裏爲輪詢方式，也能夠是balance source
contimeout 5000 　　　　  #鏈接超時
clitimeout 50000　　　　　#客戶端超時
srvtimeout 50000　　　　  #服務器超時
timeout check 2000 　　  #心跳檢測超時

 三、監控頁面配置段參考：

listen admin_status #對Frontend和Backend進行監控統計，監控組名稱能夠自定義
mode http 　　　　　　 #使用協議
bind 192.168.142.110:8080 #監聽地址和端口
stats enable 　　　　　　#啓用信息統計功能
stats hide-version     #隱藏版本號
stats uri /HAproxy     #訪問URL
stats realm HAProxy\Statistics #登陸提示信息
stats auth admin:admin         #admin界面，驗證成功後容許管理節點
stats refreah 10s              #頁面刷新時間

#下面語句用於捕獲並將指定的請求/響應首部記錄到HAProxy的日誌中，日誌中記錄的是指定首部的值：
capture request header host len 40
capture request header content-length len 10
capture request header referer len 200
capture request header server len 40
capture response header content-length len 10
capture response header cache-control len 8

四、 FrontEnd配置段參考：

　　FrontEnd配置段主要經過bind配置監聽的虛擬IP地址和端口，同時Frontend配置裏面能夠定義多個acl以進行請求精確匹配，Frontend配置段中還能夠定義與全局默認配置段重名的參數以覆蓋全局配置段的參數。

frontend web_server   #定義前端名稱，可自定義。
bind 0.0.0.0:80   #監聽IP地址與端口
mode http  #使用http協議
log global  #應用全局的日誌配置
option httplog #啓用http的log
option httpclose  #每次請求完主動關閉http通道
option forwardfor 容許發往服務器的請求頭部中插入「X-Forwarded For」頭部
acl warrior_blog hdr_dom(host) -i blog.warrior.cn #若是請求的域名知足www.warrior.cn，則返回true，-i表示忽略大小寫。
acl（缺）

 

五、BackEnd配置段參考：

　　Backend配置段主要配置負載均衡算法，定義後端服務器以及相應的健康檢查方式等參數，同時Backend配置段也能夠定義與默認全局配置段重名的參數，從而覆蓋全局參數值以進行局部後端定義。

backend server_web  #後端名稱
mode http    #http七層模式
balance roundrobin     #負載均衡的方式
option ignore-persist {if | unless} <condition>   #在某些條件下拒絕持續鏈接，適用於靜態文件的負載均衡。
option independant-streams    #啓用雙向超時處理，如socket的read和write
option log-health-checks      #記錄健康檢查日誌
option log—separate—errors    #對非徹底成功的鏈接改變日誌記錄等級
option logasap     #傳輸大文件時能夠提早記錄日誌
option mysql-check    #mysql健康檢查
option  persist     #強制將http請求發往已經down掉的server 
option redispatch   #是否容許從新分配在session失敗後 
option smtpchk    #smtp檢查
option httpchk    #經過http協議進行健康檢查
option socket-stats  #容許對單個socket進行統計
option  srvtcpka     #是否容許向server發送 keepalive 
option tcpka      #是否容許向 server和 client發送 keepalive 
option tcplog     #容許記錄tcp鏈接的狀態和時間 
option transparent     #容許客戶端透明代理 
option httpchk GET /1b.html HTTP/1·0    #心跳檢測的文件
tick-table type ip size 1024     #爲當先後端配置粘性表；表存儲條目類型爲IP地址，容許存儲1k大小的IP地址 
stick on dst        #定義一個請求模式dst，以將一個客戶端同某個後端服務器關聯起來 
timeout server 90m     #後端服務器最大等待時間，超過此時間則認爲服務器不可用。                                           

　　以下進行多後端服務器定義， check inter 1500是檢測心跳頻率， rise 3表示3次檢查結果正確則認爲服務器可用，fall 3表示檢測結果失敗3次則認爲服務器不可用， weight表明服務器權重。port 9200表示經過端口9200來進行基於 http的健康檢查， backup表示該服務器是備份服務器，只有在其餘非 backup服務器均不可用的狀況下負載均衡器纔會使用該後端服務器，默認狀況下使用第一個標記爲 backup的後端服務器， upon-marked-down shutdown-sessions表示當該服務器被認爲是 shutdown的時候，關閉所有與該服務器的請求鏈接。

server 192.168.51.78 192.168.151.78:80 check inter 1500 rise 3 fall 3 weight 1 port 9200 backup on-marked-down shutdown-sessions

server 192.168.51.79 192.168.151.79:80 check inter 1500 rise 3 fall 3 weight 1 port 9200 backup on-marked-down shutdown-sessions

server 192.168.51.80 192.168.151.80:80 check inter 1500 rise 3 fall 3 weight 1 port 9200 backup on-marked-down shutdown-sessions