下面部分原理部分,是從網上摘錄，源網址已經無從獲取，我將其中一小部分模糊的說明加入了一些自己的理解，僅最大可能讓全文容易閱讀，也方便自己以后參考，若你是大牛希望能給我一些寶貴的建議，將理解有誤的地方加以修改，若你跟我一樣也在學習中，這會讓你對LVS有更深入的了解，以便在此基礎上,能快的進步。
-------------依然不忘：快就是慢，慢就是快！謹記。
負載均衡和高可用的簡單介紹
1.LB(LoadBalancer)負載均衡,或稱為調度器
硬件：F5 Big-IP ， Citrix(思傑) Netscaler 最常用，A10
軟件：LVS(4層)：根據套接字來負載均衡。 套接字=IP + 端口
Nginx(7層) ：更適合http，smtp，pop3，imap的負載均衡
Haproxy(7層) :根據用戶請求的內容來調度。
它支持4層和7層的負載均衡，其更適合http，tcp(如：mysql，smtp)
LB集群主要以提高並發能力為根本
LB的功能：
1. 監控主服務器的存活情況
2. 故障切換時，完成掛載存儲，啟動服務，搶占VIP
2. HA(HighAvailability) 高可用集群
在線時間/(在線時間 + 故障恢復時間)
RHCS,heartbeat,pacemaker,rose(windows),PowerHA(AIX)：目前這些使用都不多了。
主流是：Keepalived,目前官方也非常活躍,更新版本為2.x。
高可用指標：99％, 99.9%, 99.99%, 99.999%
#HA集群主要解決提高服務在線時間為根本
3. HPC(High-Performance Computing):高性能計算【HPC集群主要解決大任務計算的問題】
MapReduce
追蹤任務完成的狀態
Hadoop
LVS的工作原理:
LVS的兩大組件：
用戶空間： ipvsadm
內核空間： ipvs
當用戶請求被網卡收到，該請求將最先來到PREROUTING鏈，接着進入INPUT鏈，當請求進入INPUT鏈后，ipvs將監聽
到這個連接請求，並將該連接請求重定向到自己，接着根據內部調度規則進行匹配，若沒有匹配到則將該請求原封不動的
轉交給INPUT鏈，最終被INPUT鏈轉發給監聽在指定套接字(IP+Port)的應用程序。若匹配調度規則，則ipvs將修改該請求
的相關地址(NAT模型：修改VIP-->RIP; DR模型：修改目的MAC為RealSRV的MAC)后，重定向到POSTROUTING鏈上，最終
轉發到后端的Real Server上。
使用LVS所需要的加載的幾個重要內核模塊:
- ip_vs
- ip_vs_rr
- ip_vs_wrr
- ip_vs_sh
- nf_conntrack_ipv4 # kernel < 4.19
- nf_conntrack # kernel >= 4.19
LVS的四種工作模式介紹：
1.Virtual server via NAT（VS-NAT）
優點：集群中的物理服務器可以使用任何支持TCP/IP操作系統，物理服務器可以分配Internet的
保留私有地址，只有負載均衡器需要一個合法的IP地址。
缺點：擴展性有限。當服務器節點（普通PC服務器）數據增長到20個或更多時,負載均衡器
將成為整個系統的瓶頸，因為所有的請求包和應答包都需要經過負載均衡器。假使TCP包的
平均長度是536字節的話，平均每個包重新構建,延遲時間大約為60us（在Pentium處理器上計算的，
采用更快的處理器將使得這個延遲時間變短），負載均衡器的最大容許能力為8.93M/s，假定每台
物理服務器的平台容許能力為400K/s來計算，負載均衡器能為22台物理服務器提供計算。
解決辦法：即使是是負載均衡器成為整個系統的瓶頸，如果是這樣也有兩種方法來解決它。
一種是混合處理: 如果采用混合處理的方法，將需要許多同屬單一的RR(DNS的資源記錄) DNS域。
另一種是采用Virtual Server via IP tunneling(即:Tunl模型)或Virtual Server via direct routing(即:DR模型) :
若使用此方式可以獲得更好的可擴展性；也可以嵌套使用負載均衡器，在最前端的是VS-Tunneling或
VS-DR的負載均衡器，然后后面采用VS-NAT的負載均衡器。
2.Virtual server via IP tunneling（VS-TUN）
我們發現，許多Internet服務（例如WEB服務器）的請求包很短小，而應答包通常很大。
優點：負載均衡器只負責將請求包分發給物理服務器，而物理服務器將應答包直接發給用戶。所以，
負載均衡器能處理很巨大的請求量，這種方式，一台負載均衡能為超過100台的物理服務器服務，
負載均衡器不再是系統的瓶頸。使用VS-TUN方式，如果你的負載均衡器擁有100M的全雙工網卡的話，
就能使得整個Virtual Server能達到1G的吞吐量。
缺點：但是，這種方式需要所有的服務器支持"IP Tunneling"(IP Encapsulation)協議，我僅在Linux系統上
實現了這個，目前其它操作系統的支持還在探索之中。
3.Virtual Server via Direct Routing（VS-DR）
優點：和VS－TUN一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端。與VS-TUN相比，
VS-DR這種實現方式不需要隧道結構，因此可以使用大多數操作系統做為物理服務器，其中包括：
Linux、Solaris 、FreeBSD 、windows、IRIX 6.5；HPUX11等。
缺點：要求負載均衡器的網卡必須與物理網卡在一個物理段上。
4. LVS-FullNAT
通過同時修改請求報文的源IP地址和目標IP地址進行轉發（CIP --> DIP, VIP --> RIP ）
此模式在跨機房，跨多個不同網絡時,FullNAT模式也可實現調度。
因為此時實際是將IP包的源和目標都修改了,就好象調度器直接去訪問遠端RealServer,遠端RealServer只需要
按照自己本地路由,找到網關,將包回應給遠端調度器，遠端調度器再次將回應包，返回給用戶。
(1) VIP是公網地址，RIP和DIP是私網地址，且通常不在同一IP網絡；因此，RIP的網關一般不會指向DIP
(2) RS收到的請求報文源地址是DIP，因此，只需響應給DIP；但Director還要將其發往Client
(3) 請求和響應報文都經由Director
(4) 支持端口映射
注意：此類型kernel默認不支持
此中使用場景較少,僅阿里雲內部的SLB使用此種模式.
對上面三種IP負載均衡技術的優缺點比較:
雜項 VS/NAT VS/TUN VS/DR
服務器操作系統 任意 支持隧道 多數(支持Non-arp )
服務器網絡 私有網絡 局域網/廣域網 局域網
服務器數目(100M網絡) 10-20 100 多(100)
服務器網關 負載均衡器 自己的路由 自己的路由
效率 一般 高 最高
LVS的調度算法介紹：
1.輪叫調度（Round Robin）(簡稱rr)
不考慮RealServer實際連接數,系統負載,只是輪流給每個RealServer分配請求.
2.加權輪叫（Weighted Round Robin）（簡稱wrr)
根據實際RealServer的主機配置,將主機配置強的RealServer更大的權重,讓調度器分配更多請求給它處理,
同時調度器可自動詢問RealServer的負載請求,並動態調整其權重值.
3.最少鏈接（Least Connections）(LC) : 將新的鏈接請求分配到當前鏈接數最小的服務器上.
調度器需要記錄每個Server已經建立鏈接的數目,當調度器給A調度一個請求,則將A的總鏈接數+1,當鏈接中止/超時,
則總鏈接-1。
缺陷：
1. Server性能相同：可平滑分發負載，但不能將長鏈接的請求發向同一Server.
2. Server性能不同：該算法並不理會。
因為TCP連接處理請求后會進入TIME_WAIT狀態,TCP的TIME_WAIT一般為2分鍾,此時連接還占用服務器的資源,
所以會出現這樣情形,性能高的服務器已處理所收到的連接,連接處於TIME_WAIT狀態,而性能低的服務器已經忙於
處理所收到的連接,還不斷地收到新的連接請求。
4.加權最少鏈接（Weighted Least Connections）(WLC)
在集群系統中的服務器性能差異較大的情況下，調度器采用“加權最少鏈接”調度算法優化負載均衡性能，具有較高權值
的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。
5.目標地址散列（Destination Hashing）(DH)
“目標地址散列”調度算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，
若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
補充：
目標地址散列調度(Destination Hashing Scheduling)算法,是針對目標IP地址的負載均衡,它是一種靜態映射算法,
通過一個散列函數將一個目標IP地址映射為一台服務器。
目標地址散列算法會先根據請求的目標IP,計算散列哈希(hash key),從靜態分配的散列表找出對應的服務器,
若該服務器是可用且未超載，則將請求發給該服務器，否則返回空,重新調度。
哈希散列表可理解如下：
在此算法中,默認它使用256個哈希桶來將目標IP的哈希值前1個字節划分,平均分成256份，每一份
就是一個范圍,這樣我只要計算出目標IP的哈希值,馬上就能確定它應該在那個桶中,然后定位到該桶，
這樣在做小范圍表掃描，速度就非常快。另外還需要注意：在此算法中它類似於一致性哈希算法，
它會事先將所有可用服務器均勻循環分布到每個桶中，更簡單理解就是本來就是一張有256條記錄的大表,
該表中事先將所有可用服務器全部順序循環插入到每一行記錄中,然后將這張大表拆分成多個小表，
並按前面的方法,將一個范圍值作為進入該小表的條件，這樣就可以最大限度均勻每一台服務器的負載。
6.源地址散列（Source Hashing）(SH)
“源地址散列”調度算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，
若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
7.基於局部性的最少鏈接（Locality-Based Least Connections）(LBLC)
“基於局部性的最少鏈接”調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。該算法根據
請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；
若服務器不存在，或者該服務器超載且有服務器處於一半的工作負載，則用“最少鏈接” 的原則選出一個可用的服務器，
將請求發送到該服務器。
8.帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication）(LBLCR)
“帶復制的基於局部性最少鏈接”調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。
它與LBLC算法的不同之處是它要維護從一個目標 IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP
地址到一台服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按“最小連接”原則
從服務器組中選出一台服務器，若服務器沒有超載，將請求發送到該服務器；
若所選服務器超載（超負載的標准是:該服務器正在處理的連接總數 > 其權重值的2倍），則按“最小連接”原則
從這個集群中選出一台服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該所選服務器組
有一段時間沒有被修改過,則所選服務器加入新緩存復制組后,很可能導致復制流量大量增加，因此將最忙的服務器
從服務器組中刪除，以降低復制流量的程度。
我的理解:
因為緩存的熱點數據可能僅有20%是有效的,最繁忙的服務器緩存的數據量很大，但有效的經常被訪問的熱點
數據並不一定很多,因此總體考慮,該組中其它服務器上現有的緩存數據可應對一定量的請求,即便損失最繁忙的
服務器的數據也不會造成太大影響，但若留着它,新加入到節點,可能需要跟它同步緩存數據,將會導致更大的網絡
帶寬被占用，很可能導致整個組的不可用,因此寧願損失一小部分緩存數據,也不能讓整體不可用。
【注意： 以上理解不一定正確，僅供參考】
9. 最短的期望的延遲（Shortest Expected Delay Scheduling SED）(SED)
基於wlc算法。這個必須舉例來說了
ABC三台機器分別權重1，2，3 ，連接數也分別是1，2，3。那么如果使用WLC算法的話一個新請求進入時
它可能會分給ABC中的任意一個，使用sed算法后會進行這樣一個運算
A：(1+1)/1 = 2
B：(1+2)/2 = 1.5
C：(1+3)/3 = 1.3334
根據運算結果，把連接交給C，因為C的處理延時最小 。
10.最少隊列調度（Never Queue Scheduling NQ）(NQ)
無需隊列。如果有台 realserver的連接數＝0就直接分配過去，不需要在進行sed運算。
下面對三種模式做示例配置說明:
1. LVS-NAT模型：
簡單的來說，LVS的NAT模型如下圖：
本質是多目標IP的DNAT，通過將請求報文中的目標地址和目標端口修改為通過調度算法挑出
的RS的RIP和PORT實現轉發。
LVS-NAT模型:
（1）RealServer和調度器應在同一個IP網絡，且應使用私網地址；RealServer的網關要指向調度器的IP
（2）調度器(Director)是RealServer的網關, 因此請求和響應報文都將由調度器轉發,因此調度器容易成為系統瓶頸.
（3）支持端口映射，可修改請求報文的目標PORT
（4）LVS必須是Linux系統，RS可以是任意OS系統
上面拓撲圖的配置如下:
Client:
使用我的物理機,將默認網關指向ISP，當然使用VM也可以.
ISP:
ip addr add dev eth0 192.168.10.254/24
ip addr add dev eth1 1.0.0.1/24
Systemctl stop firewalld #關閉firewalld,手動使用iptables來管理防火牆.
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 !-d 192.168.10.0/24 -j MASQUERADE
此實驗中讓Client可訪問企業Web,也可用簡單的方式:
在ISP和企業防火牆直接互相將默認網關指向對方.
企業FireWall：
ip addr add dev eth0 1.0.0.2/24
ip addr add dev eth1 192.168.80.254/24
systemctl stop firewalld
iptables -t nat -A PREROUTING -d 1.0.0.2 -p tcp --dport 80 -j DNAT --to-destination 192.168.80.10:80
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p
Director LVS:
ip addr add dev eth0 192.168.80.10/24
firewall-cmd --add-service=http --permanent ; firewall-cmd --reload
yum install -y ipvsadm
ipvsadm -A -t 192.168.80.10:80 -s wrr
ipvsadm -a -t 192.168.80.10:80 -r 192.168.80.11:8080 -m -w 3
ipvsadm -a -t 192.168.80.10:80 -r 192.168.80.12:8080 -m -w 2
ipvsadm -a -t 192.168.80.10:80 -r 192.168.80.13:8080 -m
ipvsadm -L -n (后來截的圖,權重不符)
三台RealServer上只需配置IP,並安裝httpd軟件，然后啟動即可.
firewall-cmd --add-port=8080/tcp --permanent; firewall-cmd --reload
在任意一台上查看httpd的日志:
可以看到CIP是ISP上的IP,即客戶端的默認網關外網接口的IP.
2. LVS-DR模型
實驗拓撲說明：
這個拓撲中必須有一個獨立的網關，因為用戶請求發來時，GW將請求發給VIP，而VIP只有調度器會響應，
GW將請求發給調度器，【注意：調度器的VIP,盡量使用32位掩碼，這非必須】，在DR模式下，調度器上與
GW連接的接口上有兩個IP，一個是VIP(Virtual IP)，一個是DIP(Director IP)； 當調度器收到來自GW的包后,
發現目標是VIP,並且訪問的服務與自身定義的虛擬服務一樣，接着調度器將數據包中的源MAC修改為自己的MAC，
而目的MAC的修改是 根據調度算法，選擇一台Real Server后，將該Real Server的MAC填寫在目的MAC上，
接着將包發給后端服務器，如此例為Real Server 1，RIP1收到后將解包發現其IP是本地loopback的接口IP，因此RIP1
繼續解包，最終將包送給上層服務，如本例是Web服務；Web開始進行響應，最終封包時，將源MAC寫為自己，
目的MAC寫為GW，源IP寫VIP，目的IP寫Client IP，並發給GW出去響應。
（1）DIP, RIP 和 VIP : 可在同一網段，也可不在同一網段 ，但他們必須在同一個交換網絡。
（2）Director(調度器)和RealServer他們的網關都必須指向真實網關(Firewall)，並且都要配置VIP.
（3）Director可以響應ARP查詢VIP的MAC，但RealServer一律都不回應查詢VIP的ARP請求.
以上拓撲圖的配置如下:
Client:
將默認網關指向ISP
ISP:
ip addr add dev eth0 192.168.10.254/24
ip addr add dev eth1 1.0.0.1/24
Systemctl stop firewalld #關閉firewalld,手動使用iptables來管理防火牆.
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 !-d 192.168.10.0/24 -j MASQUERADE
此實驗中讓Client可訪問企業Web,也可用簡單的方式:
在ISP和企業防火牆直接互相將默認網關指向對方.
企業FireWall：
ip addr add dev eth0 1.0.0.2/24
ip addr add dev eth1 192.168.80.254/24
systemctl stop firewalld
iptables -t nat -A PREROUTING -d 1.0.0.2 -p tcp --dport 80 -j DNAT --to-destination 192.168.80.10:80
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p
Director LVS:
ip addr add dev eth0 192.168.80.10/24
ip addr add dev lo 192.168.80.66/32
firewall-cmd --add-service=http --permanent ; firewall-cmd --reload
yum install -y ipvsadm
ipvsadm -A -t 192.168.80.10:80 -s wrr
ipvsadm -a -t 192.168.80.10:80 -r 192.168.80.11:8080 -g -w 3
ipvsadm -a -t 192.168.80.10:80 -r 192.168.80.12:8080 -g -w 2
ipvsadm -a -t 192.168.80.10:80 -r 192.168.80.13:8080 -g
三台RealServer:
ip addr add dev eth0 192.168.80.11/24 #三台分別配置11，12，13
ip addr add dev lo 192.168.80.66/32 #不一定非要是32,可以是24.
#下面配置實際上是只允許lo接口收到與lo直接連接的接口發來的ARP請求時,
#才響應關於192.168.80.66的MAC響應.同時不在發生免費ARP做自問自答.
#向網絡中宣告我要使用192.168.80.66這個IP了。
echo "net.ipv4.conf.all.arp_ignore = 1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.arp_announce = 2" >> /etc/sysctl.conf
echo "net.ipv4.conf.lo.arp_ignore = 1" >> /etc/sysctl.conf
echo "net.ipv4.conf.lo.arp_announce = 2" >> /etc/sysctl.conf
sysctl -p
firewall-cmd --add-port=80/tcp --permanent; firewall-cmd --reload
查看通信過程的提示:
1. 在調度器或RealServer使用
tcpdump -i 接口 -n -nn port 80 -w director.cap
#這樣可捕獲通信過程中的所有包,包括調度器收到的,轉發給RealServer的,
以及RealServer發生給Firewall的.
#若向單獨查看調度器收到和發送的包，在RealServer上查看自己收到的包和發送的包可：
tcpdump -i 接口 -n -nn -p port 80
#-p : 僅捕獲發給自己的包,非自己的不要.
2. 在Firewall上查看所有的MAC
ip addr show dev eth1 |grep link/ether
ip neigh
3. 使用Wireshare查看時,通過添加自定義列來查看MAC的變化
3. LVS Tunnel模式
拓撲：
LVS Tunnel模式配置要點：
(1) LVS調度節點、RealServer節點、VIP都必須是公網IP
(2) LVS調度節點、RealServer節點都必須配置VIP
(3) 調度節點 與 RS間必須打通一條隧道
(4) 客戶端請求發往調度節點，調度節點通過隧道將請求報文封裝起來發給RS,
RS在隧道另一端去掉GRE封裝,發現是去往VIP的,隨即轉給tunl0處理,最終Tunl0
將響應報文從RS的默認路由發出。
(5) 調度節點要在所有設備上啟用 只接收網關發送的ICMP的重定向報文。
(6) 調度節點 和 RS上都必須關閉路由轉發(ip_forward), RS上關閉ARP響應和返回路徑過濾
(即:源是A口,要從B口出,B口不丟該包).
LVS Tunnel環境搭建
(1) 路由器模擬:
echo 1 > /proc/sys/net/ipv4/ip_forward
ifconfig eth0 20.0.0.254/24 up
ifconfig eth1 30.0.0.254/24 up
ifconfig eth2 40.0.0.254/24 up
ifconfig eth3 192.168.10.254/24 up
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 ! -d 192.168.10.0/24 -j SNAT --to 192.168.10.254
(2) LVS調度節點
#關閉路由轉發（默認是關閉.）
echo 0 > /proc/sys/net/ipv4/ip_forward
#在所有接口、默認接口、eth0上都打開 僅接收來自網關的ICMP重定向.
#注：默認應該是打開的,從抓包和分析上看,ICMP重定向是必須,因為客戶端訪問的調度器的子接口,
# 而調度器的主接口IP是20.0.0.1,子(次)接口IP20.0.0.2,網關通過ARP發現,客戶端訪問的VIP20.0.0.2
# 是在調度器接口上，因此,將去往20.0.0.2的請求重定向給調度器。
echo 1 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 1 > /proc/sys/net/ipv4/conf/default/send_redirects
echo 1 > /proc/sys/net/ipv4/conf/eth0/send_redirects
#先關閉所有接口,用到那個激活那個。
service network stop
ifconfig eth0 20.0.0.1/24 up
ifconfig eth0:0 20.0.0.2 broadcast 20.0.0.2 netmask 255.255.255.255 up
ip tunnel add tun1 mode gre remote 30.0.0.1 local 20.0.0.1
ifconfig tun1 10.0.0.1/30 up
ip tunnel add tun2 mode gre remote 40.0.0.1 local 20.0.0.1
ifconfig tun2 10.0.0.5/30 up
#注：
GRE(通用路由封裝) ： https://blog.csdn.net/taozpwater/article/details/9774123
簡單理解: GRE就是在將原始IP包,再次封裝在GRE內部, 接着在再次將GRE包封裝到新IP包中,
然后在加入如鏈路層幀頭,最后發出去.其實GRE,VxLAN,NVGRE,IPSec都可認為是一種VPN.
MAC幀[IP頭[GRE頭【IP頭[TCP頭[應用協議數據]]】]]
注意：
GRE封裝后,若后端是調度器,則該調度器將永遠只能看到一個IP來訪問自己,因此要注意使用調度算法.
#添加默認路由
route add default gw 20.0.0.254
#添加主機路由,以便Linux收到去往20.0.0.2的報文后,知道轉到那個接口上。
route add -host 20.0.0.2 dev eth0:0
yum install ipvsadm
ipvsadm -A -t 20.0.0.2:80 -s rr
ipvsadm -a -t 20.0.0.2:80 -r 10.0.0.2 -i #注意:這里必須使用tunnel模式,即“-i”
ipvsadm -a -t 20.0.0.2:80 -r 10.0.0.6 -i
(2) RealServer1的配置:
ifconfig eth0 30.0.0.1/24 up
ifconfig tunl0 20.0.0.2 broadcast 20.0.0.2 netmask 255.255.255.255 up
#注意：一定要添加一條主機路由,否則Linux的tun0接口收到GRE封包后,
# 解開發現是一個去往20.0.0.2的IP報文,查本機轉發表若沒有找到,就可能丟棄該報文.
# 那么客戶端可能就打不開網頁了。
route add -host 20.0.0.2 dev tunl0
ip tunnel add tun0 mode gre remote 20.0.0.1 local 30.0.0.1
ifconfig tun0 10.0.0.2/30 up
#關閉路由轉發
echo 0 > /proc/sys/net/ipv4/ip_forward
#arp_ignore: 定義接收到ARP請求時的響應級別；
# 0：只要本地配置的有相應地址，就給予響應；
# 1：僅響應目的IP配置在此接口上的ARP廣播請求
#arp_announce: 定義將自己的地址向外通告時的通告級別(此行為僅發生在網絡設備剛接入網絡時)
# 0：將本地任何接口上的任何地址向外通告；
# 1：試圖僅向目標網絡通告與其網絡匹配的地址；
# 2：僅向與本地接口上地址匹配的網絡進行通告；
echo 1 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/tunl0/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
#關閉tunl0、eth0上返回路徑過濾
echo 0 > /proc/sys/net/ipv4/conf/tunl0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
(2) RealServer2的配置:
ifconfig eth0 40.0.0.1/24 up
ifconfig tunl0 20.0.0.2 broadcast 20.0.0.2 netmask 255.255.255.255 up
#注意：一定要添加一條主機路由,否則Linux的tun0接口收到GRE封包后,
# 解開發現是一個去往20.0.0.2的IP報文,查本機轉發表若沒有找到,就可能丟棄該報文.
# 那么客戶端可能就打不開網頁了。
route add -host 20.0.0.2 dev tunl0
ip tunnel add tun0 mode gre remote 20.0.0.1 local 40.0.0.1
ifconfig tun0 10.0.0.6/30 up
#關閉路由轉發
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/tunl0/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
#關閉tunl0、eth0上返回路徑過濾
echo 0 > /proc/sys/net/ipv4/conf/tunl0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
LVS調度器收到來客戶端的訪問報文：
#先重定向
#調度后發送的報文，注意每個IP報文內部的內容,在該IP報文看來都僅僅是數據而已。
#RealServer2收到GRE報文解封裝后，將該報文發給tun0接口后：
#RealServer2的tun0接口去掉IP層后，發現還是IP報文,隨機轉發給tunl0接口:
#回應
