1.Ursa

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

云硬盤的底層通常是分布式塊存儲系統，目前開源領域有一些此類項目，如Ceph RBD、Sheepdog。另外MooseFS和GlusterFS雖然叫做文件系統，但由于其特性與塊存儲系統接近，也能用于支持云硬盤。我們在測評中發現，這些開源項目均存在一些問題，使得它們都難以直接應用在大規模的生產系統當中。例如Ceph RBD的效率較低（CPU使用過高）；Sheepdog在壓力測試中出現了數據丟失的現象；MooseFS的POSIX語義支持、基于FUSE的架構、不完全開源的2.0版本等問題給它自身帶來了許多的局限性；GlusterFS與Ceph同屬紅帽收購的開源存儲系統，主要用于scale-out文件存儲場景，在云計算領域使用不多。此外，這些存儲系統都難以充發揮用萬兆網卡和SSD的性能潛力，難以在未來承擔重任。

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

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

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

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

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

Ceph性能測試

測試版本：0.81
操作系統：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)
服務器數量：4，其中一個為兼職客戶端
注意：由于客戶端位于一個存儲服務器上，所以有1/4的吞吐率不經過網卡。

測試結果如下：

讀IOPS：16 407（此時客戶端CPU占用率超過500%，5臺服務器CPU總使用率接近500%）
寫IOPS：941
順序讀吞吐率：218 859 KB/s
順序寫吞吐率：67 242 KB/s
順序讀延遲：1.6ms (664 IOPS)
順序寫延遲：4.4ms (225 IOPS)
網絡ping值：0.1324ms
本地硬盤順序讀寫延遲：0.03332ms (29 126 IOPS)
從測試來看，Ceph的讀吞吐率正常，然而寫吞吐率不足讀的1/3，性能偏低；讀寫延遲比顯著大于網絡延遲與磁盤I/O延遲之和；CPU占用率過高。

2.2 Sheepdog
（主要參考：http://peterylh.blog.163.com/blog/static/12033201221594937257/）

Sheepdog是由日本NTT實驗室的Morita Kazutaka專為虛擬化平臺創立的分布式塊存儲開源項目, 于2009年開源[1]。從2011年9月開始, 一些淘寶的工程師加入了Sheepdog項目，以及相關開源項目比如Corosync、Accord的開發。Sheepdog主要由兩部分組成：集群管理和存儲服務，其中集群管理目前使用Corosync或者Zookper來完成，存儲服務是全新實現的。

Sheepdog采用無中心節點的全對稱架構，基于一致性哈希實現從ObjectID到存儲節點的定位：每個節點劃分成多個虛擬節點，虛擬節點和ObjectID一樣，采用64位整數唯一標識，每個虛擬節點負責一段包含節點ID在內的ObjectID區間。DataObject副本存在ObjectID對應的虛擬節點，及在后續的幾個節點上。Sheepdog無單點故障問題，存儲容量和性能均可線性擴展，新增節點通過簡單配置即可加入集群，并且Sheepdog自動實現負載均衡，節點故障時可自動發現并進行副本修復，還直接支持QEMU/KVM。

Sheepdog的服務進程既承擔數據服務的職責，同時也是客戶端（QEMU）訪問數據的gateway。QEMU的Sheepdog driver將對volume的請求轉換成為對object的請求，然后通過UNIX domain socket或者TCP socket連接一個Sheepdog服務進程，并將訪問請求發給該進程來完成后續步驟。Sheepdog的服務進程還可以開啟數據緩存功能，以減少網絡I/O。Sheepdog的I/O路徑是“client<->gateway<->object manager(s)”，讀操作可以在任意副本完成，更新操作并行的發往所有副本， 當所有副本都更新成功之后，gateway才告訴客戶端更新操作成功。

Sheepdog的數據可靠性問題

我們對Sheepdog開展了可靠性、可用性測試。在測試中有共3臺服務器，每臺配有6個機械硬盤，配置好Sheepdog之后，每臺服務器啟動10個VM，每個VM內無限循環運行fio分別執行小塊隨機讀、寫和大塊順序讀、寫的測試。

在執行壓力測試一周后，對集群中的全部數據進行一致性檢測（collie cluster check），發現有些數據塊副本與另外2個不一致（“fixed replica ...”），有些數據塊的3個各不相同（“no majority of ...”）：
 

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

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

管理服務器Master：類似于GFS的Master，主要有兩個功能：(1）存儲文件和目錄元數據，文件元數據包括文件大小、屬性、對應的Chunk等；(2）管理集群成員關系和Chunk元數據信息，包括Chunk存儲、版本、Lease等。
元數據備份服務器Metalogger Server：根據元數據文件和log實時備份Master元數據。
存儲服務器Chunk Server：負責存儲Chunk，提供Chunk讀寫能力。Chunk文件默認為64MB大小。
客戶端Client：以FUSE方式掛到本地文件系統，實現標準文件系統接口。
MooseFS本地不會緩存Chunk信息， 每次讀寫操作都會訪問Master， Master的壓力較大。此外MooseFS寫操作流程較長且開銷較高。MooseFS支持快照，但是以整個Chunk為單位進行CoW(Copy-on-Write)，可能造成響應時間惡化，補救辦法是以犧牲系統規模為代價，降低Chunk大小。

MooseFS基于FUSE提供POSIX語義支持，已有應用可以不經修改直接遷移到MooseFS之上，這給應用帶來極大的便利。然而FUSE也帶來了一些負面作用，比如POSIX語義對于塊存儲來說并不需要，FUSE會帶來額外開銷等等。

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

HDFS基本可以認為是GFS的一個簡化開源實現，二者因此有很多相似之處。首先，GFS和HDFS都采用單一主控機+多臺工作機的模式，由一臺主控機(Master)存儲系統全部元數據，并實現數據的分布、復制、備份決策，主控機還實現了元數據的checkpoint和操作日志記錄及回放功能。工作機存儲數據，并根據主控機的指令進行數據存儲、數據遷移和數據計算等。其次，GFS和HDFS都通過數據分塊和復制（多副本，一般是3）來提供更高的可靠性和更高的性能。當其中一個副本不可用時，系統都提供副本自動復制功能。同時，針對數據讀多于寫的特點，讀服務被分配到多個副本所在機器，提供了系統的整體性能。最后，GFS和HDFS都提供了一個樹結構的文件系統，實現了類似與Linux下的文件復制、改名、移動、創建、刪除操作以及簡單的權限管理等。

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

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

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

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

2.6 iSCSI、FCoE、AoE、NBD
iSCSI、FCoE、AoE、NBD等都是用來支持通過網絡訪問塊設備的協議，它們都采用C/S架構，無法直接支持分布式塊存儲系統。

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

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

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

3.1 系統架構
分布式存儲系統總體架構可以分為有master（元數據服務器）和無master兩大類。有master架構在技術上較為簡單清晰，但存在單點失效以及潛在的性能瓶頸問題；無master架構可以消除單點失效和性能瓶頸問題，然而在技術上卻較為復雜，并且在數據布局方面具有較多局限性。塊存儲系統對master的壓力不大，同時master的單點故障問題可采用一些現有成熟技術解決，因而美團EBS的總體架構使用有master的類型。這一架構與GFS、HDFS、MooseFS等系統的架構屬于同一類型。

如圖1所示，美團EBS系統包括M、S和C三個部分，分別代表Master、Chunk Server和Client。Master中記錄的元數據包括3種：(1)關于volume的信息，如類型、大小、創建時間、包含哪些數據chunk等等；(2)關于chunk的信息，如大小、創建時間、所在位置等；(3)關于Chunk Server的信息，如IP地址、端口、數據存儲量、I/O負載、空間剩余量等。這3種信息當中，關于volume的信息是持久化保存的，其余兩種均為暫存信息，通過Chunk Server上報。

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

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

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

對于多機并行訪問云硬盤的使用模式，若數據是只讀的則無需額外處理；若數據有寫有讀，甚至是多寫多讀，則需要在上層引入分布式鎖，來確保數據一致性和完整性。這種使用模式在SAN領域并不少見，其典型應用場景是多機同時掛載一個網絡硬盤，并通過集群文件系統（而不是常見的單機文件系統）來協調訪問存儲空間。集群文件系統內部會使用分布式鎖來確保數據操作的正確性，所以我們舍C的設計決策不會影響多機并行訪問的使用模式。

3.3 并發模型
并發（不是并行！）模型的選擇和設計無法作為實現細節隱藏在局部，它會影響到程序代碼的各個部分，從底層到上層。基本的并發模型只有這樣幾種：事件驅動、多線程、多進程以及較為小眾的多協程。

事件驅動模型是一種更接近硬件工作模式的并發模型，具有更高的執行效率，是高性能網絡服務的普遍選擇。為能充分發揮萬兆網絡和SSD的性能潛力，我們必須利用多核心并行服務，因而需要選用多線程或者多進程模型。由于多進程模型更加簡單，進程天然是故障傳播的屏障，這兩方面都十分有利于提高軟件的健壯性；并且我們也很容易對業務進行橫向拆分，做到互相沒有依賴，也不需要交互，所以我們選擇了多進程模型，與事件驅動一起構成混合模型。

協程在現實中的應用并不多，很多語言/開發生態甚至不支持協程，然而協程在一些特定領域其實具有更好的適用性。比如，QEMU/KVM在磁盤I/O方面的并發執行完全是由協程負責的，即便某些block driver只提供了事件驅動的接口（如Ceph RBD），QEMU/KVM也會自動把它們轉化封裝成多協程模式。實踐表明，在并發I/O領域，多協程模型可以同時在性能和易用性方面取得非常好的效果，所以我們做了跟QEMU/KVM類似的選擇——在底層將事件驅動模型轉換成了多協程模型，最終形成了“多進程+多協程+事件驅動”的混合并發模型。

3.4 存儲結構
如圖所示，Ursa中的存儲結構與GFS/HDFS相似，存儲卷由64MB（可配置）大小的chunk組成。Ursa系統中的數據復制、故障檢測與修復均在chunk層次進行。系統中，每3個（可配置）chunk組成一組，互為備份。每2個chunk組構成一個stripe組，實現條帶化交錯讀寫，提高單客戶端順序讀寫性能。Ursa在I/O棧上層添加Cache模塊，可將最常用的數據緩存在客戶端本地的SSD介質當中，當訪問命中緩存時可大大提高性能。

3.5 寫入策略
最常見的寫入策略有兩種：(1)客戶端直接寫多個副本到各個Chunk Server，如圖(a)所示，Sheepdog采用此種辦法；(2)客戶端寫第一個副本，并將寫請求依次傳遞下去，如圖(b)所示。這兩種方法各有利弊：前者通常具有較小的寫入延遲，但吞吐率最高只能達到網絡帶寬的1/3；后者的吞吐率可以達到100%網絡帶寬，卻具有較高的寫入延遲。

由于Ursa可能用于支持各種類型的應用，必須同時面向吞吐率和帶寬進行優化，所以我們設計采用了一種分叉式的寫入策略：如圖(c)所示，客戶端使用WRITE_REPLICATE請求求將數據寫到第一個副本，稱為primary，然后由primary負責將數據分別寫到其他副本。這樣Ursa可以在吞吐率和延遲兩方面取得較好的均衡。為確保數據可靠性，寫操作會等所有副本的寫操作都完成之后才能返回。

3.6 無狀態服務
Chunk Server內部幾乎不保存狀態，通常情況下各個請求之間是完全獨立執行的，并且重啟Chunk Server不會影響后續請求的執行。這樣的Chunk Server不但具有更高的魯棒性，而且具有更高的擴展性。許多其他網絡服務、協議的設計都遵循了無狀態的原則。

3.7 模塊
如下圖所示，Ursa中的I/O功能模塊的組織采用decorator模式，即所有模塊都實現了IStore抽象接口，其中負責直接與Chunk Server通信的模塊屬于decorator模式中的concrete component，其余模塊均為concrete decorator。所有的decorator都保存數量不等的指向其他模塊的指針（IStore指針）。

在運行時，Ursa的I/O棧層次結構的對象圖如下所示。

3.8 產品界面

4.性能實測

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

測試環境的網絡延遲如下：

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

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

作為對比，我們在測試Ceph的過程中監測到服務端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倍。

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