NOVA-GLANCE-SWIFT三者之间的关系.docx

NOVA GLANCE SWIFT三者之间的关系
总的来说，nova的各个组件是以数据库和队列为中心进行通信的，下面对其中的几个组件做一个简单的介绍：
Queue，也就是消息队列，它就像是网络上的一个hub，nova各个组件之间的通信几乎都是靠它进行的，当前的Queue是用RabbitMQ实现的，它和database一起为各个守护进程之间传递消息。
database存储云基础架构中的绝大多数状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。当前广泛使用的数据库是sqlite3(仅适合测试和开发工作)、MySQL和PostgreSQL。
nova-compute负责决定创造虚拟机和撤销虚拟机，通过运行一系列系统命令（例如发起一个KVM实例，）并把这些状态更新到nova-database中去，其过程相当复杂，但是基本原理很简单。
nova-schedule负责从queue里取得虚拟机请求并决定把虚拟机分配到哪个服务器上去。schedule的算法可以自己定义，目前有Simple （最少加载主机）,chancd(随机主机分配)，zone(可用区域内的随机节点)等算法。
nova-volume负责记录每一个计算实例，相当于一个计算请求吧，并负责创建，分配或撤销持久层容器(Amazon的，iSCSI，AoE等等)给这些compute instances。
nova -netwok负责处理队列里的网络任务。
nova-api守护进程是OpenStack Compute的中心。它为所有API查询提供一个入口，并且同时支持OpenStack API 和 Amazon EC2 API。
为了看看nova是如何工作的，我们可以以启动一个实例为例来进行说明，因为启动一个新的instance涉及到很多openstack nova里面的组件共同协作。

其中：
API：处理客户端的请求，并且转发到 Queue和Database中。
Scheduler：选择一个host去执行命令
nova-compute：启动和停止实例，附加和删除卷等操作
nova-network：管理网络资源，分配固定IP。
接下来就是真正的过程了，先从API开始：
API
例如我们输入一个命令：euca-run-instances-k test -t m1.tiny ami-tiny 它会执行以下操作：
查看这种类型的instance是否达到最大值
给scheduler发送一个消息（实际上是发送到Queue中）去运行这个实例。
Schedule
调度器接收到了消息队列Queue中API发来的消息，然后根据事先设定好的调度规则，选择好一个host，之后，这个instance会在这个host上创建。
Compute
真正去创建一个instance的操作是由Compute完成的，而这个过程中compute组件与Glance密不可分，如图所示：

接下来，需要了解一下Glance在OpenStack里面所起的作用了。
我觉得看图是最直观的了，所以要弄明白Glance在整个OpenStack项目中的角色，就再来看一张图。

可以看出，通过Glance，Opentack的3个模块被链接成了一个整体，Glance为Nova提供镜像的查找操作，而Swift又为Glance提供实际的存储服务，Swift可以看作是Glacne存储接口的一个具体实现。
以我个人的理解来看，Glance的功能类似虚拟文件系统VFS，Glance提供给用户，或者说是Nova，一个统一的操作接口，而至于具体存储的是在Swift上还是在Amazon S3上，使用者不必关心。
知道了Glance所起到的作用之后，再来看compute调用Glance的那张图，详细会更好理解。
glance-api主要是用来接受各种api调用请求，并提供相应的操作。
glacne-registry用来和MySQL数据库进行交互，存储或者获取镜像的元数据，注意，刚才在Swift中提到，Swift在自己的Storage Server中是不保存元数据的，这儿的元数据是指保存在MySQL数据库中的关于镜像的一些信息，这个元数据是属于Glance的。
image store也就是图中的”Swift of S3″，是一个存储接口，通过接口，glance可以获取镜像，image不仅仅支持OpenStack自己的Swift格式的镜像，也同时支持Amazon S3等其他的镜像。
以上就是我对OpenStack三大组件的一些理解，这些内容有的直接来源于网络，有的是我看完资料后的总结，由于看了很多资料，而且没有保存链接，没法一一列举了
-------------
Glance项目提供虚拟机镜像的查找，注册和重现，使用RESTful接口接受虚拟机镜像管理的查询请求。
在程辉的一篇博客中，有Glance的架构介绍，其中有上面的图。作者将Glance-API和Glance-Registry解释为调用关系是不正确的。这两个服务是独立运行的服务，在sbin目录下，看过glance部署文章的同学知道，glance部署的最后一步就是启动glance-api和glance-registry这两个服务。这两个服务作为WSGI，会分别响应来自用户的RESTful请求，而不是图上所暗示的glance-api响应请求，然后调用glance-registry进行image元数据在数据库的注册。
Glance对外服务的入口主要有2个
1、Glance-API：主要负责接收响应镜像管理命令的Restful请求，分析消息请求信息并分发其所带的命令（如新增，删除，更新等）。默认绑定端口是9292。
2、Glance-Registry：主要负责接收响应镜像元数据命令的Restful请求。分析消息请求信息并分发其所带的命令（如获取元数据，更新元数据等）。默认绑定的端口是9191。
在/etc/glance目录下有两个文件glance-api-paste.ini和glance-registry-paste.ini，两个入口服务启动后，会用配置文件分析模块读取这两个文件，执行其文件中标注的需要执行的WSGIapp和middleware。简述paste文件中的概念：
app：实际处理REST API请求的python类。
filter:一种装饰器，为app提供一层封装，在app处理请求之前会先调用filter的对象。
pipeline:所对应的对象是对filter和app的的封装，他将多个filter和某个app绑在一起，在app处理请求之前要先通过pipline指定的在app之前的filter的处理。
---------------------------
OpenStack虚拟机创建过程中镜像格式的的变化过程
 Glance用来作为独立的大规模镜像查找服务，当它与Nova和Swift配合使用时，就为OpenStack提供了虚拟机镜像的查找服务，像所有的OpenStack项目一样，遵循以下设计思想：
· 基于组件的架构 - 便于快速增加新特性
· 高可用性 - 支持大负荷
· 容错性 - 独立的进程地址空间，避免串行错误
· 开放标准 - 对社区驱动的API提供参考实现
1. Glancle架构
Glance主要由三个部分构成：glance-api、glance-registry以及image store。
· (1) Glance-api接收REST API的请求，类似nova-api；
Glance-api在功能上与nova-api十分类似，都是接收REST API请求，然后通过其他模块（glance-registry及image store）来完成诸如镜像的查找、获取、上传、删除等操作，i默认监听端
口9292。
· (2) glance-registry用于与MySQL数据库交互，用于存储或获取镜像的元数据（metadata）；
Glance-registry用于提供镜像元数据相关的REST接口，通过glance-registry，可以向数据库中写入或获取镜像的各种数据，glance-registry监听端口9191。Glance的数据库中有两张表，
一张是image表，另一张是image property表。Image表保存了镜像格式、大小等信息；image property表则主要保存镜像的定制化信息。
· (3) image store是一个存储的接口层，通过这个接口，glance可以获取镜像，image store支持的存储有Amazon的S3、OpenStack本身的Swift，还有诸如ceph，sheepdog，GlusterFS等分布式存储。
Image store是镜像保存与获取的接口，它仅仅是一个接口层，具体的实现需要外部的存储支持，目前，支持的接口有Amazon S3、GlusterFS、Swift，sheepdog，ceph等。
    Glance体系结构如下图所示，通过glance，OpenStack的三个模块计算组件（nova）、镜像管理组件（glance）、存储组件（swift，ceph，sheepdog等）被连接成一个整体，Glance为Nova提供镜像的查找等操作，而存储组件又为Glance提供了实际的存储服务。而Swift，ceph，gluster，sheepdog等又是Glance存储接口的一些具体实现，Glance的存储接口还能支持S3等第三方的商业组件。

4