Facebook是如何存儲每天20億張照片的——Cold Storage系統揭秘

morris_2007

Facebook的龐大帝國需要存儲的數據時刻都在不斷爆炸。比方說，現在它每天要分享20億張照片，而且需求還在不斷增加，唯有靠不斷建設擴充存儲和數據中心才能滿足。

此前我們曾多次介紹過Facebook的數據中心（見Facebook新數據中心揭秘、再探Facebook數據中心），包括俄勒岡的Prineville、北卡羅來納州的Forest和瑞典的呂勒奧以及愛荷華州的阿爾圖納擁等不僅如此，Facebook還大量采用自己自家的技術來搭建，並且把這種經驗開放出來跟大家共享。這裏面最先進的是最新的阿爾圖納數據中心，它采用了由廉價交換機組成的網狀連接交換架構來提升性能，Facebook稱之為下一代的數據中心—Data Center Fabric。



上述解決方案對於提升數據中心的網絡性能、降低成本以及提高能效起到了非常關鍵的作用。但是對於存儲需求的不斷增加卻沒有辦法，需要Facebook研究其他的應對措施。近日，Facebook揭秘了自己的cold storage system存儲系統是如何解決這個問題的。

顧名思義，cold storage（冷存儲）存放的就是不常使用的數據，比如說幾年前的歷史數據。對於歷史數據，傳統的解決方案是采用帶庫、光盤等廉價介質來存儲的，但是這種介質的缺點在於存取和訪問速度太慢。Google不久前推出的雲存儲服務Google Cloud Storage Nearline較好地解決了這個問題。

設計原則

不過Facebook團隊決定用全新的角度去審視問題，他們從頭開始，以端到端的方式重新設計了軟硬件。

1）節能降耗

在這套以存儲為核心的Cold Storage System中，存儲資源是按需啟動的，同時摒棄了冗余發電機或備用電池等以提高能效。由於cold storage采用的是低端商品化硬盤，硬件方面的約束要求進行命令批處理要非常小心，並且需要犧牲時延以換取效能。其對物理盤的存取是以平均故障間隔時間為基礎控制硬盤的忙閑度（占空比）的。

2）智能管理

由於前面為了省電降低成本舍棄了備用電，這就要求軟件任何時候都能應對哪怕是最小的電力中斷，避免出現數據丟失的情況。

此外，數據還要具備持久性並保證完整性。為了保證持久性，系統設計時每一層面都要考慮持久性，消除單點故障，以盡可能少的步驟恢復整個系統，Cold Storage甚至連單獨管理元數據的系統都是可有可無。也就是說，數據本身即可自我描述，不需要借助外部就能夠輔助進行恢復。這麽做的原因在於cold storage是其他系統數據丟失情況下的最後一道防線了。

3）面向未來

考慮到Facebook的數據設計時還需要考慮未來。很多系統在規模擴大或者利用率上升時往往就會性能下降或出問題，所以Facebook的這套系統一開始設計時就得考慮如何避免這一問題。


Facebook在Prineville的Cold Storage設施

基於上述考慮，目前Facebook已經在Prineville及Forest兩個中心建設了兩套cold storage系統，裏面存放著數百PB（100萬）的數據。不過如此的高容量其能耗僅為傳統存儲解決方案的1/4。而且跟一般系統不一樣的是，這套系統的性能並不會隨著規模擴大而下降，恰恰相反，系統越大性能反而越佳。最後一點值得關註的是，Facebook的這套存儲系統采用了十分經濟高效的冗余備份方式，可以以低於2的系數實現數據的備份冗余。從以上幾點來看，作為一套半在線半離線存儲系統，cold storage表現出來十分理想的特性。當然，要想發揮這套系統的效用，還需要Facebook開放計算體系如開放機架、網絡、數據中心等其他組成部分的配合，一般人想學並不容易。

Cold Storage System的基礎是Open Vault Storage。這是一套專門針對Open Rack（開放計算的機架標準）打造的簡單高效的存儲解決方案，它采用了模塊化的I/O拓撲，2U機框可容納30塊硬盤（每托盤15塊硬盤，橫放而不是豎放），幾乎可以與任何服務器互操作。Cold Storage就是在這樣一套高密度的JBOD（Just a Bunch Of Disks ，磁盤簇）存儲基礎上修改而成的。


Cold Storage機架

硬盤按需啟動，電耗降到1/4

降低耗電是系統一開始的設計目標之一。據介紹這套系統的耗電極低，降到了傳統數據中心的1/6。其手段之一是以空間換降耗。數據中心占地面積非常大，滿容的情況下每數據大廳可支撐1000PB的存儲容量。隨著以後單盤容量的提升，其存儲規模還可以進一步擴大。

同時由於cold storage system存放的不是活躍的生產數據，而是歷史數據，所以Facebook把冗余電力系統（不間斷電源、發電機、備用電池等）也撤銷了，從而進一步提升了能效。


架內布置，每2U放30塊硬盤，電源插框放中間位置

為了盡可能降低能耗，Cold Storage允許服務器可以不帶硬盤啟動，然後由軟件來控制忙閑度。不過這樣就要求對Open Vault存儲規範進行修改。其最大的改動是每次只允許每托盤有一塊硬盤上電。為了避免軟件bug錯將所有硬盤上電導致數據中心保險燒壞，Facebook甚至還專門修改了硬盤驅動器的固件。

此外，由於不必每次都要給所有硬盤供電，每個存儲節點散熱風扇的數量也從6個降到了4個，供電機框數從3個降到了1個，供電單元數從7個降到了5個，Open Rack機架母線數特從3條降到了1條。這樣的調優令機架的存儲密度大大增加，每機架可容納2PB的存儲容量（4TB硬盤），與傳統存儲服務器相比，其耗電只有後者的1/4。


2U機箱，5*3塊硬盤，綠色的是SAS擴展板

用經濟的方式保證數據安全

傳統上為了保證數據的安全，一般會采用多副本技術來避免硬件故障，但這麽做需要拷貝幾份數據，造成了資源的浪費，能不能在存放的數據不多於兩份的情況下避免數據丟失呢？

尤其是Cold Storage采用的都是些廉價硬盤，而且又沒有備用電池，故障中斷等情況都是難免的。

怎麽解決呢？Facebook采用了Reed Solomon Coding糾刪碼技術。糾刪碼是存儲領域常用的數據冗余技術，其基本原理是將原始數據切分為n塊，然後根據這幾塊生成m個校驗塊。利用算法，從從n個原始數據塊和m 個校驗塊中任取n塊就能解碼出原始數據，也就是說進行這樣的處理後，哪怕有m塊數據同時丟失數據仍能恢復。通過將這些數據分到不同的故障域（如硬盤），Cold Storage就可以以較小的成本實現數據的保護。顯然，校驗塊越多，可容忍的數據塊出錯數也就越多。當然，其代價是額外需要的硬盤也越多。

那多少才合適呢？這需要對硬盤的失敗特征進行調查和建模才能確定數據分塊數和校驗塊數。Facebook目前的配置是10:4（每10塊硬盤配4塊校驗盤）。也就是說，用1.4GB的空間實現對1GB數據的備份，這種情況下可忍受4塊硬盤同時壞掉。但是這種配比也會隨著硬件特性以及對安全性的要求而變化的，因此Facebook開發了數據重新編碼服務，這樣就可以根據情況變化（存儲媒體的可靠性）來重新靈活組織數據。


RS糾刪碼技術，把1GB數據切分為10塊分別放在10塊硬盤，另用4塊硬盤放校驗，可容忍4塊硬盤同時壞掉

與以往模式相比，這種備份方式效率顯然高得多，而且數據的持久性也大為增長。不過糾刪碼只能應付數據丟失，但是對於篡改卻無能為力。為此，Facebook通過創建、維護及檢查校驗和來驗證數據的完整性。而且這些校驗和就挨著數據存放，一旦發現錯誤就馬上從別處復制一份過來。

俗話說大腦越用越靈，不用則衰，存儲也是這樣。完全閑置或者不動的數據容易損壞，這就是所謂的“位衰減”。為此，Facebook在後臺開啟了一個“反熵”進程，專門用來定期掃描所有硬盤上的數據，從中檢測數據畸變並報告。這個頻率是每30天一次全掃描。一旦發現錯誤，另一個進程就會接管，然後讀取足夠多的數據去重建丟失的數據，並將其寫入到新的硬盤上。由於整個過程將檢測、失敗分析與重構及保護分離開來，重構的耗時從小時級降到了分鐘級。

Facebook還對數據存取進行了徹底改造。由於大多數現代文件系統在設計上的缺陷，這些文件系統基本上無法勝任短時間內進行大量頻繁的加載與卸載操作。而且而且由於文件系統處在非常底層的位置，導致錯誤調試非常困難。Facebook的做法是跳過文件系統，將所有硬盤移植為“裸盤”。這樣的好處是可以掌控整個數據流，從而進一步保證數據的持久性。

規模越大性能越好

傳統系統往往規模越大性能就開始下降。Facebook希望避免這一點，甚至定下了越大越好的目標。其做法是每次增加容量時軟件都要對現有數據進行再平衡—即將原有數據分配到新的硬件上，並釋放之前用過的空間。這個過程並非實時進行，十分適合於在用系統的逐步移植，即既不影響系統的使用，又能逐步將數據遷移到新硬件上。如果把Cold Storage看作一塊大硬盤的話，你可以把這種再平衡的做法視為智能硬盤整理程序。

未來計劃

通過將冷數據（歷史數據）與熱數據（生產數據）分離、用冷存儲系統處理冷數據的做法，Facebook得以實現降低能耗及節省其他資源節省的同時服務好數據請求。不過盡管目前Facebook的兩套cold storage系統已經有數百PB的數據，但是這還只是整個數據量的1%，而且Facebook的數據每天還在不斷增加。因此，社交巨頭還需要繼續擴大自己系統的規模，同時還將探索閃存、藍光盤等各種存儲媒介的利用，以及研究跨數據中心分布式存儲文件數據的方法以改進持久性。

本文編譯自：code.facebook.com

http://36kr.com/p/532802.html