UCloud優(yōu)刻得歸檔存儲技術(shù)安全、快速、低成本

云計算憑借其強大的分布式計算能力,可伸縮的特性以及低成本高可靠性的優(yōu)勢, 在海量數(shù)據(jù)處理方面占據(jù)優(yōu)勢地位。但是日常所產(chǎn)生的數(shù)據(jù)并非都是需要隨時存取的,事實上,我們依賴于云服務(wù)進行存儲的數(shù)據(jù),大多數(shù)都不是需要頻繁訪問的熱點數(shù)據(jù),大量的數(shù)據(jù)被存儲后訪問頻率很低(例如數(shù)據(jù)歸檔, 長期備份等場景,平均一年訪問一次甚至更低),這時候我們可以將這些不再經(jīng)常使用的“冷數(shù)據(jù)”轉(zhuǎn)移到一種成本更低的存儲設(shè)備來進行長期保存,我們稱這種存儲為歸檔存儲。歸檔存儲安全、持久且成本極低,為了保持成本低廉,數(shù)據(jù)取回時間可能需要花費數(shù)小時。

在數(shù)據(jù)歸檔領(lǐng)域,傳統(tǒng)的磁帶庫或是藍光盤庫介質(zhì)在過往一直是首選,這些磁帶或者光盤一旦存儲了數(shù)據(jù),就意味著數(shù)據(jù)進入到數(shù)據(jù)中心某個不起眼的角落中,如無必要的話,這些數(shù)據(jù)將通常會進入到“沉睡”階段,有些數(shù)據(jù)甚至幾十年都不再被讀取使用。 如今數(shù)字經(jīng)濟的背景下,冷數(shù)據(jù)的價值挖掘受到了越來越多的關(guān)注,靈活的數(shù)據(jù)檢索,準(zhǔn)實時的數(shù)據(jù)取回能力,也成為了新時代數(shù)據(jù)歸檔場景的核心需求。

UCloud優(yōu)刻得的歸檔存儲為對象存儲US3提供了一套極低價格的數(shù)據(jù)存儲系統(tǒng),該系統(tǒng)具備存儲速度快、可靠性高、數(shù)據(jù)取回靈活等特性,以下是該系統(tǒng)的介紹。

硬件架構(gòu)

UCloud優(yōu)刻得的存儲硬件架構(gòu)是采用兩個機頭連接多個JBOD的方式來組織的,一個機架里有多個JBOD和兩個機頭,每個JBOD都分別連接到兩個機頭的HBA卡上,每個JBOD容納了一百塊以上的硬盤,JBOD是存儲領(lǐng)域中一類重要的存儲設(shè)備,英文Just a Bunch Of Disks,意為磁盤簇,磁盤連續(xù)捆束陣列,是在一個底板上安裝的帶有多個磁盤驅(qū)動器的存儲設(shè)備。不同于RAID陣列,JBOD沒有用來管理磁盤上數(shù)據(jù)分布的前端邏輯,每個磁盤進行單獨尋址,可以作為分開的存儲資源,用戶可以像訪問普通硬盤一樣,訪問JBOD中的任意一塊硬盤。JBOD在近幾年被一些廠家提出,并逐漸被廣泛采用。

硬盤的選擇上我們首選HM-SMR(Host-Managed-SMR)盤,當(dāng)然也兼容普通的CMR盤,SMR盤的優(yōu)點是成本低廉,但是不支持隨機讀寫,上面的數(shù)據(jù)按固定的大小(通常是256MB)被分為一個個的Zone,只有1%的CMR Zone是支持隨機寫的,剩余99%的SMR Zone都是只支持順序?qū)懙模瑪?shù)據(jù)的擦除也是以Zone為單位的,這種盤的缺點是不適用于頻繁更改性寫入,但用來存儲大容量,修改少的數(shù)據(jù)卻十分合適,且成本低于普通HDD盤,適合作為UCloud優(yōu)刻得歸檔存儲的存儲介質(zhì)。

兩個機頭用于管理連接在上面的JBOD和硬盤,裝有操作系統(tǒng),它們之間是主從關(guān)系,主機頭負(fù)責(zé)接收IO請求,主機頭故障后,從機頭接替成為主。

存儲的成本其中還有非常顯著的一部分是電力的開銷,如果所有硬盤長時間保持全部上電狀態(tài),將帶來比較大的一筆電力開銷,考慮到我們歸檔存儲寫多讀少的特性,且寫入都是追加寫,速度很快,少量的硬盤就可以充分利用網(wǎng)絡(luò)帶寬,所以我們的設(shè)計目標(biāo)是在正常使用的情況下可以做到大部分的硬盤處于下電狀態(tài),只有少部分硬盤處于上電狀態(tài)提供IO,在5年的質(zhì)保期間保證50k的上下電頻率,平均下來是小時級別。為此,UCloud優(yōu)刻得在軟件架構(gòu)上設(shè)計了一套上下電調(diào)度策略,具體后文會有講解。

軟件架構(gòu)

冗余策略

常用的冗余策略有副本和糾刪兩種方式,為了達到節(jié)省成本的目的,UCloud優(yōu)刻得歸檔存儲采用的策略是對數(shù)據(jù)進行糾刪分片,又由于硬件架構(gòu)上的較多硬盤配置,以及異步寫的原因,我們采用了較大的EC比例。

Blob

考慮到前面提到的SMR盤的Zone和糾刪條帶的設(shè)定,我們引入了Blob這一概念, 例如采用大比例的EC糾刪策略, 把綜合考慮Zone和EC比例的數(shù)據(jù)劃分到一個Blob,這樣刪除或壓縮數(shù)據(jù)時可以以Blob為單位來進行。

磁盤組

我們把每個JBOD的磁盤分成了一個個邏輯的磁盤組。一次IO的所有糾刪分片都在一個磁盤組中,一個Blob也只屬于某一個磁盤組,例如23+3的糾刪分片,那么一個磁盤組就包含26塊盤, 且上電,下電也是以磁盤組為最小單位的。當(dāng)上層來了寫IO時,為了避免磁盤組頻繁上下電,會讓一個磁盤組持續(xù)服務(wù)寫操作,當(dāng)該磁盤組寫到一定的量后,按輪詢策略挑選下一個磁盤組進行上電。

元數(shù)據(jù)

我們利用每塊硬盤那1%的支持隨機讀寫的CMR Zone來存儲元數(shù)據(jù)信息,元數(shù)據(jù)信息包含兩部分,Disk Meta和Zone Meta, Disk Meta用于保存整個磁盤的元數(shù)據(jù),包含唯一標(biāo)識這塊盤的Disk ID, 屬于哪個JBOD,有多少個Zone,以及Zone Meta在磁盤中的偏移和長度等。Zone Meta用于保存這塊盤每個Zone的元數(shù)據(jù)信息,包括這個Zone是第幾個,有沒有被使用等。

歸檔服務(wù)啟動時,通過加載Disk Meta和Zone Meta在內(nèi)存中構(gòu)建每個Blob的信息。

上下電調(diào)度策略

為了節(jié)省電力成本,所有磁盤組并不是保持長期上電狀態(tài)的,當(dāng)沒有讀IO時,只有當(dāng)前負(fù)責(zé)寫的磁盤組處于上電狀態(tài),當(dāng)這個磁盤組寫到一定量后,切換到下一個寫磁盤組上電,原來的寫磁盤組安排下電。對于讀IO,分為非緊急讀和緊急讀兩種,如果是非緊急讀,且這個讀IO對應(yīng)的磁盤組處于下電狀態(tài),則為這個磁盤組加一個讀標(biāo)記,每小時輪詢所有磁盤組,將有讀標(biāo)記但處于下電狀態(tài)的磁盤組上電,已處于上電狀態(tài)的磁盤組如果超過一定時間沒有收到IO請求會安排下電,也就是說,對于非緊急讀,最多需要數(shù)個小時的時間來等待磁盤組上電,而對于緊急讀IO來說,如果這次IO對應(yīng)的磁盤組處于下電狀態(tài),則立即安排上電,進行數(shù)據(jù)讀取。

IO流程

上層IO的數(shù)據(jù)通過計算被切割成一個個EC分片(如果數(shù)據(jù)大小沒有按EC條帶對齊需要填0),分別派發(fā)到其對應(yīng)磁盤組的每個磁盤上,如果是非緊急讀IO可能需要等待對應(yīng)的磁盤組上電后進行重試,如果是寫IO,當(dāng)一個Blob寫滿后,也就是磁盤組中每個磁盤的當(dāng)前Zone被寫滿后,會切換到下一個Zone,分配下一個Blob開始寫,寫成功后向上層返回這次IO對應(yīng)的Blob編號和在這個Blob內(nèi)的偏移,用于上層組織文件的元數(shù)據(jù)信息。

數(shù)據(jù)保存

數(shù)據(jù)在磁盤上是以4KB大小的Sector為單位寫下去的,每個IO所攜帶的數(shù)據(jù)經(jīng)過EC計算后落盤時,都會被拆分成一個個Sector, 且在每個Sector的尾部都填充了一塊Sector Meta,用于記錄這個Sector的元數(shù)據(jù)信息,包括這個Sector對應(yīng)了第幾個Zone,以及這個Sector上數(shù)據(jù)的crc等,這樣可以防止硬盤的靜默錯誤。

周期性數(shù)據(jù)檢查

歸檔服務(wù)啟動后會周期性掃描已經(jīng)寫滿的Blob,對這個Blob的每個Sector進行數(shù)據(jù)校驗,這一過程利用了上文提到的每個Sector 尾部的Sector Meta里保存的crc,校驗失敗時會上報錯誤,通知到相關(guān)運維人員進行處理。

總結(jié)

這套歸檔存儲系統(tǒng)在保證了高性能、安全的前提下,大幅地優(yōu)化了成本。非常適用于一些數(shù)據(jù)量大但訪問頻率不高的存儲場景,比如保存一些下載量少的多媒體數(shù)據(jù),大型數(shù)據(jù)庫、日志、用戶資料的備份等等。目前,UCloud優(yōu)刻得歸檔存儲服務(wù)已經(jīng)于2019年上線,且穩(wěn)定運行多年,存儲了PB級別的歸檔數(shù)據(jù),預(yù)計隨著更大圍的應(yīng)用,將會更大幅度地節(jié)省存儲成本。

有對UCloud優(yōu)刻得歸檔存儲感興趣的小伙伴,可以與我們進行更多產(chǎn)品咨詢和交流。

(免責(zé)聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏,概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時,應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明,并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后,將會依法盡快聯(lián)系相關(guān)文章源頭核實,溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 )