OpenStack架构分析与实践
OpenStack以每年两个版本的速度不断迅速演进，所以对于OpenStack的架构而言，也是不断向前发展的。回顾一下E版本的OpenStack，它只有5个组件：Nova、Galnce、Swift、Horizon和Keystone；当发展到F版本后，其核心组件发展到了7个，比E版本多了Neutron和Cinder两个组件，它们分别实现Compute Network和Compute Volume的功能，但是从后续的发展中可以看出，它们远远超出了Compute Network和Compute Volume所支持的功能。
一、业务架构设计思路
OpenStck做的比较好的一点就是架构设计比较通过，对于不同的模块，其业务架构设计方面一般满足以下设计思路：
• REST API接收外部请求
• Scheduler负责调度服务
• Worker负责任务分配
• Driver负责任务实现
• 消息队列负责组件内部通信
• 数据库服务
接下来分别介绍一下上述设计思路。
REST API接收外部请求。OpenStack中的逻辑关系是要各个组件之间的信息传输来实现的，而不同的组件间的消息的传递与交互是通过各个组件的REST API进行的。可以理解为，REST API是所有服务的入口，它对外接收客户发来的REST请求，对内实现请求转发。
REST API还有一个好处就是可以对外隐藏内部实现细节，提供统一的访问接口，由于其模块化的设计，REST API可以很方便的与第三方系统进行集成；在大规模环境下，REST API可以采用分布式部署的方式，从而极大的提高了API的高可用。
Scheduler负责调度服务。这里所说的Scheduler只是一个统称，并不是说每一个组件中都有一个xxx-scheduler的服务，但是大部分组件中都有一个提供类似功能的服务，它可能是单独存在，也有可能是与其他的服务柔和在一起共同提供服务。
我们以Nova为例来说明一下Scheduler的调度服务。当我们创建虚拟机时，往往需要选择出合适的计算节点，然后在这个节点上进行虚拟机的创建，那么，这里对节点的筛选就需要借助nova-scheduler的调度功能。
Worker负责工作服务。上面提到的Scheduler只会负责任务的分配，它有点类似于公司中的项目经理，它会统筹大家的工作，把工作分配给合适的人去做，而Worker才是真正执行相关任务的服务。例如：在Nova中，Worker就是nova-compute服务；在Heat中，heat-engine就是Worker，在许多组件中，我们可以把xxx-engine看作是不同的Worker。
当把负责调度的Scheduler和负责工作的Worker分开后，就使得OpenStack更加容易扩展，这也使得我们可以从不同的方面考虑如何去提高系统的并发性与应对大规模请求的场景。
Driver负责任务实现。为了拥抱不同的技术，OpenStack采用了大量的Driver，例如，在Nova组件中，nova-compute服务可以支持多种不同的Hypervisor，用户可以根据需要通过配置文件进行配置，当修改完配置文件后，只需要重新启动一下服务即可；在Glance组件中，它支持多种存储后端，如：本地文件系统、Ceph、Cinder和Swift等。
其实说白了，之所以可以支持各种不同的Driver，是因为不同的组件会有各自的Driver框架，用户只需要把符合需求的Driver配置好即可使用。Driver框架的存在，也降低了上层开发人员对底层知识的要求。上层开发人员无需关心底层Driver是如何实现的，关于Diver的实现完全可以交给专的人员去做。
消息队列负责组件内部通信。通过前几章节的学习相信大家对这个并不会感到陌生，消息队列的产生，极大的解耦了同一组件的不同服务，使得它们可以实现分布式独立部署。在生产中，我们经常使用的消息队列调用方式有：同步调用和异步调用。
同步调用，从调用关系上来看，是REST API直接调用组件内部服务，以Nova为例，同步调用就是nova-api服务直接调用nova-scheduler且等待返回结果。在这种方式下，当后端面没有返回响应时，REST API服务将一直处于等待状态。
异步调用，与同步调用相反，即，当REST请求发出后，发送方并不会等待接收方的响应而是直接返回。
数据库服务。OpenStack中每一个组件都需要维护各自的状态信息，所以各个组件后端都会有一个数据库服务与之对应。
二、部署架构设计思路
模块化的业务架构极大的将不同组件进行了解耦，正因如此，也使得同一组件不同服务之间实现解耦。这样以来，非但不同的组件可以实现分布式部署，就连同一组件的不同服务的也可以实现分布式部署，近几年随着容器技术的兴趣，OpenStack组件分离及服务模块化的设计更加容易实现容器化部署。
提示：社区中已经有一个针对OpenStack部署的较为成熟的容器化部署方案，这个项目的名字叫Kolla。
抛开容器化，我们看一下OpenStack有着怎么样的一个部署上的设计思路。
上一节是从逻辑关系及相互之间的通信关系分析了OpenStack的业务设计架构，属于上层的软件逻辑架构，众所周知，OpenStack是一个分布式的系统，它就得解决上层逻辑与底层物理架构映射的问题，除此之外，还需要考虑如何才能合理的将不同组件安装到实际的物理服务器上、同一组件不同服务应该如何进行部署等问题。
OpenStack的部署粗略的可以分为两种：
All-in-One部署。适用于开发环境、学习环境。因为OpenStack发展速度比较快，如果我们对某个组件比较感兴趣，可以通过此种方式快速搭建一套含有此组件的OpenStack环境。目前关于快速搭建的工具主要有：DevStack 和RDO两种。另外，通过Fuel也可以实现快速搭建，但这种方式在使用方面比较笨重。
分布式部署。也可以称作集群部署，即，将不同的组件及同一组件的不同服务分别进行部署，可以部署在同一个物理服务器上，也可以根据实现需要部署到不同的物理服务器上。
虽然我们这里提到了两种部署方式，但是OpenStack的部署也不是一成不变的，而是需要根据实际的生产实践需求设计不同的落地方案。在真正的生产中部署时，需要对OpenStack中的计算、网络、存储等资源提前进行规划，针对不同的规划方案，又延伸出两种部署架构：简单部署架构和复杂部署架构。
简单部署架构
这是一个满足简单生产环境的简易部署方案，对于此种方案的部署而言，一般节点角色较为简单，网络设置也不是特别复杂。其架构设计如下：
1. 节点角色
仅包含控制节点、计算节点、存储节点。对于OpenStack的大多数服务而言，它们都部署在控制节点上，例如认证服务、镜像服务等，控制节点也可以称为管理节点，主要用于调度本节点及其他节点上的相关服务；计算节点是指虚拟机运行时所在的物理服务器；存储节点主要用于提供存储服务，特别像Ceph这种分布式存储，一般会将存储单独部署在存储节点上。
这里没有提到网络节点，实际上，网络节点在OpenStack中是非常重要的，网络出了问题，那么很多服务都将无法正常运行。为什么这里没有单独提到“网络节点”这一角色呢，因为网络节点往往可以与控制节点部署在一起。另外，存储节点也是必需单独部署的，这需要看我们使用是什么样的存储结构，一般来说，存储节点也是可以与计算节点部署在一起的，例如，当我们使用Sheepdog作为后端存储时，可以将之与计算节点部署在一起。
2. 网络部署
虽然网络既可以单独部署，也可以与其他的节点一起部署，这里还是需要单独来说明一下，因为网络规划的好处，极大的影响了整个云平台稳定性、安全性与可维护性。
这里我们暂且将部署网络服务的节点称为网络节点吧（虽然它有可能与上面提到的节点角色有所重叠）。网络节点部署时一般分为三类：管理网、存储网、数据网和上联网。
管理网。它负责管理节点与其他节点间的通信，管理节点可以通过这个网络实现对其他服务的管理。
存储网。是计算节点访问存储节点的网络，其他节点向存储设备中读写数据时都会走这个网络。
数据网。也称作内部网，用于OpenStack内部组件通信使用。在云平台中的同一个物理服务器上，可能同时存在着大量的虚拟机，不同虚拟机之间需要进行通信，那么诸如此类的内部通信，就需要经过数据网。
上联网。也有人称之为外网，可以对外提供服务的网络。
以上就是简单部署架构，从这里看，虽然是简单部署，但还是遵循着分布式部署的思想，组件、服务分布式部署，网络按功能进行划分并进行部署。上述简单部署可以满足对云平台要求不高的用户，在上述部署方案中，并没有考虑高可用的问题，也没有考虑多区域的问题等高级而又复杂的特性。
3.复杂部署架构
此种部署方式可以说是在前一种部署方式的基础之上进行设计与实现的。针对上述简单部署架构，在复杂架构设计时，首先需要考虑的问题就是高可用问题，高可用的实现方式有多种，可以将同一组件部署到不同的节点上来实现高可用，也可以通过第三方工具实现高可见。Pacemaker + Cronsyc是一种较为常见的高可用方式，前者实现对资源的管理，后者为前者提供通信服务。容器技术出现后，社区也采取了积极的态度，借助K8S的高可用架构也可以实现OpenStack的高可用，此种部署方案需要将OpenStack的组件部署到容器中。
另外，还需要考虑大规模高并发的情况。针对大规模的场景，我们需要把管理服务分别部署到不同的物理节点上，还可以考虑将同一组件的不同服务也进行剥离实现分布式部署，这样以来，就可以很容易的实现对OpenStack不同服务进行水平扩展。如：某一时刻有大量创建虚拟机的请求到达，我们可以对水平扩展相关的Nova服务（nova-api、nova-scheduler、nova-conductor和nova-compute）以提高应对高并发的能力。
三、平台用户角色设计
OpenStack中功能众多，可以为我们提供IaaS服务，而一个完整的IaaS服务需要提供以下功能：
• 平台可以进行计费
• 允许平台的所有者在平台中进行服务注册
• 允许开发人员、运维人员各自创建并存储他们的自定义镜像
• 允许运营管理员配置与修改平台的基础架构
基于上述功能，我们可以将OpenStack最基本的平台用户角色表示为 如图所示。
图： 用户角色及功能对应关系示意
平台中共有四类用户角色：开发人员，运维人员、Owner和运营人员，并每不同的人员分配了各自所需的功能。
对于一个完整的云平台而言，在设计方面离不开上面所提到的三类设计。友好的角色设计、良好的业务架构及灵活可变的部署方式，是云平台设计之初就必需仔细考虑的问题，三者缺少一者，必将使得平台的易用性和可操作性大打折扣。
提示：对于角色来说，不同的云平台可以根据自身情况自定义一些角色，从而达到对不同人员进行资源隔离的目的，从而也增加了云平台的安全性。