《OpenStack高可用集群（下册）：部署与运维》—11.2.3　OpenStack高可用部署软件拓扑架构

11.2.3　OpenStack高可用部署软件拓扑架构

在OpenStack集群高可用部署中，可以将软件划分为两大类，即基础服务软件和OpenStack核心服务软件。基础服务软件主要包括集群管理软件Pacemaker/Pacemaker_remote、负载均衡软件HAProxy/Keepalived、数据库管理软件MariaDB/MongoDB、缓存系统Memcache/Redis和消息队列AMQP（RabbitMQ）等。OpenStack核心服务包括计算服务Nova、网络服务Neutron、存储服务Cidner/Swift、认证服务Keystone、镜像服务Glance和控制面板（GUI）服务Horizon等，由于OpenStack服务具有极高的部署灵活性，而OpenStack每个服务项目又由多个可分布式部署的功能组件构成（典型的便是接收请求的前端API和处理请求的后端驱动分开部署），并且OpenStack社区也在不断增加新的项目。因此，用户在实施部署OpenStack集群之前，除了功能架构上的设计外，还需要对提供各个功能模块的软件拓扑进行规划设计，尤其是在生产环境中，如何无死角地实现全部OpenStack基础服务软件和核心服务软件的高可用，对后期集群的整体稳定和高可用运行起着至关重要的作用。

本章介绍的OpenStack高可用集群方案主要参考Redhat的OSP系列高可用部署架构，采用三控制节点服务集中式部署方案，相对服务分离式部署，三控制节点集中式部署更适合广大用户，尤其是私有云用户。因为服务分离式高可用部署意味着所需服务器数目为3的n倍，n为需要进行高可用部署的服务数目。在本章介绍的三控制节点服务集中式高可用部署中，OpenStack相关软件拓扑架构如图11-11所示。在图11-11中，Pacemaker集群由三个控制节点组成，同时像数据库服务和RabbitMQ服务的高可用集群均运行在三个控制节点上，此外，众多OpenStack服务组件（Nova-compute运行在独立的计算节点上）也运行在三个控制节点上，并由Pacemaker资源管理器进行控制管理。Pacemaker集群中的每个资源均被指派一个虚拟服务IP，客户端通过虚拟IP对集群资源进行访问，同时访问请求被HAProxy负载均衡器根据设定的负载均衡算法转发到三个控制节点上。

图11-11是从控制节点角度给出的软件部署拓扑架构图，将高可用部署的全部软件拆分之后，OpenStack高可用集群软件部署模式如图11-12所示。其中C1、C2和C3分别代表图11-11中所示的三个控制节点，图11-12所示形象地给出了OpenStack集群中服务软件高可用部署的分布情况和数据访问流向。Pacemaker集群管理着若干虚拟服务IP，每个虚拟IP均代表了某种集群服务资源，而集群服务资源均以Active/Active或者Active/Passive高可用模式运行在三个控制节点上。同时，任何对集群资源的访问均需要通过运行在三个控制节点上的HAProxy负载均衡器，并由负载均衡器将服务请求转发到三个控制节点中的某个节点上进行响应处理。从理论上讲，图11-12中所示的每个集群服务均可独立部署到三个节点组成的独立集群中，而HAProxy负载均衡软件也可由硬件负载均衡交换机替换，如F5公司的负载均衡设备。如此一来，OpenStack高可用集群就会由若干个Pacemaker集群组成，每个Pacemaker集群由三个节点构成并且仅运行一个服务，集群服务之间在物理层面被完全隔离，对于大型公有云部署，这是RedHat推荐的高可用部署模式，但是对于私有云部署而言，这种软件独立部署模式无疑极大地增加了部署成本，同时也增加了运维管理的集群数目。而实际上，在控制节点物理资源充分的情况下，将全部服务集成部署到三个控制节点组成的一个Pacemaker集群中，也可满足OpenStack集群高可用服务的要求，而且所需成本也可被大多数用户接受。此外，随着容器技术的发展，OpenStack容器化部署的趋势也日趋明显，如国内九州云大力推行的Kolla项目和Marantis推行的Kubernetes (k8s)都在致力于将OpenStack容器化，即采用Kolla或K8s来编排部署OpenStack将成为未来OpenStack部署的趋势。因此，未来OpenStack服务分离到独立集群中部署以实现服务物理隔离的方案很可能会被直接淘汰，因为容器技术的特点之一便是服务隔离。

图11-11　OpenStack高可用集群软件部署拓扑架构

图11-12　OpenStack高可用集群服务分布