一、負載均衡LVS基本介紹
LB集羣的架構和原理很簡單,就是當用戶的請求過來時,會直接分發到Director Server上,然後它把用戶的請求根據設置好的調度算法,智能均衡地分發到後端真正服務器(real server)上。爲了避免不同機器上用戶請求得到的數據不一樣,需要用到了共享存儲,這樣保證所有用戶請求的數據是一樣的。
LVS是 Linux Virtual Server 的簡稱,也就是Linux虛擬服務器。這是一個由章文嵩博士發起的一個開源項目,它的官方網是 http://www.linuxvirtualserver.org 現在 LVS 已經是 Linux 內核標準的一部分。使用 LVS 可以達到的技術目標是:通過 LVS 達到的負載均衡技術和 Linux 操作系統實現一個高性能高可用的 Linux 服務器集羣,它具有良好的可靠性、可擴展性和可操作性。從而以低廉的成本實現最優的性能。LVS 是一個實現負載均衡集羣的開源軟件項目,LVS架構從邏輯上可分爲調度層、Server集羣層和共享存儲。
二、LVS的基本工作原理
-
當用戶向負載均衡調度器(Director Server)發起請求,調度器將請求發往至內核空間
-
PREROUTING鏈首先會接收到用戶請求,判斷目標IP確定是本機IP,將數據包發往INPUT鏈
-
IPVS是工作在INPUT鏈上的,當用戶請求到達INPUT時,IPVS會將用戶請求和自己已定義好的集羣服務進行比對,如果用戶請求的就是定義的集羣服務,那麼此時IPVS會強行修改數據包裏的目標IP地址及端口,並將新的數據包發往POSTROUTING鏈
- POSTROUTING鏈接收數據包後發現目標IP地址剛好是自己的後端服務器,那麼此時通過選路,將數據包最終發送給後端的服務器
三、LVS的組成
LVS 由2部分程序組成,包括 ipvs 和 ipvsadm。
1.ipvs(ip virtual server):一段代碼工作在內核空間,叫ipvs,是真正生效實現調度的代碼。
- ipvsadm:另外一段是工作在用戶空間,叫ipvsadm,負責爲ipvs內核框架編寫規則,定義誰是集羣服務,而誰是後端真實的服務器(Real Server)
四、LVS相關術語
- DS:Director Server。指的是前端負載均衡器節點。
- RS:Real Server。後端真實的工作服務器。
- VIP:向外部直接面向用戶請求,作爲用戶請求的目標的IP地址。
- DIP:Director Server IP,主要用於和內部主機通訊的IP地址。
- RIP:Real Server IP,後端服務器的IP地址。
- CIP:Client IP,訪問客戶端的IP地址。
下邊是三種工作模式的原理和特點總結。
五、LVS/NAT原理和特點
- 重點理解NAT方式的實現原理和數據包的改變。
(a). 當用戶請求到達Director Server,此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP,目標IP爲VIP
(b). PREROUTING檢查發現數據包的目標IP是本機,將數據包送至INPUT鏈
(c). IPVS比對數據包請求的服務是否爲集羣服務,若是,修改數據包的目標IP地址爲後端服務器IP,然後將數據包發至POSTROUTING鏈。 此時報文的源IP爲CIP,目標IP爲RIP
(d). POSTROUTING鏈通過選路,將數據包發送給Real Server
(e). Real Server比對發現目標爲自己的IP,開始構建響應報文發回給Director Server。 此時報文的源IP爲RIP,目標IP爲CIP
(f). Director Server在響應客戶端前,此時會將源IP地址修改爲自己的VIP地址,然後響應給客戶端。 此時報文的源IP爲VIP,目標IP爲CIP
- LVS-NAT模型的特性
RS應該使用私有地址,RS的網關必須指向DIP
DIP和RIP必須在同一個網段內
請求和響應報文都需要經過Director Server,高負載場景中,Director Server易成爲性能瓶頸
支持端口映射
RS可以使用任意操作系統
缺陷:對Director Server壓力會比較大,請求和響應都需經過director server
六、LVS/DR原理和特點
1.重將請求報文的目標MAC地址設定爲挑選出的RS的MAC地址
(a) 當用戶請求到達Director Server,此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP,目標IP爲VIP
(b) PREROUTING檢查發現數據包的目標IP是本機,將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否爲集羣服務,若是,將請求報文中的源MAC地址修改爲DIP的MAC地址,將目標MAC地址修改RIP的MAC地址,然後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改,僅修改了源MAC地址爲DIP的MAC地址,目標MAC地址爲RIP的MAC地址
(d) 由於DS和RS在同一個網絡中,所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址爲RIP的MAC地址,那麼此時數據包將會發至Real Server。
(e) RS發現請求報文的MAC地址是自己的MAC地址,就接收此報文。處理完成之後,將響應報文通過lo接口傳送給eth0網卡然後向外發出。 此時的源IP地址爲VIP,目標IP爲CIP
(f) 響應報文最終送達至客戶端
- LVS-DR模型的特性
特點1:保證前端路由將目標地址爲VIP報文統統發給Director Server,而不是RS
RS可以使用私有地址;也可以是公網地址,如果使用公網地址,此時可以通過互聯網對RIP進行直接訪問
RS跟Director Server必須在同一個物理網絡中
所有的請求報文經由Director Server,但響應報文必須不能進過Director Server
不支持地址轉換,也不支持端口映射
RS可以是大多數常見的操作系統
RS的網關絕不允許指向DIP(因爲我們不允許他經過director)
RS上的lo接口配置VIP的IP地址
缺陷:RS和DS必須在同一機房中
- 特點1的解決方案:
在前端路由器做靜態地址路由綁定,將對於VIP的地址僅路由到Director Server
存在問題:用戶未必有路由操作權限,因爲有可能是運營商提供的,所以這個方法未必實用
arptables:在arp的層次上實現在ARP解析時做防火牆規則,過濾RS響應ARP請求。這是由iptables提供的
修改RS上內核參數(arp_ignore和arp_announce)將RS上的VIP配置在lo接口的別名上,並限制其不能響應對VIP地址解析請求。
七、LVS/Tun原理和特點
在原有的IP報文外再次封裝多一層IP首部,內部IP首部(源地址爲CIP,目標IIP爲VIP),外層IP首部(源地址爲DIP,目標IP爲RIP)
(a) 當用戶請求到達Director Server,此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP,目標IP爲VIP 。
(b) PREROUTING檢查發現數據包的目標IP是本機,將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否爲集羣服務,若是,在請求報文的首部再次封裝一層IP報文,封裝源IP爲爲DIP,目標IP爲RIP。然後發至POSTROUTING鏈。 此時源IP爲DIP,目標IP爲RIP
(d) POSTROUTING鏈根據最新封裝的IP報文,將數據包發至RS(因爲在外層封裝多了一層IP首部,所以可以理解爲此時通過隧道傳輸)。 此時源IP爲DIP,目標IP爲RIP
(e) RS接收到報文後發現是自己的IP地址,就將報文接收下來,拆除掉最外層的IP後,會發現裏面還有一層IP首部,而且目標是自己的lo接口VIP,那麼此時RS開始處理此請求,處理完成之後,通過lo接口送給eth0網卡,然後向外傳遞。 此時的源IP地址爲VIP,目標IP爲CIP
(f) 響應報文最終送達至客戶端
LVS-Tun模型特性
RIP、VIP、DIP全是公網地址
RS的網關不會也不可能指向DIP
所有的請求報文經由Director Server,但響應報文必須不能進過Director Server
不支持端口映射
RS的系統必須支持隧道
其實企業中最常用的是 DR 實現方式,而 NAT 配置上比較簡單和方便,後邊實踐中會總結 DR 和 NAT 具體使用配置過程。
八、LVS的八種調度算法
1.輪叫調度 rr
這種算法是最簡單的,就是按依次循環的方式將請求調度到不同的服務器上,該算法最大的特點就是簡單。輪詢算法假設所有的服務器處理請求的能力都是一樣的,調度器會將所有的請求平均分配給每個真實服務器,不管後端 RS 配置和處理能力,非常均衡地分發下去。
- 加權輪叫 wrr
這種算法比 rr 的算法多了一個權重的概念,可以給 RS 設置權重,權重越高,那麼分發的請求數越多,權重的取值範圍 0 – 100。主要是對rr算法的一種優化和補充, LVS 會考慮每臺服務器的性能,並給每臺服務器添加要給權值,如果服務器A的權值爲1,服務器B的權值爲2,則調度到服務器B的請求會是服務器A的2倍。權值越高的服務器,處理的請求越多。
- 最少鏈接 lc
這個算法會根據後端 RS 的連接數來決定把請求分發給誰,比如 RS1 連接數比 RS2 連接數少,那麼請求就優先發給 RS1
- 加權最少鏈接 wlc
這個算法比 lc 多了一個權重的概念。
- 基於局部性的最少連接調度算法 lblc
這個算法是請求數據包的目標 IP 地址的一種調度算法,該算法先根據請求的目標 IP 地址尋找最近的該目標 IP 地址所有使用的服務器,如果這臺服務器依然可用,並且有能力處理該請求,調度器會盡量選擇相同的服務器,否則會繼續選擇其它可行的服務器
- 複雜的基於局部性最少的連接算法 lblcr
記錄的不是要給目標 IP 與一臺服務器之間的連接記錄,它會維護一個目標 IP 到一組服務器之間的映射關係,防止單點服務器負載過高。
- 目標地址散列調度算法 dh
該算法是根據目標 IP 地址通過散列函數將目標 IP 與服務器建立映射關係,出現服務器不可用或負載過高的情況下,發往該目標 IP 的請求會固定發給該服務器。
- 源地址散列調度算法 sh
與目標地址散列調度算法類似,但它是根據源地址散列算法進行靜態分配固定的服務器資源。
九、實踐LVS的NAT模式
1、實驗環境
三臺服務器,一臺作爲 director,兩臺作爲 real server,director 有一個外網網卡(172.16.254.200) 和一個內網ip(192.168.0.8),兩個 real server 上只有內網 ip (192.168.0.18) 和 (192.168.0.28),並且需要把兩個 real server 的內網網關設置爲 director 的內網 ip(192.168.0.8)
2、安裝和配置
兩個 real server 上都安裝 nginx 服務
yum install -y nginx
Director 上安裝 ipvsadm
yum install -y ipvsadm
Director 上編輯 nat 實現腳本
vim /usr/local/sbin/lvs_nat.sh
編輯寫入如下內容:
#! /bin/bash
director服務器上開啓路由轉發功能:
echo 1 > /proc/sys/net/ipv4/ip_forward
關閉 icmp 的重定向
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
director設置 nat 防火牆
iptables -t nat -F
iptables -t nat -X
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
director設置 ipvsadm
IPVSADM='/sbin/ipvsadm'
$IPVSADM -C
$IPVSADM -A -t 172.16.254.200:80 -s wrr
$IPVSADM -a -t 172.16.254.200:80 -r 192.168.0.18:80 -m -w 1
$IPVSADM -a -t 172.16.254.200:80 -r 192.168.0.28:80 -m -w 1
保存後,在 Director 上直接運行這個腳本就可以完成 lvs/nat 的配置
/bin/bash /usr/local/sbin/lvs_nat.sh
查看ipvsadm設置的規則
ipvsadm -ln
3、測試LVS的效果
通過瀏覽器測試2臺機器上的web內容 http://172.16.254.200 。爲了區分開,我們可以把 nginx 的默認頁修改一下:
在 RS1 上執行
echo "rs1rs1" >/usr/share/nginx/html/index.html
在 RS2 上執行
echo "rs2rs2" >/usr/share/nginx/html/index.html
注意,切記一定要在兩臺 RS 上設置網關的 IP 爲 director 的內網 IP。
十、實踐LVS的DR模式
1、實驗環境
三臺機器:
Director節點: (eth0 192.168.0.8 vip eth0:0 192.168.0.38)
Real server1: (eth0 192.168.0.18 vip lo:0 192.168.0.38)
Real server2: (eth0 192.168.0.28 vip lo:0 192.168.0.38)
2、安裝
兩個 real server 上都安裝 nginx 服務
yum install -y nginx
Director 上安裝 ipvsadm
yum install -y ipvsadm
3、Director 上配置腳本
vim /usr/local/sbin/lvs_dr.sh
#! /bin/bash
echo 1 > /proc/sys/net/ipv4/ip_forward
ipv=/sbin/ipvsadm
vip=192.168.0.38
rs1=192.168.0.18
rs2=192.168.0.28
ifconfig eth0:0 down
ifconfig eth0:0 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip dev eth0:0
$ipv -C
$ipv -A -t $vip:80 -s wrr
$ipv -a -t $vip:80 -r $rs1:80 -g -w 3
$ipv -a -t $vip:80 -r $rs2:80 -g -w 1
執行腳本:
bash /usr/local/sbin/lvs_dr.sh
4、在2臺 rs 上配置腳本:
vim /usr/local/sbin/lvs_dr_rs.sh
#! /bin/bash
vip=192.168.0.38
ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip lo:0
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
rs 上分別執行腳本:
bash /usr/local/sbin/lvs_dr_rs.sh
5、實驗測試
測試方式同上,瀏覽器訪問 http://192.168.0.38
注意:在 DR 模式下,2臺 rs 節點的 gateway 不需要設置成 dir 節點的 IP 。
參考鏈接地址:
http://www.cnblogs.com/lgfeng/archive/2012/10/16/2726308.html
十一、LVS結合keepalive
LVS可以實現負載均衡,但是不能夠進行健康檢查,比如一個rs出現故障,LVS 仍然會把請求轉發給故障的rs服務器,這樣就會導致請求的無效性。keepalive 軟件可以進行健康檢查,而且能同時實現 LVS 的高可用性,解決 LVS 單點故障的問題,其實 keepalive 就是爲 LVS 而生的。
1、實驗環境
4臺節點
Keepalived1 + lvs1(Director1):192.168.0.48
Keepalived2 + lvs2(Director2):192.168.0.58
Real server1:192.168.0.18
Real server2:192.168.0.28
IP: 192.168.0.38
2、安裝系統軟件
Lvs + keepalived的2個節點安裝
yum install ipvsadm keepalived -y
Real server + nginx服務的2個節點安裝
yum install epel-release -y
yum install nginx -y
3、設置配置腳本
Real server節點2臺配置腳本:
vim /usr/local/sbin/lvs_dr_rs.sh
#! /bin/bash
vip=192.168.0.38
ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up
route add -host $vip lo:0
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
2節點rs 上分別執行腳本:
bash /usr/local/sbin/lvs_dr_rs.sh
keepalived節點配置(2節點):
主節點( MASTER )配置文件
vim /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.0.38
}
}
virtual_server 192.168.0.38 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 0
protocol TCP
real_server 192.168.0.18 80 {
weight 1
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.0.28 80 {
weight 1
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
從節點( BACKUP )配置文件
拷貝主節點的配置文件keepalived.conf,然後修改如下內容:
state MASTER -> state BACKUP
priority 100 -> priority 90
keepalived的2個節點執行如下命令,開啓轉發功能:
echo 1 > /proc/sys/net/ipv4/ip_forward
4、啓動keepalive
<strong>先主後從分別啓動keepalive</strong>
service keepalived start
5、驗證結果
實驗1
手動關閉192.168.0.18節點的nginx,service nginx stop 在客戶端上去測試訪問 http://192.168.0.38 結果正常,不會出現訪問18節點,一直訪問的是28節點的內容。
實驗2
手動重新開啓 192.168.0.18 節點的nginx, service nginx start 在客戶端上去測試訪問 http://192.168.0.38 結果正常,按照 rr 調度算法訪問18節點和28節點。
實驗3
測試 keepalived 的HA特性,首先在master上執行命令 ip addr ,可以看到38的vip在master節點上的;這時如果在master上執行 service keepalived stop 命令,這時vip已經不再master上,在slave節點上執行 ip addr 命令可以看到 vip 已經正確漂到slave節點,這時客戶端去訪問 http://192.168.0.38 訪問依然正常,驗證了 keepalived的HA特性
聲明:轉載自https://blog.csdn.net/Ki8Qzvka6Gz4n450m/article/details/79119665