負載均衡學習筆記
一、總體介紹
1.1 定義
1.1.1 Load balancing
Load Balancing is the process of distributing data across disparate services to provide redundancy, reliability, and improve performance.
The entire intent of load balancing is to create a system that virtualizes the "service" from the physical servers that actually run that service. A more basic definition is to balance the load across a bunch of physical servers
and make those servers look like one great big server to the outside world. There are many reasons to do this, but the primary drivers can be summarized as "scalability," "high availability," and "predictability."
Scalability is the capability of dynamically, or easily, adapting to increased load without impacting existing performance. Service virtualization presented an interesting opportunity for scalability; if the service, or the
point of user contact, was separated from the actual servers, scaling of the application would simply mean adding more servers or cloud resources which would not be visible to the end user.
High Availability (HA) is the capability of a site to remain available and accessible even during the failure of one or more systems. Service virtualization also presented an opportunity for HA; if the point of user contact
was separated from the actual servers, the failure of an individual server would not render the entire application unavailable. Predictability is a little less clear as it represents pieces of HA as well as some lessons learned along the way. However, predictability
can best be described as the capability of having confidence and control in how the services are being delivered and when they are being delivered in regards to availability, performance, and so on.
1.1.2 Load balancer
A load balancer is a device that acts as a reverse proxy and distributes network or application traffic across a number of servers.
Load balancers are used to increase capacity (concurrent users) and reliability of applications. They improve the overall performance of applications by decreasing the burden on servers associated with managing and maintaining
application and network sessions, as well as by performing application-specific tasks.
Load balancers are generally grouped into two categories: Layer 4 and Layer 7. Layer 4 load balancers act upon data found in network and transport layer protocols (IP, TCP, FTP, UDP). Layer 7 load balancers distribute requests
based upon data found in application layer protocols such as HTTP.
Requests are received by both types of load balancers and they are distributed to a particular server based on a configured algorithm. Some industry standard algorithms are:
Ø Round robin
Ø Weighted round robin
Ø Least connections
Ø Least response time
Layer 7 load balancers can further distribute requests based on application specific data such as HTTP headers, cookies, or data within the application message itself, such as the value of a specific parameter.
Load balancers ensure reliability and availability by monitoring the "health" of applications and only sending requests to servers and applications that can respond in a timely manner.
1.2 均衡種類
1.2.1 四層
所謂四層就是基於IP+端口的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。換句話說，二層負載均衡會通過一個虛擬MAC地址接收請求，然後再分配到真實的MAC地址；三層負載均衡會通過一個虛擬IP地址接收請求，然後再分配到真實的IP地址；四層通過虛擬IP+端口接收請求，然後再分配到真實的服務器；七層通過虛擬的URL或主機名接收請求，然後再分配到真實的服務器。
1.2.2 七層
所謂的四到七層負載均衡，就是在對後臺的服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。比如四層的負載均衡，就是通過發佈三層的IP地址（VIP），然後加四層的端口號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至後臺服務器，並記錄下這個TCP或者UDP的流量是由哪臺服務器處理，後續這個連接的所有流量都同樣轉發到同一臺服務器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，比如同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web服務器分成兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然後選擇對應的語言服務器組進行負載均衡處理
1.2.3 負載均衡器
1. 負載均衡器通常稱爲四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。
2. 負載均衡分爲L4 switch（四層交換），即在OSI第4層工作，就是TCP層。此種Load
Balance不理解應用協議（如HTTP/FTP/MySQL等等）。例子：LVS，F5。
3. 另一種叫做L7 switch（七層交換），OSI的最高層，應用層。此時，該Load
Balancer能理解應用協議。例子： haproxy，MySQL Proxy。
注意：上面的很多Load Balancer既可以做四層交換，也可以做七層交換。
1.2.4 區別
1.2.4.1 技術原理
所謂四層負載均衡，也就是主要通過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。以常見的TCP爲例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的服務器，並對報文中目標IP地址進行修改(改爲後端服務器IP），直接轉發給該服務器。TCP的連接建立，即三次握手是客戶端和服務器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，爲保證服務器回包可以正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。
所謂七層負載均衡，也稱爲“內容交換”，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
以常見的TCP爲例，負載均衡設備如果要根據真正的應用層內容再選擇服務器，只能先代理最終的服務器和客戶端建立連接(三次握手)後，纔可能接受到客戶端發送的真正應用層內容的報文，然後再根據該報文中的特定字段，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。負載均衡設備在這種情況下，更類似於一個代理服務器。負載均衡和前端的客戶端以及後端的服務器會分別建立TCP連接。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。
1.2.4.2 應用場景
七層應用負載的好處，是使得整個網絡更智能化。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片服務器並可以使用緩存技術；將對文字類的請求可以轉發到特定的文字服務器並可以使用壓縮技術。當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和服務器的響應進行任意意義上的修改，極大的提升了應用系統在網絡層的靈活性。很多在後臺，例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上，例如客戶請求中的Header重寫，服務器響應中的關鍵字過濾或者內容插入等功能。
另外一個常常被提到功能就是安全性。網絡中最常見的SYN Flood攻擊，即黑客控制衆多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，通常這種攻擊會大量發送SYN報文，耗盡服務器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發到後端的服務器上；而七層模式下這些SYN攻擊自然在負載均衡設備上就截止，不會影響後臺服務器的正常運營。另外負載均衡設備可以在七層層面設定多種策略，過濾特定報文，例如SQL
Injection等應用層面的特定攻擊手段，從應用層面進一步提高系統整體安全。
現在的七層負載均衡，主要還是着重於應用HTTP協議，所以其應用範圍主要是衆多的網站或者內部信息平臺等基於B/S開發的系統。 四層負載均衡則對應其他TCP應用，例如基於C/S開發的ERP等系統。
二、LVS負載均衡
2.1 概述
LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集羣系統。
一般來說，LVS集羣採用三層結構，其主要組成部分爲：
A、負載調度器（load balancer），它是整個集羣對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認爲服務是來自一個IP地址（我們可稱之爲虛擬IP地址）上的。調度器是服務器集羣系統的唯一入口點（Single Entry Point），它可以採用IP負載均衡技術、基於內容請求分發技術或者兩者相結合。
B、服務器池（server pool），是一組真正執行客戶請求的服務器，執行的服務有WEB、MAIL、FTP和DNS等。
C、共享存儲（shared storage），它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。
在IP負載均衡技術中，需要服務器池擁有相同的內容提供相同的服務。當客戶請求到達時，調度器只根據服務器負載情況和設定的調度算法從服務器池中選出一個服務器，將該請求轉發到選出的服務器，並記錄這個調度；當這個請求的其他報文到達，也會被轉發到前面選出的服務器。在基於內容請求分發技術中，服務器可以提供不同的服務，當客戶請求到達時，調度器可根據請求的內容選擇服務器執行請求。因爲所有的操作都是在Linux操作系統核心空間中完成的，它的調度開銷很小，所以它具有很高的吞吐率。服務器池的結點數目是可變的。當整個系統收到的負載超過目前所有結點的處理能力時，可以在服務器池中增加服務器來滿足不斷增長的請求負載。
2.2 IP負載均衡
在分析服務器集羣實現虛擬網絡服務的相關技術上，詳細描述了LVS集羣中實現的三種IP負載均衡技術VS/NAT、VS/TUN、VS/DR的工作原理，以及它們的優缺點。
2.2.1 簡述LVS負載均衡
IP負載均衡技術是在負載調度器的實現技術中效率最高的。在已有的IP負載均衡技術中，主要有通過網絡地址轉換NAT（Network
Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，稱之爲VS/NAT技術（Virtual Server via Network Address Translation）。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，提出了通過IP隧道實現虛擬服務器的方法VS/TUN （Virtual Server
via IP Tunneling），和通過直接路由實現虛擬服務器的方法VS/DR（Virtual
Server via Direct Routing），它們可以極大地提高系統的伸縮性。VS/NAT、VS/TUN和VS/DR技術是LVS集羣中實現的三種IP負載均衡技術，後面將詳細描述它們的工作原理和各自的優缺點。
2.2.2 常用方法
在網絡服務中，一端是客戶程序，另一端是服務程序，在中間可能有代理程序。由此看來，可以在不同的層次上實現多臺服務器的負載均衡。用集羣解決網絡服務性能問題的現有方法主要分爲以下四類。
2.2.2.1 基於RR-DNS
有一組WEB服務器，他們通過分佈式文件系統 AFS(Andrew
File System)來共享所有的HTML文檔。這組服務器擁有相同的域名（如www.ncsa.uiuc.edu），當用戶按照這個域名訪問時,RR-DNS服務器會把域名輪流解析到這組服務器的不同IP地址，從而將訪問負載分到各臺服務器上。
這種方法帶來幾個問題：
第一，域名服務器是一個分佈式系統，是按照一定的層次結構組織的。當用戶就域名解析請求提交給本地的域名服務器，它會因不能直接解析而向上一級域名服務器提交，上一級域名服務器再依次向上提交，直到RR-DNS域名服器把這個域名解析到其中一臺服務器的IP地址。可見，從用戶到RR-DNS間存在多臺域名服器，而它們都會緩衝已解析的名字到IP地址的映射,這會導致該域名服器組下所有用戶都會訪問同一WEB服務器，出現不同WEB服務器間嚴重的負載不平衡。爲了保證在域名服務器中域名到IP地址的映射不被長久緩衝，RR-DNS在域名到IP地址的映射上設置一個TTL(Time
To Live)值，過了這一段時間，域名服務器將這個映射從緩衝中淘汰。當用戶請求，它會再向上一級域名服器提交請求並進行重新影射。這就涉及到如何設置這個TTL值，若這個值太大，在這個TTL期間，很多請求會被映射到同一臺WEB服務器上，同樣會導致嚴重的負載不平衡。若這個值太小，例如是０，會導致本地域名服務器頻繁地向RR-DNS提交請求，增加了域名解析的網絡流量，同樣會使RR-DNS服務器成爲系統中一個新的瓶頸。
第二，用戶機器會緩衝從名字到IP地址的映射，而不受TTL值的影響，用戶的訪問請求會被送到同一臺WEB服務器上。由於用戶訪問請求的突發性和訪問方式不同，例如有的人訪問一下就離開了，而有的人訪問可長達幾個小時，所以各臺服務器間的負載仍存在傾斜（Skew）而不能控制。假設用戶在每個會話中平均請求數爲20，負載最大的服務器獲得的請求數額高於各服務器平均請求數的平均比率超過百分之三十。也就是說，當TTL值爲0時，因爲用戶訪問的突發性也會存在着較嚴重的負載不平衡。
第三，系統的可靠性和可維護性差。若一臺服務器失效，會導致將域名解析到該服務器的用戶看到服務中斷，即使用戶按“Reload”按鈕，也無濟於事。系統管理員也不能隨時地將一臺服務器切出服務進行系統維護，如進行操作系統和應用軟件升級，這需要修改RR-DNS服務器中的IP地址列表，把該服務器的IP地址從中劃掉，然後等上幾天或者更長的時間，等所有域名服器將該域名到這臺服務器的映射淘汰，和所有映射到這臺服務器的客戶機不再使用該站點爲止。
2.2.2.2 DNS delegation
Another more effective technique for load-balancing using DNS is to delegate www.example.org as a sub-domain whose zone is served by each of the same servers that are serving the web site. This technique works particularly
well where individual servers are spread geographically on the Internet. For example:
one.example.org A 192.0.2.1
two.example.org A 203.0.113.2
www.example.org NS one.example.org
www.example.org NS two.example.org
However, the zone file for www.example.org on each server is different such that each server resolves its own IP Address as the A-record. On server one the zone file for www.example.org reports:
@ in a 192.0.2.1
On server two the same zone file contains:
@ in a 203.0.113.2
This way, when a server is down, its DNS will not respond and the web service does not receive any traffic. If the line to one server is congested, the unreliability of DNS ensures less HTTP traffic reaches that server. Furthermore,
the quickest DNS response to the resolver is nearly always the one from the network's closest server, ensuring geo-sensitive load-balancing. A short TTL on
the A-record helps to ensure traffic is quickly diverted when a server goes down. Consideration must be given the possibility that this technique may cause individual clients to switch between individual servers in mid-session.
2.2.2.3 基於客戶端
基於客戶端的解決方法需要每個客戶程序都有一定的服務器集羣的知識，進而把以負載均衡的方式將請求發到不同的服務器。例如，Netscape Navigator瀏覽器訪問Netscape的主頁時，它會隨機地從一百多臺服務器中挑選第N臺，最後將請求送往www.netscape.com。然而，這不是很好的解決方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻煩，當使用IE等其他瀏覽器不可避免的要進行RR-DNS解析。
Smart Client是Berkeley做的另一種基於客戶端的解決方法。服務提供一個Java
Applet在客戶方瀏覽器中運行，Applet向各個服務器發請求來收集服務器的負載等信息，再根據這些信息將客戶的請求發到相應的服務器。高可用性也在Applet中實現，當服務器沒有響應時，Applet向另一個服務器轉發請求。這種方法的透明性不好，Applet向各服務器查詢來收集信息會增加額外的網絡流量，不具有普遍的適用性。
2.2.2.4 基於應用層
多臺服務器通過高速的互聯網絡連接成一個集羣系統，在前端有一個基於應用層的負載調度器。當用戶訪問請求到達調度器時，請求會提交給作負載均衡調度的應用程序，分析請求，根據各個服務器的負載情況，選出一臺服務器，重寫請求並向選出的服務器訪問，取得結果後，再返回給用戶。
應用層負載均衡調度的典型代表有Zeus負載調度器、pWeb、Reverse-Proxy和SWEB等。Zeus負載調度器是Zeus公司的商業產品，它是在Zeus
Web服務器程序改寫而成的，採用單進程事件驅動的服務器結構。pWeb就是一個基於Apache 1.1服務器程序改寫而成的並行WEB調度程序，當一個HTTP請求到達時，pWeb會選出一個服務器，重寫請求並向這個服務器發出改寫後的請求，等結果返回後，再將結果轉發給客戶。Reverse-Proxy利用Apache
1.3.1中的Proxy模塊和Rewrite模塊實現一個可伸縮WEB服務器，它與pWeb的不同之處在於它要先從Proxy的cache中查找後，若沒有這個副本，再選一臺服務器，向服務器發送請求，再將服務器返回的結果轉發給客戶。SWEB是利用HTTP中的redirect錯誤代碼，將客戶請求到達一臺WEB服務器後，這個WEB服務器根據自己的負載情況，自己處理請求，或者通過redirect錯誤代碼將客戶引到另一臺WEB服務器，以實現一個可伸縮的WEB服務器。
基於應用層負載均衡調度的多服務器解決方法也存在一些問題。第一，系統處理開銷特別大，致使系統的伸縮性有限。當請求到達負載均衡調度器至處理結束時，調度器需要進行四次從核心到用戶空間或從用戶空間到核心空間的上下文切換和內存複製；需要進行二次TCP連接，一次是從用戶到調度器，另一次是從調度器到真實服務器；需要對請求進行分析和重寫。這些處理都需要不小的CPU、內存和網絡等資源開銷，且處理時間長。所構成系統的性能不能接近線性增加的，一般服務器組增至3或4臺時，調度器本身可能會成爲新的瓶頸。所以，這種基於應用層負載均衡調度的方法的伸縮性極其有限。第二，基於應用層的負載均衡調度器對於不同的應用，需要寫不同的調度器。以上幾個系統都是基於HTTP協議，若對於FTP、Mail、POP3等應用，都需要重寫調度器。
2.2.2.5 基於IP層
用戶通過虛擬IP地址（Virtual IP Address）訪問服務時，訪問請求的報文會到達負載調度器，由它進行負載均衡調度，從一組真實服務器選出一個，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將報文發送給選定的服務器。真實服務器的迴應報文經過負載調度器時，將報文的源地址和源端口改爲Virtual IP Address和相應的端口，再把報文發給用戶。
Berkeley的Magic Router、Cisco的Local
Director、Alteon的ACE
Director和F5的Big/IP等都是使用網絡地址轉換方法。Magic
Router是在Linux 1.3版本上應用快速報文插入技術，使得進行負載均衡調度的用戶進程訪問網絡設備接近核心空間的速度，降低了上下文切換的處理開銷，但並不徹底，它只是研究的原型系統，沒有成爲有用的系統存活下來。Cisco的Local Director、Alteon的ACE Director和F5的Big/IP是非常昂貴的商品化系統，它們支持部分TCP/UDP協議，有些在ICMP處理上存在問題。
IBM的TCP Router使用修改過的網絡地址轉換方法在SP/2系統實現可伸縮的WEB服務器。TCP
Router修改請求報文的目標地址並把它轉發給選出的服務器，服務器能把響應報文的源地址置爲TCP Router地址而非自己的地址。這種方法的好處是響應報文可以直接返回給客戶，壞處是每臺服務器的操作系統內核都需要修改。IBM的 NetDispatcher是TCP Router的後繼者，它將報文轉發給服務器，而服務器在non-ARP的設備配置路由器的地址。這種方法與LVS集羣中的VS/DR類似，它具有很高的可伸縮性。
在貝爾實驗室的ONE-IP中，每臺服務器都獨立的IP地址，但都用IP
Alias配置上同一VIP地址，採用路由和廣播兩種方法分發請求，服務器收到請求後按VIP地址處理請求，並以VIP爲源地址返回結果。這種方法也是爲了避免迴應報文的重寫，但是每臺服務器用IP Alias配置上同一VIP地址，會導致地址衝突，有些操作系統會出現網絡失效。通過廣播分發請求，同樣需要修改服務器操作系統的源碼來過濾報文，使得只有一臺服務器處理廣播來的請求。
微軟的Windows NT負載均衡服務（Windows NT Load
Balancing Service，WLBS）是1998年底收購Valence Research公司獲得的，它與ONE-IP中的基於本地過濾方法一樣。WLBS作爲過濾器運行在網卡驅動程序和TCP/IP協議棧之間，獲得目標地址爲VIP的報文，它的過濾算法檢查報文的源IP地址和端口號，保證只有一臺服務器將報文交給上一層處理。但是，當有新結點加入和有結點失效時，所有服務器需要協商一個新的過濾算法，這會導致所有有Session的連接中斷。同時，WLBS需要所有的服務器有相同的配置，如網卡速度和處理能力。
2.2.3 VS/NAT
由於IPv4中IP地址空間的日益緊張和安全方面的原因，很多網絡使用保留IP地址（10.0.0.0/255.0.0.0、172.16.0.0/255.240.0.0和192.168.0.0/255.255.0.0）。這些地址不在Internet上使用，而是專門爲內部網絡預留的。當內部網絡中的主機要訪問Internet或被Internet訪問時，就需要採用網絡地址轉換（Network
Address Translation, 以下簡稱NAT），將內部地址轉化爲Internets上可用的外部地址。NAT的工作原理是報文頭（目標地址、源地址和端口等）被正確改寫後，客戶相信它們連接一個IP地址，而不同IP地址的服務器組也認爲它們是與客戶直接相連的。由此，可以用NAT方法將不同IP地址的並行網絡服務變成在一個IP地址上的一個虛擬服務。
VS/NAT的體系結構如下圖所示。在一組服務器前有一個調度器，它們是通過Switch/HUB相連接的。這些服務器提供相同的網絡服務、相同的內容，即不管請求被髮送到哪一臺服務器，執行結果是一樣的。服務的內容可以複製到每臺服務器的本地硬盤上，可以通過網絡文件系統（如NFS）共享，也可以通過一個分佈式文件系統來提供。
客戶通過Virtual IP Address（虛擬服務的IP地址）訪問網絡服務時，請求報文到達調度器，調度器根據連接調度算法從一組真實服務器中選出一臺服務器，將報文的目標地址Virtual IP Address改寫成選定服務器的地址，報文的目標端口改寫成選定服務器的相應端口，最後將修改後的報文發送給選出的服務器。同時，調度器在連接Hash表中記錄這個連接，當這個連接的下一個報文到達時，從連接Hash表中可以得到原選定服務器的地址和端口，進行同樣的改寫操作，並將報文傳給原選定的服務器。當來自真實服務器的響應報文經過調度器時，調度器將報文的源地址和源端口改爲Virtual
IP Address和相應的端口，再把報文發給用戶。在連接上引入一個狀態機，不同的報文會使得連接處於不同的狀態，不同的狀態有不同的超時值。在TCP連接中，根據標準的TCP有限狀態機進行狀態遷移。在UDP中，只設置一個UDP狀態。不同狀態的超時值是可以設置的，在缺省情況下，SYN狀態的超時爲1分鐘，ESTABLISHED狀態的超時爲15分鐘，FIN狀態的超時爲1分鐘；UDP狀態的超時爲5分鐘。當連接終止或超時，調度器將這個連接從連接Hash表中刪除。
這樣，客戶所看到的只是在Virtual IP Address上提供的服務，而服務器集羣的結構對用戶是透明的。對改寫後的報文，應用增量調整Checksum的算法調整TCP Checksum的值，避免了掃描整個報文來計算Checksum的開銷。
在一些網絡服務中，它們將IP地址或者端口號在報文的數據中傳送，若只對報文頭的IP地址和端口號作轉換，這樣就會出現不一致性，服務會中斷。所以，針對這些服務，需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。
下面，舉個例子來進一步說明VS/NAT，如圖所示：
VS/NAT的配置如下所示，所有到IP地址爲202.103.106.5和端口爲80的流量都被負載均衡地調度的真實服務器172.16.0.2:80和 172.16.0.3:8000上。目標地址爲202.103.106.5:21的報文被轉移到172.16.0.3:21上。而到其他端口的報文將被拒絕。
| Protocol | Virtual IP address | Port | Real IP address | Port | Weight |
| TCP | 202.103.106.5 | 80 | 172.16.0.2 | 80 | 1 |
| 172.16.0.3 | 8000 | 2 | |||
| TCP | 202.103.106.5 | 21 | 172.16.0.3 | 21 | 1 |
從以下的例子中，可以更詳細地瞭解報文改寫的流程。
訪問Web服務的報文可能有以下的源地址和目標地址：
SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80
調度器從調度列表中選出一臺服務器，例如是172.16.0.3:8000。該報文會被改寫爲如下地址，並將它發送給選出的服務器。
SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000
從服務器返回到調度器的響應報文如下：
SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456
響應報文的源地址會被改寫爲虛擬服務的地址，再將報文發送給客戶：
SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456
這樣，客戶認爲是從202.103.106.5:80服務得到正確的響應，而不會知道該請求是服務器172.16.0.2還是服務器172.16.0.3處理的。
2.2.4VS/TUN
在VS/NAT的集羣系統中，請求和響應的數據報文都需要通過負載調度器，當真實服務器的數目在10臺和20臺之間時，負載調度器將成爲整個集羣系統的新瓶頸。大多數Internet服務都有這樣的特點：請求報文較短而響應報文往往包含大量的數據。如果能將請求和響應分開處理，即在負載調度器中只負責調度請求而響應直接返回給客戶，將極大地提高整個集羣系統的吞吐量。
IP隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標爲一個IP地址的數據報文能被封裝和轉發到另一個IP地址。IP隧道技術亦稱爲IP封裝技術（IP
encapsulation）。IP隧道主要用於移動主機和虛擬私有網絡（Virtua lP private Network），在其中隧道都是靜態建立的，隧道一端有一個IP地址，另一端也有唯一的IP地址。
利用IP隧道技術將請求報文封裝轉發給後端服務器，響應報文能從後端服務器直接返回給客戶。但在這裏，後端服務器有一組而非一個，所以不可能靜態地建立一一對應的隧道，而是動態地選擇一臺服務器，將請求報文封裝和轉發給選出的服務器。這樣，可以利用IP隧道的原理將一組服務器上的網絡服務組成在一個IP地址上的虛擬網絡服務。VS/TUN的體系結構如圖所示，各個服務器將VIP地址配置在自己的IP隧道設備上。
VS/TUN 的工作流程如上圖所示：它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。調度器根據各個服務器的負載情況，動態地選擇一臺服務器，將請求報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；服務器收到報文後，先將報文解封獲得原來目標地址爲VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。
需要指出，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址肯定也爲VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認爲得到正常的服務，而不會知道究竟是哪一臺服務器處理的。
2.2.5VS/DR
跟VS/TUN方法相同，VS/DR利用大多數Internet服務的非對稱特點，負載調度器中只負責調度請求，而服務器直接將響應返回給客戶，可以極大地提高整個集羣系統的吞吐量。該方法與IBM的Net
Dispatcher產品中使用的方法類似（其中服務器上的IP地址配置方法是相似的）。
VS/DR的體系結構如圖所示：調度器和服務器組都必須在物理上有一個網卡通過不分斷的局域網相連，如通過高速的交換機或者HUB相連。VIP地址爲調度器和服務器組共享，調度器配置的VIP地址是對外可見的，用於接收虛擬服務的請求報文。所有的服務器把VIP地址配置在各自的Non-ARP網絡設備上，它對外面是不可見的，只是用於處理目標地址爲VIP的網絡請求。
VS/DR的工作流程如上圖所示：它的連接調度和管理與VS/NAT和VS/TUN中的一樣，它的報文轉發方法又有不同，將報文直接路由給目標服務器。在VS/DR中，調度器根據各個服務器的負載情況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改爲選出服務器的MAC地址，再將修改後的數據幀在與服務器組的局域網上發送。因爲數據幀的MAC地址是選出的服務器，所以服務器肯定可以收到這個數據幀，從中可以獲得該IP報文。當服務器發現報文的目標地址VIP是在本地的網絡設備上，服務器處理這個報文，然後根據路由表將響應報文直接返回給客戶。
2.2.6 比較
2.2.6.1 總體比較
以上主要講述了LVS集羣中的三種IP負載均衡技術。在分析網絡地址轉換方法（VS/NAT）的缺點和網絡服務的非對稱性的基礎上，我們給出了通過IP隧道實現虛擬服務器的方法VS/TUN，和通過直接路由實現虛擬服務器的方法VS/DR，極大地提高了系統的伸縮性。
在VS/DR中，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址肯定也爲VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認爲得到正常的服務，而不會知道是哪一臺服務器處理的。
VS/DR負載調度器跟VS/TUN一樣只處於從客戶到服務器的半連接中，按照半連接的TCP有限狀態機進行狀態遷移。
三種方法的優缺點比較/LVS負載均衡 編輯
三種IP負載均衡技術的優缺點歸納在下表中：
|
方法 Server |
VS/NAT | VS/TUN | VS/DR |
| Server any | Tunneling | Non-arp | device |
| Server network | private | LAN/WAN | LAN |
| Server number | low(10~20) | High(100) | High(100) |
| Server gateway | Load balancer | Own router | Own router |
注：以上3種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡，調度器的硬件配置與後端服務器的硬件配置相同，而且是對一般Web服務。使用更高的硬件配置（如千兆網卡和更快的處理器）作爲調度器，調度器所能調度的服務器數量會相應增加。當應用不同時，服務器的數目也會相應地改變。所以，以上數據估計主要是爲三種方法的伸縮性進行量化比較。
2.2.6.2 Virtual Server via NAT
VS/NAT的優點是服務器可以運行任何支持TCP/IP的操作系統，它只需要一個IP地址配置在調度器上，服務器組可以用私有的IP地址。缺點是它的伸縮能力有限，當服務器結點數目升到20時，調度器本身有可能成爲系統的新瓶頸，因爲在VS/NAT中請求和響應報文都需要通過負載調度器。
基於VS/NAT的集羣系統可以適合許多服務器的性能要求。如果負載調度器成爲系統新的瓶頸，可以有三種方法解決這個問題：混合方法、VS/TUN和 VS/DR。在DNS混合集羣系統中，有若干個VS/NAT負載調度器，每個負載調度器帶自己的服務器集羣，同時這些負載調度器又通過RR-DNS組成簡單的域名。但VS/TUN和VS/DR是提高系統吞吐量的更好方法。
對於那些將IP地址或者端口號在報文數據中傳送的網絡服務，需要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。這會帶來實現的工作量，同時應用模塊檢查報文的開銷會降低系統的吞吐率。
2.2.6.3 Virtual Server via IP Tunneling
在VS/TUN的集羣系統中，負載調度器只將請求調度到不同的後端服務器，後端服務器將應答的數據直接返回給用戶。這樣負載調度器就可以處理大量的請求，它甚至可以調度百臺以上的服務器（同等規模的服務器），而它不會成爲系統的瓶頸。即使負載調度器只有100Mbps的全雙工網卡，整個系統的最大吞吐量可超過 1Gbps。所以，VS/TUN可以極大地增加負載調度器調度的服務器數量，而它本身不會成爲系統的瓶頸，可以用來構建高性能的超級服務器。
VS/TUN技術對服務器有要求，即所有的服務器必須支持“IP Tunneling”或者“IP
Encapsulation”協議。目前，VS/TUN的後端服務器主要運行Linux操作系統。因爲“IP Tunneling”正成爲各個操作系統的標準協議，所以VS/TUN應該會適用運行其他操作系統的後端服務器。
2.2.6.4 Virtual Server via Direct Routing
跟VS/TUN方法一樣，VS/DR調度器只處理客戶到服務器端的連接，響應數據可以直接從獨立的網絡路由返回給客戶。這可以極大地提高LVS集羣系統的伸縮性。
跟VS/TUN相比，這種方法沒有IP隧道的開銷，但是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備（或者設備別名）不作ARP響應，或者能將報文重定向（Redirect）到本地的Socket端口上。
2.2.7 文件系統
網絡文件系統的伸縮能力有限，一般來說，NFS/CIFS服務器只能支持3~6個繁忙的服務器結點。對於規模較大的集羣系統，可以考慮用分佈式文件系統，如AFS、GFS、Coda和Intermezzo等。分佈式文件系統可爲各服務器提供共享的存儲區，它們訪問分佈式文件系統就像訪問本地文件系統一樣，同時分佈式文件系統可提供良好的伸縮性和可用性。
三、實例
3.1 總體比較
Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件。
一般對負載均衡的使用是隨着網站規模的提升根據不同的階段來使用不同的技術。具體的應用需求還得具體分析，如果是中小型的Web應用，比如日PV小於1000萬，用Nginx就完全可以了；如果機器不少，可以用DNS輪詢，LVS所耗費的機器還是比較多的；大型網站或重要的服務，且服務器比較多時，可以考慮用LVS。
一種是通過硬件來進行，常見的硬件有比較昂貴的F5和Array等商用的負載均衡器，它的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小的網絡服務來說暫時還沒有需要使用；另外一種就是類似於Nginx/LVS/HAProxy的基於 Linux的開源免費的負載均衡軟件，這些都是通過軟件級別來實現，所以費用非常低廉。
3.2 Nginx
3.2.1優點
1. 工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構，它的正則規則比HAProxy更爲強大和靈活，這也是它目前廣泛流行的主要原因之一，Nginx單憑這點可利用的場合就遠多於LVS了。
2. Nginx對網絡穩定性的依賴非常小，理論上能ping通就能進行負載功能，這個也是它的優勢之一；相反LVS對網絡穩定性依賴比較大。
3. Nginx安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日誌打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。
4. 可以承擔高負載壓力且穩定，在硬件不差的情況下一般能支撐幾萬次的併發量，負載度比LVS相對小些。
5. Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而不滿。
6. Nginx不僅僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。LNMP也是近幾年非常流行的web架構，在高流量的環境中穩定性也很好。
7. Nginx現在作爲Web反向加速緩存越來越成熟了，速度比傳統的Squid服務器更快，可以考慮用其作爲反向代理加速器。
8. Nginx可作爲中層反向代理使用，這一層面Nginx基本上無對手，唯一可以對比Nginx的就只有
lighttpd了，不過 lighttpd目前還沒有做到Nginx完全的功能，配置也不那麼清晰易讀，社區資料也遠遠沒Nginx活躍。
9. Nginx也可作爲靜態網頁和圖片服務器，這方面的性能也無對手。還有Nginx社區非常活躍，第三方模塊也很多。
3.2.2 缺點
1. Nginx僅能支持http、https和Email協議，這樣就在適用範圍上面小些，這個是它的缺點。
2. 對後端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。不支持Session的直接保持，但能通過ip_hash來解決。
3. LVS：使用Linux內核集羣實現一個高性能、高可用的負載均衡服務器，它具有很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。
3.3 LVS
3.3.1 優點
1. 抗負載能力強、工作在網絡四層之上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件裏的性能最強的，對內存和CPU資源消耗比較低。
2. 配置性比較低，這是一個缺點也是一個優點，因爲沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人爲出錯的機率。
3. 工作穩定，因爲其本身抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived。
4. 無流量，LVS只分發請求，而流量並不從它本身出去，這點保證了均衡器IO的性能不會受到大流量的影響。
5. 應用範圍比較廣，因爲LVS工作在四層，所以它幾乎可以對所有應用做負載均衡，包括http、數據庫、在線聊天室等等。
3.3.2 缺點
軟件本身不支持正則表達式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優勢所在。
如果是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較複雜了，特別後面有 Windows Server的機器的話，如果實施及配置還有維護過程就比較複雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。
3.4 HAProxy
HAProxy的特點是：
1. HAProxy支持虛擬主機。
2. HAProxy的優點能夠補充Nginx的一些缺點，比如支持Session的保持，Cookie的引導；同時支持通過獲取指定的url來檢測後端服務器的狀態。
3. HAProxy跟LVS類似，本身就只是一款負載均衡軟件；單純從效率上來講HAProxy會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的。
4. HAProxy支持TCP協議的負載均衡轉發，可以對MySQL讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡。
HAProxy負載均衡策略非常多，HAProxy的負載均衡算法現在具體有如下8種：
a) roundrobin，表示簡單的輪詢；
b) static-rr，表示根據權重；
c) leastconn，表示最少連接者先處理；
d) source，表示根據請求源IP，這個跟Nginx的IP_hash機制類似，我們用其作爲解決session問題的一種方法；
e) ri，表示根據請求的URI；
f) rl_param，表示根據請求的URl參數’balance
url_param’ requires an URL parameter name；
g) hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；
h) rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。
3.5 Nginx VS LVS
1. Nginx工作在網絡的七層，可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下LVS並不具備這樣的功能，所以Nginx可用場合就遠多於LVS了；但Nginx有用的這些功能使其可調整度要高於LVS，配置多人爲出問題的機率會大。
2. Nginx對網絡穩定性的依賴較小，理論上只要ping得通，網頁訪問正常，Nginx就能連得通，這是Nginx的一大優勢。Nginx同時還能區分內外網，如果是同時擁有內外網的節點，就相當於單機擁有了備份線路；LVS就比較依賴於網絡環境，目前來看服務器在同一網段內並且LVS使用direct方式分流，效果較能得到保證。另外注意，LVS需要至少申請多一個IP來做Visual
IP。
3. Nginx安裝和配置比較簡單，測試起來也很方便，因爲它基本能把錯誤用日誌打印出來。LVS的安裝和配置、測試就要花比較長的時間了；LVS對網絡依賴比較大，很多時候不能配置成功都是因爲網絡問題而不是配置問題，出了問題要解決也相應的會麻煩得多。
4. Nginx能承受很高負載且穩定，但負載度和穩定度差LVS還有幾個等級：Nginx處理所有流量所以受限於機器IO和配置。
5. Nginx可以檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點。目前LVS中VS/DR也能支持針對服務器內部的情況來監控，但LVS的原理使其不能重發請求。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了。
6. Nginx對請求的異步處理可以幫助節點服務器減輕負載，假如使用
apache直接對外服務，那麼出現很多的窄帶鏈接時apache服務器將會佔用大量內存而不能釋放，使用多一個Nginx做apache代理的話，這些窄帶鏈接會被Nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相當多的資源佔用。這點使用squid也有相同的作用。
7. Nginx能支持http、https，LVS所支持的應用在這點上會比Nginx更多。在使用上，一般最前端所採取的策略應是LVS，也就是DNS的指向應爲LVS均衡器，LVS的優點令它非常適合做這個任務。重要的IP地址。Nginx可作爲LVS節點機器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。Nginx也可作爲中層代理使用。
3.6 技術選擇
現在對網絡負載均衡的使用是隨着網站規模的提升根據不同的階段來使用不同的技術：
第一階段：利用Nginx或HAProxy進行單點的負載均衡，這一階段服務器規模剛脫離開單服務器、單數據庫的模式，需要一定的負載均衡，但是規模較小沒有專業的維護團隊來進行維護，也不需要進行大規模的網站部署。這樣利用Nginx或HAproxy就是第一選擇，配置容易，在七層之上利用HTTP協議就可以。
第二階段：隨着網絡服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用Array就是首要選擇，Nginx此時就作爲LVS或者Array的節點來使用。
第三階段：這時網絡服務已經成爲主流產品，此時隨着公司知名度也進一步擴展，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定製，以及降低成本來講開源的LVS成爲首選。
最終形成比較理想的基本架構爲：Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。
四、SLB
負載均衡（Server Load Balancer，簡稱SLB）是對多臺雲服務器進行流量分發的負載均衡服務。SLB可以通過流量分發擴展應用系統對外的服務能力，通過消除單點故障提升應用系統的可用性。
The process of evenly distributing multiple user requests across a number of servers supporting a company's network. Utilized effectively, this traffic optimization method can increase productivity and performance of a network
by allowing users in a variety of locations access to business-critical information and applications without slow response times or failed connections.
When servers are overwhelmed with high-volume traffic, processing capabilities decelerate and data retrieval becomes slow or, in some cases, impossible. Traffic congestions and server request failures are just some of the potential
problems that server load balancing can solve. Since most businesses rely
on the availability of network information and applications, retrieval complications can hinder productivity in very substantial ways. By evenly distributing server requests across multiple servers, load balancing provides maximum efficiency of data center
resources. Along with the efficient direction of traffic, server load balancing solutions can also provide alternate routes to business-sensitive information when user requests increase to maximum levels or a particular server loses functionality. By providing
these additional paths to data and applications, networks can maintain a high-level of IT infrastructure support, resulting in increased performance and guaranteed around the clock access.
Server load balancing is a method for improving the availability and performance of software applications that are run across multiple servers. This method boosts application availability by routing client request traffic away
from servers that are congested or malfunctioning, and elevates performance by balancing request traffic across healthy servers so that no one server is over-burdened.
Server load balancing is especially important for mission critical applications that handle a high volume of requests. In high traffic contexts such as popular websites and web-based applications, request traffic typically
must be balanced across servers in multiple geographically dispersed datacenters.
