11.2 OpenStack集群高可用部署架构设计

对于OpenStack高可用集群部署而言，笔者建议在生产环境中正式部署之前，先在实验环境中进行OpenStack各个功能模块和高可用性的验证。通过实验环境从理论上完全实现了前期需求分析中对IaaS基础架构的各种需求之后，生产环境中的部署将会变得非常快速和简单（通常只需将实验环境中部署成功的代码复制一份，并放到生产环境中运行即可），而且不会因为很多意外问题而额外占用很多诸如电力、网络等生产环境资源。因此，本节将从实验环境准备和生产环境准备两个方面来介绍OpenStack高可用集群部署的硬件环境塔建。值得指出的是，由于OpenStack部署模式的灵活性，事实上并不存在绝对唯一的部署架构，例如不同的服务可以合并部署到一个节点，也可以分开部署到不同节点，而多个服务又可以以不同的组合形式部署。因此，这里给出的仅是参考实现架构，不同用户根据自身的实际环境，通常需要作出适当的调整。

11.2.1 OpenStack高可用部署实验环境架构

为了实现一个“移动式”OpenStack高可用实验环境，笔者建议将实验环境部署在一台笔记本电脑上，以方便随时随地全身心投入OpenStack的研究部署中，当然也可以部署在数据中心PC Server上。由于普通笔记本物理资源，尤其是内存，难以满足集群需求，因此在开始OpenStack环境塔建之前，可能需要对个人笔记本进行硬件升级。这里硬件升级通常指升级内存条。不同型号笔记本支持的最大内存受主板限制可能不一样，较老型号的可能仅支持最大4GB或8GB，而较新的主板可能支持16GB或32GB。查看主板支持的最大内存方式如图11-3所示，在cmd命令窗口中输入wmic memphysical get maxcapacity命令即可查看，图11-3中笔记本最大支持16GB内存。

由于OpenStack高可用集群实验环境仅做功能验证测试，不做性能压力测试，因此根据笔者经验，16GB内存通过虚拟化完全可以实现三个控制节点和两个计算节点的OpenStack高可用集群实验环境。此外，如果希望在此电脑上进行Ceph存储使用，则建议增大硬盘容量，1TB的硬盘空间足以满足存储节点实验和虚拟机的多次快照保存。以笔者的实验环境为例，笔记本型号为联想T440p，内存16GB, CPU为Intel酷睿i5处理器，存储为两块500GB硬盘，操作系统为64位Windows7 SP1旗舰版，虚拟化软件为VMware Workstaion11，一共创建5台VMware虚拟机，其中3台控制节点用于实现OpenStack服务的高可用，2台计算节点用于实现实例HA。另外，由于OpenStack高可用环境中必须实现Quorum机制，并能够对控制节点进行隔离操作（Fencing），而VMware虚拟机在实现Fencing上有一定困难，因此在三台控制节点VMware虚拟机上又各自创建了一台KVM虚拟机，并且将这三台KVM虚拟机作为最终的OpenStack高可用集群控制节点。笔者的实验环境物理架构如图11-4所示。在图11-4中，控制节点由三台VMware虚拟机中的三台KVM虚拟机组成。计算节点由两台VMware虚拟机组成，OpenStack高可用集群由运行Pacemaker和Corosync进程的控制节点，以及运行Pacemaker_remote的计算节点组成。计算节点之所以仅运行Pacemaker_remote，是因为生产环境中如果计算节点也运行Pacemaker和Corosync进程，则Pacemaker高可用集群最大仅支持16个节点，而这显然不能满足生产环境中大规模节点部署的需求。Pacemaker_remote为Redhat专为解决Pacemaker集群节点限制而开发的精简版Pacemaker，计算节点在运行Pacemaker_remote时，并不存在最大16个节点的限制，并且运行Pacemaker_remote的计算节点完全可以作为Pacemaker集群节点存在并接受控制节点的控制。

在基于图11-4所示实现的实验环境中，服务器节点的部署实现所需要准备的工作便是准备好5台VMware虚拟机（3台为控制节点，2台为计算节点）。控制节点VMware虚拟机的配置如图11-5所示。

为了能够在VMware虚拟机中嵌套创建KVM虚拟机，在VMware虚拟机设置的处理器选项中，为处理器选择Intel VT-x/EPT或AMD-V/RVI虚拟化引擎。此外，处理器的数量不易设置过大，否则容易出现因资源分配问题而导致的VMware虚拟机Holding问题。如果对VMware虚拟机CPU数量有要求，可以通过每个处理器的核心数来控制。由于3台VMware虚拟机需要嵌套创建KVM虚拟机来作为控制节点，并且3台KVM虚拟机控制节点需要运行绝大部分的OpenStack相关基础服务和OpenStack核心服务，因此建议分配相对较多的内存。图11-5所示分配了4GB内存给VMware虚拟机，其中的3GB用于VMware虚拟机中创建的KVM虚拟机控制节点。与控制节点不同，计算节点主要负责用户实例创建，如果资源允许，计算节点可以分配较多的CPU和内存等资源。此外，对于一个高可用的OpenStack集群而言，任何节点都应该支持Fencing功能。由于是实验环境，图11-4所示的架构中仅运行在VMware虚拟机中的3个KVM虚拟机控制节点通过虚拟机Fencing驱动实现了隔离Fencing功能，而两个运行在VMware虚拟机上的计算节点并没有实现Fencing，但是这并不影响实验环境中OpenStack集群的多数高可用功能验证。如果在生产环境中，则计算节点的Fencing功能是必须的。

根据图11-4所示的实验环境架构，如果想要在自己的笔记本上部署一套高可用的OpenStack实验环境，则可以按照如下步骤进行实现。

1）准备一台硬件相对高配的笔记本电脑，进入主板BIOS，打开虚拟化支持功能（Intel-VT或AMD-V）。通常笔记本或PC服务器出厂时虚拟化支持功能均会打开，但是仍然建议进行检查，因为后面很多与虚拟化相关的奇怪问题可能均与主板虚拟化功能是否开启有关。

2）在Windows系统中安装VMware Workstation虚拟化软件，VMware Workstation与VMware ESXi系列虚拟化引擎不一样，Workstation是一种操作系统层面的虚拟化机制，其以应用程序的形式运行在操作系统中，因此在启动实验环境后，建议不要在同一个操作系统里面运行过多的其他应用程序，尤其是资源密集型的应用程序，以保证VMware Workstaion可以获得最多的资源。

3）在VMware Workstation中创建三台VMware虚拟机（虚拟机名称分别为Controller1、Controller2和Controller3），虚拟机具体配置可以参考图11-5所示。三台VMware虚拟机用作OpenStack高可用集群控制节点宿主机。VMware虚拟机安装Centos7.1系统。为了最大化KVM虚拟机控制节点的资源使用，VMware虚拟机操作系统安装方式选为最小安装。

4）在VMware Workstation中创建两台VMware虚拟机（虚拟机名称分别为Compute1和Compute2），两台虚拟机用作OpenStack高可用集群的计算节点，虚拟机具体配置可以参考图11-6所示。VMware虚拟机安装Centos7.1系统。为了最大化将计算节点资源应用到用户实例中，计算节点操作系统选用最小安装方式安装。

5）将控制节点Controller1设置为Master控制节点，Master控制节点将同时充当管理集群节点的角色，后续此节点将被配置为NFS服务器。因为实验环境采用离线安装方式，在运行部署脚本之前，先将Centos71系统镜像和OpenStack离线安装所需的rpm软件包和依赖包上传到Master上。

6）运行自动化配置脚本，初始化Controller1、Controller2和Controller3这三台VMware虚拟机，为后期部署OpenStack服务准备好系统环境。初始化完成后，Controller1将被配置为Master控制节点和集群管理节点，同时被配置为集群NFS服务器。

7）运行自动化配置脚本初始化Compute1和Compute2这两台VMware虚拟机。初始化完成后，两台虚拟机将被配置为计算节点环境，从而为后期部署OpenStack的Nova-compute和Pacemaker_remote服务准备好系统环境。

8）将自动化配置所需的全部脚本上传到Master控制节点，并在其上运行相应的脚本以在三个控制节点上安装配置OpenStack相关服务，同时设置Pacemaker集群资源和资源约束等与集群管理相关的参数配置。

9）在Master控制节点上运行相应配置脚本，以在两个计算节点上安装配置Compute相关服务，并设置Pacemaker_remote相关资源和集群约束。

10）启动Pacemaker集群服务并验证集群服务运行情况。

11）验证OpenStack集群服务的高可用性。

通常，实验环境各个节点资源有限，在实验环境中仅限于对OpenStack高可用集群的部分关键功能进行测试，对于诸如压力测试等生产环境下必须的测试环节，实验环境无能为力。此外，由于资源限制，某些理论上可以正常实现的功能，也可能因为资源不足而不能实现，甚至无法启动某些服务。此时需要明白故障背后的深层原因，究竟是因为资源不足导致还是因为软件问题、配置不对或配置冲突等问题导致的？正常情况下，实验环境中可以正常实现的功能，在迁移至生产环境后，都可以成功实现，用户需要注意的是随着集群规模的扩大，客户端连接数的增加为数据库和消息队列等基础服务带来的影响，例如数据库的最大连接数设置和消息队列的阻塞等问题。

11.2.2 OpenStack高可用部署生产环境架构

对于开源软件的使用，没有任何固定的设计架构，尤其是像OpenStack这类“大帐篷”模式发展的开源社区软件。在云计算不断落地发展的现今，基于OpenStack的创业公司层出不穷，同时传统IT巨头也在借力OpenStack加速转型成为云计算公司，并且很多具有较强IT技术实力的企业也在基于OpenStack自建私有云，因此应用于生产环境中的OpenStack部署架构可以说是“百花齐放，百家争鸣”。在OpenStack高可用集群架构设计中，不同厂商均提出了自己的高可用设计架构，这其中以开源领导厂商RedHat和Pure Play OpenStack厂商Mirantis的高可用方案最为主流，而国内很多OpenStack创业公司初期的OpenStack高可用方案都源自RedHat OSP（OpenStack Platform）和Mirantis的Fuel系列OpenStack部署软件的定制化和二次开发，因此对于计划自建OpenStack高可用集群的用户而言，如果没有更好的高可用设计架构，则RedHat和Mirantis的高可用方案确实是非常值得借鉴的。图11-7所示为RedHat OSP系列的OpenStack高可用集群部署参考架构，关于RedHat OSP高可用架构的具体描述可以参考第2章中的相关部分。

从架构的整体设计上来看，RedHat提供的高可用架构充分考虑了企业级应用服务的高可用性，因此架构在设计和实现上都需要一定的技术实力和成本预算来支撑，对于有较多云计算人才和充分预算的企业，RedHat方案将是不错的选择。图11-8所示是Mirantis主导的OpenStack高可用架构设计方案之一。Mirantis是一家完全基于OpenStack的初创公司，其设计理论和方案以简单实用为主，在架构设计上不会显得冗余繁重，非常适合对云计算接触并不深入的年轻团队或者在成本预算上受到限制的部门或初创公司进行基于OpenStack的云计算建设参考。当然，除了Redhat和Mirantis的OpenStack高可用方案外，用户也可以综合各家所长实现自己的OpenStack高可用架构，只要整个架构的最终设计能够满足前期提出的IaaS服务需求分析即可。

对于生产环境而言，硬件服务器节点的拓扑情况通常根据OpenStack各个服务组件部署模式的不同选择而不同，由于OpenStack服务组件的部署具有极大的灵活性，因此在项目实施之初的设计阶段需要谨慎，以保证OpenStack集群在功能正常使用的同时，还应该具备高可靠性、高可用性和水平可扩展性。通常，为了保证生产环境的高可用，控制节点数目至少由3个物理服务器构成，而计算节点则根据实际的规划需求可以分为一期上线和后续二期扩容的形式来规划采购。对集群拓扑影响较大的可能是后端存储的采用，如果采用IBM、EMC、Netapp或华为等企业存储阵列，则OpenStack集群后端存储需要一个复杂的存储SAN网络支撑，图11-9所示即是比较典型的基于企业级高可用存储的OpenStack集群部署架构，OpenStack集群存储云盘由Cinder项目提供，Cinder后端可以使用LVM驱动或直接使用由特定存储厂商提供的存储驱动来使用底层存储。图11-9中，后端底层存储采用EMC VPLEX或IBM SVC存储异构虚拟化产品对底层不同存储厂商的存储阵列进行异构虚拟化封装，并统一由VPLEX或SVC作为Cinder的后端存储设备，而在Cinder的后端存储驱动矩阵中，用户可以轻易找到EMC和IBM提供的VPLEX和SVC驱动程序。

在企业生产环境中，采用类似图11-9所示的OpenStack高可用集群有很多优势，首先冗余控制节点为OpenStack集群的控制层面提供了高可靠和可用性，同时将集群服务、负载均衡服务、消息队列服务、数据库服务和缓存服务等与计算无关的OpenStack基础服务与计算节点独立并集中到高可用控制节点统一部署管理。在以后的使用过程中，用户对集群的扩容仅限于计算和存储，而计算节点的扩容完全是Scale-out形式的，且独立于控制节点和后端存储阵列，计算节点扩容也仅需针对Nova-compute服务即可。此外，由于采用了传统企业级存储阵列，存储空间的扩容也变得极为简单，只需在线对存储阵列进行磁盘扩容即可，并且无须改变任何OpenStack集群配置。用户还可以利用VPLEX/SVC将数据同步到多个底层存储阵列，从而为关键数据提供更高层次的保护。采用类似图11-9所示的传统企业级存储架构的OpenStack高可用集群的不足之处在于成本较高，复杂的后端底层存储和SAN网络需要专门的存储管理员维护，并且多数存储阵列的扩容仍然是Scale-up形式（也有类似IBM XIV的Scale-out阵列）。在大容量扩容之后，有限的存储控制器处理能力和前后端带宽必然限制高并发用户对海量存储的访问，因此是否选用此类型的OpenStack高可用集群架构，需要用户根据自己的成本和业务慎重考虑。

与图11-9不同，图11-10采用的是基于分布式开源存储集群Ceph的OpenStack高可用架构。Ceph作为一种统一分布式存储集群，其在高可用、高可靠和故障自我愈合方面都有相当不错的表现，并且也是OpenStack中使用极为普遍的后端存储之一，目前其提供的文件系统存储CephFS、块存储RBD和对象存储RGW均为稳定版本。Ceph RBD不仅可以作为Cinder的块存储后端，还可以为Glance和Nova提供镜像存储和虚拟机临时磁盘空间。Ceph存储集群主要由Ceph监控节点和Ceph OSD节点组成，其中监控节点负责整个集群的健康检查并保存集群运行状态和提供集群数据恢复的依据；而OSD节点负责用户数据的存储。Ceph监控节点对整个Ceph集群的正常运行至关重要，可采用仲裁机制来保证监控节点的高可用，因此生产环境下建议监控节点数目最少为3个。图11-10中所示Ceph监控节点被放置到OpenStack控制节点上，当然用户可以使用独立的Ceph监控节点，或者将其部署到OSD节点上（为了实现控制与数据的分离，不建议OSD节点同时作为监控节点）。与传统企业级Scale-up扩容的存储阵列不同，Ceph OSD节点可以按需在线以Scale-out的形式扩容。从理论上讲，Ceph OSD节点越多，Ceph集群的可用性、可靠性和存储性能就越强大，因此Ceph存储集群并不存在理论上的容量极限，用户只需根据容量需求不断增加OSD节点用以存储数据，而不用担心Ceph客户端会受到影响。

在生产环境中，采用基于Ceph存储集群的OpenStack高可用集群架构具有很多优势：首先，Ceph是一种开源分布式的存储集群软件，采用Ceph作为OpenStack集群的后端存储，在成本上相对传统企业级动辄上百万的存储阵列要实惠很多；其次，Ceph天生具备大规模集群高并发访问的优势，其节点越多优势越明显，非常适合大规模和海量数据存储的业务场景；Ceph存储集群完全采用Scale-out的形式扩容，避免了用户在存储扩容时性能瓶颈的顾虑；此外，Ceph提供的文件系统存储、块存储和对象存储可以同时满足用户不同的数据存储需求；其强壮的稳定性和数据自我恢复能力也是Ceph存储集群特有优势。不过，相对传统企业级存储阵列和SAN存储网络，Ceph依然很年轻，而且在Ceph较长一段时间的发展过程中，虽然其理论依据已经非常成熟，但是其科研院校的出身背景使得其在企业关键业务系统数据存储领域的使用却很少。正是OpenStack的出现带来了Ceph在企业应用中的普及，因此企业在使用Ceph存储集群为OpenStack提供后端存储时，需要投入相当多的人力对Ceph进行持续的研究跟进，方能解决突发的Ceph存储集群故障问题。

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服务分离到独立集群中部署以实现服务物理隔离的方案很可能会被直接淘汰，因为容器技术的特点之一便是服务隔离。