【轉】lvs、nginx、haproxy轉發模式優缺點總結

原文地址：mysql

https://yq.aliyun.com/ziliao/78374nginx

1、LVS轉發模式web

LVS是章文嵩博士寫的一個工做於四層的高可能性軟件。不像後二者支持七層轉發，不過也正由於其簡單，因此其是最穩定的。其共有三種IP負載均衡技術：VS/NAT（Virtual Server via Network Address Translation）、VS/TUN（Virtual Server via IP Tunneling）和VS/DR（Direct Routing），三者之間具體的比較見下表算法

lvs
2、nginx負載模式sql

nginx有五種負載算法模式，分別是：輪詢、weight(權重)、ip_hash、fair、url_hash 。現逐一說明：apache

輪詢（默認）: 每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除。
weight :指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。配置爲：後端

        upstream bakend {
        server 192.168.0.14 weight=10;
        server 192.168.0.15 weight=10;
        }緩存

ip_hash:每一個請求按訪問ip的hash結果分配，這樣每一個訪客固定訪問一個後端服務器，能夠解決session的問題。配置爲：服務器

        upstream bakend {
        ip_hash;
        server 192.168.0.14:88;
        server 192.168.0.15:80;
        }cookie

fair：按後端服務器的響應時間來分配請求，響應時間短的優先分配。

        upstream backend {
        server server1;
        server server2;
        fair;
        }

url_hash：按訪問url的hash結果來分配請求，使每一個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。配置如：

        upstream backend {
        server squid1:3128;
        server squid2:3128;
        hash $request_uri;
        hash_method crc32;
        }

注：第五種模式下，須要注意在upstream中加入hash語句，server語句中不能寫入weight等其餘的參數，hash_method是使用的hash算法。

server後面常接的參數有以下幾個：

    down 表示單前的server暫時不參與負載
    weight 默認爲1.weight越大，負載的權重就越大。
    max_fails ：容許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤
    fail_timeout:max_fails次失敗後，暫停的時間。
    backup：其它全部的非backup機器down或者忙的時候，請求backup機器。因此這臺機器壓力會最輕。

3、haproxy

haproxy是三者之間負載算法最多的，有八種，因此其應用場景也是最多，配置也是最靈活的，具體8種算法爲：

①roundrobin，表示簡單的輪詢，這個是負載均衡基本都具有的；

②static-rr，表示根據權重，和nginx的weight算法相似；

③leastconn，表示最少鏈接者先處理，有點相似於nginx的fair,不過fair是根據響應時間；

④source，表示根據請求源IP，這個跟Nginx的IP_hash機制相似，咱們用其做爲解決session問題的一種方法，建議關注；

⑤ri，表示根據請求的URI，相似於nginx的url_hash；

⑥rl_param，表示根據請求的URl參數'balance url_param' requires an URL parameter name；

⑦hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；

⑧rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。

優缺點

三種負載均衡器的優缺點說明以下：

LVS的優勢：
一、抗負載能力強、工做在第4層僅做分發之用，沒有流量的產生，這個特色也決定了它在負載均衡軟件裏的性能最強的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；
二、工做穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；
三、應用範圍比較廣，能夠對全部應用作負載均衡；
四、配置性比較低，這是一個缺點也是一個優勢，由於沒有可太多配置的東西，因此並不須要太多接觸，大大減小了人爲出錯的概率；
LVS的缺點：
一、軟件自己不支持正則處理，不能作動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優點。
二、若是網站應用比較龐大，LVS/DR+Keepalived就比較複雜了，特別是後面有Windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單多了。
#############################################################

1. LVS/DR如何處理請求報文的，會修改IP包內容嗎？

1.1 vs/dr自己不會關心IP層以上的信息，即便是端口號也是tcp/ip協議棧去判斷是否正確，vs/dr自己主要作這麼幾個事：

1）接收client的請求，根據你設定的負載均衡算法選取一臺realserver的ip；

2）以選取的這個ip對應的mac地址做爲目標mac，而後從新將IP包封裝成幀轉發給這臺RS；

3）在hash table中記錄鏈接信息。

vs/dr作的事情不多，也很簡單，因此它的效率很高，不比硬件負載均衡設備差多少。

數據包、數據幀的大體流向是這樣的：client --> VS --> RS --> client

1.2 前面已做了回答，vs/dr不會修改IP包的內容.

2. RealServer爲何要在lo接口上配置VIP？在出口網卡上配置VIP能夠嗎？

2.1 既然要讓RS可以處理目標地址爲vip的IP包，首先必需要讓RS能接收到這個包。

在lo上配置vip可以完成接收包並將結果返回client。

2.2 答案是不能夠將VIP設置在出口網卡上,不然會響應客戶端的arp request,形成client/gateway arp table紊亂，以致於整個load balance都不能正常工做。

3. RealServer爲何要抑制arp幀？

這個問題在上一問題中已經做了說明，這裏結合實施命令進一步闡述。咱們在具體實施部署的時候都會做以下調整：

       echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
       echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
       echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
       echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce我相信不少人都不會弄懂它們的做用是什麼，只知道必定得有。我這裏也不打算拿出來詳細討論，只是做幾點說明，就當是補充吧。

3.1

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce這兩條是能夠不用的，由於arp對邏輯接口沒有意義。

3.2 若是你的RS的外部網絡接口是eth0，那麼

echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce其實真正要執行的是：

echo "1" >/proc/sys/net/ipv4/conf/eth0/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/eth0/arp_announce因此我我的建議把上面兩條也加到你的腳本里去，由於萬一系統裏上面兩條默認的值不是0，那有多是會出問題滴。

4. LVS/DR load balancer（director）與RS爲何要在同一網段中？

從第一個問題中你們應該明白vs/dr是如何將請求轉發給RS的了吧？它是在數據鏈路層來實現的，因此director必須和RS在同一網段裏面。

5. 爲何director上lo接口除了VIP另外還要在eth0配一個ip（即DIP）？

5.1 若是是用了keepalived等工具作HA或者Load Balance,則在健康檢查時須要用到DIP。

5.2 沒有健康檢查機制的HA或者Load Balance則沒有存在的實際意義。

6. LVS/DR ip_forward須要開啓嗎？

不須要。由於director跟realserver是同一個網段，無需開啓轉發。

7. director的vip的netmask必定要是255.255.255.255嗎？

lvs/dr裏，director的vip的netmask 不必設置爲255.255.255.255，也不須要再去

route add -host $VIP dev eth0:0director的vip原本就是要像正常的ip地址同樣對外通告的,不要搞得這麼特殊.

8. LVS/DR如何進行tcp的三次握手？

#####################################################################

Nginx的優勢：
一、工做在OSI第7層，能夠針對http應用作一些分流的策略。好比針對域名、目錄結構。它的正則比HAProxy更爲強大和靈活；
二、Nginx對網絡的依賴很是小，理論上能ping通就就能進行負載功能，這個也是它的優點所在；
三、Nginx安裝和配置比較簡單，測試起來比較方便；
四、能夠承擔高的負載壓力且穩定，通常能支撐超過幾萬次的併發量；
五、Nginx能夠經過端口檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點；
六、Nginx不只僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。LNMP如今也是很是流行的web環境，大有和LAMP環境平起平坐之勢，Nginx在處理靜態頁面、特別是抗高併發方面相對apache有優點；
七、Nginx如今做爲Web反向加速緩存愈來愈成熟了，速度比傳統的Squid服務器更快，有需求的朋友能夠考慮用其做爲反向代理加速器；
Nginx的缺點：
一、Nginx不支持url來檢測。
二、Nginx僅能支持http和Email，這個它的弱勢。
三、Nginx的Session的保持，Cookie的引導能力相對欠缺。

HAProxy的優勢：
一、HAProxy是支持虛擬主機的，能夠工做在四、7層(支持多網段)；
二、可以補充Nginx的一些缺點好比Session的保持，Cookie的引導等工做；
三、支持url檢測後端的服務器；
四、它跟LVS同樣，自己僅僅就只是一款負載均衡軟件；單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的；
五、HAProxy能夠對Mysql讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，不過在後端的MySQL slaves數量超過10臺時性能不如LVS；
六、HAProxy的算法較多，達到8種；

4、總結

具體現網應用能夠根據據體的實際狀況選擇最好的負載方式。三者中，lvs穩定性最好，可配置性最少；nginx針對域名、目錄結構進行正則匹配是最強的，同時其對網絡依賴比較小，不過性能上和lvs和haproxy相比稍差一點點；haproxy支持虛擬主機，尤爲在session保持方面作的最好，其有三種算法能夠實現session共享———— ip識別（source）、cookie識別、session識別三種，除此以外在對mysql作HA方案時也常常會用到該軟件。

以上是雲棲社區小編爲您精心準備的的內容，在雲棲社區的博客、問答、公衆號、人物、課程等欄目也有的相關內容，歡迎繼續使用右上角搜索按鈕進行搜索算法，服務器，應用， nginx ，負載均衡配置 haproxy nginx lvs、haproxy lvs、lvs和haproxy的區別、haproxy lvs比較、haproxy和lvs，以便於您獲取更多的相關知識。