【存储论文笔记】Facebook’s Tectonic Filesystem: Efficiency from Exascale

研发背景

1. 不同业务类型需求不一致，有的是IOPS敏感型，有的是吞吐敏感型，当前facebook不同的业务类型使用独立的集群导致不能同时充分利用集群的吞吐和IOPS资源，造成资源浪费。
2. 对于一些数据仓库业务，通常其容量需求巨大，单个集群无法满足，所以一个数据仓库的数据需要存储在多个小集群中，这种方式使得数据处理复杂度提升了。

因此，facebook这次推出的tectonic存储系统有两个特点，一个是同一集群可以提供不同业务需求的服务，另一个是单个集群能够达到EB级别的扩展能力。

那么同一集群及提供IOPS敏感类型的服务也提供吞吐敏感类型的服务，那么就需要有能力提供性能隔离，减少一种业务类型对另一种业务类型的影响。另外，对于一个集群提供EB级别的存储能力，在小文件场景下，元数据量会很庞大，需要有能力保证随着存储数据量增加带来的元数据量膨胀，需要元数据存储具备同样的强悍的扩展能力。

实现架构

Tectonic’s design generally prioritizes simplicity over efficiency.

与大多数分布式存储系统的架构一样，tectonic也是client、metaserver、chunksever这样的组成结构，同时由于tectonic对外提供的是appendonly的读写接口，所以在底层不可避免的需要引入GC等后台任务处理角色。在这些角色中只有metaserver和chunkserver是有状态的，其他都是无状态服务。

作为一个可以单集群扩展到EB级别，同时提供多种业务类型的分布式存储系统，我比较关注以下几个问题：

1. metadata管理
2. 单集群如何平衡不同业务类型的需求？

元数据管理

元数据存储

tectonic的元数据存储在名为ZippyDB的KV存储引擎中，这个ZippyDB内部是封装了RocksDB。

为了提供简单的且更容易扩展的元数据存储方式，tectonic采用细粒度的元数据切分方式，通过对元数据进行hash partition的方式在多个元数据存储节点之间打散元数据，这种方式同时也会避免目录热点带来的热点访问问题。

元数据根据hash partition策略切分成一个一个的shard，然后这些shard会有一个高可用复制组，通过Paxos算法在复制组见复制元数据，保障数据可靠性。

需要注意的是，tectonic并不在shard之间提供事务性保证。

tectonic的文件系统相关的元数据如下：

其hash partition的粒度是dirId，fileId，blockId，这种切分力度已经很细了，好处是其比较容易scaleout且避免热点，坏处也比较明显，会很容易出现跨两个shard的元数据操作。

元数据优化

• 元数据量优化
  海量小文件的存储一直是一个比较有挑战的问题，海量小文件意味着庞大的元数据，在对读写延时有要求的场景中，元数据操作效率很低影响IO质量。
  tectonic其实做法也是常规做法，将多个小文件组合成大文件，记录小文件的offset映射关系。
• Sealed file/block/directory
  seal的file/block/directory由于不会再被改变，所以可以cache在存储节点，提高访问效率的同时也不违背一致性。
• single writer
  与HDFS类似，tectonic也只提供single writer的写入模式，这样极大的简化了元数据一致性访问的设计。
• 存储优化
  如果目录d1包含了两个文件foo和bar，那么tectonic在存储的时候存储了两个带有d1前缀的key在Name元数据shard中，这种方式好处在于如果需要修改其中的一个文件元数据信息，不需要读取整个目录，这种在海量元数据场景中还是很有帮助的。

资源平衡

资源分类

Tectonic将资源划分为： non-ephemeral and ephemeral。可以理解为可重复使用的和不可重复使用的，对于存储资源，一旦分配给一个租户就不能再分配给其他租户了，那么他就是不可重复使用的，是一个长期占用的资源。但是对于IOPS这样的资源，租户只会在发请求的时候使用到，并且这个请求结束后IOPS资源就被释放出来了，他是一个暂时的占用。

这个也是为什么大多数云厂商通常都是IOPS超售，存储资源不超售的原因。

因此，可以看出我们能够做文章的也就是这些non-ephemeral的资源。这里的挑战在于，首先我们既要满足每个用户的最基本的存储需求，另外还需要给不同类型的用户提供符合其业务类型需求的优化。

用户分类

tectonic服务的application数百个，所以在进行资源调度的时候如果以application为粒度，那么整个调度会异常复杂。所以，为了简化资源调度，不按application分类，按照traffic group分类。

同一traffic group里的application其资源需求相似，在单个集群中，tectonic支持50多种traffic group。

一个traffic group对应一个trafficClass，trafficClass代表该group对于请求latency的敏感程度，这里分为金、银、铜三个等级，对应的延时敏感性从高到低，同时也对应了其IO优先级。这里需要注意的是，这三个不同等级影响的IO优先级仅限于那些富余的IOPS资源。如果这个集群的在服务当前所有租户没有盈余，这些金银铜等级就没有意义，这点其实很类似mclock的调度模式。

所以，资源平衡只是针对满足了集群所有租户必要消耗基础之上的调度。

当一个请求下发时，在client端需要先经过漏桶，告知自己需要多少的资源，client检查自己的trafficgroup的资源够不够这次IO，够的话就将请求下发到底层存储节点(tectonic不仅对存储节点进行了资源平衡调度，同时也对元数据节点也有一致的优化)，存储节点采用权重轮训(WRR)的方式，依次处理到来的请求。

在存储节点调度IO时有如下三个优化：

1. 如果一个低优先级的IO其处理时间足够的情况下，WRR会转让本次执行权限给高优先级的IO，这个策略防止高优先级被低优先级IO阻塞。
2. 对于非金牌优先级的IO，在存储节点会限制其inflight IO数量。在达到非金牌IO inflight上限时，如果有金牌IO需要处理，都会先处理金牌IO，再进来的非金牌IO都会被阻塞。
3. 磁盘本身也可以参与重排请求顺序，如果一个金牌IO已经在磁盘pending太久超出阈值，tectonic会停止调度非金牌IO。

总结

在元数据管理上创新点并不多，主要还是常规的做法，小文件合成大文件，当然在元数据存储上一些优化还是很好的适用于海量存储。在总体设计上为了简单，也做了一些妥协，比如元数据打散粒度太小会导致很容易出现shard之间的元数据操作。同时，hash切分的方式对于循环获取文件目录内容不友好，需要多次在多个元数据节点之间进行IO。

在资源平衡上，个人觉得本质上类似于mclock调度算法。

reference：

1. Facebook’s Tectonic Filesystem: Efficiency from Exascale