解密負載均衡：如何輕松提升業務性能

什么是負載均衡

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

【LVS是最前端的調度器，后端的調度就由haproxy來執行】

為什么用負載均衡

Web服務器動態水平擴展 --> 對用戶完全透明
提升業務并發處理能力 --> 有效解決單服務器性能瓶頸
優化公網IP資源 --> 顯著降低IT運營成本
保護內部服務器IP --> 增強系統安全性
簡易配置 --> 采用標準化配置文件格式
功能全面 --> 同時支持四層和七層協議，支持主機動態移除
高性能表現 --> 輕松應對數萬至數十萬并發請求

負載均衡類型

硬件

美國F5網絡公司官網：F5 | 多云安全和應用交付

Netscaler

美國思杰公司產品頁面：NetScaler: Application Delivery at Scale

Array

華耀官網：北京華耀科技有限公司

AD-1000

深信服官網：深信服 - 讓每個用戶的數字化更簡單、更安全

四層負載均衡

1.通過ip+port決定負載均衡的去向。

2.對流量請求進行NAT處理，轉發至后臺服務器。

3.記錄tcp、udp流量分別是由哪臺服務器處理，后續該請求連接的流量都通過該服務器處理。

【即使客戶端和服務器中夾著一個調度器，客戶端還是回和服務器有一定的網絡通信的】

支持四層的軟件

lvs：重量級四層負載均衡器。

Nginx：輕量級四層負載均衡器，可緩存。（nginx四層是通過upstream模塊）

Haproxy：模擬四層轉發。

七層負載均衡

1.通過虛擬ur|或主機ip進行流量識別，根據應用層信息進行解析，決定是否需要進行負載均衡。

2.代理后臺服務器與客戶端建立連接，如nginx可代理前后端，與前端客戶端tcp連接，與后端服務器建立

tcp連接,

【客戶端與服務器是沒有網絡鏈接的，二者是相互獨立的個體。二者通過中的的調度器調度：客戶端發送報文給調度器，調度器拆包將其調度給合適的服務器；之后，服務器發送報文給調度器，調度器再發給客戶端。速度比四層的LVS慢一點，畢竟不是服務器和客戶端的直接連接發送】

支持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攻擊

haproxy簡介

HAProxy是由法國開發者威利塔羅(Willy Tarreau)于2000年使用C語言開發的開源軟件。

作為一款高性能負載均衡器，它支持TCP和HTTP協議，具備萬級以上的高并發處理能力。主要特性包括：

基于cookie的會話保持
自動故障轉移
正則表達式支持
實時Web狀態統計

資源鏈接：

企業版官網：HAProxy Technologies | Powering the World's Busiest Applications
社區版官網：http://www.haproxy.org
GitHub倉庫：https://github.com/haprox

haproxy的安裝和服務信息

【用戶在通過火墻后，認可用戶可以使用HAPROXY并開始訪問，HAPROXY通過客戶的請求將相應流量調度給后端相應的服務器上；與LVS架構很類似】

實驗環境【關閉防火墻、SELinux】

IP為172.25.254.的是nat模式

IP為192.168.0.的是僅主機模式

功能	IP
客戶端	172.25.254.111
haproxy	172.25.254.100;192.168.0.10
RS1	172.25.254.10
RS2	172.25.254.20

軟件安裝

安裝軟件包

dnf install haproxy -y

查看版本

haproxy -v

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

官方文檔：http://cbonte.github.io/haproxy-dconv/

多進程和線程

多進程和socket文件配置如下，在haproxy中進行：

vim /etc/haproxy/haproxy.cfg

# turn on stats unix socket
stats socket /var/lib/haproxy/haproxy.sock1 mode 600 level admin process 1 
#啟用多個sock文件
stats socket /var/lib/haproxy/haproxy.sock2 mode 600 level admin process 2
nbproc 2 
#啟用多進程
cpu-map 1 0 
#進程和cpu核心綁定防止cpu抖動從而減少系統資源消耗
cpu-map 2 1 
#2 表示第二個進程，1表示第二個cpu核心

systemctl start haproxy.service

查看：

pstree -p | grep haproxy

啟用多線程：

vim /etc/haproxy/haproxy.cfg

nbthread 2 #啟用多線程

systemctl restart haproxy.service

查看：

systemctl restart haproxy.service

多線程對比【如果開啟多線程的話，需要線程與CPU進行綁定，每個線程對應一個自己的CPU，減少不必要的時間損耗】

cat /proc/xxxx(haproxy子進程id)/status

Proxies配置-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服務器
#在apache配置文件中加入:<br>%{XForwarded-For}i
#后在webserver中看日志即可看到地址透傳
信息
option redispatch #當server Id對應的服務器掛掉后，強制定
向到其他健康的服務器，重新派發
option http-keep-alive #開啟與客戶端的會話保持
retries 3 #連接后端服務器失敗次數
3.3.2.3 Proxies配置-frontend
frontend 配置參數：
frontend 配置示例：
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

systemctl restart haproxy.service

Proxies配置-frontend

frontend lee-webserver-80
bind 172.25.254.100:80
mode http
use_backend lee-webserver-80-RS

Proxies配置-backend

backend lee-webserver-80-RS
mode http
server web1 172.25.254.10:80 check inter 3s fall 3 rise 5
server web2 172.25.254.20:80 check inter 3s fall 3 rise 5

systemctl restart haproxy.service

測試：

在RS1,RS2安裝nginx:

dnf install nginx -y

開啟：

systemctl start nginx

在網頁文檔中寫入內容：

#寫在RS1
echo RS1 -172.25.254.10 > /usr/share/nginx/html/index.html
#寫在RS2
echo RS2 -172.25.254.20 > /usr/share/nginx/html/index.html

在客戶端測試：

for N in {1..6};do curl 172.25.254.100;done

Proxies配置-listen 簡化配置

使用listen替換 frontend和backend的配置方式，可以簡化設置，通常只用于TCP協議的應用

 99 listen webserver
100     bind        *:80
101     mode        http
102     balance     static-rr
103     server webserver1 172.25.254.10:80 check inter 3s fall 3 weight 2
104     server webserver2 172.25.254.20:80 check inter 3s fall 3 weight 2

systemctl restart haproxy.service

客戶端測試：

for N in {1..6};do curl 172.25.254.100;done

socat 工具

haproxy安裝socat工具：

dnf install socat -y

修改配置文件：

vim /etc/haproxy/haproxy.cfg
stats socket /var/lib/haproxy/stats mode 600 level adminsystemctl restart haproxy.service

查看幫助：

socat -h
echo "help" | socat stdio /var/lib/haproxy/stats

查看haproxy狀態：

echo "show info" | socat stdio /var/lib/haproxy/stats

查看集群狀態：

echo "show servers state" | socat stdio /var/lib/haproxy/stats

查看集群權重：

 echo get weight webserver/web1 | socat stdio /var/lib/haproxy/stats

設置集群權重：

echo set weight webserver/web1 1 | socat stdio /var/lib/haproxy/stats

后端服務器：

下線：

echo "disable server webserver/web1 " | socat stdio /var/lib/haproxy/stats

上線：

echo "enable server webserver/web1 " | socat stdio /var/lib/haproxy/stats

haproxy的狀態界面

vim /etc/haproxy/haproxy.cfg
...上面內容省略...
listen stats
mode http
bind   *:1616
stats  enable
log    global
stats uri /haproxy-status
stats auth lee:lee

haproxy的算法

客戶端進行測試

while true;do curl 172.25.254.100 ; sleep 0.1;done

【

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

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

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

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

】

靜態算法

靜態算法：按照事先定義好的規則輪詢公平調度，不關心后端服務器的當前負載、連接數和響應速度

等，且無法實時修改權重(只能為0和1,不支持其它值)，只能靠重啟HAProxy生效。

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

不支持運行時利用socat進行權重的動態調整(只支持0和1,不支持其它值)

不支持端服務器慢啟動

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

【

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

問題后在給一部分

】

?first

根據服務器在列表中的位置，自上而下進行調度

其只會當第一臺服務器的連接數達到上限，新請求才會分配給下一臺服務

其會忽略服務器的權重設置

不支持用socat進行動態修改權重,可以設置0和1,可以設置其它值但無效

破壞掉第一臺：

動態算法

【

動態算法

基于后端服務器狀態進行調度適當調整，

新請求將優先調度至當前負載較低的服務器

權重可以在haproxy運行時動態調整無需重啟

】

roundrobin

1. 基于權重的輪詢動態調度算法，

2. 支持權重的運行時調整，不同于lvs中的rr輪訓模式，

3. HAProxy中的roundrobin支持慢啟動(新加的服務器會逐漸增加轉發數)，

4. 其每個后端backend中最多支持4095個real server，

5. 支持對real server權重動態調整，

6. roundrobin為默認調度算法,此算法使用廣泛

動態調整權重

echo "set weight webserver_80/webserver1 2" | socat stdio  /var/lib/haproxy/haproxy.sock

leastconn

leastconn加權的最少連接的動態

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

端連接)

比較適合長連接的場景使用，比如：MySQL等場景。

其他算法

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

source

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

個后端web服務器。此方式當后端服務器數據量發生變化時，會導致很多用戶的請求轉發至新的后端服

務器，默認為靜態方式，但是可以通過hash-type支持的選項更改這個算法一般是在不插入Cookie的TCP

模式下使用，也可給拒絕會話cookie的客戶提供最好的會話粘性，適用于session會話保持但不支持

cookie和緩存的場景源地址有兩種轉發客戶端請求到后端服務器的服務器選取計算方式，分別是取模法

和一致性hash

map-base 取模法

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

求轉發至對應的后端服務器。

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

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

【

?原理一句話總結

用 源地址（source IP） 做哈希，再 對總權重取模，決定轉發到哪臺后端服務器。

?優點

實現簡單，計算快。
請求分布均勻，能做到較好的負載均衡。
無狀態，不依賴歷史連接或會話。

?缺點

靜態調度：一旦后端服務器數量或權重變化，所有哈希結果都會重新分布。
- 也就是說：上線/下線一臺機器，所有連接都會被打亂重排。
不支持：
- 動態權重調整（不能在線改權重）
- 慢啟動（slow-start）
- 會話保持（除非用一致性哈希）

?舉個例子

假設有三臺后端服務器，權重分別為：

A：3
B：2
C：1
總權重 = 6

一個客戶端 IP 哈希后得 17，則：

17 % 6 = 5

根據權重區間劃分：

A：0~2
B：3~4
C：5
→ 請求會打到 C。

如果此時 C 下線，總權重變成 5，那么：

17 % 5 = 2

現在會打到 A，之前打到 C 的所有請求都變了。

?總結一句話

取模哈希法簡單高效，但服務器變化會導致“全量重排”，不適合對穩定性要求高的業務。

?替代方案

一致性哈希調度（consistent hashing）：服務器增減只影響局部請求，避免全量重排。
加權輪詢（WRR）或 最少連接數（LC）：支持動態權重和慢啟動。

】

【

所謂取模運算，就是計算兩個數相除之后的余數，10%7=3, 7%4=3

map-based算法：基于權重取模，hash(source_ip)%所有后端服務器相加的總權重

】

#不支持動態調整權重值
[root@haproxy ~]# echo "set weight webserver_80/webserver1 2" | socat stdio
/var/lib/haproxy/haproxy.sock
Backend is using a static LB algorithm and only accepts weights '0%' and '100%'.
#只能動態上線和下線
[root@haproxy ~]# echo "set weight webserver_80/webserver1 0" | socat stdio
/var/lib/haproxy/haproxy.sock
[root@haproxy ~]# echo "get weight webserver_80/webserver1" | socat stdio
/var/lib/haproxy/haproxy.sock
0 (initial 1)

一致性hash

一致性哈希，當服務器的總權重發生變化時，對調度結果影響是局部的，不會引起大的變動hash（o）

mod n

該hash算法是動態的，支持使用 socat等工具進行在線權重調整，支持慢啟動

【

基本概念

? 傳統取模：hash(o) mod n
服務器數量 n 一變，所有結果重新洗牌 → 命中率雪崩。

? 一致性哈希：把服務器和對象都映射到 0～232 的「Hash 環」上。
對象順時針找最近的服務器。
服務器數量變化時，只影響環上相鄰的一小段 → 局部重映射。

環偏斜（Skew）與虛擬節點

? 問題：真實節點在環上可能分布不均，導致負載不均。
? 解決：每個物理節點拆成 w × k 個「虛擬節點」
HAProxy 中叫 id，Nginx 中叫 weight × consistent 參數。
虛擬節點越多，分布越均勻，但 CPU 略增。

】

uri

基于對用戶請求的URI的左半部分或整個uri做hash，再將hash結果對總權重進行取模后

根據最終結果將請求轉發到后端指定服務器

適用于后端是緩存服務器場景

默認是靜態算法，也可以通過hash-type指定map-based和consistent，來定義使用取模法還是一致性

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

uri 取模法配置示例

uri 一致性hash配置示例

訪問測試：

客戶端測試：

url_param

url_param對用戶請求的url中的 params 部分中的一個參數key對應的value值作hash計算，并由服務器

總權重相除以后派發至某挑出的服務器,后端搜索同一個數據會被調度到同一個服務器，多用與電商

通常用于追蹤用戶，以確保來自同一個用戶的請求始終發往同一個real server

如果無沒key，將按roundrobin算法

url_param取模法配置示例

客戶端訪問測試：

curl 172.25.254.100/index.html?name=aaa

url_param一致性hash配置示例

客戶端測試：

hdr

針對用戶每個http頭部(header)請求中的指定信息做hash，

此處由 name 指定的http首部將會被取出并做hash計算，

然后由服務器總權重取模以后派發至某挑出的服務器，如果無有效值，則會使用默認的輪詢調度。

【

一句話解釋

HAProxy 先看你指定的 HTTP 頭字段（比如 User-Agent、X-Real-IP、X-Api-Key 等），
把這個頭的值做 hash → 再按 服務器總權重取模 → 決定把請求扔給哪臺后端。
? 頭字段存在 → 用 hash 結果挑服務器（靜態映射）。
? 頭字段不存在 → 退化成普通輪詢（round-robin）。

為什么用它

? 同一客戶端或同一類客戶端 始終落到同一臺機器（會話粘滯、緩存親和）。
? 頭字段變化少，hash 結果就穩定，命中率高。
? 支持在線調權重（一致性哈希版本），也支持慢啟動。

】

hdr取模法配置示例

客戶端測試:

curl -v 172.25.254.100

?一致性hash配置示例

客戶端測試：

curl -vA "firefox" 172.25.254.100

算法總結

#靜態
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 #基于客戶端請求報文頭部做下一步處理

高級功能及配置

基于cookie的會話保持

【

cookie value：為當前server指定cookie值，實現基于cookie的會話黏性，相對于基于 source 地址hash

調度算法對客戶端的粒度更精準，但同時也加大了haproxy負載，目前此模式使用較少，已經被session 共享服務器代替

（在響應里給客戶端 種一個特定 cookie，以后客戶端每次帶著這個 cookie 來，HAProxy 就根據 cookie 值把請求 精確地送回上一次那臺后端，實現會話黏著（sticky session）。）

注意：不支持 tcp mode，使用 http mode

】

配置：

驗證cookie信息：

通過命令行驗證：

curl -i 172.25.254.100

指定訪問：

curl -b WEBCOOKIE=web1 172.25.254.100

curl -vb WEBCOOKIE=web1 172.25.254.100

HAProxy狀態頁

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

啟用狀態頁

listen statsmode httpbind  *:1616stats enablelog globalstats uri /statusstats auth xyz:xyz

瀏覽器訪問：

http://172.25.254.100:1616/status

backend server信息

session rate(每秒的連接會話信息):

Errors(錯誤統計信息)：

cur:每秒的當前會話數量 :

Req:錯誤請求量

max:每秒新的最大會話數量

conn:錯誤鏈接量

limit:每秒新的會話限制量

Resp:錯誤響應量

sessions(會話信息):

Warnings(警告統計信息)：

cur:當前會話量

Retr:重新嘗試次數

max:最大會話量

Redis:再次發送次數

limit: 限制會話量

Total:總共會話量

Server(real server信息)：

LBTot:選中一臺服務器所用的總時間

Status:后端機的狀態，包括UP和DOWN

Last：和服務器的持續連接時間

LastChk:持續檢查后端服務器的時間

Wght:權重

Bytes(流量統計)：

Act:活動鏈接數量

In:網絡的字節輸入總量

Bck:備份的服務器數量

Out:網絡的字節輸出總量

Chk:心跳檢測時間

Dwn:后端服務器連接后都是DOWN的數量

Denied(拒絕統計信息)：

Dwntme:總的downtime時間

Req:拒絕請求量

Thrtle:server 狀態

Resp:拒絕回復量

IP透傳

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

四層IP透傳

未開啟透傳的四層代理：

haproxy:

rs1:

正常nginx：

vim /etc/nginx/nginx.conf

在訪問haproxy后查看nginx日志：

rs1：

tail -n 3 /var/log/nginx/access.log

開啟四層透傳：

' "$proxy_protocol_addr"'80 proxy_protocol; #啟用此項，將無法直接訪問此網站，只能通過四層代理

vim /etc/nginx/nginx.conf
systemctl restart nginx

修改haproxy：

查看日志內容：

tail -n 3 /var/log/nginx/access.log

七層IP透傳

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

1 HAProxy配置

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

修改haproxy：

vim /etc/haproxy/haproxy.cfg

web服務器日志格式配置

配置web服務器，記錄負載均衡透傳的客戶端IP地址

【修改haproxy的端口號為8080，避免占用阿帕奇的端口號，導致阿帕奇無法正常啟動】

apache配置：

LogFormat "%{X-Forwarded-For}i %a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

ACL

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

是一種基于包過濾的訪問控制技術

它可以根據設定的條件對經過服務器傳輸的數據包進行過濾(條件匹配)即對接收到的報文進行匹配和過

濾，基于請求報文頭部中的源地址、源端口、目標地址、目標端口、請求方法、URL、文件后綴等信息內

容進行匹配并執行進一步操作，比如允許其通過或丟棄。

ACL示例-域名匹配：

客戶端測試：

基于源地址的訪問控制：

匹配瀏覽器類型：

（瀏覽器和wget都不可以訪問）

基于文件后綴名實現動靜分離

在rs1,rs2上制作頁面，安裝php：

dnf install php -y

vim /usr/share/nginx/html/index.php<?phpphpinfo(); 
?>

創建相關文件：

[root@rs1 ~]# mkdir /usr/share/nginx/html/static
[root@rs1 ~]# echo static 192.168.0.101 > /usr/share/nginx/html/static/index.html

測試：

自定義HAProxy 錯誤界面

[root@haproxy ~]# mkdir /haproxy/errorpages/ -p
[root@haproxy ~]# cp /usr/share/haproxy/503.http /haproxy/errorpages/503page.http
[root@haproxy ~]# vim /haproxy/errorpages/503page.http

客戶端測試：

基于http重定向錯誤頁面

瀏覽器測試：

HAProxy 四層負載

listen mysql_port
bind :3306
mode tcp
balance leastconn
server mysql1 192.168.0.101:3306 check
server mysql2 192.168.0.102:3306 check

在后端服務器rs1,rs2安裝和配置mariadb服務：

yum install mariadb-server -yvim /etc/my.cnf[mysqld]
server-id=1 #在另一臺主機為[mysqld]
server-id=2 #在另一臺主機為

mysql -e "grant all on *.* to lee@'%' identified by 'lee';"

客戶端測試：

mysql -ulee -plee -h 172.25.254.100 -e "show variables like
'hostname'"

mysql -ulee -plee -h172.25.254.100 -e "select @@server_id"

HAProxy https 實現

haproxy：

制作證書：

mkdir /etc/haproxy/certs/

openssl req  -newkey rsa:2048 -nodes  -sha256 -keyout /etc/haproxy/certs/timinglee.org.key -x509 -days 365 -out /etc/haproxy/certs/timinglee.org.crt

cat /etc/haproxy/certs/timinglee.org.crt \/etc/haproxy/certs/timinglee.org.key \> /etc/haproxy/timinglee.org.pem

frontend webserver
bind *:80
redirect scheme https if !{ ssl_fc }
mode http
use_backend webcluster
frontend webserver-https
bind *:443 ssl crt /etc/haproxy/timinglee.org.pem
mode http
use_backend webcluster
backend webcluster
mode http
balance roundrobin
server web1 172.25.254.10:80 check inter 3s fall 3 rise 5
server web2 172.25.254.20:80 check inter 3s fall 3 rise 5