您现在的位置 >> Hadoop教程 >> Hadoop实战 >> 专题  
 

OpenStack虚拟机创建过程中镜像格式的的变化过程

【作者:Hadoop实战专家】【关键词:虚拟机 镜像 创建 OpenStack 】 【点击:10024次】【2013-11-2】
Glance体系结构如下图所示,通过glance,OpenStack的三个模块计算组件(nova)、镜像管理组件(glance)、存储组件(swift,ceph,sheepdog等)被连接成一个整体,Glance为Nova提供镜像的查找等操作,而存储组件又为Glance提供了实际的存储服务。 8. 2. 3. 2.  

相关热门搜索:

大数据标签:bigdata

问题导读:

1、Glance由哪些部分构成?
2、如何用命令创建实例?

前言
Glance用来作为独立的大规模镜像查找服务,当它与Nova和Swift配合使用时,就为OpenStack提供了虚拟机镜像的查找服务,像所有的OpenStack项目一样,遵循以下设计思想:
基于组件的架构 - 便于快速增加新特性
高可用性 - 支持大负荷
容错性 - 独立的进程地址空间,避免串行错误
开放标准 - 对社区驱动的API提供参考实现

1. Glancle架构
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等第三方的商业组件。

11.png (20.24 KB, 下载次数: 0)

  

2014-6-12 13:51 上传

2. Openstack创建虚拟机的过程中镜像文件格式的变化过程
这里通过OpenStack的horizon组件来创建一个m1.small的virtual machine,来详细分析下镜像格式的变化以及glance底层具体执行的哪些操作。

(1)首先看一下Glance管理的镜像,如果采用local storage,glance将镜像文件默认存储到/var/lib/glance/image目录下,这里我们选择c036d689-0336-4fcd-a8e0-4aed4dd5e420这个镜像来作为创建虚拟机的模板,此镜像是通过如下命令添加的,因此在horizon中显示的名称为:Precise x86_64。

1. glance add name="Precise x86_64" is_public=true

2. container_format=ovf disk_format=qcow2

3. < ubuntu-12.04-server-cloudimg-amd64-disk1.img

复制代码

1. ubuntu@compute-63-02:/var/lib/glance/images$ ll -alh

2. total 2.5G

3. drwxr-xr-x 2 glance glance 4.0K Jan 30 01:30 ./

4. drwxr-xr-x 6 glance glance 4.0K Dec 27 21:11 ../

5. -rw-r----- 1 glance glance 768M Dec 27 04:31 5b298155-8bcf-442f-bc83-bc52f3fe5be9

6. -rw-r----- 1 glance glance 712M Jan 30 01:31 8760d55b-0d91-4987-8980-d6659c7856ab

7. -rw-r----- 1 glance glance 223M Dec 25 03:58 c036d689-0336-4fcd-a8e0-4aed4dd5e420

8. -rw-r----- 1 glance glance 768M Dec 27 04:44 d771b2ce-9310-4757-8ec5-d80f8d1e1712

复制代码

通过qemu-img info命令,先看一下镜像文件的大小和格式如下:

1. ubuntu@compute-63-02:/var/lib/glance/images$ sudo qemu-img info c036d689-0336-4fcd-a8e0-4aed4dd5e420

2. image: c036d689-0336-4fcd-a8e0-4aed4dd5e420

3. file format: qcow2                                       //qcow2格式的镜像

4. virtual size: 2.0G (2147483648 bytes)                    //镜像文件大小的上限为2G,实际使用了223M

5. disk size: 223M

6. cluster_size: 65536

复制代码

(2)通过horizon创建m1.small(具体配置为:1vcpu,2G memory,10G root disk,20G extra volume)的virtual machine
新创建的虚拟机存放在/var/lib/nova/instances目录下,该目录的大体结构如下:

1. ubuntu@compute-63-12:/var/lib/nova/instances$ ll

2. total 32

3. drwxr-xr-x 8 nova nova 4096 Feb 28 21:39 ./

4. drwxr-xr-x 10 nova nova 4096 Dec 25 01:07 ../

5. drwxrwxr-x 2 nova nova 4096 Feb 28 21:39 _base/                    //相当于镜像文件的cache目录,在此host上创建的所有的vm,都会先cacha到这里

6. drwxrwxr-x 2 nova nova 4096 Jan 8 05:56 instance-00000022/         //instance-xxxxx新创建的虚拟机

7. drwxrwxr-x 2 nova nova 4096 Feb 28 03:40 instance-00000034/

8. drwxrwxr-x 2 nova nova 4096 Feb 28 04:02 instance-00000037/

9. drwxrwxr-x 2 nova nova 4096 Feb 28 21:39 instance-0000003a/

10. drwxrwxr-x 2 nova nova 4096 Jan 30 01:30 snapshots/                 //此host上虚拟机对应的快照文件

复制代码

通过查看nova-compute.log可以看到vm创建过程中,镜像文件格式的变化过程,下面总结了下,具体参见下图。

22.jpg (59.74 KB, 下载次数: 0)

  

2014-6-12 13:53 上传

从glance中得知,有个virtual size =2G的qcow2格式的镜像文件Precise x86_64,它在glance中的ID=c036d689-0336-4fcd-a8e0-4aed4dd5e420。

当Nova Compute接收到vm创建的请求时,通过以下步骤完成一个VM的创建过程:
(1)步:
从vm的描述文件中获得所使用的image文件的ID,然后向Glance发起索取image文件的HTTP请求,结果是image文件从Glance的存储节点下载到发起请求的host机器上,即:/var/lib/nova/instances/_base目录下:

1. ubuntu@compute-63-11:/var/lib/nova/instances/_base$ ll -alh

2. total 4.0G

3. drwxrwxr-x 2 nova nova 4.0K Feb 28 21:39 ./

4. drwxr-xr-x 8 nova nova 4.0K Feb 28 21:39 ../

5. -rw-r--r-- 1 nova kvm 2.0G Mar 1 02:06 d265f9d66b8be65448e6c9147a83d65a300e1852

6. -rw-r--r-- 1 nova kvm 10G Mar 1 02:06 d265f9d66b8be65448e6c9147a83d65a300e1852_10

7. -rw-rw-r-- 1 nova nova 223M Feb 28 03:17 d265f9d66b8be65448e6c9147a83d65a300e1852.part

8. -rw-r--r-- 1 nova nova 20G Feb 28 04:01 ephemeral_0_20_None

9. -rw-r--r-- 1 libvirt-qemu kvm 20G Feb 28 04:01 ephemeral_0_20_None_20

10. -rw-r--r-- 1 nova nova 40G Feb 28 21:39 ephemeral_0_40_None

11. -rw-r--r-- 1 libvirt-qemu kvm 40G Feb 28 21:39 ephemeral_0_40_None_40

复制代码

即从:c036d689-0336-4fcd-a8e0-4aed4dd5e420 ---> d265f9d66b8be65448e6c9147a83d65a300e1852.part
通过qemu-img info,可以发现d265f9d66b8be65448e6c9147a83d65a300e1852.part仍为qcow2格式的镜像,且大小与glance上的大小一致。

1. ubuntu@compute-63-11:/var/lib/nova/instances/_base$ sudo qemu-img info d265f9d66b8be65448e6c9147a83d65a300e1852.part

2. image: d265f9d66b8be65448e6c9147a83d65a300e1852.part

3. file format: qcow2

4. virtual size: 2.0G (2147483648 bytes)

5. disk size: 223M

6. cluster_size: 65536

复制代码

(2)步:
镜像下载成功后,openstack先去判断image文件的类型是否为qcow2,如果是,则现将其转化为raw格式,否则,直接进入(3)
这里通过qemu-img convert命令,将qcow2格式转化为raw格式,转化完的镜像为:d265f9d66b8be65448e6c9147a83d65a300e1852,通过qemu-imag info查看其information。

1. ubuntu@compute-63-11:/var/lib/nova/instances/_base$ sudo qemu-img info d265f9d66b8be65448e6c9147a83d65a300e1852

2. image: d265f9d66b8be65448e6c9147a83d65a300e1852

3. file format: raw

4. virtual size: 2.0G (2147483648 bytes)

5. disk size: 659M

复制代码

(3)(4)两步:
由于所请求的vm的类型为m1.small,其root disk的大小为10G,所以需要resize image fille to 10G。
这里比较奇怪的是,在resize之前,openstack会将d265f9d66b8be65448e6c9147a83d65a300e1852拷贝一份d265f9d66b8be65448e6c9147a83d65a300e1852_10,然后对d265f9d66b8be65448e6c9147a83d65a300e1852_10进行resize操作,将其变成10G的raw,这可能与vm的备份有关,暂时还没有理解为什么这么做。

1. cp /var/lib/nova/instances/_base/d265f9d66b8be65448e6c9147a83d65a300e1852 /var/lib/nova/instances/_base/d265f9d66b8be65448e6c9147a83d65a300e1852_10 (raw -->raw 2G-->2G)

2. qemu-img resize /var/lib/nova/instances/_base/d265f9d66b8be65448e6c9147a83d65a300e1852_10 10737418240 (raw--> raw 2G -->10G)

复制代码

(5) 步:
以(3)中创建的d265f9d66b8be65448e6c9147a83d65a300e1852_10作为base创建qcow2格式的overlay,可以理解为以d265f9d66b8be65448e6c9147a83d65a300e1852_10为base,创建了一个快照disk,具体看对应虚拟机目录下的文件:

1. ubuntu@compute-63-12:/var/lib/nova/instances/instance-0000003a$ ll -alh

2. total 417M

3. drwxrwxr-x 2 nova nova 4.0K Feb 28 21:39 ./

4. drwxr-xr-x 8 nova nova 4.0K Feb 28 21:39 ../

5. -rw-rw---- 1 libvirt-qemu kvm 23K Feb 28 21:40 console.log

6. -rw-r--r-- 1 libvirt-qemu kvm 417M Mar 1 02:36 disk

7. -rw-r--r-- 1 libvirt-qemu kvm 576K Mar 1 01:35 disk.local

8. -rw-rw-r-- 1 nova nova 1.6K Feb 28 21:38 libvirt.xml

复制代码

现在来总结下镜像文件的变化过程:

1. c036d689-0336-4fcd-a8e0-4aed4dd5e420    (223M -- qcow2)

2.      -->d265f9d66b8be65448e6c9147a83d65a300e1852.part   (223M -- qcow2)

3.            --> d265f9d66b8be65448e6c9147a83d65a300e1852      (2G -- raw)

4.                   -->d265f9d66b8be65448e6c9147a83d65a300e1852_10   (10G -- raw)

5.                           --> disk    (417M -- qcow2)

复制代码

3. cache机制

如果之后创建的vm的类型也是m1.small,并且是同一个image,将不会再去glance下载image文件,而是直接利用本地_base下的d265f9d66b8be65448e6c9147a83d65a300e1852_10来直接创建vm的disk文件,大大减少的vm的部署时间。

大数据系列相关文章:

最新评论
时趣张首华2014-09-10 06:49:53
。。。。。。。。。。。。
紫梦依然2014-09-10 03:10:01
真好
数据分析微招聘2014-09-09 01:46:27
直接 虚拟机上了 内存 扩一下 就可以了
lei2014-09-08 11:27:01
@StaY_Real■ 作为外部数据,路径也不会变,只是建立了元数据
0象限2014-09-08 07:25:05
你用jinfo看一下,你用的什么收集器,
 
  • Hadoop生态系统资料推荐