關於LVS-DR中一次數據的完整旅行

第一次完整的LVS數據旅行格式

首先咱們定義一下IP報文的格式：  源MAC地址:目的MAC地址/源IP地址：目的IP地址

客戶機須要發出一個IP報文(客戶機MAC地址:目的MAC地址/客戶機IP地址：VIP)，這裏對於客戶機MAC地址，客戶機的操做系統自己是知道的，而客戶機的IP地址，客戶機的操做系統
也是知道的，VIP地址客戶機的瀏覽器上有，如今不肯定的是目標MAC地址，所以客戶機的這個請求報文無法發出去，那該怎麼辦呢？

客戶機就會先發一個廣播報文，這報文的格式是這樣的  客戶機MAC地址:客戶機IP地址/ ×××××：VIP地址 

這個廣播報文會發送給全部的局域網終端，意思是 ：個人MAC地址是這個，個人IP地址是這個，請問VIP地址是這個的機器，你的MAC地址是什麼？

這個數據被廣播到交換機上，交換機一看，立刻會把"客戶機MAC地址:客戶機IP地址"記錄在本身的緩存裏面，記住，這一點很重要

咱們但願這個數據被髮送到Director上去，因此Director上應該正常配置這個VIP地址，以便響應這個ARP數據報文，所以在Director上配置這個VIP

如今Director上有VIP了，它會響應客戶機的ARP請求，他響應客戶的ARP請求：個人mac是這個，我是VIP

如今客戶機能夠發送報文(客戶機MAC地址:Director的MAC地址/客戶機IP地址：VIP),這個報文被直接發給了Director

第一步完成

Director收到報文以後，查看報文的目的IP地址，發現是發給它的，因而根據調度算法，選出一臺realserver，假設是rs1，想把報文轉發給rs1，因而director會怎麼作呢？

director發送報文(director的MAC地址:目的MAC地址/客戶機IP地址：VIP)，注意，這裏全部的IP都沒有變化，只是mac地址有變化。

在這裏，遇到一個問題，目的MAC地址該填什麼呢？

咱們但願director把這個報文轉發給rs1，所以，目的MAC地址應該是rs1的目的地址，可是，rs1的MAC地址不知道啊？怎麼辦呢？

director是知道rs1的真實ip地址的(固然知道啊，director必定要清楚本身集羣裏面都有哪些節點嘛)，因此director就發一個arp請求

director的MAC地址：VIP/*****:rs1的真實地址，這意思就是說，個人VIP地址是這個，個人MAC地址是這個，請問rs1真實地址是這個的機器，你的mac地址是什麼？

這個數據被廣播到交換機上，交換機一看，立刻會把"director的MAC地址:VIP"記錄在本身的緩存中。注意，如今交換機中的VIP地址對應的是director的MAC地址，這很重要

rs1早就配置好了真實地址，所以它會響應director的arp請求：個人mac是這個，我是rs1真實IP

如今director能夠把數據轉發給rs1了(director的MAC地址:rs1的MAC地址/客戶機IP地址：VIP)                注意這裏IP層地址都沒有變化，只有MAC地址發生了變化

第二步完成了

rs1收到數據以後，它會判斷是否處理這個數據報文。判據是什麼呢？是報文的目的IP地址，若是該報文的目的IP地址是本身，它就會處理，不然不處理

咱們知道，這個從director轉發過來的數據的目的IP是VIP，可是rs1如今可沒有VIP，所以rs1是不會處理這個數據報文的，那該怎麼辦呢？

辦法就是給rs1配置一個VIP，那就應該在rs1的eth0上再配置一個VIP嗎？(由於eth0上已經有一個真實IP了嘛)，好的，咱們配一個試試看

配完以後，發現rs1上的VIP和director上的VIP發生IP地址衝突了(由於在第一步的客戶機請求VIP的mac地址時，rs1和director都會響應這個arp請求)，這下完蛋了。

所以，VIP須要配置到rs1的lo接口上。那麼，爲何設置到rs1的lo接口上就不會有問題呢？

首先，lo接口是個邏輯接口，這個接口根本不會收到arp請求，收不到arp請求也就不會發送arp響應，再說lo這種邏輯接口根本就不會有MAC地址，可是請注意，它能夠收到IP數據報文

其次，在第一步中，客戶機對VIP這個地址的MAC的ARP請求是會被廣播給rs1的eth0接口的！此時eth0上有真實IP，沒有VIP，lo接口上有VIP。在arp_ignore爲0的狀況下(這是默認狀況)，

eth0網卡收到了對lo上的VIP的arp請求，eth0也是會響應的，它很熱情，它會把lo的mac地址(其實就是本身的MAC地址響應出去)--------0對應的是「迴應任何網絡接口上對任何本地IP地址

的arp查詢請求」，所以咱們須要禁止eth0的這種熱情的行爲，使用arp_ignore = 1

1對應的是 「只回答目標IP地址是來訪網絡接口本地地址的arp查詢請求」，也就是說，若是arp請求是詢問eth0上的那個真實地址的mac，eth0纔會響應(若是這個都不響應，director

就無法把報文轉發給rs1了)，對於其餘的對lo上的VIP的arp的請求，根本不響應。

經過「在lo上配置VIP，在eth0上arp_ignore = 1」這兩種手段，解決了VIP衝突的問題

如今rs1解開數據包，發現目標地址是VIP，而本身配置了VIP地址，所以它會處理這個數據包。

處理完以後，它會把本身的響應數據返回給客戶機，這個數據報文是這樣的

rs1的eth0的mac地址：目標MAC地址/rs1的IP(這裏是VIP)：客戶機IP            注意這裏IP層地址都沒有變化，只有MAC地址發生了變化

對於rs1的eth0的mac地址，rs1操做系統本身是知道的，IP層的兩個IP，也都是知道的，如今問題就是目標MAC地址，這個目標MAC地址應該填什麼呢？

這個IP報文應該直接發給客戶機，所以目標MAC地址應該是客戶機的。但如今rs1並不知道客戶機的MAC地址是什麼，它該怎麼辦呢？

按照慣例，rs1應該發一個arp請求來獲取客戶機的MAC地址，下面的話很重要

這個arp請求裏面包括了本身的ip地址和Mac地址，按照linux的默認設置，默認是將IP報文中的源IP地址做爲arp請求中的源地址的。

咱們能夠看到IP報文中的源IP地址是VIP，所以arp請求報文的數據是這樣的

eth0的MAC地址:VIP/ ×××××：客戶機IP

這意思就是說：個人ip是VIP，個人mac地址是這個，我想問一下，客戶機IP是這個的機器，你的mac是什麼？

結果這個arp請求一發出去，交換機一看，咦，VIP對應的MAC地址好像有變化啊，我要更新MAC地址表--------完蛋了

那該怎麼辦？

當內網的機器要發送一個到外部的ip包，那麼它就會請求路由器的Mac地址，發送一個arp請求，這個arp請求裏面包括了本身的ip地址和Mac地址， 

而linux默認是使用ip的源ip地址做爲arp裏面的源ip地址，而不是使用發送設備上面的，

若是設置 arp_announce 爲2，則使用發送設備上的ip。

arp_announce = 0        在任意網絡接口上的任何本地地址 (默認)

arp_announce = 2         對查詢目標使用最適當的本地地址.在此模式下將忽略這個IP數據包的源地址並嘗試選擇與能與該地址通訊的本地地址.
                        首要是選擇全部的網絡接口的子網中外出訪問子網中包含該目標IP地址的本地地址. 若是沒有合適的地址被發現,將選擇當前的
                        發送網絡接口或其餘的有可能接受到該ARP迴應的網絡接口來進行發送

對查詢目標使用最適當的本地地址，意味着對客戶機IP這個查詢目標使用最適當的本地地址，最適當的本地地址就是eth0上的地址啊。由於數據最後是從這個
接口發出去的，eth0上的本地地址固然是最適當的，這個地址是rs1的真實IP地址。

因而arp請求報文是這樣樣子的：eth0的MAC地址:rs1的eth0上的真實IP地址/ ×××××：客戶機IP

這時候就不會發生VIP地址衝突了，客戶機也會順利的響應這個arp請求，rs1收到了arp響應以後，

就能夠把IP響應數據返回給客戶機了

一次完整的數據流程結束