基于OpenStack M版本各組件高可用方案探索是怎樣的,針對這個問題,這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),簡陽企業(yè)網(wǎng)站建設(shè),簡陽品牌網(wǎng)站建設(shè),網(wǎng)站定制,簡陽網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,簡陽網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力??沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿,時刻以成就客戶成長自我,堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
本測試主要是針對Openstack各個組件,探索實現(xiàn)高可用的部署架構(gòu),防止在某個物理節(jié)點down機(jī)之后造成云平臺服務(wù)以及虛擬機(jī)實例的不可用。
Openstack主要組件以及需要考慮實現(xiàn)HA的部分如下:
1:keystone認(rèn)證模塊
1) keystone-api
2:glance鏡像模塊
1) glance-api
2) glance-registry
3) glance backend storage
3:nova計算模塊
1) nova-api
2) nova-novncproxy
3) instance
4;cinder塊存儲模塊
1) cinder-api
2) cinder-volume
5:neutron網(wǎng)絡(luò)模塊
1) neutron-server
2) l3 router
6:swift對象存儲模塊
1) proxy-server
7:horizon前臺dashboard界面
8:后臺mariaDB數(shù)據(jù)庫
9:rabbitmq消息隊列中間件
10:memcache緩存系統(tǒng)
部署的物理主機(jī)信息如下:
節(jié)點名 | 登錄操作IP地址 | 內(nèi)部組件通信IP地址 | OS版本 | Openstack版本 |
controller | 10.45.5.155 | 192.168.159.128 | CentOS7.2 | mitaka |
compute | 10.45.6.196 | 192.168.159.129 | CentOS7.2 | mitaka |
compute1 | 10.45.6.191 | 192.168.159.130 | CentOS7.2 | mitaka |
所有主機(jī)均部署openstack所有的服務(wù)組件,方便進(jìn)行高可用部署。
1) keystone-api(httpd)
高可用實現(xiàn)方式:
pacemaker+corosync:通過pacemaker生成浮動地址,3個節(jié)點將keystone服務(wù)監(jiān)聽直接啟動在0.0.0.0,浮動地址在各個節(jié)點之間切換,同時只有一個節(jié)點提供服務(wù)。
haproxy:通過pacemaker生成浮動地址,3個節(jié)點將keystone服務(wù)監(jiān)聽直接啟動在各個節(jié)點的內(nèi)部通信ip上,再通過haproxy將監(jiān)聽啟動在浮動ip上,統(tǒng)一對外提供服務(wù),并對下面3個物理節(jié)點分發(fā)請求。
遺留問題:使用haproxy無法做到A-A負(fù)載均衡模式,會有token信息混亂的問題,所以在haproxy中只能配置一個active節(jié)點,其他節(jié)點為backup。
1) glance-api, glance-registry
高可用實現(xiàn)方式:
pacemaker+corosync:通過pacemaker生成浮動地址,3個節(jié)點將api和registry服務(wù)監(jiān)聽直接啟動在0.0.0.0,浮動地址在各個節(jié)點之間切換,同時只有一個節(jié)點提供服務(wù)。
haproxy:通過pacemaker生成浮動地址,3個節(jié)點將api和registry服務(wù)監(jiān)聽直接啟動在各個節(jié)點的內(nèi)部通信ip上,再通過haproxy將監(jiān)聽啟動在浮動ip上,統(tǒng)一對外提供服務(wù),并對下面3個物理節(jié)點分發(fā)請求實現(xiàn)A-A模式冗余。
2) glance后端存儲
高可用實現(xiàn)方式:
swift:后端通過連接swift對象存儲的浮動ip,依靠swift本身的高可用性,實現(xiàn)glance后端存儲的HA。
遺留問題:暫無
1) nova-api, nova-novncproxy
高可用實現(xiàn)方式:
pacemaker+corosync:通過pacemaker生成浮動地址,3個節(jié)點將api和vncproxy服務(wù)監(jiān)聽直接啟動在0.0.0.0,浮動地址在各個節(jié)點之間切換,同時只有一個節(jié)點提供服務(wù)。
haproxy:通過pacemaker生成浮動地址,3個節(jié)點將api和vncproxy服務(wù)監(jiān)聽直接啟動在各個節(jié)點的內(nèi)部通信ip上,通過haproxy將監(jiān)聽啟動在浮動ip上,統(tǒng)一對外提供服務(wù),并對下面3個物理節(jié)點分發(fā)請求,實現(xiàn)A-A模式冗余。
2) instance
高可用實現(xiàn)方式:
instance live migrate:通過live migrate功能實現(xiàn)實例在計算節(jié)點之間的在線遷移.(類似vSphere中的vmotion功能 )
instance evacuate:通過nova-evacuate組件實現(xiàn)在計算節(jié)點宕機(jī)的情況下,將instance從其他節(jié)點上重啟。
遺留問題:暫時沒有可靠的方法實現(xiàn)在主機(jī)故障的情況下自動觸發(fā)instance evacuate.(實現(xiàn)類似vSphere HA的功能)
1) cinder-api
高可用實現(xiàn)方式:
pacemaker+corosync:通過pacemaker生成浮動地址,3個節(jié)點將api服務(wù)監(jiān)聽直接啟動在0.0.0.0,浮動地址在各個節(jié)點之間切換,同時只有一個節(jié)點提供服務(wù)。
haproxy:通過pacemaker生成浮動地址,3個節(jié)點將api服務(wù)監(jiān)聽直接啟動在各個節(jié)點的內(nèi)部通信ip上,通過haproxy將監(jiān)聽啟動在浮動ip上,統(tǒng)一對外提供服務(wù),并對下面3個物理節(jié)點分發(fā),請求實現(xiàn)A-A模式冗余。
2) cinder-volume
高可用實現(xiàn)方式:
cinder migrate:通過在多個節(jié)點部署cinder-volume服務(wù),連接后端同一個磁陣。當(dāng)其中一個cinder-volume出現(xiàn)問題,如主機(jī)宕機(jī),存儲鏈路故障等,即可使用cinder migrate將volume host為宕機(jī)的cinder節(jié)點的volume的volume host更改為正常的host,即可重新訪問到存儲。
遺留問題:
1. 暫時沒有可靠的方案實現(xiàn)cinder-volume服務(wù)狀態(tài)的檢測以及自動切換,如無法監(jiān)控存儲鏈路故障。
2. 暫時無法配置volume跨backend的在線拷貝遷移(實現(xiàn)類似vSphere中Storage Vmotion的功能)
1) neutron-server
高可用實現(xiàn)方式:
pacemaker+corosync:通過pacemaker生成浮動地址,3個節(jié)點將neutron-server服務(wù)監(jiān)聽直接啟動在0.0.0.0,浮動地址在各個節(jié)點之間切換,同時只有一個節(jié)點提供服務(wù)。
haproxy:通過pacemaker生成浮動地址,3個節(jié)點將neutron-server服務(wù)監(jiān)聽直接啟動在各個節(jié)點的內(nèi)部通信ip上,通過haproxy將監(jiān)聽啟動在浮動ip上,統(tǒng)一對外提供服務(wù),并對下面3個物理節(jié)點分發(fā)請求, 實現(xiàn)A-A模式冗余。
2) l3 router
高可用實現(xiàn)方式:
keepalived+vrrp:待測試
遺留問題:
1. 如果要將我們當(dāng)前的vmware的組網(wǎng)方式照搬到openstack上,可能無法對號入座,需要一起討論一下。
1) proxy-server
高可用實現(xiàn)方式:
pacemaker+corosync:通過pacemaker生成浮動地址,3個節(jié)點將proxy-server服務(wù)監(jiān)聽直接啟動在0.0.0.0,浮動地址在各個節(jié)點之間切換,同時只有一個節(jié)點提供服務(wù)。
haproxy:通過pacemaker生成浮動地址,3個節(jié)點將keystone服務(wù)監(jiān)聽直接啟動在各個節(jié)點的內(nèi)部通信ip上,通過haproxy將監(jiān)聽啟動在浮動ip上,統(tǒng)一對外提供服務(wù),并對下面3個物理節(jié)點分發(fā)請求,實現(xiàn)A-A模式冗余。
遺留問題:暫無
1) dashboard
高可用實現(xiàn)方式:
pacemaker+corosync:通過pacemaker生成浮動地址,3個節(jié)點將dashboard web服務(wù)監(jiān)聽直接啟動在0.0.0.0,浮動地址在各個節(jié)點之間切換,同時只有一個節(jié)點提供服務(wù)。
haproxy:通過pacemaker生成浮動地址,3個節(jié)點將dashboard web服務(wù)監(jiān)聽直接啟動在各個節(jié)點的內(nèi)部通信ip上,通過haproxy將監(jiān)聽啟動在浮動ip上,統(tǒng)一對外提供服務(wù),并對下面3個物理節(jié)點分發(fā)請求,實現(xiàn)A-A模式冗余。
遺留問題:暫無
galera cluster:三個節(jié)點均安裝MariaDB數(shù)據(jù)庫,通過galera cluster創(chuàng)建多節(jié)點多主集群,然后通過pacemaker生成浮動地址,在各個節(jié)點之間切換,同時只有一個數(shù)據(jù)庫節(jié)點提供服務(wù)。
遺留問題:官方ha-guide中有使用haproxy掛galera cluster的例子,但是實際配置中暫時無法使用haproxy做前端分發(fā),通過haproxy監(jiān)聽的端口無法連接數(shù)據(jù)庫,原因暫時還未查明。
rabbitmq internal cluster:rabbitmq內(nèi)部提供和原生的集群機(jī)制,可以將多個節(jié)點加入到一個集群中,通過網(wǎng)絡(luò)同步消息隊列數(shù)據(jù)。并且openstack其他各個組件也內(nèi)部提供了冗余的消息隊列配置選項,在配置message queue地址的時候,同時加入3個節(jié)點的地址和端口即可。
遺留問題:暫無
original supported by openstack:openstack原生支持memcached的A-A多點配置,和rabbitmq類似,只需要在配置項中配置所有memcached節(jié)點的地址即可
遺留問題:暫無
根據(jù)如上測試結(jié)論,得出各個組件的HA機(jī)制實現(xiàn)矩陣如下:
系統(tǒng)模塊 | 服務(wù)模塊 | pacemaker+corosync | haproxy | 其他機(jī)制 | 備注 |
keystone認(rèn)證模塊 | keystone-api | √ | √ | haproxy暫時不支持負(fù)載均衡模式 | |
glance鏡像模塊 | glance-api | √ | √ | ||
glance-registry | √ | √ | |||
glance后端存儲 | × | × | swift | ||
nova計算模塊 | nova-api | √ | √ | ||
nova-novncproxy | √ | √ | |||
instance | × | × | nova migrate | 暫時無法實現(xiàn)故障時自動evacuate | |
cinder塊存儲模塊 | cinder-api | √ | √ | ||
cinder-volume | × | × | cinder migrate | 暫時無法實現(xiàn)故障時自動migrate | |
neutron網(wǎng)絡(luò)模塊 | neutron-server | √ | √ | ||
L3 router | × | × | Keepalived+vrrp | Router冗余方案待測試 openstack組網(wǎng)方案需要討論 | |
swift對象存儲模塊 | proxy-server | √ | √ | ||
horizon前臺管理界面 | dashboard | √ | √ | ||
mariadb后臺sql數(shù)據(jù)庫 | mariadb | √ | × | galera cluster | 按照官方ha指導(dǎo)中的haproxy配置方式客戶端無法連接數(shù)據(jù)庫 |
rabbitmq消息隊列 | rabbitmq | × | × | 自帶cluster機(jī)制 | |
memcached緩存系統(tǒng) | memcached | × | × | openstack原生支持多memcached server |
關(guān)于基于OpenStack M版本各組件高可用方案探索是怎樣的問題的解答就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。