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

王界兵 王文利 董迪馬

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

關鍵詞：OpenStack;塊存儲;云芯一號;硬件壓縮

DOI：10.11907/rjd k.191258

中圖分類號：TP301 文獻標識碼：A 文章編號：1672-7800（2019）012-0089-04

0引言

隨著大數據、互聯網云時代的來臨，云平臺規模不斷擴大，處理的數據量也日益增多，各類應用和數據的處理時間更長，導致云存儲對硬件設備和存儲數據的預壓縮要求也越來越高?，F場可編程邏輯門陣列（FPGA）可以基于硬件資源實現數據的壓縮和解壓，處理速度也是傳統壓縮軟件的數倍。

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

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

1云芯一號

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

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

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

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

設備專用驅動程序（DSD）是一個與芯片組相關的功能模塊，其主要功能是為Frontsuff服務框架（FsF）提供統一的硬件接口，并且將每個設備的特定結構格式轉換為與FSF相同的統一結構。而軟件庫則執行軟件中的壓縮、認證、加密和公鑰操作等，如果云芯一號芯片發生硬件錯誤或處于正在從錯誤中恢復的狀態，或者在系統中沒有可操作的Frontsurf設備，則軟件庫將作為設備特定的驅動程序實現相關請求操作，以模擬硬件完成用戶請求。云芯一號中的軟件庫類似一個容災模塊，為硬件設備和運行軟件部署的運行環境提供最大限度的服務保障。

2openStack上的塊存儲機制——Cinder

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

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

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

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

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

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

該架構主要有3類節點：控制節點、計算節點和塊存儲節點。3類節點由1臺交換機通過各自的ethO網卡連接在一起。此外，計算節點和塊存儲節點也通過各自的ethl連接在另外一個網絡上（0penStack中通常所說的內網）。

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

該架構中，在存儲節點上加入了自主研發的云芯一號加速芯片，塊存儲數據通過節點調度來到塊存儲節點實現存儲。與傳統無預先處理不同的是，在塊存儲加速架構中，數據需要先進行硬件加速處理，極大降低自身數據大小和存儲所需空間。另外，云芯一號獨特的軟硬件加速特性，也使得數據在加速過程中如遇到硬件資源的非工作情景，也可通過軟件庫中的驅動程序實現相關請求操作，以模擬硬件完成用戶請求，從而達到軟硬件加速雙重保險的低風險數據壓縮機制。

4實驗測試

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

4.1壓縮解壓速度測試

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

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

4.2存儲速度對比測試

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

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

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

5結語

本文著重研究傳統OpenStack云平臺中塊存儲的存儲效率和性能，再從存儲空間、存儲調度上進行優化，并從數據處理平臺架構和硬件環境加以探索和創新。本文提出基于云芯一號硬件加速卡的塊存儲加速方案，在傳統的OpenStack Block Storage Node上進行硬件擴充和優化，對存儲數據進入節點前進行壓縮預處理。通過不同環境下的實驗結果對比可知，無論是純文件壓縮還是與傳統OpenStack平臺Block Storage Node中數據的存儲速度進行對比，本文提出的加速方案均遠優于傳統塊存儲方式。