知識星球作者簡介
潘國林, 高階軟體工程師。目前就職於DELL EMC，儲存裝置研發，檔案系統相關。
早期在諾基亞上海貝爾從事通訊板卡研發，主要涉及驅動，核心，通訊以及平臺服務等領域。
娛樂愛好：看喜劇小品，聽相聲。
塊儲存裝置
網際網路越來越發達，網速越來越快（管制也越來越嚴），很多事情都可以透過聯網解決。很多儲存行業商家也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公眾號的文章呢，向大牛們學習學習，我一直覺得技術沒啥長進，內心挺虛的。”
“看你體格應該不只是心虛吧？確實，這些文章質量都很高，值得學習，除了那篇《大話儲存》有點打醬油。在說，學習沒必要偷偷摸摸的吧？”
“習慣了，沒辦法，看感興趣的東西就這樣。”
“我只能呵呵了。我關註的主播要上線了，先走了，這個移動硬碟放這借你用用。”
“裡面是什麼?”
“當然也是你感興趣的東西——你懂的”。
