分享阿里雲SLB-負載均衡的實現基本原理架構

負載均衡技術原理淺析

https://help.aliyun.com/knowledge_detail/39444.html?spm=5176.7839438.2.6.XBbX5l

阿里定製版的LVC 開源地址：https://github.com/alibaba/LVS?spm=5176.7739444.2.10.WxLaqZ

更新時間：2016-07-12 13:21:10   

一、技術架構
二、LVS技術特色

• FULLNAT技術概述
• SYNPROXY技術概述
• 集羣部署方式
• Keepalived優化

三、Tengine技術特色
四、更多功能
 

---

SLB（Server Load Balancer）服務經過設置虛擬服務地址（IP），將位於同一地域（Region）的多臺雲服務器（Elastic Compute Service，簡稱ECS）資源虛擬成一個高性能、高可用的應用服務池；再根據應用指定的方式，未來自客戶端的網絡請求分發到雲服務器池中。

SLB服務會檢查雲服務器池中ECS的健康狀態，自動隔離異常狀態的ECS，從而解決了單臺ECS的單點問題，同時提升了應用的總體服務能力。在標準的負載均衡功能以外，SLB服務還具有TCP與HTTP抗DDoS攻擊的特性，加強了應用服務器的防禦能力。

SLB服務是ECS面向多機方案的一個配套服務，須要同ECS結合使用。

一、技術架構

整個負載均衡系統由3部分構成：四層負載均衡、七層負載均衡和控制系統，以下圖所示：

 

• 四層負載均衡
  採用開源軟件LVS（Linux Virtual Server）構建，並根據雲計算需求對其進行了定製和優化。
• 七層負載均衡
  採用開源軟件Tengine構建。
• 控制系統
  用於配置和監控負載均衡系統。

二、LVS技術特色

LVS是全球最流行的四層負載均衡開源軟件，能夠實現LINUX平臺下的負載均衡。

LVS是 基於Linux Netfilter框架實現的一個內核模塊（ IPTables是基於Netfilter基本架構實現的一個可擴展的數據報高級管理系統或核外配置工具），名稱爲IPVS。其鉤子函數分別HOOK在LOCAL_IN和FORWARD兩個HOOK點，以下圖所示：

 

在雲計算大規模網絡環境下，官方LVS存在以下問題：

• 問題1：LVS支持NAT/DR/TUNNEL三種轉發模式，上述模式在多VLAN網絡環境下部署時，存在網絡拓撲復雜，運維成本高的問題。
• 問題2：和商用負載均衡設備（如F5等）相比，LVS缺乏DDOS攻擊防護功能。
• 問題3：LVS採用PC服務器，經常使用Keepalived軟件的VRRP心跳協議進行主備部署，其性能沒法擴展。
• 問題4：LVS經常使用管理軟件Keepalived的配置和健康檢查性能不足。

爲了解決上述問題， SLB在官方LVS基礎上進行了以下定製化和優化：

• 解決1：新增轉發模式FULLNAT，實現LVS-RealServer間跨VLAN通信。
• 解決2：新增了SYNPROXY等TCP標誌位DDOS攻擊防護功能。
• 解決3：採用LVS集羣方式部署。
• 解決4：對Keepalived的性能進行了優化。

 

Aliyun-LVS開源地址： https://github.com/alibaba/LVS 。 更多相關說明以下所述。

• FULLNAT技術概述

以下圖所示，FULLNAT主要實現方式爲：

• 引入local address（內網IP地址）。cip-vip轉換爲lip->rip，而 lip和rip均爲IDC內網IP，能夠跨VLAN通信。
• IN/OUT的數據流所有通過LVS，爲了保證帶寬，採用萬兆（10G）網卡。
• FULLNAT轉發模式，當前僅支持TCP協議。

 

• SYNPROXY技術概述

LVS針對TCP標誌位DDOS攻擊，採起以下策略：

• 對於SYN flood類型攻擊，利用SYNPROXY模塊進行防護。

以下圖所示，主要實現方式爲：參照Linux TCP協議棧中SYN cookie的思想，LVS代理TCP三次握手。代理過程：

1)     Client發送SYN包給LVS。

2)     LVS構造特殊SEQ的SYN ACK包給Client。

3)     Client回覆ACK給LVS。

4)     LVS驗證ACK包中ack_seq是否合法。

5)     若是合法，則LVS再和Realserver創建3次握手。

 

•  對於ACK/FIN/RSTFlood類型攻擊，查找鏈接表，若是不存在，則直接丟棄。

 

• 集羣部署方式

LVS集羣部署方式實現的主要方式爲：

• LVS和上聯交換機間運行OSPF協議。
• 上聯交換機經過ECMP等價路由，將數據流分發給LVS集羣。
• LVS集羣再轉發給業務服務器。

集羣方式部署極大的保證了異常狀況下，負載均衡服務的穩定性：

• 健壯性
  LVS和交換機間運行OSPF心跳。1個VIP配置在集羣的全部LVS上。當一臺LVS down，交換機會自動發現並將其從ECMP等價路由中剔除。
• 可擴展
  若是當前LVS集羣沒法支撐某個VIP的流量，LVS集羣能夠進行水平擴容。

 

• Keepalived優化

阿里雲在SLB中針對LVS管理軟件Keepalived進行了全面優化，主要包括：

• 優化了網絡異步模型，select方式改成epoll方式。
• 優化了reload過程。

綜上所述，基於LVS的SLB四層負載均衡產品具備以下特色；

• 高可用：LVS集羣保證了冗餘性，無單點。
• 安全：LVS自帶攻擊防護+雲盾，提供了接近於實時防護的能力。
• 健康檢查：SLB對後端ECS進行健康檢查，自動屏蔽異常狀態的ECS，待該ECS恢復正常後自動解除屏蔽。

三、Tengine技術特色

Tengine是阿里巴巴發起的WEB服務器項目，其在Nginx的基礎上，針對大訪問量網站的需求，添加了不少高級功能和特性是當前最流行的7層負載均衡開源軟件之一。Tengine的性能和穩定性已經在大型的網站如淘寶網，天貓商城等獲得了很好的檢驗。它的最終目標是打造一個高效、穩定、安全、易用的Web平臺。

注：Tengine開源地址http://tengine.taobao.org/。

針對雲計算場景，Tengine定製的主要特性以下：

• 繼承Nginx-1.4.6的全部特性，100%兼容Nginx的配置。
• 動態模塊加載（DSO）支持。加入一個模塊再也不須要從新編譯整個Tengine。
• 更增強大的負載均衡能力，包括一致性Hash模塊、會話保持模塊，還能夠對後端的服務器進行主動健康檢查，根據服務器狀態自動上線下線。
• 監控系統的負載和資源佔用從而對系統進行保護。
• 對運維人員更友好的出錯信息，便於定位出錯機器。
• 更強大的防攻擊（訪問速度限制等）模塊。

採用Tengine做爲SLB的基礎模塊的阿里雲SLB七層負載均衡產品，具備以下特色：

• 高可用：Tengine集羣保證了冗餘性，無單點。
• 安全：多維度的CC攻擊防護能力。
• 健康檢查：SLB對後端ECS進行健康檢查，自動屏蔽異常狀態的ECS，待該ECS恢復正常後自動解除屏蔽。
• 會話保持：支持7層會話保持功能。
• 一致性：支持一致性hash調度。

四、更多功能

SLB做爲負載均衡設備，其最重要的指標是【穩定性】，在進一步提升穩定性方面，主要工做包括：

• 支持集羣內部 session同步。
• 採用Anycast技術實現同城雙A。

在功能方面有更多支持，包括：

• 白名單訪問控制
  從SLB層面實現訪問控制，用戶能夠在SLB系統上配置白名單，便於用戶靈活限定外部訪問請求。
• 更多服務協議的支持
  當前已經支持HTTPS、UDP。

 

四層和七層負載均衡的區別

 

　　（一）

　　簡單理解四層和七層負載均衡:

　　① 所謂四層就是基於IP+端口的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說，二層負載均衡會經過一個虛擬MAC地址接收請求，而後再分配到真實的MAC地址；三層負載均衡會經過一個虛擬IP地址接收請求，而後再分配到真實的IP地址；四層經過虛擬IP+端口接收請求，而後再分配到真實的服務器；七層經過虛擬的URL或主機名接收請求，而後再分配到真實的服務器。

　　② 所謂的四到七層負載均衡，就是在對後臺的服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。 好比四層的負載均衡，就是經過發佈三層的IP地址（VIP），而後加四層的端口號，來決定哪些流量須要作負載均衡，對須要處理的流量進行NAT處理，轉發至後臺服務器，並記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，後續這個鏈接的全部流量都一樣轉發到同一臺服務器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，好比同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否須要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，若是你的Web服務器分紅兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就能夠當用戶來訪問你的域名時，自動辨別用戶語言，而後選擇對應的語言服務器組進行負載均衡處理。

　　③ 負載均衡器一般稱爲四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡之外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。

　　一、負載均衡分爲L4 switch（四層交換），即在OSI第4層工做，就是TCP層啦。此種Load Balance不理解應用協議（如HTTP/FTP/MySQL等等）。例子：LVS，F5。

　　二、另外一種叫作L7 switch（七層交換），OSI的最高層，應用層。此時，該Load Balancer能理解應用協議。例子：  haproxy，MySQL Proxy。

　　注意：上面的不少Load Balancer既能夠作四層交換，也能夠作七層交換。

　　（二）

　　負載均衡設備也常被稱爲"四到七層交換機"，那麼四層和七層二者到底區別在哪裏？

　　第一，技術原理上的區別。

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

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

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

　　以常見的TCP爲例，負載均衡設備若是要根據真正的應用層內容再選擇服務器，只能先代理最終的服務器和客戶端創建鏈接(三次握手)後，纔可能接受到客戶端發送的真正應用層內容的報文，而後再根據該報文中的特定字段，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。負載均衡設備在這種狀況下，更相似於一個代理服務器。負載均衡和前端的客戶端以及後端的服務器會分別創建TCP鏈接。因此從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。

　　第二，應用場景的需求。

　　七層應用負載的好處，是使得整個網絡更"智能化"。例如訪問一個網站的用戶流量，能夠經過七層的方式，將對圖片類的請求轉發到特定的圖片服務器並能夠使用緩存技術；將對文字類的請求能夠轉發到特定的文字服務器並能夠使用壓縮技術。固然這只是七層應用的一個小案例，從技術原理上，這種方式能夠對客戶端的請求和服務器的響應進行任意意義上的修改，極大的提高了應用系統在網絡層的靈活性。不少在後臺，例如Nginx或者Apache上部署的功能能夠前移到負載均衡設備上，例如客戶請求中的Header重寫，服務器響應中的關鍵字過濾或者內容插入等功能。

　　另一個經常被提到功能就是安全性。網絡中最多見的SYN Flood攻擊，即黑客控制衆多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，一般這種攻擊會大量發送SYN報文，耗盡服務器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也能夠看出，四層模式下這些SYN攻擊都會被轉發到後端的服務器上；而七層模式下這些SYN攻擊天然在負載均衡設備上就截止，不會影響後臺服務器的正常運營。另外負載均衡設備能夠在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提升系統總體安全。

　　如今的7層負載均衡，主要仍是着重於應用HTTP協議，因此其應用範圍主要是衆多的網站或者內部信息平臺等基於B/S開發的系統。 4層負載均衡則對應其餘TCP應用，例如基於C/S開發的ERP等系統。

　　第三，七層應用須要考慮的問題。

　　1：是否真的必要，七層應用的確能夠提升流量智能化，同時必不可免的帶來設備配置複雜，負載均衡壓力增高以及故障排查上的複雜性等問題。在設計系統時須要考慮四層七層同時應用的混雜狀況。

　　2：是否真的能夠提升安全性。例如SYN Flood攻擊，七層模式的確將這些流量從服務器屏蔽，但負載均衡設備自己要有強大的抗DDoS能力，不然即便服務器正常而做爲中樞調度的負載均衡設備故障也會致使整個應用的崩潰。

　　3：是否有足夠的靈活度。七層應用的優點是可讓整個應用的流量智能化，可是負載均衡設備須要提供完善的七層功能，知足客戶根據不一樣狀況的基於應用的調度。最簡單的一個考覈就是可否取代後臺Nginx或者Apache等服務器上的調度功能。可以提供一個七層應用開發接口的負載均衡設備，可讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。

　　（本節出自 「ADC技術博客」 博客，請務必保留此出處http://virtualadc.blog.51cto.com/3027116/591396）

　　（三）

　　負載均衡四七層介紹:

　　負載均衡（Load Balance）創建在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增長吞吐量、增強網絡數據處理能力、提升網絡的靈活性和可用性。

　　負載均衡有兩方面的含義：首先，大量的併發訪問或數據流量分擔到多臺節點設備上分別處理，減小用戶等待響應的時間；其次，單個重負載的運算分擔到多臺節點設備上作並行處理，每一個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力獲得大幅度提升。

　　本文所要介紹的負載均衡技術主要是指在均衡服務器羣中全部服務器和應用程序之間流量負載的應用，目前負載均衡技術大多數是用於提升諸如在Web服務器、FTP服務器和其它關鍵任務服務器上的Internet服務器程序的可用性和可伸縮性。

　　負載均衡技術分類

　　目前有許多不一樣的負載均衡技術用以知足不一樣的應用需求，下面從負載均衡所採用的設備對象、應用的網絡層次（指OSI參考模型）及應用的地理結構等來分類。

　　軟/硬件負載均衡

　　軟件負載均衡解決方案是指在一臺或多臺服務器相應的操做系統上安裝一個或多個附加軟件來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優勢是基於特定環境，配置簡單，使用靈活，成本低廉，能夠知足通常的負載均衡需求。

　　軟件解決方案缺點也較多，由於每臺服務器上安裝額外的軟件運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，因此當鏈接請求特別大的時候，軟件自己會成爲服務器工做成敗的一個關鍵；軟件可擴展性並非很好，受到操做系統的限制；因爲操做系統自己的Bug，每每會引發安全問題。

　　硬件負載均衡解決方案是直接在服務器和外部網絡間安裝負載均衡設備，這種設備咱們一般稱之爲負載均衡器，因爲專門的設備完成專門的任務，獨立於操做系統，總體性能獲得大量提升，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。 

　　負載均衡器有多種多樣的形式，除了做爲獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於服務器與Internet連接之間，有些則以兩塊網絡適配器將這一功能集成到PC中，一塊鏈接到Internet上，一塊鏈接到後端服務器羣的內部網絡上。

　　通常而言，硬件負載均衡在功能、性能上優於軟件方式，不過成本昂貴。

　　本地/全局負載均衡

　　負載均衡從其應用的地理結構上分爲本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance，也叫地域負載均衡)，本地負載均衡是指對本地的服務器羣作負載均衡，全局負載均衡是指對分別放置在不一樣的地理位置、有不一樣網絡結構的服務器羣間做負載均衡。

　　本地負載均衡能有效地解決數據流量過大、網絡負荷太重的問題，而且不需花費昂貴開支購置性能卓越的服務器，充分利用現有設備，避免服務器單點故障形成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給服務器羣內的服務器共同負擔。即便是再給現有服務器擴充升級，也只是簡單地增長一個新的服務器到服務羣中，而不需改變現有網絡結構、中止現有的服務。 

　　全局負載均衡主要用於在一個多區域擁有本身服務器的站點，爲了使全球用戶只以一個IP地址或域名就能訪問到離本身最近的服務器，從而得到最快的訪問速度，也可用於子公司分散站點分佈廣的大公司經過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。

　　網絡層次上的負載均衡

　　針對網絡上負載太重的不一樣瓶頸所在，從網絡的不一樣層次入手，咱們能夠採用相應的負載均衡技術來解決現有問題。 

　　隨着帶寬增長，數據流量不斷增大，網絡核心部分的數據接口將面臨瓶頸問題，原有的單一線路將很難知足需求，並且線路的升級又過於昂貴甚至難以實現，這時就能夠考慮採用鏈路聚合（Trunking）技術。

　　鏈路聚合技術（第二層負載均衡）將多條物理鏈路看成一條單一的聚合邏輯鏈路使用，網絡數據流量由聚合邏輯鏈路中全部物理鏈路共同承擔，由此在邏輯上增大了鏈路的容量，使其能知足帶寬增長的需求。

　　現代負載均衡技術一般操做於網絡的第四層或第七層。第四層負載均衡將一個Internet上合法註冊的IP地址映射爲多個內部服務器的IP地址，對每次 TCP鏈接請求動態使用其中一個內部IP地址，達到負載均衡的目的。在第四層交換機中，此種均衡技術獲得普遍的應用，一個目標地址是服務器羣VIP（虛擬 IP，Virtual IP address）鏈接請求的數據包流經交換機，交換機根據源端和目的IP地址、TCP或UDP端口號和必定的負載均衡策略，在服務器IP和VIP間進行映射，選取服務器羣中最好的服務器來處理鏈接請求。

　　第七層負載均衡控制應用層服務的內容，提供了一種對訪問流量的高層控制方式，適合對HTTP服務器羣的應用。第七層負載均衡技術經過檢查流經的HTTP報頭，根據報頭內的信息來執行負載均衡任務。 

　　第七層負載均衡優勢表如今以下幾個方面： 

　　經過對HTTP報頭的檢查，能夠檢測出HTTP400、500和600系列的錯誤信息，於是能透明地將鏈接請求從新定向到另外一臺服務器，避免應用層故障。

　　可根據流經的數據類型（如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等），把數據流量引向相應內容的服務器來處理，增長系統性能。

　　能根據鏈接請求的類型，如是普通文本、圖象等靜態文檔請求，仍是asp、cgi等的動態文檔請求，把相應的請求引向相應的服務器來處理，提升系統的性能及安全性。

　　第七層負載均衡受到其所支持的協議限制（通常只有HTTP），這樣就限制了它應用的普遍性，而且檢查HTTP報頭會佔用大量的系統資源，勢必會影響到系統的性能，在大量鏈接請求的狀況下，負載均衡設備自身容易成爲網絡總體性能的瓶頸。

　　負載均衡策略

　　在實際應用中，咱們可能不想僅僅是把客戶端的服務請求平均地分配給內部服務器，而無論服務器是否宕機。而是想使Pentium III服務器比Pentium II能接受更多的服務請求，一臺處理服務請求較少的服務器能分配到更多的服務請求，出現故障的服務器將再也不接受服務請求直至故障恢復等等。

　　選擇合適的負載均衡策略，使多個設備能很好的共同完成任務，消除或避免現有網絡負載分佈不均、數據流量擁擠反應時間長的瓶頸。在各負載均衡方式中，針對不一樣的應用需求，在OSI參考模型的第2、3、4、七層的負載均衡都有相應的負載均衡策略。

　　負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：1、負載均衡算法，2、對網絡系統情況的檢測方式和能力。 

　　考慮到服務請求的不一樣類型、服務器的不一樣處理能力以及隨機選擇形成的負載分配不均勻等問題，爲了更加合理的把負載分配給內部的多個服務器，就須要應用相應的可以正確反映各個服務器處理能力及網絡狀態的負載均衡算法：

　　輪循均衡（Round Robin）：每一次來自網絡的請求輪流分配給內部中的服務器，從1至N而後從新開始。此種均衡算法適合於服務器組中的全部服務器都有相同的軟硬件配置而且平均服務請求相對均衡的狀況。

　　權重輪循均衡（Weighted Round Robin）：根據服務器的不一樣處理能力，給每一個服務器分配不一樣的權值，使其可以接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是 3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器獲得更多的使用率，避免低性能的服務器負載太重。

　　隨機均衡（Random）：把來自網絡的請求隨機分配給內部中的多個服務器。

　　權重隨機均衡（Weighted Random）：此種均衡算法相似於權重輪循算法，不過在處理請求分擔時是個隨機選擇的過程。

　　響應速度均衡（Response Time）：負載均衡設備對內部各服務器發出一個探測請求（例如Ping），而後根據內部中各服務器對探測請求的最快響應時間來決定哪一臺服務器來響應客戶端的服務請求。此種均衡算法能較好的反映服務器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與服務器間的最快響應時間，而不是客戶端與服務器間的最快響應時間。

　　最少鏈接數均衡（Least Connection）：客戶端的每一次請求服務在服務器停留的時間可能會有較大的差別，隨着工做時間加長，若是採用簡單的輪循或隨機均衡算法，每一臺服務器上的鏈接進程可能會產生極大的不一樣，並無達到真正的負載均衡。最少鏈接數均衡算法對內部中需負載的每一臺服務器都有一個數據記錄，記錄當前該服務器正在處理的鏈接數量，當有新的服務鏈接請求時，將把當前請求分配給鏈接數最少的服務器，使均衡更加符合實際狀況，負載更加均衡。此種均衡算法適合長時處理的請求服務，如FTP。 

　　處理能力均衡：此種均衡算法將把服務請求分配給內部中處理負荷（根據服務器CPU型號、CPU數量、內存大小及當前鏈接數等換算而成）最輕的服務器，因爲考慮到了內部服務器的處理能力及當前網絡運行情況，因此此種均衡算法相對來講更加精確，尤爲適合運用到第七層（應用層）負載均衡的狀況下。

　　DNS響應均衡（Flash DNS）：在Internet上，不管是HTTP、FTP或是其它的服務請求，客戶端通常都是經過域名解析來找到服務器確切的IP地址的。在此均衡算法下，分處在不一樣地理位置的負載均衡設備收到同一個客戶端的域名解析請求，並在同一時間內把此域名解析成各自相對應服務器的IP地址（即與此負載均衡設備在同一位地理位置的服務器的IP地址）並返回給客戶端，則客戶端將以最早收到的域名解析IP地址來繼續請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的狀況下，對本地負載均衡是沒有意義的。

　　儘管有多種的負載均衡算法能夠較好的把數據流量分配給服務器去負載，但若是負載均衡策略沒有對網絡系統情況的檢測方式和能力，一旦在某臺服務器或某段負載均衡設備與服務器網絡間出現故障的狀況下，負載均衡設備依然把一部分數據流量引向那臺服務器，這勢必形成大量的服務請求被丟失，達不到不間斷可用性的要求。因此良好的負載均衡策略應有對網絡故障、服務器系統故障、應用服務故障的檢測方式和能力：

　　Ping偵測：經過ping的方式檢測服務器及網絡系統情況，此種方式簡單快速，但只能大體檢測出網絡及服務器上的操做系統是否正常，對服務器上的應用服務檢測就無能爲力了。

　　TCP Open偵測：每一個服務都會開放某個經過TCP鏈接，檢測服務器上某個TCP端口（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。

　　HTTP URL偵測：好比向HTTP服務器發出一個對main.html文件的訪問請求，若是收到錯誤信息，則認爲服務器出現故障。

　　負載均衡策略的優劣除受上面所講的兩個因素影響外，在有些應用狀況下，咱們須要未來自同一客戶端的全部請求都分配給同一臺服務器去負擔，例如服務器將客戶端註冊、購物等服務請求信息保存的本地數據庫的狀況下，把客戶端的子請求分配給同一臺服務器來處理就顯的相當重要了。有兩種方式能夠解決此問題，一是根據IP地址把來自同一客戶端的屢次請求分配給同一臺服務器處理，客戶端IP地址與服務器的對應信息是保存在負載均衡設備上的；二是在客戶端瀏覽器 cookie內作獨一無二的標識來把屢次請求分配給同一臺服務器處理，適合經過代理服務器上網的客戶端。

　　還有一種路徑外返回模式（Out of Path Return），當客戶端鏈接請求發送給負載均衡設備的時候，中心負載均衡設備將請求引向某個服務器，服務器的迴應請求再也不返回給中心負載均衡設備，即繞過流量分配器，直接返回給客戶端，所以中心負載均衡設備只負責接受並轉發請求，其網絡負擔就減小了不少，而且給客戶端提供了更快的響應時間。此種模式通常用於HTTP服務器羣，在各服務器上要安裝一塊虛擬網絡適配器，並將其IP地址設爲服務器羣的VIP，這樣才能在服務器直接回應客戶端請求時順利的達成三次握手。

　　負載均衡實施要素

　　負載均衡方案應是在網站建設初期就應考慮的問題，不過有時隨着訪問流量的爆炸性增加，超出決策者的意料，這也就成爲不得不面對的問題。當咱們在引入某種負載均衡方案乃至具體實施時，像其餘的許多方案同樣，首先是肯定當前及未來的應用需求，而後在代價與收效之間作出權衡。

　　針對當前及未來的應用需求，分析網絡瓶頸的不一樣所在，咱們就須要確立是採用哪一類的負載均衡技術，採用什麼樣的均衡策略，在可用性、兼容性、安全性等等方面要知足多大的需求，如此等等。 

　　無論負載均衡方案是採用花費較少的軟件方式，仍是購買代價高昂在性能功能上更強的第四層交換機、負載均衡器等硬件方式來實現，亦或其餘種類不一樣的均衡技術，下面這幾項都是咱們在引入均衡方案時可能要考慮的問題：

　　性能：性能是咱們在引入均衡方案時須要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可將每秒鐘經過網絡的數據包數目作爲一個參數，另外一個參數是均衡方案中服務器羣所能處理的最大併發鏈接數目，可是，假設一個均衡系統能處理百萬計的併發鏈接數，但是卻只能以每秒2個包的速率轉發，這顯然是沒有任何做用的。性能的優劣與負載均衡設備的處理能力、採用的均衡策略息息相關，而且有兩點須要注意：1、均衡方案對服務器羣總體的性能，這是響應客戶端鏈接請求速度的關鍵；2、負載均衡設備自身的性能，避免有大量鏈接請求時自身性能不足而成爲服務瓶頸。有時咱們也能夠考慮採用混合型負載均衡策略來提高服務器羣的整體性能，如DNS負載均衡與NAT負載均衡相結合。另外，針對有大量靜態文檔請求的站點，也能夠考慮採用高速緩存技術，相對來講更節省費用，更能提升響應性能；對有大量ssl/xml內容傳輸的站點，更應考慮採用ssl/xml加速技術。

　　可擴展性：IT技術突飛猛進，一年之前最新的產品，如今或許已經是網絡中性能最低的產品；業務量的急速上升，一年前的網絡，如今須要新一輪的擴展。合適的均衡解決方案應能知足這些需求，能均衡不一樣操做系統和硬件平臺之間的負載，能均衡HTTP、郵件、新聞、代理、數據庫、防火牆和 Cache等不一樣服務器的負載，而且能以對客戶端徹底透明的方式動態增長或刪除某些資源。

　　靈活性：均衡解決方案應能靈活地提供不一樣的應用需求，知足應用需求的不斷變化。在不一樣的服務器羣有不一樣的應用需求時，應有多樣的均衡策略提供更普遍的選擇。

　　可靠性：在對服務質量要求較高的站點，負載均衡解決方案應能爲服務器羣提供徹底的容錯性和高可用性。但在負載均衡設備自身出現故障時，應該有良好的冗餘解決方案，提升可靠性。使用冗餘時，處於同一個冗餘單元的多個負載均衡設備必須具備有效的方式以便互相進行監控，保護系統儘量地避免遭受到重大故障的損失。

　　易管理性：無論是經過軟件仍是硬件方式的均衡解決方案，咱們都但願它有靈活、直觀和安全的管理方式，這樣便於安裝、配置、維護和監控，提升工做效率，避免差錯。在硬件負載均衡設備上，目前主要有三種管理方式可供選擇：1、命令行接口（CLI：Command Line Interface），可經過超級終端鏈接負載均衡設備串行接口來管理，也能telnet遠程登陸管理，在初始化配置時，每每要用到前者；2、圖形用戶接口（GUI：Graphical User Interfaces），有基於普通web頁的管理，也有經過Java Applet 進行安全管理，通常都須要管理端安裝有某個版本的瀏覽器；3、SNMP（Simple Network Management Protocol，簡單網絡管理協議）支持，經過第三方網絡管理軟件對符合SNMP標準的設備進行管理。

 

 

lvs、haproxy、nginx 負載均衡的比較分析

對軟件實現負載均衡的幾個軟件，小D詳細看了一下，從性能和穩定上仍是LVS最牛，基本達到了F5硬件設備的60%性能，其餘幾個10%都有點困難。

     不過就由於LVS忒牛了，配置也最麻煩了，並且健康檢測須要另外配置Ldirector，其餘HAPROXY和NGINX本身就用，並且配置超級簡單。

 

 

 

     因此小D建議，若是網站訪問量不是門戶級別的用HAPROXY或者NGINX就OK了，到了門戶級別在用LVS+Idirector吧 哈哈

    lvs和nginx均可以用做多機負載的方案，它們各有優缺，在生產環境中須要好好分析實際狀況並加以利用。

首先提醒，作技術切不可人云亦云，我雲即你雲；同時也不可太趨向保守，過於相信舊有方式而等別人來幫你作墊被測試。把全部即時據說到的好東西加以鑽研，從而提升本身對技術的認知和水平，乃是一個好習慣。

下面來分析一下二者：

1、lvs的優點：

一、抗負載能力強，由於lvs工做方式的邏輯是很是之簡單，並且工做在網絡4層僅作請求分發之用，沒有流量，因此在效率上基本不須要太過考慮。在我手裏的 lvs，僅僅出過一次問題：在併發最高的一小段時間內均衡器出現丟包現象，據分析爲網絡問題，即網卡或linux2.4內核的承載能力已到上限，內存和 cpu方面基本無消耗。

二、配置性低，這一般是一大劣勢，但同時也是一大優點，由於沒有太多可配置的選項，因此除了增減服務器，並不須要常常去觸碰它，大大減小了人爲出錯的概率。

三、工做穩定，由於其自己抗負載能力很強，因此穩定性高也是瓜熟蒂落，另外各類lvs都有完整的雙機熱備方案，因此一點不用擔憂均衡器自己會出什麼問題，節點出現故障的話，lvs會自動判別，因此係統總體是很是穩定的。

四、無流量，上面已經有所說起了。lvs僅僅分發請求，而流量並不從它自己出去，因此能夠利用它這點來作一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。

五、基本上能支持全部應用，由於lvs工做在4層，因此它能夠對幾乎全部應用作負載均衡，包括http、數據庫、聊天室等等。

另：lvs也不是徹底能判別節點故障的，譬如在wlc分配方式下，集羣裏有一個節點沒有配置VIP，會使整個集羣不能使用，這時使用wrr分配方式則會丟掉一臺機。目前這個問題還在進一步測試中。因此，用lvs也得多多小心爲妙。

2、nginx和lvs做對比的結果

一、nginx工做在網絡的7層，因此它能夠針對http應用自己來作分流策略，好比針對域名、目錄結構等，相比之下lvs並不具有這樣的功能，因此 nginx單憑這點可利用的場合就遠多於lvs了；但nginx有用的這些功能使其可調整度要高於lvs，因此常常要去觸碰觸碰，由lvs的第2條優勢 看，觸碰多了，人爲出問題的概率也就會大。

二、nginx對網絡的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區份內外網，若是是同時擁有內外網的 節點，就至關於單機擁有了備份線路；lvs就比較依賴於網絡環境，目前來看服務器在同一網段內而且lvs使用direct方式分流，效果較能獲得保證。另 外注意，lvs須要向託管商至少申請多一個ip來作Visual IP，貌似是不能用自己的IP來作VIP的。要作好LVS管理員，確實得跟進學習不少有關網絡通訊方面的知識，就再也不是一個HTTP那麼簡單了。

三、nginx安裝和配置比較簡單，測試起來也很方便，由於它基本能把錯誤用日誌打印出來。lvs的安裝和配置、測試就要花比較長的時間了，由於同上所述，lvs對網絡依賴比較大，不少時候不能配置成功都是由於網絡問題而不是配置問題，出了問題要解決也相應的會麻煩得多。

四、nginx也一樣能承受很高負載且穩定，但負載度和穩定度差lvs還有幾個等級：nginx處理全部流量因此受限於機器IO和配置；自己的bug也仍是難以免的；nginx沒有現成的雙機熱備方案，因此跑在單機上仍是風險較大，單機上的事情全都很難說。

五、nginx能夠檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點。目前lvs中 ldirectd也能支持針對服務器內部的狀況來監控，但lvs的原理使其不能重發請求。重發請求這點，譬如用戶正在上傳一個文件，而處理該上傳的節點剛 好在上傳過程當中出現故障，nginx會把上傳切到另外一臺服務器從新處理，而lvs就直接斷掉了，若是是上傳一個很大的文件或者很重要的文件的話，用戶可能 會所以而惱火。

六、nginx對請求的異步處理能夠幫助節點服務器減輕負載，假如使用apache直接對外服務，那麼出現不少的窄帶連接時apache服務器將會佔用大 量內存而不能釋放，使用多一個nginx作apache代理的話，這些窄帶連接會被nginx擋住，apache上就不會堆積過多的請求，這樣就減小了相 當多的內存佔用。這點使用squid也有相同的做用，即便squid自己配置爲不緩存，對apache仍是有很大幫助的。lvs沒有這些功能，也就沒法能 比較。

七、nginx能支持http和email（email的功能估計比較少人用），lvs所支持的應用在這點上會比nginx更多。

在使用上，通常最前端所採起的策略應是lvs，也就是DNS的指向應爲lvs均衡器，lvs的優勢令它很是適合作這個任務。

重要的ip地址，最好交由lvs託管，好比數據庫的ip、webservice服務器的ip等等，這些ip地址隨着時間推移，使用面會愈來愈大，若是更換ip則故障會接踵而至。因此將這些重要ip交給lvs託管是最爲穩妥的，這樣作的惟一缺點是須要的VIP數量會比較多。

nginx可做爲lvs節點機器使用，一是能夠利用nginx的功能，二是能夠利用nginx的性能。固然這一層面也能夠直接使用squid，squid的功能方面就比nginx弱很多了，性能上也有所遜色於nginx。

nginx也可做爲中層代理使用，這一層面nginx基本上無對手，惟一能夠撼動nginx的就只有lighttpd了，不過lighttpd目前尚未 能作到nginx徹底的功能，配置也不那麼清晰易讀。另外，中層代理的IP也是重要的，因此中層代理也擁有一個VIP和lvs是最完美的方案了。

nginx也可做爲網頁靜態服務器，不過超出了本文討論的範疇，簡單提一下。

具體的應用還得具體分析，若是是比較小的網站（日PV<1000萬），用nginx就徹底能夠了，若是機器也很多，能夠用DNS輪詢，lvs所耗費的機器仍是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用lvs。

****************************************************************************************************************

Nginx的優勢:
性能好，能夠負載超過1萬的併發。
功能多，除了負載均衡，還能做Web服務器，並且能夠經過Geo模塊來實現流量分配。
社區活躍，第三方補丁和模塊不少
支持gzip proxy
缺點:
不支持session保持。
對後端realserver的健康檢查功能效果很差。並且只支持經過端口來檢測，不支持經過url來檢測。
nginx對big request header的支持不是很好，若是client_header_buffer_size設置的比較小，就會返回400bad request頁面。
Haproxy的優勢:
它的優勢正好能夠補充nginx的缺點。支持session保持，同時支持經過獲取指定的url來檢測後端服務器的狀態。
支持tcp模式的負載均衡。好比能夠給MySQL的從服務器集羣和郵件服務器作負載均衡。
缺點：
不支持虛擬主機(這個很傻啊)
目前沒有nagios和cacti的性能監控模板
LVS的優勢:
性能好，接近硬件設備的網絡吞吐和鏈接負載能力。
LVS的DR模式，支持經過廣域網進行負載均衡。這個其餘任何負載均衡軟件目前都不具有。
缺點：
比較重型。另外社區不如nginx活躍。

*************************************************************************************

 

如今網絡中常見的的負載均衡主要分爲兩種：一種是經過硬件來進行進行，常見的硬件有比較昂貴的NetScaler、F五、Radware和Array等商用的負載均衡器，也有相似於LVS、Nginx、HAproxy的基於Linux的開源的負載均衡策略,

商用負載均衡裏面NetScaler從效果上比F5的效率上更高。對於負載均衡器來講，不過商用負載均衡因爲能夠創建在四~七層協議之上，所以適用 面更廣因此有其不可替代性，他的優勢就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，因此對於規模較小的網絡服務來講暫時尚未須要使用。

另外一種負載均衡的方式是經過軟件：比較常見的有LVS、Nginx、HAproxy等，其中LVS是創建在四層協議上面的，而另外Nginx和HAproxy是創建在七層協議之上的，下面分別介紹關於

LVS：使用集羣技術和Linux操做系統實現一個高性能、高可用的服務器，它具備很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。

LVS的特色是：

一、抗負載能力強、是工做在網絡4層之上僅做分發之用，沒有流量的產生；

二、配置性比較低，這是一個缺點也是一個優勢，由於沒有可太多配置的東西，因此並不須要太多接觸，大大減小了人爲出錯的概率；

三、工做穩定，自身有完整的雙機熱備方案；

四、無流量，保證了均衡器IO的性能不會收到大流量的影響；

五、應用範圍比較廣，能夠對全部應用作負載均衡；

六、LVS須要向IDC多申請一個IP來作Visual IP，所以須要必定的網絡知識，因此對操做人的要求比較高。

Nginx的特色是：

一、工做在網絡的7層之上，能夠針對http應用作一些分流的策略，好比針對域名、目錄結構；

二、Nginx對網絡的依賴比較小；

三、Nginx安裝和配置比較簡單，測試起來比較方便；

四、也能夠承擔高的負載壓力且穩定，通常能支撐超過1萬次的併發；

五、Nginx能夠經過端口檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點，不過其中缺點就是不支持url來檢測；

六、Nginx對請求的異步處理能夠幫助節點服務器減輕負載；

七、Nginx能支持http和Email，這樣就在適用範圍上面小不少；

八、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡算法。

HAProxy的特色是：

一、HAProxy是工做在網絡7層之上。

二、可以補充Nginx的一些缺點好比Session的保持，Cookie的引導等工做

三、支持url檢測後端的服務器出問題的檢測會有很好的幫助。

四、更多的負載均衡策略好比：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現

五、單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度。

六、HAProxy能夠對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。

***********************************************************************************************

 

如今網站發展的趨勢對網絡負載均衡的使用是隨着網站規模的提高根據不一樣的階段來使用不一樣的技術：

第一階段：利用Nginx或者HAProxy進行單點的負載均衡，這一階段服務器規模剛脫離開單服務器、單數據庫的模式，須要必定的負載均衡，可是 仍然規模較小沒有專業的維護團隊來進行維護，也沒有須要進行大規模的網站部署。這樣利用Nginx或者HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協議就能夠。這時是第一選擇

第二階段：隨着網絡服務進一步擴大，這時單點的Nginx已經不能知足，這時使用LVS或者商用F5就是首要選擇，Nginx此時就做爲LVS或者 F5的節點來使用，具體LVS或者F5的是選擇是根據公司規模，人才以及資金能力來選擇的，這裏也不作詳談，可是通常來講這階段相關人才跟不上業務的提 升，因此購買商業負載均衡已經成爲了必經之路。

第三階段：這時網絡服務已經成爲主流產品，此時隨着公司知名度也進一步擴展，相關人才的能力以及數量也隨之提高，這時不管從開發適合自身產品的定製，以及下降成原本講開源的LVS，已經成爲首選，這時LVS會成爲主流。

最終造成比較理想的狀態爲：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。

 

 

LVS：三種負載均衡方式比較

 

一、什麼是LVS？

　　首先簡單介紹一下LVS (Linux Virtual Server)究竟是什麼東西，其實它是一種集羣(Cluster)技術，採用IP負載均衡技術和基於內容請求分發技術。調度器具備很好的吞吐率，將請求均衡地轉移到不一樣的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，並且無需修改客戶端和服務器端的程序。

　　爲此，在設計時須要考慮系統的透明性、可伸縮性、高可用性和易管理性。通常來講，LVS集

　　羣採用三層結構，其體系結構如圖所示：

　　LVS集羣的體系結構

　　二、LVS主要組成部分爲：

　　負載調度器(load balancer/ Director)，它是整個集羣對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認爲服務是來自一個IP地址(咱們可稱之爲虛擬IP地址)上的。

　　服務器池(server pool/ Realserver)，是一組真正執行客戶請求的服務器，執行的服務通常有WEB、MAIL、FTP和DNS等。

　　共享存儲(shared storage)，它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。

　　三、LVS負載均衡方式:

　　◆Virtual Server via Network Address Translation NAT(VS/NAT)

　　VS/NAT是一種最簡單的方式，全部的RealServer只須要將本身的網關指向Director便可。客戶端能夠是任意操做系統，但此方式下，一個Director可以帶動的RealServer比較有限。在VS/NAT的方式下，Director也能夠兼爲一臺RealServer。VS/NAT的體系結構如圖所示。

　　VS/NAT的體系結構

　　◆Virtual Server via IP Tunneling(VS/TUN)

　　IP隧道(IP tunneling)是將一個IP報文封裝在另外一個IP報文的技術，這能夠使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。IP隧道技術亦稱爲IP封裝技術(IP encapsulation)。IP隧道主要用於移動主機和虛擬私有網絡(Virtual Private Network)，在其中隧道都是靜態創建的，隧道一端有一個IP地址，另外一端也有惟一的IP地址。它的鏈接調度和管理與VS/NAT中的同樣，只是它的報文轉發方法不一樣。調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，將請求報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的服務器;服務器收到報文後，先將報文解封得到原來目標地址爲 VIP 的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。

　　VS/TUN的體系結構

　　VS/TUN的工做流程：

　　◆Virtual Server via Direct Routing(VS/DR)

　　VS/DR方式是經過改寫請求報文中的MAC地址部分來實現的。Director和RealServer必需在物理上有一個網卡經過不間斷的局域網相連。 RealServer上綁定的VIP配置在各自Non-ARP的網絡設備上(如lo或tunl),Director的VIP地址對外可見，而RealServer的VIP對外是不可見的。RealServer的地址便可以是內部地址，也能夠是真實地址。

　　VS/DR的體系結構

　　VS/DR的工做流程

　　VS/DR的工做流程如圖所示：它的鏈接調度和管理與VS/NAT和VS/TUN中的同樣，它的報文轉發方法又有不一樣，將報文直接路由給目標服務器。在VS/DR中，調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改成選出服務器的MAC地址，再將修改後的數據幀在與服務器組的局域網上發送。由於數據幀的MAC地址是選出的服務器，因此服務器確定能夠收到這個數據幀，從中能夠得到該IP報文。當服務器發現報文的目標地址VIP是在本地的網絡設備上，服務器處理這個報文，而後根據路由表將響應報文直接返回給客戶。

　　VS/DR的工做流程

　　四、三種負載均衡方式比較：

　　◆Virtual Server via NAT

　　VS/NAT 的優勢是服務器能夠運行任何支持TCP/IP的操做系統，它只須要一個IP地址配置在調度器上，服務器組能夠用私有的IP地址。缺點是它的伸縮能力有限，當服務器結點數目升到20時，調度器自己有可能成爲系統的新瓶頸，由於在VS/NAT中請求和響應報文都須要經過負載調度器。咱們在Pentium166 處理器的主機上測得重寫報文的平均延時爲60us，性能更高的處理器上延時會短一些。假設TCP報文的平均長度爲536 Bytes，則調度器的最大吞吐量爲8.93 MBytes/s. 咱們再假設每臺服務器的吞吐量爲800KBytes/s，這樣一個調度器能夠帶動10臺服務器。(注：這是很早之前測得的數據)

　　基於 VS/NAT的的集羣系統能夠適合許多服務器的性能要求。若是負載調度器成爲系統新的瓶頸，能夠有三種方法解決這個問題：混合方法、VS/TUN和 VS/DR。在DNS混合集羣系統中，有若干個VS/NAT負調度器，每一個負載調度器帶本身的服務器集羣，同時這些負載調度器又經過RR-DNS組成簡單的域名。

　　但VS/TUN和VS/DR是提升系統吞吐量的更好方法。

　　對於那些將IP地址或者端口號在報文數據中傳送的網絡服務，須要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。這會帶來實現的工做量，同時應用模塊檢查報文的開銷會下降系統的吞吐率。

　　◆Virtual Server via IP Tunneling

　　在VS/TUN 的集羣系統中，負載調度器只將請求調度到不一樣的後端服務器，後端服務器將應答的數據直接返回給用戶。這樣，負載調度器就能夠處理大量的請求，它甚至能夠調度百臺以上的服務器(同等規模的服務器)，而它不會成爲系統的瓶頸。即便負載調度器只有100Mbps的全雙工網卡，整個系統的最大吞吐量可超過 1Gbps。因此，VS/TUN能夠極大地增長負載調度器調度的服務器數量。VS/TUN調度器能夠調度上百臺服務器，而它自己不會成爲系統的瓶頸，能夠用來構建高性能的超級服務器。VS/TUN技術對服務器有要求，即全部的服務器必須支持「IP Tunneling」或者「IP Encapsulation」協議。目前，VS/TUN的後端服務器主要運行Linux操做系統，咱們沒對其餘操做系統進行測試。由於「IP Tunneling」正成爲各個操做系統的標準協議，因此VS/TUN應該會適用運行其餘操做系統的後端服務器。

　　◆Virtual Server via Direct Routing

　　跟VS/TUN方法同樣，VS/DR調度器只處理客戶到服務器端的鏈接，響應數據能夠直接從獨立的網絡路由返回給客戶。這能夠極大地提升LVS集羣系統的伸縮性。跟VS/TUN相比，這種方法沒有IP隧道的開銷，可是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備(或者設備別名)不做ARP響應，或者能將報文重定向(Redirect)到本地的Socket端口上。

　　三種LVS負載均衡技術的優缺點概括如下表：

　　VS/NATVS/TUNVS/DR

　　服務器操做系統任意支持隧道多數(支持Non-arp)

　　服務器網絡私有網絡局域網/廣域網局域網

　　服務器數目(100M網絡)10~20100大於100

　　服務器網關負載均衡器本身的路由本身的路由

　　效率通常高最高

　　注：以上三種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡，調度器的硬件配置與後端服務器的硬件配置相同，並且是對通常Web服務。使 用更高的硬件配置(如千兆網卡和更快的處理器)做爲調度器，調度器所能調度的服務器數量會相應增長。當應用不一樣時，服務器的數目也會相應地改變。因此，以上數據估計主要是爲三種方法的伸縮性進行量化比較。

　　五、負載均衡調度算法

　　◆最少的鏈接方式(Least Connection)：傳遞新的鏈接給那些進行最少鏈接處理的服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配, 直到其恢復正常。

　　◆最快模式(Fastest)：傳遞鏈接給那些響應最快的服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

　　◆觀察模式(Observed)：鏈接數目和響應時間以這兩項的最佳平衡爲依據爲新的請求選擇服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

　　◆預測模式(Predictive)：BIG-IP利用收集到的服務器當前的性能指標，進行預測分析，選擇一臺服務器在下一個時間片內，其性能將達到最佳的服務器相應用戶的請求。(被BIG-IP 進行檢測)

　　◆動態性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應用程序和應用服務器的各項性能參數，動態調整流量分配。

　　◆動態服務器補充(Dynamic Server Act.):當主服務器羣中因故障致使數量減小時，動態地將備份服務器補充至主服務器羣。

　　◆服務質量(QoS):按不一樣的優先級對數據流進行分配。

　　◆服務類型(ToS): 按不一樣的服務類型(在Type of Field中標識)負載均衡對數據流進行分配。

　　◆規則模式：針對不一樣的數據流設置導向規則，用戶可自行

 

 

一、什麼是LVS？

　　首先簡單介紹一下LVS (Linux Virtual Server)究竟是什麼東西，其實它是一種集羣(Cluster)技術，採用IP負載均衡技術和基於內容請求分發技術。調度器具備很好的吞吐率，將請求均衡地轉移到不一樣的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，並且無需修改客戶端和服務器端的程序。

　　爲此，在設計時須要考慮系統的透明性、可伸縮性、高可用性和易管理性。通常來講，LVS集

　　羣採用三層結構，其體系結構如圖所示：

　　LVS集羣的體系結構

　　二、LVS主要組成部分爲：

　　負載調度器(load balancer/ Director)，它是整個集羣對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認爲服務是來自一個IP地址(咱們可稱之爲虛擬IP地址)上的。

　　服務器池(server pool/ Realserver)，是一組真正執行客戶請求的服務器，執行的服務通常有WEB、MAIL、FTP和DNS等。

　　共享存儲(shared storage)，它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。

　　三、LVS負載均衡方式:

　　◆Virtual Server via Network Address Translation NAT(VS/NAT)

　　VS/NAT是一種最簡單的方式，全部的RealServer只須要將本身的網關指向Director便可。客戶端能夠是任意操做系統，但此方式下，一個Director可以帶動的RealServer比較有限。在VS/NAT的方式下，Director也能夠兼爲一臺RealServer。VS/NAT的體系結構如圖所示。

　　VS/NAT的體系結構

　　◆Virtual Server via IP Tunneling(VS/TUN)

　　IP隧道(IP tunneling)是將一個IP報文封裝在另外一個IP報文的技術，這能夠使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。IP隧道技術亦稱爲IP封裝技術(IP encapsulation)。IP隧道主要用於移動主機和虛擬私有網絡(Virtual Private Network)，在其中隧道都是靜態創建的，隧道一端有一個IP地址，另外一端也有惟一的IP地址。它的鏈接調度和管理與VS/NAT中的同樣，只是它的報文轉發方法不一樣。調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，將請求報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的服務器;服務器收到報文後，先將報文解封得到原來目標地址爲 VIP 的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。

　　VS/TUN的體系結構

　　VS/TUN的工做流程：

　　◆Virtual Server via Direct Routing(VS/DR)

　　VS/DR方式是經過改寫請求報文中的MAC地址部分來實現的。Director和RealServer必需在物理上有一個網卡經過不間斷的局域網相連。 RealServer上綁定的VIP配置在各自Non-ARP的網絡設備上(如lo或tunl),Director的VIP地址對外可見，而RealServer的VIP對外是不可見的。RealServer的地址便可以是內部地址，也能夠是真實地址。

　　VS/DR的體系結構

　　VS/DR的工做流程

　　VS/DR的工做流程如圖所示：它的鏈接調度和管理與VS/NAT和VS/TUN中的同樣，它的報文轉發方法又有不一樣，將報文直接路由給目標服務器。在VS/DR中，調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改成選出服務器的MAC地址，再將修改後的數據幀在與服務器組的局域網上發送。由於數據幀的MAC地址是選出的服務器，因此服務器確定能夠收到這個數據幀，從中能夠得到該IP報文。當服務器發現報文的目標地址VIP是在本地的網絡設備上，服務器處理這個報文，而後根據路由表將響應報文直接返回給客戶。

　　VS/DR的工做流程

　　四、三種負載均衡方式比較：

　　◆Virtual Server via NAT

　　VS/NAT 的優勢是服務器能夠運行任何支持TCP/IP的操做系統，它只須要一個IP地址配置在調度器上，服務器組能夠用私有的IP地址。缺點是它的伸縮能力有限，當服務器結點數目升到20時，調度器自己有可能成爲系統的新瓶頸，由於在VS/NAT中請求和響應報文都須要經過負載調度器。咱們在Pentium166 處理器的主機上測得重寫報文的平均延時爲60us，性能更高的處理器上延時會短一些。假設TCP報文的平均長度爲536 Bytes，則調度器的最大吞吐量爲8.93 MBytes/s. 咱們再假設每臺服務器的吞吐量爲800KBytes/s，這樣一個調度器能夠帶動10臺服務器。(注：這是很早之前測得的數據)

　　基於 VS/NAT的的集羣系統能夠適合許多服務器的性能要求。若是負載調度器成爲系統新的瓶頸，能夠有三種方法解決這個問題：混合方法、VS/TUN和 VS/DR。在DNS混合集羣系統中，有若干個VS/NAT負調度器，每一個負載調度器帶本身的服務器集羣，同時這些負載調度器又經過RR-DNS組成簡單的域名。

　　但VS/TUN和VS/DR是提升系統吞吐量的更好方法。

　　對於那些將IP地址或者端口號在報文數據中傳送的網絡服務，須要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。這會帶來實現的工做量，同時應用模塊檢查報文的開銷會下降系統的吞吐率。

　　◆Virtual Server via IP Tunneling

　　在VS/TUN 的集羣系統中，負載調度器只將請求調度到不一樣的後端服務器，後端服務器將應答的數據直接返回給用戶。這樣，負載調度器就能夠處理大量的請求，它甚至能夠調度百臺以上的服務器(同等規模的服務器)，而它不會成爲系統的瓶頸。即便負載調度器只有100Mbps的全雙工網卡，整個系統的最大吞吐量可超過 1Gbps。因此，VS/TUN能夠極大地增長負載調度器調度的服務器數量。VS/TUN調度器能夠調度上百臺服務器，而它自己不會成爲系統的瓶頸，能夠用來構建高性能的超級服務器。VS/TUN技術對服務器有要求，即全部的服務器必須支持「IP Tunneling」或者「IP Encapsulation」協議。目前，VS/TUN的後端服務器主要運行Linux操做系統，咱們沒對其餘操做系統進行測試。由於「IP Tunneling」正成爲各個操做系統的標準協議，因此VS/TUN應該會適用運行其餘操做系統的後端服務器。

　　◆Virtual Server via Direct Routing

　　跟VS/TUN方法同樣，VS/DR調度器只處理客戶到服務器端的鏈接，響應數據能夠直接從獨立的網絡路由返回給客戶。這能夠極大地提升LVS集羣系統的伸縮性。跟VS/TUN相比，這種方法沒有IP隧道的開銷，可是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備(或者設備別名)不做ARP響應，或者能將報文重定向(Redirect)到本地的Socket端口上。

　　三種LVS負載均衡技術的優缺點概括如下表：

　　VS/NATVS/TUNVS/DR

　　服務器操做系統任意支持隧道多數(支持Non-arp)

　　服務器網絡私有網絡局域網/廣域網局域網

　　服務器數目(100M網絡)10~20100大於100

　　服務器網關負載均衡器本身的路由本身的路由

　　效率通常高最高

　　注：以上三種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡，調度器的硬件配置與後端服務器的硬件配置相同，並且是對通常Web服務。使 用更高的硬件配置(如千兆網卡和更快的處理器)做爲調度器，調度器所能調度的服務器數量會相應增長。當應用不一樣時，服務器的數目也會相應地改變。因此，以上數據估計主要是爲三種方法的伸縮性進行量化比較。

　　五、負載均衡調度算法

　　◆最少的鏈接方式(Least Connection)：傳遞新的鏈接給那些進行最少鏈接處理的服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配, 直到其恢復正常。

　　◆最快模式(Fastest)：傳遞鏈接給那些響應最快的服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

　　◆觀察模式(Observed)：鏈接數目和響應時間以這兩項的最佳平衡爲依據爲新的請求選擇服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

　　◆預測模式(Predictive)：BIG-IP利用收集到的服務器當前的性能指標，進行預測分析，選擇一臺服務器在下一個時間片內，其性能將達到最佳的服務器相應用戶的請求。(被BIG-IP 進行檢測)

　　◆動態性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應用程序和應用服務器的各項性能參數，動態調整流量分配。

　　◆動態服務器補充(Dynamic Server Act.):當主服務器羣中因故障致使數量減小時，動態地將備份服務器補充至主服務器羣。

　　◆服務質量(QoS):按不一樣的優先級對數據流進行分配。

　　◆服務類型(ToS): 按不一樣的服務類型(在Type of Field中標識)負載均衡對數據流進行分配。

　　◆規則模式：針對不一樣的數據流設置導向規則，用戶可自行