張滬濱，李小勇

?

面向QEMU的分布式塊存儲系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

張滬濱，李小勇

計(jì)算系統(tǒng)虛擬化是當(dāng)前的主流趨勢，然而為虛擬機(jī)磁盤提供存儲的現(xiàn)有后端系統(tǒng)常直接沿襲分布式文件系統(tǒng)的設(shè)計(jì)，導(dǎo)致一系列虛擬磁盤I/O場景下不必要的開銷。提出的COMET系統(tǒng)，是一個(gè)面向QEMU的分布式塊存儲系統(tǒng)。它基于Proactor模式，針對虛擬磁盤I/O特性揚(yáng)棄文件系統(tǒng)的語義并在數(shù)據(jù)讀寫與一致性等方面采用精簡合理的設(shè)計(jì)，盡可能縮短I/O路徑，在具備線性擴(kuò)展能力、高可用性的同時(shí)，實(shí)現(xiàn)了寫時(shí)復(fù)制的磁盤快照和寫時(shí)復(fù)制的磁盤克隆等創(chuàng)新功能。測試數(shù)據(jù)表明，COMET在部分I/O場景下?lián)碛凶阋枣敲滥酥脸匠墒扉_源系統(tǒng)的性能。

QEMU；塊存儲；分布式；快照；克隆

0 引言

虛擬化是云環(huán)境下服務(wù)器聚合和彈性資源管理的關(guān)鍵使能技術(shù)。近年來，諸如PLE、EPT、SR-IOV等新一代硬件加速技術(shù)的成功應(yīng)用和改進(jìn)[1]使虛擬機(jī)對CPU、內(nèi)存、網(wǎng)卡的訪問效率足以匹敵相同硬件環(huán)境下的物理機(jī)；而虛擬機(jī)磁盤I/O的性能，雖然借由virtio半虛擬化驅(qū)動[2]等技術(shù)在前端進(jìn)行了大量優(yōu)化，但仍隨后端存儲具體實(shí)現(xiàn)的不同，呈現(xiàn)出巨大的靈活性與提升空間。

目前，虛擬塊設(shè)備（VBDs）是為虛擬機(jī)提供塊存儲的主流解決方案[3,4]。該方案中，將虛擬磁盤作為一個(gè)抽象的文件存儲在DAS、SAN、NAS或提供塊設(shè)備接口的分布式文件系統(tǒng)中。然而，DAS不易擴(kuò)展，SAN的性能依賴于高價(jià)的Fibre-Channel協(xié)議專用硬件且擴(kuò)展性有限，NAS缺乏高可用配置容易形成單點(diǎn)故障且后期的擴(kuò)展成本高，它們都無法滿足云規(guī)模的IaaS服務(wù)場景。分布式文件系統(tǒng)的根本設(shè)計(jì)目的是面向文件，而非面向虛擬磁盤文件，使用分布式文件系統(tǒng)存儲虛擬磁盤文件并提供塊設(shè)備接口雖然充分利用了分布式文件系統(tǒng)本身的可擴(kuò)展性、高可用性等優(yōu)點(diǎn)，但也同時(shí)強(qiáng)制引入文件系統(tǒng)的諸多復(fù)雜語義，導(dǎo)致了虛擬磁盤I/O場景下的不必要開銷。例如，一般分布式文件系統(tǒng)中，用戶位于云運(yùn)營商管轄范圍之外。對于多用戶共享同一文件的場景，必須統(tǒng)一使用鎖或租約等同步機(jī)制；對于多用戶各自獨(dú)占文件的場景，必須結(jié)合元數(shù)據(jù)進(jìn)行相應(yīng)的訪問控制機(jī)制；對于一致性場景，也必須在站在多用戶的角度進(jìn)行復(fù)雜設(shè)計(jì)實(shí)現(xiàn)而產(chǎn)生較大的開銷……在虛擬磁盤I/O場景下，虛擬磁盤的直接用戶是位于云運(yùn)營商管轄范圍之內(nèi)的虛擬機(jī)，每個(gè)虛擬機(jī)對自身的磁盤獨(dú)占使用，互不干擾，相對于分布式文件系統(tǒng)，在提供的語義、鎖機(jī)制、元數(shù)據(jù)管理、一致性等諸多方面都能夠得到巨大的簡化。

基于此，本論文提出并實(shí)現(xiàn)專用于為IaaS虛擬機(jī)提供塊存儲的COMET分布式塊存儲系統(tǒng)。它提供針對虛擬磁盤I/O場景的最小化語義，避免了不必要的性能損耗。它基于無中心架構(gòu)，不會出現(xiàn)單點(diǎn)故障并且具備線性擴(kuò)展能力。它采取雙副本和強(qiáng)一致性，為高可用性提供保障。此外，COMET實(shí)現(xiàn)了寫時(shí)復(fù)制的磁盤快照和寫時(shí)復(fù)制的磁盤克隆等創(chuàng)新功能。

本論文其余部分組織如下：第1部分闡述近年來為虛擬機(jī)提供后端磁盤存儲的相關(guān)研究，第2部分詳述系統(tǒng)設(shè)計(jì)，第3部分進(jìn)行性能測試與對比，第4部分為總結(jié)和展望。

1 相關(guān)工作

論文MOBBS: A Multi-tier Block Storage Systemfor Virtual Machines using Object-based Storage[5]使用HDD和SSD的混合介質(zhì)為虛擬機(jī)提供后端存儲，并提出了Hybrid Pool技術(shù)對不同介質(zhì)的設(shè)備進(jìn)行有效利用。

論文PIOD: A Parallel I/O Dispatch Model Based on Lustre File System for Virtual Machine Storage[6]基于Lustre并行分布式文件系統(tǒng)，通過OST_Queue技術(shù)將I/O請求按照對應(yīng)物理磁盤位置分批提交，減少磁頭抖動提高性能。

開源分布式文件系統(tǒng)Ceph[7]通過librbd為虛擬機(jī)提供塊存儲，后者導(dǎo)出了創(chuàng)建卷、克隆卷、創(chuàng)建快照、快照回滾、讀寫數(shù)據(jù)等一系列API。然而，Ceph在塊存儲方面表現(xiàn)出的擴(kuò)展速度慢、集群不穩(wěn)定等現(xiàn)象常被人們所詬病。

開源分布式對象存儲系統(tǒng)Sheepdog以輕量級的代碼為虛擬機(jī)提供塊存儲。Sheepdog采用多副本模式，以Zookeeper或corosync進(jìn)行管理集群，也支持日志和糾刪碼。

開源系統(tǒng)OpenStack與Cinder結(jié)合使用可以達(dá)到提供塊存儲的目的[8]，其中，OpenStack是存儲資源的提供者，而Cinder是分布式塊存儲的API框架，Cinder主要與OpenStack中的Nova交互，通過軟件定義方式，向上層提供塊存儲視圖。

Amazon是虛擬機(jī)IaaS云服務(wù)的首要運(yùn)營商之一，其中虛擬機(jī)后端存儲由Amazon EBS提供。Amazon EBS 主要提供兩種虛擬磁盤卷：能夠激增至數(shù)百IOPS的標(biāo)準(zhǔn)卷和支持4000IOPS的預(yù)配置IOPS卷，并允許對虛擬磁盤卷隨時(shí)進(jìn)行創(chuàng)建、刪除、遷移、快照等操作。Amazon EBS憑借其強(qiáng)大的彈性服務(wù)成為業(yè)界翹楚，然而其技術(shù)細(xì)節(jié)并無公開資料供檢索。

2 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

2.1 總體架構(gòu)

COMET主要涉及3個(gè)層次，如圖1所示：

圖1 系統(tǒng)架構(gòu)總圖

虛擬機(jī)集群、服務(wù)器集群和物理磁盤群，服務(wù)器集群和物理磁盤群構(gòu)成COMET分布式塊存儲系統(tǒng)的主體，每個(gè)服務(wù)器掛載不定量的多個(gè)物理磁盤。圖1給出了包含虛擬機(jī)集群在內(nèi)的系統(tǒng)架構(gòu)總圖。

虛擬磁盤在COMET中以4M分割，每個(gè)4M塊稱為一個(gè)Chunk，每個(gè)Chunk作為服務(wù)器上的一個(gè)文件存儲于物理磁盤中，多個(gè)Chunk散布于不同的物理磁盤乃至不同服務(wù)器上，對同一虛擬磁盤的讀寫可以通過多個(gè)底層物理磁盤的協(xié)作來提高效率。

出于可用性考慮，服務(wù)器集群由兩個(gè)隔離域組成，該兩域位于不同機(jī)房，以降低同時(shí)掉電等事故的概率。每個(gè)隔離域中包含多臺服務(wù)器，支持服務(wù)器的動態(tài)加入和移出。每個(gè)Chunk有兩個(gè)副本，分別位于隔離域A和隔離域B中，雙副本和隔離域?qū)蛻魴C(jī)透明而對QEMU不透明，這里通過改進(jìn)的一致性哈希算法實(shí)現(xiàn)Chunk的定位。COMET采取去中心架構(gòu)，徹底避免了單點(diǎn)故障，具備線性擴(kuò)展能力。

2.2 QEMU端I/O設(shè)計(jì)

本論文選用了支持KVM[9]與virtio的高性能開源Hypervisor QEMU[10]作為客戶機(jī)與物理機(jī)的中間層。為構(gòu)建完整的I/O路徑，必須成功建立自客戶機(jī)應(yīng)用層到COMET后端存儲的I/O回路。這一步的關(guān)鍵是，在貫穿客戶機(jī)與宿主機(jī)的復(fù)雜I/O棧中，確定合適的層次將接收到的I/O指令移接至COMET存儲，并在成功執(zhí)行指令后將I/O數(shù)據(jù)或完成狀態(tài)回送至該層。為性能計(jì)，必須保證總I/O路徑盡可能短。

用宿主機(jī)本地磁盤為客戶機(jī)虛擬磁盤存下的I/O路徑圖，如圖2所示：

圖2 I/O路徑示例圖

其中只畫出I/O指令的下發(fā)路線，I/O數(shù)據(jù)或狀態(tài)的回送路線與之互逆。啟用virtio時(shí)，位于客戶機(jī)操作系統(tǒng)的virtio前端和QEMU中的virtio后端里應(yīng)外合，自客戶機(jī)用戶空間下達(dá)的讀寫指令傳送到塊設(shè)備驅(qū)動層時(shí)被virtio前端截獲，經(jīng)由virtio-ring環(huán)形緩沖區(qū)傳至virtio后端，進(jìn)而抵達(dá)QEMU中的I/O仿真層。圖2場景下，I/O仿真層代碼通過相應(yīng)系統(tǒng)調(diào)用讀寫位于宿主機(jī)本地磁盤上為客戶機(jī)磁盤提供存儲的文件，最終讀寫物理磁盤。不啟用virtio時(shí)，客戶機(jī)I/O指令到達(dá)塊設(shè)備驅(qū)動層后，繼續(xù)向客戶機(jī)視角下的底層磁盤設(shè)備傳送，進(jìn)而被宿主機(jī)KVM模塊的I/O陷入子模塊截獲，通過共享內(nèi)存頁的方式輸送給QEMU中的I/O仿真層，后續(xù)過程與啟用virtio的情形相同。對比知，virtio的存在，繞過了傳統(tǒng)的KVM的I/O陷入方式，不僅減少了CPU通過VM entry、VM exit在根模式與非根模式之間切換的次數(shù)[11]，而且減少了宿主機(jī)在用戶空間和內(nèi)核空間切換的次數(shù)，極大地提高了效率。

基于此，在客戶機(jī)的內(nèi)部的I/O棧里進(jìn)行I/O指令的接收和I/O路徑的移接相當(dāng)于放棄了virtio對虛擬機(jī)I/O的優(yōu)化效應(yīng)，并不合理；而在宿主機(jī)的內(nèi)核I/O棧里這樣做則會導(dǎo)致I/O路徑過長，同樣不合理。COMET最終采用的方案為：在距離virtio后端最近的I/O仿真層實(shí)現(xiàn)并添加新的代碼塊，將接收到的I/O指令解析后提交給后端的分布式存儲，并根據(jù)后端存儲返回的I/O數(shù)據(jù)或狀態(tài)在該層提交給QEMU，構(gòu)成I/O回路。

2.3 數(shù)據(jù)一致性

分布式文件系統(tǒng)中，對一致性的實(shí)現(xiàn)必須考慮位于多個(gè)物理節(jié)點(diǎn)的多個(gè)用戶共享同一文件情形下的多副本一致性，其實(shí)現(xiàn)往往需要借助Paxos[12]等成熟協(xié)議。而虛擬磁盤I/O場景下，同一虛擬磁盤的唯一用戶為位于同一物理節(jié)點(diǎn)上的客戶機(jī)，使問題得到了巨大簡化。COMET針對虛擬磁盤I/O場景實(shí)現(xiàn)了雙副本的強(qiáng)一致性。

COMET為每一個(gè)Chunk維護(hù)一個(gè)版本號信息，QEMU端維護(hù)著對應(yīng)虛擬磁盤全部Chunk的版本信息（以1TB虛擬磁盤為例，占用內(nèi)存空間為1M）。讀操作不改變版本號，寫操作使版本號增1，無論讀寫，COMET在回執(zhí)中攜帶相應(yīng)Chunk的版本號以供QEMU端對照。對于寫操作，QEMU端等待兩個(gè)副本所在服務(wù)器都回執(zhí)寫成功后才向客戶機(jī)報(bào)告寫成功（故障導(dǎo)致超時(shí)的情形下允許以單個(gè)副本的寫成功標(biāo)識成功），同時(shí)更新本地維護(hù)的Chunk版本號；對于首次讀操作，QEMU端向兩個(gè)副本分別索要版本號，若一致，則任選其一拉取數(shù)據(jù)；若不一致，則觸發(fā)修復(fù)事件，先使用高版本Chunk覆蓋低版本Chunk，再讀出數(shù)據(jù)。對于后續(xù)讀操作，QEMU任選一個(gè)副本進(jìn)行交互。

為說明故障場景下的強(qiáng)一致性，不妨假設(shè)客戶機(jī)A在對某Chunk進(jìn)行讀寫，Chunk的兩個(gè)副本為甲和乙。一個(gè)典型的過流程為：

① A首次讀Chunk②乙所在服務(wù)器宕機(jī)③ A無法與乙所在服務(wù)器建立連接，轉(zhuǎn)而與甲副本交互④ A寫甲副本，甲副本版本號更新，A更新自己維護(hù)的對應(yīng)Chunk的版本號⑤ 乙所在服務(wù)器重啟⑥ A讀到乙副本，發(fā)現(xiàn)返回的版本號與維護(hù)的Chunk版本號不同，觸發(fā)修復(fù)事件⑦乙副本被修復(fù)⑧A讀到最新數(shù)據(jù)⑨后續(xù)讀寫注：若第⑥步未發(fā)生，則COMET后臺修復(fù)進(jìn)程會對低版本乙進(jìn)行發(fā)現(xiàn)，仍觸發(fā)修復(fù)，之后A再讀乙將直接得到新版本的數(shù)據(jù)。

在分布式文件系統(tǒng)中，則無法采用該方法，這是因?yàn)?，分布式文件系統(tǒng)中多用戶位于多個(gè)物理節(jié)點(diǎn)，即便令其在本地維護(hù)Chunk的版本號，在文件共享情形下，所維護(hù)的版本號無法及時(shí)更新，從而在不同用戶間產(chǎn)生分歧。以位于不同物理節(jié)點(diǎn)的用戶A、B讀同一Chunk的甲、乙副本為例，一個(gè)可能的流程為：

① A首次讀Chunk②B首次讀Chunk③乙所在服務(wù)器宕機(jī)④ A無法與乙所在服務(wù)器建立連接，轉(zhuǎn)而與甲副本交互⑤ A寫甲副本，甲副本版本號更新，A更新自己維護(hù)的對應(yīng)Chunk的版本號，B不知道A對Chunk進(jìn)行了寫操作，未更新本地維護(hù)的Chunk的版本號⑥乙所在服務(wù)器重啟⑦ B讀到乙副本，發(fā)現(xiàn)返回的版本號與維護(hù)的Chunk版本號相同，認(rèn)為讀操作成功，從而B讀到舊數(shù)據(jù)，強(qiáng)一致性被破壞

可見，COMET強(qiáng)一致性的實(shí)現(xiàn)是針對虛擬磁盤I/O場景的精簡實(shí)現(xiàn)，該實(shí)現(xiàn)避免了分布式文件系統(tǒng)中強(qiáng)一致性對應(yīng)的復(fù)雜設(shè)計(jì)所帶來的開銷，提高了性能。

2.4 快照與克隆

COMET系統(tǒng)實(shí)現(xiàn)寫時(shí)復(fù)制的磁盤快照和寫時(shí)復(fù)制的磁盤克隆的創(chuàng)新功能。COMET中一個(gè)Chunk在讀、寫、快照等混合請求下的事件時(shí)序圖，如圖3所示：

圖3 快照時(shí)序圖

COMET中，所有客戶機(jī)的虛擬磁盤都基于一個(gè)事先建立好的根磁盤快照，稱為S0。建立一個(gè)虛擬機(jī)的過程即將該虛擬機(jī)的物理存儲導(dǎo)向S0，除此之外不需要做任何事情。對S0的首次寫會導(dǎo)致創(chuàng)建真正的客戶機(jī)Chunk，稱為C。數(shù)據(jù)寫入C而不影響S0。后續(xù)讀寫都在C上執(zhí)行。

COMET結(jié)合時(shí)間戳（實(shí)際上是以時(shí)間戳為主體結(jié)合遞增數(shù)字字串的可區(qū)分字符串）來輔助快照的管理。對于拍攝快照請求，系統(tǒng)只是記錄請求時(shí)間戳，在后續(xù)發(fā)生寫操作時(shí)，才真正創(chuàng)建快照Chunk并維護(hù)其Chunk時(shí)間戳。圖3中t1時(shí)刻由寫操作觸發(fā)所創(chuàng)建的St1，同時(shí)作為S1和S2的快照Chunk。對于讀請求，直接在當(dāng)前Chunk執(zhí)行。對于寫請求，需結(jié)合時(shí)間戳檢查之前是否有未處理的快照請求（即該請求并無與之對應(yīng)的新建快照Chunk），若存在，則新建快照Chunk，否則直接寫入。對于快照讀取請求，若存在未處理的快照請求，則保存當(dāng)前Chunk為快照Chunk，否則自所讀取快照的請求時(shí)間戳向后，定位至最近的快照Chunk，同時(shí)清理當(dāng)前Chunk。對于快照刪除請求，若存在未處理的快照請求，則保存當(dāng)前Chunk為快照Chunk，以圖3中刪除S1為例，繼而，先找到位于S1請求時(shí)間戳之后的最近快照Chunk St1，再自St1向前回溯至最近的快照Chunk（這里為S0），若兩個(gè)快照Chunk之間除待刪除快照外還存在其他快照（這里為S2），則只刪除S1的維護(hù)信息，不刪除快照Chunk；若兩個(gè)快照Chunk之間只有待刪除快照且其對應(yīng)快照Chunk不是當(dāng)前Chunk，則真正刪除快照Chunk。COMET根據(jù)時(shí)間戳找尋快照Chunk的過程中是以快照鏈為外沿進(jìn)行的。舉例而言，在圖3基礎(chǔ)上，若先讀取快照S1再經(jīng)歷讀寫并產(chǎn)生快照S4，雖然全局范圍內(nèi)，自S4請求時(shí)間戳向前的最近快照Chunk為St2，然而St2（對于S3）和S4分屬不同的快照鏈，故對COMET而言，S4請求時(shí)間戳之前的最近快照為位于S4快照鏈上的St1。

基于該實(shí)現(xiàn)，克隆客戶機(jī)類相當(dāng)于為當(dāng)前Chunk拍攝快照，而舊客戶機(jī)和新客戶機(jī)成為該快照下的兩個(gè)分支，由于磁盤快照本身幾乎不消耗時(shí)間，故而磁盤克隆也可以瞬時(shí)完成。

3 讀寫性能測試

3.1 測試環(huán)境

硬件方面，本測試使用3臺配有Intel(R) Xeon(R) CPU E5506系列4核處理器、16G內(nèi)存、7200轉(zhuǎn)1TB SATA盤的服務(wù)器。服務(wù)器之間使用Intel X520-SR1 10Gbps網(wǎng)卡、高速網(wǎng)線、DELL N4032萬兆以太網(wǎng)交換機(jī)互連。其中，服務(wù)器A作虛擬機(jī)節(jié)點(diǎn)，服務(wù)器B、C除引導(dǎo)盤外分別掛載八塊磁盤，用作后端存儲節(jié)點(diǎn)。

軟件方面，3臺服務(wù)器均安裝基于Linux-2.6.32內(nèi)核的CentOS6.6，A上采用針對COMET添加了I/O仿真層代碼的qemu-2.3.0作Hypervisor，并啟用kvm和kvm-intel模塊，為虛擬機(jī)分配4GB內(nèi)存。

3.2測試方案

本論文分別測試基于COMET與成熟開源分布式對象存儲系統(tǒng)Sheepdog的前端虛擬機(jī)I/O性能并進(jìn)行對比，其中COMET和Sheepdog均采用雙副本。具體測試涵蓋 {1~512線程} × {4K~4M讀寫塊} × {順序讀寫, 隨機(jī)讀寫} 的全部情形。測試工具為Fio，測試方法為在虛擬機(jī)上安裝Fio并執(zhí)行語句：

順序讀寫：fio -name=… -numjobs=… -bs=… -rw=read/write -size=… -direct=0-ioengine=sync -runtime=…

隨機(jī)讀寫：fio-name=… -numjobs=… -bs=…-rw=randread/randwrite -size=… -direct=1 -ioengine=libaio -iodepth=8 -runtime=…

3.3 主要結(jié)果

限于篇幅，這里選用較有代表性的128KB塊大小多線程順序讀寫和4KB塊大小多線程隨機(jī)讀寫的測試數(shù)據(jù)進(jìn)行闡述。COMET和Sheepdog的性能對比如圖4所示：

圖4 多線程讀寫性能對比

其中，COMET順序讀性能比Sheepdog略高，隨機(jī)讀性能高出Sheepdog較多，隨機(jī)寫性能明顯高于Sheepdog且比Sheepdog穩(wěn)定，這不僅得益于針對性的設(shè)計(jì)，也得益于系統(tǒng)內(nèi)部高并發(fā)架構(gòu)的實(shí)現(xiàn)與異步IO的成功使用。

對于順序?qū)?，COMET在多于16線程的情形下明顯低于Sheepdog。這是因?yàn)镾heepdog在其QEMU端驅(qū)動和后端存儲之間維護(hù)了寫緩存，該緩存的命中減少了交付后端的寫請求個(gè)數(shù)從而提高性能。COMET尚未實(shí)現(xiàn)緩存機(jī)制，然而考慮到寫緩存會降低系統(tǒng)可靠性，擬只實(shí)現(xiàn)讀緩存。

4 總結(jié)

COMET系統(tǒng)的創(chuàng)新性在于：1）針對虛擬磁盤I/O場景揚(yáng)棄了文件系統(tǒng)的語義，在數(shù)據(jù)讀寫和一致性等方面采用了精簡合理的設(shè)計(jì)；2）實(shí)現(xiàn)了寫時(shí)復(fù)制的磁盤快照和寫時(shí)復(fù)制的磁盤克隆等創(chuàng)新功能。

COMET的不足在于尚未實(shí)現(xiàn)緩存機(jī)制（為可靠性計(jì)，擬只實(shí)現(xiàn)讀緩存），性能上仍存在優(yōu)化空間。就業(yè)界現(xiàn)狀而言，除內(nèi)存緩存外，使用大容量SSD的為分布式系統(tǒng)提供緩存也已成為技術(shù)熱點(diǎn)。在后續(xù)工作中，COMET系統(tǒng)將構(gòu)建基于內(nèi)存與SSD的多層讀緩存，力求性能上的進(jìn)一步階躍。

參考文獻(xiàn)：

[1] Dong Y, Zheng Z, Zhang X, et al. Improving virtualization performance and scalability with advanced hardware accelerations[C]//Workload Characterization (IISWC), 2010 IEEE International Symposium on. IEEE, 2010: 1-10.

[2] Russell R. virtio: towards a de-facto standard for virtual I/O devices[J]. ACM SIGOPS Operating Systems Review, 2008, 42(5): 95-103.

[3] Tarasov V, Hildebrand D, Kuenning G, et al. Virtual machine workloads: the case for new benchmarks for NAS[C]//FAST. 2013: 307-320.

[4] Tarasov V, Jain D, Hildebrand D, et al. Improving I/O performance using virtual disk introspection[C]//Proceedings of the 5th USENIX conference on Hot Topics in Storage and File Systems. USENIX Association, 2013: 11-11.

[5] Ma S, Chen H, Lu H, et al. MOBBS: A Multi-tier Block Storage Systemfor Virtual Machines usingObject-based Storage[C]//High Performance andCommunications (HPCC), 16th International Conference on. IEEE, 2014: 272-275.

[6] Lei Z, Zhou Z, Hu B, et al. PIOD: A Parallel I/O Dispatch Model Based on Lustre File System for Virtual Machine Storage[C]//Cloud and Service Computing (CSC), 2013 International Conference on. IEEE, 2013: 30-35.

[7] Weil S A, Brandt S A, Miller E L, et al. Ceph: A scalable, high-performance distributed file system[C]//Proceedings of the 7th symposium on Operating systems design and implementation. USENIX Association, 2006: 307-320.

[8] Rosado T, Bernardino J. An overview of openstack architecture[C]//Proceedings of the 18th International Database Engineering & Applications Symposium. ACM, 2014: 366-367.

[9] Ali S. Virtualization with KVM[M]//Practical Linux Infrastructure. Apress, 2015: 53-80.

[10] Huynh K, Hajnoczi S. KVM/QEMU storage stack performance discussion[C]//Linux Plumbers Conference. 2010.

[11] Uhlig R, Neiger G, Rodgers D, et al. Intel virtualization technology[J]. Computer, 2005, 38(5): 48-56.

[12] Zhao W. Fast Paxos Made Easy: Theory and Implementation[J]. International Journal of Distributed Systems and Technologies (IJDST), 2015, 6(1): 15-33.

Design and Implementation of Distributed Block Storage for QEMU

Zhang Hubin, Li Xiaoyong

(College of Information Security, Shanghai Jiaotong University, Shanghai 200240, China)

Virtualization of computing system has become a main trend. However,currentbackend storage implementationsfor virtual machine disks usuallyreference directly from distributed file system, resulting in a series of unnecessary overhead in virtual disk I/O scenarios.The COMET system presented by this paper is a distributed block storage systems for QEMU. Based on Proactor mode, COMET abandons the semantics of the file system, takes reasonable design in data access as well as consistency and maintains a minized I/O path for virtual disk I/O scenarios. Withlinear scalability, high availability, COMET implemented innovative features such as write-on-copy disk snapshot and write-on-copyclone.Results show that COMET has a performance comparable to or even betterthan mature open source systems in certain I/O scenarios.

QEMU; Block Storage; Distributed System;Snapshot; Clone

1007-757X(2016)04-0054-04

TP311

A

（2015.09.06）

張滬濱（1990-），男，上海交通大學(xué)，信息安全工程學(xué)院，碩士，研究方向：操作系統(tǒng)、網(wǎng)絡(luò)、存儲、分布式，上海，200240

李小勇（1972-），男，上海交通大學(xué)，信息安全工程學(xué)院，副教授、博士，研究方向：操作系統(tǒng)、網(wǎng)絡(luò)、存儲、分布式，上海，200240