十 LVS 負載均衡

時間 2019-12-14

標籤 lvs 負載均衡欄目負載均衡简体版

原文原文鏈接

回顧nginx 反向代理負載均衡html

負載均衡的妙用linux

負載均衡（Load Balance）集羣提供了一種廉價、有效、透明的方法，nginx

來擴展網絡設備和服務器的負載、帶寬、增長吞吐量、增強網絡數據處理能力、web

提升網絡的靈活性和可用性。
單臺計算機沒法承受大規模的併發訪問或數據流量了，算法

此時須要搭建負載均衡集羣把流量分攤到多臺節點設備上分別處理，vim

即減小用戶等待響應的時間又提高了用戶體驗；
7*24小時的服務保證，任意一個或多個有限後端節點設備宕機，不能影響整個業務的運行。windows

爲何要學lvs後端

工做在網絡模型的7層，能夠針對http應用作一些分流的策略，好比針對域名、瀏覽器

目錄結構，Nginx單憑這點可利用的場合就遠多於LVS了。
最新版本的Nginx也支持4層TCP負載，曾經這是LVS比Nginx好的地方。
Nginx對網絡穩定性的依賴很是小，理論上能ping通就就能進行負載功能，緩存

這個也是它的優點之一，相反LVS對網絡穩定性依賴比較大。
Nginx安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日誌打印出來。

LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。

簡單一句話，當併發超過了Nginx上限，就可使用LVS了。

日1000-2000W PV或併發請求1萬如下均可以考慮用Nginx。

大型門戶網站，電商網站須要用到LVS

LVS介紹

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統，

能夠在UNIX/LINUX平臺下實現負載均衡集羣功能。該項目在1998年5月由章文嵩博士組織成立，

是中國國內最先出現的自由軟件項目之一。

官網：http://www.linuxvirtualserver.org/index.html
中文資料
LVS項目介紹        http://www.linuxvirtualserver.org/zh/lvs1.html
LVS集羣的體系結構     http://www.linuxvirtualserver.org/zh/lvs2.html
LVS集羣中的IP負載均衡技術 http://www.linuxvirtualserver.org/zh/lvs3.html
LVS集羣的負載調度     http://www.linuxvirtualserver.org/zh/lvs4.html

LVS內核模塊ip_vs介紹

早在2.2內核時， IPVS就已經之內核補丁的形式出現。
從2.4.23版本開始，IPVS軟件就合併到Linux內核的經常使用版本的內核補丁的集合。
從2.4.24之後IPVS已經成爲Linux官方標準內核的一部分。

LVS無需安裝
安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive
ipvsadm是經過命令行管理，而keepalive讀取配置文件管理
後面咱們會用Shell腳本實現keepalive的功能

LVS相關名詞介紹

LVS集羣的工做模式--DR直接路由模式

DR模式是經過改寫請求報文的目標MAC地址，將請求發給真實服務器的，

而真實服務器將響應後的處理結果直接返回給客戶端用戶。
DR技術可極大地提升集羣系統的伸縮性。

但要求調度器LB與真實服務器RS都有一塊物理網卡連在同一物理網段上，

即必須在同一局域網環境。

經過在調度器LB上修改數據包的目的MAC地址實現轉發。

注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。
請求的報文通過調度器，而RS響應處理後的報文無需通過調度器LB，

所以，併發訪問量大時使用效率很高，比Nginx代理模式強於此處。
因DR模式是經過MAC地址的改寫機制實現轉發的，

所以，全部RS節點和調度器LB只能在同一個局域網中。
須要注意RS節點的VIP的綁定(lo:vip/32)和ARP抑制問題。
強調下：RS節點的默認網關不須要是調度器LB的DIP，

而應該直接是IDC機房分配的上級路由器的IP(這是RS帶有外網IP地址的狀況)，

理論上講，只要RS能夠出網便可，不須要必須配置外網IP，但走本身的網關，那網關就成爲瓶頸了。
因爲DR模式的調度器僅進行了目的MAC地址的改寫，所以，

調度器LB沒法改變請求報文的目的端口。LVS DR模式的辦公室在二層數據鏈路層（MAC），

NAT模式則工做在三層網絡層（IP）和四層傳輸層（端口）。
當前，調度器LB支持幾乎全部UNIX、Linux系統，但不支持windows系統。

真實服務器RS節點能夠是windows系統。
總之，DR模式效率很高，可是配置也較麻煩。

所以，訪問量不是特別大的公司能夠用haproxy/Nginx取代之。

這符合運維的原則：簡單、易用、高效。

日1000-2000W PV或併發請求1萬如下均可以考慮用haproxy/Nginx(LVS的NAT模式)
直接對外的訪問業務，例如web服務作RS節點，RS最好用公網IP地址。

若是不直接對外的業務，例如：MySQL，存儲系統RS節點，最好只用內部IP地址。

回顧--ARP網絡知識

ARP協議,全稱"Address Resolution Protocol",中文名是地址解析協議，

使用ARP協議可實現經過IP地址得到對應主機的物理地址(MAC地址)。
10.0.0.1  ARP  00:50:56:c0:00:08

域名:老男孩教育
IP：匯德商廈403
MAC地址：教室的編號

快遞員給學生送快遞，最多就知道學校的地址（IP），可是不知道學生在哪一個教室。
班主任就是ARP協議，告訴快遞員具體的教室。

ARP協議要求通訊的主機雙方必須在同一個物理網段（即局域網環境）！

爲了提升IP轉換MAC的效率，系統會將解析結果保存下來，這個結果叫作ARP緩存。

Windows查看ARP緩存命令 arp -a
Linux查看ARP緩存命令 arp -n
Linux解析IP對應的MAC地址 arping -c 1 -I eth0 10.0.0.6

ARP緩存表是把雙刃劍
①主機有了arp緩存表，能夠加快ARP的解析速度，減小局域網內廣播風暴。

由於arp是發廣播解析的，頻繁的解析也是消耗帶寬的，尤爲是機器多的時候。
②正是有了arp緩存表，給惡意黑客帶來了攻擊服務器主機的風險，這個就是arp欺騙攻擊。

有同窗惡做劇，假裝班主任告訴快遞員錯誤的教室編號。
③切換路由器，負載均衡器等設備時，可能會致使短時網絡中斷。由於全部的客戶端ARP緩存表沒有更新。

服務器切換ARP問題

當集羣中一臺提供服務的lb01機器宕機後，而後VIP會轉移到備機lb02上，

可是客戶端的ARP緩存表的地址解析仍是宕機的lb01的MAC地址。從而致使，

即便在lb02上添加VIP，也會發生客戶端沒法訪問的狀況。

解決辦法是：當lb01宕機，VIP地址遷移到lb02時，

須要經過arping命令通知全部網絡內機器更新本地的ARP緩存表，從而使得客戶機訪問時從新廣播獲取MAC地址。
這個是本身開發服務器高可用腳本及全部高可用軟件必須考慮到的問題。

ARP廣播進行新的地址解析
arping -I eth0 -c 1 -U VIP
arping -I eth0 -c 1 -U 10.0.0.3

測試命令
ip addr del 10.0.0.13/24 dev eth0

ip addr add 10.0.0.13/24 dev eth0
ip addr show eth0
arping -I eth0 -c 1 -U 10.0.0.13
windows查看arp -a

arp_announce和arp_ignore詳解

lvs在DR模式下須要關閉arp功能

arp_announce
對網絡接口上，本地IP地址的發出的，ARP迴應，做出相應級別的限制:
肯定不一樣程度的限制,宣佈對來自本地源IP地址發出Arp請求的接口
0 - (默認) 在任意網絡接口（eth0,eth1，lo）上的任何本地地址
1 -儘可能避免不在該網絡接口子網段的本地地址作出arp迴應.

當發起ARP請求的源IP地址是被設置應該經由路由達到此網絡接口的時候頗有用.

此時會檢查來訪IP是否爲全部接口上的子網段內ip之一.

若是改來訪IP不屬於各個網絡接口上的子網段內,那麼將採用級別2的方式來進行處理.
2 - 對查詢目標使用最適當的本地地址.在此模式下將忽略這個IP數據包的源地址並嘗試選擇與能與該地址通訊的本地地址.

首要是選擇全部的網絡接口的子網中外出訪問子網中包含該目標IP地址的本地地址.

若是沒有合適的地址被發現,將選擇當前的發送網絡接口或其餘的有可能接受到該ARP迴應的網絡接口來進行發送.

lvs在DR模式下須要關閉arp功能

arp_ignore
定義對目標地址爲本地IP的ARP詢問不一樣的應答模式0
0 - (默認值): 迴應任何網絡接口上對任何本地IP地址的arp查詢請求
1 - 只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求
2 -只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求,且來訪IP必須在該網絡接口的子網段內
3 - 不迴應該網絡界面的arp請求，而只對設置的惟一和鏈接地址作出迴應
4-7 - 保留未使用
8 -不迴應全部（本地地址）的arp查詢

抑制RS端arp前的廣播狀況

抑制RS端arp後廣播狀況

LVS集羣的工做模式總結

DR（Direct Routing）直接路由模式
NAT（Network Address Translation）
TUN（Tunneling）隧道模式
FULLNAT（Full Network Address Translation）

LVS集羣的工做模式--NAT

經過網絡地址轉換，調度器LB重寫請求報文的目標地址，根據預設的調度算法，

將請求分派給後端的真實服務器，真實服務器的響應報文處理以後，返回時必需要經過調度器，

通過調度器時報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。

收費站模式---來去都要通過LB負載均衡器。

LVS集羣的工做模式--隧道模式

採用NAT技術時，因爲請求和響應的報文都必須通過調度器地址重寫，當客戶請求愈來愈多時，

調度器的處理能力將成爲瓶頸，爲了解決這個問題，調度器把請求的報文經過IP隧道(至關於ipip或ipsec )轉發至真實服務器，

而真實服務器將響應處理後直接返回給客戶端用戶，這樣調度器就只處理請求的入站報文。

因爲通常網絡服務應答數據比請求報文大不少，採用 VS/TUN技術後，集羣系統的最大吞吐量能夠提升10倍。
VS/TUN工做流程,它的鏈接調度和管理與VS/NAT中的同樣，只是它的報文轉發方法不一樣。

調度器根據各個服務器的負載狀況，鏈接數多少，動態地選擇一臺服務器，

將原請求的報文封裝在另外一個 IP報文中，再將封裝後的IP報文轉發給選出的真實服務器；

真實服務器收到報文後，先將收到的報文解封得到原來目標地址爲VIP地址的報文,

服務器發現VIP地址被配置在本地的IP隧道設備上(此處要人爲配置)，因此就處理這個請求，

而後根據路由表將響應報文直接返回給客戶。

LVS集羣搭建

環境準備
1.準備4檯安裝好CentOS7.4系統的虛擬機，內存512M。
2.全部虛擬機的防火牆和Selinux關閉
3.主機名及IP地址關係以下：

用以前部署好的服務器，關閉nginx負載
lb03 10.0.0.5
lb04 10.0.0.6
web01 10.0.0.7
web02 10.0.0.8
4.web03和web04安裝Tomcat軟件，並知足下面條件：
curl http://10.0.0.7/頁面底部獲得結果爲web03
curl http://10.0.0.8/頁面底部獲得結果爲web04
5.安裝好wireshark 2.2.2版本 2.2.x版本以上便可

安裝ipvsadm管理工具（只在lb01操做）
# 查看系統的LVS模塊。
lsmod|grep ip_vs

# 默認沒有加載模塊，須要安裝管理工具纔會激活。
yum -y install ipvsadm

# 查看當前LVS狀態，順便激活LVS內核模塊。
ipvsadm

[root@lb01 ~]# lsmod|grep ip_vs
ip_vs 141092 0
nf_conntrack 111302 1 ip_vs
libcrc32c 12644 2 xfs,ip_vs

配置LVS負載均衡服務（只在lb01操做）
步驟1：在eth0網卡綁定VIP地址（ip）
步驟2：清除當前全部LVS規則（-C）
步驟3：設置tcp、tcpfin、udp連接超時時間（--set）
步驟4：添加虛擬服務（-A），調度算法見man ipvsadm
步驟5：將虛擬服務關聯到真實服務上（-a）
步驟6：查看配置結果（-ln）
ip addr add 10.0.0.3/24 dev eth0 label eth0 手動添加。之後經過keepalived就能夠了

# ip a s eth0 查看vip
ipvsadm -C
ipvsadm --set 30 5 60
ipvsadm -A -t 10.0.0.3:80 -s wrr -p 20 ----wrr輪詢算法 -p 會話保持時間默認300秒，這個設置至關於池塘
ipvsadm -a -t 10.0.0.3:80 -r 10.0.0.7:80 -g -w 1 這兩個設置至關於標籤 -g 表示 DR模式
ipvsadm -a -t 10.0.0.3:80 -r 10.0.0.8:80 -g -w 1 -----------------------------
ipvsadm -ln 顯示

web服務器配置（在web01/web02同時操做下面步驟）
步驟1：在lo網卡綁定VIP地址（ip）
步驟2：修改內核參數抑制ARP響應
ip addr add 10.0.0.3/32 dev lo

cat >>/etc/sysctl.conf<<EOF
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
EOF
sysctl -p ---system control 系統控制

使用瀏覽器訪問http://10.0.0.3/
不要在lb01訪問！能夠在lb02測試（未加入LVS「團伙」）

請求時源mac地址是訪問者目標mac是負載

響應時源mac是web服務的目標mac是訪問者

lvsadm的規則是臨時的 web綁定的vip也是臨時的

lvsadm的規則能夠用keepalived解決

web的vip綁定經過修改lo網卡解決

[root@web01 network-scripts]# cp ifcfg-lo ifcfg-lo:1

# vim /etc/sysconfig/network-scripts/ifcfg-lo:1

安裝配置Keepalive

步驟1：在lb03和lb04安裝Keepalive
yum -y install keepalived

步驟2：配置Keepalive， lb03和lb04的配置文件分紅三部分配置
1.global_defs --全局定義
2.vrrp 實例配置 --VIP
3.virtual_server配置 --lvs的配置

第一部分：全局定義

###########lb01###########
global_defs {
router_id LVS_01
}

###########lb02###########
global_defs {
router_id LVS_02
}

第二部分：VIP配置

###########lb01###########
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.0.13/24
}
}

###########lb02###########
vrrp_instance VI_2 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.0.13/24
}
}

第三部分：lvs的配置

virtual_server 10.0.0.3 80 {
delay_loop 6
lb_algo wrr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeput 50
protocol TCP

#等價ipvsadm -A -t 10.0.0.3:80 -s wrr -p 20 ----wrr輪詢算法 -p 會話保持時間默認300秒，這個設置至關於池塘

real_server 10.0.0.7 80 {
weight 1
TCP_CHECK {
connect_timeout 8
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}

real_server 10.0.0.8 80 {
weight 1
TCP_CHECK {
connect_timeout 8
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}

#等價ipvsadm -a -t 10.0.0.3:80 -r 10.0.0.7:80 -g -w 1
ipvsadm -a -t 10.0.0.3:80 -r 10.0.0.8:80 -g -w 1

重啓 keepalived

# /etc/init.d/keepalived restart

清掉以前ipvsadm 規則

ipvsadm -C

重啓 keepalived 再查看規則 ipvsadm -ln獲取到了

ip a 也能看到虛擬 ip 10.0.0.3

測試關掉lb01的 keepalived 虛擬ip沒了查看lb02 獲取到了虛擬ip

==========================================

這部分兩臺負載同樣。

根據配置文件對比前面學過的ipvsadm命令

啓動Keepalive

檢查lb03的vip，ipvsadm -ln是否還在，清除掉。

systemctl start keepalived.service
systemctl status keepalived.service
ip addr show eth0
ipvsadm -ln

能夠測試keepalive高可用，故障轉移(包含VIP及LVS配置)。

web服務器配置

（在web03/web04同時操做下面步驟）
步驟1：在lo網卡綁定VIP地址（ip）
步驟2：修改內核參數抑制ARP響應
ip addr add 10.0.0.13/32 dev lo

cat >>/etc/sysctl.conf<<EOF
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
EOF
sysctl -p

測試Keepalive健康檢查功能

關閉web03

LVS故障排錯

常見LVS負載均衡高可用解決方案

開發相似keepalived的腳本，早期的辦法，如今不推薦使用。
heartbeat+lvs+ldirectord腳本配置方案，複雜不易控制，不推薦使用
RedHat工具piranha，一個web界面配置LVS。
LVS-DR+keepalived方案，老師推薦最優方案，簡單、易用、高效。

問題1：瀏覽器訪問沒有發現輪詢效果
答：LVS的輪詢不像Nginx明顯，可使用多個客戶端訪問（Windows和Linux）
問題2：使用抓包工具，發現進行通訊的是windows的IP和lb03的80端口，可是lb03明明沒有80端口？
答：Windows抓包查看，能夠發現數據包的源MAC地址是web01或web02
Linux:tcpdump -nn port 80; tcpdump -nn -e port 80

問題3：客戶端的操做有什麼含義？

1. RealServer爲何要在lo接口上配置VIP？
答：既然要讓RS可以處理目標地址爲vip的IP包，首先必需要讓RS能接收到這個包。

在lo上配置vip可以完成接收包並將結果返回client。

2.在eth0網卡上配置VIP能夠嗎？

答：不能夠，將VIP設置在eth0網卡上,會影響RS的arp請求,

形成總體LVS集羣arp緩存表紊亂，以致於整個負載均衡集羣都不能正常工做。

3.爲何要抑制ARP響應？先回顧ARP知識及瞭解arp_announce和arp_ignore做用。