歡迎光臨
每天分享高質量文章

EMC潘國林: 大話儲存系列之月光寶盒(塊儲存)

作者簡介

潘國林, 高級軟體工程師。目前就職於DELL EMC,儲存設備研發,檔案系統相關。
早期在諾基亞上海貝爾從事通信板卡研發,主要涉及驅動,內核,通信以及平臺服務等領域。
娛樂愛好:看喜劇小品,聽相聲。

上接EMC潘國林: 大話儲存系列之磁盤娶親(RAID)


塊儲存設備

互聯網越來越發達,網速越來越快(管制也越來越嚴),很多事情都可以通過聯網解決。很多儲存行業商家也get到了這個點。下圖是個極簡的模型,商家儲存設備(黑盒子),用戶一個筆記本電腦,通過TCP/IP承載的iSCSI協議,對於Linux用戶,可以看到一個塊設備/dev/sdax,就像使用本地硬碟(如/dev/sda)一樣,可以對其進行分割槽,格式化為檔案系統,亦或直接裸設備讀寫。

圖9 塊儲存設備

對於用戶,這就夠了,著實方便,付錢就行。

對於一個有追求的碼農,我們是有必要看看這個黑盒子裡面是什麼。下圖是黑盒子裡面的東西,再次強調,包括本文之前或之後的插圖及描述,都是十分宏觀的。篇幅有限不能說的太細,符合本文主旨;另外,說的太細就會和具體商家產品很像,咱不能那麼乾。

拋開硬體、驅動、OS等,直接看軟體邏輯,首先將系統上的硬碟組成多個RAID,如何組,組成哪種RAID,哪幾塊盤組成RAID等等,這些都是可以通過管理員配置。有人問了(對,還是前面問問題的那個人):“就一個RAID行不行?”

可以,但是有風險,如果一個盤出現故障,RAID就暫時不能提供服務了,整個系統所有用戶會受到影響。如果組成多個RAID,那麼,僅僅有故障盤的RAID暫時無法服務,其它RAID是可以繼續工作,不至於影響所有用戶。套用某相聲表演藝人的話說,用戶就是衣食父母。

繼續看圖,軟體對下要管理RAID,對上要為用戶提供服務,它給用戶提供的是LUN(全稱是Logical Unit Number,也就是邏輯單元號),當然啦,用戶(人)不必去理解什麼是LUN,就如上面所說,頂多是一個/dev/sdax,LUN是軟體、協議層面的東西。怎麼理解呢?每個LUN關聯了一組物理儲存資源,你擁有了這個LUN,就擁有了這組物理儲存資源,凡是使用物理儲存資源,需要提供你的LUN ID。有過編程經驗的人很容易理解,十分類似一個檔案或socket句柄。客戶端(這裡不使用用戶這個詞,這裡偏只程式)對LUN的讀寫,至少需要提供”LUN ID+R/W+Offset+Length[+data]”這些信息。

為什麼需要LUN,而不是把RAID直接“丟給”用戶?

圖10 塊儲存設備內部

因為每個用戶的需求是不一樣。

碼農李二狗,全部身家800G代碼,做開發的時候谷歌一下然後複製粘貼來的。某宅男,擁有海量高清大片,4TB+不在話下。按照圖10,我們可以給李二狗分配LUN 1,給某宅男分配LUN 2。軟體邏輯層負責做映射,事實上,一個LUN可以映射到多個RAID,多個LUN也可以映射到一個RAID上(不常用,因為RAID故障影響多個用戶),用戶資料都會準確的儲存到屬於該LUN的物理儲存資源中,不會出現張冠李戴的情況。當用戶需求改變的時候,如李二狗也開始收集高清大片了,需要的空間就大了,那麼可以將LUN1資源進行擴充,十分靈活。最後,LUN的大小和該LUN所映射的物理儲存資源大小以及用戶查看/dev/sdax的大小是一致的。

 

帶檔案系統的儲存設備

其實在大多數場景,用戶都是將設備格式化成某個檔案系統使用。那麼設備廠商就對用戶說:“我有一個辦法,你們可以不用自己格式化,我直接提供一個檔案系統,直接mount就行了,NFS,簡單吧。”

“好啊!好啊!”

“不過,得加錢。”

“……”

商業上的事我們先不管,看下圖。用戶交好錢,被告知一個地址,直接mount到本地,確實方便。

圖11 帶檔案系統的儲存設備


這回,黑盒子裡面又是什麼東西呢?

圖12 帶檔案系統的儲存設備

看圖之後,是不是和我一樣的感覺?MMP姦商。 就多了一個檔案系統層,內部格式化LUN,然後就多收了不少錢。

如果你以為只有這些就錯了!

我們假設,你付費買了1TB的空間,服務商是沒有真的給你預留1TB物理儲存資源的,當你用的時候,再去申請物理儲存資源。你很憤憤,就存滿1TB,此時你以為真的消耗服務商1TB物理儲存資源了?不見得!有可能只消耗了0.8TB甚至更少。

拋開商業成見,但從技術角度來看,這裡有兩個技術需要提到壓縮 和 去重,這在檔案系統層面很容易做到。

壓縮(Compress)

您可能知道,檔案系統在進行IO時候是以一定大小資料塊(block)為單位進行的,以4KB為例。壓縮也是以這個資料塊為單位,在寫入磁盤之前進行壓縮,原本4KB的資料,壓縮之後可能就變成2KB,多個壓縮之後的資料塊再次拼成4KB,然後儲存到物理磁盤。這個操作,節省了物理資源。用戶讀資料的時候,如果是壓縮的,需要首先解壓縮,然後傳回給用戶。壓縮、解壓縮操作是純演算法的,主要消耗CPU資源,因此在系統負載很高的時候,不建議啟用壓縮機制。另外,資料是否壓縮,需要額外的元資料(metadata)記錄,這增加了系統複雜度。有的設備會將壓縮、解壓縮操作交給硬體去完成,減少CPU的消耗。

 

去重(Deduplicate)

上傳一個大的高清影片到網盤,秒傳,遇到過吧?這說明服務商儲存系統存在了一個和你一模一樣的檔案,你遇到了一個志同道合的宅友。為了節省空間,系統就僅僅給你做個標記(或類似一個軟鏈接),然後增加檔案的取用計數,免得別人刪除了影響到你。這個還是從檔案層面的去重,也十分容易理解。我們做個極端假設,如果兩個1G大小的檔案,僅僅有一個位元組不同,按照上面方式是不能做到去重的,還是得上傳。檔案的一部分一樣就不能進行去重了嗎?

答案是有。資料塊(block)級別的去重。

圖13 資料塊級別去重


我們看圖13說話。最初,硬碟神馬都沒有,檔案1資料全部寫入硬碟,這沒什麼好說的。然後,檔案2,其中BEF三個塊,硬碟已經存在,不必寫入了,剩下的塊需要寫入。最後再看檔案3,前面3個塊,XYZ不存在於硬碟中,需要寫。後面的XY就不必寫了,最後的E也是不必寫。

去重技術確實節約物理儲存資源,但也存在一些問題。

比如:如何確定當前要寫的塊硬碟中已經存在?

 

不可能去硬碟中逐一比較!

一個做法是將早期寫入的塊進行HASH計算,將HASH值以及塊信息儲存到記憶體中,作為Cache,新預寫的塊計算HASH值,如果HASH值在Cache中存在,則取出Cache中塊信息,做去重操作,記錄信息。記憶體有限,Cache不能足夠大到儲存所有硬碟中的塊信息,因此去重是有限度的,另外Cache的更新也是一個技術要點,何種Cache更新演算法能夠得到好的去重效率是一個值得深入研究的話題。

 

好了,以上簡要介紹了兩種儲存設備。接下來……

有人問了(對,依舊是前面問問題的那個人):

“我替碼農李二狗他父親王老爺子問個問題,是軟體就有BUG,如果你這軟體崩潰了,是不是所有用戶都不能正常訪問了?”

“沒錯!”

“弱爆了吧?”

在前面RAID的描述中,可以體會到一個詞“冗餘”,冗餘起到保險、保護作用。既然說軟體存在缺陷,可能掛,那麼就放兩份在那,兩個物理獨立的設備運行同樣的軟體,互為主備。主用設備工作時備用設備待命,主備共享系統中RAID、LUN等配置及狀態,主用設備掛了,備用設備上。用戶無感知。這類方案在很多領域(如通信設備)也是常見的。

圖14 主備備份


“看起來有用,你這主備設備都放在哪裡?”

“服務商機房或資料中心。”

“如果資料中心著火了或其它情況,這些設備就不能提供服務了吧?”

“沒錯!”

“弱爆了吧?”

資料中心可是個有網、有電、有空調,有外賣宅男嚮往的好地方,是具備基本的防火、防盜(防師兄?)等防災害的地方,但凡事預則立不預則廢,萬一齣現差錯可就是大事了。

其實資料中心也有“備份”。一般在同城的其它地方,也會有一個資料中心,用於備份當前資料中心的資料,同城較近拉光纖,備份效率杠杠的,甚至是實時備份。

圖15 資料中心

“如果城市發生較大地震,兩個資料中心都損毀了,資料就丟了吧?”

“沒錯!”

“弱爆了吧?”

兩地三中心。即生產資料中心、同城災備中心、異地災備中心建設方案。兩個城市的三個資料中心互聯,如果一個資料中心發生故障或災難,其他資料中心可以正常運行並對核心業務或全部業務實現接管。

圖16 兩地三中心

“那如果兩個城市都……”

“你稍等,我打個電話。”

喂,代罵公司嗎?這是我的個人資產證明,幫我罵個人,罵道我破產。

……

天下無不散宴席。本次分享就到此結束了,還是那句話,能力有限水平一般,蜻蜓點水的啰嗦了這些,萬一有那麼一句半句勾起了您的興趣,我就十分欣慰。

註:我們尊重對知識刨根問底的精神,以上代罵公司有關說辭純屬扯淡。

  

尾聲

“你可嚇壞我了,在看Linuxer公眾號的文章呢,向大牛們學習學習,我一直覺得技術沒啥長進,內心挺虛的。”

“看你體格應該不只是心虛吧?確實,這些文章質量都很高,值得學習,除了那篇《大話儲存》有點打醬油。在說,學習沒必要偷偷摸摸的吧?”

“習慣了,沒辦法,看感興趣的東西就這樣。”

“我只能呵呵了。我關註的主播要上線了,先走了,這個移動硬碟放這借你用用。”

“裡面是什麼?”

“當然也是你感興趣的東西——你懂的”。

赞(0)

分享創造快樂