基於openstack搭建百萬級併發負載均衡器的解決方案

最近，喜歡研究一些國外技術大咖們的文章，而這篇文章是基於openstack負載均衡器的解決方案，作的一些總結~但願可以給小夥伴帶來一些靈感或者幫助。

openstack現有的負載均衡解決方案，不管是lbaas plugin仍是octavia，後端都是基於haproxy的，因爲haproxy自己的限制，其單任務最高併發不會超過5萬，經本人親測，利用octavia，在openstack雲主機上運行haproxy最高達到過3萬併發，全部若是要想達到更高基本的併發，就須要從新設計負載均衡的架構了。

廢話很少，先上實現架構圖：

如上圖，利用lvs的dr轉發模式把外部請求分發到多個haproxy，而後由haproxy提供4、七層負載均衡服務。藉助這種方式咱們就能橫向擴展haproxy集羣了，整個集羣的能力最終由LVS決定，因爲lvs特殊的流量轉發的處理方式，因此其性能咱們徹底不必擔憂（後面會有解釋）。

【01 LVS】

Linux Virtual Server是一個由章文嵩博士發起的一個開源項目，它的官方網站是 http://www.linuxvirtualserver.org如今 LVS 已是 Linux 內核標準的一部分。LVS能提供高性能的四層負載均衡功能。

LVS有三種轉發方式：DR、NAT、TUN，其中DR模式下LVS僅處理二層包頭，LVS僅做爲訪問入口，不做爲網關，且後端返回流量不須要進過LVS，所以，LVS對於大流量的轉發有很高的處理性能。此次咱們藉助LVS的DR轉發模式提供高速轉發功能，在結合haproxy豐富的四、7層功能，來達到咱們的需求。

【02 Keepalived】

Keepalived顧名思義keepalilved是實現多機熱備的軟件，LVS做爲負載均衡集羣的訪問入口，天然要考慮到單點故障的問題，keepaived+lvs的模式是目前業內的首選解決方案，當前端接收請求的lvs虛機出現健康問題時，keepalived會迅速轉移VIP到健康的LVS虛機上，保證整個業務不間斷。

另外Keepalived不只能監控前端lvs的健康情況，還能監控後端haproxy集羣每臺haproxy虛機的健康情況，實時剔除不健康的虛機，併發出報警。

【03 VIP】

整個集羣對外的IP，VIP分佈在haproxy集羣的每臺機器及LVS虛機上（只能有一臺LVS虛機擁有VIP），LVS上的VIP做爲請求的目的IP，haproxy上的VIP做爲應答的原IP。配置VIP有不少注意事項，我後面會給出一些配置連接做爲參考。

【04 RIP】

haproxy虛機的真實IP，用於haproxy集羣內部通信，接收lvs分發過來的流量，及管理虛機的IP。

【05 Haproxy】

這個就不作介紹了，凡是在openstack上搗鼓負載均衡的小夥伴們對它應該有了深刻的瞭解了。

參考連接：

LVS相關：

http://www.cnblogs.com/liwei0526vip/p/6370103.html

http://www.cnblogs.com/czh-liyu/archive/2011/11/29/2267963.html

http://www.cnblogs.com/danbo/p/4609202.html

keepalived相關：

http://freeloda.blog.51cto.com/2033581/1280962

http://www.cnblogs.com/edisonchou/p/4281978.html

http://blog.csdn.net/xyang81/article/details/52554398

更詳細的資料，小夥伴們就須要本身在網上找了，本身動手試着搭建一套，能對上面架構有更深入的理解。

注意！！！（在小夥伴們火燒眉毛想驗證這個架構時必定要先閱讀這兒）

參考連接的配置是在正常物理機上的配置，但在openstack環境中，有如下幾點須要注意：

一、 openstack默認開啓了防arp欺騙（這個會過濾掉源IP和目的IP爲VIP的數據包），且在ovs流表和iptables規則中均有防arp欺騙的規則，在配置文件中關閉防arp欺騙，也只是去掉了ovs流表的規則，iptables中的規則依然存在。正確的解決方案是在配置集羣以前要爲每一個haproxy虛擬機的port添加allowed_address_pairs。添加方法：neutron port-update--allowed-address-pair ip_address=VIP

二、 openstack會利用iptables規則檢查非法的tcp鏈接（即：請求和應答不在同一端口上的鏈接（有沒有一種它就是故意針對lvs dr轉發模式的感受）），這裏解決方案給出兩種：

2.1若是僅是在驗證階段，改變下面三個內核參數：

net.bridge.bridge-nf-call-ip6tables = 0

net.bridge.bridge-nf-call-iptables = 0

net.bridge.bridge-nf-call-arptables = 0

2.2若是小夥伴以爲方案可行，想要實現代碼時：

修改neutron代碼：neutron/agent/linux/iptables_firewall.py，

須要註釋掉625行（僅此一行，小夥伴們大可放心，不會對neutron功能有任何影響）

三、因爲VIP是咱們手動設置上的，在neutron數據庫中沒有記錄，neutron爲後續虛擬機分配IP時可能會重複，所以咱們要先建立一個port佔用VIP，建立方法：

neutron port-create--fixed-ip ip_address=VIP

最後給出實現該方案的編碼建議：

依然利用octavia的架構，octavia-api不變。添加octavia.amphora.drivers、octavia.compute.drivers和octavia.network.drivers，可根據用戶建立負載均衡時選擇的最大鏈接數決定啓動多少haproxy虛機。

另，還可實現octavia的多provider，若是用戶要求併發數很少，後端可用namespace，若是用戶要求稍大併發可用octavia的默認方法用單個虛擬機haproxy實現，若是要求大併發就用lvs+haproxy的方式實。