論文筆記：[OSDI14] F4: Facebooks 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).

推薦閱讀：