OpenStack入门以及一些资料之(五、Glance镜像)

来源:互联网 发布:剑三萝莉捏脸数据 编辑:程序博客网 时间:2024/04/30 08:30

注:本文内容均来自网络,我只是在此做了一些摘抄和整理的工作,来源均有注明。

0、简介及基本概念


简介:

     OpenStack Image Service(Glance)是IaaS的核心组件。它接受从终端用户或OpenStack计算组件发来的关于磁盘或server镜像、镜像metadata的API请求。它支持多样化的后端存储系统,包括了OpenStack Object Storage(Cinder)。
     Glance会运行一定数量的周期性进程以支持caching。复制(replication)服务确保集群的一致性和可用性。其它的一些周期性进程包括auditors,updaters,reapers。

基本概念:


1.Image identifiers                         

Image使用URI作为唯一标识,URL符合以下格式:

     <Glance Server Location>/images/<ID>
Glance Server Location是镜像的所在位置, ID是镜像在Glance的唯一标识。


2.Image Statuses                         共六种状态。

queued                                标识该镜像ID已经被保留,但是镜像还未上传。

saving                                  标识镜像正在被上传。

active                                    标识镜像在Glance中完全可用。

killed                                     标识镜像上传过程中出错,镜像完全不可用。

  deleted                                             Glance已经保存了镜像的信息,但是无法继续使用。在此状态下的镜像稍后将会被自动清除。

  pending_delete                                   类似于deleted,区别在于Glance还没有移除镜像数据。在此状态下的镜像是可以被恢复的。

状态之间的关系如下图:
Image status transition

3.Task Statuses

  • pending

    在Glance中保留task identifier。但此时还没有进程开始执行。

  • processing

    任务已被底层执行者选中,并且后端Glance根据任务类型开始执行对应的逻辑操作。

  • success

    表示该任务已成功运行。在任务的“result”域中会显示关于输出结果的更多细节。

  • failure

    表示在任务的执行过程中发生了一个错误,并且它不能继续执行下去。任务的“message”域展示了是什么错误。


4.Disk and Container format
Disk  Format:raw vhd vmdk vdi iso qcow2 aki ari ami
虚拟机镜像的磁盘格式是底层磁盘镜像的格式。Virtual appliance vendors have different formats for laying out the information contained in a virtual machine disk image.

Container Format:ovf bare aki ari ami
container格式表示虚拟机镜像是否在一个包括虚拟机的metadata文件格式中。
Note that the container format string is not currently used by Glance or other OpenStack components, so it is safe to simply specify bare as the container format if you are unsure

当disk format为aki ari ami时,disk format 和container format一致。

5.Image Registries

使用Glance,镜像metadata可以注册至image registries。

只要为image metadata提供了rest like API,任何web程序可以作为image registries与Glance对接。

当然,Glance也提供了参考实现。




1、组件及架构


Glance主要由三个部分构成:glance-api、glance-registry以及image store。

  • Glance-api接收REST API的请求,类似nova-api;

Glance-api在功能上与nova-api十分类似,都是接收REST API请求,然后通过其他模块(glance-registry及image store)来完成诸如镜像的查找、获取、上传、删除等操作,i默认监听端口9292。

  • glance-registry用于与MySQL数据库交互,用于存储或获取镜像的元数据(metadata);

Glance-registry用于提供镜像元数据相关的REST接口,通过glance-registry,可以向数据库中写入或获取镜像的各种数据,glance-registry监听端口9191。Glance的数据库中有两张表,一张是image表,另一张是image property表。Image表保存了镜像格式、大小等信息;image property表则主要保存镜像的定制化信息。

  • 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等第三方的商业组件。

x1




2、镜像缓存机制


     Glance中的镜像文件不管用什么样的方式存储,都是存储在server端,用户在创建实例的前要先从server端获取相应镜像,再到本地根据配置进行相关的处理。有些镜像文件非常的大,在从服务端传到客户端要花费大量的时间,使实例的启动变得非常慢,对于一些特定的应用来说会比较吃力,如果利用Glance的缓存机制,预先通过命令将特定的镜像进行缓存,缓存到需要的计算节点上会有很好的效果。对镜像进行缓存变相的增加了镜像存储的可靠性。
     本地缓存的另一个好处就是,你可以通过它实现镜像的base imag(或者叫金手指,差异镜像等)的功能。比如一些分布式自动化测试平台对于运行时间的要求是非常的高的就可以利用缓存功能。

     Glance的缓存服务是需要在配置文件中进行配置开启的。Glance缓存还提供了缓存,删除,根据配置的过期时间删除等众多的功能。





参考:

  1. OpenStack官方文档:  http://docs.openstack.org/developer/glance/
  2. OpenStack之Glance笔记(一):  http://blog.csdn.net/grandvalley/article/details/6658115
  3. OpenStack虚拟机创建过程中镜像格式的的变化过程:  http://www.openstack.cn/p358.html
  4. OpenStack Glance的镜像缓存机制介绍:  http://www.linuxidc.com/Linux/2013-05/84376.htm
0 0
原创粉丝点击