負載均衡

1、四層負載均衡和七層負載均衡

　　

1.四層負載均衡（目標地址和端口交換）

　　主要經過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

　　以常見的TCP爲例，負載均衡設備在接收到第一個來自客戶端的SYN請求時，即經過上述方式選擇一個最佳的服務器，並對報文中的目標IP地址進行修改（改成後端服務器IP）直接轉發給該服務器。TCP的鏈接創建，即三次握手是客戶端和服務器直接創建的，負載均衡只是起到一個相似路由器的轉發動做。在某些部署狀況下，爲保證服務器回包能夠正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。

　　實現四層負載均衡的軟件有：

　　　　F5：硬件負載均衡器，功能好，但成本很高；

　　　　LVS：重量級的四層負載軟件

　　　　Nginx：輕量級的四層負載軟件，帶緩存功能，正則表達式較靈活；

　　　　haproxy：模擬四層轉發，較靈活；

2.七層負載均衡（內容交換）

　　所謂七層負載均衡，也稱爲「內容交換」，也就是主要經過報文中真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

　　七層應用負載的好處，是使得整個網絡更加智能化。例如訪問一個網站的用戶流量，能夠經過七層的方式，將對圖片類的請求轉發到特定的圖片服務器並可使用緩存技術；將對文字類的請求能夠轉發到特定的文字服務器並可使用壓縮技術。實現七層負載均衡的軟件有：

　　　　haproxy：天生七層負載均衡技能，全面支持七層代理、會話支持、標記，路徑轉移；

　　　　Nginx：只在HTTP協議和mail協議上功能比較好，性能與haproxy差很少；

　　　　apache：功能較差；

　　　　MySQL proxy：功能尚可；

2、負載均衡算法/策略

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的請求轉發至同一服務器的算法。

3、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%。

4、KeepAlive

　　keepalive起初是爲LVS設計的，專門用來監控LVS各個服務節點的狀態，後來加入了VRRP的功能，所以除了LVS，也能夠做爲其餘服務的高可用軟件。VRRP是虛擬路由器冗餘協議。VRRP的出現就是爲了解決靜態路由出現的單點故障，它可以保證網絡能夠不間斷的穩定的運行。因此keepalive一方面具備LVS cluster node healthcheck 功能，另外一方面也具備LVS director failover。

5、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的節點