一、四層負載均衡和七層負載均衡
1.四層負載均衡（目標地址和埠交換）
主要通過報文中的目標地址和埠，再加上負載均衡設備設定的服務器選擇方式，決定最終選擇的內部服務器，
以常見的TCP為例，負載均衡設備在接收到第一個來自客戶端的SYN請求時，即通過上述方式選擇一個最佳的服務器，并對報文中的目標IP地址進行修改（改為后端服務器IP）直接轉發給該服務器，TCP的連接建立，即三次握手是客戶端和服務器直接建立的，負載均衡只是起到一個類似路由器的轉發動作，在某些部署情況下，為保證服務器回包可以正確回傳給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改，
實作四層負載均衡的軟體有：
F5：硬體負載均衡器，功能好，但成本很高；
LVS：重量級的四層負載軟體
Nginx：輕量級的四層負載軟體，帶快取功能，正則運算式較靈活；
haproxy：模擬四層轉發，較靈活；
2.七層負載均衡（內容交換）
所謂七層負載均衡，也稱為“內容交換”，也就是主要通過報文中真正有意義的應用層內容，再加上負載均衡設備設定的服務器選擇方式，決定最終選擇的內部服務器，
七層應用負載的好處，是使得整個網路更加智能化，例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片服務器并可以使用快取技術；將對文字類的請求可以轉發到特定的文字服務器并可以使用壓縮技術，實作七層負載均衡的軟體有：
haproxy：天生七層負載均衡技能，全面支持七層代理、會話支持、標記，路徑轉移；
Nginx：只在HTTP協議和mail協議上功能比較好，性能與haproxy差不多；
apache：功能較差；
MySQL proxy：功能尚可；
二、負載均衡演算法/策略
1.輪循均衡（Round Robin）
每一次來自網路的請求輪流分配給內部服務器，從1到N，然后重新開始，此種均衡演算法適用于服務器組中的所有服務器都有相同的軟硬體配置并且平均服務請求相對均衡的情況；
2.權重輪循均衡（Weighted Round Robin）
根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求，例如：服務器A的權值被設成1，B的權值是3，C的權值是6，則服務器A，B，C將分別接受10%，30%，60%的服務請求，此種均衡演算法確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重，
3.隨機均衡（Random）
把來自網路的請求隨機分配給內部的多個服務器，
4.權重隨即均衡（Weighted Random）
此種均衡演算法類似于權重輪循演算法，不過在處理請求分但時是個隨機選擇的程序，
5.回應速度均衡（Response Time 探測時間）
負載均衡設備對內部各服務器發出一個探測請求（例如ping），然后根據內部中各服務器對探測請求的最快回應時間來決定哪一臺服務器來回應客戶端的服務請求，此種均衡演算法能較好地反映服務器的當前運行狀態，但這最快回應時間僅僅指的是負載均衡設備與服務期間的最快回應時間，而不是客戶端與服務器間的最快回應時間，
6.最少連接數均衡（Least Connection）
最少連接數均衡演算法對內部中需負載的每一臺服務器都有一個資料記錄，記錄當前該服務器正在處理的連接數量，當有新的服務器請求時，將把當前請求分配給連接數最少的服務器，使均衡更加符合實際情況，負載更加均衡，此種均衡演算法適合長時處理的請求服務，如FTP，
7.處理能力均衡（CPU、記憶體）
此種均衡演算法將服務請求分配給內部中處理負荷（根據服務器CPU型號、CPU數量、記憶體大小及當前連接數等換算而成）最輕的服務器，由于考慮了內部服務器的處理能力及當前網路運行狀況，所以此種均衡演算法相對來說更加精確，尤其適合運用到第七層（應用層負載均衡的情況下），
8.DNS回應均衡（Flash DNS）
在此均衡演算法下，分處在不同地地理位置的負載均衡設備收到同一個客戶端的域名決議請求，并在同一時間把此域名決議成各個相對應服務器的IP地址并回傳給客戶端，則客戶端將以最先收到的域名決議IP地址來繼續請求服務，而忽略其他的IP地址回應，此種均衡策略適用于在全域負載均衡的情況下，對本地負載均衡是沒有意義的，
9.哈希演算法
一致性哈希，相同引數的請求總是發到同一提供者，當某一臺提供者掛時，原本發往該提供者的請求，基于虛擬節點，平攤到其他提供者，不會引起劇烈變動，
10.IP地址散列（保證客戶端服務器對應關系穩定）
通過管理發送方IP和目的地IP地址的散列，將來自同一發送方的分組（或發送至同一目的地的分組）統一轉發到相同服務器的演算法，當客戶端有一系列業務需要處理而必須和一個服務器反復通信時，該演算法能夠以流（會話）為單位，保證來自相同客戶端的通信能夠一直在同一服務器中進行處理，
11.URL散列
通過管理客戶端請求URL資訊的散列，將發送至相同URL的請求轉發至同一服務器的演算法，
三、LVS
1.LVS原理
IPVS
LVS的IP負載均衡技術是通過IPVS模式來實作的，IPVS是LVS集群系統的核心軟體，它的主要作用是：安裝在Director Server上，同時在Director server上虛擬出一個IP地址，用戶必須通過這個虛擬的IP地址訪問服務器，這個虛擬IP一般稱為LVS的VIP，即Virtual IP，訪問的請求首先經過VIP到達負載調度器，然后由負載調度器從Real Server串列中選取一個服務節點回應用戶的請求，在用戶的請求到達負載調度器后，調度器如何將請求發送到提供服務的Real server節點，而real server節點如何回傳資料給用戶，是IPVS實作的重點技術，
ipvs：作業于內核空間，主要用于使用戶定義的策略生效，
ipvsadm：作業于用戶空間，主要用于用戶定義和管理集群服務的工具，
ipvs作業于內核空間的INPUT鏈上，當收到用戶請求某集群服務時，經過PREROUTING鏈，經檢查本機路由表，送往INPUT鏈；在進入netfilter的INPUT鏈時，ipvs強行將請求報文通過ipvsadm定義的集群服務策略的路徑改為FORWORD鏈，將報文轉發至后端真實提供服務的主機，
2.LVS NAT模式
1）客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP（客戶端IP），目標地址為VIP（負載均衡器前端地址），
2）負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將客戶端請求報文的目標地址改為了后端服務器的RIP地址并將報文根據演算法發送出去，
3）報文送到Real Server后，由于報文的目標地址是自己，所以會回應該請求，并將回應報文返還給LVS，
4）然后LVS將此報文的源地址修改為本機并發送給客戶端，
注意：在NAT模式中，Real Server的網關必須指向LVS，否則報文無法送達客戶端，
特點：
1）NAT技術將請求的報文和回應的報文都需要通過LB進行地址改寫，因此網站訪問量比較大時LB負載均衡調度器有比較大的瓶頸，一般要求最多只能10-20臺節點，
2）只需要在LB上配置一個公網IP地址就可以了，
3）每臺內部的realserver服務器的網關地址必須是調度器LB的內網地址，
4）NAT模式支持對IP地址和埠進行轉換，即用戶請求的埠和真實服務器的埠可以不一致，
優點：集群中的物理服務器可以使用任何支持TCP/IP作業系統，只有負載均衡器需要一個合法的IP地址，
缺點：擴展性有限，當服務器節點（普通PC服務器）增長過多時，負載均衡器將成為整個系統的瓶頸，因為所有請求包和應答包的流向都經過負載均衡器，當服務器節點過多時，大量的資料包都交匯在負載均衡器那，速度就會變慢！
3.LVS DR模式（局域網改寫mac地址）
1）客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP，
2）負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將客戶端請求報文的源MAC地址改為自己DIP的MAC地址，目標MAC改為RIP的MAC地址，并將此包發送給RS，
3）RS發現請求報文中的目的MAC是自己，就會將此報文接收下來，處理完請求報文后，將回應報文通過io介面送給eth0網卡直接發送給客戶端，
注意：需要設定io介面的VIP不能回應本地網路內的ARP請求，
總結：
1）通過在調度器LB上修改資料包的目的MAC地址實作轉發，注意源地址仍然是CIP，目的地址仍然是VIP地址，
2）請求的報文經過調度器，而RS回應處理后的報文無需經過調度器LB，因此并發訪問量大時使用效率高（和NAT模式相比）
3）因為DR模式是通過MAC地址改寫機制實作轉發，因此所有RS節點和調度器LB只能在一個局域網里面，
4）RS主機需要系結VIP地址在LO介面（掩碼32位）上，并且需要配置ARP抑制，
5）RS節點的默認網關不需要配置成LB，而是直接配置為上級路由的網關，能讓RS直接出網就可以，
6）由于DR模式的調度器僅做MAC地址的改寫，所以調度器LB就不能改寫目標埠，那么RS服務器就得使用和VIP相同得埠提供服務，
7）直接對外的業務比如WEB等，RS得IP最好是使用公網IP，對外的服務，比如資料庫等最好使用內網IP，
優點：和TUN（隧道模式）一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法回傳給客戶端，與VS-TUN相比，VS-DR這種實作方式不需要隧道結構，因此可以使用大多數作業系統作為物理服務器，DR模式的效率很高，但是配置稍微復雜一點，因此對于訪問量不是特別大的公司可以用haproxy/nginx取代，
缺點：所有RS節點和調度器LB只能在一個局域網里面
4.LVS TUN（IP封裝、跨網段）
1）客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP，
2）負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將在客戶端請求報文的首部再封裝一層IP報文，將源地址改為DIP，目標地址改為RIP，并將此包發送給RS，
3）RS收到請求報文后，會首先拆開第一層封裝，然后發現里面還有一層IP首部的目標地址是自己lo介面上的VIP，所以會處理此請求報文，并將回應報文通過lo介面送給eth0網卡直接發送給客戶端，
注意：需要設定lo介面的VIP不能再公網上出現，
總結：
1）TUNNEL模式必須在所有的realserver機器上面系結VIP的IP地址
2）TUNNEL模式的VIP----->realserver的包通信通過TUNNRL模式，不管是內網和外網都能通信，所以不需要lvs vip跟realserver在同一個網段內，
3）TUNNEL模式realserver會把packet直接發送給client不會給LVS了
4）TUNNEL模式走的隧道模式，所以運維起來比較難，所以一般不用，
優點：負載均衡器只負責將請求報分發給后端節點服務器，而RS將應答包直接發給用戶，所以，減少了負載均衡器的大量資料流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器能夠為很多RS進行分發，而且跑在公網上就能進行不同地域的分發，
缺點：隧道模式的RS節點需要合法IP，這種方式需要所有的服務器支持“IP Tunneling”（IP Encapsulation）協議，服務器可能只局限在部分Linux系統上，
5.LVS FULLNAT模式
無論是DR還是NAT模式，不可避免的都有一個問題：LVS和RS必須在同一個VLAN下，否則LVS無法作為RS的網關，這引發的兩個問題是：
1）同一個VLAN的限制導致運維不方便，跨VLAN的RS無法接入，
2）LVS的水平擴展受到制約，當RS水平擴容時，總有一天其上的單點LVS會成為瓶頸，
Full-NAT由此而生，解決的是LVS和RS跨VLAN的問題，而跨VLAN的問題解決后，LVS和RS不再存在VLAN上的從屬關系，可以做到多個LVS對應多個RS，解決水平擴容的問題，
Full-NAT相比NAT的主要改進是，在SNAT/DNAT的基礎上，加上另一種轉換，轉換程序如下：
1）在包從LVS轉到RS的程序中，源地址從客戶端IP被替換成了LVS的內網IP，內網IP之間可以通過多個交換機跨VLAN通信，目標地址從VIP修改為RS IP，
2）當RS處理完接受到的包，處理完成后回傳時，將目標地址修改為LVS IP，源地址修改為RS IP，最終將這個包回傳給LVS的內網IP，這一步也不受限于VLAN，
3）LVS收到包后，在NAT模式修改源地址的基礎上，再把RS發來的包中的目標地址從LVS內網IP改為客戶端的IP，并將源地址修改為VIP，
Full-NAT主要的思想是把網關和其下機器的通信，改為了普通的網路通信，從而解決了跨VLAN的問題，采用這種方式，LVS和RS的部署在VLAN上將不再有任何限制，大大提高了運維部署的便利性，
總結：
1）FULL NAT模式不需要LBIP和realserver IP在同一個網段，
2）FULL NAT因為要更新sorce IP 所以性能正常比NAT模式下降10%，
四、KeepAlive
keepalive起初是為LVS設計的，專門用來監控LVS各個服務節點的狀態，后來加入了VRRP的功能，因此除了LVS，也可以作為其他服務的高可用軟體，VRRP是虛擬路由器冗余協議，VRRP的出現就是為了解決靜態路由出現的單點故障，它能夠保證網路可以不間斷的穩定的運行，所以keepalive一方面具有LVS cluster node healthcheck 功能，另一方面也具有LVS director failover，
五、Nginx反向代理負載均衡
普通的負載均衡軟體，如LVS，其實作的功能只是對請求資料包的轉發、傳遞，從負載均衡下的節點服務器來看，接收到的請求還是來自訪問負載均衡器的客戶端的真實用戶；而反向代理就不一樣了，反向代理服務器在接受訪問用戶為請求后，會代理用戶重新發起請求代理下的節點服務器，最后把資料回傳給客戶端用戶，在節點服務器看來，訪問的節點服務器的客戶端用戶就是反向代理服務器，而非真實的網站訪問用戶，
1.upstream_module和健康監測
ngx_http_upstream_module是負載均衡模塊，可以實作網站的負載均衡功能，即節點的健康檢查，upstream模塊允許Nginx定義一組或多組節點服務器組，使用時可通過proxy_pass代理方式把網站的請求發送到事先定義好的對應upstream組的名字上，
2.proxy_pass請求轉發
proxy_pass指令屬于ngx_http_proxy_module模塊，此模塊可以將請求轉發到另一臺服務器，在實際的反向代理作業中，會通過location功能匹配指定的URI，然后把接收到服務匹配URI的請求通過proxy_pass拋給定義的upstream節點池，
location /download/{
proxy_pass http://download/video/;
}
#這是前端代理節點的設定
#交給后端upstream為download的節點
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/175737.html
標籤：其他