OpenStack入门之核心组件梳理（3）——Glance篇
前言
之前的文章中相继介绍了OpenStack中关于Keystone以及Nova组件的概念、架构、原理等内容，那么本文继续讲述OpenStack中的Glance组件的相关理论要点。
对于Glance组件的理解还是需要对OpenStack整体概念和组件构成有所掌握，并且在OpenStack这一大项目中，对于各个组件之间的联系的梳理还是尤为重要的。笔者给出下面的几篇文章，对于初学者而言理解起来有所帮助。
友情链接：
OpenStack概念以及核心组件概述
OpenStack部署节点类型和架构
OpenStack核心组件Keystone
OpenStack核心组件Nova
Glance是OpenStack中提供的服务的，用户可以上传和发现与其他服务一起使用的数据资源。本文主要从Glance组件的概念及作用、主要的功能模块、基本的架构组成、以及其支持虚拟机镜像的格式类型四个方面进行阐述，最后对Glance项目做一个总结。
一、Glance的概念作用
1.1概念引入
对于Glance项目，笔者在之前的文章（参考上述链接文章）中有基本介绍，从中可以了解Glance项目是OpenStack中用来通过Image Service（镜像服务）的。
所谓Image可以理解为包含了这些基本操作系统和其他软件的模板，这种模板称为镜像，如果对于镜像还无法理解的朋友可以将其理解为我们生活中使用的光盘，或者暂时可以认为是副本（例如VMware中的快照）。下文会具体讲述关于镜像服务支持的镜像文件格式类型。
那么OpenStack中为什么需要这项服务呢？或者说Glance项目的作用是什么呢？
1.2主要作用
Glance项目主要负责Image（镜像）的注册和查询传送服务，这些Image可以是用户自己制作上传的镜像，也可以是当前实例进行快照（可以理解为复制、备份的意思）后的副本，这两种类型的镜像都可以快速用于实例部署（可以通过Dashboard操作）（这也体现出云环境所带来的便利与优势）。
那么，用户或管理员是如何使用Glance项目所提供的镜像服务的呢？
OpenStack的用户或管理员可以通过Glance提供的RESTful API接口在多台服务器上进行并行查询和访问Glance存储的镜像文件，这些镜像文件默认情况下存储在部署Glance服务的主机目录/var/lib/glance/images上。
而要理解Glance具体的服务请求响应和服务过程，首先需要了解它的功能模块以及作用。
二、Glance的功能模块
本小节将详细介绍Glance的功能模块组成，为下面对Glance的基本架构理解做铺垫。
2.1 glance-api
glance-api是系统后台运行的服务进程，可以使用ps -ef | grep glance-api查看进程信息。对外提供REST API，用于响应image的查询、获取和存储的调用，但是其并不会真正处理请求。而是将请求完成的操作交给相应的其他模块去完成。
因此，glance-api的作用就是接收请求，但是自身不处理请求，可以联想一下服务器集群中负载均衡服务器的作用来类比理解。
查看进程代码例：
[root@ct ~(keystone_admin)]# ps -e | grep glance-api
1256 ? 00:00:02 glance-api
2381 ? 00:00:00 glance-api
2385 ? 00:00:00 glance-api
2388 ? 00:00:00 glance-api
2391 ? 00:00:00 glance-api2.2 glance-registry
glance-registry也是系统后台运行的服务进程，可以使用ps -e | grep glance-registry查看进程信息。该进程主要负责处理和存取image和metadata，例如image的大小和类型（下文会具体介绍）。
注意：registry是一个内部服务接口，不会暴露给普通用户。
查看进程代码例：
[root@ct ~(keystone_admin)]# ps -e | grep glance-registry
1253 ? 00:00:02 glance-registry
2365 ? 00:00:00 glance-registry
2366 ? 00:00:00 glance-registry
2367 ? 00:00:00 glance-registry
2368 ? 00:00:00 glance-registry 补充：官网给出说明，对于glance-registry以及其API可能将在S版本的开发时删除，因为在Q版本中已经弃用了该服务组件。不过笔者所部署的R版本中是具有该组件的。
2.3 Datebase
Glance中的数据库，一般是MySQL，或者Mariadb以及SQLite数据库。主要是用于保存image的metdata信息的。上篇文章笔者将实验环境中OpenStack多节点部署的R版本的一键安装的流程详细给出了，其中在真正执行一键部署前是对应答文件进行修改的，而且是使用的sed工具修改了ip地址以及密码（全局问题）。其中对密码的修改还是非常有必要的，假设您并未对密码进行修改，那么要使用数据库时就需要查看一下用户名和密码了。
下面给出如何登录该实验的数据库流程：
1、使用vi编辑器打开应答文件；
[root@ct ~]# source keystonerc_admin
[root@ct ~(keystone_admin)]# vi openstack.txt
2、末行模式搜索MARIADB；
3、按"n"进行next查找操作，找到对应账号及密码；
4、登录数据库，查看有哪些数据库，主要看一下glance数据库中有哪些表
[root@ct ~(keystone_admin)]# mysql -uroot -pb437a94478394d62
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 6962
Server version: 10.1.20-MariaDB MariaDB Server
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases; #数据库清单
+--------------------+
| Database |
+--------------------+
| cinder |
| glance |
| gnocchi |
| information_schema |
| keystone |
| mysql |
| neutron |
| nova |
| nova_api |
| nova_cell0 |
| nova_placement |
| performance_schema |
| test |
+--------------------+
13 rows in set (0.00 sec)
MariaDB [(none)]> use glance; #使用glance数据库
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [glance]> show tables; #查看glance数据库中的表
+----------------------------------+
| Tables_in_glance |
+----------------------------------+
| alembic_version |
| image_locations |
| image_members |
| image_properties |
| image_tags |
| images |
| metadef_namespace_resource_types |
| metadef_namespaces |
| metadef_objects |
| metadef_properties |
| metadef_resource_types |
| metadef_tags |
| migrate_version |
| task_info |
| tasks |
+----------------------------------+
15 rows in set (0.00 sec)
MariaDB [glance]> exit
Bye
通过对应的英文名称也可以验证该服务的作用。
2.4 Store backend
该服务是实际用于存储的，因为glance自身并不存储image的，而是将image存放在backend中的，一般是后端的服务器，专门负责存储工作的，例如Swift、Cinder、Amazon的S3、Ceph存储、Sheepdog等等。在官方文档给出的glance架构中，是将这些不同的存储类型都归于glance_store源中（用于管理glance与各种存储服务的交互的）。
具体如何规定某种类型的backend要通过对其配置文件进行设置，本文不进行深究，该配置文件默认为：/etc/glance/glance-api.conf。参考下图：
以上就是Glance组件中主要的功能模块了。相较于Nova并不复杂，或许您已经可以在脑海中有了Glance的架构图了，下面就来介绍Glance的基本架构图。
三、Glance的基本架构
对于Glance基本架构，首先可以参考官方文档：Glance的基本架构
但是结合上述的主要构成，加之考虑到官方的架构图对于初学者而言并不容易理解，因此笔者通过一个简化版本的架构图进行说明。
该架构看上去是否非常简单，下面来简述Glance的工作流程（这里不考虑与其他服务之间的交互）：
1、glance-api接收到对应的服务请求，该服务进行响应；
2、此时glance-api服务将会对请求进行判断，假设是与metadata相关的操作则会将该任务交给glance-registry进行处理，对应数据库操作；如果是与image自身相关的操作，则会将请求发给对应的store backend进行处理，对应与之相连的存储服务的相关操作。
四、Glance支持镜像格式类型
前文多次提到镜像，那么本小节就是来介绍有关Glance中支持的镜像的格式类型的。先来谈谈镜像格式这个词是怎么来的。这个问题涉及到虚拟化技术，简单来讲，不同的商家使用的虚拟化技术都不一样，大家所熟悉的可能就是VMware，或者Hyper-V了，对应不同的虚拟化技术，那么各个厂家对应虚拟机磁盘格式的定义就有着自己的标准。因此，不同镜像格式的镜像（可能就是一个文件）是由于不同的虚拟化技术而产生的。
下面列出在OpenStack中常见的几种镜像格式。
4.1 RAW
RAW是一种没有格式或裸格式的磁盘文件类型，属于非结构化的镜像格式。RAW对数据不做任何修饰和处理，直接保存最原始的状态，所以在性能方面非常出色。由于RAW格式保存原始数据，因此更容易和其他镜像格式进行转换。
4.2 QCOW2
QCOW2是QCOW的升级版本，支持QEMU并且支持动态磁盘镜像扩展和写时复制的格式。其主要特性是磁盘文件大小可以动态按需增长，并且不会占用所有的实际磁盘空间大小。例如创建了100GB的QCOW2格式的磁盘，而实际只保存了2GB数据，那么将只占用了实际物理磁盘的2GB空间。与RAW相比，使用这种格式可以节省磁盘容量，但性能较差。
4.3 VHD
VHD是微软公司产品使用的磁盘格式。 Virtual PC（微软早期虚拟化产品）和 Hyper-V使用的就是VHD格式 VirtualBox也提供了对VHD的支持。如需在 OpenStack上使用 Hyper-V类型的虚拟化，就应上传VHD格式的镜像文件
4.4 VMDK
这个大家都比较熟悉了吧。使用过VMware的都见过。
VMDK是 VMware公司产品使用的磁盘格式，支持多种Hypervisor。目前也是一个开放的通用格式，除了 VMware自家的产品外，QEM和 Virtualbox也提供了对VMDK格式的支持。
4.5 VDI
VDI是Oracle公司的 VirtualBox虚拟软件所使用的格式。
4.6 ISO
这个大家也比较熟悉了，无论按照Windows还是Linux系统都见过。这是一种存档数据文件在光盘上的格式，例如CD-ROM。
4.7 AKI
该镜像格式是AWS的Kernel镜像格式。
4.8 ARI
该镜像格式是AWS的Ramdisk镜像格式。
4.9 AMI
该镜像格式是AWS的虚拟机镜像格式。
补充：本文关于Glance的容器格式不做介绍。
五、Glance的理论总结
本文主要讲述OpenStack中核心组件之一的Glance项目。其中重点在于Glance所提供的服务、其基本架构和服务流程。Glance的关键还在于镜像格式的类型，这里强调的RAW与QCOW2，要了解它们之间的区别。
笔者能力有限，若有疏漏之处还望指出，感谢您的阅读与支持！