一種基于云芯一號(hào)的OPenStack塊存儲(chǔ)加速方案

王界兵 王文利 董迪馬

摘要：為了改善傳統(tǒng)OpenStack平臺(tái)在非對(duì)象存儲(chǔ)上存儲(chǔ)效率低下、存儲(chǔ)方式單一等缺點(diǎn)，基于自主研發(fā)的云芯一號(hào)（cloud Core V1.0），在多節(jié)點(diǎn)分布式OpenStack云平臺(tái)上研發(fā)基于云芯一號(hào)的塊存儲(chǔ)加速體系結(jié)構(gòu)，并進(jìn)行試驗(yàn)部署。研究結(jié)果表明，基于云芯一號(hào)的塊存儲(chǔ)加速方案，增加了OpenStack塊存儲(chǔ)的存儲(chǔ)對(duì)象種類;在塊存儲(chǔ)前進(jìn)行文件硬件壓縮處理，極大提升了塊存儲(chǔ)的存儲(chǔ)速度和安全可靠性;基于云芯一號(hào)的Open-Stack塊存儲(chǔ)加速方案不僅能快速有效地對(duì)非對(duì)象存儲(chǔ)資源進(jìn)行安全有效存儲(chǔ)，而且為存儲(chǔ)前的節(jié)點(diǎn)調(diào)度和資源監(jiān)控夯實(shí)了基礎(chǔ)。

關(guān)鍵詞：OpenStack;塊存儲(chǔ);云芯一號(hào);硬件壓縮

DOI：10.11907/rjd k.191258

中圖分類號(hào)：TP301 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1672-7800（2019）012-0089-04

0引言

隨著大數(shù)據(jù)、互聯(lián)網(wǎng)云時(shí)代的來臨，云平臺(tái)規(guī)模不斷擴(kuò)大，處理的數(shù)據(jù)量也日益增多，各類應(yīng)用和數(shù)據(jù)的處理時(shí)間更長(zhǎng)，導(dǎo)致云存儲(chǔ)對(duì)硬件設(shè)備和存儲(chǔ)數(shù)據(jù)的預(yù)壓縮要求也越來越高?，F(xiàn)場(chǎng)可編程邏輯門陣列（FPGA）可以基于硬件資源實(shí)現(xiàn)數(shù)據(jù)的壓縮和解壓，處理速度也是傳統(tǒng)壓縮軟件的數(shù)倍。

目前，業(yè)內(nèi)主流的軟件類無損壓縮算法有算術(shù)編碼、霍夫曼編碼和字典式的Lz系列編碼等?；诮y(tǒng)計(jì)學(xué)模型開發(fā)的算術(shù)編碼壓縮比最高，但其基于現(xiàn)有硬件實(shí)現(xiàn)解壓縮的方式卻很復(fù)雜。與以上兩種壓縮方法不同，基于字典式的LZ系列算法的壓縮和解壓縮過程并不對(duì)稱，解壓縮過程比壓縮過程簡(jiǎn)單很多，易于硬件實(shí)現(xiàn)，且該算法的實(shí)現(xiàn)不依賴特定FPGA結(jié)構(gòu)。已有研究幾乎都是基于字典式的Lz系列算法。文獻(xiàn)[5]根據(jù)Xilinx公司Virtex系列器件的特定結(jié)構(gòu)，采用改進(jìn)的LZSS算法，取得的壓縮比為4;文獻(xiàn)[6]改進(jìn)了經(jīng)典LZW算法，取得了較好效果，但沒有仔細(xì)考慮這種改進(jìn)給硬件解壓縮帶來的難度;文獻(xiàn)[7]用到的壓縮算法利用了Xilinx公司XC6200器件的特殊結(jié)構(gòu)，取得的壓縮比為7，在幾種算法中最高，但只適用于XC6200一種器件。另外，在主流FPGA廠商Xilinx公司的商業(yè)軟件里也實(shí)現(xiàn)了一種基于LZ77的算法，用來壓縮其配置文件。

針對(duì)已有研究的各種缺陷，本文首先研發(fā)一種擁有自主產(chǎn)權(quán)的FPGA加速芯片——云芯一號(hào)（cloud CoreVI.0），然后基于此芯片，結(jié)合OpenStack開源云平臺(tái)，提出一種數(shù)據(jù)預(yù)壓縮塊存儲(chǔ)加速方案。對(duì)文件在進(jìn)入OpenStack進(jìn)行塊壓縮前完成文件數(shù)據(jù)預(yù)壓縮處理，有效提高了OpenStack中存儲(chǔ)節(jié)點(diǎn)的存儲(chǔ)效率，同時(shí)也為將來文件的分布式存儲(chǔ)調(diào)度研究打下了堅(jiān)實(shí)基礎(chǔ)。通過實(shí)驗(yàn)對(duì)比，驗(yàn)證了基于云芯一號(hào)對(duì)各類文件處理的高效性以及基于該芯片提出的云平臺(tái)塊存儲(chǔ)加速機(jī)制的實(shí)時(shí)性和高效性。

1云芯一號(hào)

云芯一號(hào)（cloud-Core VI.O）是一張擁有自主知識(shí)產(chǎn)權(quán)的硬件加速卡，其外觀如圖1所示。

云芯一號(hào)可以使用任何可用的12V PCIe插槽對(duì)芯片進(jìn)行供電。硬件環(huán)境上，云芯一號(hào)支持8路雙工收發(fā)器，可插入x8或更大的PCIe 3.0插槽。另外，服務(wù)器上所有能與云芯一號(hào)進(jìn)行通信的硬件設(shè)備均通過PCIe接口進(jìn)行。

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

SAI模塊主要為其它模塊提供基礎(chǔ)服務(wù)，主要由OS抽象層（0SAL）、日志和文件解析器3個(gè)組件組成。對(duì)于API層，云芯一號(hào)提供Raw加速（原始）API對(duì)用戶的各類應(yīng)用程序進(jìn)行連接。Raw Acceleration API可以利用Cloud-Core VI.O上的所有功能，包括文件壓縮、文件加密、身份認(rèn)證、RNG和PK等各項(xiàng)操作。Frontsurf ServiceFramework（FsF）模塊的功能是為云芯一號(hào)的API層提供算法加速。在Cloud-Core VI.O中，所有與芯片組無關(guān)的代碼都位于Frontsurf服務(wù)框架中。與之相反，所有與芯片組相關(guān)的代碼位于設(shè)備專用驅(qū)動(dòng)程序中。另外，F(xiàn)rontsuff服務(wù)框架（FsF）模塊還管理所有使用設(shè)備特定驅(qū)動(dòng)程序注冊(cè)的會(huì)話、密鑰和設(shè)備，從而使得云芯一號(hào)可以實(shí)現(xiàn)硬件加速和軟件庫操作。具體流程為：FSF從API層檢索操作請(qǐng)求，然后將這些操作轉(zhuǎn)換為硬件命令并同時(shí)提交硬件命令給相應(yīng)硬件，接下來檢索完成的命令，并將完成的操作反饋信息返回給API層。此外，F(xiàn)SF還管理云芯一號(hào)整個(gè)芯片的負(fù)載平衡、會(huì)話上下文和密鑰池。如果部署云芯一號(hào)的硬件不可用于數(shù)據(jù)操作，則FSF與軟件庫一起工作以提供軟件上的各種支持，例如文件軟壓縮、軟件認(rèn)證、文件軟加密和PK，以完成相關(guān)軟件操作，最大程度保證服務(wù)的正常運(yùn)行。

設(shè)備專用驅(qū)動(dòng)程序（DSD）是一個(gè)與芯片組相關(guān)的功能模塊，其主要功能是為Frontsuff服務(wù)框架（FsF）提供統(tǒng)一的硬件接口，并且將每個(gè)設(shè)備的特定結(jié)構(gòu)格式轉(zhuǎn)換為與FSF相同的統(tǒng)一結(jié)構(gòu)。而軟件庫則執(zhí)行軟件中的壓縮、認(rèn)證、加密和公鑰操作等，如果云芯一號(hào)芯片發(fā)生硬件錯(cuò)誤或處于正在從錯(cuò)誤中恢復(fù)的狀態(tài)，或者在系統(tǒng)中沒有可操作的Frontsurf設(shè)備，則軟件庫將作為設(shè)備特定的驅(qū)動(dòng)程序?qū)崿F(xiàn)相關(guān)請(qǐng)求操作，以模擬硬件完成用戶請(qǐng)求。云芯一號(hào)中的軟件庫類似一個(gè)容災(zāi)模塊，為硬件設(shè)備和運(yùn)行軟件部署的運(yùn)行環(huán)境提供最大限度的服務(wù)保障。

2openStack上的塊存儲(chǔ)機(jī)制——Cinder

操作系統(tǒng)獲得存儲(chǔ)空間的方式一般有兩種：①通過某種協(xié)議（sAS、SCSI、SAN、iSCSI等）直接掛接硬件存儲(chǔ)資源（裸硬盤），然后對(duì)Mount上的硬盤進(jìn)行分區(qū)和格式化，最后創(chuàng)建文件系統(tǒng)，或者直接使用裸硬盤對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)（例如大多數(shù)數(shù)據(jù)庫）;②通過NFS、CIFS等協(xié)議，掛載遠(yuǎn)程的文件系統(tǒng)到本地進(jìn)行數(shù)據(jù)存儲(chǔ)。第一方式也稱為BlockStorage（塊存儲(chǔ)），每個(gè)硬件資源硬盤（即裸硬盤）通常被稱為Volume（卷）;第二種叫作文件系統(tǒng)存儲(chǔ)。NAS和NFS服務(wù)器以及各種分布式文件系統(tǒng)提供的都是這類存儲(chǔ)機(jī)制。

在開源云平臺(tái)openstack中，提供Block storageService的是組件Cinder，其具體功能包括：①提供對(duì)vol-ume從創(chuàng)建到刪除整個(gè)生命周期的管理;②提供原生的REST API給用戶，使其可以在平臺(tái)上對(duì)已有的Volume、Volume Snapchat和Volume Type進(jìn)行查詢和管理;③提供Cinder Scheduler調(diào)度Volume創(chuàng)建請(qǐng)求，合理優(yōu)化存儲(chǔ)資源分配;④通過Cinder Driver架構(gòu)支持多種Back-end（后端）的存儲(chǔ)方式，包括LVM、NFS、CEPH和其它諸如EMC、IBM等商業(yè)存儲(chǔ)商品和方案，其具體架構(gòu)如圖3所示。

Cinder主要包含：①Cinder-api負(fù)責(zé)接收OpenStack的API請(qǐng)求，然后調(diào)用Cinder-volume執(zhí)行操作;②Cin-der-volume負(fù)責(zé)管理Colume的各類服務(wù)，并與ColumeProvider協(xié)調(diào)工作以管理Colume資源的生命周期，在OpenStack平臺(tái)中運(yùn)行Cinder-volume服務(wù)的節(jié)點(diǎn)被通常稱作為存儲(chǔ)節(jié)點(diǎn)（storage Node）;③Cinder-scheduler的主要功能是通過調(diào)度算法（可以選擇OpenStack自帶的默認(rèn)調(diào)度機(jī)制或者自己編寫適合的調(diào)度算法）選擇最合適的存儲(chǔ)節(jié)點(diǎn)創(chuàng)建Colume;④Colume Provider則是存儲(chǔ)數(shù)據(jù)的存儲(chǔ)設(shè)備，為Colume的存儲(chǔ)提供空間。OpenStack中的Cin-der組件支持多種Colume Provider，每種Colume Provider都可以通過Driver與Cinder-volume協(xié)調(diào)工作。

在開源OpenStack平臺(tái)中，各節(jié)點(diǎn)之間的通信主要通過Message Queue解決。Cinder中的各子服務(wù)通過Mes-sage Queue實(shí)現(xiàn)進(jìn)程間的通信和相互協(xié)作。有了消息隊(duì)列，子服務(wù)之間才實(shí)現(xiàn)了解耦，這種松散的結(jié)構(gòu)也是分布式系統(tǒng)的重要特征。另外，在Cinder組件中，一些配置數(shù)據(jù)和資源元數(shù)據(jù)需要存放到數(shù)據(jù)庫中，一般使用MySQL。而通常情況下，數(shù)據(jù)庫安裝在控制節(jié)點(diǎn)（control Node）上。

3基于云芯一號(hào)的塊存儲(chǔ)加速方案

分析開源云平臺(tái)OpenStack中Cinder組件的價(jià)格和功能可知，在OpenStack平臺(tái)中，對(duì)于非對(duì)象存儲(chǔ)數(shù)據(jù)主要提供存儲(chǔ)空間及其管理和優(yōu)化，而對(duì)數(shù)據(jù)本身進(jìn)入存儲(chǔ)空間前并沒有過多處理和要求。這樣容易造成在數(shù)據(jù)存儲(chǔ)過程中過于被動(dòng)，以及在硬件架構(gòu)上對(duì)原生數(shù)據(jù)沒有任何優(yōu)化從而導(dǎo)致存儲(chǔ)資源使用率過低。鑒于此，本文提出一種基于自主產(chǎn)權(quán)的云芯一號(hào)芯片的塊存儲(chǔ)加速方案，利用芯片對(duì)存儲(chǔ)前的數(shù)據(jù)進(jìn)行預(yù)存儲(chǔ)，從而達(dá)到存儲(chǔ)時(shí)間縮短、存儲(chǔ)效率提升、存儲(chǔ)資源利用率大幅度提高的目的。塊存儲(chǔ)加速方案具體架構(gòu)如圖4所示。

該架構(gòu)主要有3類節(jié)點(diǎn)：控制節(jié)點(diǎn)、計(jì)算節(jié)點(diǎn)和塊存儲(chǔ)節(jié)點(diǎn)。3類節(jié)點(diǎn)由1臺(tái)交換機(jī)通過各自的ethO網(wǎng)卡連接在一起。此外，計(jì)算節(jié)點(diǎn)和塊存儲(chǔ)節(jié)點(diǎn)也通過各自的ethl連接在另外一個(gè)網(wǎng)絡(luò)上（0penStack中通常所說的內(nèi)網(wǎng)）。

在該架構(gòu)中，控制器節(jié)點(diǎn)主要負(fù)責(zé)資源管理和調(diào)度等任務(wù)，此外還包括身份服務(wù)、映像服務(wù)、網(wǎng)絡(luò)管理及各種網(wǎng)絡(luò)虛擬功能和儀表板（Horizon）等服務(wù)?？刂乒?jié)點(diǎn)還支持SQL數(shù)據(jù)庫、消息隊(duì)列和NTP等消息通信等服務(wù)。如果僅用測(cè)試，可以將計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)上的相關(guān)服務(wù)都部署在控制節(jié)點(diǎn)中，形成單節(jié)點(diǎn)的OpenStack架構(gòu)進(jìn)行相關(guān)功能測(cè)試。與之相對(duì)應(yīng)的計(jì)算節(jié)點(diǎn)則主要運(yùn)行與VM資源相關(guān)的Compute服務(wù)，用于部署操作實(shí)例的運(yùn)行環(huán)境和相關(guān)功能。默認(rèn)情況下，Compute Node使用KVM的Hy-pervisor。另外，計(jì)算節(jié)點(diǎn)還運(yùn)行網(wǎng)絡(luò)服務(wù)代理，將實(shí)例連接到虛擬網(wǎng)絡(luò)，并通過安全組為實(shí)例提供防火墻服務(wù)等安全服務(wù)。

該架構(gòu)中，在存儲(chǔ)節(jié)點(diǎn)上加入了自主研發(fā)的云芯一號(hào)加速芯片，塊存儲(chǔ)數(shù)據(jù)通過節(jié)點(diǎn)調(diào)度來到塊存儲(chǔ)節(jié)點(diǎn)實(shí)現(xiàn)存儲(chǔ)。與傳統(tǒng)無預(yù)先處理不同的是，在塊存儲(chǔ)加速架構(gòu)中，數(shù)據(jù)需要先進(jìn)行硬件加速處理，極大降低自身數(shù)據(jù)大小和存儲(chǔ)所需空間。另外，云芯一號(hào)獨(dú)特的軟硬件加速特性，也使得數(shù)據(jù)在加速過程中如遇到硬件資源的非工作情景，也可通過軟件庫中的驅(qū)動(dòng)程序?qū)崿F(xiàn)相關(guān)請(qǐng)求操作，以模擬硬件完成用戶請(qǐng)求，從而達(dá)到軟硬件加速雙重保險(xiǎn)的低風(fēng)險(xiǎn)數(shù)據(jù)壓縮機(jī)制。

4實(shí)驗(yàn)測(cè)試

完成基于云芯一號(hào)在開源云平臺(tái)OpenStack上部署的塊存儲(chǔ)加速方案后，通過實(shí)驗(yàn)對(duì)提出的方案進(jìn)行測(cè)試：①文件壓縮解壓速度對(duì)比實(shí)驗(yàn);②該方案與傳統(tǒng)塊存儲(chǔ)數(shù)據(jù)存儲(chǔ)速度對(duì)比實(shí)驗(yàn)。集群中的各類節(jié)點(diǎn)硬件環(huán)境均為：CPU：Intel（R）Core（TM）i5-4590CPU@3.30GHz;MEM：DDR3-1333MHz 64GB。

4.1壓縮解壓速度測(cè)試

純壓縮測(cè)試是為了對(duì)比傳統(tǒng)基于CPU的各類HDFS軟壓縮特性和基于云芯一號(hào)芯片的硬件壓縮能力。為此測(cè)試了一組隨機(jī)大?。◤淖钚?shù)據(jù)大小7.27MB到最大數(shù)據(jù)大小100MB），總共88132MB數(shù)據(jù)集的壓縮速度。結(jié)果顯示云芯一號(hào)芯片文件壓縮的進(jìn)程壓縮速度在1508.7MB/s（>1500MB/s）左右。同時(shí)，將該數(shù)據(jù)集在傳統(tǒng)HDFS上的各類軟壓縮軟件（GZIP、BZIP2、LAOBEST、LZO）上進(jìn)行了相同實(shí)驗(yàn)，得到壓縮性能對(duì)比如表1所示。

由數(shù)據(jù)對(duì)比可以看出，在處理同樣大小的原始文件時(shí)，云芯一號(hào)芯片對(duì)文件的壓縮大小最小，壓縮和解壓速度比其它軟件壓縮算法平均高近10倍。同時(shí)也發(fā)現(xiàn)，其它軟件算法在文件壓縮大小、壓縮速度、解壓速度3方面都會(huì)出現(xiàn)某一指標(biāo)表現(xiàn)不盡如人意的情況，而云芯一號(hào)芯片卻沒有這種問題，較其它軟件算法，其3個(gè)性能參數(shù)指標(biāo)均最優(yōu)。

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

完成云芯一號(hào)芯片的純壓縮解壓測(cè)試后，對(duì)塊存儲(chǔ)加速方案和傳統(tǒng)塊存儲(chǔ)加速方案的存儲(chǔ)效率進(jìn)行對(duì)比。采用4組不同大小的數(shù)據(jù)集，分別為1G、10G、20G、50G，每組分別測(cè)試3次，取平均值，測(cè)試結(jié)果如圖5所示。

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

為了更直觀地體現(xiàn)壓縮速度對(duì)比，將測(cè)試的隨機(jī)大小文件集群的壓縮速度進(jìn)行了同一坐標(biāo)對(duì)比，如圖6所示?？梢灾庇^地看出，基于硬件加速的云芯一號(hào)芯片的壓縮速度平均在l 500MB/s左右，而其它軟件壓縮文件速度平均在50MB/s以內(nèi)。

5結(jié)語

本文著重研究傳統(tǒng)OpenStack云平臺(tái)中塊存儲(chǔ)的存儲(chǔ)效率和性能，再從存儲(chǔ)空間、存儲(chǔ)調(diào)度上進(jìn)行優(yōu)化，并從數(shù)據(jù)處理平臺(tái)架構(gòu)和硬件環(huán)境加以探索和創(chuàng)新。本文提出基于云芯一號(hào)硬件加速卡的塊存儲(chǔ)加速方案，在傳統(tǒng)的OpenStack Block 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ì)比可知，無論是純文件壓縮還是與傳統(tǒng)OpenStack平臺(tái)Block Storage Node中數(shù)據(jù)的存儲(chǔ)速度進(jìn)行對(duì)比，本文提出的加速方案均遠(yuǎn)優(yōu)于傳統(tǒng)塊存儲(chǔ)方式。