|
應(yīng)用的角度聊過了，我們再看看這三種存儲的一些技術(shù)細節(jié)，首先看看在系統(tǒng)層級的分布。
 我們從底層往上看，最底層就是硬盤，多個硬盤可以做成RAID組，無論是單個硬盤還是RAID組，都可以做成PV，多個PV物理卷捏在一起構(gòu)成VG卷組，這就做成一塊大蛋糕了。接下來，可以從蛋糕上切下很多塊LV邏輯卷，這就到了存儲用戶最熟悉的卷這層。到這一層為止，數(shù)據(jù)一直都是以Block塊的形式存在的，這時候提供出來的服務(wù)就是塊存儲服務(wù)。你可以通過FC協(xié)議或者iSCSI協(xié)議對卷訪問，映射到主機端本地，成為一個裸設(shè)備。在主機端可以直接在上面安裝數(shù)據(jù)庫，也可以格式化成文件系統(tǒng)后交給應(yīng)用程序使用，這時候就是一個標準的SAN存儲設(shè)備的訪問模式，網(wǎng)絡(luò)間傳送的是塊。 如果不急著訪問，也可以在本地做文件系統(tǒng)，之后以NFS/CIFS協(xié)議掛載，映射到本地目錄，直接以文件形式訪問，這就成了NAS訪問的模式，在網(wǎng)絡(luò)間傳送的是文件。
如果不走NAS，在本地文件系統(tǒng)上面部署OSD服務(wù)端，把整個設(shè)備做成一個OSD，這樣的節(jié)點多來幾個，再加上必要的MDS節(jié)點，互聯(lián)網(wǎng)另一端的應(yīng)用程序再通過HTTP協(xié)議直接進行訪問，這就變成了對象存儲的訪問模式。當然對象存儲通常不需要專業(yè)的存儲設(shè)備，前面那些LV/VG/PV層也可以統(tǒng)統(tǒng)不要，直接在硬盤上做本地文件系統(tǒng)，之后再做成OSD，這種才是對象存儲的標準模式，對象存儲的硬件設(shè)備通常就用大盤位的服務(wù)器。
從系統(tǒng)層級上來說，這三種存儲是按照塊->文件->對象逐級向上的。文件一定是基于塊上面去做，不管是遠端還是本地。而對象存儲的底層或者說后端存儲通常是基于一個本地文件系統(tǒng)（XFS/Ext4..）。這樣做是比較合理順暢的架構(gòu)。但是大家想法很多，還有各種特異的產(chǎn)品出現(xiàn)，我們逐個來看看：
對象存儲除了基于文件，可以直接基于塊，但是做這個實現(xiàn)的很少，畢竟你還是得把文件系統(tǒng)的活給干了，自己實現(xiàn)一套元數(shù)據(jù)管理，也挺麻煩的，目前我只看到Nutanix宣稱支持。另外對象存儲還能基于對象存儲，這就有點尷尬了，就是轉(zhuǎn)一下，何必呢？但是這都不算最奇怪的，最奇怪的是把對象存儲放在最底層，那就是這兩年大紅的Ceph。
 Ceph是個開源的分布式存儲，相信類似的架構(gòu)圖大家都見過，我把底層細節(jié)也畫出來，方便分析。
底層是RADOS，這是個標準的對象存儲。以RADOS為基礎(chǔ)，Ceph 能夠提供文件，塊和對象三種存儲服務(wù)。其中通過RBD提供出來的塊存儲是比較有價值的地方，畢竟因為市面上開源的分布式塊存儲少見嘛（以前倒是有個sheepdog，但是現(xiàn)在不當紅了）。當然它也通過CephFS模塊和相應(yīng)的私有Client提供了文件服務(wù)，這也是很多人認為Ceph是個文件系統(tǒng)的原因。另外它自己原生的對象存儲可以通過RadosGW存儲網(wǎng)關(guān)模塊向外提供對象存儲服務(wù)，并且和對象存儲的事實標準Amazon S3以及Swift兼容。所以能看出來這其實是個大一統(tǒng)解決方案，啥都齊全。
上面講的大家或多或少都有所了解，但底層的RADOS的細節(jié)可能會忽略，RADOS也是個標準對象存儲，里面也有MDS的元數(shù)據(jù)管理和OSD的數(shù)據(jù)存儲，而OSD本身是可以基于一個本地文件系統(tǒng)的，比如XFS/EXT4/Brtfs。在早期版本，你在部署Ceph的時候，是不是要給OSD創(chuàng)建數(shù)據(jù)目錄??？這一步其實就已經(jīng)在本地文件系統(tǒng)上做操作了（現(xiàn)在的版本Ceph可以直接使用硬盤）。
現(xiàn)在我們來看數(shù)據(jù)訪問路徑，如果看Ceph的文件接口，自底層向上，經(jīng)過了硬盤（塊）->文件->對象->文件的路徑；如果看RBD的塊存儲服務(wù)，則經(jīng)過了硬盤（塊）->文件->對象->塊，也可能是硬盤（塊）->對象->塊的路徑；再看看對象接口（雖然用的不多），則是經(jīng)過了硬盤（塊）->文件->對象或者硬盤（塊）->對象的路徑。
是不是各種組合差不多齊全了？如果你覺得只有Ceph一個這么玩，再給你介紹另一個狠角色，老牌的開源分布式文件系統(tǒng)GlusterFS最近也宣布要支持對象存儲。它打算使用swift的上層PUT、GET等接口，支持對象存儲。這是文件存儲去兼容對象存儲。對象存儲Swift也沒閑著，有人在研究Swift和hadoop的兼容性，要知道MapReduce標準是用原生的HDFS做存儲的，這相當是對象存儲去兼容文件存儲，看來混搭真是潮流啊。
雖說現(xiàn)在大家都這么隨便結(jié)合，但是這三種存儲本質(zhì)上還是有不同的，我們回到計算機的基礎(chǔ)課程，從數(shù)據(jù)結(jié)構(gòu)來看，這三種存儲有著根本不同。塊存儲的數(shù)據(jù)結(jié)構(gòu)是數(shù)組，而文件存儲是二叉樹（B,B-,B ,B*各種樹），對象存儲基本上都是哈希表。
 數(shù)組和二叉樹都是老生常談，沒有太多值得說的，而對象存儲使用的哈希表也就是常聽說的鍵值（KeyVaule型）存儲的核心數(shù)據(jù)結(jié)構(gòu)，每個對象找一個UID（所謂的“鍵”KEY），算哈希值（所謂的“值Vaule”）以后和目標對應(yīng)。找了一個哈希表例子如下：
鍵值對應(yīng)關(guān)系簡單粗暴，畢竟算個hash值是很快的，這種扁平化組織形式可以做得非常大，避免了二叉樹的深度，對于真.海量的數(shù)據(jù)存儲和大規(guī)模訪問都能給力支持。所以不僅是對象存儲，很多NoSQL的分布式數(shù)據(jù)庫都會使用它，比如Redis，MongoDB，Cassandra 還有Dynamo等等。順便說一句，這類NoSQL的出現(xiàn)有點打破了數(shù)據(jù)庫和文件存儲的天然屏障，原本關(guān)系數(shù)據(jù)庫里面是不會存放太大的數(shù)據(jù)的，但是現(xiàn)在像MongoDB這種NoSQL都支持直接往里扔大個的“文檔”數(shù)據(jù)，所以從應(yīng)用角度上，有時候會把對象存儲，分布式文件系統(tǒng)，分布式數(shù)據(jù)庫放到一個臺面上來比較，這才是混搭。
當然實際上幾個開源對象存儲比如swift和ceph都是用的一致性哈希，進階版，最后變成了一個環(huán)，首首尾相接，避免了節(jié)點故障時大量數(shù)據(jù)遷移的尷尬，這個幾年前寫Swift的時候就提過。這里不再深入細節(jié)。
|
|
|
來自： jxl0716 > 《企業(yè)級存儲》
