詳細介紹負載均衡,讓它更透徹

        在理解學習負載均衡時,須要瞭解下網絡協議的模型,須要知道每一層都支持哪些協議,又是如何進行負載均衡,是使用軟件,仍是使用硬件,熟悉瞭解後才能更好的掌握負載均衡的實質.

 

網絡協議

請移步至OSI七層網絡模型進行詳細瞭解.

小知識:

多層負載解釋說明:            

二層負載均衡會經過一個虛擬MAC地址接收請求，而後再分配到真實的MAC地址；            

三層負載均衡會經過一個虛擬IP地址接收請求，而後再分配到真實的IP地址；            

四層負載均衡會經過虛擬IP+端口接收請求，而後再分配到真實的服務器；            

七層負載均衡會經過虛擬的URL或主機名接收請求，而後再分配到真實的服務器。

1、什麼是負載均衡

負載均衡（Load Balance）

        其意思就是分攤到多個操做單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工做任務。單從字面上的意思來理解就能夠解釋N臺服務器平均分擔負載，不會由於某臺服務器負載高宕機而某臺服務器閒置的狀況。那麼負載均衡的前提就是要有多臺服務器才能實現，也就是兩臺以上便可。

2、負載均衡的優勢

        減小服務器的壓力，將本來一臺服務器索要承受的訪問量分給多臺，並提升項目的可用性，當一臺服務器掛掉的時候不會致使項目癱瘓。

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

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

        四層負載均衡工做在OSI模型的傳輸層，主要工做是轉發，它在接收到客戶端的流量之後,經過修改數據包的地址信息將流量轉發到應用服務器。

能夠這樣理解經過發佈三層的IP地址（VIP），而後加四層的端口號，來決定哪些流量須要作負載均衡，對須要處理的流量進行NAT處理，轉發至後臺服務器，並記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，後續這個鏈接的全部流量都一樣轉發到同一臺服務器處理。

四層負載和七層負載

        七層負載均衡工做在OSI模型的應用層，由於它須要解析應用層流量，因此七層負載均衡在接到客戶端的流量之後，還須要一個完整的TCP/IP協議棧。七層負載均衡會與客戶端創建一條完整的鏈接,並將應用層的請求流量解析出來，再按照調度算法選擇一個應用服務器，並與應用服務器創建另一條鏈接將請求發送過去，所以七層負載均衡的主要工做就是代理。七層負載均衡 也稱爲「內容交換」，也就是主要經過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

能夠這樣理解爲在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，好比同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否須要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，若是你的Web服務器分紅兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就能夠當用戶來訪問你的域名時，自動辨別用戶語言，而後選擇對應的語言服務器組進行負載均衡處理。

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

1.是否真的必要。

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

2.是否真的能夠提升安全性。

        例如SYN Flood攻擊，七層模式的確將這些流量從服務器屏蔽，但負載均衡設備自己要有強大的抗DDoS(一種網絡黑客方式,詳細瞭解請搜索"DDOS")能力，不然即便服務器正常而做爲中樞調度的負載均衡設備故障也會致使整個應用的崩潰。

3.是否有足夠的靈活度。

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

        七層負載均衡的優勢：

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

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

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

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

4、負載均衡軟/硬件

 

負載均衡架構圖

　軟/硬件負載均衡

　　軟件負載均衡解決方案是指在一臺或多臺服務器相應的操做系統上安裝一個或多個附加軟件來實現負載均衡，負載均衡軟件有Nginx(web服務器軟件)、LVS(Linux Virtual Server linux虛擬服務器軟件)、HaProxy(代理軟件)等是目前使用最普遍的三種負載均衡軟件。它的優勢是基於特定環境，配置簡單，使用靈活，成本低廉，能夠知足通常的負載均衡需求。

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

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

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

負載均衡器一般稱爲四層交換機或七層交換機。四層交換機主要分析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等系統。 

4、負載均衡算法

通常來講負載均衡設備都會默認支持多種負載均衡分發策略

輪詢（RoundRobin）將請求順序循環地發到每一個服務器。當其中某個服務器發生故障，AX就把其從順序循環隊列中拿出，不參加下一次的輪詢，直到其恢復正常。

比率（Ratio）：給每一個服務器分配一個加權值爲比例，根椐這個比例，把用戶的請求分配到每一個服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

優先權（Priority）：給全部服務器分組，給每一個組定義優先權，將用戶的請求分配給優先級最高的服務器組（在同一組內，採用預先設定的輪詢或比率算法，分配用戶的請求）；當最高優先級中全部服務器或者指定數量的服務器出現故障，AX將把請求送給次優先級的服務器組。這種方式，實際爲用戶提供一種熱備份的方式。

最少鏈接數（LeastConnection）：AX會記錄當前每臺服務器或者服務端口上的鏈接數，新的鏈接將傳遞給鏈接數最少的服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

最快響應時間（Fast Reponse time）：新的鏈接傳遞給那些響應最快的服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

哈希算法( hash): 將客戶端的源地址，端口進行哈希運算，根據運算的結果轉發給一臺服務器進行處理，當其中某個服務器發生故障，就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

基於數據包的內容分發：例如判斷HTTP的URL，若是URL中帶有.jpg的擴展名，就把數據包轉發到指定的服務器。

 

5、健康檢查

健康檢查用於檢查服務器開放的各類服務的可用狀態。

負載均衡設備通常會配置各類健康檢查方法，例如Ping，TCP，UDP，HTTP，FTP，DNS等。

        Ping屬於第三層的健康檢查，用於檢查服務器IP的連通性，TCP/UDP屬於第四層的健康檢查，用於檢查服務端口的UP/DOWN，若是要檢查的更準確，就要用到基於7層的健康檢查，例如建立一個HTTP健康檢查，Get一個頁面回來，而且檢查頁面內容是否包含一個指定的字符串，若是包含，則服務是UP的，若是不包含或者取不回頁面，就認爲該服務器的Web服務是不可用（DOWN）的。好比，負載均衡設備檢查到172.16.20.3這臺服務器的80端口是DOWN的，負載均衡設備將不把後面的鏈接轉發到這臺服務器，而是根據算法將數據包轉發到別的服務器。建立健康檢查時能夠設定檢查的間隔時間和嘗試次數，例如設定間隔時間爲5秒，嘗試次數爲3，那麼負載均衡設備每隔5秒發起一次健康檢查，若是檢查失敗，則嘗試3次，若是3次都檢查失敗，則把該服務標記爲DOWN，而後服務器仍然會每隔5秒對DOWN的服務器進行檢查，當某個時刻發現該服務器健康檢查又成功了，則把該服務器從新標記爲UP。健康檢查的間隔時間和嘗試次數要根據綜合狀況來設置，原則是既不會對業務產生影響，又不會對負載均衡設備形成較大負擔。

 

6、會話保持

如何保證一個用戶的兩次http請求轉發到同一個服務器，這就要求負載均衡設備配置會話保持。

會話保持用於保持會話的連續性和一致性，因爲服務器之間很難作到實時同步用戶訪問信息，這就要求把用戶的先後訪問會話保持到一臺服務器上來處理。

    舉個例子，用戶訪問一個電子商務網站，若是用戶登陸時是由第一臺服務器來處理的，但用戶購買商品的動做卻由第二臺服務器來處理，第二臺服務器因爲不知道用戶信息，因此本次購買就不會成功。這種狀況就須要會話保持，把用戶的操做都經過第一臺服務器來處理才能成功。固然並非全部的訪問都須要會話保持，例如服務器提供的是靜態頁面好比網站的新聞頻道，各臺服務器都有相同的內容，這種訪問就不須要會話保持。

絕大多數的負載均衡產品都支持兩類基本的會話保持方式：源/目的地址會話保持和cookie會話保持，另外像hash，URL Persist等也是比較經常使用的方式，但不是全部設備都支持。基於不一樣的應用要配置不一樣的會話保持，不然會引發負載的不均衡甚至訪問異常。咱們主要分析B/S結構的會話保持。

 

7、基於B/S結構的應用：

        對於普通B/S結構的應用內容，例如網站的靜態頁面，能夠不用配置任何的會話保持，可是對於一個基於B/S結構尤爲是中間件平臺的業務系統來講，必須配置會話保持，通常狀況下，咱們配置源地址會話保持能夠知足需求，可是考慮到客戶端可能有上述不利於源地址會話保持的環境，採用Cookie會話保持是一個更好的方式。Cookie會話保持會把負載均衡設備選擇的Server信息保存在Cookie中發送到客戶端，客戶端持續訪問時，會把該Cookie帶來，負載均衡器經過分析Cookie把會話保持到以前選定的服務器。Cookie分爲文件Cookie和內存cookie，文件cookie保存在客戶端計算機硬盤上，只要該cookie文件不過時，則不管是否重複關閉開放瀏覽器都能保持到同一臺服務器。內存Cookie則是把Cookie信息保存在內存中，Cookie的生存時間從打開瀏覽器訪問開始，關閉瀏覽器結束。因爲如今的瀏覽器對Cookie都有必定默認的安全設置，有些客戶端可能規定不許使用文件Cookie，因此如今的應用程序開發多使用內存Cookie。

        然而，內存Cookie也不是萬能的，好比瀏覽器爲了安全可能會徹底禁用Cookie，這樣Cookie會話保持就失去了做用。咱們能夠經過Session-id來實現會話保持，即將session-id做爲url參數或者放在隱藏字段<input type="hidden">中，而後分析Session-id進行分發。

        另外一種方案是：將每一會話信息保存到一個數據庫中。因爲這個方案會增長數據庫的負載，因此這個方案對性能的提升並很差。數據庫最好是用來存儲會話時間比較長的會話數據。爲了不數據庫出現單點故障，而且提升其擴展性，數據庫一般會複製到多臺服務器上，經過負載均衡器來分發請求到數據庫服務器上。

        基於源/目的地址會話保持其實不太好用，由於客戶多是經過DHCP，NAT或者Web代理來鏈接Internet的，其IP地址可能常常變換，這使得這個方案的服務質量沒法保障。

        NAT(Network Address Translation，網絡地址轉換):當在專用網內部的一些主機原本已經分配到了本地IP地址(即僅在本專用網內使用的專用地址)，但如今又想和因特網上的主機通訊(並不須要加密)時，可以使用NAT方法。這種方法須要在專用網鏈接到因特網的路由器上安裝NAT軟件。裝有NAT軟件的路由器叫作NAT路由器，它至少有一個有效的外部全球IP地址。這樣，全部使用本地地址的主機在和外界通訊時，都要在NAT路由器上將其本地地址轉換成全球IP地址，才能和因特網鏈接。

8、負載均衡項目需求分析

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

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

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

　　性能：性能是咱們在引入均衡方案時須要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可將每秒鐘經過網絡的數據包數目作爲一個參數，另外一個參數是均衡方案中服務器羣所能處理的最大併發鏈接數目，可是，假設一個均衡系統能處理百萬計的併發鏈接數，但是卻只能以每秒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標準的設備進行管理

注:文章若有疑問或錯誤之處,請留言評論指出,必將學習之.