当前位置: 首页 > 工具软件 > Glance > 使用案例 >

OpenStack学习笔记-Glance组件深入了解

鲜于温书
2023-12-01

视频了解:
glance:为虚拟机的创建提供镜像的服务
glance的功能:使用户能够发现、注册、检索虚拟机的镜像,它提供一个能够查询虚拟机镜像元数据和检索真实镜像的REST API
REST API的体现就是一个URL,而在glance中通过一个URL地址来标识一个URL地址来唯一标识一个镜像的形式如:
<Glance Server Location>/v1/images/<ID>
<Glance Server Location>:glance服务按照的位置
/v1:使用v1版本,详见四
/images:请求的类型为镜像
/<ID>:一个uuid,在glance中全局唯一

v1版本的glance:
1、V1版本的实现,具有glance-api和glance-registry两个WSGI服务,二者都提供REST API,但需要强调的一点是:glance-registry提供的REST API是给glance-api使用的
2、Glance-API:1、接受api发来的请求,发给glance-registry。2、到后端的存储设备拉取镜像
3、Glance-Registry:1、连接数据库,从数据库中找到符合客户端标准的镜像,获取镜像的元数据,将镜像的信息返回给glance-api
v2版本的glance:
1、v2的实现就是将glance-registry集成到了glance-api内部,这么做的好处是减少了一个中间的处理环节。
2、Glance-API:接受api发来的请求直接去访问数据库,获取到镜像的元数据后去存储设备拉取镜像。

书籍笔记:
Glance体系结构(v1版本):
1、Glance主要由glance-api与glance-registry两个服务组成。
2、glance-api 是进入Glance的入口,负责接收用户的RESTful请求,然后通过后台的Swift 等存储系统完成镜像的存储与获取。
3、Glance的Store模块实现了一个存储后台的框架,根据这个框架所提供的接口,实现了对各种不同后台存储系统的支持。
4、在Juno版本之前,Store模块的实现位于glance/store目录;Juno版本之后,Store模块作为一个独立的项目glance store被剥离出来 ,以便为更多的项目服务
5、glacne-registry也是一个 WSGI Server,不同的是,glance-registry处理的是与镜像元数据(这里的元数据是指保存在数据库中的关于镜像的一些信息)相关的RESTful请求。
6、glance-api接收到用户的RESTful请求后,如果该请求与元数据相关,则将其转发给glance-registry服务。然后glance-registry会解析请求的内容,并与数据库进行交互,存取或更新镜像的元数据,Glance的DB模块存储的仅仅是镜像的元数据。
v2版本的Glance中,glance-registry服务的内容被整合进了glance-api之中。

Glance源码结构分析:
1、Glance的核心代码位于glance目录
2、所有服务以及工具的执行脚本位于glance/cmd
3、glance-api、glance/registry分别对应GlanceAPI 和 Glance-registry
4、glance-api可以为镜像建立本地缓存,实现API服务节点的数量扩展,提供多个API节点为同一个镜像提供服务的效率(本地的Image Cache是镜像文件的完全复制,这种缓存机制对用户来说是透明的)。
5、用户可以通过配置文件/etc/glance/glance-cache.conf指定Cache文件存放的路径、本地能够用于Cache的存储空间等信息。
6、镜像缓存的实现位于glance/image_cache目录。
7、针对import、export等镜像操作,Glance引入Task的概念(针对镜像的异步操作,glance/async即是部分实现)
8、Glance釆用了责任链(Chain of Responsibility)的设计模式实现用户请求的处理流程。使系统可以在不影响客户端的情况下动态地重新组织链和分配责任。
9、glance.domain模块定义了一些基类或接口,glance.gateway.Gateway模块则是实现了责任链的建立。
10、Rally是一个用于性能测试的项目,glance/rally-jobs目录是一些用于Rally的文件或插件。

setup.cfg:
entry_points,中的命名空间“consolc_scripts”里,涵盖了Glance所提供的所有服务以及工具
其中的每一项都表示一个可执行的脚本,这些脚本在部署时会被安装,它们同时也是 Glance各项工作的入口。
1、glance-cache-*: 4 个对 Image Cache 进行管理的工具。
2、glance-manage:用于Glance数据库的管理。
3、glance-replicator:用于实现镜像的复制。
4、glance-scrubber:用于清理已经删除的Image。
5、glance-control: Glance 提供了 glance-api 和 glance-registry 两个WSGI Server.以及一 个glance-scrubber后台服务进程,这里的glance-control工具即是用于控制这3个服务进程。
6、glance-glare: Glare API 服务,目前正在开发中。

Glance API详细介绍:
Glance API主要提供镜像的管理功能。比如Image的导入/导出、镜像元数据的管理等。
目前Glance API共有v1和v2两个版本,v2版本整合了glance-registry服务的功能,并且采用责任链设计模式来实现了API的处理流程。
Image:
Image是Glance所管理的主要资源。如果从Image启动VM,该VM被删除后,Image依然存在,但是Image上不包含本次在该VM实例上的修改(因为Image只是给VM启动的模板)
对Image的描述:
1、id:唯一一个标识Image的UUID
2、name:Image的名字
3、owner:Image的拥有者
4、size:Image的字节大小
5、created_at、updated_at:表示Image的出生时间、最后一次被修改的时间
6、location:Image存储的位置
7、disk_format:Image本身的格式(比如raw、qcow2(用于Qemu)、vdi(用于Virtual Box)、vmdk(用于Vmware)等)
8、status:镜像的状态。(Glance负责管理Image的生命周期)
Image的各种状态:
1、queued:表面镜像ID已经被保留,但是镜像数据还没有上传
2、saving:表面此时镜像正在上传
3、active:是Image成功上传完毕后的状态,此时该Image完全可用
4、killed:表面上传时发生错误,此时Image完全不可用。(在v2中被废除,如果上传失败,状态码变为“queued”以便上传可以重试)
5、deleted:虽然此时Glance还保留Image的相关信息,但是该Image已不可用,在未 来某个时候会被glance-scrubber彻底删除。
6、pending_delete:和deleted类似,但是并不会删除Image,此时尚可恢复。
Task:
Task是针对Image的异步(Async)操作,具有的一些属性包括id、owner状态等。Glance同时也实现了统一的JSON格式的API来操作这些Task,比如创建、删除、查询状态等。
在一个Task运行过程中,我们不断查询它的状态。
1、pending:表示Task被创建,但未被执行
2、processing:表示Task正在被执行中。
3、success:表示Task正在执行中。
4、failure:表示Task由于某种原因未能成功结束。
Task和Image的操作完全是两个概念:
1、首先它们都是不同的API资源;
2、其次,Task是异步的操作,是对Image操作的封装,目前只对clone、imports export 3种操作进行了封装;
3、最后,Task一旦创建,可以不断查询这个它的状态,在一次操作比如import之后,Task可以消亡,但是此时生成的Image依然存在。
 

 类似资料: