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

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。