harbor GC优化(ceph后端)

分享
源代码 2024-9-30 15:41:25 57 0 来自 中国
配景


  • harbor版本 1.6。
  • distribution(原来的名字叫registry)版本为2.7.1,存储后端对接ceph (s3),线上情况ceph存储性能一样寻常。
  • 应用会定期删除不须要的镜像,每个镜像只生存肯定个数的tag数。
  • harbor的bucket占用了52T的存储容量。
  • 实验gc,耗时过长。
针对以上题目,须要深入研究distribution gc的原理和s3相干的接口,进而优化gc代码,理想目标是gc在8个小时以内。
镜像仓库中的相干概念


  • registry
    docker的镜像管理工具,负责对接各种差别的存储后端,厥后改名为distribution。
    distribution的github链接
  • harbor
    开源的私有仓库管理工具,在distribution的底子上增长了ui、认证、配额等等功能。
    harbor的github链接
  • manifest
    镜像的描述文件,如镜像的设置信息,数据信息(layers)
    manifest官方表明
  • blob
    blob这个词应该是参考自mysql中的数据范例blob,在distribution中表现一个存储数据的文件。
GC逻辑简介

在1.6版本的harbor中,暂时还没有GC的概念,以是这里个GC是指对于镜像仓库(distribution)的GC。下面简单先容下GC的逻辑。

  • 将仓库设置为只读
  • 遍历distribution的存储目次,获取到镜像列表。
  • 遍历镜像的revisions目次,获取镜像的差别版本号的manifest文件。
  • 根据3中的manifest,标志blob信息,生存到markSet(字典布局),可以索引到的blob就可以以为不能删除。
  • 遍历全部blob文件,如果blob不在markSet中,则以为该blob无镜像引用,到场到deleteSet中
  • 遍历deleteSet,调用存储接口挨个删除blob数据,完成镜像仓库的整理。
GC的delete-untagged参数

harbor [ / ]$ registry_DO_NOT_USE_GC garbage-collect --help`garbage-collect` deletes layers not referenced by any manifestsUsage:   registry garbage-collect <config> [flags]Flags:  -m, --delete-untagged=false: delete manifests that are not currently referenced via tag  -d, --dry-run=false: do everything except remove the blobs  -h, --help=false: help for garbage-collect通过查询相干文档,并没有检察到详细的表明,通过梳理代码流程,这个参数的作用是整理以下两种情况下的镜像。

  • 利用类似的镜像tag推送差别的镜像内容,之前的镜像就不能再通过tag的方式拉取。
docker tag centos:7 myos:v1docker push myos:v1   # 天生一个sha256值docker tag ubuntu:20 myos:v1docker push myos:v1   # 天生一个sha256值经过上诉步调后,利用docker pull myos:v1只能拉取到ubuntu的镜像,但是centos:7这个镜像并没有被删除,可以通过centos:7的sha256值的方式举行拉取。

  • 如果通过sha256的方式删除镜像,那么此sha256对应镜像的tag将无法被拉取。
docker push myos:v2  # 天生一个sha256值,比如是987654321docker tag myos:v2 centos:7docker push centos:7docker tag myos:v2 ubuntu:20docker push ubuntu:20docker remove remote myos@987654321经过上诉步调后,centos:7和````ubuntu:20``均无法被拉取。
优化思绪

相识原有gc速率慢是由于ceph性能低的缘故原由后,就可以做针对性的优化。
1、通过s3 list 遍历获取镜像列表 改为 从pgsql中中获取镜像列表
2、去掉stat获取key的状态。
3、遍历blob,不须要遍历到data文件。
4、去掉删除函数中的list利用。
5、归并删除哀求,挨个删除blob数据,修改为每500个blob(这个量要控制一下,防止ceph瓦解和其他影响),调用s3接口删除一次。
6、为方便观察GC服从,增长GC纪录信息,每隔5分钟输出一次剩余的待删除layers的数据。
总结

相干代码就不展示了,须要的同砚可以私信获取。优化的第一步就是要相识到性能慢的细节和代码实验的完备步调,在有限的条件下思考每个步调是否有优化的空间。本次优化,将GC时间从原来的至少两天收缩到了不到3个小时,性能提升了20多倍。
您需要登录后才可以回帖 登录 | 立即注册

Powered by CangBaoKu v1.0 小黑屋藏宝库It社区( 冀ICP备14008649号 )

GMT+8, 2024-11-22 00:07, Processed in 0.349831 second(s), 32 queries.© 2003-2025 cbk Team.

快速回复 返回顶部 返回列表