分布式塊存儲系統(tǒng)Ursa的設計與實現(xiàn)

1、分布式塊存儲系統(tǒng)Ursa的設計與實現(xiàn)引言云硬盤對IaaS云計算平臺有至關(guān)重要的作用，幾乎已成為必備組件，如亞馬遜的EBS(Elastic Block Store)、阿里云的盤古、OpenStack中的Cinder等。云硬盤可為云計算平臺帶來許多優(yōu)良特性，如更高的數(shù)據(jù)可靠性和可用性、靈活的數(shù)據(jù)快照功能、更好的虛擬機動態(tài)遷移支持、更短的主機故障恢復時間等等。隨著萬兆以太網(wǎng)逐漸普及，云硬盤的各項優(yōu)勢得到加強和凸顯，其必要性變得十分強烈。云硬盤的底層通常是分布式塊存儲系統(tǒng)，目前開源領(lǐng)域有一些此類項目，如Ceph RBD、Sheepdog。另外MooseFS和GlusterFS雖然叫做文件系統(tǒng)，但由于其

2、特性與塊存儲系統(tǒng)接近，也能用于支持云硬盤。我們在測評中發(fā)現(xiàn)，這些開源項目均存在一些問題，使得它們都難以直接應用在大規(guī)模的生產(chǎn)系統(tǒng)當中。例如Ceph RBD的效率較低（CPU使用過高）；Sheepdog在壓力測試中出現(xiàn)了數(shù)據(jù)丟失的現(xiàn)象；MooseFS的POSIX語義支持、基于FUSE的架構(gòu)、不完全開源的2.0版本等問題給它自身帶來了許多的局限性；GlusterFS與Ceph同屬紅帽收購的開源存儲系統(tǒng)，主要用于scale-out文件存儲場景，在云計算領(lǐng)域使用不多。此外，這些存儲系統(tǒng)都難以充發(fā)揮用萬兆網(wǎng)卡和SSD的性能潛力，難以在未來承擔重任。由于以上原因，美團云研發(fā)了全新的分布式塊存儲系統(tǒng)Ursa

3、，通過簡單穩(wěn)固的系統(tǒng)架構(gòu)、高效的代碼實現(xiàn)以及對各種非典型場景的仔細考慮，實現(xiàn)了高可靠、高可用、高性能、低開銷、可擴展、易運維、易維護等等目標。Ursa的名字源于DotA中的熊戰(zhàn)士，他具有極高的攻擊速度、攻擊力和生命值，分別隱喻存儲系統(tǒng)中的IOPS、吞吐率和穩(wěn)定性。分布式塊存儲相關(guān)項目與技術(shù)2.1 Ceph（主要參考：Ceph項目起源于其創(chuàng)始人Sage Weil在加州大學Santa Cruz分校攻讀博士期間的研究課題。項目的起始時間為2004年。在2006年的OSDI學術(shù)會議上，Sage發(fā)表了關(guān)于Ceph的論文，并提供了項目的下載鏈接，由此開始廣為人知。2010年Ceph客戶端部分代碼正式進入L

4、inux kernel 2.6.34。Ceph同時提供對象、塊和文件這三個層次的分布式存儲服務，其中只有塊層存儲與我們相關(guān)。由于塊存儲在IaaS云計算系統(tǒng)中占有重要地位，Ceph在近些年的關(guān)注度得到顯著提高。許多云計算系統(tǒng)實例基于Ceph提供塊存儲服務，如UnitedStack、Mirantis OpenStack等。Ceph性能測試· 測試版本：0.81· 操作系統(tǒng)：CentOS 6.x· 測試工具：fio· 服務器配置：o CPU: Intel Xeon E5-2650v2 2.6GHzo RAM: 96GBo NIC: 10 GbEo HDD: 6

5、 NL SAS, 7200 RPMo RAID Controller: Dell H710p (LSI 2208 with 1GB NVRAM)· 服務器數(shù)量：4，其中一個為兼職客戶端注意：由于客戶端位于一個存儲服務器上，所以有1/4的吞吐率不經(jīng)過網(wǎng)卡。測試結(jié)果如下：· 讀IOPS：16 407（此時客戶端CPU占用率超過500%，5臺服務器CPU總使用率接近500%）· 寫IOPS：941· 順序讀吞吐率：218 859 KB/s· 順序?qū)懲掏侣剩?7 242 KB/s· 順序讀延遲：1.6ms (664 IOPS)· 順

6、序?qū)懷舆t：4.4ms (225 IOPS)· 網(wǎng)絡ping值：0.1324ms· 本地硬盤順序讀寫延遲：0.03332ms (29 126 IOPS)從測試來看，Ceph的讀吞吐率正常，然而寫吞吐率不足讀的1/3，性能偏低；讀寫延遲比顯著大于網(wǎng)絡延遲與磁盤I/O延遲之和；CPU占用率過高。2.2 Sheepdog（主要參考：Sheepdog是由日本NTT實驗室的Morita Kazutaka專為虛擬化平臺創(chuàng)立的分布式塊存儲開源項目, 于2009年開源1。從2011年9月開始, 一些淘寶的工程師加入了Sheepdog項目，以及相關(guān)開源項目比如Corosync、Accord的開

7、發(fā)。Sheepdog主要由兩部分組成：集群管理和存儲服務，其中集群管理目前使用Corosync或者Zookper來完成，存儲服務是全新實現(xiàn)的。Sheepdog采用無中心節(jié)點的全對稱架構(gòu)，基于一致性哈希實現(xiàn)從ObjectID到存儲節(jié)點的定位：每個節(jié)點劃分成多個虛擬節(jié)點，虛擬節(jié)點和ObjectID一樣，采用64位整數(shù)唯一標識，每個虛擬節(jié)點負責一段包含節(jié)點ID在內(nèi)的ObjectID區(qū)間。DataObject副本存在ObjectID對應的虛擬節(jié)點，及在后續(xù)的幾個節(jié)點上。Sheepdog無單點故障問題，存儲容量和性能均可線性擴展，新增節(jié)點通過簡單配置即可加入集群，并且Sheepdog自動實現(xiàn)負載均衡，節(jié)

8、點故障時可自動發(fā)現(xiàn)并進行副本修復，還直接支持QEMU/KVM。Sheepdog的服務進程既承擔數(shù)據(jù)服務的職責，同時也是客戶端（QEMU）訪問數(shù)據(jù)的gateway。QEMU的Sheepdog driver將對volume的請求轉(zhuǎn)換成為對object的請求，然后通過UNIX domain socket或者TCP socket連接一個Sheepdog服務進程，并將訪問請求發(fā)給該進程來完成后續(xù)步驟。Sheepdog的服務進程還可以開啟數(shù)據(jù)緩存功能，以減少網(wǎng)絡I/O。Sheepdog的I/O路徑是“client<->gateway<->object manager(s)”，讀操作

9、可以在任意副本完成，更新操作并行的發(fā)往所有副本， 當所有副本都更新成功之后，gateway才告訴客戶端更新操作成功。Sheepdog的數(shù)據(jù)可靠性問題我們對Sheepdog開展了可靠性、可用性測試。在測試中有共3臺服務器，每臺配有6個機械硬盤，配置好Sheepdog之后，每臺服務器啟動10個VM，每個VM內(nèi)無限循環(huán)運行fio分別執(zhí)行小塊隨機讀、寫和大塊順序讀、寫的測試。在執(zhí)行壓力測試一周后，對集群中的全部數(shù)據(jù)進行一致性檢測（collie cluster check），發(fā)現(xiàn)有些數(shù)據(jù)塊副本與另外2個不一致（“fixed replica .”），有些數(shù)據(jù)塊的3個各不相同（“no majority of

10、 .”）：rootnode3-10gtest # collie cluster check fix vdi test1-3 99.9 % => 50 GB / 50 GB fixed replica 3e563000000fca 99.9 % => 50 GB / 50 GB fixed replica 3e563000000fec 100.0 % => 50 GB / 50 GB fixed replica 3e5630000026f5 100.0 % => 50 GB / 50 GB fixed replica 3e563000002da6 100.0 % =>

11、; 50 GB / 50 GB fixed replica 3e563000001e8c 100.0 % => 50 GB / 50 GB fixed replica 3e563000001530 . fix vdi test2-9 50.9 % => 25 GB / 50 GB no majority of d781e300000123 51.0 % => 26 GB / 50 GB no majority of d781e300000159 51.2 % => 26 GB / 50 GB no majority of d781e30000018a 53.2 % =&

12、gt; 27 GB / 50 GB 2.3 MooseFS（主要參考：MooseFS是容錯的分布式文件系統(tǒng)，通過FUSE支持標準POSIX文件系統(tǒng)接口。 MooseFS的架構(gòu)類似于GFS，由四個部分組成：· 管理服務器Master：類似于GFS的Master，主要有兩個功能：(1）存儲文件和目錄元數(shù)據(jù)，文件元數(shù)據(jù)包括文件大小、屬性、對應的Chunk等；(2）管理集群成員關(guān)系和Chunk元數(shù)據(jù)信息，包括Chunk存儲、版本、Lease等。· 元數(shù)據(jù)備份服務器Metalogger Server：根據(jù)元數(shù)據(jù)文件和log實時備份Master元數(shù)據(jù)。· 存儲服務器Chunk

13、 Server：負責存儲Chunk，提供Chunk讀寫能力。Chunk文件默認為64MB大小。· 客戶端Client：以FUSE方式掛到本地文件系統(tǒng)，實現(xiàn)標準文件系統(tǒng)接口。MooseFS本地不會緩存Chunk信息， 每次讀寫操作都會訪問Master， Master的壓力較大。此外MooseFS寫操作流程較長且開銷較高。MooseFS支持快照，但是以整個Chunk為單位進行CoW(Copy-on-Write)，可能造成響應時間惡化，補救辦法是以犧牲系統(tǒng)規(guī)模為代價，降低Chunk大小。MooseFS基于FUSE提供POSIX語義支持，已有應用可以不經(jīng)修改直接遷移到MooseFS之上，這給

14、應用帶來極大的便利。然而FUSE也帶來了一些負面作用，比如POSIX語義對于塊存儲來說并不需要，F(xiàn)USE會帶來額外開銷等等。2.4 GFS/HDFS（主要參考：HDFS基本可以認為是GFS的一個簡化開源實現(xiàn)，二者因此有很多相似之處。首先，GFS和HDFS都采用單一主控機+多臺工作機的模式，由一臺主控機(Master)存儲系統(tǒng)全部元數(shù)據(jù)，并實現(xiàn)數(shù)據(jù)的分布、復制、備份決策，主控機還實現(xiàn)了元數(shù)據(jù)的checkpoint和操作日志記錄及回放功能。工作機存儲數(shù)據(jù)，并根據(jù)主控機的指令進行數(shù)據(jù)存儲、數(shù)據(jù)遷移和數(shù)據(jù)計算等。其次，GFS和HDFS都通過數(shù)據(jù)分塊和復制（多副本，一般是3）來提供更高的可靠性和更高的性

15、能。當其中一個副本不可用時，系統(tǒng)都提供副本自動復制功能。同時，針對數(shù)據(jù)讀多于寫的特點，讀服務被分配到多個副本所在機器，提供了系統(tǒng)的整體性能。最后，GFS和HDFS都提供了一個樹結(jié)構(gòu)的文件系統(tǒng)，實現(xiàn)了類似與Linux下的文件復制、改名、移動、創(chuàng)建、刪除操作以及簡單的權(quán)限管理等。然而，GFS和HDFS在關(guān)鍵點的設計上差異很大，HDFS為了規(guī)避GFS的復雜度進行了很多簡化。例如HDFS不支持并發(fā)追加和集群快照，早期HDFS的NameNode（即Master）沒原生HA功能?？傊琀DFS基本可以認為是GFS的簡化版，由于時間及應用場景等各方面的原因?qū)FS的功能做了一定的簡化，大大降低了復雜度。2.

16、5 HLFS（主要參考：HLFS（HDFS Log-structured File System）是一個開源分布式塊存儲系統(tǒng)，其最大特色是結(jié)合了LFS和HDFS。HDFS提供了可靠、隨時可擴展的文件服務，而HLFS通過Log-structured技術(shù)彌補了HDFS不能隨機更新的缺憾。在HLFS中，虛擬磁盤對應一個文件， 文件長度能夠超過TB級別，客戶端支持Linux和Xen，其中Linux基于NBD實現(xiàn)，Xen基于blktap2實現(xiàn)，客戶端通過類POSIX接口libHLFS與服務端通訊。HLFS主要特性包括多副本、動態(tài)擴容、故障透明處理和快照。HLFS性能較低。首先，非原地更新必然導致數(shù)據(jù)塊在

17、物理上非連續(xù)存放，因此讀I/O比較隨機，順序讀性能下降。其次，雖然從單個文件角度看來，寫I/O是順序的，但是在HDFS的Chunk Server服務了多個HLFS文件，因此從它的角度來看，I/O仍然是隨機的。第三，寫延遲問題，HDFS面向大文件設計，小文件寫延時不夠優(yōu)化。第四，垃圾回收的影響，垃圾回收需要讀取和寫入大量數(shù)據(jù)，對正常寫操作造成較大影響。此外，按照目前實現(xiàn)，相同段上的垃圾回收和讀寫請求不能并發(fā)，垃圾回收算法對正常操作的干擾較大。2.6 iSCSI、FCoE、AoE、NBDiSCSI、FCoE、AoE、NBD等都是用來支持通過網(wǎng)絡訪問塊設備的協(xié)議，它們都采用C/S架構(gòu)，無法直接支持分

18、布式塊存儲系統(tǒng)。Ursa的設計與實現(xiàn)分布式塊存儲系統(tǒng)給虛擬機提供的是虛擬硬盤服務，因而有如下設計目標：· 大文件存儲：虛擬硬盤實際通常GB級別以上，小于1GB是罕見情況· 需要支持隨機讀寫訪問，不需支持追加寫，需要支持resize· 通常情況下，文件由一個進程獨占讀寫訪問；數(shù)據(jù)塊可被共享只讀訪問· 高可靠，高可用：任意兩個服務器同時出現(xiàn)故障不影響數(shù)據(jù)的可靠性和可用性· 能發(fā)揮出新型硬件的性能優(yōu)勢，如萬兆網(wǎng)絡、SSD· 由于應用需求未知，同時需要優(yōu)化吞吐率和IOPS· 高效率：降低資源消耗，就降低了成本除了上述源于虛擬硬盤的直

19、接需求意外，分布式塊存儲還需要支持下列功能：· 快照：可給一個文件在不同時刻建立多個獨立的快照· 克隆：可將一個文件或快照在邏輯上復制成獨立的多份· 精簡配置（thin-provisioning）：只有存儲數(shù)據(jù)的部分才真正占用空間3.1 系統(tǒng)架構(gòu)分布式存儲系統(tǒng)總體架構(gòu)可以分為有master（元數(shù)據(jù)服務器）和無master兩大類。有master架構(gòu)在技術(shù)上較為簡單清晰，但存在單點失效以及潛在的性能瓶頸問題；無master架構(gòu)可以消除單點失效和性能瓶頸問題，然而在技術(shù)上卻較為復雜，并且在數(shù)據(jù)布局方面具有較多局限性。塊存儲系統(tǒng)對master的壓力不大，同時master的

20、單點故障問題可采用一些現(xiàn)有成熟技術(shù)解決，因而美團EBS的總體架構(gòu)使用有master的類型。這一架構(gòu)與GFS、HDFS、MooseFS等系統(tǒng)的架構(gòu)屬于同一類型。如圖1所示，美團EBS系統(tǒng)包括M、S和C三個部分，分別代表Master、Chunk Server和Client。Master中記錄的元數(shù)據(jù)包括3種：(1)關(guān)于volume的信息，如類型、大小、創(chuàng)建時間、包含哪些數(shù)據(jù)chunk等等；(2)關(guān)于chunk的信息，如大小、創(chuàng)建時間、所在位置等；(3)關(guān)于Chunk Server的信息，如IP地址、端口、數(shù)據(jù)存儲量、I/O負載、空間剩余量等。這3種信息當中，關(guān)于volume的信息是持久化保存的，其

21、余兩種均為暫存信息，通過Chunk Server上報。在元數(shù)據(jù)中，關(guān)于volume的信息非常重要，必須持久化保存；關(guān)于chunk的信息和Chunk Server的信息是時變的，并且是由Chunk Server上報的，因而沒必要持久化保存。根據(jù)這樣的分析，我們將關(guān)于volume的信息保存在MySQL當中，其他元數(shù)據(jù)保存在Redis當中，余下的集群管理功能由Manager完成。Master = Manager + MySQL + Redis，其中MySQL使用雙機主從配置，Redis使用官方提供的標準cluster功能。3.2 CAP取舍C、A、P分別代表Consistency、Availabil

22、ity和Partition-tolerance。分布式系統(tǒng)很難同時在這三個方面做到很高的保障，通常要在仔細分析應用需求的基礎(chǔ)之上對CAP做出取舍。塊存儲系統(tǒng)主要用于提供云硬盤服務，每塊云硬盤通常只會掛載到1臺VM之上，不存在多機器并發(fā)讀寫的情況，因而其典型應用場景對一致性的需求較低。針對這一特性，我們可以在設計上舍C而取AP。對于多機并行訪問云硬盤的使用模式，若數(shù)據(jù)是只讀的則無需額外處理；若數(shù)據(jù)有寫有讀，甚至是多寫多讀，則需要在上層引入分布式鎖，來確保數(shù)據(jù)一致性和完整性。這種使用模式在SAN領(lǐng)域并不少見，其典型應用場景是多機同時掛載一個網(wǎng)絡硬盤，并通過集群文件系統(tǒng)（而不是常見的單機文件系統(tǒng)）來

23、協(xié)調(diào)訪問存儲空間。集群文件系統(tǒng)內(nèi)部會使用分布式鎖來確保數(shù)據(jù)操作的正確性，所以我們舍C的設計決策不會影響多機并行訪問的使用模式。3.3 并發(fā)模型并發(fā)（不是并行！）模型的選擇和設計無法作為實現(xiàn)細節(jié)隱藏在局部，它會影響到程序代碼的各個部分，從底層到上層。基本的并發(fā)模型只有這樣幾種：事件驅(qū)動、多線程、多進程以及較為小眾的多協(xié)程。事件驅(qū)動模型是一種更接近硬件工作模式的并發(fā)模型，具有更高的執(zhí)行效率，是高性能網(wǎng)絡服務的普遍選擇。為能充分發(fā)揮萬兆網(wǎng)絡和SSD的性能潛力，我們必須利用多核心并行服務，因而需要選用多線程或者多進程模型。由于多進程模型更加簡單，進程天然是故障傳播的屏障，這兩方面都十分有利于提高軟件的

24、健壯性；并且我們也很容易對業(yè)務進行橫向拆分，做到互相沒有依賴，也不需要交互，所以我們選擇了多進程模型，與事件驅(qū)動一起構(gòu)成混合模型。協(xié)程在現(xiàn)實中的應用并不多，很多語言/開發(fā)生態(tài)甚至不支持協(xié)程，然而協(xié)程在一些特定領(lǐng)域其實具有更好的適用性。比如，QEMU/KVM在磁盤I/O方面的并發(fā)執(zhí)行完全是由協(xié)程負責的，即便某些block driver只提供了事件驅(qū)動的接口（如Ceph RBD），QEMU/KVM也會自動把它們轉(zhuǎn)化封裝成多協(xié)程模式。實踐表明，在并發(fā)I/O領(lǐng)域，多協(xié)程模型可以同時在性能和易用性方面取得非常好的效果，所以我們做了跟QEMU/KVM類似的選擇在底層將事件驅(qū)動模型轉(zhuǎn)換成了多協(xié)程模型，最終形

25、成了“多進程+多協(xié)程+事件驅(qū)動”的混合并發(fā)模型。3.4 存儲結(jié)構(gòu)如圖所示，Ursa中的存儲結(jié)構(gòu)與GFS/HDFS相似，存儲卷由64MB（可配置）大小的chunk組成。Ursa系統(tǒng)中的數(shù)據(jù)復制、故障檢測與修復均在chunk層次進行。系統(tǒng)中，每3個（可配置）chunk組成一組，互為備份。每2個chunk組構(gòu)成一個stripe組，實現(xiàn)條帶化交錯讀寫，提高單客戶端順序讀寫性能。Ursa在I/O棧上層添加Cache模塊，可將最常用的數(shù)據(jù)緩存在客戶端本地的SSD介質(zhì)當中，當訪問命中緩存時可大大提高性能。3.5 寫入策略最常見的寫入策略有兩種：(1)客戶端直接寫多個副本到各個Chunk Server，如圖(

26、a)所示，Sheepdog采用此種辦法；(2)客戶端寫第一個副本，并將寫請求依次傳遞下去，如圖(b)所示。這兩種方法各有利弊：前者通常具有較小的寫入延遲，但吞吐率最高只能達到網(wǎng)絡帶寬的1/3；后者的吞吐率可以達到100%網(wǎng)絡帶寬，卻具有較高的寫入延遲。由于Ursa可能用于支持各種類型的應用，必須同時面向吞吐率和帶寬進行優(yōu)化，所以我們設計采用了一種分叉式的寫入策略：如圖(c)所示，客戶端使用WRITE_REPLICATE請求求將數(shù)據(jù)寫到第一個副本，稱為primary，然后由primary負責將數(shù)據(jù)分別寫到其他副本。這樣Ursa可以在吞吐率和延遲兩方面取得較好的均衡。為確保數(shù)據(jù)可靠性，寫操作會等所

27、有副本的寫操作都完成之后才能返回。3.6 無狀態(tài)服務Chunk Server內(nèi)部幾乎不保存狀態(tài)，通常情況下各個請求之間是完全獨立執(zhí)行的，并且重啟Chunk Server不會影響后續(xù)請求的執(zhí)行。這樣的Chunk Server不但具有更高的魯棒性，而且具有更高的擴展性。許多其他網(wǎng)絡服務、協(xié)議的設計都遵循了無狀態(tài)的原則。3.7 模塊如下圖所示，Ursa中的I/O功能模塊的組織采用decorator模式，即所有模塊都實現(xiàn)了IStore抽象接口，其中負責直接與Chunk Server通信的模塊屬于decorator模式中的concrete component，其余模塊均為concrete decorator。所有的decorator都保存數(shù)量不等的指向其他模塊的指針（IStore指針）。在運行時，Ursa的I/O棧層次結(jié)構(gòu)的對象圖如下所示。3.8 產(chǎn)品界面性能實測如下圖所示，測試環(huán)境由萬兆以太網(wǎng)、1臺Client和3臺Chunk Server組成，