王界兵 王文利 董迪馬

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

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

DOI：10.11907/rjd k.191258

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

0引言

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

目前，業(yè)內(nèi)主流的軟件類無損壓縮算法有算術(shù)編碼、霍夫曼編碼和字典式的Lz系列編碼等。基于統(tǒng)計學(xué)模型開發(fā)的算術(shù)編碼壓縮比最高，但其基于現(xiàn)有硬件實現(xiàn)解壓縮的方式卻很復(fù)雜。與以上兩種壓縮方法不同，基于字典式的LZ系列算法的壓縮和解壓縮過程并不對稱，解壓縮過程比壓縮過程簡單很多，易于硬件實現(xiàn)，且該算法的實現(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è)軟件里也實現(xiàn)了一種基于LZ77的算法，用來壓縮其配置文件。

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

1云芯一號

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

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

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

SAI模塊主要為其它模塊提供基礎(chǔ)服務(wù)，主要由OS抽象層（0SAL）、日志和文件解析器3個組件組成。對于API層，云芯一號提供Raw加速（原始）API對用戶的各類應(yīng)用程序進(jìn)行連接。Raw Acceleration API可以利用Cloud-Core VI.O上的所有功能，包括文件壓縮、文件加密、身份認(rèn)證、RNG和PK等各項操作。Frontsurf ServiceFramework（FsF）模塊的功能是為云芯一號的API層提供算法加速。在Cloud-Core VI.O中，所有與芯片組無關(guān)的代碼都位于Frontsurf服務(wù)框架中。與之相反，所有與芯片組相關(guān)的代碼位于設(shè)備專用驅(qū)動程序中。另外，F(xiàn)rontsuff服務(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)的功能模塊，其主要功能是為Frontsuff服務(wù)框架（FsF）提供統(tǒng)一的硬件接口，并且將每個設(shè)備的特定結(jié)構(gòu)格式轉(zhuǎn)換為與FSF相同的統(tǒng)一結(jié)構(gòu)。而軟件庫則執(zhí)行軟件中的壓縮、認(rèn)證、加密和公鑰操作等，如果云芯一號芯片發(fā)生硬件錯誤或處于正在從錯誤中恢復(fù)的狀態(tài)，或者在系統(tǒng)中沒有可操作的Frontsurf設(shè)備，則軟件庫將作為設(shè)備特定的驅(qū)動程序?qū)崿F(xiàn)相關(guān)請求操作，以模擬硬件完成用戶請求。云芯一號中的軟件庫類似一個容災(zāi)模塊，為硬件設(shè)備和運行軟件部署的運行環(huán)境提供最大限度的服務(wù)保障。

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

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

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

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

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

3基于云芯一號的塊存儲加速方案

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

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

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

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

4實驗測試

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

4.1壓縮解壓速度測試

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

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

4.2存儲速度對比測試

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

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

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

5結(jié)語

本文著重研究傳統(tǒng)OpenStack云平臺中塊存儲的存儲效率和性能，再從存儲空間、存儲調(diào)度上進(jìn)行優(yōu)化，并從數(shù)據(jù)處理平臺架構(gòu)和硬件環(huán)境加以探索和創(chuàng)新。本文提出基于云芯一號硬件加速卡的塊存儲加速方案，在傳統(tǒng)的OpenStack Block Storage Node上進(jìn)行硬件擴(kuò)充和優(yōu)化，對存儲數(shù)據(jù)進(jìn)入節(jié)點前進(jìn)行壓縮預(yù)處理。通過不同環(huán)境下的實驗結(jié)果對比可知，無論是純文件壓縮還是與傳統(tǒng)OpenStack平臺Block Storage Node中數(shù)據(jù)的存儲速度進(jìn)行對比，本文提出的加速方案均遠(yuǎn)優(yōu)于傳統(tǒng)塊存儲方式。