LVS負載均衡集羣
回顧-Nginx反向代理型負載
負載均衡（load balance）集羣，提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載、帶寬、增長吞吐量、增強網絡數據處理能力、提升網絡的靈活性和可用性。html
- 單臺計算機沒法承受大規模的併發訪問，或者數據流量。此時須要搭建負載均衡集羣把流量分攤到多臺節點設備上分別處理，即減小用戶的等待響應的時間，又提高了用戶體驗；
- 7*24小時的服務保證，任意一個或者多個有限後端節點宕機，不能影響整個業務的運行。
爲何還要學習LVS
- 工做在網絡模型的7層，能夠針對http應用作一些分流的策略，好比針對域名、目錄結構，Nginx單憑這點可利用的場合就遠多於LVS了。
- 最新版本的Nginx也支持4層TCP負載，曾經這是LVS比Nginx好的地方。
- Nginx對網路穩定性的依賴很是小，理論上能ping通就能進行負載均衡，這個也是它的優點之一，相反LVS對網絡穩定性依賴比較大。
- Nginx的安裝配置比較簡單，測試起來比較方便，它基本能把錯誤用日誌打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。
懵逼了，Nginx這麼好用，爲何還要用LVS。linux
簡單一句話，當併發量超過Nginx上線，就可使用LVS了。nginx
日1000-2000W PV 或者併發請求10000一下均可以考慮用Nginx。web
大型門戶網站，點上網站須要用到LVS。算法
併發訪問量達到幾十萬用LVSvim
LVS介紹
LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統，能夠在UNIX/LINUX平臺下實現負載均衡集羣功能。該項目在1998年5月由章文嵩博士組織成立，是中國國內最先出現的自由軟件項目之一。
windows
官網：http://www.linuxvirtualserver.org/index.html後端
# 中文資料 ，網址裏面加zh 就是中文的了 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介紹
LVS相關名詞解釋
CIP：客戶端主機IP地址瀏覽器
VIP：負載均衡主設備緩存
DIP：負載服務器的IPDIZHI
RIP：真實web服務器地址
LVS集羣的工做模式-四種
- DR模式，用的最多的，direct routing 直接路由模式
- NAT模式 , Network Address Translation
- TUN，隧道模式， Tunneling
- FULL NAT模式，章教授到淘寶以後開發的 ，Full Network Address Translation
DR直接路由模式
DR模式是經過改寫請求報文的目標MAC地址，將請求發給真實服務器的，而真實服務器將響應後的處理結果直接返回給客戶端用戶。
DR技術可極大地提升集羣系統的伸縮性。但要求調度器LB與真實服務器RS都有一塊物理網卡連在同一物理網段上，即必須在同一局域網環境。
DR模式主要實現過程：
- LB修改Mac地址爲RS的Mac地址
- RS的L0（本地網卡）綁定VIP地址
- RS抑制ARP解析
- 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地址。
3個問題-關於RealServer
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做用。
不抑制RS端arp前的廣播狀況圖示
只有抑制了，才能只有LB去響應
NAT模式
收費站模式 --- 來去都要通過LB負載均衡器。
經過網絡地址轉換，調度器LB重寫請求報文的目標地址，
根據預設的調度算法，將請求分派給後端的真實服務器，
真實服務器的響應報文處理以後，返回時必需要經過調度器，
通過調度器時報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。
TUN-隧道模式
採用NAT技術時，
因爲請求和響應的報文都必須通過調度器地址重寫，當客戶請求愈來愈多時，調度器的處理能力將成爲瓶頸，
爲了解決這個問題，調度器把請求的報文經過IP隧道(至關於ipip或ipsec )轉發至真實服務器，
而真實服務器將響應處理後直接返回給客戶端用戶，這樣調度器就只處理請求的入站報文。
因爲通常網絡服務應答數據比請求報文大不少，採用 VS/TUN技術後，集羣系統的最大吞吐量能夠提升10倍。
VS/TUN工做流程,
它的鏈接調度和管理與VS/NAT中的同樣，只是它的報文轉發方法不一樣。
調度器根據各個服務器的負載狀況，鏈接數多少，動態地選擇一臺服務器，
將原請求的報文封裝在另外一個 IP報文中，再將封裝後的IP報文轉發給選出的真實服務器；
真實服務器收到報文後，先將收到的報文解封得到原來目標地址爲VIP地址的報文, 服務器發現VIP地址被配置在本地的IP隧道設備上(此處要人爲配置)，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。
FULLNAT模式
類比地鐵站多個閘機。
LVS的DR和NAT模式要求RS和LVS在同一個vlan中，致使部署成本太高； TUNNEL模式雖然能夠跨vlan，但RealServer上須要部署ipip隧道模塊等，網絡拓撲上須要連通外網，較複雜，不易運維。
爲了解決上述問題，
開發出FULLNAT，該模式和NAT模式的區別是：數據包進入時，除了作DNAT，還作SNAT（用戶ip->內網ip），
從而實現LVS-RealServer間能夠跨vlan通信，RealServer只須要鏈接到內網。
ARP網絡知識
ARP協議，全程「Address Resolution Protocol」，中文名是地址解析協議，使用ARP協議可實現經過IP地址得到對應主機的物理地址（MAC地址）。
10.0.0.1 ------>ARP ------> 00:50:55：AV：c4:09
ARP是第三層協議，工做在第二層
一個比喻：
快遞員給學生送快遞，最多就知道學校地址（IP），可是不知道學生在那個教室，坐在哪一個位置，班主任就是ARP歇息，告訴快遞員具體的教室。
ARP協議要求通訊的主機雙方必須在同一個物理網段（即局域網環境）！
經過抓包軟件WireShark看一下，抓包VM8網卡搜arp，回車
在Linux裏面ping 10.0.0.5
查看抓包過程
刪除緩存後，從新廣播
爲了提升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迴應的網絡接口來進行發送.
arp_ignore
定義對目標地址爲本地IP的ARP詢問不一樣的應答模式0
0 - (默認值): 迴應任何網絡接口上對任何本地IP地址的arp查詢請求 1 - 只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求 2 - 只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求,且來訪IP必須在該網絡接口的子網段內 3 - 不迴應該網絡界面的arp請求，而只對設置的惟一和鏈接地址作出迴應 4-7 - 保留未使用 8 - 不迴應全部（本地地址）的arp查詢
LVS集羣搭建-DR模式
環境準備
1.準備4檯安裝好CentOS7.4系統的虛擬機，內存512M。 2.全部虛擬機的防火牆和Selinux關閉 3.主機名及IP地址關係以下： lb03 10.0.0.15 （將以前部署的keeplived和nginx關掉） lb04 10.0.0.16 （將以前部署的keeplived和nginx關掉） web03 10.0.0.17 web04 10.0.0.18 4.web03和web04安裝Tomcat軟件，並知足下面條件： curl http://10.0.0.17/頁面底部獲得結果爲web03 10.0.0.17 curl http://10.0.0.18/頁面底部獲得結果爲web04 10.0.0.18 5.安裝好wireshark 2.2.2版本 2.2.x版本以上便可
安裝ipvsadm（只在lb03）
# 查看系統的LVS模塊。 lsmod|grep ip_vs # 默認沒有加載模塊，須要安裝管理工具纔會激活。 yum -y install ipvsadm keeplivaed -y # 查看當前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負載均衡服務+ipvsadm（只作lb03）
步驟1：在eth0網卡綁定VIP地址（ip） 步驟2：清除當前全部LVS規則（-C） 步驟3：設置tcp、tcpfin、udp連接超時時間（--set） 步驟4：添加虛擬服務（-A），調度算法見man ipvsadm 步驟5：將虛擬服務關聯到真實服務RS上（-a） 步驟6：查看配置結果（-ln） ip addr add 10.0.0.13/24 dev eth0 label eth0:1 ipvsadm -C ipvsadm --set 30 5 60 ipvsadm -A -t 10.0.0.13:80 -s wrr -p 20 wrr是加權輪詢，-p是會話保持時間，至關於建立了一個池塘 ipvsadm -a -t 10.0.0.13:80 -r 10.0.0.17:80 -g -w 1 ipvsadm -a -t 10.0.0.13:80 -r 10.0.0.18:80 -g -w 1 ipvsadm -ln
-g 表示DR模式，默認的
已配置好，能夠轉發了，能夠做MAC地址的轉換了
Web服務器配置（web0三、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
可使用了！
使用瀏覽器訪問http://10.0.0.13/，同時使用wireshark抓取數據包http
不要在lb03本地訪問測試！能夠在lb04測試（未加入LVS「團伙」）
LVS不像nginx那樣1:1很強烈的規律，只有訪問頻率很高的時候，近似的1:1
將配置永久保存
添加的內核參數，是永久的
可是添加的規則是臨時的，即ipvsadm -ln 的規則（稍後用keepalived好一些）
咱們添加的VIP，lo網卡上綁定的IP是臨時的
解決：
一、複製lo網卡的配置文件爲ifcfg-lo:1 2、修改配置，名字、IP、子網掩碼，以下，而後保存 3、重啓網卡 [root@web03 ~]# cd /etc/sysconfig/network-scripts/ [root@web03 network-scripts]# cp ifcfg-lo ifcfg-lo:1 [root@web03 network-scripts]# vim ifcfg-lo:1 DEVICE=lo:1 IPADDR=10.0.0.13 # If you're having problems with gated making 127.0.0.0/8 a martian, # you can change this to something else (255.255.255.255, for example) NETMASK=255.255.255.255 ONBOOT=yes NAME=lo:1 [root@web03 network-scripts]# systemctl restart network.service
三個問題
問題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：客戶端的操做有什麼含義？
配置LVS負載均衡+keepalied(高可用)
接下來的實驗又是一個新的開始，配置負載均衡不須要ipvsadm這個工具，由於keepalived原本就是另一個自動管理工具。
安裝keepalive
步驟1：在lb03和lb04安裝Keepalive yum -y install keepalived 步驟2：配置Keepalive， lb03和lb04的配置文件分紅三部分配置(man keepalived.conf） 1.global_defs ------>全局定義 2.vrrp 實例配置 ------>VIP 3.virtual_server配置 --->lvs的配置
第一部分-全局定義
###########lb03########### 至關於 global_defs { router_id LVS_03 } ###########lb04########### global_defs { router_id LVS_04 }
router_id 每個keeplive的配置都有的獨一無二的，至關於身份證號
第二部分-VIP配置
###########lb03########### 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 { # VIP 10.0.0.13/24 } } ###########lb04########### vrrp_instance VI_1 { 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配置,管理和配置lvs
這部分兩臺負載同樣。根據配置文件對比前面學過的ipvsadm命令
virtual_server 10.0.0.13 80 { # 至關於 ipvsadm -A -t 10.0.0.13:80 delay_loop 6 # 循環次數 lb_algo wrr # 輪詢的模式 lb_bind DR # 模式 nat_mask 255.255.255.0 persistence_timeout 50 # 會話保持的時間 也是-A中的 protocol TCP real_server 10.0.0.17 80 { # 至關於ipvs -a weight 1 TCP_CHECK { # 端口的檢測，如端口掛掉怎麼作，還有其餘如HTTP_CHECK等 connect_timeout 8 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 10.0.0.18 80 { weight 1 TCP_CHECK { connect_timeout 8 nb_get_retry 3 delay_before_retry 3 connect_port 80 } }
那麼主備有什麼區別呢？推薦使用beyongdCompare軟件對比
- router_id 路由名稱不同
- state 主備標誌不同
- priority 表示主備的權重值不同
vim /etc/keepalived/keepalived.conf 修改配置文件
重啓兩臺主機的keepalived 服務
先檢查lb03的vip，ipvsadm -ln是否還在，清除掉。
ipvsadm -ln
ipvsadm -C /etc/init.d/keepalived restart
ipvsadm -ln 檢查 配置規則，又從新有了
# Centos7的操做 systemctl start keepalived.service systemctl status keepalived.service ip addr show eth0 ipvsadm -ln 能夠測試keepalive高可用，故障轉移(包含VIP及LVS配置)。
測試keepalive的高可用功能
關閉lb01的keepalived服務，而後查看lb02的ip，檢查VIP
測試Keepalive的健康檢查功能
關閉web03
做業：部署NAT模式
部署NAT模式
常見的LVS負載均衡高可用解決方案
- 開發相似keepalived的腳本，早期的辦法，如今不推薦使用。
- heartbeat+lvs+ldirectord腳本配置方案，複雜不易控制，不推薦使用
- RedHat工具piranha，一個web界面配置LVS。
- LVS-DR+keepalived方案，老師推薦最優方案，簡單、易用、高效。
LVS故障排除
做業
完成Keepalived多實例
相關文章
- 1. LVS負載均衡集羣
- 2. LVS負載均衡羣集
- 3. Lvs負載均衡羣集
- 4. LVS-負載均衡集羣
- 5. 負載均衡集羣LVS
- 6. 【LVS】負載均衡集羣
- 7. lvs負載均衡集羣
- 8. LVS集羣-DR負載均衡集羣
- 9. 負載均衡集羣-LVS應用
- 10. LVS負載均衡羣集——DR模式
- 更多相關文章...
- • Swarm 集羣管理 - Docker教程
- • ionic 加載動作 - ionic 教程
- • ☆技術問答集錦（13）Java Instrument原理
- • NewSQL-TiDB相關
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. LVS負載均衡集羣
- 2. LVS負載均衡羣集
- 3. Lvs負載均衡羣集
- 4. LVS-負載均衡集羣
- 5. 負載均衡集羣LVS
- 6. 【LVS】負載均衡集羣
- 7. lvs負載均衡集羣
- 8. LVS集羣-DR負載均衡集羣
- 9. 負載均衡集羣-LVS應用
- 10. LVS負載均衡羣集——DR模式