1. LB Cluster 負(fù)載均衡集群
1.1 基于工作的協(xié)議層次劃分
傳輸層（通用）：利用DNAT 和 DPORT
LVS：LVS中的DNAT, 可以把用戶(hù)請(qǐng)求轉(zhuǎn)發(fā)到不同的后端服務(wù)器, 而iptables(Netfilter)中的DNAT只能轉(zhuǎn)發(fā)到一個(gè)后端服務(wù)器
nginx：stream
haproxy：mode tcp
應(yīng)用層（專(zhuān)用）：針對(duì)特定協(xié)議祟偷，常稱(chēng)為 proxy server
http：nginx, httpd, haproxy(mode http), …
fastcgi：nginx, httpd, …
mysql：mysql-proxy, …
1.2 負(fù)載均衡的會(huì)話保持
1.session 綁定：同一用戶(hù)調(diào)度固定服務(wù)器
基于 Source IP：LVS SH算法（可以對(duì)某一特定服務(wù)而言; nginx可以基于$ip_hash實(shí)現(xiàn)源地址hash, 也可以基于hash $remote_addr實(shí)現(xiàn)源地址hash
Cookie: lvs不支持, nginx支持基于請(qǐng)求報(bào)文的cookie字段進(jìn)行調(diào)度, $cookie_NAME
2.session 復(fù)制：每臺(tái)服務(wù)器擁有全部session
session multicast cluster
3.session 共享：利用專(zhuān)門(mén)的session服務(wù)器存儲(chǔ)session, 應(yīng)用程序鏈接session服務(wù)器獲取session
Memcached索昂，Redis
1.3 高可用集群實(shí)現(xiàn)
LVS本身存在單點(diǎn)失敗問(wèn)題, 需要配合keepalived實(shí)現(xiàn)高可用
keepalived：vrrp協(xié)議
2. Linux Virtual Server 簡(jiǎn)介
2.1 LVS介紹
LVS：Linux Virtual Server雀彼，負(fù)載調(diào)度器，內(nèi)核集成的功能, 一般配合keepalived實(shí)現(xiàn)高可用負(fù)載均衡集群
2.2 LVS工作原理
LVS根據(jù)請(qǐng)求報(bào)文的目標(biāo)IP和目標(biāo)協(xié)議及端口將其調(diào)度轉(zhuǎn)發(fā)至某RS袱吆，根據(jù)調(diào)度算法來(lái)挑選RS
LVS是內(nèi)核級(jí)功能盛泡，工作在INPUT鏈憾赁，將發(fā)往INPUT的流量進(jìn)行“處理”
范例: 查看內(nèi)核是否支持LVS, 已經(jīng)支持的算法
grep -i -C 10 ipvs /boot/config-4.18.0-147.el8.x86_64
...（省略部分內(nèi)容）...
CONFIG_NETFILTER_XT_MATCH_IPVS=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
...（省略部分內(nèi)容）...
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_FO=m #新增
CONFIG_IP_VS_OVF=m #新增
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
# CONFIG_IP_VS_MH is not set
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
...（省略部分內(nèi)容）...
2.3 LVS集群體系架構(gòu)
2.4 LVS 功能及組織架構(gòu)
負(fù)載均衡的應(yīng)用場(chǎng)景為高訪問(wèn)量的業(yè)務(wù)，提高應(yīng)用程序的可用性和可靠性赠橙。
應(yīng)用于高訪問(wèn)量的業(yè)務(wù)
如果您的應(yīng)用訪問(wèn)量很高耽装，可以通過(guò)配置監(jiān)聽(tīng)規(guī)則將流量分發(fā)到不同的云服務(wù)器 ECS（Elastic Compute Service 彈性計(jì)算服務(wù)）實(shí)例上。此外期揪，可以使用會(huì)話保持功能將同一客戶(hù)端的請(qǐng)求轉(zhuǎn)發(fā)到同一臺(tái)后端ECS
擴(kuò)展應(yīng)用程序
可以根據(jù)業(yè)務(wù)發(fā)展的需要掉奄，隨時(shí)添加和移除ECS實(shí)例來(lái)擴(kuò)展應(yīng)用系統(tǒng)的服務(wù)能力，適用于各種Web服務(wù)器和App服務(wù)器。
消除單點(diǎn)故障
可以在負(fù)載均衡實(shí)例下添加多臺(tái)ECS實(shí)例姓建。當(dāng)其中一部分ECS實(shí)例發(fā)生故障后诞仓，負(fù)載均衡會(huì)自動(dòng)屏蔽故障的ECS實(shí)例，將請(qǐng)求分發(fā)給正常運(yùn)行的ECS實(shí)例速兔，保證應(yīng)用系統(tǒng)仍能正常工作
同城容災(zāi) （多可用區(qū)容災(zāi)）
為了提供更加穩(wěn)定可靠的負(fù)載均衡服務(wù)墅拭，阿里云負(fù)載均衡已在各地域部署了多可用區(qū)以實(shí)現(xiàn)同地域容災(zāi)。當(dāng)主可用區(qū)出現(xiàn)機(jī)房故障或不可用時(shí)涣狗，負(fù)載均衡仍然有能力在非常短的時(shí)間內(nèi)（如：大約30s中斷）切換到另外一個(gè)備可用區(qū)恢復(fù)服務(wù)能力谍婉；當(dāng)主可用區(qū)恢復(fù)時(shí)，負(fù)載均衡同樣會(huì)自動(dòng)切換到主可用區(qū)提供服務(wù)镀钓。
使用負(fù)載均衡時(shí)穗熬，您可以將負(fù)載均衡實(shí)例部署在支持多可用區(qū)的地域以實(shí)現(xiàn)同城容災(zāi)。此外丁溅，建議您結(jié)合自身的應(yīng)用需要唤蔗，綜合考慮后端服務(wù)器的部署。如果您的每個(gè)可用區(qū)均至少添加了一臺(tái)ECS實(shí)例唧瘾，那么此種部署模式下的負(fù)載均衡服務(wù)的效率是最高的措译。
如下圖所示，在負(fù)載均衡實(shí)例下綁定不同可用區(qū)的ECS實(shí)例饰序。正常情況下领虹，用戶(hù)訪問(wèn)流量將同時(shí)轉(zhuǎn)至發(fā)主、備可用區(qū)內(nèi)的ECS實(shí)例求豫；當(dāng)可用區(qū)A發(fā)生故障時(shí)塌衰，用戶(hù)訪問(wèn)流量將只轉(zhuǎn)發(fā)至備可用區(qū)內(nèi)的ECS實(shí)例。此種部署既可以避免因?yàn)閱蝹€(gè)可用區(qū)的故障而導(dǎo)致對(duì)外服務(wù)的不可用蝠嘉，也可以通過(guò)不同產(chǎn)品間可用區(qū)的選擇來(lái)降低延遲最疆。
負(fù)載均衡層和后端服務(wù)器都實(shí)現(xiàn)高可用
如果采取如下圖所示的部署方案，即在負(fù)載均衡實(shí)例的主可用區(qū)下綁定多臺(tái)ECS實(shí)例蚤告，而在備可用區(qū)沒(méi)有任何ECS實(shí)例努酸。當(dāng)主可用區(qū)發(fā)生故障時(shí)會(huì)造成業(yè)務(wù)中斷，因?yàn)閭淇捎脜^(qū)沒(méi)有ECS實(shí)例來(lái)接收請(qǐng)求杜恰。這樣的部署方式很明顯是以犧牲高可用性為代價(jià)來(lái)獲取低延時(shí)获诈。
僅實(shí)現(xiàn)負(fù)載均衡層的高可用, 后端服務(wù)器并沒(méi)有高可用
跨地域容災(zāi)
您可以在不同地域下部署負(fù)載均衡實(shí)例，并分別掛載相應(yīng)地域內(nèi)不同可用區(qū)的ECS心褐。上層利用云解析做智能DNS舔涎，將域名解析到不同地域的負(fù)載均衡實(shí)例服務(wù)地址下，可實(shí)現(xiàn)全局負(fù)載均衡逗爹。當(dāng)某個(gè)地域出現(xiàn)不可用時(shí)亡嫌，暫停對(duì)應(yīng)解析即可實(shí)現(xiàn)所有用戶(hù)訪問(wèn)不受影響。
2.5 LVS集群術(shù)語(yǔ)
VS: Virtual Server
RS: Real Server, upstream server(nginx), backend server(haproxy)
CIP: client IP, 客戶(hù)端IP
VIP: Virtual Server IP, LVS接受請(qǐng)求的網(wǎng)卡的IP
DIP: Director IP, LVS和Real Server通信用的IP
RIP: 后端服務(wù)器的IP
3. LVS工作模式和相關(guān)命令
3.1 LVS集群的工作模式
lvs-nat：修改請(qǐng)求報(bào)文的目標(biāo)IP,多目標(biāo)IP的DNAT
lvs-dr：操縱封裝新的MAC地址
lvs-tun：在原請(qǐng)求IP報(bào)文之外新加一個(gè)IP首部
lvs-fullnat：修改請(qǐng)求報(bào)文的源和目標(biāo)IP, 內(nèi)核默認(rèn)不支持
3.1.1 LVS的NAT模式
lvs-nat：本質(zhì)是多目標(biāo)IP的DNAT，通過(guò)將請(qǐng)求報(bào)文中的目標(biāo)地址和目標(biāo)端口修改為某挑出的RS的RIP和PORT實(shí)現(xiàn)轉(zhuǎn)發(fā)
（1）RIP和DIP可以是通過(guò)交換機(jī)相連的同一個(gè)網(wǎng)段, 也可以是路由器相連的不同網(wǎng)段, 只要保證是原路返回即可. 用交換機(jī)連接時(shí), RS的網(wǎng)關(guān)要指向DIP, 而用路由器連接時(shí), RS的網(wǎng)關(guān)指向路由器的接口地址. 不過(guò)一般NAT模式都是用交換機(jī)相連, 不會(huì)跨網(wǎng)絡(luò)
（2）請(qǐng)求報(bào)文和響應(yīng)報(bào)文都必須經(jīng)由Director轉(zhuǎn)發(fā)挟冠，Director易于成為系統(tǒng)瓶頸. 因此LVS-NAT模式要求后端服務(wù)器數(shù)量不能太高. 雖然LVS支持百萬(wàn)并發(fā), 但是還要受到網(wǎng)段帶寬的限制, 一般幾十臺(tái)
,
（3）支持端口映射于购，可修改請(qǐng)求報(bào)文的目標(biāo)PORT
（4）VS必須是Linux系統(tǒng)，RS可以是任意OS系統(tǒng)
LVS-NAT模式的通信過(guò)程
1. 客戶(hù)端發(fā)起請(qǐng)求, 源ip為客戶(hù)端ip地址(如果有SNAT會(huì)被SNAT轉(zhuǎn)換), 源端口為客戶(hù)端開(kāi)啟的隨機(jī)端口(如果有SNAT那么會(huì)被SNAT轉(zhuǎn)換). 目標(biāo)ip為L(zhǎng)VS的vip, 目標(biāo)端口為vip監(jiān)聽(tīng)的端口
2. 經(jīng)過(guò)LVS服務(wù)器, 修改請(qǐng)求報(bào)文的目標(biāo)ip, 目標(biāo)port(如果后端服務(wù)器修改了web服務(wù)器的監(jiān)聽(tīng)端口那么就DNAT要修改目標(biāo)端口)
3. 根據(jù)指定的調(diào)度算法, 把請(qǐng)求報(bào)文轉(zhuǎn)發(fā)給相應(yīng)的服務(wù)器
4. 服務(wù)器處理請(qǐng)求, 封裝響應(yīng)報(bào)文, 源ip為服務(wù)器自己的ip, 源端口為服務(wù)器監(jiān)聽(tīng)的web端口, 目標(biāo)客戶(hù)端的ip, 目標(biāo)端口是客戶(hù)端的端口
5. 相應(yīng)報(bào)文到達(dá)LVS, 進(jìn)行SNAT, 把響應(yīng)報(bào)文的源ip改為L(zhǎng)VS的vip, 源端口改為L(zhǎng)VS上監(jiān)聽(tīng)的web端口
6. 客戶(hù)端收到響應(yīng)報(bào)文, 查看源ip和port是否和請(qǐng)求時(shí)的ip地址相同, 相同則接受, 不同則丟棄
LVS-NAT模式, 限定了請(qǐng)求和響應(yīng)報(bào)文都必須經(jīng)過(guò)LVS
客戶(hù)端發(fā)起請(qǐng)求時(shí), 目標(biāo)ip是LVS的vip
如果響應(yīng)報(bào)文不經(jīng)過(guò)LVS做NAT轉(zhuǎn)換, 直接由后端RS發(fā)給客戶(hù)端, 那么客戶(hù)端收到的響應(yīng)報(bào)文的源ip是客戶(hù)端ip, 和當(dāng)初自己請(qǐng)求的vip不同, 因此不會(huì)處理
LVS工作在Netfilter的PREROUTING鏈后的路由預(yù)處理與INPUT鏈之間
請(qǐng)求報(bào)文 > PREROUTING > 路由預(yù)處理 > IPVS > INPUT > POSTROUTING
LVS服務(wù)器收到請(qǐng)求報(bào)文, 由于目標(biāo)ip是自己的vip, 因此會(huì)通過(guò)PREROUTING鏈, 進(jìn)入路由預(yù)處理
路由表檢查發(fā)現(xiàn)請(qǐng)求報(bào)文的目標(biāo)地址是自己的vip, 因此會(huì)轉(zhuǎn)發(fā)到INPUT鏈, 而LVS策略就是工作在INPUT鏈之前, 直接做DNAT轉(zhuǎn)換, 不讓請(qǐng)求報(bào)文進(jìn)到LVS內(nèi)部, 而是做完轉(zhuǎn)換直接從POSTROUTING鏈發(fā)給后端服務(wù)器
而DNAT工作在PREROUTING鏈, 在PREROUTING上直接做目標(biāo)地址和端口修改, 否則因?yàn)檎?qǐng)求報(bào)文的目標(biāo)IP就是服務(wù)器的ip地址, 如果不在PREROUTING做轉(zhuǎn)換, 那么就會(huì)進(jìn)入到INPUT鏈, 交給防火墻自身處理, 而防火墻是沒(méi)有處理功能的, 需要交給后端的服務(wù)器處理
雖然LVS的IPVS模塊和Iptables的Netfilter模塊是不同的內(nèi)核模塊, 但是使用LVS時(shí), 不要在LVS服務(wù)器上做iptables規(guī)則, 尤其是PREROUTING鏈, 因?yàn)榭赡苡捎赑REROUTING鏈設(shè)置不正確, 導(dǎo)致請(qǐng)求報(bào)文直接在PREROUTING被丟棄
利用路由器連接LVS和RS
利用交換機(jī)連接LVS和RS
3.1.2 LVS的DR模式
LVS-DR：Direct Routing圃郊，直接路由价涝，LVS默認(rèn)模式, 應(yīng)用最廣泛, 通過(guò)為請(qǐng)求報(bào)文重新封裝一個(gè)MAC首部進(jìn)行轉(zhuǎn)發(fā)，修改請(qǐng)報(bào)文的目標(biāo)MAC地址, 之后源MAC也被修改為DIP所在的接口的MAC持舆，目標(biāo)MAC是某挑選出的RS的RIP所在接口的MAC地址色瘩；源IP/PORT，以及目標(biāo)IP/PORT均保持不變
DR模型簡(jiǎn)易圖
DR模型通信過(guò)程
LVS如何得到后端服務(wù)器的MAC地址
LVS上會(huì)配置后端RS的RIP, 但是MAC地址是不知道的
LVS通過(guò)arp廣播, 根據(jù)被被調(diào)度的RS的RIP, 查詢(xún)其MAC地址
由于LVS和RS依靠arp廣播, 因此, LVS和RS必須在同一個(gè)網(wǎng)段, 不能用路由器相連, 不遠(yuǎn)程調(diào)度, 需要LVS和RS部署在同一個(gè)機(jī)房, 一旦機(jī)房出現(xiàn)問(wèn)題, 會(huì)有單點(diǎn)故障
DR模式的特點(diǎn)：
1.Director和各RS都配置有VIP. 因?yàn)镈R模式下, 響應(yīng)報(bào)文是直接由RS發(fā)給客戶(hù)端, 客戶(hù)端請(qǐng)求的目標(biāo)ip是LVS的vip, 而RS的響應(yīng)報(bào)文源ip是自己的RIP, 會(huì)造成客戶(hù)端丟棄響應(yīng)報(bào)文. 因此, 在RS配置VIP, 這樣響應(yīng)報(bào)文的源ip可以用VIP
2.確保前端路由器將目標(biāo)IP為VIP的請(qǐng)求報(bào)文發(fā)往Director, DR模型下, LVS和RS都會(huì)配置VIP, 因此會(huì)產(chǎn)生地址沖突
地址產(chǎn)生沖突的原因:
服務(wù)器網(wǎng)卡啟動(dòng)后, 會(huì)向局域網(wǎng)發(fā)送免費(fèi)arp, 探測(cè)網(wǎng)絡(luò)中是否有服務(wù)器和自己用了相同的ip地址
如果沒(méi)有服務(wù)器使用自己的ip, 那么會(huì)對(duì)外宣稱(chēng)自己的ip就是這個(gè)ip
如果有服務(wù)器使用了自己的ip, 那么就會(huì)發(fā)現(xiàn)地址沖突
解決地址沖突方法:
方法1: 在前端網(wǎng)關(guān)做靜態(tài)綁定VIP和Director的MAC地址 ,讓請(qǐng)求報(bào)文只轉(zhuǎn)發(fā)到LVS, 不轉(zhuǎn)發(fā)給RS
方法2: 在RS上使用arptables工具
arptables -A IN -d VIP -j DROP
arptables -A OUT -sVIP -j mangle --mangle-ip-s $RIP
方法3: 在RS上調(diào)整內(nèi)核參數(shù), 禁止RS服務(wù)器響應(yīng)免費(fèi)arp廣播, 禁止RS服務(wù)器發(fā)送免費(fèi)arp廣播
/proc/sys/net/ipv4/conf/all/arp_ignore
/proc/sys/net/ipv4/conf/all/arp_announce
3.RS的RIP可以使用私網(wǎng)地址逸寓，也可以是公網(wǎng)地址居兆；如果是私網(wǎng)地址, 那么RIP與DIP在同一IP網(wǎng)絡(luò)；RIP的網(wǎng)關(guān)不能指向DIP竹伸，而是指向前端路由器, 以確保響應(yīng)報(bào)文不會(huì)經(jīng)由Director
4.RS和Director要在同一個(gè)物理網(wǎng)絡(luò)
5.請(qǐng)求報(bào)文要經(jīng)由Director泥栖，但響應(yīng)報(bào)文不經(jīng)由Director，而由RS經(jīng)過(guò)路由器直接發(fā)往Client
6.不支持端口映射（端口不能修改）, DR模型, 修改的是二次的目標(biāo)MAC地址, 三層以上的信息不會(huì)修改, 因此vip監(jiān)聽(tīng)的端口和rs監(jiān)聽(tīng)的端口必須一致
7.RS可使用大多數(shù)OS系統(tǒng)
3.1.3 LVS的隧道模型
轉(zhuǎn)發(fā)方式：不修改請(qǐng)求報(bào)文的IP首部（源IP為CIP勋篓，目標(biāo)IP為VIP）吧享，而在原IP報(bào)文之外再封裝一個(gè)IP首部（源IP是DIP，目標(biāo)IP是RIP）譬嚣，將報(bào)文發(fā)往挑選出的目標(biāo)RS钢颂；RS直接響應(yīng)給客戶(hù)端（源IP是VIP，目標(biāo)IP是CIP）
TUN模式特點(diǎn)：
DIP, VIP, RIP是公網(wǎng)地址, 也可私網(wǎng)地址(需要拉專(zhuān)線)
RS的網(wǎng)關(guān)一般不能指向DIP, RS會(huì)直接響應(yīng)客戶(hù)端
rs的隧道接口上配置vip地址, 以便接受lvs轉(zhuǎn)發(fā)過(guò)來(lái)的數(shù)據(jù)包, 以及作為響應(yīng)報(bào)文的源ip
lvs轉(zhuǎn)發(fā)給rs時(shí)需要使用隧道, 隧道外層的ip頭部源ip是lvs的DIP, 目標(biāo)IP是RIP, 而RS響應(yīng)給客戶(hù)的報(bào)文的ip頭部是根據(jù)隧道內(nèi)層的ip頭分析得到的, 源ip是vip, 目標(biāo)ip是客戶(hù)端ip
請(qǐng)求報(bào)文要經(jīng)由Director拜银，但響應(yīng)不經(jīng)由Director
不支持端口映射
RS的OS須支持隧道功能
雖然LVS和RS都配置vip, 但是并不沖突, 因?yàn)長(zhǎng)VS和RS不在同一個(gè)物理網(wǎng)絡(luò)中
隧道模型雖然支持LVS和RS在同一個(gè)物理網(wǎng)段, 但是性能不如RS
因?yàn)樗淼滥Ｐ鸵砑觟p頭部, 而RS只是修改源,目mac, 通訊過(guò)程本身就是要修改mac地址的
LVS適合有多機(jī)房的大型企業(yè), 用戶(hù)可以訪問(wèn)固定的部署了lvs的機(jī)房, 之后lvs根據(jù)用戶(hù)的地址, 把請(qǐng)求調(diào)度到離用戶(hù)進(jìn)的機(jī)房, 回包直接送離用戶(hù)進(jìn)的機(jī)房返回給用戶(hù)
應(yīng)用場(chǎng)景:
一般來(lái)說(shuō), 隧道模式常會(huì)用來(lái)負(fù)載調(diào)度緩存服務(wù)器組, 這些緩存服務(wù)器一般放置在不同的網(wǎng)絡(luò)環(huán)境, 不同的機(jī)房, 可以就近返回給用戶(hù)
在請(qǐng)求對(duì)象不在緩存服務(wù)器本地命中的情況下, 緩存服務(wù)器要向源服務(wù)器發(fā)送請(qǐng)求, 將結(jié)果取回, 在本地緩存, 然后將結(jié)果返回給用戶(hù)
3.1.4 FullNAT模式
通過(guò)同時(shí)修改請(qǐng)求報(bào)文的源IP地址和目標(biāo)IP地址進(jìn)行轉(zhuǎn)發(fā)
CIP –> DIP
VIP –> RIP
特點(diǎn)：
1.VIP是公網(wǎng)地址殊鞭，RIP和DIP是私網(wǎng)地址，且通常不在同一IP網(wǎng)絡(luò)尼桶；因此操灿，RIP的網(wǎng)關(guān)一般不會(huì)指向DIP
2.RS收到的請(qǐng)求報(bào)文源地址是DIP，因此泵督，只需響應(yīng)給DIP趾盐；但Director還要將其發(fā)往Client
3.請(qǐng)求和響應(yīng)報(bào)文都經(jīng)由Director
4.相對(duì)NATi模式，可以更好的實(shí)現(xiàn)LVS-RealServer間跨VLAN通訊
5.支持端口映射
與NAT模式相比, FullNAT除了修改請(qǐng)求報(bào)文的目標(biāo)ip地址, 還會(huì)修改源ip地址
FullNAT下, RS看不到客戶(hù)端的ip, 因?yàn)長(zhǎng)VS會(huì)修改請(qǐng)求報(bào)文的源ip, 而NAT模式源ip不變, RS可以看到客戶(hù)端的ip地址
可以支持局域網(wǎng), 或者跨路由, 但是本身NAT模式也是都支持的, 因此, 一般FullNAT模式應(yīng)用場(chǎng)景不是很多
注意：此類(lèi)型kernel默認(rèn)不支持
3.1.5 不同工作模式的比較
LVS工作模式總結(jié)和比較
lvs-nat與lvs-fullnat：
請(qǐng)求和響應(yīng)報(bào)文都經(jīng)由Director
lvs-nat：RIP的網(wǎng)關(guān)要指向DIP
lvs-fullnat：RIP和DIP未必在同一IP網(wǎng)絡(luò)小腊，但要能通信
lvs-dr與lvs-tun：
請(qǐng)求報(bào)文要經(jīng)由Director救鲤，但響應(yīng)報(bào)文由RS直接發(fā)往Client
lvs-dr：通過(guò)封裝新的MAC首部實(shí)現(xiàn)，通過(guò)MAC轉(zhuǎn)發(fā)
lvs-tun：通過(guò)在原IP報(bào)文外封裝新IP頭實(shí)現(xiàn)轉(zhuǎn)發(fā)溢豆，支持遠(yuǎn)距離通信
3.2 LVS的調(diào)度算法
根據(jù)LVS調(diào)度時(shí)是否考慮各RS當(dāng)前的負(fù)載狀態(tài), 分為靜態(tài)算法和動(dòng)態(tài)算法
3.2.1 靜態(tài)算法
特點(diǎn): 僅根據(jù)算法本身進(jìn)行調(diào)度, 不考慮后端服務(wù)器當(dāng)前負(fù)載狀態(tài)
1、RR：roundrobin瘸羡，輪詢(xún)
2漩仙、WRR：Weighted RR，加權(quán)輪詢(xún)
3、SH：Source Hashing队他，實(shí)現(xiàn)session sticky卷仑，源IP地址hash；將來(lái)自于同一個(gè)IP地址的請(qǐng)求始終發(fā)往第一次挑中的RS麸折，從而實(shí)現(xiàn)會(huì)話綁定
4锡凝、DH：Destination Hashing；目標(biāo)地址哈希垢啼，第一次輪詢(xún)調(diào)度至RS窜锯，后續(xù)將發(fā)往同一個(gè)目標(biāo)地址的請(qǐng)求始終轉(zhuǎn)發(fā)至第一次挑中的RS，典型使用場(chǎng)景是正向代理緩存場(chǎng)景中的負(fù)載均衡芭析，如：寬帶運(yùn)營(yíng)商
把不同RS上的內(nèi)容, 緩存到不同的緩存服務(wù)器上, 讓LVS去調(diào)度這些緩存服務(wù)器, LVS會(huì)將用戶(hù)的請(qǐng)求按照其要訪問(wèn)的對(duì)象的ip地址進(jìn)行調(diào)度, 也就目標(biāo)地址hash
3.2.2 動(dòng)態(tài)算法
根據(jù)RS當(dāng)前的負(fù)載狀態(tài)及調(diào)度算法進(jìn)行調(diào)度Overhead=value 較小的RS將被調(diào)度
1锚扎、LC：least connections 適用于長(zhǎng)連接應(yīng)用
Overhead=activeconns*256+inactiveconns
2、WLC：Weighted LC馁启，默認(rèn)調(diào)度方法
Overhead=(activeconns*256+inactiveconns)/weight, 權(quán)重越高的服務(wù)器, 負(fù)載值越低, 越會(huì)被調(diào)度
3驾孔、SED：Shortest Expection Delay，初始連接高權(quán)重優(yōu)先, 只檢查活動(dòng)鏈接, 不考慮非活動(dòng)鏈接
Overhead=(activeconns+1)*256/weight
對(duì)于WLC算法來(lái)說(shuō), 當(dāng)多臺(tái)不同權(quán)重的服務(wù)器, 剛上線時(shí), 權(quán)重大的服務(wù)器會(huì)被優(yōu)先調(diào)度, 造成其承受過(guò)多的負(fù)載, 而權(quán)重小的服務(wù)器沒(méi)有請(qǐng)求調(diào)度
同時(shí), 非活動(dòng)鏈接對(duì)于服務(wù)器負(fù)載的消耗不是很大, 但是如果不考慮非活動(dòng)鏈接, 那么當(dāng)沒(méi)有活動(dòng)鏈接時(shí), 所有服務(wù)器的負(fù)載又都為0
因此, 在SED中, 使用活動(dòng)鏈接+1來(lái)避免當(dāng)活動(dòng)鏈接為0, 所有服務(wù)器負(fù)載都為0的情況. 讓權(quán)重高的主機(jī)優(yōu)先被調(diào)度
4惯疙、NQ：Never Queue翠勉，第一輪均勻分配，后續(xù)SED
避免權(quán)重高的機(jī)器, 前幾次都會(huì)被調(diào)度, 而其余服務(wù)器不會(huì)被調(diào)度
5霉颠、LBLC：Locality-Based LC对碌，動(dòng)態(tài)的DH算法，使用場(chǎng)景：根據(jù)負(fù)載狀態(tài)實(shí)現(xiàn)正向代理
6掉分、LBLCR：LBLC with Replication俭缓，帶復(fù)制功能的LBLC，解決LBLC負(fù)載不均衡問(wèn)題酥郭，從負(fù)載重的復(fù)制到負(fù)載輕的RS
內(nèi)核版本 4.15 版本后新增調(diào)度算法：FO和OVF
FO（Weighted Fail Over）調(diào)度算法,在此FO算法中华坦，遍歷虛擬服務(wù)所關(guān)聯(lián)的真實(shí)服務(wù)器鏈表，找到還未過(guò)載（未設(shè)置IP_VS_DEST_F_OVERLOAD標(biāo)志）的且權(quán)重最高的真實(shí)服務(wù)器不从，進(jìn)行調(diào)度. 不關(guān)心活動(dòng)鏈接數(shù), 只關(guān)系服務(wù)器的權(quán)重, 以及是否有過(guò)載標(biāo)記位, 類(lèi)似靜態(tài)算法
OVF（Overflow-connection）調(diào)度算法惜姐，基于真實(shí)服務(wù)器的活動(dòng)連接數(shù)量和權(quán)重值實(shí)現(xiàn)。將新連接調(diào)度到權(quán)重值最高的真實(shí)服務(wù)器椿息，直到其活動(dòng)連接數(shù)量超過(guò)權(quán)重值歹袁，之后調(diào)度到下一個(gè)權(quán)重值最高的真實(shí)服務(wù)器,在此OVF算法中，遍歷虛擬服務(wù)相關(guān)聯(lián)的真實(shí)服務(wù)器鏈表寝优，找到權(quán)重值最高的可用真實(shí)服務(wù)器条舔。屬于動(dòng)態(tài)的FO算法.
一個(gè)可用的真實(shí)服務(wù)器需要同時(shí)滿足以下條件：
未過(guò)載（未設(shè)置IP_VS_DEST_F_OVERLOAD標(biāo)志）, 如果過(guò)載, 會(huì)設(shè)置IP_VS_DEST_F_OVERLOAD標(biāo)記. 或者當(dāng)某個(gè)RS服務(wù)器需要做升級(jí)或維護(hù)時(shí), 可以加IP_VS_DEST_F_OVERLOAD標(biāo)記, 讓其不會(huì)調(diào)度, 等到升級(jí)或維護(hù)完成, 再繼續(xù)調(diào)度
真實(shí)服務(wù)器當(dāng)前的活動(dòng)連接數(shù)量小于其權(quán)重值
其權(quán)重值不為零
