论文笔记：[OSDI'14] F4: Facebook's Warm BLOB Storage System

F4 是 Facebook 为了降低存储成本而开发的，应用于只读可删除不可写场景的，对象存储系统。

加入了 F4 后 Facebook 的对象存储整体架构如下图所示：

其中 Haystack 负责 Hot 对象的存储，F4 负责 Warm 对象的的存储。在其上通过 Router Tier 将请求正确的路由到相应的系统中去。由于 Facebook 的对象存储主要用于图片和视频，应用场景主要是 Feed 流，因此对象的热度和其创建时间有着非常高的相关性。在 Haystack 中对象被顺序写入 Physical Volume 中，当 Physical Volume 写满后（比如说 100GB）被设为只读但是可删除。在过一段时间之后，整个 Physical Volume 的 BLOBs 都不再 Hot 了，此时整个 Physical Volume 被移入 F4 存储系统中继续提供服务。在 F4 中，Physical Volume 被拆散成若干份（取决于采用的 Erasure Encoding 需要），使用 Erasure Encoding 生成 Parity 后得到若干 Blocks，这些 Blocks 分布到不同的节点上。不同 DataCenter 的 2 个不同 Block 会做一次 XOR 然后将结果存在另一个 DataCenter 中，如下图所示：

如果采用 Reed-Solomon(10, 4) 编码的话，相当于每个 Physical Volume 先被放大到 1.4 倍，然后两个 Physical Volume 再扩大一个 Physical Volume 这么多，因此相当于平均每个 BLOB 放大了 \(1.4 + 1.4/2 = 2.1\) 倍。F4 系统的架构如下图所示：

一个读请求的处理流程如下：

1. 通过 Name Node 找到对应的 Storage Node

2. 通过 Index API 找到对应的 Block 和 Offset

3. 通过 File API 读取对应的 Block 的对应 Offset

4. 如果这个 Block 坏掉了，就去找 Backoff Node 读取。Backoff Node 联系任意 10 个 Block + Parity 进行单 Block 的恢复

其他一些跟错误恢复相关的：

• 在 Rebuilder Node 上进行整个 Physical Volume 的恢复

  • 可以取到所有已知的 Blocks + Parity 进行恢复

  • 不行的话还可以通过 XOR 恢复

• 在 Coordinator Node 的协调下将 Blocks 根据 Placement Policy 分布到不同的 Storage Node 上

F4 因为只需要处理只读的情况，因此设计上比较简单。新的写请求会落到 Haystack 中，然后将 F4 中对应的 BLOB 删掉（只删除索引即可），因为写后马上就会迎来一波热点服务（出现在朋友的 Feed 流中）。

References

• [1] Subramanian Muralidhar, Wyatt Lloyd, Southern California, Sabyasachi Roy, Cory Hill, Ernest Lin, Weiwen Liu, Satadru Pan, Shiva Shankar, Viswanath Sivakumar, Linpeng Tang, and Sanjeev Kumar. 2014. f4: Facebook’s Warm BLOB Storage System. Osdi’14 (2014), 383—​398. Retrieved from https://www.usenix.org/conference/osdi14/technical-sessions/presentation/muralidhar

• [2] Beaver, D., Kumar, S., Li, H. C., Sobel, J., Vajgel, P., & Facebook, I. (2010). Finding a Needle in Haystack: Facebook’s Photo Storage. In Proc. USENIX Symp. Operating Systems Design and Implementations (OSDI’10) (pp. 1–14).