rgw 上传对象后，底层发生了什么变化

Last updated on 10 months ago

rgw 简介

​

当我们用 s3cmd 上传一个文件后，底层会发生什么？
image-20230518180047787

上传文件后池的变化？

上传成功后，s3cmd ls 看下这个桶有什么？发现已经上传成功
那问题来了，这个上传的文件 具体在哪里？
image-20230518202434734

​

首先 看下底层的池发生了什么变化，这里我们 用rados df 命令来看，发现有两个池里有新增的数据？这个两个池的名字上看，一个是数据池和索引池，上传后是这样，从 bucket.data 可以看到 USED即使用容量变化，多了4.3k，这不就是上传那个文件大小吗？现在我们推断 bucket.data池应该存放的是上传文件数据，但还不能百分百确定，那那个index多出来的玩意又什么呢？为了确定我们看下这两个池里有什么东西。
image-20230518195352279

池里面有什么？

先用 看下 bucket.data 池的，发现有一个OBJ，并且名字还很长，但是名字里包含了一个 对象名字？难道这个就是上传的文件？这是还不确定，继续看下这个obj的内容 （提问： 这一大串字符是怎么来的，有什么规则？）
image-20230518203046083

可以先看下obj的信息，发现这个obj 大小刚好就是上传大小，现在可以确定，这个obj就是刚才上传的对象
image-20230518204501827

那如何看该对象 里面内容的内容呢？？？ 首先我们把这个 对象 get 出来，并比对下，发现确实是这个上传的文件
image-20230518205747544

data池 我们看过了，现在看下 index 那个池，我们刚才 从rados df 命令看到 index 池有两个对象，但list 出来却只有1个？另一个呢？？
image-20230518210353323image-20230519095408565

按道理是可以 ls 出来的，但是为什么没有呢？ 我们看下 rados 命令帮助（rados -h），发现有个可以和 ls 一起使用参数 –all, 我们试一下
image-20230519100119397

添加后发现出现两个，并且前面一个有个还是带 head 的，上面帮助也提到 -N namespace，可以知道 这个 head 指的是一个namespace（命名空间），我们试下 -N 参数
image-20230519100321879

发现加了 -N head 其实就是指定了一个命名空间并 ls， 而 –all 是全部， 如果都不加则是ls 出默认的不在命名空间的

image-20230519100707659

按时看data 池的方法我们继续看下 index 池里面对象大小以及内容； 可是size 为0，一个空对象？ 既然没有什么内容，那存在的意思是？ （提问： size 0就没有东西了?）

扩展: xattr

这里就不得提及下 文件系统扩展属性（attr）的 概念了（允许用户为文件或目录添加自定义的元数据（描述数据的数据））

举个例子 ： 我创建了个文件，大小也是0的，但是尽管是 元数据是0 ，我依然可以添加一些属性去描述这文件
image-20230519114347567

添加两条attr ，并查看， 可以 看到 文件大小为0，还是可以携带元数据的
image-20230519115335925image-20230519115547120

回到 index 池，按道理，index池中 size 为0 的也可能会有类似于 attr的东西，但要怎么看呢？ 还是通过 rados -h 看下帮助image-20230519123329970

可以看有三种 ： xattr ， omap， omapheader （三个元数据的作用是？）

先看下 index 池 head命名空间里的xattr，可以看到有很多我们比较熟悉的字眼，acl，manifest，我们这里先选一个user.rgw.acl来看看

image-20240220205258982

有很多xattr，先看下 较为熟悉的ACL，使用 getxattr，可以获取，但是打开是乱码….

image-20240220205317842

怎么办？ ceph里面有个工具专门解码 ceph-dencoder 工具可以将这些乱码输出成 json格式（第一个 是指定怎样的结构体进行解码，第二个是输出的格式，有兴趣可以研究下）
image-20240220205333747

我们刚才看到的这写xattr，其实就是 描述这个对象的元数据，有兴趣可以看下 user.rgw.manifest ，这个属性记录了对象的大部分的信息；

看下 index 池里的另外一个obj
image-20240220205344935

发现没有 xattr，却有 omap，和 omapheader

看下 omap有什么内容，可以从内容给上看是刚才上传文件 ceph.conf 的索引信息，假如我再上传一个呢？

image-20240220205406879

上传一个 acl_new文件，发现 key多了个 acl_new，相当于是往桶里上传一个文件，这里就会多一个key
image-20240220205435695

看下 omapheader，查看的具体方式和上面看xattr 一样，都是需要 取出来后 用工具解码， 那这里面内容是？

池里的数据放在哪里？

实际上 以上所说的都是我们用一些工具看到的，就好比一个大小为0的空文件，他可以带有很多 attr，这些attr也肯定是 占据磁盘空间的，那我们上文说介绍的 很多obj，以及xattr 具体是存放哪里呢？会是那个目录呢? 还是以 data 池的为例，data池里面有两个 obj，首先我们 探究下这个 两个obj 都放在哪里
image-20240220205522013

大家都知道 数据是有osd 管理的，没错，那我怎么知道 这个obj 是放那个osd呢？ 可以使用 osd map 看到对象映射的关系； （提问：这个是如何通过 池和对象名字知道 pg的，以及如何通过pg 找到 osd）
image-20240220205537047

通过这个命令，我们得到以下信息，在那个pg 上，以及那个osd上（因为我设置是三副本），pg 是映射到 osd 1,0，2上，并且 1是 主的osd

osdmap e29: 这个是OSD map的版本号 pool 'expondata.rgw.buckets.data' (8) : 这是池名字和ID object '....': 这个是对象名称 pg 8.32b76fd0(8.0)：8.32b76fd0 是通过 池和对象的名字hash出来的，而8.0是通过pg取模而来；这表示对象 ..ceph.conf.. 属于PG 8.0 up ([1,0,2] ：这是osd的up集合，这里包含osd.1、osd.0、osd.2。由于副本级是3，因此每一个PG将会存放到三个OSD上

现在知道数据在哪些osd上了，那我们怎么知道osd 的数据 是在linux的文件系统哪里呢？ 可以通过 osd元数据查看 osd_data (PS: 为了呈现效果比较突出，我选用 的是filestore 做为存储引擎，Bluestore不支持在线浏览某个OSD下面存储的具体对象数据，需要将OSD进程停止之后，才能用ceph-objectstore-tool或ceph-kvstore-tool之类工具进行访问 ，因为bluestore 直接写到裸盘上面，由于无文件系统，在系统无法看到具体文件（需要用特定的工具挂载)）， osd meatdata 可以查看很多信息，如ceph 版本，内核版本，使用的是哪些设备，网络平面端口等…
image-20240220205610947

进入osd data目录有什么内容，发现只有 很多文件（osd重新载入时需要信息），以及一个目录，进入这个目录看看

image-20240220205625849

目录里面又有很多目录！ 这些是什么呢？

看如下两副图你就明白了

image-20240220205648667

image-20240220205700863

可见 我们一直说的pg都是以一个文件夹的方式保存的！刚才我们 用 osd map 知道 对象所在的 pg是 8.0；进入 8.0_head 目录，8.0_TEMP(改目录是为pg temp准备的这里不过多讨论)；可以看到有个文件，并且带有cpeh.conf ，我们打开看看

image-20240220205749546

index池 还有两个obj，通过上面的方法看看是放在哪里，按照先前的方法并没有知道…
image-20240220205803364

在看下这个 命令的帮助 ceph osd map -h，发现其后面还可添加个待选项 namespace，刚好这个 obj 也是就是在 命名空间head下的，添加 head后，确实找到了该obj的路径image-20240220205831253

上面我们有说过这个obj 虽然为空，但是带有该文件的一些属性，并且以attr形式存放的，我们现在知道该文件的放哪里了（摸得着），用前面介绍过的 attr 命令查看，并比对下 用listxattr 看到的元数据，发现时一样的
对于omap 呢？index池里 dir开头的对象里面存放了两个 omapkey，按道理我们也是是可以知道到
image-20240220205904228

对于 omap 也是k-v 形式存在，但是呢 用了 RocksDB 来存放 ，回到osd data的目录，我们可以除了pg文件夹，还有个omap的目录，这个目录底下存放的就是 RocksDB 数据（这里不继续深入了…）
image-20240220205924010

ceph 里面也有对应的工具查看 omap的（用这个工具，需要把对应osd停掉，只能离线使用…）
image-20240220205943470

前面看到有两个omapkeys ， 我们可以过滤看看
image-20240220205956491

发现确实有这个两个，通过 dump [prefix ] 看看有什么 也是和最开始 getomapvals 获取的结果是一样的

image-20240220210013795

image-20240220210024843

可以看到就是我们上传的那个文件，以上 我们从 s3cmd 上传文件到桶里，再到对象在哪个池，池里的对象有什么，对象的元数据有那些格式的，以及池里面数据在哪里存放的，做了一个大致的梳理