基于OpenStack M版本各組件高可用方案探索是怎樣的

基于OpenStack M版本各組件高可用方案探索是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

1       前言

本測試主要是針對Openstack各個組件，探索實現高可用的部署架構，防止在某個物理節點down機之后造成云平臺服務以及虛擬機實例的不可用。

Openstack主要組件以及需要考慮實現HA的部分如下：

1：keystone認證模塊

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網絡模塊

1)     neutron-server

2)     l3 router

6：swift對象存儲模塊

1)     proxy-server

7：horizon前臺dashboard界面

8：后臺mariaDB數據庫

9：rabbitmq消息隊列中間件

10：memcache緩存系統

部署的物理主機信息如下：

所有主機均部署openstack所有的服務組件，方便進行高可用部署。

2       Openstack各組件HA實現方式

2.1      keystone組件高可用

1)     keystone-api(httpd)

高可用實現方式：

pacemaker+corosync：通過pacemaker生成浮動地址，3個節點將keystone服務監聽直接啟動在0.0.0.0，浮動地址在各個節點之間切換，同時只有一個節點提供服務。

haproxy：通過pacemaker生成浮動地址，3個節點將keystone服務監聽直接啟動在各個節點的內部通信ip上，再通過haproxy將監聽啟動在浮動ip上，統一對外提供服務，并對下面3個物理節點分發請求。

遺留問題：使用haproxy無法做到A-A負載均衡模式，會有token信息混亂的問題，所以在haproxy中只能配置一個active節點，其他節點為backup。

2.2      glance組件高可用

1)     glance-api, glance-registry

高可用實現方式：

pacemaker+corosync：通過pacemaker生成浮動地址，3個節點將api和registry服務監聽直接啟動在0.0.0.0，浮動地址在各個節點之間切換，同時只有一個節點提供服務。

haproxy：通過pacemaker生成浮動地址，3個節點將api和registry服務監聽直接啟動在各個節點的內部通信ip上，再通過haproxy將監聽啟動在浮動ip上，統一對外提供服務，并對下面3個物理節點分發請求實現A-A模式冗余。

2)     glance后端存儲

高可用實現方式：

swift：后端通過連接swift對象存儲的浮動ip，依靠swift本身的高可用性，實現glance后端存儲的HA。

遺留問題：暫無

2.3      nova組件高可用

1)     nova-api, nova-novncproxy

高可用實現方式：

pacemaker+corosync：通過pacemaker生成浮動地址，3個節點將api和vncproxy服務監聽直接啟動在0.0.0.0，浮動地址在各個節點之間切換，同時只有一個節點提供服務。

haproxy：通過pacemaker生成浮動地址，3個節點將api和vncproxy服務監聽直接啟動在各個節點的內部通信ip上，通過haproxy將監聽啟動在浮動ip上，統一對外提供服務，并對下面3個物理節點分發請求，實現A-A模式冗余。

2)     instance

高可用實現方式：

instance live migrate：通過live migrate功能實現實例在計算節點之間的在線遷移.(類似vSphere中的vmotion功能 )

instance evacuate：通過nova-evacuate組件實現在計算節點宕機的情況下，將instance從其他節點上重啟。

遺留問題：暫時沒有可靠的方法實現在主機故障的情況下自動觸發instance evacuate.(實現類似vSphere HA的功能)

2.4      cinder組件高可用

1)     cinder-api

高可用實現方式：

pacemaker+corosync：通過pacemaker生成浮動地址，3個節點將api服務監聽直接啟動在0.0.0.0，浮動地址在各個節點之間切換，同時只有一個節點提供服務。

haproxy：通過pacemaker生成浮動地址，3個節點將api服務監聽直接啟動在各個節點的內部通信ip上，通過haproxy將監聽啟動在浮動ip上，統一對外提供服務，并對下面3個物理節點分發，請求實現A-A模式冗余。

2)     cinder-volume

高可用實現方式：

cinder migrate：通過在多個節點部署cinder-volume服務，連接后端同一個磁陣。當其中一個cinder-volume出現問題，如主機宕機，存儲鏈路故障等，即可使用cinder migrate將volume host為宕機的cinder節點的volume的volume host更改為正常的host，即可重新訪問到存儲。

遺留問題：

1.      暫時沒有可靠的方案實現cinder-volume服務狀態的檢測以及自動切換，如無法監控存儲鏈路故障。

2.      暫時無法配置volume跨backend的在線拷貝遷移(實現類似vSphere中Storage Vmotion的功能)

2.5      neutron組件高可用

1)     neutron-server

高可用實現方式：

pacemaker+corosync：通過pacemaker生成浮動地址，3個節點將neutron-server服務監聽直接啟動在0.0.0.0，浮動地址在各個節點之間切換，同時只有一個節點提供服務。

haproxy：通過pacemaker生成浮動地址，3個節點將neutron-server服務監聽直接啟動在各個節點的內部通信ip上，通過haproxy將監聽啟動在浮動ip上，統一對外提供服務，并對下面3個物理節點分發請求, 實現A-A模式冗余。

2)     l3 router

高可用實現方式：

keepalived+vrrp：待測試

遺留問題：

1.      如果要將我們當前的vmware的組網方式照搬到openstack上，可能無法對號入座，需要一起討論一下。

2.6      swift組件高可用

1)     proxy-server

高可用實現方式：

pacemaker+corosync：通過pacemaker生成浮動地址，3個節點將proxy-server服務監聽直接啟動在0.0.0.0，浮動地址在各個節點之間切換，同時只有一個節點提供服務。

haproxy：通過pacemaker生成浮動地址，3個節點將keystone服務監聽直接啟動在各個節點的內部通信ip上，通過haproxy將監聽啟動在浮動ip上，統一對外提供服務，并對下面3個物理節點分發請求，實現A-A模式冗余。

遺留問題：暫無

2.7      horizon組件高可用

1)     dashboard

高可用實現方式：

pacemaker+corosync：通過pacemaker生成浮動地址，3個節點將dashboard web服務監聽直接啟動在0.0.0.0，浮動地址在各個節點之間切換，同時只有一個節點提供服務。

haproxy：通過pacemaker生成浮動地址，3個節點將dashboard web服務監聽直接啟動在各個節點的內部通信ip上，通過haproxy將監聽啟動在浮動ip上，統一對外提供服務，并對下面3個物理節點分發請求，實現A-A模式冗余。

遺留問題：暫無

2.8      MariaDB高可用

galera cluster：三個節點均安裝MariaDB數據庫，通過galera cluster創建多節點多主集群，然后通過pacemaker生成浮動地址，在各個節點之間切換，同時只有一個數據庫節點提供服務。

遺留問題：官方ha-guide中有使用haproxy掛galera cluster的例子，但是實際配置中暫時無法使用haproxy做前端分發，通過haproxy監聽的端口無法連接數據庫，原因暫時還未查明。

2.9      RabbitMQ高可用

rabbitmq internal cluster：rabbitmq內部提供和原生的集群機制，可以將多個節點加入到一個集群中，通過網絡同步消息隊列數據。并且openstack其他各個組件也內部提供了冗余的消息隊列配置選項，在配置message queue地址的時候，同時加入3個節點的地址和端口即可。

遺留問題：暫無

2.10 Memcached高可用

original supported by openstack：openstack原生支持memcached的A-A多點配置，和rabbitmq類似，只需要在配置項中配置所有memcached節點的地址即可

遺留問題：暫無

3       總結

根據如上測試結論，得出各個組件的HA機制實現矩陣如下：

關于基于OpenStack M版本各組件高可用方案探索是怎樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。