碼上歡樂
相關內容    簡體    繁體

OpenStack虛擬機創建過程中鏡像格式的的變化過程

本文轉載自   查看原文   2016-05-24 10:08   4658    openstack

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

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
  2.       新創建的虛擬機存放在/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上虛擬機對應的快照文件

  4.   通過查看nova-compute.log可以看到vm創建過程中，鏡像文件格式的變化過程，下面總結了下，具體參見下圖。

        從glance中得知，有個virtual size =2G的qcow2格式的鏡像文件Precise x86_64，它在glance中的ID=c036d689-0336-4fcd-a8e0-4aed4dd5e420。

  5.   當Nova Compute接收到vm創建的請求時，通過以下步驟完成一個VM的創建過程：
  6.   
  7. （1）步：
  8.     從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
  9. 通過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）步：
  11.       鏡像下載成功后，openstack先去判斷image文件的類型是否為qcow2，如果是，則現將其轉化為raw格式，否則，直接進入（3）
  12.       這里通過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）兩步：
  13.      由於所請求的vm的類型為m1.small，其root disk的大小為10G，所以需要resize image fille to 10G。
  14.     這里比較奇怪的是，在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) 步：
  15.     以（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
    現在來總結下鏡像文件的變化過程：
  16.  c036d689-0336-4fcd-a8e0-4aed4dd5e420    (223M -- qcow2)
  17.      -->d265f9d66b8be65448e6c9147a83d65a300e1852.part   (223M -- qcow2)
  18.            --> d265f9d66b8be65448e6c9147a83d65a300e1852      (2G -- raw)
  19.                   -->d265f9d66b8be65448e6c9147a83d65a300e1852_10   (10G -- raw)
  20.                           --> disk    (417M -- qcow2)

3. cache機制

   如果之后創建的vm的類型也是m1.small，並且是同一個image,將不會再去glance下載image文件，而是直接利用本地_base下的d265f9d66b8be65448e6c9147a83d65a300e1852_10來直接創建vm的disk文件，大大減少的vm的部署時間。







免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 openstack創建一個虛擬機的過程 openstack nova創建虛擬機過程(二) android 虛擬機 (avd) 運行過程中死機 openstack虛擬機啟動過程 VMware的虛擬網絡編輯器，在配置的過程中沒有橋接模式！（虛擬機卸載） openstack虛擬機啟動過程源碼分析 openstack創建虛擬機 openstack虛擬機導出鏡像 qemu創建aarch64虛擬機過程記錄 ##8.創建虛擬機-- openstack pike
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM