LVS的DR工作模式，是目前生產環境中最常用的一種工作模式，網上的資料也是最多的，有的文章對DR工作模式的講解還是比較透徹的。這裡我們通過圖文的方式再向您介紹一下DR的工作模式（同樣，如果看不清楚，請右鍵“檢視原圖”）：

上圖反映了DR模式的整個工作過程，同樣為了簡單起見，這裡的Real Server也只畫了一個。如果是多個Real Server的話，LVS會通過排程演算法來決定發往哪臺Real Server。LVS-DR工作模式的幾個關鍵點在於：

• 被Real Server處理後形成的響應報文，不再回發到LVS節點，而是直接路由給中心交換機然後傳送出去。省去了LVS-NAT方式中的LVS回發過程；

• LVS節點只會改寫鏈路層的報文封裝，對網路層和傳輸層報文是不進行改寫的；

• 有網帖說DR工作模式，不能跨子網，也就是說LVS節點和各個Real Server節點必須處於同一個網段中。這是為什麼呢？事實又真的是這樣嗎？很多網路帖子沒有回答這個問題，這篇文章馬上回答一下（實際上章文嵩先生已經回答過這個問題）；

• 使用DR模式時，需要Real Server設定LVS上的VIP為自己的一個迴環IP，不然包會被丟棄。這又是為什麼呢？很多網貼同樣沒有回答這個問題，好吧，我們馬上回答一下。

先來說一說上圖的工作原理：

1. 同樣的，我們為了演示整個生產環境中，從機房中心交換機收到一個數據報文後開始講解。中心交換機同樣採取的IP對映方式。但是與LVS-NAT方式不一樣，Real Server在機房的中心交換機上也需要繫結一個外網對映。這樣保證Real Server回發的響應報文能夠被髮送到外網；

2. LVS節點接收到請求報文後，會改寫報文的資料鏈路層格式。將Target Mac改寫成Real Server的Mac，但是網路層和傳輸層報文不會改寫，然後重新回發給交換機。這裡就涉及一個問題，現在target Mac和Destination IP的對應關係的錯誤的，這個資料報文到了交換機後，由於這種錯位的關係，是不能進行三層交換的，只能進行二層交換（一旦進行IP交換，資料報文的驗證就會出錯，被丟棄）。所以LVS-DR方式要求Real Server和LVS節點必須在同一個區域網內，或者這樣說更確切：LVS節點需要找到一個二層鏈路，將改寫了Mac地址的報文傳送給Real Server，而不能進行三層交換的校驗

   。這樣來看，實際上LVS節點和Real Server介面不一定要在同一個子網，您用一個獨立網絡卡獨立組網，傳送報文也是可行的；

3. 通過二層交換，資料被髮送到Real Server節點。那麼Real Server節點怎麼來判斷這個包的正確性呢？首先當然是傳輸層TCP/IP報文校驗沒有問題，LVS-NAT沒有改寫TCP/IP，當然校驗就沒有問題（除非報文字身就存在問題）；然後是鏈路層的MAC地址能夠被識別，這時就是迴環IP的功勞了。對於Real Server節點來說，192.168.100.10這個VIP就是自己的迴環IP，繫結的MAC也就是被LVS替換後的target mac。那麼Real Server會認為這個包是在本機執行的某一個應用程式通過迴環IP發給自己的，所以這個包不能被丟棄，必須處理；

4. 被處理後的生成的響應報文，被直接傳送給網管。這個就沒有太多的解釋的了，只要保證Real server的預設路由設定成到核心交換機的192.168.100.1就OK了。另外，需要說明的是，由於LVS-DR模式並沒有更改原有的IP報文和TCP報文，所以LVS-DR模式本身是不支援埠對映的，實際上在日常使用實踐中，我們一般使用Nginx做埠對映，因為: 靈.活.。

LVS-DR工作模式的優點在於：

• 解決了LVS-NAT工作模式中的轉發瓶頸問題，能夠支撐規模更大的負載均衡場景；

• 比較耗費網外IP資源，機房的外網IP資源都是有限的，如果在正式生產環境中確實存在這個問題，可以採用LVS-NAT和LVS-DR混合使用的方式來緩解。

LVS-DR當然也有缺點：

• 配置工作較LVS-NAT方式稍微麻煩一點，您至少需要了解LVS-DR模式的基本工作方式才能更好的指導自己進行LVS-DR模式的配置和執行過程中問題的解決；

• 由於LVS-DR模式的報文改寫規則，導致LVS節點和Real Server節點必須在一個網段，因為二層交換是沒法跨子網的。但是這個問題針對大多數系統架構方案來說，實際上並沒有本質限制。

附：FAQ

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

vs/dr本身不會關心IP層以上的資訊，即使是埠號也是tcp/ip協議棧去判斷是否正確，vs/dr本身主要做這麼幾個事：

1. 接收client的請求，根據你設定的負載均衡演算法選取一臺realserver的ip；
2. 以選取的這個ip對應的mac地址作為目標mac，然後重新將IP包封裝成幀轉發給這臺RS；
3. 在hashtable中記錄連線資訊。

vs/dr做的事情很少，也很簡單，所以它的效率很高，不比硬體負載均衡裝置差多少。

2、RealServer為什麼要在lo介面上配置VIP,在出口網絡卡上配置VIP可以嗎?

既然要讓RS能夠處理目標地址為vip的IP包，首先必須要讓RS能接收到這個包。在lo上配置vip能夠完成接收包並將結果返回client。

不可以將VIP設定在出口網絡卡上,否則會響應客戶端的arp request,造成client/gateway arp table紊亂，以至於整個loadbalance都不能正常工作。

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

我相信很多人都不會弄懂它們的作用是什麼，只知道一定得有。我這裡也不打算拿出來詳細討論，只是作幾點說明，就當是補充吧。

第一

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

這兩條是可以不用的，因為arp對邏輯介面沒有意義。

第二

如果你的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 loadbalancer（director）與RS為什麼要在同一網段中?

從第一個問題中大家應該明白vs/dr是如何將請求轉發給RS的了吧？它是在資料鏈路層來實現的，所以director必須和RS在同一網段裡面。

5、為什麼director上eth0介面除了VIP另外還要配一個ip（即DIP）？

如果是用了keepalived等工具做HA或者LoadBalance,則在健康檢查時需要用到DIP，
沒有健康檢查機制的HA或者Load Balance則沒有存在的實際意義.

6、LVS/DR ip_forward需要開啟嗎？

不需要。因為director跟realserver是同一個網段，無需開啟轉發。

7、lvs/dr裡，director的vip的netmask 沒必要設定為255.255.255.255，也不需要再去 route add -host $VIP dev eth0:0，director的vip本來就是要像正常的ip地址一樣對外通告的,不要搞得這麼特殊。