Yig S3 协议兼容的分布式对象存储系统 项目简介
Yet another Index GatewayYig 是 S3 协议兼容的分布式对象存储系统。它脱胎于开源软件 ceph ,在多年的商业化运维中, 针对运维中出现的问题和功能上的新需求,重新实现了一遍 radosgw 用于解决以下问题:单 bucket 下面文件数目的限制大幅度提高小文件的存储能力bucket 下面文件过多时,list 操作延迟变高后台 ceph 集群在做 recovery 或者 backfill 时极大影响系统性能提高大文件上传并发效率Yig 设计设计一个新的存储系统解决以上问题,无非这些思路隔离后台 rebalance 影响根据 haystack 的论文,默认的 filestore 或者 bludestore ,并不特别适合小文件存储,需要新的存储引擎radosgw 对 librados 提高的 omap 和 cls 用得太重,我们如何简化架构,让代码更容易懂,也更不容易出错。更加统一的 cache 层,提高读性能架构如图所见:从整体看,分为2层:S3 API layer,负责 S3 API 的解析,处理。所有元数据存储在 hbase 中,元数据包括 bucket 的信息,object 的元数据(如ACL,contenttype),multipart 的切片信息,权限管理,BLOB Storage 的权值和调度。所以的元数据都 cache 在统一的 cache 层。可以看到所有元数据都存储在 hbase 中,并且有统一的 cache ,相比于 radosgw 大大提高的对元数据操作的可控性,也提高了元数据查询的速度。BLOB Storage 层,可以并行的存在多个 Ceph Cluster 。只使用 rados_read/rados_write 的 API 。如果其中一个 ceph cluster 正在做 rebalance ,可以把它上面所有写请求调度到其他 ceph 集群,减少写的压力,让 rebalance 迅速完成。从用户角度看,所有的写入并没有影响,只是到这个正在 rebalance 的 ceph cluster 上的读请求会慢一点儿。大规模扩容也非常容易,比如存在这种情况,初期上线了5台服务器做存储,发现容量增加很快,希望加到50台,但是在原 ceph 集群上一下添加45台新服务器,rebalance 的压力太大。在 yig 的环境中,只要新建一个45台的 ceph 集群,接入 yig 的环境就行,可以快速无缝的添加容量。在 ceph 层提升性能使用 libradosstriper API 提升大文件读取写入性能对于大文件,相比与 radosgw 每次使用 512K 的 buf ,用 rados_write 的 API 写入 ceph 集群,yig 使用动态的 buf ,根据用户上传的速度的大小调整 buf 在 (512K~1M) 之间。 并且使用 rados striping 的 API 提高写入的并发程度。让更多的 OSD 参与到大文件的写入,提高并发程度。 拆分方法如图: 使用 kvstore 提升小文件存储性能针对小文件,直接使用 kvstore 存储,底层使用 rocksdb ,这个方案相比与 bluestore 或者 filestore 更轻。性能更好。但是要注意2点:默认的 kvstore 并没有打开布隆过滤器,需要在 ceph 的配置文件中配置打开,否则读性能会很差在 Ceph 的 replicatePG 层,每次写 object 之前,都会尝试读取原 Object ,然后在写入。这个对于 rbd 这种大文件的应用影响不大,但是对于小文件写入就非常糟糕。 所以我们在 rados 的请求中加入的一个新的 FLAG: LIBRADOS_OP_FLAG_FADVISE_NEWOBJ,在 replicatedPG 中会检查是否有这个 FLAG ,如果有,就不会尝试读取不存在的小文件。通过这个 patch ,可以极大的提升小文件的写入性能和降低 cpu 的利用率。测试功能测试因为采用了标准的 S3 接口,可以使用标准的工具。采用标准的 python boto 库测试 yig复用 ceph 社区的 s3-test 项目测试 yig性能测试ceph cluster 性能测试原始 ceph 性能,使用 rados bench 测试4k小文件的随机读写。使用 wrk 配合 lua 脚本测试 S3 API使用 ycsb 测试 S3 API 性能部分性能测试数据: 测试平台: 后台3台物理机,ceph 采用普通硬盘,hbase 采用普通硬盘,3副本方案 测试场景:写入1K小文件,然后测试在 90% read 和 10% write 的情况下(类似有于线上环境)的性能数据 测试结果:load 数据阶段性能: 可以看到即使是在3副本的情况下,S3 写入 iops 仍然很高,可以注意到没割一段时间,iops 的的性能会下降,这是由于 rocksdb 后台在做 compaction 。模拟线上环境性能:由于是读多写少的环境,iops 相比于纯写入有很大提升,也不容易发生 compact ,所以 iops 能维持在较高的水平。延迟情况是90%以上的请求延迟小于1s,平均延迟就更小了。