1.Ursa

云硬盤對IaaS云計算平臺有至關重要的作用，幾乎已成為必備組件，如亞馬遜的EBS(Elastic Block Store)、阿里云的盤古、OpenStack中的Cinder等。云硬盤可為云計算平臺帶來許多優(yōu)良特性，如更高的數(shù)據(jù)可靠性和可用性、靈活的數(shù)據(jù)快照功能、更好的虛擬機動態(tài)遷移支持、更短的主機故障恢復時間等等。隨著萬兆以太網(wǎng)逐漸普及，云硬盤的各項優(yōu)勢得到加強和凸顯，其必要性變得十分強烈。

云硬盤的底層通常是分布式塊存儲系統(tǒng)，目前開源領域有一些此類項目，如Ceph RBD、Sheepdog。另外MooseFS和GlusterFS雖然叫做文件系統(tǒng)，但由于其特性與塊存儲系統(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文件存儲場景，在云計算領域使用不多。此外，這些存儲系統(tǒng)都難以充發(fā)揮用萬兆網(wǎng)卡和SSD的性能潛力，難以在未來承擔重任。

由于以上原因，美團云研發(fā)了全新的分布式塊存儲系統(tǒng)Ursa，通過簡單穩(wěn)固的系統(tǒng)架構(gòu)、高效的代碼實現(xiàn)以及對各種非典型場景的仔細考慮，實現(xiàn)了高可靠、高可用、高性能、低開銷、可擴展、易運維、易維護等等目標。Ursa的名字源于DotA中的熊戰(zhàn)士，他具有極高的攻擊速度、攻擊力和生命值，分別隱喻存儲系統(tǒng)中的IOPS、吞吐率和穩(wěn)定性。

分布式塊存儲相關項目與技術

2.1 Ceph
（主要參考：https://www.ustack.com/blog/ceph_infra/）

Ceph項目起源于其創(chuàng)始人Sage Weil在加州大學Santa Cruz分校攻讀博士期間的研究課題。項目的起始時間為2004年。在2006年的OSDI學術會議上，Sage發(fā)表了關于Ceph的論文，并提供了項目的下載鏈接，由此開始廣為人知。2010年Ceph客戶端部分代碼正式進入Linux kernel 2.6.34。

Ceph同時提供對象、塊和文件這三個層次的分布式存儲服務，其中只有塊層存儲與我們相關。由于塊存儲在IaaS云計算系統(tǒng)中占有重要地位，Ceph在近些年的關注度得到顯著提高。許多云計算系統(tǒng)實例基于Ceph提供塊存儲服務，如UnitedStack、Mirantis OpenStack等。

Ceph性能測試

測試版本：0.81
操作系統(tǒng)：CentOS 6.x
測試工具：fio
服務器配置：
CPU: Intel Xeon E5-2650v2 @ 2.6GHz
RAM: 96GB
NIC: 10 GbE
HDD: 6 NL SAS, 7200 RPM
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)
順序?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
（主要參考：http://peterylh.blog.163.com/blog/static/12033201221594937257/）

Sheepdog是由日本NTT實驗室的Morita Kazutaka專為虛擬化平臺創(chuàng)立的分布式塊存儲開源項目, 于2009年開源[1]。從2011年9月開始, 一些淘寶的工程師加入了Sheepdog項目，以及相關開源項目比如Corosync、Accord的開發(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é)點故障時可自動發(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)”，讀操作可以在任意副本完成，更新操作并行的發(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 ...”）：
 

2.3 MooseFS
（主要參考：http://peterylh.blog.163.com/blog/static/12033201251791139592/）

MooseFS是容錯的分布式文件系統(tǒng)，通過FUSE支持標準POSIX文件系統(tǒng)接口。 MooseFS的架構(gòu)類似于GFS，由四個部分組成：

管理服務器Master：類似于GFS的Master，主要有兩個功能：(1）存儲文件和目錄元數(shù)據(jù)，文件元數(shù)據(jù)包括文件大小、屬性、對應的Chunk等；(2）管理集群成員關系和Chunk元數(shù)據(jù)信息，包括Chunk存儲、版本、Lease等。
元數(shù)據(jù)備份服務器Metalogger Server：根據(jù)元數(shù)據(jù)文件和log實時備份Master元數(shù)據(jù)。
存儲服務器Chunk 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之上，這給應用帶來極大的便利。然而FUSE也帶來了一些負面作用，比如POSIX語義對于塊存儲來說并不需要，F(xiàn)USE會帶來額外開銷等等。

2.4 GFS/HDFS
（主要參考：http://www.nosqlnotes.net/archives/119）

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）來提供更高的可靠性和更高的性能。當其中一個副本不可用時，系統(tǒng)都提供副本自動復制功能。同時，針對數(shù)據(jù)讀多于寫的特點，讀服務被分配到多個副本所在機器，提供了系統(tǒng)的整體性能。最后，GFS和HDFS都提供了一個樹結(jié)構(gòu)的文件系統(tǒng)，實現(xiàn)了類似與Linux下的文件復制、改名、移動、創(chuàng)建、刪除操作以及簡單的權限管理等。

然而，GFS和HDFS在關鍵點的設計上差異很大，HDFS為了規(guī)避GFS的復雜度進行了很多簡化。例如HDFS不支持并發(fā)追加和集群快照，早期HDFS的NameNode（即Master）沒原生HA功能。總之，HDFS基本可以認為是GFS的簡化版，由于時間及應用場景等各方面的原因?qū)FS的功能做了一定的簡化，大大降低了復雜度。

2.5 HLFS
（主要參考：http://peterylh.blog.163.com/blog/static/120332012226104116710/）

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

HLFS性能較低。首先，非原地更新必然導致數(shù)據(jù)塊在物理上非連續(xù)存放，因此讀I/O比較隨機，順序讀性能下降。其次，雖然從單個文件角度看來，寫I/O是順序的，但是在HDFS的Chunk Server服務了多個HLFS文件，因此從它的角度來看，I/O仍然是隨機的。第三，寫延遲問題，HDFS面向大文件設計，小文件寫延時不夠優(yōu)化。第四，垃圾回收的影響，垃圾回收需要讀取和寫入大量數(shù)據(jù)，對正常寫操作造成較大影響。此外，按照目前實現(xiàn)，相同段上的垃圾回收和讀寫請求不能并發(fā)，垃圾回收算法對正常操作的干擾較大。

2.6 iSCSI、FCoE、AoE、NBD
iSCSI、FCoE、AoE、NBD等都是用來支持通過網(wǎng)絡訪問塊設備的協(xié)議，它們都采用C/S架構(gòu)，無法直接支持分布式塊存儲系統(tǒng)。

3.Ursa的設計與實現(xiàn)
分布式塊存儲系統(tǒng)給虛擬機提供的是虛擬硬盤服務，因而有如下設計目標：

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

快照：可給一個文件在不同時刻建立多個獨立的快照
克隆：可將一個文件或快照在邏輯上復制成獨立的多份
精簡配置（thin-provisioning）：只有存儲數(shù)據(jù)的部分才真正占用空間

3.1 系統(tǒng)架構(gòu)
分布式存儲系統(tǒng)總體架構(gòu)可以分為有master（元數(shù)據(jù)服務器）和無master兩大類。有master架構(gòu)在技術上較為簡單清晰，但存在單點失效以及潛在的性能瓶頸問題；無master架構(gòu)可以消除單點失效和性能瓶頸問題，然而在技術上卻較為復雜，并且在數(shù)據(jù)布局方面具有較多局限性。塊存儲系統(tǒng)對master的壓力不大，同時master的單點故障問題可采用一些現(xiàn)有成熟技術解決，因而美團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)關于volume的信息，如類型、大小、創(chuàng)建時間、包含哪些數(shù)據(jù)chunk等等；(2)關于chunk的信息，如大小、創(chuàng)建時間、所在位置等；(3)關于Chunk Server的信息，如IP地址、端口、數(shù)據(jù)存儲量、I/O負載、空間剩余量等。這3種信息當中，關于volume的信息是持久化保存的，其余兩種均為暫存信息，通過Chunk Server上報。

在元數(shù)據(jù)中，關于volume的信息非常重要，必須持久化保存；關于chunk的信息和Chunk Server的信息是時變的，并且是由Chunk Server上報的，因而沒必要持久化保存。根據(jù)這樣的分析，我們將關于volume的信息保存在MySQL當中，其他元數(shù)據(jù)保存在Redis當中，余下的集群管理功能由Manager完成。Master == Manager + MySQL + Redis，其中MySQL使用雙機主從配置，Redis使用官方提供的標準cluster功能。

3.2 CAP取舍
C、A、P分別代表Consistency、Availability和Partition-tolerance。分布式系統(tǒng)很難同時在這三個方面做到很高的保障，通常要在仔細分析應用需求的基礎之上對CAP做出取舍。

塊存儲系統(tǒng)主要用于提供云硬盤服務，每塊云硬盤通常只會掛載到1臺VM之上，不存在多機器并發(fā)讀寫的情況，因而其典型應用場景對一致性的需求較低。針對這一特性，我們可以在設計上舍C而取AP。

對于多機并行訪問云硬盤的使用模式，若數(shù)據(jù)是只讀的則無需額外處理；若數(shù)據(jù)有寫有讀，甚至是多寫多讀，則需要在上層引入分布式鎖，來確保數(shù)據(jù)一致性和完整性。這種使用模式在SAN領域并不少見，其典型應用場景是多機同時掛載一個網(wǎng)絡硬盤，并通過集群文件系統(tǒng)（而不是常見的單機文件系統(tǒng)）來協(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的性能潛力，我們必須利用多核心并行服務，因而需要選用多線程或者多進程模型。由于多進程模型更加簡單，進程天然是故障傳播的屏障，這兩方面都十分有利于提高軟件的健壯性；并且我們也很容易對業(yè)務進行橫向拆分，做到互相沒有依賴，也不需要交互，所以我們選擇了多進程模型，與事件驅(qū)動一起構(gòu)成混合模型。

協(xié)程在現(xiàn)實中的應用并不多，很多語言/開發(fā)生態(tài)甚至不支持協(xié)程，然而協(xié)程在一些特定領域其實具有更好的適用性。比如，QEMU/KVM在磁盤I/O方面的并發(fā)執(zhí)行完全是由協(xié)程負責的，即便某些block driver只提供了事件驅(qū)動的接口（如Ceph RBD），QEMU/KVM也會自動把它們轉(zhuǎn)化封裝成多協(xié)程模式。實踐表明，在并發(fā)I/O領域，多協(xié)程模型可以同時在性能和易用性方面取得非常好的效果，所以我們做了跟QEMU/KVM類似的選擇——在底層將事件驅(qū)動模型轉(zhuǎn)換成了多協(xié)程模型，最終形成了“多進程+多協(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，如圖(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ù)可靠性，寫操作會等所有副本的寫操作都完成之后才能返回。

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)品界面

4.性能實測

如下圖所示，測試環(huán)境由萬兆以太網(wǎng)、1臺Client和3臺Chunk Server組成，chunk文件存在tmpfs上，即所有寫操作不落盤，寫到內(nèi)存為止。選擇tmpfs主要是為了避免硬盤的I/O速度的局限性，以便測試Ursa在極限情況下的表現(xiàn)。

測試環(huán)境的網(wǎng)絡延遲如下：

在上述環(huán)境中，用fio分別測試了讀寫操作的吞吐率、IOPS以及I/O延遲，測試參數(shù)與結(jié)果如下：

從測試結(jié)果可以看出：
(1). Ursa在吞吐率測試中可以輕易接近網(wǎng)卡理論帶寬；
(2). Ursa的IOPS性能可以達到SSD的水準；
(3). Ursa的讀延遲接近ping值，寫操作需要寫3個副本，延遲比讀高68%。

作為對比，我們在測試Ceph的過程中監(jiān)測到服務端CPU占用情況如下：

此時機器上5個存儲服務進程ceph-osd共占用123.7%的CPU資源，提供了4 101的讀IOPS服務；而Ursa的服務進程只消耗了43%的CPU資源，提供了61 340讀IOPS服務，運行效率比Ceph高43倍。在客戶端方面，Ceph消耗了500%+的CPU資源，得到了16 407讀IOPS；而Ursa只消耗了96%的CPU資源，得到了61 340讀IOPS，運行效率比Ceph高21倍。

總結(jié)與展望
Ursa從零開始動手開發(fā)到內(nèi)部上線只經(jīng)歷了9個月的時間，雖然基本功能、性能都已達到預期，但仍有許多需要進一步開發(fā)的地方。一個重要的方向是對SSD的支持。雖然將HDD簡單替換為SSD，不修改Ursa的任何代碼、配置就可以運行，并取得性能上的顯著改善，然而SSD在性能、成本、壽命等方面與HDD差異巨大，Ursa必須做出針對性的優(yōu)化才能使SSD揚長避短。另一個重要方向是對大量VM同時啟動的更好的支持。如果同時有上百臺相同的VM從Ursa啟動（即系統(tǒng)盤放在Ursa上），會在短時間內(nèi)有大量讀請求訪問相同的數(shù)據(jù)集（啟動文件），形成局部熱點，此時相關的Chunk Server服務能力會出現(xiàn)不足，導致啟動變慢。由于各個VM所需的啟動數(shù)據(jù)基本相同，我們可以采用“一傳十，十傳百”的方式組織一個應用層組播樹overlay網(wǎng)絡來進行數(shù)據(jù)分發(fā)，這樣可以從容應對熱點數(shù)據(jù)訪問問題。隨著一步步的完善，相信Ursa將在云平臺的運營當中起到越來越重要的作用。