ceph对象存储使用的一些思考
-
导言
我在某司做对象存储约4年时间，作为研发人员，接触过大量的市场项目，对国内市场上对对象存储的使用有一些了解和思考。本文主要是对本人经历的过往对象存储项目中发现的一些问题进行总结。
背景如下：- 基于ceph版本进行开发并进行市场交付。
- 行业覆盖通信、金融、互联网、车企、测绘等行业。
-
ceph对象存储的弊端1：元数据过大
在ceph对象存储中，每个对象（或者叫做文件）都有rgw层携带的元数据信息（即，XATTR）。
表中结果以对象名111为例，未开启多版本。对象名越长，manifest、acl和dir_entry占用字节更多。xattr属性一般是存储在ssd介质中，而ssd介质的空间是有限的。
也就是说：上传一个1K的对象，其默认的元数据就占了差不多1K多。这对于空间的占用和浪费是不可忍受的，尤其是在数据recovery重构的时候，更是灾难性的问题。 -
ceph对象存储的弊端2：桶index的设计
本节或许不该叫做弊端。
index的设计带来了接下来的问题：- 桶内对象个数的限制
- 单个index过大导致的重构问题
- 桶内对象有序list的速度
先说一下当前桶index设计的好处，对象通过hash桶的分片数（默认好像是128，可以调整，甚至分裂），分别在各个index上进行记录，便于list等操作。这种hash后进行记录，大大提升了读写速度。再说弊端。
弊端1： 官方推荐分片数不超过65535，且每个分片上不超过10万条记录，则限制了单桶最多的对象个数为65亿左右。然而国内市场的大部分使用者都不会主动进行分桶的设计和使用。 暴力使用的后果就是单桶对象往往超百亿，这也为后来的生命周期处理和有序list带来了不小的挑战。xsky后来推出了单桶千亿的功能。将元数据管理单独拎出来，确实是一种解决思路。但单桶对象过多会导致弊端2和弊端3的问题。暂时从我的理解来看，该问题是一个无解的问题，只能进行舍弃。
弊端2： index对象（存储在.rgw.bucket.index存储池中，或者元数据池中，一般是ssd介质）一般记录的是对象的记录，多版本信息、分片信息、多站点等。如果对象过多，index对象一般较大，可能会在1G以上。 当ssd盘发生坏盘、ssd换盘或者节点宕机重启，触发对象recovery重构时，则会阻碍业务的写操作，该动作是致命的，虽然可以调整recovery速度，但是还是会对业务产生不小的影响，除非完全不重构。
**弊端3：**分片数过多，会导致有序list的耗时倍增。因为每次有序list都需要和osd进行多次交互。性能较差，耗时较长。
1）每个桶都有默认的1024个索引分片，索引分片上记录了对象名等信息。
2）桶内对象的list其实是访问桶的索引分片，获取对象的oid信息。
3）桶索引分片的结构是omap结构，单个分片是有序的，分片之间是无序的。
4）有序list存在的意义有两个：一是对象有理论上的目录结构，需要有序返回显示；二是S3的标准需要有序的返回对象列表。
和osd的交互增多，意味着list的时间长。
吐槽：其实单桶上亿时，客户就不要想着去list了，但是某些用户就是。。。
自己的一些思考：
1）引入单独的元数据管理机制，当前ceph的元数据管理机制其实不太适合海量的对象文件。
2）ceph也在尝试引入DBStore，让用户自己去使用各种数据库，但感觉不是长久之计
3）或许国外的使用者不会这样粗暴的使用存储桶。。。
-
ceph对象存储的弊端3：桶生命周期的设计
生命周期会定时（默认是0点-6点，可调整）进行 遍历 桶内对象，判断是否是需要处理。当生命周期的桶较多，且桶内对象较多时，往往删除或者转移的速度跟不上写入的速度。存储空间来不及进行释放。 -
删除对象
过于依赖桶生命周期进行删除。 删除速度跟不上，存储空间得不到快速释放。- 后来我们团队写了个脚本，直接多进程遍历桶index对象，判断对象是否过期，然后进行删除。
- 且缺乏直接清空桶的操作，我们团队也补充了该功能。
-
总结
常规的使用ceph对象存储，问题不大。丰富的SDK文档和协议接口，帮助开发人员能够较好的使用存储。但是上述问题，却是我们在上市项目遇到的绝大对数复杂问题，也是对象存储的难点和重点改进方向，至少在我看来是的。