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

最近，喜歡研究一些國外技術大咖們的文章，而這篇文章是基于openstack負載均衡器的解決方案，做的一些總結~希望能夠給小伙伴帶來一些靈感或者幫助。

openstack現有的負載均衡解決方案，無論是lbaas plugin還是octavia，后端都是基于haproxy的，由于haproxy本身的限制，其單任務最高并發不會超過5萬，經本人親測，利用octavia，在openstack云主機上運行haproxy最高達到過3萬并發，所有如果要想達到更高基本的并發，就需要重新設計負載均衡的架構了。

廢話不多，先上實現架構圖：

如上圖，利用lvs的dr轉發模式把外部請求分發到多個haproxy，然后由haproxy提供四、七層負載均衡服務。借助這種方式我們就能橫向擴展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豐富的4、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環境中，有以下幾點需要注意：

1、 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

2、 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功能有任何影響）

3、由于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的方式實。