基于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版本各组件高可用方案探索是怎样的问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。