Categories
程式開發

基於鯤鵬平台的Ceph深度性能調優


隨著IOT、大數據、移動互聯等應用的暴漲,產生的數據也越來越多,整個存儲市場總量也逐年增長,預計到2021年分佈式存儲會占到整個存儲市場的50%,到2027年,分佈式存儲會占到整個市場的70%。 Ceph則是典型的分佈式存儲軟件的代表。

杉岩數據作為一家軟件定義存儲商,軟件的發展與硬件的結合密必不可分,與華為共建ARM生態是杉岩發展的關鍵著力點。目前,杉岩數據的對象存儲MOS和塊存儲USP已完成在鯤鵬平台的適配工作,且可進行商用了,以下是杉岩數據云存儲高級研發工程師劉亮奇在Ceph開發和應用方面的經驗分享。

Ceph是什麼?

基於鯤鵬平台的Ceph深度性能調優 1

在用戶層面,Ceph對外提供的三個服務:

1、Block storage即(RDB塊存儲接口):如同一個沒有格式化的U盤,在第一次接入個人PC時,windows操作系統會彈出一個格式化的請求界面供用戶選擇參數,如比較重要的文件系統選項,有NTFS、exFAT等文件系統以供選擇,格式化完成後的U盤才能進行創建目錄、拷貝文件等操作;形像一點的概括:整個塊設備可以看成一棟大樓的框架,在進入大樓工作生活前,需要對這棟大樓進行裝修,即格式化。而大樓不可能只有一個人,所以需要物業進行管理,物業可以比作一個文件系統。

2、Object storage即(RADOS GW對象存儲):對象存儲在大家的生活中也是接觸較多的,例如我們平常使用的雲盤;或者我們使用的智能手機都有云備份功能,都是基於對象存儲的一種業務表現。所以對象存儲是為了解決信息化時代海量不規則文件的存儲問題。就如世界上沒有兩片相同的葉子,每個人都會產生不同的信息,如何解決這些獨一無二數據的存儲,對象存儲就是提供了一種解決方法。

3、Flie system文件系統:把Ceph提供文件系統服務,類比成購買個人電腦的過程,DIY用戶可能會買各種硬件、零件組裝起來裝上操作系統之後才能使用,而電腦商家還會提供一個已經預裝好windows系統的整機供用戶選擇,用戶購買之後接通電源開機後可直接使用。 Ceph提供的文件系統服務也就類似於這樣的一個整機,用戶只需將對應的目錄掛載到本地即可進行工作。

RGW:對象存儲接口,使用這個接口服務需要配合一些客戶端軟件;當然了,手機上的雲備份功能是因為手機操作系統已經內置了APP進行支撐,所以不需要再額外安裝軟件。

RBD:塊存儲接口,如果使用的是Linux系統,可以使用內核模塊krbd直接在本地直接生成一個塊設備供用戶使用。針對Windows系統,則可以通過iSCSI協議,虛擬一塊硬盤來供用戶使用。

再往下是整個Ceph集群的統一抽象層RADOS,即抽象的對象存儲集群。它是上面的所有接口數據經過處理後都會以對象的形式保存在集群當中。同時RADOS還確保這些接口數據在整個集群中的一致性,而LIBRADOS,主要是訪問RADOS層的接口庫。

接下來是Ceph集群中一些比較重要的組件,如mgr,mirror等,這些組分佈在集群中的各個服務器上,未在上圖中體現。下面簡略說明各個組件的職能:

  • MON:即monitor,可以認為是集群的大腦,負責集群狀態的維護和元數據的管理。

  • MDS:元數據服務,它是為Ceph FS接口服務提供文件層次結構檢索和元數據管理的,如果不需要Ceph FS服務,可以選擇不部署該組件。

  • OSD:對象存儲設備,這是整個集群中用戶數據主要承載的終端設備,用戶所有的數據讀寫請求基本上最終由OSD來負責執行。所以OSD的性能決定了整個上層業務的表現。 OSD一般會綁定一個較大的存儲空間,例如一塊硬盤或一個硬盤分區;而OSD管理存儲空間的本地存儲接口主要有File Store和Blue Store。當然File Store還需要藉助本地文件系統(比如XFS)來管理存儲空間。而Blue Store則可以直接接管裸設備,這樣就可以減少它的IO路徑,以提高性能。

總體來看,Ceph是一個統一的分佈式存儲系統。它的設計目標是較好的性能,可靠性和可擴展性。這是因為從Ceph的架構來看,沒有專門的緩存層,所以在性能表現並不是很理想。社區也針對這個問題一直在推動分級緩存(tier)功能,但這個功能還沒有達到可生產的階段;所以目前比較通用的做法就是在操作系統層面來緩存Ceph數據;如內核的通用塊層使用dm -cache、bcache、enhanceIO等開源軟件,在操作系統層面將數據緩存在一個較高速的設備(如SSD),以此提高Ceph的性能。

Ceph現有架構與業務存在哪些問題?

基於鯤鵬平台的Ceph深度性能調優 2

1、Ceph數據與內核緩存的割裂問題。以BlueStore為例,它將OSD的元數據保存在RockDB中,RockDB又是運行在一個簡化的文件系統(Blue FS)之上的,此時可以認為Blue FS的IO就是OSD的元數據,但對於內核緩存來說,它是無法感知OSD下發的數據是有元數據和業務數據之分的。

2、內核緩存無法區分OSD業務的熱點數據和冷數據,比如用戶配置比較典型的三副本存儲策略,此時只有主副本數據才會為客戶端提供讀寫服務,而從副本則直接不用緩存即可,但是內核層緩存是沒法區分這種差異的。如果使用的是DM Cache,還會在內存中分配一個空間來緩存部分數據,這無還疑會浪費內存資源。

總體來說,內核緩存存在浪費Cache空間,還有Cache命中率不高,頻繁刷新緩存導致緩存設備壽命縮短等缺陷。

有何解決方案?
基於鯤鵬平台的Ceph深度性能調優 3

在BlueStore下發IO的地方增加一個適配層,用來標記下發IO的類型,在內核緩存入口處增加一個適配層,用來捕捉OSD的IO類型,最後在內核緩存處理時,根據IO類型進行不同的寫回、淘汰策略。

例如將三副本中的兩個從副本用NOCACHE標籤經過適配層隨IO請求一起帶到內核緩存裡去,這樣內核緩存就可以不緩存,直接寫後備盤。同時可以將Blue FS的IO標記成元數據類型,讓其在內核緩存更長時間的駐留。或根據用戶業務需求,將用戶有比較重要的,且讀寫頻繁的數據,標為高等級,其他不重要的數據標成中或低等級,然後在內核緩存針對高等級數據採用和元數據一樣的處理策略;這樣就可以根據用戶需求來執行不同的淘汰和回寫策略。
基於鯤鵬平台的Ceph深度性能調優 4

BlueStore使用的是Libaio API接口來下發IO請求,此時需要一個IOCB結構體作為下發請求的IO參數,可以通過io_prep_pwrite函數生成iocb結構體之後,把io flag設置到IOCB的Flag結構體當中,作為io_submit的參數,一起提交至內核層;內核在VFS層時捕捉到Direct io時,將flag轉換到通用塊設備層的BIO結構體裡面,比如BIO的bi_rw結構體裡面,此時位於通用塊層的內核緩存即可捕捉到上層業務標籤。內核緩存可根據不同的標籤執行不同的回寫、分配策略,比如讓元數據更久的駐留在緩存當中,或者讓高等級的用戶數據和元數據執行相同的緩存策略。

Ceph在ARM架構上面臨的問題與挑戰

基於鯤鵬平台的Ceph深度性能調優 5

華為鯤鵬處理器與Intel Xeon主要存在如下六個方面的差異:
1、ARM的跨片訪問:主要反映在內存方面,(數據是估測值,非實測數據,不做測評)。 ARM相對X86來說不佔優勢,所以後面的優化手段中有規避跨片numa的操作。

2、矢量運算方面,未獲取到鯤鵬的具體參數,以ARM的A76作為參考,從目前來看, ARM也是不佔優勢的。

3、物理核數:ARM先天就有物理核數上面的優勢。

4、協處理器:即加速器,在加速器方面鯤鵬920有EC/RSA/zlib等外圍協處理器,相對通用的X86 6148來說是較為豐富,這是鯤鵬920的優勢。

5、內存操作:ARM採用的是load-store的微架構,簡單地理解為:ARM在內存到內存之間的拷貝是需要CPU參與的,X86則可以直接做到不用CPU參與內存到內存間的拷貝。這是ARM微架構決定的。

6、功耗比,單論總體的功耗不太準確,畢竟功耗還跟啟用的物理核數有關係。當然先進的工藝在可以降低功耗。如果論單個物理核的功耗比,ARM確實相對X86是有優勢的。

基於鯤鵬平台的Ceph調優

針對鯤鵬平台的Ceph,目前有以下幾種主流的優化方案:

1、針對跨片NUMA操作場景,限定進程運行在片內NUMA
基於鯤鵬平台的Ceph深度性能調優 6

針對跨片NUMA操作場景,採用將進程限定在片內NUMA上面,以Ceph為例,Ceph M及以後的版本提供一個OSD_numa_node參數,該參數可以限定整個OSD進程所運行的numa。如果使用的是其他版本的ceph,可以藉助numactl和taskset這兩個工具來實現限定進程運行在指定numa的功能。 numactl需要在進程啟動時進行設置,主要的參數有綁分配內存NUMA(–membind)、綁進程運行的NUMA(–cpunodebind),以及更細的,綁進程運行的物理核(–physcpubind)。 Taskset較為靈活,可以在進程運行時進行設置。限定了NUMA之前,對應的硬件都盡量分配在片內的總線下面,比如網卡、內存、SSD等都盡量分配在對應片內總線下面,以避免跨片訪問。

2、矢量運算短板借助協處理器補齊
基於鯤鵬平台的Ceph深度性能調優 7

矢量運算方面可以藉助鯤鵬920的平台的加速器,華為有提供一些基礎設施的接口文檔,可以根據這些文檔進行相應的適配;比如這裡的糾刪碼運算(EC),華為提供的接口文檔有詳細的設置和參數配置,需要在代碼層面上進行適配,此時需要投入工作量,進行穩定性方面的測試。

3、增加進/線程數以及內存操作
基於鯤鵬平台的Ceph深度性能調優 8

利用鯤鵬在物理核上的優勢,可以增加相應處理業務的進程或線程,針對業務繁忙的線程,可以把線程拆分成兩個,分配到不同物理核上去。

內存操作方面,除了減少內存操作,華為還針對ARM微架構出了一個補丁,該補丁主要優化了內存方面的接口,可以去華為的基礎設施網站上下載patch來提升性能。

此外,還有其他優化手段:
基於鯤鵬平台的Ceph深度性能調優 9

  • 綁定網卡/SSD中斷:必須先把irqbalace服務關閉,否則irqbalace服務會將綁定給重新均衡掉。

  • cgroup隔離業務:針對對繁忙的線程或者進程來說是比較有效的,主要是基於CPU cache考慮,如果CPU被切換到不相關的進程和線程的時候,會導致CPU cache刷新,致使命中率下降,CPU cache預讀也會浪費內存帶寬。同時進程CPU一旦被切出,就會導致整個流水線被清空/排空的,此時並發的指令數也會減少,所以對性能還是有影響的。主要還是在業務比較繁忙的時候對性能的改善比較大。

  • 第三方庫:主要是優化內存的分配和回收效率,有Tcmalloc和jemalloc可選,可以去Tcmalloc和jemalloc的網站去下載相關文件進行閱讀。

接下來,為大家介紹三種Ceph性能觀測工具,如下圖所示:
基於鯤鵬平台的Ceph深度性能調優 10

Ceph的OSD perf/perf daemon:這是Ceph自帶的工具,其中OSD perf主要記錄IO讀寫的時延,可以初步判斷到底的瓶頸是否在我們的硬盤上面,如果是,可以採取相應的優化手段。

perf daemon主要是記錄整個IO請求在Ceph內部的一些狀態的處理流程,這些處理流程耗時多少,都會通過這個命令導出,可以進行初步的診斷。

操作系統——Perf工具:比較常用的perf top,顯現當前整個系統的運行情況,如上圖的右上腳,OSD進程顯然是耗費了大量的CPU,可以進行層級下剝,查找到熱點函數位置,再針對性地去優化熱點函數。而perf stat主要是採集進程在一段時間內的總體的情況。還可以使用perf record,記錄數據,後續可以結合FlamGraph生成一個火焰圖,這種火焰圖相對來說比較直觀。主要關註一些平頭的函數調用(圖),因為這裡耗費的cpu時間比重比較大,是優化的目標。

Systemtap:主要在Redhat系統用得比較多。通過採集內核函數、系統調用、用戶函數的運行信息、函數出入口數據等,根據這些採集的數據,進行函數級別的分析。如基於openresty-systemtap-toolkit工具,進行二次開發。通過工具就可以去分析整個系統或者是程序在哪裡有瓶頸點,然後再針對瓶頸點進行性能優化。

優化後的Ceph存儲系統性能如何?

基於鯤鵬平台的Ceph深度性能調優 11

兼容性方面:從開始到結束整個過程沒有遇到比較大的阻塞點,依賴庫和部分技術問題在華為的基礎設施網站上能夠找到解決方法,將Ceph移植到鯤鵬平台上的整個流程較為順利。

優化的性能:基於現有服務器配置進行的優化前後對比,這裡的測試並未鯤鵬CPU的極限,主要的瓶頸點是在硬盤上。主要是展示經過上面介紹的優化方法、手段進行優化後的成果。如表所示,可以看到優化後的性能是有改善的。

低功耗:主要體現在ARM的單物理核的功耗確實比X86要低的,所以在後期運營成本上具備優勢。

下面介紹一下我們的塊存儲產品運行在鯤鵬平台上的狀況,主界面顯示的是整個塊存儲產品集群的狀態,節點信息部分,上面部署了monitor和OSD等組件,這裡的服務器信息可以看出是華為的TaiShan服務器,TaiShan 200(型號2280)的服務器使用的就鯤鵬920的處理器。

其他管理功能,例如捲管理,Linux系統可以通過內核的krbd模塊實現本地掛載,,也可以走iSCSI協議掛載到windows系統上供用戶使用(圖)。當了還有其他的功能,這就不展開了。

未來的展望和計劃

基於鯤鵬平台的Ceph深度性能調優 12

首先是基於TaiShan服務器的一個長遠計劃,例如發布一個基於全閃存場景的產品,這種場景下所有的硬盤性能都比較高,而傳統以太網網絡將是一個瓶頸,現在TaiShan服務器剛好支持RDMA功能,為全閃存場景的部署鋪平了道路,無需額外適配、調優網絡端口了。

seastar對於ARM架構來說,多核競爭中跨片訪問時,性能處於劣勢,此時採用無共享編程的seastar框架,有利於規避ARM跨片訪問的劣勢;seastar架構的改造社區也在積極投入,我們也會持續跟進。

最後是安全存儲產品對數據加解密和解壓縮的處理較為重要,而鯤鵬外圍加速器zlib/rsa/md5/sm3能夠提供高效的數據安全處理流程。

關於強耦合的內核緩存改造後是否需要重新編譯操作系統?不需要,在VFS層時是通過kernel hacking的方式處理I/O的,不需要改動內核原有的邏輯,只需將修改後的KO加載到操作系統就可以處理我們定制的IO了。

為什麼不考慮將緩存做到blue Store裡面? Blue Store在社區當時設計的目標是面向未來全閃存場景的,是沒有考慮過混合場景的;而且混合場景只是一個過渡階段,並不長遠,所以社區在設計時就沒有考慮過加緩存;如果將緩存做到Blue Store的話,是與社區設計理念相悖,同時導致整個Blue Store處理異常複雜;無論是以後跟進社區還是向社區推送改動都比較麻煩。

分享嘉賓信息:
基於鯤鵬平台的Ceph深度性能調優 13

演講精彩視頻

(或者短鏈接