構(gòu)建一個企業(yè)級分布式存儲系統(tǒng)對于任何一個團(tuán)隊(duì)來說，都是一件極具挑戰(zhàn)性的工作。不僅需要大量的理論基礎(chǔ)，還需要有良好的工程能力。SmartX 在分布式存儲領(lǐng)域已經(jīng)投入 5 年的時間，積累了很多寶貴的實(shí)踐經(jīng)驗(yàn)。我們將通過一系列文章，向大家詳細(xì)介紹 SmartX 如何構(gòu)建分布式塊存儲產(chǎn)品。本文是第一部分，整理自 SmartX 聯(lián)合創(chuàng)始人兼 CTO 張凱在 QCon 2018 大會上的演講，著重介紹相關(guān)背景和元數(shù)據(jù)服務(wù)。

成都創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括資中網(wǎng)站建設(shè)、資中網(wǎng)站制作、資中網(wǎng)頁制作以及資中網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，資中網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到資中省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

大家下午好，我今天跟大家分享的題目是『ZBS：SmartX 自研分布式塊存儲系統(tǒng)』。SmartX 是我們公司的名字，我本人是這個公司的聯(lián)合創(chuàng)始人兼 CTO。ZBS 是 SmartX 研發(fā)的分布式塊存儲產(chǎn)品的名字。

我畢業(yè)于清華計(jì)算機(jī)系，畢業(yè)以后加入百度基礎(chǔ)架構(gòu)部工作了兩年，主要從事分布式系統(tǒng)和大數(shù)據(jù)相關(guān)的工作。我本身也是開源社區(qū)的代碼貢獻(xiàn)者，參與的項(xiàng)目包括 Sheepdog 和 InfluxDB。其中 Sheepdog 是一個開源的分布式塊存儲項(xiàng)目，InfluxDB 是一個時序數(shù)據(jù)庫（Time Series Database，TSDB）項(xiàng)目。2013 年我從百度離職，和清華的兩個師兄一起創(chuàng)辦了 SmartX 公司。

SmartX 于 2013 年成立，是一個以技術(shù)為主導(dǎo)的公司，目前主要專注于分布式存儲及虛擬化這個兩個領(lǐng)域。我們的產(chǎn)品均為自己研發(fā)，目前已經(jīng)運(yùn)行在數(shù)千臺物理服務(wù)器上，存儲了數(shù)十 PB 的數(shù)據(jù)。SmartX 跟國內(nèi)主流的硬件服務(wù)商、云服務(wù)商都有合作，我們的產(chǎn)品已經(jīng)服務(wù)了包括公有云、私有云以及金融業(yè)、制造業(yè)等核心領(lǐng)域的關(guān)鍵業(yè)務(wù)，其中也包括核心應(yīng)用和核心數(shù)據(jù)庫等應(yīng)用場景。今天我將主要圍繞分布式塊存儲進(jìn)行介紹。

一般來說，我們根據(jù)存儲的訪問接口以及應(yīng)用場景，把分布式存儲分為三種類型，包括分布式塊存儲，分布式文件存儲，和分布式對象存儲。

其中，分布式塊存儲的主要應(yīng)用場景包括：

虛擬化：比如像 KVM，VMware，XenServer 等 Hypervisor，以及像 Openstack，AWS 等云平臺。塊存儲在其中的角色是支撐虛擬機(jī)中的虛擬盤的存儲。

數(shù)據(jù)庫：比如 MySQL，Oracle 等。很多 DBA 都將數(shù)據(jù)庫的數(shù)據(jù)盤運(yùn)行在一個共享的塊存儲服務(wù)上，例如分布式塊存儲。此外也有很多客戶直接把數(shù)據(jù)庫運(yùn)行在虛擬機(jī)中。

容器：容器最近幾年在企業(yè)中使用越來越廣泛。一般來說，容器中運(yùn)行的應(yīng)用都是無狀態(tài)的，但在很多應(yīng)用場景下，應(yīng)用也會有數(shù)據(jù)持久化的需求。應(yīng)用可以選擇將數(shù)據(jù)持久化到數(shù)據(jù)庫中，也可以選擇將數(shù)據(jù)持久化到一個共享虛擬磁盤上。這個需求對應(yīng)到 Kubernetes 中，就是 Persistent Volume 這個功能。

今天我將主要圍繞 SmartX 如何打造分布式塊存儲進(jìn)行介紹。SmartX 從 2013 年成立開始，到目前已經(jīng)積累了 5 年左右的分布式塊存儲的研發(fā)經(jīng)驗(yàn)，所以今天我們除了分享 SmartX 如何實(shí)現(xiàn)我們自己研發(fā)的分布式塊存儲 ZBS 以外，還會詳細(xì)介紹我們在分布式塊存儲的研發(fā)過程中的一些思考和選擇。此外也將介紹一下我們產(chǎn)品未來的規(guī)劃。

從廣泛意義上講，分布式存儲中通常需要解決三個問題，分別是元數(shù)據(jù)服務(wù)，數(shù)據(jù)存儲引擎，以及一致性協(xié)議。

其中，元數(shù)據(jù)服務(wù)提供的功能一般包括：集群成員管理，數(shù)據(jù)尋址，副本分配，負(fù)載均衡，心跳，垃圾回收等等。數(shù)據(jù)存儲引擎負(fù)責(zé)解決數(shù)據(jù)在單機(jī)上存儲，以及本地磁盤的管理，磁盤故障處理等等。每一個數(shù)據(jù)存儲引擎之間是隔離的，在這些隔離的存儲引擎之間，需要運(yùn)行一個一致性協(xié)議，來保證對于數(shù)據(jù)的訪問可以滿足我們期望的一致性狀態(tài)，例如強(qiáng)一致，弱一致，順序一致，線性一致等等。我們根據(jù)不同的應(yīng)用場景，選擇一個適合的一致性協(xié)議，這個協(xié)議將負(fù)責(zé)數(shù)據(jù)在不同的節(jié)點(diǎn)之間的同步工作。

有了這三部分，我們基本上就掌握了一個分布式存儲的核心。不同的分布式存儲系統(tǒng)之間的區(qū)別，基本也都來自于這三個方面的選擇不同。

接下來我會分別從這三個方面介紹一下我們在做 ZBS 系統(tǒng)設(shè)計(jì)的時候是怎樣思考的，以及最終決定采用哪種類型的技術(shù)和實(shí)現(xiàn)方法。

首先我們來介紹一下元數(shù)據(jù)服務(wù)。我們先來談?wù)勎覀儗υ獢?shù)據(jù)服務(wù)的需求。

所謂元數(shù)據(jù)就是『數(shù)據(jù)的數(shù)據(jù)』，比如說數(shù)據(jù)放在什么位置，集群中有哪些服務(wù)器，等等。如果元數(shù)據(jù)丟失了，或者元數(shù)據(jù)服務(wù)無法正常工作，那么整個集群的數(shù)據(jù)都無法被訪問了。

由于元數(shù)據(jù)的重要性，所以對元數(shù)據(jù)的第一個需求就是可靠性。元數(shù)據(jù)必須是保存多份的，同時元數(shù)據(jù)服務(wù)還需要提供 Failover 的能力。

第二個需求就是高性能。盡管我們可以對 IO 路徑進(jìn)行優(yōu)化，使得大部分 IO 請求都不需要訪問元數(shù)據(jù)服務(wù)，但永遠(yuǎn)都有一些 IO 請求還是需要修改元數(shù)據(jù)，比如數(shù)據(jù)分配等等。為避免元數(shù)據(jù)操作成為系統(tǒng)性能的瓶頸，元數(shù)據(jù)操作的響應(yīng)時間必須足夠短。同時由于分布式系統(tǒng)的集群規(guī)模在不斷的擴(kuò)大，對于元數(shù)據(jù)服務(wù)的并發(fā)能力也有一定的要求。

最后一個需求是輕量級。由于我們產(chǎn)品大部分使用場景是私有部署，也就是我們的產(chǎn)品是部署在客戶的數(shù)據(jù)中心的，且由客戶自己運(yùn)維，而非我們的運(yùn)維人員運(yùn)維。這個場景和很多互聯(lián)網(wǎng)公司自己來運(yùn)維自己的產(chǎn)品是完全不同的場景。所以對于 ZBS 來說，我們更強(qiáng)調(diào)整個系統(tǒng)，尤其是元數(shù)據(jù)服務(wù)的輕量級，以及易運(yùn)維的能力。我們期望元數(shù)據(jù)服務(wù)可以輕量級到可以把元數(shù)據(jù)服務(wù)和數(shù)據(jù)服務(wù)混合部署在一起。同時我們希望大部分的運(yùn)維操作都可以由程序自動完成，或用戶只需要在界面上進(jìn)行簡單的操作就可以完成。如果大家了解 HDFS 的話，HDFS 中的元數(shù)據(jù)服務(wù)的模塊叫做 Namenode，這是一個非常重量級的模塊。Namenode 需要被獨(dú)立部署在一臺物理服務(wù)器上，且對硬件的要求非常高，且非常不易于運(yùn)維，無論是升級還是主備切換，都是非常重的操作，非常容易因操作問題而引發(fā)故障。

以上就是我們對元數(shù)據(jù)服務(wù)的需求。接下來我們來看一下具體有哪些方法可以構(gòu)造一個元數(shù)據(jù)服務(wù)。

談到存儲數(shù)據(jù)，尤其是存儲結(jié)構(gòu)化的數(shù)據(jù)，我們第一個想到的就是關(guān)系型數(shù)據(jù)庫，例如 MySQL，以及一些成熟的 KV 存儲引擎，例如 LevelDB，RocksDB 等。但這種類型的存儲大的問題就是無法提供可靠的數(shù)據(jù)保護(hù)和 Failover 能力。LevelDB 和 RocksDB 雖然非常輕量級，但都只能把數(shù)據(jù)保存在單機(jī)上。而盡管 MySQL 也提供一些主備方案，但我們認(rèn)為 MySQL 的主備方案是一個太過笨重的方案，且缺乏簡易的自動化運(yùn)維方案，所以并不是一個十分好的選擇。

其次，我們來看一下一些分布式數(shù)據(jù)庫，例如 MongoDB 和 Cassandra。這兩種分布式數(shù)據(jù)庫都可以解決數(shù)據(jù)保護(hù)和提供 Failover 機(jī)制。但是他們都不提供 ACID 機(jī)制，所以在上層實(shí)現(xiàn)時會比較麻煩，需要額外的工作量。其次就是這些分布式數(shù)據(jù)庫在運(yùn)維上也相對復(fù)雜，不是很易于自動化運(yùn)維。

也有一種選擇是基于 Paxos 或者 Raft 協(xié)議自己實(shí)現(xiàn)一個框架。但這樣實(shí)現(xiàn)的代價非常大，對于一個創(chuàng)業(yè)公司不是一個很劃算的選擇。并且我們創(chuàng)業(yè)的時間是 2013 年，當(dāng)時 Raft 也只是剛剛提出。

第四種是選擇 Zookeeper。Zookeeper 基于 ZAB 協(xié)議，可以提供一個穩(wěn)定可靠地分布式存儲服務(wù)。但 Zookeeper 的大的問題是能夠存儲的數(shù)據(jù)容量非常有限。為了提高訪問速度，Zookeeper 把存儲的所有數(shù)據(jù)都緩存在內(nèi)存中，所以這種方案導(dǎo)致元數(shù)據(jù)服務(wù)所能支撐的數(shù)據(jù)規(guī)模嚴(yán)重受限于服務(wù)器的內(nèi)存容量，使得元數(shù)據(jù)服務(wù)無法做到輕量級，也無法和數(shù)據(jù)服務(wù)混合部署在一起。

最后還有一種方式是基于 Distributed Hash Table（DHT）的方法。這種方法的好處元數(shù)據(jù)中不需要保存數(shù)據(jù)副本的位置，而是根據(jù)一致性哈希的方式計(jì)算出來，這樣就極大地降低了元數(shù)據(jù)服務(wù)的存儲壓力和訪問壓力。但使用 DHT 存在的問題，就喪失了對數(shù)據(jù)副本位置的控制權(quán)，在實(shí)際生產(chǎn)環(huán)境中，非常容易造成集群中的產(chǎn)生數(shù)據(jù)不均衡的現(xiàn)象。同時在運(yùn)維過程中，如果遇到需要添加節(jié)點(diǎn)，移除節(jié)點(diǎn)，添加磁盤，移除磁盤的情況，由于哈希環(huán)會發(fā)生變化，一部分?jǐn)?shù)據(jù)需要重新分布，會在集群中產(chǎn)生不必要的數(shù)據(jù)遷移，而且數(shù)據(jù)量往往非常大。而這種于運(yùn)維操作在一個比較大規(guī)模的環(huán)境中幾乎每天都會發(fā)生。大規(guī)模的數(shù)據(jù)遷移很容易影響到線上的業(yè)務(wù)的性能，所以 DHT 使得運(yùn)維操作變得非常麻煩。

以上介紹的方法都存在各種各樣的問題，并不能直接使用。最終 ZBS 選擇了使用 LevelDB（也可以替換成 RocksDB） 和 Zookeeper 結(jié)合的方式，解決元數(shù)據(jù)服務(wù)的問題。首先，這兩個服務(wù)相對來說都非常輕量級；其次 LevelDB 和 Zookeeper 使用在生產(chǎn)中也非常穩(wěn)定。

我們采用了一種叫做 Log Replication 的機(jī)制，可以同時發(fā)揮 LevelDB 和 Zookeeper 的優(yōu)點(diǎn)，同時避開他們自身的問題。

這里我們簡單的介紹一下 Log Replication。簡單來說，我們可以把數(shù)據(jù)或者狀態(tài)看作是一組對數(shù)據(jù)操作的歷史集合，而每一個操作都可以通過被序列化成 Log 記錄下來。如果我們可以拿到所有 的 Log，并按照 Log 里面記錄的操作重復(fù)一遍，那么我們就可以完整的恢復(fù)數(shù)據(jù)的狀態(tài)。任何一個擁有 Log 的程序都可以通過重放 Log 的方式恢復(fù)數(shù)據(jù)。如果我們對 Log 進(jìn)行復(fù)制，實(shí)際上也就相當(dāng)于對數(shù)據(jù)進(jìn)行了復(fù)制。這就是 Log Replication 最基本的想法。

我們具體來看一下 ZBS 是如何利用 Zookeeper + LevelDB 完成 Log Replication 操作的。首先，集群中有很多個 Meta Server，每個 Server 本地運(yùn)行了一個 LevelDB 數(shù)據(jù)庫。Meta Server 通過 Zookeeper 進(jìn)行選主，選出一個 Leader 節(jié)點(diǎn)對外響應(yīng)元數(shù)據(jù)請求，其他的 Meta Server 則進(jìn)入Standby 狀態(tài)。

當(dāng) Leader 節(jié)點(diǎn)接收到元數(shù)據(jù)的更新操作后，會將這個操作序列化成一組操作日志，并將這組日志寫入 Zookeeper。由于 Zookeeper 是多副本的，所以一旦 Log 數(shù)據(jù)寫入 Zookeeper，也就意味著 Log 數(shù)據(jù)是安全的了。同時這個過程也完成了對 Log 的復(fù)制。

當(dāng)日志提交成功后，Meta Server 就可以將對元數(shù)據(jù)的修改同時提交到本地的 LevelDB 中。這里 LevelDB 中存儲的是一份全量的數(shù)據(jù)，而不需要以 Log 的形式存儲。

對于非 Leader 的 Meta Server 節(jié)點(diǎn)，會異步的從 Zookeeper 中拉取 Log，并將通過反序列化，將 Log 轉(zhuǎn)換成對元數(shù)據(jù)的操作，再將這些修改操作提交到本地的 LevelDB 中。這樣就能保證每一個 Meta Server 都可以保存一個完整的元數(shù)據(jù)。

前面提到，由于 Zookeeper 存儲數(shù)據(jù)的容量受限于內(nèi)存容量。為了避免 Zookeeper 消耗過多內(nèi)存，我們對 Zookeeper 中的 Log 定期執(zhí)行清理。只要 Log 已經(jīng)被所有的 Meta Server 同步完， Zookeeper 中保存的 Log 就可以被刪除了，以節(jié)省空間。通常我們在 Zookeeper 上只保存 1GB 的 Log，已經(jīng)足夠支撐元數(shù)據(jù)服務(wù)。

Failover 的邏輯也非常簡單。如果 Leader 節(jié)點(diǎn)發(fā)生故障，其他還存活的的 Meta Server 通過 Zookeeper 再重新進(jìn)行一次選主，選出一個新的 Meta Leader。這個新的 Leader 將首先從 Zookeeper 上同步所有還未消耗的日志，并在提交到本地的 LevelDB 中，然后就可以對外提供元數(shù)據(jù)服務(wù)了。

現(xiàn)在我們總結(jié)一下 ZBS 中元數(shù)據(jù)服務(wù)實(shí)現(xiàn)的特點(diǎn)。

首先，這個原理非常容易理解，而且實(shí)現(xiàn)起來非常簡單。由 Zookeeper 負(fù)責(zé)選主和 Log Replication，由 LevelDB 負(fù)責(zé)本地元數(shù)據(jù)的存儲。背后的邏輯就是盡可能的將邏輯進(jìn)行拆分，并盡可能的復(fù)用已有項(xiàng)目的實(shí)現(xiàn)。

其次，速度足夠快。Zookeeper 和 LevelDB 本身的性能都不錯，而且在生產(chǎn)中，我們將 Zookeeper 和 LevelDB 運(yùn)行在 SSD 上。在實(shí)際測試中，對于單次元數(shù)據(jù)的修改都是在毫秒級完成。在并發(fā)的場景下，我們可以對元數(shù)據(jù)修改的日志做 Batch，以提高并發(fā)能力。

此外，這種方式支持 Failover，而且 Failover 的速度也非常快。Failover 的時間就是選主再加上 Log 同步的時間，可以做到秒級恢復(fù)元數(shù)據(jù)服務(wù)。

最后說一下部署。在線上部署的時候，我們通常部署 3 個或 5 個 Zookeeper 服務(wù)的實(shí)例以及至少 3 個 Meta Server 服務(wù)的實(shí)例，以滿足元數(shù)據(jù)可靠性的要求。元數(shù)據(jù)服務(wù)對資源消耗都非常小，可以做到和其他服務(wù)混合部署。

以上是一些基本的原理，我們再來看一下 ZBS 內(nèi)部的對于元數(shù)據(jù)服務(wù)的具體實(shí)現(xiàn)。

我們將上述的 Log Replication 邏輯封裝在了一個 Log Replication Engine 中，其中包含了選主、向 Zookeeper 提交 Log、向 LevelDB 同步數(shù)據(jù)等操作，進(jìn)一步簡化開發(fā)復(fù)雜度。

在 Log Replication Engine 的基礎(chǔ)之上，我們實(shí)現(xiàn)了整個 Meta Sever 的邏輯，其中包含了 Chunk Manager，NFS Manger，iSCSI Manager，Extent Manager 等等很多管理模塊，他們都可以通過 Log Replication Engine，管理特定部分的元數(shù)據(jù)。RPC 模塊是 Meta Server 對外暴露的接口，負(fù)責(zé)接收外部的命令，并轉(zhuǎn)發(fā)給對應(yīng)的 Manager。例如創(chuàng)建/刪除文件，創(chuàng)建/刪除虛擬卷等等。此外，Meta Server 中還包含了一個非常復(fù)雜的調(diào)度器模塊，里面包含了各種復(fù)雜的分配策略，恢復(fù)策略，負(fù)載均衡策略，以及心跳，垃圾回收等功能。

以上就是關(guān)于 SmartX 超融合系統(tǒng)中 SMTX 分布式塊存儲元數(shù)據(jù)服務(wù)部分的介紹。

了解更多信息可訪問 SmartX 官網(wǎng)：https://www.smartx.com

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

本文標(biāo)題：SmartX產(chǎn)品技術(shù)解析：SMTX分布式塊存儲--元數(shù)據(jù)篇-創(chuàng)新互聯(lián)
當(dāng)前路徑：http://www.rwnh.cn/article18/cesjdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計(jì)、營銷型網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化、外貿(mào)建站、小程序開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)