提高服務(wù)器響應(yīng)能力的方法：

scale on? 在原有服務(wù)器的基礎(chǔ)上進(jìn)行升級或者直接換一臺新的性能更高的服務(wù)器。 scale out? 橫向擴(kuò)展，將多臺服務(wù)器并發(fā)向外響應(yīng)客戶端的請求。優(yōu)點(diǎn)：成本低，擴(kuò)展架構(gòu)比較簡單。
? 集群（Cluster），通俗地講就是按照某種組織方式將幾臺電腦組織起來完成某種特定任務(wù)的這樣一種架構(gòu)。
? 集群技術(shù)主要分為三大類：

1、高可用性HA(High Available Cluster)
?
利用集群管理軟件，當(dāng)主服務(wù)器故障時，備份服務(wù)器能夠自動接管主服務(wù)器的工作，并及時切換過去，以實(shí)現(xiàn)對用戶的不間斷服務(wù)。

2、負(fù)載均衡LB(Load balancing Cluster)
負(fù)載均衡其實(shí)就是一個樂隊的指揮，指揮下面的樂隊

即把負(fù)載壓力根據(jù)某種算法合理分配到集群中的每一臺計算機(jī)上，以減輕主服務(wù)器的壓力，降低對主服務(wù)器的硬件和軟件要求。?

可以擴(kuò)展服務(wù)容量；常用的有LVS

3、高性能計算HP(High Performance Computing)

即充分利用集群中的每一臺計算機(jī)的資源，實(shí)現(xiàn)復(fù)雜運(yùn)算的并行處理，通常用于科學(xué)計算領(lǐng)域，比如基因分析，化學(xué)分析等。
?
? LB Cluster:負(fù)載均衡集群
? Director:負(fù)載均衡器，也叫調(diào)度器； 負(fù)責(zé)接收客戶端請求，并將請求按照某種算法分發(fā)到后臺真正提供服務(wù)的服務(wù)器上。 調(diào)度器在調(diào)度時要考慮后端服務(wù)器的狀態(tài);還能夠?qū)蠖朔?wù)器的健康狀態(tài)進(jìn)行檢測 Shared Storage(共享存儲)： 在負(fù)載均衡中后端的real server需要對數(shù)據(jù)進(jìn)行共享； Shared Storage為所有Real Server提供共享存儲空間和一致的數(shù)據(jù)內(nèi)容。
? 共享存儲分為：
DAS:直接附加存儲
????? 直接連到主機(jī)總線那去的；；靠主板芯片通電
????? 在塊級別；連接線的長度很短
NAS：網(wǎng)絡(luò)附加存儲
? ? ? ? 文件共享是在文件級別的；不能格式化，用于共享文件
? ? ? ? ?通過NFS/Samba實(shí)現(xiàn)
? ? ??
SAN:存儲區(qū)域網(wǎng)絡(luò)
????? 基于塊級別的，可以分區(qū)，格式化，需要鎖管理 SAN又分為：
???? FC SAN ：光纖
???? IP SAN：以太網(wǎng)

? 能夠提供負(fù)載均衡的方案：
Hardware
1、F5 ：BIG IP? 1000w并發(fā)請求
2、Citix:netscler? 思捷 500w并發(fā)請求
3、IBM的A10?? 600w

Software:

4、lvs：能夠達(dá)到400w；
5、 haproxy:
? LVS :?Linux虛擬服務(wù)

LVS是一個開源軟件
體系結(jié)構(gòu)：
LVS由前端的負(fù)載均衡器(Load Balancer，LB)和后端的真實(shí)服務(wù)器(Real Server，RS)群組成。RS間可通過局域網(wǎng)或廣域網(wǎng)連接。 LVS的這種結(jié)構(gòu)對用戶是透明的，用戶只能看見一臺作為LB的虛擬服務(wù)器(Virtual Server)，而看不到提供服務(wù)的RS群。

類似于iptables的架構(gòu)，在內(nèi)核中有一段代碼用于實(shí)時監(jiān)聽數(shù)據(jù)包來源的請求，當(dāng)數(shù)據(jù)包到達(dá)端口時做一次重定向。這一系列的工作必須在內(nèi)核中實(shí)現(xiàn)。在內(nèi)核中實(shí)現(xiàn)數(shù)據(jù)包請求處理的代碼叫做ipvs。ipvs僅僅提供了功能框架不識別服務(wù)，ipvs和iptables一樣，要想真正工作起來要靠規(guī)則；寫規(guī)則的工具是工作在用戶空間的ipvsadm。


Director是一種四層交換；tcp/udp的協(xié)議都可以通過lvs向后端做負(fù)載均衡的；是工作在四層的一個軟件，
用戶的請求應(yīng)該是一個特定協(xié)議的特定請求；如tcp/80是web服務(wù)，

常見的名稱稱呼：
VIP--Virtual IP address：虛擬IP地址，并不提供服務(wù)，而是將用戶的請求轉(zhuǎn)發(fā)至后方
RIP--Real IP address：后臺真正提供服務(wù)的服務(wù)器的IP地址
DIP--Director IP address：調(diào)度IP地址，通常是和RIP相連的LVS的IP地址
CIP--Client IP address：客戶端IP。

LVS的類型：
NAT：地址類型
DR：直接路由
TUN：隧道

一、NAT：目標(biāo)地址轉(zhuǎn)換 所有客戶端的請求都被Director根據(jù)訪問請求和調(diào)度算法被定向到后臺的Real Server上。

NAT方式下前端的DR與RS是一托N的，DR可以帶動n個服務(wù)器工作的，所有的服務(wù)器的進(jìn)出請求都要經(jīng)過DR的；這樣Director的壓力就比較大。當(dāng)服務(wù)器規(guī)模增大到一定程度時，DR會稱為整個系統(tǒng)的瓶頸的。
NAT適用于規(guī)模不大的集群的

NAT模型和DNAT(目標(biāo)地址轉(zhuǎn)換)基本相似，只是比后者多了負(fù)載均衡的用法

?

?數(shù)據(jù)包地址轉(zhuǎn)換過程：
S:CIP D:VIP--->Director--->S:CIP D:RIP--->Real Server--->
--->S:RIP? D:CIP--->Director--->S:VIP? D:CIP?

特征：

1、集群節(jié)點(diǎn)與DR在同一網(wǎng)絡(luò)中
??? real server 和director在同一網(wǎng)絡(luò)中
2、RIP是私有Ip，僅用于通信
3、DR工作在clients和RS中間，負(fù)責(zé)處理進(jìn)出的全部報文
4、RS網(wǎng)關(guān)要指向DIP
5、可以實(shí)現(xiàn)端口轉(zhuǎn)換（或映射）
6、RS可以是任何操作系統(tǒng)
7、DR可能會成為系統(tǒng)瓶頸，不適合在較大規(guī)模中應(yīng)用

二、DR：直接路由

由于在NAT模式下當(dāng)服務(wù)器數(shù)量達(dá)到一定規(guī)模是會成為整個系統(tǒng)的瓶頸，影響集群性能的發(fā)揮，為了解決這個問題，引入了一種類似旁路的方式，即DR只負(fù)責(zé)處理請求的報文，服務(wù)器端響應(yīng)請求時直接到達(dá)客戶端，不在經(jīng)過DR，請求與響應(yīng)分離，這樣DR就相當(dāng)于處理了一半的業(yè)務(wù)量，DR的性能就大大的釋放出來了，也避免了Director稱為單點(diǎn)故障了；

?

1、客戶請求經(jīng)過Director，而Real Server在響應(yīng)的時候直接回應(yīng)給客戶端

2、但每一個real server必須隱藏自己的VIP，不能響應(yīng)前段的請求；
每一個real server都不能告訴用戶自己的mac地址；如果用戶直接能夠找到
real server的mac地址，那么就繞過了Director了，這樣負(fù)載均衡的意義也就不存在了。

3、DR收到報文后根據(jù)算法選擇后臺相應(yīng)的real server
并將目標(biāo)mac變成選擇的real server的mac地址

4、Director怎么知道real server的mac地址？
Director和RS必須要處于同一個物理網(wǎng)絡(luò)中，在一個局域網(wǎng)中，實(shí)行廣播，讓Director知道其內(nèi)的每一個RS的mac地址，這樣Director可以將請求發(fā)至選擇的RS中

5、除了上述說的real server需要mac地址；每個real server還要有自己的RIP

? 需解決兩個問題： 1、如何避免real server對客戶端發(fā)來的請求的直接響應(yīng)；達(dá)到隱藏real server的RIP？ 解決方法：修改內(nèi)核的兩個參數(shù)：
??????? 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
1)arp_announce?當(dāng)ARP請求通過某個端口進(jìn)來是否利用這個接口來回應(yīng)。
012用于定義通告級別的
0，是默認(rèn)級別，控制本機(jī)至外地的所有通告
1，避免使用跟目標(biāo)網(wǎng)絡(luò)不在同一網(wǎng)絡(luò)內(nèi)的地址進(jìn)行通告
2，只使用最佳本地網(wǎng)絡(luò)地址通告給目標(biāo)地址
2）arp_ignore:當(dāng)ARP請求發(fā)過來后發(fā)現(xiàn)自己正是請求的地址是否響應(yīng) 0、不論請求從哪個目標(biāo)地址來的，只要本機(jī)上有，就給予響應(yīng)
1，只有你的請求報文從這個網(wǎng)絡(luò)接口進(jìn)來，才予以響應(yīng)
##對linux來說IP地址屬于系統(tǒng)而不屬于某個接口。

2、當(dāng)Real Server內(nèi)網(wǎng)網(wǎng)卡響應(yīng)客戶端請求時，要以VIP作為源地址，不能以RIP作為源地址。
解決方法：
添加一條路由 如：route add -host 192.168.0.127(VIP) dev lo:0使客戶端訪問VIP，就讓VIP來響應(yīng)客戶端。這樣避免了使用RIP作為源地址。

DIP來完成與RIP彼此間實(shí)現(xiàn)arp解析，并將客戶端的請求轉(zhuǎn)發(fā)給Real Server。 VIP作用是響應(yīng)客戶端請求；
? DR模式：DR模式是這樣工作的，當(dāng)CIP訪問VIP后，VIP把數(shù)據(jù)包通過DIP轉(zhuǎn)交給RIP,RIP在收到數(shù)據(jù)包后通過網(wǎng)卡別名欺騙（節(jié)點(diǎn)的網(wǎng)卡配置別名，IP為VIP），直接用別名的VIP響應(yīng)客戶端，從而加快了回應(yīng)速度，也避免了Director成為地址轉(zhuǎn)換的單點(diǎn)故障.目前主要應(yīng)用的為DR模式的負(fù)載均衡.

特征：
1、集群節(jié)點(diǎn)和Director必須在同一物理網(wǎng)絡(luò)中，中間不能隔路由網(wǎng)關(guān)的
2、RIP可以是公網(wǎng)地址
3、Director僅處理入站請求(僅處理請求報文)；而real server直接響應(yīng)請求給用戶
4、RS的網(wǎng)關(guān)不能指向DIP；而是以公網(wǎng)上的某臺路由器作為網(wǎng)關(guān)；
5、不能使用端口映射
6、大多數(shù)操作系統(tǒng)都可以用作RS；windows除外
7、DR模型的Director能夠處理比NAT更海量的請求


三、隧道模型：
與DR的網(wǎng)絡(luò)結(jié)構(gòu)一樣，但Director和Real Server可以在不同的網(wǎng)絡(luò)當(dāng)中，可以實(shí)現(xiàn)異地容災(zāi)的功能。DIP----->VIP 基于隧道來傳輸，在數(shù)據(jù)包外層額外封裝了S:DIP D :RIP 的地址。

LVS-TUN可實(shí)現(xiàn)基于網(wǎng)絡(luò)的集群；這樣就脫離了DR模型中的real server之間距離的限制?

特征：
1、集群節(jié)點(diǎn)不必在同一物理網(wǎng)絡(luò)中
2、RIP一定不能使用私有地址
3、Director僅處理請求報文
4、real server的響應(yīng)報文不能經(jīng)過Director
5、基于隧道模型不能使用端口映射
6、僅允許支持隧道協(xié)議的操作系統(tǒng)用于RS

調(diào)度方法：十種

分為動態(tài)方法和靜態(tài)(固定)
靜態(tài)僅根據(jù)算法本身調(diào)度，不考慮real server的當(dāng)前連接狀況，

動態(tài)要將RS的鏈接狀態(tài)記入調(diào)度考量標(biāo)準(zhǔn)的

四種靜態(tài)調(diào)度方法：
1、rr：Round-robin 輪詢，將用戶請求平均分配給后端real server
2、wrr：Weighted round-robin 加權(quán)輪詢
????????給每臺Real Server分配一個權(quán)重，權(quán)重越大，性能越好,分到的請求越多。?????
3、DH：目標(biāo)地址hash；Destination hashing?
? ? ? ? 來自于同一個IP地址的請求都被重定向到同一臺Real Server上；主要為了提高緩存利用率? ? ? ? ?
4、SH： 源地址hash； ? ? ?? ? ? ? ? ?Director必須確保響應(yīng)的數(shù)據(jù)包必須通過請求數(shù)據(jù)包所經(jīng)過的路由器或者防火墻（保證原地址不變）。

六種動態(tài)調(diào)度方法：
1、LC：least? connection 最少鏈接
????? 哪一個Real Server上的連接數(shù)少就將下一個連接請求定向到那臺Real Server上去。
? ? ?算法：Overhead=active*256+inactive 2、WLC：加權(quán)最少鏈接；Weight Least-Connection
??? 在最少連接的基礎(chǔ)上給每臺Real Server分配一個權(quán)重。
??? 算法：Override=(active*256+inactice)/weight 3、SED：最短延遲；不再考慮非活動連接數(shù)
???? Override=(active+1*256)/weight ????? 缺點(diǎn)：當(dāng)權(quán)重差別大，值又相等時，會造成性能強(qiáng)的服務(wù)器連接了幾個，而性能弱的會一直處于等待狀態(tài)；
4、NQ：不用排隊；在sed基礎(chǔ)上改進(jìn)，先會為每一個分配一個請求
??????????????
5、LBLC： 基于本地狀態(tài)的最少連接，Locality-Based Least-Connection
????????該算法根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址最近使用的服務(wù)器，如果一個用戶曾經(jīng)鏈接過的話，分配到原先分配的RS上；新連接會考慮到后方RS服務(wù)器的鏈接狀態(tài)
?6、LBLCR：帶復(fù)制功能的基于本地的最少鏈接?????????
????????它與LBLC算法的不同之處是它要維護(hù)從一個目標(biāo)IP地址到一組服務(wù)器的映射，而LBLC算法維護(hù)從一個目標(biāo)IP地址到一臺服務(wù)器的映射。

較常用的是WLC,LBLC


定義集群服務(wù)：

ipvsadm -A|E -t|u|f service-address [-s scheduler]
-A：添加
-E:修改

-t：tcp服務(wù) -u：udpfw
-f:防火墻標(biāo)記；后加標(biāo)記號

-s scheduler:調(diào)度算法

刪除：
ipvsadm -D -t|u|f service-address

管理集群服務(wù)中的RS：

ipvsadm -a|e -t|u|f service-address -r server-addr -g|i|m? [-w weight]

-a:增加
-e：修改

-g,? --gatewaying???? DR模式?
-i,?? --ipip ? ? ? ? ? ? ? TUN模式
-m,? --masquerading?? NAT模式 ??

刪除：
ipvsadm -d -t|u|f service-addr -r server-addr

查看定義的服務(wù)及RS：

ipvsadm -L|l：
????????? -n：輸出IP和端口的數(shù)字形式
????????? -c：顯示當(dāng)前的鏈接狀態(tài)
????????? --stats：顯示統(tǒng)計信息
????????? --rate:顯示速率信息
????????? -Z --zero：置零

ipvsadm -C?清空所有的定義
ipvsadm -R = ipvsadm-restore 存儲
ipvsadm -S = ipvsadm-save 保存
?

轉(zhuǎn)載于:https://blog.51cto.com/51880526/1070412

總結(jié)

以上是生活随笔為你收集整理的LVS负载均衡基础总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。