共计 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 行业资讯频道了解更多相关知识。