當前位置:首頁 » 服務存儲 » 分布式存儲架構
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

分布式存儲架構

發布時間: 2022-02-07 07:31:06

1. 求 分布式對象存儲 原理 架構及Go語言實現 pdf

分布式對象存儲系統的書,代碼是用 GO 實現的,書上當然寫的不全。不知道視頻會全否?但是大體的思路和應該實現的功能都講到了。還是不錯的。至少在思路指導上。還有這種系統業界的標準是亞馬遜的 AWS s3 那麼參考它們的 SDK API 來實現是有必要了。兼容標准嘛。

2. 系統架構 分布式 哪本書比較好

Distributed Computer Systems Engineering——經典和詳細的介紹了分布式系統的技術和工程實現經驗,值得每個做分布式系統的人去看一遍,繼續錘煉和提高自己的眼界和技術。

補充三篇論文:
1. Sinfonia: A New Paradigm for Building Scalable Distributed Systems,這篇論文是SOSP2007的Best Paper,闡述了一種構建分布式文件系統的範式方法,個人感覺非常有用。淘寶在構建TFS、OceanBase和Tair這些系統時都充分參考了這篇論文。
2. The Chubby lock service for loosely-coupled distributed systems,這篇論文詳細介紹了Google的分布式鎖實現機制Chubby。Chubby是一個基於文件實現的分布式鎖,Google的Bigtable、Maprece和Spanner服務都是在這個基礎上構建的,所以Chubby實際上是Google分布式事務的基礎,具有非常高的參考價值。另外,著名的zookeeper就是基於Chubby的開源實現,但是根據在Google工作的朋友講,zookeeper跟Chubby在性能和功能上都還有差距。
3. Spanner: Google's Globally-Distributed Database,這個是第一個全球意義上的分布式資料庫,也是Google的作品。其中介紹了很多一致性方面的設計考慮,為了簡單的邏輯設計,還採用了原子鍾,同樣在分布式系統方面具有很強的借鑒意義。

另外,還有一本書:
剛出的,讀了一下樣章,感覺還不錯,一起推薦給大家——《大規模分布式存儲系統:原理解析與架構實戰》

3. 分布式架構的對比

EMC VMAX
VMAX架構包含1個到8個VMAX引擎(存儲節點)。這些引擎相互連接在一起,被稱為虛擬Matrix架構。每個引擎都可以當作存儲陣列,擁有自己的前端主機埠連接、後端磁碟導向器、高速緩存(內部鏡像化)和處理器。VMAX引擎使用Matrix介面主板封裝器(MIBE)連接在一起。MIBE有副本以備冗餘。虛擬Matrix可以進行引擎之間的記憶體訪問。當主機訪問埠和數據不在同一個引擎上的時候需要虛擬Matrix提供連接性。
3Par InServ
3Par由多個存儲節點組成。這些存儲節點匯集到一個高速連接上。3Par稱之為InSpire架構。2到8個節點(按對配置)連接到一個被動背板,每個節點之間的帶寬可高達1.6Gb/秒。3Par如圖所示展示他們的8節點架構,連接的數量很容易就能看清楚。我還看到2節點、4節點、6節點和8節點部署下的連接是如何增加的。InServ陣列按對寫入高速緩存數據,因此每個節點都有一個伴點。如果一個節點發生故障,伴點上的高速緩存可以馬上寫入另一個節點,從而保護高速緩存數據。
IBM XIV
IBM XIV陣列採用的是另一種節點設置方式。節點直接連接到底層硬體的數據保護機制。XIV只使用RIAD-1類型的保護,採用的是1MB大小的數據塊,也稱為分區。數據以偽隨機方式均勻分布在節點上,確保對任何LUN來說,數據都是寫入在所有節點上。本文底部的XIV圖片顯示了這個架構。節點(在XIV中稱為模塊)分成介面模塊和數據模塊。介面模塊有自己的高速緩存、處理器、數據磁碟和主機介面。數據模塊沒有主機介面,但是仍然有高速緩存、處理器和磁碟。每個模塊有12個1TB SATA驅動器。當數據寫入陣列的時候,這些1MB分區寫入到所有驅動器和模塊中,確保任意一個分區的兩個鏡像對不會都處在同一個模塊上。LUN的順序分區分布在各個模塊上。這樣做的結果就是所有的模塊都參與服務所有的卷,且單個模塊的故障不會導致數據丟失。

4. 分布式存儲系統架構設計,應該遵循什麼樣的原則

分布式存儲分很多類型啊,對稱/非對稱 並行IO/串列IO,不同需求有不同架構思路。沒有設計目標不要談原則。

5. 集中式存儲和分布式存儲可以共同部署嗎

不能共同部署的,面對如何數據增長的趨勢,分布式存儲更加具備優勢;

分布式和集中式存儲的選擇

集中存儲的優缺點是,物理介質集中布放;視頻流上傳到中心對機房環境要求高,要求機房空間大,承重、空調等都是需要考慮的問題。

分布存儲,集中管理的優缺點是,物理介質分布到不同的地理位置;視頻流就近上傳,對骨幹網帶寬沒有什麼要求;可採用多套低端的小容量的存儲設備分布部署,設備價格和維護成本較低;小容量設備分布部署,對機房環境要求低。

杉岩數據專注分布式存儲,提供整體的存儲解決方案

6. 有沒有用Java寫的輕量級開源的分布式存儲系統

以下內容源於分布式內存文件系統:Tachyon 14年9月的文章
Tachyon是一個分布式內存文件系統,可以在集群里以訪問內存的速度來訪問存在tachyon里的文件。把Tachyon是架構在最底層的分布式文件存儲和上層的各種計算框架之間的一種中間件。主要職責是將那些不需要落地到DFS里的文件,落地到分布式內存文件系統中,來達到共享內存,從而提高效率。同時可以減少內存冗餘,GC時間等。
<img src="https://pic3.mg.com/_b.png" data-rawwidth="810" data-rawheight="311" class="origin_image zh-lightbox-thumb" width="810" data-original="https://pic3.mg.com/_r.png">
Tachyon架構
Tachyon的架構是傳統的Master—slave架構,這里和Hadoop類似,TachyonMaster里WorkflowManager是 Master進程,因為是為了防止單點問題,通過Zookeeper做了HA,可以部署多台Standby Master。Slave是由Worker Daemon和Ramdisk構成。這里個人理解只有Worker Daemon是基於JVM的,Ramdisk是一個off heap memory。Master和Worker直接的通訊協議是Thrift。
下圖來自Tachyon的作者Haoyuan Li:
<img src="https://pic4.mg.com/_b.png" data-rawwidth="854" data-rawheight="571" class="origin_image zh-lightbox-thumb" width="854" data-original="https://pic4.mg.com/_r.png">
三、Fault Tolerant
Tachyon是一個分布式文件存儲系統,但是如果Tachyon里的容錯機制是怎麼樣的呢?
Tachyon使用血統這個我們在Spark里的RDD里已經很熟悉了,這里也有血統這一概念。會使用血統,通過非同步的向Tachyon的底層文件系統做Checkpoint。
當我們向Tachyon裡面寫入文件的時候,Tachyon會在後台非同步的把這個文件給checkpoint到它的底層存儲,比如HDFS,S3.. etc...
這里用到了一個Edge的演算法,來決定checkpoint的順序。
比較好的策略是每次當前一個checkpoint完成之後,就會checkpoint一個最新生成的文件。當然想Hadoop,Hive這樣的中間文件,需要刪除的,是不需要checkpoint的。
下圖來自Tachyon的作者Haoyuan Li:
<img src="https://pic1.mg.com/_b.png" data-rawwidth="822" data-rawheight="609" class="origin_image zh-lightbox-thumb" width="822" data-original="https://pic1.mg.com/_r.png">

關於重新計算時,資源的分配策略:
目前Tachyon支持2種資源分配策略:
1、優先順序的資源分配策略
2、公平調度的分配策略
<img src="https://pic2.mg.com/_b.png" data-rawwidth="940" data-rawheight="621" class="origin_image zh-lightbox-thumb" width="940" data-original="https://pic2.mg.com/_r.png">

四、總結
Tachyon是一個基於內存的分布式文件系統,通常位於分布式存儲系統和計算框架直接,可以在不同框架內共享內存,同時可以減少內存冗餘和基於Jvm內存計算框架的GC時間。
Tachyon也有類似RDD的血統概念,input文件和output文件都是會有血統關系,這樣來達到容錯。並且Tachyon也利用血統關系,非同步的做checkpoint,文件丟失情況下,也能利用兩種資源分配策略來優先計算丟失掉的資源。

7. 分布式存儲和超融合區別及優勢

分布式存儲是什麼

關於分布式存儲實際上並沒有一個明確的定義,甚至名稱上也沒有一個統一的說法,大多數情況下稱作 Distributed Data Store 或者 Distributed Storage System。

其中維基網路中給 Distributed data store 的定義是:分布式存儲是一種計算機網路,它通常以數據復制的方式將信息存儲在多個節點中。

在網路中給出的定義是:分布式存儲系統,是將數據分散存儲在多台獨立的設備上。分布式網路存儲系統採用可擴展的系統結構,利用多台存儲伺服器分擔存儲負荷,利用位置伺服器定位存儲信息,它不但提高了系統的可靠性、可用性和存取效率,還易於擴展。

盡管各方對分布式存儲的定義並不完全相同,但有一點是統一的,就是分布式存儲將數據分散放置在多個節點中,節點通過網路互連提供存儲服務。這一點與傳統集中式存儲將數據集中放置的方式有著明顯的區分。

超融合是什麼

參考維基網路中的超融合定義:

超融合基礎架構(hyper-converged infrastructure)是一個軟體定義的 IT 基礎架構,它可虛擬化常見「硬體定義」系統的所有元素。HCI 包含的最小集合是:虛擬化計算(hypervisor),虛擬存儲(SDS)和虛擬網路。HCI 通常運行在標准商用伺服器之上。

超融合基礎架構(hyper-converged infrastructure)與 融合基礎架構(converged infrastructure)最大的區別在於,在 HCI 裡面,無論是存儲底層抽象還是存儲網路都是在軟體層面實現的(或者通過 hypervisor 層面實現),而不是基於物理硬體實現的。由於所有軟體定義的元素都圍繞 hypervisor 實現,因此在超融合基礎架構上的所有實例可以聯合共享所有受管理的資源。

分布式存儲和超融合區別及優勢?

分布式存儲,它的最大特點是多節點部署, 數據通過網路分散放置。分布式存儲的特點是擴展性強,通過多節點平衡負載,提高存儲系統的可靠性與可用性。

超融合基礎架構從定義中明確提出包含軟體定義存儲(SDS),具備硬體解耦的能力,可運行在通用伺服器之上。超融合基礎架構與 Server SAN 提倡的理念類似,計算與存儲融合,通過全分布式的架構,有效提升系統可靠性與可用性,並具備易於擴展的特性。

SMTX ZBS 分布式塊存儲架構

除此之外,超融合基礎架構有更進一步的擴展,它強調以虛擬化計算(hypervisor)為核心,以軟體定義的方式整合包括虛擬化計算, 軟體定義存儲以及虛擬網路資源。從筆者來看超融合基礎架構未來的可能性更多,可促進計算,存儲,網路,安全,容災等等 IT 服務大融合,降低IT 基礎架構的復雜性,重新塑造」軟體定義的數據中心」。

8. 超融合產品和分布式文件系統的區別是什麼

超融合和分布式文件系統,其實兩者無論在應用場景,還是在架構設計,都不在同一個層次上。
首先,超融合的出現是為了提高效率、降低運營成本。推動客戶選擇超融合的主要原因是:
- 敏捷性:在數據中心內具有公共雲速度、效率和經濟性。
- 可擴展性:從小規模開始,可輕松縱向或橫向擴展,同時保持性能水平。
- 簡單性:用軟體驅動的自動化和生命周期管理來簡化運營。
超融合系統不僅僅具備計算、網路、存儲和伺服器虛擬化等資源和技術,而且還包括緩存加速、重復數據刪除、在線數據壓縮、備份軟體、快照技術等元素,而多節點可以通過網路聚合起來,實現模塊化的無縫橫向擴展(scale-out),形成統一的資源池。超融合基礎架構還提供了具有高效可擴展性的虛擬化就緒環境。此外,由於簡化了采購和部署並降低了管理成本和復雜性,它還可能實現資本和運營支出的減少。
通常超融合系統採用分布式存儲架構,通過增加節點的方式橫向擴容,但是不一定是分布式文件系統,比如杉岩的超融合一體機。
而分布式文件系統,通常也通過增加節點的方式橫向擴容,提供分布式塊存儲、分布式文件存儲、分布式對象存儲等存儲服務。但分布式文件系統與超融合並不是同一個層次上的東西。

9. 分布式存儲排名前十名有哪些

一、 Ceph

Ceph最早起源於Sage就讀博士期間的工作、成果於2004年發表,並隨後貢獻給開源社區。經過多年的發展之後,已得到眾多雲計算和存儲廠商的支持,成為應用最廣泛的開源分布式存儲平台。
二、 GFS

GFS是google的分布式文件存儲系統,是專為存儲海量搜索數據而設計的,2003年提出,是閉源的分布式文件系統。適用於大量的順序讀取和順序追加,如大文件的讀寫。注重大文件的持續穩定帶寬,而不是單次讀寫的延遲。
三、 HDFS

HDFS(Hadoop Distributed File System),是一個適合運行在通用硬體(commodity hardware)上的分布式文件系統,是Hadoop的核心子項目,是基於流數據模式訪問和處理超大文件的需求而開發的。該系統仿效了谷歌文件系統(GFS),是GFS的一個簡化和開源版本。

10. 大規模分布式存儲系統的作品目錄

前言第1章概述1.1分布式存儲概念1.2分布式存儲分類第一篇基礎篇第2章單機存儲系統2.1硬體基礎2.1.1CPU架構2.1.2IO匯流排2.1.3網路拓撲2.1.4性能參數2.1.5存儲層次架構2.2單機存儲引擎2.2.1哈希存儲引擎2.2.2B樹存儲引擎2.2.3LSM樹存儲引擎2.3數據模型2.3.1文件模型2.3.2關系模型2.3.3鍵值模型2.3.4SQL與NoSQL2.4事務與並發控制2.4.1事務2.4.2並發控制2.5故障恢復2.5.1操作日誌2.5.2重做日誌2.5.3優化手段2.6數據壓縮2.6.1壓縮演算法2.6.2列式存儲第3章分布式系統3.1基本概念3.1.1異常3.1.2一致性3.1.3衡量指標3.2性能分析3.3數據分布3.3.1哈希分布3.3.2順序分布3.3.3負載均衡3.4復制3.4.1復制的概述3.4.2一致性與可用性3.5容錯3.5.1常見故障3.5.2故障檢測3.5.3故障恢復3.6可擴展性3.6.1總控節點3.6.2資料庫擴容3.6.3異構系統3.7分布式協議3.7.1兩階段提交協議3.7.2Paxos協議3.7.3Paxos與2PC3.8跨機房部署第二篇范型篇第4章分布式文件系統4.1Google文件系統4.1.1系統架構4.1.2關鍵問題4.1.3Master設計4.1.4ChunkServer設計4.1.5討論4.2Taobao File System4.2.1系統架構4.2.2討論4.3Facebook Haystack4.3.1系統架構4.3.2討論4.4內容分發網路4.4.1CDN架構4.4.2討論第5章分布式鍵值系統5.1Amazon Dynamo5.1.1數據分布5.1.2一致性與復制5.1.3容錯5.1.4負載均衡5.1.5讀寫流程5.1.6單機實現5.1.7討論5.2淘寶Tair5.2.1系統架構5.2.2關鍵問題5.2.3討論第6章分布式表格系統6.1Google Bigtable6.1.1架構6.1.2數據分布6.1.3復制與一致性6.1.4容錯6.1.5負載均衡6.1.6分裂與合並6.1.7單機存儲6.1.8垃圾回收6.1.9討論6.2Google Megastore6.2.1系統架構6.2.2實體組6.2.3並發控制6.2.4復制6.2.5索引6.2.6協調者6.2.7讀取流程6.2.8寫入流程6.2.9討論6.3Windows Azure Storage6.3.1整體架構6.3.2文件流層6.3.3分區層6.3.4討論第7章分布式資料庫7.1資料庫中間層7.1.1架構7.1.2擴容7.1.3討論7.2Microsoft SQL Azure7.2.1數據模型7.2.2架構7.2.3復制與一致性7.2.4容錯7.2.5負載均衡7.2.6多租戶7.2.7討論7.3Google Spanner7.3.1數據模型7.3.2架構7.3.3復制與一致性7.3.4TrueTime7.3.5並發控制7.3.6數據遷移7.3.7討論第三篇實踐篇第8章OceanBase架構初探8.1背景簡介8.2設計思路8.3系統架構8.3.1整體架構圖8.3.2客戶端8.3.3RootServer8.3.4MergeServer8.3.5ChunkServer8.3.6UpdateServer8.3.7定期合並&數據分發8.4架構剖析8.4.1一致性選擇8.4.2數據結構8.4.3可靠性與可用性8.4.4讀寫事務8.4.5單點性能8.4.6SSD支持8.4.7數據正確性8.4.8分層結構第9章分布式存儲引擎9.1公共模塊9.1.1內存管理9.1.2基礎數據結構9.1.3鎖9.1.4任務隊列9.1.5網路框架9.1.6壓縮與解壓縮9.2RootServer實現機制9.2.1數據結構9.2.2子表復制與負載均衡9.2.3子表分裂與合並9.2.4UpdateServer選主9.2.5RootServer主備9.3UpdateServer實現機制9.3.1存儲引擎9.3.2任務模型9.3.3主備同步9.4ChunkServer實現機制9.4.1子表管理9.4.2SSTable9.4.3緩存實現9.4.4IO實現9.4.5定期合並&數據分發9.4.6定期合並限速9.5消除更新瓶頸9.5.1讀寫優化回顧9.5.2數據旁路導入9.5.3數據分區第10章資料庫功能10.1整體結構10.2隻讀事務10.2.1物理操作符介面10.2.2單表操作10.2.3多表操作10.2.4SQL執行本地化10.3寫事務10.3.1寫事務執行流程10.3.2多版本並發控制10.4OLAP業務支持10.4.1並發查詢10.4.2列式存儲10.5特色功能10.5.1大表左連接10.5.2數據過期與批量刪除第11章質量保證、運維及實踐11.1質量保證11.1.1RD開發11.1.2QA測試11.1.3試運行11.2使用與運維11.2.1使用11.2.2運維11.3應用11.3.1收藏夾11.3.2天貓評價11.3.3直通車報表11.4最佳實踐11.4.1系統發展路徑11.4.2人員成長11.4.3系統設計11.4.4系統實現11.4.5使用與運維11.4.6工程現象11.4.7經驗法則第四篇專題篇第12章雲存儲12.1雲存儲的概念12.2雲存儲的產品形態12.3雲存儲技術12.4雲存儲的核心優勢12.5雲平台整體架構12.5.1Amazon雲平台12.5.2Google雲平台12.5.3Microsoft雲平台12.5.4雲平台架構12.6雲存儲技術體系12.7雲存儲安全第13章大數據13.1大數據的概念13.2MapRece13.3MapRece擴展13.3.1Google Tenzing13.3.2Microsoft Dryad13.3.3Google Pregel13.4流式計算13.4.1原理13.4.2Yahoo S413.4.3Twitter Storm13.5實時分析13.5.1MPP架構13.5.2EMC Greenplum13.5.3HP Vertica13.5.4Google Dremel參考資料