《OpenStack高可用集群（上册）：原理与架构》—2.3.2　Redhat OpenStack高可用集群服务规划

2.3.2　Redhat OpenStack高可用集群服务规划

Redhat的OpenStack高可用集群部署方案推荐使用的是HAProxy和Pacemaker来进行高可用和资源管理，Redhat为每个OpenStack集群服务分配虚拟IP（VIP），VIP均衡分布到三台控制器集群上，并通过Pacemaker来进行HAProxy的高可用，HAProxy将客户端对VIP的访问转发到具体的后端OpenStack集群服务中进行处理，OpenStack集群服务的高可用性通过Pacemaker进行控制。由于集群服务特性各自不一，因此，Redhat将不同的OpenStack集群服务配置成为不同的高可用模式，如无状态服务配置为Active/Active模式，有状态服务配置为Active/Passive模式，Redhat对OpenStack集群各服务高可用性的配置如下：

数据库。数据库是OpenStack部署中的核心基础部分，基于SQL的数据库存储了OpenStack平台配置信息和各服务项目的运行时状态信息，包括实例状态信息、网络状态信息、镜像状态信息、存储状态信息和用户及租户信息等。OpenStack支持全部SQL兼容的数据库，但是Redhat推荐OpenStack部署使用的数据库为MariaDB，同时在Redhat的OpenStack高可用集群中，MariaDB通过Galera高可用集群被配置为Active/Active高可用模式，而Pacemaker通过OCF脚本来管理MariaDB的集群资源。

消息队列。消息队列系统的主要目的是使应用程序组件之间可以通过消息交换来进行彼此通信，OpenStack集群服务使用消息队列来进行任务通信和交互，同时OpenStack服务的Endpoint、Scheduler、Agent之间的状态变化通知也要通过消息队列来实现。OpenStack默认使用RabbitMQ作为集群消息队列，在Redhat的架构中，RabbitMQ部署在高可用控制节点集群上，RabbitMQ通过自身的集群配置方式将消息队列配置为Mirrored模式从而实现消息队列的高可用，Pacemaker通过RabbitMQ提供的OCF脚本将其配置为Active/Active高可用模式。

Memcache。Memcache是将Key-Value数据类型存储在内存中的小型数据库。OpenStack中使用Memcache的主要作用是通过降低数据库的访问压力来提升应用程序的性能，在Redhat的高可用集群架构中，Memcache部署在高可用控制节点集群中，并运行在Active/Active高可用模式。

Keystone。Keystone部署在高可用控制节点集群中，Pacemaker将其配置为Cloned资源，Keystone最终以Active/Active高可用模式运行在控制节点集群上。

Glance。Glance包括Glance-api和Glance-registry两个子服务，Pacemaker将Glance服务配置为Cloned资源，两个子服务最终以Active/Active高可用模式运行在控制节点集群上。

Nova。Nova由多个子服务构成，Nova的多个服务运行在Active/Active和Active/Passive组成的Mixed模式下，其中，Nova-api、Nova-scheduler、Nova-consoleauth和Nova-novncproxy均部署在高可用控制节点集群上，Nova-api、Nova-consoleauth和Nova-novncproxy均以Cloned资源的形式运行在Active/Active模式，Nova-scheduler运行在Active/Passive模式。

Cinder。Cinder的多个服务也运行在Mixed模式，其中Cinder-api、Cinder-scheduler运行在Active/Active模式，Cinder-volume运行在Active/Passive模式。

Neutron。Neutron由多个子服务构成，其中Neutron-server、L3-agent、DHCP-agent、OpenVSwitch-agent、metadata-agent均部署在高可用集群控制节点上，同时运行在Active/Passive模式。

Horizon。Horizon 的Dashboard服务以Httpd资源的形式部署在高可用集群控制节点上，并且运行在Active/Active模式。

Nova-compute。Nova-compute部署在每个计算节点上，Nova-compute的服务以Single Node模式运行，即单点模式，当Nova-compute服务故障时，Pacemaker会将其服务重启或者将计算节点进行隔离（Fencing）操作。

表2-3归纳了Redhat OpenStack高可用集群各个服务的高可用运行模式，表中的服务部署是根据图2-20中的Redhat OpenStack集群高可用架构实现的，即两台LoadBlancer服务器（LB[0-1]），控制节点集群由三台服务器组成（Controller[2-4]），计算节点由三台服务器组成（Compute[5-7]）。在Redhat的高可用集群部署中，OpenStack的多数服务均运行在高可用控制节点集群上，即Active/Active的服务运行在全部控制节点上，而Active/Passive的服务也需要部署在全部控制节点上，但是在Passive控制节点上的服务并未被激活，此外，Nova-compute服务以单点模式运行在计算节点上，负载均衡器上运行HAproxy和VIP服务。

表2-3　RedhatOpenStack高可用集群服务部署规划

OpenStack高可用集群由诸多服务组件构成，为了保证每一个服务的高可用性和可扩展性，OpenStack的高可用架构要求每一个服务都应该具备Scale-out的扩展特性，即在服务访问负载较大的情况下，可以实现服务处理能力的弹性扩展并能够将访问请求以负载均衡的形式分布到不同的服务节点上进行响应。为此，部署有OpenStack服务的每个控制节点都要求能够在不影响当前服务的情况下实现Scale-out扩展，而在集群中的某个控制节点出现故障的情况下OpenStack的服务可用性也不能受到影响。为了实现OpenStack服务的高可用性，Redhat的高可用集群架构将OpenStack的每一个服务都交由集群资源管理器Pacemaker来管理，并通过HAproxy将访问负载均衡分布到每个集群处理节点上，同时为了防止集群脑裂（Brain-split），建议OpenStack控制节点集群至少由三台服务器构成。Redhat推荐的OpenStack高可用部署架构下控制节点Pacemaker管理的高可用服务分布如图2-22所示。

图2-22　Redhat OpenStack集群Pacemaker高可用服务