SPDK簡介


SPDK(Storage Performance Development Kit)是Intel發布的存儲性能開發工具集。

 

簡介

固態存儲設備正在取代數據中心。目前這一代的閃存存儲,比起傳統的磁盤設備,在性能(performance)、功耗(power consumption)和機架密度(rack density)上具有顯著的優勢。這些優勢將會繼續增大,使閃存存儲作為下一代設備進入市場。

用戶使用現在的固態設備,比如Intel® SSD DC P3700 Series Non-Volatile Memory Express(NVMe)驅動,面臨一個主要的挑戰:因為吞吐量和延遲性能比傳統的磁盤好太多,現在總的處理時間中,存儲軟件占用了更大的比例。換句話說,存儲軟件棧的性能和效率在整個存儲系統中越來越重要。隨着存儲設備繼續發展,它將面臨遠遠超過正在使用的軟件體系結構的風險(即存儲設備受制於相關軟件的不足而不能發揮全部性能),在接下來的幾年中,存儲設備將會繼續發展到一個令人難以置信的地步。

為了幫助存儲OEM(設備代工廠)和ISV(獨立軟件開發商)整合硬件,Inte構造了一系列驅動,以及一個完善的、端對端的參考存儲體系結構,被命名為Storage Performance Development Kit(SPDK)。SPDK的目標是通過同時使用Intel的網絡技術,處理技術和存儲技術來提高突出顯著的效率和性能。通過運行為硬件設計的軟件,SPDK已經證明很容易達到每秒鍾數百萬次I/O讀取,通過使用許多處理器核心和許多NVMe驅動去存儲,而不需要額外卸載硬件。Intel在BSD license許可協議下通過Github分發提供其全部的Linux參考架構的源代碼。博客、郵件列表和額外文檔可以在spdk.io中找到。

 

軟件體系結構概覽

SPDK如何工作?達到這樣的超高性能運用了兩個關鍵技術:運行於用戶態和輪詢模式。讓我們進一步了解這兩個軟件工程術語。

首先,我們的設備驅動代碼運行在用戶態意味着,在定義上驅動代碼不會運行在內核中。避免內核上下文切換和中斷將會節省大量的處理開銷,允許更多的時鍾周期被用來做實際的數據存儲。無論存儲算法(去冗,加密,壓縮,空白塊存儲)多么復雜,浪費更少的時鍾周期總是意味着更好的性能和延遲。這並不是說內核增加了不必要的開銷;相反,內核增加了那些可能不適用於專用存儲堆棧的通用計算用例的相關開銷。SPDK的指導原則是通過消除每一處額外的軟件開銷來提供最少的延遲和最高的效率。

其次,輪詢模式驅動(Polled Mode Drivers, PMDs)改變了I/O的基本模型。在傳統的I/O模型中,應用程序提交讀寫請求后睡眠,一旦I/O完成,中斷就會將其喚醒。PMDs的工作方式不同,應用程序提交讀寫請求后繼續執行其他工作,以一定的時間間隔回頭檢查I/O是否已經完成。這種方式避免了中斷帶來的延遲和開銷,並使得應用程序提高了I/O的效率。在旋轉設備時代(磁帶和機械硬盤),中斷開銷只占整個I/O時間的一個很小的百分比,因此給系統帶來了巨大的效率提升。然而,在固態設備的時代,持續引入更低延遲的持久化設備,中斷開銷成為了整個I/O時間中不能被忽視的部分。這個問題在更低延遲的設備上只會越來越嚴重。系統已經能夠每秒處理數百萬個I/O,所以消除數百萬個事務的這種開銷,能夠快速地復制到多個內核中。數據包和數據塊被立即分發,等待時間減小到最少,使得延遲更低,一致性延遲更多(抖動更少),吞吐量也得到提高。

SPDK由數個子組件構成,相互連接並共享用戶態操作和輪詢模式操作的共有部分。當構造端對端SPDK體系結構時,每個組件被構造用於克服遭遇到的特定的性能瓶頸。然而,每個組件也可以被整合進非SPDK體系結構,允許用戶利用SPDK中使用的經驗和技術來加速自己的軟件。

 SPDK Architecture

SPDK Architecture

我們從下往上構建:

硬件驅動

NVMe Driver:SPDK的基礎組件,這個高優化無鎖的驅動提供了高擴展性,高效性和高性能。

Inter QuickData Technology:也稱為Intel I/O Acceleration Technology(Inter IOAT,英特爾I/O加速技術),這是一種基於Xeon處理器平台上的copy offload引擎。通過提供用戶空間訪問,減少了DMA數據移動的閾值,允許對小尺寸I/O或NTB的更好利用。

后端塊設備

NVMe over Fabrics(NVMe-oF)initiator:從程序員的角度來看,本地SPDK NVMe驅動和NVMe-oF啟動器共享一套共同的API命令。這意味着,比如本地/遠程復制非常容易實現。

Ceph RADOS Block Device(RBD):使Ceph成為SPDK的后端設備,比如這可能允許Ceph用作另一個存儲層。

Blobstore Block Device:由SPDK Blobstore分配的塊設備,是虛擬機或數據庫可以與之交互的虛擬設備。這些設備得到SPDK基礎架構的優勢,意味着零拷貝和令人難以置信的可擴展性。

Linux Asynchrounous I/O(AIO):允許SPDK與內核設備(比如機械硬盤)交互。

存儲服務

Block device abstration layer(bdev):這種通用的塊設備抽象是連接到各種不同設備驅動和塊設備的存儲協議的粘合劑。還在塊層中提供靈活的API用於額外的用戶功能(磁盤陣列,壓縮,去冗等等)。

Blobstore:為SPDK實現一個高精簡的文件式語義(非POSIX)。這可以為數據庫,容器,虛擬機或其他不依賴於大部分POSIX文件系統功能集(比如用戶訪問控制)的工作負載提供高性能基礎。

存儲協議

iSCSI target:建立了通過以太網的塊流量規范,大約是內核LIO效率的兩倍。現在的版本默認使用內核TCP/IP協議棧。

NVMe-oF target:實現了新NVMe-oF規范。雖然這取決於RDMA硬件,NVMe-oF的目標可以為每個CPU核提供高達40Gbps的流量。

vhost-scsi target:KVM/QEMU的功能利用了SPDK NVMe驅動,使得訪客虛擬機訪問存儲設備時延遲更低,使得I/O密集型工作負載的整體CPU負載減低。

 

 

從流程上來看,spdk有數個子構件組成,包括網絡前端、處理框架和存儲后端


前端由DPDK、網卡驅動、用戶態網絡服務構件組成。DPDK給網卡提供一個高性能的包處理框架;網卡驅動提供一個從網卡到用戶態空間的數據快速通道;用戶態網絡服務則破解TCP/IP包並生成iSCSI命令。

處理框架得到包的內容,並將iSCSI命令翻譯為SCSI塊級命令。不過,在將這些命令送給后端驅動之前,SPDK提供一個API框架以加入用戶指定的功能,即spcial sauce(上圖綠框中)。例如緩存,去冗,數據壓縮,加密,RAID和糾刪碼計算等,諸如這些功能都包含在SPDK中。不過這些功能僅僅是為了幫助我們模擬應用場景,需要經過嚴格的測試優化才可使用。

數據到達后端驅動,在這一層中與物理塊設備發生交互,即讀與寫。SPDK包括了幾種存儲介質的用戶態輪詢模式驅動:

NVMe設備;
inux異步IO設備如傳統磁盤;
基於塊地址的內存應用的內存驅動(如RAMDISKS);
可以使用Intel I/O加速技術設備。


四.編譯使用


4.1下載代碼

git clone https://github.com/spdk/spdk.git
git submodule update –init

4.2 編譯dpdk

cd spdk/script
./pkgdep.sh //在編譯之前,需安裝依賴
make install T=x86_64-native-linuxapp-gcc DESTDIR=.

4.3 編譯spdk

cd ..
make DPDK_DIR=./dpdk/x86_64-native-linuxapp-gcc

4.4 配置spdk

./scripts/setup.sh

至此,spdk的基本安裝已經完成,下面要做的就是插入nvme ssd設備並進行測試。測試代碼在examples下。


4.5 實現原理
通過UIO這個的驅動接口,將驅動中共性的一部分放在內核態實現,eal層次通過解析sysfs的相關節點獲取設備信息(bar,function等)傳遞給用戶態的設備模型,之后eal層次用mmap建立內核和用戶空間的數據傳遞通道和同步機制,實現了驅動的用戶態功能實現。
Spdk提供了多種存儲接口(scsi,nvme等)不同層次的操作接口,可以供用戶直接調用完成設備識別,控制,數據傳輸等。
---------------------
原文:https://blog.csdn.net/zlarm/article/details/79140299

 

SPDK不適應所有的存儲體系結構。這里有一些問題可能會幫助用戶決定SPDK組件是否適合你們的體系結構。

這個存儲系統是否基於Linux或FreeBSD?
SPDK主要在Linux上測試和支持。硬件驅動被FreeBSD和Linux支持。

存儲系統的硬件平台是否要求是Intel體系結構?
SPDK被設計為充分利用Intel平台的特性,並針對Intel芯片和系統測試和調整。

這個存儲系統的高性能路徑是否運行在用戶態?
SPDK通過更多地在用戶態下運行從網卡到磁盤的高性能路徑,提高性能和效率。通過將具有SPDK功能(比如NVMe-oF目標,NVMe-oF啟動器,Blobstore)的應用程序結合起來,整個數據通路可能能夠在用戶空間運行,從而提供顯著的高效率。

系統體系結構可以合並無鎖的PMDs到它的線程模型嗎?
因為PMD持續運行在它們的線程中(而不是睡眠或者不用時讓出處理器),所以它們有特殊的線程模型需求。

系統現在是否用DPDK處理網絡數據包的工作負載
SPDK和DPDK共享早期的編程模型,所以現在使用DPDK的用戶可能會發現與SPDK緊密整合非常有用。同樣地,如果正在使用SPDK的用戶為網絡處理添加DPDK功能可能是個重要的機遇。

開發團隊自己是否具有理解和解決問題的專業技能?
Intel沒有為相關軟件提供支持的義務。當Intel和圍繞SPDK的開源社區將付出商業上合理的努力去調出未修改的發布版本軟件的潛在錯誤,任何情況下Intel都沒有任務義務為用戶提供針對該軟件任何形式的維護和支持。

(出處: http://aidaiz.com/spdk/)

 

spdk動機

  市售的基於NVMe硬盤動輒可達到單盤GB級的讀寫帶寬和十萬量級的隨機IOPS,為SATA固態硬盤的5~10倍。然而,由於Linux內核驅動實現與調度機制的限制,一般存儲軟件的表現,相對於NVMe來說,在整個IO事務中消耗的時間百分比就顯得太多了。換言之,主流的軟件定義存儲系統並不能完全釋放其性能,存儲軟件協議棧的性能和效率在存儲整體系統中的地位就顯得越來越關鍵了。

  我們可以把NVMe看做一個硬件進步推動軟件革新需求的例子,隨着后續比它更快的存儲介質投入市場,這種推動力將更為急迫。

spdk基本原理

  SPDK(Storage Performance Development Kit),包含一套驅動程序,以及一整套端到端的存儲參考架構。SPDK的目標是能夠把硬件平台的計算、網絡、存儲的最新性能進展充分發揮出來。自芯片而上進行設計優化,SPDK已展示出超高的性能指標。

  它的高性能實際上來自於兩項核心技術:第一個是用戶態運行,第二個是輪詢模式驅動。

用戶態運行:降低指令周期

  將設備驅動代碼運行在用戶態,是和運行在“內核態”相對而言的。把設備驅動移出內核空間避免了內核上下文切換與中斷處理,從而節省了大量的CPU負擔,允許更多的指令周期用在實際處理數據存儲的工作上。無論存儲算法復雜還是簡單,也無論進行去重(deduplication),加密(encryption),壓縮(compression),還是簡單的塊讀寫,更少的指令周期浪費意味着更好的整體性能。

輪詢模式驅動:

  中斷式IO處理模式:有IO需要處理時就請求一個中斷,CPU收到中斷后才進行資源調度來處理IO,采用的是被動的派發式工作。當硬盤速度上千倍的提高后,將隨之產生大量IO中斷,Linux內核的中斷驅動式IO處理(Interrupt Driven IO Process)就顯得效率不高了。

  定點輪詢(polling)模式:使用專門的計算資源(特定的CPU核)用來主導存儲設備的輪詢式處理——就像專門的出租車道和車流用來處理乘客任務,數據包和塊得到迅速派發,等待時間最小化,從而達到低延時、更一致的延時(抖動變少)、更好的吞吐量的效果。

  關於兩種方式的比較和討論,參考這里...,注意:spdk使用輪詢模式的前提是高性能的磁盤設備,最終是終端驅動處理還是輪詢驅動處理,取決於系統硬件的搭配方式,不同的條件會匹配不同的優化策略

基本組件:

  SPDK中大概有三類子組件:網絡前端、處理框架、后端。

 

圖1 spdk基本架構

網絡前端

  網絡前端子組件包括DPDK網卡驅動和用戶態網絡服務UNS(這是一個Linux內核TCP/IP協議棧的替代品,能夠突破通用TCP/IP協議棧的種種性能限制瓶頸)。DPDK在網卡側提供了一個高性能的發包收包處理框架,在數據從網卡到操作系統用戶態之間提供了一條快速通道。UNS代碼則接續這一部分處理,“crack”了TCP/IP數據包的標准處理方式,並形成iSCSI命令。 

處理框架

  “處理框架”部分拿到了數據包內容,將iSCSI命令轉換為SCSI塊級命令。然而,在它將這些命令發到“后端”驅動之前,SPDK提供了一套API框架,讓廠商能夠插入自己定義的處理邏輯(架構圖中綠色的方框)。通過這種機制,存儲廠商可在這里實現例如緩存、去重、壓縮、加密、RAID計算,或擦除碼(Erasure Coding)計算等功能,使這些功能包含在SPDK的處理流程中。在SPDK的開源軟件包里,會有這些功能的實現樣例。

后端

  數據到達了“后端”驅動層,在這里SPDK和物理塊設備交互(讀和寫操作)。如前所述,SPDK提供了用戶態的PMD[2],支持NVMe設備、Linux AIO設備(傳統spinning硬盤)、RAMDISK設備,以及利用到英特爾I/O加速技術的新設備(CBDMA=3D XPoint?)。這一系列后端設備驅動涵蓋了不同性能的存儲分層,保證SPDK幾乎與每種存儲應用形成關聯。事實上,英特爾在2015年9月首先開源的SPDK部分就主要包含支持NVMe的用戶態輪詢模式驅動。

spdk在ceph中的使用

  Ceph長期以來就其計算資源占用率和性能方面,雖不斷提高,但在閃存環境下仍難覓突破性進展。順應業界趨勢,將SPDK的支持在Ceph中實現勢在必行。

Ceph與SPDK結合架構圖

 (http://www.cnblogs.com/yunlion/p/5742141.html)

 

Blobstore和BlobFS

 

Blobstore的設計目標

Blobstore是由Twitter開發的一個低成本和可擴展的的存儲系統,可以用來存儲圖片以及其他的二進制對象(稱為“blob”-- binary large object, 典型的BLOB是一張圖片或一個聲音文件,由於它們的尺寸,必須使用特殊的方式來處理)。在開始構建Blobstore時,Twitter有三個設計目標:
• 低成本:可以大大減少花費在添加圖片到Tweet中的時間和成本。
• 高性能:圖片延遲保持在幾十毫秒之內,同時保證每秒上千萬張吞吐量的圖片請求。
• 易於操作:隨着Twitter基礎設施的不斷增長,能夠擴展操作開銷。

 

Blobstore是如何進行工作的?
當用戶推送一張照片,就會把照片發送到一組Blobstore前端的服務器。前端服務器解析后會給該照片一個特定的寫地址,接下來將其轉發到具體的服務器進行實際的數據存儲。其實可以把這些存儲服務器稱之為存儲節點,它們把照片信息存儲到一個磁盤上,然后通知元數據存儲——圖像已經存儲完畢並記錄所需要的信息以便進行照片檢索。元數據存儲庫,這是一個非關系型鍵/值存儲集群,它可以自動的進行多數據中心(multi-data-center)的同步功能,更重要的是可以跨所有的Twitter的數據中心,進而在Blobstore上提供的一致性的視圖數據。
Blobstore核心是Blob Manager,它運行在前端,用於存儲節點以及索引集群。Blob Manager充當系統中心“協調員”的角色,對集群進行管理。它是所有前端信息(決定應該把文件存儲到哪個地方)的源。不僅如此,它還負責更新映射,在增加存儲節點或者由於添加失敗節點被移除時,協調數據的遷移。
還有一點比較重要,就是依靠Kestrel。這是Twitter現有的異步隊列服務器,主要用來處理任務,比如說復制圖像以及確保數據中心中數據的完整性。
Twitter確保一旦圖像上傳成功,用戶就可以立即從數據中心中進行讀取,而且絕對是最原始的圖像。而且在如此之短的時間內,圖像已經復制到Twitter所有其他的數據中心之內,並且可以從這些數據中心進行讀取。此功能主要依賴於Blobstore內的多數據中心元數據存儲對文件的中央索引。Twitter高度關注短時間內一個圖像是否被已經被寫入它最初的數據中心,他們使用路由請求,確保該Kestrel隊列能夠進行數據復制。

 

BlobStore和SPSK
BlobStore 的定義是一個持久化的,數據安全的塊設備管理引擎,用來提供一個高層的邏輯 API 來利用塊設備,可以理解為是一個簡陋版的文件系統。
SPDK BlobStore 主要目標是在為 NVME 設備提供一個異步接口,沒有緩存,並行讀寫的 Blob 接口,這個 Blob 可以是任意 block size 對齊的范圍。
SPDK BlobStore 提供了一個相比純粹塊接口,更佳豐富的語意,方便應用使用,同時,它的特點是利用了 SPDK 進行高性能訪問寫入。
跟 BlobStore 一起推出的還有 BlobFS,顧名思義,就是給予 BlobStore 之上,提供一個偽文件系統接口到 RocksDB,因為很難定義這種接口語意,所以 BlobFS 目前只是深度跟 RocksDB 集成。

 

與 GAE (Google App Engine)相關的3種存儲方法
1. Bigtable 使用很簡單,但是它有 1MB 文件大小限制。
2. Blobstore 的大文件最高可以支持 2GB,但是一次 URL 在 Web 服務中很難實現。
3. Google Storage for Developers 是三種 GAE 存儲方法中最強大的一種,但是最復雜,需要付費。
Datastore(即 Bigtable)負責保存一般保存到數據庫的常規數據,而 Blobstore 則負責保存大型的二進制文件。

詳見http://www.uml.org.cn/sjjm/201204054.asp

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM