大資料技術訓練艙，手把手從零教你大資料技術開發：
大資料技術訓練艙：從零開始部署Hadoop3高可用集群（基于CentOS7）
大資料技術訓練艙——從零開始安裝、配置CentOS 7
很多人容易將分布式存盤和分布式檔案系統的概念搞混，我先做一個概念上的梳理：
分布式存盤所涵蓋的范圍極廣，例如NFS，雖然只是用于目錄共享的網路檔案系統，但是它也屬于分布式存盤范疇，再比如說分布式物件存盤，例如Ceph體系不僅包括了分布式檔案系統CephFS，也包括了Ceph分布式物件存盤，它們都屬于分布式存盤范圍，
分布式檔案系統（DFS）最關鍵的一個特征就是模擬了本地檔案系統的目錄層次，這對于檔案在虛擬目錄中的移動，管理具有很好的優勢，首先這個優勢是分布式物件存盤等無法做到的，
我們再回傳頭專門說分布式檔案系統(DFS)的問題：
1. 解決副本存盤占用率問題
先說資料可靠性問題，副本因子為3個副本，這在不少的DFS系統中作為默認副本數量，這只是資料可靠性的一種策略，通過3副本的形式，提升資料可靠性，本質上就是提升了分布式環境資料的容錯率，但是3副本最大的問題就是占空間，DFS集群的空間利用率只有33.3%，這么低的利用率顯然不符合一些場景，例如長期的冷數備份，
那么DFS有沒有更好的空間利用方式呢？有！目前比較成熟的方案就是糾刪碼（EC冗余），類似Raid5，Raid6，
我們拿其中一種分布式檔案系統GlusterFS來探其原理，看看它是怎么通過糾刪碼解決的：
首先資料寫檔案的時候被分成N個組塊(chunk)，每個chunk又被切成N個條(stripe)，如果分布式環境有三個存盤節點(bricks)，那么就把stripe切成2個塊(block)，然后再根據這2個block計算出1個校驗塊，然后這3個塊分別存盤在3個bricks，資料條就這么依次輪詢的方式，將校驗塊的位置輪換存盤在不同brick上，這樣校驗塊的分布可以更均勻，
其次當從檔案讀資料時，每次只從兩個bricks中各取出1個塊，如果這兩個block都是資料塊，那么就成功拿到chunk里的一個資料條，如果有一個是校驗塊，那么就能通過校驗塊和一個資料block計算出另一個資料block，完成資料條的組合，這種情況下，即便是3個bricks節點有1個brick宕機了，另外兩個bricks也能通過校驗碼計算完成資料恢復，這就是GlusterFS利用糾刪碼技術實作資料冗余的原理，
通過這種方式，我們就比2副本50%，3副本33.3%的多副本模式要省空間，最少可以達到66.7%的磁盤利用率，但是其問題是特別消耗CPU計算，上面那種讀取情況，三分之二的讀取資料條時間都要進行校驗碼計算，因此可以利用Intel CPU推出的ISA-L底層函式庫專門用于提升校糾刪碼演算法的編解碼性能，通常情況下，EC冗余策略用于冷資料的備份，也就是不經常訪問，但又必須聯機存盤以備查詢的資料，
除了磁盤利用率，多副本方式用空間換效率的方式肯定是最好的，從性能考慮是沒什么問題，
唯一一點需要注意的是GlusterFS是去中心化的DFS架構，其檔案目錄的管理操作不如其他中心化DFS架構容易，例如Hadoop HDFS架構都是基于NameNode的主節點通過對元資料的操作，實作各個節點的資料檔案的邏輯變化，但GlusterFS不行，需要客戶端來主導管理性操作，但最終都會觸發不同節點的資料檔案發生物理上的變動，
盡管HDFS也有EC方案，但并沒有GlusterFS的EC策略靈活方便，GlusterFS很容易就能形成ES策略與其他策略在同一集群的共用，也支持分布式卷+EC卷=分布式EC卷的架構靈活組合，
2. 解決復雜的高可用問題
傳統分布式檔案管理存在對元資料的高度依賴問題，HDFS的大量資料存盤節點DataNode，需要依賴元資料服務NameNode的統一管理，MooseFS的大量資料存盤節點ChunkServer需要依賴元資料服務MFS Master，任何客戶端發起對資料存盤節點的寫入和查詢，都需要從元資料服務節點獲取路徑，或者獲取寫入管道的分配，
這種依賴元資料服務的架構，極為突出的問題就是元資料服務不能掛，一旦元資料掛了，那么整個集群就停擺了，所謂單點故障導致的災難，
因此HDFS為NameNode引入了高可用（HA）架構，相當于雙節點主備關系，中間的元資料需要QJM機制來保證同步，ZKFC服務來監控主備節點的狀態，我們掐指一算，NN Active、NN Standby、Journal集群、ZKFC監控雙節點、ZooKeeper集群，五種角色的服務或者集群來保證元資料架構的高可用，非常的復雜，
MooseFS甚至對于高可用版本只存在于商業版本，而只是給開源版本采用了類似MySQL的主從機制，一個MFS Master連接多個MFS MetaLogger，只實作了元資料的主從復制，滿足Master宕機后，可以在其他MetaLogger節點手動啟動Master讀取備份的元資料，但是沒有商用版的高可用支持，開源版本就無法達到故障轉移的運行可靠性，因此MFS Master掛了，集群肯定就不好了，開源版本無法作為嚴格性要求高的生產環境，需要達到就請付費了，
我們看到了分布式檔案系統因為對元資料的高度依賴，形成了對高可用環境的高度需求，高可用環境又導致了部署復雜度，甚至干脆收費，
那么有沒有更好的辦法呢？這個問題還是GlusterFS做的比較獨樹一幟，直接拋棄了傳統分布式檔案系統的元資料集中式管理，大家想，為什么能在一個集群成百上千臺機器之上構建出一個虛擬的檔案目錄形式？這是因為全靠集群元資料的組織與管理，我們讀取的目錄，實際上只是元資料在記憶體中的一個組織樹結構而已，
作為GlusterFS到好，直接廢了這種元資料集中管理的架構，而是采用了思想更為超前的去中心化架構，任何一個節點都是對等的，每個節點的目錄屬性里面存盤了自己的元資料，大家通過共識機制，而非管理機制，那么客戶端只需要遵循共識機制來訪問集群的資料節點，可以這么講，客戶端這時候即當媽又當爹，被設計得非常重，集資料讀寫、查詢和組織管理為一身，
GlusterFS用卷(Volume)的邏輯概念，適配了分布式的不同架構，例如：分布式卷，集群不同存盤節點但完全相同路徑的目錄被Hash成多個段，檔案寫入的時候，客戶端計算檔案的Hash值，就能確定這個檔案應該存盤的路徑目錄屬于集群那個節點的Hash范圍，客戶端就存盤到那個節點上的目錄，這樣就實作了大量寫入檔案在集群多個存盤節點的相同路徑目錄的分布存放，
GlusterFS還支持復制卷，也就是一對三的檔案復制模式，甚至還支持分布式副本卷這樣的卷卷嵌套模式，總之GlusterFS想通過去中心這種方式，避開傳統分布式檔案系統的因為單點故障而高度依賴的高可用架構所帶來的復雜度，
不過去中心化也有去中心化的問題，在檔案的操作管理上始終不如集中式的靈活，并且元資料的操作GlusterFS傾向于物理行為，而集中式都是邏輯行為，因此GlusterFS才會出現在移動檔案操作的時候，竟然在不同節點做分布式檔案鏈接這樣通過策略解決架構缺陷的蹩腳手法，當然這樣完全可以理解，沒有十全十美的事情，
但是GlusterFS作為去中心化架構，這種優勢就是將所有節點的重要級別拉平了，那么就不存在那個節點是最重要的問題，任何節點都可以故障，但不會影響到集群整體的高可靠性，這是去中心化架構一直以來最具有優勢的傳統，
您覺得文章寫得不錯就點贊、分享一下吧！
本文由公眾號「守護石」出品，轉載請注明來源和作者，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/399630.html
標籤：區塊鏈
上一篇：NFT概述