原文地址：
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所在網卡的其它網卡上