歡迎光臨
每天分享高質量文章

詳解Ceph資料是如何佈局的?

Ceph專案始於2004年,是為優秀的效能、可靠性和可擴充套件性而設計的統一的分散式儲存系統。

在使用RADOS系統時,客戶端程式透過與OSD或者Monitor的互動獲取ClusterMap,然後直接在本地進行計算,得出物件的儲存位置後,便直接與對應的OSD通訊,完成資料的各種操作。可見,在此過程中,只要保證ClusterMap不頻繁更新,則客戶端顯然可以不依賴於任何元資料伺服器,不進行任何查表操作,便完成資料訪問流程。

在RADOS的執行過程中,Cluster Map的更新完全取決於系統的狀態變化,而導致這一變化的常見事件只有兩種(OSD出現故障或者RADOS規模擴大)。而正常應用場景下,這兩種事件發生的頻率顯然遠遠低於客戶端對資料進行訪問的頻率。

OSD依賴底層檔案系統Xattrs來記錄物件狀態和元資料,Xattr必須提供足夠的容量大小,ext4僅4KB,xfs 64KB,而btrfs沒有限制,Btrfs不夠穩定,ext4 Xattr太小,生產部署推薦xfs測試推薦btrfs

  • Client:部署在Linux伺服器上,實現資料切片,透過Crush演演算法定位物件位置,併進行物件資料的讀寫。

  • OSD:儲存資料,處理資料複製,恢復,回填,重新調整,並向Monitor報告一些檢測資訊。單叢集至少需要2個OSD,一般情況下一個OSD對應一塊物理硬碟,部署btrfs、xfs或ext4的本地檔案系統。

  • Monitor:實現OSD叢集的狀態監控,維護OSD(守護行程)對映,分組(PG)對映,和CRUSH對映。

  • Metadata Cluster:元資料叢集,用於管理檔案元資料,僅CephFS需要。

 

Ceph系統的邏輯架構和概念對理解資料佈局和架構十分重要,所以有必要在此進行說明。

  • 一個Cluster可邏輯上劃分為多個Pool。

  • 一個 Pool 包含若干個邏輯PG(Placement Group),同時可定義Pool內的副本數量。

  • 一個物理檔案會被切分為多個Object。

  • 每個Object會被對映到一個PG,一個PG內可包含多個Object。

  • 一個PG對映到一組OSD,其中第一個OSD是主(Primary),其餘的是從(Secondary),承擔相同PG的OSD間透過心跳來相互監控存活狀態。

  • 許多 PG 可以對映到某個OSD。

  • 引入PG的概念後,OSD只和PG相關,簡化了OSD的資料儲存;同時實現了Object到OSD的動態對映,OSD的新增和故障不影響Object的對映。

在Ceph的現有機制中,一個OSD平時需要和與其共同承載同一個PG的其他OSD交換資訊,以確定各自是否工作正常,是否需要進行維護操作。由於一個OSD上大約承載數百個PG,每個PG內通常有3個OSD,因此,一段時間內,一個OSD大約需要進行數百至數千次OSD資訊交換。

然而,如果沒有PG的存在,則一個OSD需要和與其共同承載同一個Object的其他OSD交換資訊。由於每個OSD上承載的Object很可能高達數百萬個,因此,同樣長度的一段時間內,一個OSD大約需要進行的OSD間資訊交換將暴漲至數百萬乃至數千萬次。而這種狀態維護成本顯然過高。

 

資料定址流程可分三個對映過程,首先要將使用者要操作的File,對映為RADOS能夠處理的Object。就是簡單的按照Object的Size對File進行切分,相當於RAID中的條帶化過程。接著把Object對映到PG,在File被對映為一個或多個Object之後,就需要將每個Object獨立地對映到一個PG中去。第三次對映就是將作為Object的邏輯組織單元的PG對映到資料的實際儲存單元OSD。

 

1.File ->Object對映

這次對映的目的是,將使用者要操作的File,對映為RADOS能夠處理的Object。其對映十分簡單,本質上就是按照object的最大size對file進行切分,相當於RAID中的條帶化過程。這種切分的好處有二。

  • 一是讓大小不限的File變成最大Size一致、可以被RADOS高效管理的Object。

  • 二是讓對單一File實施的序列處理變為對多個Object實施的並行化處理。

2.Object -> PG對映

在File被對映為一個或多個Object之後,就需要將每個Object獨立地對映到一個PG中去。這個對映過程也很簡單,如圖中所示,其計算公式是(Hash(OID) & Mask -> PGID)。

3. PG -> OSD對映

第三次對映就是將作為Object的邏輯組織單元的PG對映到資料的實際儲存單元OSD。如圖所示,RADOS採用一個名為CRUSH的演演算法,將PGID代入其中,然後得到一組共N個OSD。這N個OSD即共同負責儲存和維護一個PG中的所有Object。

1.File —— 此處的file就是使用者需要儲存或者訪問的檔案。對於一個基於Ceph開發的物件儲存應用而言,這個file也就對應於應用中的“物件”,也就是使用者直接操作的“物件”。將使用者操作的File切分為RADOS層面的Object,每個Object一般為2MB或4MB,大小可設定。

2. Ojbect —— 此處的object是RADOS所看到的“物件”。Object與上面提到的file的區別是,Object的最大Size由RADOS限定(通常為2MB或4MB),以便實現底層儲存的組織管理。因此,當上層應用向RADOS存入Size很大的File時,需要將File切分成統一大小的一系列Object(最後一個的大小可以不同)進行儲存。為避免混淆,在本文中將儘量避免使用中文的“物件”這一名詞,而直接使用File或Object進行說明。每個Object透過雜湊演演算法對映到唯一的PG。

3. PG(Placement Group)—— 顧名思義,PG的用途是對Object的儲存進行組織和位置對映。具體而言,一個PG負責組織若干個Object(可以為數千個甚至更多),但一個object只能被對映到一個PG中,即,PG和object之間是“一對多”對映關係。同時,一個PG會被對映到N個OSD上,而每個OSD上都會承載大量的PG,即,PG和OSD之間是“多對多”對映關係。在實踐當中,N至少為2,如果用於生產環境,則至少為3。一個OSD上的PG則可達到數百個。

事實上,PG數量的設定牽扯到資料分佈的均勻性問題。關於這一點,下文還將有所展開。每個PG透過CRUSH演演算法對映到實際儲存單元OSD,PG和OSD間是多對多的對映關係.

 

4. OSD —— 即Object Storage Device,OSD的數量事實上也關係到系統的資料分佈均勻性,因此其數量不應太少。在實踐當中,至少也應該是數十上百個的量級才有助於Ceph系統的設計發揮其應有的優勢。OSD在物理上可劃分為多個故障域(機房、機架、伺服器),可透過策略配置使PG的不同副本位於不同的故障域中。

關於Ceph技術文章,請搜尋參閱本號歷史相關發文。另外,筆者對之前的Ceph分析文章進行了更新,具體透過原文連結檢視“Ceph技術架構、生態和特性詳細對比分析(第2版)”詳情。

溫馨提示:

請搜尋“ICT_Architect”“掃一掃”二維碼關註公眾號,點選原文連結獲取更多技術文章

求知若渴, 虛心若愚

贊(0)

分享創造快樂