阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

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

60次阅读
没有评论

共计 9828 个字符,预计需要花费 25 分钟才能阅读完成。

Glance 用来作为独立的大规模镜像查找服务,当它与 Nova 和 Swift 配合使用时,就为 OpenStack 提供了虚拟机镜像的查找服务,像所有的 OpenStack 项目一样,遵循以下设计思想:

  • 基于组件的架构 – 便于快速增加新特性
  • 高可用性 – 支持大负荷
  • 容错性 – 独立的进程地址空间,避免串行错误
  • 开放标准 – 对社区驱动的 API 提供参考实现

1. Glance 架构

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

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

在 Ubuntu 12.10 上安装部署 Openstack http://www.linuxidc.com/Linux/2013-08/88184.htm

Ubuntu 12.04 OpenStack Swift 单节点部署手册 http://www.linuxidc.com/Linux/2013-08/88182.htm

OpenStack 云计算快速入门教程 http://www.linuxidc.com/Linux/2013-08/88186.htm

企业部署 OpenStack:该做与不该做的事 http://www.linuxidc.com/Linux/2013-09/90428.htm

CentOS 6.5 x64bit 快速安装 OpenStack http://www.linuxidc.com/Linux/2014-06/103775.htm

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。
glance add name=”Precise x86_64″ is_public=true

 

container_format=ovf disk_format=qcow2

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

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

total 2.5G

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

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

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

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

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

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

通过 qemu-img info 命令,先看一下镜像文件的大小和格式如下:
ubuntu@compute-63-02:/var/lib/glance/images$ sudo qemu-img info c036d689-0336-4fcd-a8e0-4aed4dd5e420

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

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

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

disk size: 223M

cluster_size: 65536

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

total 32

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

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

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

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

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

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

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

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

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

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

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

更多详情见请继续阅读下一页的精彩内容 :http://www.linuxidc.com/Linux/2014-07/104772p2.htm

当 Nova Compute 接收到 vm 创建的请求时,通过以下步骤完成一个 VM 的创建过程:

(1)步:
从 vm 的描述文件中获得所使用的 image 文件的 ID,然后向 Glance 发起索取 image 文件的 HTTP 请求,结果是 image 文件从 Glance 的存储节点下载到发起请求的 host 机器上,即:/var/lib/nova/instances/_base 目录下:
Ubuntu@compute-63-11:/var/lib/nova/instances/_base$ ll -alh

total 4.0G

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

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

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

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

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

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

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

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

-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 上的大小一致。
ubuntu@compute-63-11:/var/lib/nova/instances/_base$ sudo qemu-img info d265f9d66b8be65448e6c9147a83d65a300e1852.part

image: d265f9d66b8be65448e6c9147a83d65a300e1852.part

file format: qcow2

virtual size: 2.0G (2147483648 bytes)

disk size: 223M

cluster_size: 65536

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

image: d265f9d66b8be65448e6c9147a83d65a300e1852

file format: raw

virtual size: 2.0G (2147483648 bytes)

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 的备份有关,暂时还没有理解为什么这么做。
cp /var/lib/nova/instances/_base/d265f9d66b8be65448e6c9147a83d65a300e1852 /var/lib/nova/instances/_base/d265f9d66b8be65448e6c9147a83d65a300e1852_10(raw –>raw 2G–>2G)
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, 具体看对应虚拟机目录下的文件:
ubuntu@compute-63-12:/var/lib/nova/instances/instance-0000003a$ ll -alh

total 417M

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

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

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

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

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

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

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

c036d689-0336-4fcd-a8e0-4aed4dd5e420 (223M — qcow2)
–>d265f9d66b8be65448e6c9147a83d65a300e1852.part (223M — qcow2)

–> d265f9d66b8be65448e6c9147a83d65a300e1852 (2G — raw)
–>d265f9d66b8be65448e6c9147a83d65a300e1852_10 (10G — raw)
–> disk (417M — qcow2)

3. cache 机制

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

Glance 用来作为独立的大规模镜像查找服务,当它与 Nova 和 Swift 配合使用时,就为 OpenStack 提供了虚拟机镜像的查找服务,像所有的 OpenStack 项目一样,遵循以下设计思想:

  • 基于组件的架构 – 便于快速增加新特性
  • 高可用性 – 支持大负荷
  • 容错性 – 独立的进程地址空间,避免串行错误
  • 开放标准 – 对社区驱动的 API 提供参考实现

1. Glance 架构

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

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

在 Ubuntu 12.10 上安装部署 Openstack http://www.linuxidc.com/Linux/2013-08/88184.htm

Ubuntu 12.04 OpenStack Swift 单节点部署手册 http://www.linuxidc.com/Linux/2013-08/88182.htm

OpenStack 云计算快速入门教程 http://www.linuxidc.com/Linux/2013-08/88186.htm

企业部署 OpenStack:该做与不该做的事 http://www.linuxidc.com/Linux/2013-09/90428.htm

CentOS 6.5 x64bit 快速安装 OpenStack http://www.linuxidc.com/Linux/2014-06/103775.htm

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。
glance add name=”Precise x86_64″ is_public=true

 

container_format=ovf disk_format=qcow2

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

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

total 2.5G

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

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

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

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

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

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

通过 qemu-img info 命令,先看一下镜像文件的大小和格式如下:
ubuntu@compute-63-02:/var/lib/glance/images$ sudo qemu-img info c036d689-0336-4fcd-a8e0-4aed4dd5e420

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

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

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

disk size: 223M

cluster_size: 65536

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

total 32

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

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

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

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

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

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

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

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

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

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

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

更多详情见请继续阅读下一页的精彩内容 :http://www.linuxidc.com/Linux/2014-07/104772p2.htm

正文完
星哥说事-微信公众号
post-qrcode
 
星锅
版权声明:本站原创文章,由 星锅 2022-01-20发表,共计9828字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中