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

75次阅读
没有评论

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

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-16发表,共计4592字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)