NAT模型
NAT模型其實就是通過網絡地址轉換來實現負載均衡的,它的工作方式幾乎跟iptables 中的DNAT一模一樣的,NAT模型的工作方式:
1.用戶請求VIP(也就是是CIP請求VIP)
2,Director Server 收到用戶的請求後,發現源地址爲CIP請求的目標地址爲VIP，那麼Dorector Server會認爲用戶請求的是一個集羣服務，那麼Director Server 會根據此前設定好的調度算法將用戶請求負載給某臺Real Server ,假如說此時Director Server 根據調度算法的結果會將請求分攤到Real Server 2上去,那麼Director Server 會將用戶的請求報文中的目標地址,從原來的VIP改爲Real Server 2的IP,然後再轉發給Real Server 2
3,此時Real Server 1收到一個源地址爲CIP目標地址爲自己的請求,那麼Real Server 1處理好請求後會將一個源地址爲自己目標地址爲CIP的數據包通過Director Server 發出去,
4.當Driector Server收到一個源地址爲Real Server 1 的IP 目標地址爲CIP的數據包,此時Driector Server 會將源地址修改爲VIP,然後再將數據包發送給用戶,
DR模型：
1.director必須與realserver位於同一個網絡。
2.director只負責處理入站請求。而響應報文則由realserver直接返回給client端。大大節省director的資源。
3.不能做端口映射
整個工作原理如下：
客戶端通過路由器將請求交給director的VIP。director接收請求，將通過相應的算法將請求轉發給相應的realserver。在轉發的過程中，會修改請求包的目的mac地址，目的ip地址不變。realserver接收請求，並直接響應客戶端。這時，便出現一個問題：director此時與realserver位於同一個網絡中，當director直接將請求轉發給realserver時，realserver檢測到該請求包的目的ip是vip而並非自己，便會丟棄，而不會響應。。爲了解決這個問題，我們需要在所有realserver上都配上VIP。這時會出現第二個問題：director與realserver位於同一個網絡中，當出現多個vip時，通過arp廣播，整個網絡必然混亂，我們無法保證客戶端的請求一定會發往director。爲保證當客戶端請求抵達網絡時，只有director來響應請求。我們需要realserver忽略對vip的arp請求，並且在arp通告時，不通告vip地址。我們需要配置如下兩個內核參數：
arp_ignore ：當一臺主機某個接口接收到arp請求時，這臺機上的ip地址是否通過該接口響應給對應請求的限制級別。簡單來說，當這臺主機有多塊網卡，或者有多個ip地址時，是否通過該接口將所有ip地址響應給對應的請求。
0:不作任何限制。將所有本機的ip地址都響應給對應請求。
1:當請求的ip就配置在本接口上時，才予以響應。換句話說，就是隻響應當前接口的ip地址。
arp_announce：當一臺主機加入到一個新的網絡。會發出ARP通告，向網絡中其他主機通告自己的ip地址及mac等信息。arp_anounce就用來限制通告的級別。當這臺主機有多塊網卡或者多個ip地址時，是否通過某一個接口將所有ip地址通告給該網絡中的主機。
0:不作任何限制。從任意接口通告所有ip地址。
1:儘可能避免通告非本接口上的ip。
2:只通知本接口的ip。非本接口的ip不予通告。
由此我們亦可知，在realserver上配置vip時顯然也不能配置的物理接口的虛接口上，而應該配置在loopback上。
1、當Director收到用戶的請求後根據預先設定的調度算法來確定將請求負載到某臺Real Server上去，假如說此時根據調度算法的結果，會將請求負載到Real Server 1上面去，此時Director會將數據幀中的目標MAC地址修改爲Real Server1的MAC地址，然後再將數據幀發送出去。
2、當Real Server1 收到一個源地址爲CIP目標地址爲VIP的數據包時，Real Server1發現目標地址爲VIP,而自己本地是有VIP的，於是接受數據包並給予處理,當Real Server1處理完請求後，會將一個源地址爲VIP目標地址爲CIP的數據包發出去，此時的響應請求就不會再經過Director Server了，而是直接響應給用戶。