OpenStack架构
v0.2: 2013-04-08
添加服务架构说明
v0.1: 2013-04-02
完成基于folsom版本的初始版本
1.1
组件
目前（folsom版本），OpenStack包括7个核心部件，包括前端面板、计算、对象、镜像、鉴权、网络和块存储。各部分功能为
l
前端面板 项目名称为Horizon，为所有的OpenStack服务提供web前端接口界面。利用web界面，可以进行大部分的云操作，包括运行实例、分配IP和设置访问控制等。
l
计算 项目名称为Nova，提供虚拟机服务。基于Nova，HP和Rackspace都开发有商用的计算服务方案，同时在Mercado Libre和NASA（发起人）等公司内部都有使用。
l
对象 项目名称为Swift 允许储存或获取文件（但不能像文件服务器一样挂载目录）。基于Swift，数家公司开发了商业的存储服务方案，包括KT，Rackspace（发起人）和Internap。Swift同时在多家大型企业内部应用负责数据存储。
l
镜像 项目名称为Glance，提供登记和虚拟机镜像的管理，这些镜像主要是支持计算服务的。
l
鉴权 项目名称为Keystone，为OpenStack所有的服务提供认证和授权，同时提供了服务的登记管理。
l
网络 项目名称为Quantum，在网络接口设备之间提供连接服务。允许用户创建自由网络并挂载端口。架构开放，支持插件。从Folsom版本时引入。
l
块存储 项目名称为Cinder，为guest虚拟机提供永久性块设备，前身为nova-volume。所提供的块存储并非类似NFS或CIFS share的文件系统。从Folsom版本时引入。
与Amazon的AWS相比，OpenStack大部分的工具和API等都有很好的兼容性。包括
l
Nova在概念上类似EC2。可以有多种方式来支持EC2的API。
l
Swift在概念上类似于S3.在WSGI中间件上实现了部分S3 API。
l
Glance提供了Amazon的AMI登记服务类似的很多特性。
l
Cinder提供了类似于EBS的块设备。
1.2
架构
1.2.1
概念架构
OpenStack在整体设计上是“提供大量的可扩展的云服务的操作系统”，为了实现这点，各个组成的服务被设计一起协作提供“架构即服务（IaaS）”。这些协作通过服务提供的API之间进行操作实现。这些API允许服务之间的调用，并且相互之间松耦合。
概念架构如图表 1所示。
其中，Horizon提供用户的web前端；Nova存储和获取虚拟机，并且在Glance中维护元数据；Quantum为Nova提供虚拟网络；Cinder为Nova提供块存储；Glance在Swift中保持实际的虚拟机硬盘文件；所有的服务都需要Keystone进行认证。
1.2.2
逻辑架构
逻辑架构比概念架构复杂的多。图表 2中给出了最常见的一些架构。
用户可以通过Horizon跟其他服务交互，或者通过其他服务提供的API。
所有的服务都需要通过Keystone来进行认证。
部分服务通过公开的API跟其他服务进行交互。
1.2.3
服务架构
图表 3 服务和通信架构
1.3
Horizon-前端面板
Horizon是一个模块化的Django web应用，它为用户和管理员提供访问OpenStack服务的界面接口，如图表 2。
跟大部分的web应用类似，Horizon的架构比较简单：
l
Horizon一般通过Apache中的mod_wsgi进行部署。它的代码独立成为一个可重用的python模块，包括大部分的逻辑（跟不同的OpenStack API交互）和展示层（为不同站点提供容易的定制）。
l
一个数据库。因为大部分数据都是依赖自其它服务，自身存储的数据很少。
从网络架构的角度，Horizon服务需要是用户可访问的，同时能跟其他服务的公开API交互。如果同时需要一些管理功能（例如，管理其他服务），则Horizon需要能够访问到其他服务的管理API（这些API一般是用户不能直接访问的）。
1.4
Nova-计算
Nova是最复杂，同时也是最分散的一个组件。该组件包括大量的进程合作来把用户的API请求发给运行中的虚拟机。包括如下的进程：
l
Nova-api 接受和响应终端用户的计算API请求。支持OpenStack的计算API，Amazon的EC2 API和一些特定的管理API（给超级用户提供管理操作）。并且发起大部分的协调（orchestration）操作，比如运行一个虚拟机实例。此外，还包括对策略的支持（主要是配额检查）。
l
Nova-compute 主要是个工作守护进程（worker daemon），通过hypervisor的API（包括XenServer/XCP的XenAPI，KVM和QEMU的libvirt，VMWare的VMWareAPI等）来创建和关闭虚拟机实例。进程要做的事情很复杂，但是工作过程却比较直观：不断从队列中获取请求并响应，执行一系列的系统命令（例如运行一个KVM实例），同时更新数据库的状态。
l
Nova-volume 负责管理为计算实例提供创建、挂载和卸载永久性存储（类似于Amazon的Elastic Block Storage）。该进程支持很多类型的存储，包括iSCSI、Ceph中的Rados Block Device。新出现的Cinder项目将最终取代Nova-volume，在Folsom版本中，两者提供了类似的功能。
l
Nova-schedule 该进程在概念上是Nova中最简单的一个进程：从队列中获取创建虚拟机实例的请求，并且决定在哪里运行它（特别的，运行在哪一台物理机上）。
l
Queue 提供一个中央的hub，来在各个daemon之间传递消息。基于RabbitMQ实现，但同时支持任何兼容AMPQ消息的queue机制（包括Apache Qpid和Zero MQ）。
l
SQL数据库 存储架构中大部分的创建和运行时状态。包括可用、在用、网络可用的实例类型和项目等。理论上，Nova可以支持被SQL_Alchemy支持的任意数据库，目前广泛应用的包括sqlite3（推荐仅用于测试和开发）、MySQL和PostgreSQL。
l
Nova还提供了一些控制台服务，让用户可以通过一个proxy来访问虚拟实例的控制台。包括若干daemon（nova-console、nova-vncproxy和nova-consoleauth）。
Nova跟OpenStack大部分的其他服务都有交互。例如需要KeyStone提供认证、Glance提供镜像管理、Horizon提供web接口。与Glance的交互是核心。API进程可以上传和查询Glance，同时nova-compute可以通过Glance下载镜像以运行。
1.5
Swift-对象
Swift在架构上也是分布式的，以避免单点故障（single point of failure）和支持横向扩展，包括如下的子组件。
l
Swift-proxy-server 接受通过OpenStack对象API或原始HTTP的来访请求。接受包括文件上传、元信息修改和容器创建（container creation）。另外，为web浏览器提供文件或列出容器服务。该自组件通常采用可选的cache（一般部署memcache）来提高性能。
l
Account servers 管理被对象存储服务（object storage service）定义的账户。
l
Container servers 管理在对象储存服务（object store service）中容器（例如文件夹）的映射。
l
Object servers 管理存储节点上的实际对象（例如对象）。
此外，还有一些周期性的进程，负责大数据仓库中一些管理维护工作。其中最重要的是冗余服务（replication services），来确保cluster中数据的一致性和可用性。其他的周期性进程包括审计（auditors）、更新（updaters）和收获（reapers）。
对象仓促可以通过HTTP来提供静态的网页或对象。例如图像、多媒体等。
认证是通过可配置的WSGI中间件来负责的，即Keystone。
1.6
Glance-镜像
Glance组件的架构从Cactus版本以来就一直很稳定。最大的改变包括添加了认证。Glance主要包括四个主要部分：
l
Glance-api 接受镜像API调用，包括发现镜像、获取镜像和存储镜像等。
l
Glance-registry 存储、处理和获取镜像的元数据（包括尺寸、类型等）。
l
数据库 存储镜像的元数据。数据库类型可选（i一般推荐MySQL或SQlite）。
l
镜像文件的存储 一般镜像存储是在Swift中，但这是可以配置的。Glance支持文件系统、RADOS块设备、Amazon S3和HTTP。但部分仅支持读操作。
类似Swift，Glance中也包括一些周期性进程来支持caching和冗余等。
Glance在整个OpenStack的概念架构上，起到了IaaS中的中心作用。它接受用户或Nova对镜像的请求API，并且存储磁盘文件到对象服务Swift中。
1.7
Keystone-鉴权
Keystone提供了一个对OpenStack中策略（policy）、登记（catalog）、口令（token）和认证（authentication）的支持。
l
处理API请求，包括提供可配置的登记、策略、口令和身份服务。
l
每个Keystone的功能，后面都是一个可插拔式（pluggable）的后端，从而可以采用多种不同的服务。大部分支持的标准后端包括LDAP、SQL和Key Value Store（KVS）。
Keystone一般常被用来提供认证服务。
1.8
Quantum-网络
Quantum试图在OpenStack其他服务（大部分情况下是Nova）管理的接口设备之间提供“网络连接即服务（network connectivity as a service）”。Quantum允许用户创建自由的网络，同时将接口连接上去。跟OpenStack中很多服务类似，Quantum的架构也是可配置的，支持插件（plug-in）。这些插件适应不同的网络设备和软件。因此，Quantum的架构和部署都是可以快速调整的。
l
Quantum-server 接受接受API请求，转发给合适的Quantum插件上。
l
Quantum插件和代理 执行实际的操作，包括插上、拔下端口、创建网络、划分子网和管理IP地址。这些插件和代理可以来自不同的提供商。Quantum自身支持或已配置的插件和代理包括Cisco虚拟和物理交换机，Nicira的NVP产品，NEC OpenFlow产品、Open vSwitch、Linux bridging和Ryu网络控制器。Midokua提供了一个插件来帮助整合。常见的代理包括L3、DHCP和其他指定的插件代理。
l
大部分情况下，Quantum采用一个消息队列来在Quantum-server和各种代理之间传递消息，同时采用数据库来为一些特定插件存储网络状态。
Quantum大部分交互都是跟Nova进行的，为虚拟机提供网络连通服务。
1.9
Cinder-块存储
Cinder将nova-volume服务单独剥离出来，提供永久性块存储服务。提供API来支持操作存储卷、存储类型和快照等。
l
Cinder-api 接受API请求，并转发给cinder-volume。
l
Cinder-volume 通过读写Cinder数据库来响应请求，包括维护状态、跟其他进程打交道、提供软件和硬件等。通过驱动层，可以跟不同类型的存储设备交互，包括IBM、SolidFire、NetApp、Nexenta、Zadara、Linux iSCSI等。
l
Cinder-scheduler 选取最优的块设备节点来创建存储卷。
l
Cinder采用一个消息队列来在Cinder各个进程之间传递消息，同时采用数据库类存储存储卷状态。
与Quantum类似，Cinder大部分交互都是跟Nova进行的，为虚拟实例提供存储服务。
1.10
未来版本中的部件
这些项目可能在今后版本的OpenStack中出现，包括
Ceilometer 提供一些测量（metering）信息，让提供接口展现OpenStack中的一些内部活动。该项目并非计费项目。要实现计费，需要测量、评估和计费。该项目让用户可以更好的了解哪些操作被执行了，评估则负责价格和条目、计费则计算费用，并发给用户。
Heat 提供REST API来协调多个实现标准的云应用，例如ASW的CloudFormation。
1.11
参考
