文章目錄
二、三種工作模式
2.1 LVS/NAT模式
NAT
2.1.1 工作流程
1 ) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP
2 ) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
3 ) IPVS比對數據包請求的服務是否爲集羣服務，若是，修改數據包的目標IP地址爲後端服務器IP，然後將數據包發至POSTROUTING鏈。 此時報文的源IP爲CIP，目標IP爲RIP
4 ) POSTROUTING鏈通過選路，將數據包發送給Real Server
5 ) Real Server比對發現目標爲自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP爲RIP，目標IP爲CIP
6 ) Director Server在響應客戶端前，此時會將源IP地址修改爲自己的VIP地址，然後響應給客戶端。 此時報文的源IP爲VIP，目標IP爲CIP
2.1.2 特性
1 ) RS應該使用私有地址，RS的網關必須指向DIP
2 )DIP和RIP必須在同一個網段內
3 ) 請求和響應報文都需要經過Director Server，高負載場景中，Director Server易成爲性能瓶頸
4 ) 支持端口映射
5 ) RS可以使用任意操作系統
缺陷：對Director Server壓力會比較大，請求和響應都需經過director server
2.2 LVS/DR模式
DR
2.2.1 工作流程
1 ) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP
2 ) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
3 ) IPVS比對數據包請求的服務是否爲集羣服務，若是，將請求報文中的源MAC地址修改爲DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址爲DIP的MAC地址，目標MAC地址爲RIP的MAC地址
4 ) 由於DS和RS在同一個網絡中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址爲RIP的MAC地址，那麼此時數據包將會發至Real Server。
5 ) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之後，將響應報文通過lo接口傳送給eth0網卡然後向外發出。 此時的源IP地址爲VIP，目標IP爲CIP
6 ) 響應報文最終送達至客戶端
2.2.2 特性
1 ）保證前端路由將目標地址爲VIP報文統統發給Director Server，而不是RS
解決方案
1.在前端路由器做靜態地址路由綁定，將對於VIP的地址僅路由到Director Server
2.在arp的層次上實現在ARP解析時做防火牆規則，過濾RS響應ARP請求。這是由iptables提供的
3.修改RS上內核參數（arp_ignore和arp_announce）將RS上的VIP配置在lo接口的別名上，並限制其不能響應對VIP地址解析請求。
- arp_ignore
定義對目標地址爲本地IP的ARP詢問不同的應答模式 - 原版說明
arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied
4-7 - reserved
8 - do not reply for all local addresses
The max value from conf/{all,interface}/arp_ignore is used
when ARP request is received on the {interface}
參數說明
0 - (默認值): 迴應任何網絡接口上對任何本地IP地址的arp查詢請求
1 - 只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求
2 - 只回答目標IP地址是來訪網絡接口本地地址的ARP查詢請求,且來訪IP必須在該網絡接口的子網段內
3 - 不迴應該網絡界面的arp請求，而只對設置的唯一和連接地址做出迴應
4-7 - 保留未使用
8 - 不迴應所有（本地地址）的arp查詢
- arp_announce
對網絡接口上，本地IP地址的發出的，ARP迴應，作出相應級別的限制: 確定不同程度的限制,宣佈對來自本地源IP地址發出Arp請求的接口 - 原版說明
arp_announce - INTEGER
Define different restriction levels for announcing the local
source IP address from IP packets in ARP requests sent on
interface:
0 - (default) Use any local address, configured on any interface
1 - Try to avoid local addresses that are not in the target's
subnet for this interface. This mode is useful when target
hosts reachable via this interface require the source IP
address in ARP requests to be part of their logical network
configured on the receiving interface. When we generate the
request we will check all our subnets that include the
target IP and will preserve the source address if it is from
such subnet. If there is no such subnet we select source
address according to the rules for level 2.
2 - Always use the best local address for this target.
In this mode we ignore the source address in the IP packet
and try to select local address that we prefer for talks with
the target host. Such local address is selected by looking
for primary IP addresses on all our subnets on the outgoing
interface that include the target IP address. If no suitable
local address is found we select the first local address
we have on the outgoing interface or on all other interfaces,
with the hope we will receive reply for our request and
even sometimes no matter the source IP address we announce.
The max value from conf/{all,interface}/arp_announce is used.
Increasing the restriction level gives more chance for
receiving answer from the resolved target while decreasing
the level announces more valid sender's information.
參數說明
0 - (默認) 在任意網絡接口（eth0,eth1，lo）上的任何本地地址
1 - 儘量避免不在該網絡接口子網段的本地地址做出arp迴應. 當發起ARP請求的源IP地址是被設置應該經由路由達到此網絡接口的時候很有用.此時會檢查來訪IP是否爲所有接口上的子網段內ip之一.如果改來訪IP不屬於各個網絡接口上的子網段內,那麼將採用級別2的方式來進行處理.
2 - 對查詢目標使用最適當的本地地址.在此模式下將忽略這個IP數據包的源地址並嘗試選擇與能與該地址通信的本地地址.首要是選擇所有的網絡接口的子網中外出訪問子網中包含該目標IP地址的本地地址. 如果沒有合適的地址被發現,將選擇當前的發送網絡接口或其他的有可能接受到該ARP迴應的網絡接口來進行發送.
2 ) RS可以使用私有地址；也可以是公網地址，如果使用公網地址，此時可以通過互聯網對RIP進行直接訪問
3 ) RS跟Director Server必須在同一個物理網絡中
4 ) 所有的請求報文經由Director Server，但響應報文必須不能進過Director Server
5 ) 不支持地址轉換，也不支持端口映射
6 ) RS可以是大多數常見的操作系統
7 ) RS的網關絕不允許指向DIP(因爲我們不允許他經過director)
8 ) RS上的lo接口配置VIP的IP地址
不足：LVS-RS間必須在同一個VLAN；RS上綁定VIP，風險大；
2.3 LVS/TUNNEL模式(常用)
tunnel
2.3.1 工作流程
1.當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP 。
2.PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
3.IPVS比對數據包請求的服務是否爲集羣服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP爲爲DIP，目標IP爲RIP。然後發至POSTROUTING鏈。 此時源IP爲DIP，目標IP爲RIP
4.POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因爲在外層封裝多了一層IP首部，所以可以理解爲此時通過隧道傳輸）。 此時源IP爲DIP，目標IP爲RIP
5.RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裏面還有一層IP首部，而且目標是自己的lo接口VIP，那麼此時RS開始處理此請求，處理完成之後，通過lo接口送給eth0網卡，然後向外傳遞。 此時的源IP地址爲VIP，目標IP爲CIP
6.響應報文最終送達至客戶端
2.3.2 特性
RIP、VIP、DIP全是公網地址
RS的網關不會也不可能指向DIP
所有的請求報文經由Director Server，但響應報文必須不能經過Director Server
不支持端口映射
RS的系統必須支持隧道
不足：RS配置複雜（IPIP模塊等）；RS上綁定VIP，風險大；
2.4 存在的問題
（一）UDP 服務狀態檢查問題
在不配置服務狀態檢查(MONITORING SCRIPTS)腳本時，LVS 對 TCP 服務採用發送 SYNC 包來確認服務端口是否正常，但對於無連接狀態的 UDP 服務就無法這麼做，因此針對 UDP 服務需要編寫專門的業務測試腳本來監控應用狀態，否則將失去業務故障自動切換功能。
處理方式：編寫專用業務應用測試腳本來實現 UDP 服務狀態檢查的功能。
（二）DR 模式下 UDP 服務問題
在 DR 模式下，由於 UDP 是無連接狀態的，當 RS 迴應結果時默認採用原先的地址，Client 在轉發數據包時，源地址不是原先請求的 IP（VS IP），所以會存在問題。
處理方式：RS 程序在提供相應的 UDP 服務時強制綁定 VS IP（默認是綁定0.0.0.0/*）。
（三）DR 模式下 RS ARP 處理問題
這個問題在 RedHat 的手冊中是按照 arptables 來處理，按手冊的說明配置，在實際測試中還是存在不穩定的問題。使用修改 linux 內核參數的方式來處理，同樣存在問題。這個問題估計是 LVS 軟件包的 bug，預計新版本會解決該問題。
處理方式：儘量使用 NAT 模式。
2.5 FULLNAT
2.6 IPVS優化
– 多隊列網卡，1個隊列綁定到1個cpu核上
– 增大session hash table
– 增大session hash bucket lock個數
– 避免路由cache條目過多
– LOCKLESS
– 硬件：Westmere(第二代nehalem)/bios配置