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