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

目录

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合并到了一起,减少了一个中间环节。

### 解决方案分析 #### 错误原因解析 `HTTPConnectionPool` 报错 `Max retries exceeded` 和 `[Errno 111] Connection refused` 表明客户端尝试多次连接到指定主机和端口失败,具体原因是目标服务未运行或网络配置不正确。此问题可能由以下几个方面引起: - **服务状态异常**:OpenStack 的某些组件(如 Glance API 或 Keystone)未正常启动[^1]。 - **防火墙或安全组设置不当**:控制器节点上的防火墙规则阻止了外部访问特定端口[^2]。 - **DNS 配置错误**:如果使用域名而非 IP 地址,可能存在 DNS 解析问题。 - **网络连通性问题**:客户端无法到达服务器所在子网。 --- #### 排查方法解决方案 ##### 1. 检查服务状态 确认 OpenStack 组件是否正在运行。对于引用中的两个报错,分别涉及以下服务: - `/v1/AUTH_...` 路径指向 Keystone 认证服务。 - `/v2/schemas/image` 路径指向 Glance 图像管理服务。 可以通过命令检查这些服务的状态: ```bash systemctl status openstack-keystone systemctl status openstack-glance-api ``` 如果发现任何服务处于停止状态,则需重新启动它们并查看日志文件排查潜在问题: ```bash journalctl -u openstack-keystone journalctl -u openstack-glance-api ``` --- ##### 2. 网络连通性测试 验证客户端能否成功访问目标地址和端口。可以使用以下工具进行诊断: - 使用 `ping` 测试主机名解析及基本可达性: ```bash ping controller ``` - 使用 `telnet` 或 `nc` 测试端口连通性: ```bash telnet controller 8080 nc -zv controller 9292 ``` 若上述操作返回超时或拒绝连接的结果,则说明存在网络隔离或其他阻断机制。 --- ##### 3. 防火墙规则调整 确保控制器节点上允许必要的流量通过。以下是针对常见 Linux 发行版的操作指南: ###### 对于 iptables 用户: 临时禁用防火墙以排除干扰因素: ```bash iptables -F ``` 永久修改规则前先备份现有策略;随后添加如下条目开放所需端口: ```bash iptables -A INPUT -p tcp --dport 8080 -j ACCEPT iptables -A INPUT -p tcp --dport 9292 -j ACCEPT service iptables save ``` ###### 对于 firewalld 用户: 启用对应的服务或自定义端口范围: ```bash firewall-cmd --add-port=8080/tcp --permanent firewall-cmd --add-port=9292/tcp --permanent firewall-cmd --reload ``` --- ##### 4. 修改请求重试次数 当确实遇到短暂性的高负载情况时,可适当增加 urllib3 库的最大重试次数来提升鲁棒性。例如,在 Python 请求脚本中加入以下参数: ```python import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session = requests.Session() retries = Retry(total=5, backoff_factor=1, status_forcelist=[500, 502, 503, 504]) adapter = HTTPAdapter(max_retries=retries) session.mount('http://', adapter) response = session.get("http://controller:8080/v1/AUTH...") print(response.status_code) ``` 此处设置了最大五次重试以及指数退避算法延时逻辑。 --- ##### 5. 日志审查 最后一步也是至关重要的环节——深入挖掘后台日志寻找根本诱因。重点查阅路径通常位于 `/var/log/` 下面的不同目录里头比如 keystone.log glance/api.log 这些地方记录着每一次交互详情有助于定位确切位置发生何事为何如此这般反应出来给定提示信息以便进一步采取行动加以修正完善整个流程直至恢复正常运作为止。 --- ### 总结 综上所述,解决 `HTTPConnectionPool Max retries exceeded Errno 111 Connection refused` 问题的关键在于逐一核实服务可用性、网络通畅度以及防护措施合理性等方面的内容,并依据实际情况灵活运用前述各项技术手段予以妥善处置即可达成预期效果。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

范桂飓

文章对您有帮助就请一键三连:)

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值