NVMe儲存效能瓶頸的主要來源:檔案系統
NVMe透過改進物理介面、增加命令數量和佇列深度,使儲存基礎設施能夠充分利用快閃記憶體的優勢。但是NVMe也帶來了一個挑戰:NVMe的延遲非常低,它暴露了儲存基礎架構中其他元件的弱點。基礎架構中的任何薄弱環節都會增加延遲並降低NVMe的價值。
檔案系統是儲存基礎架構中的一個問題較大的部分。現在是供應商重新考慮檔案系統架構的時候了,特別是,他們必須修改檔案系統與NVMe儲存的互動方式,以避免成為瓶頸。
Photo by panumas nikhomkhai from
為什麼是檔案系統?
服務於AI和高速工作負載的檔案系統通常是可橫向擴充套件的。一個橫向擴充套件檔案系統由多個儲存伺服器或節點組成,檔案系統聚合這些節點中的內部儲存,將其表示為使用者和應用程式可以訪問的單個儲存池。傳統的檔案系統也可以橫向擴充套件,但它們是序列的,這意味著所有I/O都要經過一個主節點,而AI和高速工作負載很容易將其壓倒,從而造成瓶頸。這些工作負載依賴於一個並行檔案系統結構,該結構允許叢集中的任何節點向使用者或應用程式提供I/O服務,這使得網路效率更加重要。
大多數NVMe儲存系統都是為塊儲存而設計的。因此,它們避免了檔案系統架構的效能開銷。然而,在大多數情況下,檔案系統會被新增到塊儲存系統中,以便這些AI和高速工作負載可以使用它。大多數現代應用程式——尤其是AI、機器學習和大資料分析處理程式——都依賴於檔案系統。
新增了檔案系統的設計良好、基於塊的NVMe儲存系統仍然可能比基於塊的SAS儲存系統快,但是RAW塊儲存和檔案系統控制的儲存之間的效能下降是顯著的。所以,組織需要針對NVMe進行過最佳化的檔案系統。
對於基準測試,應關注什麼
供應商常常會使用幾個檔案系統基準測試來演示其功能。這些測試中的大多數使用帶有並行檔案系統的NVMe塊儲存,供應商可以輕鬆地使用各種配置來使某個引數達到圖表的頂部,然這可能具有一定的誤導性。
例如,在當前的標準效能評估公司SFS 2014基準測試中,頂級供應商在測試環境中的驅動器數量、驅動器型別和儲存節點數量上存在顯著差異。在大多數情況下,硬體供應商試圖透過使用超出需求的硬體來減少檔案系統架構開銷,並將價格推高到超出對於大多陣列織來說較為合理的水平。
真正重要的是硬體和檔案系統對組織的工作負載型別和預算的實施情況,大多數公司沒有無限的資金來建立完美的NVMe-檔案系統組合。IT專業人員應該尋找能夠達到需求的最簡單的配置。
對於檔案系統,應關注什麼
檔案系統效能主要有三個限制因素:
· 檔案系統與儲存節點的通訊效率;
· 檔案系統如何高效地管理連線各個儲存節點的網路,以及如何高效地與客戶端通訊;
· 檔案系統如何有效地管理後設資料訪問。
在大多數現代應用程式環境中,後設資料佔所有I/O的80%以上。
檔案系統通常透過作業系統I/O棧與儲存媒介通訊。大多數高階檔案系統都基於Linux,並透過該堆疊進行通訊,但是Linux堆疊增加了開銷。另一種方法是檔案系統建立自己的I/O通道,以連線到基於NVMe的檔案系統。從檔案系統開發過程來看,與驅動器的直接通訊更加困難,但是它為檔案系統使用者提供了獲得最大效能的最佳機會,而不必使用昂貴的硬體進行過度補償。
檔案系統通常透過使用標準NFS協議與客戶端通訊,但是NVMe有一個網路變體(NVMe- oF),現代檔案系統應該提供軟體支援並行,以及本地NVMe-oF訪問,以便在客戶端上執行。NVMe-oF還可以用於互連各種儲存節點,這樣會使檔案系統更易於訪問,以直連儲存的延遲。
在全NVMe檔案系統架構中,後設資料訪問本質上是快速的,但是後設資料的佈局方式必須是高效的,以便從NVMe的低延遲中獲益。最佳化後設資料效能,需要將其跨越檔案系統叢集中的所有節點,這樣就不會出現單個節點的效能瓶頸。
如何充分利用NVMe
與其他型別的工作負載相比,AI和高速負載可以更充分地利用NVMe。這些工作負載的挑戰通常是應用程式透過檔案系統訪問儲存,傳統的檔案系統沒有為基於NVMe的驅動器最佳化它們的I/O。更快的節點硬體和NVMe驅動器提供了更好的效能,但是傳統檔案系統的架構無法使硬體充分發揮其潛力。
為了避免這個問題,需要尋找直接寫入NVMe驅動器而不是透過作業系統I/O堆疊的檔案系統。還要尋找能夠讓客戶端跨NVMe-oF進行通訊的檔案系統,並以不影響效能的方式管理後設資料。
原文作者:George Crump 來源:TechTarget
來自 “ TechTarget ”,原文連結:http://blog.itpub.net/31545805/viewspace-2636402/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 打破儲存效能瓶頸,杉巖資料為AI提速增效AI
- 各種儲存效能瓶頸場景的分析與最佳化手段
- 基於 NVMe SSD 的分散式檔案儲存 UFS 效能提升技術解析分散式
- 杉巖資料物件儲存替換IBM FileNet,突破效能瓶頸物件IBM
- 在Linux中,如何進行系統效能瓶頸分析?Linux
- 效能分析(6)- 如何迅速分析出系統 CPU 的瓶頸在哪裡
- 04 磁碟儲存和檔案系統
- 使用 sar 和 kSar 來發現 Linux 效能瓶頸Linux
- 打破Kafka帶來的瓶頸?Kafka
- Linux命令----分析系統I/O的瓶頸Linux
- 大資料檔案儲存系統HDFS大資料
- docker檔案系統分層儲存原理Docker
- 效能測試瓶頸調優
- 資料庫叢集伺服器系統效能瓶頸分析(zt)資料庫伺服器
- JVM 效能調優實戰之:一次系統效能瓶頸的尋找過程JVM
- 如何正確定義效能瓶頸
- 用 pprof 找出程式碼效能瓶頸
- 利用PerfDog分析遊戲效能瓶頸遊戲
- Chrome執行時效能瓶頸分析Chrome
- 本地儲存-系統和保留-系統檔案佔用儲存空間過大的解決方式
- 如何實現檔案傳輸系統的多儲存
- 必須掌握的分散式檔案儲存系統—HDFS分散式
- 流量高峰時期的效能瓶頸有哪些、以及如何來解決
- 實用技巧:快速定位Zuul的效能瓶頸Zuul
- 塊儲存 檔案儲存 物件儲存物件
- 如何迅速分析出系統CPU的瓶頸在哪裡?
- 阿里雲檔案儲存CPFS正式商業化,提供雲上高效能並行檔案系統阿里並行
- [資料庫系統]儲存和檔案結構資料庫
- Laravel 整合 GitHub 來儲存檔案.mdLaravelGithub
- 分散式檔案儲存系統 fastdfs 的 Composer 包釋出!分散式AST
- 效能課堂-TPS 瓶頸精準定位
- LightDB資料庫效能瓶頸分析(一)資料庫
- 檔案儲存
- 資料儲存--檔案儲存
- AI系統有助突破醫藥研發瓶頸AI
- 將座標系統儲存為一個檔案.prj
- Hadoop 基石HDFS 一文了解檔案儲存系統Hadoop
- vivo 軒轅檔案系統:AI 計算平臺儲存效能最佳化實踐AI