-
一、元數據和元數據管理
- （1）元數據
在學習Ceph之前，需要了解元數據的概念。元數據又稱為中介數據、中繼數據，為描述數據的數據。主要描述數據屬性的信息，用來支持如指示存儲位置、歷史數據、資源查找、文件記錄等功能。通俗地說，就 是用於描述一個文件的特征的系統數據，比如訪問權限、文件擁有者以及文件數據庫的分布信息（inode)等等。在集群文件系統中，分布信息包括文件在磁盤上的位置以 及磁盤在集群中的位置。用戶需要操作一個文件就必須首先得到它的元數據，才能定位到文件的位置並且得到文件的內容或相關屬性。
使用stat命令，可以顯示文件的元數據
[root@ceph-node1 ~]# stat 1.txt File: ‘1.txt’ Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 802h/2050d Inode: 33889728 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: unconfined_u:object_r:admin_home_t:s0 Access: 2018-08-05 16:38:22.137566272 +0800 Modify: 2018-08-05 16:38:22.137566272 +0800 Change: 2018-08-05 16:38:22.137566272 +0800 Birth: - File：文件名 Size：文件大小（單位：B） Blocks：文件所占扇區個數，為8的倍數（通常的Linux扇區大小為512B，連續八個扇區組成一個block） IO Block：每個數據塊的大小（單位：B） regular file：普通文件（此處顯示文件的類型） Inode：文件的Inode號 Links：硬鏈接次數 Access：權限 Uid：屬主id/屬主名 Gid：屬組id/屬組名 Access：最近訪問時間 Modify：數據改動時間 Change：元數據改動時間 以上的參數均屬於文件的元數據，元數據即用來描述數據的數據。
- （2）元數據管理
元數據的管理方式有2種方式：集中式管理和分布式管理。
集中式管理是指在系統中有一個節點專門司職元數據管理，所有元數據都存儲在該節點的存儲設備上。所有客戶端對文件的請求前，都要先對該元數據管理器請求元數據。
分布式管理是指將元數據存放在系統的任意節點並且能動態的遷移。對元數據管理的職責也分布到各個不同的節點上。大多數集群文件系統都采用集中式的元數據管理。
因為集中式管理實現簡單，一致性維護容易，在一定的操作頻繁內可以提供較為滿意的性能。缺點是單一失效的問題，若該服務器失效，整個系統將無法正常 工作。而且，當對元數據的操作過於頻繁時，集中的元數據管理會成為整個系統的性能瓶頸。
分布式元數據管理的好處是解決了集中式管理的單一失效點問題，而且性能不會隨着操作頻繁而出現瓶頸。其缺點是，實現復雜，一致性維護復雜，對性能有一 定的影響。
-
二、什么是Ceph？
Ceph是一種為優秀的性能、可靠性和可擴展性而設計的統一的、分布式的存儲系統。Ceph 獨一無二地用統一的系統提供了對象、塊、和文件存儲功能，它可靠性高、管理簡便、並且是開源軟件。 Ceph 的強大足以改變貴公司的 IT 基礎架構、和管理海量數據的能力。Ceph 可提供極大的伸縮性——供成千用戶訪問 PB 乃至 EB 級的數據。 Ceph 節點以普通硬件和智能守護進程作為支撐點， Ceph 存儲集群組織起了大量節點，它們之間靠相互通訊來復制數據、並動態地重分布數據。
-
三、Ceph的核心組件
Ceph的核心組件包括Ceph OSD、Ceph Monitor和Ceph MDS三大組件。
Ceph OSD：OSD的英文全稱是Object Storage Device，它的主要功能是存儲數據、復制數據、平衡數據、恢復數據等，與其它OSD間進行心跳檢查等，並將一些變化情況上報給Ceph Monitor。一般情況下一塊硬盤對應一個OSD，由OSD來對硬盤存儲進行管理，當然一個分區也可以成為一個OSD。
Ceph Monitor：由該英文名字我們可以知道它是一個監視器，負責監視Ceph集群，維護Ceph集群的健康狀態，同時維護着Ceph集群中的各種Map圖，比如OSD Map、Monitor Map、PG Map和CRUSH Map，這些Map統稱為Cluster Map，Cluster Map是RADOS的關鍵數據結構，管理集群中的所有成員、關系、屬性等信息以及數據的分發，比如當用戶需要存儲數據到Ceph集群時，OSD需要先通過Monitor獲取最新的Map圖，然后根據Map圖和object id等計算出數據最終存儲的位置。
Ceph MDS：全稱是Ceph MetaData Server，主要保存的文件系統服務的元數據，但對象存儲和塊存儲設備是不需要使用該服務的。
查看各種Map的信息可以通過如下命令：ceph osd(mon、pg) dump
-
四、Ceph的架構
架構圖：
Ceph系統邏輯層次結構：
自下向上，可以將Ceph系統分為四個層次：
- （1）基礎存儲系統RADOS（Reliable, Autonomic, Distributed Object Store，即可靠的、自動化的、分布式的對象存儲）
顧名思義，這一層本身就是一個完整的對象存儲系統，所有存儲在Ceph系統中的用戶數據事實上最終都是由這一層來存儲的。而Ceph的高可靠、高可擴展、高性能、高自動化等等特性本質上也是由這一層所提供的。因此，理解RADOS是理解Ceph的基礎與關鍵。
- （2）基礎庫librados
這一層的功能是對RADOS進行抽象和封裝，並向上層提供API，以便直接基於RADOS（而不是整個Ceph）進行應用開發。特別要注意的是，RADOS是一個對象存儲系統，因此，librados實現的API也只是針對對象存儲功能的。
RADOS采用C++開發，所提供的原生librados API包括C和C++兩種。物理上，librados和基於其上開發的應用位於同一台機器，因而也被稱為本地API。應用調用本機上的librados API，再由后者通過socket與RADOS集群中的節點通信並完成各種操作。
- （3）高層應用接口
這一層包括了三個部分：RADOS GW（RADOS Gateway）、 RBD（Reliable Block Device）和Ceph FS（Ceph File System），其作用是在librados庫的基礎上提供抽象層次更高、更便於應用或客戶端使用的上層接口。
RADOS GW是一個提供與Amazon S3和Swift兼容的RESTful API的gateway，以供相應的對象存儲應用開發使用。RADOS GW提供的API抽象層次更高，但功能則不如librados強大。因此，開發者應針對自己的需求選擇使用。
RBD則提供了一個標准的塊設備接口，常用於在虛擬化的場景下為虛擬機創建volume。目前，Red Hat已經將RBD驅動集成在KVM/QEMU中，以提高虛擬機訪問性能。
Ceph FS是通過Linux內核客戶端和FUSE來提供一個兼容POSIX的文件系統。
-
五、RADOS的存儲邏輯架構
RADOS如圖所示，RADOS集群主要由2種節點組成。一種是負責數據存儲和維護功能的OSD，另一種則是若干個負責完成系統狀態監測和維護的monitor。OSD和monitor之間相互傳輸節點的狀態信息，共同得出系統的總體工作運行狀態，並形成一個全局系統狀態記錄數據結構，即所謂的cluster map。這個數據結構和RADOS提供的特定算法相結合，便實現了Ceph“無需查表，算算就好”的核心機制和若干優秀特性。
在使用RADOS系統時，大量的客戶端程序通過與OSD或者monitor的交互獲取cluster map，然后直接在本地進行計算，得出對象的存儲位置后，便直接與對應的OSD通信，完成數據的各種操作。可見，在此過程中，只要保證cluster map不頻繁更新，則客戶端顯然可以不依賴於任何元數據服務器，不進行任何查表操作，便完成數據訪問流程。在RADOS的運行過程中，cluster map的更新完全取決於系統的狀態變化，而導致這一變化的常見事件只有兩種：OSD出現故障，或者RADOS規模擴大。而正常應用場景下，這兩種事件發生的頻率顯然遠遠低於客戶端對數據進行訪問的頻率。