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负责工作服务。上面