共計 4592 個字符，預計需要花費 12 分鐘才能閱讀完成。

基于 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 緩存系統

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

節點名

登錄操作 IP 地址

內部組件通信 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

所有主機均部署 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 機制實現矩陣如下：

系統模塊

服務模塊

pacemaker+corosync

haproxy

其他機制

備注

keystone 認證模塊

keystone-api

√

√

haproxy 暫時不支持負載均衡模式

glance 鏡像模塊

glance-api

√

√

glance-registry

√

√

glance 后端存儲

  ×

  ×

swift

nova 計算模塊

nova-api

√

√

nova-novncproxy

√

√

instance

  ×

  ×

nova migrate
nova evacuate

暫時無法實現故障時自動 evacuate

cinder 塊存儲模塊

cinder-api

√

√

cinder-volume

  ×

  ×

cinder migrate

暫時無法實現故障時自動 migrate

neutron 網絡模塊

neutron-server

√

√

L3 router

×

×

Keepalived+vrrp

Router 冗余方案待測試

openstack 組網方案需要討論

swift 對象存儲模塊

proxy-server

√

√

horizon 前臺管理界面

dashboard

√

√

mariadb 后臺 sql 數據庫

mariadb

√

  ×

galera cluster

按照官方 ha 指導中的 haproxy 配置方式客戶端無法連接數據庫

rabbitmq 消息隊列

rabbitmq

  ×

  ×

自帶 cluster 機制

memcached 緩存系統

memcached

  ×

  ×

openstack 原生支持多 memcached server

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