LVS工做總結之原理篇–DR模式

原文地址：

http://www.chenqing.org/2012/11/%E3%80%90lvs%E3%80%91lvs%E5%B7%A5%E4%BD%9C%E6%80%BB%E7%BB%93%E4%B9%8B%E5%8E%9F%E7%90%86%E7%AF%87.html

博客中還有其餘模式和keepalived的原理總結。這篇本身總結標註和整理了一下，本身總結的地方紅色標註。

======================================================================================================================================

先解釋幾個名詞：

    LB(Load Balancer) :負載均衡器，也就是裝有LVS（ipvsadm）的server

    VIP(Virtual IP):虛擬IP，也就是給遠程客戶端（網民）提供服務的外部IP，好比，提供80服務，域名是www.a.com,則www.a.com 對應的A記錄就是VIP

    LD(Load Balancer Director):同LB，負載均衡調度器

    real server:即後端提供真是服務的server，好比你提供的是80服務，那你機器可能就是裝着Apache這中web服務器

    DIP(Director IP)：在NAT模式中是後端realserver的gateway，在DR和Tune中若是使用heartbeat或者keepalived，用來探測使用

    RIP(Real Server IP):後端realserver的IP

LVS的三種工做模式

    DR（直接路由）

    NAT（網絡地址轉換）

    Tune （隧道）

DR(直接路由)

這裏咱們以及後面的例子咱們都會假設這麼一個場景，咱們使用LVS爲咱們的web集羣提供負載均衡功能：

    VIP： 221.130.1.2

    DIP1: 221.130.1.3

    DIP2: 221.130.1.4

    RIP1: 221.130.1.100

    RIP2: 221.130.1.101

    GATEWAY: 221.130.1.1

關於公網VIP得到：這個IP不能真實存在，不能是服務器的IP，VIP和其餘IP必須在一個網段，若是機器均置於IDC機房，只須要向你的IDC申請5個公網IP便可，多餘的一個公網ip用於VIP；

DR模式的原理

如今客戶端CLient訪問www.a.com ,通過dns查詢獲得目的IP爲VIP，目的端口爲80，因而客戶端和咱們VIP，端口80創建鏈接（TCP三次握手，只是創建鏈接沒有傳送數據），以後客戶端發送HTTP請求，LVS在VIP上收到以後，根據hash策略，從後端realserver中選

出一臺做爲這次請求的接受者，假設爲RIP1，LVS將請求包的目的mac地址更改成RIP1的mac，而後封裝後轉發給後端的RIP1，同時將該連接記錄在hash表中。

RIP1的某一塊網卡，好比eth0，接收到這個轉發包看到mac地址是本身的，因而就轉發給上層的IP層，IP層解開包後，發現目的的IP地址也是本身，由於VIP也配置在咱們的一塊non-arp的網卡上（好比lo:0）,而後根據IP首部的類型字段（這裏是TCP），把請求送給

TCP，而後TCP根據目的端口80，傳給應用層的Apache，Apache處理完請求以後，將數據傳給TCP，TCP將源端口更改成80 ，源IP更改成VIP，目的端口更改成客戶端的端口，目的IP更改成Client的IP，打包後給IP層，IP層根據目的地址進行路由，而後通過網絡返給

Client，完成了一次請求，而不通過LB；

這裏注意的是，VIP和realserver必須在同一個網段中的（想一想爲何？）

DR模式的優缺點

優勢：

    可擴展性強，ld不會成爲業務增加的瓶頸

缺點：

    節點不能跨網段，即real server和ld必須在一個物理網段中,必定程度上可能會使用多個公網IP

    realserver上須有一塊網卡不接受arp廣播

DR模式與arp

因爲DR模式使用的是更改目的的mac地址，因此不免要和arp打交道。

通常來講客戶端是不會和咱們的服務器在同一個網段的，那麼請求就會通過咱們的服務器所在網段的路由設備上，咱們知道在同一網段中，兩個主機通訊靠的是二層的物理地址而不是Ip地址，因此當請求包到達這路由設備上以後，若路由設備的arp表中沒有VIP對應的

MAC，就會廣播一個arp請求，在這裏咱們將LVS和real server上都配置了VIP，那麼按照理論他們都會響應這個arp請求，那路由器的arp表就會亂了。因此，咱們就須要只讓LVS上響應VIP的arp請求，而real server 不響應；

Linux主機有這麼一個特性，假設咱們的主機上有兩塊網卡，好比eth0,eth1 當arp請求eth1的mac地址的時候，eth1會答覆，這個是理所固然的，可是eth0也會「好心」的幫eth1回答這個arp請求； 要防止這樣的話，就須要更改下咱們的一些內核參數：

    net.ipv4.conf.lo.arp_ignore = 1

    net.ipv4.conf.all.arp_ignore = 1

正常狀況下只寫第二條就是了，all 是指全部設備的interface，當all和具體的interface好比lo，按照最大的值生效；

另一個linux的特性就是，對於一個從realserver發出的arp請求，其源IP是VIP，而出口不會是lo，這裏假設是eth0，那麼這個arp請求包裏裏面，源IP就是VIP，源MAC是eth0的mac，目的IP是網關，那麼路由器在接收到這個請求的時候，會將將本身的相應接口的硬

件地址放在arp響應包中，同時將請求包中的源IP及MAC放在arp高速緩存中，那這下可就亂套 了，就會使真正的VIP得不到正確的請求了.

這是由於，正常的狀況下，arp的請求中源IP是出去的所在接口的地址，mac也是出去的接口的mac，但linux在默認狀況下卻不是這樣的，若是一個接口發出的arp請求須經另外一個出口出去的時候，源IP就不是所出去接口的IP，那麼將內核參數設置爲 2 相應的解決了這個

問題。

    net.ipv4.conf.lo.arp_announce = 2

    net.ipv4.conf.all.arp_announce = 2

===================

關於arp:
1.什麼是arp？

ARP協議是「Address Resolution Protocol」（地址解析協議）的縮寫。在局域網中，網絡中實際傳輸的是「幀」，幀裏面是有目標主機的MAC地址的。在以太網中，一個主機要和另外一個主機進行直接通訊，必需要知道目標主機的MAC地址。但這個目標MAC地址是如何獲

得的呢？它就是經過地址解析協議得到的。所謂「地址解析」就是主機在發送幀前將目標IP地址轉換成目標MAC地址的過程。ARP協議的基本功能就是經過目標設備的IP地址，查詢目標設備的MAC地址，以保證通訊的順利進行。

2.arp協議的工做原理？

在每檯安裝有TCP/IP協議的電腦裏都有一個ARP緩存表，表裏的IP地址與MAC地址是一一對應的

咱們以主機A（ ）向主機B（ ）發送數據爲例。當發送數據時，主機A會在本身的ARP緩存表中尋找是否有目標IP地址。若是找到了，也就知道了目標MAC地址，直接把目標MAC地址寫入幀裏面發送就能夠了；若是在ARP緩存表中沒有找到相對應的IP地址，主機A就會在

網絡上發送一個廣播，目標MAC地址是「FF.FF.FF.FF.FF.FF」，這表示向同一網段內的全部主機發出這樣的詢問：「 的MAC地址是什麼？」網絡上其餘主機並不響應ARP詢問，只有主機B接收到這個幀時，才向主機A作出這樣的迴應：「 的MAC地址是00-aa-00-62-

c6-09」。這樣，主機A就知道了主機B的MAC地址，它就能夠向主機B發送信息了。同時它還更新了本身的ARP緩存表，下次再向主機B發送信息時，直接從ARP緩存表裏查找就能夠了。ARP緩存表採用了老化機制，在一段時間內若是表中的某一行沒有使用，就會被刪

除，這樣能夠大大減小ARP緩存表的長度，加快查詢速度。

3.如何查看arp緩存表？

ARP緩存表是能夠查看的，也能夠添加和修改。在命令提示符下，輸入「arp -a」就能夠查看ARP緩存表中的內容了

用「arp -d」命令能夠刪除ARP表中某一行的內容

用「arp -s」能夠手動在ARP表中指定IP地址與MAC地址的對應。

===================

其它問題    ip_forward不須要打開，由於LB和real server在同一個網段    通常VIP所在的網卡還配置一個DIP，這是由於若是是用了keepalived等工具作HA或者Load Balance,則在健康檢查時須要用到DIP    在realserver上也能夠將VIP配置在除RIP所在網卡的其它網卡上