基于云芯一號(hào)的對(duì)象加速存儲(chǔ)架構(gòu)和實(shí)現(xiàn)

王界兵 王文利 董迪馬

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

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

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

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

0 引 言

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

1 云芯一號(hào)

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

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

1.2 軟件架構(gòu)

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

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

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

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

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

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

2 OpenStack平臺(tái)中的對(duì)象存儲(chǔ)—Swift組件

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

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

3 對(duì)象存儲(chǔ)加速架構(gòu)

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

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

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

（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 實(shí)驗(yàn)對(duì)比

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

4.1 純壓縮測(cè)試

純壓縮測(cè)試是為了對(duì)比傳統(tǒng)的基于CPU的各類HDFS軟壓縮特性和基于云芯一號(hào)芯片的硬件壓縮能力。為此測(cè)試了一組隨機(jī)大?。◤淖钚?shù)據(jù)（7.27 MB）到最大數(shù)據(jù)

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

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

MEM：DDR3-1 333 MHz 64 GB。

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

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

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

4.2 存儲(chǔ)速度對(duì)比測(cè)試

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

所示。

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

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

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

5 結(jié) 語(yǔ)

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

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

參 考 文 獻(xiàn)

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

[2]尤肖虎，潘志文，高西奇，等.5G移動(dòng)通信發(fā)展趨勢(shì)與若干關(guān)鍵技術(shù)[J].中國(guó)科學(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部署實(shí)踐[M].北京：人民郵電出版社，2014.

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

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