《OpenStack高可用集群（下册）：部署与运维》—11.2 OpenStack集群高可用部署架构设计

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

对于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-3　查看主板支持最大内存

图11-4　OpenStack高可用部署实验环境架构

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

图11-5　控制节点VMware虚拟机配置

为了能够在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服务器出厂时虚拟化支持功能均会打开，但是仍然建议进行检查，因为后面很多与虚拟化相关的奇怪问题可能均与主板虚拟化功能是否开启有关。

图11-6　计算节点VMware虚拟机配置

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