深入分析美團(tuán)的Ursa分布式存儲(chǔ)系統(tǒng)

1.Ursa

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

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

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

分布式塊存儲(chǔ)相關(guān)項(xiàng)目與技術(shù)

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

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

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

Ceph性能測試

測試版本：0.81
操作系統(tǒng)：CentOS 6.x
測試工具：fio
服務(wù)器配置：
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)
服務(wù)器數(shù)量：4，其中一個(gè)為兼職客戶端
注意：由于客戶端位于一個(gè)存儲(chǔ)服務(wù)器上，所以有1/4的吞吐率不經(jīng)過網(wǎng)卡。

測試結(jié)果如下：

讀IOPS：16 407（此時(shí)客戶端CPU占用率超過500%，5臺(tái)服務(wù)器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)絡(luò)ping值：0.1324ms
本地硬盤順序讀寫延遲：0.03332ms (29 126 IOPS)
從測試來看，Ceph的讀吞吐率正常，然而寫吞吐率不足讀的1/3，性能偏低；讀寫延遲比顯著大于網(wǎng)絡(luò)延遲與磁盤I/O延遲之和；CPU占用率過高。

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

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

Sheepdog采用無中心節(jié)點(diǎn)的全對稱架構(gòu)，基于一致性哈希實(shí)現(xiàn)從ObjectID到存儲(chǔ)節(jié)點(diǎn)的定位：每個(gè)節(jié)點(diǎn)劃分成多個(gè)虛擬節(jié)點(diǎn)，虛擬節(jié)點(diǎn)和ObjectID一樣，采用64位整數(shù)唯一標(biāo)識(shí)，每個(gè)虛擬節(jié)點(diǎn)負(fù)責(zé)一段包含節(jié)點(diǎn)ID在內(nèi)的ObjectID區(qū)間。DataObject副本存在ObjectID對應(yīng)的虛擬節(jié)點(diǎn)，及在后續(xù)的幾個(gè)節(jié)點(diǎn)上。Sheepdog無單點(diǎn)故障問題，存儲(chǔ)容量和性能均可線性擴(kuò)展，新增節(jié)點(diǎn)通過簡單配置即可加入集群，并且Sheepdog自動(dòng)實(shí)現(xiàn)負(fù)載均衡，節(jié)點(diǎn)故障時(shí)可自動(dòng)發(fā)現(xiàn)并進(jìn)行副本修復(fù)，還直接支持QEMU/KVM。

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

Sheepdog的數(shù)據(jù)可靠性問題

我們對Sheepdog開展了可靠性、可用性測試。在測試中有共3臺(tái)服務(wù)器，每臺(tái)配有6個(gè)機(jī)械硬盤，配置好Sheepdog之后，每臺(tái)服務(wù)器啟動(dòng)10個(gè)VM，每個(gè)VM內(nèi)無限循環(huán)運(yùn)行fio分別執(zhí)行小塊隨機(jī)讀、寫和大塊順序讀、寫的測試。

在執(zhí)行壓力測試一周后，對集群中的全部數(shù)據(jù)進(jìn)行一致性檢測（collie cluster check），發(fā)現(xiàn)有些數(shù)據(jù)塊副本與另外2個(gè)不一致（“fixed replica ...”），有些數(shù)據(jù)塊的3個(gè)各不相同（“no majority of ...”）：

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

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

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

MooseFS基于FUSE提供POSIX語義支持，已有應(yīng)用可以不經(jīng)修改直接遷移到MooseFS之上，這給應(yīng)用帶來極大的便利。然而FUSE也帶來了一些負(fù)面作用，比如POSIX語義對于塊存儲(chǔ)來說并不需要，F(xiàn)USE會(huì)帶來額外開銷等等。

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

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

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

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

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

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

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

3.Ursa的設(shè)計(jì)與實(shí)現(xiàn)
分布式塊存儲(chǔ)系統(tǒng)給虛擬機(jī)提供的是虛擬硬盤服務(wù)，因而有如下設(shè)計(jì)目標(biāo)：

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

快照：可給一個(gè)文件在不同時(shí)刻建立多個(gè)獨(dú)立的快照
克?。嚎蓪⒁粋€(gè)文件或快照在邏輯上復(fù)制成獨(dú)立的多份
精簡配置（thin-provisioning）：只有存儲(chǔ)數(shù)據(jù)的部分才真正占用空間

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

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

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

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

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

對于多機(jī)并行訪問云硬盤的使用模式，若數(shù)據(jù)是只讀的則無需額外處理；若數(shù)據(jù)有寫有讀，甚至是多寫多讀，則需要在上層引入分布式鎖，來確保數(shù)據(jù)一致性和完整性。這種使用模式在SAN領(lǐng)域并不少見，其典型應(yīng)用場景是多機(jī)同時(shí)掛載一個(gè)網(wǎng)絡(luò)硬盤，并通過集群文件系統(tǒng)（而不是常見的單機(jī)文件系統(tǒng)）來協(xié)調(diào)訪問存儲(chǔ)空間。集群文件系統(tǒng)內(nèi)部會(huì)使用分布式鎖來確保數(shù)據(jù)操作的正確性，所以我們舍C的設(shè)計(jì)決策不會(huì)影響多機(jī)并行訪問的使用模式。

3.3 并發(fā)模型
并發(fā)（不是并行！）模型的選擇和設(shè)計(jì)無法作為實(shí)現(xiàn)細(xì)節(jié)隱藏在局部，它會(huì)影響到程序代碼的各個(gè)部分，從底層到上層。基本的并發(fā)模型只有這樣幾種：事件驅(qū)動(dòng)、多線程、多進(jìn)程以及較為小眾的多協(xié)程。

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

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

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

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

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

3.6 無狀態(tài)服務(wù)
Chunk Server內(nèi)部幾乎不保存狀態(tài)，通常情況下各個(gè)請求之間是完全獨(dú)立執(zhí)行的，并且重啟Chunk Server不會(huì)影響后續(xù)請求的執(zhí)行。這樣的Chunk Server不但具有更高的魯棒性，而且具有更高的擴(kuò)展性。許多其他網(wǎng)絡(luò)服務(wù)、協(xié)議的設(shè)計(jì)都遵循了無狀態(tài)的原則。

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

在運(yùn)行時(shí)，Ursa的I/O棧層次結(jié)構(gòu)的對象圖如下所示。

3.8 產(chǎn)品界面

4.性能實(shí)測

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

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

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

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

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

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

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