分布式儲存,spdk繞開核心的方案有前途嗎?

時間 2021-05-08 08:23:44

1樓:黃瓜瓜

其實spdk包括RDMA,在系統效能提公升方面絕對是個好東西,基本能把單路延遲提公升到乙個可觀的資料。

但是問題在針對spdk/rdma的機器適配,機房機架的替換改造,還有對於有經驗工程師的招聘的成本所帶來的成本提公升,對於中小企業甚至有營收負擔的大部門來說,都是不小的壓力。

任何分布式系統都得考慮平衡效能與成本啊……

2樓:任弘迪

取決於核心的迭代速度。如果 io uring 能比較快地接過 epoll, aio 的大旗達到跟 spdk, dpdk 相當的效能,那就沒有前途。

不過長期來看乙個泛用,穩定的底層軟體方案總是能由核心實現的。核心本身不就是這類軟體的集合麼。

3樓:傑特JET

這個問題我也一直在思考,談下我最近的感想:

儲道在2023年做過乙個ppt,講我們之前依託SATA盤構建的儲存系統,能否完全發揮出NVMe SSD的高效能。

在這樣的系統中,IO的瓶頸進行了轉移,磁碟系統中面臨的問題很多已經不復存在,NVMe SSD新的問題擺在了面前。如何通過軟體的手段充分發揮SSD的效能和效率?如何解決IO瓶頸問題?

如何應對快閃儲存器儲存本身的新問題?如何突破傳統匯出介面的瓶頸問題?如何在快閃儲存器儲存系統中實現傳統儲存功能,並與現有系統相容?

這些都是快閃儲存器儲存系統設計過程中需要考慮的問題,同樣也是系統設計過程遇到的種種挑戰。

下面這張PPT我印象非常深刻

可見,當IO瓶頸得到改善後,計算機系統其他的軟肋越發的被人們重視。因此也導致近幾年軟硬體技術突飛猛進,從儲存到網路,新的技術可以說改變了儲存系統的生態。

PPT中提到各個瓶頸點,每乙個都值得我們工程師去認真思考,各家大廠也都在這方面有很多研究成果,開源、閉源方案也是數不勝數。

而spdk/dpdk作為軟體解決方案,它通過高效能使用者態輪詢設計理念加上驅動的配合、協議棧的支援,彌補了很多上文PPT中提到的缺陷(之前是乙個公司很多人攻關乙個瓶頸點,效果還不一定很顯著。現在是乙個spdk給你,告訴你這麼多瓶頸都解決了)。並且由於它是開源的,任何企業和個人,都可以比較輕鬆的參與其中,並且以較低的研發代價、不需要專業硬體的配合,就可以達到較高的效能。

經過這麼多個版本的迭代,spdk的軟體棧越來越全,支撐的場景越來越多,這對大家都是好事。所以大家也都願意參與到spdk的開發過程中,為上游做貢獻。

在此吐槽一些硬體廠商,打著」軟硬體協同「的旗號,但自己的軟體解決方案都是乙個個黑盒,而且這些閉源軟體背後的設計理念,卻spdk差不多,甚至直接把spdk拿來用。難怪大廠都想自己設計硬體...

至於說繞開核心這個技術點,應該說不是用不用,有沒有前途的問題,而是未來能發展成什麼樣。目前iouring的開發者Jens已經測試出iouring在某些場景下效率高於spdk,我們不妨把iouring看作是核心發現大家都想繞開我,之後的乙個補救措施...

作為儲存人,設計儲存系統,肯定要將IO鏈路優化到極致。現在的高效能儲存大多離不開以spdk/rdma為代表的高效能方案。但並不是說有spdk/rdma就夠了。

現在雲上的環境越來越複雜,客戶的要求也越來越高,由此帶來的一致性、高併發等問題更是對儲存系統提出了更高的要求。吾輩當共勉之。

NVMe快閃儲存器儲存系統設計挑戰-儲存之道-51CTO部落格

2023年4月補充:

傑特JET:什麼是SPDK,以及什麼場景需要它

4樓:

要回答這個問題,首先要看看為什麼dpdk/spdk這類使用者態協議棧有更低的延遲。

最初的計算機是不分核心態和使用者態的,乙個程式需要使用某裝置時,會獨佔這個裝置,並通過輪詢的方式檢查是否接收到新的資料報文。這樣的好處是處理器可以在第一時間處理資料報文以實現最低的延遲。壞處之一就是裝置被某個程式獨佔,從而導致其它程式只能等待。

為了解決這個問題(當然也非僅為解決這個問題),人們把作業系統分為了核心和使用者態,僅允許核心直接訪問裝置,使用者態程序則通過核心共享裝置。每當裝置接收到乙個資料報文時,會以中斷的形式通知CPU,並最終喚醒上層程序進行處理。這樣做的好處是使得多個程序可以同時訪問裝置,壞處則是對於網絡卡這種高速裝置,過於頻繁的中斷會占用過多CPU資源。

於是人們又想到了乙個辦法,當網絡卡收到的資料報文累積到一定程度後才觸發乙個中斷,但代價就是CPU不能在第一時間處理資料報文,導致延遲增加。

回到SPDK。SPDK本質上又回到了獨佔和輪詢裝置的做法,只不過它執行在使用者態而非核心態。簡單的說,就是乙個使用者態程序獨佔該裝置,並不斷的詢問「有資料嗎?

」若有,則立即處理;若無,再繼續問「有資料嗎?」從核心的角度看,該程序跟普通程序並沒什麼區別。

很顯然,如果你確信你只需要這乙個程序訪問該裝置,那麼這麼做也無妨。但倘若你希望多個程序同時訪問該裝置,那麼直接與這個裝置打交道的程序,就不再是乙個業務程序,而是乙個驅動程序,它還需要扮演核心的角色——從裝置獲得資料報文然後傳遞給其他的業務程序。如此一來,使用者態程序呼叫核心所需要的syscall、記憶體複製等開銷,在程序間通訊場景下一點兒省不了。

多說一點。聽說過「微核心」架構嗎?就是把裝置驅動寫入使用者態程序的架構,原理跟上面說的一樣,有乙個驅動程序專門負責與裝置打交道,其他業務程序通過程序間通訊再跟這個驅動程序打交道。

所以裝置驅動程序掛了,確實不影響核心,大不了該裝置用不了了,或者重啟該驅動程序即可。但很顯然,程序間通訊仍然要從核心一進一出,開銷也更大。所以這就是為什麼微核心效能較差的原因。

話說回來。正是因為「程序獨佔裝置」這個大前提,才有了「通過SPDK實現低延遲」的結果。如果不是程序獨佔裝置,效能神話就沒有了。

至於它是否有前途,各人都有各人的看法。只不過我個人不喜歡開歷史倒車。

5樓:

在高併發(數百萬甚至千萬)高速度(50G/100G/200G)場景下,要做到這麼高的效能,一種是軟體路線就是繞過核心降低各種開銷,還有一種硬體路線就是用FPGA/ASIC晶元來加速。貌似硬體方案在接下來的10年裡,會更吃香一些,但是硬體投入成本更高,頭部大廠對效能追求永無止境,又有錢,更傾向走硬體路線。

分布式儲存和傳統儲存哪個更划算?

焱融科技 我們認為,是否划算要從兩個維度。簡單地看,單TB的軟硬體成本是要考慮的 如果基於開源分布式儲存軟體,那直接計算硬體成本就好了 當然,成本裡別忘了計算連線元件的成本,如果選擇傳統儲存,包括必要的HBA卡 光交等,如果選擇分布式儲存,得考慮是否添置交換機等。根據經驗,容量只是3 50TB的儲存...

分布式資料庫計算引擎對分布式儲存系統底座提出了哪些新的技術挑戰?

lemon wonder 我說一下HTAP情況,對於資料庫,TP主要是事務相關,一般底層儲存引擎使用行存,對於AP是分析性,對事務要求沒那麼高,一般用列存,要處理HTAP,那要做到行列混合儲存就很困難。對於儲存引擎,一種是外掛程式型,向MySQL中,SQL和儲存約定好介面,實現介面並直接使用。但是要...

請問,塊儲存,物件儲存,分布式儲存本質區別?

bloomingTony 1 塊儲存可以認為是裸盤,最多包一層邏輯卷 LVM 常見的DAS FC SAN IP SAN都是塊儲存,塊儲存最明顯的特徵就是不能被作業系統直接讀寫,需要格式化為指定的檔案系統 Ext3 Ext4 NTFS 後才可以訪問。優點 讀寫快 頻寬 IOPS 缺點 因為太底層了,不...