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

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