1、負載均衡Load Balance(LB)

概念

負載均衡：是一種服務或基于硬件設備等實現的高可用反向代理技術，負載均衡將特定的業務(web服務、網絡流量等)分擔給指定的一個或多個后端特定的服務器或設備，從而提高了 公司業務的并發處理能力、保證了業務的高可用性、方便了業務后期的水平動態擴展

?阿里云SLB介紹：SLB技術原理淺析-阿里云開發者社區

優勢

• Web服務器的動態水平擴展-->對用戶無感知

• 增加業務并發訪問及處理能力-->解決單服務器瓶頸問題

• 節約公網IP地址-->降低IT支出成本

• 隱藏內部服務器IP-->提高內部服務器安全性

• 配置簡單-->固定格式的配置文件

• 功能豐富-->支持四層和七層，支持動態下線主機

• 性能較強-->并發數萬甚至數十萬

類型：F5、Netscaler（思杰）、Array（華耀）、AD-100（深信服）

四層負載均衡（基于TCP/IP協議棧的傳輸層）

1.通過ip+port決定負載均衡的去向。
2.對流量請求進行NAT處理，轉發至后臺服務器。
3.記錄tcp、udp流量分別是由哪臺服務器處理，后續該請求連接的流量都通過該服務器處理。
4.支持四層的軟件：
? ?lvs：重量級四層負載均衡器。
? ?Nginx：輕量級四層負載均衡器，可緩存。（nginx四層是通過upstream模塊）
? ?Haproxy：模擬四層轉發。

七層負載均衡（應用層）

1.通過虛擬ur|或主機ip進行流量識別，根據應用層信息進行解析，決定是否需要進行負載均衡。
2.代理后臺服務器與客戶端建立連接，如nginx可代理前后端，與前端客戶端tcp連接，與后端服務器建立
tcp連接,
3.支持7層代理的軟件：
? ?Nginx:基于http協議(nginx七層是通過proxy_pass)
? ?Haproxy:七層代理，會話保持、標記、路徑轉移等。

所謂的四到七層負載均衡，就是在對后臺的服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎么樣轉發流量

四層的負載均衡，就是通過發布三層的IP地址（VIP），然后加四層的端口號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至后臺服務器，并記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，后續這個連接的所有流量都同樣轉發到同一臺服務器處理

七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特征，比如同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。

區別：

1.分層位置:四層負載均衡在傳輸層及以下，七層負載均衡在應用層及以下
2.性能 :四層負載均衡架構無需解析報文消息內容，在網絡吞吐量與處理能力上較高:七層可支持解析應用
層報文消息內容，識別URL、Cookie、HTTP header等信息。、
3.原理 :四層負載均衡是基于ip+port;七層是基于虛擬的URL或主機IP等。
4.功能類比:四層負載均衡類似于路由器;七層類似于代理服務器。
5.安全性:四層負載均衡無法識別DDoS攻擊;七層可防御SYN Cookie/Flood攻擊

2、haproxy

haproxy的安裝和服務信息

實驗環境

功能	IP
客戶端	ens160:172.25.254.104
haproxy	ens160:172.25.254.100
RS1	ens160:172.25.254.101
RS2	ens160:172.25.254.102

RS1和RS2的配置（都配成nat模式，如果是僅主機就要都是僅主機，要實現調度，需要都在一個網段中）

下載nginx

dnf install nginx -y

關閉防火墻！！

# 停止防火墻服務
systemctl stop firewalld# 禁止防火墻開機自啟
systemctl disable firewalld# 驗證狀態（確保顯示 inactive）
systemctl status firewalld

將你所想呈現的命令導入nginx的默認發布目錄（為了在驗證時直觀的看見，若成功就會顯示自己導入的命令）

#在RS1上
echo RS1 - 172.25.254.101 > /usr/share/nginx/html/index.html#在RS2上
echo RS2 - 172.25.254.102 > /usr/share/nginx/html/index.html

開啟nginx

systemctl enable --now nginx

在haproxy上進行檢測（haproxy也要記得一個事情——關火墻！）

haproxy上的配置

關火墻?

安裝haproxy并啟動

#安裝
dnf install haproxy -y#啟動
systemctl start haproxy#查看版本
[root@work-node1 ~]# haproxy -v
HAProxy version 2.4.22-f8e3218 2023/02/14 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2026.
Known bugs: http://www.haproxy.org/bugs/bugs-2.4.22.html
Running on: Linux 5.14.0-427.13.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 10 10:29:16 EDT 2024 x86_64

haproxy軟件基本信息

主配置目錄：/etc/haproxy/

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

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

啟動文件：/lib/systemd/system/haproxy.service（初始化腳本）

在啟動文件里面發現將配置寫在子配置目錄是生效的且名字不限

基本配置信息

global：全局配置段
? ? ? ? ? ? ?進程及安全配置相關的參數
? ? ? ? ? ? ?性能調整相關參數
? ? ? ? ? ? ?Debug參數
proxies：代理配置段
? ? ? ? ? ? ?defaults：為frontend, backend, listen提供默認配置
? ? ? ? ? ? ?frontend：前端，相當于nginx中的server {}
? ? ? ? ? ? ?backend：后端，相當于nginx中的upstream {}
? ? ? ? ? ? ?listen：同時擁有前端和后端配置,配置簡單,生產推薦使用

注：最終代理中的參數會把默認中的參數覆蓋，默認中的參數會把全局中的參數覆蓋?

簡單負載均衡示例

vim /etc/haproxy/haproxy.cfg

注釋掉原來的示例??

1、frontend（前端）配合backend（后端）

?

#重啟
[root@work-node1 ~]# systemctl restart haproxy.service#檢查haproxy是否開啟80端口
[root@work-node1 ~]# netstat -antlupe | grep haproxy
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          138625     70945/haproxy

測試

在RealServer中可發現訪問的ip是haproxy的ip地址，通過ip透傳知道是172.25.254.1要求172.25.254.100訪問RealServer

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以守護進程方式運行
????# turn on stats unix socket
???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?????????????????????????????#指定每個客戶端每秒建立連接的最大數量

注：nbproc 2后接了幾個數字就會開幾個work，把主進程分成了多個子進程，和核有關，不是越多越好?

多進程和多線程

多進程：

可以看出是一個父程序（haproxy）后接了兩個子程序，子進程通常負責流量轉發、負載均衡。

多線程（不能和多進程同時使用）：

?[root@work-node1 ~]# cat /proc/19012/status

proxies配置參數說明

參數	類型（都是proxies）	作用
defaults [<name>]	-	默認配置項，針對以下的frontend、backend和listen生效，可以多個 name也可以沒有name
frontend?<name>	-	前端servername，類似于Nginx的一個虛擬主機 server和LVS服務集 群。
backend?<name>	-	后端服務器組，等于nginx的upstream和LVS中的RS服務器
listen?<name>	-	將frontend和backend合并在一起配置，相對于frontend和backend 配置更簡潔，生產常用

注：name字段只能使用大小寫字母，數字，‘-’(dash)，'_‘(underscore)，'.' (dot)和 ':'(colon)，并且嚴格區分大小寫

Proxies配置-defaults：

defaultsmode ? ? ? ? ? ? ? ? ? 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服務器#在apache配置文件中加入:<br>%{XForwarded-For}i#后在webserver中看日志即可看到地址透傳信息option ? ? ? ? ? ? ? ? redispatch       #當server Id對應的服務器掛掉后，強制定向到其他健康的服務器，重新派發option http-keep-alive                 #開啟與客戶端的會話保持retries ? ? ? ? ? ? ? ?3               #連接后端服務器失敗次數
timeout http-request ?    10s             #等待客戶端請求完全被接收和處理的最長時間timeout queue ? ? ? ?  1m              #設置刪除連接和客戶端收到503或服務不可用等提示信息前的等待時間timeout connect ? ? ?  120s            #設置等待服務器連接成功的時間timeout client ? ? ? ? 600s            #設置允許客戶端處于非活動狀態，即既不發
送數據也不接收數據的時間timeout server ? ? ? ? 600s            #設置服務器超時時間，即允許服務器處于既不接收也不發送數據的非活動時間timeout http-keep-alive 60s            #session 會話保持超時時間，此時間段內會轉發到相同的后端服務器timeout check ? ? ? ? ? 10s            #指定后端服務器健康檢查的超時時間maxconn ? ? ? ? ? ? ? ? 3000           default-server inter 1000 weight 3     

Proxies配置-frontend

bind：指定HAProxy的監聽地址，可以是IPV4或IPV6，可以同時監聽多個IP或端口，可同時用于listen字段中
#格式：
bind [<address>]:<port_range> [, ...] [param*]
#注意：如果需要綁定在非本機的IP，需要開啟內核參數：net.ipv4.ip_nonlocal_bind=1

backlog <backlog> #針對所有server配置,當前端服務器的連接數達到上限后的后援隊列長度，注意：不支持backend

Proxies配置-backend

定義一組后端服務器，backend服務器將被frontend進行調用。

注意: 1、backend 的名稱必須唯一,并且必須在listen或frontend中事先定義才可以使用,否則服務無法啟動；

? ? ? ? ? 2、option后面加 httpchk，smtpchk,mysql-check,pgsql-check，ssl-hello-chk方法，可用于實現更多應用層檢測功能。

mode http|tcp ? ? ? #指定負載協議類型,和對應的frontend必須一致
option              #配置選項
server ?            #定義后端real server,必須指定IP和端口

server配置

#針對一個server配置
check             #對指定real進行健康狀態檢查，如果不加此設置，默認不開啟檢查,只有check后面沒有其它配置也可以啟用檢查功能#默認對相應的后端服務器IP和端口,利用TCP連接進行周期性健康性檢查,注意必須指定端口才能實現健康性檢查addr <IP> ? ? ?   #可指定的健康狀態監測IP，可以是專門的數據網段，減少業務網絡的流量
port <num> ? ? ?  #指定的健康狀態監測端口
inter <num> ? ?   #健康狀態檢查間隔時間，默認2000 ms
fall <num> ? ? ?  #后端服務器從線上轉為線下的檢查的連續失效次數，默認為3
rise <num> ? ? ?  #后端服務器從下線恢復上線的檢查的連續有效次數，默認為2
weight <weight>   #默認為1，最大值為256，0(狀態為藍色)表示不參與負載均衡，但仍接受持久連接
backup ? ? ? ?   ?#將后端服務器標記為備份狀態,只在所有非備份主機down機時提供服務，類似Sorry 
Serverdisabled ? ? ?   ?#將后端服務器標記為不可用狀態，即維護狀態，除了持久模式#將不再接受連接,狀態為深黃色,優雅下線,不再接受新用戶的請求redirect prefix http://www.baidu.com/ ? #將請求臨時(302)重定向至其它URL，只適用于http模式maxconn <maxconn> ? ? ? ? ? ? ? ? ? ? ? #當前后端server的最大并發連接數

對于server的配置練習

check，inter <num>，fall <num>，rise <num>：

權重weight <weight>：

web1:172.25.254.101次數增多，web2:172.25.254.102；條件是主機權重高且沒有負載限額

sorry server（當后端服務器都宕機出現問題時的返回頁面）

用httpd充當sorryserver，端口改為8080

vim /etc/httpd/conf/httpd.conf

設定好顯示sorryserver頁面

在haproxy.cfg中配置好sorryserver

backup：指定它的sorryserver

測試：

socat工具

對服務器動態權重和其它狀態可以利用 socat工具進行調整，Socat 是 Linux 下的一個多功能的網絡工具，名字來由是Socket CAT，相當于netCAT的增強版.Socat 的主要特點就是在兩個數據流之間建立雙向通道，且支持眾多協議和鏈接方式。如 IP、TCP、 UDP、IPv6、Socket文件等

#修改配置文件
[root@haproxy ~]# vim /etc/haproxy/haproxy.cfg
stats socket /var/lib/haproxy/stats mode 600 level admin#查看幫助
haproxy ~]# socat -h
haproxy ~]# echo "help" | socat stdio /var/lib/haproxy/stats
The following commands are valid at this level:
help ? ? ? ? ? : this message
prompt ? ? ? ? : toggle interactive mode with prompt
quit ? ? ? ? ? : disconnectenable server : enable a disabled server (use 'set server' instead) ? #啟用服務器
set maxconn server : change a server's maxconn setting
set server ? ? : change a server's state, weight or address ? ? ? ? ? #設置服務器 ? 
get weight ? ? : report a server's current weight? #查看權重
set weight ? ? : change a server's weight (deprecated) #設置權重
show startup-logs : report logs emitted during HAProxy startup
how peers [peers section]: dump some information about all the peers or this 
peers section
set maxconn global : change the per-process maxconn setting
set rate-limit : change a rate limiting value
set severity-output [none|number|string] : set presence of severity level in
feedback information
set timeout ? : change a timeout setting
show env [var] : dump environment variables known to the process
show cli sockets : dump list of cli sockets
show cli level ? : display the level of the current CLI session
show fd [num] : dump list of file descriptors in use

后面的實驗里面出現的問題就是權限的問題，用socat工具改后解決問題

3、haproxy的算法----8種（面試筆試核心）

HAProxy通過固定參數 balance 指明對后端服務器的調度算法
balance參數可以配置在listen或backend選項中。
HAProxy的調度算法分為靜態和動態調度算法。
有些算法可以根據參數在靜態和動態算法中相互轉換。

靜態算法（2種）

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

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

不支持運行時利用socat進行權重的動態調整(只支持0和1,不支持其它值)
不支持端服務器慢啟動
其后端主機數量沒有限制，相當于LVS中的 wrr

譯：慢啟動是指在服務器剛剛啟動上不會把他所應該承擔的訪問壓力全部給它，而是先給一部分，當沒問題后在給一部分

檢測可看出嚴格按照權重值進行輪詢

不支持熱更新

因為權限問題所以在執行 echo "set weight webcluster/web1 1" | sudo socat stdio /var/lib/haproxy/stat會返回Permission denied

修改/etc/haproxy/haproxy.cfg中的命令

# 配置統計套接字，允許管理命令
stats socket /var/lib/haproxy/stats mode 660 user haproxy group haproxy level admin expose-fd listeners

成功！

first?

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

動態算法（2種）

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

roundrobin

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

?

支持熱更新

leastconn

leastconn加權的最少連接的動態
支持權重的運行時調整和慢啟動，即:根據當前連接最少的后端服務器而非權重進行優先調度(新客戶端連接)
比較適合長連接的場景使用，比如：MySQL等場景。

其他算法（4種）

其它算法即可作為靜態算法，又可以通過選項成為動態算法

source

源地址hash，基于用戶源地址hash并將請求轉發到后端服務器，后續同一個源地址請求將被轉發至同一個后端web服務器。

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

有兩種轉發客戶端請求到后端服務器的服務器選取計算方式，分別是取模法和一致性hash

同一個源地址請求將被轉發至同一個后端web服務器

注：如果訪問客戶端時一個家庭，那么所有的家庭的訪問流量都會被定向到一臺服務器，這時source算法的缺陷

map-base取模法

map-based：取模法，對source地址進行hash計算，再基于服務器總權重的取模，最終結果決定將此請求轉發至對應的后端服務器。

此方法是靜態的，即不支持在線調整權重，不支持慢啟動，可實現對后端服務器均衡調度

缺點是當服務器的總權重發生變化時，即有服務器上線或下線，都會因總權重發生變化而導致調度結果整體改變

hash-type 指定的默值為此算法

注：所謂取模運算，就是計算兩個數相除之后的余數，10%7=3, 7%4=3
map-based算法：基于權重取模，hash(source_ip)%所有后端服務器相加的總權重

比如當源hash值時1111，1112，1113，三臺服務器a b c的權重均為1，
即abc的調度標簽分別會被設定為 0 1 2（1111%3=1，1112%3=2，1113%3=0）
1111 ----- > nodeb
1112 ------> nodec
1113 ------> nodea
如果a下線后，權重數量發生變化
1111%2=1，1112%2=0，1113%2=1
1112和1113被調度到的主機都發生變化，這樣會導致會話丟失，一致性哈希可以解決這個問題

一致性hash

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

算法（就近訪問原則）：

1、后端服務器哈希環點keyA=hash(后端服務器虛擬ip)%(2^32)
2、客戶機哈希環點key1=hash(client_ip)%(2^32) ，得到的值在[0---4294967295]之間，
3、將keyA和key1都放在hash環上，將用戶請求調度到離key1最近的keyA對應的后端服務器

hash對象

Hash對象到后端服務器的映射關系：

一致性哈希示意圖

后端服務器在線與離線調度方式

uri（只能在七層做）

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

注：此算法基于應用層，所以只支持 mode http ，不支持 mode tcp

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
整個uri：/<path>;<params>?<query>#<frag>
左半部分：/<path>;<params>

可以在指定的path中訪問

url_param

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

hdr

針對用戶每個http頭部(header)請求中的指定信息做hash，
此處由 name 指定的http首部將會被取出并做hash計算，
然后由服務器總權重取模以后派發至某挑出的服務器，如果無有效值，則會使用默認的輪詢調度。

算法總結

#靜態
static-rr--------->tcp/http ?
first------------->tcp/http ?

#動態
roundrobin-------->tcp/http?
leastconn--------->tcp/http?
random------------>tcp/http

#以下靜態和動態取決于hash_type是否consistent
source------------>tcp/http
Uri--------------->http
url_param--------->http ????
hdr--------------->http

場景：

first #使用較少
static-rr #做了session共享的web集群
roundrobin
random
leastconn #數據庫
source保持
?
#基于客戶端公網IP的會話保持
Uri--------------->http #緩存服務器，CDN服務商，藍汛、百度、阿里云、騰訊
url_param--------->http #可以實現session保持
hdr #基于客戶端請求報文頭部做下一步處理

4、高級功能及配置?

基于cookie的會話保持

cookie value：為當前server指定cookie值，實現基于cookie的會話黏性，相對于基于 source 地址hash?
調度算法對客戶端的粒度更精準，但同時也加大了haproxy負載，目前此模式使用較少， 已經被session共享服務器代替

注：不支持 tcp mode，使用 http mode；意味著只走七層

cookie name [ rewrite | insert | prefix ][ indirect ] [ nocache ][ postonly ] [ 
preserve ][ httponly ] [ secure ][ domain ]* [ maxidle <idle> ][ maxlife ]name：     #cookie 的 key名稱，用于實現持久連接
insert：   #插入新的cookie,默認不插入cookie
indirect： #如果客戶端已經有cookie,則不會再發送cookie信息
nocache：  #當client和hapoxy之間有緩存服務器（如：CDN）時，不允許中間緩存器緩存cookie，#因為這會導致很多經過同一個CDN的請求都發送到同一臺后端服務器

驗證cookie信息

也可在本機上進行測試

HAProxy狀態頁

通過web界面，顯示當前HAProxy的運行狀態

stats enable ?                 #基于默認的參數啟用stats page
stats hide-version ?           #將狀態頁中haproxy版本隱藏
stats refresh <delay>          #設定自動刷新時間間隔，默認不自動刷新
stats uri <prefix>             #自定義stats page uri，默認值：/haproxy?stats 
stats auth <user>:<passwd>     #認證時的賬號和密碼，可定義多個用戶,每行指定一個用戶#默認：no authentication
stats admin { if | unless } <cond> #啟用stats page中的管理功能

啟動狀態頁

?

登錄狀態頁

如圖兩臺web服務器都在正常運行

?#pid為當前pid號，process為當前進程號，nbproc和nbthread為一共多少進程和每個進程多少個線程
pid = 27134 (process #1, nbproc = 1, nbthread = 1)?

#啟動了多長時間
uptime = 0d 0h00m04s?

#系統資源限制：內存/最大打開文件數/
system limits: memmax = unlimited; ulimit-n = 200029?

#最大socket連接數/單進程最大連接數/最大管道數maxpipes
maxsock = 200029; maxconn = 100000; maxpipes = 0?

#當前連接數/當前管道數/當前連接速率
current conns = 2; current pipes = 0/0; conn rate = 2/sec; bit rate = 0.000 kbps?

#運行的任務/當前空閑率
Running tasks: 1/14; idle = 100 %?

active UP： #在線服務器
backup UP： #標記為backup的服務器
active UP, going down： #監測未通過正在進入down過程
backup UP, going down： #備份服務器正在進入down過程
active DOWN, going up： #down的服務器正在進入up過程
backup DOWN, going up： #備份服務器正在進入up過程
active or backup DOWN： #在線的服務器或者是backup的服務器已經轉換成了down狀態
not checked： #標記為不監測的服務器

#active或者backup服務器人為下線的
active or backup DOWN for maintenance (MAINT)
#active或者backup被人為軟下線(人為將weight改成0)
active or backup SOFT STOPPED for maintenance?

IP透傳

web服務器中需要記錄客戶端的真實IP地址，用于做訪問統計、安全防護、行為分析、區域排行等場景。

四層IP透傳

未開透傳，后端realserver沒有顯示訪問信息

nginx配置?

vim /etc/nginx/nginx.conf

?

開啟IP透傳

在haproxy上：

在后端服務器上：

測試

七層IP透傳

當haproxy工作在七層的時候，也可以透傳客戶端真實IP至后端服務器（默認開啟透傳）

配制

在由haproxy發往后端主機的請求報文中添加“X-Forwarded-For"首部，其值為前端客戶端的地址；用于向后端主發送真實的客戶端IP

option forwardfor [ except <network> ] [ header <name> ] [ if-none ]
[ except <network> ]：請求報請來自此處指定的網絡時不予添加此首部，如haproxy自身所在網絡
[ header <name> ]： 使用自定義的首部名稱，而非“X-Forwarded-For"，示例：X-client
[ if-none ] 如果沒有首部才添加首部，如果有使用默認值

ACL

訪問控制列表ACL，Access Control Lists）

是一種基于包過濾的訪問控制技術
它可以根據設定的條件對經過服務器傳輸的數據包進行過濾(條件匹配)即對接收到的報文進行匹配和過濾，基于請求報文頭部中的源地址、源端口、目標地址、目標端口、請求方法、URL、文件后綴等信息內容進行匹配并執行進一步操作，比如允許其通過或丟棄。

?

?測試

[root@work-node1 ~]# curl 172.25.254.100
RS2 - 172.25.254.102
[root@work-node1 ~]# curl www.suyawen.org
RS1 - 172.25.254.101

自定義HAProxy 錯誤界面

 
[root@localhost ~]# mkdir -p /etc/haproxy/errorpage
[root@localhost ~]# vim  /etc/haproxy/errorpage/503.http
HTTP/1.0 503 Service Unavailable
Cache-Control: no-cache
Connection: close
Content-Type: text/html;charset=UTF-8
<html><body><h1>什么動物生氣最安靜</h1>
大猩猩！！
</body></html>
[root@localhost ~]# vim /etc/haproxy/haproxy.cfgerrorfile 503  /etc/haproxy/errorpage/503.http
[root@localhost ~]# systemctl restart haproxy.service

?