Facebook's Tectonic Filesystem


Facebook’s Tectonic Filesystem: Efficiency from Exascale

0x00 基本架构

这篇Paper是关于Facebook的一个分布式文件系统,Tectonic。这种类型的分布式文件系统最经典的设计为GFS。但是GFS的设计存在一些取舍,这些tradeoff可能在今天就不是很适合了。所以近些年出现另外的分布式文件系统的设计,其特点比如使用分布式的Key-Value or 数据库等代替取代GFS中使用逻辑上单个的Master,元数据保持到内存中的设计;使用分布式的存储池系统来代替Chunk Store。总体上元数据和数据的存储都变得更加解耦,都是用更加通用的分布式存储系统,而这个Distributed FS更加聚焦在维护文件系统的语义上面。Tectonic 也是一个类似的设计。Tectonic整体的架构为见1. 元数据通过hash partition的方式保存到一个分布式的key-value store中,2. 数据保存到一个分布式blob store中,3. 另外在multitenant有不少的一些内容。

Tectonic的总体架构如上图所示,在Tectonic中:

  • Chunk Store就是一个一般的Object Store,其保存了数据的Chunks,其由文件的Blocks组成。Paper中这里描述的是 Chunks make up blocks,paper这里描述的简短,不是很清楚。从上下文来看,应该是Tectonic中的文件系统又一些blocks组成,block在chunk store中,一些block组成来一个chunk。也就是chunk作为chunk store层面的抽象,而block为FS层面的抽象。而在操作的时候,block做为单个的逻辑单元和持久化单位。而Chunk Store更像是一个Block Store,一个Chunk最终保存到storage node的文件系统之上。这里storage node来保存chunk,而不是使用裸盘等更加激进的方式。做这样的一个Chunk Store会有不少的内容,但是paper中对这里没有多少的描述;

  • Block写入的时候会被EC之后写入,根据EC编码RS(r,k)的配置将数据拆分为r个data chunks和k parity chunks,在保存到不同的fault domains内。对于不同类型的数据,会选择不同的EC配比。这里对于短生存时间的文件,会使用更小的配比,比如3+3。Client直接写入Chunk Store。写入chunks选择那些磁盘在考虑了fault-daomins之外,也不是随机选择的,而是会维护一些固定数量的Copysets,在data unavailability和reconstruction load之间取一个平衡。因为如果是随机选择的,即copysets数量非常多,较短时间内有多个disks故障的情况下丢失数据的可能性会更大,而copysets太少的话,数据恢复的带宽受限;

  • 元数据转化为key-value的形式保存到一个分布式KVS中。映射方式对于文件路径上的信息,就是id+name的方式,通过不变的id加上变的name组合,方便rename的操作。对于文件的数据,通过file id映射到block id,在通过block获取到保存到哪里的chunks的消息。这个kvs使用的是其ZippyDB。在数据分区上,这里选择了和一般不同的hash分区的方式,其优点之一是可以避免掉一些热点的问题;

  • 在上面的元数据和数据不同的服务之外,还有诸多的后台服务,比如rebalance、GC和一些后台数据收集和数据检查的一些服务。这些里面有不少在工程实现上,也应该是比较麻烦的,比如GC,paper中对这些没有描述。

0x01 Multitenancy

这里后面就花了较大的篇幅来介绍Tectonic Multitenancy的特性,其希望使用一个 approximate (weighted) fair sharing,基本的思路是一个资源共享,又能在不同的tenants之间实现资源隔离。Tectonic先将资源分为不同的类型: non-ephemeral 和 ephemeral两种类型,前者指的是存储容量之类的会长期占用的资源,而ephemeral指的是想Storage IOPS capacity 和metadata query capacity这样的的占用会快速的变化的资源。

  • 对于ephemeral类型的资源,tectonic认为将tenant作为粒度来管理资源不是一个好的方式,因为一个tenant内部也会有不同的workload,不同的性能要求,另外一个是因为application数量太多,管理起来会比较麻烦。所以Tectonic使用的方式将application分为TrafficGroups的方式,一个group里面的应用类型的资源要求,而不同的tenant可以将其不同的应用划分到不同的group。一个Tectonic集群里面一般支持50个左右的TrafficGroups,每个会分配一个TrafficClass,其表示了对性能的一个要求和获取资源的一个优先级。
  • 也就是说Tectonic利用Tenants 和TrafficGroups,在TrafficClass的方式下实现ephemeral资源隔离。每个tenant会分配到其可以得到的一定的ephemeral资源数量,然后这些ephemeral资源会被再tenant内划分给tenant内不同的TrafficGroups。如果一个tenant中某个TrafficGroup的资源过剩,则可以通过降低其TrafficClass的方式提供给其它的TrafficGroups使用,再剩余的也可以通过同意的方式分享给其它的tenants。这里就是一层TrafficGroup 加 tenants,在加上TrafficClass几个层面的一个Multitenancy的方式;
  • 对于全局的资源共享方式的实现,在client的层面其client library会使用一个rate limiter服务来请求做一个limiter。请求的时候会根据自己的TrafficGroup,同tenant内其它的TrafficGroup,以及其它tenants的顺序,检查有没有剩余的资源。有得时候在去请求,否则会等待 or 拒绝请求。对于服务node的层面,metadata和data节点本地的资源,也会使用一种local resource sharing的机制,基本方式是通过一种 weighted round-robin (WRR) 的方式,在会超出本地资源容量的时候不给一个TrafficGroup分配资源。另外要考虑的一些问题是要避免小IO请求收到大IO请求的影响,还有就是如何尽量保持高优先级对性能的要求。Paper中描述的一些方式有: 在低优先级/lower TrafficClass的请求还剩余足够的时间去完成它的请求的时候,可以先让给高优先级/higher TrafficClass 先操作;另外一个是会限制操作过程中的非高优先级的请求的数量等。

Paper中还提到tectonic为一些具体业务进行的一些专门优化:

  • 比如针对Data Warehouse的应用,比如对不同类型的文件使用不同配置的EC编码,对于 write-once-read-many使用方式最一些特定的优化等,比如buffer数据到一点大小之后再去写入,在这种情况下close文件之后再去读区数据,这样一致性就在buffer数据的方式下也能保证;
  • 另外为了优化tail latency,使用了一种quorum writing的方式,也利用了hedge请求的思路,但是不是使用发送多个实际请求的方式,而是讲探测请求提前到实际请求之前的方式。这个方式解决了hedge请求带来额外IO的缺点,基本方式是在发送请求之前,先发送一个reservation请求,使用reservation请求先返回的节点写入数据。比如按照EC 9+6写入的时候,可以先向19个存储结点发送reservation请求,选择先返回的15个写入实际数据,14个返回成功之后就返回结果给client。
  • 另外一个是对blob存储的一些优化,比如其对低延迟的一些需求,其使用的方式是partial block quorum appends。其通过写3副本,ack 2个的时候就可以返回来降低延迟。而为了降低存储的开销,和小对象在写入延迟上面做一个tradeoff,这里先写副本,然后在转编码为EC的方式。

0x02 Production总结

这里主要是实际应用过程中的一些总结。

参考

  1. Facebook’s Tectonic Filesystem: Efficiency from Exascale, FAST ‘21.