1 四層負(fù)載均衡(轉(zhuǎn)發(fā))
主要通過報(bào)文中的目標(biāo)地址和端口，再加上負(fù)載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，決定最終選擇的內(nèi)部服務(wù)器。
- F5
- 硬件負(fù)載均衡器，功能很好，價(jià)格昂貴
- LVS
- 重量級(jí)的四層負(fù)載均衡器
- Nginx
- 輕量級(jí)的四層負(fù)載均衡器，帶緩存功能，正則表達(dá)式較靈活
- haproxy
- 模擬四層轉(zhuǎn)發(fā)，較靈活
2 七層負(fù)載均衡(代理)
所謂七層負(fù)載均衡，也稱為“內(nèi)容交換”，也就是主要通過報(bào)文中的真正有意義的應(yīng)用層內(nèi)容，再加上負(fù)載均衡設(shè)備設(shè)置的服務(wù)器選擇方式，決定最終選擇的內(nèi)部服務(wù)器。
- haproxy
- 全面支持七層負(fù)載均衡器，功能全面
- nginx
- 只在http協(xié)議和mail協(xié)議上功能比較好，性能與haproxy差不多
- apache
- 功能較差
- mysql proxy
- 功能尚可
3 負(fù)載均衡算法
- Round Robin輪詢：服務(wù)器性能均衡
- Random隨機(jī)
- 權(quán)重輪詢：性能好的服務(wù)器獲得較多請(qǐng)求
- 權(quán)重隨機(jī)
- 最少連接數(shù)均衡：當(dāng)前連接數(shù)最少的機(jī)器接收用戶請(qǐng)求，適合長(zhǎng)時(shí)間處理的請(qǐng)求服務(wù)，如FTP
- 一致性哈希：相同參數(shù)的請(qǐng)求總是發(fā)到同一服務(wù)器，當(dāng)該節(jié)點(diǎn)掛掉時(shí)基于虛擬節(jié)點(diǎn)，平攤到其他提供者
- IP散列：相同client請(qǐng)求發(fā)到同一server處理
- URL散列：發(fā)送至相同URL的請(qǐng)求轉(zhuǎn)發(fā)至同一服務(wù)器
- 響應(yīng)速度均衡：負(fù)載均衡器發(fā)送探測(cè)請(qǐng)求，響應(yīng)最快的服務(wù)器來接收用戶請(qǐng)求，反映了服務(wù)器當(dāng)前狀態(tài)。
- 處理能力均衡(CPU、內(nèi)存)：將請(qǐng)求發(fā)給處理負(fù)荷最輕的服務(wù)器，反映了服務(wù)器處理能力和當(dāng)前網(wǎng)絡(luò)現(xiàn)狀。
- DNS響應(yīng)均衡：最先收到域名解析IP地址來繼續(xù)請(qǐng)求服務(wù)
4 LVS原理
- LVS NAT模式
- LVS DR模式
- LVS TUN模式
- LVS FULLNAT模式
LVS，Linux Virtual Server，Linux虛擬機(jī)服務(wù)器，現(xiàn)在是Linux標(biāo)準(zhǔn)內(nèi)核的一部分，是一個(gè)虛擬的四層負(fù)載均衡器。
- ipvs ： 工作于內(nèi)核空間，主要用于使用戶定義的策略生效
- ipvsadm : 工作于用戶空間，主要用于用戶定義和管理集群服務(wù)的工具
4.1 LVS NAT模式
①.客戶端將請(qǐng)求發(fā)往前端的負(fù)載均衡器，請(qǐng)求報(bào)文源地址是CIP(客戶端IP),后面統(tǒng)稱為CIP)，目
標(biāo)地址為VIP(負(fù)載均衡器前端地址，后面統(tǒng)稱為VIP)。
②.負(fù)載均衡器收到報(bào)文后，發(fā)現(xiàn)請(qǐng)求的是在規(guī)則里面存在的地址，那么它將客戶端請(qǐng)求報(bào)文的目
標(biāo)地址改為了后端服務(wù)器的RIP 地址并將報(bào)文根據(jù)算法發(fā)送出去。
③.報(bào)文送到Real Server 后，由于報(bào)文的目標(biāo)地址是自己，所以會(huì)響應(yīng)該請(qǐng)求，并將響應(yīng)報(bào)文返還
給LVS。
④.然后lvs 將此報(bào)文的源地址修改為本機(jī)并發(fā)送給客戶端。
注意：在NAT 模式中，Real Server 的網(wǎng)關(guān)必須指向LVS，否則報(bào)文無法送達(dá)客戶端。
特點(diǎn)：
1、NAT 技術(shù)將請(qǐng)求的報(bào)文和響應(yīng)的報(bào)文都需要通過 LB 進(jìn)行地址改寫，因此網(wǎng)站訪問量比較大的
時(shí)候 LB 負(fù)載均衡調(diào)度器有比較大的瓶頸，一般要求最多之能 10-20 臺(tái)節(jié)點(diǎn)
2、只需要在 LB 上配置一個(gè)公網(wǎng) IP 地址就可以了。
3、每臺(tái)內(nèi)部的 realserver 服務(wù)器的網(wǎng)關(guān)地址必須是調(diào)度器 LB 的內(nèi)網(wǎng)地址。
4、NAT 模式支持對(duì) IP 地址和端口進(jìn)行轉(zhuǎn)換。即用戶請(qǐng)求的端口和真實(shí)服務(wù)器的端口可以不一致。
優(yōu)點(diǎn)：
集群中的物理服務(wù)器可以使用任何支持TCP/IP 操作系統(tǒng)，只有負(fù)載均衡器需要一個(gè)合法的IP 地
址。
缺點(diǎn)：
擴(kuò)展性有限。當(dāng)服務(wù)器節(jié)點(diǎn)（普通PC 服務(wù)器）增長(zhǎng)過多時(shí),負(fù)載均衡器將成為整個(gè)系統(tǒng)的瓶頸，因
為所有的請(qǐng)求包和應(yīng)答包的流向都經(jīng)過負(fù)載均衡器。當(dāng)服務(wù)器節(jié)點(diǎn)過多時(shí)，大量的數(shù)據(jù)包都交匯
在負(fù)載均衡器那，速度就會(huì)變慢！
4.2 LVS DR模式(局域網(wǎng)改寫MAC地址)
①.客戶端將請(qǐng)求發(fā)往前端的負(fù)載均衡器，請(qǐng)求報(bào)文源地址是CIP，目標(biāo)地址為VIP。
②.負(fù)載均衡器收到報(bào)文后，發(fā)現(xiàn)請(qǐng)求的是在規(guī)則里面存在的地址，那么它將客戶端請(qǐng)求報(bào)文的源
MAC 地址改為自己DIP 的MAC地址，目標(biāo)MAC改為了RIP 的MAC 地址，并將此包發(fā)送給RS。
③.RS 發(fā)現(xiàn)請(qǐng)求報(bào)文中的目的MAC 是自己，就會(huì)將次報(bào)文接收下來，處理完請(qǐng)求報(bào)文后，將響應(yīng)
報(bào)文通過lo 接口送給eth0 網(wǎng)卡直接發(fā)送給客戶端。
注意：需要設(shè)置lo 接口的VIP 不能響應(yīng)本地網(wǎng)絡(luò)內(nèi)的arp 請(qǐng)求。
總結(jié)：
1、通過在調(diào)度器 LB 上修改數(shù)據(jù)包的目的 MAC 地址實(shí)現(xiàn)轉(zhuǎn)發(fā)。注意源地址仍然是 CIP，目的地址
仍然是 VIP 地址。
2、請(qǐng)求的報(bào)文經(jīng)過調(diào)度器，而 RS 響應(yīng)處理后的報(bào)文無需經(jīng)過調(diào)度器 LB，因此并發(fā)訪問量大時(shí)使
用效率很高（和 NAT 模式比）
3、因?yàn)?DR 模式是通過 MAC 地址改寫機(jī)制實(shí)現(xiàn)轉(zhuǎn)發(fā)，因此所有 RS 節(jié)點(diǎn)和調(diào)度器 LB 只能在一個(gè)
局域網(wǎng)里面
4、RS 主機(jī)需要綁定 VIP 地址在 LO 接口（掩碼32 位）上，并且需要配置 ARP 抑制。
5、RS 節(jié)點(diǎn)的默認(rèn)網(wǎng)關(guān)不需要配置成 LB，而是直接配置為上級(jí)路由的網(wǎng)關(guān)，能讓 RS 直接出網(wǎng)就
可以。
6、由于 DR 模式的調(diào)度器僅做 MAC 地址的改寫，所以調(diào)度器 LB 就不能改寫目標(biāo)端口，那么 RS
服務(wù)器就得使用和 VIP 相同的端口提供服務(wù)。
7、直接對(duì)外的業(yè)務(wù)比如WEB 等，RS 的IP 最好是使用公網(wǎng)IP。對(duì)外的服務(wù)，比如數(shù)據(jù)庫等最好
使用內(nèi)網(wǎng)IP。
優(yōu)點(diǎn)：
- 和TUN（隧道模式）一樣，負(fù)載均衡器也只是分發(fā)請(qǐng)求，應(yīng)答包通過單獨(dú)的路由方法返回給客戶
端。與VS-TUN 相比，VS-DR 這種實(shí)現(xiàn)方式不需要隧道結(jié)構(gòu)，因此可以使用大多數(shù)操作系統(tǒng)做為
物理服務(wù)器。 - DR 模式的效率很高，但是配置稍微復(fù)雜一點(diǎn)，因此對(duì)于訪問量不是特別大的公司可以用
haproxy/nginx 取代。日1000-2000W PV或者并發(fā)請(qǐng)求1 萬一下都可以考慮用haproxy/nginx。
缺點(diǎn)：
所有 RS 節(jié)點(diǎn)和調(diào)度器 LB 只能在一個(gè)局域網(wǎng)里面
4.3 LVS TUN模式(IP封裝、跨網(wǎng)段)
①.客戶端將請(qǐng)求發(fā)往前端的負(fù)載均衡器，請(qǐng)求報(bào)文源地址是CIP，目標(biāo)地址為VIP。
②.負(fù)載均衡器收到報(bào)文后，發(fā)現(xiàn)請(qǐng)求的是在規(guī)則里面存在的地址，那么它將在客戶端請(qǐng)求報(bào)文的
首部再封裝一層IP 報(bào)文,將源地址改為DIP，目標(biāo)地址改為RIP,并將此包發(fā)送給RS。
③.RS 收到請(qǐng)求報(bào)文后，會(huì)首先拆開第一層封裝,然后發(fā)現(xiàn)里面還有一層IP 首部的目標(biāo)地址是自己
lo 接口上的VIP，所以會(huì)處理次請(qǐng)求報(bào)文，并將響應(yīng)報(bào)文通過lo 接口送給eth0 網(wǎng)卡直接發(fā)送給客
戶端。
注意：需要設(shè)置lo 接口的VIP 不能在共網(wǎng)上出現(xiàn)。
總結(jié)：
1.TUNNEL 模式必須在所有的 realserver 機(jī)器上面綁定 VIP 的 IP 地址
2.TUNNEL 模式的 vip ------>realserver 的包通信通過 TUNNEL 模式，不管是內(nèi)網(wǎng)和外網(wǎng)都能通
信，所以不需要 lvs vip 跟 realserver 在同一個(gè)網(wǎng)段內(nèi)。
3.TUNNEL 模式 realserver 會(huì)把 packet 直接發(fā)給 client 不會(huì)給 lvs 了
4.TUNNEL 模式走的隧道模式，所以運(yùn)維起來比較難，所以一般不用。
優(yōu)點(diǎn)：
負(fù)載均衡器只負(fù)責(zé)將請(qǐng)求包分發(fā)給后端節(jié)點(diǎn)服務(wù)器，而RS 將應(yīng)答包直接發(fā)給用戶。所以，減少了負(fù)載均衡器的大量數(shù)據(jù)流動(dòng)，負(fù)載均衡器不再是系統(tǒng)的瓶頸，就能處理很巨大的請(qǐng)求量，這種方式，一臺(tái)負(fù)載均衡器能夠?yàn)楹芏郣S 進(jìn)行分發(fā)。而且跑在公網(wǎng)上就能進(jìn)行不同地域的分發(fā)。
缺點(diǎn)：
隧道模式的RS 節(jié)點(diǎn)需要合法IP，這種方式需要所有的服務(wù)器支持”IP Tunneling”(IP
Encapsulation)協(xié)議，服務(wù)器可能只局限在部分Linux 系統(tǒng)上。
4.4 LVS FULLNAT模式
無論是 DR 還是 NAT 模式，不可避免的都有一個(gè)問題：LVS 和 RS 必須在同一個(gè) VLAN 下，否則
LVS 無法作為 RS 的網(wǎng)關(guān)。這引發(fā)的兩個(gè)問題是：
1、同一個(gè) VLAN 的限制導(dǎo)致運(yùn)維不方便，跨 VLAN 的 RS 無法接入。
2、LVS 的水平擴(kuò)展受到制約。當(dāng) RS 水平擴(kuò)容時(shí)，總有一天其上的單點(diǎn) LVS 會(huì)成為瓶頸。
Full-NAT 由此而生，解決的是 LVS 和 RS 跨 VLAN 的問題，而跨 VLAN 問題解決后，LVS 和 RS
不再存在 VLAN 上的從屬關(guān)系，可以做到多個(gè) LVS 對(duì)應(yīng)多個(gè) RS，解決水平擴(kuò)容的問題。
Full-NAT 相比 NAT 的主要改進(jìn)是，在 SNAT/DNAT 的基礎(chǔ)上，加上另一種轉(zhuǎn)換，轉(zhuǎn)換過程如下：
- 在包從 LVS 轉(zhuǎn)到 RS 的過程中，源地址從客戶端 IP 被替換成了 LVS 的內(nèi)網(wǎng) IP。內(nèi)網(wǎng) IP 之間
可以通過多個(gè)交換機(jī)跨 VLAN 通信。目標(biāo)地址從VIP 修改為RS IP. - 當(dāng) RS 處理完接受到的包，處理完成后返回時(shí)，將目標(biāo)地址修改為L(zhǎng)VS ip，原地址修改為RS
IP，最終將這個(gè)包返回給 LVS 的內(nèi)網(wǎng) IP，這一步也不受限于 VLAN。 - LVS 收到包后，在 NAT 模式修改源地址的基礎(chǔ)上，再把 RS 發(fā)來的包中的目標(biāo)地址從 LVS 內(nèi)
網(wǎng) IP 改為客戶端的 IP,并將原地址修改為VIP。
Full-NAT 主要的思想是把網(wǎng)關(guān)和其下機(jī)器的通信，改為了普通的網(wǎng)絡(luò)通信，從而解決了跨 VLAN
的問題。采用這種方式，LVS 和 RS 的部署在 VLAN 上將不再有任何限制，大大提高了運(yùn)維部署的
便利性。
總結(jié)
- FULL NAT 模式不需要 LBIP 和 realserver ip 在同一個(gè)網(wǎng)段；
- full nat 因?yàn)橐?sorce ip 所以性能正常比 nat 模式下降 10%
5 Keepalive原理
- Keepalived是Linux下一個(gè)輕量級(jí)別的高可用解決方案。雖然它沒有HeartBeat功能強(qiáng)大，但是Keepalived部署和使用非常的簡(jiǎn)單，所有配置只需要一個(gè)配置文件即可以完成。
- keepalive 起初是為L(zhǎng)VS 設(shè)計(jì)的，專門用來監(jiān)控lvs 各個(gè)服務(wù)節(jié)點(diǎn)的狀態(tài)，后來加入了vrrp 的功能，因此除了lvs，也可以作為其他服務(wù)（nginx，haproxy）的高可用軟件。
- VRRP 是virtual router redundancy protocal（虛擬路由器冗余協(xié)議）的縮寫。VRRP 的出現(xiàn)就是為了解決靜態(tài)路由出現(xiàn)的單點(diǎn)故障，它能夠保證網(wǎng)絡(luò)可以不間斷的穩(wěn)定的運(yùn)行。所以keepalive 一方面具有LVS cluster node healthcheck 功能，另一方面也具有LVS director failover。
5.1 keepalived體系結(jié)構(gòu)
keepalived運(yùn)行時(shí)，會(huì)啟動(dòng)3個(gè)進(jìn)程，分別為：core(核心進(jìn)程)，check和vrrp.
- core：負(fù)責(zé)主進(jìn)程的啟動(dòng)，維護(hù)和全局配置文件的加載；
- check：負(fù)責(zé)健康檢查
- vrrp：用來實(shí)現(xiàn)vrrp協(xié)議
5.2 Keepalvied的工作原理
網(wǎng)絡(luò)層：Keepalived通過ICMP協(xié)議向服務(wù)器集群中的每一個(gè)節(jié)點(diǎn)發(fā)送一個(gè)ICMP數(shù)據(jù)包(有點(diǎn)類似與Ping的功能)，如果某個(gè)節(jié)點(diǎn)沒有返回響應(yīng)數(shù)據(jù)包，那么認(rèn)為該節(jié)點(diǎn)發(fā)生了故障，Keepalived將報(bào)告這個(gè)節(jié)點(diǎn)失效，并從服務(wù)器集群中剔除故障節(jié)點(diǎn)。
傳輸層：Keepalived在傳輸層里利用了TCP協(xié)議的端口連接和掃描技術(shù)來判斷集群節(jié)點(diǎn)的端口是否正常，比如對(duì)于常見的WEB服務(wù)器80端口?；蛘逽SH服務(wù)22端口，Keepalived一旦在傳輸層探測(cè)到這些端口號(hào)沒有數(shù)據(jù)響應(yīng)和數(shù)據(jù)返回，就認(rèn)為這些端口發(fā)生異常，然后強(qiáng)制將這些端口所對(duì)應(yīng)的節(jié)點(diǎn)從服務(wù)器集群中剔除掉。
應(yīng)用層：Keepalived的運(yùn)行方式也更加全面化和復(fù)雜化，用戶可以通過自定義Keepalived工作方式，例如：可以通過編寫程序或者腳本來運(yùn)行Keepalived，而Keepalived將根據(jù)用戶的設(shè)定參數(shù)檢測(cè)各種程序或者服務(wù)是否允許正常，如果Keepalived的檢測(cè)結(jié)果和用戶設(shè)定的不一致時(shí)，Keepalived將把對(duì)應(yīng)的服務(wù)器從服務(wù)器集群中剔除。
5.3 VRRP選舉機(jī)制
VRRP路由器在運(yùn)行過程中有三種狀態(tài)：
- Initialize狀態(tài)： 系統(tǒng)啟動(dòng)后就進(jìn)入Initialize，此狀態(tài)下路由器不對(duì)VRRP報(bào)文做任何處理；
- Master狀態(tài)；
- Backup狀態(tài)；
一般主路由器處于Master狀態(tài)，備份路由器處于Backup狀態(tài)。
VRRP使用選舉機(jī)制來確定路由器的狀態(tài)，優(yōu)先級(jí)選舉：
- VRRP組中IP擁有者。如果虛擬IP地址與VRRP組中的某臺(tái)VRRP路由器IP地址相同，則此路由器為IP地址擁有者，這臺(tái)路由器將被定位主路由器。
- 比較優(yōu)先級(jí)。如果沒有IP地址擁有者，則比較路由器的優(yōu)先級(jí)，優(yōu)先級(jí)的范圍是0~255，優(yōu)先級(jí)大的作為主路由器
- 比較IP地址。在沒有Ip地址擁有者和優(yōu)先級(jí)相同的情況下，IP地址大的作為主路由器。
5.4 keepalived & heartbeat
Heartbeat、Corosync是屬于同一類型，Keepalived與Heartbeat、Corosync，根本不是同一類型的。Keepalived使用的vrrp虛擬路由冗余協(xié)議方式；Heartbeat或Corosync是基于主機(jī)或網(wǎng)絡(luò)服務(wù)的高可用方式；簡(jiǎn)單的說就是，Keepalived的目的是模擬路由器的高可用，Heartbeat或Corosync的目的是實(shí)現(xiàn)Service的高可用。
一般Keepalived是實(shí)現(xiàn)前端高可用，常用的前端高可用的組合有，就是我們常見的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是實(shí)現(xiàn)服務(wù)的高可用，常見的組合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 實(shí)現(xiàn)Web服務(wù)器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 實(shí)現(xiàn)MySQL服務(wù)器的高可用。
總結(jié)一下，Keepalived中實(shí)現(xiàn)輕量級(jí)的高可用，一般用于前端高可用，且不需要共享存儲(chǔ)，一般常用于兩個(gè)節(jié)點(diǎn)的高可用。而Heartbeat(或Corosync)一般用于服務(wù)的高可用，且需要共享存儲(chǔ)，一般用于多節(jié)點(diǎn)的高可用。
6 HeartBeat原理
- 心跳檢測(cè)
- 資源管理
7 HAProxy原理
HAProxy 的優(yōu)點(diǎn)能夠補(bǔ)充 Nginx 的一些缺點(diǎn)，比如支持 Session 的保持，Cookie 的引導(dǎo);同時(shí)支持通過獲取指定的 URL 來檢測(cè)后端服務(wù)器的狀態(tài)。
HAProxy 跟 LVS 類似，本身就只是一款負(fù)載均衡軟件;單純從效率上來講 HAProxy 會(huì)比 Nginx 有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于 Nginx 的。
HAProxy 支持 TCP 協(xié)議的負(fù)載均衡轉(zhuǎn)發(fā)，可以對(duì) MySQL 讀進(jìn)行負(fù)載均衡，對(duì)后端的 MySQL 節(jié)點(diǎn)進(jìn)行檢測(cè)和負(fù)載均衡，可以用 LVS+Keepalived 對(duì) MySQL 主從做負(fù)載均衡。
7.1 會(huì)話保持方案
同一客戶端訪問服務(wù)器，Haproxy保持回話的三種方案：
- Haproxy將客戶端ip進(jìn)行Hash計(jì)算并保存，由此確保相同IP訪問時(shí)被轉(zhuǎn)發(fā)到同一真實(shí)服務(wù)器上。
- Haproxy依靠真實(shí)服務(wù)器發(fā)送給客戶端的cookie信息進(jìn)行回話保持。
- Haproxy保存真實(shí)服務(wù)器的session及服務(wù)器標(biāo)識(shí)，實(shí)現(xiàn)會(huì)話保持功能。
7.2 Haproxy代理模式
- 四層tcp代理：Haproxy僅在客戶端和服務(wù)器之間雙向轉(zhuǎn)發(fā)流量，可用于郵件服務(wù)內(nèi)部協(xié)議通信服務(wù)器、Mysql服務(wù)等；
- 七層應(yīng)用代理：Haproxy會(huì)分析應(yīng)用層協(xié)議，并且能通過運(yùn)行、拒絕、交換、增加、修改或者刪除請(qǐng)求（request）或者回應(yīng)（reponse）里指定內(nèi)容來控制協(xié)議?？捎糜贖TTP代理或https代理。
7.3 haproxy、Nginx、LVS比較
- 大型網(wǎng)站架構(gòu)：對(duì)性能有嚴(yán)格要求的時(shí)候可以使用lvs或者硬件F5，單從負(fù)載均衡的角度來說，lvs也許會(huì)成為主流，更適合現(xiàn)在大型的互聯(lián)網(wǎng)公司；
- 中型網(wǎng)站架構(gòu)：對(duì)于頁面分離請(qǐng)求由明確規(guī)定，并且性能有嚴(yán)格要求時(shí)，可以使用haproxy
- 中小型網(wǎng)站架構(gòu)：比如日訪問量小于1000萬，需要進(jìn)行高并發(fā)的網(wǎng)站或者對(duì)網(wǎng)絡(luò)不太嚴(yán)格的時(shí)候，可以使用nginx
8 Nginx原理
- 反向代理
- 負(fù)載均衡
9 nginx反向代理怎么配置
- upstream_module：負(fù)載均衡
- proxy_pass：請(qǐng)求轉(zhuǎn)發(fā)
10 nginx反向代理怎么知道其中一臺(tái)tomcat掛掉了？
Nginx配置這兩個(gè)參數(shù)，可以查看到請(qǐng)求落在了后端的具體哪個(gè)server上。
- upstream_addr
- upstream_status
