LVS-模式

LVS主要是DR,TUN,NAT和淘寶的FULLNAT模式，對於絕大部分人而言只能選擇原版內核支持的前三種。

1.DR模式

DR模式是效率最高的一種，對於每個請求LVS把目的mac改爲從RS中選擇的機器的mac，再將修改後的數據幀在與服務器組的局域網上發送。可是侷限性是LVS機器須要和RS至少能有一個網卡同在一個VLAN下面，這樣限制了DR模式只能在比較單一的網絡拓撲下使用。

2.TUN模式

TUN模式其實性能與DR模式相比差異不大的，TUN模式下會動態地從RS列表選擇一臺服務器，將請求報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；RS服務器收到報文後，先將報文解封得到原來目標地址爲VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。TUN模式能夠解決DR模式下不能垮網段的問題，甚至能夠垮公網進行。可是須要RS能支持ipip模塊。

3.NAT模式

NAT模式對RS沒有其餘要求，惟一的要求是得把RS的網關設置爲LVS機器。由於進出的流量都要經過LVS機器，因此性能相對會差不少，並且部署的規模很難作大。

以上DR模式和TUN模式在部署的時候都須要在本機綁定VIP，很是麻煩，好比咱們以前有的老應用由於一些歷史問題單個應用的VIP有40來個，若是用LVS作負載均衡基本就崩潰了，每次新增/刪除一個VIP，估計得線下測試好屢次ip addr add/del的用法。NAT模式在部署的時候也是太麻煩了。並且還有一個很關鍵很關鍵的是，使用了LVS後萬一被人ddos怎麼辦？syn-cookie在抵擋***的時候效果通常不是太好，這樣***透過lvs直擊後端應用就杯具了。因此在不少大公司都不敢直接把lvs放公網，前面得加個防火牆啥的。因此淘寶單獨搞了一個fullnat模式，一方面能夠解決部署綁VIP、或者把RS的網關設置爲LVS機器IP帶來的部署複雜問題，另一方面是加了一個syn-proxy等等，能夠抵擋下通常的網絡層***。可是使用FULLNAT模式後確實有個麻煩的是後端機器看不到用戶的IP了，因此RS上還得用裝上打過補丁的內核，對取IP的操做就劫持才能獲取到用戶IP。

對於大規模網站，其實不管單獨使用哪一種LVS都是不能替換商業設備的，因此仍是得配合nginx or haproxy作負載均衡。這個時候最簡單的就是lvs(fullnat)+nginx/haproxy（nginx官方版本如今沒有4層代理功能，haproxy對後端又不支持keepalive）,固然使用DR模式或者TUN模式也還能夠的。總之基本都得用2層才能搞得定，知足大部分應用上的需求。其實對於不少小公司，我以爲直接用nginx/haproxy就OK了。搞的那麼複雜維護成本會很是高的，自動化運維沒有跟上的時候只會把本身給玩死。