LVS－原理

一. 集羣的概念

服務器集羣簡稱集羣是一種服務器系統，它經過一組鬆散集成的服務器軟件和/或硬件鏈接起來高度緊密地協做完成計算工做。在某種意義上，他們能夠被看做是一臺服務器。
集羣系統中的單個服務器一般稱爲節點，一般經過局域網鏈接，但也有其它的可能鏈接方式。集羣服務器一般用來改進單個服務器的計算速度和/或可靠性。通常狀況下集羣
服務器比單個服務器，好比工做站或超級服務器性能價格比要高得多。集羣就是一組獨立的服務器，經過網絡鏈接組合成一個組合來共同完一個任務。

說的直白點，集羣就是一組相互獨立的服務器，經過高速的網絡組成一個服務器系統，每一個集羣節點都是運行其本身進程的一個獨立服務器。對網絡用戶來說，網站後
端就是一個單一的系統，協同起來向用戶提供系統資源，系統服務。

二. 爲何要使用集羣

1) 集羣的特色
-  高性能performance
一些須要很強的運算處理能力好比天氣預報，核試驗等。這就不是幾臺服務器可以搞定的。這須要上千臺一塊兒來完成這個工做的。

-  價格有效性
一般一套系統集羣架構，只須要幾臺或數十臺服務器主機便可，與動則上百萬的專用超級服務器具備更高的性價比。

-  可伸縮性
當服務器負載壓力增加的時候，系統可以擴展來知足需求，且不下降服務質量。

-  高可用性
儘管部分硬件和軟件發生故障，整個系統的服務必須是7*24小時運行的。

2) 集羣的優點
-  透明性
若是一部分服務器宕機了業務不受影響，通常耦合度沒有那麼高，依賴關係沒有那麼高。好比NFS服務器宕機了其餘就掛載不了了，這樣依賴性太強。

-  高性能
訪問量增長，可以輕鬆擴展。

-  可管理性
整個系統可能在物理上很大，但很容易管理。

-  可編程性
在集羣系統上，容易開發應用程序，門戶網站會要求這個。

3) 集羣分類及不一樣分類的特色
計算機集羣架構按照功能和結構通常分紅如下幾類：
-  負載均衡集羣（Loadbalancingclusters）簡稱LBC
-  高可用性集羣（High-availabilityclusters）簡稱HAC
-  高性能計算集羣（High-perfomanceclusters）簡稱HPC
-  網格計算（Gridcomputing）

就集羣分類而言, 網絡上面通常認爲是有三個，負載均衡和高可用集羣式咱們互聯網行業經常使用的集羣架構。

1) 負載均衡集羣
負載均衡集羣爲企業提供了更爲實用，性價比更高的系統架構解決方案。負載均衡集羣把不少客戶集中訪問的請求負載壓力可能儘量平均的分攤到計算機集羣中處理。
客戶請求負載一般包括應用程度處理負載和網絡流量負載。這樣的系統很是適合向使用同一組應用程序爲大量用戶提供服務。每一個節點均可以承擔必定的訪問請求負載壓力，
而且能夠實現訪問請求在各節點之間動態分配，以實現負載均衡。

負載均衡運行時，通常經過一個或多個前端負載均衡器將客戶訪問請求分發到後端一組服務器上，從而達到整個系統的高性能和高可用性。這樣集羣有時也被稱爲服務器羣。
通常高可用性集羣和負載均衡集羣會使用相似的技術，或同時具備高可用性與負載均衡的特色。

負載均衡集羣的做用：
a）分擔訪問流量（負載均衡）
b）保持業務的連續性（高可用）

2) 高可用性集羣
通常是指當集羣中的任意一個節點失效的狀況下，節點上的全部任務自動轉移到其餘正常的節點上，而且此過程不影響整個集羣的運行，不影響業務的提供。相似是集羣中運行着兩個或兩個以上的同樣的節點，當某個主節點出現故障的時候，那麼其餘做爲從 節點的節點就會接替主節點上面的任務。從節點能夠接管主節點的資源（IP地址，架構身份等），此時用戶不會發現提供服務的對象從主節點轉移到從節點。
高可用性集羣的做用：當一臺機器宕機另外一臺進行接管。比較經常使用的高可用集羣開源軟件有：keepalive，heardbeat。

3) 高性能計算集羣
高性能計算集羣採用將計算任務分配到集羣的不一樣計算節點兒提升計算能力，於是主要應用在科學計算領域。比較流行的HPC採用Linux操做系統和其它一些免費軟件來完成並行運算。這一集羣配置一般被稱爲Beowulf集羣。這類集羣一般運行特定的程序以發揮HPCcluster的並行能力。這類程序通常應用特定的運行庫, 好比專爲科學計算設計的MPI庫。HPC集羣特別適合於在計算中各計算節點之間發生大量數據通信的計算做業，好比一個節點的中間結果或影響到其它節點計算結果的狀況。

三. 負載均衡集羣介紹

負載均衡集羣是 Load Balance 集羣, 是一種將網絡上的訪問流量分佈於各個節點，以下降服務器壓力，更好的向客戶端提供服務的一種方式。
負載均衡集羣的做用：提供一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載帶寬、增長吞吐量，增強網絡數據處理能力、提升網絡的靈活性和可用性。簡單來講,也就是:
1) 把單臺計算機沒法承受的大規模的併發訪問或數據流量分擔到多臺節點設備上分別處理，減小用戶等待響應的時間，提高用戶體驗。
2) 單個重負載的運算分擔到多臺節點設備上作並行處理，每一個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力獲得大幅度提升。
3) 7*24小時的服務保證，任意一個或多個設備節點設備宕機，不能影響到業務。在負載均衡集羣中，全部計算機節點都應該提供相同的服務，集羣負載均衡獲取全部對該服務的如站請求。

經常使用的負載均衡分爲:
1) 開源軟件負載均衡:  Nginx, LVS, Haproxy  (Nginx和Haproxy一般作七層負載均衡, LVS作四層負載均衡. 可是Nginx也能夠經過stream模塊作四層負載均衡, Haproxy也能夠作四層負載均衡 ) ;
2) 商業的硬件負載均衡: 設備F五、Netscale ;

簡單理解一下軟件負載均衡:
1) 所謂分層的負載均衡，都是以網絡的模型來講的。四層就是基於IP和端口的負載均衡，七層就是基於URL等應用信息的負載均衡。因此簡單的說四層負載均衡就是經過IP和端口接收請求再分發至真實的服務器，七層是經過URL或主機名接收請求，而後分發至真實的服務器。
2) .而七層的實現也是在四層的基礎上是實現的，沒有四層就不可能有七層。在第七層上能夠作許多事情，好比能夠根據七層的瀏覽器類別區分是手機仍是PC，將WEB服務器分爲2組，手機登錄專門的移動端網站。
3) 對客戶端來講，客戶端好像是訪問的同一臺主機。其實爲了有更好的用戶體驗，從智能DNS入手，根據客戶端IP來源將域名解析到距離客戶端最近的一臺服務器或者訪問最快速的一臺服務器，但這些內容客戶端都是感受不到的，客戶端感受到的只能是訪問網站很快。

linux virtual server簡稱LVS，Internet的快速增加使多媒體網絡服務器面對的訪問數量快速增長，服務器須要具有提供大量併發訪問服務的能力，所以對於大負載的服務器來說， CPU、I/O處理能力很快會成爲瓶頸。因爲單臺服務器的性能老是有限的，簡單的提升硬件性能並不能真正解決這個問題。爲此，必須採用多服務器和負載均衡技術才能知足大量併發訪問的須要。Linux 虛擬服務器(Linux Virtual Servers,LVS) 使用負載均衡技術將多臺服務器組成一個虛擬服務器。它爲適應快速增加的網絡訪問需求提供了一個負載能力易於擴展，而價格低廉的解決方案。lvs的負載能力特別強，優化空間特別大，lvs的變種DPVS聽說是lvs性能的幾倍，由愛奇藝開發，並普遍用於愛奇藝IDC。其餘負載均衡服務器還有nginx，haproxy，F5，Netscale。

 

 

 

LVS負載均衡分爲三層架構(也就是LVS負載均衡主要組成部分)：

第一層：負載調度器（load balancer/ Director），它是整個集羣的總代理，它在有兩個網卡，一個網卡面對訪問網站的客戶端，一個面對整個集羣的內部。負責將客戶端的請求發送到一組服務器上執行，而客戶也認爲服務是來自這臺主的。舉個生動的例子，集羣是個公司，負載調度器就是在外接攬生意，將接攬到的生意分發給後臺的真正幹活的真正的主機們。固然須要將活按照必定的算法分發下去，讓你們都公平的幹活。
第二層：服務器池（server pool/ Realserver），是一組真正執行客戶請求的服務器，能夠當作WEB服務器。就是上面例子中的小員工。  
第三層：共享存儲（shared storage），它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。一個公司得有一個後臺帳目吧，這才能協調。否則客戶把錢付給了A，而換B接待客戶，由於沒有相同的帳目。B說客戶沒付錢，那這樣就不是客戶體驗度的問題了。

 IP負載均衡與負載調度算法
IP負載均衡技術
負載均衡技術有不少實現方案，有基於DNS域名輪流解析的方法、有基於客戶端調度訪問的方法、有基於應用層系統負載的調度方法，還有基於IP地址的調度方法，在這些負載調度算法中，執行效率最高的是IP負載均衡技術。

LVS的IP負載均衡技術是經過IPVS模塊來實現的，IPVS是LVS集羣系統的核心軟件，它的主要做用是：安裝在Director Server上，同時在Director Server上虛擬出一個IP地址，用戶必須經過這個虛擬的IP地址訪問服務。這個虛擬IP通常稱爲LVS的VIP，即Virtual IP。訪問的請求首先通過VIP到達負載調度器，而後由負載調度器從Real Server列表中選取一個服務節點響應用戶的請求。當用戶的請求到達負載調度器後，調度器如何將請求發送到提供服務的Real Server節點，而Real Server節點如何返回數據給用戶，是IPVS實現的重點技術，IPVS實現負載均衡機制有三種，分別是NAT、TUN和DR(下面會詳細介紹);

負載調度算法
負載調度器是根據各個服務器的負載狀況，動態地選擇一臺Real Server響應用戶請求，根據不一樣的網絡服務需求和服務器配置，IPVS實現了以下八種負載調度算法：rr、wrr、Wlc、Dh、SH、Lc、Lblc

LVS負載均衡調度算法

VS的調度算法決定了如何在集羣節點之間分佈工做負荷。當director調度器收到來自客戶端訪問VIP的上的集羣服務的入站請求時，director調度器必須決定哪一個集羣節點應該
處理請求。

Director調度器用的調度方法基本分爲兩類 (以下所列, LVS總共有10種調度算法, 經常使用的也就四種調度算法, 下面會說到):
靜態調度算法：rr，wrr，dh，sh
動態調度算法：wlc，lc，lblc，lblcr, sed, nq

靜態調度 (也就是固定調度算法)的4種算法:
rr（輪詢）
輪詢調度：這種是最簡單的調度算法，就是將請求A一個，B一個，A一個，B一個 ...... 循環的發。就算A主機掛掉了，調度器仍是會將請求發送到A。十分均衡。

wrr（權重, 即加權輪詢）
加權輪詢調度：這種算法是在rr基礎上實現的，只不過加了權重，權重範圍爲1-100，假設A的服務器性能好，就給A的權重設置的高一點，設爲2，而B主機是1。這樣就實現A二個，B一個，A二個，B一個 ...... 循環的發。這樣照顧到了服務器性能。

sh（源地址哈希）
源地址散列：主要是實現將此前的session（會話）綁定。將此前客戶的源地址做爲散列鍵，從靜態的散列表中找出對應的服務器，只要目標服務器是沒有超負荷的就將請求發送過去。
就是說某客戶訪問過A,如今這個客戶又來了，因此客戶請求會被髮送到服務過他的A主機。

dh（目的地址哈希）
目的地址散列：以目的地址爲關鍵字查找一個靜態hash表來得到須要的RS。以目標地址爲標準挑選。 功能是和sh近似的，但應用場景不一樣; 舉個dh調度算法的例子：
假設1號客戶訪問了web集羣的一個動態頁面，調度器將請求轉發個A服務器，A服務器的PHP將這個動態請求運行了一遍，生成了緩存並回應1號客戶。這下2號客戶也訪問了這個動態頁面，
調度器應該將請求發給A。畢竟A已經跑過這段程序了，有緩存，對吧。因此這既是dh算法）




動態調度算法，動態算法與靜態算法最大的區別就是動態算法考慮了服務器的壓力。
活動連接（active）：客戶與服務器創建鏈接而且有數據傳送
非活動連接（inactive）：只是創建鏈接，沒有數據傳送，沒有斷開鏈接

動態調度的6種算法
lc（最少連接）
最少鏈接調度：這種算法是看A，和B的主機誰的鏈接少，請求就發給誰。
簡單算法：active*256+inactive  （誰小發給誰）

wlc（加權最少連接）LVS的理想算法
加權最少連接：這種算法就是比lc多了一個加權。
簡單算法：( active*256+inactive )/weight    (誰小就發給誰)

sed（最短時間望延遲）
基於wlc算法，假設A，B的權重分別是1，2 。而A的連接數爲1，B的連接數爲2 。這樣的話，用wlc算法得出的結果同樣，而明顯B的權重大，B的能力較強。用sed算法的話，就能夠避免wlc出現的問題。
簡單算法：（active+1)*256/weight （活動的鏈接數+1）*256/除以權重  誰小發給誰
A：（1+1）/1
B：（2+1）/2  （B小，交給B）

nq（不用排隊）
基於sed算法：在sed的基礎上，若誰的連接數爲0，直接將請求發送給它! LBLC（基於局部性的最少鏈接）相似於dh，目標地址hash
這個算法主要用於Cache集羣系統，由於Cache集羣的中客戶請求報文的目標IP地址的變化，將相同的目標URL地址請求調度到同一臺服務器，來提升服務器的訪問的局部性和Cache命中率。從而調整整個集羣的系統處理能力。
可是，若是realserver的負載處於一半負載，就用最少連接算法，將請求發送給活動連接少的主機。

LBLCR（帶複製的基於局部性的最少連接）
該算法首先是基於最少連接的，當一個新請求收到後，必定會將請求發給最少鏈接的那臺主機的。但這樣又破壞了cache命中率。但這個算法中，集羣服務是cache共享的，假設A的PHP跑了一遍，獲得緩存。
但其餘realserver能夠去A那裏拿緩存，這是種緩存複製機制。

負載調度器是根據各個服務器的負載狀況，動態地選擇一臺Real Server響應用戶請求，那麼動態選擇是如何實現呢，其實也就是這裏要說的負載調度算法，根據不一樣的網絡服務需求和服務器配置，
IPVS實現瞭如上的十種負載調度算法，下面詳細講述LVS最經常使用的四種調度算法：

- 輪叫調度（Round Robin） "輪叫"調度也叫1:1調度，調度器經過"輪叫"調度算法將外部用戶請求按順序1:1的分配到集羣中的每一個Real Server上，這種算法平等地對待每一臺Real Server，而無論服務器
上實際的負載情況和鏈接狀態。

- 加權輪叫調度（Weighted Round Robin） "加權輪叫"調度算法是根據Real Server的不一樣處理能力來調度訪問請求。能夠對每臺Real Server設置不一樣的調度權值，對於性能相對較好的Real Server能夠設置較高的權值，而對於處理能力較弱的Real Server，能夠設置較低的權值，這樣保證了處理能力強的服務器處理更多的訪問流量。充分合理的利用了服務器資源。同時，調度器還能夠自動查詢Real Server的負載狀況，並動態地調整其權值。

- 最少連接調度（Least Connections） "最少鏈接"調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上。若是集羣系統的真實服務器具備相近的系統性能，採用"最小鏈接"調度算法能夠較好地均衡負載。

- 加權最少連接調度（Weighted Least Connections） "加權最少連接調度"是"最少鏈接調度"的超集，每一個服務節點能夠用相應的權值表示其處理能力，而系統管理員能夠動態的設置相應的權值，缺省權值爲1，加權最小鏈接調度在分配新鏈接請求時儘量使服務節點的已創建鏈接數和其權值成正比。



LVS調度算法的生產環境選型：
1）通常的網絡服務，如http，nginx，mysql等經常使用的LVS調度算法爲：
a. 基本輪詢調度rr
b. 加權最小鏈接調度wlc
c. 加權輪詢調度wrc

2）基於局部性的最小鏈接lblc和帶複製的給予局部性最小鏈接lblcr主要適用於web cache和DB cache;

3）源地址散列調度SH和目標地址散列調度DH能夠結合使用在防火牆集羣中，能夠保證整個系統的出入口惟一;

其實對於LVS的理解，主要部分仍是在於3種工做方式和8種調度算法，實際這些算法的適用範圍不少，工做中最好參考內核中的鏈接調度算法的實現原理，而後根據具體的業務需求合理的選型。 

 

 

 

 

 

 

 

當用戶向負載均衡調度器（Director Server）發起請求，調度器將請求發往至內核空間。
PREROUTING鏈首先會接收到用戶請求，判斷目標IP肯定是本機IP，將數據包發往INPUT鏈。
IPVS是工做在INPUT鏈上的，當用戶請求到達INPUT時，IPVS會將用戶請求和本身已定義好的集羣服務進行比對，若是用戶請求的就是定義的集羣服務，
那麼此時IPVS會強行修改數據包裏的目標IP地址及端口，並將新的數據包發往POSTROUTING鏈。
POSTROUTING連接收數據包後發現目標IP地址恰好是本身的後端服務器，那麼此時經過選路，將數據包最終發送給後端的服務器。

LVS 由2部分程序組成，包括 ipvs 和 ipvsadm。

IPVS(ip virtual server)：一段代碼工做在內核空間，叫IPVS，是真正生效實現調度的代碼。IPVS的整體結構主要由IP包處理、負載均衡算法、
　　　　　　　　　　　　　　　　系統配置與管理三個模塊及虛擬服務器與真實服務器鏈表組成。
ipvsadm：另一段是工做在用戶空間，叫ipvsadm，即IPVS管理器，負責爲ipvs內核框架編寫規則，定義誰是集羣服務，而誰是後端真實的服務器(Real Server)。

 

DS：Director Server。指的是前端負載均衡器節點。 RS：Real Server。後端真實的工做服務器。 VIP：Virtual IP，向外部直接面向用戶請求，做爲用戶請求的目標的IP地址。 DIP：Director Server IP，主要用於和內部主機通信的IP地址。 RIP：Real Server IP，後端服務器的IP地址。 CIP：Client IP，訪問客戶端的IP地址。

 

 

 

LVS工做模式

NAT模式

 

 

1 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP。
2 PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈。
3 IPVS比對數據包請求的服務是否爲集羣服務，如果，修改數據包的目標IP地址爲後端服務器IP，而後將數據包發至POSTROUTING鏈。
　此時報文的源IP爲CIP，目標IP爲RIP。
4 POSTROUTING鏈經過選路，將數據包發送給Real Server
5 Real Server比對發現目標爲本身的IP，開始構建響應報文發回給Director Server。 此時報文的源IP爲RIP，目標IP爲CIP。
6 Director Server在響應客戶端前，此時會將源IP地址修改成本身的VIP地址，而後響應給客戶端。 此時報文的源IP爲VIP，目標IP爲CIP。

NAT特性
RIP最好是內網IP
RS的網關必須指向DIP。
DIP和RIP必須在同一個網段內。
請求和迴應的報文都必須通過director，director容易成爲瓶頸。
nat支持端口轉發。

DR模式

 

 

1 首先用戶用CIP請求VIP。
2 根據上圖能夠看到,無論是Director Server仍是Real Server上都須要配置相同的VIP,那麼當用戶請求到達咱們的集羣網絡的前端路由器的時候,
  請求數據包的源地址爲CIP目標地址爲VIP,此時路由器會發廣播問誰是VIP,那麼咱們集羣中全部的節點都配置有VIP,此時誰先響應路由器那麼路由器就會將用戶請求發給誰,
  這樣一來咱們的集羣系統是否是沒有意義了,那咱們能夠在網關路由器上配置靜態路由指定VIP就是Director Server,或者使用一種機制不讓Real Server
  接收來自網絡中的ARP地址解析請求,這樣一來用戶的請求數據包都會通過Director Servrer。
3 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP。
4 PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈。
5 IPVS比對數據包請求的服務是否爲集羣服務，如果，將請求報文中的源MAC地址修改成DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，而後將數據包發至POSTROUTING鏈。 
  此時的源IP和目的IP均未修改，僅修改了源MAC地址爲DIP的MAC地址，目標MAC地址爲RIP的MAC地址
6 因爲DS和RS在同一個網絡中，因此是經過二層來傳輸。POSTROUTING鏈檢查目標MAC地址爲RIP的MAC地址，那麼此時數據包將會發至Real Server。
7 RS發現請求報文的MAC地址是本身的MAC地址，就接收此報文。處理完成以後，將響應報文經過lo接口傳送給eth0網卡而後向外發出。 此時的源IP地址爲VIP，目標IP爲CIP
8 響應報文最終送達至客戶端。

第一種方式：
在路由器上明顯說明vip對應的地址必定是Director上的MAC，只要綁定，之後再跟vip通訊也不用再請求了，這個綁定是靜態的，因此它也不會失效，也不會再次發起請求，
可是有個前提，咱們的路由設備必須有操做權限可以綁定MAC地址，萬一這個路由器是運行商操做的，咱們無法操做怎麼辦？第一種方式當然很簡便，但未必可行。

第二種方式：
在給別主機上（例如：紅帽）它們引進的有一種程序arptables,它有點相似於iptables,它確定是基於arp或基於MAC作訪問控制的，很顯然咱們只須要在每個real server上
定義arptables規則，若是用戶arp廣播請求的目標地址是本機的vip則不予相應，或者說相應的報文不讓出去，很顯然網關（gateway）是接受不到的，也就是director相應的
報文才能到達gateway，這個也行。第二種方式咱們能夠基於arptables。
 第三種方式：
在相對較新的版本中新增了兩個內核參數(kernelparameter)，第一個是arp_ignore定義接受到ARP請求時的相應級別;第二個是arp_announce定義將本身地址向外通告時的通告級別。
【提示：很顯然咱們如今的系統通常在內核中都是支持這些參數的，咱們用參數的方式進行調整更具備樸實性，它還不依賴於額外的條件，像arptables,也不依賴外在路由配置的設置，
反而一般咱們使用的是第三種配置】

arp_ignore:定義接受到ARP請求時的相應級別
0：  只要本地配置的有相應地址，就給予響應。（默認）

1：  僅迴應目標IP地址是本地的入網地址的arp請求。

2：  僅迴應目標IP地址是本地的入網地址，並且源IP和目標IP在同一個子網的arp請   求。

3：  不迴應該網絡界面的arp請求，而只對設置的惟一和鏈接地址作出迴應

4-7：保留未使用

8：  不迴應全部的arp請求。

arp_announce：定義將本身地址向外通告是的通告級別;
0:    將本地任何接口上的任何地址向外通告

1：  試圖僅向目標網絡通告與其網絡匹配的地址

2：  僅向與本地接口上地址匹配的網絡進行通告

DR特性
特色1：保證前端路由將目標地址爲VIP報文通通發給Director Server，而不是RS。
Director和RS的VIP爲同一個VIP。
RS可使用私有地址；也能夠是公網地址，若是使用公網地址，此時能夠經過互聯網對RIP進行直接訪問。
RS跟Director Server必須在同一個物理網絡中。
全部的請求報文經由Director Server，但響應報文必須不能進過Director Server。
不支持地址轉換，也不支持端口映射
RS能夠是大多數常見的操做系統
RS的網關毫不容許指向DIP(由於咱們不容許他通過director)
RS上的lo接口配置VIP的IP地址
DR模式是市面上用得最廣的。
缺陷：RS和DS必須在同一機房中

補充：特色1的解決方法

1. 在前端路由器作靜態地址路由綁定，將對於VIP的地址僅路由到Director Server。存在問題：用戶未必有路由操做權限，由於有多是運營商提供的，因此這個方法未必實用。
2. arptables：在arp的層次上實如今ARP解析時作防火牆規則，過濾RS響應ARP請求。這是由iptables提供的。
3. 修改RS上內核參數（arp_ignore和arp_announce）將RS上的VIP配置在lo接口的別名上，並限制其不能響應對VIP地址解析請求。

Tunnel模式

 

 

1 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP 。
2 PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈。
3 IPVS比對數據包請求的服務是否爲集羣服務，如果，在請求報文的首部再次封裝一層IP報文，封裝源IP爲爲DIP，目標IP爲RIP。而後發至POSTROUTING鏈。
  此時源IP爲DIP，目標IP爲RIP。
4 POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（由於在外層封裝多了一層IP首部，因此能夠理解爲此時經過隧道傳輸）。 此時源IP爲DIP，目標IP爲RIP。
5 RS接收到報文後發現是本身的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裏面還有一層IP首部，並且目標是本身的lo接口VIP，那麼此時RS開始處理此請求
  處理完成以後，經過lo接口送給eth0網卡，而後向外傳遞。 此時的源IP地址爲VIP，目標IP爲CIP
6 響應報文最終送達至客戶端

 

Tunnel模式特性
RIP、VIP、DIP全是公網地址。
RS的網關不會也不可能指向DIP
全部的請求報文經由Director Server，但響應報文必須不能進過Director Server
不支持端口映射
RS的系統必須支持隧道