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

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

廢話不多，先上實現(xiàn)架構(gòu)圖：

如上圖，利用lvs的dr轉(zhuǎn)發(fā)模式把外部請求分發(fā)到多個haproxy，然后由haproxy提供四、七層負(fù)載均衡服務(wù)。借助這種方式我們就能橫向擴(kuò)展haproxy集群了，整個集群的能力最終由LVS決定，由于lvs特殊的流量轉(zhuǎn)發(fā)的處理方式，所以其性能我們完全沒必要擔(dān)心（后面會有解釋）。

【01 LVS】

Linux Virtual Server是一個由章文嵩博士發(fā)起的一個開源項目，它的官方網(wǎng)站是 http://www.linuxvirtualserver.org現(xiàn)在 LVS 已經(jīng)是 Linux 內(nèi)核標(biāo)準(zhǔn)的一部分。LVS能提供高性能的四層負(fù)載均衡功能。

LVS有三種轉(zhuǎn)發(fā)方式：DR、NAT、TUN，其中DR模式下LVS僅處理二層包頭，LVS僅作為訪問入口，不作為網(wǎng)關(guān)，且后端返回流量不需要進(jìn)過LVS，因此，LVS對于大流量的轉(zhuǎn)發(fā)有很高的處理性能。這次我們借助LVS的DR轉(zhuǎn)發(fā)模式提供高速轉(zhuǎn)發(fā)功能，在結(jié)合haproxy豐富的4、7層功能，來達(dá)到我們的需求。

【02 Keepalived】

Keepalived顧名思義keepalilved是實現(xiàn)多機(jī)熱備的軟件，LVS作為負(fù)載均衡集群的訪問入口，自然要考慮到單點故障的問題，keepaived+lvs的模式是目前業(yè)內(nèi)的首選解決方案，當(dāng)前端接收請求的lvs虛機(jī)出現(xiàn)健康問題時，keepalived會迅速轉(zhuǎn)移VIP到健康的LVS虛機(jī)上，保證整個業(yè)務(wù)不間斷。

另外Keepalived不僅能監(jiān)控前端lvs的健康狀況，還能監(jiān)控后端haproxy集群每臺haproxy虛機(jī)的健康狀況，實時剔除不健康的虛機(jī)，并發(fā)出報警。

【03 VIP】

整個集群對外的IP，VIP分布在haproxy集群的每臺機(jī)器及LVS虛機(jī)上（只能有一臺LVS虛機(jī)擁有VIP），LVS上的VIP作為請求的目的IP，haproxy上的VIP作為應(yīng)答的原IP。配置VIP有很多注意事項，我后面會給出一些配置鏈接作為參考。

【04 RIP】

haproxy虛機(jī)的真實IP，用于haproxy集群內(nèi)部通訊，接收lvs分發(fā)過來的流量，及管理虛機(jī)的IP。

【05 Haproxy】

這個就不做介紹了，凡是在openstack上搗鼓負(fù)載均衡的小伙伴們對它應(yīng)該有了深入的了解了。

參考鏈接：

LVS相關(guān)：

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相關(guān)：

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

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

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

更詳細(xì)的資料，小伙伴們就需要自己在網(wǎng)上找了，自己動手試著搭建一套，能對上面架構(gòu)有更深刻的理解。

注意！！！（在小伙伴們迫不及待想驗證這個架構(gòu)時一定要先閱讀這兒）

參考鏈接的配置是在正常物理機(jī)上的配置，但在openstack環(huán)境中，有以下幾點需要注意：

1、 openstack默認(rèn)開啟了防arp欺騙（這個會過濾掉源IP和目的IP為VIP的數(shù)據(jù)包），且在ovs流表和iptables規(guī)則中均有防arp欺騙的規(guī)則，在配置文件中關(guān)閉防arp欺騙，也只是去掉了ovs流表的規(guī)則，iptables中的規(guī)則依然存在。正確的解決方案是在配置集群之前要為每個haproxy虛擬機(jī)的port添加allowed_address_pairs。添加方法：neutron port-update--allowed-address-pair ip_address=VIP

2、 openstack會利用iptables規(guī)則檢查非法的tcp連接（即：請求和應(yīng)答不在同一端口上的連接（有沒有一種它就是故意針對lvs dr轉(zhuǎn)發(fā)模式的感覺）），這里解決方案給出兩種：

2.1如果僅是在驗證階段，改變下面三個內(nèi)核參數(shù)：

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

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

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

2.2如果小伙伴覺得方案可行，想要實現(xiàn)代碼時：

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

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

3、由于VIP是我們手動設(shè)置上的，在neutron數(shù)據(jù)庫中沒有記錄，neutron為后續(xù)虛擬機(jī)分配IP時可能會重復(fù)，因此我們要先創(chuàng)建一個port占用VIP，創(chuàng)建方法：

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

最后給出實現(xiàn)該方案的編碼建議：

依然利用octavia的架構(gòu)，octavia-api不變。添加octavia.amphora.drivers、octavia.compute.drivers和octavia.network.drivers，可根據(jù)用戶創(chuàng)建負(fù)載均衡時選擇的最大連接數(shù)決定啟動多少haproxy虛機(jī)。

另，還可實現(xiàn)octavia的多provider，如果用戶要求并發(fā)數(shù)不多，后端可用namespace，如果用戶要求稍大并發(fā)可用octavia的默認(rèn)方法用單個虛擬機(jī)haproxy實現(xiàn)，如果要求大并發(fā)就用lvs+haproxy的方式實。

轉(zhuǎn)載于:https://www.cnblogs.com/xiaohanlin/p/8570275.html

總結(jié)

以上是生活随笔為你收集整理的基于openstack搭建百万级并发负载均衡器的解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。