OpenStack的架构详解(3)

3. OpenStack Compute架构

3.1 OpenStack Compute逻辑架构

OpenStack Compute逻辑架构中，组件中的绝大多数可分为两种自定义编写的Python守护进程(custom written python daemons)。

a) 接收和协调API调用的WSGI应用(nova-api, glance-api, etc)

b) 执行部署任务的Worker守护进程(nova-compute, nova-network, nova-schedule, etc.)

然而，逻辑架构中有两个重要的部分，既不是自定义编写，也不是基于Python，它们是消息队列和数据库。二者简化了复杂任务(通过消息传递和信息共享的任务)的异步部署。

逻辑架构图3-1如下所示：

3-1 OpenStack Compute逻辑架构

从图中，我们可以总结出三点：

a) 终端用户(DevOps, Developers 和其他的 OpenStack 组件)通过和nova-api对话来与OpenStack Compute交互。

b) OpenStack Compute守护进程之间通过队列(行为)和数据库(信息)来交换信息，以执行API请求。

c) OpenStack Glance基本上是独立的基础架构，OpenStack Compute通过Glance API来和它交互。

其各个组件的情况如下：

a) nova-api守护进程是OpenStack Compute的中心。它为所有API查询(OpenStack API 或 EC2 API)提供端点，初始化绝大多数部署活动(比如运行实例)，以及实施一些策略(绝大多数的配额检查)。

b) nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。其过程相当复杂，但是基本原理很简单：从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们。

c) nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商，比如，ISCSI和AoE。

d) Nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务，然后执行任务以操控网络，比如创建bridging interfaces或改变iptables rules。

e) Queue提供中心hub，为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是python ampqlib支持的任何AMPQ消息队列。

f) SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。理论上，OpenStack Compute能支持SQL-Alchemy支持的任何数据库，但是当前广泛使用的数据库是sqlite3(仅适合测试和开发工作)，MySQL和PostgreSQL。

g) OpenStack Glance，是一个单独的项目，它是一个compute架构中可选的部分，分为三个部分：glance-api, glance-registry and the image store. 其中，glance-api接受API调用，glance-registry负责存储和检索镜像的元数据，实际的Image Blob存储在Image Store中。Image Store可以是多种不同的Object Store，包括OpenStack Object Storage (Swift)

h) 最后，user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个OpenStack Compute界面来给应用开发者和devops staff类似API的功能。当前它是作为Django web Application来实现的。当然，也有其他可用的Web前端。