基于OpenStackM版本各组件高可用方案探索是怎样的

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

当前标题：基于OpenStackM版本各组件高可用方案探索是怎样的
转载来于：http://cdxtjz.cn/article/picoip.html