1 HAProxy 簡介

HAProxy（ High Availability Proxy）是一個高性能的負載均衡器和代理服務器，為基于 TCP 和 HTTP 的應用程序提供高可用性、負載平衡和代理，廣泛應用于提高 web 應用程序的性能和可靠性。它支持多種協議，包括 ?四層（TCP/UDP）與七層（HTTP/HTTPS）負載均衡?，能夠處理大量并發連接，支持基于cookie的持久性、自動故障切換、支持正則表達式、SSL終端卸載、HTTP頭改寫、路徑路由及web狀態統計等功能。

企業版網站：HAProxy Technologies | Powering the World's Busiest Applications

社區版網站：HAProxy - The Reliable, High Perf. TCP/HTTP Load Balancer

github：https://github.com/haprox

四層負載均衡和七層負載均衡的區別

1.分層位置:四層負載均衡在傳輸層及以下，七層負載均衡在應用層及以下

2.性能 :四層負載均衡架構無需解析報文消息內容，在網絡吞吐量與處理能力上較高:七層可支持解析應用 層報文消息內容，識別URL、Cookie、HTTP header等信息。

3.原理 :四層負載均衡是基于ip+port;七層是基于虛擬的URL或主機IP等。

4.功能類比:四層負載均衡類似于路由器;七層類似于代理服務器。

5.安全性:四層負載均衡無法識別DDoS攻擊;七層可防御SYN Cookie/Flood攻擊

1.1 負載均衡

負載均衡是一種將網絡流量或計算任務分配到多個服務器或資源上的技術。目的是優化性能、提高可靠性和增強可擴展性。其核心原理是通過調度算法將請求均勻分發，避免單一服務器過載，從而提升整體系統的處理能力和服務穩定性。

負載均衡器：負載均衡器（Load Balancer）是網絡架構中的關鍵組件，負責將客戶端請求智能分配到多個后端服務器，以優化資源利用、提升系統性能并保障高可用性。?

代理服務器：代理服務器（Proxy Server）是位于客戶端與目標服務器之間的中間節點，通過轉發請求和響應實現網絡通信的中介功能。其核心價值在于優化性能、增強安全性和擴展網絡能力。

?分類?

?硬件負載均衡器?：專用設備（如F5），性能高但成本昂貴。

軟件負載均衡器?：如Nginx、HAProxy，靈活且成本低，但可能受限于宿主資源。

??網絡層級?

四層負載均衡?：基于TCP/UDP協議，通過IP和端口分發請求。

?七層負載均衡?：解析HTTP內容（如URL、Cookie），實現更精細的路由。

?常用算法?

??輪詢（Round Robin）??：依次分配請求，簡單但忽略服務器負載差異。

?加權輪詢?：根據服務器性能分配權重，高性能服務器處理更多請求。

最少連接數?：優先將請求發送至當前連接數最少的服務器。

哈希算法?：基于請求特征（如IP或URL）固定分配到特定服務器，適用于會話保持。

??應用場景?

Web服務?：分散高并發訪問壓力，如電商促銷活動。 ?云計算?：動態分配虛擬機或容器資源，適應流量波動。 ?數據庫集群?：通過讀寫分離提升數據庫性能。 ?全局負載均衡?：結合DNS解析，實現跨地域容災。?

??優勢?

?高可用性?：自動屏蔽故障節點，保障服務持續運行。

?擴展性?：按需增減服務器，靈活應對流量變化。 ?

資源優化?：均衡負載避免資源浪費，提升處理效率。

1.2 HAProxy的基本配置信息

HAProxy 的配置文件haproxy.cfg由兩大部分組成，分別是：global（全局配置段）和proxies（代理配置段）

1.2.1 global：全局配置段

進程及安全配置相關的參數

性能調整相關參數

Debug參數

1.2.1.1?global 配置參數說明

global ?

? ? ? ?log ? ? ? ? 127.0.0.1 local2 ? ? ? ? ? ? ? ? ? ? ? ?#定義全局的syslog服務器；日志服務器需要開啟UDP協議，最多可以定義兩個

? ? ? ? chroot ? ? ? ? ? ? ?/var/lib/haproxy ? ? ? ? ? ? ? ? # 鎖定運行目錄 ?

? ? ? ? pidfile ? ? ? ? ? ? ?/var/run/haproxy.pid ? ? ? ? ?#指定pid文件 ?

? ? ? ? maxconn ? ? ? ? 100000 ? ? ? ? ? ? ? ? ? ? ? ? ? ? #指定最大連接數 ?

? ? ? ? user ? ? ? ? ? ? ? ? ?haproxy ? ? ? ? ? ? ? ? ? ? ? ? ? #指定haproxy的運行用戶 ?

? ? ? ? group ? ? ? ? ? ? ? ?haproxy ? ? ? ? ? ? ? ? ? ? ? ? ? #指定haproxy的運行組 ?

? ? ? ? daemon ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#指定haproxy以守護進程方式運行

? ? ? ? stats socket ? ? ? /var/lib/haproxy/stats ? ? ?#指定haproxy的套接字文件 ?

? ? ? ? nbproc ? ? ? ? ? ? ? 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #指定haproxy的work進程數量，默認是1個 ? ? ? ? ? cpu-map ? ? ? ? ? ?1 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#指定第一個work綁定第一個cpu核心 ?

? ? ? ? cpu-map ? ? ? ? ? ? 2 1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #指定第二個work綁定第二個cpu核心

? ? ? ? nbthread ? ? ? ? ? ? 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#指定haproxy的線程數量，默認每個進程一個線 程，此參數與nbproc互斥

? ? ? ? maxsslconn ? ? ? 100000 ? ? ? ? ? ? ? ? ? ? ? ? ? #每個haproxy進程ssl最大連接數,用于haproxy配置了證書的場景下

? ? ? ? maxconnrate ? ? ?100 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #指定每個客戶端每秒建立連接的最大數量

1.2.2 proxies：代理配置段

defaults：為frontend, backend, listen提供默認配置

frontend：前端，相當于nginx中的server {}

backend：后端，相當于nginx中的upstream {}

listen：同時擁有前端和后端配置,配置簡單,生產推薦使用

1.2.2.1 ?proxies參數說明proxies

1.defaults：默認配置項，針對以下的frontend、backend和listen生效，可以多個 name也可以沒有name

2.frontend：前端servername，類似于Nginx的一個虛擬主機 server和LVS服務集 群。

3.backend：后端服務器組，等于nginx的upstream和LVS中的RS服務器

4.listen： 將frontend和backend合并在一起配置，相對于frontend和backend 配置更簡潔，生產常用

1.2.2.2 ?defaults默認配置項詳解?

defaults
????????mode ???????????????????????????http????????????????????????#HAProxy實例使用的連接協議
????????log????????????????????????????????global?????????????????????#指定日志地址和記錄日志條目的syslog/rsyslog日志設備，此處的 global表示使用 global配置段中 設定的log值。
????????option???????????????????????????httplog????????????????????#日志記錄選項，httplog表示記錄與 HTTP
會話相關的各種屬性值，包括 HTTP請求、會話狀態、連接數、源地 址以及連接時間等
????????option???????????????????????????dontlognull???????????????#dontlognull表示不記錄空會話連接日志
????????option http-server-close????????????????????????????????#等待客戶端完整HTTP請求的時間，此處為等 待10s。
????????option forwardfor ?????????except 127.0.0.0/8???#透傳客戶端真實IP至后端web服務器
????????option ??????????????????????????redispatch????????????????#當server Id對應的服務器掛掉后，強制定 向到其他健康的服務器，重新派發
????????retries???????????????????????????3???????????????????????????????#連接后端服務器失敗次數
????????timeout http-request?????10s???????????????????????????#等待客戶端請求完全被接收和處理的最長時間
????????timeout queue??????????????1m?????????????????????????????#設置刪除連接和客戶端收到503或服務不可用等提示信息前的等待時間
????????timeout connect????????????10s???????????????????????????#設置等待服務器連接成功的時間
????????timeout client????????????????1m????????????????????????????#設置允許客戶端處于非活動狀態，即既不發 送數據也不接收數據的時間
????????timeout server???????????????1m???????????????????????????#設置服務器超時時間，即允許服務器處于既 不接收也不發送數據的非活動時間
????????timeout http-keep-alive 10s??????????????????????????#session 會話保持超時時間，此時間段內
會轉發到相同的后端服務器
????????timeout check ???????????????10s?????????????????????????#session 會話保持超時時間，此時間段內
會轉發到相同的后端服務器
????????maxconn????????????????????????3000
????????errorloc ?503 https://www.baidu.com

1.3?HAProxy的算法

HAProxy通過固定參數 balance 指明對后端服務器的調度算法

balance參數可以配置在listen或backend選項中。

HAProxy的調度算法分為靜態和動態調度算法

有些算法可以根據參數在靜態和動態算法中相互轉換。

1.3.1?靜態算法

靜態算法：按照事先定義好的規則輪詢公平調度，不關心后端服務器的當前負載、連接數和響應速度等，且無法實時修改權重(只能為0和1,不支持其它值)，只能靠重啟HAProxy生效。

1.3.1.1?static-rr：基于權重的輪詢調度

按權重輪詢分配請求，權重固定且不支持動態調整。

不支持運行時利用socat進行權重的動態調整(只支持0和1,不支持其它值)。 不支持端服務器慢啟動（慢啟動是指在服務器剛剛啟動上不會把他所應該承擔的訪問壓力全部給它，而是先給一部分，當沒問題后在給一部分）。

其后端主機數量沒有限制，相當于LVS中的 wrr。

1.3.1.2 first

按服務器列表順序分配，優先使用連接數未達上限的服務器。適用于冷熱服務器混合部署（優先啟用新服務器）。

根據服務器在列表中的位置，自上而下進行調度。
其只會當第一臺服務器的連接數達到上限，新請求才會分配給下一臺服務。
其會忽略服務器的權重設置。
不支持用socat進行動態修改權重,可以設置0和1,可以設置其它值但無效。

1.3.2 動態算法

基于后端服務器狀態進行調度適當調整， 新請求將優先調度至當前負載較低的服務器 權重可以在haproxy運行時動態調整無需重啟

1.3.2.1? roundrobin（動態輪詢）

默認加權輪詢算法，支持動態權重調整。適用于無狀態服務（如API網關），確保高性能服務器處理更多請求。

1. 基于權重的輪詢動態調度算法
2. 支持權重的運行時調整，不同于lvs中的rr輪訓模式
3. HAProxy中的roundrobin支持慢啟動(新加的服務器會逐漸增加轉發數)
4. 其每個后端backend中最多支持4095個real server
5. 支持對real server權重動態調整
6. roundrobin為默認調度算法,此算法使用廣泛

1.3.2.2? leastconn（最少連接數）

將請求分配給當前連接數最少的服務器，適合長連接場景（如數據庫、WebSocket）。

leastconn加權的最少連接的動態
支持權重的運行時調整和慢啟動，即:根據當前連接最少的后端服務器而非權重進行優先調度(新客戶端連接)

1.3.3 哈希算法

1.3.3.1 source

源地址hash，基于用戶源地址hash并將請求轉發到后端服務器，后續同一個源地址請求將被轉發至同一個后端web服務器。此方式當后端服務器數據量發生變化時，會導致很多用戶的請求轉發至新的后端服務器，默認為靜態方式，但是可以通過hash-type支持的選項更改這個算法一般是在不插入Cookie的TCP模式下使用，也可給拒絕會話cookie的客戶提供最好的會話粘性，適用于session會話保持但不支持cookie和緩存的場景源地址有兩種轉發客戶端請求到后端服務器的服務器選取計算方式，分別是取模法和一致性hash。

1）map-base 取模法

map-based：取模法，對source地址進行hash計算，再基于服務器總權重的取模，最終結果決定將此請 求轉發至對應的后端服務器。 此方法是靜態的，即不支持在線調整權重，不支持慢啟動，可實現對后端服務器均衡調度 缺點是當服務器的總權重發生變化時，即有服務器上線或下線，都會因總權重發生變化而導致調度結果整體改變。

2）一致性哈希

一致性哈希，當服務器的總權重發生變化時，對調度結果影響是局部的，不會引起大的變動hash（o） mod n 該hash算法是動態的，支持使用 socat等工具進行在線權重調整，支持慢啟動。

1.3.3.2 uri

uri(網絡資源標識)，包括url和urn，基于對用戶請求的URI的左半部分或整個uri做hash，再將hash結果對總權重進行取模后 根據最終結果將請求轉發到后端指定服務器 適用于后端是緩存服務器場景 默認是靜態算法，也可以通過hash-type指定map-based和consistent，來定義使用取模法還是一致性哈希。

1.3.3.3?url_param

url_param對用戶請求的url中的 params 部分中的一個參數key對應的value值作hash計算，并由服務器 總權重相除以后派發至某挑出的服務器,后端搜索同一個數據會被調度到同一個服務器，多用與電商 通常用于追蹤用戶，以確保來自同一個用戶的請求始終發往同一個real server 如果無沒key，將按roundrobin算法

#假設:

url = Bárbaro Cavernario

host = "www.mlw.com"

url_param = "key=value"

2 HAProxy的安裝

2.1 實驗環境

主機	IP
haproxy(nat)	192.168.88.101
RS1(nat)	192.168.88.11
RS2(nat)	192.168.88.12
client（nat）	192.168.88.102

根據實驗環境配置IP、及其主機名，關閉防火墻和selinux、啟動網絡服務和網卡，確保haproxy與RS1,RS2之間網絡互通,并在三臺虛擬機上安裝nginx,然后在RS1,RS2的網頁默認文件中寫入提示語句方便后面測試。

[root@haproxy?~]# dnf install nginx -y [root@haproxy?~]# systemctl disable --now firewalld.service

[root@RS1 ~]# echo RS1 - 192.168.1.51?> /usr/share/nginx/html/index.html [root@RS1 ~] # systemctl enable --now nginx

[root@RS2?~]# echo RS1 - 192.168.1.52?> /usr/share/nginx/html/index.html [root@RS2?~] # systemctl enable --now nginx

2.2 軟件安裝 ?安裝軟件包 ，啟動軟件

?[root@haproxy ~]# dnf install haproxy -y

?[root@haproxy ~]# systemctl start haproxy.service

查看版本

[root@haproxy ~]# haproxy -v HAProxy version 2.4.17-9f97155 2022/05/13 - HAProxy - The Reliable, High Perf. TCP/HTTP Load Balancer Status: long-term supported branch - will stop receiving fixes around Q2 2026. Known bugs: http://www.haproxy.org/bugs/bugs-2.4.17.html Running on: Linux 5.14.0-284.11.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 12 10:45:03 EDT 2023 x86_64?

haproxy軟件基本信息

軟件安裝包： haproxy-2.4.22-3.el9_3.x86_64.rpm

啟動文件： /lib/systemd/system/haproxy.service

主配置目錄： /etc/haproxy/

主配置文件： /etc/haproxy/haproxy.cfg

子配置目錄： /etc/haproxy/conf.d

2.3?ACL示例-基于源地址的訪問控制

[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg

#具體配置如下圖

?

2.4 haproxy的全站加密

1）生成證書

[root@haproxy ~]# mkdir /etc/haproxy/certs/ [root@haproxy ~]# openssl req -newkey rsa:2048 -nodes -sha256 -keyout /etc/haproxy/certs/mlw.org.key -x509 -days 365 -out /etc/haproxy/certs/mlw.org.crt

[root@haproxy ~]# cd /etc/haproxy/certs/

[root@haproxy certs]# cat mlw.org.key mlw.org.crt > mlw.pem

?

2）配置haproxy

[root@haproxy certs]# vim /etc/haproxy/haproxy.cfg [root@haproxy certs]# systemctl restart haproxy.service

?3)測試結果

[root@client ~]# curl -IkL http://192.168.88.11
HTTP/1.1 302 Found
content-length: 0
location: https://192.168.88.11/
cache-control: no-cacheHTTP/1.1 200 OK
server: nginx/1.20.1
date: Mon, 28 Jul 2025 11:58:36 GMT
content-type: text/html
content-length: 21
last-modified: Mon, 28 Jul 2025 11:13:45 GMT
etag: "68875b69-15"
accept-ranges: bytes[root@client ~]# curl -Ik https://www.mlw.org
HTTP/2 301
server: nginx
date: Mon, 28 Jul 2025 04:00:02 GMT
content-type: text/html; charset=UTF-8
location: https://mlw.org/
x-redirect-by: WordPress
expires: Mon, 28 Jul 2025 04:00:02 GMT
cache-control: max-age=0
x-cache-status: MISS
x-rocket-nginx-serving-static: MISS
strict-transport-security: max-age=31536000;
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: no-referrer-when-downgrade
content-security-policy: default-src * 'unsafe-inline' 'unsafe-eval' data: blob:;