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机制实现矩阵如下：