Openstack组件实现原理 — Glance架构(V1/V2)

简介: 目录目录Glance 安装列表Glance Image serviceImage service 的组件Glance-ApiGlance-RegistryGlance-dbImage StoreStore BackendImageGl...

目录

Glance 安装列表

Openstack组建部署 — Glance Install

Glance Image service

Image service项目代号Glance,是Openstack的镜像服务组件。Glance主要提供了一个虚拟机镜像文件的存储、查询和检索服务,通过提供一个虚拟磁盘映像目录和存储库,为Nova的虚拟机提供镜像服务。现在Glance具有V1和V2(Openstack-F发布)两个版本。
这里写图片描述

Image service 的组件

Glance-Api

glance-api:是一个对外的API接口,能够接受外部的API镜像请求。主要用于分析、分发、响应各种镜像管理的REST Request,然后通过其他模块(EG. glance-registry、Store Backend后端存储接口)完成镜像的发现、获取、存储等操作。默认绑定端口是9292

Glance-Registry

glance-registry:用于存储、处理、获取Image Metadata。通过响应从glance-api发送过来的Image Metadata REST Request,然后与MySQL进行交互,实现Image Metadate的存储、处理、获取。默认绑定的端口是9191

Glance-db

glance-db:在Openstack中使用MySQL来支撑,用于存放Image Metadate
Image Metadate(镜像元数据):指通过glance-registry来保存在MySQL Database中的镜像文件相关信息。

Image Store(Store Backend)

Image Store:用于存储镜像文件。通过Store Backend后端存储接口来与glance-api联系。通过这个接口,glance可以从Image Store获取镜像文件再交由Nova用于创建虚拟机。

Glance 通过Store Adapter(存储适配器)支持多种Imange Store方案
这里写图片描述

Glance允许上传私有或共有的不同格式镜像

  • Raw
  • Machine (kernel/ramdisk outside of image, a.k.a. AMI)
  • VHD (Hyper-V)
  • VDI (VirtualBox)
  • qcow2 (Qemu/KVM)
  • VMDK (VMWare)
  • OVF (VMWare, others)

Image

Image(镜像文件)的访问权限分为

  • Public 公共的:可以被所有的Tenant使用。
  • Private 私有的/项目的:只能被Image Owner所在的Tenant使用。
  • Shared 共享的:一个非公共的Image可以共享给指定的Tenant,通过member-*操作来实现。
  • Protected 受保护的:Protected Image不能被删除。

Image的状态类型

  • Queued:没有上传Image数据,只SQL Database中存有该镜像的元数据。
  • Saving:正在上传Image。
  • Active:正常状态。
  • Deleted/pending_delete: 已删除/等待删除的Image。
  • Killed:Image元数据不正确,等待被删除。

Image状态类型转换

  • ‘queued’ => (‘saving’, ‘active’, ‘deleted’)
  • ‘saving’ => (‘active’, ‘killed’, ‘deleted’, ‘queued’)
  • ‘active’ => (‘queued’, ‘pending_delete’, ‘deleted’)
  • ‘killed’ => (‘deleted’)
  • ‘pending_delete’ => (‘deleted’)
  • ‘deleted’ => ()

Glance 架构

Glance Restful API — V1

V1的功能:提供了基本的ImageMember操作
1. 镜像文件的创建、删除、查询、更改
2. 镜像Tenant成员的创建、删除和查询

V1包含有glance-apiglance-registry两个WSGI service,都提供了REST API接口来接收虚拟机镜像管理的请求。

两者的区别在于glance-api的REST API能够对外开放而glance-registry的REST API只能够被glance-api调用。

V1的架构

这里写图片描述

需要注意的是glance-api 不会真正去处理REST Request,可以将glance-api再分为两部分:

  • 一部分是中间件,主要用于对REST Request的分析、分发工作(EG. 分析出版本号)
  • 另一部分来提供实际的服务(EG. 与Store Backend后端存储接口交互,实现镜像上传、下载)

所以若glance-api接收到涉及SQL Database的操作请求时,会调用registry-clinet并生成HTTP指令,然后转发给glance-registry API进行处理。

Glance Restful API — V2

V2的功能:除了拥有V1的功能之外,还能够:
1. 镜像Location的添加、删除和修改
2. Metadata、Namespace、Image tag操作

V2架构图
这里写图片描述

V2在实现上,把glance-registryglance-api合并到了一起,减少了一个中间环节。

目录
打赏
0
0
0
0
37
分享
相关文章
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
154 21
RocketMQ原理—5.高可用+高并发+高性能架构
基于LlamaIndex实现CodeAct Agent:代码执行工作流的技术架构与原理
CodeAct是一种先进的AI辅助系统范式,深度融合自然语言处理与代码执行能力。通过自定义代码执行代理,开发者可精准控制代码生成、执行及管理流程。本文基于LlamaIndex框架构建CodeAct Agent,解析其技术架构,包括代码执行环境、工作流定义系统、提示工程机制和状态管理系统。同时探讨安全性考量及应用场景,如软件开发、数据科学和教育领域。未来发展方向涵盖更精细的代码生成、多语言支持及更强的安全隔离机制,推动AI辅助编程边界拓展。
44 3
基于LlamaIndex实现CodeAct Agent:代码执行工作流的技术架构与原理
MySQL进阶突击系列(03) MySQL架构原理solo九魂17环连问 | 给大厂面试官的一封信
本文介绍了MySQL架构原理、存储引擎和索引的相关知识点,涵盖查询和更新SQL的执行过程、MySQL各组件的作用、存储引擎的类型及特性、索引的建立和使用原则,以及二叉树、平衡二叉树和B树的区别。通过这些内容,帮助读者深入了解MySQL的工作机制,提高数据库管理和优化能力。
【AI系统】LLVM 架构设计和原理
本文介绍了LLVM的诞生背景及其与GCC的区别,重点阐述了LLVM的架构特点,包括其组件独立性、中间表示(IR)的优势及整体架构。通过Clang+LLVM的实际编译案例,展示了从C代码到可执行文件的全过程,突显了LLVM在编译器领域的创新与优势。
260 3
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
199 3
《docker基础篇:2.Docker安装》包括前提说明、Docker的基本组成、Docker平台架构图解(架构版)、安装步骤、阿里云镜像加速、永远的HelloWorld、底层原理
《docker基础篇:2.Docker安装》包括前提说明、Docker的基本组成、Docker平台架构图解(架构版)、安装步骤、阿里云镜像加速、永远的HelloWorld、底层原理
593 90
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
Tiktokenizer 是一款现代分词工具,旨在高效、智能地将文本转换为机器可处理的离散单元(token)。它不仅超越了传统的空格分割和正则表达式匹配方法,还结合了上下文感知能力,适应复杂语言结构。Tiktokenizer 的核心特性包括自适应 token 分割、高效编码能力和出色的可扩展性,使其适用于从聊天机器人到大规模文本分析等多种应用场景。通过模块化设计,Tiktokenizer 确保了代码的可重用性和维护性,并在分词精度、处理效率和灵活性方面表现出色。此外,它支持多语言处理、表情符号识别和领域特定文本处理,能够应对各种复杂的文本输入需求。
131 6
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
MySQL原理简介—2.InnoDB架构原理和执行流程
本文介绍了MySQL中更新语句的执行流程及其背后的机制,主要包括: 1. **更新语句的执行流程**:从SQL解析到执行器调用InnoDB存储引擎接口。 2. **Buffer Pool缓冲池**:缓存磁盘数据,减少磁盘I/O。 3. **Undo日志**:记录更新前的数据,支持事务回滚。 4. **Redo日志**:确保事务持久性,防止宕机导致的数据丢失。 5. **Binlog日志**:记录逻辑操作,用于数据恢复和主从复制。 6. **事务提交机制**:包括redo日志和binlog日志的刷盘策略,确保数据一致性。 7. **后台IO线程**:将内存中的脏数据异步刷入磁盘。
151 12
ClickHouse 架构原理及核心特性详解
ClickHouse 是由 Yandex 开发的开源列式数据库,专为 OLAP 场景设计,支持高效的大数据分析。其核心特性包括列式存储、字段压缩、丰富的数据类型、向量化执行和分布式查询。ClickHouse 通过多种表引擎(如 MergeTree、ReplacingMergeTree、SummingMergeTree)优化了数据写入和查询性能,适用于电商数据分析、日志分析等场景。然而,它在事务处理、单条数据更新删除及内存占用方面存在不足。
923 21
Druid 架构原理及核心特性详解
Druid 是一个分布式、支持实时多维OLAP分析的列式存储数据处理系统,适用于高速实时数据读取和灵活的多维数据分析。它通过Segment、Datasource等元数据概念管理数据,并依赖Zookeeper、Hadoop和Kafka等组件实现高可用性和扩展性。Druid采用列式存储、并行计算和预计算等技术优化查询性能,支持离线和实时数据分析。尽管其存储成本较高且查询语言功能有限,但在大数据实时分析领域表现出色。
536 19
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等