負載均衡集群實現方法：
1、硬件方式
F5,CITRX,NETSCALER,A10（價格逐漸降低，由于為了防止調度器成為單點故障，所以要配置一臺備用設備，所以造價更高了）
2、軟件方式
四層：LVS（根據請求的ip和端口來分發），性能好，但對高級特性支持不好。
七層（反向代理）：Nginx（http,smtp,pop3,imap），Haproxy（主要是http，tcp（mysql，smtp）），能夠精確解碼請求的協議，并能做適當修改后向后轉發，操作能力強，性能略差于LVS,更適應生產環境。
LVS:Linux virtual server
lvs工作于內核的tcp/ip協議棧的input鏈，不能和iptables同時工作。當調度器上定義一個集群服務后才會向后進行轉發，當請求報文經過prerouting到達input時，經過input上定義的集群策略審查，若是集群服務則請求報文會被送至forward并通過postrouting向后轉發。
Lvs也是兩段式：ipvsadm（用戶空間）和ipvs（內核的input）
內核2.4.23之前并沒有ipvs代碼，所以需要打補丁。
相關術語：
Lvs的類型：
1、Nat模型
2、DR模型
3、TUN模型
Nat模型：工作機制和DNAT一樣
當客戶端請求報文到達調度器時ip報文首部是CIP|VIP,從prerouting送至input發現為集群服務后，將報文轉發至forward經postrouting向后轉發，此時ip首部變為CIP|RIP1，后端realserver發現是目標地址是自己后進行拆解報文、響應報文、封裝報文，此時ip首部為RIP1|CIP,然后經過調度器的源地址轉換，ip首部變為VIP|CIP，通過路由設備回應給客戶端。
NAT模型遵循的法則：
1、集群節點和調度器必須在一個網絡中
2、RIP地址為私有地址，僅用于集群節點間的通信
3、調度器位于客戶端和realserver之間，復制處理進出的所有通信
4、realserver網關必須指向DIP
5、調度器支持端口映射
6、realserver可以支持使用任何操作系統
較大規模場景中，調度器容易成為瓶頸，理想狀況下后端能帶10臺主機。生產環境一般不用這種模型。
DR模型：（常用）
調度器和realserver都連接在交換機上，并且調度器和RS都配置了VIP，只是RS的VIP被隱藏起來了，不用做通信，只是在響應時修改源地址而已。調度器的VIP配置在網卡上，而DIP配置在網卡別名上，RS的RIP配置在網卡上，VIP配置在網卡別名上。因為在一個網絡中，所以調度器和RS的mac地址會通過arp解析得到其他人的mac地址。當請求報文發送至集群網絡時ip報文首部為CIP|VIP，這時因為RS的VIP被隱藏起來了，所以只有調度器響應，而位于input鏈的策略發現是集群服務時，它不會拆解ip首部，而是把mac首部拆了，封裝mac（源mac改為調度器的mac，目標mac改為調度器挑選的RS的mac），并向RS轉發，報文傳至RS時，RS發現目標地址是自己，然后進行響應，封裝報文，源地址修改為VIP，目標地址為CIP，然后直接通過路由設備將報文發給客戶端。
DR模型遵循的法則：
1、集群節點必須和調度器在同一物理網絡中
2、RIP不用為私有地址了，實現了便捷的遠程管理和監控
3、調度器只負責進站請求，響應保衛有RS直接發往客戶端
4、集群節點不能將網關指向DIP
5、調度器不支持端口映射
6、大多數操作系統能支持RS，因為RS要求隱藏VIP
TUN模型：為了實現異地災備（不常用）
工作機制和DR模型近似。RS有兩個IP：RIP、VIP(隱藏的)，且RIP是公網地址，RS和調度器不再同一網絡，RS可直接將響應報文發送給客戶端。調度器也有兩個ip：VIP、DIP（別名）。當請求報文發送到調度器時，ip報文首部為CIP|VIP,調度器發現是集群服務想外轉發時在CIP|VIP前面封裝一層首部DIP|RIP,RS接受報文并且拆分外面的首部后發現目標地址的確為自己，便開始響應并直接經過路由設備回傳給客戶端，不需要經過調度器。這種模型需要調度器和RS支持隧道機制。
TUN模型遵循的法則：
1、各集群節點可跨越互聯網
2、RIP必須為公網地址
3、調度器僅處理入站請求，響應報文則由RS直接發往客戶端
4、RS網關不能指向調度器
5、只有支持隧道功能的os才能用于RS
6、不支持端口映射
原創文章，作者：黑白子，如若轉載，請注明出處：http://www.www58058.com/9482
