生产环境中OpenStack的高可用性设计

基础架构服务高可用

包括消息队列服务高可用、数据库服务高可用和缓存服务高可用

控制服务高可用

Nova-API、Glance-API和Neutron-server等
目前主流的OpenStack控制服务高可用性主要分为两大类：

• Pacemaker和Haproxy


• Keepalived和Haproxy

在这两种方案中，OpenStack控制服务和基础架构服务通常都部署在三台控制节点上，OpenStack控制服务以Active/Active或Active/Passive高可用模式运行在三个节点上，并且OpenStack基础架构服务的高可用实现在两种方案中是类似的。
如通过消息队列镜像方式实现RabbitMQ服务的高可用，通过Galera集群实现Mysql或MarriaDB数据库的高可用，通过列表形式实现Memcache缓存服务的高可用行。

网络服务高可用

网络服务的高可用主要涉及API服务、L2和L3服务的高可用。API由于是无状态服务，因此通过三节点和HAProxy负载均衡器即可解决，但是像L3这种有状态服务，则需专门的高可用解决方案–L3 HA和DVR。

• L3 HA高可用解决方案

这种主要思想是在多个网络节点（通常就在控制节点）上同时部署L3 Agent服务。当租户创建高可用L3 Router时，在多个运行L3 agent的网络节点上同步创建多个L3 Router实例，不同网络节点上的L3 Router 完全相同，借助VRRP使得多个网络节点上的L3Router具有不同的运行状态，即其中仅有L3 Router 是Master状态，而其他Router是Standby状态。正常情况下，Master向虚拟机提供路由服务，当Master出现故障时，重新从standby状态的L3 Router选举新的Master。

• DVR高可用方案

L3 HA高可用方案虽然可以解决网络服务高可用问题，但是由于集群中全部东西和南北向网络流量全汇聚到网络节点，因此在大规模集群中很容易造成网络节点的瓶颈。DVR解决方案将所有东西流量和南北向中的DNAT全部转移到各个计算节点，网络节点仅保留南北向流量中的SNAT功能，因此分布式的虚拟路由不仅解决了L3 的高可用问题，同时也解决了网络瓶颈问题。

在实际应用中，为了解决DVR方案中SNAT的高可用性，通常将DVR与L3 HA高可用方案同时启用，从而利用L3 HA高可用方案解决SNAT的单点故障问题。

存储服务高可用

Cinder-volume、Ceph RBD
Cinder项目是OpenStack私有云建设中最主要的存储服务提供者，但是Cinder服务的高可用一直被诟病，主要原因在于Cinder-volume使用了本地锁，因此无法实现在Active/Active模式下的高可用运行。
因此对于Cinder服务的高可用，目前主流的做法仍然是通过HaProxy实现Cinder-scheduler的高可用性，并将Cinder-volume以Active/Passive模式运行在Pacemaker集群中，由pacemaker来控制Cinder-volume的高可用。

实践中，存储高可用最佳实践采用Ceph分布式存储解决方案。在Ceph存储高可用方案中，存储服务前段（如cinder-API和cinder-scheduler)的高可用由HAProxy实现，存储后端的高可用直接交由Ceph分布式存储集群。

计算服务高可用

Nova-compute和虚拟机

计算服务是Openstack私有云中最核心的服务，由于社区一直未提供完善的计算服务高可用解决方案，因此只能通过第三方基础架构软件来实现。
最主流的便是由Redhat主导的pacemaker_remote计算服务高可用解决方案。其重要部署在计算节点上，从而将计算节点与控制节点全部加入pacemaker集群，最终将Openstack计算服务纳入Pacemaker集群中进行高可用实现。

采用pacemaker_remote解决方案，用户无须自己编写脚步监测计算节点服务运行情况，而通过Redhat开源代理fence-agent和resource-agent即可自动实现对计算节点服务的监测、隔离和虚拟机撤离操作。