王界兵 王文利 董迪馬

摘 要：云平臺中的對象存儲是一種新型存儲技術(shù)，結(jié)合傳統(tǒng)文件存儲和塊存儲的優(yōu)點，向用戶提供持久的數(shù)據(jù)存儲服務(wù)。對象存儲能夠?qū)?shù)據(jù)進(jìn)行快速讀、寫，支持分布式存儲。隨著云計算、大數(shù)據(jù)等技術(shù)的快速發(fā)展，現(xiàn)有的塊存儲技術(shù)已經(jīng)受到了硬件存儲資源的限制，隨之而來便是各類應(yīng)用環(huán)境的資源瓶頸問題。針對此問題，文中首先設(shè)計并研制出一款擁有自主產(chǎn)權(quán)的硬件加速卡—云芯一號（Cloud Core V1.0），然后結(jié)合開源云平臺OpenStack提出基于對象存儲組件Swift的對象存儲架構(gòu)。最后通過大量實驗驗證和性能指標(biāo)表明，在純文件壓縮/

解壓過程中，云芯一號的速度相比傳統(tǒng)的軟件壓縮/解壓速度快近10倍，在提出的對象加速存儲架構(gòu)中大幅度縮短了云平臺中的對象存儲時間。

關(guān)鍵詞：OpenStack;對象存儲;Swift;云芯一號;互聯(lián)網(wǎng);FPGA

中圖分類號：TP311.5文獻(xiàn)標(biāo)識碼：A文章編號：2095-1302（2019）08-00-04

0 引 言

隨著互聯(lián)網(wǎng)行業(yè)的快速發(fā)展，各類應(yīng)用和數(shù)據(jù)呈指數(shù)級增長，不僅對數(shù)據(jù)的大容量存儲需求越來越多[1-2]，互聯(lián)網(wǎng)應(yīng)用種類也越來越多，如云盤、視頻點播、協(xié)作辦公等都對數(shù)據(jù)存儲有著嚴(yán)格的要求，因此數(shù)據(jù)存儲在現(xiàn)有的大數(shù)據(jù)和云計算環(huán)境下，占有越來越重要的位置。在此基礎(chǔ)上，云存儲是一種基于云計算技術(shù)發(fā)展而來的服務(wù)類型，是云計算和傳統(tǒng)存儲的一種延伸和擴展[3-4]，相關(guān)技術(shù)的主要目的是把傳統(tǒng)的本地存儲放在云端存儲，但給用戶帶來的是與本地存儲一樣的服務(wù)體驗。各類云存儲中，對象存儲（Object-based Storage，OS）是一種新的網(wǎng)絡(luò)存儲架構(gòu)[5]，基于對象存儲技術(shù)的設(shè)備即對象存儲設(shè)備[6]（Object-based Storage Device，OSD）。對象存儲綜合NAS和SAN的優(yōu)點[7-8]，同時具有SAN的高速直接訪問和NAS的分布式數(shù)據(jù)共享等優(yōu)勢，可提供具有高性能、高可靠性、跨平臺以及安全的數(shù)據(jù)共享存儲體系結(jié)構(gòu)[9]。為了提高服務(wù)器等硬件設(shè)備的計算能力和數(shù)據(jù)安全性[10]，一些針對性強的硬件加速設(shè)備，如FPGA等被用來對數(shù)據(jù)進(jìn)行預(yù)先處理?；诖?，本文設(shè)計了一款擁有自主產(chǎn)權(quán)的硬件加速卡—云芯一號（Cloud Core V1.0），然后結(jié)合開源云平臺OpenStack提出了基于對象存儲組件Switft的對象存儲加速架構(gòu)。

1 云芯一號

1.1 硬件結(jié)構(gòu)

本文設(shè)計的具有自主知識產(chǎn)權(quán)的FPGA加速芯片—云芯一號如圖1所示。該芯片可以使用任何可用的12 V PCle 插槽供電。與此同時，芯片還支持8路雙工收發(fā)器，可插入x8或更大的PCle 3.0插槽。所有和芯片之間的通信都必須通過芯片上的PCle接口進(jìn)行。

1.2 軟件架構(gòu)

云芯一號主要由5個軟件模塊組成，包括服務(wù)助理基礎(chǔ)設(shè)施（SAI）、API層、Frontsurf服務(wù)框架（FSF）、設(shè)備專用驅(qū)動程序（DSD）、軟件庫。具體如圖2所示。

SAI模塊主要為其他模塊提供基礎(chǔ)服務(wù)，由OS抽象層（OSAL）、日志和文件解析器組成。

對于API層而言，云芯一號提供Raw加速（原始）API對用戶的各類應(yīng)用程序進(jìn)行連接。Raw Acceleration API可以利用Cloud-Core V1.0上的所有功能，包括文件壓縮、文件加密、身份認(rèn)證、RNG和PK等。

Frontsurf Service Framework（FSF）模塊的功能是為云芯一號的API層提供算法加速。在Cloud Core V1.0中，所有與芯片組無關(guān)的代碼都位于Frontsurf服務(wù)框架中。與之相反，所有與芯片組相關(guān)的代碼位于設(shè)備專用驅(qū)動程序中。另外，F(xiàn)rontsurf服務(wù)框架（FSF）模塊還管理所有使用設(shè)備特定驅(qū)動程序注冊的會話、密鑰和設(shè)備，從而使得云芯一號可以實現(xiàn)硬件加速和軟件庫操作。具體流程：FSF從API層檢索操作請求，然后將這些操作轉(zhuǎn)換為硬件命令，同時提交硬件命令給相應(yīng)的硬件，檢索命令，并將完成的操作反饋信息返回給API層。除此之外，F(xiàn)SF還管理云芯一號的負(fù)載平衡，會話上下文和密鑰池。如果部署云芯一號的硬件不可用于數(shù)據(jù)操作，則FSF與軟件庫將一起工作以提供軟件上的各種支持，例如文件軟壓縮、軟件認(rèn)證、文件軟加密和PK，完成相關(guān)的軟件操作，最大程度保障服務(wù)的正常運行。

設(shè)備專用驅(qū)動程序（DSD）是一個與芯片組相關(guān)的功能模塊，其主要功能是為Frontsurf服務(wù)框架（FSF）提供統(tǒng)一的硬件接口，并且將每個設(shè)備的特定結(jié)構(gòu)格式轉(zhuǎn)換為與FSF相同的結(jié)構(gòu)。

軟件庫執(zhí)行軟件中的壓縮、認(rèn)證、加密和公鑰操作等。如果云芯一號芯片發(fā)生硬件錯誤或正處于從錯誤中恢復(fù)的狀態(tài)，抑或在系統(tǒng)中沒有可操作的Frontsurf設(shè)備，則軟件庫將作為設(shè)備特定的驅(qū)動程序來實現(xiàn)相關(guān)請求，通過模擬硬件完成用戶的請求。云芯一號中的軟件庫類似一個容災(zāi)模塊，在硬件設(shè)備和運行軟件方面，為其部署的運行環(huán)境提供最大限度的服務(wù)保障。

2 OpenStack平臺中的對象存儲—Swift組件

2010年Rackspace公司開發(fā)的高可用分布式對象存儲（Object-Storage）服務(wù)—Swift項目被共享給了OpenStack開源社區(qū)，并在同年成為OpenStack的核心子項目之一，其主要作用是為OpenStack平臺中的計算組件Nova提供虛擬機鏡像的對象存儲服務(wù)。Swift的搭建無任何硬件環(huán)境的限制，可以直接搭建在較便宜的基礎(chǔ)硬件設(shè)施之上，對于磁盤冗余陣列的要求不高，即使無RAID架構(gòu)也可以提供相關(guān)服務(wù)。同時Swift在軟件層面引入了一致性散列技術(shù)和數(shù)據(jù)冗余性技術(shù)，通過犧牲一定程度的存儲數(shù)據(jù)一致性來達(dá)到云平臺的高可用性和可伸縮一致性。另外Swift還支持OpenStack上的多租戶模式，支持容器和對象的讀寫操作，適合解決互聯(lián)網(wǎng)中各類應(yīng)用場景的非結(jié)構(gòu)化數(shù)據(jù)存儲問題。OpenStack平臺中的Swift 組件具體包括9個模塊，分別為代理服務(wù)（Proxy Server）、認(rèn)證服務(wù)（Authentication Server）、緩存服務(wù)（Cache Server）、賬戶服務(wù)（Account Server）、容器服務(wù)（Container Server）、對象服務(wù)（Object Server）、復(fù)制服務(wù)（Replicator）、更新服務(wù)（Updater）、審計服務(wù)（Auditor）、賬戶清理服務(wù)（Account Reaper）。

Swift具體架構(gòu)如圖3所示。

3 對象存儲加速架構(gòu)

基于開源云平臺OpenStack中現(xiàn)有的對象存儲架構(gòu)，本文提出了基于云芯一號芯片的對象存儲加速架構(gòu)，對文件進(jìn)入存儲前進(jìn)行硬件加速預(yù)處理，包括文件的硬件壓縮和解壓，從硬件層對文件的存儲和讀取進(jìn)行全方面的加速處理，具體架構(gòu)如圖4所示。

從圖中我們可以看出，在整個加速存儲架構(gòu)的上層，OpenStack平臺通過硬件（比如F5）或者軟件（比如HAProxy）負(fù)載均衡器將客戶端的請求按照配置分配到無狀態(tài)的Proxy Service。訪問層（Proxy Server）負(fù)責(zé)向客戶端提供REST API和無狀態(tài)的WSGI服務(wù)，多個Proxy Server可以組成一個集群，將客戶端的請求轉(zhuǎn)發(fā)至某個對象存儲節(jié)點上的Account，Container或Object。

在存儲層（Capacity Tier），分配到存儲節(jié)點進(jìn)行存儲的數(shù)據(jù)首先通過云芯一號芯片（Cloud Core V1.0）進(jìn)行存儲前壓縮處理，之后通過該層的其他部分進(jìn)行文件的分布式存儲。

（1）Account Server提供Account操作的Rest API。

（2）Container Server提供Container操作的Rest API。

（3）Object Server 提供Object操作的Rest API。

（4）Consistency Servers提供包括Replicators，Updaters和Auditors等后天服務(wù)，用于保證Object的一致性。

4 實驗對比

我們完成了基于云芯一號的對象存儲加速架構(gòu)的設(shè)計和實現(xiàn)，之后通過純壓縮測試對比實驗和HDFS數(shù)據(jù)存儲速度對比實驗來驗證所提出的加速存儲架構(gòu)的性能和優(yōu)越性。

4.1 純壓縮測試

純壓縮測試是為了對比傳統(tǒng)的基于CPU的各類HDFS軟壓縮特性和基于云芯一號芯片的硬件壓縮能力。為此測試了一組隨機大小（從最小數(shù)據(jù)（7.27 MB）到最大數(shù)據(jù)

（100 MB）），共88 132 MB的數(shù)據(jù)集的壓縮速度，測試環(huán)境如下。

CPU：Intel? CoreTM i5-4590 CPU@3.30 GHz。

MEM：DDR3-1 333 MHz 64 GB。

結(jié)果如圖5所示。

從圖中可以看到，基于云芯一號硬件壓縮的進(jìn)程壓縮速度約為1 508.7 MB/s（>1 500 MB/s）。與此同時，將該數(shù)據(jù)集在傳統(tǒng)HDFS上的各類軟壓縮軟件上進(jìn)行了相同實驗，得到的壓縮性能對比見表1所列。

從表格中可以清楚地看出，基于硬件加速的云芯一號芯片在同樣大小的原始文件上，無論是壓縮速度、解壓速度還是壓縮后的文件大小都占據(jù)絕對優(yōu)勢。尤其是壓縮速度和解壓速度兩個指標(biāo)更是較普通的軟件壓縮高10倍。為了更直觀地體現(xiàn)壓縮速度的差異，將測試的隨機大小文件集群的壓縮速度進(jìn)行了同一坐標(biāo)對比，如圖6所示。

4.2 存儲速度對比測試

完成了云芯一號芯片的純壓縮解壓測試后，我們將對比提出的對象存儲加速方案和傳統(tǒng)對象存儲方案的存儲效率。采用四組不同大小的數(shù)據(jù)集，分別為1 GB，10 GB，20 GB，50 GB，每組分別測試三次，取平均值，測試結(jié)果如圖7

所示。

從圖中可以看到不同大小的數(shù)據(jù)集存儲速度，存儲前通過云芯一號芯片加速后均體現(xiàn)出明顯高效的存儲效率，隨著數(shù)據(jù)集的增大，存儲時間的差異越來越大。可以預(yù)見，如果面對大額存儲數(shù)據(jù)時，云芯一號芯片的加入會極大地縮短數(shù)據(jù)存儲到Swift Storage Node中的時間，為后期的數(shù)據(jù)挖掘、分析等節(jié)約大量時間。

另外，為了更直觀地體現(xiàn)壓縮速度的對比，我們將測試的隨機大小文件集群的壓縮速度進(jìn)行了同一坐標(biāo)對比，如圖7

所示。從圖7中直觀地看出，基于硬件加速的云芯一號芯片的壓縮速度平均約為1 500 MB/s，而其他軟件壓縮文件速度幾乎平均在50以內(nèi)。

5 結(jié) 語

本文著力于傳統(tǒng)OpenStack云平臺中對象存儲的存儲效率和性能，在從存儲空間以及存儲調(diào)度上進(jìn)行優(yōu)化外，也思考從數(shù)據(jù)處理的平臺架構(gòu)和依托的硬件環(huán)境進(jìn)行創(chuàng)新。因此，我們提出了基于云芯一號硬件加速卡的對象存儲加速方案，在傳統(tǒng)的OpenStack Swift Storage Node上進(jìn)行硬件擴充和優(yōu)化，對存儲數(shù)據(jù)進(jìn)入節(jié)點前進(jìn)行壓縮預(yù)處理。通過不同環(huán)境的實驗結(jié)果對比，得出無論是在純文件壓縮上還是與傳統(tǒng)OpenStack平臺對象存儲節(jié)點中數(shù)據(jù)的存儲速度上，我們提出的方案均遠(yuǎn)遠(yuǎn)優(yōu)于傳統(tǒng)的存儲方式，為后續(xù)工作帶來更好的創(chuàng)新方向和架構(gòu)支撐。

注：本文通訊作者為王界兵。

參 考 文 獻(xiàn)

[1]賈向東，頡滿剛，周猛.基于帶內(nèi)回程的全雙工大規(guī)模MIMO異構(gòu)網(wǎng)覆蓋分析[J]. 計算機工程，2017，43（7）：124-128.

[2]尤肖虎，潘志文，高西奇，等.5G移動通信發(fā)展趨勢與若干關(guān)鍵技術(shù)[J].中國科學(xué)（信息科學(xué)），2014 （5）：551-563.

[3] ANDREWS J G. Seven ways that Het-Nets are a cell ular paradigm shift [J]. IEEE communications magazine，2013，51（3）：136-144.

[4] ZHENG Y，SUN S，RONG B，et al. Traffic aware power allocation and frequency reuse for green LTE-A heterogeneous networks [C]// Proceedings of IEEE International Conference on Communications. Washington C USA：IEEE Press，2015：3167-3172.

[5] MAHMUD A，HAMDI KA. A unified framework for the analysis of fractional frequency reuse techniques [J]. IEEE Transactions on Communications，2014，62 （10）：3692-3705.

[6] NOVLANTD，GANTI R K，GHOSH A，et al. Analytical evaluation of fractional frequency reuse for heterogeneous cellular networks [J]. IEEE transactions on communications，2012，60（7）：2029-2039.

[7] MOLTCHANOV D. Distance distributions in random networks [J]. Ad hoc networks，2012，10（6）：1146-1166.

[8]張子凡.OpenStack部署實踐[M].北京：人民郵電出版社，2014.

[9]汪楠.基于OpenStack云平臺的計算資源動態(tài)調(diào)度及管理[M].大連：大連理工大學(xué)，2013.

[10]陳康，鄭緯民.云計算：系統(tǒng)實例與研究現(xiàn)狀[J].軟件學(xué)報，2009（5）：1337-1348.