LVS之DR模型架構

1、LVS-DR模型架構圖

2、DR模型實現負載均衡的工做方式
       說了NAT模型的實現方式,那麼NAT模型有個缺陷,由於進出的每一個數據包都要通過Director Server,當集羣系統負載過大的時候Director Server將會成爲整個集羣系統的瓶頸,那麼DR模型就避免了這樣的狀況發生,DR模型在只有請求的時候纔會通過Director Server, 迴應的數據包由Real Server 直接響應用戶不須要通過Director Server,其實三種模型中最經常使用的也就是DR模型了,下面來講DR模型具體是怎麼實現負載均衡的,根據上圖,
1, 首先用戶用CIP請求VIP, 
2, 根據上圖能夠看到,不論是Director Server仍是Real Server上都須要配置VIP,那麼當用戶請求到達咱們的集羣網絡的前端路由器的時候,請求數據包的源地址爲CIP目標地址爲VIP,此時路由器會發廣播問誰是VIP,那麼咱們集羣中全部的節點都配置有VIP,此時誰先響應路由器那麼路由器就會將用戶請求發給誰,這樣一來咱們的集羣系統是否是沒有意義了,那咱們能夠在網關路由器上配置靜態路由指定VIP就是Director Server,或者使用一種機制不讓Real Server 接收來自網絡中的ARP地址解析請求,這樣一來用戶的請求數據包都會通過Director Servre,
3,當Director Server收到用戶的請求後根據此前設定好的調度算法結果來肯定將請求負載到某臺Real Server上去,假如說此時根據調度算法的結果,會將請求負載到Real Server 1上面去,此時Director Server 會將數據幀中的目標MAC地址修改成Real Server1的MAC地址,而後再將數據幀發送出去,
4,當Real Server1 收到一個源地址爲CIP目標地址爲VIP的數據包時,Real Server1發現目標地址爲VIP,而VIP是本身,因而接受數據包並給予處理,當Real Server1處理完請求後,會將一個源地址爲VIP目標地址爲CIP的數據包發出去,此時的響應請求就不會再通過Director Server了,而是直接響應給用戶

編輯DR有三種方式
第一種方式：在路由器上明顯說明vip對應的地址必定是Director上的MAC，只要綁定，之後再跟vip通訊也不用再請求了，這個綁定是靜態的，因此它也不會失效，也不會再次發起請求，可是有個前提，咱們的路由設備必須有操做權限可以綁定MAC地址，萬一這個路由器是運行商操做的，咱們無法操做怎麼辦？第一種方式當然很簡便，但未必可行。
 
第二種方式：在給別主機上（例如：紅帽）它們引進的有一種程序arptables,它有點相似於iptables,它確定是基於arp或基於MAC作訪問控制的，很顯然咱們只須要在每個real server上定義arptables規則，若是用戶arp廣播請求的目標地址是本機的vip則不予相應，或者說相應的報文不讓出去，很顯然網關（gateway）是接受不到的，也就是director相應的報文才能到達gateway，這個也行。第二種方式咱們能夠基於arptables。
 
第三種方式：在相對較新的版本中新增了兩個內核參數(kernelparameter)，第一個是arp_ignore定義接受到ARP請求時的相應級別;第二個是arp_announce定義將本身地址向外通告是的通告級別。【提示：很顯然咱們如今的系統通常在內核中都是支持這些參數的，咱們用參數的方式進行調整更具備樸實性，它還不依賴於額外的條件，像arptables,也不依賴外在路由配置的設置，反而一般咱們使用的是第三種配置】
 
arp_ignore:定義接受到ARP請求時的相應級別
     0：只要本地配置的有相應地址，就給予響應。
     1：僅在請求的目標地址配置請求到達的接口上的時候，纔給予響應
     2：只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求,且來訪IP必須在該網絡接口的子網段內
     3：不迴應該網絡界面的arp請求，而只對設置的惟一和鏈接地址作出迴應
     4-7：保留未使用
     8：不迴應全部（本地地址）的arp查詢
      
arp_ignore 
設置爲1，當別人的arp請求過來的時候，若是接收的設備上面沒有這個ip，就不響應，默認是0，只要這臺機器上面任何一個設備上面有這個ip，就響應arp請求，併發送MAC地址應答。
      arp_announce：定義將本身地址向外通告是的通告級別;
         0: 將本地任何接口上的任何地址向外通告
         1：試圖僅想目標網絡通告與其網絡匹配的地址
         2：僅向與本地藉口上地址匹配的網絡進行通告

補充LVS-DR原理

全部的Director和RealServer都在同一個物理網絡中(交換機)而且都只有一塊網卡，交換機前面有個路由器，這個路由器多是咱們機房內部的，也有多是網絡運行商的。
 
當客戶端的請求被送到R2和Switch之間的時候，這個時候源ip是cip，目標地址是vip。vip必定在Director上是毋庸置疑的，因此這個報文就背送到Director的vip網卡上。
當客戶端的請求被送到Switch和Director之間的時候，這個時候源ip仍然是cip，目標地址是vip。Director發現當前本機配置的有vip地址，因此請求的必定是當前主機
因此報文通過Prerouting鏈到達Input鏈，而監控在Input鏈上的ipvs規則發現請求的是一個集羣服務，好比監聽在80端口的web集羣服務。這個時候lvs要根據ipvs規則
等等要修改報文了，在LVS-DR模型下報文送到Director上的時候，Director不會拆它的IP首部，也不會拆它的TCP首部，Director只要將MAC地址或者幀首部拆掉了。
爲何Director要拆開幀首部MAC地址呢？由於報文的目的地址就是Director本地主機，只要到達目的主機，網卡就會拆開幀首部的。由於目標MAC就是本地主機。
拆掉幀首部之後，查看IP首部和TCP首部，它發現請求的報文訪問的是一個集羣服務。
所以爲了實現LVS-DR模型的效果，在源有的IP首部之上(切記源IP、目標IP、源端口、目標端口等等沒有動)，僅僅是在原有的報文外面又從新封裝了一個MAC地址幀首部
幀首部有源MAC和目標MAC，這個時候發送的主機是Director。因而Director把本地網卡的MAC地址做爲整個報文的源MAC地址，而目的MAC就是選擇的後端某臺RealServer
[選擇後端的某臺RealServe是Director根據它的一些調度算法(rr,wrr...)選擇的]。假如選擇的是RealServer2，那麼會找到RealServer2 IP對應的MAC地址，因而找到了
RealServer2網卡對應的MAC地址，它是經過ARP地址解析找到的RealServer2對應的MAC地址。
那麼Director到RealServer2之間的報文傳送是源MAC地址是Director網卡對應的MAC地址，目標MAC地址是RealServer2網卡對應的MAC地址。
RealServer2接收到報文之後，發現請求的報文真的是自已，因而拆掉了MAC的幀首部，拆掉後發現請求的報文源地址是cip，目標地址是VIP。若是RealServer2上沒有VIP
，那麼RealServer2是不會接受這個報文的，所以必須在每一個RealServer上配置VIP地址。由於RealServer2上有VIP地址，報文被接收下來，拆掉了IP首部，發現了報文
請求的是一個服務，好比80 由於傳輸層沒有作任何修改，用戶請求的是80服務，那麼RealServer2接收到的報文也是請求的80服務。若是RealServer2上有80服務，因而
RealServer2把這個請求轉交給用戶空間的進程，由用戶空間處理完成後，向外響應的。而請求報文的源地址是CIP，目標地址是VIP。那麼儘量讓它使用CIP是目標地址
VIP是源地址，因而這個響應報文直接被髮送到了交換機上。
 
當RealServer2響應報文到達Switch的時候，這個時候源地址是VIP，目標地址是CIP。
由於目標地址是CIP，假如VIP和CIP不在同一個網段當中，這個時候要根據目標地址CIP作路由選擇，好比默認路由，網關才能響應CIP的報文請求
你們都知道目標地址CIP是互聯網地址，那麼每一個RealServer的網關要指向哪呢？？？？？？
要指向可以訪問互聯網的設備，不該該指向Director的DIP地址。而是直接指向了可以訪問互聯網的路由設備。全部(頗有可能)指向的是R2路由的私有地址作網關。
爲何是頗有可能而不是說必定呢？？？？
 
 
當報文被送到Switch和R2的時候，這個時候的源地址是VIP，目標地址是CIP。那麼這個時候報文被送到R2網關的時候，R2發現目標地址是互聯網的地址CIP，它會經過
路由NAT而後被送到CIP上的。
 
 
 
這裏要考慮一個問題，爲了實現每臺RealServer在向外發送響應報文的時候，能夠把VIP做爲源地址，所以咱們在每臺RealServer上配置了VIP地址。
 
假如客戶端發送請求報文被送到R2路由器的時候，那麼R2路由器會拆開客戶端的請求報文發現源地址是CIP，目標地址是VIP；不管是將請求送給Director仍是RealServer，必需要根據
MAC地址向內轉發，由於在同一網段，那麼它怎麼知道VIP對應的MAC地址是什麼呢？？？？
那麼將進行廣播說：‘我知道有一個傢伙的VIP地址，那麼請告訴我它對應的MAC地址’，那麼它發送的廣播請求，同一網段的全部主機都能收到，因而配置有VIP地址的全部主機都進行相應並告訴自已的MAC地址，那麼若是全部的主機都進行相應，那麼前端的路由設備就混亂了，它就沒法分辨誰纔是VIP對應的MAC地址。
默認狀況下，誰相應的快，就會把客戶端的請求報文發送給那臺主機，若是被送到RealServer2 那麼就不符合咱們負載均衡的條件了。
那麼咱們在這裏須要作一個很是重要的事情，就是每臺配置有RealServer的VIP地址不給予ARP響應。那麼咱們若是屏蔽它不能響應呢？
那麼全部的RealServer上都要關閉對ARP廣播的響應。 
要達到的目的：讓咱們的前端路由或者網關，實現報文發送的時候，僅僅可以將報文對目標IP爲VIP發送給Director？
實現的方式有如下三種：
一、在R2路由器的內部接口上手動綁定一個靜態的解析地址，明確指明目標是VIP的MAC必定是Director的MAC
   那麼之後發送報文的時候就不用再次請求了，能夠由指定的靜態解析地址直接發送給Director
   這個綁定是靜態的也不會失效
   缺點：
   R2路由是內部路由器，那麼VIP是私有地址；若是R2是網絡運營商提供的路由設備，也就是VIP是公網地址，咱們就沒法再R2上進行靜態綁定了。
二、arptables：
   基於MAC地址作訪問控制的，咱們只須要在每臺RealServer上定義arptables規則，若是用戶的arp廣播請求的目標地址是本機的VIP則不給予響應或者響應的報文不出去。
   那麼這個狀況全部的RealServer上不響應arp廣播請求，只有Director響應給路由則報文就必然被髮送給Director。
三、kernel paramter:
    arp_ignore
    arp_announce
    做用：限定咱們的Linux主機對arp廣播請求的響應級別，以及向外通告自已ip地址的通告級別的。

3、配置集羣服務

一、在Real Server1和Real Server2上作配置以下

# 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 
以上命令需填加到/etc/rc.local文件中讓其開機自動生效 
# vim /etc/sysconfig/network-scripts/ifcfg-lo:0 內容以下 
DEVICE=lo:0 
IPADDR=10.19.166.88
NETMASK=255.255.255.255 
BROADCAST=10.19.166.88
ONBOOT=yes 
NAME=loopback 
  
# ifdown lo:0
# ifup lo:0
# route add -host 10.19.166.88 dev lo:0
# echo "route add -host 10.19.166.88 dev lo:0" >> /etc/rc.local

二、在Director Server上作如下配置

# vim /etc/sysconfig/network-scripts/ifcfg-eth2:0  內容以下  
DEVICE=eth2:0  
IPADDR=10.19.166.88  
NETMASK=255.255.255.255  
BROADCAST=10.19.166.88  
ONBOOT=yes  
# ifdown eth2:0 
# ifup eth2:20
# route add -host 10.19.166.88 dev eth2:0 
# echo "route add -host 10.19.166.88 dev eth2:0" >> /etc/rc.local 
# echo "1" > /proc/sys/net/ipv4/ip_forward 
# echo "echo "1" > /proc/sys/net/ipv4/ip_forward" >> /etc/rc.local 
# ipvsadm -A -t 10.19.166.88:80 -s wlc
# ipvsadm -a -t 10.19.166.88:80 -r 10.19.166.119 -g -w 2
# ipvsadm -a -t 10.19.166.88 -r 10.19.166.84 -g -w 1