共計 4142 個字符,預計需要花費 11 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關為什么需要關注 Ceph,丸趣 TV 小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
為什么需要關注 Ceph
在目前開源世界里多樣的存儲項目中,不同的項目都有側重點,而它們最終都是要為企業的 IT 基礎設施服務。那么企業 IT 基礎設施經理們到底需要怎么樣的存儲,它們的需求得到滿足了嗎?作者嘗試根據對企業級存儲產品的調研歸納出如下圖。
圖一
從上圖我們可以了解到存儲接口需求、擴展、運維和成本構成了企業級存儲產品的四大中心。幾乎所有的存儲產品包括硬件 (存儲一體機,SAN) 和軟件都致力于在這個方面強調自己的優勢,它們或者考慮成本,或者強調擴展性。那么我們來看 Ceph 它是如何定位自己的。
圖二
Ceph 通過其三大存儲接口滿足了企業的多樣需求,通過其建立之初就”大肆宣揚”的擴展性,通過其分布式架構和致力于 PB 級規模存儲目標的容錯性建立了自己的需求矩陣。
圖四
上圖也是 Ceph 可以帶來的企業 IT 架構方案的變革,在了解到 Ceph 提供的特性后,如何達到并實現是每個不熟悉 Ceph 的人迫切需要了解的。
Ceph 的架構
還是下圖這張經典的 Ceph 模塊架構圖。
圖五
底層是 Rados,也是 Ceph 實現分布式存儲的根本,所有存儲接口都是基于 Rados 實現的。Rados 本身就是一個對象存儲接口,它自身維護了一個集群狀態和實現了數據分發的要求,我們通常也講 Rados 稱為 Ceph Cluster,因為其上的存儲接口如 CephFS 都是基于其上的接口實現而已。
為什么底層是對象存儲模型?
與使用固定塊大小存儲比較,名字可以在一個扁平的命名空間里,可以采用可變的大小并且簡單的 API 就有豐富的語義。
與使用文件存儲比較,不需要難以分布的樹形層次,上傳語義不能跨越對象,不能并行化。
RADOS 的組件有哪些?
OSD: 每一個 disk、SSD 或者 RAID group 或者其他一個物理存儲設備都成為一個 OSD,主要負責存儲和查找對象,并且負責向該對象的復制節點分發和恢復。
Monitor: 維護集群的成員和狀態,提供強一致性的決策(類似于 Zookeeper 的作用)
RADOS 分發策略–CRUSH 算法
圖六
從上圖的流程中作者嘗試解讀 RADOS 是如何將對象分發到不同的 OSD 上(OSD),首先需要了解 Ceph 定義的幾個存儲區域概念。Pool 是一個命名空間,客戶端向 RADOS 上存儲對象時需要指定一個 Pool,Pool 通過配置文件定義并可以指定 Pool 的存儲 OSD 節點范圍和 PG 數量。PG 是 Pool 內部的概念,是對象和 OSD 的中間邏輯分層,對象首先會通過簡單的 Hash 算法來得到其存儲的 PG,這個 PG 和對象是確定的。然后每一個 PG 都有一個 primary OSD 和幾個 Secondary OSD,對象會被分發都這些 OSD 上存儲,而這個分發策略稱為 CRUSH—Ceph 的數據均勻分布的核心。需要注意的是整個 CRUSH 以上的流程實現都是在客戶端計算,因此客戶端本身需要保存一份 Cluster Map,而這是從 Monitor 處獲得。從這里我們也可以了解到 Monitor 主要職責就是負責維護這份 Cluster Map 并保證強一致性。
CRUSH 通過偽隨機算法來確保均勻的數據分布,它的輸入是 PG,Cluster State 和 Policy,并且保證 CRUSH 的 Object Name 一樣的情況下,即使后兩者參數發生改變也會得到一致的讀取(注意是讀取)。并且這個 CRUSH 算法是可配置的,通過 PG Number 和 Weight 的指定可以得到不同的分布策略。這個可配置的分布策略讓 Ceph 的能力得到極大加強。
圖七
Ceph 的使用場景 Librados
圖八
首先回顧之前看到的整個架構圖,在上述文中我們了解了 RADOS 的原理和作用,然后我們聚焦在 Librados,Librados 提供了對 RADOS 的直接訪問。librados 提供對 C、C++、Java、Python、Ruby 和 PHP 的支持。
圖九
librados 和之后提到的 RADOSGW 的不同在于它是直接訪問 RADOS,沒有 Http 協議的負載。它支持單個單項的原子操作如同時更新數據和屬性、CAS 操作,同時有對象粒度的快照操作。它的實現是基于 RADOS 的插件 API,因此,其實際上就是在 Rados 上運行的封裝庫。
RadosGW
圖十
從上圖可以看到 RadosGW 位于 Librados 之上,它主要提供 RESTful 接口并且兼容 S3、Swfit 的接口。同時 RadosGW 提供了 Bucket 的命名空間 (類似于文件夾) 和賬戶支持,并且具備使用記錄用于賬單目的。相對的,它增加了 Http 協議的負載。
RadosGW 可以提供將 Ceph Cluster 作為分布式對象存儲的能力,如 Amazon 的 S3 范圍,Swift 等。企業也可以直接使用其作為媒體數據存儲,分發等。
RBD
塊存儲是 Ceph 的另一大支撐點,它目前可以為虛擬機和主機 (Host) 提供不同路徑的塊存儲。
圖十一
上圖為 Ceph Cluster 為虛擬機提供塊設備支持。LibRBD 是基于 Librados 的塊設備接口實現,主要將一個塊設備映射為不同的對象來實現。通過 LibRBD 可以創建一個塊設備(Container),然后通過 QEMU/KVM Attach 到 VM 上。通過 Container 和 VM 的解耦使得塊設備可以被綁定到不同的 VM 上。
圖十二
上圖為 Ceph Cluster 為主機提供塊設備支持,通過 RBD Kernel Module(rbd.ko)為主機提供塊設備。這里有一個與上述不同之處在于 Librados 是內核模塊而模塊名稱為(libceph)。這是因為 RBD 內核模塊需要利用同樣位于內核空間的 Librados。從這里我們可以了解到,實際上 Ceph 維護了數量非常多的 Library,而實際上質量是層次不齊的,這需要了解 Ceph 的人去合理使用。正是因為如何多樣的 Library 也使得 Ceph 的存儲接口得到多樣化,而不是讓不同的存儲接口勉強實現。不同的存儲接口具有完全不同的路徑。
以上兩種方式都是將一個虛擬的塊設備分片存儲在 RADOS(Ceph Cluster)中,都會利用利用數據條帶化提高數據并行傳輸,都支持塊設備的快照,COW(Copy-On-Write)克隆。最重要的是 RBD 還支持 Live migration。目前的 OpenStack,CloudStack 都采用第一種方式為虛擬機提供塊設備。
圖十三
圖十四
上述圖示也表明了在大量 VM 的情況下如何使得存儲容量利用的最小化和高效性。當大量 VM 基于同一個 Snapshot 建立 Volume 時,所有容量不會立即得到占用,而都是 COW。這個特征也是目前眾多存儲廠商在 VDI 解決方案一直強調的。在 VDI 解決方案中,存儲成本是最重要的一環,利用 Ceph 通過 Thin provisioning 和數據并行化可以大大提高 VDI 方案的吸引力。
目前 Ceph 的塊存儲是大力推薦并且高速開發的模塊,因為它提供的接口對于用戶更加熟悉,并且在目前流行的 OpenStack 和 CloudStack 中可以得到廣泛接受和支持。Ceph 塊存儲的計算和存儲解耦、Live migration 特性、高效的快照和克隆 / 恢復都是引入注目的特性。
CephFS
CephFS 是基于 Rados 實現的 PB 級分布式文件系統,這里會引入一個新的組件 MDS(Meta Data Server),它主要為兼容 POSIX 文件系統提供元數據,如目錄和文件元數據。同時,MDS 會將元數據也存在 RADOS(Ceph Cluster)中。元數據存儲在 RADOS 中后,元數據本身也達到了并行化,大大加強了文件操作的速度。需要注意的是 MDS 并不會直接為 Client 提供文件數據,而只是為 Client 提供元數據的操作。
圖十五
從上圖可以看到,Client 當 Open 一個文件時,會查詢并更新 MDS 相應的元數據如文件包括的對象信息,然后再根據提供的對象信息直接從 RADOS(Ceph Cluster)中直接得到文件數據。
圖十六
CephFS 既然是分布式文件系統,當面對不同的文件熱點和大小時,它需要提供數據負載均衡來避免 MDS 的熱點。通過上圖我們可以看到五個 MDS 管理著不同“面積”的目錄樹,因為不同文件的訪問熱點和大小的原因來進行動態調整。
這里還需要介紹引入 MDS 帶來的好處有目錄列表操作的加快,如目錄下文件大小、數量和時間等。同時,支持對文件的快照。
目前 CephFS 有多種使用方式:
1. Linux Kernel client: 使用”mount -t ceph 8.8.8.8:/ /mnt”可以直接掛載到本地并訪問。
2. ceph-fuse: 通過 ceph-fuse 可以從用戶態空間掛載 CephFS 如”ceph-fuse -m 192.168.0.1:6789 /home/username/cephfs”
3. libcephfs.so: 通過 libcephfs 可以替代 HDFS 來支持不同 Hadoop 乃至 HBase。
Ceph 的其他
QoS 機制: Ceph Cluster 支持多種 QoS 配置,如集群重平衡,數據恢復的優先級配置,避免影響正常的數據通信。
Geo-replication: 基于地理位置的對象存儲
OpenStack: Ceph 目前在大力融合入 OpenStack,OpenStack 的所有存儲 (除數據庫外) 都可以將 Ceph 作為存儲后端。如 KeyStone 和 Swfit 可以利用 RadosGW,Cinder、Glance 和 Nova 利用 RBD 作為塊存儲。甚至所有 VM 的 Image 都存儲在 CephFS 上。
目前 Ceph 的優化點也非常多,目前 Rados IO 路徑過于復雜,線程管理得不到有限控制,如果在 Rados 上優化 Small IO 的性能,Ceph Cluster 的集群性能會得到極大提高。很多人也會擔心 Ceph 實現了如此多樣的存儲接口會不會一定降低每一個接口的性能要求。但從架構上來說,Ceph 的 RADOS 只是一個單純的分布式存儲機制,其上的接口看到的都是一層統一的存儲池,接口實現互相分離而不影響。
關于“為什么需要關注 Ceph”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。