1.DR模式的原理

其實就是在一臺主機上面搭建lvs服務器，設置lvs的工作模式是DR模式，lvs僅僅是一個調度器，它會把客戶端的請求轉發給后備服務器
DR模式直接由后備服務器把數據返回給客戶端，不需要逆向發送數據包，此時lvs專注做調度就可，效率很高
此時lvs調度器叫做DS調度器(director server)，RS是真正的后端web服務器(real server)
Client發送請求 --> DS(調度器) -->prerouting --> INPUT -->postrouting -->RS（真正的服務器）–>lo回環接口 --> 網卡eth0 -->Client
整個過程的數據流向如下
用戶（client）發送請求給調度器(DS)，DS調度器先把請求發往prerouting鏈（內核空間kernal space），確定請求的是不是VIP
到了INPUT鏈之后，如果請求的是集群服務，會在這里修改MAC地址，把源MAC地址改為DS的MAC地址
把目的MAC地址改為RS的MAC地址，此時IP仍然不變，處理完成后把請求發往postrouting鏈
檢測請求的是否為RS（會檢測請求的MAC地址），如果是，接受請求，把請求通過回環接口發給出口的網卡，再發回給客戶端
數據在系統內的交流用的是回環接口，與外部的交流用的是網卡eth0
DR模式高效的原因就是RS服務器會直接響應客戶端的請求，發送的請求一直往前發送數據包，不會再返回數據包給調度器
注意：這里的prerouting，input，postrouting都是iptables防火墻里面的鏈，如果不懂先回去復習iptables

2.DR模式中的名詞解釋

DS調度器，lvs的前端設備

RS	真正提供服務的后端服務器
RIP	后端服務器的ip地址
DIP	調度器和后端服務器通信的ip
源IP	CIP（客戶端的IP）
目的IP	VIP（設置的統一入口），對外公布的ip，客戶請求進來的ip
源MAC地址	DS調度器的MAC地址
目的MAC地址	RS真正服務器的MAC地址

3.DR模式的特點

所有的請求報文都是由調度器（DS）進行調度的
DR模式不支持端口映射
RS和DS必須在同一網絡，可以不在同一網段，使用交換機即可
MAC地址在第二層，數據鏈路層，還沒有到IP所在的網絡層
realserver的RIP和Director的DIP必須處于同一網段中，以便使用MAC地址進行通信
realserver上必須配置VIP地址，以便接收director轉發過來的數據包，以及作為響應報文的源IP
realserver響應給客戶端的數據包的源和目的IP為VIP—>CIP
director只處理入站請求，響應請求由realserver完成
七層調度（負載均衡），4層分攤流量
LVS（Linux Virtual Server）Linux虛擬服務器
附著在netfilter上，有5個內置的鉤子函數處理內置的請求，工作在4層模型上，會強行改變數據的流向
它不接受請求，只是一個調度器，把請求發給后端真正的服務器（RS）
LVS包括兩個東西：
（1）IPVS：工作在INPUT鏈，依附于5個內置鉤子函數，其實就是一段代碼，已經集成在LInux的源碼中
（2）IPVSADM：具體編寫策略的工具
DR模式改變的是MAC地址
DR模式可能會有人惡意連接，一直發送數據包給一臺后端服務器，不輪詢，導致后端服務器癱瘓，可以解決

4.搭建實驗環境

一共需要3臺rhel7.5版本的虛擬機

主機信息主機的功能（服務）

真機172.25.8.250	客戶端client
server1(172.25.8.1)	lvs調度器（DS）
server2(172.25.8.2)	后端的web服務器1（RS）
server3(172.25.8.3)	后端的web服務器2（RS）

在真機中開啟三臺虛擬機
1臺做lvs調度器，兩臺做后端輪詢的web服務器，用真機分別連接三臺虛擬機，真機本身是客戶端

5.實現lvs調度器的DR模式

注意：雖然lvs的調度算法很多，為了實驗效果明顯起見，我們使用輪詢算法
實驗步驟如下

• （1）在server1上面搭建lvs服務

yum search ipvsadm尋找這個服務（工具） yum install ipvsadm.x86_64 -y安裝服務 此時的虛擬機版本是7.5的，7.5版本的yum源的packages安裝包中有LoadBalancer負載均衡模塊，因此不再需要搭建負載均衡的yum源 如果是6.5版本的yum源，需要搭建負載均衡的yum源才可以安裝這個服務

• （2）ipvsadm -l列出策略（查看調度策略）
  
• （3）查看ipvsadm服務的基本信息

systemctl status ipvsadm.service可以看出這個服務的啟動腳本 vim /usr/lib/systemd/system/ipvsadm.service查看開啟這個服務的時候都干了一些什么

• （4）開啟服務

systemctl start ipvsadm.service開啟服務,錯誤

• （5）cat /var/log/messages在日志里面查看服務啟動錯誤的原因
  
  
• （6）排除錯誤

touch /etc/sysconfig/ipvsadm 建立編寫策略的文件 systemctl start ipvsadm.service開啟服務，正確 systemctl status ipvsadm.service再次查看服務的狀態

• （7）配置服務

vim /etc/sysconfig/ipvsadm-config 修改lvs服務的配置文件:no->yes,重啟服務的時候保存策略

• （8）設置DR模式的訪問策略

ipvsadm -A -t 172.25.12.100:80 -s rr 設置客戶端進入lvs調度器的入口地址，調度算法是輪詢 ipvsadm -a -t 172.25.12.100:80 -r 172.25.12.2:80 -g設置lvs的策略：入口的第一臺后端服務器的信息 ipvsadm -a -t 172.25.12.100:80 -r 172.25.12.3:80 -g設置lvs的策略：入口的第二臺后端服務器的信息 -s表示調度算法，rr表示輪詢，-g表示lvs調度器工作在DR模式

cat /etc/sysconfig/ipvsadm 查看策略文件，發現沒有策略 systemctl restart ipvsadm.service重啟服務的時候保存策略 cat /etc/sysconfig/ipvsadm 查看策略文件，發現有策略

• （9）設置兩臺后端服務器（server2和server3）的apache服務，也就是web服務

yum install httpd -y安裝httpd vim /var/www/html/index.html編寫共享頁面 systemctl restart httpd重啟

• （11）在lvs服務器上面查看剛才設置的調度策略（DR模式的輪詢）

ipvsadm -l做解析，慢 ipvsadm -nl不做解析，快

• （12）測試前的準備工作
  在真機里面測試，先做解析
  

在lvs(server1)上面設置用戶訪問的入口地址:ip addr add 172.25.8.100/24 dev eth0 ip a查看

在后端服務器1(server2)上面設置用戶訪問的入口地址:ip addr add 172.25.8.100/24 dev eth0 ip a查看

在后端服務器2(server3)上面設置用戶訪問的入口地址:ip addr add 172.25.8.100/24 dev eth0 ip a查看

注意：在兩個web服務器上設置用戶訪問的入口地址是為了web服務器可以直接給客戶端發送資源，不需要再返回給調度器
因為客戶端訪問的是入口地址，如果不適用入口地址給客戶發送資源，客戶可能不會接收這個數據包
如果直接在客戶端curl 172.25.8.100發現客戶端要不到資源
因為DR工作模式是：client->vs->rs->client，由后備服務器端直接送回資源給客戶端
但是客戶端問172.25.8.100要的資源，后端服務器直接把資源給客戶端，客戶端不會識別
因此要在兩個后端服務器上面設置入口地址

• （13）在真機上面測試
  第一次
  
  第二次
  
  第三次

注意：此時客戶端訪問資源有時候輪詢，有時候不輪詢，出現這樣的現象是為什么呢？
造成這種情況的原因是因為DR模式是通過修改MAC地址進行訪問的，調度器和兩臺web服務器上都有172.25.8.100這個入口地址ip
所以客戶端在請求的時候，三臺虛擬機都有可能回復請求，客戶端會記錄回復他的那臺虛擬機的mac地址
所以下次在訪問的時候他會找記錄過的mac地址對應的虛擬機（有可能是真實的服務器）直接訪問
這在現實中是不允許的，因為如果請求全部發往后端某一臺真正的服務器的話，這臺服務器會因為壓力過大而宕機
而且，直接訪問后端的真正的服務器，我們的server1（LVS調度器）也就沒有起到作用
并沒有實現真正意義上的負載均衡，這也是DR模式的一個缺點
這就類似于DDOS攻擊，有可能會導致后端服務器癱瘓，造成用戶不能正常訪問資源

• （14）在客戶端查看它訪問的入口地址的主機的MAC地址是多少
  
  
• （15）在客戶端刪除剛才記錄的MAC地址，再次訪問
  
  

6.現在解決DR模式不輪詢的問題，因為DR模式使用的是MAC地址

會造成DDOS攻擊，導致后端服務器癱瘓
因為客戶端第一次訪問172.25.8.100的時候server1,server2,server3均可以接收客戶端的請求，這個是隨機的
有可能不會經過lvs調度器，客戶端直接問web服務器要資源
在兩個web后端上進行設置，防止ddos攻擊
在server2（第一個后端服務器）上進行設置

• （1）yum install -y arptables_jf安裝針對MAC地址的防火墻管理工具
  
• （2）arptables -nL查看設置的訪問規則，沒有，因為還沒有進行設置
  
• （3）man arptable可以查看設置規則
  
  
• （4）設置規則

arptables -A INPUT -d 172.25.8.100 -j DROP丟棄客戶端的直接訪問 arptables -A OUTPUT -s 172.25.8.100 -j mangle --mangle-ip-s 172.25.8.2使自己以172.25.8.100的身份發送資源給客戶端 cat /etc/sysconfig/arptables查看規則 arptables-save > /etc/sysconfig/arptables保存策略 cat /etc/sysconfig/arptables再次查看 systemctl start arptables.service重啟服務 systemctl status arptables.service

在兩個web服務器上面進行同樣的操作，server3（后端服務器）同理




在真機上面進行測試
此時做完這個：就可以實現調度了
web2和web3就不會接受客戶端的請求了，每次客戶端的訪問只能由調度器接受
只有調度器才會接收這個請求，因此也就是通過lvs調度器的mac地址，因此可以實現正常訪問
通過調度器訪問時，因為調度器里面設置了調度規則，因此可以實現正常訪問

清除緩存，發現輪詢了

再次清除緩存，發現輪詢了

可以看到客戶端此時訪問的MAC地址是lvs調度器的MAC地址

7.lvs調度器工作在DR模式的總結（個人理解以及總結）

因為lvs、web1、web2均有172.25.8.100這個ip地址
當客戶端第一次找lvs調度器這個入口地址的時候
他可能直接找到web1或者web2，因此就不能實現調度了
現在在web1和web2上面進行設置拒絕客戶端請求172.25.8.100這個ip
因此只有lvs調度器入口地址才會接受客戶端的請求
因此客戶端訪問就是一直是使用調度器的MAC地址
每次客戶端只能通過lvs調度器去找web1和web2服務
這樣就實現了調度，輪詢工作
當客戶端發送數據包給172.25.8.100（lvs）的時候（源地址172.25.8.250–》目的地址172.25.8.100）
此時lvs會將源mac地址變為lvs服務器的mac地址，將目的mac地址變為web服務器的mac地址，然后就實現調度了
直接去找目標mac地址，然后找web服務器，web服務器直接將數據返回給客戶端（IP地址全程不變）
DR模式的特點

不支持端口影射 RS和DS必須在同一網絡（不是同一網段） DR工作在數據鏈路層使用的是MAC地址，還沒有牽扯到IP地址 IP地址始終不變，變的是MAC地址 lo是回環接口（和自己進行交流的時候用，使用起來快），系統里服務和服務之間使用的回環接口，效率高，快 etho是網卡（和外界進行交流的時候用）

總結

以上是生活随笔為你收集整理的企业级负载均衡集群——lvs的DR模式（直接路由模式）详细说明的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。