Openstack 架构

因为Openstack 已经越来越成熟，有的方面虽然仍然很简单，但是，某些方面也越来越复杂。从一个运维人员的方面看，因为给出了默认的选项和云服务的飞速发展，每一个服务已经变得越来越容易部署。Openstack的架构已经变得越来越来越复杂，添加了新的服务，并且他们之间的集成也变得越来越可能。


Openstack 组件：
Openstack 当前有七个组件：计算（Compute)，对象存储（Object storage)，认证(Identity)，面板(Dashboard)，块存储（Block Storage)，网络(Network)和镜像(Image)服务。我们详细看一下每个的作用：
存储：
Object storage（代号：Swift) 允许你存储或者检索文件。但是不是以文件系统来组织的。
Image store(代号：Glance) 为虚拟镜像，提供目录和仓库，虚拟镜像是使用在计算节点中。
Block Storage(代号：cinder) 为客户VMS提供可持久的块存储。

Compute(代号： Nova) 提供虚拟服务器。
Dashboard(代号：Horizon) 提供模块化的WEB界面。
Identity(代号：Keystone) 为所有服务提供认证。
Network (代号：Neutron 原为：Quantum)  为其他Openstack服务，大多数是 nova ， 提供 网络连接服务。

除了这几个主要的项目，还有一些其他的非核心项目。


概念架构：
Openstack是为了实现一个大规模可扩展的云操作系统。为了达到这个目标，每一个下层的组件都设计成：Iaas.所有组件的集成是通过每个服务提供的API来实现的。这些API允许每个服务使用另外的服务，用户可以通过这些API来连接服务，同样也可以通过这些API来断开服务。
下面是一张概念图：

Dashboard为其他的服务提供web界面。
计算节点 存储和取回 虚拟盘（即：Images）、关联元数据 都是通过Image store(Glance)
Neutron 为计算节点提供网络
Block Storage为计算节点 提供storage volumes
Image store 实际上存储了object storage中的 虚拟盘文件。
所有的服务认证通过 identity

但是 openstack并不是“要不全部署，要不不部署”，我们可以选择其中的一些组件，或者替换一些组件进行部署。


逻辑架构：
逻辑架构远比概念架构复杂。因为openstack是面向服务的，所以结构图很快因为各个组件之间的复杂连接而变得混乱。下面的图像只是一种可能的架构。


这张图像在以下几个方面是和上面的概念图一致的：
用户和各个服务的交互可以通过horizon或者直接api；
所有的认证都是通过keystone
每个服务都可以通过api与其他服务交互。


接下来，我们就每个服务进行详细的介绍：

Dashboard组件
horizon 是一个基于django的为用户提供其他服务web操作接口的服务。


这个接口有以下几个页面：
配额 和 使用信息
用来操作虚拟机的实例
block storage的管理：用来 创建 删除和连接  vloume 。
image 和snapshot的上传和虚拟镜像的管理，主要用来备份和 新建实例。
管理keypairs 和 安全组。

horizon通常通过apache的mod_wsgi进行部署，代码被分割成一个带有大部分逻辑的可以重用的python模块，主要是用来和openstack的api进行交互，另外还有一个展示模块，主要是为了更加易于改动。

compute 组件
 nova 是openstack 最复杂和分散的一部分，大量的进程合作把终端用户的API请求转化到虚拟机的实际变化。
下面是一些比较突出的特点：
启动，停止或者重新为虚拟机（即实例）划分大小；
分配和移除公网IP地址。
连接和断开 block storage
增加，修改或者删除安全组
展示实例的控制台，
备份(snapshot)运行中的实例。

nova 和其他服务都有交互，但是最主要的是glance，因为nova 将从glance 上下载 image镜像，然后使用。

object store 组件
swift是用来提供大规模可扩展的存储，不像通常的文件服务器，他提供完全分布式的存储，每一个存储对象都会提供多份拷贝，他提供以下的用户功能：
存取文件
设置和修改对象的标签(即元数据）
实例化文件
提供静态web页面和文件对象。

swift 为了防止单节点的失败提供了分布式的架构，他包含以下几个方面：
swift-proxy-server，他可以上传文件，修改元数据，创建容器。提供文件和容器的列表。
通过object storage 服务定义的 账户管理服务器 管理账户，
容器服务器通过object storage服务管理容器（即 文件夹）
object server在storage节点上管理实际的对象（即 文件）。

同时还有许多进程来处理object store中日常性的事务。
最重要的是同步服务，保证了集群的可用性和可持久性。

Image store
image store 为用户和其他的服务提供了 虚拟镜像的中心（virtual images),主要功能为：
存储公共和私有的images，以便用户可以用来创建instance
用户可以查询可用的images
传递images到nova服务来启动instance
存储运行中instances的snapshots（备份)
glance-registry 存取，运行，images的元数据（例如，大小，种类）。
一个实际images 文件的存储仓库，在上面的图形中我们说swift是文件的存储仓库，但是这是可以配置的。glance 支持常规的文件存储类型，但是有些是只读的。

同swift一样，他最重要的日常性服务也是同步服务。从图中我们可以看到glance是一个非常重要的组成部分。他接受来自images和nova的API请求，也可以将他的文件村组在object storage中，比如swift

Identity
keystone 为openstack 的令牌和认证提供了单节点的整合。

用于其他服务的用户认证和令牌

基于用户权限控制的用户和租户存储

提供服务的目录

创建适用于用户和服务的策略。

从架构上来说，keystone非常简单。

keystone 既处理API请求，又提供可配置的目录，策略，令牌和认证服务。

keystone提供了可扩展的后台俩允许不同的方式使用这个服务。

Block Storage

Cinder 是从nova中独立出来的项目。Block Storage的api允许对volume的操作，volume的种类（类似与compute flavors)和volume 快照

原文翻译自：http://www.solinea.com/blog/openstack-grizzly-architecture-revisited

但因为原文是介绍G版的，现在网络部分已经更改，所以这篇文章中没有加入网络部分。并且译者对原文做了较大的改动，省略了译者认为对初学者用处不大的部分。