該文檔即講實打實的技術問題，又說了心貼心的生態現狀，產品決策和技術選型人員都可以來看看。

1. 前言和背景說明

能搭建和使用PB級存儲一直是強悍但無用的屠龍絕技，我們更多將其用於炫耀和吹噓。但最近兩三年，我接觸了數十家存儲量到PB級的客戶，深感屠龍絕技已經不再是擺設。

下列變化導致了PB級存儲需求的橫空出世，連帶著CDN、大數據、AI技術一併發展。

首先看數據是因何產生的：

• 4G和光纖網路普及，帶寬提速但資費降價，UGC和PGC都如魚得水。

• 智能終端的硬體競賽讓攝像頭更清晰、感測器更靈敏。

• 物聯網設備入網，例如感測器數據、醫療影像、基因測序、氣象數據。

數據保存下來不代表有價值，曾經我們保留幾百TB的日誌，卻只能做最簡單的加減乘除統計，或者用於出問題後扒日誌堆找證據；我們可以下載數萬部影視劇，但一個人一輩子都看不完這些視頻。

現在某些營銷雲已經可以做到毫秒級響應做精準廣告投放，用戶的日誌更有價值了；人工智慧逐漸參與輔助醫療，醫學影像數據值得保存十年了。隨著技術進步價格降低，無論是監管政策還是客戶需求，都在推動著數據總量越來越大。比如說現在您買理財產品已經要求全程錄像防止誤導消費者了，比如說人臉識別已經應用到手機轉賬審核中。

我們在一個風口時代，無數從不聯網的設備、從不收集的數據都躍上雲端，已聯網設備信息量也大大增加，作為技術決策人，必須有應對PB級存儲需求的前瞻性。

• 假設你做ToC的App，只要你有爆款的夢想，就要存儲爆倉的數據。

• 假設你是智能終端的設計者，現在生成的多媒體數據不僅僅可以被自然人拿來看了，我們還有很多想像空間把數據進行統計和處理。

• 假設你是物聯網綜合方案規劃者，數據從存5天變成了存5年，你們能做出多少更合理更有長遠性的決策？

PB級存儲需求來了，但是市面上有多少成熟可用的PB級存儲案例哪？

傳統廠商會說我沒問題，請上200個存儲櫃吧！但是就算我砸鍋賣鐵買了200個存儲櫃，存儲服務不是簡單的磁碟堆疊啊；而且提速降價的號角是2015年才的吹響的，傳統存儲設備的測試和成熟周期要5年時間吧。

前些年大量的個人網盤宣稱自己有EB級別的數據，1EB的存儲空間可是要用掉30-100萬塊4T盤啊，這些EB級網盤關停以後，這麼多閑置硬碟居然沒導致盤價跳水。專用的網盤客戶端遮住了實現細節，你的存儲技術能否復用到我的項目中？即使介面可以復用，你是在存儲群集層面真做到了PB級別，還是無數個50T小群集簡單加成的1EB？跟個人客戶做過的市場宣傳，不應該拿到企業客戶這裡當做正式承諾。

我有幸在某牛和某度兩個雲存儲廠商呆過，也親手搭建和維護過單一命名空間過PB的存儲系統。在此我和大家分享三方面的知識：

• 為什麼PB級存儲必須是對象存儲？

• 如何採購和使用對象存儲。

• 如何設計和實現一個PB級對象存儲。

2.大存儲必須是對象存儲

2.1目錄樹的無奈

當我們還是兒童的時候，想的是掙大錢了買什麼？絕對不是買房買車買彩票，而是買玩具食物和小衣服。當我們從GB級用戶變成PB級用戶時，傳統存儲用法已經過時，為通用需求設計的的PB級存儲都必須用對象存儲介面。

假設你有10PB存儲，每個文件100M大，那麼你會有1億個文件。一億個文件你該如何組織目錄結構？我們不考慮文件系統設計上限，我們也假設inode沒有耗盡，無論你是每個目錄下放100萬個文件，還是套十萬層目錄去存儲文件，這種文件訪問和管理方式是特別笨拙和無奈。實際情況會比1億個文件殘酷的多，我們常見的文件只有1M左右，大型客戶一個項目能有數百億個文件，這是目錄樹的設計者們從未考慮過的大變局。

據上文推理，具有普遍適用性的PB級存儲，硬體存儲廠商從未實現過，因為他們不參與解決過億文件的管理問題。開源存儲方案求一直在談自己的技術先進性，如何做出又大又快的存儲，但很少有人介紹自己元數據系統在百億Metadata的性能設計。

當前能支撐PB級存儲需求的訪問方式只有對象存儲形式，比如http://mytest.baiduoss.com/ab/cd/ef.txt&token=asdf 。當客戶向存儲群集提交這個get請求時，hostname部分可以被存儲系統定位到出該存儲群集上某個租戶，在確認該租戶的token=asdf有效以後，會通過查詢metadata資料庫的方式，快速得到「ab/cd/ef.txt這個key值存儲在第80組存儲的第15個扇區」，然後存儲伺服器將文件取出發給客戶，客戶瀏覽器下載的文件會命名為「ef.txt」。

這種訪問形式不用擔心一個目錄下有100萬個文件，也不用一層一層遍歷目錄，即使1000億個文件，我們要定位文件也只做一次資料庫查詢。

2.2對象存儲對程序員友好

我們習慣了點開文件夾的訪問方式，對象存儲對人類並不友好，但這種方式對程序很友好。

曾經你寫程序必須要知道公用數據存在哪裡能不能訪問，你要關心ext4和nfs的許可權問題，偶發網路波動會讓你的所有應用全部hang住；現在你只需要拼接一個url並簽發一個token，你編寫的任何聯網應用都可以讀寫數據，數據讀寫成功都有日誌，即使讀取失敗也有可以理解的http返回值。資源可以被簡單描述、簡單調用、調用結果可信賴、即使調用失敗也能catch異常，這才是程序員想過的日子嘛。

對象存儲不僅僅讓讀寫一個文件變得簡單優雅，還讓管理一群文件不那麼複雜。市面上通用的對象存儲系統都包含下列文件信息，可以快速的管理大批文件。

• filename / key value，就是文件的名字，存儲資源的描述。

• filesize 和createtime，文件大小和文件創建時間，文件管理和統計費用，也可用於文件篩選和判斷。

• Hash/MD5等等文件指紋，文件校驗和去重使用。

• Filehandle，描述文件實際在存儲系統中的位置，這可能是物理或邏輯位置，這個信息一般不暴露給客戶。

• Mimetype或者其他的自定義文件標識，這是個擴展位，方便大存儲順路做簡單數據處理。

• Last Modified time其實是文件的createtime或meta信息的修改時間，對象存儲所有的文件都沒有修改，只有同名新文件。

• 不提供Owner信息，訪問域名已經標識了多租戶級別的Owner信息，開發者給自己的用戶頒發token的過程中就完成了對應用級Owner的標識。

常規文件系統也提供了這些信息（hash值除外），但文件系統在億萬文件管理是太緩慢了，而且很多程序員並不熟悉如何調用這些信息，哪怕只有幾萬個文件，他們也更習慣把這些信息存在數據表裡。現在有一個方便調用的API介面，這比自己維護數據表的成本更低了。

2.3 PB數據的業務場景

上文闡述清楚PB級存儲必須用對象存儲這種介面方式，什麼樣的場景會產生PB數據？即使我們現在只有10GB數據，我們也要做好成為PB用戶的規劃。

如果你要做個有百萬以上用戶級別的ToC應用，或者出貨量過百萬的智能硬體，每客戶每月產生100M持久存儲數據，一年就是1PB。最早的PB級用戶大都是圖床相冊類用戶，每月100M數據過去是100張低清照片，現在攝像頭升級只能存30張照片了；中國的Icloud付費用戶都在增加，其他有用戶自生數據的應用就更多了。

在中國這麼大人口基數的國家，只做一個百萬級用戶的ToC應用是很務實的小目標了。在沒有高性價比存儲的時代，這些應用只能犧牲用戶感受限制用戶存儲數據，只能放棄有價值的客戶行為日誌。現在時代變了，該幫客戶存的數據存起來，該為自己記得日誌記下來吧。某些智能硬體廠商通過分析日誌來精準廣告投放和運營APP市場，他們已經可以賠錢賣硬體靠廣告賺錢，但這有個前提你要先存下來幾個P的用戶日誌。

ToB業務的用戶規模遠不如ToC應用，但文件的存儲周期和可靠性要求十倍於個人娛樂用戶。ToB業務涉及人員請注意一下，帶寬和存儲已經都降價了，連帶著大數據和AI技術都在進步，以前不敢想的業務場景可以去實踐了。比如高清企業視頻會議和無人機航拍後人工智慧做設備點檢，還有一套套呼之欲出的IOT方案，這都是在促進生產力的進步。

近幾年自然數據的產生和處理能力急劇提升，PB存儲俱樂部里也有了一批高科技新玩家，我們願意幫著他們改變世界。比如醫療信息化整改，一個區域的所有PX影像要集中存十年以上，而且隨著醫療器械的更新換代，這些影像數據會越來越大。以前我們拍個CT片子是橫著切5片，一個膠片20MB，現在我們拍個CT是縱切30片，一個膠片是200M。比如基因測序，每家基因公司都立志將全人類的基因記錄一遍，錄完人類的還有其他生物可以搞。比如氣象和地質活動，現在有了更新的監測手段、更密集的監測網點，數據記錄量也翻倍增加。這類方案對存儲要求長周期平滑擴容，雲服務廠商的對象存儲會是這類客戶的最佳方案。

2.4變通和妥協

對象存儲並不是萬能解決方案，它有解決不了的問題，也願意為適應現狀做兼容和妥協。

基於HTTP協議的文件傳輸，天然無法滿足「大文件的小範圍修改且實時落盤」這一需求，最典型的場景就是資料庫的DBfile，以及視頻原片的現編操作。即使我們費盡心力讓對象存儲把自己模擬成本地磁碟，不嚴謹的兼容POSIX介面，當你打開一個1G的文件修改1k並保存時，本地文件系統只修改1k文件，而對象存儲會上傳一個1G大的新文件。

資料庫這類低延遲應用天生和HTTP協議不投緣，而資料庫活躍文件也不可能到PB級，所以DBfile很難去嘗試兼容對象存儲介面。視頻剪輯軟體倒是有兼容對象存儲介面的技術可行性，他們可以把20G大的原片分散成2000個小文件，但客戶的需求還不夠強烈，本地的帶寬還是不夠穩定，這需要假以時日。

對象存儲會主動用Fuse/NFS/FTP等手段來服務工業級數據產生設備；比如廠家幾千萬賣出的醫療儀器只支持FTP協議，這些儀器不可能主動去兼容對象存儲，那對象存儲就來主動適應這些工業設備。這些數據生產設備對存儲的需求也很簡單，就像投遞郵件一樣寫數據，根本不關心已經寫入的數據如何管理，也極大降低對象存儲兼容模擬的實現難度。

對象存儲還會用Fuse/NFS/FTP等手段來服務一些傳統客戶的低負載低需求需求，以保證盡量減少客戶的業務變化。比如說銀行里依賴一套存儲的應用有50個，其中5個高性能應用必須改用對象存儲介面，而另外45個低需求應用可以沿襲舊的訪問方式，否則換個存儲要改50套應用是推不下去的。

3.如何採購對象存儲服務

各家公有雲都做對象存儲服務，那麼該從哪些維度選存儲服務，我有一些思考和建議。不用帶任何情懷和理想，一年內能達到的存儲容量是用戶分類的唯一標準，GB/TB和PB。同樣也不帶任何理想和情懷，企業採購雲服務就是公平交易，不要奢求免費的蛋糕，我們只期望能物有所值就夠了。

3.1 小型用戶寬鬆心態

如果你是一個GB級用戶，一年內存儲量都不會達到1TB，這時候用對象存儲只是為了方便開發應用，不用太多思考存儲自身特性。

首先談價格，100G數據的存儲成本每天就幾毛錢，我不想討論如何節約一毛錢的問題。

對象存儲和雲主機沒任何直接技術關聯，它是一個獨立到孤立的服務，典型互聯網架構中，對象存儲甚至不和雲主機交互任何業務數據，雲存儲直通客戶APP。

對象存儲一般會接CDN，CDN是最成熟透明的雲應用，你可以CDN和存儲選一家，也可以只用存儲做源站，技術上不會有任何限制。

雲存儲都對接多媒體處理，市面上的多媒體處理大都套用imagemagick和ffmpeg，各家的主體功能趨同，細節毛刺上區別的這個級別的用戶感覺不出來，有新需求也會被禮貌性無視。

對象存儲的業務形態很容易被平台方竊取數據，即使你做了數據加密也可以根據你的計費日誌評估你的業務量，但你現在只有G級別的數據，暫時不用考慮太多廠商中立性。

小容量數據也很容易遷移，假設你要從雲存儲遷移100G的數據到虛擬機，總成本不超過300元，遷移時間也可以控制在一天以內。有了方便遷移這個特性，雲存儲平台有什麼讓你不爽的，直接遷走。

3.2 中型用戶三思後行

GB級用戶不在意的坑，TB級用戶全部要踩一遍；而TB級客戶在面對繁雜市場宣傳，很難看透雲存儲服務的本質內容。對象存儲都是用API介面調用，普通用戶看不到也不關心群集規模和技術細節。大家讀完本文以後可以更理性和警惕的評估雲存儲供應商。

首先說數據持久性和安全性不用太關心。雲存儲廠商都宣稱數據可靠性超過10個9，在我看來各種SLA超過8個9就已經比第三次世界大戰的幾率還小了； 平台說自己能到多少個9，我們都笑笑就好，故障出來了平台總能找到理由的。你買最貴的EMC存儲櫃也不能保證100%不丟數據，怕丟數據要設計備份方案而不是寄希望於單一硬體或服務。

TB級用戶同樣不用太關心存儲群集的性能，因為你是用HTTP協議訪問一個廣域網服務，廣域網和客戶端才是網路吞吐性能的瓶頸。幾家雲存儲廠商在SLA里都沒承諾速率，上行帶寬本來就免費，而下行帶寬都會走CDN。但是這類客戶已經出現遷移困難了，假設你有200T數據要從某雲遷到自己機房，如果你的遷移用IDC帶寬是1000M需要20天才能完成任務。

上文是撥開一些企宣煙幕彈信息，下文是TB級用戶最關注的問題。

1. 1. 價格問題。

假設你有200T數據，每年的開銷在30萬左右；這裡說談價格不是讓你死摳存儲的價格是10萬還是40萬，而是注意存儲會帶來其他消費，比如說現在存儲要計算CDN回源帶寬了，比如說兩個雲存儲互為備份帶寬同步費用有多少。當前存儲廠商是按需付費定期調價，短周期看大家都是在不計成本的降價獲取客戶，但長周期看寡頭形成競爭會淡化，存儲漲價是合法商業行為，而你數據量大且深度耦合平台業務很難搬走。企業服務市場沒有免費蛋糕，我們要適當考慮超低價服務的風險。

1. 2. 雲端處理和分發能力。

當你的數據量到TB以後，單台伺服器已經無法承載和處理這些數據了，你需要盡量藉助雲存儲平台的處理和分發能力。我本來以為這些功能大家都會各平台都有，但試讀者反饋還是建議我加上這一段。

雲存儲直接處理數據都是這樣一個形態：文件輸入來自於雲存儲，參數輸入來自於客戶的get和post請求，在雲端做一些無狀態處理，文件可以下載或存儲到雲存儲，參數輸出或者介面回調。常見的例子是圖片實時打水印有損壓縮後下載，視頻非同步轉碼另存，涉廣告圖片檢查後返回特徵碼，日誌文件檢索特定欄位，文件自定義加密解密等等。這些服務使用方便收費低廉，甚至在改變原有的開發模式，成為存儲必備的核心功能點，但是這些服務使用過程中小坑不斷。

比如說實時有損壓縮圖片這個功能可極大節省CDN帶寬提高資源載入速度，客戶端可以根據自己的設備、網路、應用場景決定要什麼解析度的圖片，此功能帶來了無與倫比的靈活性。但用戶不可能是多媒體處理專家，很多應用場景細節根本就想不到的。比如你往我的平台塞個200M大圖我是拒絕處理的，友商不管圖片多大都敢去切圖，但有30%幾率是後台切圖程序崩潰，讓你等是十分鐘才收到個50X的報錯；比如說某些音頻編解碼規範應用了半個世紀，某款新出的手機可能會出兼容性問題。這類技能太生僻，雲廠商培養技術人員都很困難，客戶要靠自己評估廠商就更難了。我的建議是多發幾個工單，看接工單的是技術人員還是商務客服，看工單處理周期和結果吧。

分發能力好理解，某網盤廠商一開始是把雲存儲掛載伺服器後端，由伺服器端的BGP帶寬來負責網盤文件下載，後來改成雲存儲通過CDN直接給網盤客戶端發數據，帶寬成本降低到以前的20%。

1. 3. 廠商的職業操守

前文剛一本正經的說雲計算是企業服務，現在怎麼突然又提到操守了？國內的雲平台都是做互聯網ToC業務起家，習慣用擺布個人用戶的伎倆去招攬企業生意，近幾年大型雲平台屢屢爆出蠻橫管理狡詐運營的醜聞。雲計算是企業服務，雲平台是我們的供應商不是我們的管理者。TB級用戶正是業務高速發展的關鍵時刻，我們更要防備某些吃相難看的混蛋。

雲存儲相對業務簡單，遇到野蠻運營的問題主要集中在竊取數據、估算業務量、惡意不兼容其他服務這三方面。

竊取用戶數據指的是監守者自盜後自用，要是泄露給第三方那是安全事故可以直接報警抓人，但平台方自用用戶數據很難抓現行。雲存儲里大都是多媒體數據，誰敢盜播打官司就好；日誌文件加密了就用不了雲端大數據分析了，但不掛個人信息的基因測序樣本被偷了也不怕。如果客戶真的特別害怕丟數據，雲平台確實沒手段能自證清白，誰偷過用戶數據只能聽業內風聞。

真正讓用戶頭疼的是平台方會根據計費日誌估算你的業務規模，就像小區保安總共能看到你何時出門一樣。據不可靠傳聞，某廠商本來能拿到某雲廠商母公司數億美元投資，自吹數據量有數PB，該司投資部去調了一下他們的消費金額就取消投資了。單一個消費總金額就這麼麻煩,訪問日誌可以看文件數量、用戶規模分布和大致的動作類型，一個新興企業最好還是把業務分散在兩個廠商那裡，畢竟他們兩家不能核對你的賬單。

最後一條就是有些領先大廠直接壓制，故意做技術無關的不兼容、甚至拒絕服務、甚至從其他層面正面打壓業務。這裡就不舉例了，太明顯針對單一廠商。如果只是技術不兼容那算和其他雲平台惡意競爭，如果到了雲平台明搶客戶自身業務的階段，技術採購決策人請把風險告知公司決策層，該妥協還是硬扛不是你的職責範圍。

3.3 大型用戶謹慎選型

大型用戶即使只存儲1PB，每年也要花100多萬了；中小型客戶只要做選型，而大項目不僅要選型和定製，還有更多技術以外的東西要考量。

首先同樣說價格問題，大型客戶比中小客戶更難辦，小客戶是嫌價格貴，大客戶卻怕低價砸場。雲存儲服務不能違背商業服務的本質，甲方沒蠢到敢讓乙方賠錢做服務，但採購決策層更喜歡看誰的報價最低。數十PB的數據上雲後基本下不來，平台方無論是提價還是降速，有的是追加預算的手段；如果對方真是賠本賣吆喝，成功了就會甩開這個包袱，失敗了就直接倒閉。我談PB級存儲項目時，我很願意分享不同底層技術帶來的實際成本構成，為什麼同樣的價格我們還能掙錢而友商已經在貼錢，相關內容會在第四章節詳細說明。

成功案例是很重要的決策依據，但這個依據很難考證真實性。廠商做過PB級項目但其實是一小群TB項目做的計費融合，廠商確實做過數百P的項目卻和標準對象存儲功能不通用，這類事情太多了，對象存儲合同上不會有總容量，發票存根也只是簡單的信息服務費。客戶的成功案例必須是單一命名空間容量達到PB級別，並簡要說明文件數量和主要讀寫場景。考察案例真實性的方法主要靠聽對方能否自圓其說，甚至讓多個廠商當面質疑，能邏輯自治的廠商終歸還是靠譜一些。

大客戶對雲端數據的處理的要求比中小客戶更簡單，因為複雜業務功能可以自己做，還可以要求廠商為自己做定製開發。

大客戶的數據一般都是存在於舊系統的，其遷移方案比小客戶複雜，拉專線、寄設備、追增量、切業務等等方面都要考慮到。一般遷移方案是現有數百T數據，規劃未來3年到10PB，數十個輕量應用對接代理網關繼續使用，幾個核心高負載應用改成直接訪問存儲。為了更好的發揮對象存儲優勢，廠商還要誘導客戶使用雲平台的各種新功能。遷移方案要靠譜必須說清楚所依賴環境、操作時間規劃、各步風險評估、驗證驗收標準等信息。

大客戶同樣在於雲平台的職業操守，但其反擊能力要強於中小客戶，因為他們不會用雲平台的標準合同，而是自己訂製合同內容。法律合同上能震懾平台的一部分小動作，但計費統計數據云平台還是會拿到，客戶可以考慮多分幾個供應商多做幾個存儲池。

3.4 何時選擇私有雲

對象存儲一般是公有雲服務，但是超大型國企、電信運營商、國家級項目、大型獨立互聯網企業、金融行業、智慧城市、基因、氣象、醫療等行業都因特定原因使用私有雲存儲。

對象存儲適用於私有雲主要基於這三方面考慮：

• 建設成本。

公有雲建設成本有三大頭，伺服器、IDC和公網帶寬。公有雲對比對中小型客戶在這三方面成本有巨大優勢，但也給自己保留了利潤空間。很多客戶能拿到比雲廠商更低價格的資源，那可以拿掉給雲平台留的利潤，自建私有雲存儲。

• 網路通信成本。

這裡提的網路通訊成本和前文的公網帶寬並不重複，公網帶寬是面向分散的廣域網客戶的，網路通訊成本是強調幾個固定的大帶寬消耗對象。假設你某個應用的數據讀寫速度是10Gb/s，雲存儲和客戶端兩側的廣域網帶寬成本是巨大的，某些弱勢運營商甚至要考慮網間結算費用。大讀寫速率的客戶端和雲存儲會是固定長期合作關係，無論是內網互聯、同IDC光纖、同城專線的成本都比互聯網通訊的成本低很多。

• 數據安全等合規需求。

有些客戶連計費日誌都不想讓公有雲看到，或者確實有強安全性法規限制，或者只讓採購資產不認可採購服務，那也會採用私有雲的建設方式。如果本地數據做雲端的容災備份，或者多雲廠商之間的權威數據源，這也是可行的方案。

私有雲的輸出形式有三類，分別是遠程代維護、買軟體和軟硬一體化。買軟體和軟硬一體化交付大家很熟悉，廠商需要提供非常詳實的交付文檔，應對一切異常情況。但當前雲存儲軟體的可維護性並不高，交付文檔可能寫不出來，遠程代維護才是最便利的交付方式。按過去買硬體的習慣，離線運維繫統都要巡檢和計劃內停機，其可用性比在線運維要低很多。廠商的駐場工程師只能做日常響應工作，讓核心技術人員遠程代維好過停業務等人來現場。現在幾個硬體存儲廠商也用類似的遠程維護方案，他們的智能診斷程序會將群集狀態信息自動發送給廠商，這泄密的風險和遠程代維護是相同的。

4.自建/評估對象存儲群集

免泄密聲明：此文是我基於已知公開常識寫的內容，我的工作經歷是讓我驗證這些觀點並感覺到了客戶痛點，此文只談架構不談具體實現方法，並不涉及技術機密。

本章節都是架構技術乾貨，無論是要自建對象存儲群集、採購私有雲還是採購PB級公有雲都需要評估廠商的技術架構是否可靠，如果您做其他分散式系統也可能會有所收穫。

4.1 群集總覽

計算機只是一個應用技術，最近幾十年少有顛覆性技術革新，我們做的是架構選型和調優，通過放棄某些功能來獲得更高更可靠的性能，而非設計一個新模式。為了實現高性能高容量的對象存儲，只有將其在HTTP訪問場景下做深度優化定製，讓底層組件的功能簡單甚至笨拙，才能實現足夠的性能和穩定性。

首先讓大家驚訝一下，我喜歡的對象存儲每個節點看起來都有點土。

• 大部分伺服器拆了硬碟後價格低於兩萬元，沒有任何吞金怪獸級硬體。

• 分散式系統網路IO最珍貴，但為省錢我更願意用幾根千兆線做Bond。

• 只做入門常識級系統優化，沒用專用文件系統也沒寫裸設備，據說每個節點有50%的性能優化餘地。

• 整體結構可以簡化到不需要畫架構圖的地步，群集有幾十個功能項，你想合併成幾個服務也行，想分成幾十個進程也對。

• 因為有超高的容錯性，所以群集自協商機制比較簡單，嗯，應該說是簡陋。

我們不買高配伺服器，因為我們的技術是做公有雲過來的，公有雲定價不看成本只看友商的價格，合理花錢才能生存下去持續服務；我們不做單點極限性能優化，那是招不到架構師才走的歪路。這是最有性價比最務實的架構方案，我們練得是一招致命的殺敵功夫，不是翩若驚鴻的表演性武術。

一個基於http對象存儲的架構場景有三個主要角色：讀寫代理、元數據、存儲服務。

• 讀寫代理，客戶端直接訪問的Web server，它不存數據只是代理。

• 元數據，客戶可見的Metadata信息和不可見的Filehandle等信息都在這裡。

• 存儲服務，實際數據落盤在這些伺服器上，有不同的存儲形式。

此外還有些輔助角色，簡單列一下但不細聊了。

• 客戶端SDK，簡化客戶訪問，還能做一些容錯遮蔽。

• 群集狀態同步服務，99%類似Zookeeper。

• 鑒權認證系統

• 計費系統以及附屬的計費日誌搜集系統。

• 運維監控系統和資產管理系統。

• 核心組件設計

• 堅持有中心設計

很多分散式系統都宣稱無中心設計，說有中心架構里到處是性能瓶頸和高可用單點。但我堅持有中心設計，有中心設計非常容易做文件管理和統計，群集的修復和擴容範圍可控，支持異構存儲。而所謂的性能瓶頸和高可用單點，在Http對象存儲場景下都有成熟的解決方案。

為了讓下文的系統設計更有目標性，我們先預設一個通用訪問場景：

當前10PB的存儲群集已有200億個500k的文件，群集並髮帶寬20G，並發鏈接（含等待鏈接）5萬個，客戶每秒寫入5000個文件，讀取5000個文件，查詢2萬個文件的fileinfo，有5個客戶在做五千萬文件的list操作。

4.2.2 給元數據減負

元數據服務是個資料庫，存儲每個文件的key值、所屬bucket、metadata、filehandle以及一些特殊標識。客戶每次讀訪問、寫訪問、列表統計都會訪問元數據服務，我們要充分考慮其性能和高可用問題。

首先元數據服務選型，因為各條用戶數據的關聯不大，沒有任何全局排序對比算平均數的需求，推薦用文檔型或列族型NoSql，但繼續用關係型資料庫少做些索引也沒問題。

文檔型Nosql一般是三個節點自協商誰是主從，且客戶端會旁觀整個選舉過程，關係型資料庫也有成熟的高可用方案，現在元數據的高可用問題算解決一多半了，讀寫代理來解決另一小辦高可用問題。

我們看看元數據的訪問需求究竟有多大？上文場景說的是每秒對資料庫做5000個讀和寫操作，再加上2萬個獲取fileinfo的操作，用戶猛然一看這頻率很低啊！但每個文件500KByte大，5000個文件就等於20Gbit帶寬了，有多少應用群集能是超過20Gbit帶寬接入的？

在寫庫的時候，假設群集每秒接5000個創建文件的請求，在資料庫看來就是在表尾做5000條數據的appended操作；單台Mongodb只要做一些常識性優化，配塊SSD盤輕鬆達到1萬QPS，案例中的5000個寫請求對資料庫沒任何壓力。

用戶要讀取單條Metadata數據的時候也只有文件名一個篩選條件，沒有任何複雜的排序對比操作，這代表數據可以輕易分庫分表，25000個讀請求分到4個實例還有壓力嗎？

任何資料庫都討厭list操作，但存儲計費和用戶需求都會掃表。結合對象存儲的list需求，我們可以做幾個只讀的從庫就可以查詢99.9%的准實時數據，如果你怕從庫數據同步慢還可以單獨做個最熱數據表，在最熱表上合併一下0.1%的新數據。當我們貼合場景去想，平台計費list操作不要求實時高精確數據啊，我給1000個文件晚計費1分鐘很重要嗎？一個客戶要下載自己2000萬條fileinfo信息，按5條信息1k算，這2000萬條 fileinfo信息有4GB大，就算雲存儲能精確的0.1秒查完，客戶有能力0.1秒下載完這些信息嗎？

如果你覺得元數據服務壓力還是大，那還可以讓計費系統、讀寫代理都對查詢結果做緩存，或者將資料庫掛在成熟的Proxy背後做分庫和調度。

我們的資料庫能低壓力運行，就是設計時充分理解適應了對象存儲元數據這一簡單需求。

4.2.3 靈活的讀寫代理

讀寫代理是整個群集保持松耦合高性能的關鍵點，這也離不開對場景的深度理解。

首先說讀寫代理的高可用、負載均衡和高性能，我們會在讀寫代理前面加幾台Nginx，客戶端到讀寫代理都是無狀態連接。客戶端可以通過LVS、單域名DNS輪詢、多域名分散業務等方式將請求分散到多台Nginx，Nginx將請求交給任意讀寫代理都是能得到相同結果的。單個讀寫代理服務崩潰了SDK端會後台重試，直接訪問API的用戶會以為是自己網慢重新刷新。這麼靈活的訪問方式，有性能問題多堆幾台機器就好了，20G帶寬5萬個鏈接很容易消化。

讀寫代理在訪問客戶時代表存儲服務端，在群集內部扮演的可信客戶端。一個分散式系統中，客戶端是可控可信，可以知曉群集內其他服務狀態，則群集設計會非常簡單，可以做到所有組件都自動協商、自宣告狀態、有序引導流量以及異常錯誤重試。

讀寫代理要訪問元數據時可以看到主從庫的選舉結果，還可以從狀態服務獲取存儲群集的自宣告信息。它不會訪問已經宕機的資料庫，也不會往已滿的存儲內寫入數據。自宣告的狀態信息總有意外時效的情況，這沒關係，區域網內重試速度很快的，客戶感覺只是多了幾毫秒延遲。

讀寫代理還可以將一些讀寫策略、緩存策略寫入自身配置屬性，比如100k以下文件寫到SSD存儲池，優先寫入新擴容存儲伺服器，某Bucket文件自動做異地複製，某後綴名的文件不緩存，某賬戶有特殊API語法等等。

綜上所述，讀寫代理是元數據和存儲系統的可控可信可減負的好朋友好客戶。

4.2.4 存儲的硬功夫

存儲在元數據和讀寫代理的保護和調度下過濾了外部訪問壓力，每個節點都只關心存儲本職工作就好。

對象存儲群集內部存儲可以分為四種，可四種混用也可只用一兩個。

• 三副本存儲，讀寫代理將數據寫入到member1，member1一邊落盤一邊將數據通過網卡複製給member2，member2將數據傳遞給member3。這種存儲實現原理簡單，單鏈接速度上限就是單盤順序讀寫速度，磁碟再慢也比網路塊，插上十幾塊盤就能跑滿本機網卡。這類存儲大多作為糾刪碼大存儲池的持久化寫緩衝組件，單獨使用三副本消耗太多硬碟了，即使不在意硬碟的價格，硬碟越多機器就越多組網就越麻煩。

• 資料庫型存儲，讀寫代理將數據文件處理成N多kb級碎片，然後塞入資料庫中做持久化寫緩衝組件，後端有消費者服務將數據取出另存到糾刪碼大存儲池。我實踐中不太推薦這種方式，因為對三副本存儲沒太大優勢。

• 糾刪碼存儲是老技術了，大家買的超強糾錯的VCD碟片就用的本地糾刪碼技術。我們可以簡單把糾刪碼技術類比成網路版Raid5，這種技術大大的節省磁碟，而且可以設置多塊校驗盤來提高數據安全性，是PB級存儲的主力存儲池。但它的缺點也很明顯，因為數據要做聚合條帶後重新編碼，寫入速度較慢；Raid5磁碟修復時IO放大問題在EC里同樣嚴重；而且糾刪碼回收已刪除文件的空間難度很大速度很慢。

• SSD小文件存儲，這其實是標準三副本存儲的SSD版本，一般用來存儲小文件，SSD盤再貴也比緩存服務的內存便宜。小文件存儲的數據總量不大，一般在本盤存儲即可，不用導入糾刪碼存儲中。

上述存儲手段只是落盤手段，作為存儲組件還要通盤考慮下列問題。

• 磁碟故障時的修復性能。

商用磁碟都是按照36-60個月的使用周期設計的，假設你有6000塊磁碟每個月要壞100塊盤，天天壞盤天天修盤已經成為常態。廠商要保證損壞磁碟快速修復，避免修復周期內另外幾塊冗餘盤一併損壞，又要保證磁碟修復時群集性能受不了太大影響。

當前大家都採購4T8T硬碟，按照磁碟順序寫入300M的速率，填滿一個磁碟的數據需要10個小時以上，最通用的處理方案是將一塊4T盤分為40個小PG，40個PG逃逸到40塊新盤上速度就在30分鐘以內,而且沒消耗新磁碟太多IO。磁碟修復時的IO放大有解決方案但很複雜且涉密，本文不提及。我只透露前文不讓做單節點性能壓榨就是防著這類異常情況，http下載場景中引入緩存可以減少重複讀取的壓力。

• 群集動態擴容能力。

很少有項目是上線就建設50PB的容量，並在半個月內全部數據就位。對象存儲群集剛建成只有幾十個機櫃幾千兆帶寬，後續群集容量和性能都要動態擴容。存儲系統擴容後不要做無意義的數據重新分布，因為數據重新分布可以理解成磁碟修復，太容易出性能類故障了。我們不做數據再平衡，但磁碟寫入時要有優先順序，否則群集內各存儲節點會受力不均而出現新的瓶頸，比如當前有四組存儲，第一組用量90%，第二組50%，第三組10%，第四組剛新增用量0%。我們在讀寫代理那一層可以做策略控制，第一組存儲不再寫入數據，第二組存儲低優先順序寫入數據，第三第四組存儲主力寫入數據。

• 如何提升讀寫性能。

對象存儲場景里很少出現一個鏈接讀寫100G文件的情況，而常見的是幾萬個鏈接去競爭帶寬資源，大家都慢慢讀寫。只要有100個並發連接，群集的訪問壓力會分布均勻。一個PB級存儲系統，存儲機怎麼也有20台以上，每台主機提供1000Mb帶寬用於對外服務，這就是20Gb總出口帶寬了，群集默認性能就不會太差。數據都是順序寫入硬碟，SATA盤也能達到極高寫入性能。讀取數據的性能也不是大問題，互聯網類型數據的緩存命中功率極高，一台緩存可以減負一大堆元數據和存儲服務；大數據一下要讀幾百T的數據必然是多鏈接，每個存儲節點都會分到數據讀取任務的，而且應用要讀這麼多數據不會要秒級完成任務，五分鐘內完成下載就是閃電速度了。

• 回收空間的性能

前文提到數據都是順序寫硬碟，這樣文件刪除時回收空間很慢，但4T盤浪費50%的空間也比買15K盤或者SSD合算，某些小規模或超有錢雲存儲都沒做回收空間這個功能。

當文件有計劃內滾動刪除需求需求，比如說互聯網安防監控，一般是用兩副本或單副本群集扛性能，為回收空間要浪費50%空間，也有公司在開發快刪專用的環形存儲結構。如果數據進了糾刪碼才被刪掉，比如說走了個PB級相冊客戶，那浪費磁碟空間的損失可能要持續半年以上。

• 數據去重問題

對象存儲不做數據去重功能，看著簡單的功能背後都有蛛網一樣的複雜考量，元數據服務、計費服務、存儲服務、增數據邏輯、刪數據邏輯、回收空間邏輯、用戶資源隔離邏輯都會因為這個很炫的功能被徹底改變。真正要去重的文件就是那些電影，隨著版權保護的加深，電影只存原片盜版減少會是趨勢，其他文件即使做切片去重，命中率也非常低。我們提供hash值讓客戶判斷該不該刪文件，該不該做文件映射就夠了。

• 長周期軟硬體換代

對象存儲是付費企業級服務，並不是終身免費但匆匆關張的個人網盤。我們必須考慮十年為刻度的長周期維護問題，某種硬體停產了怎麼辦，假設系統內核停止維護怎麼辦？我強烈反對極端優化單點性能，就是因為單點性能極限優化必然和硬體、內核、文件系統都有深度關聯。我推薦存儲主力服務是應用層服務用戶態進程，老中青三代伺服器和諧運行，群集性能瓶頸本來就不在單點，不要給自己的軟體無故設限。

• 冷存儲問題

冷存儲分真冷和低溫兩種類型，真冷存儲就是用磁帶、藍光碟、可離線存儲節點來存儲數據，這樣可以節省機櫃電量，但這是個工程學問題不是計算機問題了。低溫存儲就是標準存儲換更大更慢更省電的磁碟，通過硬體選型來降低硬體和機櫃成本。

4.3 存儲測試標準

前文我大量篇幅介紹對象存儲和傳統存儲的不同，如果搭建一個私有對象存儲群集，我們該做的測試也要貼合場景。

存儲系統交付時，我會推薦做如下測試：

• 用戶側標準功能測試，如文件讀、寫、刪除、獲取metadata信息。

• 單鏈接讀寫速率測試。

• 一萬並發連接讀寫速率測試。

• 群集長周期並發寫入測試，既要擊穿寫緩衝池，又為其他測試積累數據。

• 群集長周期隨機讀取測試，注意是隨機讀取避免命中緩存。

• 隨機關一台存儲伺服器，觀測群集讀寫性能是否受影響，觀察群集修復速率。

• 通過讀取文件Metadata信息對元數據服務進行讀取和並發性能壓測。

• 隨機關閉各角色伺服器各一台，看群集功能和性能是否受影響。

• 同名文件大範圍替換測試，觀察文件頻繁修改後是否會性能降低。

• 根據廠商承諾的空間回收策略做空間回收測試。

某些廠商沒話題可聊就強調自己的IO和IOPS非常高，這就非常不專業了，HTTP介面的存儲要談性能也該談並發連接和總帶寬。

4.4 運營成本問題

當你要建設一個存儲群集時，沒有存儲技術可以去買，但建完賠錢就不行了。評估TCO成本是要上公有雲還是私有雲，用哪家公司方案最合理的主要依據。

我們不能像買個存儲櫃一樣簡單算TCO成本，對象存儲群集的成本有五大塊：

• 硬體採購成本，一般佔總成本的20-30%。

伺服器和硬碟是一次性投入，按照五年報廢周期折算。

• 機櫃電力成本，一般佔總成本的20-30%。

存儲節點經常插幾十塊磁碟，都是高功耗的電老虎，五年機櫃成本不比硬體低。

• 帶寬接入成本，一般佔總成本的是5-50%。

根據這個存儲的業務類型可以確定帶寬接入成本，最低可能只是個維護帶寬加幾光纖，最高可能是運營商的大客戶。

• 資源閑置成本，一般佔總成本的5-50%。

私有群集要計算多久才能填滿空間，公有群集要為潛在需求預留足夠資源。

• 人力/軟體成本，一般佔總成本的20-30%。

開發一套對象存儲然後公有雲磨練幾年，這需要投入億元以上，分攤到一個項目也有數百萬投入。廠商的人力成本很多是用在壓縮硬體、機櫃、帶寬、閑置成本上，節省了人力成本其他開銷就會增大。

在千萬級別項目投入里，金融成本也是很大的成本。建設一個存儲群集的總成本會和買一套硬體存儲櫃的價格差不多，報價不便宜但考慮金融成本就很合算了。假設客戶買一套硬體存儲櫃是一次性掏5000萬；而對象存儲群集硬體佔比不高，機櫃、帶寬人力等成本都是按月繳納五年才湊到5000萬的。

拿著上述數據我們已經可以預估出新建一個存儲群集的實際成本，我們拿這些錢和公有雲價格進行對比，如果私有雲成本比公有雲高太多，我們也能說服採購決策層繼續用公有雲。

在群集運營過程中規模會受到IDC環境的限制，機櫃和帶寬不是想買就有的。電力也好機櫃也好，IDC都是賣不出去資源就願意接大客戶，哪怕零利潤總好過閑置；但如果資源都賣給一個大客戶了，這個IDC也就沒資源接其他客戶了。我很少考慮100PB以上的存儲問題，也有這方面考慮。有些工程師吹牛皮說做過EB級存儲，讓他基於常識說一下自己的硬體投了多少。

結束語

上文為我對PB級對象存儲知道的一切常識，PB級存儲需求離你我業務越來越近，大家早做準備各自努力吧。