高併發場景 LVS 安裝及keepalived的應用
1.1 負載均衡介紹
1.1.1 負載均衡的妙用
負載均衡（Load Balance）集羣提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載、帶寬、增長吞吐量、增強網絡數據處理能力、提升網絡的靈活性和可用性。html
ü 單臺計算機沒法承受大規模的併發訪問或數據流量了，此時須要搭建負載均衡集羣把流量分攤到多臺節點設備上分別處理，即減小用戶等待響應的時間又提高了用戶體驗；前端
ü 7*24小時的服務保證，任意一個或多個有限後端節點設備宕機，不能影響整個業務的運行。node
1.1.2 爲何要用lvs
n 工做在網絡模型的7層，能夠針對http應用作一些分流的策略，好比針對域名、目錄結構，Nginx單憑這點可利用的場合就遠多於LVS了。python
n 最新版本的Nginx也支持4層TCP負載，曾經這是LVS比Nginx好的地方。linux
n Nginx對網絡穩定性的依賴很是小，理論上能ping通就就能進行負載功能，這個也是它的優點之一，相反LVS對網絡穩定性依賴比較大。web
n Nginx安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日誌打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。算法
那爲何要用lvs呢？windows
ü 簡單一句話，當併發超過了Nginx上限，就可使用LVS了。後端
ü 日1000-2000W PV或併發請求1萬如下均可以考慮用Nginx。瀏覽器
ü 大型門戶網站，電商網站須要用到LVS。
1.2 LVS介紹
LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統，能夠在UNIX/LINUX平臺下實現負載均衡集羣功能。該項目在1998年5月由章文嵩博士組織成立，是中國國內最先出現的自由軟件項目之一。
1.2.1 相關參考資料
LVS官網：http://www.linuxvirtualserver.org/index.html
相關中文資料
|
1
2
3
4
|
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
|
1.2.2 LVS內核模塊ip_vs介紹
早在2.2內核時， IPVS就已經之內核補丁的形式出現。
從2.4.23版本開始，IPVS軟件就合併到Linux內核的經常使用版本的內核補丁的集合。
從2.4.24之後IPVS已經成爲Linux官方標準內核的一部分。
ü LVS無需安裝
ü 安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive
ü ipvsadm是經過命令行管理，而keepalive讀取配置文件管理
ü 後面咱們會用Shell腳本實現keepalive的功能
1.3 LVS集羣搭建
1.3.1 集羣環境說明
| 主機名 |
IP地址 |
軟件 |
系統版本 |
| lb03 |
10.0.0.10 |
lvs keepalived |
CentOS Linux release 7.4.1708 |
| lb04 |
10.0.0.11 |
lvs keepalived |
CentOS Linux release 7.4.1708 |
| web03 |
10.0.0.1 |
tomcat |
CentOS Linux release 7.4.1708 |
| web04 |
10.0.0.2 |
tomcat |
CentOS Linux release 7.4.1708
|
主機說明
[root@lb03 ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@lb03 ~]# uname -a
Linux lb03 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@lb03 ~]# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)
[root@lb03 ~]# getenforce
Disabled
web環境說明
主機說明
[root@lb03 ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@lb03 ~]# uname -a
Linux lb03 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@lb03 ~]# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)
[root@lb03 ~]# getenforce
Disabled
web環境說明
[root@lb03 ~]# curl 10.0.0.1 node1 [root@lb03 ~]# curl 10.0.0.2 node2
1.3.2 安裝ipvsadm管理工具
安裝管理工具
yum -y install ipvsadm
查看當前LVS狀態，順便激活LVS內核模塊。
ipvsadm
查看系統的LVS模塊。
[root@lb03 ~]# lsmod|grep ip_vs ip_vs_wrr 12697 1 ip_vs 141092 3 ip_vs_wrr nf_conntrack 133387 1 ip_vs libcrc32c 12644 3 xfs,ip_vs,nf_conntrack
1.3.3 LVS集羣搭建
配置LVS負載均衡服務（在lb03操做）
步驟1：在eth0網卡綁定VIP地址（ip）
步驟2：清除當前全部LVS規則（-C）
步驟3：設置tcp、tcpfin、udp連接超時時間（--set）
步驟4：添加虛擬服務（-A），-t指定虛擬服務的IP端口，-s 指定調度算法 調度算法見man ipvsadm， rr wrr 權重輪詢 -p 指定超時時間
步驟5：將虛擬服務關聯到真實服務上（-a） -r指定真實服務的IP端口 -g LVS的模式 DR模式 -w 指定權重
步驟6：查看配置結果（-ln）
命令集：
ip addr add 10.0.0.100/24 dev eth0 ipvsadm -C ipvsadm --set 30 5 60 ipvsadm -A -t 10.0.0.100:80 -s wrr -p 20 ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.1:80 -g -w 1 ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.2:80 -g -w 1 ipvsadm -ln
service ipvsadm save
檢查結果：
[root@lb03 ~]# ipvsadm -ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.0.0.100:80 wrr persistent 20 -> 10.0.0.1:80 Route 1 0 0 -> 10.0.0.2:80 Route 1 0 0
ipvsadm參數說明：(更多參照 man ipvsadm)
| 參數 (短格式) |
參數 (長格式) |
參數說明 |
| -A |
--add-service |
在內核的虛擬服務器表中添加一條新的虛擬服務器記錄。也就是增長一臺新的虛擬服務器。 |
| -E |
--edit-service |
編輯內核虛擬服務器表中的一條虛擬服務器記錄。 |
| -D |
--delete-service |
刪除內核虛擬服務器表中的一條虛擬服務器記錄。 |
| -C |
--clear |
清除內核虛擬服務器表中的全部記錄。 |
| -R |
--restore |
恢復虛擬服務器規則 |
| -S |
--save |
保存虛擬服務器規則，輸出爲-R 選項可讀的格式 |
| -a |
--add-server |
在內核虛擬服務器表的一條記錄裏添加一條新的真實服務器記錄。也就是在一個虛擬服務器中增長一臺新的真實服務器 |
| -e |
--edit-server |
編輯一條虛擬服務器記錄中的某條真實服務器記錄 |
| -d |
--delete-server |
刪除一條虛擬服務器記錄中的某條真實服務器記錄 |
| -L|-l |
--list |
顯示內核虛擬服務器表 |
| -Z |
--zero |
虛擬服務表計數器清零（清空當前的鏈接數量等） |
| - |
--set tcp tcpfin udp |
設置鏈接超時值 |
| - |
--start-daemon |
啓動同步守護進程。他後面能夠是master 或backup，用來講明LVS Router 是master 或是backup。在這個功能上也能夠採用keepalived 的VRRP 功能。 |
| - |
--stop-daemon |
中止同步守護進程 |
| -h |
--help |
顯示幫助信息 |
| -t |
--tcp-service service-address [vip:port] or [real-server-ip:port] |
說明虛擬服務器提供的是tcp 的服務 |
| -u |
--udp-service service-address [vip:port] or [real-server-ip:port] |
說明虛擬服務器提供的是udp 的服務 |
| -f |
--fwmark-service fwmark |
說明是通過iptables 標記過的服務類型。 |
| -s |
--scheduler scheduler |
使用的調度算法，有這樣幾個選項 rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq 默認的調度算法是： wlc |
| -p |
--persistent [timeout] |
持久穩固的服務。這個選項的意思是來自同一個客戶的屢次請求，將被同一臺真實的服務器處理。timeout 的默認值爲300秒。 |
| -M |
--netmask netmask |
persistent granularity mask |
| -r |
--real-server server-address |
真實的服務器[Real-Server:port] |
| -g |
--gatewaying |
指定LVS 的工做模式爲直接路由模式（也是LVS 默認的模式） |
| -i |
--ipip |
指定LVS 的工做模式爲隧道模式 |
| -m |
--masquerading |
指定LVS 的工做模式爲NAT 模式 |
| -w |
--weight weight |
真實服務器的權值 |
| - |
--mcast-interface |
interface 指定組播的同步接口 |
| -c |
--connection |
顯示LVS 目前的鏈接 如：ipvsadm -L -c |
| - |
--timeout |
顯示tcp tcpfin udp 的timeout 值 如：ipvsadm -L --timeout |
| - |
--daemon |
顯示同步守護進程狀態 |
| - |
--stats |
顯示統計信息 |
| - |
--rate |
顯示速率信息 |
| - |
--sort |
對虛擬服務器和真實服務器排序輸出 |
| - |
--numeric -n |
輸出IP 地址和端口的數字形式 |
1.3.4 在web瀏覽器配置操做
步驟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
至此LVS集羣配置完畢！
1.3.5 進行訪問測試
命令行測試：
1.4 負載均衡（LVS）相關名詞
術語說明：
DS：Director Server。指的是前端負載均衡器節點。 RS：Real Server。後端真實的工做服務器。 VIP：向外部直接面向用戶請求，做爲用戶請求的目標的IP地址。 DIP：Director Server IP，主要用於和內部主機通信的IP地址。 RIP：Real Server IP，後端服務器的IP地址。 CIP：Client IP，訪問客戶端的IP地址。
1.4.1 LVS集羣的工做模式--DR直接路由模式
DR模式是經過改寫請求報文的目標MAC地址，將請求發給真實服務器的，而真實服務器將響應後的處理結果直接返回給客戶端用戶。
DR技術可極大地提升集羣系統的伸縮性。但要求調度器LB與真實服務器RS都有一塊物理網卡連在同一物理網段上，即必須在同一局域網環境。
DR直接路由模式說明：
|
1
2
3
4
5
6
7
8
|
a)經過在調度器LB上修改數據包的目的MAC地址實現轉發。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。
b)請求的報文通過調度器，而RS響應處理後的報文無需通過調度器LB，所以，併發訪問量大時使用效率很高，比Nginx代理模式強於此處。
c)因DR模式是經過MAC地址的改寫機制實現轉發的，所以，全部RS節點和調度器LB只能在同一個局域網中。須要注意RS節點的VIP的綁定(lo:vip
/
32
)和ARP抑制問題。
d)強調下：RS節點的默認網關不須要是調度器LB的DIP，而應該直接是IDC機房分配的上級路由器的IP(這是RS帶有外網IP地址的狀況)，理論上講，只要RS能夠出網便可，不須要必須配置外網IP，但走本身的網關，那網關就成爲瓶頸了。
e)因爲DR模式的調度器僅進行了目的MAC地址的改寫，所以，調度器LB沒法改變請求報文的目的端口。LVS DR模式的辦公室在二層數據鏈路層（MAC），NAT模式則工做在三層網絡層（IP）和四層傳輸層（端口）。
f)當前，調度器LB支持幾乎全部UNIX、Linux系統，但不支持windows系統。真實服務器RS節點能夠是windows系統。
g)總之，DR模式效率很高，可是配置也較麻煩。所以，訪問量不是特別大的公司能夠用haproxy
/
Nginx取代之。這符合運維的原則：簡單、易用、高效。日
1000
-
2000W
PV或併發請求
1
萬如下均可以考慮用haproxy
/
Nginx(LVS的NAT模式)
h)直接對外的訪問業務，例如web服務作RS節點，RS最好用公網IP地址。若是不直接對外的業務，例如：MySQL，存儲系統RS節點，最好只用內部IP地址。
|
DR的實現原理和數據包的改變
|
1
2
3
4
5
6
|
(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) 響應報文最終送達至客戶端
|
1.5 在web端的操做有什麼含義？
1.5.1 RealServer爲何要在lo接口上配置VIP？
既然要讓RS可以處理目標地址爲vip的IP包，首先必需要讓RS能接收到這個包。
在lo上配置vip可以完成接收包並將結果返回client。
1.5.2 在eth0網卡上配置VIP能夠嗎？
不能夠，將VIP設置在eth0網卡上,會影響RS的arp請求,形成總體LVS集羣arp緩存表紊亂，以致於整個負載均衡集羣都不能正常工做。
1.5.3 爲何要抑制ARP響應？
① arp協議說明
ARP協議,全稱"Address Resolution Protocol",中文名是地址解析協議，使用ARP協議可實現經過IP地址得到對應主機的物理地址(MAC地址)。
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緩存表是把雙刃劍
a) 主機有了arp緩存表，能夠加快ARP的解析速度，減小局域網內廣播風暴。由於arp是發廣播解析的，頻繁的解析也是消耗帶寬的，尤爲是機器多的時候。
b) 正是有了arp緩存表，給惡意黑客帶來了攻擊服務器主機的風險，這個就是arp欺騙攻擊。
c) 切換路由器，負載均衡器等設備時，可能會致使短時網絡中斷。由於全部的客戶端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.100
測試命令
ip addr del 10.0.0.100/24 dev eth0 ip addr add 10.0.0.100/24 dev eth0 ip addr show eth0 arping -I eth0 -c 1 -U 10.0.0.100
windows查看arp -a
接口: 10.0.0.1 --- 0x12 Internet 地址 物理地址 類型 10.0.0.100 00-0c-29-de-7c-97 動態 10.0.0.15 00-0c-29-de-7c-97 動態 10.0.0.16 00-0c-29-2e-47-20 動態 10.0.0.17 00-0c-29-4a-ac-4a 動態 10.0.0.18 00-0c-29-ea-ca-55 動態
③arp_announce和arp_ignore詳解
# 配置的內核參數 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
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查詢 |
抑制RS端arp前的廣播狀況
抑制RS端arp後廣播狀況
1.6 LVS集羣的工做模式
DR（Direct Routing）直接路由模式
NAT（Network Address Translation）
TUN（Tunneling）隧道模式
FULLNAT（Full Network Address Translation）
|
1.6.1 LVS集羣的工做模式--NAT
經過網絡地址轉換，調度器LB重寫請求報文的目標地址，根據預設的調度算法，將請求分派給後端的真實服務器，真實服務器的響應報文處理以後，返回時必需要經過調度器，通過調度器時報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。
收費站模式---來去都要通過LB負載均衡器。
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模型的特性
l RS應該使用私有地址，RS的網關必須指向DIP
l DIP和RIP必須在同一個網段內
l 請求和響應報文都須要通過Director Server，高負載場景中，Director Server易成爲性能瓶頸
l 支持端口映射
l RS可使用任意操做系統
l 缺陷：對Director Server壓力會比較大，請求和響應都需通過director server
1.6.2 LVS集羣的工做模式--隧道模式TUN
採用NAT技術時，因爲請求和響應的報文都必須通過調度器地址重寫，當客戶請求愈來愈多時，調度器的處理能力將成爲瓶頸，爲了解決這個問題，調度器把請求的報文經過IP隧道(至關於ipip或ipsec )轉發至真實服務器，而真實服務器將響應處理後直接返回給客戶端用戶，這樣調度器就只處理請求的入站報文。因爲通常網絡服務應答數據比請求報文大不少，採用 VS/TUN技術後，集羣系統的最大吞吐量能夠提升10倍。
VS/TUN工做流程,它的鏈接調度和管理與VS/NAT中的同樣，只是它的報文轉發方法不一樣。調度器根據各個服務器的負載狀況，鏈接數多少，動態地選擇一臺服務器，將原請求的報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的真實服務器；真實服務器收到報文後，先將收到的報文解封得到原來目標地址爲VIP地址的報文, 服務器發現VIP地址被配置在本地的IP隧道設備上(此處要人爲配置)，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。
TUN原理和數據包的改變
(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模型特性
l RIP、VIP、DIP全是公網地址
l RS的網關不會也不可能指向DIP
l 全部的請求報文經由Director Server，但響應報文必須不能進過Director Server
l 不支持端口映射
l RS的系統必須支持隧道
1.6.3 LVS集羣的工做模式--FULLNAT
LVS的DR和NAT模式要求RS和LVS在同一個vlan中，致使部署成本太高；TUNNEL模式雖然能夠跨vlan，但RealServer上須要部署ipip隧道模塊等，網絡拓撲上須要連通外網，較複雜，不易運維。
爲了解決上述問題，開發出FULLNAT，該模式和NAT模式的區別是：數據包進入時，除了作DNAT，還作SNAT（用戶ip->內網ip），從而實現LVS-RealServer間能夠跨vlan通信，RealServer只須要鏈接到內網。
類比地鐵站多個閘機。
1.7 IPVS調度器實現了以下八種負載調度算法：
a) 輪詢（Round Robin）RR
調度器經過"輪叫"調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均等地對待每一臺服務器，而無論服務器上實際的鏈接數和系統負載。
b) 加權輪叫（Weighted Round Robin）WRR
調度器經過"加權輪叫"調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣能夠保證處理能力強的服務器處理更多的訪問流量。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。
c) 最少連接（Least Connections） LC
調度器經過"最少鏈接"調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能，採用"最小鏈接"調度算法能夠較好地均衡負載。
d) 加權最少連接（Weighted Least Connections） Wlc
在集羣系統中的服務器性能差別較大的狀況下，調度器採用"加權最少連接"調度算法優化負載均衡性能，具備較高權值的服務器將承受較大比例的活動鏈接負載。調度器能夠自動問詢真實服務器的負載狀況，並動態地調整其權值。
e) 基於局部性的最少連接（Locality-Based Least Connections） Lblc
"基於局部性的最少連接" 調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器 是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工做負載，則用"最少連接"的原則選出一個可用的服務 器，將請求發送到該服務器。
f) 帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication）
"帶複製的基於局部性最少連接"調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個 目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按"最小鏈接"原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小鏈接"原則從這個集羣中選出一 臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的 程度。
g) 目標地址散列（Destination Hashing） Dh
"目標地址散列"調度算法根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。
h) 源地址散列（Source Hashing）SH
"源地址散列"調度算法根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。
1.8 LVS+Keepalived方案實現
1.8.1 keepalived功能
1. 添加VIP
2. 添加LVS配置
3. 高可用（VIP漂移）
4. web服務器健康檢查
1.8.2 在負載器安裝Keepalived軟件
yum -y install keepalived
# 檢查軟件是否安裝
[root@lb03 ~]# rpm -qa keepalived keepalived-1.3.5-1.el7.x86_64
1.8.3 修改配置文件
lb03上keepalied配置文件
[root@lb03 ~]# cat /etc/keepalived/keepalived.conf global_defs { router_id LVS_01 } 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.100/24 } } virtual_server 10.0.0.100 80 { delay_loop 6 lb_algo wrr lb_kind DR nat_mask 255.255.255.0 persistence_timeout 50 protocol TCP real_server 10.0.0.1 80 { weight 1 TCP_CHECK { connect_timeout 8 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 10.0.0.2 80 { weight 1 TCP_CHECK { connect_timeout 8 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } }
lb04的Keepalied配置文件
[root@lb04 ~]# cat /etc/keepalived/keepalived.conf global_defs { router_id LVS_01 } 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.100/24 } } virtual_server 10.0.0.100 80 { delay_loop 6 lb_algo wrr lb_kind DR nat_mask 255.255.255.0 persistence_timeout 50 protocol TCP real_server 10.0.0.1 80 { weight 1 TCP_CHECK { connect_timeout 8 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 10.0.0.2 80 { weight 1 TCP_CHECK { connect_timeout 8 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } }
keepalived persistence_timeout參數意義 LVS Persistence 參數的做用
http://blog.csdn.net/nimasike/article/details/53911363
1.8.4 啓動keepalived服務
[root@lb03 ~]# systemctl restart keepalived.service
# 檢查lvs狀態
[root@lb03 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.0.0.100:80 wrr persistent 50
-> 10.0.0.1:80 Route 1 0 0
-> 10.0.0.2:80 Route 1 0 0
# 檢查虛擬ip
[root@lb03 ~]# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:de:7c:97 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.15/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet 10.0.0.100/24 scope global secondary eth0
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fede:7c97/64 scope link
valid_lft forever preferred_lft forever
1.8.5 在web服務器上進行配置
（在web03/web04同時操做下面步驟） 步驟1：在lo網卡綁定VIP地址（ip） 步驟2：修改內核參數抑制ARP響應 ip addr add 10.0.0.100/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
注意：web服務器上的配置爲臨時生效，能夠將其寫入rc.local文件，注意文件的執行權限。
使用curl命令進行測試
[root@lb04 ~]# curl 10.0.0.100 node1
至此keepalived+lvs配置完畢
1.9 常見LVS負載均衡高可用解決方案
Ø 開發相似keepalived的腳本，早期的辦法，如今不推薦使用。
Ø heartbeat+lvs+ldirectord腳本配置方案，複雜不易控制，不推薦使用
Ø RedHat工具piranha，一個web界面配置LVS。
Ø LVS-DR+keepalived方案，老師推薦最優方案，簡單、易用、高效。
1.9.1 lvs排錯思路
1.9.2 參考文檔
|
1
2
3
4
5
6
7
|
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
NAT模式安裝詳解 http:
/
/
www.cnblogs.com
/
liwei0526vip
/
p
/
6370103.html
開發眼光看lvs http:
/
/
blog.hesey.net
/
2013
/
02
/
introduce
-
to
-
load
-
balance
-
and
-
lvs
-
briefly.html
lvs 介紹 http:
/
/
www.it165.net
/
admin
/
html
/
201401
/
2248.html
|
- 1. 高併發場景 LVS 安裝及高可用實現
- 2. 之高併發場景 LVS 簡快入門實戰
- 3. LVS+Nginx(LVS + Keepalived + Nginx安裝及配置)
- 4. lvs+keepalived安裝
- 5. Linux-centos下安裝lvs+keepalived高可用
- 6. redis事務、併發及應用場景
- 7. 4.1併發應用場景
- 8. 32---keepalived功能及使用場景(2)
- 9. LVS-keepalived高可用
- 10. keepalived高可用lvs
- 更多相關文章...
- • TiDB數據庫的應用場景 - NoSQL教程
- • Rust 併發編程 - RUST 教程
- • Composer 安裝與使用
- • TiDB 在摩拜單車在線數據業務的應用和實踐
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. eclipse設置粘貼字符串自動轉義
- 2. android客戶端學習-啓動模擬器異常Emulator: failed to initialize HAX: Invalid argument
- 3. android.view.InflateException: class com.jpardogo.listbuddies.lib.views.ListBuddiesLayout問題
- 4. MYSQL8.0數據庫恢復 MYSQL8.0ibd數據恢復 MYSQL8.0恢復數據庫
- 5. 你本是一個肉體，是什麼驅使你前行【1】
- 6. 2018.04.30
- 7. 2018.04.30
- 8. 你本是一個肉體，是什麼驅使你前行【3】
- 9. 你本是一個肉體，是什麼驅使你前行【2】
- 10. 【資訊】LocalBitcoins達到每週交易比特幣的7年低點