《OpenStack高可用集群（上册）：原理与架构》—2.3　Redhat OpenStack高可用部署架构

2.3　Redhat OpenStack高可用部署架构

Redhat与Mariantis均是OpenStack社区代码贡献最为强劲的两家厂商，同时各自都有自己基于OpenStack的产品线，Redhat的OpenStack Platform（OSP）系列产品，Mariantis的Fule系列产品都在OpenStack个人和企业部署市场上占有较大的份额。本节主要介绍Redhat的OpenStack高可用部署方案。

2.3.1　Redhat OpenStack高可用集群部署架构

Redhat的OpenStack高可用方案主要分为两种方式：一种是基于Keepalived的高可用方案（图2-16所示）；一种是基于HAproxy负载均衡器和Pacemaker集群资源的高可用方案。后一种方案又可以分为服务独立的集群高可用部署（HACluster-deployment-segregated）方案（图2-17所示）和服务集中的集群高可用部署（HACluster-deployment-collapsed）方案（图2-18所示）。由于后一种方案利用了Pacemaker强大的资源管理功能，因此，Redhat官方推荐的部署方案是基于HAProxy和Pacemaker的高可用部署方案。

HAproxy是一种基于TCP/IP的负载均衡器，在Redhat架构中，HAproxy用于对Openstack的访问请求进行负载均衡，HAproxy支持Active/Active模式，Active/Passive模式等多种负载均衡模式。Pacemaker是一种开源的高可用资源管理器，它可以检测到服务器级别和应用级别的故障并能够将服务从故障中恢复，在Redhat高可用架构中，如果Open-Stack的某个服务故障，则Pacemaker负责重启该服务，同时Pacemaker还负责OpenStack使用的基础组件的高可用，如数据库高可用、Message队列和HAproxy负载均衡器的高可用。图2-17和图2-18中描述了每个OpenStack服务的高可用模式，这是Redhat高可用集群经常使用的服务高可用模式，这些高可用模式包括：

Active/Active模式。也称为双活模式，当服务配置为主/主模式时，全部节点都同时运行相同服务并同时接受访问请求，如果其中一个节点故障，则该节点的访问请求被转移到其他任一正常节点，整个过程客户端的服务请求不会中断。

Active/Passive模式。也称为主备模式，当服务配置为此主/备模式时，只有一个节点运行服务并接受请求，当此节点故障时，备节点服务会被激活，后续的请求会被转发到备节点上，整个过程中客户端请求会有短暂中断。

图2-16　Redhat基于Keepalived的OpenStack高可用集群部署方案

图2-17　Redhat服务独立的OpenStack高可用集群部署方案

Hot Standby模式。也称为热备模式，当服务配置为热备模式时，所有节点都同时运行相同服务，但是只有一个节点在响应客户端的访问请求，其余节点没有客户端的请求访问，当接受请求的节点故障时，客户端访问请求被无缝切换至运行相同服务的正常节点上继续处理，整个过程客户端的服务请求不会中断。

图2-18　Redhat服务集中的OpenStack高可用集群部署方案

Mixed模式。混合模式通常用在由多个子服务组成的服务组件中，即将服务组件的子服务配置成上述几种高可用模式组合，混合模式的配置因服务情况而异，通常，混合高可用模式指某些子服务配置成为主/主模式，而有些配置成为主/备或者热备模式。

Single Node模式。也称为单点模式，即服务仅在一个节点运行，这类服务可以通过Pacemaker来管理，如果Pacemaker检测到其故障则重新启动它，整个过程会有相对较长时间的中断。

为了实现每一个服务的独立和高可用，Redhat从概念上设计了一个理想的高可用服务集群部署方案，在这种理想的高可用集群部署模式下，每一个服务都被分散部署在独立的物理服务器（或者虚拟机）上，并且运行每个OpenStack服务组件的一组服务器（Redhat推荐三个服务器为一组）组成一个高可用集群，最终实现独立的集群负责独立服务组件的高可用性。在这种概念设计的高可用模式下，每个OpenStack服务组件均运行在一组独立的服务器上，同时服务器的数量还可以根据服务的负载集群进行按需扩容，图2-19即为这种理想化的OpenStack高可用集群概念设计方案。

当然，这种理想化的OpenStack高可用集群方案要变为现实，对于很多用户而言是很难接受的，因为为了保证每个服务的独立和高可用，在不考虑计算节点的情况下就需要使用大量服务器来提供各种API服务，更重要的是，对于OpenStack的服务而言，最消耗物理资源（或者说最需物理资源）的往往是计算服务，而不是各种API和调度服务。当然，如果用户确实需要将各个服务组件隔离到独立的集群下运行，又不希望浪费大量的物理服务器，Redhat建议可以将各个OpenStack服务隔离到虚拟机上运行，即只需将图2-19中每个服务集群的三台服务器变为虚拟机即可。

图2-19　Redhat概念化的OpenStack高可用集群方案

在实际部署中，Redhat也提供了服务集中式的高可用部署方案，即将OpenStack的控制、API、调度等服务集中到控制节点集群（控制节点集群至少由三台服务器组成）上运行，同时将计算服务独立到计算节点上运行，OpenStack运行在控制节点集群上的服务通过Pacemaker集群管理软件进行高可用管理，计算节点通过精简的Pacemaker_Remoter服务以远程节点的形式加入控制节点集群中，通过控制节点的集群管理软件统一实现高可用管理，图2-20为Redhat提供的服务集中式OpenStack高可用集群部署方案。

在OpenStack的集群服务中，各服务之间是一种相互依赖和交互的关系，即某些服务的存在是以另一服务的存在为前提的，而某些服务之间可能并不存在相互依赖关系，所以这部分服务是可以独立存在或者并行启动的，集群服务之间的这种依赖关系涉及了服务启动的先后顺序，当然由于资源管理器Pacemaker的存在，这种启动顺序和依赖关系可以得到很好解决。用户要注意的是如何区分哪些服务是可以并行启动的，哪些服务之间因为有依赖关系而必须是先后启动的，Redhat为这种OpenStack服务的依赖关系也提供了参考，图2-21便是Redhat在OpenStack高可用集群中推荐的服务启动依赖关系图。

图2-21描述了Redhat在OpenStack高可用集群中分配的各个服务之间的启动依赖关系，从中可以看到，整个集群最先启动的一定是最底层的负载均衡器，然后是支撑OpenStack服务的基础类服务如消息队列AMQP、数据库MariaDB（或者MySQL）和MongoDB紧随其后可以并行启动，接着是认证服务Keystone和Memcached可以同时启动，之后是OpenStack核心服务，如Nova、Neutron、Cidner等跟着可以并行启动，最后，一旦IaaS所需的全部服务启动完成，则整个IaaS平台进入服务Ready状态。图2-21中的CheckPoint层可以认为是非活动时间间隔，此间隔的存在主要是为了在启动下一阶段的服务之前先检查并验证本阶段的服务是否完全成功启动，CheckPoint的时间大小不一，关键是要保证下一阶段的服务启动之前，本阶段的服务必须在集群中完全成功启动。

图2-20　Redhat实际应用的OpenStack高可用集群部署架构

图2-21　Redhat OpenStack高可用集群服务启动依赖关系